مزودو نماذج اللغة يقدمون غالبا سياقا بحجم 32K مهما قال بطاقة النموذج

نشر مطور يشغّل وكيل محادثة وبرمجة مستضافا على نماذج بأوزان مفتوحة تحذيرا على dev.to في 26 سبتمبر: نافذة السياق المذكورة في بطاقة النموذج نادرا ما تطابق ما تقدمه نقطة النهاية فعليا.

الرقم المكتوب على البطاقة ليس الرقم الذي تحصل عليه

النافذة في البطاقة خاصية من خصائص الأوزان، أما النافذة التي يتلقاها المستخدم فتعتمد على الجهة التي تستضيف هذه الأوزان. وبحسب اختبارات الكاتب، تقدم معظم نقاط النهاية نحو 32K رمزا بصرف النظر عما تدعيه البطاقة، بينما تصل قلة منها إلى 256K، ولم يجد حتى الآن أي نقطة نهاية تقدم فعلا رقم 1M الوارد في إعلانات الإصدار.

وللمشغّل سبب: الطول الأقصى للسياق ميزانية لـ KV-cache تُوازن مقابل عدد الطلبات المتزامنة، وتقديم مليون رمز لكل طلب للجميع سيكون مكلفا للغاية. وهذه المقايضة لا تُوثَّق تقريبا أبدا، والفشل يحدث بصمت.

لا تظهر أي أخطاء

لا خطأ 413 ولا أي تحذير. يُخدم الطلب وفق أدنى سقف متاح، ويختفي الجزء الأول من السياق ببساطة. وفي المحادثة يكاد ذلك لا يُلاحظ: يصبح الحوار أقل ذكاء بمرور الوقت.

أما في المهام الوكيلية فهو القيد الحاسم: تصل جولة build طويلة إلى السقف، فيعمل compaction، ويتحول بيان الهدف إلى ملخص غامض، فيعيد النموذج الذي لم يعد يعرف بدقة ما كان يفعله خطة العمل من البداية بهدوء. ومن الخارج يبدو الأمر وكأن النموذج ضعيف في المهام الطويلة، لكن السبب هو إعدادات الاستضافة، على حد قول الكاتب.

كيف تجد السقف الحقيقي

أرسل طلبا أكبر من اللازم عمدا واقرأ الخطأ: فالمزودون يكشفون عادة الحد الأقصى الحقيقي في نص الخطأ، لذا فإن إرسال 500K رمز إلى نقطة نهاية تدّعي 1M يبيّن ما يعود فعلا. والطريقة الثانية أخشن: في تشغيل طويل، حدد النقطة التي يتوقف عندها أقدم محتوى عن التأثير في الناتج ثم عُدّ إلى الخلف.

ويقول الكاتب إن لا وثائق المزود ولا بطاقة النموذج كانت موثوقة في هذه المسألة.

ثلاث نتائج تستحق الاستيعاب

نتيجة الاختبارات القياسية تقيس النموذج عند طول سياق واحد، لا النموذج نفسه: فالأوزان ذاتها عند 32K وعند 200K ليست الوكيل نفسه. ومقارنة المزودين بتكلفة الرمز دون تثبيت السقف الفعلي تعني تسمية الفرق سعرا.

وفي gateway يستخدم fallback يمكن أن يتغير السقف في منتصف الجلسة: فالتشغيل الذي ينتقل من مزود بـ 200K إلى مزود بـ 32K لا يعيد خطأ بل يقتطع السياق. وهذه مشكلة صحة وليست مشكلة أداء.

وفي RAG يُبطل ذلك ضبط الاسترجاع بصمت: تُضبط أحجام الأجزاء و top-k وإعادة الترتيب وفق ميزانية مأخوذة من البطاقة. ونظام ضُبط على 128K لكنه يُخدم بـ 32K يسترجع أكثر من اللازم، وتُقتطع أجزاؤه المعاد ترتيبها، ويعود الجواب واثقا وخاطئا؛ ثم يبدأ الفريق بضبط نموذج embedding الذي لم يكن المشكلة يوما.

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