هندسة السياق: لماذا يضلّ وكلاء الذكاء الاصطناعي في المحادثات الطويلة وكيف تُعالج المشكلة

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

ما الذي يميّز هندسة السياق عن هندسة الـ prompt

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

• لا تظهر المشكلة فورًا، بل بعد عشرات التكرارات في المحادثة مع الوكيل
• الأعراض: ارتباك في اختيار الأدوات، واستخدام استدعاءات قديمة، وترسّخ الأخطاء السابقة
• تختلف هندسة السياق عن هندسة الـ prompt وRAG وMCP، فهي مجال مستقل لإدارة السياق

لماذا يبدأ الوكيل بالخطأ

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

ماذا يعني ذلك

مع انتقال وكلاء AI من العروض التجريبية إلى سيناريوهات عمل طويلة تعتمد على RAG والأدوات والذاكرة، تتحول إدارة السياق إلى تخصص هندسي مستقل، يقف على قدم المساواة مع تصميم الـ prompt واختيار النموذج. والفرق التي تضع قواعد صريحة لانتقاء السياق وتنظيفه قبل كل خطوة تحصل على وكلاء أكثر استقرارًا في المحادثات الطويلة.