من المجلدات إلى قاعدة المعرفة: كيف جعلت ملاحظاتي تعمل لصالحي

سلسلة: إدارة المعرفة المدعومة بالـ AI — المقال 1 من 9

فخ المجلدات

كنت مستخدماً مكثّفاً لـ OneNote لسنوات. كان مثالياً بالنسبة لي في ذلك الوقت. كانت عندي أقسام متداخلة داخل أقسام داخل دفاتر ملاحظات، ملوّنة ومُعتنى بها بعناية. عندما كنت أحتاج شيئاً، كنت أتنقّل في تسلسل هرمي بنيته من ذاكرتي. كان يعمل طالما تذكّرت أين وضعت الأشياء، وطالما أن المعلومات تناسبت بسهولة في تصنيف واحد.

في كثير من الأحيان لم تكن تتناسب مع تصنيف واحد فقط. كان هذا محبطاً، لكنني تعايشت معه.

هل ملاحظة عن نمط مصادقة API تنتمي إلى "الأمان" أم "Backend" أم "مشروع بيتا"؟ في نظام المجلدات، تختار واحداً وتأمل أن تتذكر أيّهما اخترت بعد ستة أشهر. أو تنسخها. أو تنشئ اختصاراً. كل حل هو حل بديل مؤقت لحقيقة أن المجلدات تفرض محوراً واحداً للتنظيم على معلومات تعيش على محاور متعددة في آنٍ واحد.

المجلدات هي الطريقة التي نظّم بها معظمنا الأشياء دائماً. على حواسيبنا، في بريدنا الإلكتروني، في رؤوسنا. بدت وكأنها الطريقة الطبيعية للتفكير في المعلومات.

الوسوم والخصائص وشبكة الروابط

عندما انتقلت إلى Obsidian، حملت العادة معي. أول vault عندي بدا مثل دفاتر ملاحظات OneNote: أشجار مجلدات عميقة، مرتّبة بعناية. Obsidian كان أداة أفضل، لكنني كنت أستخدمه بنفس الطريقة. كان خزانة ملفات بواجهة أجمل.

التحوّل بدأ عندما عثرت على فكرة تنظيم الملاحظات بالوسوم وخصائص الـ front matter (أو خصائص الصفحة) بدلاً من المجلدات. Obsidian يدعم كتلة YAML في أعلى كل ملاحظة حيث يمكنك تعريف بيانات وصفية منظّمة: وسوم، علاقات مع ملاحظات أخرى، مصادر، حالة. طبعاً، Obsidian يعرض كل ذلك في واجهة مستخدم لطيفة فلا تحتاج للتعامل مع الإعدادات الخام. بدلاً من وضع ملاحظة داخل مجلد اسمه "الأمان"، تضع عليها وسم knowledge/security وأيضاً knowledge/backend وتربطها أيضاً بمشروع بيتا. الملاحظة تتواجد في سياقات متعددة في نفس الوقت بدون نسخها.

والأهم من ذلك، بدأت أستخدم خصائص العلاقات — up للملاحظات الأم، sibling للروابط الجانبية، source للمراجع. هذا أنشأ شبكة من الروابط الصريحة بين الملاحظات تتواجد بشكل مستقل عن مكان الملفات على القرص. الموقع الفعلي أصبح ثانوياً. المعنى كان في البيانات الوصفية.

ما زلت أضع الوسوم على كل ملاحظة يدوياً. أنا مهووس بهذا. لكن تلك العادة، التي بدت كعبء إضافي في ذلك الوقت، تبيّن أنها كانت الأساس لكل ما جاء بعدها.

الخروج من حدود الـ Vault

بمجرد أن استوعبت فكرة أن الروابط أهم من الموقع، ظهر احتكاك جديد: حدود vault الخاص بـ Obsidian. الـ vault في Obsidian هو مفهوم استخدام مجلد جذري عالي المستوى لتخزين جميع ملفات Markdown الخاصة بك، ملفات ملاحظاتك. داخل هذا الـ vault، كل شيء مترابط وقابل للاكتشاف. خارجه، لا شيء متصل. لا مشاريع الكود، لا مستندات العمل، لا ملفات PDF المرجعية. الـ vault كان جزيرة منظّمة بشكل أفضل، لكنه ظلّ جزيرة.

