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

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

لماذا هذا مهم

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

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

كيفية اكتشاف التقادم

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

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

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

القواعد والفخاخ

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

كما يكتب المؤلف:

"الخطة القديمة هي نفس السياق المسموم، فقط بمظهر بريء."

الجزء الثاني من الحجة يجلب الجانب المعاكس: LLM يجعل الأتمتة رخيصة جدًا، لذا يبدأ المطور بسهولة في تحسين العملية بدلاً من المنتج. ADR آخر، نص برمجي آخر أو خط أنابيب مخطط بشكل مثالي يبدو وكأنه تقدم، حتى لو كان الإنتاج قد لا يزال يفتقد إلى ميزة تعمل. الإرشاد العملي هنا صارم: أولاً المنتج، ثم التطوير والمراقبة وCI/CD، ثم الكتابة والاختبارات والدورات الذاتية الأكثر تعقيدًا. إذا بنت الفريق سلسلة كاملة "الفرضية - الإنشاء - النشر" قبل تعلم كيفية اكتشاف دمج معطوب، فإنها تستثمر في ميتا-تحسين بعائد استثمار مشكوك فيه.

ماذا يعني هذا

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