هندسة السياق تحل محل هندسة الأوامر بوصفها مهارة الذكاء الاصطناعي الأهم
لم تكن هندسة الأوامر يوماً مسألة إيجاد كلمات سحرية. كانت تتعلق بتزويد النموذج بمعلومات كافية وذات صلة، بصيغة يمكنه استخدامها، لإنتاج إجابة جيدة. كان هذا الفرق أقل أهمية عندما كانت المهمة مجرد سؤال وجواب واحد. أما اليوم، فمعظم أنظمة الذكاء الاصطناعي الإنتاجية هي وكلاء: حلقات تستدعي أدوات، وتقرأ نتائج، وتسترجع وثائق، وتحمل حالة عبر عشرات الخطوات، فأصبح هذا الفرق بالغ الأهمية.
المهارة التي تحدد نجاح هذه الأنظمة ليست صياغة الأمر بعد الآن، بل هندسة السياق — أي تحديد ما يدخل نافذة سياق النموذج في كل خطوة، وكيف يُنظَّم، ومتى يُحذف. الفرق التي تتعامل مع هذا كأمر ثانوي تبني وكلاء مكلفين وبطيئين، ويصعب تصحيح أخطائهم.
لماذا لم تعد هندسة الأوامر كافية
الأمر الواحد المصاغ بعناية يفترض أن النموذج يملك أصلاً كل ما يحتاجه للإجابة. لكن مسارات عمل الوكلاء لا تعمل بهذا الشكل. فوكيل يعالج عطلاً إنتاجياً قد يجمع مقتطفات من السجلات، ودليل تشغيل، وثلاث محادثات Slack ذات صلة، ونتائج استدعاءين لأدوات — كل ذلك قبل أن يكتب كلمة واحدة من إجابته الفعلية. لا شيء من هذا هو «الأمر» بالمعنى الذي كان سائداً في 2023. إنه ميزانية سياق، وكل رمز (token) فيها قرار.
نوافذ السياق الأكبر جعلت الأمر أسوأ قبل أن تُحسّنه. عندما كانت نماذج جيل GPT-4 تتوقف عند حدود 32 ألف رمز، كانت الفرق مضطرة للانتقاء بدافع الضرورة. نوافذ السياق بمليون رمز أزالت هذا القيد، وتبيّن أن الاستجابة البديهية — إلقاء كل ما له صلة وترك النموذج يرتبه — تُضعف الأداء. تُظهر الأبحاث حول الاسترجاع في سياقات طويلة باستمرار أن النماذج توزّع انتباهها بشكل غير متساوٍ عبر سياق كبير، وتفضّل غالباً المعلومات القريبة من البداية أو النهاية، وتفقد الدقة في الحقائق المدفونة في الوسط. المزيد من الرموز لا يعني مزيداً من الإشارة المفيدة؛ غالباً ما يعني مزيداً من الضجيج مع فاتورة API أعلى.
أربع مهام لهندسة السياق
عملياً، تنقسم هندسة السياق إلى أربع مسائل منفصلة، وتعود معظم أخطاء الوكلاء إلى الإخلال بواحدة منها.
اختيار الاسترجاع
تحديد ما يُدخَل إلى السياق أصلاً. هذه هي المهمة التي بُنيت من أجلها خطوط أنابيب RAG، لكن جودة الاختيار أهم من استرجاع أكبر قدر ممكن. إعادة أفضل 20 مقتطفاً من حيث التشابه الدلالي ليست مثل إعادة الخمسة التي تجيب فعلاً عن السؤال. الفرق التي تضبط أنظمتها لتفضيل الكمية على الدقة تنتهي بها الحال في نفس فخ «إلقاء كل شيء»، لكن هذه المرة يقوم بذلك نموذج تمثيل (embedding) بدلاً من إنسان.
الضغط
مخرجات الأدوات الخام وملفات السجلات ومقتطفات الوثائق نادراً ما تكون بصيغة تستحق الإرسال كما هي. يمكن ضغط أثر مكدّس (stack trace) من 400 سطر إلى ثلاثة أسطر ذات صلة وملخص دون خسارة أي شيء يحتاجه النموذج. من هنا يأتي معظم التوفير في تكلفة الرموز في أنظمة الوكلاء الإنتاجية، ومن هنا أيضاً قد يحذف التلخيص الساذج بصمت التفصيل الوحيد المهم.
البنية والترتيب
موضع المعلومة داخل السياق يؤثر في استخدام النموذج لها بشكل صحيح. وضع القيود والتعليمات مباشرة قبل خطوة التوليد، بدلاً من دفنها في أعلى أمر نظام طويل، يحسّن بشكل قابل للقياس اتباع التعليمات في سياقات طويلة. الترتيب ليس تجميلياً — إنه عنصر حامل للبنية.
إعادة الكتابة إلى الذاكرة
الوكلاء الذين يعملون لأكثر من جولة واحدة يحتاجون إلى سياسة تحدد ما يُكتب إلى الذاكرة الدائمة وما يبقى مؤقتاً في السياق الحالي. كتابة كل شيء تحوّل الذاكرة إلى مكب ثانٍ بنفس مشكلة الضجيج. عدم كتابة أي شيء يجعل الوكيل يستخرج نفس الحقائق من جديد في كل جلسة، مستهلكاً الرموز والوقت في إعادة الاكتشاف.
أين تُخطئ الفرق
الخطأ الأكثر شيوعاً هو التعامل مع السياق كموارد مجانية. وهو ليس كذلك. كل وثيقة إضافية في النافذة تزيد زمن الاستجابة والتكلفة، وبعد كثافة معينة، تُسبب انخفاضاً قابلاً للقياس في جودة الإجابة يُعرف أحياناً بـ«تحلل السياق». الخطأ الثاني هو التجميع الثابت للسياق: بناء خط أنابيب واحد لتركيب السياق واستخدامه لكل استعلام، بصرف النظر عن احتياج المهمة إلى ثلاث وثائق أو ثلاثين. الخطأ الثالث هو تجاهل سياسة الحذف كلياً، فتتراكم مخرجات الأدوات في جلسة وكيل طويلة الأمد حتى تصبح معظم نافذة السياق مجرد هيكل من خطوات لا يحتاجها الوكيل بعد الآن.
كيف يبدو هذا في نظام يعمل بشكل جيد
الفرق التي تُحسن هذا الأمر تملك عادة ميزانية سياق واضحة لكل خطوة: سقف رموز للوثائق المسترجعة، وسقف منفصل لمخرجات الأدوات، وحصة محفوظة للتعليمات وأحدث جولات المحادثة لا تُزاح أبداً. وهي تسجّل محتوى السياق عندما يُنتج الوكيل إجابة سيئة، تماماً كما تُسجَّل آثار الأخطاء البرمجية، لأن تركيب السياق أصبح الآن سطحاً أساسياً للتصحيح، لا تفصيلاً تنفيذياً.
الخلاصة العملية
- أوقفوا تحسين صياغة الأوامر بمعزل عن غيرها. دقّقوا فعلياً ما يدخل نافذة السياق في كل خطوة من تنفيذ الوكيل، وقيسوا كم من ذلك يستخدمه النموذج فعلياً.
- اعتبروا دقة الاسترجاع أهم من شموليته. إعادة نتائج أقل وأكثر صلة أفضل من إعادة نتائج أكثر على أمل أن يُصفّيها النموذج.
- بنوا خطوة ضغط لمخرجات الأدوات والسجلات قبل دخولها نافذة السياق، لا بعد أن تُظهر مراجعة التكاليف إنفاق الرموز.
- ضعوا تعليمات المهمة وقيودها قريباً من نقطة التوليد، لا مدفونة في أعلى أمر نظام طويل، خصوصاً حين يتجاوز السياق بضعة آلاف من الرموز.
- حدّدوا سياسة واضحة لإعادة الكتابة إلى الذاكرة، بدلاً من الافتراض التلقائي بتكديس كل شيء أو حذف كل شيء بين الجولات.