قد يعمل الوكيل المدعوم بنماذج اللغة الكبيرة (LLM) بشكل مثالي في العروض التجريبية، ثم يتباطأ وتتضخم فاتورته بعد عدد قليل من التفاعلات. الجاني الخفي ليس نموذجاً غير مستقر، بل هو "انزياح الرموز" (token drift)، وهو التضخم التدريجي في المطالبة (prompt) التي يتعين على النموذج معالجتها في كل مرة.
يحدث انزياح الرموز عندما تضيف كل عملية تفاعل المزيد من النصوص إلى سياق الإدخال الخاص بالنموذج. تتراكم سجلات المحادثة، ومخططات الأدوات (tool schemas)، واستجابات واجهة برمجة التطبيقات (API)، والمستندات المسترجعة، مما يجعل كل استدعاء لاحق يحمل حمولة أكبر. وبما أن وقت معالجة النموذج وتكلفته يرتفعان مع عدد رموز الإدخال، فإن التكلفة ترتفع بشكل تربيعي وليس خطياً.
لماذا تظهر المشكلة في بيئة الإنتاج وليس في العروض التجريبية
تحافظ عمليات النشر الحقيقية على كل شيء: كل ما ينطقه المستخدم، وكل مخرجات الأدوات، وكل جزء من المعرفة المسترجعة. يظل هذا التراكم مخفياً حتى يرتفع زمن الاستجابة (latency) وتصل الفاتورة.
المصادر الشائعة لانزياح الرموز
- النصوص المكررة – الاحتفاظ بكل رسالة قديمة في المطالبة بدلاً من تلخيصها أو التخلص منها.
- مخططات أدوات ثقيلة – إرسال تعريفات JSON ضخمة لقدرات الأدوات في كل دورة.
- نتائج أدوات ضخمة – تضمين استجابات API كاملة أو صفوف قواعد بيانات تحتوي على بيانات أكثر مما يحتاجه الوكيل فعلياً.
- تضخم الـ RAG – توليد المعزز بالاسترجاع (RAG) الذي يضيف العديد من أجزاء المستندات، والتي قد يكون بعضها قديماً أو غير ذي صلة.
- الذاكرة المكررة – حشد ملخص، وكائن حالة (state object)، والنص الخام معاً، مما يكرر نفس المعلومات ثلاث مرات.
كل من هذه العوامل يضيف رموزاً لا تساهم في قدرة استدلالية جديدة، ومع ذلك فهي تضخم حجم المطالبة.
كيفية التحكم في ميزانية الرموز
1. اعتماد تصميم سياق متعدد الطبقات
- تعليمات مستقرة – احتفظ بمطالبات النظام وقواعد السلامة في الأعلى وقم بالإشارة إليها بدلاً من إعادة إرسالها في كل دورة.
- حالة منظمة – تخزين تمثيل مضغوط للأهداف والقرارات والمعرفات التي يمكن للوكيل قراءتها بسرعة.
- سجل مضغوط – تلخيص الدورات القديمة في فقرة قصيرة قابلة للقراءة البشرية، مع التحديث فقط عند الوصول إلى حد معين.
- الدورات الأخيرة – تضمين الرسائل القليلة الأخيرة حرفياً للحفاظ على الاستمرارية.
إن فصل النص الثابت عن المحتوى القابل للتلخيص يمنعك من إعادة إرسال نفس الكلمات مراراً وتكراراً.
2. تقليص مخرجات الأدوات
- استخراج الحقول التي يستخدمها الوكيل فعلياً فقط؛ والتخلص من الأوصاف المطولة.
- استبدال النتائج الكبيرة بملخص موجز أو معرف مرجعي (reference ID)، وتخزين الحمولة الكاملة في قاعدة بيانات أو ذاكرة تخزين مؤقت (cache) أو مخزن كائنات (blob store).
- عندما تعيد الأداة قائمة، أرسل فقط العناصر الـ N الأولى التي تهم القرار الحالي.
3. تطبيق التلخيص الذكي
- تخطَّ عملية التلخيص بعد كل دورة؛ فالمعالجة الإضافية تزيد من الأعباء (overhead).
- قم بتحديث الملخص فقط عندما يتجاوز عدد الرموز المتراكم للدورات القديمة حداً معيناً.
- احتفظ بالحقائق المهمة — مثل المعرفات (IDs)، والمبالغ، والطوابع الزمنية — في مخزن منظم بدلاً من تضمينها في نص إنشائي، ليبقى الملخص قصيراً.
4. تتبع المقاييس الصحيحة
- سجل استخدام الرموز لكل استدعاء للنموذج، وليس فقط لكل طلب مستخدم. هذا يكشف عن النمو الخفي في جانب الإدخال.
- راقب عدد رموز الإدخال المضافة في كل دورة؛ فالقفزة المفاجئة تشير إلى مصدر الانزياح.
- افصل بين الرموز المخزنة مؤقتاً (المعاد استخدامها من استدعاءات سابقة) والرموز المنشأة حديثاً؛ فالأولى فقط هي التي تسبب الانزياح.
تعامل مع المطالبة (prompt) كمورد محدود، وليس كنص غير محدود. من خلال القياس والتلخيص والتقليص المتعمد، ستحافظ على وكيل الـ LLM الخاص بك سريعاً، وبتكلفة معقولة، وجاهزاً للتوسع في بيئة الإنتاج.
الخلاصة: يؤدي انزياح الرموز بصمت إلى رفع التكاليف وإبطاء الوكلاء. حدد الأجزاء المتنامية في مطالبتك، وقم بضغطها أو جعلها خارجية، وراقب استخدام الرموز لكل استدعاء. إن النهج المنضبط يحول صدمات الفواتير غير المتوقعة إلى عملية يمكن إدارتها وتناسب الميزانية.