100 ألف رمز كافية: اضغط الذاكرة بدل شراء نافذة أكبر

النافذة ليست المشكلة

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

مشروع billion-context، وهو مشروع TypeScript لـ ranxianglei يتسلق منذ أواخر سبتمبر، يتبنى الموقف المعاكس في شعاره: سياق بحجم 100K كافٍ. ليس "كافٍ في الوقت الحالي". كافٍ، إن توقفت عن التعامل مع المحادثة كسجل لا يقبل إلا الإضافة.

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

كيف يعمل الضغط

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

الخيار التصميمي المهم أن النموذج هو من يقرر متى يضغط، لا عتبة ثابتة. عادةً ما يعمل الملخِّص المدمج في أي مضيف عند امتلاء النافذة، فيستبدل كل ما قبل نقطة القطع بملخص واحد لا يمكن التراجع عنه. أما billion-context فيضغط في نطاقات صغيرة، ويبقيها قابلة للعكس، ويحافظ على ذاكرة البادئة سليمة.

هذه النقطة الأخيرة هي التفصيل الهندسي الذي يستحق الاهتمام. فذاكرة البادئة هي ما يجعل جلسات الوكيل الطويلة محتملة التكلفة؛ وإذا أعاد كل ضغط كتابة بداية المحادثة، فإن الذاكرة تخفق وتدفع السعر كاملاً للسجل بأكمله من جديد. يقول المشروع إن الجلسة السليمة تحافظ على نسبة إصابة 95-97% في ذاكرة البادئة، وإن الضغط نفسه لا يكلف أكثر من 2% من الحمل الإضافي. وهذه أرقامه هو، ويأتي مع أوامر تُنسب انخفاض نسبة الإصابة إلى سبب، غالباً انتهاء صلاحية TTL لذاكرة المنبع أو تبديل النموذج.

الرقم الذي يجعل الادعاء قابلاً للتصديق

يعلن الموردون توفير الرموز باستمرار. غير العادي هنا دراسة طولية مرفقة بالشيفرة: أربعة أشهر ونصف، ثلاثة مضيفين، 174,327 استدعاءً للنموذج، و18.76B رمز إدخال متراكم على مضيف واحد، ونحو 24.7B على جميعها. ويقول التقرير إن أطول الجلسات امتدت من 8,584 إلى 12,049 استدعاءً، مع صفر تجاوزات لنافذة السياق على نماذج بسعة 204,800 رمز.

صفر تجاوزات هي الجملة المهمة. تعني أن أياً من الجلسات لم تمت لأن المحادثة كبرت على النموذج. وكل ما تبقى في الدراسة يقع في أثر هذه الجملة.

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

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

ما الذي يتغير في الروتين اليومي

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

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

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

لماذا صار هذا فئة قائمة بذاتها

هناك ثلاثة مقاربات مختلفة على الأقل تتنافس على المشكلة نفسها. الأولى جواب المختبر: ابنِ نافذة أكبر. الثانية جواب إطار التشغيل: استرجع بدل أن تتذكر، واحتفظ فقط بمجموعة عمل داخل السياق. الثالثة، التي يمثلها billion-context: احتفظ بالمحادثة واضغطها في مكانها، بشكل قابل للعكس.

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

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

وهناك أيضاً مسألة الترخيص الصغيرة. الورقة التقنية برخصة MIT وتقيم في المستودع. أما ترخيص المستودع نفسه فيُذكر بأنه "Other" لا ترخيص OSI قياسي. وإذا كنت تنشره داخل شركة، فسيظهر هذا الفرق.

الاستنتاج المزعج

إن كان الضغط يعمل جيداً بما يكفي ليكفي 100K، فإن جزءاً كبيراً من تسويق نوافذ السياق يستهدف مشكلة أرخص حلاً في البرمجيات. هذا لا يجعل النوافذ الأكبر عديمة الفائدة، فمستند من 400 صفحة يجب أن يتسع له مكان ما، لكنه يعني أن "لدينا مليون رمز" حجة أضعف مما تبدو. الأمر كالإعلان عن خزان وقود أكبر بدل استهلاك أفضل.

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

للمشروع أكثر من ألف نجمة، ونحو 400,000 تنزيل شهري على npm، وشارات لأكثر من عشرين عميلاً. هذه ليست قاعدة تثبيت بمستوى الهواية. إنها تشير إلى أن الألم حقيقي ومنتشر، وأن الجواب الذي تمتد إليه الأيدي ليس صفراً آخر في حجم النافذة.

وهذا هو الخلاصة المفيدة، أياً كانت الأداة التي ستستخدمها في النهاية. السياق ميزانية، لا وعاء. الفرق التي تتعامل معه بهذا الشكل ستنجز أكثر مقابل كل دولار، وتلك التي تنتظر نافذة أكبر ستستمر في الدفع مقابل امتياز ألا تقرر ما يهم.