مطوّرو مدير ذكاء اصطناعي للأسواق الإلكترونية يحذفون الوكيل ويقلّصون الكود بمقدار 461 سطرًا

بعد أربعة أيام من الإطلاق، حذف الفريق الذي يطوّر مدير ذكاء اصطناعي لبائعي الأسواق الإلكترونية وكيله بالكامل. بدا الوكيل ناجحًا في الاختبارات الداخلية، لكن المحادثات الحية أظهرت صورة مختلفة: كانت الإجابات تُقدَّم بثقة، لكنها تستند إلى جزء ضئيل من البيانات. ولم يكتفِ المطوّرون بالإصلاح، بل تخلّصوا من نواتهم الخاصة ونقلوا دورة عمل الوكيل إلى Pydantic AI. وجاء الـ commit معبّرًا: حُذف 582 سطرًا وأُضيف 121.

الاختبارات قالت شيئًا والمحادثات قالت شيئًا آخر

لتقييم الأداء، أعدّ الفريق معيارًا مرجعيًا: ثماني مهام نموذجية لكل دور وظيفي، ونموذج قاضٍ يمنح الإجابة درجة من 1 إلى 5 ويطّلع على البيانات التي اعتمد عليها الوكيل. وبحسب هذا المعيار، تفوّق الوكيل على التحليل القديم للعبارات في سبعة أدوار من تسعة، وحصل مدير الأسواق الإلكترونية على 4,28.

ثم قرأ المؤلفون الحوارات نفسها. يسأل المالك عن سبب تراجع المبيعات، فينظر الوكيل في عشرة منتجات من أصل مئة: الأداة تُرجع «حتى 15 نتيجة»، والجدول المعروض للنموذج يُقتطع أيضًا. يبدو الاستنتاج سلسًا، لكنه مبني على عُشر المتجر. ولا يلتقط القاضي هذا الخطأ لأن البيانات التي رآها الوكيل تتفق مع استنتاجه. وهذه نقطة عمياء معروفة في التقييم بواسطة LLM: القاضي يتحقق من اتساق الإجابة مع السياق، لا من اكتمال السياق نفسه.

وتبيّن أن المشكلات الأخرى تعود إلى السبب ذاته:

• كان الغلاف البرمجي الخاص بالتقييمات يُرجع أحدث التقييمات، لا كلها. وعندما يُطلب «حلّل كل شيء خلال نصف عام»، يصطدم الطلب بغياب الطريقة المناسبة، فيجيب الوكيل «لا أجيد ذلك بعد». وكانت قائمة هذه الطلبات في لوحة الإدارة تنمو أسرع مما يكتب الفريق أغلفة جديدة.
• تضمّنت أوصاف الأدوات توجيهات مثل «استدعاء أو استدعاءان بكلمات عامة» و«حتى 15». والتزم النموذج بها حتى حين كانت المهمة تتطلب عشرين استدعاءً.
• لم يكن حدّ الدورة الواحدة، وهو ثماني خطوات، كافيًا لمهام من نوع «افهم لماذا تتراجع الفئة». رُفع الحد إلى 50 خطوة و15 دقيقة، لكن الأثر كان محدودًا: لم يكن الوكيل يصطدم بعدد الخطوات، بل بأن كل خطوة تمنحه قطعة صغيرة فقط من البيانات.

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

لماذا حُذفت النواة بدل إصلاحها

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

لذلك استُبدلت الحلقة بـ Pydantic AI. تُحمَّل الأدوات النادرة عبر DeferredLoadingToolset عند البحث فقط، ولا تبقى في سياق كل خطوة. ومن المجموعة الجاهزة اعتُمد بحث DuckDuckGo بثماني نتائج وتحميل الصفحة عبر الرابط. وعُطّل حدّ الطلبات: usage_limits.request_limit يساوي None. وبقيت الأدوات الخاصة كما هي وتُستدعى عبر الدوال نفسها، ولذلك لم تتغير الجداول المعروضة للمالك ولا سجل الإجراءات ولا قواعد الكتابة.

أداة واحدة بدل عشرات الأغلفة

التغيير الرئيسي هو في المبدأ. في السابق كان الوكيل يتلقى أدوات مع شرح لطريقة استخدامها. أما الآن فيحصل على صلاحية الوصول وأداة ودليل مرجعي، ويختار طريقة الاستخدام بنفسه.

أصبحت واجهة Wildberries API كلها أداة واحدة تتيح 307 طرق، إضافة إلى أداة منفصلة تضم الدليل الرسمي. والبطاقات والأسعار والمخزون والطلبات والإمدادات والإعلانات والتقييمات والمحادثات والمالية متاحة للوكيل بالنطاق نفسه المتاح في الواجهة ذاتها. وإذا لم تكن الطريقة موجودة في الدليل، تُرجع الأداة تلميحًا بالتحقق عبر استدعاء الدليل. وتُنفَّذ طرق القراءة فورًا وكاملةً، دون اقتطاع. وبالطريقة نفسها رُبطت واجهة خدمة التحليلات MPStats. وأُزيلت مكتبة المعرفة من الـ prompt: فالدليل موجود إلى جانب الواجهة، وما عداه يبحث عنه الوكيل بنفسه في الإنترنت.

وبقيت قاعدة واحدة بعد إعادة الكتابة: أي تعديل في لوحة البائع لا يتم إلا بعد موافقة المالك بكلمة «نعم». الذي تغيّر هو الآلية. فالتعديلات خلال الدورة الواحدة تتجمع في دفعة واحدة، مثل «تغيير السعر لثلاثة منتجات، ورفع المزايدة في حملتين، والرد على أربعة تقييمات». يرى المالك القائمة بصيغة «كان → سيصبح» ويرد مرة واحدة. وتُنفَّذ الدفعة بالترتيب وتتوقف عند أول خطأ.

ومن التحسينات الصغيرة: القراءة المتوازية (بينما يطّلع الوكيل على الطلبات يفحص المخزون والإعلانات)، والتعديلات واحدًا تلو الآخر بصرامة، والبث المتدفق للنص مع رسائل حالة مثل «أقرأ تقييمات شهر مارس»، وحفظ استدعاءات API الناجحة في المشروع، ومتابعة الدورة من النقطة نفسها بعد تعطّل النموذج أو البحث.

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