اتّضح هذا لي خلال محادثة مع زميل. كان قد جرّب Obsidian وتخلّى عنه لأن عمله الفعلي لم يكن يعيش داخل الـ vault. تلك المحادثة قادتني لبناء إضافة FolderTether لـ Obsidian. تُنشئ رابطاً ثنائي الاتجاه بين ملاحظة وأي مجلد على نظام الملفات. من Obsidian، نقرة واحدة تفتح المجلد المرتبط في Finder. من Finder، ملف .url موجود في المجلد يفتح الملاحظة مباشرة في Obsidian. الـ vault يتوقف عن كونه حديقة مسوّرة ويصبح فهرساً للتنقّل عبر مساحة عملك الرقمية بالكامل.

أداة صغيرة، لكنها أكملت تحوّلاً في طريقة تفكيري بالملاحظات. الملاحظة عن مشروع بيتا لا تحتاج أن تعيش في مجلد "المشاريع". لا تحتاج حتى أن تكون بالقرب من ملفات المشروع. تحتاج فقط رابطاً إليها. نفس المبدأ الذي نقلني من المجلدات إلى الوسوم امتدّ الآن خارج الـ vault نفسه: الموقع الفعلي ثانوي مقارنة بالعلاقات.

وتبيّن أن هذا مهم لوكلاء AI أيضاً. عندما يستعلم Claude Code من الـ vault الخاص بي، يستطيع اكتشاف الملاحظات عن المشاريع ويتبع خاصية linked_dir للعثور على مجلد المشروع الفعلي بدون أن أخبره أين توجد الأشياء. الـ vault أصبح فهرساً ليس فقط لي، بل لأي أداة تستطيع قراءة Markdown واتباع الروابط.

عندما لا يكون التنظيم الجيد كافياً

هنا يتوقف معظم الناس، وبصراحة، هنا توقفت أنا أيضاً لفترة. الوسوم والروابط تحسين حقيقي مقارنة بالمجلدات. تستطيع إيجاد الأشياء حسب الموضوع، تتبّع الروابط بين الأفكار، وعرض الرسم البياني في Obsidian يعطيك خريطة بصرية لكيفية ترابط كل شيء. لنظام إدارة معرفة شخصي، هذا جيد. لمئات الملاحظات، ممتاز.

لآلاف الملاحظات، ينهار بطريقة مختلفة.

المشكلة على "نطاق واسع" لم تعد التنظيم، بل الاسترجاع. يمكنك أن تضع الوسوم بشكل مثالي ومع ذلك لا تجد ما تحتاجه، لأنك تبحث عن مفهوم وملاحظتك استخدمت كلمات مختلفة. ابحث عن "authentication" ولن تجد الملاحظة التي كتبتها عن "session token management" أو "login security". معظم الناس يتوقعون أنها عن نفس الشيء. البحث بالكلمات المفتاحية يجد تطابقات نصية. لا يفهم المعنى.

هنا أخذت الرحلة منعطفاً آخر. منعطف حدث فقط بعد أن بدأت العمل مع AI وتطبيق RAG (التوليد المعزّز بالاسترجاع). البحث الدلالي يعتمد على المتجهات (تمثيلات رقمية للمعنى) ويُجرى البحث بناءً على التشابه بدلاً من التطابق النصي الحرفي. تسأل "كيف أتعامل مع مصادقة المستخدم؟" فيُرجع لك ملاحظات عن session tokens وتدفقات OAuth وأمان تسجيل الدخول، لأنه يفهم أن هذه المفاهيم مرتبطة حتى لو لم تشترك في أي كلمات مفتاحية.

بمجرد أن تجرّب البحث الدلالي، يصبح البحث بالكلمات المفتاحية مثل البحث عن كتاب بلون غلافه.

رؤية كيف تتصل الأفكار

لكن حتى البحث الدلالي له سقف. رغم أنه يجد المستندات ذات الصلة، لا يفهم كيف ترتبط ببعضها. يستطيع أن يخبرك أن خمس ملاحظات كلها مرتبطة بـ "AI"، لكنه لا يستطيع أن يخبرك أن اثنتين منها تصفان نفس مزوّد LLM، وأن واحدة تشير إلى نموذج لم يعد state of the art، أو أن ثلاثة منها كُتبت عن نفس إطار عمل الوكلاء.

