خطوة واحدة للوكيل — 120,000 رمز: أين تذهب وكيف أصلحناها
يمكن للوكيل المستقل أن يستهلك رموزًا أكثر بكثير مما هو متوقع بسبب الإرسال المتكرر للسياق الكامل في كل خطوة من خطوات حلقة الوكيل. تصف المقالة كيف اكتشفت Uma Computer أن السبب الحقيقي ليس تاريخ الحوار، بل الحمل الزائد المضاعف لتعليمات النظام ومخططات الأدوات والذاكرة، وتقدم ثلاثة تحسينات: نقل الحجم إلى أدوات عند الطلب، والتحول إلى ميزانية أحرف مع علامات اقتطاع صريحة، وتوقعات سرعة شفافة.
طور مطورو Uma Computer، وهو وكيل مستقل يقوم بمهام مثل البحث على الويب وتوليد الوسائط وقص الفيديو، التحقيق في سبب تكلفة طلب مستخدم واحد 38 رصيدًا بدلاً من الثلث المتوقع. أظهرت الفواتير 119,208 رمزًا مميزًا للإدخال و1,018 رمزًا فقط للإخراج، مما يعني أن النموذج كان يقرأ في الغالب وليس يكتب. كانت الفرضية الأولية هي وجود تاريخ محادثة طويل، لكن المحادثة الإشكالية الفعلية كانت تحتوي على رسالتين فقط بإجمالي 530 حرفًا. كشف القياس أن السياق لكل خطوة كان 13,900 رمزًا، ومع 9 خطوات وصل الإجمالي إلى حوالي 120,000 رمزًا؛ تضاعف الحمل الزائد بعدد الخطوات في حلقة الوكيل. بالإضافة إلى ذلك، يحجز المزود التكلفة في أسوأ الحالات مع تعيين max_tokens على قيمة عالية، مما يسبب أخطاء HTTP 402 حتى مع وجود رصيد كافٍ. تضمن الإصلاح نقل السياق المحمل مسبقًا إلى أدوات عند الطلب، واستخدام ميزانية أحرف مع أولويات وعلامات اقتطاع صريحة، وجعل توقعات السرعة شفافة. تؤكد المقالة على أنه لا ينبغي أبدًا إخفاء السياق بصمت عن النموذج، ويجب التحقق من التحسينات على حالات ملموسة، حيث كادوا يحسنون لحالة كان فيها التاريخ غير ذي صلة.
المصدر: Habr — хаб ML —
الأصلي
