🤖 AI

Anchor: Mitigating Artifact Drift in Agent Benchmark Generation

تقدم هذه الورقة "Anchor"، وهو مسار لتوليد المهام يعمل على الحد من انحراف النواتج (artifact drift) عبر صياغة تدفقات العمل التجارية في برامج تحسين القيود لإنتاج بيئات تقييم قابلة للتدقيق والتحقق والتوسع، وهو ما تم إثباته من خلال إصدار "ERP-Bench"، وهو معيار يتكون من 300 مهمة طويلة المدى في نظام تخطيط موارد المؤسسات (ERP) بمستوى إنتاجي.

المؤلفون الأصليون: Maksim Ivanov, Abhijay Rana

نُشر 2026-05-27

📖 4 دقيقة قراءة☕ قراءة في استراحة قهوة

CC BY 4.0

المؤلفون الأصليون: Maksim Ivanov, Abhijay Rana

البحث الأصلي مرخَّص بموجب CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل

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

المشكلة، وفقاً لهذه الورقة البحثية، هي أن معظم هذه الاختبارات معطلة. فهي تعاني مما يسميه المؤلفون "انزياح الأثر" (Artifact Drift).

المشكلة: "الوصفة المعطلة"

فكر في إنشاء اختبار لوكيل ذكاء اصطناعي كأنك تكتب وصفة لصنع كعكة. لجعل الاختبار عادلاً، يجب أن تتطابق أربعة أشياء تماماً:

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

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

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

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

الحل: "Anchor" (المرساة)

بنى المؤلفون نظاماً جديداً يسمى Anchor لإصلاح ذلك.

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

عندما تريد إنشاء اختبار:

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

ولأن كل شيء يأتي من ذلك المخطط الواحد، فلا يمكنها أبداً أن تختلف. التعليمات، والبيئة، والإجابة، والقاضي، جميعهم متوافقون تماماً.

النتيجة: ERP-Bench

باستخدام هذا النظام، أنشأ المؤلفون مجموعة اختبارات جديدة تسمى ERP-Bench.

ما هي؟ هي مجموعة من 300 مهمة تجارية واقعية تتضمن شراء القطع، وتصنيع المنتجات، وإدارة المخزون، وكل ذلك داخل نظام برمجيات تجاري حقيقي يسمى Odoo.
لماذا هي مميزة؟ إنها "قابلة للتحقق". فالنظام يعرف الإجابة المثالية الرياضية لكل مهمة. يمكنه إخبارك بالضبط بمدى اقتراب الذكاء الاصطناعي من الحل المثالي، وليس فقط ما إذا كان "يبدو" صحيحاً.

ما وجدوه

اختبروا خمسة من أذكى نماذج الذكاء الاصطناعي المتاحة اليوم على هذه المهام الـ 300. إليكم ما حدث:

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

الخلاصة

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

ملخص تقني: Anchor – الحد من انحراف المكونات في إنشاء معايسات قياس الوكلاء

بيان المشكلة

تعاني معايسات القياس الحالية لوكلاء الذكاء الاصطناعي في المؤسسات من خلل جوهري في البناء يُسمى انحراف المكونات (artifact drift). في عملية إنشاء معايسات القياس التقليدية، غالبًا ما يتم إنشاء المكونات الأربعة الحرجة للمهمة — وهي التعليمات ( $I$ )، والبيئة ( $E$ )، والحل المثالي ( $x^*$ )، والمُحقِّق ( $V$ ) — عبر عمليات مفككة الارتباط. يؤدي هذا التفكك إلى عدم اتساق حيث تتعارض المكونات بشأن متطلبات المهمة. على سبيل المثال، قد تفتقر البيئة إلى بيانات يفترضها النص الإرشادي، أو قد يعتمد الحل المثالي على حالة تم إغفالها في البيئة، أو قد يقبل المُحقِّق نتائج لم تكن مطلوبة في التعليمات. تؤدي هذه التناقضات إلى بيئات غير قابلة للحل، أو عرضة لـ "اختراق المكافأة" (reward hacking)، أو ببساطة غير متسقة، مما يخلق فجوة بين درجات معيار القياس والأداء الفعلي في بيئة الإنتاج.

