تقنيات المعالجة المسبقة باستخدام بايثون لتحويل ملاحظات Obsidian إلى مجموعة بيانات GraphRAG

منع تعارض إصدارات المكتبات وأخطاء نفاد الذاكرة (OOM)

أول عقبة تواجهها عند بناء نظام RAG محلي هي سعة VRAM والتعارض الشديد في الإصدارات بين المكتبات. تستهلك نماذج الكمية (Quantization) بمستوى 8-بت حوالي 1 جيجابايت من VRAM لكل مليار معلمة (Parameter). وبالنظر إلى حصة أنظمة التشغيل مثل Windows أو macOS، يجب ترك مساحة فارغة بنسبة 20% على الأقل. بدون هذه المساحة، ستشهد أداءً كارثياً حيث تنخفض سرعة توليد الرموز (Tokens) إلى حوالي رمزين في الثانية. خاصةً إطار عمل lightrag-hku، الذي غالباً ما يطلق أخطاء وقت التشغيل عند دمجه مع إصدارات numpy 2.x الحديثة.

أولاً، افتح الطرفية (Terminal) وقم بتثبيت إصدار محدد عن طريق إدخال pip install numpy==1.26.4 --force-reinstall. بعد ذلك، قم بتثبيت nest_asyncio وأضف nest_asyncio.apply() في أعلى الكود الخاص بك. إذا لم تفعل ذلك، ستتعطل الحلقة غير المتزامنة (Asynchronous loop) في Jupyter Notebook مما يؤدي لتوقف العملية بالكامل. إذا كانت ذاكرة GPU أقل من 8 جيجابايت، فعند تهيئة LightRAG، اجعل embedding_batch_num أقل من 10، و llm_model_max_async حوالي 4. هذا الإعداد وحده كفيل بمنع ظاهرة نفاد الذاكرة (OOM) التي تسبب توقف النظام بدون سبب واضح، وسيوفر عليك ساعتين على الأقل من المحاولات الفاشلة.

تصفية التعبيرات النمطية (Regex) لملفات Markdown لبناء الرسم البياني للمعرفة

تخزين النصوص ككتل بسيطة يؤدي إلى فقدان السياق بين المعلومات. ومع ذلك، إذا قمت بتحليل هيكل روابط الويكي ([[link]]) في Obsidian بشكل صحيح، يمكنك إنشاء رسم بياني للمعرفة (Knowledge Graph) رائع حقاً. السر يكمن في إزالة رموز Markdown غير الضرورية قبل أن يقرأها نموذج اللغة الكبير (LLM). مجرد تنظيف الرموز الفوضوية يمكن أن يوفر ما يقرب من 30% من استهلاك الرموز.

عند كتابة الملاحظات، تعود على وضع حقول مثل type و domain في منطقة YAML العلوية؛ فهذا يغير سرعة تصفية البحث تماماً. استخدم نمط r"\[\[(.+?)\]\]" في وحدة re الخاصة ببايثون لاستخراج روابط الاتصال بين المستندات، ثم حولها إلى مجموعة بيانات علاقات بتنسيق JSONL. اسم الملف مهم أيضاً؛ فاستخدام الموضوع الجوهري للمعرفة كعنوان، بدلاً من تاريخ مثل "2024-04-14"، يجعل العقد المفهرسة تؤدي دورها بفعالية. البيانات المتصلة بهذه الطريقة تسمح بالاستدلال الذي يتجاوز البحث البسيط ليتنقل بين المفاهيم المختلفة.

طبقة التخزين المؤقت الدلالي باستخدام DiskCache

أكثر ما يضيع الوقت عند تشغيل LLM محلي هو إعادة حساب التضمينات (Embeddings) التي تم حسابها بالفعل. التخزين المؤقت الافتراضي في بايثون يختفي بمجرد إغلاق البرنامج. لذا، يجب استخدام DiskCache المعتمد على SQLite لإنشاء مستودع تخزين فيزيائي. صمم النظام بحيث إذا تجاوز تشابه الجيب تماماً (Cosine Similarity) بين الأسئلة 0.95، يتم إرجاع الاستجابة المخزنة مؤقتاً مباشرة دون استدعاء LLM. تطبيق هذا التخزين المؤقت الدلالي (Semantic Caching) يمكن أن يقلل وقت الاستجابة إلى حوالي 100 مللي ثانية.

الطريقة بسيطة: قم بتثبيت المكتبة عبر pip install diskcache وأنشئ فئة (Class) لتخزين أزواج نصوص التضمين والمتجهات. ومن الأفضل دمج خوارزمية ترجيح الوقت هنا:

$$Relevance Score = Cosine Similarity + (1.0 - decay\_rate)^{hours\_passed}$$

الهدف هو بناء منطق يجعل الملاحظة التي تم تعديلها للتو تظهر في مقدمة نتائج البحث. إذا ضبطت مدة الصلاحية (TTL) لذاكرة التضمين المؤقتة بساعة واحدة، ولذاكرة استجابات التوليد بساعتين، يمكنك الحصول على نظام استجابة فوري للأسئلة المتكررة.

الفهرسة متعددة الوسائط للبحث عن الصور

تحتوي المخططات المعمارية أو لقطات الشاشة الموجودة داخل الملاحظات على معلومات أكثر بكثير من النصوص. استبعادها من البحث يعد خسارة. باستخدام نموذج CLIP، يمكنك وضع الصور والنصوص في نفس المساحة الاتجاهية، بحيث يمكنك العثور على الصور ذات الصلة بمجرد كتابة "مخطط تدفق البيانات". إذا لم يكن لديك GPU عالي المواصفات، يمكنك تحويل نموذج CLIP-ViT-B-32 إلى تنسيق OpenVINO وتشغيله على CPU.

عندما تجد مسار صورة في ملف Markdown، قم بجمع حوالي 200 حرف من النص المحيط بها. بعد ذلك، استخرج أوصاف الصور (Captions) تلقائياً باستخدام نموذج VLM محلي خفيف مثل Phi-3.5-vision. قم بتخزين متجهات الأوصاف هذه مع متجهات ميزات الصور في قاعدة بيانات متجهات محلية مثل Qdrant. من خلال هذه العملية، سيتم تضمين حتى الصور المعقدة التي يصعب شرحها بالنص في نتائج البحث.

أتمتة الفهرسة في الوقت الفعلي باستخدام سكريبت Watchdog

إعادة فهرسة المخزن بالكامل في كل مرة تعدل فيها ملفاً واحداً هو عمل غير فعال. باستخدام مكتبة watchdog في بايثون، يمكنك اكتشاف لحظة حفظ الملف وتحديث الأجزاء المتغيرة فقط. ومع ذلك، بما أن الفهرسة المستمرة أثناء الكتابة ستجعل المعالج (CPU) يصرخ، فإن معالجة فك الارتداد (Debouncing) ضرورية.

عند كتابة السكريبت، اجعله يراقب المجلد باستخدام watchdog.observers وعند حدوث حدث تعديل، ينتظر لمدة 5 ثوانٍ قبل بدء العمل. يجب أيضاً تضمين عملية لمقارنة قيمة هاش SHA-256 لكل ملف للتأكد من أن المحتوى قد تغير فعلياً. قم باستخراج الملفات التي تغيرت قيم الهاش الخاصة بها فقط، واحذف العقد القديمة وأدخل المتجهات الجديدة. بهذه الطريقة، ستحصل على قاعدة معرفية محدثة في الوقت الفعلي تنعكس في نظام البحث بمجرد حفظ الملاحظة، مما يعني أنك لن تحتاج للضغط على زر التحديث يدوياً أبداً.