Habr: كيف تُفسد قاعدة المعرفة القديمة عمل وكلاء LLM وكيف يمكن إصلاح ذلك

نشر Habr الجزء الثاني من سلسلة مقالات عن التطوير باستخدام LLM، يشرح فيه المؤلف لماذا تُعدّ قاعدة المعرفة (knowledge base) القديمة أخطر من غياب الوثائق تمامًا. فإذا عُرض على الوكيل ملف markdown أنيق لكنه غير محدّث، فسيأخذه على أنه حقيقة، وسيبدأ بارتكاب الأخطاء على مستوى البنية المعمارية والحالات والاعتماديات.

لماذا يهمّ هذا الأمر

الفكرة الرئيسية بسيطة: يثق LLM بالسياق كما يثق المترجم (compiler) بالبيانات المُدخلة. فحين تحتوي قاعدة المعرفة على إصدارات قديمة من الخدمات وروابط معطوبة وخطط ابتعدت منذ زمن عن الواقع، يعتمد الوكيل على خريطة زائفة للمشروع. وهكذا لا تنشأ الأخطاء من ضعف النموذج، بل من أنه زُوِّد بوصف غير صحيح للبيئة. وفي الفرق التي تدير عشرات المشاريع المتوازية، سرعان ما تتحول هذه المشكلة إلى مشكلة منهجية، لا إلى سهو عابر.

ويؤكد المؤلف أن الانضباط اليدوي لا يجدي هنا تقريبًا. فكلما زاد عدد المستندات والمستودعات والجلسات مع الوكيل، تراكمت الفوضى (entropy) في قاعدة المعرفة بوتيرة أسرع. وحتى الـ workbench جيد التنظيم يصبح قديمًا منذ لحظة إنشائه إذا لم يفحصه أحد آليًا. ولذلك لم يعد السؤال: هل نكتب الوثائق أم لا؟ بل: كيف ندمج في العملية آليات تمنعها من التدهور بصمت وتسميم دورة التطوير التالية؟

كيف نرصد التقادم

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

• فحص الروابط الداخلية بين ملفات markdown
• مراقبة حداثة المستندات الرئيسية بحسب تاريخ التحديث
• فحص التغطية: يجب أن يكون لكل مشروع ملف workspace
• تجميع TODO من جميع مستندات markdown في نقطة مراجعة واحدة

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

القواعد والمزالق

لا تكفي السكربتات وحدها إذا لم تكن للمستندات نفسها دورة حياة واضحة. يقترح المؤلف وسمها بالحالات active وreference وdraft وarchived، ونقل المواد القديمة إلى archive/ بدل حذفها. وبعد كل مرحلة عمل، ينبغي للوكيل تحديث المستندات المرتبطة، وتوثيق ما لم يكتمل، وعند امتلاء نافذة السياق إعداد continuation prompt للجلسة التالية. وبهذا تبقى قاعدة المعرفة متزامنة بين الجلسات بدل أن تتشتت في ذاكرة النموذج.

يقول المؤلف:

«الخطة القديمة هي السياق المسموم نفسه، لكنها تبدو في ظاهرها بريئة».

وفي الجزء الثاني من الطرح يظهر الجانب المعاكس: فـ LLM يجعل الأتمتة رخيصة جدًا، ولذلك ينزلق المطوّر بسهولة إلى تحسين العملية بدل تحسين المنتج. فإضافة ADR جديد أو سكربت آخر أو pipeline مفصّلًا بإتقان تبدو تقدمًا، بينما قد لا تكون في production ميزة عاملة بعد. والمعيار العملي هنا صارم: المنتج أولًا، ثم staging والمراقبة وCI/CD، ثم الكتابة الصارمة للأنواع (typing) والاختبارات والدورات المستقلة الأكثر تعقيدًا. وإذا بنت الفرقة سلسلة كاملة «فرضية — توليد — نشر» قبل أن تتعلم رصد عملية merge معطوبة، فهي تستثمر في تحسين ميتا ذي عائد استثمار (ROI) مشكوك فيه.

ما معنى ذلك

يصيب الطرح المنشور على Habr موضع الألم الرئيسي في التطوير بمساعدة الذكاء الاصطناعي: فجودة إجابة النموذج لم تعد تتوقف على الـ prompt وحده، بل تتوقف بدرجة متزايدة على نظافة السياق المحيط بالشيفرة. والخلاصة عملية للفرق وللمطورين المنفردين: يجب أن تخضع قاعدة المعرفة للقواعد نفسها التي تخضع لها الشيفرة، أي فحوصات وحالات وتحديث منتظم. وإلا فلن يسرّع LLM العمل، بل سيسرّع انتشار الأخطاء القديمة التي تبدو معقولة وتتكرر من جلسة إلى أخرى.