المنهجية: خط إنتاج Anchor

لمعالجة انحراف المكونات، قدم المؤلفون Anchor، وهو خط إنتاج لإنشاء المهام يقوم بتجميع جميع مكونات المهمة الأربعة من مواصفات واحدة محلولة. يعمل خط الإنتاج كما يلي:

الصياغة الرسمية (Formalization): يقوم خبير في المجال ومهندس بصياغة سير عمل تجاري (مثل تحديد أولويات الفواتير، أو جدولة الإنتاج) كبرنامج قيود بارامتري باستخدام OR-Tools CP-SAT. تتضمن هذه المواصفات متغيرات القرار، وقيود قواعد العمل، ومقياس الهدف.
الحل (Solving): بالنسبة لمجموعة معينة من المعلمات ( $\theta$ )، يقوم مُحلل CP-SAT إما برفض الحالة لعدم قابليتها للحل أو بتقديم حل مثالي معتمد ( $x^*_\theta$ ). تشكل هذه النتيجة، جنباً إلى جنب مع المعلمات والقيود، مواصفات محلولة ( $S_\theta$ ).
التجميع الحتمي (Deterministic Compilation): تقوم أربع طبقات ترجمة بإسقاط $S_\theta$ $S_{θ}$ حتمياً إلى مكونات المهمة:
- مولد التعليمات: يحول المعلمات والقيود والأهداف إلى لغة طبيعية.
- مولد الإعداد: يكتب السجلات الأولية التي تم أخذ عينات منها في حاوية البيئة.
- مولد الحل المثالي: يكتب الحل المعتمد من المُحلل كحالة نهائية مرجعية.
- مولد المُحقِّق: يقيم الحالات النهائية مقابل قيود البرنامج والهدف.

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

المساهمات الرئيسية

1. خط إنتاج Anchor

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

2. ERP-Bench

معيار قياس يتكون من 300 مهمة طويلة المدى تغطي سير عمل المشتريات والتصنيع داخل نظام Odoo 19، وهو نظام تخطيط موارد المؤسسات (ERP) مفتوح المصدر ومن الدرجة الإنتاجية.

النطاق: يغطي 29 نمطاً لسير العمل، بما في ذلك التزويد الروتيني، والتعافي من الاضطرابات، وسيناريوهات الإنتاج والتنفيذ.
التعقيد: تتضمن المهام بيانات مهيكلة (أوامر المبيعات، أوامر الشراء، أوامر التصنيع، قوائم المواد BOMs) وتتطلب من الوكلاء التنقل عبر قواعد عمل معقدة (مهل التسليم، الحد الأدنى لكميات الطلب MOQ، قيود القدرة الاستيعابية).
التحقق: يستخدم المُحقِّق نظام تسجيل مرجح (25% لرضا القيود، 60% للأمثلية، 15% للتتبع) مع بوابات فشل صارمة (hard-zero gates) للإخفاقات الحرجة.

3. التقييم الشامل

قيم المؤلفون خمسة نماذج رائدة (GPT-5.5، Claude Opus 4.7، GLM-5.1، GLM-5V-Turbo، Kimi K2.5) عبر ثلاث منصات تشغيل (البرمجة، المتصفح، استخدام الكمبيوتر) عبر 18,000 تجربة.

المنصات: بُنيت على مجموعة أدوات pi-mono مفتوحة المصدر لتعكس الهياكل الواقعية بدلاً من الأغلفة المخصصة لمعايير القياس فقط.
المقاييس: تم تقييم Pass@1، وPass@5، ومتوسط الدرجات، وفجوة القابلية للحل-الأمثلية.

