تحليل على Habr: وكلاء AI يستنزفون التوكنات قبل أول سطر من الكود.. وخمسة أنماط للحد من ذلك

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

أين تُستنزف التوكنات

تجاوز الوكلاء منذ زمن توليد دوال منفردة. يعدّد المؤلف ما يفعلونه في المشاريع الحقيقية: يستكشفون المستودع، ويبحثون عن الملفات المطلوبة، ويحللون البنية المعمارية، ويشغّلون الاختبارات ويتحققون من النتيجة. والمهام عادية: إضافة صفحة في frontend، أو إنشاء endpoint، أو تعديل مخطط قاعدة البيانات، أو التعامل مع طابور رسائل، أو إصلاح data pipeline، أو تحديث CI/CD، أو ربط خدمة جديدة.

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

ما جاء في الإعلان

• الموضوع: توفير توكنات وكلاء AI عند العمل على قاعدة الشيفرة.
• الصيغة: خمسة أنماط عامة غير مرتبطة بحزمة تقنية محددة.
• النطاق: frontend، وbackend، ومخططات قواعد البيانات، والطوابير، وdata pipeline، وCI/CD، والخدمات الجديدة.
• الفرضية الرئيسية: يرتفع استهلاك التوكنات أسرع من حجم الكود المكتوب.
• الملاحظة الأساسية: يُنفق جزء كبير من التوكنات قبل كتابة أول سطر.

لا توجد أرقام محددة للتوفير في المقطع المتاح. ولا يمكن تقييم فاعلية الأنماط استناداً إلى الإعلان.

أي الأساليب تنجح عادةً

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

• البحث أولاً ثم القراءة. تحديد الرموز والمسارات المطلوبة ببحث دقيق، وفتح نطاقات أسطر محددة بدلاً من الملفات كاملة.
• خريطة مختصرة للمستودع. وصف موجز للبنية والوحدات الرئيسية، كي لا يضطر الوكيل إلى إعادة اكتشافها في كل جلسة.
• ملف بقواعد المشروع. أوامر البناء والاختبار، والاصطلاحات، والمناطق المحظورة، تُدوَّن مرة واحدة.
• تصفية المخرجات. يحتاج الوكيل إلى الاختبارات الفاشلة وتتبّع الخطأ (stack trace)، لا إلى السجل الكامل للتشغيل.
• عزل الاستكشاف. يُنقل البحث الثقيل إلى جلسة منفصلة أو إلى وكيل فرعي، ويعود إلى السياق الرئيسي ملخص موجز فقط.
• تخزين البادئة الثابتة للـ prompt مؤقتاً (caching)، إذا كان المزوّد يدعم ذلك.

ماذا على الفرق أن تفعل

ابدؤوا بالقياس. فمن دون توزيع التوكنات على المراحل (الاستكشاف، والتعديلات، والتحقق) تصبح أي محاولة للتحسين عمياء. سجّلوا الاستهلاك لكل مهمة وقارنوه بحجم الفرق (diff): فإذا كان الاستكشاف أغلى باستمرار من كتابة الكود، فالمشكلة في التنقل داخل المشروع، لا في النموذج.

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

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