بناء محرك معرفة عملي للمطور المستقل باستخدام Claude Code وLightRAG

إن إضاعة الوقت في البحث في الوثائق لإصلاح سطر واحد من الكود هو هدر حقيقي. ويزداد الأمر سوءاً إذا كنت مطور Full-stack تعمل بمفردك وتدير كل شيء بنفسك. إذا قام Claude Code بتفسير هيكل مشروعك بشكل خاطئ وكتب كوداً غير ذي صلة، فهذه ليست مشكلة ذكاء لدى الذكاء الاصطناعي، بل لأن مخزن المعرفة الخاص بك في حالة فوضى. إليك كيفية تحويل LightRAG من مجرد تثبيت بسيط إلى مستودع معرفة ذكي وفعال.

إعادة هيكلة وثائق المشروع حول الكيانات (Entities)

لا يقوم LightRAG بتقطيع النصوص بشكل عشوائي، بل يرسم رسماً بيانياً للمعرفة (Knowledge Graph) يربط بين الكلمات وعلاقاتها. لتجنب سوء فهم الذكاء الاصطناعي لسياق الكود الخاص بك، يجب عليك البدء بإعادة كتابة ملف README.md. سرد الميزات بشكل مسطح لا فائدة منه.

أضف تعليقات توضح التبعيات في الجزء العلوي من الوثيقة. على سبيل المثال، قم بتضمين علاقات ثنائية مثل (OrderProcessor, uses, PaymentService) مباشرة في النص. كلما كانت العلاقات المعقدة مقسمة إلى أجزاء أصغر، تمكن LightRAG من إنشاء عقد (Nodes) أكثر دقة. من خلال تحديد الروابط بين الخدمات (Services)، والمتحكمات (Controllers)، وDTOs بشكل صريح، يمكنك القضاء على ظاهرة "الهلوسة" التي تحدث عندما يفشل Claude Code في استيعاب هيكل المكتبة الداخلية. في الواقع، فهرسة الوثائق التي تحدد العلاقات ترفع موثوقية الإجابات المتعلقة بالبنية المعمارية إلى أكثر من 90%.

تصفية البيانات لمنع الفهرسة غير الضرورية

تغذية المحرك بكل الملفات المحلية هو تصرف غير حكيم. فهو يستهلك التوكنز (Tokens) ويجعل رسم المعرفة البياني مشتتاً. خاصة التبعيات الخارجية مثل node_modules التي تدرب عليها الذكاء الاصطناعي بالفعل من خلال كميات هائلة من البيانات العالمية؛ لذا لا داعي لتلويث محركك المحلي بها.

قم بإنشاء ملف .ragignore في جذور المشروع. يجب استبعاد نواتج البناء، السجلات، والملفات المؤقتة دون تردد:

• استبعاد مجلدات البناء مثل node_modules/, dist/, target/
• حظر البيانات المتطايرة الناتجة عن التشغيل مثل *.log, tmp/
• إذا كان هناك تعريفات واجهة متكررة، أضف وصف @primary_definition للملف الأساسي لمنحه الأولوية.

مجرد التخلص من البيانات غير الضرورية سيرفع دقة البحث إلى ما فوق 90%، بالإضافة إلى تسريع عملية البحث بفضل الفهرس الخفيف.

تحسين خادم MCP للربط مع Claude Code

يتواصل Claude Code مع العالم الخارجي عبر MCP. في هذه المرحلة، تمرير النص بالكامل سيؤدي إلى استجابة بطيئة واستنزاف لميزانيتك. السر يكمن في اختيار أعلى $k$ من العقد التي تمتلك أعلى درجة تشابه $S$.

$$D = \frac{sum_{i=1}^{k} S(N_i)}{k}$$

في إعدادات MCP، قم بتفعيل خيار only_need_context واحصره لاستخراج الفرع البياني (Sub-graph) المطلوب فقط. تحتاج إلى ذكاء في استدعاء الأنماط بناءً على طبيعة السؤال: استخدم نمط global عند السؤال عن البنية المعمارية، ونمط local عند طلب تعديل وظيفة (Function) محددة. ضبط هذه المعايير يجعل سرعة الاستجابة تتضاعف بأكثر من مرتين، مما يجعل الذكاء الاصطناعي يدرك نية السؤال بدقة ويشير إلى عقدة المعرفة الأكثر ملاءمة.

توزيع الموارد المحلية وضمان الاستقرار

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

إذا كان لديك 16GB من الرام، خصص حوالي 4GB فقط لحاوية LightRAG. اترك المساحة المتبقية لبيئة التطوير (IDE) والـ LLM المحلي. يمكنك وضع حدود قصوى في ملف docker-compose.yaml مثل cpus: '2.0' و memory: 4G. إذا كانت السرعة هي أولويتك، فاستخدم نموذج تضمين (Embedding) مثل nomic-embed-text الذي يبلغ زمن تأخيره 56ms. أما إذا كانت الدقة هي الأهم، فعليك الموازنة واختيار text-embedding-3-small رغم استغراقه 90ms.

تحديث المعرفة في الوقت الفعلي باستخدام Git Hook

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

استخدام post-commit hook في Git يحل هذه المشكلة. اكتب سكريبت يختار الملفات المعدلة فقط عند كل Commit ويرسلها إلى خادم LightRAG. استخرج قائمة الملفات المتغيرة باستخدام git diff-tree وأرسل فقط تلك التي لا تقع تحت حظر .ragignore إلى نقطة النهاية /insert. بوجود نظام فهرسة تراكمي كهذا، سيفهم Claude Code كودك "في هذه اللحظة" دائماً دون عناء إضافي، مما يوفر لك ساعة واحدة على الأقل يومياً كانت تضيع في الإدارة اليدوية.