كيف تحوّل هندسة السياق نموذجًا لغويًا محليًا ضعيفًا إلى وكيل موثوق

أظهر كاتب المقالة على Habr أن موثوقية الوكيل المبني على نموذج لغوي محلي، يعمل في بيئة مغلقة على عتاد محدود، لا يحددها حجم النموذج، بل طريقة بناء سياقه.

لماذا لا يجدي «اختيار نموذج أكبر»

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

مما يتكوّن السياق «الصحيح»

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

• حدّ صادق للصلة بالسؤال: يُعرض على النموذج ما يتعلق بالسؤال فعلًا فقط، لا كل شيء «تحسبًا»
• ترتيب مدروس للأقسام: توضع المعلومات المهمة للإجابة بحيث لا «يفقدها» النموذج وسط التفاصيل الثانوية

بعبارة أخرى، سيختلف السياق للسؤال نفسه بحسب دور المستخدم وقناة الطلب والموضوع: فمن المنطقي أن يُعرض على موظف الدعم ومطوّر البرمجيات مقتطفان مختلفان من قاعدة المعرفة، حتى لو سألا من الناحية الشكلية «عن الشيء نفسه».

بماذا يختلف النموذج القوي عن الضعيف في هذا السيناريو

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

وعمليًا، يعني ذلك أن اختبار المطالبات (prompts) وخط معالجة السياق (context-pipeline) ينبغي أن يجري على النموذج المستهدف (الضعيف)، لا على نموذج سحابي رائد: فما يبدو صالحًا على نموذج قوي قد ينهار عند نقله إلى نموذج محلي.

أين يكون ذلك حرجًا بوجه خاص

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

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

ماذا يعني ذلك

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