هذا ما يضيفه رسم المعرفة البياني (Knowledge Graph). بدلاً من معاملة الملاحظات كمستندات منعزلة تصادف أنها تطابق استعلاماً، يستخرج رسم المعرفة البياني الكيانات والعلاقات بينها. يبني هيكلاً يعكس كيف تتصل المعلومات فعلاً. تتوقف عن السؤال "أي المستندات تتطابق؟" وتبدأ بالسؤال "كيف ترتبط هذه الأفكار؟" و"أي المشاريع تستخدم هذه التقنية؟" و"ماذا كتبت أيضاً عن هذه الأداة؟"

الرسم البياني لا يحلّ محل البحث. يجلس فوقه. البحث الدلالي يجد الملاحظات ذات الصلة؛ رسم المعرفة البياني يفهم الروابط بينها.

اسأل ملاحظاتك سؤالاً واحصل على إجابة

السبب الذي يجعلني أكتب هذه السلسلة هو تسليط الضوء على ما يحدث عندما تجمع كل هذا مع وكيل AI مثل Claude Code.

الإعداد: Obsidian يحتفظ بالملاحظات. فهرس دلالي يجعلها قابلة للبحث بالمعنى. رسم معرفة بياني يرسم العلاقات بين الكيانات. ووكيل AI يجلس في القمة، يستقبل سؤالك، يسترجع السياق المناسب من الطبقات الثلاث، ويولّد إجابة مع اقتباسات تعود إلى ملاحظاتك الفعلية.

هذا هو RAG مُطبّق على قاعدة معرفتك الشخصية. تسأل سؤالاً بلغة طبيعية. النظام يسترجع السياق المناسب من ملاحظاتك. النموذج يولّد إجابة مبنية على ما كتبته فعلاً، مع روابط إلى الملاحظات المصدرية حتى تتحقق وتتعمّق أكثر.

يبدو كبنية تحتية كثيرة لملاحظات شخصية. وإذا كان عندك خمسون ملاحظة عن وصفات طبخ وخطط سفر، فهي فعلاً كذلك. لكن إذا كان عندك سنوات من المعرفة المتراكمة عبر مشاريع وأبحاث وقرارات وأفكار، فهذا يغيّر الغرض من ملاحظاتك. وكشخص تتقاطع مشاريعه وأفكاره بانتظام بين الخاص والمهني، امتلاك طريقة لربط كل ذلك والاستعلام عنه يغيّر قواعد اللعبة.

لم أخطط لهذا المسار. لم أجلس يوماً وقررت بناء خط أنابيب لإدارة المعرفة. بدأت بنقل ملاحظاتي من OneNote. ثم أحبطتني المجلدات. ثم اكتشفت الوسوم. ثم وصلت لحدود البحث بالكلمات المفتاحية. كل خطوة حلّت مشكلة كشفتها الخطوة السابقة. وكل خطوة، كما تبيّن، كانت تمهّد الطريق للخطوة التالية.

أنا محظوظ أيضاً بالتوقيت. لو كنت قمت بإعادة التنظيم هذه بعد سنتين من الآن بدلاً من قبل سنتين، كانت أدوات AI ستكون موجودة لكن ملاحظاتي لم تكن لتكون جاهزة لها. الوسوم، العلاقات، خصائص الملاحظات المنظّمة — كل ذلك العمل اليدوي الذي قمت به قبل أن تصبح وكلاء AI جزءاً من سير عملي هو بالضبط ما يجعل الملاحظات قابلة للاستهلاك من قبل وكلاء AI الآن. الدرس هو أن الاستثمار في كيفية تنظيم معلوماتك يؤتي ثماره بطرق لا تستطيع توقعها وقت القيام بذلك.

ما التالي

هذا المقال الأول في سلسلة من تسعة أجزاء عن بناء نظام إدارة معرفة مدعوم بالـ AI. المقال التالي يتناول Obsidian تحديداً، ليس كتطبيق لتدوين الملاحظات، بل كمنصة معرفة، ولماذا تبيّن أن ملفات Markdown على القرص هي الأساس المثالي لكل ما ذُكر أعلاه.

هذا المقال جزء من سلسلة إدارة المعرفة المدعومة بالـ AI. التالي: Obsidian كمنصة معرفة.