النتائج

1. ارتباط الصعوبة

نجح التدخل البارامتري للصعوبة في التنبؤ بالأداء الفعلي. عبر جميع النماذج والمنصات، تنخفض درجات Pass@5 بشكل رتيب من المستويات السهلة إلى الصعبة:

البرمجة: 70.5% $\to$ 22.3%
المتصفح: 46.5% $\to$ 7.7%
استخدام الكمبيوتر: 56.0% $\to$ 9.5%

تظهر المعلمات مثل عدد مراكز العمل، وأوامر التصنيع، والموردين المختلفين ارتباطات سلبية قوية مع Pass@1.

2. فجوة القابلية للحل-الأمثلية

توجد فجوة كبيرة بين استيفاء القيود وتحقيق الأمثلية. عبر جميع النماذج، يستوفي الوكلاء قيود المهمة الصريحة في 26.1% من التجارب ولكنهم يصلون إلى حل أمثل بالكامل في 17.4% فقط. يظهر أقوى نموذج (GPT-5.5 في البرمجة) فجوة قدرها 23.4 نقطة. ويُعزى تدهور الدرجات بشكل أساسي إلى كسر القيود الصريحة (القابلية للحل) بدلاً من المقايضات دون المثالية بين الخطط القابلة للتنفيذ.

3. أداء المنصات

تؤدي النماذج أداءً أفضل بكثير في منصة البرمجة (المدفوعة بالواجهة البرمجية API) مقارنة بمنصات المتصفح أو استخدام الكمبيوتر.

تحل منصات واجهة المستخدم الرسومية (GUI) مهاماً أقل بنسبة تتراوح بين 16 إلى 56 نقطة مئوية مقارنة بمنصة البرمجة.
تُكلف منصات واجهة المستخدم الرسومية ما بين 3.1 إلى 14.3 ضعف تكلفة المهمة الواحدة بسبب زيادة عدد الدورات (بسبب قيود تجميع الإجراءات في واجهة المستخدم مقابل API).
لم تُلاحظ أي حالات لاختراق المكافأة أثناء التقييم.

4. الموثوقية

الوكلاء الحاليون ليسوا موثوقين بما يكفي بعد للنشر غير المراقب. بينما يمكن قياس Pass@5 (نجاح واحد على الأقل في خمس تجارب)، فإن Pass5 (نجاح جميع التجارب الخمس) أقل بنحو عشرة أضعاف (على سبيل المثال، 9.8% في البرمجة)، مما يشير إلى تباين عالٍ في أداء الوكلاء.

الأهمية والادعاءات

يزعم البحث أن Anchor و ERP-Bench يوفران وصفة ملموسة لبناء بيئات تقييم قابلة للتدقيق للعمل الذي يقوم به الوكلاء ذو القيمة الاقتصادية. من خلال صياغة سير العمل التجاري في برامج تحسين القيود، يوضح المؤلفون أنه من الممكن إنشاء معايسات قياس واقعية، وقابلة للتحقق، وقابلة للتوسع، مما يقلل من انحراف المكونات الذي يعيب التقييمات الحالية.

يضع المؤلفون هذا العمل كخطوة نحو سد الفجوة بين درجات معايسات القياس والأداء في بيئة الإنتاج. ويشيرون إلى أنه بينما تعطي هذه الإطار الأولوية للمهام القابلة للتنفيذ، والقابلة لإعادة الإنتاج، والقابلة للتقييم بدقة، إلا أنه مناسب طبيعياً للعمل المؤسسي المرئي في حالات النظام النهائية (مثل عمليات ERP)، ولكنه أقل ملاءمة لسير العمل الذي يعتمد على التقدير الضمني أو التفاوض. إن نشر مولد المهام ومجموعة البيانات عبر erpbench.ai يهدف إلى دعم المزيد من الأبحاث في تدريب وتقييم الوكلاء القابل للتحقق.