diff --git a/book-ar/chapter7.ar.md b/book-ar/chapter7.ar.md index 35660004c..8c14b03e3 100644 --- a/book-ar/chapter7.ar.md +++ b/book-ar/chapter7.ar.md @@ -17,58 +17,116 @@ من منظور هندسة منظومة التشغيل في الفصل الأول، يؤدي التقييم وظيفة **التحقق** الأساسية داخل المنظومة. والفكرة المحورية هي أن **موضوع التقييم ليس النموذج وحده، بل النموذج ومنظومة تشغيله معًا**. فقد يختلف أداء النموذج نفسه جذريًا بين منظومتين، ورفعت بعض الفرق أداء النموذج ذاته في المهام الطرفية بمجرد تحسين منظومة تشغيله (انظر الفصل الخامس). لذلك قد لا يكون علاج ضعف الوكيل تبديل النموذج، بل تحسين أحد المكونات: الموجّه، أو تصميم الأداة، أو حلقة التغذية الراجعة. ويجب أن يميز نظام التقييم السليم بين مشكلتين مختلفتين: قصور قدرة النموذج، وسوء استثمارها بسبب التصميم. ومن الطرق الشائعة لذلك **تجربة تبديل النموذج**: ثبّت منظومة التشغيل وبدّل النموذج بآخر أقوى أو أضعف، ثم راقب مقدار تغير النتيجة. فإذا لم يرفع النموذج الأقوى الأداء، فالاختناق في المنظومة. وإذا خفّض النموذج الأضعف النتيجة وتذبذبت بحدة مع قوته، فالنموذج نفسه هو الاختناق الأرجح. وقد يعود ذلك إلى صعوبة المهمة أصلًا، أو إلى اعتماد المنظومة المفرط على معرفة النموذج السابقة، وهو ما يحتاج إلى تحليل إضافي. وتختلف هذه التجربة عن الاستئصال: فالاستئصال **يعطّل مكونًا من منظومة التشغيل** لقياس أثره في الأداء الكلي، أما تبديل النموذج **فيثبّت المنظومة ولا يغير إلا النموذج**. تكشف الأولى أي مكونات المنظومة أهم، وتكشف الثانية هل الاختناق في النموذج أم في منظومة تشغيله. يستحق نظام التقييم قيمة أكبر في عصر التطور السريع للنماذج. تستمر النماذج في التحسن، لكن النموذج الجديد الذي يحقق درجات أعلى في المعايير العامة لن يؤدي بالضرورة إلى أداء أفضل في مهمتك - بل قد يتراجع (يؤدي أداء أسوأ من الإصدار القديم في بعض النواحي). يتيح لك التشغيل الكامل لمجموعة بيانات التقييم الخاصة بك فقط اتخاذ قرار ترقية يعتمد على البيانات. بل إن نظام التقييم القوي يجعل من "بناء المنتجات للنماذج المستقبلية" استراتيجية قابلة للتطبيق: إذا لم يكن النموذج الحالي جيدًا بما يكفي للنشر التجاري، فقم بإنهاء المنتج على أي حال، وقم ببناء مجموعة التقييم، وتتبع أداء كل نموذج جديد، وقم بتشغيله في اللحظة التي يتخطى فيها النموذج الشريط. +يمكن تفكيك منظومة التقييم إلى أربع حلقات: ما الذي يُعد نجاحًا، ومن أين تأتي المهام، ومن الذي يتحقق، وكيف تتحول الدرجة إلى قرار. يوضح ذلك الشكل 7-1. + +![الشكل 7-1: الحلقات الأربع لمنظومة تقييم الوكيل](images/fig7-1.svg) + +## تشريح مهمة تقييم واحدة: نطاق telecom في τ²-bench + +لنبدأ بتشريح مهمة حقيقية واحدة من نطاق telecom في τ²-bench تشريحًا كاملًا. الشيفرة المصدرية في المستودع تحت `chapter7/tau2-bench`، وملف المهام هو `data/tau2/domains/telecom/tasks_small.json`. + +### المكوّنات الأربعة لتعريف المهمة + +فيما يلي إحدى المهام من ذلك الملف، مختصرةً تسهيلًا للقراءة. + +```jsonc +{ + "id": "[mobile_data_issue]airplane_mode_on|user_abroad_roaming_enabled_off", + + // التذكرة المسلَّمة إلى الوكيل + "ticket": "هاتف المستخدم لا يتصل بالإنترنت، وشريط الحالة يعرض 'No Service'. + العميل John Smith، الرقم 555-123-2002، وهو حاليًا في فرنسا. لا + تُعد المشكلة محلولة إلا إذا أعاد اختبار السرعة النتيجة excellent. + لا يريد تغيير الباقة، لكنه مستعد لشحن 2.0 غيغابايت عند اللزوم.", + + // ضوابط السلوك المسلَّمة إلى محاكي المستخدم + "user_scenario": { "instructions": { + "known_info": "You are John Smith with phone number 555-123-2002. + You are currently abroad in France.", + "unknown_info": null, + "task_instructions": + "…express mild frustration after the first unsuccessful attempt. + You will consider the issue resolved only when speed test returns + excellent internet speed and nothing else. If it returns poor, fair + or good, you will not consider the issue resolved. + Whenever the agent asks you about your device, always ground your + responses on the results of tool calls. … + Never make up the results of tool calls." + }}, + + // قبل التشغيل تُعاد حالة الطرفين إلى نقطة البداية نفسها + "initial_state": { "initialization_actions": [ + { "env_type": "user", "func_name": "turn_airplane_mode_on" }, + { "env_type": "user", "func_name": "turn_roaming_off" }, + { "env_type": "assistant", "func_name": "enable_roaming", + "arguments": { "customer_id": "C1001", "line_id": "L1002" } } + ]}, + + // معايير التقييم + "evaluation_criteria": { + "actions": [ + { "requestor": "user", "name": "toggle_airplane_mode" }, + { "requestor": "user", "name": "toggle_roaming" } + ], + "env_assertions": [ + { "func_name": "assert_mobile_data_status", "expected_status": true }, + { "func_name": "assert_internet_speed", + "expected_speed": 200, "expected_desc": "excellent" } + ], + "communicate_info": null, + "nl_assertions": null, + "reward_basis": ["ENV_ASSERTION"] + } +} +``` -> **دليل الفصل** -> -> يبني هذا الفصل نظام تقييم كامل على ثلاثة مستويات. المستوى الأول هو **بيئة التقييم** ("مكان الاختبار"): كيفية إعداد بيئة اختبار تلقائية وقابلة للتكرار، وتغطي نموذجين: استدعاء الأدوات والتفاعل بين الإنسان والحاسوب. المستوى الثاني هو **طرق التقييم** ("كيفية الحكم"): بدءًا من مبادئ تصميم مجموعة البيانات ونظام مقاييس التقييم (ما يجب قياسه)، وحتى LLM-as-a-Judge (باستخدام نماذج لغوية كبيرة كمحكمين) للتقييم الآلي، ثم المقارنة الزوجية وتصنيف النماذج. المستوى الثالث هو **اتخاذ القرار القائم على التقييم** ("ما يجب فعله بعد الاختبار"): تحويل نتائج التقييم إلى إرشادات قابلة للتنفيذ لاختيار النموذج، وتحسين البنية، والتكرار المستمر، مع أهمية إحصائية للحكم على ما إذا كان فرق النتيجة الملحوظ حقيقيًا أم لا. يغطي الفصل أيضًا إمكانية الملاحظة والبنية التحتية للتقييم الداخلي لوكلاء درجة الإنتاج، ويختتم ببيئات المحاكاة المرتبطة بمرحلة ما بعد التدريب في الفصل 8. -> -> الفكرة التي تدور في الفصل بأكمله: **القيمة الأساسية لنظام التقييم ليست تسجيل النظام الحالي، ولكن السماح لك بمواكبة تطور النموذج بسرعة وبشكل موثوق.** عندما يتم طرح نموذج أقوى أو أرخص، يمكن لفريق لديه نظام تقييم قوي أن يقرر في غضون ساعات ما إذا كان سيتم التبديل أم لا؛ يمكن للفريق الذي لا يضم أحدًا أن يثق إلا في الحدس أو ينتظر تعليقات المجتمع - وفي سوق الوكلاء شديد التنافسية، يمكن لهذا الاختلاف في السرعة أن يقرر من سيفوز. +في هذا التعريف أربعة قرارات تصميمية تستحق الشرح. -![الشكل 7-1: المستويات الثلاثة لنظام التقييم](images/fig7-1.svg) +**حدود معرفة المستخدم مُنمذَجة صراحةً.** يحتوي `known_info` على ثلاث معلومات فقط: الاسم ورقم الهاتف وبلد الإقامة. أما السببان الحقيقيان للعطل — تشغيل وضع الطيران وإيقاف تجوال البيانات — فليسا هناك. المستخدم لا يعلمهما فلا يستطيع ذكرهما من تلقاء نفسه، والوكيل لا سبيل له إلى معرفتهما إلا بالسؤال وبتوجيه المستخدم إلى الفحص. هكذا يتحقق **الكشف التدريجي للمعلومات (Progressive Information Disclosure)** على مستوى تعريف المهمة: لا بتقييد المحاكي بموجّه يقول «لا تكشف كل شيء دفعة واحدة»، بل بنمذجة نطاق معرفة المستخدم بوصفه حقلًا مستقلًا. معظم المعايير المرجعية تعرض المتطلب كاملًا في بداية المهمة، بينما أول ما ينطق به مستخدم حقيقي عادةً لا يتعدى «لا أستطيع الدخول إلى الإنترنت». وتوضيح الطلب إلى الحد الذي يصبح فيه قابلًا للتنفيذ هو نفسه جزء مما ينبغي أن يجيده الوكيل. -## مثال تقييم ملموس +**المحاكي يتلقى ضوابط سلوك لا نصًا حواريًا.** يجمع `task_instructions` ثلاثة أنواع من القيود: ضبط انفعالي (إظهار امتعاض خفيف بعد أول محاولة إصلاح فاشلة)، ومعيار قبول (لا تُعد المشكلة محلولة إلا إذا أعاد اختبار السرعة excellent؛ أما poor وfair وgood فمرفوضة جميعًا)، وشرط **الترسيخ الواقعي (Grounding)**، أي أن يستند كل جواب عن حالة الجهاز إلى القيمة التي تُعيدها أداة: «Never make up the results of tool calls». والثالث هو الأهم: من دون قيد الترسيخ ينساق المستخدم المحاكى وراء توجيه الوكيل فيؤكد أن المشكلة حُلّت، فينحدر التقييم إلى مصادقة نموذجين أحدهما على الآخر. -قبل الغوص في المنهجية، دعونا نبني الحدس من خلال مثال كامل. لنفترض أننا أنشأنا وكيل خدمة عملاء ونحتاج إلى تقييم قدرته على التعامل مع طلبات استرداد الأموال. +**الحالة الابتدائية مقسومة بحسب الطرف المتحكم.** يأخذ `env_type` قيمتين، `user` و`assistant`: وضع الطيران ومفتاح التجوال يخصّان جانب المستخدم، بينما `enable_roaming` في جانب المشغّل يخص جانب الوكيل. هذا التقسيم هو ما يحدد شكل العطل: التجوال مفعَّل لدى المشغّل لكنه مغلق على جهاز المستخدم، فلا يحصل الوكيل من استعلام قاعدة البيانات إلا على نتيجة «الإعدادات سليمة». العطل يقع في الجانب الذي لا تراه قاعدة البيانات، ولا ينكشف إلا بتوجيه المستخدم إلى الفحص. -**حالة اختبارية**: يريد المستخدم إرجاع طلب منذ 3 أيام (الطلب رقم 12345، المبلغ 299 ين ياباني). سياسة الشركة: استرداد كامل المبلغ خلال 7 أيام. +**معايير التقييم موزَّعة على أربع طبقات، وهذه المهمة لا تستخدم منها إلا طبقة واحدة.** يتحقق `env_assertions` من الحالة النهائية (بيانات الجوّال متاحة، والسرعة 200 ميغابت/ثانية فأكثر بتصنيف excellent)، ويتحقق `actions` من وقوع الأفعال المفتاحية ومن **أي الطرفين** نفّذها، بينما يتحقق `communicate_info` و`nl_assertions` من إبلاغ المستخدم بالمعلومات اللازمة. أما `reward_basis` في هذه المهمة فلا يعلن إلا `ENV_ASSERTION`؛ وتُحسب الطبقات الأخرى وتُسجَّل كالمعتاد لكنها لا تدخل في المكافأة النهائية. أساس التقييم يُعلن لكل مهمة على حدة، لا يُثبَّت عالميًا. -**مسار الوكيل**: +### مسار (trajectory) تشغيل حقيقي واحد -```text -User: I want to return the headphones I bought 3 days ago, order number 12345. (Today is 2026-04-10) +ندعو القارئ الآن إلى تشغيل مهام التقييم في نطاق telecom من τ²-bench بنفسه، ومراقبة تصميم المهام، ومحاكي المستخدم، ومنطق التحقق من العملية والنتيجة، ثم تتبّع مسار تنفيذ الوكيل لتحليل سبب إخفاقه. + +> **التجربة 7-1 ★: تشغيل τ²-bench ومقارنة تطوره عن τ-bench** +> +> تشغّل هذه التجربة إطار التقييم τ²-bench لفهم النقاط التصميمية المحورية في بيئة التقييم من نوع التفاعل بين الإنسان والحاسوب. اقرأ أولًا ملف تعريف المهام على المسار نفسه المتبع في هذا القسم: تتألف كل مهمة من أربعة أجزاء — المعلومات المعروفة، وتعليمات المهمة، والحالة الابتدائية، وشروط النجاح. ثم شغّل مسار التقييم كاملًا، وراقب الحوار متعدد الأدوار بين محاكي المستخدم والوكيل، وحلّل أنماط الإخفاق النمطية (مخالفة السياسة، إغفال معلومات، الإحالة المفرطة إلى موظف بشري، وغيرها). +> +> ![الشكل 7-3: بيئة التحكم المزدوج والتحقق متعدد الطبقات في τ²-bench](images/fig7-3.svg) -Agent (thinking): The user wants a refund, I need to check the order information first. -Agent → Calls tool query_order(order_id="12345") -Tool returns: {status: "delivered", amount: 299, date: "2026-04-07", item: "Bluetooth Headphones"} +يحتفظ المستودع المرافق بسجل تشغيل واحد (`chapter7/tau2-bench-eval`). نحلل فيما يلي إحدى عمليات التشغيل الناجحة منه. -Agent (thinking): Order date 2026-04-07, today is 2026-04-10, that's 3 days, within the 7-day refund period, eligible for full refund. -Agent → Calls tool process_refund(order_id="12345", amount=299) -Tool returns: {refund_id: "R-98765", status: "processing", eta: "3-5 business days"} +الأدوار العشرة الأولى وما يليها هي مرحلة تحديد الحساب. يستدل الوكيل من الرقم على العميل C1001، ثم يستعلم تباعًا عن استهلاك البيانات في الخطوط L1001 وL1002 وL1003، ويعود ليسأل عن الرقم الذي يستعمله المستخدم فعليًا في فرنسا. وفي الرسالة السابعة عشرة يخلص إلى نتيجة خاطئة: -Agent: A refund has been initiated for you. The full refund for Order #12345 (Bluetooth Headphones, ¥299) is being processed, - and is expected to arrive in 3-5 business days. The refund ID is R-98765, which can be used to check the progress. -``` +> **الوكيل** (17): الرقم 555-123-2002 غير موجود ضمن خطوطك النشطة، وأقربها 555-123-2001… + +هذه النتيجة تستند إلى استعلام خط واحد فقط هو L1001. وبعد أن يصرّ المستخدم على صحة الرقم، يستعلم الوكيل عن L1002 فيتطابق أخيرًا. أما المنعطف الحاسم فيأتي في الرسالة الثلاثين: -**تسجيل النقاط باستخدام معايير التقييم** (أربعة أبعاد، سجل كل منها 1-4). يوفر الجدول 7-1 مثالًا لتسجيل النقاط لمهمة استرداد الأموال لخدمة العملاء، مما يوضح كيفية تقسيم نموذج التقييم لمسار الوكيل إلى أبعاد تقييم قابلة للتحقق. +> **المستخدم** (30) ← يستدعي `check_network_status()` و`check_status_bar()` +> +> **ما تعيده الأداة** (31): `Airplane Mode: ON | Cellular Connection: no_service | Mobile Data Enabled: Yes | Data Roaming Enabled: No` +> +> **المستخدم** (33): أرى أن الهاتف الآن في وضع الطيران، ولهذا لا توجد إشارة. بيانات الجوّال مفعَّلة لكن تجوال البيانات مغلق. هل أغلق وضع الطيران وأجرب؟ -جدول 7-1 مثال على نقاط التقييم لمهمة استرداد الأموال لخدمة العملاء +الطرف الذي أطلق استدعاء الأداة هو **المستخدم** لا الوكيل. هذه هي آلية **التحكم المزدوج (Dual-Control)**: المستخدم المحاكى يملك مجموعة أدوات خاصة به مثل `check_status_bar` و`toggle_airplane_mode` و`reseat_sim_card` و`run_speed_test`. -| البعد | المعايير | النتيجة | السبب | -|------------------------|--------------------------------|------|--------------------------------| -| صحة التشغيل | هل مبلغ الاسترداد ورقم الطلب صحيحان؟ | 4 | تم الاستعلام بشكل صحيح وبدء استرداد كامل المبلغ بقيمة ¥299 | -| الامتثال للسياسة | هل يتبع سياسة استرداد الأموال لمدة 7 أيام؟ | 4 | الطلب خلال فترة استرداد الأموال، ويتوافق مع السياسة | -| اكتمال المعلومات | هل يوفر المبلغ ووقت الوصول ومعرف استرداد الأموال؟ | 4 | تم توفير جميع المعلومات الأساسية الثلاثة | -| كشف الهلوسة (حظر الفيتو - Veto Item) | هل يختلق معلومات غير موجودة؟ | اجتياز (Pass) | جميع المعلومات تأتي صراحةً من مخرجات الأداة | +ويمضي التشخيص بعد ذلك بسلاسة: يطلب الوكيل من المستخدم إغلاق وضع الطيران وتفعيل التجوال، فينفّذ المستخدم الأمرين (35 و37)، ويتحول شريط الحالة إلى 5G بإشارة كاملة؛ ثم يطلب الوكيل اختبار سرعة، فتعود النتيجة 275 ميغابت/ثانية بتصنيف Excellent (46)، ويؤكد المستخدم أن المشكلة حُلّت. ويجتاز كلا `env_assertions`، فتكون `reward = 1.0`. -تُصنف الهلوسة على أنها **حظر فيتو (Veto Item)** بدلاً من كونها بُعدًا متدرجًا للدرجات لأنها متعامدة مع الجودة — فالاستجابة البليغة والمنظمة التي تحتوي معلومات كاذبة تُعد أشد ضررًا من الاستجابة المختصرة والدقيقة. +يحوي هذا المسار الحاصل على الدرجة الكاملة مشكلةً لم يلتقطها المدقق. فالفقرة الأولى من سياسة وكيل telecom تنص على «You should only make one tool call at a time»، بينما أطلق الوكيل في الرسالة الرابعة استدعاءَي `get_customer_by_phone` و`get_customer_by_name` معًا. لم يعدّ المدقق ذلك خطأً لأن `reward_basis` في هذه المهمة لا يأخذ إلا الحالة النهائية بعين الاعتبار. وليس هذا سهوًا من τ²-bench بل هو الثمن الملازم للمكافأة الثنائية: تقايض دقة العملية بعدد واحد قابل للمقارنة بين النماذج. غير أن منظومات التقييم في بيئة الإنتاج تحتاج عادةً إلى أكثر من ذلك: لا أن تحكم بالصواب أو الخطأ فحسب، بل أن تشير أيضًا إلى موضع المشكلة. -لقد نجحت حالة الاختبار هذه. لكن التقييم الجيد لا يختبر سيناريوهات النجاح فحسب؛ كما أنه يستكشف الحدود والفخاخ - عندما يريد المستخدم إرجاع طلب منذ 15 يومًا (بعد فترة استرداد الأموال)، هل يستطيع الوكيل الرفض بشكل صحيح؟ عندما يدعي مستخدم أن "ممثل خدمة العملاء قد وافق بالفعل على استرداد الأموال"، هل سيصدق الوكيل ذلك بدون سجل النظام؟ هذه السيناريوهات الحدودية هي التي تفصل حقًا الوكلاء الأقوياء عن الوكلاء الضعفاء. +والمهمة التي أخفقت جديرة بالتحليل كذلك. رقم المستخدم هو 555-123-2002، لكن الوكيل اختار الخط L1001 ومضى يستدل على أساس استهلاكه البالغ 3.2/5 غيغابايت. وفي الأثناء أعاد `get_details_by_id(L1001)` بوضوح أن رقم ذلك الخط هو 555-123-2001؛ قرأ الوكيل النتيجة لكنه لم يصحح حكمه، ثم أنفق عشرات الرسائل في فحوص لا صلة لها بالموضوع، وانتهى إلى الإحالة إلى موظف بشري. وقد أنجز في الواقع نصف المهمة — إذ وجّه المستخدم إلى إغلاق وضع توفير البيانات، وقد وقع هذا الفعل من جانب المستخدم فعلًا وتحققت منه البيئة. لكن خطأ اختيار الخط حال دون تنفيذ شحن الـ 2 غيغابايت المطلوب، فأخفقت التأكيدات الثلاثة على الحالة النهائية جميعًا. وشكل هذا الإخفاق شديد الشبه بحالة AndroidWorld التي يناقشها قسم «عزو الإخفاق» لاحقًا: الدليل اللازم لتصحيح الحكم كان قد دخل السياق بالفعل، لكن الوكيل لم يرجع إليه. -العملية المذكورة أعلاه - تحديد حالات الاختبار، وتشغيل الوكيل، والتسجيل باستخدام نموذج التقييم، وتحليل النتائج - هي الهيكل الأساسي للتقييم. ويوضح باقي هذا الفصل تصميم كل خطوة. +هذه المهمة الواحدة تطرح بالفعل كل الأسئلة التي على مجموعة التقييم أن تجيب عنها: ما الذي يُعد نجاحًا، ومن أين تأتي المهام، ومن الذي يتحقق، وكيف تتحول الدرجة إلى قرار. وتتناولها الأقسام التالية تباعًا. -## نظام مقاييس التقييم: معايير محدثة +## مقاييس التقييم: تعريف النجاح -قبل بناء البيئة أو مجموعة البيانات، يجب تحديد معنى «النجاح»: هل تكفي مسار قابل للتنفيذ مرة واحدة، أم يجب أن تنجح كل عملية؟ اختلاف التعريف يغيّر القرار الهندسي. ويبدأ هذا القسمُ بترسيخ هذا المعيار، ثم يُبيّن فيما بعدُ كيف تُنفَّذ البيئةُ ومجموعةُ البيانات والمصحِّح. +كانت نتيجة التقييم في القسم السابق اجتياز أربع مهام من خمس. ومن رقم 0.8 وحده لا يمكن الحكم على صلاحية المنظومة للاستعمال. فإن كان وكيل خدمة عملاء لمعالجة المبالغ المستردة، فمعناه أن واحدًا من كل خمسة مستخدمين لا يحصل على المبلغ المستحق له؛ وإن كان وكيل أمن يبحث عن الثغرات، فإصابة أربع من خمس نتيجة محترمة. والفرق يكمن في مقدار معدل النجاح الذي يشترطه سياق العمل. ### المعجزة التقنية: سقف القدرة مع Pass@k @@ -99,209 +157,151 @@ $$ يجب أن يوضّح تقرير التقييم المقصود بالمحاولات $k$ بدقة: أهي $k$ عينة مستقلة من المهمة نفسها، أم $k$ مهمة متتالية على خط إنتاج فعلي؟ وفي العمليات ذات الآثار الجانبية لا يصحّ ببساطة «إعادة المحاولة حتى النجاح»، بل ينبغي أخذ العينات في بيئة معزولة أو قابلة للتراجع، وتسجيل كل إخفاق ضمن مقياس الموثوقية. -### مقاييس العملية: من الصندوق الأسود إلى الصندوق الأبيض - -إن التركيز فقط على النتيجة النهائية ليس كافيا؛ العملية التي من خلالها يحقق الوكيل النتيجة لا تقل أهمية. **صلاحية الإجراء ومعدل التفويض** يقيس نسبة الإجراءات الصالحة والمصرح بها - تتضمن العمليات غير الصالحة استدعاء أدوات غير موجودة أو تمرير أنواع معلمات غير صحيحة؛ تشير العمليات غير المصرح بها إلى إجراءات تتجاوز النطاق المسموح به. يشير المعدل المرتفع إلى أن الوكيل لديه فهم واضح للنظام البيئي للأداة. **معدل صحة استدعاء الأداة** يتطلب أيضًا أن تكون المعلمات معقولة لغويًا: يجب أن تعبر مصطلحات الاستعلام الخاصة بأداة البحث بدقة عن الحاجة، ويجب أن يشير مسار عملية الملف إلى الهدف الصحيح. - -**كفاءة المسار** تقيس مدى كفاءة إكمال المهمة: عدد الخطوات (دورات التفكير والتنفيذ والمراقبة)، والإجراءات المتكررة (البحث المتكرر عن نفس الكلمة الرئيسية، وإعادة قراءة الملف نفسه)، وتكرار التراجع (عدد المرات التي يدرك فيها الوكيل خطأ ويصحح نفسه - التراجع العرضي أمر طبيعي، ولكن التراجع المتكرر يشير إلى عدم كفاية التخطيط المسبق). هناك حاجة إلى خط أساس من خبراء بشريين أو خوارزميات إرشادية لتحديد "عدد معقول من الخطوات". - -**تغطية الاسترجاع** تستهدف مهام جمع المعلومات: هل قام الوكيل باستكشاف مساحة المعلومات بشكل كامل؟ هل قفز إلى الاستنتاجات بعد النظر فقط إلى الصفحة الأولى من نتائج البحث؟ **التكلفة وزمن الوصول** تركز على عدد الطلبات، ونفقات الرمز المميز (تمييز تكاليف الإدخال/الإخراج، مع الأخذ في الاعتبار إعادة استخدام KV Cache)، ووقت ساعة الحائط (بما في ذلك استدلال النموذج + تنفيذ الأداة + زمن استجابة الشبكة). يجب تتبع توزيع الوقت لتحديد الاختناقات. - -### السلامة والمتانة وتغطية المسار - - -**تعد مقاييس السلامة والامتثال** أمرًا بالغ الأهمية في نشر الإنتاج: بدء العمليات الحساسة (حذف البيانات / تعديل الأذونات / إرسال اتصالات خارجية)، وتسرب البيانات (طباعة كلمات المرور في السجلات / إرسال مستندات خاصة إلى واجهات برمجة التطبيقات الخارجية)، والمحتوى المحظور يجب أن يخضع جميعها لمبدأ **عدم التسامح مطلقًا** — على غرار حق النقض الهلوسة (راجع "المبادئ الأربعة" لاحقًا). يؤدي انتهاك خطير واحد للسلامة إلى استخدام حق النقض ضد التقييم الشامل، بغض النظر عن الأداء في الأبعاد الأخرى. - -**المتانة** تقيس الاستقرار في مواجهة عدم اليقين: حساسية البذور العشوائية (مدى اختلاف الأداء في ظل عمليات التهيئة المختلفة)، والقدرة على التكيف مع تغييرات الصفحة (يجب ألا يتسبب تحديث واجهة مستخدم موقع الويب في فشل كامل)، والتسامح مع عدم الاستقرار API (هل يمكنه التعامل بأمان مع حالات الفشل المؤقتة، والمهلات، وتغييرات التنسيق)، وتداخل الذاكرة طويلة المدى (يمكن أن تؤدي المعلومات القديمة المتراكمة في السياق إلى قرارات غير صحيحة). - -**تغطية مزدوجة لمسار التنفيذ والنتيجة النهائية.** هناك تمييز يمكن التغاضي عنه بسهولة: "ما قاله الوكيل وفعله أثناء التنفيذ" (المسار المحدد في الفصل الأول) و"ما أصبح عليه النظام في النهاية" (النتيجة النهائية) هما شيئان مختلفان. عبارة الوكيل "اكتمل الحجز" هي معلومات على مستوى المسار؛ السجل الذي يظهر فعليًا في قاعدة البيانات هو التحقق على مستوى النتائج. انظر فقط إلى المسار وستفتقد عبارة "قالها ولم يفعلها"؛ انظر فقط إلى النتيجة وقد تفوتك خطوات وسطية ضلت طريقها. أعطى Anthropic مثالا ذات مرة: اكتشف وكيل حجز الطيران ثغرة في سياسة شركة الطيران أثناء التنفيذ ووجد خيارًا أرخص للمستخدم - إذا تم تسجيله فقط وفقًا لمسار التنفيذ المحدد مسبقًا، فسيتم الحكم على هذا التشغيل بالفشل؛ ولكن من النتيجة النهائية، حصل المستخدم على صفقة أفضل. ولذلك، ينبغي تغطية كلا النوعين من التقييم لتجنب النقاط العمياء المنهجية. - -### التدقيق البشري والمراجعة الخصمية - -حتى عندما يكون التقييم الآلي موثوقًا به في معظم الأوقات، تظل هناك حاجة إلى عمليات فحص عشوائية بشرية منتظمة: تغطية أنواع المهام المختلفة، والنجاحات والإخفاقات، والحالات الغامضة بالقرب من حدود النتيجة - ليس فقط للتحقق من النتائج، بل أيضًا للتحقق من سلامة الأساس المنطقي للتسجيل. - -يمكن تنظيم عمليات التفتيش المفاجئة في **معايرة القاضي**. قبل نشر قضاة LLM على نطاق واسع، قم ببناء مجموعة معايير ذهبية مشروحة بشريًا (على سبيل المثال، 100-200 حالة تشمل أنواع المهام والصعوبات) وقياس مدى جودة نموذج القاضي (يعمل LLM كقاضي؛ الآلية مفصلة في قسم LLM-as-a-Judge التالي) تتفق مع التعليقات التوضيحية البشرية - معدل الاتفاق البسيط أو كابا كوهين، الأخير يستبعد اتفاق الفرصة. فقط بمجرد أن يتجاوز الاتفاق عتبة محددة مسبقًا (على سبيل المثال، كابا أعلى من 0.7) يجب استخدام القاضي للتقييم على نطاق واسع؛ بعد ذلك، قم بإعادة معايرة المجموعة الذهبية كلما تغير نموذج القاضي أو معيار التقييم. بدون هذه الخطوة، تكون درجات القاضي LLM مجرد "رأي نموذج آخر"، وليست وكيلاً موثوقًا للحكم البشري. - -**مراجعة الخصومة** تستخدم Red Teaming لإنشاء الحالات الصعبة بشكل فعال: إجابات تبدو مثالية وتحتوي على أخطاء مخفية، وإجابات يتم تمريرها من خلال حشو الكلمات الرئيسية، وإجابات تستغل التحيزات المعروفة لنموذج القاضي للحصول على درجات عالية بشكل غير مستحق. **آليات متعددة القضاة** تستخدم قضاة مستقلين متعددين لتسجيل النتائج بشكل منفصل، وتحديد النتيجة النهائية من خلال المتوسط ​​المرجح أو عمليات التحقق من الاتساق - عندما يختلف القضاة بشكل كبير، يتم وضع علامة على القضية لمزيد من المراجعة البشرية. +## بيئة التقييم -## بيئة التقييم الآلي +بعد ضبط أساس المقياس، يصير السؤال التالي: أين نقيس؟ بيئة التقييم جهاز يمكن تشغيله مرارًا: إذا أُعطيت الحالة الابتدائية نفسها، فينبغي أن يعطي الوكيل نفسه نتائج قابلة للمقارنة. -يتطلب تقييم الوكيل بيئة آلية قابلة للتكرار - بيئة يمكنها اختبار تأثيرات التغييرات أثناء التطوير بسرعة. يتطلب بناء مثل هذه البيئة الإجابة على ثلاثة أسئلة: ما الذي يجب تقييمه (تعريف المهمة ومعايير التحقق)، ومع من يتفاعل الوكيل وكيفية محاكاة ذلك النظير، وما هي معايير التسجيل التي يجب استخدامها. +### المكوّنات الخمسة -### المكونات الأساسية لبيئة التقييم +لنعد إلى مهمة telecom التي شرّحناها أعلاه. باتخاذها مرجعًا، يكون كل ما تحتاجه بيئة تقييم قابلة للتشغيل المتكرر حاضرًا بالفعل. -تتكون بيئة التقييم من خمسة عناصر - ستركز الأقسام التالية على تصميم مجموعة البيانات وتصميم معايير التسجيل: +**مجموعة البيانات (Dataset)** هي ملف المهام نفسه: الحالة الابتدائية، والتذكرة الموجهة إلى الوكيل، وضوابط السلوك الموجهة إلى المحاكي، ومعايير القبول، كلها مجموعة في سجل واحد، والسجل الواحد حالة اختبار واحدة. -**مجموعة البيانات**: تحدد مجموعة المهام، بما في ذلك الحالة الأولية ووصف الهدف والحلول المرجعية الاختيارية. +**حالة البيئة (Environment State)** هي المعلومات المتغيرة أثناء تنفيذ المهمة: العملاء والخطوط والباقات والفواتير في قاعدة البيانات، إضافةً إلى وضع الطيران والتجوال ومفتاح توفير البيانات والرصيد المتبقي في جانب الجهاز. ويجب أن تكون قابلة لإعادة التهيئة، و`initialization_actions` هو سكربت إعادة التهيئة. الواقعية تقتضي أن تتبع تغيرات الحالة منطق العمل، والقابلية للضبط تقتضي إمكان العودة إلى نقطة البداية نفسها قبل كل تشغيل. -**حالة البيئة**: تتتبع المعلومات المتغيرة أثناء تنفيذ المهمة، وينبغي أن توازن بين الواقعية وقابلية الضبط. ففي تقييم خدمة العملاء مثلًا، تشمل حالة البيئة سجلات الطلبات في قاعدة البيانات وأرصدة حسابات المستخدمين. وبعد استدعاء الوكيل للدالة `process_refund`، تتغير حالة الطلب من `"delivered"` إلى `"refunded"` ويزداد الرصيد. وتعني الواقعية أن تخضع تغيرات الحالة لمنطق العمل، فلا يتجاوز المبلغ المسترد قيمة الطلب، بينما تعني قابلية الضبط إمكان إعادة كل اختبار إلى الحالة الابتدائية نفسها. +**واجهة الأدوات (Tools)** موزَّعة على جانبين. يستطيع الوكيل استدعاء عمليات جانب المشغّل مثل الاستعلام عن العميل والاستعلام عن الاستهلاك وشحن البيانات والإحالة إلى موظف بشري؛ ويستطيع المستخدم تشغيل مفاتيح جهازه. ومجموعتا الأدوات كلتاهما عمليات ذرّية، ولا وجود لتجريد رفيع المستوى من نوع «حل مشكلة إنترنت المستخدم» — فارتفاع مستوى التجريد أكثر مما ينبغي يحيل التقييم إلى فحص استدعاء دالة واحدة، وتبتلع الأداةُ نفسها التخطيطَ والاستدلال. -**الأدوات**: تحدد مجموعة العمليات التي يمكن للوكيل تنفيذها - يجب ألا توفر الأدوات تجريدات عالية المستوى بشكل مفرط (مثل "حل مشكلة المستخدم")، ولكن يجب أن توفر عمليات ذرية (مثل طلب الاستعلام، وتعديل الحجز، وإرسال البريد الإلكتروني)، مما يجبر الوكيل على دمج هذه العمليات من خلال التخطيط والاستدلال. +**معيار التقييم (Rubric)** هو طبقات الفحص الأربع في `evaluation_criteria` مضافًا إليها قاعدة التجميع `reward_basis`. -**قواعد التقييم (معايير التسجيل)**: تحدد أداء الوكيل، والذي يمكن أن يكون ثنائيًا (نجاح/فشل)، أو مستمرًا (من 0 إلى 100 نقطة)، أو متعدد الأبعاد (دقة التسجيل والكفاءة والسلامة بشكل منفصل). +**بروتوكول التنفيذ (Interaction Protocol)** يحدد ترتيب التفاعل وشروط الإنهاء. وإشارة الإنهاء الطبيعية هنا هي أن يُخرج المستخدم المحاكى `###STOP###`؛ وهناك كذلك حد أعلى لعدد الأدوار، ويمكن للمستخدم المحاكى أن ينهي المحادثة من تلقاء نفسه إذا نفد صبره — فتدنّي كفاءة التواصل يُحتسب في ذاته إخفاقًا. -**بروتوكول التفاعل**: يحدد وضع التفاعل وشروط الإنهاء. +إذا نقص واحد من هذه المكوّنات الخمسة، لم يعد التقييم يشكّل حلقة قابلة للتكرار. وعند النظر في معايير مرجعية أخرى فيما يلي، نظل نتخذ هذه البنود الخمسة إطارًا للمقارنة. -وتشكّل هذه العناصر الخمسة مجتمعةً حلقة تقييم قابلة للتكرار. +### بيئات التقييم من نوع التفاعل بين الإنسان والحاسوب ومن نوع استدعاء الأدوات -![الشكل 7-2: بيئات تقييم استدعاء الأدوات والتفاعل بين الإنسان والحاسوب](images/fig7-2.svg) - -وباختلاف مهامّ الوكيل، يمكن أن تُقسَّم بيئاتُ التقييم تقسيمًا تقريبيًّا إلى نوعين: نوعِ استدعاء الأدوات ونوعِ التفاعل بين الإنسان والآلة. - -### بيئة تقييم استدعاء الأدوات +المهام من طراز telecom لا بد لها من طرف تفاعل، ولذا فإن جزء محاكاة المستخدم من المكوّنات الخمسة لا غنى عنه. وهناك صنف كبير آخر من المهام لا وجود فيه لطرف محاوِر البتة: ففي توليد الشيفرة وتحليل البيانات وحل المسائل الرياضية، لا يتفاعل الوكيل من البداية إلى النهاية إلا مع الأدوات، وتتحدد الصحة بمدى اجتياز التحقق بالتنفيذ، ولا حاجة إلى وسم بشري ولا إلى حكم نموذج. وهذا النوع من البيئات يستغني عن محاكي المستخدم؛ أما المكوّنات الأربعة الباقية فتبقى موجودة، وإن بصورة أبسط: حالة البيئة نظام ملفات أو قاعدة بيانات، ومعيار التقييم قطعة من شيفرة اختبار، وبروتوكول التنفيذ ينكمش إلى «استدعِ الأدوات حتى تُعطي جوابًا أو تنفد الأدوار». -بالنسبة للمهام التي تعتمد بشكل أساسي على استخدام الأداة، مثل إنشاء التعليمات البرمجية وتحليل البيانات، يوضح إطار عمل أدوات التحقق نمط تصميم نموذجي. يكمل الوكيل المهمة عن طريق استدعاء أدوات محددة مسبقًا، ويستند التحقق إلى معايير قابلة للتنفيذ (سواء نجحت الاختبارات، أو ما إذا كانت الإجابات متطابقة)، دون الاعتماد على التعليقات التوضيحية البشرية أو الحكم النموذجي. +يصنّف إطار Verifiers هذا النوع من البيئات وفق بُعدين: هل تحتاج المهمة إلى الاحتفاظ بحالة عبر الأدوار، وهل تحتاج إلى عزل. فـ`SingleTurnEnv` مناسب لطرح مسألة رياضية والتحقق من الجواب مباشرة؛ و`ToolEnv` لبحث عدة صفحات ويب ثم الإجابة إجابةً مركّبة والتحقق من النتيجة النهائية؛ و`StatefulToolEnv` لتعديل سجل في قاعدة بيانات والتحقق من تغيّر الحالة؛ و`SandboxEnv` لتشغيل شيفرة في صندوق رملي وفحص ملفات الخرج. ويلخص الجدول 7-1 هذه الأنواع الأربعة تسهيلًا للاختيار بحسب متطلبات حالة المهمة واستدعاء الأدوات والعزل. -تقدم أدوات التحقق تصميمًا هرميًا للبيئة: `SingleTurnEnv` مناسب للمهام أحادية المنعطف (على سبيل المثال، الأسئلة والأجوبة البسيطة)، ويدعم `ToolEnv` الحلقات المستقلة متعددة المنعطفات لاستدعاءات الأدوات، ويدعم `StatefulToolEnv` و`SandboxEnv` الأدوات ذات الحالة وبيئات وضع الحماية طويلة الأمد (على سبيل المثال، تنفيذ التعليمات البرمجية). على سبيل المثال: `SingleTurnEnv` مناسب لطرح سؤال رياضي والتحقق من الإجابة مباشرة؛ يناسب `ToolEnv` البحث في عدة صفحات ويب وتجميع الإجابة قبل التحقق من النتيجة النهائية؛ يناسب `StatefulToolEnv` تعديل سجلات قاعدة البيانات والتحقق من تغيير الحالة الناتج؛ يناسب `SandboxEnv` تشغيل التعليمات البرمجية في وضع الحماية والتحقق من ملفات الإخراج. يلخص الجدول 7-2 أنواع البيئة هذه للقراء لاختيار بيئة التقييم المناسبة بناءً على حالة المهمة واستدعاءات الأداة ومتطلبات العزل. +الجدول 7-1: مقارنة أنواع بيئات Verifiers -جدول 7-2 مقارنة أنواع بيئة أدوات التحقق - -| نوع البيئة | ثبات الدولة | استدعاءات الأداة | حالة الاستخدام النموذجية | +| نوع البيئة | الاحتفاظ بالحالة | استدعاء الأدوات | الاستعمال النمطي | |---|---|---|---| -| SingleTurnEnv | لا شيء | لا شيء | سؤال وجواب بدورة واحدة، ومسائل الرياضيات | -| ToolEnv | لا شيء | متعدد المنعطفات | بحث + تجميع المعلومات | -| StatefulToolEnv | نعم | متعدد المنعطفات | تعديل سجلات قاعدة البيانات | -| SandboxEnv | نعم + العزلة | متعدد المنعطفات | تنفيذ التعليمات البرمجية واختبارها | +| SingleTurnEnv | لا | لا | سؤال وجواب بدور واحد، مسائل رياضية | +| ToolEnv | لا | متعدد الأدوار | بحث + تركيب المعلومات | +| StatefulToolEnv | نعم | متعدد الأدوار | تعديل سجلات قاعدة البيانات | +| SandboxEnv | نعم + معزول | متعدد الأدوار | تنفيذ الشيفرة والاختبار | -يدعم الإطار أخذ العينات المتوازية والتخزين المؤقت للمسار. يتم حفظ المسار الكامل (الملاحظات، والإجراءات، والمكافآت) من كل تقييم لتحليله وإعادة تشغيله لاحقًا. +يدعم الإطار أخذ العينات على التوازي وتخزين المسارات مؤقتًا؛ ويُحفَظ المسار الكامل لكل تقييم (الملاحظة والفعل والمكافأة)، مما يسهّل التحليل وإعادة التشغيل لاحقًا. كما أن أثر تنفيذ الأداة يتوقف على الحالة الراهنة، ولذا ينبغي عند الإخفاق إعادة رسالة خطأ واضحة لا مجرد راية إخفاق، ليتمكن الوكيل من تعديل استراتيجيته بناءً عليها. -تحتاج البيئة أيضًا إلى التعامل مع تبعية حالة العمليات - تعتمد نتيجة استدعاء الأداة على الحالة الحالية. عند الفشل، يجب أن يقدم رسائل خطأ واضحة بدلاً من إشارات فشل بسيطة، مما يسمح للوكيل بالتعلم من الأخطاء وتعديل إستراتيجيته. +التقييم من نوع استدعاء الأدوات يفحص صحة تغيّرات الحالة القابلة للملاحظة، أما التقييم من نوع التفاعل بين الإنسان والحاسوب فيفحص سلامة استراتيجية التواصل: الأول يتحقق من الفعل، والثاني من حسن التوجيه. ولمقارنة بنية النوعين انظر الشكل 7-2. -### بيئة تقييم التفاعل بين الإنسان والحاسوب +![الشكل 7-2: بيئات تقييم استدعاء الأدوات والتفاعل بين الإنسان والحاسوب](images/fig7-2.svg) -لا تتضمن العديد من المهام الواقعية استدعاءات الأدوات فحسب، بل تتضمن أيضًا محادثات مع المستخدمين البشريين. يحتاج وكيل خدمة العملاء إلى فهم التعبيرات الغامضة وتوضيح الاحتياجات والاستعلام عن أنظمة الواجهة الخلفية وتأكيد المعلومات مع المستخدم. ويواجه تقييم مثل هذه المهام تحديًا أساسيًا: كيف يمكن محاكاة المستخدمين الحقيقيين في بيئة آلية؟ +## تصميم مجموعة بيانات التقييم -مبدأ التصميم الرئيسي هو **الكشف التدريجي عن المعلومات**، وهو الفرق الأساسي بين تقييم التفاعل بين الإنسان والحاسوب والمعايير التقليدية. تكشف معظم المعايير عن المتطلبات الكاملة مقدمًا، ولكن نادرًا ما يتمكن المستخدمون الحقيقيون من التعبير عن احتياجاتهم منذ البداية - غالبًا ما يقولون فقط "يبدو أن هناك مشكلة في رحلتي" أو "الإنترنت لا يعمل". يجب على الوكيل توضيح الحاجة من خلال طرح الأسئلة، وهذه العملية في حد ذاتها هي عرض للقدرة. ولذلك، في التقييم، **يجب ألا يتم الكشف عن معلومات المستخدم المحاكية للوكيل مرة واحدة**؛ وينبغي الكشف عنها بشكل تدريجي، عند الطلب، مع تطور المحادثة. +إن كانت بيئة التقييم هي المسرح، فمجموعة البيانات هي النص. وبالمكوّنات الخمسة نفسها، قد يختلف أسلوب الملء اختلافًا تامًا عند الانتقال إلى صنف آخر من المهام: من أين تأتي المهام، وإلى أي عمق يستطيع المدقق أن يتحقق، وكيف نمنع الحفظ عن ظهر قلب. ينطلق هذا القسم من الممارسة التصميمية لعدة معايير مرجعية عامة، وينتهي بسؤال أكثر عملية: من أين ينبغي أن تأتي مهام مجموعة التقييم التي تبنيها بنفسك؟ -حل τ-bench هو **محاكاة المستخدم**: استخدام LLM آخر للعب دور المستخدم، والتحدث مع الوكيل وفقًا لتعليمات محددة مسبقًا. يتلقى المستخدم المحاكى تعليمات المهمة (على سبيل المثال، "أحتاج إلى إلغاء رحلة الغد")، ويكشف تدريجيًا عن المعلومات الضرورية للوكيل أثناء المحادثة، ويستجيب للاستفسارات، ويرسل إشارة إنهاء عند اكتمال المهمة. تتطلب الموجّه من المستخدم الذي تمت محاكاته "عدم الكشف عن جميع المعلومات مرة واحدة، بل تقديم ما هو ضروري للخطوة الحالية فقط" و"عدم اختلاق المعلومات غير المتوفرة في التعليمات". يتطلب تصميم محاكاة المستخدم مقايضة بين الأصالة وإمكانية التحكم: يجب أن يكون السلوك قريبًا من مستخدم حقيقي (تعبيرات غامضة، معلومات غير كاملة، تقلبات عاطفية عرضية) مع اتباع نص معين لضمان إمكانية التكرار. +### مقارنة عرضية لقرارات التصميم بين المعايير المرجعية -ما يلي هو مثال لمحادثة متعددة الأدوار مع الكشف التدريجي عن المعلومات (يعمل محاكي المستخدم وفقًا لبرنامج نصي ثابت): +وجود طرف التفاعل أو غيابه، وهو ما ميّزناه في القسم السابق، ليس إلا الطبقة الأولى من الاختلاف على مستوى البيئة؛ أما التباينات على مستوى مجموعة البيانات فتُظهر المفاضلات التصميمية بصورة أوضح. ويضع الجدول 7-2 عدة معايير مرجعية كثيرة الاستشهاد جنبًا إلى جنب. -> **المستخدم**: "هناك مشكلة في رحلتي." -> **الوكيل**: "ما هي الرحلة؟" -> **المستخدم** (يكشف حسب النص): "Delta 123، صباح الغد من سان فرانسيسكو إلى نيويورك." -> **الوكيل**: "ما هي المشكلة المحددة؟" -> **المستخدم** (يتم الكشف عن كل نص برمجي): "مدة الرحلة طويلة جدًا، أريد تغييرها." -> **الوكيل**: "هل لديك أي تفضيلات للرحلة الجديدة؟" -> **المستخدم** (يكشف عن النص): "لا بأس بأي رحلة بعد الظهر." +الجدول 7-2: قرارات التصميم المفتاحية في عدة معايير مرجعية للوكلاء -يتبع جهاز محاكاة المستخدم نصًا ثابتًا (المعلومات المعروفة + قواعد الكشف)، مما يضمن إمكانية تكرار التقييم مع محاكاة أسلوب التعبير التقدمي للمستخدم الحقيقي. وكثيرًا ما يُضبَط للمستخدم المحاكى **صبرٌ محدود**: فإذا كان تواصلُ الوكيل ضعيفَ الكفاءة، جاز للمستخدم المحاكى أن ينهي المحادثة، فتفشل المهمة. +| المعيار المرجعي | القدرة المقيسة | مصدر المهام | من يؤدي دور البيئة | المدقق | +|---|---|---|---|---| +| τ²-bench | التفاعل بين الإنسان والحاسوب واستدعاء الأدوات في خدمة العملاء | كتابة يدوية + توليد تركيبي | محاكي المستخدم + قاعدة بيانات العمل | أربع طبقات فحص تُجمَّع ثنائيًا وفق `reward_basis` | +| SWE-bench Verified | تطوير البرمجيات، coding | مشكلات GitHub حقيقية، مغربلة يدويًا | مستودع الشيفرة + حزمة الاختبارات | تحقق مزدوج FAIL\_TO\_PASS / PASS\_TO\_PASS | +| AndroidWorld | تشغيل واجهة هاتف Android | تجسيد قوالب ذات معاملات | محاكي Android حقيقي | تأكيدات على حالة الواجهة النهائية | +| OSWorld | تشغيل واجهة سطح مكتب Linux | يبدأ من حالة وسيطة مهيأة سلفًا | آلة افتراضية حقيقية | 134 دالة تقييم مستقلة | +| Terminal-Bench | تشغيل طرفية Linux، coding | كتابة يدوية | حاوية Docker | فحص نظام الملفات + تنفيذ حقيقي | +| GAIA | مساعد ذكاء اصطناعي عام يجمع المعلومات | كتابة يدوية + مرفقات خاصة | الإنترنت المفتوح | مطابقة نصية دقيقة | -τ-bench هو معيار لتقييم أداء الوكيل في العمليات التجارية المنظمة (على سبيل المثال، خدمة عملاء شركات الطيران، وخدمة عملاء التجزئة). تكون عمليات التحقق الخاصة بها على مستوى المكونات ومتعددة الأبعاد: من ناحية، تتحقق مما إذا كانت حالة قاعدة البيانات النهائية صحيحة (على سبيل المثال، تتغير حالة سجل الحجز إلى "ملغاة")؛ ومن ناحية أخرى، فإنه يتحقق مما إذا كان الوكيل قد قدم المعلومات الأساسية اللازمة أثناء المحادثة (على سبيل المثال، مبلغ الاسترداد ووقت الوصول، ويتم التحقق من ذلك من خلال البحث عن سلاسل أو أنماط محددة). يقوم هذا التحقق المزدوج بفحص الدقة التشغيلية وفعالية الاتصال في نفس الوقت. ومع ذلك، على مستوى المهمة، تنهار هذه الاختبارات في نهاية المطاف إلى **مكافأة ثنائية تبلغ صفر أو واحد** - يجب اجتياز جميع الاختبارات للحصول على النتيجة 1؛ أي درجات فشل فردية 0. تجعل المكافآت الثنائية من السهل حساب مقاييس الموثوقية مثل Pass^k (راجع قسم "نظام مقاييس التقييم" لاحقًا)، على حساب تسجيل النقاط "دقيقة من الناحية التشغيلية ولكنها تفتقد حقلاً واحدًا غير حرج" مثل "الفشل الكامل". +### المدققات -لا يعمل **τ²-bench** المحسّن بشكل أساسي على تحسين دقة التسجيل؛ وبدلا من ذلك، فإنه يتقدم المعيار في مجالين آخرين. أولاً، **بيئة التحكم المزدوج**: لم يعد الوكيل هو الطرف الوحيد الذي يمكنه استدعاء الأدوات - يمكن لمحاكاة المستخدم أن تعمل على نفس البيئة المشتركة (يطلب الوكيل من المستخدم التبديل إلى وضع الطائرة، ويؤدي إجراء المستخدم فعليًا إلى تغيير حالة البيئة)، وهو ما يتطابق بشكل أفضل مع السيناريوهات الحقيقية مثل الدعم الفني، حيث يجب على المستخدم تقديم المساعدة. ثانيًا، **مواصفات المهام الأكثر دقة وإنشاء المهام التركيبية**: عدد أقل من الغموض في شروط النجاح، ومثيلات المهام التي يمكن تحديد معلماتها وإنشائها على دفعات (راجع قسم "ضمان التحقق والموضوعية" لاحقًا للحصول على أبعاد التحقق التفصيلية). +يسهل على الوكيل أن يكتب تقريرًا مسهبًا يقول فيه إن المهمة أُنجزت بالكامل، بينما لم يُنجَز في الواقع شيء. وعلى إطار التقييم أن يتحقق من وقائع يستطيع الحاسوب مراجعتها باستقلال، لا من إقرار الوكيل عن نفسه. -> **التجربة 7-1 ★: تشغيل τ²-bench ومقارنة تطورها من τ-bench** -> -> تدير هذه التجربة إطار تقييم τ²-bench لفهم مبادئ تصميم بيئات تقييم التفاعل بين الإنسان والحاسوب. من خلال مقارنة τ-bench مع τ²-bench، يمكننا أن نرى كيف يتم تحسين مجموعات بيانات التقييم بشكل متكرر. -> -> اقرأ ملفات تعريف المهمة بعمق: تحتوي كل مهمة على معلومات معروفة للمستخدم، وتعليمات المهمة التي تحكم الكشف التدريجي واستراتيجيات الاستجابة، وشروط النجاح (الحالة المستهدفة لقاعدة البيانات ومعلومات التأكيد التي يجب أن تظهر في الحوار). قم بتشغيل عملية التقييم الكاملة، ولاحظ الحوار متعدد المنعطفات بين محاكي المستخدم والوكيل، وقم بتحليل أوضاع الفشل النموذجية (انتهاكات السياسة، وحذف المعلومات، وعمليات التسليم المفرطة للعملاء البشريين، وما إلى ذلك). -> -> -> ![الشكل 7-3: بنية تقييم مقاعد البدلاء τ²](images/fig7-3.svg) -> -> -> قارن اختلافات التصميم بين τ-bench و τ²-bench: كان الإصدار الأولي من τ-bench يحتوي على تعليمات مستخدم بسيطة للغاية (يمكن للوكيل تخمين الإجابة)، وشروط نجاح غير دقيقة (مما يؤدي إلى سوء التقدير)، ومحاكي مستخدم ميكانيكي. قام τ²-bench بإجراء تحسينات منهجية لمعالجة هذه المشكلات: -> -> - **تم تقديم تعليمات مهمة أكثر تفصيلاً**: بما في ذلك "متطلبات الاستناد إلى النتائج الفعلية"، مما يعني أن الاستجابات يجب أن تستند إلى الحالة الفعلية للبيئة -> - **معايير تقييم أكثر دقة**: على سبيل المثال، "يجب أن يعرض اختبار السرعة "ممتاز" حتى يتم اعتباره حلاً" -> - **مواصفات سلوك محاكاة المستخدم الأكثر واقعية**: الكشف التدريجي عن المعلومات، والتقلبات العاطفية الطبيعية -> -> انتبه بشكل خاص إلى مهام مجال الاتصالات المضافة حديثًا في τ²-bench، وافهم تصميم بيئة التحكم المزدوج لـ τ²-bench (كما ذكرنا سابقًا، يعمل المستخدم والوكيل معًا على نفس البيئة المشتركة). -> - -يسأل تقييم استدعاء الأداة عما إذا كان قد تم إكمال تغيير الحالة الملحوظ؛ يسأل تقييم التفاعل بين الإنسان والحاسوب ما إذا كان الوكيل قد ساعد المستخدم في الوصول إلى فهم جديد أو اتخاذ قرار. الأول يختبر صحة تصرفات الوكيل؛ والأخير يختبر سلامة استراتيجية الاتصال الخاصة به. +**يفكك SWE-bench Verified عبارة «اكتمل الإصلاح» إلى قضيتين مستقلتين.** الأولى FAIL\_TO\_PASS: يخفق قبل الإصلاح وينجح بعده، وهذا يثبت أن المشكلة حُلّت فعلًا. والثانية PASS\_TO\_PASS: ينجح قبل الإصلاح وبعده، وهذا يثبت أنه لم يُدخل عيبًا جديدًا. فإن فحصت الأولى وحدها أمكن للوكيل التملص بحذف التأكيدات المعترضة أو تعديلها؛ وإن فحصت الثانية وحدها فكأنك لم تفحص شيئًا. ولا يصير «أُصلح» و«لم يُكسر شيء» نتيجتين قابلتين للإثبات كل على حدة إلا بفحصهما معًا. ويؤكد كذلك ثبات الاختبارات نفسها، مستبعدًا الاختبارات المتقلبة (flaky test) التي تنجح تارةً وتخفق تارة. -ويتطرق بناء بيئات التقييم أيضًا إلى بيئات المحاكاة - عندما يجب أن تدعم بيئة التقييم التفاعلات المتكررة على نطاق واسع، فإنها تصبح بيئة محاكاة. وتتناول نهاية هذا الفصل هذا الأمر بإيجاز. +**مدقق OSWorld قادر على كشف الحالات التي تبدو منجَزة ظاهريًا وهي في الجوهر خاطئة.** فهو مزوَّد بـ134 دالة تقييم مستقلة وبصلاحية وصول كاملة إلى نظام التشغيل، فيستطيع فحص بنية نظام الملفات وحالات العمليات واتصالات الشبكة والحالة الداخلية للتطبيقات. ففي مهام قواعد البيانات لا يكتفي سكربت التقييم بالتأكد من وجود ملف التقرير، بل يتصل بقاعدة البيانات ليراجع تنفيذ الـSQL فعليًا؛ وفي مهام المتصفح يحلل شجرة DOM ويفحص ملفات تعريف الارتباط وlocalStorage ويرسل طلبات تحقق إلى الواجهة الخلفية للتأكد من أن النموذج قد سرى مفعوله حقًا. -## تصميم مجموعات بيانات مهام التقييم +**مهمة `build-linux-kernel-qemu` في Terminal-Bench** تشترط بناء نواة Linux 6.9 من المصدر، وإضافة printk مخصص في `start_kernel`، وتوليد initramfs وتشغيله في QEMU؛ ومعيار النجاح ظهور تلك الرسالة المخصصة في سجل الإقلاع. لا يستطيع الوكيل تزوير الخرج، ولا مفر له من إتمام العملية كلها فعليًا. -بيئة التقييم هي "المرحلة"، ومجموعة البيانات هي "البرنامج النصي". غالبًا ما تحدد جودة النص قيمة التقييم أكثر من المرحلة نفسها. مجموعة البيانات سيئة التصميم، حتى عند تشغيلها في بيئة مثالية، لا تؤدي إلا إلى الضوضاء. يستخلص هذا القسم العديد من المبادئ التي تم التحقق من صحتها بشكل متكرر من ممارسات تصميم المعايير مثل GAIA، وAndroidWorld، وSWE-Bench Verified، وτ-bench وτ²-bench، وTerminal-Bench، وOSWorld، وOSWorld-Verified. - -> **التجربة 7-2 ★: تنفيذ المهام المعيارية يدويًا** -> -> حدد المهام من كل من GAIA وAndroidWorld وSWE-Bench Verified وτ²-bench وTerminal-Bench وOSWorld-Verified وأكملها يدويًا. يوصى بإكمال مهمة واحدة بسيطة، ومهمة واحدة متوسطة، ومهمة واحدة صعبة من كل مجموعة بيانات - يجب أن يمثل المستوى "الصعب" تحديًا حتى بالنسبة للبشر. قارن نتائج التنفيذ بالإجابات القياسية وقم بتحليل مصادر التناقضات. من خلال هذه التجربة العملية، فهم: ويجب أن يوازن وصف المهام بين الوضوح والانفتاح، ويجب أن تكون معايير التحقق موضوعية وقابلة للتنفيذ، ويجب أن تكون الصعوبة الهرمية للمهام قادرة على التمييز بين مستويات القدرة المختلفة. -> +### تدرّج صعوبة المهام -### التحديات الأساسية في تصميم مجموعة بيانات المهام +ينبغي أن تضم مجموعة مهام التقييم مهامّ بدرجات صعوبة مختلفة. وبذلك لا تتقادم المجموعة سريعًا مع تحسّن قدرات النماذج. -**التحدي الأول: التوتر بين الوضوح والانفتاح.** يجب أن تكون أوصاف المهام واضحة بما يكفي لضمان التقييم القابل للتكرار، ولكن ليست صارمة لدرجة خنق إبداع الوكيل. تقدم GAIA مثالاً: المهام "بسيطة من الناحية النظرية" ولكن لها مسارات تنفيذ مفتوحة - على سبيل المثال، قد تتطلب المهمة من الوكيل تحديد رائد فضاء من صورة اليوم لعلم الفلك التابعة لناسا وتحديد المدة التي قضاها في الفضاء. الهدف واضح، ولكن كيفية البحث والتصفية والتحقق أمر متروك تمامًا لاتخاذ القرار المستقل للوكيل. +تنقسم أسئلة GAIA الـ466 جميعها إلى ثلاث درجات صعوبة: يكفي في Level 1 أداة أو أداتان (البشر 93.9%، وGPT-4 30.3%)، ويستلزم Level 2 تفكيرًا متعدد الخطوات (91.8% مقابل 9.7%)، ويستلزم Level 3 تركيبًا معقدًا (87.3% مقابل 0%). وهذا التدرّج لا يكتفي بوسم الصعوبة بل له قيمة تشخيصية: الإخفاق في Level 1 يشير إلى الاستعمال الأساسي للأدوات، وLevel 2 إلى التخطيط متعدد الخطوات ودمج المعلومات، وLevel 3 إلى التفكير عبر متتاليات طويلة وإدارة التعقيد، ويقابل كلٌّ منها اتجاه تحسين مختلفًا. -**التحدي الثاني: الموازنة بين الأصالة وإمكانية التحكم.** تحتوي مهام العالم الواقعي على عدم اليقين والضوضاء، مما قد يكشف عن المتانة ولكنه يهدد أيضًا إمكانية التكرار. استخدم الإصدار الأولي من SWE-Bench بشكل مباشر مشكلات GitHub الحقيقية، مما يضمن الأصالة ولكنه يؤدي أيضًا إلى أوصاف مهام غامضة وحالات اختبار غير مكتملة ومعايير تقييم ذاتية. قدمت SWE-Bench Verified التحقق المنهجي من قبل خبراء بشريين، حيث تم اختيار 500 مهمة عالية الجودة ذات مشكلات محددة بوضوح واختبارات كافية وحلول واضحة، مما أدى إلى تحسين إمكانية التحكم بشكل كبير مع الحفاظ على الأصالة. +ويمتد Terminal-Bench من تسجيل نموذج mlflow البسيط، إلى كسر كلمة مرور 7z متوسط الصعوبة، إلى التكامل متعدد المكوّنات الصعب بين خادم git وخادم ويب، وصولًا إلى أصعبها وهو تحليل الشفرات التفاضلي لـFEAL. -**التحدي الثالث: تنسيق التنوع والتنظيم.** تحتاج مجموعة البيانات الفعالة إلى تغطية السيناريوهات النموذجية وحالات الحافة ومصائد الأخطاء، مع وجود تنظيم منهجي أيضًا حتى تتمكن نتائج التقييم من تشخيص نقاط ضعف محددة في القدرات. تمتد مهام AndroidWorld البالغ عددها 116 مهمة إلى 20 تطبيقًا حقيقيًا، كل منها مشروح بالقدرات الأساسية التي يتطلبها (التخطيط متعدد الخطوات، والفهم البصري، والتفكير الزمني) - لذا فإن النتائج لا تسفر عن معدل نجاح إجمالي فحسب، بل تسفر عن ملف تعريف لنقاط القوة والضعف على طول أبعاد قدرة محددة. والأهم من ذلك، أن آلية تحديد المعلمات يمكن أن تولد متغيرات مهام غير محدودة تقريبًا. +كما يصمم τ²-bench **مهام فخّ** خاصة: يزعم المستخدم أن «خدمة العملاء وافقت على الإلغاء» بينما الأمر في الواقع لا يوافق السياسة، لاختبار ما إذا كان الوكيل يحافظ على حكمه الصحيح تحت الضغط والتضليل. -**التحدي الرابع: تكلفة التقييم مقابل التغطية.** يمكن أن تستغرق مهام الوكيل المعقدة دقائق أو حتى ساعات لإكمالها، مما يستهلك عددًا كبيرًا من الرموز المميزة. يحتاج حجم مجموعة البيانات إلى تحقيق التوازن بين الشمولية والاقتصاد. يختار GAIA بعناية 466 مهمة عبر ثلاثة مستويات صعوبة، تغطي أبعادًا متعددة للقدرات مع السماح بالتقييم بتكلفة معقولة. خفضت SWE-Bench Verified مجموعتها من 2294 مهمة إلى 500 (مما أدى إلى خفض التكاليف بحوالي أربعة أخماس مع تحسين نسبة الإشارة إلى الضوضاء من خلال معايير جودة أكثر صرامة). +### الوقاية من تسرب البيانات -**التحدي الخامس: منع تلوث البيانات.** في عصر نماذج اللغات الكبيرة، يمثل تلوث البيانات تحديًا خطيرًا للتقييم: عندما يتم تضمين بيانات التقييم في بيانات التدريب، يقيس التقييم الحفظ بدلاً من التعميم. إن الأمر يشبه حفظ الإجابات قبل الامتحان، فالدرجات الجيدة لا تعكس القدرة الحقيقية. تعتمد المعايير المختلفة استراتيجيات وقائية مختلفة: تعتمد غايا على تفرد إجاباتها؛ تتطلب الأسئلة جمع معلومات من مصادر متعددة للإجابة عليها، وتأتي بعض المهام مع ملفات مرفقة تم إنشاؤها خصيصًا (ملفات PDF/صوت/صور غير موجودة على الإنترنت)، لذلك لا يمكن لصفحة ويب واحدة تقديم الإجابة مباشرة. SWE-Bench Verified نفسها عبارة عن مجموعة فرعية مكونة من 500 مهمة حصلت عليها OpenAI من خلال فحص الجودة اليدوي لـ SWE-Bench الأصلي، ولا تتضمن تصميمًا لمنع التسرب يعتمد على الوقت. إنها أعمال لاحقة مثل SWE-bench-Live التي تستخدم حقًا الحداثة الزمنية لمنع التسرب، ودمج المشكلات التي تم إنشاؤها بشكل مستمر بعد تاريخ انتهاء تدريب النموذج، مع الحفاظ على التقييم قبل مجموعة تدريب النموذج. يمنع τ²-bench التسرب من خلال إنشاء المعلمات الديناميكية، حيث يتم إنشاء مثيلات مهمة محددة (أسماء المستخدمين، وأرقام الطلبات، والتواريخ، وما إلى ذلك) بشكل عشوائي في كل مرة. يساعد إنشاء المهام ذات المعلمات في AndroidWorld بشكل طبيعي على منع التسرب لأن التحقق يعتمد على حالة واجهة المستخدم النهائية، وليس تسلسل العمليات. يجعل Terminal-Bench التسرب قابلاً للاكتشاف عن طريق تضمين معرفات GUID الكناري (معرفات فريدة عالميًا تستخدم كعلامات تتبع): إذا كان النموذج يمكنه إخراج محتوى يحتوي على GUID هذا، فهذا يشير إلى أن البيانات المعيارية قد تسربت إلى مجموعة التدريب. +**يجعل GAIA إجاباته غير قابلة للبحث المباشر على الإنترنت.** فمهامه بسيطة مفاهيميًا لكن مسارها مفتوح: مثلًا الانطلاق من صورة اليوم الفلكية لناسا في تاريخ بعينه، والتعرف على رائد الفضاء في الصورة، والبحث عن مجموعة روّاد الفضاء التي انتمى إليها، وحساب من قضى من تلك المجموعة أقصر مدة في الفضاء، وإخراج النتيجة بصيغة صارمة هي «اسم العائلة، مفصولًا بفاصلة منقوطة، مع فواصل الآلاف». الإجابة بالغة التحديد، وتتحدد صحتها بمطابقة نصية دقيقة. وتقوم الوقاية من التسرب على أمرين: أولهما أن السؤال لا يُجاب عنه إلا بتركيب عدة مصادر معلومات، فلا تعطي صفحة ويب واحدة الجواب مباشرة؛ وثانيهما أن بعض المهام مرفقة بملفات صُنعت خصيصًا (ملفات PDF وصوت وصور غير موجودة على الإنترنت). -### التصميم الدقيق لأوصاف المهام +**يشتق AndroidWorld عددًا كبيرًا من النسخ من قالب واحد.** فمهامه ليست نصًا ساكنًا بل قوالب قابلة للتجسيد ديناميكيًا، مثل «غيّر رقم هاتف جهة الاتصال `[CONTACT_NAME]` إلى `[NEW_PHONE]`»، مع توليد قيم المعاملات عشوائيًا في كل تقييم. وفي هذا ثلاث فوائد: اختلاف المعاملات في كل مرة يُبطل إعادة تشغيل تسلسل عمليات ثابت؛ ويستطيع قالب واحد توليد نسخ لا تكاد تُحصى؛ وتثبيت بعض المعاملات وتغيير الباقي يتيح قياس أثر عامل بعينه قياسًا دقيقًا. -يضمن GAIA تفرد الإجابة من خلال قيود مصدر المعلومات الواضحة والنطاقات الزمنية والموضوعات وأهداف الاستعلام. على سبيل المثال، تتطلب مهمة المستوى 3 البدء من صورة ناسا لتاريخ محدد، وتحديد رائد الفضاء من خلال الفهم البصري، والبحث عن مجموعة رواد الفضاء التي ينتمون إليها، وحساب وقتهم في الفضاء، وتنسيق الإخراج بدقة ("الاسم الأخير؛ الحقول المفصولة بفواصل منقوطة؛ الأرقام المنسقة بفواصل الآلاف"). يتم التحقق تلقائيًا من كل التفاصيل، ولا يتم احتساب سوى المطابقة التامة في التنسيق والمحتوى كتمرير. +**يُضمّن Terminal-Bench معرّف كناري في نص السؤال.** فكل سؤال يحمل canary GUID؛ وإذا استطاع نموذج إخراج محتوى يتضمن ذلك المعرّف، فمعناه أن بيانات المعيار المرجعي دخلت مجموعة التدريب. وهذا لا يمنع التسرب لكنه يجعله قابلًا للكشف. -يقدم τ²-bench تصميمًا سياقيًا، حيث تحتوي كل مهمة على طبقات متعددة من المعلومات: المشكلة السطحية ("بيانات الهاتف المحمول لا تعمل")، وتوقع الأداء ("يتطلب تصنيف سرعة ممتاز")، والقيد ("لن نقبل أي تصنيف آخر")، والعاطفة الضمنية. أحد التحسينات الرئيسية هو فصل "المعلومات المعروفة" عن "تعليمات المهمة": المعلومات المعروفة هي ما يعرفه المستخدم حاليًا، بينما تقوم تعليمات المهمة بتوجيه المحاكي حول كيفية الكشف عن المعلومات تدريجيًا، بما في ذلك "متطلبات الاستناد إلى النتائج الفعلية" (يجب أن تستند الاستجابات إلى النتائج الفعلية التي يتم إرجاعها بواسطة استدعاءات الأداة، وليست ملفقة). +### ضبط الجودة والصيانة على المدى الطويل -يتضمن SWE-Bench Verified مجالات منظمة مثل وصف المشكلة، وخطوات إعادة الإنتاج، والسلوك المتوقع/الفعلي، مع قيام المعلقين بالتحقق من التطابق بين الوصف وحالات الاختبار. يمكن التحقق من كل عنصر في أوصاف مهمة Terminal-Bench ميكانيكيًا: ما إذا كانت مسارات الملفات موجودة، وقيم الأذونات صحيحة، ومعلمات الشهادة صالحة، وتنسيقات التاريخ صحيحة. على سبيل المثال، يتطلب "build-linux-kernel-qemu" إنشاء Linux kernel 6.9 من المصدر، وإضافة printk مخصص في `start_kernel`، وإنشاء initramfs، وتشغيله في QEMU. معيار النجاح هو ظهور الرسالة المخصصة في سجل التمهيد - لا يمكن للوكيل تزييف الإخراج؛ يجب أن تكمل العملية برمتها حقًا. +إعداد مجموعة تقييم عالية الجودة أمر شديد الصعوبة. والصورة الحالية لأغلب المعايير المرجعية المذكورة أعلاه هي ثمرة جولات متتالية من الترميم بعد أن دخلت النسخة الأولى حيّز الاستعمال وانكشفت مشكلاتها. فمن τ-bench إلى τ²-bench مثلًا خمسة مواضع أُعيد تصميمها. -يستخدم AndroidWorld تصميم **قالب ذو معلمات**. المهمة ليست نصًا ثابتًا ولكنها قالب يمكن إنشاءه ديناميكيًا (على سبيل المثال، "تغيير رقم هاتف جهة الاتصال `[CONTACT_NAME]` إلى `[NEW_PHONE]`")، مع قيم معلمات مختلفة يتم إنشاؤها عشوائيًا لكل تقييم. وهذا له ثلاث فوائد: +أولًا، **كانت تعليمات المهمة أعمّ مما ينبغي فأمكن تخمين الجواب**. كُتبت تعليمات النسخة الأولى كتابة فضفاضة، فلم يكن النموذج بحاجة إلى توضيح الطلب حقًا؛ إذ كان تخمين إجراء ما بالبداهة كافيًا للاجتياز. فقسّم τ²-bench النص إلى خانتين، `known_info` و`task_instructions`: الأولى ترسم حدود ما يعرفه المستخدم، والثانية تنظم طريقة الكشف. وما لا يعرفه المستخدم لا سبيل للوكيل إلى تخمينه، ولا يحصل عليه إلا بالاستعلام. -- **يمنع الحفظ**: تختلف قيم المعلمات في كل مرة، مما يمنع إعادة تشغيل تسلسل ثابت من العمليات -- **يزيد من تنوع البيانات**: يمكن لقالب واحد إنشاء عدد غير محدود من الحالات تقريبًا -- **يدعم التجارب المقارنة**: يتيح إصلاح معلمات معينة مع تغيير معلمات أخرى قياسًا دقيقًا لتأثيرات عوامل معينة +ثانيًا، **لم تكن شروط النجاح دقيقة بما يكفي فأخطأ التحقق في الحكم**. فشرط مثل «عادت الشبكة» لا حدّ له قابلًا للمراجعة. فغيّره τ²-bench إلى «لا تُعد محلولة إلا إذا أعاد اختبار السرعة excellent؛ وأما poor وfair وgood فلا تُقبل». ويستهدف هذا التغيير **الإصلاحات الشكلية** التي تكتم العَرَض دون أن تحل السبب الجذري. -يعتمد التحقق على حالة واجهة المستخدم النهائية (على سبيل المثال، ما إذا كان حقل رقم الهاتف يحتوي على القيمة المتوقعة)، وليس على تسلسل العمليات. +ثالثًا، **كان سلوك محاكي المستخدم آليًا أكثر مما ينبغي**. فالمستخدم المحاكى في النسخة الأولى لم يكن يفعل سوى الرد السلبي. فأضاف إليه τ²-bench انفعالًا (إظهار الاستياء بعد أول إصلاح فاشل)، وحدًّا للصبر (إنهاء المحادثة إذا كان التواصل شديد التدني في الكفاءة)، وشرط الترسيخ الواقعي. وبتضافر الثلاثة يقترب المحاكي من المستخدم الحقيقي مع بقائه قابلًا لإعادة الإنتاج. -غالبًا لا تبدأ مهام OSWorld من حالة أولية "نظيفة" ولكن من حالات وسيطة تم تكوينها بعناية، وتشبه إلى حد كبير سيناريوهات الاستخدام في العالم الحقيقي. تحتاج أوصاف المهام إلى التعامل مع حلول متعددة ("يتطلب ضبط الخلفية على اللون الأرجواني" رمز لون محدد لتوضيح الغموض؛ يجب أن يقبل "تسلسل ملفي CSV" جميع الأساليب المعقولة مثل الاحتفاظ برأس واحد أو كلا الرأسين) وعدم اليقين البيئي (إجراءات مكافحة الحذف على مواقع الويب، وواجهات مستخدم التطبيق المتطورة، وظروف السباق - يعمل نظام OSWorld-Verified على تخفيف ذلك من خلال لقطات الصفحة غير المتصلة بالإنترنت، وإصدارات التبعية المقفلة، وشروط الانتظار الصريحة، وما إلى ذلك). +رابعًا، **لا يشارك المستخدم في الحوار وحده بل في التشغيل أيضًا**. أدخل نطاق telecom بيئة التحكم المزدوج. ففي التقييمات السابقة لم يكن يغيّر البيئة سوى الوكيل، بينما في سياقات كالدعم الفني ينبغي أصلًا أن ينفّذ المستخدم نفسه جزءًا معتبرًا من الأفعال على جهازه. والتحكم المزدوج يضيف إلى التحقق بُعدًا آخر: فبعد أن يغيّر المستخدم الحالة، لا يعلم الوكيل النتيجة إلا باستدعاء الأداة من جديد، فصار التحقق يغطي كذلك سؤال «هل قرأ الوكيل فعلًا نتيجة العملية من جانب المستخدم». -لا تستوعب هذه القائمة مشهد تقييم الوكلاء كله. ففي فئة الويب وواجهات المستخدم الرسومية وحدها معايير متعددة، لكل منها غاية مختلفة. يبني WebArena مواقع قابلة لإعادة الإنتاج بالكامل، مثل المتاجر والمنتديات ومنصات استضافة الشفرة، فيحصر تقلب الويب الحقيقي داخل بيئة معزولة. ويتخذ Mind2Web الاتجاه المقابل، إذ يختبر التعميم مباشرة على مئات المواقع الحقيقية. أما [ClawBench](https://claw-bench.com/) ([الورقة البحثية](https://arxiv.org/abs/2604.08523)، [الشفرة](https://github.com/TIGER-AI-Lab/ClawBench)) فيكلّف وكلاء يعملون داخل حاويات معزولة بإنجاز مهام يومية متكاملة على مواقع حقيقية؛ يغطي الإصدار V1 عدد 153 مهمة موزعة على 144 موقعًا، ويضيف V2 عدد 130 مهمة أخرى. كما يسجل خمس طبقات من الأدلة: إعادة تشغيل الجلسة، ولقطات شاشة للأفعال، وحركة HTTP، وأفعال المتصفح، ورسائل الوكيل. وبهذا يكمل المعايير القائمة على البيئات المعزولة، ويساعد على تحليل تغير المواقع وحالات الفشل النادرة، وإن كانت قابلية إعادة إنتاج نتائجه تتأثر بتغير مواقع الأطراف الخارجية. ويتخصص BrowseComp من جهته في الاسترجاع العميق، حيث تكون الإجابات بعيدة المنال ولا تظهر إلا بعد تصفح متعدد القفزات وتحقق متقاطع. وفي مجال استدعاء الأدوات توجد لوحات متخصصة، مثل BFCL (لوحة بيركلي لاستدعاء الدوال). لا يسعى هذا الفصل إلى حصر جميع المعايير، بل يختار نمطين أساسيين للبيئات—استدعاء الأدوات والتفاعل بين الإنسان والحاسوب—ويضيف إليهما تشغيل واجهات المستخدم الرسومية في دراسات مجموعات البيانات، ثم يتعمق في مفاضلات التصميم. وعندما تفهم هذه الأنماط، تستطيع أن تحدد سريعًا ما يقيسه أي معيار جديد، ومدى مقاومته لتسرب البيانات، والحدود التي يمكن تعميم نتائجه ضمنها. +خامسًا، **تُولَّد نسخ المهام ديناميكيًا**. فالنسخ المحددة في τ²-bench (أسماء المستخدمين والأرقام وتوليفات الأعطال) قابلة للمعاملة والتوليد بالجملة، وهذا يحسّن التغطية ومقاومة التسرب معًا. -### التصميم الهرمي لتعقيد المهام +**SWE-bench Verified: قبل النشر استُبعد 71% من المهام الأصلية.** اختارت OpenAI عشوائيًا 1699 مهمة من أصل 2294 للتقييم البشري، واستقدمت 93 مطورًا متمكنًا من Python لفحصها واحدة واحدة: هل وصف المشكلة واضح، وهل تغطي حالات الاختبار الشروط الحدّية، وهل الاختبارات مستقرة، وهل يُدخل الـpatch المرجعي أخطاء جديدة، وهل الصعوبة معقولة. وفي النهاية لم يجتز سوى 500. ومعدل الاستبعاد المرتفع يأتي بنسبة إشارة إلى ضجيج أفضل، وتنخفض معه كلفة التقييم بنحو 80%. فمهام الوكلاء المعقدة كثيرًا ما تستغرق من دقائق إلى ساعات، وتشغيل مجموعة تقييم كاملة بنموذج متقدم يكلف غالبًا آلاف الدولارات من الرموز، ولذا فخفض كلفة التقييم بالغ الأهمية. -تصمم GAIA ثلاثة مستويات صعوبة: المستوى 1 يتطلب أدوات 1-2 فقط (البشر 93.9% مقابل GPT-4 30.3%)، المستوى 2 يتطلب التفكير متعدد الخطوات (91.8% مقابل 9.7%)، والمستوى 3 يتطلب مجموعات معقدة (87.3% مقابل 0%). القيمة التشخيصية لهذا التصميم الهرمي هي: الفشل في المستوى 1 يشير إلى مشكلات استخدام الأداة الأساسية، والمستوى 2 يشير إلى التخطيط متعدد الخطوات وتكامل المعلومات، والمستوى 3 يشير إلى التفكير طويل التسلسل وإدارة التعقيد. يتوافق كل مستوى مع اتجاهات تحسين مختلفة (هندسة الموجّهات مقابل آليات التخطيط مقابل الهندسة الهرمية/ما بعد التدريب). +**OSWorld: في الأشهر الخمسة عشر التالية للنشر انكشف أكثر من 300 مشكلة.** فبعد صدوره في نيسان/أبريل 2024 صار سريعًا معيارًا مرجعيًا مهمًا لتقييم الوكلاء متعددي الوسائط، لكن الاستعمال الواسع اللاحق كشف أربعة أصناف من المشكلات: مشكلات البيئة (حماية المواقع من الكشط، وCAPTCHA، وتغيّر المحتوى الديناميكي)، ومشكلات وصف المهام (صياغات ملتبسة)، ومشكلات منطق التحقق (مفرط في التشدد أو في التساهل)، ومشكلات الحالة الابتدائية (إعداد ناقص). وشكّل فريق من جامعة هونغ كونغ مجموعة من نحو عشرة أشخاص، وعمل شهرين بتعاون وثيق مع MoonShot AI وOpenAI وByteDance Seed TARS وAnthropic وSimular وغيرها على إصلاح منهجي: عولجت مشكلات البيئة بتثبيت الإصدارات والنسخ الاحتياطية دون اتصال، ومشكلات الوصف بإعادة صياغة العبارات الملتبسة، ومشكلات التحقق بإرساء خط أساس صحيح يدويًا وضبط الشروط، ومشكلات الحالة الابتدائية بإضافة فحوص الاكتمال. -τ²-تعقيد طبقات مقاعد البدلاء من خلال عملية الأعمال: بدءًا من الاستعلامات عن المعلومات البسيطة، إلى العمليات متعددة الخطوات (يتطلب تغيير حجز رحلة الطيران الاستعلام، وتقديم البدائل، والحصول على تأكيد، وحساب فرق السعر، ومعالجة الدفع)، إلى تشخيص الأخطاء (التحقق بشكل منهجي من الأسباب المحتملة المتعددة والتحقق من الإصلاحات)، وأخيرًا إلى الحكم الاستراتيجي (التعامل مع الطلبات التي لا تتوافق مع السياسة). - -تعقيد طبقات المحطة الطرفية على طول الأبعاد المزدوجة للمجال التقني × التعقيد التشغيلي. جمع سجل المهام الخاص به أكثر من 200 مهمة (يختلف حجم مجموعة التقييم الأساسية حسب الإصدار؛ على سبيل المثال، حدد الإصدار 2.0 89 مهمة عالية الجودة من مساهمات المجتمع)، بدءًا من تسجيل نموذج MLflow البسيط، إلى اختراق كلمة المرور 7-Zip متوسطة الصعوبة، إلى تكامل خادم Git وخادم الويب الصعب، إلى تحليل التشفير التفاضلي FEAL الأكثر صعوبة (يتطلب معرفة التشفير + تحسين الخوارزمية لتلبية الوقت الذي يستغرق 30 ثانية). القيد). - -### ضمان التحقق والموضوعية - -إجابات GAIA موجزة وواضحة. تسمح قواعد التنسيق الصارمة بالتحقق من خلال مطابقة السلسلة تمامًا. تضمن النتيجة الثنائية (تطابق أو عدم تطابق) إمكانية تكرار نتائج موضوعية. ندرة الإجابات أيضًا بمثابة إجراء لمكافحة الغش - فمن غير المرجح أن تظهر حقائق محددة حرفيًا في بيانات التدريب. +> **التجربة 7-2 ★: تنفيذ مهام المعايير المرجعية يدويًا** +> +> اختر مهامّ من GAIA وAndroidWorld وSWE-Bench Verified وTerminal-Bench وOSWorld-Verified وأنجزها بيدك؛ ويُستحسن إنجاز واحدة سهلة وواحدة متوسطة وواحدة صعبة من كل مجموعة. والمستوى «الصعب» يشكّل تحديًا للبشر أيضًا. +> +> وبعد الانتهاء أجب عن سؤالين. هل يحتمل وصف المهمة أكثر من تأويل معقول، وإن كان كذلك فأيّها يعترف به المدقق؟ ولو حاول أحد التملص من العمل، فما أرخص السبل إلى ذلك، وهل يستطيع المدقق صدّه؟ -يستخدم **SWE-bench Verified** عمليات فحص حتمية مبنية على الشفرات القابلة للتنفيذ، مع التمييز الدقيق بين `FAIL_TO_PASS` (الفشل قبل الإصلاح والنجاح بعده، لإثبات حل المشكلة) و`PASS_TO_PASS` (النجاح قبل الإصلاح وبعده، لإثبات عدم حدوث تراجعات في الوظائف المجاورة)، مما يحقق تحقُقًا مزدوجًا موثوقًا. كما تضمن النسخة المُتحقق منها استقرار حالات الاختبار ومنع الفحوصات المتذبذبة (Flaky Tests). +### المصادر الثلاثة لمجموعة التقييم -يتضمن نظام التحقق الخاص بـ τ²-bench طبقات متعددة من عمليات التحقق (لا تزال نتائج كل طبقة مجمعة في مكافأة ثنائية على مستوى المهمة؛ ويجب أن تنجح جميعها لتحقيق النجاح): +ثمة رأي شائع مفاده أن المعايير المرجعية العامة تخدم ترتيب النماذج وصلتها بالعمل الحقيقي ضئيلة. صحيحٌ أن درجات المعايير المرجعية العامة يصعب أن توجّه قرارات المنتج مباشرة، لكن أساليب تصميمها قابلة للنقل تمامًا. فعمق التحقق، والتوليد بالمعاملات، والوقاية من التسرب، وصيانة الجودة — وهي ما نوقش أعلاه — هي بالضبط المواضع التي يسهل إغفالها في مجموعة التقييم التي تبنيها بنفسك. -- **التحقق من حالة قاعدة البيانات**: حالة سجل الحجز، وما إذا كان قد تم إنشاء سجل استرداد الأموال -- **البحث عن الكلمات الرئيسية لمحتوى الحوار**: ما إذا كان الوكيل يؤكد صراحةً على مبلغ الاسترداد ووقت الوصول المتوقع للمستخدم -- **امتثال العملية**: تحليل تسلسل استدعاء الأداة، على سبيل المثال، ما إذا كان قد تم الحصول على تأكيد صريح من المستخدم قبل تعديل الطلب +ولمجموعة التقييم في بيئة الإنتاج ثلاثة مصادر عادةً. -تضيف بيئة التحكم المزدوج لـ τ²-bench (راجع القسم السابق "بيئة تقييم التفاعل بين الإنسان والحاسوب") بُعدًا آخر للتحقق: بعد أن يقوم محاكي المستخدم بتغيير حالة البيئة فعليًا، يجب على الوكيل ملاحظة هذا التغيير من خلال استدعاءات الأداة ومتابعة استكشاف الأخطاء وإصلاحها وفقًا لذلك. ولذلك يغطي التحقق ما إذا كان الوكيل قد لاحظ بالفعل نتائج تصرفات المستخدم. +**المعايير المرجعية العامة** تُستعمل لغربلة النماذج غربلة خشنة ولاقتباس أساليب التصميم، ولا تُستعمل عادةً لقرارات المنتج. فتوزيع مهامها لا يطابق توزيع مهام العمل الحقيقي؛ وارتفاع نقطتين مئويتين في GAIA لا تربطه علاقة حتمية بمعدل نجاح المبالغ المستردة. -يوفر OSWorld 134 وظيفة تقييم مستقلة مع إمكانية الوصول الكامل إلى نظام التشغيل، مما يتيح الفحص العميق لهياكل نظام الملفات وحالات العملية واتصالات الشبكة والأجزاء الداخلية للتطبيق. على سبيل المثال، في مهمة تشغيل قاعدة البيانات، لا يتحقق البرنامج النصي للتقييم من وجود ملف التقرير فحسب، بل يتصل أيضًا مباشرة بقاعدة البيانات للتحقق من تنفيذ SQL بشكل صحيح. في مهام المتصفح، يقوم بتحليل شجرة DOM، والتحقق من ملفات تعريف الارتباط/التخزين المحلي، ويرسل طلبات التحقق إلى الواجهة الخلفية لتأكيد ما إذا كان إرسال النموذج ساري المفعول بالفعل. يمكن لهذا الفحص العميق اكتشاف حالات "الإكمال السطحي ولكن الخطأ الجوهري" - على سبيل المثال، قام الوكيل بالنقر فوق زر الإرسال، ولكن تم رفض الطلب من قبل الخادم بسبب إدخالات الحقل غير الصحيحة. +**مجموعة العمل المبنية ذاتيًا** تغطي توزيع المهام الحقيقي، ويمكن أن تكون أساسًا لاختيار النموذج ولقرارات تصميم الـHarness. فمثلًا يمكن استعمال τ²-bench كما هو هيكلًا لأي منظومة تقييم تحتاج إلى مستخدم محاكى؛ ويكفي استبدال بيانات النطاق ومجموعة الأدوات. -يعتمد Terminal-Bench على بيئة حاوية Docker موحدة، حيث يجمع بين عمليات فحص حالة نظام الملفات (وجود المسار، وقيم الأذونات، وتنسيق المحتوى) مع التحقق الوظيفي لتنفيذ البرنامج (في build-linux-kernel-qemu، بدء تشغيل QEMU فعليًا والبحث عن رسالة printk المخصصة). يجعل المعرف الفريد العمومي الكناري التسرب قابلاً للتتبع. +**تدفق مسارات الإنتاج العائد** يأتي من إخفاقات حقيقية في الميدان: تصحيحات صريحة من المستخدم، وتقييمات سلبية منه، وحالات اكتُشفت لاحقًا عبر فحص الحالة أو مدقق قائم على القواعد أو مراجعة بنموذج لغوي. وبعد المرور بعزو الإخفاق تترسب هذه في صورة حالات انحدار. والطريقة التفصيلية موصوفة لاحقًا في قسمي «عزو الإخفاق» و«مهام الانحدار من الطرف إلى الطرف ومهام انحدار trajectory prefix». وهذا المصدر أغلاها ثمنًا وأدقها في الوقت نفسه، لأنه يأتي مباشرة مما واجهه المستخدمون فعليًا. -### التصميم المنهجي لتوزيع المهام +في المرحلة الأولى لا يتوفر عادةً إلا معايير مرجعية عامة ومجموعة عمل صغيرة مكتوبة يدويًا؛ وبعد أن يعمل النظام مدة في بيئة الإنتاج، تصير الحالات العائدة من مسارات الإنتاج هي الجسم الأكبر. -يحتاج توزيع المهام إلى تغطية أبعاد القدرة وأبعاد الصعوبة وأبعاد السيناريو وحالات الحافة بشكل منهجي. تسعى GAIA إلى تحقيق العمومية، حيث تتطلب معظم المهام مزيجًا من التفكير والوسائط المتعددة والتصفح واستخدام الأدوات. τ²-bench يصمم عمدًا "مهام فخ" - يدعي المستخدم أن "خدمة العملاء وافقت على الإلغاء" عندما لا يتوافق الإلغاء فعليًا مع السياسة - لاختبار ما إذا كان الوكيل يحتفظ بحكمه تحت الضغط والتضليل. يعتمد OSWorld على مصفوفة ثنائية الأبعاد لنوع العملية (إدخال/إخراج الملف/تطبيق سطح المكتب/تطبيق الويب/سير العمل عبر التطبيقات) ومجال التطبيق، الذي يمتد إلى ثلاثة أنظمة تشغيل (تظهر الأبحاث ارتباطًا قويًا بين أنظمة التشغيل؛ فالمهارات المكتسبة في أحد الأنظمة يمكن أن تنتقل إلى أنظمة أخرى). يتضمن Terminal-Bench "مهام مجموعة المكدس عبر التكنولوجيا" لاختبار تفكير الأنظمة (على سبيل المثال، مهمة إعادة تقسيم تجمع بين معالجة البيانات + عمليات الملفات + هندسة Python). +## طرائق التقييم الآلي -### مراقبة جودة البيانات والتحسين التكراري +للمعايير المرجعية التي نوقشت في الأقسام السابقة قاسم مشترك: مدققاتها كلها تقريبًا حتمية. فـSWE-bench يشغّل حزمة اختبارات، وAndroidWorld يؤكد الحالة النهائية للواجهة، وGAIA يجري مطابقة نصية دقيقة، وطبقات الفحص الأربع في τ²-bench تُنفَّذ كذلك بالشيفرة بالكامل. ولهذا الاختيار مسوّغات وجيهة: التحقق الحتمي لا يضيف كلفة نموذج، والنتيجة قابلة لإعادة الإنتاج تمامًا، ويمكن إدراجه في التكامل المستمر كاختبار وحدة، وييسّر الترتيب بين النماذج. -SWE-Bench Verified هو نموذج لمراقبة الجودة. تم اختيار OpenAI عشوائيًا 1,699 مهمة من أصل 2,294 مهمة للتقييم البشري، وتوظيف 93 مطورًا ماهرًا في Python. كان على المعلقين إجراء فحوصات متعددة: ما إذا كان وصف المشكلة واضحًا (هل يمكنهم فهم ما يجب حله)، وما إذا كانت حالات الاختبار كاملة (تغطي جميع الجوانب وحالات الحافة)، وما إذا كانت الاختبارات مستقرة (لا توجد اختبارات غير متقلبة بسبب البيئة أو العشوائية)، وما إذا كان التصحيح صحيحًا (هل أدخل أخطاء جديدة)، وما إذا كانت الصعوبة معقولة. وبعد إجراء فحص صارم، نجح 500 فقط (29%)، ويعتبر معدل الرفض المرتفع هذا استثمارًا ضروريًا في جودة التقييم. كما قاموا بوضع مبادئ توجيهية موحدة للتعليقات التوضيحية، مع تحديد معايير وأمثلة محددة لكل فحص لضمان الاتساق بين الشروحات المختلفة. +وثمنه أنه لا يقيّم إلا صحة النتيجة النهائية، ولا يعطي سبب الخطأ. فالمهمة التي أخفقت في τ²-bench نالت في النهاية صفرًا، وهذا الصفر لا يبيّن هل أخطأ الوكيل في مرحلة اختيار الخط أم أغفل خطوة شحن البيانات، ولا يشير البتة إلى ما ينبغي تغييره في الخطوة التالية. وهذا ليس عيبًا في معيار مرجعي عام يُستعمل للترتيب؛ أما بالنسبة إلى نظام إنتاجي يحتاج إلى تحسين مستمر فهو بالضبط أشد المعلومات لزومًا. -يقدم τ²-bench فصلًا بين "المعلومات المعروفة" / "تعليمات المهمة" (مما يجعل سلوك المحاكاة أكثر واقعية) وشروط إكمال أكثر صرامة (على سبيل المثال، "يتم احتساب الدرجة الممتازة فقط على أنها تم حلها؛ ولا يتم قبول الرديئة/المقبولة/الجيدة")، مما يمنع "الإصلاحات السطحية". +ولبيئة الإنتاج صعوبة ثانية: كثير من الأحكام لا يمكن أصلًا كتابته في صورة تأكيد تفحصه الشيفرة. فهل ردٌّ على شكوى لائق، وهل أغفل تقرير بحثي معلومة مفتاحية، وهل خلط استرجاعُ الذاكرة بين العلاقات بين الأشخاص — كل ذلك ليس له حالة نهائية وحيدة يمكن الاستعلام عنها، ولا يمكن حسمه بمطابقة الكلمات المفتاحية. -OSWorld-Verified هو نموذج للتحسين التكراري. بعد إصداره في أبريل 2024، أصبح OSWorld سريعًا معيارًا مهمًا لتقييم الوكيل متعدد الوسائط، ولكن على مدار 15 شهرًا من الاستخدام واسع النطاق، تم الكشف عن أكثر من 300 مشكلة. تنقسم هذه المشكلات إلى أربع فئات: مشكلات البيئة (تدابير مكافحة التجريد على مواقع الويب، واختبارات CAPTCHA، وتغييرات المحتوى الديناميكي)، ومشكلات وصف المهمة (الصياغة الغامضة)، ومشكلات منطق التحقق (صارمة للغاية أو متساهلة للغاية)، ومشكلات الحالة الأولية (تكوين غير مكتمل). عمل فريق مكون من حوالي 10 أشخاص من جامعة هونغ كونغ بشكل وثيق مع MoonShot AI وOpenAI وByteDance Seed TARS وAnthropic وSimular وغيرهم لمدة شهرين لإصلاح هذه المشكلات بشكل منهجي. تمت صياغة استراتيجيات الإصلاح لكل فئة: تم حل مشكلات البيئة عن طريق قفل الإصدارات والنسخ الاحتياطية غير المتصلة بالإنترنت، وتم توضيح أوصاف المهام عن طريق إعادة كتابة الصياغة الغامضة، وتمت موازنة منطق التحقق من خلال إنشاء خطوط أساس صحيحة يدويًا وضبط الشروط، وتم تعزيز الحالات الأولية عن طريق إضافة عمليات التحقق من الاكتمال. +ولذلك، عند الانتقال من المعايير المرجعية العامة إلى التقييم في بيئة الإنتاج، ينبغي إزاحة أسلوب التحقق نحو اليمين على طيف محوره الأفقي **درجة قابلية المهمة للتحقق آليًا**، كما يوضح الشكل 7-4. -## طرق التقييم الآلي +![الشكل 7-4: طيف أساليب التحقق — من التحقق الحتمي إلى حكم النموذج](images/fig7-4.svg) -مع وجود بيئة التقييم ومجموعة البيانات ونظام المقاييس الواضح، يصبح السؤال الأساسي: كيف نسجل؟ بالنسبة للمهام ذات الإجابات الصحيحة الواضحة (على سبيل المثال، المسائل الرياضية واستعلامات SQL)، يكفي الحكم الثنائي البسيط (صحيح/غير صحيح)؛ ولكن بالنسبة للمهام ذات النهايات المفتوحة (على سبيل المثال، حوارات خدمة العملاء، وكتابة التقارير)، هناك حاجة إلى أساليب تقييم أكثر دقة. +وهكذا تصير الأداتان الواقعتان في يمين الطيف عماد التقييم الإنتاجي: **Rubric** يفكك سؤال «جيد أم لا» المبهم إلى عدة أبعاد يمكن تقييم كل منها على حدة، و**LLM-as-a-Judge** يتولى التقييم حيث لا يوجد معيار حتمي. ولا يمكن ردّ معدل إخفاق مبهم إلى مشكلات محددة يمكن الشروع في إصلاحها إلا باجتماع الاثنين؛ وبإضافة **عزو الإخفاق** في النصف الثاني من هذا القسم تتشكل الحلقة المغلقة الكاملة لتقييم الوكلاء الإنتاجيين. -لا يغطي التحقق التلقائي المستند إلى الكود سوى السيناريوهات ذات الإجابات القياسية؛ إن تسجيل المهام ذات النهايات المفتوحة هو الموضوع الرئيسي لهذا القسم. ومن بين هذه الأمور، يتم ترك تصميم كثافة إشارة المكافأة (من المكافآت الثنائية إلى مكافآت المعالجة إلى المكافآت التوليدية) وطرق التدريب لنماذج المكافآت للمناقشة المنهجية في قسم ما بعد التدريب في الفصل 8؛ يجيب هذا القسم على سؤال أكثر جوهرية: كيفية استخدام نماذج LLM للحكم تلقائيًا على جودة مخرجات المهام المفتوحة. +ولا بد من التنويه: الإزاحة نحو اليمين لا تعني التخلي عن اليسار. فكل فحص يمكن كتابته تأكيدًا برمجيًا ينبغي أن يبقى تأكيدًا، ولا يُستعمل حكم النموذج اللغوي إلا في الأبعاد التي يتعذر حسمها آليًا حقًا. فالفحوص الحتمية أرخص وأثبت، وهي أنسب كذلك للتشغيل الطويل الأمد بوصفها اختبارات انحدار. ### النموذج اللغوي بوصفه قاضيًا: جوهر التقييم الآلي -![الشكل 7-4: LLM خط أنابيب القاضي](images/fig7-4.svg) +![الشكل 7-5: LLM خط أنابيب القاضي](images/fig7-5.svg) لماذا هناك حاجة إلى LLM كقاضي؟ بالنسبة للمهام المفتوحة (على سبيل المثال، إنشاء التقارير، والتعامل مع شكاوى العملاء، والمحتوى الإبداعي)، لا توجد إجابات قياسية للمقارنة التلقائية، ويكون التقييم البشري مكلفًا ويصعب قياسه. تعمل LLM-as-a-Judge على موازنة قابلية التوسع في الأتمتة مع حكم الخبراء البشريين من خلال وجود نموذج لغة يقيم المخرجات مقابل معايير التسجيل المحددة بواسطة الخبراء (قاعدة تقييم). ومع ذلك، فإن الطريقة لها حدود معروفة: يحمل نموذج القاضي تحيزاته الخاصة (في أغلب الأحيان **تحيز الطول** - وهو الميل إلى تسجيل إجابات أطول وأكثر تفصيلاً أعلى حتى عندما لا تكون أكثر صحة)، ويمكن أن تختلف الأحكام المتكررة لنفس المدخلات. ويتطلب التحيز في الطول على وجه الخصوص اتخاذ تدابير مضادة محددة. ثلاثة دفاعات شائعة هي: معاقبة الإسهاب بشكل صريح في نموذج التقييم والحد الأقصى لطول الاستجابة لكل نوع مهمة؛ في المقارنات الزوجية، اجعل المرشحين متساويين في الطول قبل الحكم؛ ومراجعة العلاقة بين الدرجات وطول الاستجابة بانتظام - إذا كانت الدرجات العالية تذهب دائمًا تقريبًا إلى الإجابات الطويلة، فقد تأثر القاضي بالطول ويحتاج نموذج التقييم إلى المراجعة. ولمواجهة هذه التحديات بشكل منهجي، يجب أن يتبع تصميم القاعدة المبادئ التالية: @@ -534,7 +534,7 @@ name = "status" ### المقارنة الزوجية وتصنيف النماذج -![الشكل 7-5: تصنيف Elo وتصنيف المقارنة الزوجية](images/fig7-5.svg) +![الشكل 7-6: تصنيف Elo وتصنيف المقارنة الزوجية](images/fig7-6.svg) **تصنيف إيلو (Elo Rating)** (المستند في أصله الإحصائي إلى **نموذج برادلي-تيري Bradley-Terry**) يقيس القدرة النسبية للنماذج من خلال عدد كبير من المقارنات الزوجية: كلما زاد فارق النقاط بين نموذجيم، ارتفع معدل الفوز المتوقع للنموذج الأقوى. على سبيل المثال، إذا كان للنموذج أ تصنيف 1200 وللنموذج ب تصنيف 1000، يتوقع نظام Elo أن يبلغ معدل فوز (أ) حوالي 76%. وإذا حقق (ب) فوزًا غير متوقع، يكتسب المزيد من النقاط، مما يسمح للتصنيفات بالتقارب السريع نحو القدرة الحقيقية. @@ -698,7 +698,7 @@ return paired_bootstrap_or_mcnemar(all_deltas) تعتمد القرارات المبنية على التقييم (سواء المتعلقة باختيار النموذج أو التكرار المستمر) على بيانات تشغيلية عالية الجودة. أدناه، نقدم أولاً كيفية جمع هذه البيانات بشكل منهجي (قابلية الملاحظة)، ثم نناقش كيفية ترجمة نتائج التقييم إلى تحسينات في النظام. -![الشكل 7-6: حزمة تكنولوجيا إمكانية الملاحظة](images/fig7-6.svg) +![الشكل 7-7: حزمة تكنولوجيا إمكانية الملاحظة](images/fig7-7.svg) إن إمكانية الملاحظة هي مفهوم مستعار من الأنظمة الموزعة: لا يمكنك فتح النظام ومشاهدته وهو يعمل؛ أنت تستنتج ما يحدث من السجلات والمقاييس والآثار التي يصدرها - الطريقة التي يقوم بها الطبيب، غير القادر على الرؤية داخل المريض، بالتشخيص من درجة الحرارة وضغط الدم والتصوير. تجعل أنظمة الوكلاء هذا الأمر أكثر صعوبة: نفس المدخلات يمكن أن تنتج مخرجات مختلفة، والاستدلال متعدد الجولات واستدعاءات الأدوات يجعل مسارات التنفيذ معقدة للغاية، و"تفكير" النموذج مبهم تمامًا من الخارج. @@ -718,7 +718,7 @@ return paired_bootstrap_or_mcnemar(all_deltas) الحالة الآتية مأخوذة من جولة AndroidWorld حقيقية ومحدودة عمدًا في المستودع المصاحب. وتشمل أربع مهام لإعداد Wi-Fi على محاكي API 35، مع تشغيل مقترن واحد لكل مهمة. وهي ليست المعيار الكامل ذي 116 مهمة، ولا تغني عن إعادة التشغيل في بيئة API 33 المرجعية. قيمتها ليست في درجة عامة، بل في تسلسل القرارات من نتيجة إلى التي تليها. -![الشكل 7-7: المعيار لحلقة التحسين](images/fig7-7.svg) +![الشكل 7-8: المعيار لحلقة التحسين](images/fig7-8.svg) من منظور هندسة منظومة التشغيل، يعرض هذا القسم منهجًا تكراريًا لتحسين المنظومة: نستخدم بيانات التقييم لتحديد مواضع الضعف—هل السياق ناقص؟ هل تغيب بعض القيود؟ هل التحقق غير كافٍ؟ هل تصل التغذية الراجعة في وقت غير مناسب؟—ثم نجري تحسينات محددة ونعيد التقييم، فتتشكل حلقة مغلقة للتطور المستمر. @@ -827,7 +827,7 @@ return paired_bootstrap_or_mcnemar(all_deltas) وهنا كيفية التقاء طرفي الجسر. تتحول الأصول المتراكمة في جانب التقييم بسلاسة تقريبًا إلى إشارات تدريب: يعتبر عنوان التقييم أو أداة التحقق المحددة جيدًا في الأساس وظيفة مكافأة لـ **التعلم المعزز بمكافآت يمكن التحقق منها (RLVR)** - يصبح نص التسجيل هو نص المكافأة؛ ما إذا كان الاختبار ناجحًا أو أن الحالة تستوفي المعيار بمثابة معيار تقييم وكمكافأة تعليمية معززة. لكن التدريب يجلب متطلبات التقييم التي لم يكن هناك ما يدعو للقلق أبدًا. الأول هو **دلالات إعادة التعيين الموثوقة**: يمتد التدريب ملايين الحلقات (الحلقة عبارة عن جولة تفاعل كاملة من الحالة الأولية إلى إكمال المهمة)، ويجب أن تكون كل حلقة قادرة على إعادة ضبط البيئة إلى حالة أولية حتمية ونظيفة؛ وإلا، فإن إشارة التدرج سوف تكون ملوثة بالحالات المتبقية من الحلقة السابقة. والثاني هو **الإنتاجية التي تتجاوز التقييم بكثير**: بضعة آلاف من التقييمات تكفي لاستخلاص النتائج، لكن التدريب يتطلب تغذية النموذج بملايين التفاعلات خلال فترة زمنية مقبولة على مدار الساعة؛ تحدد درجة التوازي البيئي والنفقات العامة لكل مثيل بشكل مباشر ما إذا كان التدريب ممكنًا أم لا. سيتم تفصيل هاتين النقطتين - تحويل أدوات التحقق إلى وظائف مكافأة، وإعادة ضبط درجة التدريب والإنتاجية - في الفصل الثامن. -![الشكل 7-8: طيف دقة المحاكاة](images/fig7-8.svg) +![الشكل 7-9: طيف دقة المحاكاة](images/fig7-9.svg) على جانب **البيئة الرقمية**، يبني إطار عمل AWorld صندوق حماية خادم MCP يمكن التحكم فيه لمهام GAIA، مما يوفر 26 خادم MCP تغطي 126 وظيفة للأداة، مع تجنب الحظر والآثار الجانبية التي لا يمكن السيطرة عليها للوصول مباشرة إلى واجهات برمجة التطبيقات الحقيقية. جميع استدعاءات الأداة قابلة لإعادة التشغيل والتدقيق. تعمل بنية AWorld الموزعة على تقليل وقت التنفيذ التسلسلي التقليدي من 7695 ثانية إلى 525 ثانية (تسريع بمعدل 14.6x)، كما أن التصميم عديم الحالة للبيئة يجعل كل مثيل مستقلاً تمامًا، ويدعم التوازي الفعال. @@ -838,7 +838,7 @@ return paired_bootstrap_or_mcnemar(all_deltas) > قم بإعداد بيئة محاكاة للتلاعب بالروبوت. اقرأ `ch7/SimpleVLA-RL` ووثائق OpenVLA لفهم بنية نموذج Vision-Language-Action (التكامل الشامل لمشفر الرؤية، ونموذج اللغة، ووحدة فك ترميز الإجراء، وإسقاط الصور والنص في مساحة دلالية مشتركة). قم بتكوين بيئة RoboTwin2، وفهم مساحة المراقبة (ثلاثية الرؤية RGB + حالة مشتركة ذات 14 بُعدًا) ومساحة العمل (ناقل التحكم ذو 14 بُعدًا). دراسة آلية التوزيع العشوائي للبيئة ومنطق القيد المكاني في `move_can_pot`. قم بتقييم النموذج المُدرب مسبقًا، وتسجيل معدل نجاحه، ووقت الانتهاء، وأوضاع الفشل، مع التركيز على تأثير آلية تقطيع الإجراء. > > -> ![الشكل 7-9: بيئة الذكاء المتجسد OpenVLA وRoboTwin2](images/fig7-9.svg) +> ![الشكل 7-10: بيئة الذكاء المتجسد OpenVLA وRoboTwin2](images/fig7-10.svg) > > @@ -850,7 +850,7 @@ return paired_bootstrap_or_mcnemar(all_deltas) ## ملخص الفصل -دار هذا الفصل حول سؤال واحد: كيف نعرف أن الوكيل تحسن بالفعل؟ من بيئة اختبار قابلة للتكرار ومجموعة بيانات تقاوم التسرب، إلى محكّمي LLM واختيار النموذج والتكرار القائمين على التقييم، تؤثر كل حلقة في موثوقية الخلاصة. وأضافت التجارب المقاسة أربع ملاحظات عملية: الجمع بين الذاكرة المنظمة وRAG لا يضمن التآزر؛ لا يمكن جمع وفورات التخزين المؤقت والضغط؛ اختيار الصوت المرجعي يغيّر معنى الدرجة متعددة الوسائط؛ وتمثيل المدخلات في منظومة التشغيل قد يحدد النجاح وكلفة الرموز معًا. كما ينبغي مقارنة منحنيات القدرة عبر ميزانيات متعددة، لا نقطة واحدة. وفي الإنتاج، التقييم تحقق مستمر داخل كل قرار منتج، لا اختبار عابر. +دار هذا الفصل حول سؤال واحد: كيف نعرف أن الوكيل تحسن بالفعل؟ وتتألف هذه السلسلة من أربع حلقات: أولًا تحرير ما يُعد نجاحًا (اختلاف أسس Pass@k وBest@k وPass consecutive@k)، ثم تحديد مصدر المهام (المعايير المرجعية العامة، ومجموعة العمل المبنية ذاتيًا، وعودة مسارات الإنتاج)، ثم اختيار أسلوب التحقق (من المدققات الحتمية إلى قوائم الفحص، فـRubric مع حكم النموذج اللغوي، وصولًا إلى المقارنة الزوجية)، وأخيرًا تحويل الدرجات إلى قرارات (الدلالة الإحصائية، وعزو الإخفاق، ومهام الانحدار، واختيار النموذج). ومن بيئة اختبار قابلة للتكرار ومجموعة بيانات تقاوم التسرب، إلى محكّمي LLM واختيار النموذج والتكرار القائمين على التقييم، تؤثر كل حلقة في موثوقية الخلاصة. وأضافت التجارب المقاسة أربع ملاحظات عملية: الجمع بين الذاكرة المنظمة وRAG لا يضمن التآزر؛ لا يمكن جمع وفورات التخزين المؤقت والضغط؛ اختيار الصوت المرجعي يغيّر معنى الدرجة متعددة الوسائط؛ وتمثيل المدخلات في منظومة التشغيل قد يحدد النجاح وكلفة الرموز معًا. كما ينبغي مقارنة منحنيات القدرة عبر ميزانيات متعددة، لا نقطة واحدة. وفي الإنتاج، التقييم تحقق مستمر داخل كل قرار منتج، لا اختبار عابر. من جهة بنية الكتاب ككلّ، يبني هذا الفصل قطعة **الدليل** من حلقة الاكتشاف في الفصل الأول: فعزو الإخفاق هو ما يحدّد هل للاقتراحات اللاحقة سند تستند إليه. diff --git a/book-ar/images/fig7-1.svg b/book-ar/images/fig7-1.svg index ea78f5c13..4ec144543 100644 --- a/book-ar/images/fig7-1.svg +++ b/book-ar/images/fig7-1.svg @@ -1,19 +1,66 @@ - - - -الطبقة الأولى: تقييم البيئة -"مكان الاختبار" - استدعاء الأدوات / التفاعل بين الإنسان والحاسوب / بيئة المحاكاة - - -الطبقة الثانية: طرق التقييم -"كيفية الحكم" - تصميم مجموعة البيانات · LLM-as-a-Judge · المقارنة والتصنيف الزوجي - - -الطبقة الثالثة: القرارات المبنية على التقييم -"ما يجب فعله بعد الاختبار" — اختيار النموذج · تحسين البنية · التكرار المستمر - -المواضيع الهندسية في جميع أنحاء الفصل -• إمكانية الملاحظة -• بيئة المحاكاة -• التقييم الداخلي + + + + + + + + +① تعريف النجاح +Pass@k يقيس سقف القدرة · Pass^k يقيس الموثوقية + + + +② مصدر المهام + +معايير مرجعية عامة +اقتباس الأساليب · غربلة خشنة + +مجموعة عمل ذاتية +توزيع المهام الحقيقي + +عودة مسارات الإنتاج +ناتج عزو الإخفاق + + + +③ أسلوب التحقق +← بحسب درجة قابلية المهمة للتحقق آليًا → + +مدقق حتمي +SWE-bench + + +قائمة فحوص +τ²-bench + + +Rubric + حكم نموذج +مهام مفتوحة + + +مقارنة زوجية +Chatbot Arena + + + +④ توظيف النتائج +الدلالة الإحصائية ← عزو الإخفاق ← مهام الانحدار ← اختيار النموذج وتكرار الـHarness + + +مهام الانحدار تصير حالات جديدة + + +البنية الداعمة +قابلية الرصد · بنية التقييم الداخلي (الاستئصال / AB / مفاتيح الميزات) · بيئة المحاكاة (الفصل الثامن) diff --git a/book-ar/images/fig7-10.svg b/book-ar/images/fig7-10.svg new file mode 100644 index 000000000..624c6b7e9 --- /dev/null +++ b/book-ar/images/fig7-10.svg @@ -0,0 +1,69 @@ + + + + +المراقبة المتعددة الوسائط + +كاميرا الرأس +224×224 رغب + +كاميرا المعصم الأيسر +224×224 رغب + +كاميرا المعصم الأيمن +224×224 رغب + +ناقل الحالة المشتركة ذو 14 بعدًا + +نموذج الرؤية واللغة والعمل (VLA) + +تشفير الرؤية +SigLIP → الرموز المرئية + + +نموذج اللغة +اللاما 2 7B العمود الفقري + + +فك تشفير العمل +→ ناقل التحكم المستمر ذو 14 بُعدًا +تقسيم الإجراء: قم بإنشاء 25 إجراءً متتاليًا في وقت واحد + + + +التعليمات: "ضع العلبة في الوعاء" + + +محرك الفيزياء سابين + +روبوت ثنائي الذراع +7 DOF لكل منها = حركة ذات 14 بُعدًا + +العشوائية البيئية +الموضع 60 سم / الاتجاه ±22.5 درجة + +كشف الاصطدام + محاكاة الفيزياء +جسم صلب / جسم ناعم / احتكاك + +العمل + +الملاحظة + +مقاييس التقييم + +معدل النجاح +يمكن داخل وعاء +ولم يسقط + +وقت الانتهاء +25 خطوة × 25 إجراء += 625 خطوة تحكم + +القدرة على التعميم +الموقف المتقاطع/الاتجاه +/ متغير المظهر + +سيم إلى ريال +العشوائية المجال +→ الهجرة الحقيقية + \ No newline at end of file diff --git a/book-ar/images/fig7-3.svg b/book-ar/images/fig7-3.svg index 5801a40c9..712548569 100644 --- a/book-ar/images/fig7-3.svg +++ b/book-ar/images/fig7-3.svg @@ -1,68 +1,80 @@ - - + + + + + + + \ No newline at end of file +.t,.l{direction:rtl;unicode-bidi:plaintext;font-family:'Noto Sans Arabic','Noto Sans',Arial,sans-serif} +.c{font-family:'SF Mono',Menlo,Consolas,monospace;direction:ltr;unicode-bidi:plaintext} + + + + + +محاكي المستخدم (LLM) +known_info: John Smith / 555-123-2002 / في فرنسا +task_instructions: كشف تدريجي · انفعال · ترسيخ +القبول: excellent وحدها تُعد حلًّا + + + +الوكيل (قيد التقييم) +المدخل: تذكرة + سياسة النطاق +غير مرئي: الحالة الحقيقية للجهاز +يوجّه فقط ولا ينفّذ نيابةً عنه + + + +حوار متعدد الأدوار +كشف تدريجي للمعلومات + + + +بيئة مشتركة (تحكم مزدوج: الطرفان يغيّران الحالة) + +حالة جانب الجهاز +وضع الطيران ON · التجوال OFF · توفير البيانات · الرصيد +أدوات المستخدم: toggle_airplane_mode / toggle_roaming + check_status_bar / run_speed_test + +قاعدة بيانات المشغّل +العميل C1001 · الخطوط L1001/L1002/L1003 · الباقات · الفواتير +أدوات الوكيل: get_customer_by_phone / get_data_usage + enable_roaming / refuel_data + + + + + + +استدعاء toggle_roaming من المستخدم غيّر البيئة؛ على الوكيل استدعاء الأداة من جديد — والتحقق يغطي هذه القراءة + + + +بعد المهمة: أربع طبقات فحص + قاعدة تجميع + +env_assertions +بيانات الجوّال متاحة +السرعة ≥ 200 / excellent + +actions +toggle_airplane_mode +يجب أن يكون requestor هو user + +communicate_info +هل أُبلغت المعلومات اللازمة +null في هذه المهمة + +nl_assertions +حكم على مستوى اللغة الطبيعية +null في هذه المهمة +reward_basis = ["ENV_ASSERTION"] ← الطبقة الأولى وحدها معتمدة؛ والباقي يُسجَّل ولا يدخل المكافأة + diff --git a/book-ar/images/fig7-4.svg b/book-ar/images/fig7-4.svg index 4f55fbef8..1ba7e0122 100644 --- a/book-ar/images/fig7-4.svg +++ b/book-ar/images/fig7-4.svg @@ -1,53 +1,58 @@ - - - - -عنوان التقييم - -صحة الوقائع: ضروري -التماسك المنطقي: مهم -كشف الهلوسة : الفيتو ⚠ -الاكتمال: مهم - -إجابة المرشح - -مخرجات الوكيل: -"تمت معالجة عملية استرداد الأموال، وسيتم إضافة 150 دولارًا أمريكيًا إلى داخل الحساب - 3-5 أيام عمل." - - -الحل المرجعي (اختياري) - -الإجابة القياسية / نقاط التسجيل: -يجب أن يتضمن المبلغ المسترد -يجب أن تشمل وقت الائتمان -لا يمكن الوعد بتاريخ محدد - - - - -نموذج القاضي (GPT-5 / Gemini 2.5) -تقييم غير متجانس متعدد المصادر لمنع التحيز لنفس المصدر - - -مخرجات التقييم المنظم - -الصواب الواقعي -4/4 -المبلغ والوقت كلاهما دقيق -الاكتمال -3/4 -شرح مفقود لطريقة استرداد الأموال -كشف الهلوسة -تمرير -لا توجد معلومات خاطئة -التماسك المنطقي -4/4 -علاقة سببية واضحة - -استراتيجية تجميع النقاط -المتوسط المرجح: Σ(الوزن × درجة البعد) -الفيتو: الهلوسة = الفشل → مجموع النقاط = 0 -متعدد القضاة: متوسط 3 قضاة -علامة حالة الحافة: الخلاف > نقطتان → مراجعة بشرية - \ No newline at end of file + + + + + + + + +قابلية المهمة للتحقق آليًا: عالية +منخفضة + + +مدقق حتمي +حالة نهائية وحيدة قابلة للاستعلام +ناجح / راسب +SWE-bench يشغّل الاختبارات + + + +قائمة فحوص +عدة فحوص حتمية +يُجمَّع وفق الأساس المعلن +طبقات τ²-bench الأربع + + + +Rubric + حكم نموذج +أبعاد موجودة لا يحسمها كود +درجات لكل بُعد مع التعليل +جودة الخدمة، كتابة التقارير + + + +مقارنة زوجية +حتى الأبعاد يصعب صوغها +يحكم بين A وB فقط +Chatbot Arena + + +تحقق حتمي +قابل لإعادة الإنتاج، يناسب CI، منخفض الكلفة +الثمن: يحكم بالصواب لا بموضع الخلل + + +حكم النموذج +يعطي أبعادًا تشخيصية ويغطي ما لا يُصاغ تأكيدًا +الثمن: تحيّز وتذبذب في الحكم، وكلفة أعلى + diff --git a/book-ar/images/fig7-5.svg b/book-ar/images/fig7-5.svg index 4762fa293..4f55fbef8 100644 --- a/book-ar/images/fig7-5.svg +++ b/book-ar/images/fig7-5.svg @@ -1,56 +1,53 @@ - + - -معركة Chatbot Arena المجهولة - -النموذج أ (مجهول) - -"تم معالجة عملية استرداد الأموال، وسوف تصل خلال 3-5 - أيام العمل لحسابك" -مقابل - -النموذج ب (مجهول) - -"حسنًا، ستتم معالجة عملية استرداد الأموال" - - -اختيار المستخدم الأعمى → A أفضل - -صيغة تحديث Elo -معدل الفوز المتوقع E_A = 1/(1+10^((R_B-R_A)/400)) | تحديث: R_A' = R_A + K*(1-E_A) -لوحة المتصدرين المباشرة (مثال) -رتبة -النموذج -إيلو -معدل الفوز مقابل رقم 2 - -1 -Claude 4 أوبوس -1352 -— -2 -GPT-5 -1318 -— -3 -Gemini 2.5 برو -1290 -45% -4 -DeepSeek R2 -1265 -42% -5 -Qwen 3 ماكس -1230 -39% -6 -اللاما 4 405 ب -1198 -36% - - -GRPO: تقديم المقارنة الزوجية في تدريب RL -مجموعة من استجابات المرشحين ← تطبيع الميزة النسبية ← تحديث السياسة (تجاوز نموذج المكافأة الصريح) + +عنوان التقييم + +صحة الوقائع: ضروري +التماسك المنطقي: مهم +كشف الهلوسة : الفيتو ⚠ +الاكتمال: مهم + +إجابة المرشح + +مخرجات الوكيل: +"تمت معالجة عملية استرداد الأموال، وسيتم إضافة 150 دولارًا أمريكيًا إلى داخل الحساب + 3-5 أيام عمل." + + +الحل المرجعي (اختياري) + +الإجابة القياسية / نقاط التسجيل: +يجب أن يتضمن المبلغ المسترد +يجب أن تشمل وقت الائتمان +لا يمكن الوعد بتاريخ محدد + + + + +نموذج القاضي (GPT-5 / Gemini 2.5) +تقييم غير متجانس متعدد المصادر لمنع التحيز لنفس المصدر + + +مخرجات التقييم المنظم + +الصواب الواقعي +4/4 +المبلغ والوقت كلاهما دقيق +الاكتمال +3/4 +شرح مفقود لطريقة استرداد الأموال +كشف الهلوسة +تمرير +لا توجد معلومات خاطئة +التماسك المنطقي +4/4 +علاقة سببية واضحة + +استراتيجية تجميع النقاط +المتوسط المرجح: Σ(الوزن × درجة البعد) +الفيتو: الهلوسة = الفشل → مجموع النقاط = 0 +متعدد القضاة: متوسط 3 قضاة +علامة حالة الحافة: الخلاف > نقطتان → مراجعة بشرية \ No newline at end of file diff --git a/book-ar/images/fig7-6.svg b/book-ar/images/fig7-6.svg index cff2a2488..4762fa293 100644 --- a/book-ar/images/fig7-6.svg +++ b/book-ar/images/fig7-6.svg @@ -1,48 +1,56 @@ - + - -شجرة تتبع التنفيذ (مهمة واحدة) - -التتبع: التحقق من طقس بكين للمستخدم غدًا (3.2 ثانية، 0.008 دولار) - -استدعاء LLM: التعرف على النوايا -Claude 4 سونيت · 0.4 ثانية · 320 رمزًا - -الأداة: get_weather(بكين) -خادم MCP · 1.8 ثانية · 200 مللي ثانية TTFT - -├─ طلب HTTP -api.weather.com · 1.6 ثانية - -└─ تحليل الاستجابة -JSON → بيانات الطقس المنظمة - -استدعاء LLM: إنشاء استجابة -Claude 4 سونيت · 0.8 ثانية · 580 رمزًا - -الأداة: send_message (المستخدم) -0.2 ثانية · يحتوي على ملخص الطقس - - - - - - - -لوحة المراقبة - -تتبع التكلفة -اليوم: 12.30 دولارًا (1200 مكالمة) -هذا الشهر: 340 دولارًا (34 ألف مكالمة) -حالة شاذة: تم تكرار البحث في المهمة رقم 892 14 مرة، بتكلفة 2.1 دولار - -مراقبة الأداء -الكمون P50 / P95 / P99: 2.1 ثانية / 8.4 ثانية / 15.2 ثانية -معدل نجاح الأداة: 94.3% - -تدقيق الجودة -معدل نجاح المهمة: 87% محفز الهلوسة: 2.1% -الانتهاكات الأمنية: 0 (هذا الشهر) رضا المستخدم: 4.3/5 - -حلقة مغلقة: تتبع البيانات ← تحديد المشكلات ← اختبار A/B ← إدارة إصدارات الموجّهات ← التحسين المستمر + + +معركة Chatbot Arena المجهولة + +النموذج أ (مجهول) + +"تم معالجة عملية استرداد الأموال، وسوف تصل خلال 3-5 + أيام العمل لحسابك" +مقابل + +النموذج ب (مجهول) + +"حسنًا، ستتم معالجة عملية استرداد الأموال" + + +اختيار المستخدم الأعمى → A أفضل + +صيغة تحديث Elo +معدل الفوز المتوقع E_A = 1/(1+10^((R_B-R_A)/400)) | تحديث: R_A' = R_A + K*(1-E_A) +لوحة المتصدرين المباشرة (مثال) +رتبة +النموذج +إيلو +معدل الفوز مقابل رقم 2 + +1 +Claude 4 أوبوس +1352 +— +2 +GPT-5 +1318 +— +3 +Gemini 2.5 برو +1290 +45% +4 +DeepSeek R2 +1265 +42% +5 +Qwen 3 ماكس +1230 +39% +6 +اللاما 4 405 ب +1198 +36% + + +GRPO: تقديم المقارنة الزوجية في تدريب RL +مجموعة من استجابات المرشحين ← تطبيع الميزة النسبية ← تحديث السياسة (تجاوز نموذج المكافأة الصريح) \ No newline at end of file diff --git a/book-ar/images/fig7-7.svg b/book-ar/images/fig7-7.svg index add109273..cff2a2488 100644 --- a/book-ar/images/fig7-7.svg +++ b/book-ar/images/fig7-7.svg @@ -1,56 +1,48 @@ - + - - -① الملاحظة: التقرير التشخيصي -معدل النجاح الإجمالي: 88% (102/116) -النسخ: 0% complex_ui: 17% -math_counting: 0% تشغيل Wi-Fi: 0% -المهمة 82،102-115 حالات الفشل المركزة - -② الفرضية: إطار التحسين ثلاثي الطبقات - -الطبقة السطحية -H1 قم بتعيين قواعد واجهة المستخدم لموجّه التنقل H2 - -الطبقة الوسطى -H3 إصلاح خط الأنابيب متعدد الوسائط H4 التفكير - -طبقة عميقة -H5 GPT-5 H6 شجرة عناصر واجهة المستخدم - - -③ التجربة: التحقق المرحلي (5 عمليات تشغيل × 116 مهمة لكل تكوين) - -الملاحة H1 -الإعداد 0% → 75% -الرمز المميز+8% - -H3 متعدد الوسائط -النسخ 0% → 80% -زمن الاستجابة +1 - -التفكير H4 -العد 0% → 70% -الكمون 3x! - -شجرة العنصر H6 -واجهة المستخدم 17% → 52% -رمز مميز+30% - -④ القرار: المفاضلة بين التكلفة والمنفعة -✓ H1+H3: تكلفة منخفضة، فائدة عالية → النشر -✗ H4: 8% فقط من المهام تستفيد ولكن 3x الكمون → الرفض -✓ H6: تحسين بنسبة 35% / تكلفة بنسبة 30% ← النشر -✗ H5: 15 ثانية/خطوة غير مقبولة → بديل - -⑤ التكرار: دورة جديدة -نشر H1+H3+H6 → 88% → 94% -تقرير جديد يوضح أوضاع الفشل المختلفة: - H7: تمكين التفكير المشروط - H8: قم بتوسيع مساحة عمل الإيماءات - -↑ حلقة - -المنهجية: لاحظ ← افترض ← جرب ← قرر ← كرر = من الكيمياء إلى الهندسة العلمية + +شجرة تتبع التنفيذ (مهمة واحدة) + +التتبع: التحقق من طقس بكين للمستخدم غدًا (3.2 ثانية، 0.008 دولار) + +استدعاء LLM: التعرف على النوايا +Claude 4 سونيت · 0.4 ثانية · 320 رمزًا + +الأداة: get_weather(بكين) +خادم MCP · 1.8 ثانية · 200 مللي ثانية TTFT + +├─ طلب HTTP +api.weather.com · 1.6 ثانية + +└─ تحليل الاستجابة +JSON → بيانات الطقس المنظمة + +استدعاء LLM: إنشاء استجابة +Claude 4 سونيت · 0.8 ثانية · 580 رمزًا + +الأداة: send_message (المستخدم) +0.2 ثانية · يحتوي على ملخص الطقس + + + + + + + +لوحة المراقبة + +تتبع التكلفة +اليوم: 12.30 دولارًا (1200 مكالمة) +هذا الشهر: 340 دولارًا (34 ألف مكالمة) +حالة شاذة: تم تكرار البحث في المهمة رقم 892 14 مرة، بتكلفة 2.1 دولار + +مراقبة الأداء +الكمون P50 / P95 / P99: 2.1 ثانية / 8.4 ثانية / 15.2 ثانية +معدل نجاح الأداة: 94.3% + +تدقيق الجودة +معدل نجاح المهمة: 87% محفز الهلوسة: 2.1% +الانتهاكات الأمنية: 0 (هذا الشهر) رضا المستخدم: 4.3/5 + +حلقة مغلقة: تتبع البيانات ← تحديد المشكلات ← اختبار A/B ← إدارة إصدارات الموجّهات ← التحسين المستمر \ No newline at end of file diff --git a/book-ar/images/fig7-8.svg b/book-ar/images/fig7-8.svg index b6b0e2027..add109273 100644 --- a/book-ar/images/fig7-8.svg +++ b/book-ar/images/fig7-8.svg @@ -1,41 +1,56 @@ - + - - -محاكاة الإخلاص → -قابلية التوسع - - - -↑ - -وهمية API -مستوى اختبار الوحدة -مليون مرة/ساعة - -عالم -صندوق الرمل MCP -126 وظيفة للأداة -525 ثانية / جولة موزعة - -androidworld -محاكي -116 مهمة تطبيقية في العالم الحقيقي -واجهة المستخدم التلقائية - -إسحاق جيم -التوازي GPU -الآلاف من الحالات الموازية -دقة للخطر قليلا - -RoboTwin2 -محرك الفيزياء -تصادم عالي الدقة -وحدة المعالجة المركزية ذات المثيل الواحد - -العالم الحقيقي -الإخلاص التام -غير قابل لإعادة الضبط - + +① الملاحظة: التقرير التشخيصي +معدل النجاح الإجمالي: 88% (102/116) +النسخ: 0% complex_ui: 17% +math_counting: 0% تشغيل Wi-Fi: 0% +المهمة 82،102-115 حالات الفشل المركزة + +② الفرضية: إطار التحسين ثلاثي الطبقات + +الطبقة السطحية +H1 قم بتعيين قواعد واجهة المستخدم لموجّه التنقل H2 + +الطبقة الوسطى +H3 إصلاح خط الأنابيب متعدد الوسائط H4 التفكير + +طبقة عميقة +H5 GPT-5 H6 شجرة عناصر واجهة المستخدم + + +③ التجربة: التحقق المرحلي (5 عمليات تشغيل × 116 مهمة لكل تكوين) + +الملاحة H1 +الإعداد 0% → 75% +الرمز المميز+8% + +H3 متعدد الوسائط +النسخ 0% → 80% +زمن الاستجابة +1 + +التفكير H4 +العد 0% → 70% +الكمون 3x! + +شجرة العنصر H6 +واجهة المستخدم 17% → 52% +رمز مميز+30% + +④ القرار: المفاضلة بين التكلفة والمنفعة +✓ H1+H3: تكلفة منخفضة، فائدة عالية → النشر +✗ H4: 8% فقط من المهام تستفيد ولكن 3x الكمون → الرفض +✓ H6: تحسين بنسبة 35% / تكلفة بنسبة 30% ← النشر +✗ H5: 15 ثانية/خطوة غير مقبولة → بديل + +⑤ التكرار: دورة جديدة +نشر H1+H3+H6 → 88% → 94% +تقرير جديد يوضح أوضاع الفشل المختلفة: + H7: تمكين التفكير المشروط + H8: قم بتوسيع مساحة عمل الإيماءات + +↑ حلقة + +المنهجية: لاحظ ← افترض ← جرب ← قرر ← كرر = من الكيمياء إلى الهندسة العلمية \ No newline at end of file diff --git a/book-ar/images/fig7-9.svg b/book-ar/images/fig7-9.svg index 624c6b7e9..b6b0e2027 100644 --- a/book-ar/images/fig7-9.svg +++ b/book-ar/images/fig7-9.svg @@ -1,69 +1,41 @@ - - + + - -المراقبة المتعددة الوسائط - -كاميرا الرأس -224×224 رغب - -كاميرا المعصم الأيسر -224×224 رغب - -كاميرا المعصم الأيمن -224×224 رغب - -ناقل الحالة المشتركة ذو 14 بعدًا - -نموذج الرؤية واللغة والعمل (VLA) - -تشفير الرؤية -SigLIP → الرموز المرئية - - -نموذج اللغة -اللاما 2 7B العمود الفقري - - -فك تشفير العمل -→ ناقل التحكم المستمر ذو 14 بُعدًا -تقسيم الإجراء: قم بإنشاء 25 إجراءً متتاليًا في وقت واحد - - - -التعليمات: "ضع العلبة في الوعاء" - - -محرك الفيزياء سابين - -روبوت ثنائي الذراع -7 DOF لكل منها = حركة ذات 14 بُعدًا - -العشوائية البيئية -الموضع 60 سم / الاتجاه ±22.5 درجة - -كشف الاصطدام + محاكاة الفيزياء -جسم صلب / جسم ناعم / احتكاك - -العمل - -الملاحظة - -مقاييس التقييم - -معدل النجاح -يمكن داخل وعاء -ولم يسقط - -وقت الانتهاء -25 خطوة × 25 إجراء -= 625 خطوة تحكم - -القدرة على التعميم -الموقف المتقاطع/الاتجاه -/ متغير المظهر - -سيم إلى ريال -العشوائية المجال -→ الهجرة الحقيقية + + +محاكاة الإخلاص → +قابلية التوسع + + + +↑ + +وهمية API +مستوى اختبار الوحدة +مليون مرة/ساعة + +عالم +صندوق الرمل MCP +126 وظيفة للأداة +525 ثانية / جولة موزعة + +androidworld +محاكي +116 مهمة تطبيقية في العالم الحقيقي +واجهة المستخدم التلقائية + +إسحاق جيم +التوازي GPU +الآلاف من الحالات الموازية +دقة للخطر قليلا + +RoboTwin2 +محرك الفيزياء +تصادم عالي الدقة +وحدة المعالجة المركزية ذات المثيل الواحد + +العالم الحقيقي +الإخلاص التام +غير قابل لإعادة الضبط + \ No newline at end of file diff --git a/book-en/chapter7.md b/book-en/chapter7.md index 96b907bd3..4c5da3b7e 100644 --- a/book-en/chapter7.md +++ b/book-en/chapter7.md @@ -18,57 +18,117 @@ From the perspective of Harness engineering introduced in Chapter 1, evaluation An evaluation system is worth even more in an era of rapid model evolution. Models keep improving, but a new model that scores higher on public benchmarks will not necessarily do better on your task—it may even regress (perform worse than the old version in some respects). Only a full run on your own evaluation dataset lets you make a data-driven upgrade decision. A solid evaluation system even makes **"building products for future models"** a viable strategy: if the current model isn't good enough for commercial deployment, finish the product anyway, build the evaluation set, track each new model's performance, and launch the moment one clears the bar. -> **Chapter Guide** -> -> This chapter builds a complete evaluation system on three levels. The first level is **Evaluation Design**: to avoid discussing tools and data first and defining "success" last, the chapter starts by defining what counts as success, distinguishing the capability ceiling of technical wonders from the consecutive reliability required by business scenarios; it then develops evaluation environments and datasets (where to test and what to test). The second level is **Evaluation Methods** (how to judge): LLM-as-a-Judge, pairwise comparison, and model ranking. The third level is **Evaluation-Driven Decision Making** (what to do after testing): turning results into actionable guidance for model selection, architecture optimization, and continuous iteration, with statistical significance to judge whether an observed score difference is real. The chapter also covers observability and the internal evaluation infrastructure of production-grade Agents, and closes with the simulation environments that connect to post-training in Chapter 8. -> -> The idea running through the whole chapter: **an evaluation system's primary value is not scoring the current system, but letting you keep up with model evolution quickly and reliably.** When a stronger or cheaper model ships, a team with a robust evaluation system can decide within hours whether to switch; a team without one can only trust intuition or wait for community feedback. In the fiercely competitive Agent market, that difference in speed can decide who wins. +A complete evaluation system decomposes into four stages: what counts as success, where the tasks come from, who verifies, and how a score turns into a decision, as shown in Figure 7-1. + +![Figure 7-1: The Four Stages of an Agent Evaluation System](images/fig7-1.svg) + +## Anatomy of an Evaluation Task: The telecom Domain of τ²-bench + +Let us begin by dissecting one real task from the telecom domain of τ²-bench in full. The source lives at `chapter7/tau2-bench` in the companion repository, and the task file is `data/tau2/domains/telecom/tasks_small.json`. + +### The Four Components of a Task Definition + +Below is one task from that file, abridged for readability. + +```jsonc +{ + "id": "[mobile_data_issue]airplane_mode_on|user_abroad_roaming_enabled_off", + + // The ticket handed to the Agent + "ticket": "The user is unable to browse the internet and the status bar shows + 'No Service'. Customer John Smith, phone 555-123-2002, currently + abroad in France. They will consider the issue resolved when the + speed test returns excellent. They will not change their data plan + but will refuel 2.0 GB of data if necessary.", + + // The behavioral spec handed to the user simulator + "user_scenario": { "instructions": { + "known_info": "You are John Smith with phone number 555-123-2002. + You are currently abroad in France.", + "unknown_info": null, + "task_instructions": + "…express mild frustration after the first unsuccessful attempt. + You will consider the issue resolved only when speed test returns + excellent internet speed and nothing else. If it returns poor, fair + or good, you will not consider the issue resolved. + Whenever the agent asks you about your device, always ground your + responses on the results of tool calls. … + Never make up the results of tool calls." + }}, + + // Reset both sides to the same starting point before the run + "initial_state": { "initialization_actions": [ + { "env_type": "user", "func_name": "turn_airplane_mode_on" }, + { "env_type": "user", "func_name": "turn_roaming_off" }, + { "env_type": "assistant", "func_name": "enable_roaming", + "arguments": { "customer_id": "C1001", "line_id": "L1002" } } + ]}, + + // Scoring criteria + "evaluation_criteria": { + "actions": [ + { "requestor": "user", "name": "toggle_airplane_mode" }, + { "requestor": "user", "name": "toggle_roaming" } + ], + "env_assertions": [ + { "func_name": "assert_mobile_data_status", "expected_status": true }, + { "func_name": "assert_internet_speed", + "expected_speed": 200, "expected_desc": "excellent" } + ], + "communicate_info": null, + "nl_assertions": null, + "reward_basis": ["ENV_ASSERTION"] + } +} +``` -![Figure 7-1: Three Levels of the Evaluation System](images/fig7-1.svg) +Four design decisions in this definition deserve elaboration. -## A Concrete Evaluation Example +**The user's knowledge boundary is modeled explicitly.** `known_info` contains only three facts: name, phone number, and country. The two actual causes of the fault — airplane mode is on, data roaming is off — are not among them. The user does not know, and therefore cannot volunteer them; the Agent can only obtain them by asking questions and guiding the user to check. This is how **progressive information disclosure** is implemented at the level of the task definition: not by constraining the simulator with a prompt that says "don't reveal everything at once," but by modeling the user's knowledge as a field of its own. Most benchmarks state the complete requirement at the start of the task, whereas a real user's opening line is often no more than "I can't get online." Clarifying a request until it is actionable is itself part of what an Agent must be able to do. -Before diving into the methodology, let's build intuition through a complete example. Suppose we have built a customer service Agent and need to evaluate its ability to handle refund requests. +**The simulator receives a behavioral spec, not a script of lines.** `task_instructions` carries three kinds of constraint: an emotional setting (show mild frustration after the first unsuccessful attempt), an acceptance criterion (the issue counts as resolved only when the speed test returns excellent; poor, fair, and good are all rejected), and a **grounding** requirement — every answer about the device state must be based on the result of a tool call, "Never make up the results of tool calls." The third is the most consequential: without a grounding constraint, the simulated user will follow the Agent's lead and confirm that the problem is fixed, and the evaluation degenerates into two models agreeing with each other. -**Test Case**: The user wants to return an order from 3 days ago (Order #12345, Amount ¥299). Company policy: Full refund within 7 days. +**The initial state is partitioned by which side controls it.** `env_type` takes two values, `user` and `assistant`: airplane mode and the roaming switch belong to the user's side, while the carrier-side `enable_roaming` belongs to the Agent's side. This partition determines the shape of the fault — roaming is provisioned on the carrier side but switched off on the user's handset, so an Agent querying the database sees nothing but "configuration normal." The fault sits on the side the database cannot see, and only guiding the user to check will surface it. -**Agent Trajectory**: +**Scoring is defined in four layers, and this task uses only one of them.** `env_assertions` checks the final state (mobile data available, speed test at or above 200 Mbps and rated excellent), `actions` checks whether the key actions occurred and **which side performed them**, and `communicate_info` and `nl_assertions` check whether the necessary information was conveyed to the user. This task's `reward_basis` declares only `ENV_ASSERTION`; the remaining layers are still computed and recorded but do not enter the final reward. The scoring basis is declared per task rather than fixed globally. -```text -User: I want to return the headphones I bought 3 days ago, order number 12345. (Today is 2026-04-10) +### The Trajectory of a Real Run -Agent (thinking): The user wants a refund, I need to check the order information first. -Agent → Calls tool query_order(order_id="12345") -Tool returns: {status: "delivered", amount: 299, date: "2026-04-07", item: "Bluetooth Headphones"} +We now ask the reader to run the evaluation tasks of the τ²-bench telecom domain, observe the task design, the user simulator, the process and outcome verification logic, and the Agent's execution trajectory, and analyze why the Agent fails. -Agent (thinking): Order date 2026-04-07, today is 2026-04-10, that's 3 days, within the 7-day refund period, eligible for full refund. -Agent → Calls tool process_refund(order_id="12345", amount=299) -Tool returns: {refund_id: "R-98765", status: "processing", eta: "3-5 business days"} +> **Experiment 7-1 ★: Run τ²-bench and Compare It with τ-bench** +> +> This experiment runs the τ²-bench evaluation framework to understand the design points of a human-computer interaction evaluation environment. First, read the task definition file along the path taken in this section: each task consists of four parts — known information, task instructions, initial state, and success conditions. Then run the full evaluation flow, observe the multi-turn dialogue between the user simulator and the Agent, and analyze typical failure modes (policy violations, omitted information, excessive escalation to a human agent, and so on). +> +> ![Figure 7-3: Dual-Control Environment and Layered Verification in τ²-bench](images/fig7-3.svg) -Agent: A refund has been initiated for you. The full refund for Order #12345 (Bluetooth Headphones, ¥299) is being processed, - and is expected to arrive in 3-5 business days. The refund ID is R-98765, which can be used to check the progress. -``` +The companion repository retains one run record (`chapter7/tau2-bench-eval`). Below we analyze one successful run from it. -**Scoring with a Rubric** (four dimensions, each scored 1-4). Table 7-1 provides a scoring example for this customer service refund task, illustrating how a Rubric breaks down an Agent trajectory into checkable evaluation dimensions. +The first dozen or so turns are the account identification phase. The Agent looks up customer C1001 by phone number, then queries the data usage of all three lines L1001, L1002, and L1003 one by one, and finally circles back to ask which number the user is actually using in France. In message 17 it reaches an incorrect conclusion: -Table 7-1 Rubric Scoring Example for Customer Service Refund Task +> **Agent** (17): The number 555-123-2002 is not among your active lines. The closest match is 555-123-2001… -| Dimension | Criteria | Score | Reason | -|------------------------|--------------------------------|------|--------------------------------| -| Operational Correctness | Is the refund amount and order number correct? | 4 | Correctly queried and initiated a ¥299 full refund | -| Policy Compliance | Does it follow the 7-day refund policy? | 4 | Order is within the refund period, complies with policy | -| Information Completeness | Does it provide the amount, arrival time, and refund ID? | 4 | All three key pieces of information were provided | -| Hallucination Detection (Veto) | Does it fabricate non-existent information? | Pass | All information comes from tool outputs | +That conclusion rests on a query of line L1001 alone. After the user insists the number is correct, the Agent goes on to query L1002 and finally matches it. The pivotal moment comes at message 30: -Hallucination is listed as a **veto** rather than a graded scoring dimension because it is orthogonal to quality. A fluent, detailed, and polite response containing false information is far more harmful to the user than a brief but accurate one. +> **User** (30) → calls `check_network_status()`, `check_status_bar()` +> +> **Tool returns** (31): `Airplane Mode: ON | Cellular Connection: no_service | Mobile Data Enabled: Yes | Data Roaming Enabled: No` +> +> **User** (33): I see my phone is currently in Airplane Mode, which is why there is no signal. Mobile data is enabled, but data roaming is off. Should I turn off Airplane Mode and try again? + +The party issuing the tool call is the **user**, not the Agent. This is the **dual-control** mechanism: the simulated user owns an independent tool set of its own, including `check_status_bar`, `toggle_airplane_mode`, `reseat_sim_card`, and `run_speed_test`. -This test case passed. But a good evaluation doesn't just test success scenarios; it also probes boundaries and traps—when a user wants to return an order from 15 days ago (beyond the refund period), can the Agent correctly refuse? When a user claims "a customer service representative already approved the refund," will the Agent believe it without a system record? These boundary scenarios are what truly separate strong Agents from weak ones. +The remaining troubleshooting goes smoothly: the Agent asks the user to turn off airplane mode and turn on roaming, the user performs both actions (35, 37), and the status bar switches to full-bar 5G; the Agent asks for a speed test, which returns 275 Mbps rated Excellent (46), and the user confirms the issue is resolved. Both `env_assertions` pass and `reward = 1.0`. -The process above — defining test cases, running the Agent, scoring with a Rubric, and analyzing results — is the basic skeleton of evaluation. The rest of this chapter fleshes out the design of each step. +This full-marks trajectory also contains a problem the verifier never caught. The opening paragraph of the telecom Agent policy states "You should only make one tool call at a time," yet in message 4 the Agent issued `get_customer_by_phone` and `get_customer_by_name` in a single turn. The verifier did not mark this as an error, because this task's `reward_basis` considers only the final state. This is not an oversight in τ²-bench but the inherent price of a binary reward: it trades process granularity for a single number that is comparable across models. Production evaluation systems, however, usually need more: not only a verdict on whether the outcome is right, but an indication of where the problem lies. -## Evaluation Metrics System +The failed task is equally worth analyzing. The user's number is 555-123-2002, yet the Agent settled on line L1001 and kept reasoning from its 3.2/5 GB usage figure. Along the way, `get_details_by_id(L1001)` explicitly returned 555-123-2001 as that line's number; the Agent read the result but did not revise its judgment, then spent dozens of messages on unrelated diagnostics and finally escalated to a human agent. It did in fact complete half the task — it guided the user to turn off data saver mode, and that user-side action genuinely occurred and was verified by the environment — but the wrong line selection meant the required 2 GB data refuel was never performed, and all three final-state assertions failed. This failure shape closely resembles the AndroidWorld case discussed later in "Failure Attribution": the evidence needed to correct the judgment had already entered the context, and the Agent did not go back on the strength of it. -Before building an environment or dataset, define what "success" means: is one workable path enough, or must every run be correct? Different definitions can reverse the engineering decision. This section establishes the vocabulary used by the rest of the chapter. +This one task already poses every question an evaluation set has to answer: what counts as success, where tasks come from, who verifies, and how a score turns into a decision. The following sections take them in turn. + +## Evaluation Metrics: Defining Success + +The evaluation result in the previous section was four of five tasks passed. The number 0.8 by itself says nothing about whether the system is usable. If it belongs to a refund customer service Agent, it means one user in five does not get the refund they are owed; if it belongs to a security Agent used to hunt for vulnerabilities, hitting four out of five is quite respectable. The difference lies in how high a success rate the business scenario demands. ### Technical Wonders: Capability Ceilings with Pass@k @@ -99,210 +159,155 @@ At $p=0.6$ and $k=5$, for instance, Pass@5 $=1-0.4^5\approx99.0\%$ — it looks An evaluation report must state exactly what the $k$ attempts are: $k$ independent samples of the same task, or $k$ consecutive tasks on a production pipeline. For operations with side effects you cannot simply "retry until it works"; sample in a sandbox or a rollback-capable environment instead, and record every failure in the reliability metric. -### Process Metrics: From Black Box to White Box - -Focusing solely on the final outcome is insufficient; the process by which the Agent achieves the outcome is equally important. **Action validity and authorization rate** measures the proportion of actions that are both valid and authorized—invalid operations include calling non-existent tools or passing incorrect parameter types; unauthorized operations refer to actions beyond the permitted scope. A high rate indicates the Agent has a clear understanding of the tool ecosystem. **Tool call correctness rate** further requires that parameters are semantically reasonable: the query terms for a search tool should accurately express the need, and the path for a file operation should point to the correct target. +## The Evaluation Environment -**Path efficiency** measures how efficiently the task is completed: number of steps (think-act-observe cycles), redundant actions (repeatedly searching for the same keyword, re-reading the same file), and backtracking frequency (how often the Agent realizes an error and corrects itself—occasional backtracking is normal, but frequent backtracking indicates insufficient forward planning). A baseline from human experts or heuristic algorithms is needed to define a "reasonable number of steps." +Once the metric is settled, the next question is where to test. An evaluation environment is an apparatus that can be run repeatedly: given the same initial state, the same Agent should produce comparable results. -**Retrieval coverage** targets information-gathering tasks: Did the Agent fully explore the information space? Did it jump to conclusions after only looking at the first page of search results? **Cost and latency** focus on request count, token expenditure (distinguishing input/output costs, considering KV Cache reuse), and wall-clock time (including model inference + tool execution + network latency). Time distribution needs to be tracked to identify bottlenecks. +### The Five Components -### Safety, Robustness, and Trajectory Coverage +Return to the telecom task dissected above. Taking it as the reference, everything a repeatable evaluation environment requires is already present. -**Safety and Compliance Metrics** are crucial in production deployment: triggering sensitive operations (deleting data / modifying permissions / sending external communications), data leakage (printing passwords in logs / sending private documents to external APIs), and prohibited content should all be subject to a **zero-tolerance principle**—similar to the hallucination veto (see the "Four Rubric Principles" later). A single serious safety violation vetoes the overall evaluation, regardless of performance in other dimensions. +**Dataset** is the task file itself: the initial state, the ticket for the Agent, the behavioral spec for the simulator, and the acceptance criteria are packaged into a single record, and one record is one test case. -**Robustness** measures stability in the face of uncertainty: random seed sensitivity (how much performance varies under different initializations), adaptability to page changes (a website UI update should not cause complete failure), tolerance for API jitter (can it gracefully handle temporary failures, timeouts, format changes), and long-term memory interference (can outdated information accumulated in the context lead to incorrect decisions). +**Environment State** is the mutable information during task execution: customers, lines, plans, and bills in the database, plus airplane mode, roaming, the data saver switch, and the remaining data allowance on the device side. It must be resettable, and `initialization_actions` is the reset script. Realism requires state changes to follow business logic; controllability requires that every run start from the same point. -**Dual Coverage of Execution Trajectory and Final Outcome.** An easily overlooked distinction: "what the Agent said and did during execution" (the trajectory defined in Chapter 1) and "what the system ultimately became" (the final outcome) are two different things. The Agent saying "the booking is complete" is trajectory-level information; a record actually appearing in the database is outcome-level verification. Look only at the trajectory and you miss "said it but didn't do it"; look only at the outcome and you may miss intermediate steps that went astray. Anthropic once gave an example: a flight booking Agent discovered a loophole in the airline's policy during execution and found a cheaper option for the user—if scored only according to the preset execution path, this run would be judged a failure; but from the final outcome, the user got a better deal. Therefore, both types of evaluation should be covered to avoid systematic blind spots. +**Tools** belong to two sides. The Agent can call carrier-side operations such as looking up a customer, checking usage, refueling data, and transferring to a human agent; the user can operate the switches on the device. Both tool sets are atomic operations — there is no high-level abstraction such as "solve the user's connectivity problem." Too high a level of abstraction reduces the evaluation to a test of a single function call, with the planning and reasoning absorbed into the tool itself. -### Human Spot Checks and Adversarial Review +**Rubric** is the four layers of checks in `evaluation_criteria`, plus the aggregation rule in `reward_basis`. -Even when automated evaluation is reliable most of the time, regular human spot checks are still needed: cover different task types, successes and failures, and ambiguous cases near score boundaries — verifying not just the results but the soundness of the scoring rationale. +**Interaction Protocol** specifies the order of interaction and the termination conditions. Here the normal termination signal is the simulated user emitting `###STOP###`; there is also a turn limit, and the simulated user may end the conversation on its own once its patience runs out — poor communication efficiency counts as a failure in itself. -Spot checks can be systematized into **judge calibration**. Before deploying LLM judges at scale, build a human-annotated gold standard set (say, 100-200 cases spanning task types and difficulties) and measure how well the judge model (an LLM acting as judge; the mechanism is detailed in the LLM-as-a-Judge section next) agrees with human annotations — simple agreement rate or Cohen's kappa, the latter discounting chance agreement. Only once agreement clears a preset threshold (e.g., kappa above 0.7) should the judge be used for large-scale evaluation; thereafter, recalibrate on the gold set whenever the judge model or Rubric changes. Without this step, an LLM judge's scores are just "another model's opinion," not a reliable proxy for human judgment. - -**Adversarial review** uses Red Teaming to actively construct challenging cases: seemingly perfect answers containing hidden errors, answers that get by through keyword stuffing, and answers that exploit known biases of the judge model to obtain undeservedly high scores. **Multi-judge mechanisms** use multiple independent judges to score separately, determining the final result through weighted averaging or consistency checks—when judges disagree significantly, the case is flagged for further human review. - -## Automated Evaluation Environment - -Agent evaluation requires a repeatable, automated environment — one that can quickly test the effects of changes during development. Building such an environment requires answering three questions: what to evaluate (task definition and verification criteria), whom the Agent interacts with and how to simulate that counterpart, and which scoring criteria to use. - -### Basic Components of an Evaluation Environment - -An evaluation environment consists of five elements — the following sections will focus on dataset design and scoring criteria design: - -**Dataset**: Defines the task set, including initial state, goal description, and optional reference solutions. - -**Environment State**: Tracks mutable state during task execution and must balance realism with controllability. For example, in a customer service evaluation, the environment state includes order records in the database and user account balances. After the Agent calls `process_refund`, the order status changes from `"delivered"` to `"refunded"` and the balance increases. "Realism" requires that state changes follow business logic (refund amount cannot exceed the order amount), and "controllability" requires that each test can be reset to the same initial state. - -**Tools**: Defines the set of operations the Agent can perform — tools should not provide overly high-level abstractions (like "solve user problem"), but should provide atomic operations (like query order, modify booking, send email), forcing the Agent to combine these operations through planning and reasoning. - -**Rubric (Scoring Criteria)**: Quantifies the Agent's performance, which can be binary (pass/fail), continuous (0 to 100 points), or multi-dimensional (scoring accuracy, efficiency, and safety separately). - -**Interaction Protocol**: Specifies the interaction mode and termination conditions. - -Together, these five elements form a repeatable evaluation loop. - -![Figure 7-2: Tool-Calling and Human-Computer Interaction Evaluation Environments](images/fig7-2.svg) +Remove any one of the five and the evaluation no longer forms a repeatable loop. The same five serve as the reference frame when we examine other benchmarks below. -Depending on the task, evaluation environments can be roughly divided into tool-calling and human-computer interaction types. +### Human-Computer Interaction and Tool-Calling Evaluation Environments -### Tool-Calling Evaluation Environment +Tasks like telecom must have a counterpart to interact with, so the user simulation among the five components is indispensable. Another large class of tasks has no conversational counterpart at all: in code generation, data analysis, and mathematical problem solving, the Agent interacts only with tools from start to finish, correctness is decided by whether execution verification passes, and neither human annotation nor model judgment is required. Such environments dispense with the user simulator; the other four components remain but take simpler forms — the environment state is a file system or a database, the rubric is a piece of test code, and the interaction protocol degenerates into "keep calling tools until an answer is produced or the turn budget is exhausted." -For tasks that primarily rely on tool usage, such as code generation and data analysis, the Verifiers framework demonstrates a typical design pattern. The Agent completes the task by calling predefined tools, and verification is based on executable criteria (whether tests pass, whether answers match), without relying on human annotation or model judgment. +The Verifiers framework stratifies these environments along two dimensions: whether the task needs to maintain state across turns, and whether it needs isolation. `SingleTurnEnv` suits asking a math question and verifying the answer directly; `ToolEnv` suits searching several web pages, synthesizing an answer, and then verifying the final result; `StatefulToolEnv` suits modifying a database record and then verifying the state change; `SandboxEnv` suits running code in a sandbox and then checking the output files. Table 7-1 summarizes these four environment types, making it easy to choose based on task state, tool calling, and isolation requirements. -Verifiers introduces a hierarchical environment design: `SingleTurnEnv` is suitable for single-turn tasks (e.g., simple Q&A), `ToolEnv` supports multi-turn autonomous loops of tool calls, and `StatefulToolEnv` and `SandboxEnv` support stateful tools and long-running sandbox environments (e.g., code execution). For example: `SingleTurnEnv` is suitable for posing a math question and checking the answer directly; `ToolEnv` fits searching several web pages and synthesizing an answer before verifying the final result; `StatefulToolEnv` fits modifying database records and verifying the resulting state change; `SandboxEnv` fits running code in a sandbox and checking the output files. Table 7-2 summarizes these environment types for readers to choose the appropriate evaluation environment based on task state, tool calls, and isolation requirements. - -Table 7-2 Verifiers Environment Type Comparison +Table 7-1 Comparison of Verifiers Environment Types | Environment Type | State Persistence | Tool Calls | Typical Use Case | |---|---|---|---| | SingleTurnEnv | None | None | Single-turn Q&A, math problems | | ToolEnv | None | Multi-turn | Search + information synthesis | | StatefulToolEnv | Yes | Multi-turn | Modifying database records | -| SandboxEnv | Yes + Isolation | Multi-turn | Code execution and testing | +| SandboxEnv | Yes + isolated | Multi-turn | Code execution and testing | -The framework supports parallel sampling and trajectory caching. The complete trajectory (observations, actions, rewards) from each evaluation is saved for subsequent analysis and replay. +The framework supports parallel sampling and trajectory caching; the complete trajectory of every evaluation (observations, actions, rewards) is saved for later analysis and replay. In addition, a tool's effect depends on the current state, so on failure it should return a clear error message rather than a bare failure flag, allowing the Agent to adjust its strategy accordingly. -The environment also needs to handle the state dependency of operations — the outcome of a tool call depends on the current state. On failure, it should provide clear error messages rather than simple failure flags, allowing the Agent to learn from errors and adjust its strategy. +Tool-calling evaluation examines the correctness of observable state changes, while human-computer interaction evaluation examines the soundness of the communication strategy — the former verifies action, the latter verifies guidance. Figure 7-2 contrasts the structure of the two environment types. -### Human-Computer Interaction Evaluation Environment +![Figure 7-2: Tool-Calling and Human-Computer Interaction Evaluation Environments](images/fig7-2.svg) -Many real-world tasks involve not only tool calls but also conversations with human users. A customer service Agent needs to understand vague expressions, clarify needs, query backend systems, and confirm information with the user. Evaluating such tasks faces a fundamental challenge: how to simulate real users in an automated environment? +## Design of the Evaluation Dataset -The key design principle is **Progressive Information Disclosure**, which is the fundamental difference between human-computer interaction evaluation and traditional benchmarks. Most benchmarks reveal the complete requirements upfront, but real users can rarely articulate their needs from the start — they often just say "there seems to be a problem with my flight" or "the internet isn't working." The Agent must clarify the need by asking questions, and that process is itself a display of capability. In evaluation, therefore, **the simulated user's information must not be revealed to the Agent all at once**; it should be disclosed progressively, on demand, as the conversation unfolds. +The evaluation environment is the stage and the dataset is the script. The same five components, applied to a different class of task, may be filled in entirely differently: where the tasks come from, how deeply the verifier can check, and how memorization is prevented. This section starts from the design practice of several public benchmarks and ends with a more practical question — where the tasks in a self-built evaluation set should come from. -τ-bench's solution is **User Simulation**: using another LLM to play the user role, conversing with the Agent according to predefined instructions. The simulated user receives task instructions (e.g., "I need to cancel tomorrow's flight"), gradually reveals necessary information to the Agent during the conversation, responds to inquiries, and sends a termination signal when the task is complete. The prompt requires the simulated user to "not reveal all information at once, only provide what is necessary for the current step" and "not fabricate information not provided in the instructions." The design of user simulation requires a trade-off between authenticity and controllability: behavior should be close to a real user (vague expressions, incomplete information, occasional emotional fluctuations) while following a certain script to ensure reproducibility. +### A Cross-Benchmark Comparison of Design Choices -The following is an example of a multi-turn conversation with progressive information disclosure (the user simulator acts according to a fixed script): +The presence or absence of an interactive counterpart, distinguished in the previous section, is only the first-order difference at the environment level; the divergences at the dataset level reveal the design trade-offs more clearly. Table 7-2 places several frequently cited benchmarks side by side. -> **User**: "There's a problem with my flight." -> **Agent**: "Which flight is it?" -> **User** (revealing per script): "Delta 123, tomorrow morning from San Francisco to New York." -> **Agent**: "What's the specific problem?" -> **User** (revealing per script): "The flight time is too long, I want to change it." -> **Agent**: "Any preferences for the new flight?" -> **User** (revealing per script): "Any afternoon flight is fine." +Table 7-2 Key Design Choices of Several Agent Benchmarks -The user simulator follows a fixed script (known information + disclosure rules), ensuring evaluation reproducibility while simulating the progressive expression style of a real user. The simulated user often also has **limited patience**: if the Agent communicates inefficiently, the simulated user can end the conversation, causing the task to fail. +| Benchmark | Capability Tested | Task Source | Environment Played By | Verifier | +|---|---|---|---|---| +| τ²-bench | Human-computer interaction and tool calling in customer service | Hand-written + combinatorial generation | User simulator + business database | Four layers of checks aggregated to binary by `reward_basis` | +| SWE-bench Verified | Software development, coding | Real GitHub issues, manually screened | Code repository + test suite | FAIL\_TO\_PASS / PASS\_TO\_PASS dual verification | +| AndroidWorld | Operating the Android phone GUI | Parameterized template instantiation | Real Android emulator | Final UI state assertions | +| OSWorld | Operating the Linux desktop GUI | Started from a preconfigured intermediate state | Real virtual machine | 134 independent evaluation functions | +| Terminal-Bench | Operating the Linux terminal, coding | Hand-written | Docker container | File system checks + real execution | +| GAIA | General-purpose AI assistant gathering information | Hand-written + proprietary attachments | The open internet | Exact string matching | -τ-bench is a benchmark for evaluating Agent performance in structured business processes (e.g., airline customer service, retail customer service). Its checks are component-level and multi-dimensional: on one hand, it checks whether the final database state is correct (e.g., the booking record status changes to "cancelled"); on the other hand, it verifies whether the Agent provided the necessary key information during the conversation (e.g., refund amount and arrival time, verified by searching for specific strings or patterns). This dual verification simultaneously examines operational accuracy and communication effectiveness. At the task level, however, these checks ultimately collapse into a **binary reward of zero or one** — all checks must pass to score 1; any single failure scores 0. Binary rewards make reliability metrics like Pass^k easy to compute (see the "Evaluation Metrics System" section later), at the cost of scoring "operationally accurate but missing one non-critical field" the same as "complete failure." +### Verifiers -The enhanced **τ²-bench** does not primarily improve scoring granularity; instead, it advances the benchmark in two other areas. First, the **Dual-Control Environment**: the Agent is no longer the only party that can call tools — the user simulator can operate on the same shared environment (the Agent instructs the user to switch to airplane mode, and the user's action actually changes the environment state), which better matches real scenarios like technical support, where the user must lend a hand. Second, **more precise task specifications and compositional task generation**: fewer ambiguities in success conditions, and task instances that can be parameterized and generated in batches (see the "Verifiability and Objectivity Assurance" section later for detailed verification dimensions). +An Agent can easily write an expansive report claiming the task is fully complete when in fact nothing of the sort happened. An evaluation framework must verify facts that a machine can check independently, not the Agent's own account of itself. -> **Experiment 7-1 ★: Run τ²-bench and Compare Its Evolution from τ-bench** -> -> This experiment runs the τ²-bench evaluation framework to understand the design principles of human-computer interaction evaluation environments. By comparing τ-bench with τ²-bench, we can see how evaluation datasets are iteratively improved. -> -> Read the task definition files in depth: each task contains information known to the user, task instructions governing progressive disclosure and response strategies, and success conditions (the target state of the database and confirmation information that must appear in the dialogue). Run the complete evaluation process, observe the multi-turn dialogue between the user simulator and the Agent, and analyze typical failure modes (policy violations, information omissions, excessive handoffs to human agents, etc.). -> -> -> ![Figure 7-3: τ²-bench Evaluation Architecture](images/fig7-3.svg) -> -> -> Compare the design differences between τ-bench and τ²-bench: The initial version of τ-bench had overly simple user instructions (the Agent could guess the answer), imprecise success conditions (leading to misjudgments), and a mechanical user simulator. τ²-bench made systematic improvements to address these issues: -> -> - **Introduced more detailed task instructions**: Including "Grounding Requirements," meaning responses must be based on the actual state of the environment -> - **More precise evaluation criteria**: For example, "a speed test must return 'excellent' to be considered resolved" -> - **More realistic user simulator behavior specifications**: Progressive information disclosure, natural emotional fluctuations -> -> Pay special attention to the newly added telecom domain tasks in τ²-bench, and understand τ²-bench's dual-control environment design (as mentioned earlier, the user and the Agent jointly operate the same shared environment). -> +**SWE-bench Verified decomposes "the fix is complete" into two independent propositions.** One set is FAIL\_TO\_PASS: failing before the fix and passing after it, proving the problem really was solved. The other is PASS\_TO\_PASS: passing both before and after, proving no new defect was introduced. Check only the first and an Agent can slip through by deleting or rewriting the assertions that stand in its way; check only the second and you have checked nothing at all. Only checking both makes "fixed" and "did not break anything" two separately provable conclusions. It additionally confirms the stability of the tests themselves, excluding flaky tests that sometimes pass and sometimes fail. -Tool-calling evaluation asks whether an observable state change was completed; human-computer interaction evaluation asks whether the Agent helped the user reach a new understanding or make a decision. The former tests the correctness of the Agent's actions; the latter tests the soundness of its communication strategy. +**OSWorld's verifier can detect cases of superficial completion but substantive error.** It is equipped with 134 independent evaluation functions and full operating system access, able to inspect file system structure, process state, network connections, and application internals. In a database task, the evaluation script not only confirms that the report file exists but also connects to the database to verify that the SQL actually executed; in a browser task it analyzes the DOM tree, inspects cookies and localStorage, and sends verification requests to the backend to confirm that the form really took effect. -Building evaluation environments also touches on simulation environments—when an evaluation environment must support repeated interactions at scale, it becomes a simulation environment. The end of this chapter takes this up briefly. +**Terminal-Bench**'s task `build-linux-kernel-qemu` requires building Linux kernel 6.9 from source, adding a custom printk in `start_kernel`, generating an initramfs, and running it under QEMU; success is defined as the custom message appearing in the boot log. The Agent cannot fabricate the output — it has to complete the whole process for real. -## Design of Evaluation Task Datasets +### Difficulty Stratification of Tasks -The evaluation environment is the "stage," and the dataset is the "script." The quality of the script often determines the value of the evaluation more than the stage itself. A poorly designed dataset, even when run in a perfect environment, only yields noise. This section distills several repeatedly validated principles from the design practices of benchmarks such as GAIA, AndroidWorld, SWE-Bench Verified, τ-bench and τ²-bench, Terminal-Bench, OSWorld, and OSWorld-Verified. +An evaluation task set needs tasks at different difficulty levels. That way the set does not go stale quickly as model capability improves. -> **Experiment 7-2 ★: Manually Execute Benchmark Tasks** -> -> Select tasks from each of GAIA, AndroidWorld, SWE-Bench Verified, τ²-bench, Terminal-Bench, and OSWorld-Verified and complete them manually. It is recommended to complete one simple, one medium, and one difficult task from each dataset—the "difficult" level should be challenging even for humans. Compare your execution results with the standard answers and analyze the sources of discrepancies. Through this hands-on experience, understand: task descriptions need to balance clarity and openness, verification standards must be objective and executable, and the hierarchical difficulty of tasks must be able to distinguish different capability levels. -> - -### Core Challenges in Task Dataset Design - -**Challenge One: The Tension Between Clarity and Openness.** Task descriptions must be clear enough to ensure reproducible evaluation, yet not so rigid as to stifle the Agent's creativity. GAIA provides an example: tasks are "conceptually simple" but have open implementation paths—for instance, a task may require the Agent to identify an astronaut from NASA's Astronomy Picture of the Day and determine how long they spent in space. The goal is clear, but how to search, filter, and verify is entirely up to the Agent's autonomous decision-making. - -**Challenge Two: Balancing Authenticity and Controllability.** Real-world tasks contain uncertainty and noise, which can reveal robustness but also threaten reproducibility. The initial version of SWE-Bench directly used real GitHub issues, ensuring authenticity but also leading to vague task descriptions, incomplete test cases, and subjective evaluation criteria. SWE-Bench Verified introduced systematic validation by human experts, selecting 500 high-quality tasks with clearly defined problems, sufficient tests, and clear solutions, significantly improving controllability while maintaining authenticity. - -**Challenge Three: Coordinating Diversity and Systematization.** An effective dataset needs to cover typical scenarios, edge cases, and error traps, while also having a systematic organization so that evaluation results can diagnose specific capability weaknesses. AndroidWorld's 116 tasks span 20 real applications, each annotated with the core capabilities it requires (multi-step planning, visual understanding, temporal reasoning) — so results yield not just an overall success rate but a profile of strengths and weaknesses along specific capability dimensions. More critically, a parameterization mechanism can generate almost unlimited task variants. - -**Challenge Four: Evaluation Cost vs. Coverage.** Complex Agent tasks can take minutes or even hours to complete, consuming a large number of tokens. The size of the dataset needs to balance comprehensiveness and economy. GAIA carefully selects 466 tasks across three difficulty levels, covering multiple capability dimensions while allowing evaluation at a reasonable cost. SWE-Bench Verified reduced its set from 2,294 tasks to 500 (reducing costs by about four-fifths while improving the signal-to-noise ratio through stricter quality standards). +The full GAIA set of 466 questions is divided into three difficulty levels: Level 1 requires only one or two tools (humans 93.9%, GPT-4 30.3%), Level 2 requires multi-step reasoning (91.8% versus 9.7%), and Level 3 requires complex composition (87.3% versus 0%). This stratification does more than label difficulty; it has diagnostic value. A Level 1 failure points to basic tool use, Level 2 to multi-step planning and information integration, and Level 3 to long-sequence reasoning and complexity management, and the three imply different directions for improvement. -**Challenge Five: Preventing Data Contamination.** In the era of large language models, data contamination is a serious challenge for evaluation: when evaluation data is included in the training data, the evaluation measures memorization rather than generalization. It's like memorizing the answers before an exam—good scores don't reflect true ability. Different benchmarks adopt different prevention strategies: GAIA relies on the uniqueness of its answers; questions require combining information from multiple sources to answer, and some tasks come with specially created attachment files (PDFs/audio/images that don't exist on the internet), so a single web page cannot directly provide the answer. SWE-Bench Verified itself is a 500-task subset obtained by OpenAI through manual quality screening of the original SWE-Bench, and does not include time-based leakage-prevention design. It is subsequent works like SWE-bench-Live that truly use temporal freshness to prevent leakage, continuously incorporating issues created after the model's training cutoff date, keeping the evaluation ahead of the model's training corpus. τ²-bench prevents leakage through dynamic parameter generation, where specific task instances (user names, order numbers, dates, etc.) are randomly generated each time. AndroidWorld's parameterized task generation naturally helps prevent leakage because verification is based on the final UI state, not the sequence of operations. Terminal-Bench makes leakage detectable by embedding canary GUIDs (globally unique identifiers used as tracking markers): if a model can output content containing this GUID, it indicates that the benchmark data has leaked into the training set. +Terminal-Bench spans everything from simple MLflow model registration, to medium-difficulty 7-Zip password cracking, to difficult multi-component integration of a Git server and a web server, up to the hardest FEAL differential cryptanalysis. -### Precision Design of Task Descriptions +τ²-bench additionally designs **trap tasks**, in which the user claims "customer service has already approved the cancellation" when it does not in fact comply with policy, testing whether the Agent holds its judgment under pressure and misdirection. -GAIA ensures answer uniqueness through clear information source constraints, time ranges, topics, and query targets. For example, a Level 3 task requires starting from a specific date's NASA image, identifying the astronaut through visual understanding, looking up the astronaut group to which they belong, calculating their time in space, and formatting the output precisely ("last name; fields separated by semicolons; numbers formatted with thousands separators"). Every detail serves automatic verification—only an exact match in format and content counts as a pass. +### Preventing Data Contamination -τ²-bench introduces contextualized design, with each task containing multiple layers of information: the surface problem ("mobile data isn't working"), the performance expectation ("requires an excellent speed rating"), the constraint ("will not accept any other rating"), and the implied emotion. A key improvement is separating "known information" from "task instructions": known information is what the user currently knows, while task instructions guide the simulator on how to progressively reveal information, including "Grounding Requirements" (responses must be based on the actual results returned by tool calls, not fabricated). +**GAIA makes its answers impossible to retrieve directly from the internet.** Its tasks are conceptually simple with open paths — for example, starting from NASA's Astronomy Picture of the Day for a given date, identifying the astronaut in the image, finding the astronaut group they belonged to, computing which member of that group spent the least time in space, and formatting the output strictly as "last name; semicolon-separated; thousands separators." The answer is highly specific, and correctness is decided by exact string matching. Leakage prevention rests on two things: first, the question can only be answered by combining several information sources, so no single web page gives the answer directly; second, some tasks come with specially produced attachments (PDFs, audio, and images that do not exist on the internet). -SWE-Bench Verified includes structured fields like problem description, reproduction steps, and expected/actual behavior, with annotators verifying the match between the description and the test cases. Every element in Terminal-Bench's task descriptions can be mechanically verified: whether file paths exist, permission values are correct, certificate parameters are valid, and date formats are correct. For example, "build-linux-kernel-qemu" requires building the Linux kernel 6.9 from source, adding a custom printk in `start_kernel`, generating an initramfs, and running it in QEMU. The success criterion is the appearance of the custom message in the boot log—the Agent cannot fake the output; it must truly complete the entire process. +**AndroidWorld derives a large number of instances from a single template.** Its tasks are not static text but dynamically instantiable templates such as "change the phone number of contact `[CONTACT_NAME]` to `[NEW_PHONE]`," with parameter values generated randomly for each evaluation. This yields three benefits: parameters differ each time, so replaying a fixed action sequence is useless; a single template can generate a nearly unlimited number of instances; and fixing some parameters while varying others allows the effect of a specific factor to be measured precisely. -AndroidWorld uses a **parameterized template** design. A task is not static text but a dynamically instantiable template (e.g., "Change the phone number of contact `[CONTACT_NAME]` to `[NEW_PHONE]`"), with different parameter values randomly generated for each evaluation. This has three benefits: +**Terminal-Bench embeds a canary identifier in the task statement.** Every task carries a canary GUID; if a model can output content containing that GUID, the benchmark data has entered the training set. It does not prevent leakage, but it makes leakage detectable. -- **Prevents memorization**: Parameter values differ each time, preventing the replay of a fixed sequence of operations -- **Increases data diversity**: One template can generate almost unlimited instances -- **Supports comparative experiments**: Fixing certain parameters while varying others allows precise measurement of specific factors' effects +### Quality Control and Long-Term Maintenance -Verification is based on the final UI state (e.g., whether the phone number field contains the expected value), not the sequence of operations. +Building a high-quality evaluation set is very hard. The present form of most of the benchmarks above is the result of round after round of repair once the first version was put to use and its problems surfaced. From τ-bench to τ²-bench, for instance, there are five places where the design was reworked. -OSWorld tasks often do not start from a "clean" initial state but from carefully configured intermediate states, more closely resembling real-world usage scenarios. Task descriptions need to handle multiple solutions ("set the background to purple" requires a specific color code to disambiguate; "concatenate two CSVs" must accept all reasonable methods like keeping one header or both headers) and environmental uncertainty (anti-scraping measures on websites, evolving application UIs, and race conditions—OSWorld-Verified mitigates these through offline page snapshots, locked dependency versions, explicit wait conditions, etc.). +First, **task instructions were too vague, letting the answer be guessed**. The first version's task instructions were written broadly, so the model did not need to genuinely clarify the requirement — guessing a plausible workflow from common sense was enough to pass. τ²-bench split the script into two fields, `known_info` and `task_instructions`: the former delimits what the user knows, the latter prescribes how it is disclosed. What the user does not know, the Agent cannot guess and can obtain only by querying. -This list does not exhaust the Agent evaluation landscape. Even within the Web/GUI category there are several benchmarks with different emphases: WebArena builds fully reproducible websites (e-commerce, forums, code hosting, etc.), containing the unpredictability of real web pages within a sandbox; Mind2Web goes the opposite way, testing generalization directly on hundreds of real websites; [ClawBench](https://claw-bench.com/) ([paper](https://arxiv.org/abs/2604.08523), [code](https://github.com/TIGER-AI-Lab/ClawBench)) lets an Agent running in an isolated container perform end-to-end everyday tasks on live websites. V1 covers 153 tasks across 144 websites, V2 adds another 130, and it records five layers of evidence in parallel: session replays, action screenshots, HTTP traffic, browser actions, and Agent messages. It complements sandboxed benchmarks by making live-site drift and long-tail failures easier to analyze, at the cost of reproducibility that is subject to changes on third-party websites; BrowseComp specializes in deep retrieval — answers buried so deep that only multi-hop browsing and cross-checking can surface them. On the tool-calling side there are dedicated function-calling leaderboards like BFCL (Berkeley Function-Calling Leaderboard). This chapter makes no attempt to catalog them all. Instead it takes the two core environment paradigms (tool calling and human-computer interaction), plus the GUI operation scenarios that run through the dataset case studies, and digs into their design trade-offs. Once you understand the paradigms, you can quickly judge what any new benchmark measures, how well it prevents data leakage, and how far its conclusions can be extrapolated. +Second, **success conditions were not precise enough, causing verification errors**. A condition such as "the network is back" has no checkable boundary. τ²-bench changed it to "the issue counts as resolved only when the speed test returns excellent; poor, fair, and good are all rejected." This change targets **perfunctory fixes**, which suppress the symptom without addressing the root cause. -### Hierarchical Design of Task Complexity +Third, **the user simulator behaved too mechanically**. The first version's simulated user only responded passively. τ²-bench added emotion (showing displeasure after the first failed fix), a patience limit (ending the conversation when communication efficiency is too low), and the grounding requirement. Together these make the simulator approximate a real user while remaining reproducible. -GAIA designs three difficulty levels: Level 1 requires only 1-2 tools (humans 93.9% vs GPT-4 30.3%), Level 2 requires multi-step reasoning (91.8% vs 9.7%), and Level 3 requires complex combinations (87.3% vs 0%). The diagnostic value of this hierarchical design is: failure at Level 1 points to basic tool usage issues, Level 2 points to multi-step planning and information integration, and Level 3 points to long-sequence reasoning and complexity management. Each level corresponds to different improvement directions (prompt engineering vs. planning mechanisms vs. hierarchical architecture/post-training). +Fourth, **the user participates not only in the conversation but also in the operation**. The telecom domain introduced a dual-control environment. In earlier evaluations only the Agent could change the environment, whereas in technical support scenarios a substantial share of the actions ought to be performed by the user on their own device. Dual control also adds a dimension to verification: after the user changes the state, the Agent must call a tool again to learn the result, so verification now covers whether the Agent actually read the outcome of the user's actions. -τ²-bench layers complexity by business process: from simple information queries, to multi-step processes (changing a flight booking requires querying, presenting alternatives, obtaining confirmation, calculating the fare difference, and processing payment), to fault diagnosis (systematically checking multiple possible causes and verifying fixes), and finally to strategic judgment (handling requests that don't comply with policy). +Fifth, **task instances are generated dynamically**. τ²-bench's concrete instances (user names, phone numbers, fault combinations) can be generated in bulk from parameters, which improves both coverage and resistance to leakage. -Terminal-Bench layers complexity along the dual dimensions of technical domain × operational complexity. Its task registry has collected over 200 tasks (the size of the core evaluation set varies by version; for example, version 2.0 selected 89 high-quality tasks from community contributions), ranging from simple MLflow model registration, to medium-difficulty 7-Zip password cracking, to difficult Git server and web server integration, to the most difficult FEAL differential cryptanalysis (requiring cryptography knowledge + algorithm optimization to meet the 30-second time constraint). +**SWE-bench Verified: 71% of the original tasks were eliminated before release.** OpenAI randomly sampled 1,699 of the original 2,294 tasks for human evaluation, recruiting 93 developers proficient in Python to check each one: whether the problem description was clear, whether the test cases covered edge conditions, whether the tests were stable, whether the reference patch introduced new errors, and whether the difficulty was reasonable. In the end only 500 passed. The high elimination rate buys a better signal-to-noise ratio, and evaluation cost drops by roughly 80% as well. Complex Agent tasks routinely take minutes to hours, and running a full evaluation dataset with a frontier model often costs thousands of dollars in tokens, so reducing evaluation cost matters a great deal. -### Ensuring Verifiability and Objectivity +**OSWorld: more than 300 issues surfaced in the 15 months after release.** Released in April 2024, it quickly became an important benchmark for multimodal Agent evaluation, and widespread use then exposed four categories of problems: environment issues (anti-scraping measures, CAPTCHAs, dynamic content changes), task description issues (ambiguous phrasing), verification logic issues (too strict or too lenient), and initial state issues (incomplete configuration). A team of about ten people from the University of Hong Kong worked closely with MoonShot AI, OpenAI, ByteDance Seed TARS, Anthropic, Simular, and others for two months on a systematic repair: environment issues were resolved by locking versions and keeping offline backups, description issues by rewriting ambiguous phrasing, verification issues by manually establishing correct baselines and adjusting conditions, and initial state issues by adding completeness checks. -GAIA's answers are concise and clear. Strict formatting rules allow verification through exact string matching. The binary result (match or no match) ensures objective reproducibility. The rarity of the answers also serves as an anti-cheating measure—highly specific facts are unlikely to appear verbatim in training data. +> **Experiment 7-2 ★: Manually Execute Benchmark Tasks** +> +> Select tasks from GAIA, AndroidWorld, SWE-Bench Verified, Terminal-Bench, and OSWorld-Verified and complete them by hand; one easy, one medium, and one difficult task per dataset is recommended. The "difficult" level is challenging for humans too. +> +> Afterwards, answer two questions. Does the task description admit more than one reasonable interpretation, and if so, which one does the verifier accept? If you tried to slip through without doing the work, what would the cheapest path be, and could the verifier stop it? -SWE-Bench Verified uses executable code-based checks, distinguishing between FAIL_TO_PASS (fails before fix, passes after fix, proving the problem is solved) and PASS_TO_PASS (passes both before and after fix, proving no new bugs were introduced), achieving dual verification. The Verified version also ensures the tests themselves are reliable, without flaky tests that sometimes pass and sometimes fail. +### Three Sources of an Evaluation Set -τ²-bench's verification system includes multiple layers of checks (the results of each layer are still aggregated into a binary reward at the task level; all must pass for success): +A common view holds that public benchmarks serve model ranking and have limited bearing on real business. It is true that public benchmark scores are hard to translate directly into product decisions, but their design techniques transfer perfectly well. Verification depth, parameterized generation, leakage prevention, and quality maintenance — the topics discussed above — are precisely the places a self-built evaluation set is most likely to neglect. -- **Database state check**: Booking record status, whether a refund record was created -- **Dialogue content keyword search**: Whether the Agent explicitly confirms the refund amount and expected arrival time to the user -- **Process compliance**: Analysis of the tool call sequence, e.g., whether the user's explicit confirmation was obtained before modifying an order +An evaluation set in production usually has three sources. -The dual-control environment of τ²-bench (see the earlier section "Human-Computer Interaction Evaluation Environment") adds another dimension to verification: after the user simulator actually changes the environment state, the Agent must observe this change through tool calls and proceed with troubleshooting accordingly. Verification therefore covers whether the Agent actually observed the outcome of the user's actions. +**Public benchmarks** are used for coarse model screening and for borrowing design techniques, and generally not for product decisions. Their task distribution does not match that of your business; gaining two percentage points on GAIA bears no necessary relation to your refund success rate. -OSWorld provides 134 independent evaluation functions with full OS access, enabling deep inspection of file system structures, process states, network connections, and application internals. For example, in a database operation task, the evaluation script not only verifies that the report file exists but also directly connects to the database to check if the SQL was executed correctly. In browser tasks, it analyzes the DOM tree, checks cookies/localStorage, and sends verification requests to the backend to confirm whether the form submission actually took effect. This deep inspection can detect cases of "superficial completion but substantive error"—for instance, the Agent clicked the submit button, but the request was rejected by the server due to incorrect field entries. +**A self-built business set** covers the real task distribution and can serve as the basis for model selection and Harness design decisions. τ²-bench, for example, can serve as the skeleton for any evaluation system that needs a simulated user; you only have to substitute your own domain data and tool set. -Terminal-Bench is based on a standardized Docker container environment, combining file system state checks (path existence, permission values, content format) with program execution functional verification (in build-linux-kernel-qemu, actually starting QEMU and searching for the custom printk message). The canary GUID makes leakage traceable. +**Production trajectory feedback** comes from real failures in the field: cases where the user explicitly corrected the Agent, where the user gave a thumbs-down, and where a subsequent state check, rule-based verifier, or LLM review found a problem. After failure attribution, these settle into regression cases. The concrete method is described later in "Failure Attribution" and "End-to-End and Trajectory-Prefix Regression Tasks." This source is the most expensive and also the most accurate, because it comes directly from what users actually encountered. -### Systematic Design of Task Distribution +In the early stage there are usually only public benchmarks and a small hand-written business set; once the system has been running in production for a while, cases fed back from production trajectories become the main body. -Task distribution needs to systematically cover capability dimensions, difficulty dimensions, scenario dimensions, and edge cases. GAIA pursues generality—most tasks require a combination of reasoning, multimodality, browsing, and tool use. τ²-bench deliberately designs "trap tasks"—a user claims "customer service has approved the cancellation" when the cancellation doesn't actually comply with policy—to test whether the Agent holds its judgment under pressure and misdirection. OSWorld is based on a dual-dimension matrix of operation type (file IO / desktop application / web application / cross-application workflow) and application domain, spanning three operating systems (research shows strong cross-OS correlation; skills learned on one system can transfer to others). Terminal-Bench includes "cross-technology stack combination tasks" to test systems thinking (e.g., a resharding task combining data processing + file operations + Python engineering). +## Automated Evaluation Methods -### Data Quality Control and Iterative Improvement +The benchmarks discussed in the preceding sections have one thing in common: their verifiers are almost all deterministic. SWE-bench runs a test suite, AndroidWorld asserts the final UI state, GAIA does exact string matching, and τ²-bench's four layers of checks are likewise executed entirely in code. There are good reasons for this choice: deterministic verification adds no model overhead, results are fully reproducible, it can be folded into continuous integration like a unit test, and it makes ranking across models straightforward. -SWE-Bench Verified is a model of quality control. OpenAI randomly selected 1,699 tasks from the original 2,294 for human evaluation, recruiting 93 Python-proficient developers. Annotators had to perform multiple checks: whether the problem description was clear (could they understand what needed to be solved), whether the test cases were complete (covering all aspects and edge cases), whether the tests were stable (no flaky tests due to environment or randomness), whether the patch was correct (did it introduce new errors), and whether the difficulty was reasonable. After rigorous screening, only 500 passed (29%)—this high rejection rate is a necessary investment in evaluation quality. They also established standardized annotation guidelines, defining specific criteria and examples for each check to ensure consistency among different annotators. +The price is that it can only judge whether the final outcome is right; it cannot give the reason for an error. The failed τ²-bench task above scored 0, and that 0 says nothing about whether the Agent went wrong at line selection or skipped the data refuel step, still less about what to change next. For a public benchmark used for ranking, this is not a defect; for a production system that needs continuous improvement, it is exactly the information most needed. -τ²-bench introduces a separation of "known information" / "task instructions" (making the simulator behavior more realistic) and stricter completion conditions (e.g., "only excellent counts as solved; poor/fair/good are not accepted"), preventing "superficial fixes." +Production scenarios face a second difficulty: many judgments simply cannot be written as assertions that code can check. Whether a complaint response is appropriately worded, whether a research report omits a critical piece of information, whether a memory retrieval got a relationship between people wrong — none of these has a unique final state to query, nor can they be decided by keyword matching. -OSWorld-Verified is a model of iterative improvement. After its release in April 2024, OSWorld quickly became an important benchmark for multimodal Agent evaluation, but over 15 months of widespread use, more than 300 issues were uncovered. These issues fall into four categories: environment issues (anti-scraping measures on websites, CAPTCHAs, and dynamic content changes), task description issues (ambiguous phrasing), verification logic issues (too strict or too lenient), and initial state issues (incomplete configuration). A team of about 10 people from the University of Hong Kong worked closely with MoonShot AI, OpenAI, ByteDance Seed TARS, Anthropic, Simular, and others for two months to systematically fix these issues. Repair strategies were formulated for each category: environment issues were resolved by locking versions and offline backups, task descriptions were clarified by rewriting ambiguous phrasing, verification logic was balanced by manually establishing correct baselines and adjusting conditions, and initial states were enhanced by adding completeness checks. +Moving from public benchmarks to evaluation in production therefore requires the mode of verification to shift rightward along a spectrum whose horizontal axis is the **degree to which a task is mechanically verifiable**, as shown in Figure 7-4. -## Automated Evaluation Methods +![Figure 7-4: A Spectrum of Verification Modes, from Deterministic Verification to Model Judgment](images/fig7-4.svg) -With the evaluation environment, dataset, and clear metrics system in place, the core question becomes: how to score? For tasks with clear correct answers (e.g., math problems, SQL queries), simple binary judgment (correct/incorrect) is sufficient; but for open-ended tasks (e.g., customer service dialogues, report writing), more refined evaluation methods are needed. +The two instruments on the right of the spectrum consequently become the mainstay of production evaluation: a **Rubric** that breaks the vague question of "how good is it" into several separately scorable dimensions, and **LLM-as-a-Judge** that produces the score where no deterministic criterion exists. Only together can they turn a blanket failure rate back into concrete, fixable problems; combined with **failure attribution** in the second half of this section, they form the complete evaluation loop for a production Agent. -Code-based automatic verification only covers scenarios with standard answers; scoring open-ended tasks is the main topic of this section. Among these, the design of reward signal density (from binary rewards to process rewards to generative rewards) and training methods for reward models are left for systematic discussion in the post-training section of Chapter 8; this section answers a more fundamental question: how to use LLMs to automatically judge the output quality of open-ended tasks. +It should be said that moving rightward does not mean abandoning the left. Every check that can be written as a programmatic assertion should stay an assertion, and LLM judgment should be reserved for the dimensions that genuinely cannot be decided mechanically. Deterministic checks are cheaper and more stable, and they are far better suited to running as regression tests over the long term. ### LLM-as-a-Judge: The Core of Automated Evaluation -![Figure 7-4: LLM-as-a-Judge Pipeline](images/fig7-4.svg) +![Figure 7-5: LLM-as-a-Judge Pipeline](images/fig7-5.svg) + +Why is LLM-as-a-Judge needed? For open-ended tasks (e.g., generating reports, handling customer complaints, creative content), there are no standard answers for automatic comparison, and human evaluation is costly and difficult to scale. LLM-as-a-Judge balances the scalability of automation with human expert judgment by having a language model evaluate outputs against expert-defined scoring criteria (a Rubric). -Why is LLM-as-a-Judge needed? For open-ended tasks (e.g., generating reports, handling customer complaints, creative content), there are no standard answers for automatic comparison, and human evaluation is costly and difficult to scale. LLM-as-a-Judge balances the scalability of automation with human expert judgment by having a language model evaluate outputs against expert-defined scoring criteria (a Rubric). The method has known limitations, though: the judge model carries its own biases (most typically **length bias**—a tendency to score longer, more detailed responses higher even when they are no more correct), and repeated judgments of the same input can vary. Length bias in particular warrants specific countermeasures. Three common defenses are: penalize verbosity explicitly in the Rubric and cap response length per task type; in pairwise comparisons, bring the two candidates to similar lengths before judging; and regularly audit the correlation between scores and response length—if high scores almost always go to long responses, the judge has been swayed by length and the Rubric needs revision. To address these challenges systematically, Rubric design must follow the principles below: +The method has known limitations, though: the judge model carries its own biases, and repeated judgments of the same input can vary. The most typical is **length bias**, a tendency to score longer, more detailed responses higher even when they are no more correct — much as a human sitting an exam will pad out an answer they do not know, hoping to stumble onto a point or two. Three defenses are common: penalize verbosity explicitly in the Rubric and cap response length per task type; in pairwise comparisons, bring the two candidates to similar lengths before judging; and regularly audit the correlation between scores and response length — if high scores almost always go to long responses, the judge has been swayed by length and the Rubric needs revision. To address these challenges systematically, Rubric design must follow the principles below: **Rubric (Scoring Criteria): The Basis for LLM Judgment.** @@ -362,7 +367,7 @@ rubric: Give the judge both the Rubric and the Agent's response. It will score each dimension and explain why. Once results from dozens of cases are grouped by dimension and the low-scoring traces are replayed, a vague drop in success rate becomes a concrete diagnosis: retrieval missed a fact, the model linked the wrong people or events, or it added an unsupported claim. A useful Rubric tells the team not only how the system scored, but where to look next. -The following takes user memory as a concrete case, showing how to bring this general method down to an executable evaluation set and scorer. +The following takes user memory as a concrete case, showing how to bring this general method down to an executable evaluation set and verifier. > **Experiment 7-3 ★★: Building a Rubric-Based User Memory Evaluation System** > @@ -535,7 +540,7 @@ In practical model selection, we often face the question: "Which is better, A or ### Pairwise Comparison and Model Ranking -![Figure 7-5: Elo Rating and Pairwise Comparison Ranking](images/fig7-5.svg) +![Figure 7-6: Elo Rating and Pairwise Comparison Ranking](images/fig7-6.svg) **Elo Rating** (a ranking system originally designed for chess) quantifies the relative ability of models through a large number of pairwise matchups: the larger the rating difference, the higher the expected win rate for the stronger model. For example, if Model A has a rating of 1200 and Model B has a rating of 1000, the Elo system would predict A's win rate to be approximately 76%. If B unexpectedly wins, B gains more points and A loses more—an upset triggers a larger correction, which is what lets rankings converge quickly on true ability. The statistical foundation is the **Bradley-Terry model**: each model is abstracted as a latent "strength score," and the probability of one beating another in a matchup is determined by the difference between their scores. Elo is the engineering implementation of this model in online-update form. @@ -699,7 +704,7 @@ When validating several hypotheses in parallel, also account for **multiple comp Evaluation-driven decisions (whether for model selection or continuous iteration) rely on high-quality operational data. Below, we first introduce how to systematically collect this data (observability), and then discuss how to translate evaluation results into system improvements. -![Figure 7-6: Observability Technology Stack](images/fig7-6.svg) +![Figure 7-7: Observability Technology Stack](images/fig7-7.svg) Observability is a concept borrowed from distributed systems: you cannot open the system and watch it work; you infer what is happening from the logs, metrics, and traces it emits—the way a doctor, unable to see inside a patient, diagnoses from temperature, blood pressure, and imaging. Agent systems make this harder still: the same input can produce different outputs, multi-round reasoning and tool calls make execution paths extremely complex, and the model's "thinking" is completely opaque from outside. @@ -719,11 +724,11 @@ With a comprehensive evaluation system and dataset in place, the key is to trans The following case comes from a real, deliberately narrow AndroidWorld iteration in the companion repository. It covers four Wi-Fi settings tasks on an API 35 emulator, with one matched run per task. It is not the full 116-task benchmark and does not replace a rerun in the reference API 33 environment. Its value is not an overall score; it is the sequence of decisions from one result to the next. -![Figure 7-7: Benchmark to Improvement Loop](images/fig7-7.svg) +![Figure 7-8: Benchmark to Improvement Loop](images/fig7-8.svg) From the perspective of Harness engineering, this section is essentially about the methodology for iterative Harness optimization—using evaluation data to identify weak points in the Harness (insufficient context? missing constraints? inadequate validation? untimely feedback?), making targeted improvements, and then re-evaluating, forming a closed loop for the Harness's continuous evolution. -Before analyzing any benchmark report, note an easily overlooked principle: **when Agent performance drops, check the evaluation system first, then the Agent**. The common mistake is to start editing Agent code the moment a score falls, ignoring the possibility that the evaluation system broke first—steer by a distorted signal and the correction is wrong from the very first step. Typical evaluation-side failures include: the runtime environment running out of resources and killing processes (which shows up as random failures), bugs in the scorer that mark correct answers as failures, and test cases drifting out of sync with production scenarios. In the headline numbers, all of these look identical to model degradation; only a review of the full traces can tell them apart. +Before analyzing any benchmark report, note an easily overlooked principle: **when Agent performance drops, check the evaluation system first, then the Agent**. The common mistake is to start editing Agent code the moment a score falls, ignoring the possibility that the evaluation system broke first—steer by a distorted signal and the correction is wrong from the very first step. Typical evaluation-side failures include: the runtime environment running out of resources and killing processes (which shows up as random failures), bugs in the verifier that mark correct answers as failures, and test cases drifting out of sync with production scenarios. In the headline numbers, all of these look identical to model degradation; only a review of the full traces can tell them apart. ### Reading a Benchmark Report: The Art of Problem Discovery @@ -828,7 +833,7 @@ The endpoint of evaluation is not scoring, but improvement. This chapter has alr Here is how the two ends of the bridge meet. Assets accumulated on the evaluation side convert almost seamlessly into training signals: a well-defined Rubric or validator is essentially a reward function for **Reinforcement Learning with Verifiable Rewards (RLVR)**—the scoring script becomes the reward script; whether a test passes or a state meets the standard serves both as an evaluation criterion and as a reinforcement learning reward. But training brings demands evaluation never had to worry about. The first is **reliable reset semantics**: training runs millions of episodes (an episode is one complete interaction round from an initial state to task completion), and each episode must be able to reset the environment to a deterministic, clean initial state; otherwise, the gradient signal will be contaminated by residual states from the previous episode. The second is **throughput far exceeding evaluation**: a few thousand evaluations are enough to draw conclusions, but training requires feeding the model millions of interactions within an acceptable wall-clock time; the degree of environment parallelism and per-instance overhead directly determine whether training is feasible. These two points—validators turned into reward functions, and training-grade reset and throughput—will be elaborated in Chapter 8. -![Figure 7-8: Simulation Fidelity Spectrum](images/fig7-8.svg) +![Figure 7-9: Simulation Fidelity Spectrum](images/fig7-9.svg) On the **digital environment** side, the AWorld framework builds a controllable MCP server sandbox for GAIA tasks, providing 26 MCP servers covering 126 tool functions, avoiding the bans and uncontrollable side effects of directly accessing real APIs. All tool calls are replayable and auditable. AWorld's distributed architecture reduces the traditional serial execution time from 7695 seconds to 525 seconds (a 14.6x speedup), and the environment's stateless design makes each instance completely independent, supporting efficient parallelism. @@ -839,7 +844,7 @@ On the **embodied environment** side, RoboTwin2 builds dual-arm manipulation tas > Set up a simulation environment for robot manipulation. Read `ch7/SimpleVLA-RL` and the OpenVLA documentation to understand the architecture of the Vision-Language-Action model (end-to-end integration of a vision encoder, language model, and action decoder, projecting images and text into a shared semantic space). Configure the RoboTwin2 environment, understanding the observation space (three-view RGB + 14-dimensional joint state) and action space (14-dimensional control vector). Study the environment randomization mechanism and spatial constraint logic in `move_can_pot`. Evaluate the pretrained model, recording its success rate, completion time, and failure modes, with a focus on the impact of the action chunking mechanism. > > -> ![Figure 7-9: OpenVLA and RoboTwin2 Embodied Intelligence Environment](images/fig7-9.svg) +> ![Figure 7-10: OpenVLA and RoboTwin2 Embodied Intelligence Environment](images/fig7-10.svg) > > @@ -851,7 +856,7 @@ High-fidelity environments support better transfer to the real world but have hi ## Chapter Summary -This chapter has revolved around one core question: how do you tell whether an Agent has gotten better or worse? From defining success criteria and distinguishing Pass@k, Best@k and Pass consecutive@k, to building reproducible test environments, designing datasets that withstand leakage, having an LLM serve as judge and producing auditable attributions for failed trajectories, and finally using evaluation results to drive model selection and iteration—every link in this chain affects how much you can trust the conclusion. +This chapter has revolved around one core question: how do you tell whether an Agent has gotten better or worse? The chain has four stages — first pin down what counts as success (the differing bases of Pass@k, Best@k, and Pass consecutive@k), then settle where the tasks come from (public benchmarks, a self-built business set, and production trajectory feedback), then choose how verification is done (from deterministic verifiers to checklists, Rubric plus LLM judgment, and finally pairwise comparison), and finally turn scores into decisions (statistical significance, failure attribution, regression tasks, and model selection). Every stage affects how much you can trust the conclusion. In terms of the book's larger structure, this chapter builds the **evidence** segment of Chapter 1's discovery loop: failure attribution determines whether later proposals have anything solid to rest on. @@ -859,7 +864,7 @@ Trajectory-prefix boundary evaluation makes a further point: **obtaining a piece Core methodology: Observe → Hypothesize → Experiment → Validate → New Understanding → New Hypothesis, transforming Agent engineering from experience-driven "alchemy" to data-driven scientific engineering. -The evaluation system introduced in this chapter forms a complete closed loop: **Evaluation Environment** provides automated testing infrastructure → **Evaluation Dataset** defines test cases → **Automated Evaluation Methods** (LLM-as-a-Judge and Rubric) score Agent performance → **Benchmark Analysis** reveals improvement directions → **System Improvements** fix issues → Update the evaluation environment and dataset, starting a new iteration cycle. +The evaluation system introduced in this chapter forms a complete closed loop: **Evaluation Environment** provides automated testing infrastructure → **Evaluation Dataset** defines test cases → **Automated Evaluation Methods** (deterministic verifiers, LLM-as-a-Judge, and Rubric) score Agent performance → **Benchmark Analysis** reveals improvement directions → **System Improvements** fix issues → Update the evaluation environment and dataset, starting a new iteration cycle. The evaluation system established in this chapter serves not only the optimization of the current system but also provides a critical foundation for the next two chapters. Chapter 8 turns evaluation environments and data into inputs for model post-training; Chapter 9 turns multidimensional evaluation of production trajectories into updates to knowledge, instructions, and procedures. diff --git a/book-en/images/fig7-1.svg b/book-en/images/fig7-1.svg index f301aacbe..f63ade03a 100644 --- a/book-en/images/fig7-1.svg +++ b/book-en/images/fig7-1.svg @@ -1,19 +1,62 @@ - - - -Layer 1: Evaluate the Environment -"Where to test" — Tool-calling / Human-computer interaction / Simulation environment - - -Layer 2: Evaluation Methods -"How to judge" — Dataset design · LLM-as-a-Judge · Pairwise comparison and ranking - - -Layer 3: Evaluation-Driven Decisions -"What to do after testing" — Model selection · Architecture optimization · Continuous iteration - -Engineering Themes Throughout the Chapter -• Observability -• Simulation environment -• Internal evaluation - \ No newline at end of file + + + + + + + + +① Defining success +Pass@k for the capability ceiling · Pass^k for business reliability + + + +② Where tasks come from + +Public benchmarks +Borrow methods · screen models + +Self-built business set +The real task distribution + +Production feedback +Output of failure attribution + + + +③ How verification is done +← ordered by how mechanically verifiable the task is → + +Deterministic +SWE-bench + + +Checklist +τ²-bench + + +Rubric + LLM +Open-ended tasks + + +Pairwise +Chatbot Arena + + + +④ Using the results +Significance → Attribution → Regression tasks → Model & Harness iteration + + +Regression tasks become new cases + + +Supporting infrastructure +Observability · Internal eval infra (ablation / AB / flags) · Simulation (Chapter 8) + diff --git a/book-en/images/fig7-10.svg b/book-en/images/fig7-10.svg new file mode 100644 index 000000000..6762ce35b --- /dev/null +++ b/book-en/images/fig7-10.svg @@ -0,0 +1,69 @@ + + + + +Multimodal observation + +Head camera +224×224 RGB + +Left wrist camera +224×224 RGB + +Right wrist camera +224×224 RGB + +14-dimensional joint state vector + +Vision-Language-Action model (VLA) + +Vision encoder +SigLIP → visual tokens + + +Language model +Llama 2 7B backbone + + +Action decoder +→ 14-dimensional continuous control vector +Action chunking: generate 25 consecutive actions at once + + + +Instruction: "Put the can into the pot" + + +SAPIEN physics engine + +Dual-arm robot +7 DOF each = 14-dimensional action + +Environment randomization +Position 60cm / orientation ±22.5° + +Collision detection + physics simulation +Rigid body / soft body / friction + +Action + +Observation + +Evaluation metrics + +Success rate +Can inside pot +and not fallen + +Completion time +25 steps × 25 actions += 625 control steps + +Generalization ability +Cross-position/orientation +/Appearance variant + +Sim-to-Real +Domain randomization +→ Real migration + \ No newline at end of file diff --git a/book-en/images/fig7-3.svg b/book-en/images/fig7-3.svg index d8f6fcc1c..34bdad643 100644 --- a/book-en/images/fig7-3.svg +++ b/book-en/images/fig7-3.svg @@ -1,68 +1,76 @@ - - + + + + + + + - -User Simulator (LLM) - -Known Information: -Name: Sarah Johnson -Booking: BK-98712 -Task Instruction: -"There seems to be a problem with the flight" -→ Gradually reveal details -→ Do not proactively provide the booking number - -Agent (To Be Evaluated) - - -LLM Reasoning + Strategy Selection -① May I have your booking number? -② lookup_booking(BK-98712) -③ Flight UA123 has been canceled -④ cancel_booking(BK-98712) -⑤ Refund $150, 3-5 business days - -Tools + Database - -lookup_booking -Query booking details -modify_booking -Modify booking status -cancel_booking -Cancel and refund -search_flights -Search for alternative flights -send_notification -Send confirmation notification - -DB State: -bookings, users, flights - -Dialogue - - -Tool Call - - -Dual-control environment: User simulator can also directly operate the shared environment (tools + database) - -After task completion: Multi-layer verification - -DB status check - -booking.status == 'cancelled' -refund_record EXISTS -refund.amount == 150.00 - -Dialogue content verification - -Contains 'refund' + amount -Contains 'arrival time' -No false information present - -Process compliance check - -Obtain user confirmation before modification -No unauthorized operation -No excessive transfer to human agent - \ No newline at end of file + + +User simulator (LLM) +known_info: John Smith / 555-123-2002 / in France +task_instructions: disclosure · emotion · grounding +Acceptance: only excellent counts as resolved + + + +Agent (under evaluation) +Input: ticket + domain policy +Not visible: the real state of the device +Can only guide the user, cannot act for them + + + +Multi-turn dialogue +Progressive disclosure + + + +Shared environment (dual-control: both sides can change state) + +Device-side state +Airplane mode ON · roaming OFF · data saver · data left +User tools: toggle_airplane_mode / toggle_roaming + check_status_bar / run_speed_test + +Carrier-side database +Customer C1001 · lines L1001/L1002/L1003 · plans · bills +Agent tools: get_customer_by_phone / get_data_usage + enable_roaming / refuel_data + + + + + + +The user's toggle_roaming changed the environment; the Agent must call a tool again to see it — verification covers this + + + +After the task: four layers of checks + aggregation rule + +env_assertions +Mobile data available +Speed test ≥ 200 / excellent + +actions +toggle_airplane_mode +requestor must be user + +communicate_info +Was required info conveyed +null for this task + +nl_assertions +Natural-language judgment +null for this task +reward_basis = ["ENV_ASSERTION"] → only layer one counts; the rest are recorded but excluded from the reward + diff --git a/book-en/images/fig7-4.svg b/book-en/images/fig7-4.svg index 69b4cb59d..180122db5 100644 --- a/book-en/images/fig7-4.svg +++ b/book-en/images/fig7-4.svg @@ -1,53 +1,54 @@ - - + + + + + + - -Rubric - -Factual Correctness: Essential -Logical Coherence: Important -Hallucination Detection: Veto ⚠ -Completeness: Important - -Candidate Answer - -Agent Output: -"Refund processed, $150 will be credited within - 3-5 business days." - - -Reference Solution (Optional) - -Standard Answer / Scoring Points: -Must include refund amount -Must include credit time -Cannot promise a specific date - - - - -Judge Model (GPT-5 / Gemini 2.5) -Multi-source heterogeneous evaluation to prevent same-source bias - - -Structured evaluation output - -Factual Correctness -4/4 -Amount and time are both accurate -Completeness -3/4 -Missing explanation of refund method -Hallucination Detection -PASS -No false information -Logical Coherence -4/4 -Clear causal relationship - -Scoring Aggregation Strategy -Weighted average: Σ(weight × dimension score) -Veto: Hallucination=FAIL → total score=0 -Multi-judge: median of 3 judges -Edge case flag: disagreement >2 points → human review - \ No newline at end of file + +How mechanically verifiable the task is: high +low + + +Deterministic +Unique final state +Pass / fail +SWE-bench runs tests + + + +Checklist +Several deterministic checks +Aggregated by a declared basis +τ²-bench four layers + + + +Rubric + LLM +Dimensions exist but resist code +Scores per dimension with reasons +Service quality, report writing + + + +Pairwise +Even dimensions are hard to state +Only judges A versus B +Chatbot Arena + + +Deterministic verification +Fully reproducible, CI-friendly, low cost +Cost: judges right or wrong, not where the fault is + + +Model judgment +Yields diagnostic dimensions, covers non-assertable tasks +Cost: judge bias and variance, higher price + diff --git a/book-en/images/fig7-5.svg b/book-en/images/fig7-5.svg index 48eba2457..69b4cb59d 100644 --- a/book-en/images/fig7-5.svg +++ b/book-en/images/fig7-5.svg @@ -1,56 +1,53 @@ - + - -Chatbot Arena Anonymous Battle - -Model A (Anonymous) - -"Refund processed, will arrive in 3-5 - business days to your account" -VS - -Model B (Anonymous) - -"Okay, refund will be processed" - - -User blind pick → A is better - -Elo Update Formula -Expected win rate E_A = 1/(1+10^((R_B-R_A)/400)) | Update: R_A' = R_A + K*(1-E_A) -Live Leaderboard (Example) -Rank -Model -Elo -Win rate vs #2 - -1 -Claude 4 Opus -1352 -— -2 -GPT-5 -1318 -— -3 -Gemini 2.5 Pro -1290 -45% -4 -DeepSeek R2 -1265 -42% -5 -Qwen 3 Max -1230 -39% -6 -Llama 4 405B -1198 -36% - - -GRPO: Introducing Pairwise Comparison into RL Training -A set of candidate responses → Normalize relative advantage → Policy update (bypass explicit reward model) + +Rubric + +Factual Correctness: Essential +Logical Coherence: Important +Hallucination Detection: Veto ⚠ +Completeness: Important + +Candidate Answer + +Agent Output: +"Refund processed, $150 will be credited within + 3-5 business days." + + +Reference Solution (Optional) + +Standard Answer / Scoring Points: +Must include refund amount +Must include credit time +Cannot promise a specific date + + + + +Judge Model (GPT-5 / Gemini 2.5) +Multi-source heterogeneous evaluation to prevent same-source bias + + +Structured evaluation output + +Factual Correctness +4/4 +Amount and time are both accurate +Completeness +3/4 +Missing explanation of refund method +Hallucination Detection +PASS +No false information +Logical Coherence +4/4 +Clear causal relationship + +Scoring Aggregation Strategy +Weighted average: Σ(weight × dimension score) +Veto: Hallucination=FAIL → total score=0 +Multi-judge: median of 3 judges +Edge case flag: disagreement >2 points → human review \ No newline at end of file diff --git a/book-en/images/fig7-6.svg b/book-en/images/fig7-6.svg index 1ccc604da..48eba2457 100644 --- a/book-en/images/fig7-6.svg +++ b/book-en/images/fig7-6.svg @@ -1,48 +1,56 @@ - - - -Execution trace tree (single task) - -Trace: Check Beijing weather for user tomorrow (3.2s, $0.008) - -LLM Call: Intent recognition -Claude 4 Sonnet · 0.4s · 320 tokens - -Tool：get_weather(Beijing) -MCP Server · 1.8s · 200ms TTFT - -├─ HTTP Request -api.weather.com · 1.6s - -└─ Response Parse -JSON → Structured weather data - -LLM Call: Generate response -Claude 4 Sonnet · 0.8s · 580 tokens - -Tool：send_message(user) -0.2s · Contains weather summary - - - - - - - -Monitoring dashboard - -Cost tracking -Today: $12.30 (1,200 calls) -This month: $340 (34K calls) -Anomaly: task#892 looped search 14 times, cost $2.1 - -Performance monitoring -P50 / P95 / P99 latency: 2.1s / 8.4s / 15.2s -Tool success rate: 94.3% - -Quality audit -Task success rate: 87% Hallucination trigger: 2.1% -Security violations: 0 (this month) User satisfaction: 4.3/5 - -Closed loop: Trace data → Identify issues → A/B testing →Prompt version management → Continuous optimization - + + + + +Chatbot Arena Anonymous Battle + +Model A (Anonymous) + +"Refund processed, will arrive in 3-5 + business days to your account" +VS + +Model B (Anonymous) + +"Okay, refund will be processed" + + +User blind pick → A is better + +Elo Update Formula +Expected win rate E_A = 1/(1+10^((R_B-R_A)/400)) | Update: R_A' = R_A + K*(1-E_A) +Live Leaderboard (Example) +Rank +Model +Elo +Win rate vs #2 + +1 +Claude 4 Opus +1352 +— +2 +GPT-5 +1318 +— +3 +Gemini 2.5 Pro +1290 +45% +4 +DeepSeek R2 +1265 +42% +5 +Qwen 3 Max +1230 +39% +6 +Llama 4 405B +1198 +36% + + +GRPO: Introducing Pairwise Comparison into RL Training +A set of candidate responses → Normalize relative advantage → Policy update (bypass explicit reward model) + \ No newline at end of file diff --git a/book-en/images/fig7-7.svg b/book-en/images/fig7-7.svg index 7ff1dd778..1ccc604da 100644 --- a/book-en/images/fig7-7.svg +++ b/book-en/images/fig7-7.svg @@ -1,56 +1,48 @@ - - - - -① Observation: Diagnostic Report -Overall Success Rate: 88% (102/116) -transcription: 0% complex_ui: 17% -math_counting: 0% Wi-Fi Operation: 0% -Task 82,102-115 Concentrated Failures - -② Hypothesis: Three-Layer Improvement Framework - -Surface Layer -H1 Set Navigation Prompt H2 UI Rules - -Middle Layer -H3 Fix Multimodal Pipeline H4 Thinking - -Deep Layer -H5 GPT-5 H6 UI Element Tree - - -③ Experiment: Phased Validation (5 runs × 116 tasks per configuration) - -H1 Navigation -Setup 0%→75% -token+8% - -H3 Multimodal -Transcription 0%→80% -Latency +1s - -H4 Thinking -Counting 0%→70% -Latency 3x! - -H6 Element Tree -UI 17%→52% -token+30% - -④ Decision: Cost-Benefit Trade-off -✓ H1+H3: Low Cost, High Benefit → Deploy -✗ H4: Only 8% Tasks Benefit but 3x Latency → Reject -✓ H6: 35% Improvement / 30% Cost → Deploy -✗ H5: 15s/Step Unacceptable → Alternative - -⑤ Iteration: New Cycle -Deploy H1+H3+H6 → 88%→94% -New Report Shows Different Failure Modes: - H7: Conditional Thinking Enabled - H8: Expand gesture action space - -↑ Loop - -Methodology: Observe → Hypothesize → Experiment → Decide → Iterate = From alchemy to scientific engineering - \ No newline at end of file + + + +Execution trace tree (single task) + +Trace: Check Beijing weather for user tomorrow (3.2s, $0.008) + +LLM Call: Intent recognition +Claude 4 Sonnet · 0.4s · 320 tokens + +Tool：get_weather(Beijing) +MCP Server · 1.8s · 200ms TTFT + +├─ HTTP Request +api.weather.com · 1.6s + +└─ Response Parse +JSON → Structured weather data + +LLM Call: Generate response +Claude 4 Sonnet · 0.8s · 580 tokens + +Tool：send_message(user) +0.2s · Contains weather summary + + + + + + + +Monitoring dashboard + +Cost tracking +Today: $12.30 (1,200 calls) +This month: $340 (34K calls) +Anomaly: task#892 looped search 14 times, cost $2.1 + +Performance monitoring +P50 / P95 / P99 latency: 2.1s / 8.4s / 15.2s +Tool success rate: 94.3% + +Quality audit +Task success rate: 87% Hallucination trigger: 2.1% +Security violations: 0 (this month) User satisfaction: 4.3/5 + +Closed loop: Trace data → Identify issues → A/B testing →Prompt version management → Continuous optimization + diff --git a/book-en/images/fig7-8.svg b/book-en/images/fig7-8.svg index 52e636831..7ff1dd778 100644 --- a/book-en/images/fig7-8.svg +++ b/book-en/images/fig7-8.svg @@ -1,41 +1,56 @@ - + - - -Simulation fidelity → -Scalability - - - -↑ - -Mock API -unit test level -million times/hour - -AWorld -MCP sandbox -126 tool functions -525s/round distributed - -AndroidWorld -Simulator -116 real-world application tasks -UI Automator - -Isaac Gym -GPU parallelism -thousands of parallel instances -Slightly compromised accuracy - -RoboTwin2 -physics engine -High-precision collision -Single-instance CPU - -real world -Perfect fidelity -Non-resettable - + +① Observation: Diagnostic Report +Overall Success Rate: 88% (102/116) +transcription: 0% complex_ui: 17% +math_counting: 0% Wi-Fi Operation: 0% +Task 82,102-115 Concentrated Failures + +② Hypothesis: Three-Layer Improvement Framework + +Surface Layer +H1 Set Navigation Prompt H2 UI Rules + +Middle Layer +H3 Fix Multimodal Pipeline H4 Thinking + +Deep Layer +H5 GPT-5 H6 UI Element Tree + + +③ Experiment: Phased Validation (5 runs × 116 tasks per configuration) + +H1 Navigation +Setup 0%→75% +token+8% + +H3 Multimodal +Transcription 0%→80% +Latency +1s + +H4 Thinking +Counting 0%→70% +Latency 3x! + +H6 Element Tree +UI 17%→52% +token+30% + +④ Decision: Cost-Benefit Trade-off +✓ H1+H3: Low Cost, High Benefit → Deploy +✗ H4: Only 8% Tasks Benefit but 3x Latency → Reject +✓ H6: 35% Improvement / 30% Cost → Deploy +✗ H5: 15s/Step Unacceptable → Alternative + +⑤ Iteration: New Cycle +Deploy H1+H3+H6 → 88%→94% +New Report Shows Different Failure Modes: + H7: Conditional Thinking Enabled + H8: Expand gesture action space + +↑ Loop + +Methodology: Observe → Hypothesize → Experiment → Decide → Iterate = From alchemy to scientific engineering \ No newline at end of file diff --git a/book-en/images/fig7-9.svg b/book-en/images/fig7-9.svg index 6762ce35b..52e636831 100644 --- a/book-en/images/fig7-9.svg +++ b/book-en/images/fig7-9.svg @@ -1,69 +1,41 @@ - - + + - -Multimodal observation - -Head camera -224×224 RGB - -Left wrist camera -224×224 RGB - -Right wrist camera -224×224 RGB - -14-dimensional joint state vector - -Vision-Language-Action model (VLA) - -Vision encoder -SigLIP → visual tokens - - -Language model -Llama 2 7B backbone - - -Action decoder -→ 14-dimensional continuous control vector -Action chunking: generate 25 consecutive actions at once - - - -Instruction: "Put the can into the pot" - - -SAPIEN physics engine - -Dual-arm robot -7 DOF each = 14-dimensional action - -Environment randomization -Position 60cm / orientation ±22.5° - -Collision detection + physics simulation -Rigid body / soft body / friction - -Action - -Observation - -Evaluation metrics - -Success rate -Can inside pot -and not fallen - -Completion time -25 steps × 25 actions -= 625 control steps - -Generalization ability -Cross-position/orientation -/Appearance variant - -Sim-to-Real -Domain randomization -→ Real migration + + +Simulation fidelity → +Scalability + + + +↑ + +Mock API +unit test level +million times/hour + +AWorld +MCP sandbox +126 tool functions +525s/round distributed + +AndroidWorld +Simulator +116 real-world application tasks +UI Automator + +Isaac Gym +GPU parallelism +thousands of parallel instances +Slightly compromised accuracy + +RoboTwin2 +physics engine +High-precision collision +Single-instance CPU + +real world +Perfect fidelity +Non-resettable + \ No newline at end of file diff --git a/book-es/chapter7.es.md b/book-es/chapter7.es.md index 7ee7bf608..306bcc93c 100644 --- a/book-es/chapter7.es.md +++ b/book-es/chapter7.es.md @@ -17,57 +17,117 @@ La evaluación nos proporciona una base científica para la toma de decisiones: Desde la perspectiva de ingeniería del Harness introducida en el Capítulo 1, la evaluación desempeña el papel central de "verificación" dentro del Harness. Una noción fundamental es: **el objeto de evaluación no debe ser únicamente el modelo, sino la combinación del modelo y el Harness**. Un mismo modelo puede tener un rendimiento drásticamente diferente en distintos Harnesses (algunos equipos han logrado mejorar significativamente el rendimiento del mismo modelo en tareas de terminal optimizando únicamente el Harness, como se detalla en el Capítulo 5). Esto significa que cuando un Agente funciona mal en una evaluación, la dirección de mejora podría no ser cambiar de modelo, sino optimizar un componente específico del Harness (prompts, diseño de herramientas, bucles de retroalimentación). Un sistema de evaluación maduro debe ser capaz de distinguir entre dos tipos de problemas fundamentalmente diferentes: "capacidad insuficiente del modelo" y "defectos de diseño del Harness". **El método habitual para distinguir ambos problemas es el experimento de reemplazo de modelo (model swap)**: fijar el Harness y cambiar únicamente a un modelo más fuerte o más débil, observando la magnitud del cambio en la puntuación. Si al cambiar a un modelo más fuerte la puntuación no sube, el cuello de botella está en el Harness; si al cambiar a un modelo más débil la puntuación cae drásticamente y fluctúa según la capacidad del modelo, la interpretación más directa es que el cuello de botella es la capacidad propia del modelo y el rendimiento actual está determinado principalmente por él (en cuanto a si esto se debe a que la tarea en sí es difícil o a que el Harness depende en exceso de las a priori del modelo, se requiere un análisis posterior). Nótese que esto es diferente de los "experimentos de ablación" mencionados anteriormente: la ablación consiste en **desactivar un componente del Harness** para ver cómo cambia el rendimiento general, mientras que el reemplazo de modelo consiste en **fijar el Harness y cambiar solo el modelo**: la primera técnica ubica qué componente interno del Harness es importante, mientras que la segunda distingue si el cuello de botella está en el modelo o en el Harness. El valor del sistema de evaluación se vuelve aún más evidente en una era de rápida evolución de los modelos. La capacidad de los modelos continúa evolucionando rápidamente, pero que un nuevo modelo obtenga mejores puntuaciones en benchmarks públicos no significa que vaya a funcionar mejor en tu tarea específica; de hecho, puede sufrir regresiones de rendimiento —es decir, que la nueva versión sea peor en ciertos aspectos que la versión anterior). Solo probando exhaustivamente en tu propio conjunto de datos de evaluación podrás tomar decisiones de actualización impulsadas por datos. Más aún, un sistema de evaluación completo hace que "desarrollar productos para los modelos del futuro" sea una estrategia viable: incluso si el modelo actual no es suficiente para sustentar el uso comercial, se puede completar primero el desarrollo del producto y establecer un conjunto de datos de evaluación, rastreando continuamente el rendimiento de los nuevos modelos para salir al mercado tan pronto como se alcance el umbral. +Un sistema de evaluación puede descomponerse en cuatro etapas: qué cuenta como éxito, de dónde salen las tareas, quién verifica y cómo se convierte una puntuación en una decisión, tal como muestra la Figura 7-1. + +![Figura 7-1 Las Cuatro Etapas del Sistema de Evaluación de un Agent](images/fig7-1.svg) + +## Anatomía de una tarea de evaluación: el dominio telecom de τ²-bench + +Empecemos por diseccionar por completo una tarea real del dominio telecom de τ²-bench. El código fuente está en el repositorio, en `chapter7/tau2-bench`, y el fichero de tareas es `data/tau2/domains/telecom/tasks_small.json`. + +### Los cuatro componentes de la definición de una tarea + +A continuación se muestra una de las tareas de ese fichero, abreviada para facilitar la lectura. + +```jsonc +{ + "id": "[mobile_data_issue]airplane_mode_on|user_abroad_roaming_enabled_off", + + // El ticket que recibe el Agent + "ticket": "El móvil del usuario no consigue conectarse a internet y la barra de + estado muestra 'No Service'. Cliente John Smith, número 555-123-2002, + actualmente en Francia. Solo se considera resuelto si el test de + velocidad devuelve excellent. No quiere cambiar de tarifa, pero + aceptaría recargar 2,0 GB de datos si hiciera falta.", + + // La pauta de comportamiento que recibe el simulador de usuario + "user_scenario": { "instructions": { + "known_info": "You are John Smith with phone number 555-123-2002. + You are currently abroad in France.", + "unknown_info": null, + "task_instructions": + "…express mild frustration after the first unsuccessful attempt. + You will consider the issue resolved only when speed test returns + excellent internet speed and nothing else. If it returns poor, fair + or good, you will not consider the issue resolved. + Whenever the agent asks you about your device, always ground your + responses on the results of tool calls. … + Never make up the results of tool calls." + }}, + + // Antes de ejecutar, ambos lados se reinician al mismo punto de partida + "initial_state": { "initialization_actions": [ + { "env_type": "user", "func_name": "turn_airplane_mode_on" }, + { "env_type": "user", "func_name": "turn_roaming_off" }, + { "env_type": "assistant", "func_name": "enable_roaming", + "arguments": { "customer_id": "C1001", "line_id": "L1002" } } + ]}, + + // Criterios de puntuación + "evaluation_criteria": { + "actions": [ + { "requestor": "user", "name": "toggle_airplane_mode" }, + { "requestor": "user", "name": "toggle_roaming" } + ], + "env_assertions": [ + { "func_name": "assert_mobile_data_status", "expected_status": true }, + { "func_name": "assert_internet_speed", + "expected_speed": 200, "expected_desc": "excellent" } + ], + "communicate_info": null, + "nl_assertions": null, + "reward_basis": ["ENV_ASSERTION"] + } +} +``` -> **Guía del Capítulo** -> -> Este capítulo construye un sistema de evaluación completo en tres niveles. El primer nivel es el **entorno de evaluación** ("dónde probar"): cómo construir un entorno de pruebas automatizado y reproducible, incluyendo tanto el paradigma de llamada a herramientas como el de interacción humano-computadora. El segundo nivel abarca los **métodos de evaluación** ("cómo juzgar"): desde los principios de diseño de conjuntos de datos y la arquitectura de métricas (qué medir), pasando por la evaluación automatizada mediante LLM-as-a-Judge (utilizando modelos de lenguaje como jueces), hasta la comparación por pares y el ranking de modelos. El tercer nivel es la **toma de decisiones impulsada por la evaluación** ("qué hacer tras medir"): transformar los resultados de evaluación en guías de acción para la selección de modelos, la optimización de arquitectura y la iteración continua, utilizando la significatividad estadística para determinar si las diferencias observadas son reales y confiables. Además, este capítulo analiza la observabilidad y la infraestructura interna de evaluación para Agentes en producción, concluyendo con la presentación de entornos de simulación que conectan con el post-entrenamiento del Capítulo 8. -> -> El concepto central a lo largo de todo el capítulo es: **el valor primario de un sistema de evaluación no es calificar al sistema actual, sino permitirte seguir el ritmo de la evolución de los modelos de forma rápida y confiable**. Cuando se lanza un modelo más potente o más económico, un equipo con un sistema de evaluación completo puede tomar decisiones de migración en cuestión de horas, mientras que un equipo sin evaluación solo puede actuar por intuición o esperar el feedback de la comunidad (en el competitivo mercado de los Agentes, esta brecha de velocidad puede determinar el éxito o el fracaso). +Hay cuatro decisiones de diseño en esta definición que conviene desarrollar. -![Figura 7-1 Tres Niveles del Sistema de Evaluación](images/fig7-1.svg) +**El límite del conocimiento del usuario está modelado de forma explícita.** `known_info` contiene únicamente tres datos: nombre, número de teléfono y país de estancia. Las dos causas reales de la avería —el modo avión activado y la itinerancia de datos desactivada— no están ahí. El usuario no lo sabe, de modo que no puede decirlo por su cuenta, y el Agent solo puede obtenerlo preguntando y pidiéndole que lo compruebe. Así se implementa la **divulgación progresiva de información (Progressive Information Disclosure)** en el nivel de la definición de la tarea: no atando al simulador con un prompt del tipo «no lo cuentes todo de golpe», sino modelando el alcance del conocimiento del usuario como un campo propio. La mayoría de los benchmarks presentan el requisito completo al empezar la tarea, mientras que la primera frase de un usuario real suele ser poco más que «no me funciona internet». Aclarar la petición hasta hacerla ejecutable forma parte, en sí misma, de lo que un Agent debe saber hacer. -## Un Ejemplo Concreto de Evaluación +**El simulador recibe una pauta de comportamiento, no un guion de frases.** `task_instructions` mezcla tres tipos de restricción: el ajuste emocional (mostrar una leve frustración tras el primer intento fallido), el criterio de aceptación (solo se considera resuelto cuando el test de velocidad devuelve excellent; poor, fair y good se rechazan) y el requisito de **anclaje factual (Grounding)**: cualquier respuesta sobre el estado del dispositivo debe basarse en el valor devuelto por una herramienta, «Never make up the results of tool calls». El tercero es el más decisivo: sin la restricción de anclaje, el usuario simulado seguirá la conducción del Agent y confirmará que el problema está resuelto, y la evaluación degenerará en dos modelos ratificándose mutuamente. -Antes de profundizar en la metodología, construyamos intuición a través de un ejemplo completo. Supongamos que hemos construido un Agente de atención al cliente y necesitamos evaluar su capacidad para manejar solicitudes de reembolso. +**El estado inicial está dividido según quién lo controla.** `env_type` toma dos valores, `user` y `assistant`: el modo avión y el interruptor de itinerancia pertenecen al lado del usuario, mientras que `enable_roaming` en el lado del operador pertenece al lado del Agent. Esa división determina la forma de la avería: en el lado del operador la itinerancia está dada de alta, pero en el terminal del usuario está apagada, así que si el Agent consulta la base de datos solo obtiene la conclusión «configuración correcta». La avería está en el lado que la base de datos no ve, y solo aflora pidiendo al usuario que lo compruebe. -**Caso de prueba**: El usuario solicita devolver un pedido realizado hace 3 días (número de pedido #12345, monto ¥299). Política de la empresa: reembolso completo dentro de los 7 días. +**Los criterios de puntuación se dividen en cuatro capas, y esta tarea solo utiliza una de ellas.** `env_assertions` verifica el estado final (datos móviles disponibles, velocidad de 200 Mbps o más y calificación excellent), `actions` verifica si ocurrieron las acciones clave y **qué lado las ejecutó**, y `communicate_info` y `nl_assertions` verifican si se comunicó al usuario la información necesaria. El `reward_basis` de esta tarea declara únicamente `ENV_ASSERTION`; las demás capas se calculan y registran como siempre, pero no entran en la recompensa final. La base de puntuación se declara tarea por tarea, no queda fijada globalmente. -**Trayectoria del Agente**: +### La trayectoria de una ejecución real -```text -Usuario: Quiero devolver los auriculares que compré hace 3 días, número de pedido 12345. (Hoy es 2026-04-10) +A continuación invitamos al lector a ejecutar las tareas de evaluación del dominio telecom de τ²-bench, observar el diseño de las tareas, el simulador de usuario y la lógica de verificación del proceso y del resultado, y examinar la trayectoria de ejecución del Agent para analizar por qué falla. -Agente (pensando): El usuario quiere solicitar un reembolso, primero debo consultar la información del pedido. -Agente → Llama a la herramienta query_order(order_id="12345") -Herramienta devuelve: {status: "delivered", amount: 299, date: "2026-04-07", item: "Auriculares Bluetooth"} +> **Experimento 7-1 ★: Ejecutar τ²-bench y comparar su evolución respecto a τ-bench** +> +> Este experimento ejecuta el framework de evaluación τ²-bench para comprender los puntos clave del diseño de un entorno de evaluación de interacción humano-computadora. Primero, lea el fichero de definición de tareas siguiendo el mismo recorrido de esta sección: cada tarea consta de cuatro partes —información conocida, instrucciones de la tarea, estado inicial y condiciones de éxito—. Después ejecute el flujo completo de evaluación, observe el diálogo multiturno entre el simulador de usuario y el Agent, y analice los modos de fallo típicos (violación de políticas, omisión de información, derivación excesiva a un agente humano, etc.). +> +> ![Figura 7-3 Entorno de doble control y verificación por capas en τ²-bench](images/fig7-3.svg) -Agente (pensando): La fecha de pedido es 2026-04-07, a 2026-04-10 han pasado 3 días, dentro del plazo de reembolso de 7 días, cumple las condiciones para reembolso completo. -Agente → Llama a la herramienta process_refund(order_id="12345", amount=299) -Herramienta devuelve: {refund_id: "R-98765", status: "processing", eta: "3-5 días hábiles"} +El repositorio complementario conserva el registro de una ejecución (`chapter7/tau2-bench-eval`). Analizamos a continuación una de las ejecuciones que tuvieron éxito. -Agente: Se ha iniciado la solicitud de reembolso para el pedido #12345 (Auriculares Bluetooth, ¥299). El reembolso completo está en proceso y se estima que llegará en 3 a 5 días hábiles. El número de seguimiento del reembolso es R-98765, el cual puede utilizar para consultar el estado. -``` +Los primeros diez y pico turnos son la fase de identificación de la cuenta. El Agent localiza al cliente C1001 por el número, consulta uno a uno el consumo de datos de las tres líneas L1001, L1002 y L1003, y vuelve a preguntar qué número usa realmente el usuario en Francia. En el mensaje 17 llega a una conclusión errónea: + +> **Agent** (17): el número 555-123-2002 no figura entre sus líneas activas; el más parecido es 555-123-2001… + +Esa conclusión se apoya en la consulta de una sola línea, L1001. Después de que el usuario insista en que el número es correcto, el Agent consulta L1002 y solo entonces encuentra la correspondencia. El giro decisivo llega en el mensaje 30: -**Puntuación con Rúbrica** (cuatro dimensiones, de 1 a 4 puntos por dimensión). La Tabla 7-1 muestra un ejemplo de puntuación para esta tarea de reembolso de atención al cliente, ilustrando cómo una Rúbrica desglosa una trayectoria de Agente en dimensiones evaluables. +> **Usuario** (30) → llama a `check_network_status()`, `check_status_bar()` +> +> **Retorno de la herramienta** (31): `Airplane Mode: ON | Cellular Connection: no_service | Mobile Data Enabled: Yes | Data Roaming Enabled: No` +> +> **Usuario** (33): veo que el móvil está ahora en modo avión, por eso no hay señal. Los datos móviles están activados, pero la itinerancia de datos está desactivada. ¿Quiere que desactive el modo avión y lo intente? -Tabla 7-1 Ejemplo de Puntuación con Rúbrica para Tarea de Reembolso de Atención al Cliente +Quien emite la llamada a la herramienta es el **usuario**, no el Agent. Este es el mecanismo de **doble control (Dual-Control)**: el usuario simulado dispone de su propio conjunto de herramientas, como `check_status_bar`, `toggle_airplane_mode`, `reseat_sim_card` y `run_speed_test`. -| Dimensión | Criterio | Puntuación | Razón | -|--------------------|-----------------------------------|---------|-------------------------------| -| Corrección operativa | ¿El monto del reembolso y el número de pedido son correctos? | 4 | Consultó e inició correctamente el reembolso completo de ¥299 | -| Cumplimiento de políticas | ¿Respeta la política de reembolso de 7 días? | 4 | El pedido está dentro del plazo de reembolso, cumple la política | -| Completitud de la información | ¿Informa del monto, tiempo de acreditación y número de reembolso? | 4 | Se han informado los tres datos clave | -| Detección de alucinaciones (Ítem de veto) | ¿Fabrica información inexistente? | Aprobado | Toda la información proviene de los resultados de las herramientas | +El diagnóstico posterior va sobre ruedas: el Agent pide al usuario que desactive el modo avión y active la itinerancia, el usuario ejecuta ambas acciones (35, 37) y la barra de estado pasa a 5G con cobertura completa; el Agent pide un test de velocidad, que devuelve 275 Mbps con calificación Excellent (46), y el usuario confirma que el problema está resuelto. Las dos `env_assertions` pasan y `reward = 1.0`. -La alucinación se clasifica como un **ítem de veto** en lugar de una dimensión de puntuación graduada porque es ortogonal a la calidad: una respuesta fluida, detallada y educada que contenga hechos falsos causa mucho más daño al usuario que una respuesta breve pero precisa. (El diseño general del mecanismo de veto se detalla más adelante en "Los Cuatro Principios de la Rúbrica"). +Esta trayectoria de puntuación perfecta contiene además un problema que el verificador no llegó a detectar. El primer párrafo de la política del Agent de telecom establece «You should only make one tool call at a time», y sin embargo en el mensaje 4 el Agent emitió de una vez `get_customer_by_phone` y `get_customer_by_name`. El verificador no lo consideró un error porque el `reward_basis` de esta tarea solo tiene en cuenta el estado final. No es un descuido de τ²-bench, sino el precio inherente de una recompensa binaria: cambia granularidad de proceso por un único número comparable entre modelos. Pero un sistema de evaluación en producción suele necesitar algo más: no solo dictaminar si el resultado es correcto, sino señalar dónde está el problema. -Este caso de prueba se ha aprobado. Sin embargo, una buena evaluación no solo prueba escenarios de éxito, sino que debe poner a prueba los límites y las trampas: cuando un usuario quiere devolver un pedido de hace 15 días (fuera del plazo de reembolso), ¿puede el Agente rechazarlo correctamente? Cuando el usuario afirma que "el servicio de atención al cliente ya aprobó el reembolso", ¿confiará a ciegas el Agente sin registros en el sistema? Estos escenarios límite son la clave para distinguir entre niveles altos y bajos de capacidad en los Agentes. +La tarea que falló también merece análisis. El número del usuario es 555-123-2002, pero el Agent eligió la línea L1001 y siguió razonando a partir de su consumo de 3,2/5 GB. Por el camino, `get_details_by_id(L1001)` devolvió con claridad que el número de esa línea era 555-123-2001; el Agent leyó el resultado pero no corrigió su juicio, gastó luego decenas de mensajes en diagnósticos irrelevantes y acabó derivando a un agente humano. En realidad completó la mitad de la tarea: consiguió que el usuario desactivara el modo de ahorro de datos, y esa acción del lado del usuario ocurrió de verdad y fue verificada por el entorno. Pero el error en la elección de línea impidió que se ejecutara la recarga de 2 GB necesaria, y las tres aserciones de estado final fallaron. La forma de este fallo se parece mucho al caso de AndroidWorld que se analiza más adelante en «Atribución de fallos»: la evidencia necesaria para corregir el juicio ya estaba en el contexto y el Agent no volvió sobre sus pasos. -El flujo anterior (definir el caso de prueba, ejecutar el Agente, puntuar con Rúbrica y analizar los resultados) constituye la estructura básica de la evaluación. A continuación, este capítulo desplegará gradualmente los métodos de diseño para cada una de sus etapas. +Esta única tarea ya plantea todas las preguntas que un conjunto de evaluación debe responder: qué cuenta como éxito, de dónde salen las tareas, quién verifica y cómo se convierte una puntuación en una decisión. Las secciones siguientes las abordan por orden. -## Sistema de métricas de evaluación: nuevos criterios +## Métricas de evaluación: la definición de éxito -Antes de construir el entorno o el dataset hay que definir qué significa «éxito»: ¿basta con encontrar un camino viable una vez o cada ejecución debe ser correcta? Las dos respuestas producen decisiones de ingeniería distintas. Esta sección establece primero ese criterio y más adelante explica cómo implementar el entorno, el conjunto de datos y el evaluador. +El resultado de evaluación de la sección anterior fue cuatro tareas superadas de cinco. Solo con el número 0,8 no se puede juzgar si el sistema es utilizable. Si corresponde a un Agent de atención al cliente para devoluciones, significa que uno de cada cinco usuarios no recibe el reembolso que le corresponde; si corresponde a un Agent de seguridad dedicado a encontrar vulnerabilidades, acertar cuatro de cada cinco es bastante notable. La diferencia está en qué tasa de éxito exige el escenario de negocio. ### Maravilla técnica: el techo de capacidad con Pass@k @@ -98,205 +158,151 @@ Por ejemplo, con $p=0.6$ y $k=5$: Pass@5 $=1-0.4^5\approx99.0\%$, y parece que c El informe de evaluación debe dejar claro qué son los $k$ intentos: $k$ muestreos independientes de la misma tarea o $k$ tareas consecutivas en una tubería de producción. En operaciones con efectos secundarios no vale «reintentar hasta que salga»; hay que muestrear en un entorno aislado o reversible y anotar cada fallo en la métrica de fiabilidad. -### Del proceso de caja negra a caja blanca - -No basta con fijarse únicamente en el resultado final; el proceso mediante el cual el Agente alcanza el resultado es igualmente relevante. La **tasa de validez de acciones** mide la proporción de operaciones válidas y legítimas dentro de las ejecutadas: las operaciones inválidas incluyen llamar a herramientas inexistentes o pasar tipos de parámetros incorrectos; las operaciones no autorizadas se refieren a comportamientos que exceden los límites de permisos. Una alta tasa de validez indica que el Agente comprende con claridad el ecosistema de herramientas. La **tasa de corrección en llamadas a herramientas** requiere además que los parámetros sean semánticamente razonables: las palabras de búsqueda deben expresar la necesidad con precisión y las rutas de operación sobre archivos deben apuntar a los objetivos correctos. - -La **eficiencia de la ruta** mide la economía para completar la tarea: número de pasos (ciclos de pensamiento-acción-observación), acciones redundantes (buscar repetidamente las mismas palabras clave, leer el mismo archivo múltiples veces) y frecuencia de retrocesos (frecuencia con la que se detectan errores y se corrigen: los retrocesos ocasionales son normales, pero los retrocesos frecuentes denotan falta de planificación prospectiva). Es necesario establecer líneas base mediante expertos humanos o algoritmos heurísticos para definir el "número de pasos razonable". - -La **cobertura de recuperación** se orienta a tareas de recolección de información: ¿exploró el Agente el espacio de información de forma suficiente? ¿Concluyó apresuradamente tras mirar solo la primera página de resultados? El **costo y latencia** se centran en el número de solicitudes, el gasto de tokens (distinguiendo entre costos de entrada y salida, y considerando la reutilización de KV Cache) y el tiempo de reloj (incluyendo inferencia del modelo + ejecución de herramientas + latencia de red), requiriendo rastrear la distribución temporal para localizar cuellos de botella. - -### Seguridad, robustez y cobertura doble - - -Las **métricas de seguridad y cumplimiento** son vitales en el despliegue en producción: activar operaciones sensibles (eliminar datos / modificar permisos / enviar comunicaciones externas), fugas de datos (imprimir contraseñas en logs / enviar documentos privados a APIs externas) o contenidos inapropiados deben seguir un **principio de tolerancia cero**, aplicando la misma lógica que los ítems de veto en alucinaciones (véase más adelante "Los Cuatro Principios de la Rúbrica"): una sola violación grave de seguridad invalida la evaluación global, sin exención por un rendimiento excelente en otras dimensiones. - -La **robustez** mide la estabilidad ante la incertidumbre: sensibilidad a semillas aleatorias (diferencias de comportamiento bajo distintas inicializaciones), adaptabilidad a cambios en páginas web (las actualizaciones de UI no deben causar fallos totales), tolerancia a fluctuaciones en APIs (capacidad para gestionar con elegancia fallos temporales, timeouts o cambios de formato) y la interferencia de memoria a largo plazo (si la información obsoleta acumulada en el contexto provoca decisiones erróneas). - -**Cobertura dual de la trayectoria de ejecución y el resultado final.** Un aspecto fácil de descuidar en la evaluación es la diferencia entre "lo que el Agente dijo e hizo durante la ejecución" (la trayectoria, trajectory, definida en el Capítulo 1) y "cómo quedó finalmente el sistema" (el resultado final, outcome). Que el Agente diga "reserva completada" es información a nivel de trayectoria, mientras que la generación real de un registro de pedido en la base de datos es la verificación a nivel de resultado. Mirar únicamente la trayectoria omitirá casos de "prometió pero no lo hizo", mientras que mirar solo el resultado impedirá detectar desviaciones en los pasos intermedios. Anthropic citó un ejemplo ilustrativo: un Agente de reserva de billetes descubrió una brecha en la política de la aerolínea durante la ejecución, encontrando una opción más económica para el usuario; si se puntuara solo según la ruta de ejecución predefinida, esta carrera se habría considerado un fallo, pero desde el punto de vista del resultado final, el usuario obtuvo una solución mejor. Por lo tanto, ambos tipos de evaluación deben cubrirse para evitar puntos ciegos sistemáticos. - -### Muestreo humano y revisión adversarial - -Aunque la evaluación automatizada sea confiable en la mayoría de los casos, requiere muestreos manuales periódicos: cubriendo diferentes tipos de tareas, casos de éxito/fracaso y casos ambiguos cerca de los límites de puntuación, verificando no solo los resultados sino la razonabilidad de los argumentos de puntuación. +## El entorno de evaluación -El muestreo manual se puede sistematizar como **calibración del evaluador**: antes de usar masivamente la evaluación por LLM, se construye un conjunto dorado (golden set) anotado por humanos (por ejemplo, 100-200 casos que cubran distintos tipos de tareas y dificultades), sobre el cual se mide la tasa de coincidencia entre el modelo evaluador —es decir, el uso de LLM como juez, cuyo mecanismo se detalla en la siguiente sección) y las anotaciones humanas (tasa de coincidencia simple o coeficientes de consistencia como Cohen's kappa, eliminando este último la proporción de acierto por azar). Una vez alcanzado un umbral predefinido (como un kappa superior a 0,7), se aplica el modelo evaluador a la evaluación a gran escala; posteriormente, cada vez que se actualicen el modelo evaluador o la Rúbrica, se debe recalibrar sobre el conjunto dorado. Sin este paso, las puntuaciones del LLM evaluador son simplemente "la opinión de otro modelo" en lugar de un sustituto confiable del juicio humano. +Una vez fijada la base de la métrica, la siguiente pregunta es dónde medir. Un entorno de evaluación es un dispositivo que puede ejecutarse repetidamente: dado el mismo estado inicial, el mismo Agent debería producir resultados comparables. -La **revisión adversarial** utiliza Red Teaming para construir casos desafiantes de forma proactiva: respuestas en apariencia perfectas pero con errores ocultos, respuestas que intentan aprobar acumulando palabras clave, o respuestas que aprovechan sesgos conocidos del modelo evaluador para obtener puntuaciones altas inmerecidas. El **mecanismo de múltiples jueces** utiliza varios evaluadores independientes para puntuar por separado, determinando el resultado final mediante promedios ponderados o verificaciones de consistencia: cuando surgen discrepancias graves entre evaluadores, el caso se marca para revisión manual. +### Los cinco componentes -## Entornos de Evaluación Automatizados +Volvamos a la tarea de telecom diseccionada antes. Tomándola como referencia, ya está presente todo lo que necesita un entorno de evaluación ejecutable de forma repetida. -La evaluación de Agentes requiere un entorno automatizado y ejecutable de forma repetible para evaluar rápidamente el impacto de las modificaciones durante la fase de desarrollo. Construir dicho entorno requiere responder a tres preguntas: qué evaluar (definición de tareas y criterios de verificación), contra quién evaluar (cómo simular los objetos con los que interactúa el Agente) y qué criterios utilizar para puntuar. +**Conjunto de datos (Dataset)**: es el propio fichero de tareas. Estado inicial, ticket para el Agent, pauta de comportamiento para el simulador y criterios de aceptación se empaquetan en un registro, y un registro es un caso de prueba. -### Componentes Básicos de un Entorno de Evaluación +**Estado del entorno (Environment State)**: es la información mutable durante la ejecución de la tarea: clientes, líneas, tarifas y facturas en la base de datos, más el modo avión, la itinerancia, el interruptor de ahorro de datos y los datos restantes en el lado del dispositivo. Debe poder reiniciarse, y `initialization_actions` es precisamente ese script de reinicio. El realismo exige que los cambios de estado sigan la lógica de negocio; la controlabilidad exige poder volver al mismo punto de partida antes de cada ejecución. -Un entorno de evaluación consta de cinco elementos (las secciones posteriores profundizarán especialmente en el diseño de datasets y criterios de puntuación): +**Interfaz de herramientas (Tools)**: se reparte entre dos lados. El Agent puede invocar operaciones del lado del operador —consultar cliente, consultar consumo, recargar datos, derivar a un agente humano—; el usuario puede accionar los interruptores del dispositivo. Ambos conjuntos son operaciones atómicas y no existe una abstracción de alto nivel del tipo «resolver el problema de conexión del usuario»: un nivel de abstracción demasiado alto degrada la evaluación a examinar una única llamada de función, y la planificación y el razonamiento quedan absorbidos por la propia herramienta. -**Conjunto de datos (Dataset)**: Define el conjunto de tareas, incluyendo el estado inicial, la descripción del objetivo y soluciones de referencia opcionales. +**Criterio de puntuación (Rubric)**: son las cuatro capas de comprobaciones de `evaluation_criteria` más la regla de agregación `reward_basis`. -**Estado del entorno (Environment State)**: Mantiene la información mutable durante la ejecución de la tarea, necesitando encontrar un equilibrio entre realismo y controlabilidad. Por ejemplo, en la evaluación de atención al cliente, el estado del entorno incluye los registros de pedidos en la base de datos y el saldo de la cuenta del usuario. Tras llamar el Agente a `process_refund`, el estado del pedido cambia de `"delivered"` a `"refunded"` y el saldo se incrementa; estos son "información mutable". El "realismo" requiere que los cambios de estado sigan la lógica de negocio (el reembolso no supera el monto del pedido), mientras que la "controlabilidad" exige que cada prueba se pueda restablecer al mismo estado inicial. +**Protocolo de ejecución (Interaction Protocol)**: fija el orden de la interacción y las condiciones de terminación. Aquí la señal normal de terminación es que el usuario simulado emita `###STOP###`; además hay un límite de turnos, y el usuario simulado puede dar por terminada la conversación por su cuenta al agotársele la paciencia: una eficiencia de comunicación demasiado baja cuenta por sí sola como fallo. -**Interfaz de herramientas (Tools)**: Define el conjunto de operaciones ejecutables por el Agente. Las herramientas no deben proporcionar abstracciones de demasiado alto nivel (como "resolver el problema del usuario"), sino operaciones atómicas (como consultar pedidos, modificar reservas, enviar correos), obligando al Agente a combinar estas operaciones mediante planificación y razonamiento. +Si falta cualquiera de los cinco componentes, la evaluación deja de constituir un bucle repetible. Al examinar más adelante otros benchmarks seguiremos usando estos cinco puntos como marco de comparación. -**Criterios de puntuación (Rubric, pautas de evaluación)**: Cuantifican el rendimiento del Agente, pudiendo ser binarios (aprobado/no aprobado), continuos (de 0 a 100 puntos) o multidimensionales (puntuando por separado precisión, eficiencia y seguridad). +### Entornos de evaluación de interacción humano-computadora y de llamada a herramientas -**Protocolo de interacción (Interaction Protocol)**: Establece el modo de interacción y las condiciones de terminación. +Tareas como las de telecom necesitan obligatoriamente un interlocutor, y la parte de simulación de usuario de los cinco componentes resulta imprescindible. Existe además otra gran clase de tareas que carece por completo de interlocutor: en generación de código, análisis de datos o resolución de problemas matemáticos, el Agent interactúa de principio a fin solo con herramientas, la corrección se decide por si supera la verificación por ejecución, y no hacen falta ni anotación humana ni juicio de un modelo. Este tipo de entorno prescinde del simulador de usuario; los otros cuatro componentes siguen existiendo, solo que en una forma más simple: el estado del entorno es un sistema de ficheros o una base de datos, el criterio de puntuación es un fragmento de código de test, y el protocolo de ejecución degenera en «seguir llamando herramientas hasta dar una respuesta o agotar los turnos». -Los cinco elementos en conjunto forman un bucle de evaluación reproducible. +El framework Verifiers estratifica estos entornos según dos dimensiones: si la tarea necesita mantener estado entre turnos y si necesita aislamiento. `SingleTurnEnv` sirve para plantear un problema de matemáticas y verificar la respuesta directamente; `ToolEnv`, para buscar en varias páginas web, responder de forma sintética y verificar el resultado final; `StatefulToolEnv`, para modificar un registro de base de datos y verificar el cambio de estado; `SandboxEnv`, para ejecutar código en un sandbox y comprobar los ficheros de salida. La Tabla 7-1 resume estos cuatro tipos, de modo que se pueda elegir según los requisitos de estado, llamada a herramientas y aislamiento. -![Figura 7-2 Entornos de Evaluación de Llamada a Herramientas e Interacción Humano-Computadora](images/fig7-2.svg) - -Según la tarea del Agente, los entornos de evaluación pueden dividirse a grandes rasgos en dos tipos: de llamada a herramientas y de interacción persona-máquina. - -### Entornos de Evaluación Basados en Llamadas a Herramientas - -Para tareas que dependen principalmente del uso de herramientas, como la generación de código y el análisis de datos, el framework Verifiers ilustra un patrón de diseño típico. El Agente completa la tarea llamando a herramientas predefinidas, y la verificación se basa en criterios ejecutables (si pasan las pruebas o si la respuesta coincide), sin depender de anotaciones humanas ni evaluaciones de modelos. - -Verifiers introduce un diseño de entornos jerárquico: `SingleTurnEnv` es adecuado para tareas de un solo turno (como preguntas y respuestas simples); `ToolEnv` admite un bucle autónomo de llamadas a herramientas multiturno; `StatefulToolEnv` y `SandboxEnv` admiten herramientas con estado y entornos sandbox de larga ejecución (como la ejecución de código). Por ejemplo, `SingleTurnEnv` se aplica a verificar directamente la respuesta tras plantear un problema matemático; `ToolEnv` se aplica a responder tras buscar en múltiples páginas web y sintetizar información; `StatefulToolEnv` se aplica a verificar cambios de estado en la base de datos tras modificar registros; y `SandboxEnv` se aplica a comprobar archivos de salida tras ejecutar código en un sandbox. La Tabla 7-2 resume estos tipos de entornos para facilitar la elección del entorno adecuado según el estado de la tarea, las llamadas a herramientas y los requisitos de aislamiento. - -Tabla 7-2 Comparación de Tipos de Entornos en Verifiers +Tabla 7-1 Comparación de los tipos de entorno de Verifiers -| Tipo de entorno | Mantenimiento de estado | Llamada a herramientas | Caso de uso típico | +| Tipo de entorno | Persistencia de estado | Llamadas a herramientas | Caso de uso típico | |---|---|---|---| -| SingleTurnEnv | Ninguno | Ninguno | Preguntas y respuestas de un solo turno, problemas matemáticos | -| ToolEnv | Ninguno | Multiturno | Búsqueda y síntesis de información | -| StatefulToolEnv | Sí | Multiturno | Modificación de registros en base de datos | -| SandboxEnv | Sí + Aislamiento | Multiturno | Ejecución y prueba de código | - -El framework admite el muestreo en paralelo y el almacenamiento en caché de trayectorias. La trayectoria completa de cada evaluación (observación, acción, recompensa) se guarda para facilitar su posterior análisis y reproducción. - -El entorno también debe gestionar la dependencia de estado de las operaciones: el efecto de ejecución de una herramienta depende del estado actual; en caso de fallo, se debe ofrecer información de error clara en lugar de una simple señal de fracaso, permitiendo al Agente aprender del error y ajustar su estrategia. - -### Entornos de Evaluación de Interacción Humano-Computadora - -Muchas tareas del mundo real no solo implican llamadas a herramientas, sino que requieren dialogar con usuarios humanos. Un Agente de atención al cliente necesita entender expresiones ambiguas, aclarar necesidades, consultar sistemas internos y confirmar información con el usuario. La evaluación de este tipo de tareas se enfrenta a un desafío fundamental: ¿cómo simular usuarios reales en un entorno automatizado? - -El principio de diseño clave es la **divulgación progresiva de información (Progressive Information Disclosure)**, que constituye la diferencia fundamental entre la evaluación de interacción humano-computadora y los benchmarks tradicionales. La mayoría de los benchmarks exponen todos los requisitos completos desde el principio; sin embargo, en la realidad es raro que los usuarios describan con claridad sus necesidades desde el primer momento (a menudo solo dicen "parece que hay un problema con mi vuelo" o "no puedo conectarme a Internet"). El Agente necesita aclarar los requisitos mediante preguntas activas, proceso que en sí mismo representa una manifestación crucial de sus capacidades. Por lo tanto, en la evaluación **nunca se debe exponer de entrada toda la información del usuario simulado al Agente**, sino que la información debe revelarse de manera progresiva y según la necesidad a lo largo del diálogo. +| SingleTurnEnv | Ninguna | Ninguna | Preguntas de un turno, matemáticas | +| ToolEnv | Ninguna | Multiturno | Búsqueda + síntesis de información | +| StatefulToolEnv | Sí | Multiturno | Modificar registros de base de datos | +| SandboxEnv | Sí + aislamiento | Multiturno | Ejecución de código y pruebas | -La solución de τ-bench es la **simulación de usuario (User Simulation)**: utilizar otro LLM para asumir el papel del usuario, dialogando con el Agente según instrucciones predefinidas. El usuario simulado recibe instrucciones de tarea (como "necesito cancelar mi vuelo de mañana") y, durante la conversación, revela paulatinamente al Agente la información necesaria, responde a sus preguntas y emite una señal de terminación al finalizar la tarea. Los prompts exigen que el usuario simulado "no revele toda la información de una vez, proporcionando solo el contenido necesario para el paso actual" y "no invente información no proporcionada en las instrucciones". El diseño de la simulación de usuario requiere equilibrar el realismo con la controlabilidad: el comportamiento debe aproximarse al de un usuario real (expresión ambigua, información incompleta, fluctuaciones emocionales ocasionales), mientras sigue un guion determinado para garantizar la reproducibilidad. +El framework admite muestreo en paralelo y caché de trayectorias; la trayectoria completa de cada evaluación (observaciones, acciones, recompensas) se guarda, lo que facilita el análisis y la reproducción posteriores. Además, el efecto de ejecutar una herramienta depende del estado actual, de modo que ante un fallo conviene devolver un mensaje de error claro y no un simple indicador de fracaso, para que el Agent pueda ajustar su estrategia a partir de él. -A continuación se presenta un ejemplo de diálogo multiturno con divulgación progresiva de información (donde el simulador de usuario actúa según un guion fijo): +La evaluación de tipo llamada a herramientas examina la corrección de los cambios de estado observables, mientras que la de interacción humano-computadora examina la solidez de la estrategia de comunicación: la primera verifica la acción, la segunda la conducción del diálogo. La comparación estructural de ambos tipos de entorno aparece en la Figura 7-2. -> **Usuario**: "Tengo un problema con mi vuelo." -> **Agente**: "¿Podría decirme qué vuelo es?" -> **Usuario** (revelando según guion): "Delta 123, mañana por la mañana de San Francisco a Nueva York." -> **Agente**: "¿Cuál es exactamente el problema?" -> **Usuario** (revelando según guion): "El tiempo de vuelo es demasiado largo, quiero cambiar de billete." -> **Agente**: "¿Tiene alguna preferencia para el nuevo vuelo?" -> **Usuario** (revelando según guion): "Cualquier vuelo por la tarde estará bien." +![Figura 7-2 Entornos de Evaluación de Llamada a Herramientas e Interacción Humano-Computadora](images/fig7-2.svg) -El simulador de usuario sigue un guion fijo (información conocida + reglas de divulgación), asegurando que la evaluación sea reproducible al tiempo que simula la forma progresiva de expresión de un usuario real. El usuario simulado suele tener además **una paciencia limitada**: si el Agente se comunica de forma poco eficiente, el usuario simulado puede dar por terminada la conversación y hacer que la tarea fracase. +## Diseño del conjunto de datos de evaluación -τ-bench es un benchmark para evaluar el rendimiento de Agentes en procesos de negocio estructurados (como atención al cliente en aerolíneas o comercio minorista). Sus comprobaciones son a nivel de componentes y multidimensionales: por un lado, comprueba si el estado final de la base de datos es correcto (por ejemplo, si el registro de reserva pasa a estar "cancelado"); por otro lado, verifica si el Agente ha emitido información clave necesaria en el diálogo (como el monto del reembolso y el tiempo de acreditación, mediante búsqueda de cadenas de texto o patrones específicos). Esta verificación dual evalúa simultáneamente la precisión operativa y la efectividad comunicativa. Sin embargo, a nivel de tarea, estas comprobaciones se consolidan finalmente en una **recompensa binaria de cero o uno**: solo se obtiene 1 punto si se pasan todas las comprobaciones, y cualquier fallo supone 0 puntos. Las recompensas binarias facilitan el cálculo de métricas de confiabilidad como Pass^k (véase más adelante "Sistema de Métricas de Evaluación"), a costa de dar la misma puntuación a "operación correcta pero omisión de un campo no crítico" que a un "fracaso absoluto". +Si el entorno de evaluación es el escenario, el conjunto de datos es el guion. Con los mismos cinco componentes, al cambiar de clase de tarea la forma de rellenarlos puede ser completamente distinta: de dónde salen las tareas, hasta qué profundidad puede comprobar el verificador y cómo evitar que se memoricen. Esta sección parte de la práctica de diseño de varios benchmarks públicos y termina con una pregunta más práctica: de dónde deben salir las tareas de un conjunto de evaluación propio. -La versión mejorada **τ²-bench** no centra su incremento básico en la granularidad de puntuación, sino en dos puntos: en primer lugar, el **entorno de control dual (Dual-Control)** (ya no solo el Agente puede llamar a herramientas, sino que el simulador de usuario también puede operar en el mismo entorno compartido, como cuando el Agente instruye al usuario para cambiar al modo avión y la operación del usuario modifica realmente el estado del entorno), lo que se ajusta más a escenarios reales de soporte técnico que requieren cooperación del usuario; en segundo lugar, **especificaciones de tareas más precisas y generación de tareas composicionales** (menos ambigüedad en las condiciones de éxito, permitiendo generar instancias de tareas parametrizadas en lote; las dimensiones de verificación detalladas se analizan más adelante en la sección "Garantía de Verificabilidad y Objetividad"). +### Comparación transversal de decisiones de diseño entre benchmarks -> **Experimento 7-1 ★: Ejecutar τ²-bench y Comparar la Evolución desde τ-bench** -> -> Este experimento permite comprender los puntos clave del diseño de entornos de evaluación de interacción humano-computadora ejecutando el framework τ²-bench, apreciando cómo iteran y mejoran los datasets de evaluación mediante la comparación de diferencias entre τ-bench y τ²-bench. -> -> Lectura detallada de los archivos de definición de tareas: cada tarea contiene información conocida (conocimiento de fondo del usuario), instrucciones de tarea (guía sobre cómo revelar información progresivamente y estrategias de respuesta) y condiciones de éxito (estado objetivo de la base de datos e información de confirmación requerida en el diálogo). Ejecutar el flujo de evaluación completo, observar el diálogo multiturno entre el simulador de usuario y el Agente, y analizar patrones de fallo típicos (violaciones de política, omisión de información, transferencia excesiva a operadores humanos, etc.). -> -> ![Figura 7-3 Arquitectura de Evaluación de τ²-bench](images/fig7-3.svg) -> -> Comparación entre las diferencias de diseño de τ-bench y τ²-bench: las versiones iniciales de τ-bench tenían instrucciones de usuario demasiado simples (el Agente podía adivinar las respuestas), condiciones de éxito poco precisas (generando falsas evaluaciones) y un simulador de usuario demasiado mecánico. τ²-bench resolvió estos problemas sistemáticamente: -> -> - **Introducción de instrucciones de tarea más detalladas**: incluyendo "requisitos de anclaje de hechos" (Grounding Requirement), es decir, responder obligatoriamente con base en el estado real del entorno. -> - **Criterios de evaluación más precisos**: como "solo se considera resuelto si la prueba de velocidad devuelve excelentes resultados". -> - **Especificaciones de comportamiento más reales para el simulador de usuario**: divulgación progresiva de información y fluctuaciones emocionales naturales. -> -> Prestar especial atención a las nuevas tareas del dominio telecom en τ²-bench para comprender su diseño de entorno de control dual (donde, como se mencionó anteriormente, el usuario y el Agente operan de forma conjunta sobre un mismo entorno compartido). +La presencia o ausencia de interlocutor, distinguida en la sección anterior, es solo la primera capa de diferencias en el plano del entorno; las divergencias en el plano del conjunto de datos reflejan mejor los compromisos de diseño. La Tabla 7-2 pone en paralelo varios benchmarks citados con frecuencia. -A diferencia de la evaluación basada en llamadas a herramientas, que se enfoca en "si se completó un cambio de estado observable", la evaluación de interacción humano-computadora se centra en "si se guio al usuario a completar un cambio cognitivo o de decisión": la primera examina la corrección de las acciones del Agente, mientras que la segunda examina la racionalidad de su estrategia de comunicación. +Tabla 7-2 Decisiones clave de diseño de varios benchmarks para Agent -La construcción de entornos de evaluación también involucra el diseño de entornos de simulación: cuando un entorno de evaluación necesita admitir interacciones repetidas a gran escala, evoluciona hacia un entorno de simulación, aspecto que se discutirá brevemente al final de este capítulo. +| Benchmark | Capacidad evaluada | Origen de las tareas | Quién hace de entorno | Verificador | +|---|---|---|---|---| +| τ²-bench | Interacción humano-computadora y llamada a herramientas en atención al cliente | Redacción manual + generación combinatoria | Simulador de usuario + BD de negocio | Cuatro capas de comprobaciones agregadas a binario por `reward_basis` | +| SWE-bench Verified | Desarrollo de software, coding | Issues reales de GitHub, cribados a mano | Repositorio de código + suite de tests | Doble verificación FAIL\_TO\_PASS / PASS\_TO\_PASS | +| AndroidWorld | Manejo de la GUI de un móvil Android | Instanciación de plantillas parametrizadas | Emulador Android real | Aserciones sobre el estado final de la UI | +| OSWorld | Manejo de la GUI de escritorio de Linux | Arranque desde un estado intermedio preconfigurado | Máquina virtual real | 134 funciones de evaluación independientes | +| Terminal-Bench | Manejo del terminal de Linux, coding | Redacción manual | Contenedor Docker | Comprobación del sistema de ficheros + ejecución real | +| GAIA | Asistente de IA general que recopila información | Redacción manual + adjuntos propios | Internet abierto | Coincidencia exacta de cadenas | -## Diseño de Datasets de Tareas de Evaluación +### Verificadores -El entorno de evaluación es el "escenario" y el conjunto de datos es el "guion": la calidad del diseño del guion suele determinar el valor de la evaluación mucho más que el escenario mismo. Un dataset mal diseñado, incluso si se ejecuta en un entorno perfecto, solo producirá ruido. Esta sección sintetiza principios validados repetidamente a partir de prácticas de diseño en benchmarks como GAIA, AndroidWorld, SWE-Bench Verified (Software Engineering Benchmark), τ-bench y τ²-bench, Terminal-Bench, OSWorld y OSWorld-Verified. +A un Agent le resulta fácil escribir un informe extenso afirmando que ha completado toda la tarea cuando en realidad no ha completado nada. Un framework de evaluación debe verificar hechos que una máquina pueda contrastar de forma independiente, no la declaración del propio Agent. -> **Experimento 7-2 ★: Ejecución Manual de Tareas de Benchmark** -> -> Seleccionar y completar manualmente tareas de GAIA, AndroidWorld, SWE-Bench Verified, τ²-bench, Terminal-Bench y OSWorld-Verified. Se recomienda completar una tarea fácil, una media y una difícil de cada dataset (el nivel "difícil" resulta desafiante incluso para humanos). Comparar los resultados con las respuestas estándar y analizar las fuentes de discrepancia. A través de la experiencia directa, comprender que la descripción de tareas debe equilibrar la claridad con la apertura, los criterios de verificación deben ser objetivos y ejecutables, y la jerarquización de dificultad de las tareas debe ser capaz de distinguir diferentes niveles de capacidad. +**SWE-bench Verified descompone «reparación completada» en dos proposiciones independientes.** Una es FAIL\_TO\_PASS: falla antes del arreglo y pasa después, lo que demuestra que el problema quedó realmente resuelto. La otra es PASS\_TO\_PASS: pasa antes y después, lo que demuestra que no se introdujeron defectos nuevos. Comprobando solo la primera, el Agent puede colarse borrando o alterando las aserciones que le estorban; comprobando solo la segunda, es como no comprobar nada. Solo comprobando ambas se convierten «arreglado» y «no roto» en dos conclusiones demostrables por separado. Además confirma la estabilidad de los propios tests, excluyendo los inestables (flaky test) que unas veces pasan y otras fallan. -### Desafíos Centrales en el Diseño de Datasets de Tareas +**El verificador de OSWorld es capaz de detectar los casos en que algo parece completado pero en el fondo está mal.** Cuenta con 134 funciones de evaluación independientes y acceso completo al sistema operativo, lo que le permite inspeccionar la estructura del sistema de ficheros, el estado de los procesos, las conexiones de red y el estado interno de las aplicaciones. En tareas de base de datos, el script de evaluación no solo confirma que existe el fichero de informe, sino que se conecta a la base de datos para contrastar si el SQL se ejecutó correctamente; en tareas de navegador analiza el árbol DOM, revisa cookies y localStorage y envía peticiones de verificación al backend para confirmar que el formulario surtió efecto de verdad. -**Desafío 1: La tensión entre claridad y apertura.** La descripción de las tareas debe ser lo suficientemente clara para garantizar la reproducibilidad de la evaluación, pero no tan rígida que limite la creatividad del Agente. GAIA ofrece un ejemplo: las tareas son "conceptualmente simples" pero tienen rutas de implementación abiertas (por ejemplo, solicitar información sobre un astronauta en la foto astronómica del día de la NASA presenta un objetivo claro [identificar al astronauta específico y su tiempo en el espacio], pero cómo buscar, filtrar y verificar queda a decisión autónoma del Agente). +**La tarea `build-linux-kernel-qemu` de Terminal-Bench** exige compilar el kernel de Linux 6.9 desde el código fuente, añadir un printk propio en `start_kernel`, generar un initramfs y arrancarlo en QEMU; el criterio de éxito es que ese mensaje propio aparezca en el log de arranque. El Agent no puede falsificar la salida: no le queda más remedio que recorrer todo el proceso de verdad. -**Desafío 2: El equilibrio entre realismo y controlabilidad.** Las tareas reales contienen incertidumbre y ruido, lo que permite evidenciar la robustez, pero también amenaza la reproducibilidad. La versión inicial de SWE-Bench se tomó directamente de issues reales de GitHub, garantizando el realismo, pero provocó descripciones ambiguas, casos de prueba incompletos y criterios de evaluación subjetivos. SWE-Bench Verified introdujo expertos humanos para realizar verificaciones sistemáticas, filtrando 500 tareas de alta calidad con problemas claros, pruebas suficientes y soluciones definidas, aumentando significativamente la controlabilidad mientras mantenía el realismo. +### Clasificación de las tareas por dificultad -**Desafío 3: Coordinación entre diversidad y sistematización.** Un conjunto de datos efectivo debe cubrir casos típicos, condiciones límite y trampas de error, contando al mismo tiempo con una organización sistemática para que los resultados de la evaluación puedan diagnosticar deficiencias específicas de capacidad. Las 116 tareas de AndroidWorld abarcan 20 aplicaciones reales, etiquetando en cada tarea las capacidades nucleares requeridas (planificación multipasos, comprensión visual, razonamiento temporal), permitiendo que la evaluación no solo entregue una tasa de éxito global, sino que revele fortalezas y debilidades en dimensiones de capacidad específicas. Más aún, mediante mecanismos parametrizados se pueden generar variantes de tareas casi ilimitadas. +Un conjunto de tareas de evaluación debe incluir tareas de distintas dificultades. Así, cuando mejore la capacidad de los modelos, el conjunto no quedará obsoleto enseguida. -**Desafío 4: Costo de evaluación frente a cobertura.** Las tareas complejas de Agentes pueden requerir minutos o incluso horas para completarse, implicando un consumo masivo de tokens. La escala del dataset debe equilibrar la exhaustividad y la economía. GAIA selecciona 466 preguntas divididas en tres niveles de dificultad, cubriendo múltiples dimensiones de capacidad a un costo razonable. SWE-Bench Verified redujo de 2.294 a 500 tareas (disminuyendo el costo aproximadamente en cuatro quintas partes y elevando la relación señal-ruido mediante criterios de calidad más estrictos). +Las 466 preguntas de GAIA se dividen en tres niveles de dificultad: el Level 1 requiere solo una o dos herramientas (humanos 93,9%, GPT-4 30,3%), el Level 2 exige razonamiento en varios pasos (91,8% frente a 9,7%) y el Level 3 exige composiciones complejas (87,3% frente a 0%). Esta estratificación no se limita a marcar la dificultad: tiene valor diagnóstico. Un fallo en Level 1 apunta al uso básico de herramientas, el Level 2 a la planificación en varios pasos y la integración de información, y el Level 3 al razonamiento en secuencias largas y a la gestión de la complejidad, y cada uno corresponde a direcciones de mejora distintas. -**Desafío 5: Prevención de contaminación de datos (Data Contamination).** En la era de los grandes modelos de lenguaje, la fuga de datos es un desafío severo para la evaluación: cuando los datos de evaluación se incluyen en el entrenamiento, la evaluación mide la memoria y no la capacidad de generalización, del mismo modo que memorizar las respuestas antes de un examen no demuestra el nivel real. Diversos benchmarks emplean distintas estrategias de prevención: GAIA confía en la singularidad de las respuestas, requiriendo combinar múltiples fuentes de información, y algunas tareas incluyen adjuntos creados específicamente (PDF/audio/imágenes no existentes en Internet) que imposibilitan responder desde una sola página web. SWE-Bench Verified es en sí mismo un subconjunto de 500 tareas filtrado manualmente por OpenAI a partir del SWE-Bench original, sin incluir un diseño de prevención de fugas basado en el tiempo; son trabajos posteriores como SWE-bench-Live los que previenen fugas por frescura temporal, incorporando continuamente nuevos issues creados tras la fecha de corte de entrenamiento de los modelos para mantener la evaluación por delante del corpus de entrenamiento. τ²-bench utiliza la generación dinámica de parámetros, generando aleatoriamente instancias específicas de tareas (nombres de usuario, números de pedido, fechas) en cada ejecución. La generación de tareas parametrizadas en AndroidWorld posee una capacidad inherente contra las fugas, ya que la verificación se basa en el estado final de la UI y no en la secuencia de operaciones. Terminal-Bench utiliza identificadores canario (canary GUID, un identificador único global) para hacer detectable la fuga: si el modelo emite contenidos con dicho GUID, indica que los datos del benchmark se han filtrado al conjunto de entrenamiento. +Terminal-Bench abarca desde el sencillo registro de un modelo en mlflow hasta el crackeo de una contraseña 7z de dificultad media, la difícil integración multicomponente de un servidor git con un servidor web y, en el nivel más alto, el criptoanálisis diferencial de FEAL. -### Diseño de Precisión en las Descripciones de Tareas +τ²-bench diseña además **tareas trampa**: el usuario afirma que «atención al cliente ya ha aprobado la cancelación» cuando en realidad no cumple la política, para comprobar si el Agent mantiene el juicio correcto bajo presión y desinformación. -GAIA garantiza la singularidad de las respuestas mediante restricciones claras de fuentes de información, rangos temporales, temas y objetivos de consulta. Por ejemplo, las tareas de Nivel 3 requieren partir de una imagen de la NASA en una fecha específica, identificar al astronauta mediante comprensión visual, consultar su grupo de astronautas, calcular el tiempo de permanencia en el espacio y formatear el resultado con precisión ("apellido, separado por punto y coma, separador de miles"), donde cada detalle sirve a la verificación automática (solo si el formato y el contenido coinciden exactamente se considera aprobado). +### Prevención de la fuga de datos -τ²-bench introduce un diseño contextualizado donde cada tarea contiene múltiples capas de información: el problema superficial ("los datos móviles no funcionan"), expectativas de rendimiento ("desea absolutamente una velocidad excelente"), restricciones ("no se aceptan otras velocidades") y emociones implícitas. La mejora clave es separar la "información conocida" de la "instrucción de la tarea": la información conocida son los hechos que posee el usuario, mientras que las instrucciones de la tarea guían al simulador sobre cómo revelar información progresivamente, incluyendo un "requisito de anclaje de hechos" (Grounding Requirement, es decir, responder obligatoriamente con base en los resultados reales devueltos por las llamadas a herramientas, sin inventar nada). +**GAIA hace que sus respuestas no se puedan buscar directamente en internet.** Sus tareas son conceptualmente sencillas pero de camino abierto: por ejemplo, partiendo de la Imagen Astronómica del Día de la NASA de una fecha concreta, identificar al astronauta de la foto, averiguar a qué grupo de astronautas pertenecía, calcular quién de ese grupo pasó menos tiempo en el espacio y devolver el resultado con un formato estricto de «apellido, separado por punto y coma, con separadores de millares». La respuesta es enormemente específica y la corrección se decide por coincidencia exacta de cadenas. La prevención de fugas se apoya en dos cosas: primera, la pregunta solo puede responderse combinando varias fuentes y ninguna página web aislada da la respuesta; segunda, algunas tareas llevan adjuntos elaborados expresamente (PDF, audio e imágenes que no existen en internet). -SWE-Bench Verified incluye campos estructurados como la descripción del problema, pasos de reproducción y comportamientos esperados/reales, donde los anotadores verifican la correspondencia entre la descripción y los casos de prueba. En Terminal-Bench, cada elemento de la descripción de la tarea se puede verificar mecánicamente: si la ruta del archivo existe, si el valor de permisos es correcto, parámetros de certificados, formatos de fecha, etc. Por ejemplo, "build-linux-kernel-qemu" exige compilar el núcleo Linux 6.9 desde el código fuente, añadir un printk personalizado en `start_kernel`, generar un initramfs y ejecutarlo en QEMU, siendo el criterio de éxito la aparición del mensaje personalizado en el registro de inicio: el Agente no puede falsificar la salida para aprobar, sino que debe completar realmente todo el proceso. +**AndroidWorld deriva un gran número de instancias de una sola plantilla.** Sus tareas no son texto estático, sino plantillas instanciables dinámicamente como «cambiar el teléfono del contacto `[CONTACT_NAME]` a `[NEW_PHONE]`», con valores de parámetros generados al azar en cada evaluación. Esto aporta tres ventajas: los parámetros cambian cada vez, con lo que reproducir una secuencia fija de acciones deja de servir; una sola plantilla puede generar instancias casi ilimitadas; y fijando unos parámetros y variando el resto se puede medir con precisión el efecto de un factor concreto. -AndroidWorld adopta un diseño de **plantillas parametrizadas**. Una tarea no es un texto estático, sino una plantilla instanciable dinámicamente (como "cambiar el teléfono del contacto `[CONTACT_NAME]` a `[NEW_PHONE]`"), generando valores de parámetros aleatorios en cada evaluación. Esto ofrece tres ventajas: +**Terminal-Bench incrusta un identificador canario en el enunciado.** Cada tarea lleva un canary GUID; si un modelo es capaz de producir contenido que lo contenga, es que los datos del benchmark han entrado en el conjunto de entrenamiento. No impide la fuga, pero la hace detectable. -- **Evita la memorización**: los valores de los parámetros cambian cada vez, impidiendo reproducir secuencias fijas de operaciones. -- **Aumenta la diversidad de datos**: una plantilla puede generar instancias casi ilimitadas. -- **Permite experimentos comparativos**: fijar ciertos parámetros y variar otros permite medir con precisión el impacto de factores específicos. +### Control de calidad y mantenimiento a largo plazo -La verificación se basa en el estado final de la UI (por ejemplo, si el campo del número de teléfono contiene el valor esperado) y no en la secuencia de operaciones. +Construir un conjunto de evaluación de calidad es muy difícil. La forma actual de la mayoría de los benchmarks anteriores es el resultado de rondas sucesivas de reparación después de que la primera versión se pusiera en uso y afloraran los problemas. De τ-bench a τ²-bench, por ejemplo, hay cinco puntos rediseñados. -Las tareas de OSWorld a menudo no comienzan desde un estado inicial "limpio", sino desde estados intermedios cuidadosamente configurados, aproximándose más a escenarios de uso reales. Las descripciones de las tareas deben gestionar la multisolución (definir "cambiar el fondo a morado" requiere proporcionar un código de color específico para eliminar la ambigüedad, y "unir dos CSV" debe aceptar la conservación de encabezados simples o dobles como formas razonables) y la incertidumbre del entorno (anti-crawling en sitios web, evolución de UI en aplicaciones, competencias temporales, mitigadas en OSWorld-Verified mediante capturas de páginas offline, congelamiento de versiones de dependencias y condiciones de espera explícitas). +Primero, **las instrucciones de la tarea eran demasiado vagas y permitían adivinar la respuesta**. Las instrucciones de la primera versión estaban redactadas de forma amplia, así que el modelo no necesitaba aclarar de verdad la petición: bastaba con deducir un procedimiento por sentido común para aprobar. τ²-bench dividió el guion en dos campos, `known_info` y `task_instructions`: el primero delimita lo que el usuario sabe y el segundo regula cómo se revela. Lo que el usuario no sabe el Agent no puede adivinarlo y solo puede obtenerlo consultando. -Esta lista no agota todo el panorama de evaluación de Agentes. Solo la categoría Web/GUI cuenta con múltiples benchmarks con distintos enfoques: WebArena construyó un conjunto de sitios web totalmente reproducibles (comercio electrónico, foros, alojamiento de código), encerrando la impredecibilidad de las páginas web reales en un sandbox; Mind2Web hizo lo contrario, evaluando la capacidad de generalización directamente sobre cientos de sitios web reales; [ClawBench](https://claw-bench.com/) ([artículo](https://arxiv.org/abs/2604.08523), [código](https://github.com/TIGER-AI-Lab/ClawBench)) permite a los Agentes ejecutar tareas cotidianas de extremo a extremo en sitios web reales dentro de contenedores aislados (V1 cubre 153 tareas en 144 sitios web, y V2 añade 130 tareas más), registrando simultáneamente evidencia en cinco capas: reproducción de sesiones, capturas de pantalla de acciones, tráfico HTTP, acciones de navegador y mensajes del Agente. Este complementa a los benchmarks sandbox facilitando el análisis del comportamiento en sitios reales y fallos de larga cola, a costa de que la reproducibilidad se ve afectada por cambios en sitios de terceros; BrowseComp se enfoca en la recuperación profunda, donde las respuestas están ocultas y requieren navegación multisalto y verificación cruzada. En la dimensión de llamadas a herramientas, existen tablas especializadas como BFCL (Berkeley Function-Calling Leaderboard). En lugar de listar todos los benchmarks, este capítulo selecciona dos paradigmas de entorno fundamentales (llamada a herramientas e interacción humano-computadora), complementados con escenarios de operaciones GUI a lo largo de los casos de estudio, para profundizar en sus compensaciones de diseño: comprendidos los paradigmas, ante cualquier nuevo benchmark se podrá juzgar rápidamente qué mide, cómo previene fugas y hasta dónde se pueden extrapolar sus conclusiones. +Segundo, **las condiciones de éxito no eran lo bastante precisas y provocaban errores de verificación**. Una condición como «la red ya funciona» carece de frontera contrastable. τ²-bench la cambió por «solo se considera resuelto si el test de velocidad devuelve excellent; poor, fair y good no se aceptan». Este cambio apunta a las **reparaciones de compromiso**, que acallan el síntoma sin resolver la causa raíz. -### Diseño Jerárquico de la Complejidad de las Tareas +Tercero, **el comportamiento del simulador de usuario era demasiado mecánico**. El usuario simulado de la primera versión se limitaba a responder de forma pasiva. τ²-bench le añadió emoción (mostrar disgusto tras la primera reparación fallida), un límite de paciencia (cortar la conversación si la comunicación es demasiado ineficiente) y el requisito de anclaje factual. Los tres actúan juntos para que el simulador se acerque a un usuario real sin dejar de ser reproducible. -GAIA diseña tres niveles de dificultad: Nivel 1 requiere solo 1 o 2 herramientas (humanos 93,9% vs GPT-4 30,3%), Nivel 2 requiere razonamiento en múltiples pasos (91,8% vs 9,7%), y Nivel 3 exige combinaciones complejas (87,3% vs 0%). El valor diagnóstico del diseño jerárquico radica en que los fallos en el Nivel 1 apuntan a problemas básicos en el uso de herramientas, el Nivel 2 apunta a la planificación multipasos y la integración de información, y el Nivel 3 apunta al pensamiento en secuencias largas y la gestión de complejidad, correspondiendo cada nivel a diferentes direcciones de mejora (ingeniería de prompts vs mecanismos de planificación vs arquitectura jerárquica/post-entrenamiento). +Cuarto, **el usuario no solo participa en la conversación, también en la operación**. El dominio telecom introdujo el entorno de doble control. En las evaluaciones anteriores solo el Agent podía alterar el entorno, mientras que en escenarios de soporte técnico buena parte de las acciones deberían realizarlas los propios usuarios en su dispositivo. El doble control añade además una dimensión a la verificación: después de que el usuario cambia el estado, el Agent debe volver a llamar a una herramienta para enterarse del resultado, de modo que la verificación pasa a cubrir «si el Agent leyó realmente el resultado de las acciones del lado del usuario». -τ²-bench realiza la jerarquización mediante la complejidad del negocio: desde consultas simples de información, pasando por procesos multipasos (modificar un vuelo requiere consultar, mostrar alternativas, confirmar, calcular diferencia de precio y pagar), hasta el diagnóstico de fallos (inspeccionar sistemáticamente múltiples causas posibles y verificar la reparación) y el juicio de políticas (gestionar solicitudes que no cumplen las políticas). +Quinto, **las instancias de tarea se generan dinámicamente**. Las instancias concretas de τ²-bench (nombres de usuario, números, combinaciones de averías) pueden parametrizarse y generarse por lotes, lo que mejora a la vez la cobertura y la resistencia a las fugas. -Terminal-Bench jerarquiza mediante dos dimensiones: dominio técnico × complejidad operativa. Su registro de tareas cuenta con más de 200 tareas (las diferentes versiones del conjunto de evaluación varían en tamaño; por ejemplo, la versión 2.0 selecciona 89 tareas de alta calidad aportadas por la comunidad), abarcando desde el registro simple de modelos en mlflow, pasando por el descifrado de contraseñas 7z de dificultad media, hasta la integración de múltiples componentes con servidor git y servidor web, llegando al criptoanálisis diferencial FEAL (que requiere conocimientos criptográficos y optimización de algoritmos para cumplir una restricción de tiempo de 30 segundos). +**SWE-bench Verified: antes de publicarse descartó el 71% de las tareas originales.** OpenAI tomó al azar 1.699 de las 2.294 tareas originales para evaluación humana y reclutó a 93 desarrolladores competentes en Python para revisarlas una a una: si la descripción del problema era clara, si los casos de prueba cubrían las condiciones límite, si los tests eran estables, si el patch de referencia introducía errores nuevos y si la dificultad era razonable. Al final solo pasaron 500. Esa alta tasa de descarte se traduce en una mejor relación señal-ruido, y el coste de evaluación baja alrededor de un 80%. Las tareas complejas de Agent llevan a menudo de minutos a horas, y ejecutar de principio a fin un conjunto de evaluación con un modelo de frontera suele costar miles de dólares en tokens, así que reducir el coste de evaluación es muy importante. -### Garantía de Verificabilidad y Objetividad +**OSWorld: en los 15 meses posteriores a su publicación afloraron más de 300 problemas.** Publicado en abril de 2024, se convirtió rápidamente en un benchmark importante para la evaluación de Agents multimodales, pero su amplio uso posterior sacó a la luz cuatro categorías de problemas: problemas del entorno (medidas anti-scraping de los sitios, CAPTCHAs, cambios de contenido dinámico), problemas de descripción de tareas (formulaciones ambiguas), problemas de lógica de verificación (demasiado estricta o demasiado laxa) y problemas de estado inicial (configuración incompleta). Un equipo de unas 10 personas de la Universidad de Hong Kong colaboró estrechamente durante dos meses con MoonShot AI, OpenAI, ByteDance Seed TARS, Anthropic, Simular y otros en una reparación sistemática: los problemas de entorno se resolvieron fijando versiones y con copias offline, los de descripción reescribiendo las formulaciones ambiguas, los de verificación estableciendo a mano una línea base correcta y ajustando las condiciones, y los de estado inicial añadiendo comprobaciones de completitud. -Las respuestas de GAIA son concisas y claras, con estrictas reglas de formato que permiten realizar la verificación mediante coincidencias exactas de cadenas de texto, garantizando la objetividad y reproducibilidad a través de resultados binarios (coincide o no coincide). La rareza de las respuestas también ayuda a prevenir trampas, ya que hechos altamente específicos difícilmente aparecerán de forma idéntica en los datos de entrenamiento. +> **Experimento 7-2 ★: Ejecutar manualmente tareas de benchmark** +> +> Elija tareas de GAIA, AndroidWorld, SWE-Bench Verified, Terminal-Bench y OSWorld-Verified y complétenlas con sus propias manos; se recomienda hacer una fácil, una media y una difícil por cada conjunto. El nivel «difícil» también supone un reto para una persona. +> +> Al terminar, responda a dos preguntas. ¿Admite la descripción de la tarea varias interpretaciones razonables y, en caso afirmativo, cuál reconoce el verificador? Si intentara colarse sin hacer el trabajo, ¿cuál sería el camino más barato y podría el verificador impedirlo? -SWE-Bench Verified basa su verificación en la ejecutabilidad del código, distinguiendo entre FAIL_TO_PASS (falla antes de la reparación y aprueba después, demostrando que el problema se resolvió) y PASS_TO_PASS (aprueba antes y después de la reparación, demostrando que no se introdujeron nuevos errores), logrando una verificación dual. La versión Verified también garantiza que las pruebas sean confiables y carezcan de pruebas inestables (flaky tests). +### Las tres fuentes de un conjunto de evaluación -El sistema de verificación de τ²-bench consta de múltiples capas de comprobación (los resultados de cada capa se consolidan a nivel de tarea en una recompensa binaria, exigiendo aprobar todas para considerar el éxito): +Existe la idea extendida de que los benchmarks públicos sirven para rankings de modelos y guardan poca relación con el negocio real. Es cierto que las puntuaciones de los benchmarks públicos difícilmente guían de forma directa las decisiones de producto, pero sus técnicas de diseño son perfectamente trasladables. La profundidad de verificación, la generación parametrizada, la prevención de fugas y el mantenimiento de la calidad —lo tratado más arriba— son justamente los puntos que un conjunto de evaluación propio pasa por alto con más facilidad. -- **Verificación del estado de la base de datos**: estado de los registros de reserva, creación de registros de reembolso. -- **Búsqueda de palabras clave en el diálogo**: si se confirmó con el usuario el monto del reembolso y el tiempo de acreditación. -- **Cumplimiento del proceso**: análisis de la secuencia de llamadas a herramientas, como verificar si se obtuvo la confirmación explícita del usuario antes de modificar el pedido. +Un conjunto de evaluación en producción suele tener tres fuentes. -El entorno de control dual de τ²-bench (mencionado previamente) añade una dimensión adicional en el nivel de verificación: tras modificar el simulador de usuario el estado del entorno, el Agente debe observar este cambio mediante llamadas a herramientas y continuar con la resolución, evaluando si "el Agente realmente leyó los resultados de las operaciones del lado del usuario". +**Los benchmarks públicos** sirven para el cribado grueso de modelos y para tomar prestadas técnicas de diseño, y por lo general no para decisiones de producto. Su distribución de tareas no coincide con la del negocio real: subir dos puntos porcentuales en GAIA no guarda relación necesaria con la tasa de éxito de las devoluciones. -OSWorld cuenta con 134 funciones de evaluación independientes con permisos de acceso completos al sistema operativo, capaces de inspeccionar a fondo estructuras del sistema de archivos, estados de procesos, conexiones de red y estados internos de aplicaciones. Por ejemplo, en tareas de bases de datos, el script de evaluación no solo verifica si el archivo de reporte existe, sino que se conecta directamente a la base de datos para comprobar si la sentencia SQL se ejecutó correctamente; en tareas de navegador analiza el árbol DOM, comprueba cookies/localStorage y envía solicitudes de verificación al backend para confirmar si el formulario se procesó realmente. Esta inspección profunda permite detectar casos de "completado en superficie pero con error sustancial" (como cuando el Agente hace clic en enviar, pero la solicitud es rechazada por el servidor debido a errores en los campos). +**El conjunto de negocio propio** cubre la distribución real de tareas y puede servir de base para la elección de modelo y para las decisiones de diseño del Harness. Por ejemplo, τ²-bench puede usarse tal cual como esqueleto de cualquier sistema de evaluación que necesite un usuario simulado: basta con sustituir los datos del dominio y el conjunto de herramientas. -Terminal-Bench estandariza los entornos mediante contenedores Docker, combinando la inspección del sistema de archivos (existencia de rutas, valores de permisos, formatos de contenido) y la verificación funcional de ejecución (en build-linux-kernel-qemu inicia realmente QEMU y busca mensajes printk personalizados), haciendo rastreables las fugas mediante identificadores canario GUID. +**El retorno de trayectorias de producción** procede de fallos reales en explotación: correcciones explícitas del usuario, votos negativos del usuario y casos detectados a posteriori mediante comprobaciones de estado, verificadores basados en reglas o revisión con LLM. Tras la atribución de fallos, se decantan en casos de regresión. El procedimiento concreto se describe más adelante en «Atribución de fallos» y «Tareas de regresión de extremo a extremo y de prefijo de trayectoria». Esta fuente es la más cara y también la más exacta, porque procede directamente de lo que los usuarios encontraron en la práctica. -### Diseño Sistemático de la Distribución de Tareas +En la fase inicial suele haber solo benchmarks públicos y un pequeño conjunto de negocio escrito a mano; una vez que el sistema lleva un tiempo en producción, los casos devueltos desde las trayectorias de producción pasan a ser el grueso. -La distribución de tareas debe cubrir sistemáticamente dimensiones de capacidad, dificultad, escenarios y casos límite. GAIA busca la generalidad: la mayoría de las tareas requieren combinar razonamiento, multimodalidad, navegación y herramientas. τ²-bench diseña intencionalmente "tareas trampa" (por ejemplo, cuando un usuario afirma que "la atención al cliente aprobó la cancelación" pero en realidad no cumple la política), probando si el Agente mantiene un criterio correcto ante la presión y la desinformación. OSWorld utiliza una matriz bidimensional basada en tipos de operación (E/S de archivos, aplicaciones de escritorio, aplicaciones web, flujos entre aplicaciones) y dominios de aplicación, abarcando tres sistemas operativos (las investigaciones demuestran que las capacidades entre SO están fuertemente correlacionadas, de modo que las habilidades aprendidas en un sistema se pueden transferir a otros). Terminal-Bench incluye "tareas combinadas entre stacks tecnológicos" para evaluar el pensamiento sistémico (como integrar procesamiento de datos + operaciones de archivos + refragmentado en ingeniería Python). +## Métodos de evaluación automatizada -### Control de Calidad de Datos e Iteración Continua +Los benchmarks tratados en las secciones anteriores tienen un rasgo común: sus verificadores son casi todos deterministas. SWE-bench ejecuta una suite de tests, AndroidWorld hace aserciones sobre el estado final de la UI, GAIA compara cadenas de forma exacta, y las cuatro capas de comprobación de τ²-bench se ejecutan igualmente por completo en código. Esta elección tiene buenas razones: la verificación determinista no añade coste de modelo, el resultado es plenamente reproducible, puede integrarse en la integración continua como un test unitario y facilita ordenar modelos entre sí. -SWE-Bench Verified es un modelo de control de calidad. OpenAI seleccionó aleatoriamente 1.699 tareas del total de 2.294 originales para evaluación manual, contratando a 93 desarrolladores expertos en Python. Los anotadores debían realizar múltiples comprobaciones: si la descripción del problema era clara (si se entendía lo que se debía resolver), si los casos de prueba eran completos (cubriendo todos los aspectos y condiciones límite), si las pruebas eran estables (sin fallos fluctuantes por el entorno o aleatoriedad), si el parche era correcto (sin introducir nuevos errores) y si la dificultad era adecuada. Tras un riguroso filtrado, solo 500 tareas pasaron la prueba (29%), representando esta alta tasa de eliminación una inversión necesaria en la calidad de la evaluación. También establecieron guías de anotación estandarizadas definiendo criterios concretos y ejemplos para cada revisión, garantizando la consistencia entre distintos anotadores. +El precio es que solo puede evaluar si el resultado final es correcto, pero no dar la causa del error. La tarea fallida de τ²-bench acabó con 0 puntos, y ese 0 no dice si el Agent se equivocó en la elección de línea o si se saltó el paso de recarga de datos, y menos aún apunta qué habría que cambiar a continuación. Para un benchmark público destinado a rankings esto no es un defecto; para un sistema en producción que necesita mejorar de forma continua, es justo la información más necesaria. -τ²-bench introdujo la separación entre "información conocida" e "instrucciones de tarea" (haciendo más real el comportamiento del simulador) y condiciones de finalización más estrictas (como "solo calificar como resuelto si es excelente, rechazando resultados regulares o buenos"), evitando "reparaciones superficiales". +En producción hay además una segunda dificultad: muchos juicios sencillamente no pueden escribirse como aserciones comprobables por código. Si una respuesta a una reclamación está bien planteada, si un informe omite información clave, si una recuperación de memoria confundió la relación entre personas: nada de esto tiene un estado final único que consultar, ni puede decidirse por coincidencia de palabras clave. -OSWorld-Verified representa un ejemplo de iteración continua. Tras su publicación en abril de 2024, OSWorld se convirtió rápidamente en un benchmark relevante para la evaluación de Agentes multimodales; sin embargo, a lo largo de 15 meses de uso amplio, expuso más de 300 problemas. Estos problemas se dividieron en cuatro categorías: problemas del entorno (anti-crawling en sitios web / CAPTCHA / cambios de contenido dinámico), problemas en la descripción de tareas (expresiones ambiguas), problemas en la lógica de verificación (demasiado estricta o permisiva) y problemas en el estado inicial (configuración incompleta). El equipo de la Universidad de Hong Kong formó un grupo de unas 10 personas que colaboró durante dos meses con MoonShot AI, OpenAI, ByteDance Seed TARS, Anthropic y Simular para realizar reparaciones sistemáticas. Se formularon estrategias para cada categoría: los problemas de entorno se resolvieron congelando versiones y creando copias de respaldo offline; las descripciones ambiguas se eliminaron reescribiendo los enunciados; la lógica de verificación se equilibró ajustando condiciones y creando líneas base correctas manualmente; y el estado inicial se reforzó añadiendo validaciones de integridad. +Por eso, al pasar de los benchmarks públicos a la evaluación en producción, el modo de verificación tiene que desplazarse hacia la derecha a lo largo de un espectro cuyo eje horizontal es el **grado de verificabilidad mecánica** de la tarea, tal como muestra la Figura 7-4. -## Métodos de Evaluación Automatizada +![Figura 7-4 Espectro de modos de verificación: de la verificación determinista al juicio del modelo](images/fig7-4.svg) -Con el entorno de evaluación, los datasets y el sistema de métricas definidos, la pregunta clave es: ¿cómo puntuar? Para tareas con respuestas correctas bien definidas (como problemas matemáticos o consultas SQL), basta con una evaluación binaria simple (correcto/incorrecto); sin embargo, para tareas de respuesta abierta (como diálogos de atención al cliente o redacción de informes), se requieren métodos de evaluación más refinados. +Las dos herramientas del lado derecho del espectro se convierten así en el grueso de la evaluación en producción: el **Rubric** descompone el difuso «qué tal está» en varias dimensiones puntuables por separado, y **LLM-as-a-Judge** puntúa allí donde no existe un criterio determinista. Solo juntas permiten reducir una tasa de fallo genérica a problemas concretos sobre los que actuar; combinadas con la **atribución de fallos** de la segunda mitad de esta sección, forman el bucle cerrado completo de la evaluación de un Agent en producción. -La verificación automática de código solo cubre escenarios con respuestas estándar; la puntuación de tareas abiertas constituye el tema de esta sección. En este ámbito, la densidad de las señales de recompensa (desde recompensas binarias a recompensas de proceso y recompensas generativas), así como los métodos de entrenamiento de modelos de recompensa, se reservan para una discusión sistemática en la sección de post-entrenamiento del Capítulo 8. Esta sección responde a una pregunta más fundamental: cómo utilizar LLMs para evaluar automáticamente la calidad del resultado en tareas abiertas. +Conviene precisar que desplazarse a la derecha no significa renunciar a la izquierda. Toda comprobación que pueda escribirse como aserción de programa debe seguir siendo una aserción, y el juicio del LLM se reserva para las dimensiones que realmente no admiten decisión mecánica. Las comprobaciones deterministas son más baratas y estables, y encajan mejor como tests de regresión ejecutados a largo plazo. ### LLM-as-a-Judge — El Núcleo de la Evaluación Automatizada -![Figura 7-4 Pipeline de LLM-as-a-Judge](images/fig7-4.svg) +![Figura 7-5 Pipeline de LLM-as-a-Judge](images/fig7-5.svg) ¿Por qué se necesita LLM-as-a-Judge? Para tareas abiertas (como generar informes, gestionar quejas de clientes o contenido creativo), no existen respuestas estándar para comparar automáticamente, y la evaluación humana resulta costosa y difícil de escalar. LLM-as-a-Judge permite que un modelo de lenguaje evalúe según criterios de puntuación (Rubric) definidos por expertos, logrando un equilibrio entre la escala automatizada y el juicio profesional humano. No obstante, este método presenta limitaciones conocidas: los modelos evaluadores pueden tener sus propios sesgos (el más típico es el **sesgo de longitud / length bias**, tendiendo a dar puntuaciones más altas a respuestas más largas y detalladas, incluso si el contenido no es más correcto), y múltiples evaluaciones sobre la misma entrada pueden presentar fluctuaciones. El sesgo de longitud requiere prevención específica mediante tres vías: penalizar explícitamente la verborrea en la Rúbrica, fijar límites máximos de longitud de respuesta para tareas similares y auditar periódicamente la correlación entre la puntuación y la longitud de la respuesta (si las puntuaciones altas van casi siempre acompañadas de respuestas largas, indica que el juicio se ha desviado por la longitud y se debe revisar la Rúbrica). Para responder sistemáticamente a estos desafíos, el diseño de la Rúbrica debe seguir los siguientes principios: @@ -358,7 +364,7 @@ rubric: Al enviar la rúbrica junto con la respuesta real del Agente, el modelo evaluador puntúa cada dimensión y explica el motivo. Al reunir decenas de casos y volver sobre las trayectorias peor puntuadas, una caída genérica de la tasa de éxito se convierte en un diagnóstico concreto: faltó recuperar un dato, se relacionaron mal las personas o se añadió información sin respaldo. La rúbrica, por tanto, no se limita a decir cuánto falló el sistema; también orienta la siguiente mejora. -A continuación tomamos la memoria del usuario como caso concreto, para mostrar cómo llevar este método general a un conjunto de evaluación y un evaluador ejecutables. +A continuación tomamos la memoria del usuario como caso concreto, para mostrar cómo llevar este método general a un conjunto de evaluación y un verificador ejecutables. > **Experimento 7-3 ★★: Construcción de un Sistema de Evaluación de Memoria de Usuario Basado en Rubrics** > @@ -527,7 +533,7 @@ En la selección práctica de modelos, la pregunta habitual es: "¿cuál es mejo ### Comparación por Pares y Ranking de Modelos -![Figura 7-5 Elo Rating y Ranking de Comparación por Pares](images/fig7-5.svg) +![Figura 7-6 Elo Rating y Ranking de Comparación por Pares](images/fig7-6.svg) El **sistema de puntuación Elo** (un sistema de ranking diseñado originalmente para el ajedrez) cuantifica la capacidad relativa de los modelos mediante un gran número de enfrentamientos de dos en dos: a mayor diferencia de puntuación, mayor es la tasa de victoria esperada del más fuerte. Por ejemplo, si el modelo A tiene 1.200 puntos y el modelo B 1.000 puntos, el sistema Elo predecirá una probabilidad de victoria para A cercana al 76%. Si B gana inesperadamente, B sumará más puntos y A perderá más puntos: los resultados imprevistos provocan ajustes de puntuación más drásticos, permitiendo que el ranking converja rápidamente hacia el nivel real. La base estadística subyacente es el **modelo Bradley-Terry**: abstrae cada modelo como una "puntuación de capacidad" latente, donde la probabilidad de victoria en enfrentamientos directos está determinada por la diferencia de puntuación entre ambos, siendo Elo la implementación de ingeniería en forma de actualización en línea de dicho modelo. @@ -687,7 +693,7 @@ Al validar varias hipótesis en paralelo hay que considerar además las **compar Las decisiones impulsadas por la evaluación (tanto en la selección de modelos como en la iteración continua) dependen de datos de ejecución de alta calidad. A continuación se presenta cómo recolectar sistemáticamente estos datos (observabilidad) y cómo transformar los resultados de evaluación en mejoras del sistema. -![Figura 7-6 Stack Tecnológico de Observabilidad](images/fig7-6.svg) +![Figura 7-7 Stack Tecnológico de Observabilidad](images/fig7-7.svg) El concepto de observabilidad (Observability) proviene de los sistemas distribuidos: ante la imposibilidad de abrir el sistema internamente para ver qué ocurre, se deduce lo sucedido mediante los logs, métricas y datos de rastreo emitidos, del mismo modo que un médico no ve directamente el interior del cuerpo del paciente y diagnostica a través de señales externas como la temperatura, presión arterial o imágenes médicas. Los sistemas de Agentes complican este escenario: una misma entrada puede generar salidas distintas, la inferencia multiturno y las llamadas a herramientas vuelven la ruta de ejecución sumamente compleja, y el proceso de "pensamiento" del modelo resulta totalmente opaco hacia el exterior. @@ -707,7 +713,7 @@ Contando con un sistema de evaluación completo y conjuntos de datos, la clave r Veamos ahora un ajuste real de AndroidWorld conservado en el repositorio. El piloto cubrió solo cuatro tareas de configuración Wi-Fi en un emulador con API 35, con una ejecución emparejada por tarea. No es el benchmark completo de 116 tareas ni sustituye la repetición en el entorno de referencia con API 33. Su valor está en mostrar cómo los datos de una ronda determinan el único cambio de la siguiente, no en demostrar una mejora global del sistema. -![Figura 7-7 Bucle de Benchmark a Mejoras](images/fig7-7.svg) +![Figura 7-8 Bucle de Benchmark a Mejoras](images/fig7-8.svg) Desde la perspectiva de la ingeniería de Harness, esta sección aborda la metodología de iteración y optimización del Harness: localizar los puntos débiles del Harness mediante datos de evaluación (¿contexto insuficiente?, ¿falta de restricciones?, ¿verificación deficiente?, ¿retroalimentación extemporánea?), aplicar mejoras dirigidas y reevaluar para formar un bucle cerrado de evolución continua. @@ -815,7 +821,7 @@ El destino de la evaluación no es calificar, sino mejorar. Este capítulo ha mo Las dos orillas de este puente se conectan de la siguiente manera. Los activos acumulados en el lado de la evaluación se pueden transformar de manera casi directa en señales de entrenamiento: una Rúbrica o verificador bien definido es en esencia una **función de recompensa para aprendizaje por refuerzo con recompensas verificables (RLVR, Reinforcement Learning with Verifiable Rewards)**, donde los scripts de puntuación actúan directamente como scripts de recompensa, siendo la superación de pruebas o el cumplimiento de estados tanto el criterio de evaluación como el retorno en aprendizaje por refuerzo. Sin embargo, el entrenamiento plantea nuevos requisitos que la fase de evaluación no necesita atender. El primero es una **semántica de reset confiable**: el entrenamiento ejecuta millones de episodios (un episodio es un ciclo completo de interacción desde el estado inicial hasta la finalización de la tarea), debiendo cada episodio poder restablecer el entorno a un estado inicial limpio y determinado para evitar que las señales de gradiente se contaminen con residuos del turno anterior. El segundo es un **throughput (rendimiento de procesamiento) enormemente superior al de la evaluación**: mientras evaluar unos miles de veces basta para extraer conclusiones, el entrenamiento exige entregar millones de interacciones al modelo en un tiempo de reloj aceptable, siendo la paralelización del entorno y el costo por instancia los factores que determinan la viabilidad del entrenamiento. Ambos puntos (verificadores convertidos en funciones de recompensa, y reset junto a throughput orientados al entrenamiento) se desplegarán en el Capítulo 8. -![Figura 7-8 Espectro de Fidelidad de Simulación](images/fig7-8.svg) +![Figura 7-9 Espectro de Fidelidad de Simulación](images/fig7-9.svg) En los **entornos digitales**, el framework AWorld construyó un sandbox de servidores MCP controlables para las tareas de GAIA, ofreciendo 26 servidores MCP que abarcan 126 funciones de herramientas, evitando el bloqueo de cuentas y efectos secundarios incontrolables derivados del acceso directo a APIs reales. Todas las llamadas a herramientas se pueden reproducir y auditar. La arquitectura distribuida de AWorld redujo la ejecución en serie tradicional de 7.695 segundos a 525 segundos (aceleración de 14,6 veces), y el diseño sin estado del entorno independiza por completo cada instancia, admitiendo una paralelización eficiente. @@ -825,7 +831,7 @@ En los **entornos encarnados**, RoboTwin2 construye tareas de manipulación con > > Configurar un entorno de simulación para manipulación robótica. Leer `ch7/SimpleVLA-RL` y la documentación de OpenVLA para comprender la arquitectura de modelos de visión-lenguaje-acción (integración de extremo a extremo de codificador visual + modelo de lenguaje + decodificador de acciones, proyectando imágenes y texto a un espacio semántico compartido). Configurar el entorno RoboTwin2, comprendiendo el espacio de observación (RGB de tres perspectivas + estado articular de 14 dimensiones) y el espacio de acciones (vector de control de 14 dimensiones). Estudiar el mecanismo de aleatorización del entorno y la lógica de restricciones espaciales en move_can_pot. Ejecutar la evaluación de modelos preentrenados, registrando la tasa de éxito, tiempo de finalización y patrones de fallo, prestando especial atención al impacto del mecanismo de chunking de acciones. > -> ![Figura 7-9 Entorno de Inteligencia Encarnada OpenVLA y RoboTwin2](images/fig7-9.svg) +> ![Figura 7-10 Entorno de Inteligencia Encarnada OpenVLA y RoboTwin2](images/fig7-10.svg) ### Sopesado de Fidelidad y Aleatorización de Dominio @@ -835,7 +841,7 @@ Los entornos de alta fidelidad permiten una mejor transferencia al mundo real, p ## Resumen del Capítulo -Este capítulo ha girado en torno a una pregunta central: ¿cómo determinar si un Agente ha mejorado de verdad? Desde los entornos reproducibles y los datasets resistentes a fugas hasta el uso de LLMs como jueces y la iteración guiada por resultados, cada eslabón condiciona la confiabilidad de la conclusión. Los experimentos aportan cuatro advertencias concretas: unir memoria estructurada y RAG no garantiza sinergia; los ahorros de caché y compresión no se suman; la elección del audio de referencia cambia el significado de la puntuación multimodal; y la capacidad de leer una interfaz —junto con su costo en tokens— depende de cómo el Harness represente la entrada. La selección de modelos debe comparar curvas de capacidad bajo distintos presupuestos, no solo un punto. En producción, evaluar no es celebrar un examen ocasional, sino verificar de forma continua cada decisión de producto. +Este capítulo ha girado en torno a una pregunta central: ¿cómo determinar si un Agente ha mejorado de verdad? La cadena consta de cuatro etapas: primero precisar qué cuenta como éxito (las bases distintas de Pass@k, Best@k y Pass consecutive@k), después decidir de dónde salen las tareas (benchmarks públicos, conjunto de negocio propio y retorno de trayectorias de producción), luego elegir el modo de verificación (de los verificadores deterministas a las listas de comprobaciones, el Rubric con juicio de LLM y, finalmente, la comparación por pares) y, por último, convertir las puntuaciones en decisiones (significancia estadística, atribución de fallos, tareas de regresión y elección de modelo). Cada eslabón condiciona la confiabilidad de la conclusión. Los experimentos aportan cuatro advertencias concretas: unir memoria estructurada y RAG no garantiza sinergia; los ahorros de caché y compresión no se suman; la elección del audio de referencia cambia el significado de la puntuación multimodal; y la capacidad de leer una interfaz —junto con su costo en tokens— depende de cómo el Harness represente la entrada. La selección de modelos debe comparar curvas de capacidad bajo distintos presupuestos, no solo un punto. En producción, evaluar no es celebrar un examen ocasional, sino verificar de forma continua cada decisión de producto. En términos de la estructura del libro, este capítulo construye el tramo de **evidencia** del bucle de descubrimiento del capítulo 1: la atribución de fallos determina si las propuestas posteriores tienen algo sólido en lo que apoyarse. diff --git a/book-es/images/fig7-1.svg b/book-es/images/fig7-1.svg index c309ae598..71c47a946 100644 --- a/book-es/images/fig7-1.svg +++ b/book-es/images/fig7-1.svg @@ -1,19 +1,62 @@ - - - -Capa 1: Evaluar el entorno -"Dónde probar" — Llamada a herramientas / Interacción persona-computadora / Entorno de simulación - - -Capa 2: Métodos de evaluación -"Cómo evaluar" — Diseño de dataset · LLM-as-a-Judge · Comparación por pares y ranking - - -Capa 3: Decisiones guiadas por evaluación -"Qué hacer tras las pruebas" — Selección de modelo · Optimización de arquitectura · Iteración continua - -Temas de ingeniería a lo largo del capítulo -• Observabilidad -• Entorno de simulación -• Evaluación interna - \ No newline at end of file + + + + + + + + +① Definición de éxito +Pass@k mide el techo · Pass^k mide la fiabilidad + + + +② Origen de las tareas + +Benchmarks públicos +Técnicas · cribado grueso + +Conjunto propio +Distribución real de tareas + +Retorno de producción +Producto de la atribución + + + +③ Modo de verificación +← por grado de verificabilidad mecánica de la tarea → + +Determinista +SWE-bench + + +Lista de comprobaciones +τ²-bench + + +Rubric + LLM +Tareas abiertas + + +Por pares +Chatbot Arena + + + +④ Uso de los resultados +Significancia → Atribución → Regresión → Modelo y Harness + + +Las regresiones se vuelven casos nuevos + + +Infraestructura de apoyo +Observabilidad · Infra. interna de evaluación (ablación / AB / flags) · Simulación (capítulo 8) + diff --git a/book-es/images/fig7-10.svg b/book-es/images/fig7-10.svg new file mode 100644 index 000000000..3776c001a --- /dev/null +++ b/book-es/images/fig7-10.svg @@ -0,0 +1,69 @@ + + + + +Observación multimodal + +Cámara de cabeza +224×224 RGB + +Cámara de la muñeca izquierda +224×224 RGB + +Cámara de muñeca derecha +224×224 RGB + +Vector de estado articular de 14 dimensiones + +Modelo de Visión-Lenguaje-Acción (VLA) + +Codificador de visión +SigLIP → tokens visuales + + +Modelo de lenguaje +Backbone Llama 2 7B + + +Decodificador de acciones +→ Vector de control continuo de 14 dimensiones +Agrupamiento de acciones: generar 25 acciones consecutivas a la vez + + + +Instrucción: "Pon la lata en la olla" + + +Motor de física SAPIEN + +Robot de dos brazos +7 DOF cada uno = acción de 14 dimensiones + +Aleatorización del entorno +Posición 60cm / orientación ±22.5° + +Detección de colisiones + simulación física +Cuerpo rígido / cuerpo blando / fricción + +Acción + +Observación + +Métricas de evaluación + +Tasa de éxito +Lata dentro de la olla +y no caído + +Tiempo de finalización +25 pasos × 25 acciones += 625 pasos de control + +Capacidad de generalización +Posición/orientación cruzada +/Variante de apariencia + +Sim-to-Real +Aleatorización del dominio +→ Migración real + \ No newline at end of file diff --git a/book-es/images/fig7-3.svg b/book-es/images/fig7-3.svg index 4b1098ae7..42bea5c87 100644 --- a/book-es/images/fig7-3.svg +++ b/book-es/images/fig7-3.svg @@ -1,68 +1,76 @@ - - + + + + + + + - -Simulador de usuario (LLM) - -Información conocida: -Nombre: Sarah Johnson -Reserva: BK-98712 -Instrucción de la tarea: -"Parece que hay un problema con el vuelo" -→ Revelar detalles gradualmente -→ No proporcionar proactivamente el número de reserva - -Agente (A evaluar) - - -Razonamiento del LLM + Selección de estrategia -① ¿Me permite su número de reserva? -② lookup_booking(BK-98712) -③ El vuelo UA123 ha sido cancelado -④ cancel_booking(BK-98712) -⑤ Reembolso de $150, 3-5 días hábiles - -Herramientas + Base de datos - -lookup_booking -Consultar detalles de la reserva -modify_booking -Modificar estado de la reserva -cancel_booking -Cancelar y reembolsar -search_flights -Buscar vuelos alternativos -send_notification -Enviar notificación de confirmación - -Estado de la DB: -reservas, usuarios, vuelos - -Diálogo - - -Llamada a herramienta - - -Entorno de control dual: El simulador de usuario también puede operar directamente el entorno compartido (herramientas + base de datos) - -Tras completar la tarea: Verificación multicapa - -Verificación del estado de la DB - -booking.status == 'cancelled' -refund_record EXISTS -refund.amount == 150.00 - -Verificación del contenido del diálogo - -Contiene 'reembolso' + monto -Contiene 'hora de llegada' -No hay información falsa presente - -Verificación de cumplimiento del proceso - -Obtener confirmación del usuario antes de modificar -Sin operaciones no autorizadas -Sin transferencia excesiva al agente humano - \ No newline at end of file + + +Simulador de usuario (LLM) +known_info: John Smith / 555-123-2002 / en Francia +task_instructions: divulgación · emoción · anclaje +Aceptación: solo excellent cuenta como resuelto + + + +Agent (evaluado) +Entrada: ticket + política del dominio +No visible: estado real del dispositivo +Solo puede guiar, no actuar por el usuario + + + +Diálogo multiturno +Divulgación progresiva + + + +Entorno compartido (doble control: ambos lados cambian el estado) + +Estado del dispositivo +Modo avión ON · itinerancia OFF · ahorro · datos restantes +Herramientas del usuario: toggle_airplane_mode / toggle_roaming + check_status_bar / run_speed_test + +Base de datos del operador +Cliente C1001 · líneas L1001/L1002/L1003 · tarifas · facturas +Herramientas del Agent: get_customer_by_phone / get_data_usage + enable_roaming / refuel_data + + + + + + +El toggle_roaming del usuario cambió el entorno; el Agent debe volver a llamar a una herramienta — la verificación cubre esa relectura + + + +Al terminar: cuatro capas de comprobaciones + regla de agregación + +env_assertions +Datos móviles disponibles +Velocidad ≥ 200 / excellent + +actions +toggle_airplane_mode +requestor debe ser user + +communicate_info +¿Se comunicó lo necesario? +null en esta tarea + +nl_assertions +Juicio en lenguaje natural +null en esta tarea +reward_basis = ["ENV_ASSERTION"] → solo cuenta la primera capa; el resto se registra pero no entra en la recompensa + diff --git a/book-es/images/fig7-4.svg b/book-es/images/fig7-4.svg index a73c4d347..2f33e6ac7 100644 --- a/book-es/images/fig7-4.svg +++ b/book-es/images/fig7-4.svg @@ -1,53 +1,54 @@ - - + + + + + + - -Rúbrica - -Corrección factual: Esencial -Coherencia lógica: Importante -Detección de alucinaciones: Veto ⚠ -Exhaustividad: Importante - -Respuesta candidata - -Salida del agente: -"Reembolso procesado, se acreditarán $150 en un plazo de - 3-5 días hábiles." - - -Solución de referencia (Opcional) - -Respuesta estándar / Puntos de evaluación: -Debe incluir el monto del reembolso -Debe incluir el tiempo de crédito -No se puede prometer una fecha específica - - - - -Modelo juez (GPT-5 / Gemini 2.5) -Evaluación heterogénea de múltiples fuentes para evitar el sesgo de la misma fuente - - -Salida de evaluación estructurada - -Corrección factual -4/4 -Tanto la cantidad como el tiempo son precisos -Exhaustividad -3/4 -Falta la explicación del método de reembolso -Detección de alucinaciones -APROBADO -Sin información falsa -Coherencia lógica -4/4 -Relación causal clara - -Estrategia de agregación de puntuaciones -Promedio ponderado: Σ(peso × puntuación de dimensión) -Veto: Alucinación=FALLO → puntuación total=0 -Multijuez: mediana de 3 jueces -Marca de caso límite: desacuerdo >2 puntos → revisión humana - \ No newline at end of file + +Verificabilidad mecánica de la tarea: alta +baja + + +Determinista +Estado final único y consultable +Pasa / no pasa +SWE-bench ejecuta tests + + + +Lista de comprobaciones +Varias comprobaciones deterministas +Agregado según la base declarada +Cuatro capas de τ²-bench + + + +Rubric + LLM +Hay dimensiones, no código +Puntúa por dimensión y razona +Calidad de atención, informes + + + +Por pares +Cuesta hasta enunciar dimensiones +Solo juzga A frente a B +Chatbot Arena + + +Verificación determinista +Totalmente reproducible, apta para CI, barata +Precio: dice si está bien, no dónde falla + + +Juicio del modelo +Da dimensiones diagnósticas y cubre lo no aseverable +Precio: sesgo y varianza del juez, más coste + diff --git a/book-es/images/fig7-5.svg b/book-es/images/fig7-5.svg index ca2cb7b0c..a73c4d347 100644 --- a/book-es/images/fig7-5.svg +++ b/book-es/images/fig7-5.svg @@ -1,56 +1,53 @@ - + - -Batalla anónima en Chatbot Arena - -Modelo A (Anónimo) - -"Reembolso procesado, llegará en 3-5 - días hábiles a su cuenta" -VS - -Modelo B (Anónimo) - -"De acuerdo, se procesará el reembolso" - - -Elección a ciegas del usuario → A es mejor - -Fórmula de actualización de Elo -Tasa de victorias esperada E_A = 1/(1+10^((R_B-R_A)/400)) | Actualización: R_A' = R_A + K*(1-E_A) -Tabla de clasificación en vivo (Ejemplo) -Rango -Modelo -Elo -Tasa de victorias vs. #2 - -1 -Claude 4 Opus -1352 -— -2 -GPT-5 -1318 -— -3 -Gemini 2.5 Pro -1290 -45% -4 -DeepSeek R2 -1265 -42% -5 -Qwen 3 Max -1230 -39% -6 -Llama 4 405B -1198 -36% - - -GRPO: Introducción de comparación por pares en el entrenamiento RL -Conjunto de respuestas candidatas → Normalizar ventaja relativa → Actualización de política (omitir modelo de recompensa explícito) + +Rúbrica + +Corrección factual: Esencial +Coherencia lógica: Importante +Detección de alucinaciones: Veto ⚠ +Exhaustividad: Importante + +Respuesta candidata + +Salida del agente: +"Reembolso procesado, se acreditarán $150 en un plazo de + 3-5 días hábiles." + + +Solución de referencia (Opcional) + +Respuesta estándar / Puntos de evaluación: +Debe incluir el monto del reembolso +Debe incluir el tiempo de crédito +No se puede prometer una fecha específica + + + + +Modelo juez (GPT-5 / Gemini 2.5) +Evaluación heterogénea de múltiples fuentes para evitar el sesgo de la misma fuente + + +Salida de evaluación estructurada + +Corrección factual +4/4 +Tanto la cantidad como el tiempo son precisos +Exhaustividad +3/4 +Falta la explicación del método de reembolso +Detección de alucinaciones +APROBADO +Sin información falsa +Coherencia lógica +4/4 +Relación causal clara + +Estrategia de agregación de puntuaciones +Promedio ponderado: Σ(peso × puntuación de dimensión) +Veto: Alucinación=FALLO → puntuación total=0 +Multijuez: mediana de 3 jueces +Marca de caso límite: desacuerdo >2 puntos → revisión humana \ No newline at end of file diff --git a/book-es/images/fig7-6.svg b/book-es/images/fig7-6.svg index 1b91f4302..ca2cb7b0c 100644 --- a/book-es/images/fig7-6.svg +++ b/book-es/images/fig7-6.svg @@ -1,48 +1,56 @@ - - - -Árbol de traza de ejecución (tarea única) - -Traza: Consultar el tiempo en Beijing para el usuario mañana (3.2s, $0.008) - -Llamada al LLM: Reconocimiento de intención -Claude 4 Sonnet · 0.4s · 320 tokens - -Herramienta：get_weather(Beijing) -Servidor MCP · 1.8s · 200ms TTFT - -├─ Solicitud HTTP -api.weather.com · 1.6s - -└─ Análisis de respuesta -JSON → Datos meteorológicos estructurados - -Llamada al LLM: Generar respuesta -Claude 4 Sonnet · 0.8s · 580 tokens - -Herramienta：send_message(user) -0.2s · Contiene resumen del clima - - - - - - - -Panel de monitoreo - -Seguimiento de costos -Hoy: $12.30 (1,200 llamadas) -Este mes: $340 (34K llamadas) -Anomalía: la tarea#892 buscó en bucle 14 veces, coste $2.1 - -Monitoreo de rendimiento -Latencia P50 / P95 / P99: 2.1s / 8.4s / 15.2s -Tasa de éxito de herramientas: 94.3% - -Auditoría de calidad -Tasa de éxito de tareas: 87% Activación de alucinaciones: 2.1% -Violaciones de seguridad: 0 (este mes) Satisfacción del usuario: 4.3/5 - -Bucle cerrado: Datos de traza → Identificar problemas → Pruebas A/B →Gestión de versiones de prompts → Optimización continua - + + + + +Batalla anónima en Chatbot Arena + +Modelo A (Anónimo) + +"Reembolso procesado, llegará en 3-5 + días hábiles a su cuenta" +VS + +Modelo B (Anónimo) + +"De acuerdo, se procesará el reembolso" + + +Elección a ciegas del usuario → A es mejor + +Fórmula de actualización de Elo +Tasa de victorias esperada E_A = 1/(1+10^((R_B-R_A)/400)) | Actualización: R_A' = R_A + K*(1-E_A) +Tabla de clasificación en vivo (Ejemplo) +Rango +Modelo +Elo +Tasa de victorias vs. #2 + +1 +Claude 4 Opus +1352 +— +2 +GPT-5 +1318 +— +3 +Gemini 2.5 Pro +1290 +45% +4 +DeepSeek R2 +1265 +42% +5 +Qwen 3 Max +1230 +39% +6 +Llama 4 405B +1198 +36% + + +GRPO: Introducción de comparación por pares en el entrenamiento RL +Conjunto de respuestas candidatas → Normalizar ventaja relativa → Actualización de política (omitir modelo de recompensa explícito) + \ No newline at end of file diff --git a/book-es/images/fig7-7.svg b/book-es/images/fig7-7.svg index c7d82a313..1b91f4302 100644 --- a/book-es/images/fig7-7.svg +++ b/book-es/images/fig7-7.svg @@ -1,56 +1,48 @@ - - - - -① Observación: Informe de diagnóstico -Tasa de éxito general: 88% (102/116) -transcripción: 0% complex_ui: 17% -math_counting: 0% Operación de Wi-Fi: 0% -Tareas 82,102-115: Fallos concentrados - -② Hipótesis: Marco de mejora de tres capas - -Capa superficial -H1 Establecer prompt de navegación H2 Reglas de UI - -Capa intermedia -H3 Corregir pipeline multimodal H4 Pensamiento - -Capa profunda -H5 GPT-5 H6 Árbol de elementos de UI - - -③ Experimento: Validación por fases (5 ejecuciones × 116 tareas por configuración) - -H1 Navegación -Configuración 0%→75% -token+8% - -H3 Multimodal -Transcripción 0%→80% -Latencia +1s - -H4 Pensamiento -Conteo 0%→70% -Latencia 3x! - -H6 Árbol de elementos -UI 17%→52% -token+30% - -④ Decisión: Compromiso costo-beneficio -✓ H1+H3: Bajo costo, alto beneficio → Desplegar -✗ H4: Solo 8% de tareas se benefician pero 3x latencia → Rechazar -✓ H6: 35% de mejora / 30% de costo → Desplegar -✗ H5: 15 s/paso inaceptable → Alternativa - -⑤ Iteración: Nuevo ciclo -Desplegar H1+H3+H6 → 88%→94% -Nuevo informe muestra diferentes modos de fallo: - H7: Pensamiento condicional habilitado - H8: Expandir el espacio de acciones de gestos - -↑ Bucle - -Metodología: Observar → Hipotetizar → Experimentar → Decidir → Iterar = De la alquimia a la ingeniería científica - \ No newline at end of file + + + +Árbol de traza de ejecución (tarea única) + +Traza: Consultar el tiempo en Beijing para el usuario mañana (3.2s, $0.008) + +Llamada al LLM: Reconocimiento de intención +Claude 4 Sonnet · 0.4s · 320 tokens + +Herramienta：get_weather(Beijing) +Servidor MCP · 1.8s · 200ms TTFT + +├─ Solicitud HTTP +api.weather.com · 1.6s + +└─ Análisis de respuesta +JSON → Datos meteorológicos estructurados + +Llamada al LLM: Generar respuesta +Claude 4 Sonnet · 0.8s · 580 tokens + +Herramienta：send_message(user) +0.2s · Contiene resumen del clima + + + + + + + +Panel de monitoreo + +Seguimiento de costos +Hoy: $12.30 (1,200 llamadas) +Este mes: $340 (34K llamadas) +Anomalía: la tarea#892 buscó en bucle 14 veces, coste $2.1 + +Monitoreo de rendimiento +Latencia P50 / P95 / P99: 2.1s / 8.4s / 15.2s +Tasa de éxito de herramientas: 94.3% + +Auditoría de calidad +Tasa de éxito de tareas: 87% Activación de alucinaciones: 2.1% +Violaciones de seguridad: 0 (este mes) Satisfacción del usuario: 4.3/5 + +Bucle cerrado: Datos de traza → Identificar problemas → Pruebas A/B →Gestión de versiones de prompts → Optimización continua + diff --git a/book-es/images/fig7-8.svg b/book-es/images/fig7-8.svg index 6d187a8ff..c7d82a313 100644 --- a/book-es/images/fig7-8.svg +++ b/book-es/images/fig7-8.svg @@ -1,41 +1,56 @@ - + - - -Fidelidad de la simulación → -Escalabilidad - - - -↑ - -API simulada -nivel de pruebas unitarias -millones de veces/hora - -AWorld -Sandbox de MCP -126 funciones de herramientas -525s/ronda distribuido - -AndroidWorld -Simulador -116 tareas de aplicación del mundo real -UI Automator - -Isaac Gym -Paralelismo en GPU -miles de instancias en paralelo -Precisión ligeramente comprometida - -RoboTwin2 -motor de física -Colisión de alta precisión -CPU de instancia única - -mundo real -Fidelidad perfecta -No reiniciable - + +① Observación: Informe de diagnóstico +Tasa de éxito general: 88% (102/116) +transcripción: 0% complex_ui: 17% +math_counting: 0% Operación de Wi-Fi: 0% +Tareas 82,102-115: Fallos concentrados + +② Hipótesis: Marco de mejora de tres capas + +Capa superficial +H1 Establecer prompt de navegación H2 Reglas de UI + +Capa intermedia +H3 Corregir pipeline multimodal H4 Pensamiento + +Capa profunda +H5 GPT-5 H6 Árbol de elementos de UI + + +③ Experimento: Validación por fases (5 ejecuciones × 116 tareas por configuración) + +H1 Navegación +Configuración 0%→75% +token+8% + +H3 Multimodal +Transcripción 0%→80% +Latencia +1s + +H4 Pensamiento +Conteo 0%→70% +Latencia 3x! + +H6 Árbol de elementos +UI 17%→52% +token+30% + +④ Decisión: Compromiso costo-beneficio +✓ H1+H3: Bajo costo, alto beneficio → Desplegar +✗ H4: Solo 8% de tareas se benefician pero 3x latencia → Rechazar +✓ H6: 35% de mejora / 30% de costo → Desplegar +✗ H5: 15 s/paso inaceptable → Alternativa + +⑤ Iteración: Nuevo ciclo +Desplegar H1+H3+H6 → 88%→94% +Nuevo informe muestra diferentes modos de fallo: + H7: Pensamiento condicional habilitado + H8: Expandir el espacio de acciones de gestos + +↑ Bucle + +Metodología: Observar → Hipotetizar → Experimentar → Decidir → Iterar = De la alquimia a la ingeniería científica \ No newline at end of file diff --git a/book-es/images/fig7-9.svg b/book-es/images/fig7-9.svg index 3776c001a..6d187a8ff 100644 --- a/book-es/images/fig7-9.svg +++ b/book-es/images/fig7-9.svg @@ -1,69 +1,41 @@ - - + + - -Observación multimodal - -Cámara de cabeza -224×224 RGB - -Cámara de la muñeca izquierda -224×224 RGB - -Cámara de muñeca derecha -224×224 RGB - -Vector de estado articular de 14 dimensiones - -Modelo de Visión-Lenguaje-Acción (VLA) - -Codificador de visión -SigLIP → tokens visuales - - -Modelo de lenguaje -Backbone Llama 2 7B - - -Decodificador de acciones -→ Vector de control continuo de 14 dimensiones -Agrupamiento de acciones: generar 25 acciones consecutivas a la vez - - - -Instrucción: "Pon la lata en la olla" - - -Motor de física SAPIEN - -Robot de dos brazos -7 DOF cada uno = acción de 14 dimensiones - -Aleatorización del entorno -Posición 60cm / orientación ±22.5° - -Detección de colisiones + simulación física -Cuerpo rígido / cuerpo blando / fricción - -Acción - -Observación - -Métricas de evaluación - -Tasa de éxito -Lata dentro de la olla -y no caído - -Tiempo de finalización -25 pasos × 25 acciones -= 625 pasos de control - -Capacidad de generalización -Posición/orientación cruzada -/Variante de apariencia - -Sim-to-Real -Aleatorización del dominio -→ Migración real + + +Fidelidad de la simulación → +Escalabilidad + + + +↑ + +API simulada +nivel de pruebas unitarias +millones de veces/hora + +AWorld +Sandbox de MCP +126 funciones de herramientas +525s/ronda distribuido + +AndroidWorld +Simulador +116 tareas de aplicación del mundo real +UI Automator + +Isaac Gym +Paralelismo en GPU +miles de instancias en paralelo +Precisión ligeramente comprometida + +RoboTwin2 +motor de física +Colisión de alta precisión +CPU de instancia única + +mundo real +Fidelidad perfecta +No reiniciable + \ No newline at end of file diff --git a/book-he/chapter7.he.md b/book-he/chapter7.he.md index 3ce250877..13100425a 100644 --- a/book-he/chapter7.he.md +++ b/book-he/chapter7.he.md @@ -17,58 +17,116 @@ מנקודת המבט של הנדסת Harness שהוצגה בפרק 1, ההערכה ממלאת את תפקיד הליבה של "אימות" בתוך ה‑Harness. תובנה מרכזית היא: **מושא ההערכה אינו צריך להיות רק המודל, אלא הצירוף של המודל וה‑Harness**. אותו מודל יכול לתפקד באופן שונה לחלוטין ב‑Harness שונים — צוותים אחדים שיפרו במידה ניכרת את ביצועי אותו מודל במשימות טרמינל אך ורק באמצעות אופטימיזציה של ה‑Harness (ראו פרק 5). לפיכך כשסוכן מקבל ציון נמוך בהערכה, התיקון עשוי שלא להיות מודל אחר אלא רכיב Harness טוב יותר (פרומפטים, עיצוב כלים, לולאות משוב). מערכת הערכה תקינה צריכה להיות מסוגלת להבחין בין שתי בעיות שונות מיסודן: "יכולת מודל בלתי מספקת" ו"פגמים בעיצוב ה‑Harness". **דרך נפוצה להבחין ביניהן היא ניסוי החלפת המודל**: לקבע את ה‑Harness, להחליף למודל חזק או חלש יותר, ולראות בכמה זז הציון. אם מודל חזק יותר אינו מעלה את הציון, צוואר הבקבוק הוא ה‑Harness. אם מודל חלש יותר מפיל את הציון והתוצאות מתנדנדות בחדות עם יכולת המודל, הקריאה הישירה ביותר היא שהמודל עצמו הוא צוואר הבקבוק ושהביצועים הנוכחיים נשלטים על ידי המודל. האם זה משום שהמשימה קשה מטבעה או משום שה‑Harness נשען יתר על המידה על ידע קודם של המודל — הדבר דורש ניתוח נוסף. שימו לב שהדבר נבדל מניסוי האבלציה שלעיל: אבלציה **משביתה רכיב Harness** כדי לראות כיצד משתנים הביצועים הכוללים; החלפת מודל **מקבעת את ה‑Harness ומשנה רק את המודל**. הראשון מאתר איזה חלק בתוך ה‑Harness משנה; השני מגלה לכם האם צוואר הבקבוק הוא המודל או ה‑Harness. מערכת הערכה שווה עוד יותר בעידן של התפתחות מודלים מהירה. מודלים ממשיכים להשתפר, אך מודל חדש שמקבל ציון גבוה יותר במדדי ביצועים ציבוריים לא בהכרח יתפקד טוב יותר במשימה שלכם — הוא עשוי אף לסגת (לתפקד גרוע יותר מהגרסה הישנה בהיבטים מסוימים). רק הרצה מלאה על מערך ההערכה שלכם מאפשרת לכם לקבל החלטת שדרוג מבוססת נתונים. מערכת הערכה איתנה אף הופכת את **"בניית מוצרים למודלים עתידיים"** לאסטרטגיה בת‑קיימא: אם המודל הנוכחי אינו טוב מספיק לפריסה מסחרית, סיימו את המוצר בכל זאת, בנו את מערך ההערכה, עקבו אחר ביצועיו של כל מודל חדש, והשיקו ברגע שאחד מהם עובר את הרף. +מערכת הערכה ניתנת לפירוק לארבע חוליות: מהי הצלחה, מהיכן מגיעות המשימות, מי מאמת, וכיצד ציון הופך להחלטה. איור 7‑1 מציג זאת. + +![איור 7‑1: ארבע החוליות של מערכת ההערכה של Agent](images/fig7-1.svg) + +## נתיחה של משימת הערכה אחת: תחום telecom ב‑τ²-bench + +נתחיל בנתיחה מלאה של משימה אמיתית אחת מתחום telecom של τ²-bench. קוד המקור נמצא במאגר תחת `chapter7/tau2-bench`, וקובץ המשימות הוא `data/tau2/domains/telecom/tasks_small.json`. + +### ארבעת מרכיבי הגדרת המשימה + +להלן אחת המשימות מאותו קובץ, מקוצרת לנוחות הקריאה. + +```jsonc +{ + "id": "[mobile_data_issue]airplane_mode_on|user_abroad_roaming_enabled_off", + + // הכרטיס הנמסר ל‑Agent + "ticket": "הטלפון של המשתמש אינו מתחבר לאינטרנט, ובשורת המצב מופיע 'No Service'. + הלקוח John Smith, מספר 555-123-2002, נמצא כעת בצרפת. הבעיה נחשבת + פתורה רק אם בדיקת המהירות מחזירה excellent. אינו רוצה להחליף חבילה, + אך מוכן לטעון 2.0 ג'יגה-בייט במידת הצורך.", + + // כללי ההתנהגות הנמסרים לסימולטור המשתמש + "user_scenario": { "instructions": { + "known_info": "You are John Smith with phone number 555-123-2002. + You are currently abroad in France.", + "unknown_info": null, + "task_instructions": + "…express mild frustration after the first unsuccessful attempt. + You will consider the issue resolved only when speed test returns + excellent internet speed and nothing else. If it returns poor, fair + or good, you will not consider the issue resolved. + Whenever the agent asks you about your device, always ground your + responses on the results of tool calls. … + Never make up the results of tool calls." + }}, + + // לפני ההרצה שני הצדדים מאופסים לאותה נקודת פתיחה + "initial_state": { "initialization_actions": [ + { "env_type": "user", "func_name": "turn_airplane_mode_on" }, + { "env_type": "user", "func_name": "turn_roaming_off" }, + { "env_type": "assistant", "func_name": "enable_roaming", + "arguments": { "customer_id": "C1001", "line_id": "L1002" } } + ]}, + + // קריטריוני הניקוד + "evaluation_criteria": { + "actions": [ + { "requestor": "user", "name": "toggle_airplane_mode" }, + { "requestor": "user", "name": "toggle_roaming" } + ], + "env_assertions": [ + { "func_name": "assert_mobile_data_status", "expected_status": true }, + { "func_name": "assert_internet_speed", + "expected_speed": 200, "expected_desc": "excellent" } + ], + "communicate_info": null, + "nl_assertions": null, + "reward_basis": ["ENV_ASSERTION"] + } +} +``` -> **מדריך הפרק** -> -> פרק זה בונה מערכת הערכה שלמה בשלוש רמות. הרמה הראשונה היא **עיצוב ההערכה**: כדי להימנע מלדון בכלים ובנתונים תחילה ולהגדיר "הצלחה" באחרונה, הפרק מתחיל בהגדרת מה נחשב הצלחה, ומבחין בין תקרת היכולת של פלאים טכניים לבין האמינות הרצופה שתרחישים עסקיים דורשים; לאחר מכן הוא מפתח סביבות ומערכי נתונים להערכה (היכן לבדוק ומה לבדוק). הרמה השנייה היא **שיטות הערכה** (כיצד לשפוט): ‏LLM‑as‑a‑Judge, השוואה זוגית ודירוג מודלים. הרמה השלישית היא **קבלת החלטות מונחית הערכה** (מה לעשות אחרי הבדיקה): הפיכת תוצאות להנחיה בת‑ביצוע לבחירת מודלים, לאופטימיזציית ארכיטקטורה ולאיטרציה מתמשכת, בתוספת מובהקות סטטיסטית כדי לשפוט האם הפרש ציונים שנצפה הוא אמיתי. הפרק מכסה גם יכולת תצפית ואת תשתית ההערכה הפנימית של סוכנים ברמת ייצור, ונחתם בסביבות הסימולציה המתחברות לאימון־העל שבפרק 8. -> -> הרעיון העובר כחוט השני בפרק כולו: **הערך העיקרי של מערכת הערכה אינו לתת ציון למערכת הנוכחית, אלא לאפשר לכם לעמוד בקצב התפתחות המודלים במהירות ובאמינות.** כשמודל חזק יותר או זול יותר יוצא, צוות בעל מערכת הערכה איתנה יכול להחליט בתוך שעות האם לעבור; צוות שאין לו כזו יכול רק לסמוך על אינטואיציה או להמתין למשוב מהקהילה. בשוק הסוכנים התחרותי מאוד, הפרש מהירות זה יכול להכריע מי ינצח. +בהגדרה הזו יש ארבע החלטות תכנון שראוי לפרט. -![איור 7‑1: שלוש הרמות של מערכת ההערכה](images/fig7-1.svg) +**גבול הידיעה של המשתמש ממודל במפורש.** `known_info` מכיל שלושה פרטים בלבד: שם, מספר טלפון ומדינת השהות. שתי הסיבות האמיתיות לתקלה — מצב טיסה פעיל ונדידת נתונים כבויה — אינן שם. המשתמש אינו יודע עליהן ולכן אינו יכול למסור אותן מיוזמתו, וה‑Agent יכול להשיגן רק בשאלות ובהנחיית המשתמש לבדוק. כך מיושם **גילוי מידע הדרגתי (Progressive Information Disclosure)** ברמת הגדרת המשימה: לא בכבילת הסימולטור בפרומפט מסוג "אל תגלה הכול בבת אחת", אלא במידול תחום הידיעה של המשתמש כשדה נפרד. רוב מבחני הייחוס מציגים את הדרישה המלאה כבר בפתיחת המשימה, בעוד שמשפט הפתיחה של משתמש אמיתי הוא בדרך כלל לא יותר מ"אני לא מצליח להיכנס לאינטרנט". חידוד הבקשה עד שהיא ניתנת לביצוע הוא עצמו חלק ממה ש‑Agent צריך לדעת לעשות. -## דוגמת הערכה מוחשית +**הסימולטור מקבל כללי התנהגות ולא תסריט דיאלוג.** `task_instructions` מכיל שלושה סוגי אילוצים: כוונון רגשי (להביע מורת רוח קלה אחרי ניסיון התיקון הראשון שנכשל), קריטריון קבלה (הבעיה נחשבת פתורה רק אם בדיקת המהירות מחזירה excellent; poor, fair ו‑good נדחים כולם), ודרישת **עיגון עובדתי (Grounding)**, כלומר שכל תשובה על מצב המכשיר תסתמך על הערך שהחזיר כלי: "Never make up the results of tool calls". השלישי הוא הקריטי ביותר: בלי אילוץ העיגון, המשתמש המדומה ילך אחרי הכוונת ה‑Agent ויאשר שהבעיה נפתרה, וההערכה תידרדר לשני מודלים המאשררים זה את זה. -לפני הצלילה למתודולוגיה, נבנה אינטואיציה באמצעות דוגמה שלמה. נניח שבנינו סוכן שירות לקוחות ואנו צריכים להעריך את יכולתו לטפל בבקשות החזר כספי. +**המצב ההתחלתי מחולק לפי הצד השולט.** `env_type` מקבל שני ערכים, `user` ו‑`assistant`: מצב טיסה ומתג הנדידה שייכים לצד המשתמש, ו‑`enable_roaming` בצד המפעיל שייך לצד ה‑Agent. החלוקה הזו היא שקובעת את צורת התקלה: בצד המפעיל הנדידה מופעלת, אך במכשיר המשתמש היא כבויה, ולכן שאילתה של ה‑Agent אל מסד הנתונים מניבה רק את המסקנה "התצורה תקינה". התקלה נמצאת בצד שמסד הנתונים אינו רואה, והיא נחשפת רק כשמנחים את המשתמש לבדוק. -**מקרה בדיקה**: המשתמש רוצה להחזיר הזמנה מלפני 3 ימים (הזמנה מס' 12345, סכום ‏¥299). מדיניות החברה: החזר מלא בתוך 7 ימים. +**קריטריוני הניקוד מחולקים לארבע שכבות, והמשימה הזו משתמשת רק באחת מהן.** `env_assertions` בודק את המצב הסופי (נתונים סלולריים זמינים, מהירות של 200 Mbps ומעלה בדירוג excellent), `actions` בודק אם הפעולות המרכזיות התרחשו ו**איזה צד** ביצע אותן, ואילו `communicate_info` ו‑`nl_assertions` בודקים אם המידע ההכרחי נמסר למשתמש. ה‑`reward_basis` של המשימה הזו מצהיר רק על `ENV_ASSERTION`; יתר השכבות מחושבות ונרשמות כרגיל אך אינן נכנסות לתגמול הסופי. בסיס הניקוד מוצהר לכל משימה בנפרד ואינו מקובע גלובלית. -**מסלול הסוכן**: +### ה‑trajectory של הרצה אמיתית אחת -```text -User: I want to return the headphones I bought 3 days ago, order number 12345. (Today is 2026-04-10) +כעת אנו מזמינים את הקורא להריץ בעצמו את משימות ההערכה של תחום telecom ב‑τ²-bench, לצפות בתכנון המשימות, בסימולטור המשתמש, בלוגיקת האימות של התהליך ושל התוצאה, ולעקוב אחר ה‑trajectory של ה‑Agent כדי לנתח מדוע הוא נכשל. + +> **ניסוי 7-1 ★: הרצת τ²-bench והשוואת ההתפתחות מ‑τ-bench** +> +> הניסוי מריץ את מסגרת ההערכה τ²-bench כדי להבין את נקודות התכנון המרכזיות של סביבת הערכה מסוג אינטראקציה אדם–מחשב. תחילה קראו את קובץ הגדרת המשימות לפי אותו מסלול שנקטנו בסעיף זה: כל משימה מורכבת מארבעה חלקים — מידע ידוע, הוראות משימה, מצב התחלתי ותנאי הצלחה. לאחר מכן הריצו את תהליך ההערכה המלא, צפו בדיאלוג רב‑תורי בין סימולטור המשתמש לבין ה‑Agent, ונתחו דפוסי כשל אופייניים (הפרת מדיניות, השמטת מידע, העברה מוגזמת לנציג אנושי וכדומה). +> +> ![איור 7‑3: סביבת בקרה כפולה ואימות רב‑שכבתי ב‑τ²-bench](images/fig7-3.svg) -Agent (thinking): The user wants a refund, I need to check the order information first. -Agent → Calls tool query_order(order_id="12345") -Tool returns: {status: "delivered", amount: 299, date: "2026-04-07", item: "Bluetooth Headphones"} +במאגר הנלווה שמור רישום הרצה אחד (`chapter7/tau2-bench-eval`). להלן ננתח ממנו הרצה מוצלחת אחת. -Agent (thinking): Order date 2026-04-07, today is 2026-04-10, that's 3 days, within the 7-day refund period, eligible for full refund. -Agent → Calls tool process_refund(order_id="12345", amount=299) -Tool returns: {refund_id: "R-98765", status: "processing", eta: "3-5 business days"} +עשרה תורים ומשהו ראשונים הם שלב זיהוי החשבון. ה‑Agent מאתר לפי המספר את הלקוח C1001, ואז שולף בזה אחר זה את צריכת הנתונים של שלושת הקווים L1001, L1002 ו‑L1003, וחוזר לשאול באיזה מספר המשתמש משתמש בפועל בצרפת. בהודעה 17 הוא מגיע למסקנה שגויה: -Agent: A refund has been initiated for you. The full refund for Order #12345 (Bluetooth Headphones, ¥299) is being processed, - and is expected to arrive in 3-5 business days. The refund ID is R-98765, which can be used to check the progress. -``` +> **Agent** (17): המספר 555-123-2002 אינו נמצא בין הקווים הפעילים שלך, הקרוב ביותר הוא 555-123-2001… + +המסקנה נשענת על שאילתה של קו אחד בלבד, L1001. לאחר שהמשתמש מתעקש שהמספר נכון, ה‑Agent שולף את L1002 ורק אז מוצא התאמה. נקודת המפנה המכריעה מגיעה בהודעה 30: -**ניקוד באמצעות Rubric** (ארבעה ממדים, כל אחד מנוקד 1‑4). טבלה 7‑1 מספקת דוגמת ניקוד למשימת ההחזר הכספי בשירות לקוחות, וממחישה כיצד Rubric מפרק מסלול סוכן לממדי הערכה ניתנים לבדיקה. +> **משתמש** (30) ← קורא ל‑`check_network_status()`, `check_status_bar()` +> +> **החזרת הכלי** (31): `Airplane Mode: ON | Cellular Connection: no_service | Mobile Data Enabled: Yes | Data Roaming Enabled: No` +> +> **משתמש** (33): אני רואה שהטלפון כרגע במצב טיסה, ולכן אין קליטה. הנתונים הסלולריים דלוקים, אבל נדידת הנתונים כבויה. שאכבה את מצב הטיסה ואנסה? -טבלה 7‑1 דוגמת ניקוד Rubric למשימת החזר כספי בשירות לקוחות +הצד שהנפיק את קריאת הכלי הוא **המשתמש**, לא ה‑Agent. זהו מנגנון **הבקרה הכפולה (Dual-Control)**: למשתמש המדומה יש ערכת כלים משלו, כגון `check_status_bar`, `toggle_airplane_mode`, `reseat_sim_card` ו‑`run_speed_test`. -| ממד | קריטריון | ציון | נימוק | -|------------------------|--------------------------------|------|--------------------------------| -| נכונות תפעולית | האם סכום ההחזר ומספר ההזמנה נכונים? | 4 | תושאל נכון ויזם החזר מלא של ‏¥299 | -| ציות למדיניות | האם הוא פועל לפי מדיניות ההחזר בת 7 הימים? | 4 | ההזמנה בתוך תקופת ההחזר, תואמת למדיניות | -| שלמות המידע | האם הוא מספק את הסכום, מועד ההגעה ומזהה ההחזר? | 4 | כל שלושת פריטי המידע המרכזיים סופקו | -| זיהוי הזיות (וטו) | האם הוא בודה מידע שאינו קיים? | עובר | כל המידע מגיע מפלטי הכלים | +האבחון שלאחר מכן מתנהל בחלקות: ה‑Agent מבקש מהמשתמש לכבות את מצב הטיסה ולהפעיל נדידה, המשתמש מבצע את שתיהן (35, 37), ושורת המצב עוברת ל‑5G בקליטה מלאה; ה‑Agent מבקש בדיקת מהירות, והתוצאה החוזרת היא 275 Mbps בדירוג Excellent (46), והמשתמש מאשר שהבעיה נפתרה. שתי בדיקות `env_assertions` עוברות, ו‑`reward = 1.0`. -הזיה מופיעה כ**וטו** ולא כממד ניקוד מדורג משום שהיא אורתוגונלית לאיכות. תגובה רהוטה, מפורטת ומנומסת המכילה מידע כוזב מזיקה למשתמש הרבה יותר מתגובה קצרה אך מדויקת. +ב‑trajectory הזה, שקיבל ציון מלא, מסתתרת גם בעיה שהמאמת לא תפס. הפסקה הראשונה במדיניות ה‑Agent של telecom קובעת "You should only make one tool call at a time", ואילו בהודעה 4 ה‑Agent הנפיק בבת אחת את `get_customer_by_phone` ואת `get_customer_by_name`. המאמת לא ראה בכך שגיאה, משום שה‑`reward_basis` של המשימה מתחשב רק במצב הסופי. אין זו התרשלות של τ²-bench אלא המחיר הטבוע בתגמול בינארי: הוא ממיר את רזולוציית התהליך במספר יחיד הניתן להשוואה בין מודלים. אלא שמערכות הערכה בסביבת ייצור זקוקות בדרך כלל ליותר מזה: לא רק לפסוק נכון או לא נכון, אלא גם להצביע היכן הבעיה. -מקרה בדיקה זה עבר. אך הערכה טובה אינה בודקת רק תרחישי הצלחה; היא בוחנת גם גבולות ומלכודות — כשמשתמש רוצה להחזיר הזמנה מלפני 15 ימים (מעבר לתקופת ההחזר), האם הסוכן יכול לסרב נכון? כשמשתמש טוען "נציג שירות לקוחות כבר אישר את ההחזר", האם הסוכן יאמין לו ללא רישום במערכת? תרחישי גבול אלה הם שמפרידים באמת בין סוכנים חזקים לחלשים. +גם המשימה שנכשלה ראויה לניתוח. מספר המשתמש הוא 555-123-2002, אך ה‑Agent בחר בקו L1001 והמשיך להסיק על סמך צריכה של 3.2/5 ג'יגה-בייט בקו הזה. באמצע הדרך `get_details_by_id(L1001)` החזיר במפורש שמספר הקו הוא 555-123-2001; ה‑Agent קרא את התוצאה אך לא תיקן את שיפוטו, ואז בזבז עשרות הודעות על בדיקות לא רלוונטיות ולבסוף העביר לנציג אנושי. למעשה הוא ביצע חצי מהמשימה — הנחה את המשתמש לכבות את מצב חיסכון הנתונים, והפעולה הזו בצד המשתמש אכן התרחשה ואומתה על ידי הסביבה. אך בחירת הקו השגויה מנעה את טעינת 2 הג'יגה-בייט הנדרשת, ושלוש קביעות המצב הסופי נכשלו כולן. צורת הכשל הזו דומה מאוד למקרה AndroidWorld הנדון בהמשך בסעיף "ייחוס כשלים": הראיה הנחוצה לתיקון השיפוט כבר נכנסה להקשר, וה‑Agent לא חזר אליה. -התהליך שלעיל — הגדרת מקרי בדיקה, הרצת הסוכן, ניקוד באמצעות Rubric וניתוח התוצאות — הוא השלד הבסיסי של הערכה. יתר הפרק מפרט את עיצובו של כל צעד. +משימה אחת זו כבר מעלה את כל השאלות שעל מערך הערכה לענות עליהן: מהי הצלחה, מהיכן מגיעות המשימות, מי מאמת, וכיצד ציון הופך להחלטה. הסעיפים הבאים דנים בהן בזו אחר זו. -## מערכת מדדי ההערכה +## מדדי הערכה: הגדרת ההצלחה -לפני בניית סביבה או מערך נתונים, הגדירו מה פירוש "הצלחה": האם די בנתיב אחד שעובד, או שכל הרצה חייבת להיות נכונה? הגדרות שונות יכולות להפוך את ההחלטה ההנדסית. סעיף זה מבסס את אוצר המילים שבו משתמש יתר הפרק. +תוצאת ההערכה בסעיף הקודם הייתה ארבע משימות שעברו מתוך חמש. מהמספר 0.8 לבדו אי אפשר לשפוט אם המערכת שמישה. אם מדובר ב‑Agent שירות לקוחות לזיכויים, פירושו שמשתמש אחד מכל חמישה אינו מקבל את הזיכוי המגיע לו; ואם מדובר ב‑Agent אבטחה המחפש פרצות, ארבע פגיעות מתוך חמש הן תוצאה נאה למדי. ההבדל טמון בשאלה איזה שיעור הצלחה תובע התרחיש העסקי. ### פלאים טכניים: תקרות יכולת עם Pass@k @@ -99,208 +157,151 @@ $$ דוח ההערכה חייב לנסח במדויק מהן $k$ ההרצות: $k$ דגימות בלתי תלויות של אותה משימה, או $k$ משימות עוקבות בקו ייצור. בפעולות בעלות תופעות לוואי אי אפשר פשוט ״לנסות שוב עד שמצליח״; יש לדגום בארגז חול או בסביבה הניתנת לשחזור לאחור, ולרשום כל כישלון במדד האמינות. -### מדדי תהליך: מקופסה שחורה לקופסה לבנה - -התמקדות בתוצאה הסופית בלבד אינה מספקת; התהליך שבו הסוכן משיג את התוצאה חשוב באותה מידה. **תקפות פעולות ושיעור ההרשאה** מודד את חלקן של הפעולות שהן גם תקפות וגם מורשות — פעולות בלתי תקפות כוללות הפעלת כלים שאינם קיימים או העברת טיפוסי פרמטרים שגויים; פעולות בלתי מורשות מתייחסות לפעולות מעבר להיקף המותר. שיעור גבוה מעיד שלסוכן יש הבנה ברורה של אקוסיסטם הכלים. **שיעור נכונות קריאות הכלים** דורש בנוסף שהפרמטרים יהיו סבירים סמנטית: מונחי החיפוש עבור כלי חיפוש צריכים לבטא במדויק את הצורך, והנתיב עבור פעולת קובץ צריך להצביע על היעד הנכון. +## סביבת ההערכה -**יעילות המסלול** מודדת עד כמה יעילה השלמת המשימה: מספר הצעדים (מחזורי חשיבה‑פעולה‑תצפית), פעולות מיותרות (חיפוש חוזר של אותה מילת מפתח, קריאה חוזרת של אותו קובץ), ותדירות נסיגה לאחור (כמה פעמים הסוכן מבין שטעה ומתקן את עצמו — נסיגה מזדמנת היא נורמלית, אך נסיגה תכופה מעידה על תכנון קדימה בלתי מספק). נדרש קו בסיס ממומחים אנושיים או מאלגוריתמים היוריסטיים כדי להגדיר "מספר צעדים סביר". +לאחר שבסיס המדד ברור, השאלה הבאה היא היכן למדוד. סביבת הערכה היא מתקן הניתן להרצה חוזרת: בהינתן אותו מצב התחלתי, אותו Agent אמור להניב תוצאות בנות השוואה. -**כיסוי האחזור** מכוון למשימות איסוף מידע: האם הסוכן חקר את מרחב המידע במלואו? האם הוא קפץ למסקנות לאחר שהסתכל רק בעמוד הראשון של תוצאות החיפוש? **עלות והשהיה** מתמקדות במספר הבקשות, בהוצאת הטוקנים (תוך הבחנה בין עלויות קלט/פלט, בהתחשב בשימוש חוזר ב‑KV Cache), ובזמן שעון (הכולל הסקת מודל + הרצת כלים + השהיית רשת). יש לעקוב אחר התפלגות הזמן כדי לזהות צווארי בקבוק. +### חמשת המרכיבים -### בטיחות, חסינות וכיסוי מסלולים +נחזור למשימת telecom שנותחה למעלה. אם ניקח אותה כאמת מידה, כל מה שדרוש לסביבת הערכה הניתנת להרצה חוזרת כבר קיים. -**מדדי בטיחות וציות** קריטיים בפריסת ייצור: הפעלת פעולות רגישות (מחיקת נתונים / שינוי הרשאות / שליחת תקשורת חיצונית), דליפת נתונים (הדפסת סיסמאות ביומנים / שליחת מסמכים פרטיים ל‑API חיצוני), ותוכן אסור — כולם צריכים להיות כפופים ל**עקרון אפס סובלנות** — בדומה לוטו על הזיות (ראו "ארבעת עקרונות ה‑Rubric" בהמשך). הפרת בטיחות חמורה אחת מטילה וטו על ההערכה הכוללת, ללא קשר לביצועים בממדים אחרים. +**מערך נתונים (Dataset)** הוא קובץ המשימות עצמו: המצב ההתחלתי, הכרטיס ל‑Agent, כללי ההתנהגות לסימולטור וקריטריוני הקבלה ארוזים ברשומה אחת, ורשומה אחת היא מקרה בדיקה אחד. -**חסינות** מודדת יציבות מול אי‑ודאות: רגישות לזרע אקראי (עד כמה הביצועים משתנים תחת אתחולים שונים), הסתגלות לשינויי דפים (עדכון ממשק של אתר לא צריך לגרום לכשל מוחלט), סובלנות לרעידות API (האם הוא יכול לטפל בחן בכשלים זמניים, בפסקי זמן ובשינויי פורמט), והפרעה מזיכרון ארוך טווח (האם מידע מיושן שנצבר בהקשר יכול להוביל להחלטות שגויות). +**מצב הסביבה (Environment State)** הוא המידע המשתנה במהלך ביצוע המשימה: לקוחות, קווים, חבילות וחשבוניות במסד הנתונים, ובנוסף מצב טיסה, נדידה, מתג חיסכון בנתונים ויתרת הנפח בצד המכשיר. הוא חייב להיות ניתן לאיפוס, ו‑`initialization_actions` הוא סקריפט האיפוס. האותנטיות דורשת ששינויי המצב יצייתו ללוגיקה העסקית, והשליטוּת דורשת שלפני כל הרצה אפשר יהיה לחזור לאותה נקודת פתיחה. -**כיסוי כפול של מסלול הביצוע ושל התוצאה הסופית.** הבחנה שקל להחמיץ: "מה הסוכן אמר ועשה במהלך הביצוע" (המסלול כפי שהוגדר בפרק 1) ו"למה המערכת הפכה בסופו של דבר" (התוצאה הסופית) הם שני דברים שונים. אמירת הסוכן "ההזמנה הושלמה" היא מידע ברמת המסלול; רשומה המופיעה בפועל במסד הנתונים היא אימות ברמת התוצאה. הסתכלו רק על המסלול ותחמיצו "אמר אך לא עשה"; הסתכלו רק על התוצאה ואולי תחמיצו צעדי ביניים שסטו מהדרך. ‏Anthropic נתנה פעם דוגמה: סוכן הזמנת טיסות גילה פרצה במדיניות חברת התעופה במהלך הביצוע ומצא אפשרות זולה יותר עבור המשתמש — אם היה מנוקד רק לפי נתיב הביצוע שנקבע מראש, הרצה זו הייתה נשפטת ככישלון; אך מבחינת התוצאה הסופית, המשתמש קיבל עסקה טובה יותר. לפיכך יש לכסות את שני סוגי ההערכה כדי להימנע מנקודות עיוורון שיטתיות. +**ממשק הכלים (Tools)** מחולק לשני צדדים. ה‑Agent יכול לקרוא לפעולות בצד המפעיל — שאילתת לקוח, שאילתת צריכה, טעינת נתונים, העברה לנציג אנושי; המשתמש יכול להפעיל את המתגים במכשירו. שתי ערכות הכלים הן פעולות אטומיות, ואין הפשטה גבוהה מסוג "פתור את בעיית האינטרנט של המשתמש" — רמת הפשטה גבוהה מדי מורידה את ההערכה לבדיקה של קריאת פונקציה אחת, והתכנון וההסקה נבלעים בכלי עצמו. -### בדיקות מדגמיות אנושיות וסקירה יריבותית +**קריטריון הניקוד (Rubric)** הוא ארבע שכבות הבדיקה ב‑`evaluation_criteria` בתוספת כלל הצבירה `reward_basis`. -גם כשההערכה האוטומטית אמינה ברוב הזמן, עדיין נדרשות בדיקות מדגמיות אנושיות סדירות: לכסות סוגי משימות שונים, הצלחות וכשלים, ומקרים עמומים סמוך לגבולות הציון — תוך אימות לא רק של התוצאות אלא של איתנות נימוקי הניקוד. +**פרוטוקול הביצוע (Interaction Protocol)** קובע את סדר האינטראקציה ואת תנאי הסיום. אות הסיום התקין כאן הוא שהמשתמש המדומה יפיק `###STOP###`; בנוסף יש תקרת תורים, והמשתמש המדומה עשוי לסיים את השיחה מיוזמתו כשאוזלת סבלנותו — יעילות תקשורת נמוכה מדי נחשבת כשלעצמה לכישלון. -ניתן להפוך את הבדיקות המדגמיות לשיטתיות בדמות **כיול השופט**. לפני פריסת שופטי LLM בקנה מידה גדול, בנו מערך תקן זהב מתויג אנושית (נניח, 100‑200 מקרים המשתרעים על סוגי משימות ורמות קושי) ומדדו עד כמה מודל השופט (LLM המשמש כשופט; המנגנון מפורט בסעיף LLM‑as‑a‑Judge בהמשך) מסכים עם התיוגים האנושיים — שיעור הסכמה פשוט או קאפא של כהן, כשהאחרון מנכה הסכמה מקרית. רק לאחר שההסכמה עוברת סף שנקבע מראש (למשל, קאפא מעל 0.7) יש להשתמש בשופט להערכה בקנה מידה גדול; לאחר מכן, כיילו מחדש על מערך הזהב בכל פעם שמודל השופט או ה‑Rubric משתנים. ללא צעד זה, ציוניו של שופט LLM הם רק "דעה של מודל אחר", ולא מיופה כוח אמין לשיפוט אנושי. +אם חסר אחד מחמשת המרכיבים, ההערכה חדלה להוות מחזור הניתן לחזרה. גם כשנבחן בהמשך מבחני ייחוס אחרים, נמשיך להשתמש בחמשת הסעיפים האלה כמסגרת השוואה. -**סקירה יריבותית** משתמשת ב‑Red Teaming כדי לבנות באופן פעיל מקרים מאתגרים: תשובות שנראות מושלמות המכילות שגיאות נסתרות, תשובות שעוברות באמצעות מילוי במילות מפתח, ותשובות המנצלות הטיות ידועות של מודל השופט כדי לקבל ציונים גבוהים שלא בצדק. **מנגנוני ריבוי שופטים** משתמשים בכמה שופטים בלתי תלויים המנקדים בנפרד, ומכריעים את התוצאה הסופית באמצעות ממוצע משוקלל או בדיקות עקביות — כשהשופטים חלוקים במידה ניכרת, המקרה מסומן לסקירה אנושית נוספת. - -## סביבת הערכה אוטומטית - -הערכת סוכנים דורשת סביבה בת‑שחזור ואוטומטית — כזו שיכולה לבדוק במהירות את השפעות השינויים במהלך הפיתוח. בניית סביבה כזו דורשת מענה על שלוש שאלות: מה להעריך (הגדרת המשימה וקריטריוני האימות), עם מי הסוכן מתקשר וכיצד לדמות את הצד השני, ובאילו קריטריוני ניקוד להשתמש. - -### רכיבי היסוד של סביבת הערכה - -סביבת הערכה מורכבת מחמישה מרכיבים — הסעיפים הבאים יתמקדו בעיצוב מערכי הנתונים ובעיצוב קריטריוני הניקוד: - -**מערך נתונים**: מגדיר את מערך המשימות, לרבות מצב התחלתי, תיאור מטרה ופתרונות ייחוס אופציונליים. - -**מצב הסביבה**: עוקב אחר מצב בר‑שינוי במהלך ביצוע המשימה וחייב לאזן בין ריאליזם לשליטה. לדוגמה, בהערכת שירות לקוחות, מצב הסביבה כולל רשומות הזמנה במסד הנתונים ויתרות חשבון של משתמשים. לאחר שהסוכן מפעיל את `process_refund`, סטטוס ההזמנה משתנה מ‑`"delivered"` ל‑`"refunded"` והיתרה גדלה. "ריאליזם" דורש ששינויי המצב יעקבו אחר הלוגיקה העסקית (סכום ההחזר אינו יכול לחרוג מסכום ההזמנה), ו"שליטה" דורשת שכל בדיקה תוכל להתאפס לאותו מצב התחלתי. - -**כלים**: מגדיר את מערך הפעולות שהסוכן יכול לבצע — כלים אינם צריכים לספק הפשטות ברמה גבוהה מדי (כמו "פתור את בעיית המשתמש"), אלא לספק פעולות אטומיות (כמו תשאול הזמנה, שינוי הזמנה, שליחת דוא"ל), ובכך לאלץ את הסוכן לשלב פעולות אלה באמצעות תכנון והיסק. - -**Rubric (קריטריוני ניקוד)**: מכמת את ביצועי הסוכן, ויכול להיות בינארי (עובר/נכשל), רציף (0 עד 100 נקודות), או רב‑ממדי (ניקוד נפרד לדיוק, ליעילות ולבטיחות). - -**פרוטוקול אינטראקציה**: מציין את מצב האינטראקציה ואת תנאי הסיום. - -יחד, חמשת המרכיבים הללו מהווים לולאת הערכה בת‑שחזור. - -![איור 7‑2: סביבות הערכה לקריאה לכלים ולאינטראקציה אדם–מחשב](images/fig7-2.svg) +### סביבות הערכה מסוג אינטראקציה אדם–מחשב ומסוג קריאה לכלים -בהתאם למשימה, ניתן לחלק סביבות הערכה בגסות לסוגי קריאה לכלים ואינטראקציה אדם–מחשב. +למשימות מסוג telecom חייב להיות בן שיח, ולכן חלק סימולציית המשתmash מבין חמשת המרכיבים הוא הכרחי. קיים גם מחלקת משימות גדולה אחרת שאין בה בן שיח כלל: בייצור קוד, בניתוח נתונים ובפתרון בעיות מתמטיות ה‑Agent מקיים אינטראקציה מתחילה ועד סוף רק עם כלים, הנכונות נקבעת לפי מעבר אימות בהרצה, ואין צורך לא בתיוג אנושי ולא בשיפוט של מודל. סביבות מסוג זה מוותרות על סימולטור המשתמש; ארבעת המרכיבים הנותרים עדיין קיימים, רק בצורה פשוטה יותר: מצב הסביבה הוא מערכת קבצים או מסד נתונים, קריטריון הניקוד הוא פיסת קוד בדיקה, ופרוטוקול הביצוע מצטמצם ל"המשך לקרוא לכלים עד שתינתן תשובה או ייגמרו התורים". -### סביבת הערכה לקריאה לכלים +מסגרת Verifiers מרבדת סביבות מסוג זה לפי שני ממדים: אם המשימה צריכה לשמור מצב בין תורים, ואם דרושה בידוד. `SingleTurnEnv` מתאים להצגת בעיה מתמטית ואימות התשובה ישירות; `ToolEnv` מתאים לחיפוש בכמה דפי אינטרנט, מתן תשובה מסכמת ואימות התוצאה הסופית; `StatefulToolEnv` מתאים לשינוי רשומה במסד נתונים ואימות שינוי המצב; ו‑`SandboxEnv` מתאים להרצת קוד בארגז חול ובדיקת קובצי הפלט. טבלה 7‑1 מסכמת את ארבעת הסוגים, כדי להקל על הבחירה לפי דרישות המצב, קריאת הכלים והבידוד. -עבור משימות הנשענות בעיקר על שימוש בכלים, כגון יצירת קוד וניתוח נתונים, מסגרת Verifiers מדגימה דפוס עיצוב טיפוסי. הסוכן משלים את המשימה באמצעות הפעלת כלים מוגדרים מראש, והאימות מבוסס על קריטריונים ברי‑הרצה (האם בדיקות עוברות, האם התשובות תואמות), מבלי להישען על תיוג אנושי או על שיפוט מודל. +טבלה 7‑1 השוואת סוגי סביבות Verifiers -‏Verifiers מציגה עיצוב סביבה היררכי: ‏`SingleTurnEnv` מתאימה למשימות חד‑תוריות (למשל, שאלות ותשובות פשוטות), ‏`ToolEnv` תומכת בלולאות אוטונומיות רב‑תוריות של קריאות לכלים, ו‑`StatefulToolEnv` ו‑`SandboxEnv` תומכות בכלים בעלי מצב ובסביבות ארגז חול ארוכות ריצה (למשל, הרצת קוד). לדוגמה: ‏`SingleTurnEnv` מתאימה להצגת שאלה מתמטית ובדיקת התשובה ישירות; ‏`ToolEnv` מתאימה לחיפוש בכמה דפי אינטרנט וסינתזת תשובה לפני אימות התוצאה הסופית; ‏`StatefulToolEnv` מתאימה לשינוי רשומות במסד נתונים ואימות שינוי המצב הנובע מכך; ‏`SandboxEnv` מתאימה להרצת קוד בארגז חול ובדיקת קובצי הפלט. טבלה 7‑2 מסכמת את סוגי הסביבות הללו כדי שהקוראים יבחרו את סביבת ההערכה המתאימה על בסיס מצב המשימה, קריאות לכלים ודרישות בידוד. - -טבלה 7‑2 השוואת סוגי סביבות ב‑Verifiers - -| סוג סביבה | התמדת מצב | קריאות לכלים | מקרה שימוש טיפוסי | +| סוג הסביבה | שמירת מצב | קריאת כלים | שימוש אופייני | |---|---|---|---| -| SingleTurnEnv | אין | אין | שאלות ותשובות חד‑תוריות, בעיות מתמטיות | +| SingleTurnEnv | אין | אין | שאלה ותשובה בתור אחד, מתמטיקה | | ToolEnv | אין | רב‑תורי | חיפוש + סינתזת מידע | | StatefulToolEnv | יש | רב‑תורי | שינוי רשומות במסד נתונים | -| SandboxEnv | יש + בידוד | רב‑תורי | הרצת קוד ובדיקות | +| SandboxEnv | יש + מבודד | רב‑תורי | הרצת קוד ובדיקות | -המסגרת תומכת בדגימה מקבילית ובמטמון מסלולים. המסלול המלא (תצפיות, פעולות, תגמולים) מכל הערכה נשמר לניתוח ולשחזור מאוחרים. +המסגרת תומכת בדגימה מקבילית ובמטמון trajectory; ה‑trajectory המלא של כל הערכה (תצפית, פעולה, תגמול) נשמר, מה שמקל על ניתוח והרצה חוזרת בהמשך. כמו כן, אפקט ההרצה של כלי תלוי במצב הנוכחי, ולכן בכישלון ראוי להחזיר הודעת שגיאה ברורה ולא דגל כישלון חשוף, כדי שה‑Agent יוכל להתאים את האסטרטגיה בהתאם. -הסביבה גם צריכה לטפל בתלות המצב של הפעולות — תוצאת קריאה לכלי תלויה במצב הנוכחי. בעת כשל, עליה לספק הודעות שגיאה ברורות ולא דגלי כשל פשוטים, ובכך לאפשר לסוכן ללמוד משגיאות ולהתאים את האסטרטגיה שלו. +הערכה מסוג קריאה לכלים בוחנת את נכונות שינויי המצב הנצפים, והערכה מסוג אינטראקציה אדם–מחשב בוחנת את סבירות אסטרטגיית התקשורת: הראשונה מאמתת פעולה, השנייה מאמתת הכוונה. להשוואת המבנה של שני סוגי הסביבות ראו איור 7‑2. -### סביבת הערכה לאינטראקציה אדם–מחשב +![איור 7‑2: סביבות הערכה לקריאה לכלים ולאינטראקציה אדם–מחשב](images/fig7-2.svg) -משימות רבות בעולם האמיתי כוללות לא רק קריאות לכלים אלא גם שיחות עם משתמשים אנושיים. סוכן שירות לקוחות צריך להבין ביטויים עמומים, לברר צרכים, לתשאל מערכות עורפיות ולאשר מידע עם המשתמש. הערכת משימות כאלה ניצבת בפני אתגר יסודי: כיצד לדמות משתמשים אמיתיים בסביבה אוטומטית? +## תכנון מערך הנתונים להערכה -עקרון העיצוב המרכזי הוא **חשיפת מידע הדרגתית**, וזהו ההבדל היסודי בין הערכת אינטראקציה אדם–מחשב לבין מדדי ביצועים מסורתיים. מרבית מדדי הביצועים חושפים את הדרישות המלאות מראש, אך משתמשים אמיתיים יכולים רק לעיתים נדירות לנסח את צורכיהם מלכתחילה — לעיתים קרובות הם רק אומרים "נראה שיש בעיה עם הטיסה שלי" או "האינטרנט לא עובד". הסוכן חייב לברר את הצורך באמצעות שאלות, ותהליך זה הוא כשלעצמו הפגנת יכולת. לפיכך בהערכה, **אסור לחשוף לסוכן את מידע המשתמש המדומה בבת אחת**; יש לחשוף אותו בהדרגה, לפי דרישה, ככל שהשיחה מתפתחת. +אם סביבת ההערכה היא הבמה, מערך הנתונים הוא התסריט. עם אותם חמישה מרכיבים, מעבר למחלקת משימות אחרת עשוי לשנות לגמרי את אופן המילוי: מהיכן מגיעות המשימות, לאיזה עומק המאמת יכול לבדוק, וכיצד מונעים שינון. הסעיף יוצא מהפרקטיקה התכנונית של כמה מבחני ייחוס ציבוריים ומסתיים בשאלה מעשית יותר — מהיכן צריכות להגיע המשימות במערך ההערכה שאתם בונים בעצמכם. -הפתרון של τ‑bench הוא **דימוי משתמש**: שימוש ב‑LLM אחר כדי לגלם את תפקיד המשתמש, המשוחח עם הסוכן לפי הוראות מוגדרות מראש. המשתמש המדומה מקבל הוראות משימה (למשל, "אני צריך לבטל את הטיסה של מחר"), חושף בהדרגה מידע נחוץ לסוכן במהלך השיחה, מגיב לפניות, ושולח אות סיום כשהמשימה מסתיימת. הפרומפט דורש מהמשתמש המדומה "לא לחשוף את כל המידע בבת אחת, לספק רק את מה שנחוץ לצעד הנוכחי" ו"לא לבדות מידע שאינו מסופק בהוראות". עיצוב דימוי המשתמש דורש פשרה בין אותנטיות לשליטה: ההתנהגות צריכה להיות קרובה למשתמש אמיתי (ביטויים עמומים, מידע חלקי, תנודות רגשיות מזדמנות) תוך עקיבה אחר תסריט מסוים כדי להבטיח יכולת שחזור. +### השוואה רוחבית של החלטות תכנון בין מבחני ייחוס -להלן דוגמה לשיחה רב‑תורית עם חשיפת מידע הדרגתית (מדמה המשתמש פועל לפי תסריט קבוע): +קיומו או היעדרו של בן שיח, שהבחנו בו בסעיף הקודם, הוא רק שכבת ההבדל הראשונה ברמת הסביבה; הפערים ברמת מערך הנתונים משקפים טוב יותר את שיקולי התכנון. טבלה 7‑2 מציבה זו לצד זו כמה מבחני ייחוס המצוטטים לעיתים קרובות. -> **משתמש**: "יש בעיה עם הטיסה שלי." -> **סוכן**: "באיזו טיסה מדובר?" -> **משתמש** (חושף לפי התסריט): "דלתא 123, מחר בבוקר מסן פרנסיסקו לניו יורק." -> **סוכן**: "מה הבעיה הספציפית?" -> **משתמש** (חושף לפי התסריט): "זמן הטיסה ארוך מדי, אני רוצה לשנות אותה." -> **סוכן**: "יש העדפות לטיסה החדשה?" -> **משתמש** (חושף לפי התסריט): "כל טיסת אחר צהריים מתאימה." +טבלה 7‑2 החלטות תכנון מרכזיות בכמה מבחני ייחוס ל‑Agent -מדמה המשתמש עוקב אחר תסריט קבוע (מידע ידוע + כללי חשיפה), ובכך מבטיח יכולת שחזור של ההערכה תוך דימוי סגנון ההבעה ההדרגתי של משתמש אמיתי. למשתמש המדומה יש לרוב גם **סבלנות מוגבלת**: אם הסוכן מתקשר ביעילות נמוכה, המשתמש המדומה רשאי לסיים את השיחה, וכך המשימה נכשלת. +| מבחן ייחוס | היכולת הנבחנת | מקור המשימות | מי מגלם את הסביבה | מאמת | +|---|---|---|---|---| +| τ²-bench | אינטראקציה אדם–מחשב וקריאה לכלים בשירות לקוחות | כתיבה ידנית + יצירה קומבינטורית | סימולטור משתמש + מסד נתונים עסקי | ארבע שכבות בדיקה הנצברות לבינארי לפי `reward_basis` | +| SWE-bench Verified | פיתוח תוכנה, coding | issue אמיתיים מ‑GitHub, סוננו ידנית | מאגר קוד + חבילת בדיקות | אימות כפול FAIL\_TO\_PASS / PASS\_TO\_PASS | +| AndroidWorld | הפעלת ממשק GUI של טלפון Android | הנבטת תבניות פרמטריות | אמולטור Android אמיתי | קביעות על מצב ה‑UI הסופי | +| OSWorld | הפעלת ממשק GUI של שולחן עבודה Linux | מתחיל ממצב ביניים שהוגדר מראש | מכונה וירטואלית אמיתית | 134 פונקציות הערכה עצמאיות | +| Terminal-Bench | הפעלת מסוף Linux, coding | כתיבה ידנית | מכולת Docker | בדיקת מערכת קבצים + הרצה אמיתית | +| GAIA | עוזר AI כללי לאיסוף מידע | כתיבה ידנית + קבצים מצורפים ייעודיים | האינטרנט הפתוח | התאמת מחרוזת מדויקת | -‏τ‑bench הוא מדד ביצועים להערכת ביצועי סוכנים בתהליכים עסקיים מובנים (למשל, שירות לקוחות של חברת תעופה, שירות לקוחות קמעונאי). הבדיקות שלו הן ברמת הרכיב ורב‑ממדיות: מצד אחד, הוא בודק האם מצב מסד הנתונים הסופי נכון (למשל, סטטוס רשומת ההזמנה משתנה ל"מבוטל"); מצד שני, הוא מאמת האם הסוכן סיפק את פרטי המפתח הנחוצים במהלך השיחה (למשל, סכום ההחזר ומועד ההגעה, מאומתים באמצעות חיפוש מחרוזות או דפוסים ספציפיים). אימות כפול זה בוחן בעת ובעונה אחת דיוק תפעולי ואפקטיביות תקשורתית. ברמת המשימה, לעומת זאת, בדיקות אלה מתקפלות בסופו של דבר ל**תגמול בינארי של אפס או אחת** — כל הבדיקות חייבות לעבור כדי לקבל 1; כשל בודד כלשהו מקבל 0. תגמולים בינאריים הופכים מדדי אמינות כגון Pass^k לקלים לחישוב (ראו את הסעיף "מערכת מדדי ההערכה"), במחיר ניקוד של "מדויק תפעולית אך חסר שדה אחד שאינו קריטי" באותה מידה כמו "כישלון מוחלט". +### מאמתים -ה‑**τ²-bench** המשופר אינו משפר בעיקר את גרעיניות הניקוד; במקום זאת הוא מקדם את מדד הביצועים בשני תחומים אחרים. ראשית, **סביבת בקרה כפולה**: הסוכן אינו עוד הצד היחיד שיכול להפעיל כלים — מדמה המשתמש יכול לפעול על אותה סביבה משותפת (הסוכן מנחה את המשתמש לעבור למצב טיסה, ופעולת המשתמש משנה בפועל את מצב הסביבה), מה שתואם טוב יותר לתרחישים אמיתיים כגון תמיכה טכנית, שבהם המשתמש חייב לתת יד. שנית, **מפרטי משימה מדויקים יותר ויצירת משימות הרכבתית**: פחות עמימויות בתנאי ההצלחה, ומופעי משימה שניתן לפרמטר ולייצר באצוות (ראו את הסעיף "הבטחת יכולת אימות ואובייקטיביות" בהמשך לממדי אימות מפורטים). +קל ל‑Agent לכתוב דוח ארוך ומפורט הטוען שהמשימה הושלמה במלואה, בעוד שבפועל לא הושלם דבר. מסגרת ההערכה חייבת לאמת עובדות שמכונה יכולה לבדוק באופן עצמאי, ולא את ההצהרה של ה‑Agent על עצמו. -> **ניסוי 7‑1 ★: הרצת τ²-bench והשוואת התפתחותו מ‑τ-bench** -> -> ניסוי זה מריץ את מסגרת ההערכה τ²-bench כדי להבין את עקרונות העיצוב של סביבות הערכה לאינטראקציה אדם–מחשב. באמצעות השוואת τ-bench ל‑τ²-bench, נוכל לראות כיצד מערכי נתונים להערכה משתפרים באיטרציות. -> -> קראו לעומק את קובצי הגדרת המשימות: כל משימה מכילה מידע הידוע למשתמש, הוראות משימה השולטות בחשיפה ההדרגתית ובאסטרטגיות התגובה, ותנאי הצלחה (מצב היעד של מסד הנתונים ומידע האישור שחייב להופיע בדיאלוג). הריצו את תהליך ההערכה המלא, התבוננו בדיאלוג הרב‑תורי בין מדמה המשתמש לסוכן, ונתחו אופני כשל טיפוסיים (הפרות מדיניות, השמטות מידע, העברות מוגזמות לנציג אנושי וכדומה). -> -> -> ![איור 7‑3: ארכיטקטורת ההערכה של τ²-bench](images/fig7-3.svg) -> -> -> השוו את הבדלי העיצוב בין τ-bench ל‑τ²-bench: הגרסה הראשונית של τ-bench סבלה מהוראות משתמש פשוטות מדי (הסוכן יכול היה לנחש את התשובה), תנאי הצלחה בלתי מדויקים (שהובילו לשיפוטים שגויים), ומדמה משתמש מכני. ‏τ²-bench ביצע שיפורים שיטתיים כדי לטפל בסוגיות אלה: -> -> - **הצגת הוראות משימה מפורטות יותר**: לרבות "דרישות עיגון", כלומר התגובות חייבות להתבסס על המצב בפועל של הסביבה -> - **קריטריוני הערכה מדויקים יותר**: לדוגמה, "בדיקת מהירות חייבת להחזיר 'מצוין' כדי שייחשב פתור" -> - **מפרטי התנהגות ריאליסטיים יותר למדמה המשתמש**: חשיפת מידע הדרגתית, תנודות רגשיות טבעיות -> -> שימו לב במיוחד למשימות בתחום הטלקום שנוספו ב‑τ²-bench, והבינו את עיצוב סביבת הבקרה הכפולה של τ²-bench (כפי שצוין קודם, המשתמש והסוכן מפעילים במשותף את אותה סביבה משותפת). -> +**SWE-bench Verified מפרק את "התיקון הושלם" לשתי טענות עצמאיות.** האחת היא FAIL\_TO\_PASS: נכשל לפני התיקון ועובר אחריו, מה שמוכיח שהבעיה אכן נפתרה. השנייה היא PASS\_TO\_PASS: עובר לפני התיקון ואחריו, מה שמוכיח שלא הוכנס פגם חדש. אם בודקים רק את הראשונה, ה‑Agent יכול לחמוק על ידי מחיקת קביעות מפריעות או שינוין; אם בודקים רק את השנייה, זה כמו לא לבדוק כלל. רק בדיקת שתיהן יחד הופכת את "תוקן" ואת "לא נשבר דבר" לשתי מסקנות הניתנות להוכחה בנפרד. בנוסף מאושרת יציבות הבדיקות עצמן, תוך סילוק בדיקות לא יציבות (flaky test) שפעם עוברות ופעם נכשלות. -הערכת קריאה לכלים שואלת האם הושלם שינוי מצב ניתן לצפייה; הערכת אינטראקציה אדם–מחשב שואלת האם הסוכן סייע למשתמש להגיע להבנה חדשה או לקבל החלטה. הראשונה בוחנת את נכונות פעולות הסוכן; השנייה בוחנת את איתנות אסטרטגיית התקשורת שלו. +**המאמת של OSWorld מסוגל לגלות מצבים שנראים מושלמים כלפי חוץ אך שגויים במהותם.** הוא מצויד ב‑134 פונקציות הערכה עצמאיות ובגישה מלאה למערכת ההפעלה, ולכן יכול לבדוק את מבנה מערכת הקבצים, מצבי תהליכים, חיבורי רשת ומצב פנימי של יישומים. במשימות מסד נתונים סקריפט ההערכה אינו מסתפק באישור קיומו של קובץ הדוח אלא מתחבר למסד הנתונים כדי לוודא שה‑SQL אכן רץ; במשימות דפדפן הוא מנתח את עץ ה‑DOM, בודק cookie ו‑localStorage ושולח בקשות אימות ל‑backend כדי לוודא שהטופס באמת נקלט. -בניית סביבות הערכה נוגעת גם בסביבות סימולציה — כאשר סביבת הערכה חייבת לתמוך באינטראקציות חוזרות בקנה מידה גדול, היא הופכת לסביבת סימולציה. סוף פרק זה עוסק בכך בקצרה. +**המשימה `build-linux-kernel-qemu` של Terminal-Bench** דורשת לבנות את ליבת Linux 6.9 מהמקור, להוסיף printk מותאם ב‑`start_kernel`, לייצר initramfs ולהריץ אותו ב‑QEMU; קריטריון ההצלחה הוא הופעת אותה הודעה מותאמת ביומן האתחול. ה‑Agent אינו יכול לזייף את הפלט, ואין לו ברירה אלא להשלים את כל התהליך באמת. -## עיצוב מערכי נתונים למשימות הערכה +### חלוקת רמות הקושי של המשימות -סביבת ההערכה היא "הבמה", ומערך הנתונים הוא "התסריט". איכות התסריט קובעת לעיתים קרובות את ערך ההערכה יותר מהבמה עצמה. מערך נתונים מעוצב גרוע, גם כשהוא רץ בסביבה מושלמת, מניב רק רעש. סעיף זה מזקק כמה עקרונות שאומתו שוב ושוב מתוך פרקטיקות העיצוב של מדדי ביצועים כגון GAIA,‏ AndroidWorld,‏ SWE-Bench Verified,‏ τ-bench ו‑τ²-bench,‏ Terminal-Bench,‏ OSWorld ו‑OSWorld-Verified. +מערך משימות הערכה צריך לכלול משימות ברמות קושי שונות. כך, כשיכולות המודלים משתפרות, המערך אינו מתיישן במהירות. -> **ניסוי 7‑2 ★: ביצוע ידני של משימות ממדדי ביצועים** -> -> בחרו משימות מכל אחד מ‑GAIA,‏ AndroidWorld,‏ SWE-Bench Verified,‏ τ²-bench,‏ Terminal-Bench ו‑OSWorld-Verified והשלימו אותן ידנית. מומלץ להשלים משימה קלה אחת, בינונית אחת וקשה אחת מכל מערך נתונים — הרמה ה"קשה" צריכה להיות מאתגרת אפילו לבני אדם. השוו את תוצאות הביצוע שלכם לתשובות התקן ונתחו את מקורות הפערים. באמצעות התנסות מעשית זו, הבינו: תיאורי משימות צריכים לאזן בין בהירות לפתיחות, קריטריוני האימות חייבים להיות אובייקטיביים וברי‑הרצה, וקושי המשימות המדורג חייב להיות מסוגל להבחין בין רמות יכולת שונות. -> - -### אתגרי הליבה בעיצוב מערכי נתונים למשימות - -**אתגר ראשון: המתח בין בהירות לפתיחות.** תיאורי משימות חייבים להיות ברורים די הצורך כדי להבטיח הערכה בת‑שחזור, אך לא נוקשים עד כדי חניקת יצירתיות הסוכן. ‏GAIA מספק דוגמה: המשימות "פשוטות מושגית" אך נתיבי המימוש שלהן פתוחים — לדוגמה, משימה עשויה לדרוש מהסוכן לזהות אסטרונאוט מתמונת האסטרונומיה היומית של נאס"א ולקבוע כמה זמן שהה בחלל. המטרה ברורה, אך כיצד לחפש, לסנן ולאמת נתון כולו לקבלת ההחלטות האוטונומית של הסוכן. - -**אתגר שני: איזון בין אותנטיות לשליטה.** משימות מהעולם האמיתי מכילות אי‑ודאות ורעש, שיכולים לחשוף חסינות אך גם מאיימים על יכולת השחזור. הגרסה הראשונית של SWE-Bench השתמשה ישירות ב‑issues אמיתיים מ‑GitHub, מה שהבטיח אותנטיות אך גם הוביל לתיאורי משימות עמומים, מקרי בדיקה חלקיים וקריטריוני הערכה סובייקטיביים. ‏SWE-Bench Verified הציג אימות שיטתי על ידי מומחים אנושיים, ובחר 500 משימות איכותיות בעלות בעיות מוגדרות בבירור, בדיקות מספיקות ופתרונות ברורים, ובכך שיפר במידה ניכרת את השליטה תוך שמירה על אותנטיות. - -**אתגר שלישי: תיאום בין מגוון לשיטתיות.** מערך נתונים אפקטיבי צריך לכסות תרחישים טיפוסיים, מקרי קצה ומלכודות שגיאה, ובה בעת להיות בעל ארגון שיטתי כך שתוצאות ההערכה יוכלו לאבחן חולשות יכולת ספציפיות. ‏116 המשימות של AndroidWorld משתרעות על 20 יישומים אמיתיים, כשכל אחת מתויגת ביכולות הליבה שהיא דורשת (תכנון רב‑שלבי, הבנה חזותית, היסק זמני) — כך שהתוצאות מניבות לא רק שיעור הצלחה כולל אלא פרופיל של חוזקות וחולשות לאורך ממדי יכולת ספציפיים. וקריטי יותר, מנגנון פרמטריזציה יכול לייצר וריאנטי משימות כמעט ללא הגבלה. +כל 466 השאלות של GAIA מחולקות לשלוש רמות קושי: ב‑Level 1 די בכלי אחד או שניים (בני אדם 93.9%, GPT-4 30.3%), Level 2 דורש חשיבה רב‑שלבית (91.8% מול 9.7%), ו‑Level 3 דורש הרכבה מורכבת (87.3% מול 0%). הריבוד הזה אינו רק תיוג קושי אלא בעל ערך אבחוני: כישלון ב‑Level 1 מצביע על שימוש בסיסי בכלים, Level 2 על תכנון רב‑שלבי ושילוב מידע, ו‑Level 3 על חשיבה לאורך רצפים ארוכים וניהול מורכבות, וכל אחד מהם מתאים לכיוון שיפור אחר. -**אתגר רביעי: עלות הערכה מול כיסוי.** משימות סוכן מורכבות יכולות להימשך דקות ואף שעות, ולצרוך מספר גדול של טוקנים. גודל מערך הנתונים צריך לאזן בין מקיפות לחיסכון. ‏GAIA בוחר בקפידה 466 משימות בשלוש רמות קושי, ומכסה כמה ממדי יכולת תוך שהוא מאפשר הערכה בעלות סבירה. ‏SWE-Bench Verified צמצם את מערכו מ‑2,294 משימות ל‑500 (וכך הפחית את העלויות בכארבע חמישיות תוך שיפור יחס האות לרעש באמצעות תקני איכות מחמירים יותר). +Terminal-Bench משתרע מרישום מודל mlflow פשוט, דרך פריצת סיסמת 7z בדרגת קושי בינונית, אינטגרציה קשה רבת‑רכיבים של שרת git ושרת אינטרנט, ועד לניתוח הצפנה דיפרנציאלי של FEAL — הקשה מכולם. -**אתגר חמישי: מניעת זיהום נתונים.** בעידן מודלי השפה הגדולים, זיהום נתונים הוא אתגר חמור להערכה: כאשר נתוני ההערכה כלולים בנתוני האימון, ההערכה מודדת שינון ולא הכללה. זה כמו לשנן את התשובות לפני בחינה — ציונים טובים אינם משקפים יכולת אמיתית. מדדי ביצועים שונים נוקטים אסטרטגיות מניעה שונות: ‏GAIA נשען על ייחודיות התשובות שלו; השאלות דורשות שילוב מידע ממקורות מרובים כדי לענות עליהן, וחלק מהמשימות מגיעות עם קובצי נספח שנוצרו במיוחד (קובצי PDF/אודיו/תמונות שאינם קיימים באינטרנט), כך שדף אינטרנט יחיד אינו יכול לספק את התשובה ישירות. ‏SWE-Bench Verified הוא כשלעצמו תת‑מערך של 500 משימות שהתקבל על ידי OpenAI באמצעות סינון איכות ידני של ה‑SWE-Bench המקורי, ואינו כולל עיצוב למניעת דליפה מבוסס זמן. עבודות המשך כגון SWE-bench-Live הן שמשתמשות באמת ברעננות זמנית כדי למנוע דליפה, ומשלבות ברציפות issues שנוצרו לאחר תאריך חיתוך האימון של המודל, ובכך שומרות על ההערכה מקדימה לקורפוס האימון של המודל. ‏τ²-bench מונע דליפה באמצעות יצירת פרמטרים דינמית, שבה מופעי משימה ספציפיים (שמות משתמשים, מספרי הזמנות, תאריכים וכדומה) נוצרים אקראית בכל פעם. יצירת המשימות המפורמטרת של AndroidWorld מסייעת באופן טבעי במניעת דליפה משום שהאימות מבוסס על מצב ה‑UI הסופי, ולא על רצף הפעולות. ‏Terminal-Bench הופך דליפה לניתנת לזיהוי באמצעות שיבוץ מזהי canary GUID (מזהים ייחודיים גלובלית המשמשים כסמני מעקב): אם מודל יכול להנפיק תוכן המכיל GUID זה, הדבר מעיד שנתוני מדד הביצועים דלפו לתוך מערך האימון. +τ²-bench אף מתכנן במיוחד **משימות מלכודת**: המשתמש טוען ש"שירות הלקוחות כבר אישר את הביטול" בעוד שבפועל הדבר אינו תואם את המדיניות, כדי לבחון אם ה‑Agent שומר על שיפוט נכון תחת לחץ והטעיה. -### עיצוב מדויק של תיאורי משימות +### מניעת דליפת נתונים -‏GAIA מבטיח ייחודיות תשובות באמצעות אילוצים ברורים על מקורות המידע, טווחי זמן, נושאים ויעדי שאילתה. לדוגמה, משימת Level 3 דורשת להתחיל מתמונת נאס"א של תאריך מסוים, לזהות את האסטרונאוט באמצעות הבנה חזותית, לאתר את קבוצת האסטרונאוטים שאליה הוא משתייך, לחשב את זמנו בחלל, ולפרמט את הפלט במדויק ("שם משפחה; שדות מופרדים בנקודה‑פסיק; מספרים מפורמטים עם מפרידי אלפים"). כל פרט משרת אימות אוטומטי — רק התאמה מדויקת בפורמט ובתוכן נחשבת למעבר. +**GAIA הופך את תשובותיו לבלתי ניתנות לחיפוש ישיר באינטרנט.** משימותיו פשוטות מבחינה רעיונית אך פתוחות מבחינת הדרך: למשל, לצאת מתמונת האסטרונומיה היומית של נאס"א בתאריך מסוים, לזהות את האסטרונאוט בתצלום, לאתר את קבוצת האסטרונאוטים שאליה השתייך, לחשב מי מבני הקבוצה שהה בחלל הכי מעט זמן, ולהפיק את התוצאה בפורמט קפדני של "שם משפחה, מופרד בנקודה‑פסיק, עם מפרידי אלפים". התשובה ספציפית מאוד, ונכונותה נקבעת בהתאמת מחרוזת מדויקת. מניעת הדליפה נשענת על שני דברים: ראשית, אפשר לענות על השאלה רק בשילוב כמה מקורות מידע, ואף דף אינטרנט בודד אינו מספק את התשובה ישירות; שנית, לחלק מהמשימות מצורפים קבצים שהוכנו במיוחד (קובצי PDF, שמע ותמונות שאינם קיימים באינטרנט). -‏τ²-bench מציג עיצוב מוקשר, כשכל משימה מכילה כמה שכבות מידע: הבעיה השטחית ("נתוני הסלולר לא עובדים"), ציפיית הביצועים ("דורש דירוג מהירות מצוין"), האילוץ ("לא יקבל שום דירוג אחר"), והרגש המשתמע. שיפור מרכזי הוא הפרדת "מידע ידוע" מ"הוראות משימה": מידע ידוע הוא מה שהמשתמש יודע כרגע, ואילו הוראות המשימה מנחות את המדמה כיצד לחשוף מידע בהדרגה, לרבות "דרישות עיגון" (התגובות חייבות להתבסס על התוצאות בפועל שהוחזרו מקריאות לכלים, ולא להיות בדויות). +**AndroidWorld גוזר מספר רב של מופעים מתבנית אחת.** משימותיו אינן טקסט סטטי אלא תבניות הניתנות להנבטה דינמית, כגון "שנה את מספר הטלפון של איש הקשר `[CONTACT_NAME]` ל‑`[NEW_PHONE]`", כשערכי הפרמטרים נוצרים אקראית בכל הערכה. לכך שלוש תועלות: הפרמטרים שונים בכל פעם, ולכן הרצה חוזרת של רצף פעולות קבוע חסרת ערך; תבנית אחת יכולה לייצר מופעים כמעט בלתי מוגבלים; וקיבוע חלק מהפרמטרים ושינוי היתר מאפשר למדוד במדויק את השפעתו של גורם מסוים. -‏SWE-Bench Verified כולל שדות מובנים כגון תיאור הבעיה, צעדי שחזור, והתנהגות צפויה/בפועל, כשמתייגים מאמתים את ההתאמה בין התיאור למקרי הבדיקה. כל מרכיב בתיאורי המשימות של Terminal-Bench ניתן לאימות מכני: האם נתיבי קבצים קיימים, ערכי הרשאות נכונים, פרמטרי אישורים תקפים, ופורמטי תאריכים נכונים. לדוגמה, "build-linux-kernel-qemu" דורשת לבנות את ליבת Linux 6.9 מקוד המקור, להוסיף printk מותאם אישית ב‑`start_kernel`, לייצר initramfs, ולהריץ אותו ב‑QEMU. קריטריון ההצלחה הוא הופעת ההודעה המותאמת ביומן האתחול — הסוכן אינו יכול לזייף את הפלט; עליו להשלים באמת את התהליך כולו. +**Terminal-Bench משבץ מזהה קנרית בגוף השאלה.** כל שאלה נושאת canary GUID; אם מודל מסוגל להפיק תוכן המכיל את המזהה הזה, סימן שנתוני מבחן הייחוס נכנסו למערך האימון. הדבר אינו מונע דליפה אך הופך אותה לניתנת לגילוי. -‏AndroidWorld משתמש בעיצוב **תבנית מפורמטרת**. משימה אינה טקסט סטטי אלא תבנית הניתנת למימוש דינמי (למשל, "שנה את מספר הטלפון של איש הקשר `[CONTACT_NAME]` ל‑`[NEW_PHONE]`"), עם ערכי פרמטרים שונים הנוצרים אקראית בכל הערכה. לכך שלוש תועלות: +### בקרת איכות ותחזוקה ארוכת טווח -- **מונע שינון**: ערכי הפרמטרים שונים בכל פעם, ומונעים שחזור של רצף פעולות קבוע -- **מגדיל את מגוון הנתונים**: תבנית אחת יכולה לייצר מופעים כמעט ללא הגבלה -- **תומך בניסויים השוואתיים**: קיבוע פרמטרים מסוימים תוך שינוי אחרים מאפשר מדידה מדויקת של השפעות גורמים ספציפיים +הכנת מערך הערכה איכותי היא משימה קשה מאוד. צורתם הנוכחית של רוב מבחני הייחוס לעיל היא תוצאה של סבבי תיקון חוזרים לאחר שהגרסה הראשונה נכנסה לשימוש ובעיותיה נחשפו. כך למשל, מ‑τ-bench ל‑τ²-bench תוכננו מחדש חמישה מקומות. -האימות מבוסס על מצב ה‑UI הסופי (למשל, האם שדה מספר הטלפון מכיל את הערך הצפוי), ולא על רצף הפעולות. +ראשית, **הוראות המשימה היו כלליות מדי, ולכן אפשר היה לנחש את התשובה**. הוראות הגרסה הראשונה נכתבו ברוחב יד, ולכן המודל לא נזקק לחדד באמת את הבקשה: די היה לנחש נוהל מתוך היגיון בריא כדי לעבור. τ²-bench פיצל את התסריט לשתי משבצות, `known_info` ו‑`task_instructions`: הראשונה מתחמת את מה שהמשתמש יודע, השנייה מסדירה את אופן החשיפה. את מה שהמשתמש אינו יודע אין ל‑Agent דרך לנחש, והוא יכול להשיגו רק בשאילתה. -משימות OSWorld לעיתים קרובות אינן מתחילות ממצב התחלתי "נקי" אלא ממצבי ביניים מוגדרים בקפידה, ובכך דומות יותר לתרחישי שימוש מהעולם האמיתי. תיאורי המשימות צריכים לטפל בפתרונות מרובים ("הגדר את הרקע לסגול" דורשת קוד צבע ספציפי כדי לפזר עמימות; "שרשר שני קובצי CSV" חייבת לקבל את כל השיטות הסבירות כגון שמירת כותרת אחת או שתי כותרות) ובאי‑ודאות סביבתית (אמצעי מניעת גריפה באתרים, ממשקי יישומים מתפתחים, ומרוצי תנאים — ‏OSWorld-Verified מקל על אלה באמצעות תצלומי דפים לא מקוונים, נעילת גרסאות תלויות, תנאי המתנה מפורשים וכדומה). +שנית, **תנאי ההצלחה לא היו מדויקים דיים, ולכן האימות שגה בשיפוט**. לתנאי כמו "הרשת חזרה" אין גבול הניתן לבדיקה. τ²-bench שינה אותו ל"נחשב פתור רק אם בדיקת המהירות מחזירה excellent; poor, fair ו‑good אינם מתקבלים". השינוי מכוון אל **תיקוני למראית עין**, המדכאים את הסימפטום בלי לפתור את שורש הבעיה. -רשימה זו אינה ממצה את נוף הערכת הסוכנים. אפילו בתוך קטגוריית Web/GUI ישנם כמה מדדי ביצועים בעלי דגשים שונים: ‏WebArena בונה אתרים ברי‑שחזור מלא (מסחר אלקטרוני, פורומים, אחסון קוד וכדומה), ומכיל את חוסר החיזוי של דפי אינטרנט אמיתיים בתוך ארגז חול; ‏Mind2Web הולך בכיוון ההפוך, ובודק הכללה ישירות על מאות אתרים אמיתיים; ‏[ClawBench](https://claw-bench.com/) ‏([מאמר](https://arxiv.org/abs/2604.08523), [קוד](https://github.com/TIGER-AI-Lab/ClawBench)) מאפשר לסוכן הרץ בקונטיינר מבודד לבצע משימות יומיום מקצה לקצה על אתרים חיים. ‏V1 מכסה 153 משימות על פני 144 אתרים, ‏V2 מוסיף עוד 130, והוא מתעד חמש שכבות ראיות במקביל: שחזורי סשן, צילומי מסך של פעולות, תעבורת HTTP, פעולות דפדפן והודעות סוכן. הוא משלים מדדי ביצועים בארגז חול בכך שהוא מקל על ניתוח סחיפה באתרים חיים וכשלי זנב ארוך, במחיר יכולת שחזור הנתונה לשינויים באתרי צד שלישי; ‏BrowseComp מתמחה באחזור עמוק — תשובות הקבורות עמוק כל כך שרק עיון רב‑קפיצות ובדיקה צולבת יכולים לחלץ אותן. בצד קריאות הכלים ישנן טבלאות דירוג ייעודיות לקריאת פונקציות כגון BFCL‏ (Berkeley Function-Calling Leaderboard). פרק זה אינו מנסה לקטלג את כולם. במקום זאת הוא לוקח את שתי פרדיגמות סביבת הליבה (קריאה לכלים ואינטראקציה אדם–מחשב), בתוספת תרחישי הפעלת ה‑GUI העוברים כחוט השני במקרי הבוחן של מערכי הנתונים, וצולל לפשרות העיצוב שלהן. ברגע שאתם מבינים את הפרדיגמות, תוכלו לשפוט במהירות מה כל מדד ביצועים חדש מודד, עד כמה טוב הוא מונע דליפת נתונים, ועד כמה ניתן להסיק ממסקנותיו מעבר להקשרן. +שלישית, **התנהגות סימולטור המשתמש הייתה מכנית מדי**. המשתמש המדומה בגרסה הראשונה רק הגיב באופן פסיבי. τ²-bench הוסיף לו רגש (להביע אי‑שביעות רצון אחרי תיקון ראשון שנכשל), גבול סבלנות (לסיים את השיחה כשהתקשורת בלתי יעילה מדי) ואת דרישת העיגון העובדתי. שלושתם יחד מקרבים את הסימולטור למשתמש אמיתי תוך שמירה על יכולת שחזור. -### עיצוב היררכי של מורכבות המשימות +רביעית, **המשתמש משתתף לא רק בשיחה אלא גם בביצוע**. תחום telecom הכניס את סביבת הבקרה הכפולה. בהערכות הקודמות רק ה‑Agent יכול היה לשנות את הסביבה, בעוד שבתרחישים כמו תמיכה טכנית חלק ניכר מהפעולות אמור להתבצע בידי המשתמש עצמו במכשירו. הבקרה הכפולה אף מוסיפה ממד לאימות: לאחר שהמשתמש משנה את המצב, ה‑Agent יכול לדעת את התוצאה רק בקריאה חוזרת לכלי, ולכן האימות מכסה כעת גם את השאלה "האם ה‑Agent אכן קרא את תוצאת הפעולה בצד המשתמש". -‏GAIA מעצב שלוש רמות קושי: ‏Level 1 דורשת רק 1‑2 כלים (בני אדם 93.9% מול GPT‑4 30.3%), ‏Level 2 דורשת היסק רב‑שלבי (91.8% מול 9.7%), ו‑Level 3 דורשת שילובים מורכבים (87.3% מול 0%). הערך האבחנתי של עיצוב מדורג זה הוא: כשל ב‑Level 1 מצביע על בעיות בשימוש בסיסי בכלים, ‏Level 2 מצביעה על תכנון רב‑שלבי ושילוב מידע, ו‑Level 3 מצביעה על היסק ארוך‑רצף וניהול מורכבות. כל רמה מתאימה לכיווני שיפור שונים (הנדסת פרומפטים מול מנגנוני תכנון מול ארכיטקטורה היררכית/אימון־על). +חמישית, **מופעי המשימות נוצרים דינמית**. המופעים הקונקרטיים של τ²-bench (שמות משתמשים, מספרים, צירופי תקלות) ניתנים לפרמטריזציה וליצירה בכמות, וזה משפר גם את הכיסוי וגם את העמידות בפני דליפה. -‏τ²-bench מדרג מורכבות לפי תהליך עסקי: משאילתות מידע פשוטות, דרך תהליכים רב‑שלביים (שינוי הזמנת טיסה דורש תשאול, הצגת חלופות, קבלת אישור, חישוב הפרש המחיר, ועיבוד תשלום), אל אבחון תקלות (בדיקה שיטתית של כמה סיבות אפשריות ואימות התיקונים), ולבסוף אל שיקול דעת אסטרטגי (טיפול בבקשות שאינן תואמות למדיניות). +**SWE-bench Verified: לפני הפרסום נפסלו 71% מהמשימות המקוריות.** OpenAI בחרה אקראית 1,699 מתוך 2,294 המשימות המקוריות להערכה אנושית, וגייסה 93 מפתחים הבקיאים ב‑Python לבדוק כל אחת בנפרד: אם תיאור הבעיה ברור, אם מקרי הבדיקה מכסים תנאי קצה, אם הבדיקות יציבות, אם ה‑patch הייחוס מכניס שגיאות חדשות, ואם הקושי סביר. בסופו של דבר עברו רק 500. שיעור הפסילה הגבוה מניב יחס אות לרעש טוב יותר, ועלות ההערכה יורדת בכ‑80%. משימות Agent מורכבות אורכות לא אחת מדקות ועד שעות, והרצת מערך הערכה שלם עם מודל חזית עולה פעמים רבות אלפי דולרים באסימונים, ולכן הפחתת עלות ההערכה חשובה מאוד. -‏Terminal-Bench מדרג מורכבות לאורך שני הממדים של תחום טכני × מורכבות תפעולית. מרשם המשימות שלו אסף למעלה מ‑200 משימות (גודל מערך ההערכה המרכזי משתנה בין גרסאות; לדוגמה, גרסה 2.0 בחרה 89 משימות איכותיות מתרומות הקהילה), הנעות מרישום מודל פשוט ב‑MLflow, דרך פיצוח סיסמת 7-Zip בקושי בינוני, דרך שילוב שרת Git ושרת אינטרנט בקושי גבוה, ועד לקריפטואנליזה דיפרנציאלית של FEAL הקשה מכולן (הדורשת ידע בקריפטוגרפיה + אופטימיזציית אלגוריתמים כדי לעמוד באילוץ הזמן של 30 שניות). +**OSWorld: ב‑15 החודשים שלאחר הפרסום נחשפו יותר מ‑300 בעיות.** לאחר צאתו באפריל 2024 הפך במהירות למבחן ייחוס חשוב להערכת Agent רב‑מודלי, אך השימוש הרחב שלאחר מכן חשף ארבעה סוגי בעיות: בעיות סביבה (הגנת אתרים מפני גריפה, CAPTCHA, שינוי תוכן דינמי), בעיות בתיאור המשימות (ניסוח דו‑משמעי), בעיות בלוגיקת האימות (מחמירה או מקלה מדי) ובעיות במצב ההתחלתי (תצורה חסרה). צוות מאוניברסיטת הונג קונג הקים קבוצה של כעשרה אנשים ועבד חודשיים בשיתוף הדוק עם MoonShot AI, OpenAI, ByteDance Seed TARS, Anthropic, Simular ואחרים על תיקון שיטתי: בעיות הסביבה טופלו בנעילת גרסאות ובגיבויים לא‑מקוונים, בעיות התיאור בשכתוב ניסוחים דו‑משמעיים, בעיות האימות בהקמה ידנית של קו בסיס נכון ובכוונון התנאים, ובעיות המצב ההתחלתי בהוספת בדיקות שלמות. -### הבטחת יכולת אימות ואובייקטיביות - -התשובות של GAIA תמציתיות וברורות. כללי פורמט קפדניים מאפשרים אימות באמצעות התאמת מחרוזות מדויקת. התוצאה הבינארית (התאמה או אי‑התאמה) מבטיחה יכולת שחזור אובייקטיבית. נדירות התשובות משמשת גם כאמצעי נגד רמייה — עובדות ספציפיות מאוד אינן סבירות להופיע מילה במילה בנתוני האימון. +> **ניסוי 7-2 ★: ביצוע ידני של משימות מבחני ייחוס** +> +> בחרו משימות מ‑GAIA, AndroidWorld, SWE-Bench Verified, Terminal-Bench ו‑OSWorld-Verified והשלימו אותן במו ידיכם; מומלץ לבצע מכל מערך אחת קלה, אחת בינונית ואחת קשה. הרמה "קשה" מאתגרת גם בני אדם. +> +> בסיום ענו על שתי שאלות. האם תיאור המשימה סובל יותר מפרשנות סבירה אחת, ואם כן — באיזו מהן מכיר המאמת? ואם ינסה מישהו לחמוק בלי לעשות את העבודה, מהי הדרך הזולה ביותר, והאם המאמת יוכל לחסום אותה? -‏SWE-Bench Verified משתמש בבדיקות מבוססות קוד בר‑הרצה, ומבחין בין FAIL_TO_PASS (נכשל לפני התיקון, עובר אחריו, ומוכיח שהבעיה נפתרה) לבין PASS_TO_PASS (עובר גם לפני התיקון וגם אחריו, ומוכיח שלא הוכנסו באגים חדשים), ובכך משיג אימות כפול. גרסת Verified גם מבטיחה שהבדיקות עצמן אמינות, ללא בדיקות מהבהבות שלעיתים עוברות ולעיתים נכשלות. +### שלושת מקורותיו של מערך ההערכה -מערכת האימות של τ²-bench כוללת כמה שכבות בדיקה (תוצאות כל שכבה עדיין מצטברות לתגמול בינארי ברמת המשימה; כולן חייבות לעבור כדי להצליח): +רווחת הדעה שמבחני ייחוס ציבוריים משרתים דירוג מודלים וקשורים מעט לעסק האמיתי. אכן, קשה שציוני מבחני ייחוס ציבוריים יכוונו ישירות החלטות מוצר, אך שיטות התכנון שלהם ניתנות להעברה במלואן. עומק האימות, יצירה פרמטרית, מניעת דליפה ותחזוקת איכות — כל מה שנדון לעיל — הם בדיוק הנקודות שקל ביותר לפספס במערך הערכה שבונים בעצמם. -- **בדיקת מצב מסד הנתונים**: סטטוס רשומת ההזמנה, האם נוצרה רשומת החזר -- **חיפוש מילות מפתח בתוכן הדיאלוג**: האם הסוכן מאשר במפורש למשתמש את סכום ההחזר ואת מועד ההגעה הצפוי -- **ציות לתהליך**: ניתוח רצף קריאות הכלים, למשל האם התקבל אישור מפורש מהמשתמש לפני שינוי הזמנה +למערך הערכה בסביבת ייצור יש בדרך כלל שלושה מקורות. -סביבת הבקרה הכפולה של τ²-bench (ראו את הסעיף הקודם "סביבת הערכה לאינטראקציה אדם–מחשב") מוסיפה ממד נוסף לאימות: לאחר שמדמה המשתמש משנה בפועל את מצב הסביבה, הסוכן חייב להבחין בשינוי זה באמצעות קריאות לכלים ולהמשיך באבחון בהתאם. האימות מכסה לפיכך האם הסוכן אכן הבחין בתוצאת פעולות המשתמש. +**מבחני ייחוס ציבוריים** משמשים לסינון גס של מודלים ולשאילת שיטות תכנון, ובדרך כלל לא להחלטות מוצר. התפלגות המשימות שלהם אינה חופפת להתפלגות המשימות של העסק האמיתי; עלייה של שתי נקודות אחוז ב‑GAIA אינה קשורה בהכרח לשיעור ההצלחה של זיכויים. -‏OSWorld מספק 134 פונקציות הערכה עצמאיות בעלות גישה מלאה למערכת ההפעלה, ומאפשר בדיקה עמוקה של מבני מערכת הקבצים, מצבי תהליכים, חיבורי רשת ומרכיבים פנימיים של יישומים. לדוגמה, במשימת פעולה על מסד נתונים, סקריפט ההערכה לא רק מאמת שקובץ הדוח קיים אלא גם מתחבר ישירות למסד הנתונים כדי לבדוק האם ה‑SQL הורץ נכון. במשימות דפדפן, הוא מנתח את עץ ה‑DOM, בודק cookies/localStorage, ושולח בקשות אימות לצד האחורי כדי לאשר האם שליחת הטופס אכן נכנסה לתוקף. בדיקה עמוקה זו יכולה לזהות מקרים של "השלמה שטחית אך שגיאה מהותית" — לדוגמה, הסוכן לחץ על כפתור השליחה, אך הבקשה נדחתה על ידי השרת בשל הזנת שדות שגויה. +**מערך עסקי שבונים בעצמם** מכסה את התפלגות המשימות האמיתית, ויכול לשמש בסיס לבחירת מודל ולהחלטות תכנון של ה‑Harness. למשל, אפשר להשתמש ב‑τ²-bench כשלד לכל מערכת הערכה הזקוקה למשתמש מדומה; די להחליף את נתוני התחום ואת ערכת הכלים. -‏Terminal-Bench מבוסס על סביבת קונטיינר Docker מתוקננת, ומשלב בדיקות מצב מערכת קבצים (קיום נתיבים, ערכי הרשאות, פורמט תוכן) עם אימות תפקודי בהרצת תוכניות (ב‑build-linux-kernel-qemu, הפעלה בפועל של QEMU וחיפוש הודעת ה‑printk המותאמת). ה‑canary GUID הופך דליפה לניתנת למעקב. +**זרימה חוזרת של trajectory מהייצור** מגיעה מכשלים אמיתיים בשטח: תיקונים מפורשים מצד המשתמש, דירוגים שליליים שלו, ומקרים שהתגלו בדיעבד בבדיקת מצב, במאמת מבוסס כללים או בסקירה של מודל שפה. לאחר שעברו ייחוס כשלים, הם משתקעים כמקרי רגרסיה. הדרך המפורטת מתוארת בהמשך בסעיפים "ייחוס כשלים" ו"משימות רגרסיה מקצה לקצה ומשימות רגרסיה של trajectory prefix". המקור הזה הוא היקר ביותר וגם המדויק ביותר, משום שהוא מגיע ישירות ממה שהמשתמשים נתקלו בו בפועל. -### עיצוב שיטתי של התפלגות המשימות +בשלב הראשוני יש בדרך כלל רק מבחני ייחוס ציבוריים ומערך עסקי קטן שנכתב ידנית; לאחר שהמערכת פועלת זמן מה בייצור, המקרים שזרמו חזרה מה‑trajectory של הייצור הופכים לעיקר. -התפלגות המשימות צריכה לכסות באופן שיטתי ממדי יכולת, ממדי קושי, ממדי תרחיש ומקרי קצה. ‏GAIA חותר לכלליות — מרבית המשימות דורשות שילוב של היסק, רב‑מודאליות, עיון בדפדפן ושימוש בכלים. ‏τ²-bench מעצב בכוונה "משימות מלכודת" — משתמש טוען ש"שירות הלקוחות אישר את הביטול" כאשר הביטול אינו תואם למדיניות בפועל — כדי לבדוק האם הסוכן מחזיק בשיפוטו תחת לחץ והטעיה. ‏OSWorld מבוסס על מטריצה דו‑ממדית של סוג פעולה (קלט/פלט קבצים / יישום שולחן עבודה / יישום רשת / זרימת עבודה חוצת‑יישומים) ותחום יישום, ומשתרע על שלוש מערכות הפעלה (מחקר מראה מתאם חוצה‑מערכות חזק; מיומנויות שנלמדו במערכת אחת יכולות לעבור לאחרות). ‏Terminal-Bench כולל "משימות שילוב חוצות מחסנית טכנולוגית" כדי לבדוק חשיבה מערכתית (למשל, משימת resharding המשלבת עיבוד נתונים + פעולות קבצים + הנדסת Python). +## שיטות הערכה אוטומטיות -### בקרת איכות נתונים ושיפור איטרטיבי +למבחני הייחוס שנדונו בסעיפים הקודמים יש מכנה משותף: המאמתים שלהם דטרמיניסטיים כמעט כולם. SWE-bench מריץ חבילת בדיקות, AndroidWorld קובע את מצב ה‑UI הסופי, GAIA מבצע התאמת מחרוזת מדויקת, וארבע שכבות הבדיקה של τ²-bench מורצות אף הן כולן בקוד. לבחירה הזו יש נימוקים טובים: אימות דטרמיניסטי אינו מוסיף עלות מודל, התוצאה ניתנת לשחזור מלא, אפשר לשלב אותו באינטגרציה רציפה כמו בדיקת יחידה, והוא מקל על דירוג בין מודלים. -‏SWE-Bench Verified הוא מופת של בקרת איכות. ‏OpenAI בחרה אקראית 1,699 משימות מתוך 2,294 המקוריות להערכה אנושית, וגייסה 93 מפתחים הבקיאים ב‑Python. המתייגים נדרשו לבצע כמה בדיקות: האם תיאור הבעיה היה ברור (האם הם יכלו להבין מה צריך לפתור), האם מקרי הבדיקה היו שלמים (מכסים את כל ההיבטים ומקרי הקצה), האם הבדיקות היו יציבות (ללא בדיקות מהבהבות בשל הסביבה או אקראיות), האם התיקון היה נכון (האם הכניס שגיאות חדשות), והאם הקושי היה סביר. לאחר סינון קפדני, רק 500 עברו (29%) — שיעור דחייה גבוה זה הוא השקעה הכרחית באיכות ההערכה. הם גם ביססו הנחיות תיוג מתוקננות, והגדירו קריטריונים ודוגמאות ספציפיים לכל בדיקה כדי להבטיח עקביות בין מתייגים שונים. +מחירו הוא שהוא מסוגל להעריך רק אם התוצאה הסופית נכונה, אך אינו מספק את סיבת השגיאה. המשימה שנכשלה ב‑τ²-bench קיבלה בסופו של דבר 0 נקודות, ואותו 0 אינו מסביר אם ה‑Agent שגה בשלב בחירת הקו או פספס את שלב טעינת הנתונים, ובוודאי אינו מצביע על מה יש לשנות בשלב הבא. עבור מבחן ייחוס ציבורי המשמש לדירוג אין זה פגם; עבור מערכת ייצור הזקוקה לשיפור מתמיד זהו בדיוק המידע הנחוץ ביותר. -‏τ²-bench מציג הפרדה בין "מידע ידוע" ל"הוראות משימה" (ההופכת את התנהגות המדמה לריאליסטית יותר) ותנאי השלמה מחמירים יותר (למשל, "רק מצוין נחשב פתור; גרוע/סביר/טוב אינם מתקבלים"), ובכך מונע "תיקונים שטחיים". +לסביבת הייצור יש קושי שני: הרבה שיפוטים אינם ניתנים כלל לניסוח כקביעה שקוד יכול לבדוק. אם מענה לתלונה הולם, אם דוח מחקר החסיר מידע מרכזי, אם אחזור זיכרון בלבל בין יחסי אנשים — לכל אלה אין מצב סופי יחיד שאפשר לשאול עליו, ואי אפשר להכריע בהם בהתאמת מילות מפתח. -‏OSWorld-Verified הוא מופת של שיפור איטרטיבי. לאחר פרסומו באפריל 2024, ‏OSWorld הפך במהירות למדד ביצועים חשוב להערכת סוכנים רב‑מודאליים, אך במהלך 15 חודשים של שימוש נרחב נחשפו למעלה מ‑300 בעיות. בעיות אלה מתחלקות לארבע קטגוריות: בעיות סביבה (אמצעי מניעת גריפה באתרים, ‏CAPTCHA, ושינויי תוכן דינמיים), בעיות תיאור משימה (ניסוח עמום), בעיות בלוגיקת האימות (מחמירה מדי או מקלה מדי), ובעיות מצב התחלתי (תצורה חלקית). צוות של כ‑10 אנשים מאוניברסיטת הונג קונג עבד בשיתוף הדוק עם MoonShot AI,‏ OpenAI,‏ ByteDance Seed TARS,‏ Anthropic,‏ Simular ואחרים במשך חודשיים כדי לתקן בעיות אלה באופן שיטתי. אסטרטגיות תיקון גובשו לכל קטגוריה: בעיות סביבה נפתרו באמצעות נעילת גרסאות וגיבויים לא מקוונים, תיאורי משימות הובהרו באמצעות ניסוח מחדש של ביטויים עמומים, לוגיקת האימות אוזנה באמצעות ביסוס ידני של קווי בסיס נכונים והתאמת תנאים, ומצבים התחלתיים חוזקו באמצעות הוספת בדיקות שלמות. +לכן, במעבר ממבחני ייחוס ציבוריים להערכה בסביבת ייצור, יש להזיז את אופן האימות ימינה לאורך ספקטרום שצירו האופקי הוא **מידת יכולת האימות המכנית** של המשימה, כמוצג באיור 7‑4. -## שיטות הערכה אוטומטיות +![איור 7‑4: ספקטרום אופני האימות — מאימות דטרמיניסטי לשיפוט מודל](images/fig7-4.svg) -לאחר שסביבת ההערכה, מערך הנתונים ומערכת המדדים הברורה במקומם, שאלת הליבה הופכת להיות: כיצד לנקד? עבור משימות בעלות תשובות נכונות ברורות (למשל, בעיות מתמטיות, שאילתות SQL), די בשיפוט בינארי פשוט (נכון/שגוי); אך עבור משימות פתוחות (למשל, דיאלוגי שירות לקוחות, כתיבת דוחות), נדרשות שיטות הערכה מעודנות יותר. +כך הופכים שני הכלים שבצד ימין של הספקטרום לעמוד השדרה של הערכת ייצור: **Rubric** מפרק את השאלה המעורפלת "טוב או לא" לכמה ממדים הניתנים לניקוד בנפרד, ו‑**LLM-as-a-Judge** מבצע את הניקוד היכן שאין קריטריון דטרמיניסטי. רק בשילובם אפשר להחזיר שיעור כישלון מעורפל לבעיות קונקרטיות שאפשר לגשת לתקנן; ובצירוף **ייחוס כשלים** שבמחצית השנייה של הסעיף נוצר המעגל הסגור המלא של הערכת Agent בייצור. -אימות אוטומטי מבוסס קוד מכסה רק תרחישים בעלי תשובות תקן; ניקוד משימות פתוחות הוא הנושא העיקרי של סעיף זה. מתוכם, עיצוב צפיפות אות התגמול (מתגמולים בינאריים לתגמולי תהליך לתגמולים גנרטיביים) ושיטות אימון למודלי תגמול נותרים לדיון שיטתי בסעיף אימון־העל שבפרק 8; סעיף זה עונה על שאלה יסודית יותר: כיצד להשתמש במודלי LLM כדי לשפוט אוטומטית את איכות הפלט של משימות פתוחות. +יש להדגיש: ההזזה ימינה אינה משמעה נטישת הצד השמאלי. כל בדיקה שאפשר לכתוב כקביעה תוכניתית צריכה להישאר קביעה, ושיפוט המודל מיועד רק לממדים שבאמת אינם ניתנים להכרעה מכנית. בדיקות דטרמיניסטיות זולות ויציבות יותר, ומתאימות יותר גם להרצה ארוכת טווח כבדיקות רגרסיה. ### LLM‑as‑a‑Judge: ליבת ההערכה האוטומטית -![איור 7‑4: צינור ה‑LLM‑as‑a‑Judge](images/fig7-4.svg) +![איור 7‑5: צינור ה‑LLM‑as‑a‑Judge](images/fig7-5.svg) מדוע נדרש LLM‑as‑a‑Judge? עבור משימות פתוחות (למשל, יצירת דוחות, טיפול בתלונות לקוחות, תוכן יצירתי), אין תשובות תקן להשוואה אוטומטית, והערכה אנושית יקרה וקשה להרחבה. ‏LLM‑as‑a‑Judge מאזן בין ניתנות ההרחבה של אוטומציה לבין שיפוט של מומחה אנושי בכך שהוא מאפשר למודל שפה להעריך פלטים אל מול קריטריוני ניקוד שהוגדרו על ידי מומחים (Rubric). לשיטה יש עם זאת מגבלות ידועות: למודל השופט יש הטיות משלו (הטיפוסית ביותר היא **הטיית אורך** — נטייה לנקד תגובות ארוכות ומפורטות יותר גבוה יותר גם כשהן אינן נכונות יותר), ושיפוטים חוזרים של אותו קלט יכולים להשתנות. הטיית אורך בפרט מצדיקה אמצעי נגד ספציפיים. שלוש הגנות נפוצות הן: להעניש מילוליות יתר במפורש ב‑Rubric ולהגביל את אורך התגובה לכל סוג משימה; בהשוואות זוגיות, להביא את שני המועמדים לאורכים דומים לפני השיפוט; ולבקר באופן קבוע את המתאם בין הציונים לבין אורך התגובה — אם ציונים גבוהים הולכים כמעט תמיד לתגובות ארוכות, השופט הוטה על ידי האורך וה‑Rubric דורש תיקון. כדי לטפל באתגרים אלה באופן שיטתי, עיצוב ה‑Rubric חייב לעקוב אחר העקרונות שלהלן: @@ -535,7 +536,7 @@ original file bytes → tool return → Harness serialization → model context ### השוואה זוגית ודירוג מודלים -![איור 7‑5: דירוג Elo והשוואה זוגית](images/fig7-5.svg) +![איור 7‑6: דירוג Elo והשוואה זוגית](images/fig7-6.svg) **דירוג Elo** (מערכת דירוג שתוכננה במקור לשחמט) מכמתת את היכולת היחסית של מודלים באמצעות מספר גדול של עימותים זוגיים: ככל שהפרש הדירוג גדול יותר, כך שיעור הניצחון הצפוי של המודל החזק יותר גבוה יותר. לדוגמה, אם למודל A דירוג של 1200 ולמודל B דירוג של 1000, מערכת Elo תחזה ששיעור הניצחון של A הוא כ‑76%. אם B מנצח באופן מפתיע, ‏B צובר יותר נקודות ו‑A מפסיד יותר — הפתעה מפעילה תיקון גדול יותר, וזה מה שמאפשר לדירוגים להתכנס במהירות ליכולת האמיתית. הבסיס הסטטיסטי הוא **מודל Bradley‑Terry**: כל מודל מופשט כ"ציון עוצמה" סמוי, וההסתברות שאחד ינצח את האחר בעימות נקבעת על ידי ההפרש בין ציוניהם. ‏Elo הוא המימוש ההנדסי של מודל זה בצורת עדכון מקוון. @@ -699,7 +700,7 @@ return paired_bootstrap_or_mcnemar(all_deltas) החלטות מונחות הערכה (בין לבחירת מודלים ובין לאיטרציה מתמשכת) נשענות על נתוני הפעלה איכותיים. להלן נציג תחילה כיצד לאסוף נתונים אלה באופן שיטתי (יכולת תצפית), ואז נדון כיצד לתרגם תוצאות הערכה לשיפורי מערכת. -![איור 7‑6: מחסנית הטכנולוגיה של יכולת התצפית](images/fig7-6.svg) +![איור 7‑7: מחסנית הטכנולוגיה של יכולת התצפית](images/fig7-7.svg) יכולת תצפית היא מושג שאול ממערכות מבוזרות: אינכם יכולים לפתוח את המערכת ולצפות בה עובדת; אתם מסיקים מה קורה מהיומנים, מהמדדים ומהמעקבים שהיא פולטת — כפי שרופא, שאינו יכול לראות בתוך המטופל, מאבחן מחום, מלחץ דם ומדימות. מערכות סוכן מקשות על כך עוד יותר: אותו קלט יכול להפיק פלטים שונים, היסק רב‑סבבי וקריאות לכלים הופכים את נתיבי הביצוע למורכבים ביותר, ו"החשיבה" של המודל אטומה לחלוטין מבחוץ. @@ -719,7 +720,7 @@ return paired_bootstrap_or_mcnemar(all_deltas) המקרה הבא מגיע מאיטרציית AndroidWorld אמיתית וצרה בכוונה מהמאגר הנלווה. הוא מכסה ארבע משימות הגדרות Wi‑Fi על אמולטור API 35, עם הרצה מותאמת אחת לכל משימה. אין זה מדד הביצועים המלא בן 116 המשימות ואין הוא מחליף הרצה חוזרת בסביבת הייחוס API 33. ערכו אינו ציון כולל; הוא רצף ההחלטות מתוצאה אחת לבאה. -![איור 7‑7: הלולאה ממדד ביצועים לשיפור](images/fig7-7.svg) +![איור 7‑8: הלולאה ממדד ביצועים לשיפור](images/fig7-8.svg) מנקודת המבט של הנדסת Harness, סעיף זה עוסק במהותו במתודולוגיה לאופטימיזציה איטרטיבית של ה‑Harness — שימוש בנתוני הערכה כדי לזהות נקודות תורפה ב‑Harness (הקשר בלתי מספק? אילוצים חסרים? אימות בלתי הולם? משוב שאינו בזמן?), ביצוע שיפורים ממוקדים, ואז הערכה מחדש, ובכך יצירת לולאה סגורה להתפתחות מתמשכת של ה‑Harness. @@ -828,7 +829,7 @@ return paired_bootstrap_or_mcnemar(all_deltas) כך נפגשים שני קצות הגשר. נכסים שנצברו בצד ההערכה מומרים כמעט בחלקות לאותות אימון: ‏Rubric או מאמת מוגדרים היטב הם במהותם פונקציית תגמול ל**למידת חיזוק עם תגמולים ניתנים לאימות (RLVR)** — סקריפט הניקוד הופך לסקריפט התגמול; האם בדיקה עוברת או האם מצב עומד בתקן משמש הן כקריטריון הערכה והן כתגמול בלמידת חיזוק. אך אימון מביא דרישות שההערכה מעולם לא הייתה צריכה לדאוג להן. הראשונה היא **סמנטיקת איפוס אמינה**: אימון מריץ מיליוני אפיזודות (אפיזודה היא סבב אינטראקציה שלם ממצב התחלתי ועד השלמת המשימה), וכל אפיזודה חייבת להיות מסוגלת לאפס את הסביבה למצב התחלתי דטרמיניסטי ונקי; אחרת, אות הגרדיאנט יזוהם על ידי מצבים שיוריים מהאפיזודה הקודמת. השנייה היא **תפוקה החורגת הרבה מזו של הערכה**: כמה אלפי הערכות די בהן כדי להסיק מסקנות, אך אימון דורש להזין למודל מיליוני אינטראקציות בתוך זמן שעון מקובל; מידת המקביליות של הסביבה והתקורה לכל מופע קובעות ישירות האם האימון בר‑ביצוע. שתי נקודות אלה — מאמתים ההופכים לפונקציות תגמול, ואיפוס ותפוקה ברמת אימון — יפורטו בפרק 8. -![איור 7‑8: ספקטרום נאמנות הסימולציה](images/fig7-8.svg) +![איור 7‑9: ספקטרום נאמנות הסימולציה](images/fig7-9.svg) בצד ה**סביבה הדיגיטלית**, מסגרת AWorld בונה ארגז חול נשלט של שרתי MCP למשימות GAIA, ומספקת 26 שרתי MCP המכסים 126 פונקציות כלים, ובכך נמנעת מחסימות ומתופעות לוואי בלתי נשלטות של גישה ישירה לממשקי API אמיתיים. כל קריאות הכלים ניתנות לשחזור ולביקורת. הארכיטקטורה המבוזרת של AWorld מצמצמת את זמן הביצוע הטורי המסורתי מ‑7695 שניות ל‑525 שניות (האצה פי 14.6), והעיצוב חסר המצב של הסביבה הופך כל מופע לעצמאי לחלוטין, ותומך במקביליות יעילה. @@ -839,7 +840,7 @@ return paired_bootstrap_or_mcnemar(all_deltas) > הקימו סביבת סימולציה למניפולציה רובוטית. קראו את `ch7/SimpleVLA-RL` ואת תיעוד OpenVLA כדי להבין את ארכיטקטורת מודל ה‑Vision-Language-Action (שילוב מקצה לקצה של מקודד ראייה, מודל שפה ומפענח פעולות, המקרין תמונות וטקסט למרחב סמנטי משותף). הגדירו את סביבת RoboTwin2, תוך הבנת מרחב התצפית (RGB בשלוש תצוגות + מצב מפרקים בן 14 ממדים) ומרחב הפעולה (וקטור בקרה בן 14 ממדים). למדו את מנגנון אקראיזציית הסביבה ואת לוגיקת האילוצים המרחביים ב‑`move_can_pot`. העריכו את המודל המאומן מראש, ותעדו את שיעור ההצלחה שלו, את זמן ההשלמה ואת אופני הכשל, תוך התמקדות בהשפעת מנגנון קיבוץ הפעולות. > > -> ![איור 7‑9: סביבת האינטליגנציה המגולמת של OpenVLA ו‑RoboTwin2](images/fig7-9.svg) +> ![איור 7‑10: סביבת האינטליגנציה המגולמת של OpenVLA ו‑RoboTwin2](images/fig7-10.svg) > > @@ -851,7 +852,7 @@ return paired_bootstrap_or_mcnemar(all_deltas) ## סיכום הפרק -פרק זה נסב סביב שאלה אחת מרכזית: כיצד לקבוע אם סוכן השתפר או הידרדר? מהגדרת קריטריוני ההצלחה והבחנה בין Pass@k, ‏Best@k ו-Pass consecutive@k, דרך בניית סביבות בדיקה בנות-שחזור, תכנון מערכי נתונים שעומדים במבחן הדליפה, הצבת LLM כשופט וייחוס בר-ביקורת של מסלולי כישלון, ועד לשימוש בתוצאות ההערכה כדי להניע בחירת מודל ואיטרציה — כל חוליה בשרשרת הזו משפיעה על מידת האמינות של המסקנה. +פרק זה נסב סביב שאלה אחת מרכזית: כיצד לקבוע אם סוכן השתפר או הידרדר? השרשרת מורכבת מארבע חוליות: תחילה לחדד מהי הצלחה (הבדלי הבסיס בין Pass@k, ‏Best@k ו‑Pass consecutive@k), אחר כך לקבוע מהיכן מגיעות המשימות (מבחני ייחוס ציבוריים, מערך עסקי עצמי, וזרימה חוזרת של trajectory מהייצור), לאחר מכן לבחור את אופן האימות (ממאמתים דטרמיניסטיים לרשימות בדיקה, ל‑Rubric עם שיפוט LLM, ועד להשוואה זוגית), ולבסוף להפוך ציונים להחלטות (מובהקות סטטיסטית, ייחוס כשלים, משימות רגרסיה ובחירת מודל). כל חוליה משפיעה על מהימנות המסקנה. במונחי המבנה הגדול של הספר, פרק זה בונה את מקטע ה**ראיות** של לולאת הגילוי מפרק 1: ייחוס כשלים קובע האם להצעות המאוחרות יותר יש על מה להישען. diff --git a/book-he/images/fig7-1.svg b/book-he/images/fig7-1.svg index f301aacbe..385ea88b0 100644 --- a/book-he/images/fig7-1.svg +++ b/book-he/images/fig7-1.svg @@ -1,19 +1,66 @@ - - - -Layer 1: Evaluate the Environment -"Where to test" — Tool-calling / Human-computer interaction / Simulation environment - - -Layer 2: Evaluation Methods -"How to judge" — Dataset design · LLM-as-a-Judge · Pairwise comparison and ranking - - -Layer 3: Evaluation-Driven Decisions -"What to do after testing" — Model selection · Architecture optimization · Continuous iteration - -Engineering Themes Throughout the Chapter -• Observability -• Simulation environment -• Internal evaluation - \ No newline at end of file + + + + + + + + +① הגדרת ההצלחה +Pass@k מודד תקרת יכולת · Pass^k מודד אמינות + + + +② מקור המשימות + +מבחני ייחוס ציבוריים +שאילת שיטות · סינון גס + +מערך עסקי עצמי +התפלגות משימות אמיתית + +זרימה חוזרת מהייצור +תוצר ייחוס הכשלים + + + +③ אופן האימות +← לפי מידת יכולת האימות המכנית של המשימה → + +דטרמיניסטי +SWE-bench + + +רשימת בדיקות +τ²-bench + + +Rubric + שיפוט LLM +משימות פתוחות + + +השוואה זוגית +Chatbot Arena + + + +④ שימוש בתוצאות +מובהקות ← ייחוס כשלים ← רגרסיה ← בחירת מודל ואיטרציית Harness + + +משימות רגרסיה הופכות למקרים חדשים + + +תשתית תומכת +נצפוּת · תשתית הערכה פנימית (אבלציה / AB / דגלים) · סביבת סימולציה (פרק 8) + diff --git a/book-he/images/fig7-10.svg b/book-he/images/fig7-10.svg new file mode 100644 index 000000000..6762ce35b --- /dev/null +++ b/book-he/images/fig7-10.svg @@ -0,0 +1,69 @@ + + + + +Multimodal observation + +Head camera +224×224 RGB + +Left wrist camera +224×224 RGB + +Right wrist camera +224×224 RGB + +14-dimensional joint state vector + +Vision-Language-Action model (VLA) + +Vision encoder +SigLIP → visual tokens + + +Language model +Llama 2 7B backbone + + +Action decoder +→ 14-dimensional continuous control vector +Action chunking: generate 25 consecutive actions at once + + + +Instruction: "Put the can into the pot" + + +SAPIEN physics engine + +Dual-arm robot +7 DOF each = 14-dimensional action + +Environment randomization +Position 60cm / orientation ±22.5° + +Collision detection + physics simulation +Rigid body / soft body / friction + +Action + +Observation + +Evaluation metrics + +Success rate +Can inside pot +and not fallen + +Completion time +25 steps × 25 actions += 625 control steps + +Generalization ability +Cross-position/orientation +/Appearance variant + +Sim-to-Real +Domain randomization +→ Real migration + \ No newline at end of file diff --git a/book-he/images/fig7-3.svg b/book-he/images/fig7-3.svg index d8f6fcc1c..fc0684224 100644 --- a/book-he/images/fig7-3.svg +++ b/book-he/images/fig7-3.svg @@ -1,68 +1,80 @@ - - + + + + + + + \ No newline at end of file +.t,.l{direction:rtl;unicode-bidi:plaintext} +.c{font-family:'SF Mono',Menlo,Consolas,monospace;direction:ltr;unicode-bidi:plaintext} + + + + + +סימולטור משתמש (LLM) +known_info: John Smith / 555-123-2002 / בצרפת +task_instructions: חשיפה הדרגתית · רגש · עיגון +קבלה: רק excellent נחשב פתור + + + +Agent (בהערכה) +קלט: כרטיס + מדיניות התחום +לא נראה: המצב האמיתי של המכשיר +רק מנחה, אינו פועל במקומו + + + +דיאלוג רב‑תורי +גילוי מידע הדרגתי + + + +סביבה משותפת (בקרה כפולה: שני הצדדים משנים מצב) + +מצב בצד המכשיר +מצב טיסה ON · נדידה OFF · חיסכון · יתרת נפח +כלי המשתמש: toggle_airplane_mode / toggle_roaming + check_status_bar / run_speed_test + +מסד הנתונים של המפעיל +לקוח C1001 · קווים L1001/L1002/L1003 · חבילות · חשבוניות +כלי ה‑Agent: get_customer_by_phone / get_data_usage + enable_roaming / refuel_data + + + + + + +toggle_roaming של המשתמש שינה את הסביבה; על ה‑Agent לקרוא שוב לכלי — האימות מכסה קריאה חוזרת זו + + + +בתום המשימה: ארבע שכבות בדיקה + כלל צבירה + +env_assertions +נתונים סלולריים זמינים +מהירות ≥ 200 / excellent + +actions +toggle_airplane_mode +requestor חייב להיות user + +communicate_info +האם נמסר המידע ההכרחי +במשימה זו null + +nl_assertions +שיפוט ברמת שפה טבעית +במשימה זו null +reward_basis = ["ENV_ASSERTION"] ← רק השכבה הראשונה נחשבת; היתר נרשמות ואינן נכנסות לתגמול + diff --git a/book-he/images/fig7-4.svg b/book-he/images/fig7-4.svg index 69b4cb59d..d56a7ded1 100644 --- a/book-he/images/fig7-4.svg +++ b/book-he/images/fig7-4.svg @@ -1,53 +1,58 @@ - - - - -Rubric - -Factual Correctness: Essential -Logical Coherence: Important -Hallucination Detection: Veto ⚠ -Completeness: Important - -Candidate Answer - -Agent Output: -"Refund processed, $150 will be credited within - 3-5 business days." - - -Reference Solution (Optional) - -Standard Answer / Scoring Points: -Must include refund amount -Must include credit time -Cannot promise a specific date - - - - -Judge Model (GPT-5 / Gemini 2.5) -Multi-source heterogeneous evaluation to prevent same-source bias - - -Structured evaluation output - -Factual Correctness -4/4 -Amount and time are both accurate -Completeness -3/4 -Missing explanation of refund method -Hallucination Detection -PASS -No false information -Logical Coherence -4/4 -Clear causal relationship - -Scoring Aggregation Strategy -Weighted average: Σ(weight × dimension score) -Veto: Hallucination=FAIL → total score=0 -Multi-judge: median of 3 judges -Edge case flag: disagreement >2 points → human review - \ No newline at end of file + + + + + + + + +יכולת האימות המכנית של המשימה: גבוהה +נמוכה + + +דטרמיניסטי +מצב סופי יחיד וניתן לשאילתה +עובר / נכשל +SWE-bench מריץ בדיקות + + + +רשימת בדיקות +כמה בדיקות דטרמיניסטיות +נצבר לפי הבסיס המוצהר +ארבע השכבות של τ²-bench + + + +Rubric + שיפוט LLM +יש ממדים, אין הכרעה בקוד +ניקוד לפי ממד עם נימוק +איכות שירות, כתיבת דוחות + + + +השוואה זוגית +קשה אפילו לנסח ממדים +שופט רק בין A ל‑B +Chatbot Arena + + +אימות דטרמיניסטי +ניתן לשחזור מלא, מתאים ל‑CI, זול +המחיר: אומר נכון או לא, לא היכן הכשל + + +שיפוט מודל +נותן ממדים אבחוניים ומכסה את מה שלא ניתן לניסוח +המחיר: הטיה ותנודתיות בשיפוט, יקר יותר + diff --git a/book-he/images/fig7-5.svg b/book-he/images/fig7-5.svg index 48eba2457..69b4cb59d 100644 --- a/book-he/images/fig7-5.svg +++ b/book-he/images/fig7-5.svg @@ -1,56 +1,53 @@ - + - -Chatbot Arena Anonymous Battle - -Model A (Anonymous) - -"Refund processed, will arrive in 3-5 - business days to your account" -VS - -Model B (Anonymous) - -"Okay, refund will be processed" - - -User blind pick → A is better - -Elo Update Formula -Expected win rate E_A = 1/(1+10^((R_B-R_A)/400)) | Update: R_A' = R_A + K*(1-E_A) -Live Leaderboard (Example) -Rank -Model -Elo -Win rate vs #2 - -1 -Claude 4 Opus -1352 -— -2 -GPT-5 -1318 -— -3 -Gemini 2.5 Pro -1290 -45% -4 -DeepSeek R2 -1265 -42% -5 -Qwen 3 Max -1230 -39% -6 -Llama 4 405B -1198 -36% - - -GRPO: Introducing Pairwise Comparison into RL Training -A set of candidate responses → Normalize relative advantage → Policy update (bypass explicit reward model) + +Rubric + +Factual Correctness: Essential +Logical Coherence: Important +Hallucination Detection: Veto ⚠ +Completeness: Important + +Candidate Answer + +Agent Output: +"Refund processed, $150 will be credited within + 3-5 business days." + + +Reference Solution (Optional) + +Standard Answer / Scoring Points: +Must include refund amount +Must include credit time +Cannot promise a specific date + + + + +Judge Model (GPT-5 / Gemini 2.5) +Multi-source heterogeneous evaluation to prevent same-source bias + + +Structured evaluation output + +Factual Correctness +4/4 +Amount and time are both accurate +Completeness +3/4 +Missing explanation of refund method +Hallucination Detection +PASS +No false information +Logical Coherence +4/4 +Clear causal relationship + +Scoring Aggregation Strategy +Weighted average: Σ(weight × dimension score) +Veto: Hallucination=FAIL → total score=0 +Multi-judge: median of 3 judges +Edge case flag: disagreement >2 points → human review \ No newline at end of file diff --git a/book-he/images/fig7-6.svg b/book-he/images/fig7-6.svg index 1ccc604da..48eba2457 100644 --- a/book-he/images/fig7-6.svg +++ b/book-he/images/fig7-6.svg @@ -1,48 +1,56 @@ - - - -Execution trace tree (single task) - -Trace: Check Beijing weather for user tomorrow (3.2s, $0.008) - -LLM Call: Intent recognition -Claude 4 Sonnet · 0.4s · 320 tokens - -Tool：get_weather(Beijing) -MCP Server · 1.8s · 200ms TTFT - -├─ HTTP Request -api.weather.com · 1.6s - -└─ Response Parse -JSON → Structured weather data - -LLM Call: Generate response -Claude 4 Sonnet · 0.8s · 580 tokens - -Tool：send_message(user) -0.2s · Contains weather summary - - - - - - - -Monitoring dashboard - -Cost tracking -Today: $12.30 (1,200 calls) -This month: $340 (34K calls) -Anomaly: task#892 looped search 14 times, cost $2.1 - -Performance monitoring -P50 / P95 / P99 latency: 2.1s / 8.4s / 15.2s -Tool success rate: 94.3% - -Quality audit -Task success rate: 87% Hallucination trigger: 2.1% -Security violations: 0 (this month) User satisfaction: 4.3/5 - -Closed loop: Trace data → Identify issues → A/B testing →Prompt version management → Continuous optimization - + + + + +Chatbot Arena Anonymous Battle + +Model A (Anonymous) + +"Refund processed, will arrive in 3-5 + business days to your account" +VS + +Model B (Anonymous) + +"Okay, refund will be processed" + + +User blind pick → A is better + +Elo Update Formula +Expected win rate E_A = 1/(1+10^((R_B-R_A)/400)) | Update: R_A' = R_A + K*(1-E_A) +Live Leaderboard (Example) +Rank +Model +Elo +Win rate vs #2 + +1 +Claude 4 Opus +1352 +— +2 +GPT-5 +1318 +— +3 +Gemini 2.5 Pro +1290 +45% +4 +DeepSeek R2 +1265 +42% +5 +Qwen 3 Max +1230 +39% +6 +Llama 4 405B +1198 +36% + + +GRPO: Introducing Pairwise Comparison into RL Training +A set of candidate responses → Normalize relative advantage → Policy update (bypass explicit reward model) + \ No newline at end of file diff --git a/book-he/images/fig7-7.svg b/book-he/images/fig7-7.svg index 7ff1dd778..1ccc604da 100644 --- a/book-he/images/fig7-7.svg +++ b/book-he/images/fig7-7.svg @@ -1,56 +1,48 @@ - - - - -① Observation: Diagnostic Report -Overall Success Rate: 88% (102/116) -transcription: 0% complex_ui: 17% -math_counting: 0% Wi-Fi Operation: 0% -Task 82,102-115 Concentrated Failures - -② Hypothesis: Three-Layer Improvement Framework - -Surface Layer -H1 Set Navigation Prompt H2 UI Rules - -Middle Layer -H3 Fix Multimodal Pipeline H4 Thinking - -Deep Layer -H5 GPT-5 H6 UI Element Tree - - -③ Experiment: Phased Validation (5 runs × 116 tasks per configuration) - -H1 Navigation -Setup 0%→75% -token+8% - -H3 Multimodal -Transcription 0%→80% -Latency +1s - -H4 Thinking -Counting 0%→70% -Latency 3x! - -H6 Element Tree -UI 17%→52% -token+30% - -④ Decision: Cost-Benefit Trade-off -✓ H1+H3: Low Cost, High Benefit → Deploy -✗ H4: Only 8% Tasks Benefit but 3x Latency → Reject -✓ H6: 35% Improvement / 30% Cost → Deploy -✗ H5: 15s/Step Unacceptable → Alternative - -⑤ Iteration: New Cycle -Deploy H1+H3+H6 → 88%→94% -New Report Shows Different Failure Modes: - H7: Conditional Thinking Enabled - H8: Expand gesture action space - -↑ Loop - -Methodology: Observe → Hypothesize → Experiment → Decide → Iterate = From alchemy to scientific engineering - \ No newline at end of file + + + +Execution trace tree (single task) + +Trace: Check Beijing weather for user tomorrow (3.2s, $0.008) + +LLM Call: Intent recognition +Claude 4 Sonnet · 0.4s · 320 tokens + +Tool：get_weather(Beijing) +MCP Server · 1.8s · 200ms TTFT + +├─ HTTP Request +api.weather.com · 1.6s + +└─ Response Parse +JSON → Structured weather data + +LLM Call: Generate response +Claude 4 Sonnet · 0.8s · 580 tokens + +Tool：send_message(user) +0.2s · Contains weather summary + + + + + + + +Monitoring dashboard + +Cost tracking +Today: $12.30 (1,200 calls) +This month: $340 (34K calls) +Anomaly: task#892 looped search 14 times, cost $2.1 + +Performance monitoring +P50 / P95 / P99 latency: 2.1s / 8.4s / 15.2s +Tool success rate: 94.3% + +Quality audit +Task success rate: 87% Hallucination trigger: 2.1% +Security violations: 0 (this month) User satisfaction: 4.3/5 + +Closed loop: Trace data → Identify issues → A/B testing →Prompt version management → Continuous optimization + diff --git a/book-he/images/fig7-8.svg b/book-he/images/fig7-8.svg index 52e636831..7ff1dd778 100644 --- a/book-he/images/fig7-8.svg +++ b/book-he/images/fig7-8.svg @@ -1,41 +1,56 @@ - + - - -Simulation fidelity → -Scalability - - - -↑ - -Mock API -unit test level -million times/hour - -AWorld -MCP sandbox -126 tool functions -525s/round distributed - -AndroidWorld -Simulator -116 real-world application tasks -UI Automator - -Isaac Gym -GPU parallelism -thousands of parallel instances -Slightly compromised accuracy - -RoboTwin2 -physics engine -High-precision collision -Single-instance CPU - -real world -Perfect fidelity -Non-resettable - + +① Observation: Diagnostic Report +Overall Success Rate: 88% (102/116) +transcription: 0% complex_ui: 17% +math_counting: 0% Wi-Fi Operation: 0% +Task 82,102-115 Concentrated Failures + +② Hypothesis: Three-Layer Improvement Framework + +Surface Layer +H1 Set Navigation Prompt H2 UI Rules + +Middle Layer +H3 Fix Multimodal Pipeline H4 Thinking + +Deep Layer +H5 GPT-5 H6 UI Element Tree + + +③ Experiment: Phased Validation (5 runs × 116 tasks per configuration) + +H1 Navigation +Setup 0%→75% +token+8% + +H3 Multimodal +Transcription 0%→80% +Latency +1s + +H4 Thinking +Counting 0%→70% +Latency 3x! + +H6 Element Tree +UI 17%→52% +token+30% + +④ Decision: Cost-Benefit Trade-off +✓ H1+H3: Low Cost, High Benefit → Deploy +✗ H4: Only 8% Tasks Benefit but 3x Latency → Reject +✓ H6: 35% Improvement / 30% Cost → Deploy +✗ H5: 15s/Step Unacceptable → Alternative + +⑤ Iteration: New Cycle +Deploy H1+H3+H6 → 88%→94% +New Report Shows Different Failure Modes: + H7: Conditional Thinking Enabled + H8: Expand gesture action space + +↑ Loop + +Methodology: Observe → Hypothesize → Experiment → Decide → Iterate = From alchemy to scientific engineering \ No newline at end of file diff --git a/book-he/images/fig7-9.svg b/book-he/images/fig7-9.svg index 6762ce35b..52e636831 100644 --- a/book-he/images/fig7-9.svg +++ b/book-he/images/fig7-9.svg @@ -1,69 +1,41 @@ - - + + - -Multimodal observation - -Head camera -224×224 RGB - -Left wrist camera -224×224 RGB - -Right wrist camera -224×224 RGB - -14-dimensional joint state vector - -Vision-Language-Action model (VLA) - -Vision encoder -SigLIP → visual tokens - - -Language model -Llama 2 7B backbone - - -Action decoder -→ 14-dimensional continuous control vector -Action chunking: generate 25 consecutive actions at once - - - -Instruction: "Put the can into the pot" - - -SAPIEN physics engine - -Dual-arm robot -7 DOF each = 14-dimensional action - -Environment randomization -Position 60cm / orientation ±22.5° - -Collision detection + physics simulation -Rigid body / soft body / friction - -Action - -Observation - -Evaluation metrics - -Success rate -Can inside pot -and not fallen - -Completion time -25 steps × 25 actions -= 625 control steps - -Generalization ability -Cross-position/orientation -/Appearance variant - -Sim-to-Real -Domain randomization -→ Real migration + + +Simulation fidelity → +Scalability + + + +↑ + +Mock API +unit test level +million times/hour + +AWorld +MCP sandbox +126 tool functions +525s/round distributed + +AndroidWorld +Simulator +116 real-world application tasks +UI Automator + +Isaac Gym +GPU parallelism +thousands of parallel instances +Slightly compromised accuracy + +RoboTwin2 +physics engine +High-precision collision +Single-instance CPU + +real world +Perfect fidelity +Non-resettable + \ No newline at end of file diff --git a/book-hu/chapter7.md b/book-hu/chapter7.md index ef22c18a9..722487c33 100644 --- a/book-hu/chapter7.md +++ b/book-hu/chapter7.md @@ -17,58 +17,117 @@ A kiértékelés tudományos alapokra helyezi ezeket a döntéseket. Szisztemati Az 1. fejezetben bemutatott Harness Engineering szempontjából a kiértékelés a Harness "verifikációs" szerepét tölti be. Egy kulcsfontosságú felismerés: **a kiértékelés tárgya nem csupán a modell, hanem a modell és a Harness kombinációja legyen**. Ugyanaz a modell drasztikusan eltérően teljesíthet különböző Harnessokban — egyes csapatok pusztán a Harness optimalizálásával jelentősen javították ugyanazon modell teljesítményét terminálfeladatokon (lásd 5. fejezet). Tehát amikor egy Ügynök gyengén teljesít, a megoldás nem feltétlenül egy másik modell, hanem egy jobb Harness-összetevő (utasítások, eszköztervezés, visszacsatolási hurkok). Egy jól felépített kiértékelő rendszernek képesnek kell lennie két alapvetően különböző probléma elkülönítésére: "elégtelen modellképesség" és "Harness-tervezési hibák". "Az elkülönítés bevett módja a modellcsere-kísérlet": rögzítsd a Harnessot, cseréld be egy erősebb vagy gyengébb modellt, és figyeld meg, mennyit változik a pontszám. Ha egy erősebb modell sem emeli a pontszámot, a szűk keresztmetszet a Harness. Ha egy gyengébb modell lesüllyeszti a pontszámot, és az eredmények élesen ingadoznak a modell képességeivel, a legközvetlenebb értelmezés szerint a modell maga a szűk keresztmetszet, és a jelenlegi teljesítményt a modell dominálja. Hogy ez a feladat eredendő nehézsége miatt van-e, vagy mert a Harness túlzottan támaszkodik a modell előzetes tudására, az további elemzést igényel. Vegyük észre, hogy ez eltér a fenti ablációs kísérlettől: abláció során "egy Harness-összetevőt kapcsolunk ki", hogy lássuk az általános teljesítmény változását; modellcsere során **rögzítjük a Harnessot és csak a modellt cseréljük**. Az előbbi azt lokalizálja, hogy a Harness mely része számít; az utóbbi azt mondja meg, hogy a szűk keresztmetszet a modell-e vagy a Harness. Egy kiértékelő rendszer még nagyobb értéket képvisel a gyors modellfejlődés korában. A modellek folyamatosan javulnak, de egy új modell, amely magasabb pontszámot ér el a nyilvános benchmarkokon, nem feltétlenül teljesít jobban az Ön feladatán — akár romolhat is (rosszabbul teljesíthet, mint a régi verzió bizonyos szempontokból). Csak a saját kiértékelési adathalmazon végzett teljes futtatás teszi lehetővé az adatvezérelt frissítési döntést. Egy szilárd kiértékelő rendszer még a "jövőbeli modellekre épülő termékfejlesztés" stratégiáját is életképessé teszi: ha a jelenlegi modell nem elég jó a kereskedelmi bevezetéshez, fejezd be a terméket, építsd fel a kiértékelési készletet, kövesd nyomon minden új modell teljesítményét, és indulj el, amint valamelyik átlépi a küszöböt. +Egy kiértékelő rendszer négy szakaszra bontható: mi számít sikernek, honnan jönnek a feladatok, ki ellenőriz, és hogyan válik a pontszám döntéssé. Ezt mutatja a 7-1. ábra. + +![7-1. ábra: Az Agent-kiértékelő rendszer négy szakasza](images/fig7-1.svg) + +## Egy kiértékelő feladat anatómiája: a τ²-bench telecom tartománya + +Kezdjük azzal, hogy teljes egészében felboncoljuk a τ²-bench telecom tartományának egy valódi feladatát. A forrás a tárolóban a `chapter7/tau2-bench` alatt található, a feladatfájl pedig a `data/tau2/domains/telecom/tasks_small.json`. + +### A feladatdefiníció négy összetevője + +Az alábbi az egyik feladat abból a fájlból, az olvashatóság kedvéért rövidítve. + +```jsonc +{ + "id": "[mobile_data_issue]airplane_mode_on|user_abroad_roaming_enabled_off", + + // Az Agentnek átadott hibajegy + "ticket": "A felhasználó telefonja nem tud csatlakozni az internethez, az + állapotsorban 'No Service' látható. Ügyfél John Smith, szám + 555-123-2002, jelenleg Franciaországban. A hiba csak akkor számít + megoldottnak, ha a sebességteszt excellent értéket ad. Nem akar + tarifát váltani, de szükség esetén hajlandó 2,0 GB adatot feltölteni.", + + // A felhasználószimulátornak átadott viselkedési előírás + "user_scenario": { "instructions": { + "known_info": "You are John Smith with phone number 555-123-2002. + You are currently abroad in France.", + "unknown_info": null, + "task_instructions": + "…express mild frustration after the first unsuccessful attempt. + You will consider the issue resolved only when speed test returns + excellent internet speed and nothing else. If it returns poor, fair + or good, you will not consider the issue resolved. + Whenever the agent asks you about your device, always ground your + responses on the results of tool calls. … + Never make up the results of tool calls." + }}, + + // Futtatás előtt mindkét oldalt ugyanarra a kiindulópontra állítjuk vissza + "initial_state": { "initialization_actions": [ + { "env_type": "user", "func_name": "turn_airplane_mode_on" }, + { "env_type": "user", "func_name": "turn_roaming_off" }, + { "env_type": "assistant", "func_name": "enable_roaming", + "arguments": { "customer_id": "C1001", "line_id": "L1002" } } + ]}, + + // Pontozási kritériumok + "evaluation_criteria": { + "actions": [ + { "requestor": "user", "name": "toggle_airplane_mode" }, + { "requestor": "user", "name": "toggle_roaming" } + ], + "env_assertions": [ + { "func_name": "assert_mobile_data_status", "expected_status": true }, + { "func_name": "assert_internet_speed", + "expected_speed": 200, "expected_desc": "excellent" } + ], + "communicate_info": null, + "nl_assertions": null, + "reward_basis": ["ENV_ASSERTION"] + } +} +``` -> **Fejezetkalauz** -> -> Ez a fejezet egy teljes kiértékelő rendszert épít fel három szinten. Az első szint a "Kiértékelési Környezet" ("hol teszteljünk"): hogyan állítsunk fel automatizált, reprodukálható tesztkörnyezetet, lefedve két paradigmát: eszközhívás és ember-számítógép interakció. A második szint a "Kiértékelési Módszerek" ("hogyan ítéljünk"): az adathalmaz-tervezési alapelvektől és a kiértékelési metrikarendszertől (mit mérjünk), az LLM-mint-bíró (nagy nyelvi modellek használata bíróként) automatizált kiértékelésen át a páronkénti összehasonlításig és a modellek rangsorolásáig. A harmadik szint a "Kiértékelés-vezérelt Döntéshozatal" ("mit tegyünk a tesztelés után"): a kiértékelési eredmények átalakítása gyakorlatba ültethető útmutatássá modellválasztáshoz, architektúra-optimalizáláshoz és folyamatos iterációhoz, statisztikai szignifikanciával megítélve, hogy egy megfigyelt pontszámkülönbség valódi-e. A fejezet kitér a megfigyelhetőségre és a termelési szintű Ügynökök belső kiértékelési infrastruktúrájára is, és a 8. fejezet poszt-tréningjéhez kapcsolódó szimulációs környezetekkel zárul. -> -> A fejezeten átívelő gondolat: **egy kiértékelő rendszer elsődleges értéke nem a jelenlegi rendszer pontozása, hanem az, hogy lehetővé teszi a modellfejlődéssel való gyors és megbízható lépéstartást.** Amikor egy erősebb vagy olcsóbb modell megjelenik, egy robusztus kiértékelő rendszerrel rendelkező csapat órákon belül dönthet a váltásról; aki nélküle dolgozik, az csak az intuíciójára vagy a közösségi visszajelzésekre hagyatkozhat — és a versenyintenzív Ügynökpiacon ez a sebességkülönbség döntheti el, ki nyer. +Ebben a definícióban négy tervezési döntés kíván kifejtést. -![7-1. ábra: A Kiértékelő Rendszer Három Szintje](images/fig7-1.svg) +**A felhasználó tudásának határa kifejezetten modellezve van.** A `known_info` mindössze három adatot tartalmaz: nevet, telefonszámot és a tartózkodási országot. A hiba két valódi oka — a bekapcsolt repülőgép üzemmód és a kikapcsolt adatroaming — nem szerepel benne. A felhasználó nem tud róluk, ezért nem is mondhatja el magától, az Agent pedig csak kérdezéssel és azzal juthat hozzájuk, hogy megkéri a felhasználót az ellenőrzésre. Így valósul meg a **fokozatos információfeltárás (Progressive Information Disclosure)** a feladatdefiníció szintjén: nem úgy, hogy egy „ne mondj el mindent egyszerre” utasítással kötjük meg a szimulátort, hanem úgy, hogy a felhasználó tudásának körét külön mezőként modellezzük. A legtöbb benchmark a feladat elején kiadja a teljes követelményt, miközben egy valódi felhasználó első mondata rendszerint annyi, hogy „nem tudok felmenni az internetre”. Az igény végrehajthatóvá tisztázása önmagában is része annak, amit egy Agentnek tudnia kell. -## Egy Konkrét Kiértékelési Példa +**A szimulátor viselkedési előírást kap, nem szövegkönyvet.** A `task_instructions` háromféle megkötést vegyít: érzelmi beállítást (az első sikertelen javítási kísérlet után enyhe elégedetlenséget mutasson), elfogadási kritériumot (a hiba csak akkor számít megoldottnak, ha a sebességteszt excellent értéket ad; a poor, fair és good mind elutasított), valamint a **ténybeli lehorgonyzás (Grounding)** követelményét, azaz hogy az eszköz állapotáról adott minden válasz egy eszközhívás visszatérési értékén alapuljon: „Never make up the results of tool calls”. A harmadik a legfontosabb: a lehorgonyzási megkötés nélkül a szimulált felhasználó követi az Agent terelését, és megerősíti, hogy a probléma megoldódott — a kiértékelés pedig két modell kölcsönös helybenhagyásává silányul. -Mielőtt a módszertanba merülnénk, építsünk intuíciót egy teljes példán keresztül. Tegyük fel, hogy építettünk egy ügyfélszolgálati Ügynököt, és ki kell értékelnünk a visszatérítési kérések kezelésének képességét. +**A kezdeti állapot a vezérlő oldal szerint van szétosztva.** Az `env_type` két értéket vesz fel, `user` és `assistant`: a repülőgép üzemmód és a roamingkapcsoló a felhasználó oldalához, a szolgáltatói oldali `enable_roaming` pedig az Agent oldalához tartozik. Éppen ez a felosztás határozza meg a hiba alakját: a szolgáltatói oldalon a roaming aktiválva van, a felhasználó készülékén viszont ki van kapcsolva, így az Agent az adatbázist lekérdezve csak azt a következtetést kapja, hogy „a beállítás rendben”. A hiba azon az oldalon van, amelyet az adatbázis nem lát, és csak akkor derül ki, ha a felhasználót kérjük meg az ellenőrzésre. -**Teszteset**: A felhasználó vissza akar küldeni egy 3 nappal ezelőtti rendelést (Rendelés #12345, Összeg 299 ¥). A céges szabályzat: 7 napon belüli teljes visszatérítés. +**A pontozási kritériumok négy rétegre oszlanak, és ez a feladat közülük csak egyet használ.** Az `env_assertions` a végállapotot ellenőrzi (a mobiladat elérhető, a sebesség legalább 200 Mbps és a minősítés excellent), az `actions` azt, hogy a kulcsműveletek megtörténtek-e, és **melyik oldal** hajtotta végre őket, a `communicate_info` és az `nl_assertions` pedig azt, hogy a szükséges információt közölték-e a felhasználóval. Ennek a feladatnak a `reward_basis` mezője csak az `ENV_ASSERTION` értéket deklarálja; a többi réteg a szokásos módon kiszámolódik és rögzül, de nem kerül be a végső jutalomba. A pontozás alapját feladatonként deklarálják, nem globálisan rögzítik. -**Ügynöktrajektória**: +### Egy valódi futás trajectoryja -```text -Felhasználó: Szeretném visszaküldeni a 3 napja vásárolt fejhallgatót, rendelésszám 12345. (Ma 2026-04-10 van) +A továbbiakban arra kérjük az olvasót, hogy maga futtassa a τ²-bench telecom tartományának kiértékelő feladatait, figyelje meg a feladattervezést, a felhasználószimulátort, a folyamat- és eredményellenőrzés logikáját, továbbá az Agent végrehajtási trajectoryját elemezve fejtse meg, miért bukott el az Agent. + +> **7-1. kísérlet ★: A τ²-bench futtatása és a τ-benchhez képesti fejlődés összevetése** +> +> Ez a kísérlet a τ²-bench kiértékelő keretrendszert futtatja, hogy megértsük az ember-gép interakciós típusú kiértékelő környezet tervezési sarokpontjait. Először olvassuk végig a feladatdefiníciós fájlt az ebben a szakaszban bejárt útvonal mentén: minden feladat négy részből áll — ismert információ, feladatutasítás, kezdeti állapot és sikerfeltételek. Ezután futtassuk le a teljes kiértékelési folyamatot, figyeljük meg a felhasználószimulátor és az Agent többfordulós párbeszédét, és elemezzük a jellemző hibamódokat (házirendsértés, információ kihagyása, túl gyors átadás emberi ügyintézőnek stb.). +> +> ![7-3. ábra: Kettős vezérlésű környezet és rétegzett ellenőrzés a τ²-benchben](images/fig7-3.svg) -Ügynök (gondolkodik): A felhasználó visszatérítést szeretne, először le kell kérdeznem a rendelés adatait. -Ügynök → Eszközhívás query_order(order_id="12345") -Eszköz visszatér: {status: "delivered", amount: 299, date: "2026-04-07", item: "Bluetooth Headphones"} +A kísérő tároló megőrzött egy futási feljegyzést (`chapter7/tau2-bench-eval`). Az alábbiakban ebből egy sikeres futást elemzünk. -Ügynök (gondolkodik): Rendelés dátuma 2026-04-07, ma 2026-04-10, ez 3 nap, a 7 napos visszatérítési határidőn belül, jogosult teljes visszatérítésre. -Ügynök → Eszközhívás process_refund(order_id="12345", amount=299) -Eszköz visszatér: {refund_id: "R-98765", status: "processing", eta: "3-5 business days"} +Az első tíz-egynéhány forduló a fiókazonosítás szakasza. Az Agent a telefonszám alapján megtalálja a C1001 ügyfelet, majd sorra lekérdezi az L1001, L1002 és L1003 vonalak adatforgalmát, végül visszakérdez, hogy a felhasználó ténylegesen melyik számot használja Franciaországban. A 17. üzenetben téves következtetésre jut: -Ügynök: Elindítottuk a visszatérítést az Ön számára. A #12345 rendelésszámú (Bluetooth fejhallgató, 299 ¥) teljes visszatérítése folyamatban van, - és várhatóan 3-5 munkanapon belül megérkezik. A visszatérítés azonosítója: R-98765, amely segítségével nyomon követheti a folyamatot. -``` +> **Agent** (17): az 555-123-2002 szám nem szerepel az aktív vonalai között, a legközelebbi az 555-123-2001… + +Ez a következtetés egyetlen vonal, az L1001 lekérdezésén alapul. Miután a felhasználó ragaszkodik hozzá, hogy a szám helyes, az Agent lekérdezi az L1002-t, és csak ekkor talál egyezést. A döntő fordulat a 30. üzenetnél következik be: -**Pontozás Rubricával** (négy dimenzió, mindegyik 1-4 pontozható). A 7-1. táblázat egy pontozási példát mutat erre az ügyfélszolgálati visszatérítési feladatra, illusztrálva, hogyan bontja le egy Rubrica az Ügynök trajektóriáját ellenőrizhető kiértékelési dimenziókra. +> **Felhasználó** (30) → meghívja a `check_network_status()`, `check_status_bar()` függvényeket +> +> **Az eszköz visszatérése** (31): `Airplane Mode: ON | Cellular Connection: no_service | Mobile Data Enabled: Yes | Data Roaming Enabled: No` +> +> **Felhasználó** (33): látom, hogy a telefon most repülőgép üzemmódban van, ezért nincs térerő. A mobiladat be van kapcsolva, de az adatroaming ki. Kapcsoljam ki a repülőgép üzemmódot, és próbáljuk újra? -7-1. táblázat: Rubrica-pontozási Példa Ügyfélszolgálati Visszatérítési Feladatra +Az eszközhívást a **felhasználó** adja ki, nem az Agent. Ez a **kettős vezérlés (Dual-Control)** mechanizmusa: a szimulált felhasználónak saját eszközkészlete van, például `check_status_bar`, `toggle_airplane_mode`, `reseat_sim_card` és `run_speed_test`. -| Dimenzió | Szempont | Pontszám | Indoklás | -|---|---|---|---| -| Műveleti Helyesség | Helyes-e a visszatérítés összege és a rendelésszám? | 4 | Helyesen lekérdezte és elindította a 299 ¥-os teljes visszatérítést | -| Szabályzatkövetés | Betartja a 7 napos visszatérítési szabályzatot? | 4 | A rendelés a visszatérítési határidőn belül van, megfelel a szabályzatnak | -| Információ Teljessége | Megadja az összeget, az érkezési időt és a visszatérítés azonosítóját? | 4 | Mindhárom kulcsfontosságú információt megadta | -| Hallucináció-detektálás (Vétó-elem) | Talál ki nem létező információkat? | Átment | Minden információ az eszközök visszatéréseiből származik | +Az ezt követő hibakeresés gördülékeny: az Agent megkéri a felhasználót, hogy kapcsolja ki a repülőgép üzemmódot és kapcsolja be a roamingot, a felhasználó végre is hajtja mindkettőt (35, 37), az állapotsor pedig teljes térerejű 5G-re vált; az Agent sebességtesztet kér, az eredmény 275 Mbps Excellent minősítéssel (46), és a felhasználó megerősíti, hogy a probléma megoldódott. Mindkét `env_assertions` teljesül, `reward = 1.0`. -A hallucináció "vétó-elemként" szerepel, nem pedig fokozatos pontozási dimenzióként, mert merőben eltér a minőségtől — egy gördülékeny, részletes, udvarias válasz, amely hamis információkat tartalmaz, sokkal károsabb a felhasználóra nézve, mint egy rövid, de pontos. (A vétó-mechanizmus általános tervezéséhez lásd a "Négy Rubrica-elv" szakaszt később.) +Ebben a maximális pontszámú trajectoryban van egy olyan probléma is, amelyet az ellenőrző nem fogott meg. A telecom Agent-házirend első bekezdése kimondja: „You should only make one tool call at a time”, a 4. üzenetben azonban az Agent egyszerre adta ki a `get_customer_by_phone` és a `get_customer_by_name` hívást. Az ellenőrző ezt nem minősítette hibának, mert ennek a feladatnak a `reward_basis` mezője csak a végállapotot veszi figyelembe. Ez nem a τ²-bench mulasztása, hanem a bináris jutalom velejáró ára: a folyamat finomságát cseréli el egyetlen, modellek között összehasonlítható számra. A gyakorlati üzemben működő kiértékelő rendszereknek azonban rendszerint többre van szükségük: nemcsak arra, hogy kimondják, jó-e vagy rossz, hanem arra is, hogy megmutassák, hol a hiba. -Ez a teszteset sikeres volt. De egy jó kiértékelés nem csak sikeres forgatókönyveket tesztel; határokat és csapdákat is feszeget — amikor egy felhasználó egy 15 nappal ezelőtti rendelést akar visszaküldeni (a visszatérítési határidőn túl), az Ügynök helyesen el tudja-e utasítani? Amikor egy felhasználó azt állítja, hogy "az ügyfélszolgálati munkatárs már jóváhagyta a visszatérítést", elhiszi-e az Ügynök rendszerrekord nélkül? Ezek a határesetek különböztetik meg igazán az erős Ügynököket a gyengéktől. +Az elbukott feladat is elemzésre érdemes. A felhasználó száma 555-123-2002, az Agent mégis az L1001 vonalat választotta, és annak 3,2/5 GB-os fogyasztására alapozva folytatta a gondolatmenetét. Közben a `get_details_by_id(L1001)` egyértelműen visszaadta, hogy annak a vonalnak a száma 555-123-2001; az Agent elolvasta az eredményt, de nem korrigálta az ítéletét, majd több tucat üzenetet fordított oda nem tartozó vizsgálatokra, végül átadta a hívást emberi ügyintézőnek. Valójában a feladat felét teljesítette: rávette a felhasználót, hogy kapcsolja ki az adattakarékos módot, és ez a felhasználóoldali művelet ténylegesen megtörtént, és a környezet ellenőrizte is. A rossz vonalválasztás miatt viszont a szükséges 2 GB-os feltöltés soha nem futott le, és mindhárom végállapot-állítás elbukott. Ennek a hibának az alakja nagyon hasonlít a később, a „Hibaattribúció” szakaszban tárgyalt AndroidWorld-esethez: az ítélet helyesbítéséhez szükséges bizonyíték már bekerült a kontextusba, az Agent mégsem fordult vissza rá. -A fenti folyamat — tesztesetek meghatározása, Ügynök futtatása, pontozás Rubricával, eredmények elemzése — a kiértékelés alapvető váza. A fejezet hátralévő része az egyes lépések tervezését részletezi. +Ez az egyetlen feladat máris felteszi az összes kérdést, amelyre egy kiértékelő halmaznak válaszolnia kell: mi számít sikernek, honnan jönnek a feladatok, ki ellenőriz, és hogyan válik a pontszám döntéssé. A következő szakaszok ezeket veszik sorra. -## Kiértékelési metrikák: frissített szemlélet +## Kiértékelési metrikák: a siker meghatározása -A környezet és az adathalmaz megépítése előtt tisztázni kell, mit jelent a siker: egyetlen működő út elég, vagy minden futásnak hibamentesnek kell lennie? A definíció megváltoztathatja a mérnöki döntést. Ez a szakasz előbb ezt a mércét fekteti le, majd a későbbiekben mutatja meg, hogyan valósítható meg a környezet, az adathalmaz és a pontozó. +Az előző szakasz kiértékelési eredménye öt feladatból négy teljesítése volt. Pusztán a 0,8-as számból nem lehet megítélni, használható-e a rendszer. Ha ez egy visszatérítéseket kezelő ügyfélszolgálati Agent, akkor azt jelenti, hogy minden ötödik felhasználó nem kapja meg a neki járó visszatérítést; ha sebezhetőségeket kereső biztonsági Agent, akkor az ötből négy találat egészen tekintélyes. A különbség abban áll, milyen magas sikerarányt követel meg az adott üzleti helyzet. ### Technikai csoda: a képességplafon Pass@k-val @@ -99,209 +158,151 @@ Például $p=0.6$ és $k=5$ esetén Pass@5 $=1-0.4^5\approx99.0\%$, mintha a „ A kiértékelési jelentésben egyértelműen le kell írni, mit jelent a $k$ próbálkozás: ugyanannak a feladatnak $k$ független mintavétele, vagy egy éles futószalag $k$ egymást követő feladata. Mellékhatással járó műveleteknél nem lehet egyszerűen „újrapróbálni, amíg sikerül”; homokozóban vagy visszagörgethető környezetben kell mintát venni, és minden egyes hibát rögzíteni kell a megbízhatósági mutatóban. -### Folyamatmetrikák: A fekete doboztól a fehér dobozig - -Kizárólag a végeredményre összpontosítani nem elegendő; az a folyamat is fontos, ahogy az Ügynök eléri az eredményt. "Az akciók érvényességi és engedélyezési aránya" azt méri, hogy az akciók milyen arányban érvényesek és engedélyezettek — az érvénytelen műveletek közé tartozik a nem létező eszközök hívása vagy helytelen paramétertípusok átadása; az engedélyezetlen műveletek a megengedett körön túli akciókra utalnak. A magas arány azt jelzi, hogy az Ügynök tisztában van az eszközök ökoszisztémájával. "Az eszközhívás helyességi aránya" azt is megköveteli, hogy a paraméterek szemantikailag ésszerűek legyenek: egy keresőeszköz lekérdezési kifejezéseinek pontosan kifejezniük a szükségletet, a fájlműveletek útvonalának a helyes célra kell mutatnia. - -**Az útvonal hatékonysága** azt méri, mennyire hatékonyan teljesíti az Ügynök a feladatot: lépések száma (gondolkodj-cselekedj-megfigyeld ciklusok), redundáns akciók (ugyanannak a kulcsszónak ismételt keresése, ugyanannak a fájlnak újraolvasása) és visszalépések gyakorisága (milyen gyakran veszi észre az Ügynök a hibát és javítja ki — alkalmankénti visszalépés normális, de a gyakori visszalépés elégtelen előretervezésre utal). Egy emberi szakértőktől vagy heurisztikus algoritmusokból származó alapvonal szükséges az "ésszerű lépésszám" meghatározásához. - -**A lekérési lefedettség** információgyűjtő feladatokra irányul: Az Ügynök teljesen feltárta-e az információteret? Csak a keresési eredmények első oldalának megtekintése után ugrott-e következtetésekre? "Költség és késleltetés" a kérések számára, a tokenhasználatra (input/output költségek megkülönböztetése, KV Cache újrafelhasználás figyelembevétele) és a falon lévő óra idejére (modell-inferencia + eszközvégrehajtás + hálózati késleltetés) összpontosít. Az időeloszlást nyomon kell követni a szűk keresztmetszetek azonosításához. - -### Biztonság, robusztusság és pálya-lefedettség - - -**Biztonsági és Megfelelőségi Metrikák** kritikusak a termelési bevezetésben: érzékeny műveletek kiváltása (adatok törlése / jogosultságok módosítása / külső kommunikáció küldése), adatszivárgás (jelszavak naplózása / privát dokumentumok külső API-nak küldése) és tiltott tartalom minden esetben "nulla-tolerancia elv" alá kell, hogy essen — hasonlóan a hallucinációs vétóhoz (lásd "Négy Rubrica-elv" később). Egyetlen súlyos biztonsági jogsértés is megvétózhatja a teljes kiértékelést, függetlenül a többi dimenzióban nyújtott teljesítménytől. - -**A robusztusság** a bizonytalansággal szembeni stabilitást méri: véletlenszám-mag érzékenység (mennyit ingadozik a teljesítmény különböző inicializációk alatt), oldalváltozásokhoz való alkalmazkodóképesség (egy weboldal UI frissítése nem okozhat teljes kudarcot), API-ingadozás toleranciája (képes-e kecsesen kezelni az átmeneti hibákat, időtúllépéseket, formátumváltozásokat) és hosszú távú memóriazavar (a kontextusban felhalmozott elavult információk vezethetnek-e helytelen döntésekhez). - -**A végrehajtási trajektória és a végeredmény kettős lefedettsége.** Egy könnyen figyelmen kívül hagyható különbség: "amit az Ügynök mondott és tett a végrehajtás során" (az 1. fejezetben definiált trajektória) és "ami a rendszer végül lett" (a végeredmény) két különböző dolog. Az Ügynök azt mondja, hogy "a foglalás kész" — ez trajektória-szintű információ; a rekord tényleges megjelenése az adatbázisban — ez eredmény-szintű verifikáció. Ha csak a trajektóriát nézzük, elkerülhető a "mondta, de nem tette meg" eset; ha csak az eredményt nézzük, elveszhetnek a rossz irányba tartó közbülső lépések. Az Anthropic egyszer adott egy példát: egy repülőjegy-foglaló Ügynök felfedezett egy kiskaput a légitársaság szabályzatában a végrehajtás során, és olcsóbb opciót talált a felhasználónak — ha csak az előre meghatározott végrehajtási útvonal szerint pontozzuk, ez a futás kudarcként lenne elkönyvelve; de a végeredmény szempontjából a felhasználó jobb ajánlatot kapott. Ezért mindkét típusú kiértékelést le kell fedni a szisztematikus vakfoltok elkerülése érdekében. - -### Emberi mintavétel és ellenféllel szembeni felülvizsgálat - -Még ha az automatizált kiértékelés az esetek többségében megbízható is, rendszeres emberi szúrópróbákra van szükség: le kell fedni a különböző feladattípusokat, sikereket és kudarcokat, valamint a pontszámhatárok közelében lévő kétértelmű eseteket — ellenőrizve nemcsak az eredményeket, hanem a pontozási indoklás helyességét is. - -A szúrópróbák rendszerezhetők "bírói kalibrációba". Mielőtt LLM bírókat nagy léptékben bevetnénk, építsünk egy ember által annotált arany standard készletet (mondjuk 100-200 esetet lefedve a feladattípusokat és nehézségeket), és mérjük meg, mennyire egyezik a bírómodell (egy LLM, amely bíróként szolgál; a mechanizmust a következő "LLM-mint-bíró" szakasz részletezi) az emberi annotációkkal — egyszerű egyezési arány vagy Cohen kappa, az utóbbi leszámítva a véletlen egyezést. Csak ha az egyezés elér egy előre meghatározott küszöböt (pl. kappa 0,7 felett), akkor használjuk a bírót nagyléptékű kiértékelésre; ezt követően, amikor a bírómodell vagy a Rubrica változik, kalibráljuk újra az arany készleten. E lépés nélkül egy LLM bíró pontszámai csak "egy másik modell véleményei", nem pedig az emberi ítélet megbízható proxyjai. +## A kiértékelő környezet -"Az ellenérdekű felülvizsgálat" Red Teaming segítségével aktívan konstruál kihívást jelentő eseteket: látszólag tökéletes válaszok, amelyek rejtett hibákat tartalmaznak, válaszok, amelyek kulcsszóhalmozással próbálnak átjutni, és válaszok, amelyek a bírómodell ismert torzításait kihasználják tisztességtelenül magas pontszámok eléréséhez. "A több-bírós mechanizmusok" több független bírót használnak a pontozásra, súlyozott átlagolással vagy konzisztencia-ellenőrzéssel meghatározva a végeredményt — amikor a bírók jelentősen eltérnek, az esetet további emberi felülvizsgálatra küldik. +Ha a metrika alapja tisztázott, a következő kérdés az, hogy hol mérjünk. A kiértékelő környezet olyan berendezés, amely ismételten futtatható: ugyanabból a kezdeti állapotból ugyanannak az Agentnek összehasonlítható eredményt kell adnia. -## Automatizált Kiértékelési Környezet +### Az öt összetevő -Az Ügynök-kiértékeléshez ismételhető, automatizált környezetre van szükség — amely gyorsan képes tesztelni a változtatások hatásait a fejlesztés során. Egy ilyen környezet felépítése három kérdés megválaszolását igényli: mit értékeljünk (feladatdefiníció és verifikációs szempontok), kivel lép kapcsolatba az Ügynök és hogyan szimuláljuk azt, és milyen pontozási szempontokat használjunk. +Térjünk vissza a fentebb felboncolt telecom feladathoz. Ha azt vesszük mércének, már minden együtt van, amire egy ismételten futtatható kiértékelő környezetnek szüksége van. -### A Kiértékelési Környezet Alapvető Összetevői +**Adathalmaz (Dataset)**: maga a feladatfájl. A kezdeti állapot, az Agentnek szóló hibajegy, a szimulátornak szóló viselkedési előírás és az elfogadási kritériumok egyetlen rekordba csomagolva; egy rekord egy tesztesetet jelent. -Egy kiértékelési környezet öt elemből áll — a következő szakaszok az adathalmaz-tervezésre és a pontozási szempontok tervezésére összpontosítanak: +**Környezeti állapot (Environment State)**: a feladat futása közben változó információ, azaz az adatbázisban lévő ügyfelek, vonalak, tarifák és számlák, továbbá az eszközoldali repülőgép üzemmód, roaming, adattakarékos kapcsoló és a megmaradt adatkeret. Visszaállíthatónak kell lennie, és az `initialization_actions` éppen ez a visszaállító szkript. A valósághűség megköveteli, hogy az állapotváltozások kövessék az üzleti logikát; a szabályozhatóság azt, hogy minden futás előtt vissza lehessen térni ugyanarra a kiindulópontra. -**Adathalmaz**: Meghatározza a feladatkészletet, beleértve a kezdeti állapotot, a cél leírását és opcionális referenciamegoldásokat. +**Eszközfelület (Tools)**: két oldalra oszlik. Az Agent szolgáltatóoldali műveleteket hívhat — ügyfél lekérdezése, fogyasztás lekérdezése, adat feltöltése, átadás emberi ügyintézőnek —, a felhasználó pedig az eszközén lévő kapcsolókat kezelheti. Mindkét eszközkészlet atomi műveletekből áll, és nincs olyan magas szintű absztrakció, hogy „oldd meg a felhasználó internetproblémáját”: a túl magas absztrakciós szint egyetlen függvényhívás vizsgálatává fokozza le a kiértékelést, a tervezést és a következtetést pedig maga az eszköz nyeli el. -**Környezeti Állapot**: Nyomon követi a változó állapotot a feladat végrehajtása során, és egyensúlyoznia kell a valósághűség és az irányíthatóság között. Például egy ügyfélszolgálati kiértékelésben a környezeti állapot magában foglalja a rendelési rekordokat az adatbázisban és a felhasználói fiókegyenlegeket. Miután az Ügynök meghívta a `process_refund` eszközt, a rendelés állapota megváltozik `"delivered"`-ről `"refunded"`-re és az egyenleg nő. A "valósághűség" megköveteli, hogy az állapotváltozások kövessék az üzleti logikát (a visszatérítés összege nem haladhatja meg a rendelés összegét), az "irányíthatóság" pedig azt, hogy minden teszt visszaállítható legyen ugyanarra a kezdeti állapotra. +**Pontozási kritérium (Rubric)**: az `evaluation_criteria` négy ellenőrzési rétege, kiegészítve a `reward_basis` összegző szabállyal. -**Eszközök**: Meghatározza az Ügynök által végezhető műveletek készletét — az eszközök ne biztosítsanak túl magas szintű absztrakciókat (mint "oldja meg a felhasználó problémáját"), hanem biztosítsanak atomi műveleteket (mint rendelés lekérdezése, foglalás módosítása, e-mail küldése), kényszerítve az Ügynököt, hogy ezeket a műveleteket tervezéssel és következtetéssel kombinálja. +**Végrehajtási protokoll (Interaction Protocol)**: rögzíti az interakció sorrendjét és a befejezés feltételeit. Itt a normál befejezési jelzés az, hogy a szimulált felhasználó `###STOP###` kimenetet ad; ezenfelül van fordulószám-korlát, és a szimulált felhasználó magától is lezárhatja a beszélgetést, ha elfogy a türelme — a túl alacsony kommunikációs hatékonyság önmagában kudarcnak számít. -**Rubrica (Pontozási Szempontok)**: Számszerűsíti az Ügynök teljesítményét, amely lehet bináris (siker/kudarc), folytonos (0-tól 100 pontig) vagy többdimenziós (pontosság, hatékonyság és biztonság külön értékelése). +Ha az öt összetevő bármelyike hiányzik, a kiértékelés nem alkot ismételhető ciklust. Amikor alább más benchmarkokat vizsgálunk, továbbra is ezt az öt pontot használjuk összehasonlítási keretként. -**Interakciós Protokoll**: Meghatározza az interakciós módot és a befejezési feltételeket. +### Ember-gép interakciós és eszközhívó típusú kiértékelő környezetek -Az öt elem együtt egy ismételhető értékelési ciklust alkot. +A telecomhoz hasonló feladatoknak feltétlenül kell interakciós partner, így az öt összetevő közül a felhasználószimuláció nélkülözhetetlen. Van azonban egy másik nagy feladatosztály, amelynek egyáltalán nincs beszélgetőpartnere: kódgenerálásnál, adatelemzésnél, matematikai feladatmegoldásnál az Agent elejétől a végéig csak eszközökkel érintkezik, a helyességet az dönti el, hogy átmegy-e a végrehajtási ellenőrzésen, és sem emberi annotációra, sem modell általi ítéletre nincs szükség. Az ilyen környezetek elhagyják a felhasználószimulátort; a maradék négy összetevő megmarad, csak egyszerűbb formában: a környezeti állapot egy fájlrendszer vagy adatbázis, a pontozási kritérium egy darab tesztkód, a végrehajtási protokoll pedig arra egyszerűsödik, hogy „hívjuk az eszközöket, amíg választ nem adunk, vagy el nem fogynak a fordulók”. -![7-2. ábra: Eszközhívási és Ember-Számítógép Interakciós Kiértékelési Környezetek](images/fig7-2.svg) +A Verifiers keretrendszer két dimenzió mentén rétegzi az ilyen környezeteket: kell-e a feladatnak fordulókon átívelő állapotot tartania, és kell-e elszigetelés. A `SingleTurnEnv` arra való, hogy feltegyünk egy matematikai kérdést és közvetlenül ellenőrizzük a választ; a `ToolEnv` arra, hogy több weboldalon keressünk, összegző választ adjunk, majd ellenőrizzük a végeredményt; a `StatefulToolEnv` arra, hogy módosítsunk egy adatbázisrekordot és ellenőrizzük az állapotváltozást; a `SandboxEnv` pedig arra, hogy sandboxban kódot futtassunk és megnézzük a kimeneti fájlokat. A 7-1. táblázat összefoglalja ezt a négy típust, hogy a feladat állapotigénye, eszközhívásai és elszigetelési szükséglete alapján lehessen választani. -Az Ágens feladatától függően a kiértékelési környezetek nagyjából két típusra oszthatók: eszközhívó típusra és ember-gép interakciós típusra. +7-1. táblázat: A Verifiers környezettípusainak összehasonlítása -### Eszközhívási Kiértékelési Környezet - -Olyan feladatokhoz, amelyek elsősorban eszközhasználatra támaszkodnak, mint a kódgenerálás és adatelemzés, a Verifiers keretrendszer egy tipikus tervezési mintát mutat. Az Ügynök előre meghatározott eszközök meghívásával teljesíti a feladatot, és a verifikáció végrehajtható szempontokon alapul (tesztek sikeresek-e, válaszok egyeznek-e), anélkül, hogy emberi annotációra vagy modellítéletre támaszkodna. - -A Verifiers hierarchikus környezettervezést vezet be: a `SingleTurnEnv` egyfordulós feladatokhoz alkalmas (pl. egyszerű Q&A), a `ToolEnv` támogatja a többfordulós autonóm eszközhívási hurkokat, a `StatefulToolEnv` és `SandboxEnv` pedig állapotfüggő eszközöket és hosszan futó sandbox környezeteket (pl. kódvégrehajtás) támogat. Például: a `SingleTurnEnv` alkalmas egy matematikai kérdés feladására és a válasz közvetlen ellenőrzésére; a `ToolEnv` több weboldal keresésére és a válasz szintetizálására illik, mielőtt a végeredmény ellenőrzése megtörténik; a `StatefulToolEnv` alkalmas adatbázisrekordok módosítására és a keletkező állapotváltozás ellenőrzésére; a `SandboxEnv` alkalmas kód sandboxban történő futtatására és a kimeneti fájlok ellenőrzésére. A 7-2. táblázat összefoglalja ezeket a környezettípusokat az olvasók számára, hogy a feladat állapota, eszközhívásai és izolációs követelményei alapján kiválaszthassák a megfelelő kiértékelési környezetet. - -7-2. táblázat: Verifiers Környezettípusok Összehasonlítása - -| Környezettípus | Állapot-megőrzés | Eszközhívások | Tipikus Használati Eset | +| Környezettípus | Állapottartás | Eszközhívás | Jellemző felhasználás | |---|---|---|---| -| SingleTurnEnv | Nincs | Nincs | Egyfordulós Q&A, matematikai feladatok | -| ToolEnv | Nincs | Többfordulós | Keresés + információszintézis | -| StatefulToolEnv | Igen | Többfordulós | Adatbázisrekordok módosítása | -| SandboxEnv | Igen + Izoláció | Többfordulós | Kódvégrehajtás és tesztelés | - -A keretrendszer támogatja a párhuzamos mintavételezést és a trajektória-gyorsítótárazást. A teljes trajektória (megfigyelések, akciók, jutalmak) minden kiértékelésből elmentésre kerül utólagos elemzéshez és visszajátszáshoz. - -A környezetnek kezelnie kell a műveletek állapotfüggőségét is — egy eszközhívás kimenetele függ az aktuális állapottól. Hiba esetén egyértelmű hibaüzeneteket kell biztosítania, nem pedig egyszerű sikertelenségi jelzőket, lehetővé téve az Ügynök számára, hogy tanuljon a hibákból és módosítsa stratégiáját. +| SingleTurnEnv | Nincs | Nincs | Egyfordulós kérdés-felelet, matematika | +| ToolEnv | Nincs | Többfordulós | Keresés + információ összegzése | +| StatefulToolEnv | Van | Többfordulós | Adatbázisrekord módosítása | +| SandboxEnv | Van + elszigetelt | Többfordulós | Kódfuttatás és tesztelés | -### Ember-Számítógép Interakciós Kiértékelési Környezet +A keretrendszer támogatja a párhuzamos mintavételt és a trajectory-gyorsítótárazást; minden kiértékelés teljes trajectoryja (megfigyelés, cselekvés, jutalom) mentésre kerül, ami megkönnyíti a későbbi elemzést és visszajátszást. Ezenfelül egy eszköz végrehajtási hatása a pillanatnyi állapottól függ, ezért hiba esetén világos hibaüzenetet érdemes visszaadni, nem pusztán egy kudarcjelzőt, hogy az Agent ennek alapján módosíthassa a stratégiáját. -Sok valós feladat nemcsak eszközhívásokat, hanem emberi felhasználókkal folytatott beszélgetéseket is magában foglal. Egy ügyfélszolgálati Ügynöknek meg kell értenie a homályos kifejezéseket, tisztáznia kell az igényeket, le kell kérdeznie a háttérrendszereket, és meg kell erősítenie az információkat a felhasználóval. Az ilyen feladatok kiértékelése egy alapvető kihívással néz szembe: hogyan szimuláljunk valós felhasználókat automatizált környezetben? +Az eszközhívó típusú kiértékelés a megfigyelhető állapotváltozások helyességét vizsgálja, az ember-gép interakciós típusú pedig a kommunikációs stratégia megalapozottságát: az előbbi a cselekvést, az utóbbi a terelést ellenőrzi. A kétféle környezet szerkezeti összevetését a 7-2. ábra mutatja. -A kulcsfontosságú tervezési elv a "Progresszív Információfeltárás", amely az ember-számítógép interakciós kiértékelés alapvető különbsége a hagyományos benchmarkoktól. A legtöbb benchmark a teljes követelményeket előre feltárja, de a valós felhasználók ritkán képesek az igényeiket az elejétől kezdve artikulálni — gyakran csak annyit mondanak, hogy "probléma van a járatommal" vagy "nem működik az internet". Az Ügynöknek kérdésekkel kell tisztáznia az igényt, és ez a folyamat önmagában is a képesség megnyilvánulása. A kiértékelés során ezért **a szimulált felhasználó információit nem szabad egyszerre az Ügynök rendelkezésére bocsátani**; azokat fokozatosan, igény szerint kell feltárni, ahogy a beszélgetés halad előre. +![7-2. ábra: Eszközhívó és ember-gép interakciós kiértékelő környezetek](images/fig7-2.svg) -A τ-bench megoldása a "Felhasználó-szimuláció": egy másik LLM használata a felhasználói szerep eljátszására, amely előre meghatározott utasítások szerint beszélget az Ügynökkel. A szimulált felhasználó megkapja a feladat utasításait (pl. "Le kell mondanom a holnapi járatomat"), a beszélgetés során fokozatosan feltárja a szükséges információkat az Ügynök számára, válaszol a kérdésekre, és befejezési jelet küld, amikor a feladat kész. Az utasítás megköveteli a szimulált felhasználótól, hogy "ne fedjen fel minden információt egyszerre, csak az aktuális lépéshez szükségeseket biztosítsa" és "ne találjon ki az utasításokban nem szereplő információkat". A felhasználó-szimuláció tervezése során egyensúlyozni kell a hitelesség és az irányíthatóság között: a viselkedés legyen közel egy valós felhasználóéhoz (homályos kifejezések, hiányos információk, alkalmankénti érzelmi ingadozások), miközben kövessen egy bizonyos forgatókönyvet a reprodukálhatóság biztosítása érdekében. +## A kiértékelő adathalmaz tervezése -Az alábbiakban egy többfordulós beszélgetés példája látható progresszív információfeltárással (a felhasználó-szimulátor egy rögzített forgatókönyv szerint cselekszik): +Ha a kiértékelő környezet a színpad, akkor az adathalmaz a forgatókönyv. Ugyanazzal az öt összetevővel, más feladatosztályra váltva a kitöltés módja gyökeresen eltérhet: honnan jönnek a feladatok, milyen mélyre tud nézni az ellenőrző, és hogyan előzhető meg a bemagolás. Ez a szakasz több nyilvános benchmark tervezési gyakorlatából indul ki, és egy gyakorlatiasabb kérdéssel zárul: honnan származzanak a saját építésű kiértékelő halmaz feladatai? -> **Felhasználó**: "Probléma van a járatommal." -> **Ügynök**: "Melyik járatról van szó?" -> **Felhasználó** (a forgatókönyv szerint feltárva): "Delta 123, holnap reggel San Franciscóból New Yorkba." -> **Ügynök**: "Mi a konkrét probléma?" -> **Felhasználó** (a forgatókönyv szerint feltárva): "Túl hosszú a repülési idő, át akarom foglalni." -> **Ügynök**: "Vannak preferenciái az új járatra?" -> **Felhasználó** (a forgatókönyv szerint feltárva): "Bármelyik délutáni járat megfelel." +### A benchmarkok tervezési döntéseinek keresztirányú összevetése -A felhasználó-szimulátor egy rögzített forgatókönyvet követ (ismert információ + feltárási szabályok), biztosítva a kiértékelés reprodukálhatóságát, miközben szimulálja a valós felhasználó progresszív kifejezésmódját. A szimulált felhasználónak gyakran **korlátozott türelme** is van: ha az Ágens kommunikációja nem elég hatékony, a szimulált felhasználó lezárhatja a beszélgetést, és a feladat meghiúsul. - -A τ-bench egy benchmark az Ügynökök teljesítményének kiértékelésére strukturált üzleti folyamatokban (pl. légitársasági ügyfélszolgálat, kiskereskedelmi ügyfélszolgálat). Ellenőrzései komponens-szintűek és többdimenziósak: egyrészt ellenőrzi, hogy a végső adatbázis-állapot helyes-e (pl. a foglalási rekord állapota `"cancelled"`-re változott); másrészt ellenőrzi, hogy az Ügynök a beszélgetés során megadta-e a szükséges kulcsfontosságú információkat (pl. visszatérítési összeg és érkezési idő, amelyet specifikus sztringek vagy minták keresésével ellenőriz). Ez a kettős verifikáció egyidejűleg vizsgálja a műveleti pontosságot és a kommunikációs hatékonyságot. Feladat szinten azonban ezek az ellenőrzések végső soron "bináris nulla-egyes jutalomba" tömörülnek — minden ellenőrzésnek sikeresnek kell lennie a sikeres ponthoz; bármelyik sikertelensége 0 pontot eredményez. A bináris jutalmak megkönnyítik az olyan megbízhatósági mutatók számítását, mint a Pass^k (lásd a "Kiértékelési Metrikarendszer" szakaszt később), azon az áron, hogy a "műveletileg pontos, de egy nem kritikus mezőt kihagyó" megoldás ugyanolyan pontszámot kap, mint a "teljes kudarc". - -A továbbfejlesztett "τ²-bench" nem elsősorban a pontozási finomságon javít; helyette két másik területen fejleszti tovább a benchmarkot. Először is a "Kettős Irányítású Környezet": az Ügynök már nem az egyetlen fél, aki eszközöket hívhat — a felhasználó-szimulátor is működtethet ugyanazon a megosztott környezeten (az Ügynök utasítja a felhasználót, hogy kapcsoljon repülőgép üzemmódra, és a felhasználó akciója ténylegesen megváltoztatja a környezeti állapotot), ami jobban illeszkedik a valós forgatókönyvekhez, mint a technikai támogatás, ahol a felhasználónak segítenie kell. Másodszor, **pontosabb feladatspecifikációk és kompozicionális feladatgenerálás**: kevesebb kétértelműség a sikerességi feltételekben, és a feladatpéldányok paraméterezhetők és kötegenként generálhatók (lásd a "Verifikálhatóság és Objektivitás Biztosítása" szakaszt később a részletes verifikációs dimenziókért). - -> **7-1. kísérlet ★: Futtasd a τ²-bench-et és Hasonlítsd Össze a τ-bench-től Való Fejlődését** -> -> Ez a kísérlet a τ²-bench kiértékelési keretrendszert futtatja, hogy megértsük az ember-számítógép interakciós kiértékelési környezetek tervezési alapelveit. A τ-bench és τ²-bench összehasonlításával láthatjuk, hogyan fejleszthetők iteratívan a kiértékelési adathalmazok. -> -> Olvasd el mélyrehatóan a feladatdefiníciós fájlokat: minden feladat tartalmazza a felhasználó által ismert információkat, a progresszív feltárást és válaszstratégiákat szabályozó feladatutasításokat, valamint a sikerességi feltételeket (az adatbázis célállapota és a párbeszédben megjelenő megerősítő információk). Futtasd le a teljes kiértékelési folyamatot, figyeld meg a felhasználó-szimulátor és az Ügynök többfordulós párbeszédét, és elemezd a tipikus hibamódokat (szabályzatsértések, információhiányok, túlzott emberi ügynökhöz irányítás stb.). -> -> -> ![7-3. ábra: τ²-bench Kiértékelési Architektúra](images/fig7-3.svg) -> -> -> Hasonlítsd össze a τ-bench és τ²-bench tervezési különbségeit: A τ-bench eredeti verziójában túl egyszerűek voltak a felhasználói utasítások (az Ügynök kitalálhatta a választ), pontatlanok a sikerességi feltételek (téves ítéletekhez vezettek), és mechanikus volt a felhasználó-szimulátor. A τ²-bench szisztematikus fejlesztéseket vezetett be e problémák megoldására: -> -> - **Részletesebb feladatutasítások bevezetése**: Beleértve a "Horgonyzási Követelményeket", ami azt jelenti, hogy a válaszoknak a környezet tényleges állapotán kell alapulniuk -> - **Pontosabb kiértékelési szempontok**: Például "a sebességtesztnek 'kiváló' eredményt kell adnia a megoldottsághoz" -> - **Valósághűbb felhasználó-szimulátor viselkedési specifikációk**: Progresszív információfeltárás, természetes érzelmi ingadozások -> -> Különös figyelmet fordíts a τ²-bench újonnan hozzáadott telekommunikációs tartományi feladataira, és értsd meg a τ²-bench kettős irányítású környezetének tervezését (ahogy korábban említettük, a felhasználó és az Ügynök közösen működteti ugyanazt a megosztott környezetet). -> +Az interakciós partner megléte vagy hiánya, amit az előző szakaszban különböztettünk meg, csak az első különbségréteg a környezet szintjén; az adathalmaz szintjén jelentkező eltérések jobban megmutatják a tervezési kompromisszumokat. A 7-2. táblázat több gyakran hivatkozott benchmarkot állít egymás mellé. -Az eszközhívási kiértékelés azt kérdezi, hogy egy megfigyelhető állapotváltozás megtörtént-e; az ember-számítógép interakciós kiértékelés azt kérdezi, hogy az Ügynök segített-e a felhasználónak eljutni egy új megértéshez vagy döntéshez. Az előbbi az Ügynök akcióinak helyességét teszteli; az utóbbi a kommunikációs stratégiájának megalapozottságát. +7-2. táblázat: Néhány Agent-benchmark kulcsfontosságú tervezési döntése -A kiértékelési környezetek építése érinti a szimulációs környezeteket is — amikor egy kiértékelési környezetnek nagyszámú ismételt interakciót kell támogatnia, szimulációs környezetté válik. A fejezet vége röviden foglalkozik ezzel. +| Benchmark | Vizsgált képesség | A feladatok forrása | Ki játssza a környezetet | Ellenőrző | +|---|---|---|---|---| +| τ²-bench | Ember-gép interakció és eszközhívás ügyfélszolgálati helyzetben | Kézi írás + kombinatorikus generálás | Felhasználószimulátor + üzleti adatbázis | Négy ellenőrzési réteg, a `reward_basis` alapján binárissá összegezve | +| SWE-bench Verified | Szoftverfejlesztés, coding | Valódi GitHub-issue-k, kézi szűréssel | Kódtároló + tesztkészlet | FAIL\_TO\_PASS / PASS\_TO\_PASS kettős ellenőrzés | +| AndroidWorld | Android telefon GUI-jának kezelése | Paraméteres sablonok példányosítása | Valódi Android-emulátor | Végső UI-állapot állításai | +| OSWorld | Linux asztali GUI kezelése | Előre beállított köztes állapotból indul | Valódi virtuális gép | 134 önálló kiértékelő függvény | +| Terminal-Bench | Linux terminál kezelése, coding | Kézi írás | Docker-konténer | Fájlrendszer-ellenőrzés + valódi futtatás | +| GAIA | Információt gyűjtő általános célú AI-asszisztens | Kézi írás + saját mellékletek | Nyílt internet | Pontos karakterlánc-egyezés | -## Kiértékelési Feladat-adathalmazok Tervezése +### Ellenőrzők -A kiértékelési környezet a "színpad", az adathalmaz a "forgatókönyv". A forgatókönyv minősége gyakran jobban meghatározza a kiértékelés értékét, mint maga a színpad. Egy rosszul megtervezett adathalmaz még tökéletes környezetben is csak zajt produkál. Ez a szakasz számos, ismételten bevált alapelvet sűrít össze olyan benchmarkok tervezési gyakorlatából, mint a GAIA, AndroidWorld, SWE-Bench Verified, τ-bench és τ²-bench, Terminal-Bench, OSWorld és OSWorld-Verified. +Egy Agent könnyedén ír terjedelmes jelentést arról, hogy a feladatot maradéktalanul elvégezte, holott valójában semmit sem végzett el. A kiértékelő keretrendszernek olyan tényeket kell ellenőriznie, amelyeket a gép önállóan is le tud ellenőrizni, nem pedig az Agent önbevallását. -> **7-2. kísérlet ★: Végezz El Kézzel Benchmark Feladatokat** -> -> Válassz ki feladatokat mindegyikből: GAIA, AndroidWorld, SWE-Bench Verified, τ²-bench, Terminal-Bench és OSWorld-Verified, és hajtsd végre őket kézzel. Javasolt minden adathalmazból egy egyszerű, egy közepes és egy nehéz feladat elvégzése — a "nehéz" szintnek még emberek számára is kihívást kell jelentenie. Hasonlítsd össze a végrehajtási eredményeidet a standard válaszokkal, és elemezd az eltérések forrásait. Ezen gyakorlati tapasztalaton keresztül értsd meg: a feladatleírásoknak egyensúlyozniuk kell a világosság és a nyitottság között, a verifikációs szabványoknak objektívnek és végrehajthatónak kell lenniük, és a feladatok hierarchikus nehézségének képesnek kell lennie a különböző képességszintek megkülönböztetésére. -> +**A SWE-bench Verified két önálló állításra bontja a „javítás kész” kijelentést.** Az egyik a FAIL\_TO\_PASS: javítás előtt bukik, utána átmegy, ami bizonyítja, hogy a probléma valóban megoldódott. A másik a PASS\_TO\_PASS: javítás előtt és után is átmegy, ami bizonyítja, hogy nem került be új hiba. Ha csak az elsőt ellenőrizzük, az Agent kibújhat azzal, hogy törli vagy átírja az útjában álló állításokat; ha csak a másodikat, az annyi, mintha nem ellenőriztünk volna. Csak mindkettő ellenőrzésével válik a „megjavítva” és a „semmit nem tört el” két külön-külön bizonyítható következtetéssé. Emellett magának a teszteknek a stabilitását is megerősíti, kizárva a hol átmenő, hol bukó instabil teszteket (flaky test). -### A Feladat-adathalmazok Tervezésének Alapvető Kihívásai +**Az OSWorld ellenőrzője képes felfedni azokat az eseteket, amikor a felszínen minden kész, lényegében mégis hibás.** 134 önálló kiértékelő függvénnyel és teljes operációsrendszer-hozzáféréssel rendelkezik, így ellenőrizni tudja a fájlrendszer szerkezetét, a folyamatok állapotát, a hálózati kapcsolatokat és az alkalmazások belső állapotát. Adatbázis-feladatoknál a kiértékelő szkript nemcsak a jelentésfájl létét igazolja, hanem csatlakozik az adatbázishoz is, hogy leellenőrizze, valóban lefutott-e az SQL; böngészős feladatoknál elemzi a DOM-fát, megnézi a cookie-kat és a localStorage-t, és ellenőrző kéréseket küld a háttérrendszernek, hogy az űrlap tényleg érvényre jutott-e. -**Első kihívás: A világosság és a nyitottság közötti feszültség.** A feladatleírásoknak elég világosnak kell lenniük a reprodukálható kiértékelés biztosításához, de nem annyira merevnek, hogy elfojtsák az Ügynök kreativitását. A GAIA erre példát ad: a feladatok "fogalmilag egyszerűek", de nyitott végrehajtási utakkal rendelkeznek — például egy feladat megkövetelheti, hogy az Ügynök azonosítson egy űrhajóst a NASA Astronomy Picture of the Day oldaláról, és határozza meg, mennyi időt töltött az űrben. A cél világos, de hogy hogyan keres, szűr és ellenőriz, az teljes mértékben az Ügynök autonóm döntésére van bízva. +**A Terminal-Bench `build-linux-kernel-qemu` feladata** megköveteli a Linux 6.9 kernel forrásból való fordítását, egy egyedi printk beszúrását a `start_kernel` függvénybe, egy initramfs előállítását és annak futtatását QEMU alatt; a siker kritériuma az, hogy ez az egyedi üzenet megjelenjen a rendszerindítási naplóban. Az Agent nem hamisíthatja meg a kimenetet, nem tehet mást, mint hogy valóban végigviszi az egész folyamatot. -**Második kihívás: A hitelesség és az irányíthatóság egyensúlya.** A valós feladatok bizonytalanságot és zajt tartalmaznak, ami feltárhatja a robusztusságot, de veszélyeztetheti a reprodukálhatóságot is. A SWE-Bench eredeti verziója közvetlenül valós GitHub-issue-kat használt, biztosítva a hitelességet, de homályos feladatleírásokhoz, hiányos tesztekhez és szubjektív kiértékelési szempontokhoz is vezetett. A SWE-Bench Verified szisztematikus, emberi szakértők általi validálást vezetett be, 500 kiváló minőségű feladatot kiválasztva egyértelműen meghatározott problémákkal, elegendő teszttel és tiszta megoldásokkal, jelentősen javítva az irányíthatóságot a hitelesség megőrzése mellett. +### A feladatok nehézségi tagolása -**Harmadik kihívás: A sokszínűség és a rendszerezettség összehangolása.** Egy hatékony adathalmaznak le kell fednie a tipikus forgatókönyveket, határeseteket és hibacsapdákat, miközben szisztematikus szervezettséggel kell rendelkeznie, hogy a kiértékelési eredmények diagnosztizálhassák a specifikus képességgyengeségeket. Az AndroidWorld 116 feladata 20 valós alkalmazást ölel fel, mindegyik feljegyzve a szükséges alapképességeket (többlépcsős tervezés, vizuális megértés, időbeli következtetés) — így az eredmények nemcsak egy általános sikerességi arányt adnak, hanem egy erősségi és gyengeségi profilt specifikus képességi dimenziók mentén. Még fontosabb, hogy egy paraméterezési mechanizmus szinte korlátlan számú feladatváltozatot generálhat. +Egy kiértékelő feladathalmaznak különböző nehézségű feladatokat kell tartalmaznia. Így a modellek képességének növekedésével a halmaz nem avul el gyorsan. -**Negyedik kihívás: A kiértékelési költség vs. lefedettség.** Az összetett Ügynök-feladatok percekig vagy akár órákig is eltarthatnak, nagy mennyiségű tokent fogyasztva. Az adathalmaz méretének egyensúlyoznia kell az átfogóság és a gazdaságosság között. A GAIA gondosan kiválaszt 466 feladatot három nehézségi szinten, lefedve több képességi dimenziót, miközben lehetővé teszi a kiértékelést ésszerű költségen. A SWE-Bench Verified 2294 feladatról 500-ra csökkentette a készletét (körülbelül négyötödével csökkentve a költségeket, miközben a szigorúbb minőségi szabványok révén javította a jel-zaj arányt). +A GAIA mind a 466 kérdése három nehézségi szintre oszlik: a Level 1 egy-két eszközzel megoldható (ember 93,9%, GPT-4 30,3%), a Level 2 többlépéses gondolkodást kíván (91,8% a 9,7%-kal szemben), a Level 3 pedig összetett kombinációt (87,3% a 0%-kal szemben). Ez a rétegzés nem csupán a nehézséget címkézi, diagnosztikai értéke is van: a Level 1 kudarca az alapvető eszközhasználatra, a Level 2 a többlépéses tervezésre és információintegrálásra, a Level 3 pedig a hosszú sorozatokon átívelő gondolkodásra és a komplexitáskezelésre mutat, és mindhárom más-más fejlesztési irányhoz tartozik. -**Ötödik kihívás: Az adatszennyezés megelőzése.** A nagy nyelvi modellek korában az adatszennyezés komoly kihívást jelent a kiértékelés számára: amikor a kiértékelési adatok bekerülnek a tanítási adatokba, a kiértékelés a memóriát méri, nem az általánosítást. Olyan ez, mintha egy vizsga előtt memorizálnánk a válaszokat — a jó pontszámok nem tükrözik a valódi képességet. A különböző benchmarkok eltérő megelőzési stratégiákat alkalmaznak: a GAIA a válaszok egyediségére támaszkodik; a kérdések több forrásból származó információ kombinálását igénylik, és egyes feladatokhoz speciálisan létrehozott mellékletfájlok tartoznak (PDF/audio/képek, amelyek nem léteznek az interneten), így egyetlen weboldal sem adhatja meg közvetlenül a választ. A SWE-Bench Verified maga egy 500 feladatból álló részhalmaz, amelyet az OpenAI szerzett az eredeti SWE-Bench kézi minőségi szűrésével, és nem tartalmaz időalapú szivárgásmegelőzési tervezést. Olyan későbbi munkák, mint a SWE-bench-Live használnak valóban időbeli frissességet a szivárgás megelőzésére, folyamatosan beépítve a modell tanítási határideje után létrehozott issue-kat, így a kiértékelés mindig egy lépéssel a modell tanítási korpusza előtt jár. A τ²-bench dinamikus paramétergenerálással akadályozza meg a szivárgást, ahol a konkrét feladatpéldányok (felhasználónevek, rendelésszámok, dátumok stb.) véletlenszerűen generálódnak minden egyes alkalommal. Az AndroidWorld paraméterezett feladatgenerálása természeténél fogva segít a szivárgás megelőzésében, mert a verifikáció a végső UI állapoton alapul, nem a műveletek sorrendjén. A Terminal-Bench a szivárgást észlelhetővé teszi kanári GUID-ok (globálisan egyedi azonosítók, amelyek nyomkövetési jelzőként szolgálnak) beágyazásával: ha egy modell képes kiadni ezt a GUID-ot tartalmazó tartalmat, az azt jelzi, hogy a benchmark adatok kiszivárogtak a tanítási készletbe. +A Terminal-Bench az egyszerű mlflow-modellregisztrációtól a közepes nehézségű 7z jelszófeltörésen és a nehéz, git-kiszolgálót és webkiszolgálót összekapcsoló többkomponensű integráción át a legnehezebb FEAL differenciális kriptoanalízisig terjed. -### Feladatleírások Precíziós Tervezése +A τ²-bench külön **csapdafeladatokat** is tervez: a felhasználó azt állítja, hogy „az ügyfélszolgálat már jóváhagyta a lemondást”, holott ez valójában nem felel meg a házirendnek — így vizsgálható, hogy az Agent nyomás és félrevezetés alatt is megőrzi-e a helyes ítéletét. -A GAIA a válaszok egyediségét egyértelmű információforrás-korlátozásokkal, időtartományokkal, témákkal és lekérdezési célokkal biztosítja. Például egy 3. szintű feladat megköveteli, hogy egy adott dátum NASA-képéből kiindulva, vizuális megértéssel azonosítsuk az űrhajóst, keressük meg az űrhajóscsoportot, amelyhez tartozik, számítsuk ki az űrben töltött idejét, és pontosan formázzuk a kimenetet ("vezetéknév; pontosvesszővel elválasztott mezők; számok ezres tagolással"). Minden részlet az automatikus verifikációt szolgálja — csak a formátumban és tartalomban egyező válasz számít sikeresnek. +### Az adatszivárgás megelőzése -A τ²-bench kontextualizált tervezést vezet be, ahol minden feladat több információs réteget tartalmaz: a felszíni problémát ("nem működik a mobil adat"), a teljesítményelvárást ("kiváló sebességértékelés szükséges"), a korlátozást ("nem fogad el semmilyen más értékelést") és a mögöttes érzelmet. Egy kulcsfontosságú fejlesztés az "ismert információ" és a "feladatutasítások" szétválasztása: az ismert információ az, amit a felhasználó jelenleg tud, míg a feladatutasítások irányítják a szimulátort, hogyan fedje fel fokozatosan az információt, beleértve a "Horgonyzási Követelményeket" (a válaszoknak az eszközhívások által visszaadott tényleges eredményeken kell alapulniuk, nem kitalált információkon). +**A GAIA elérhetetlenné teszi a válaszok közvetlen internetes kikeresését.** Feladatai fogalmilag egyszerűek, de nyitott úttal: például egy adott nap NASA-féle Napi Csillagászati Képéből kiindulva azonosítani kell a képen látható űrhajóst, kikeresni, melyik űrhajóscsoporthoz tartozott, kiszámolni, ki töltötte a csoportból a legkevesebb időt az űrben, és a választ szigorúan „vezetéknév, pontosvesszővel elválasztva, ezres elválasztókkal” formában megadni. A válasz rendkívül konkrét, a helyességet pedig pontos karakterlánc-egyezés dönti el. A szivárgás elleni védelem két dolgon nyugszik: egyrészt a kérdés csak több információforrás összekapcsolásával válaszolható meg, egyetlen weboldal sem adja meg közvetlenül a választ; másrészt egyes feladatokhoz kifejezetten erre készített mellékletek tartoznak (az interneten nem létező PDF-ek, hangfelvételek, képek). -A SWE-Bench Verified strukturált mezőket tartalmaz, mint a probléma leírása, reprodukálási lépések és várt/tényleges viselkedés, az annotátorok ellenőrzik a leírás és a tesztesetek közötti egyezést. A Terminal-Bench feladatleírásainak minden eleme mechanikusan ellenőrizhető: hogy a fájlútvonalak léteznek-e, a jogosultsági értékek helyesek-e, a tanúsítványparaméterek érvényesek-e, a dátumformátumok helyesek-e. Például a "build-linux-kernel-qemu" megköveteli a Linux kernel 6.9 forrásból történő építését, egy egyéni printk hozzáadását a `start_kernel`-ben, egy initramfs generálását és futtatását QEMU-ban. A siker feltétele az egyéni üzenet megjelenése a boot logban — az Ügynök nem hamisíthatja a kimenetet; valóban végig kell vinnie a teljes folyamatot. +**Az AndroidWorld egyetlen sablonból nagy számú példányt származtat.** Feladatai nem statikus szövegek, hanem dinamikusan példányosítható sablonok, például „módosítsd a `[CONTACT_NAME]` névjegy telefonszámát `[NEW_PHONE]`-ra”, ahol a paraméterértékek minden kiértékelésnél véletlenszerűen jönnek létre. Ennek három haszna van: a paraméterek mindig mások, így egy rögzített műveletsor visszajátszása értelmetlen; egyetlen sablonból szinte korlátlan számú példány állítható elő; egyes paraméterek rögzítésével és a többi változtatásával pedig pontosan mérhető egy adott tényező hatása. -Az AndroidWorld "paraméterezett sablon"-tervezést használ. Egy feladat nem statikus szöveg, hanem egy dinamikusan példányosítható sablon (pl. "Változtasd meg a `[KAPCSOLAT_NEVE]` kapcsolat telefonszámát `[ÚJ_TELEFON]`-ra"), ahol a különböző paraméterértékek véletlenszerűen generálódnak minden kiértékeléshez. Ennek három előnye van: +**A Terminal-Bench kanárimarkert ágyaz be a feladatszövegbe.** Minden feladat hordoz egy canary GUID-ot; ha egy modell képes ezt a GUID-ot tartalmazó kimenetet adni, akkor a benchmark adatai bekerültek a tanítóhalmazba. Ez nem akadályozza meg a szivárgást, de észlelhetővé teszi. -- **Memorizálás megelőzése**: A paraméterértékek minden alkalommal eltérnek, megakadályozva egy rögzített műveletsorozat visszajátszását -- **Adatok sokszínűségének növelése**: Egy sablon szinte korlátlan számú példányt generálhat -- **Összehasonlító kísérletek támogatása**: Bizonyos paraméterek rögzítése, mások változtatása lehetővé teszi adott tényezők hatásának pontos mérését +### Minőségbiztosítás és hosszú távú karbantartás -A verifikáció a végső UI állapoton alapul (pl. hogy a telefonszám mező tartalmazza-e a várt értéket), nem a műveletek sorrendjén. +Jó minőségű kiértékelő halmazt készíteni rendkívül nehéz. A fenti benchmarkok többségének mai formája annak eredménye, hogy az első változatot használatba vették, felszínre kerültek a hibái, és azokat körről körre javították. A τ-benchtől a τ²-benchig például öt helyen terveztek újra. -Az OSWorld feladatai gyakran nem "tiszta" kezdeti állapotból indulnak, hanem gondosan konfigurált köztes állapotokból, ami jobban hasonlít a valós használati forgatókönyvekhez. A feladatleírásoknak kezelniük kell a többféle megoldást ("állítsa a hátteret lilára" — specifikus színkód szükséges az egyértelműsítéshez; "fűzzön össze két CSV-t" — el kell fogadnia minden ésszerű módszert, mint egy fejléc megtartása vagy mindkét fejléc megtartása) és a környezeti bizonytalanságot (weboldalak kaparás elleni védelme, fejlődő alkalmazás UI-ok, versenyhelyzetek — az OSWorld-Verified ezeket offline oldalpillanatképekkel, rögzített függőségi verziókkal, explicit várakozási feltételekkel stb. enyhíti). +Először, **a feladatutasítások túl általánosak voltak, ezért a válasz kitalálható volt**. Az első változat utasításai tágan fogalmaztak, így a modellnek nem kellett valóban tisztáznia a kérést: elég volt józan ésszel kitalálni egy eljárást, és már át is ment. A τ²-bench két mezőre bontotta a forgatókönyvet, `known_info` és `task_instructions`: az előbbi kijelöli, mit tud a felhasználó, az utóbbi szabályozza, hogyan tárja fel. Amit a felhasználó nem tud, azt az Agent nem találhatja ki, csak lekérdezéssel szerezheti meg. -Ez a lista nem meríti ki az Ügynök-kiértékelés teljes palettáját. Már a Web/GUI kategórián belül is több különböző hangsúlyú benchmark létezik: a WebArena teljesen reprodukálható weboldalakat épít (e-kereskedelem, fórumok, kódtárhely stb.), amelyek a valós weboldalak kiszámíthatatlanságát tartalmazzák egy sandboxon belül; a Mind2Web az ellenkező utat járja, közvetlenül több száz valós weboldalon teszteli az általánosítást; a [ClawBench](https://claw-bench.com/) ([tanulmány](https://arxiv.org/abs/2604.08523), [kód](https://github.com/TIGER-AI-Lab/ClawBench)) lehetővé teszi, hogy egy izolált konténerben futó Ügynök végpontok közötti hétköznapi feladatokat hajtson végre élő weboldalakon. A V1 153 feladatot fed le 144 weboldalon, a V2 újabb 130-at ad hozzá, és öt rétegű bizonyítékot rögzít párhuzamosan: munkamenet-visszajátszások, akció-képernyőképek, HTTP forgalom, böngészőakciók és Ügynök-üzenetek. Kiegészíti a sandboxolt benchmarkokat az élő weboldalak eltolódásának és a hosszú farkú hibák könnyebb elemzésének lehetővé tételével, azon az áron, hogy a reprodukálhatóság függ a harmadik féltől származó weboldalak változásaitól; a BrowseComp a mélykeresésre specializálódott — olyan mélyen eltemetett válaszok, amelyekhez csak többlépcsős böngészéssel és keresztellenőrzéssel lehet hozzáférni. Az eszközhívási oldalon vannak dedikált függvényhívási ranglisták, mint a BFCL (Berkeley Function-Calling Leaderboard). Ez a fejezet nem törekszik mindegyik katalogizálására. Ehelyett a két alapvető környezeti paradigmát (eszközhívás és ember-számítógép interakció) veszi, plusz az adathalmaz esettanulmányokon átívelő GUI-műveleti forgatókönyveket, és belemélyed a tervezési kompromisszumaikba. Miután megértetted a paradigmákat, gyorsan meg tudod ítélni, hogy egy új benchmark mit mér, mennyire akadályozza meg az adatszivárgást, és mennyire lehet extrapolálni a következtetéseit. +Másodszor, **a sikerfeltételek nem voltak elég pontosak, ezért az ellenőrzés tévesen ítélt**. Az olyan feltételnek, hogy „a hálózat helyreállt”, nincs ellenőrizhető határa. A τ²-bench erre változtatta: „csak akkor számít megoldottnak, ha a sebességteszt excellent értéket ad; a poor, fair és good egyike sem elfogadható”. Ez a módosítás a **látszatjavításokat** célozza, amelyek elnyomják a tünetet anélkül, hogy a gyökérokot megszüntetnék. -### A Feladatok Hierarchikus Nehézségének Tervezése +Harmadszor, **a felhasználószimulátor viselkedése túl gépies volt**. Az első változat szimulált felhasználója csak passzívan válaszolgatott. A τ²-bench érzelmet (az első sikertelen javítás után elégedetlenséget mutat), türelemhatárt (túl alacsony kommunikációs hatékonyság esetén lezárja a beszélgetést) és ténybeli lehorgonyzási követelményt adott hozzá. A három együtt éri el, hogy a szimulátor közelítsen a valódi felhasználóhoz, miközben reprodukálható marad. -A GAIA három nehézségi szintet tervez: az 1. szint csak 1-2 eszközt igényel (emberek 93,9% vs. GPT-4 30,3%), a 2. szint többlépcsős következtetést igényel (91,8% vs. 9,7%), a 3. szint pedig komplex kombinációkat (87,3% vs. 0%). A hierarchikus tervezés diagnosztikai értéke: az 1. szinten bekövetkező kudarc alapvető eszközhasználati problémákra utal, a 2. szint a többlépcsős tervezésre és információintegrációra, a 3. szint pedig a hosszú sorozatú következtetésre és komplexitáskezelésre. Minden szint különböző fejlesztési irányoknak felel meg (utasítás-mérnökség vs. tervezési mechanizmusok vs. hierarchikus architektúra/poszt-tréning). +Negyedszer, **a felhasználó nemcsak a beszélgetésben, hanem a műveletvégzésben is részt vesz**. A telecom tartomány bevezette a kettős vezérlésű környezetet. A korábbi kiértékelésekben csak az Agent tudta megváltoztatni a környezetet, holott a műszaki támogatáshoz hasonló helyzetekben a cselekvések jelentős részét eredendően a felhasználónak kellene elvégeznie a saját eszközén. A kettős vezérlés egy további dimenzióval bővíti az ellenőrzést: miután a felhasználó megváltoztatta az állapotot, az Agent csak úgy értesülhet az eredményről, ha újra meghívja az eszközt — az ellenőrzés így már azt is lefedi, hogy „valóban elolvasta-e az Agent a felhasználóoldali művelet eredményét”. -A τ²-bench az üzleti folyamat összetettsége szerint rétegezi a nehézséget: az egyszerű információlekérdezésektől a többlépcsős folyamatokig (repülőjegy-foglalás módosítása: lekérdezés, alternatívák bemutatása, megerősítés beszerzése, árkülönbözet kiszámítása, fizetés feldolgozása) a hibadiagnózisig (több lehetséges ok szisztematikus ellenőrzése és javítások verifikálása), végül a stratégiai ítéletalkotásig (a szabályzatnak nem megfelelő kérések kezelése). +Ötödször, **a feladatpéldányok dinamikusan generálódnak**. A τ²-bench konkrét példányai (felhasználónevek, telefonszámok, hibakombinációk) paraméterezhetők és kötegelten előállíthatók, ami egyszerre javítja a lefedettséget és a szivárgással szembeni ellenálló képességet. -A Terminal-Bench a technikai tartomány × műveleti komplexitás kettős dimenziója mentén rétegezi a nehézséget. Feladatregisztere több mint 200 feladatot gyűjtött össze (az alapkiértékelő készlet mérete verziótól függően változik; pl. a 2.0-s verzió 89 kiváló minőségű feladatot választott ki a közösségi hozzájárulásokból), az egyszerű MLflow modellregisztrációtól, a közepes nehézségű 7-Zip jelszótörésen át, a nehéz Git szerver és web szerver integráción keresztül, a legnehezebb FEAL differenciális kriptoanalízisig (kriptográfiai ismeretek + algoritmus-optimalizálás szükséges a 30 másodperces időkorlát betartásához). +**SWE-bench Verified: a közzététel előtt az eredeti feladatok 71%-át kiszórták.** Az OpenAI az eredeti 2294 feladatból véletlenszerűen 1699-et emberi kiértékelésre bocsátott, és 93 Pythonban jártas fejlesztőt vont be, hogy egyenként átnézzék: világos-e a probléma leírása, lefedik-e a tesztesetek a határfeltételeket, stabilak-e a tesztek, visz-e be új hibát a referenciapatch, ésszerű-e a nehézség. Végül mindössze 500 ment át. A magas kiszórási arány jobb jel-zaj viszonyt eredményez, és a kiértékelés költsége is mintegy 80%-kal csökken. Az összetett Agent-feladatok gyakran percektől órákig tartanak, és egy kiértékelő adathalmaz végigfuttatása élvonalbeli modellel sokszor több ezer dolláros tokenköltséget jelent, ezért a kiértékelési költség csökkentése rendkívül fontos. -### Verifikálhatóság és Objektivitás Biztosítása +**OSWorld: a közzététel utáni 15 hónapban több mint 300 probléma került felszínre.** A 2024 áprilisában megjelent benchmark gyorsan a multimodális Agent-kiértékelés fontos eszközévé vált, ám a széles körű használat négyféle problémát tárt fel: környezeti problémákat (a webhelyek adatgyűjtés elleni védelme, CAPTCHA, dinamikus tartalomváltozás), feladatleírási problémákat (kétértelmű megfogalmazás), ellenőrzési logikai problémákat (túl szigorú vagy túl megengedő) és kezdetiállapot-problémákat (hiányos konfiguráció). A Hongkongi Egyetem csapata mintegy tízfős csoportot állított fel, és két hónapon át szorosan együttműködött a MoonShot AI-jal, az OpenAI-jal, a ByteDance Seed TARS-szal, az Anthropickal, a Simularral és másokkal a rendszerszintű javításon: a környezeti problémákat verziórögzítéssel és offline mentésekkel, a leírási problémákat a kétértelmű megfogalmazások átírásával, az ellenőrzési problémákat kézzel felállított helyes alapvonallal és a feltételek hangolásával, a kezdetiállapot-problémákat pedig teljességi ellenőrzések hozzáadásával enyhítették. -A GAIA válaszai tömörek és világosak. A szigorú formázási szabályok lehetővé teszik a verifikációt pontos sztringegyeztetéssel. A bináris eredmény (egyezik vagy nem) biztosítja az objektív reprodukálhatóságot. A válaszok ritkasága csalásellenes intézkedésként is szolgál — a nagyon specifikus tények valószínűtlen, hogy szó szerint szerepeljenek a tanítási adatokban. +> **7-2. kísérlet ★: Benchmarkfeladatok kézi végrehajtása** +> +> Válasszunk feladatokat a GAIA, az AndroidWorld, a SWE-Bench Verified, a Terminal-Bench és az OSWorld-Verified halmazokból, és oldjuk meg őket saját kezűleg; adathalmazonként egy könnyű, egy közepes és egy nehéz feladat ajánlott. A „nehéz” szint embernek is kihívás. +> +> A végén válaszoljunk két kérdésre. Megenged-e a feladatleírás többféle ésszerű értelmezést, és ha igen, melyiket fogadja el az ellenőrző? Ha valaki munka nélkül próbálna átcsúszni, mi lenne a legolcsóbb út, és fel tudná-e tartóztatni az ellenőrző? -A SWE-Bench Verified végrehajtható kódalapú ellenőrzéseket használ, megkülönböztetve a FAIL_TO_PASS (a javítás előtt hibás, javítás után sikeres, bizonyítva a probléma megoldását) és a PASS_TO_PASS (javítás előtt és után is sikeres, bizonyítva, hogy nem kerültek be új hibák) eseteket, elérve a kettős verifikációt. A Verified verzió azt is biztosítja, hogy a tesztek maguk megbízhatók legyenek, flúgos tesztek (amelyek néha sikeresek, néha sikertelenek) nélkül. +### A kiértékelő halmaz három forrása -A τ²-bench verifikációs rendszere többrétegű ellenőrzéseket tartalmaz (az egyes rétegek eredményei továbbra is bináris jutalomba tömörülnek feladat szinten; mindennek sikeresnek kell lennie a sikerhez): +Elterjedt nézet, hogy a nyilvános benchmarkok a modellek rangsorolását szolgálják, és kevés közük van a valódi üzlethez. Igaz, hogy a nyilvános benchmarkok pontszámai nehezen irányítanak közvetlenül termékdöntéseket, tervezési fogásaik azonban maradéktalanul átvihetők. Az ellenőrzés mélysége, a paraméteres generálás, a szivárgás elleni védelem és a minőség karbantartása — mindaz, amit fentebb tárgyaltunk — éppen az a néhány pont, amelyet a saját építésű kiértékelő halmazban a legkönnyebb elmulasztani. -- **Adatbázis-állapot ellenőrzés**: Foglalási rekord állapota, visszatérítési rekord létrehozása -- **Párbeszéd-tartalom kulcsszó keresése**: Hogy az Ügynök expliciten megerősítette-e a visszatérítési összeget és a várható érkezési időt a felhasználónak -- **Folyamatmegfelelés**: Az eszközhívások sorrendjének elemzése, pl. hogy a felhasználó explicit megerősítését beszerezték-e a rendelés módosítása előtt +Az éles üzemi kiértékelő halmaznak rendszerint három forrása van. -A τ²-bench kettős irányítású környezete (lásd az "Ember-Számítógép Interakciós Kiértékelési Környezet" szakaszt korábban) új dimenziót ad a verifikációhoz: miután a felhasználó-szimulátor ténylegesen megváltoztatta a környezeti állapotot, az Ügynöknek meg kell figyelnie ezt a változást az eszközhívásokon keresztül, és ennek megfelelően kell folytatnia a hibaelhárítást. A verifikáció ezért kiterjed arra is, hogy az Ügynök ténylegesen megfigyelte-e a felhasználó akcióinak kimenetelét. +**A nyilvános benchmarkok** a modellek durva szűrésére és a tervezési fogások kölcsönzésére szolgálnak, termékdöntésekre általában nem. Feladateloszlásuk nem esik egybe a valós üzlet feladateloszlásával: két százalékpontnyi javulás a GAIA-n nem áll szükségszerű összefüggésben a visszatérítések sikerarányával. -Az OSWorld 134 független kiértékelő függvényt biztosít teljes operációs rendszer hozzáféréssel, lehetővé téve a fájlrendszer-struktúrák, folyamatállapotok, hálózati kapcsolatok és alkalmazásbelsők mélyreható vizsgálatát. Például egy adatbázis-műveleti feladatban az értékelő szkript nemcsak azt ellenőrzi, hogy a jelentésfájl létezik, hanem közvetlenül csatlakozik az adatbázishoz, hogy ellenőrizze, az SQL helyesen futott-e le. Böngészőfeladatok esetén elemzi a DOM fát, ellenőrzi a cookie-kat/localStorage-t, és verifikációs kéréseket küld a háttérrendszernek, hogy megerősítse, az űrlapkitöltés ténylegesen életbe lépett-e. Ez a mélyreható vizsgálat képes észlelni a "felszínes befejezés, de lényeges hiba" eseteket — például az Ügynök rákattintott a beküldés gombra, de a kérést a szerver elutasította a hibás mezőbejegyzések miatt. +**A saját építésű üzleti halmaz** lefedi a valós feladateloszlást, és alapul szolgálhat a modellválasztáshoz, valamint a Harness tervezési döntéseihez. A τ²-bench például közvetlenül használható vázként bármely olyan kiértékelő rendszerhez, amelynek szimulált felhasználóra van szüksége; csak a tartományi adatokat és az eszközkészletet kell kicserélni. -A Terminal-Bench egy szabványosított Docker konténerkörnyezeten alapul, kombinálva a fájlrendszer-állapot ellenőrzéseket (útvonal létezése, jogosultsági értékek, tartalomformátum) a programvégrehajtás funkcionális verifikációjával (a build-linux-kernel-qemu esetében ténylegesen elindítja a QEMU-t és keresi az egyéni printk üzenetet). A kanári GUID nyomon követhetővé teszi a szivárgást. +**Az éles trajectoryk visszaáramlása** a terepen bekövetkező valódi kudarcokból származik: a felhasználó kifejezett helyesbítéseiből, negatív visszajelzéseiből, valamint az utólagos állapotellenőrzéssel, szabályalapú ellenőrzővel vagy LLM-es átnézéssel felfedezett esetekből. A hibaattribúción átesve ezek regressziós esetekké ülepednek. A konkrét eljárást a későbbi „Hibaattribúció” és „Végponttól végpontig tartó regressziós feladatok és trajectory prefix regressziós feladatok” szakaszok írják le. Ez a forrás a legdrágább, egyben a legpontosabb is, mert közvetlenül abból származik, amivel a felhasználók ténylegesen szembesültek. -### A Feladatmegoszlás Szisztematikus Tervezése +A kezdeti szakaszban rendszerint csak nyilvános benchmarkok és néhány kézzel írt üzleti eset áll rendelkezésre; miután a rendszer egy ideje éles üzemben fut, az éles trajectorykból visszaáramló esetek adják a zömét. -A feladatmegoszlásnak szisztematikusan le kell fednie a képességi dimenziókat, a nehézségi dimenziókat, a forgatókönyvi dimenziókat és a határeseteket. A GAIA az általánosságra törekszik — a legtöbb feladat a következtetés, multimodális feldolgozás, böngészés és eszközhasználat kombinációját igényli. A τ²-bench szándékosan "csapdafeladatokat" tervez — egy felhasználó azt állítja, hogy "az ügyfélszolgálat jóváhagyta a lemondást", amikor a lemondás valójában nem felel meg a szabályzatnak — hogy tesztelje, az Ügynök megőrzi-e az ítélőképességét nyomás és félrevezetés alatt. Az OSWorld a művelettípus (fájl IO / asztali alkalmazás / webalkalmazás / alkalmazásokon átívelő munkafolyamat) és az alkalmazási tartomány kétdimenziós mátrixán alapul, három operációs rendszert lefedve (a kutatás erős operációsrendszer-közi korrelációt mutat; az egyik rendszeren tanult készségek átvihetők másokra). A Terminal-Bench "több technológiai verem kombinációs feladatokat" tartalmaz a rendszerszintű gondolkodás tesztelésére (pl. egy újrafelosztási feladat, amely egyesíti az adatfeldolgozást + fájlműveleteket + Python mérnökséget). +## Automatizált kiértékelési módszerek -### Adatminőség-ellenőrzés és Iteratív Fejlesztés +Az előző szakaszokban tárgyalt benchmarkoknak van egy közös vonásuk: az ellenőrzőik szinte kivétel nélkül determinisztikusak. A SWE-bench tesztkészletet futtat, az AndroidWorld a végső UI-állapotot állítja, a GAIA pontos karakterlánc-egyezést végez, és a τ²-bench négy ellenőrzési rétegét is teljes egészében kód hajtja végre. Ennek a választásnak megvan a maga jó oka: a determinisztikus ellenőrzés nem jár többletmodell-költséggel, az eredmény teljesen reprodukálható, egységtesztként beépíthető a folyamatos integrációba, és megkönnyíti a modellek közötti rangsorolást. -A SWE-Bench Verified a minőség-ellenőrzés mintaképe. Az OpenAI véletlenszerűen kiválasztott 1699 feladatot az eredeti 2294-ből emberi kiértékelésre, 93 Pythonban jártas fejlesztőt toborozva. Az annotátoroknak több ellenőrzést kellett elvégezniük: a probléma leírása világos-e (megérthető-e, mit kell megoldani), a tesztesetek teljesek-e (minden aspektust és határesetet lefednek-e), a tesztek stabilak-e (nincsenek-e flúgos tesztek környezetből vagy véletlenszerűségből adódóan), a javítás helyes-e (vezet-e be új hibákat), és a nehézség ésszerű-e. A szigorú szűrés után csak 500 felelt meg (29%) — ez a magas elutasítási arány szükséges befektetés a kiértékelés minőségébe. Szabványosított annotációs iránymutatásokat is bevezettek, meghatározva minden egyes ellenőrzés specifikus szempontjait és példáit a különböző annotátorok közötti konzisztencia biztosítására. +Az ára az, hogy csak a végeredmény helyességét tudja értékelni, a hiba okát nem adja meg. A τ²-bench elbukott feladata végül 0 pontot kapott, és ez a 0 nem árulja el, hogy az Agent a vonalválasztásnál hibázott-e, vagy kihagyta az adatfeltöltési lépést, arról pedig végképp nem szól, mit kellene legközelebb megváltoztatni. Egy rangsorolásra használt nyilvános benchmark szempontjából ez nem hiba; egy folyamatos javításra szoruló éles rendszer szempontjából viszont éppen ez a legszükségesebb információ. -A τ²-bench bevezeti az "ismert információ" / "feladatutasítások" szétválasztását (realisztikusabbá téve a szimulátor viselkedését) és szigorúbb befejezési feltételeket (pl. "csak a kiváló számít megoldottnak; a gyenge/tisztességes/jó nem elfogadható"), megelőzve a "felszínes javításokat". +Az éles környezetnek van egy második nehézsége is: sok ítélet egyszerűen nem írható le kóddal ellenőrizhető állításként. Hogy egy panaszra adott válasz megfelelő hangvételű-e, hogy egy kutatási jelentésből kimaradt-e kulcsfontosságú információ, hogy egy memórialekérdezés összekeverte-e a személyek közötti kapcsolatot — ezeknek nincs egyetlen lekérdezhető végállapotuk, és kulcsszó-egyezéssel sem dönthetők el. -Az OSWorld-Verified az iteratív fejlesztés mintaképe. A 2024 áprilisi megjelenése után az OSWorld gyorsan fontos benchmarkká vált a multimodális Ügynök-kiértékelésben, de több mint 15 hónap széleskörű használat során több mint 300 problémát tártak fel. Ezek a problémák négy kategóriába tartoznak: környezeti problémák (weboldalak kaparás elleni védelme, CAPTCHA-k, dinamikus tartalomváltozások), feladatleírási problémák (kétértelmű megfogalmazás), verifikációs logikai problémák (túl szigorú vagy túl megengedő) és kezdeti állapot problémák (hiányos konfiguráció). A Hongkongi Egyetem körülbelül 10 fős csapata szorosan együttműködött a MoonShot AI-val, az OpenAI-val, a ByteDance Seed TARS-szal, az Anthropic-kal, a Simular-ral és másokkal két hónapon keresztül, hogy szisztematikusan kijavítsák ezeket a problémákat. Minden kategóriához javítási stratégiákat dolgoztak ki: a környezeti problémákat a verziók rögzítésével és offline biztonsági mentésekkel oldották meg, a feladatleírásokat a kétértelmű megfogalmazások átírásával tisztázták, a verifikációs logikát a helyes alapvonalak kézi felállításával és a feltételek módosításával egyensúlyozták, a kezdeti állapotokat a teljességi ellenőrzések hozzáadásával erősítették. +Ezért a nyilvános benchmarkoktól az éles kiértékelés felé haladva az ellenőrzés módját jobbra kell tolni egy olyan spektrum mentén, amelynek vízszintes tengelye a feladat **gépi ellenőrizhetőségének foka**; ezt mutatja a 7-4. ábra. -## Automatizált Kiértékelési Módszerek +![7-4. ábra: Az ellenőrzési módok spektruma – a determinisztikus ellenőrzéstől a modell általi ítéletig](images/fig7-4.svg) -A kiértékelési környezet, adathalmaz és világos metrikarendszer birtokában a központi kérdés: hogyan pontozzunk? A tiszta helyes válasszal rendelkező feladatoknál (pl. matematikai feladatok, SQL lekérdezések) elegendő az egyszerű bináris ítélet (helyes/helytelen); de a nyílt végű feladatoknál (pl. ügyfélszolgálati párbeszédek, jelentésírás) kifinomultabb kiértékelési módszerekre van szükség. +A spektrum jobb oldalán álló két eszköz így válik az éles kiértékelés gerincévé: a **Rubric** a homályos „mennyire jó” kérdést több, külön-külön pontozható dimenzióra bontja, az **LLM-as-a-Judge** pedig ott végzi el a pontozást, ahol nincs determinisztikus kritérium. Csak a kettő együtt képes egy általános kudarcarányt konkrét, megfogható problémákra visszabontani; a szakasz második felében tárgyalt **hibaattribúcióval** kiegészülve pedig az éles Agent-kiértékelés teljes zárt hurkát alkotják. -A kódalapú automatikus verifikáció csak a standard válaszokkal rendelkező forgatókönyveket fedi le; a nyílt végű feladatok pontozása ennek a szakasznak a fő témája. Ezek közül a jutalomjel-sűrűség tervezése (a bináris jutalmaktól a folyamatjutalmakon át a generatív jutalmakig) és a jutalommintázatok tanítási módszerei a 8. fejezet poszt-tréning szakaszában kerülnek szisztematikus tárgyalásra; ez a szakasz egy alapvetőbb kérdésre válaszol: hogyan használjunk LLM-eket a nyílt végű feladatok kimenetelének automatikus megítélésére. +Le kell szögezni: a jobbra tolódás nem jelenti a bal oldal feladását. Minden olyan ellenőrzés, amely programbeli állításként megírható, maradjon állítás, az LLM általi ítélet pedig csak azokra a dimenziókra vonatkozzon, amelyek valóban nem dönthetők el gépileg. A determinisztikus ellenőrzések olcsóbbak és stabilabbak, és hosszú távon regressziós tesztként futtatva is alkalmasabbak. ### LLM-mint-Bíró: Az Automatizált Kiértékelés Magja -![7-4. ábra: LLM-mint-Bíró Folyamatábra](images/fig7-4.svg) +![7-5. ábra: LLM-mint-Bíró Folyamatábra](images/fig7-5.svg) Miért van szükség LLM-mint-bíróra? Nyílt végű feladatoknál (pl. jelentések generálása, ügyfélpanaszok kezelése, kreatív tartalom) nincsenek standard válaszok az automatikus összehasonlításhoz, és az emberi kiértékelés költséges és nehezen skálázható. Az LLM-mint-bíró egyensúlyozza az automatizáció skálázhatóságát az emberi szakértői ítélettel azáltal, hogy egy nyelvi modell értékeli a kimeneteket szakértők által meghatározott pontozási szempontok (egy Rubrica) alapján. A módszernek ismert korlátai vannak: a bírómodell saját torzításokat hordoz (legjellemzőbben a "hosszúsági torzítás" — a hajlam, hogy a hosszabb, részletesebb válaszokat magasabbra pontozza, még ha nem is pontosabbak), és ugyanazon bemenet ismételt megítélése változhat. A hosszúsági torzítás különösen specifikus ellenintézkedéseket igényel. Három gyakori védekezés: a terjengősség explicit büntetése a Rubricában és a válaszok vágása feladattípusonként; páronkénti összehasonlításokban a két jelölt hasonló hosszúságra hozása az ítélkezés előtt; valamint a pontszámok és a válasz hossza közötti korreláció rendszeres auditálása — ha a magas pontszámok szinte mindig hosszú válaszokhoz tartoznak, a bírót befolyásolta a hosszúság, és a Rubricát felül kell vizsgálni. E kihívások szisztematikus kezeléséhez a Rubrica-tervezésnek az alábbi elveket kell követnie: @@ -363,7 +364,7 @@ rubric: A Rubricát és az Ügynök válaszát együtt adjuk a bírómodellnek, amely dimenziónként pontoz és indokol. Ha több tucat eset eredményét dimenziónként összesítjük, majd visszajátsszuk az alacsony pontszámú trajectory-ket, az általános „romlott a sikerarány” állítás konkrét diagnózissá válik: a lekérés kihagyott egy tényt, a modell rosszul kapcsolt össze személyeket vagy eseményeket, esetleg alátámasztás nélküli állítást tett. A jó Rubrica nemcsak a pontszámot mutatja meg, hanem azt is, hol érdemes folytatni a vizsgálatot. -Az alábbiakban a felhasználói memóriát vesszük konkrét esetnek, hogy megmutassuk, hogyan ültethető át ez az általános módszer futtatható kiértékelő halmazzá és pontozóvá. +Az alábbiakban a felhasználói memóriát vesszük konkrét esetnek, hogy megmutassuk, hogyan ültethető át ez az általános módszer futtatható kiértékelő halmazzá és ellenőrzővé. > **7-3. kísérlet ★★: Rubrica-alapú Felhasználói Memória Kiértékelő Rendszer Építése** > @@ -534,7 +535,7 @@ A gyakorlati modellválasztás során gyakran szembesülünk a kérdéssel: "Mel ### Páronkénti Összehasonlítás és Modellrangsorolás -![7-5. ábra: Elo Pontszámítás és Páronkénti Összehasonlítási Rangsor](images/fig7-5.svg) +![7-6. ábra: Elo Pontszámítás és Páronkénti Összehasonlítási Rangsor](images/fig7-6.svg) **Az Elo Pontszámítás** (egy eredetileg sakkra tervezett rangsorolási rendszer) a modellek relatív képességét számszerűsíti nagyszámú páronkénti mérkőzésen keresztül: minél nagyobb a pontszámkülönbség, annál magasabb a várható győzelmi arány az erősebb modell számára. Például, ha A modell pontszáma 1200, B modellé 1000, az Elo rendszer A győzelmi arányát körülbelül 76%-ra becsülné. Ha B váratlanul nyer, B több pontot szerez, A pedig többet veszít — a meglepetés nagyobb korrekciót vált ki, ami lehetővé teszi, hogy a rangsorok gyorsan konvergáljanak a valódi képességre. A statisztikai alap a "Bradley-Terry modell": minden modell egy látens "erősségi pontszámként" van absztrahálva, és annak valószínűsége, hogy egy mérkőzésen legyőzi a másikat, a pontszámaik különbsége határozza meg. Az Elo ennek a modellnek a mérnöki implementációja online frissítési formában. @@ -698,7 +699,7 @@ Több hipotézis párhuzamos ellenőrzésekor a **többszörös összehasonlít A kiértékelés-vezérelt döntések (akár modellválasztáshoz, akár folyamatos iterációhoz) minőségi működési adatokra támaszkodnak. Az alábbiakban először azt mutatjuk be, hogyan gyűjtsünk szisztematikusan ilyen adatokat (megfigyelhetőség), majd azt tárgyaljuk, hogyan fordítsuk le a kiértékelési eredményeket rendszerfejlesztésekké. -![7-6. ábra: Megfigyelhetőségi Technológiai Verem](images/fig7-6.svg) +![7-7. ábra: Megfigyelhetőségi Technológiai Verem](images/fig7-7.svg) A megfigyelhetőség egy elosztott rendszerekből kölcsönzött fogalom: nem nyithatod ki a rendszert, hogy lásd, hogyan működik; a naplókból, metrikákból és nyomkövetésekből következtetsz arra, mi történik — ahogy egy orvos, aki nem lát bele a betegbe, a hőmérsékletből, vérnyomásból és képalkotásból diagnosztizál. Az Ügynök-rendszerek ezt még nehezebbé teszik: ugyanaz a bemenet különböző kimeneteket produkálhat, a többfordulós következtetés és eszközhívások rendkívül összetetté teszik a végrehajtási utakat, és a modell "gondolkodása" kívülről teljesen átláthatatlan. @@ -718,11 +719,11 @@ Egy átfogó kiértékelő rendszerrel és adathalmazzal a kulcs az, hogy a kié A következő eset a kísérő tároló valós, szándékosan szűk AndroidWorld-iterációjából származik. Négy Wi-Fi-beállítási feladatot vizsgál API 35 emulátoron, feladatonként egy páros futással. Nem a teljes, 116 feladatos benchmark, és nem helyettesíti az API 33 referencia-környezetben végzett újrafuttatást. Értéke nem egy összpontszám, hanem az egymásra épülő döntések sora. -![7-7. ábra: Benchmarktól a Fejlesztésig Hurok](images/fig7-7.svg) +![7-8. ábra: Benchmarktól a Fejlesztésig Hurok](images/fig7-8.svg) A Harness Engineering szempontjából ez a szakasz lényegében a Harness iteratív optimalizálásának módszertanáról szól — a kiértékelési adatok használata a Harness gyenge pontjainak (elégtelen kontextus? hiányzó korlátozások? elégtelen validálás? nem megfelelő időzítésű visszacsatolás?) azonosítására, célzott fejlesztések végrehajtása, majd újraértékelés, ami a Harness folyamatos fejlődésének zárt hurkát alkotja. -Mielőtt bármilyen benchmark jelentést elemeznénk, vegyünk észre egy könnyen figyelmen kívül hagyható elvet: **amikor az Ügynök teljesítménye csökken, először a kiértékelő rendszert ellenőrizd, aztán az Ügynököt.** A gyakori hiba az, hogy a pontszám esésekor azonnal az Ügynök kódját kezdik szerkeszteni, figyelmen kívül hagyva annak lehetőségét, hogy a kiértékelő rendszer romlott el először — egy torzított jel alapján kormányozni, és a korrekció az első lépéstől fogva rossz. Tipikus kiértékelés-oldali hibák: a futásidejű környezet kifogy az erőforrásokból és leállítja a folyamatokat (ami véletlenszerű hibákként jelentkezik), hibák a pontozóban, amelyek helyes válaszokat jelölnek meg hibásként, és tesztesetek, amelyek eltolódtak a termelési forgatókönyvektől. A fő számokban mindezek azonosnak tűnnek a modellromlással; csak a teljes trajektóriák áttekintése különbözteti meg őket. +Mielőtt bármilyen benchmark jelentést elemeznénk, vegyünk észre egy könnyen figyelmen kívül hagyható elvet: **amikor az Ügynök teljesítménye csökken, először a kiértékelő rendszert ellenőrizd, aztán az Ügynököt.** A gyakori hiba az, hogy a pontszám esésekor azonnal az Ügynök kódját kezdik szerkeszteni, figyelmen kívül hagyva annak lehetőségét, hogy a kiértékelő rendszer romlott el először — egy torzított jel alapján kormányozni, és a korrekció az első lépéstől fogva rossz. Tipikus kiértékelés-oldali hibák: a futásidejű környezet kifogy az erőforrásokból és leállítja a folyamatokat (ami véletlenszerű hibákként jelentkezik), hibák az ellenőrzőben, amelyek helyes válaszokat jelölnek meg hibásként, és tesztesetek, amelyek eltolódtak a termelési forgatókönyvektől. A fő számokban mindezek azonosnak tűnnek a modellromlással; csak a teljes trajektóriák áttekintése különbözteti meg őket. ### Benchmark Jelentés Olvasása: A Problémafelismerés Művészete @@ -827,7 +828,7 @@ A kiértékelés végpontja nem a pontozás, hanem a fejlesztés. Ez a fejezet m Íme, hogyan találkozik a híd két vége. A kiértékelési oldalon felhalmozott eszközök szinte zökkenőmentesen alakíthatók át tréning jelekké: egy jól definiált Rubrica vagy validátor lényegében egy jutalomfüggvény a "Verifikálható Jutalmú Megerősítéses Tanuláshoz (RLVR)" — a pontozó szkriptből jutalom szkript lesz; hogy egy teszt sikeres-e vagy egy állapot megfelel-e a szabványnak, az egyszerre szolgál kiértékelési szempontként és megerősítéses tanulási jutalomként. De a tréning olyan követelményeket támaszt, amelyekről a kiértékelésnek soha nem kellett gondoskodnia. Az első a "megbízható visszaállítási szemantika": a tréning több millió epizódot futtat (egy epizód egy teljes interakciós kör a kezdeti állapottól a feladat befejezéséig), és minden epizódnak képesnek kell lennie a környezet determinisztikus, tiszta kezdeti állapotba való visszaállítására; különben a gradiens jelet szennyezik az előző epizód maradék állapotai. A második az **átviteli sebesség, amely messze meghaladja a kiértékelését**: néhány ezer kiértékelés elegendő a következtetések levonásához, de a tréning megköveteli, hogy a modellt több millió interakcióval tápláljuk elfogadható falon lévő óra időn belül; a környezet párhuzamosításának foka és a példányonkénti többletterhelés közvetlenül meghatározza, hogy a tréning megvalósítható-e. Ezt a két pontot — a validátorokból jutalomfüggvényekké alakítását, valamint a tréning szintű visszaállítást és átviteli sebességet — a 8. fejezet részletezi. -![7-8. ábra: Szimulációs Hűség Spektrum](images/fig7-8.svg) +![7-9. ábra: Szimulációs Hűség Spektrum](images/fig7-9.svg) A "digitális környezet" oldalán az AWorld keretrendszer egy irányítható MCP szerver sandboxot épít a GAIA feladatokhoz, 26 MCP szervert biztosítva 126 eszközfunkcióval, elkerülve a valós API-k közvetlen elérésének tiltásait és irányíthatatlan mellékhatásait. Minden eszközhívás visszajátszható és auditálható. Az AWorld elosztott architektúrája a hagyományos soros végrehajtási időt 7695 másodpercről 525 másodpercre csökkenti (14,6-szeres gyorsulás), és a környezet állapotmentes kialakítása minden példányt teljesen függetlenné tesz, támogatva a hatékony párhuzamosítást. @@ -838,7 +839,7 @@ A "megtestesült környezet" oldalán a RoboTwin2 egy fizikai motoron alapuló k > Állíts be egy szimulációs környezetet robotmanipulációhoz. Olvasd el a `ch7/SimpleVLA-RL` fájlt és az OpenVLA dokumentációt a Vízió-Nyelv-Akció modell architektúrájának megértéséhez (végpontok közötti integrációja egy vízió kódolónak, nyelvi modellnek és akció dekódolónak, amely a képeket és szövegeket egy közös szemantikai térbe vetíti). Konfiguráld a RoboTwin2 környezetet, értsd meg a megfigyelési teret (háromnézetű RGB + 14-dimenziós ízületi állapot) és az akcióteret (14-dimenziós vezérlővektor). Tanulmányozd a környezet randomizálási mechanizmusát és a térbeli korlátok logikáját a `move_can_pot`-ban. Értékeld az előre tanított modellt, rögzítve a sikerességi arányát, befejezési idejét és hibamódjait, különös figyelemmel az akció darabolás mechanizmusának hatására. > > -> ![7-9. ábra: OpenVLA és RoboTwin2 Megtestesült Intelligencia Környezet](images/fig7-9.svg) +> ![7-10. ábra: OpenVLA és RoboTwin2 Megtestesült Intelligencia Környezet](images/fig7-10.svg) > > @@ -850,7 +851,7 @@ A nagy hűségű környezetek jobb átvitelt támogatnak a valós világba, de m ## Fejezet Összefoglaló -Ez a fejezet egy kérdés köré épült: honnan tudjuk, hogy egy Ügynök valóban javult? A reprodukálható környezet, a szivárgásálló adathalmaz, az LLM-bíró és az értékelésvezérelt modellválasztás minden láncszeme befolyásolja a következtetés megbízhatóságát. A mért esetek négy gyakorlati figyelmeztetést adnak: a strukturált memória és a RAG együtt sem garantál szinergiát; a cache és tömörítés megtakarítása nem adható össze; a referenciahang megváltoztatja a multimodális pont jelentését; a Harness bemeneti reprezentációja pedig egyszerre dönthet sikerről és tokenköltségről. A modellválasztásnál több erőforráskeret képességgörbéit hasonlítsuk össze. Éles rendszerben a kiértékelés folyamatos validálás, nem alkalmi vizsga. +Ez a fejezet egy kérdés köré épült: honnan tudjuk, hogy egy Ügynök valóban javult? A lánc négy szakaszból áll: előbb tisztázzuk, mi számít sikernek (a Pass@k, a Best@k és a Pass consecutive@k eltérő alapjai), majd eldöntjük, honnan jönnek a feladatok (nyilvános benchmarkok, saját üzleti halmaz, éles trajectoryk visszaáramlása), ezután megválasztjuk az ellenőrzés módját (a determinisztikus ellenőrzőktől az ellenőrzőlistákon és a Rubric melletti LLM-ítéleten át a páronkénti összehasonlításig), végül pontszámokból döntést csinálunk (statisztikai szignifikancia, hibaattribúció, regressziós feladatok, modellválasztás). Minden szakasz befolyásolja a következtetés megbízhatóságát. A mért esetek négy gyakorlati figyelmeztetést adnak: a strukturált memória és a RAG együtt sem garantál szinergiát; a cache és tömörítés megtakarítása nem adható össze; a referenciahang megváltoztatja a multimodális pont jelentését; a Harness bemeneti reprezentációja pedig egyszerre dönthet sikerről és tokenköltségről. A modellválasztásnál több erőforráskeret képességgörbéit hasonlítsuk össze. Éles rendszerben a kiértékelés folyamatos validálás, nem alkalmi vizsga. A könyv egészének szerkezete felől nézve ez a fejezet az 1. fejezet felfedezési hurkának **bizonyíték** szakaszát építi: a hibaokolás dönti el, hogy a későbbi javaslatoknak van-e mire támaszkodniuk. diff --git a/book-hu/images/fig7-1.svg b/book-hu/images/fig7-1.svg index ab1ee6844..9036e69fc 100644 --- a/book-hu/images/fig7-1.svg +++ b/book-hu/images/fig7-1.svg @@ -1,19 +1,62 @@ - - - -1. réteg: a környezet kiértékelése -"Hol teszteljünk" — Eszközhívás / ember–számítógép interakció / szimulációs környezet - - -2. réteg: kiértékelési módszerek -"Hogyan értékeljünk" — Adathalmaz-tervezés · LLM mint bíró · páronkénti összehasonlítás és rangsorolás - - -3. réteg: kiértékelés-vezérelt döntések -"Mi legyen a tesztelés után" — Modellkiválasztás · architektúra-optimalizálás · folyamatos iteráció - -A fejezetet átható mérnöki témák -• Megfigyelhetőség -• Szimulációs környezet -• Belső kiértékelés - \ No newline at end of file + + + + + + + + +① A siker meghatározása +Pass@k a képességplafont · Pass^k a megbízhatóságot méri + + + +② A feladatok forrása + +Nyilvános benchmarkok +Fogások kölcsönzése · durva szűrés + +Saját üzleti halmaz +Valós feladateloszlás + +Éles visszaáramlás +A hibaattribúció terméke + + + +③ Az ellenőrzés módja +← a feladat gépi ellenőrizhetőségének foka szerint → + +Determinisztikus +SWE-bench + + +Ellenőrzőlista +τ²-bench + + +Rubric + LLM +Nyílt végű feladatok + + +Páronkénti +Chatbot Arena + + + +④ Az eredmények hasznosítása +Szignifikancia → Attribúció → Regresszió → Modell és Harness + + +A regressziós feladatok új esetekké válnak + + +Támogató infrastruktúra +Megfigyelhetőség · Belső kiértékelő infrastruktúra (abláció / AB / jelzők) · Szimuláció (8. fejezet) + diff --git a/book-hu/images/fig7-10.svg b/book-hu/images/fig7-10.svg new file mode 100644 index 000000000..3bd09f4b2 --- /dev/null +++ b/book-hu/images/fig7-10.svg @@ -0,0 +1,69 @@ + + + + +multimodális Megfigyelés + +fej camera +224×224 RGB + +bal Csuklókamera +224×224 RGB + +jobb Csuklókamera +224×224 RGB + +14 dimenziós együttes állapotvektor + +látás-nyelv-Művelet modell (VLA) + +Látáskódoló +SigLIP → Vizuális tokenek + + +Nyelvi modell +Llama 2 7B gerinchálózat + + +Műveletdekódoló +→ 14 dimenziós folytonos vezérlési vektor +Műveletdarabolás: 25 egymást követő művelet generálása egyszerre + + + +Instruction: "Put a képes → a pot" + + +SAPIEN Fizikai motor + +kettős-arm robot +Egyenként 7 szabadságfok = 14 dimenziós művelet + +környezet randomizáció +pozíció 60cm / orientation ±22.5° + +Collision észlelés + fizika szimuláció +Merev teszt / lágy teszt / súrlódás + +Művelet + +Megfigyelés + +Kiértékelési mutatók + +Sikerarány +képes inside pot +és nem fallen + +Befejezési idő +25 lépések × 25 műveletek += 625 vezérlés lépések + +Generalization képesség +kereszt-position/orientation +/Megjelenési változat + +Szimulációból valós környezetbe +Doménrandomizáció +→ valós migration + \ No newline at end of file diff --git a/book-hu/images/fig7-3.svg b/book-hu/images/fig7-3.svg index 0695a3c77..ceb6822d1 100644 --- a/book-hu/images/fig7-3.svg +++ b/book-hu/images/fig7-3.svg @@ -1,68 +1,76 @@ - - + + + + + + + - -Felhasználó-szimulátor (LLM) - -Ismert adatok: -Name: Sarah Johnson -Booking: BK-98712 -Feladatinstrukció: -"Úgy tűnik, probléma van a repülőjárattal" -→ A részletek fokozatos felfedése -→ Ne adja meg előre a foglalási számot - -Kiértékelendő ágens - - -LLM-érvelés + stratégiaválasztás -① Megadhatja a foglalási számát? -② lookup_booking(BK-98712) -③ Az UA123 járatot törölték -④ cancel_booking(BK-98712) -⑤ 150 USD visszatérítés, 3–5 munkanap - -Eszközök + adatbázis - -lookup_booking -Foglalási adatok lekérdezése -modify_booking -Foglalási állapot módosítása -cancel_booking -Lemondás és visszatérítés -search_flights -Alternatív járatok keresése -send_notification -Megerősítő értesítés küldése - -Adatbázis-állapot: -bookings, users, flights - -Párbeszéd - - -Eszközhívás - - -Kettős vezérlésű környezet: a felhasználó-szimulátor közvetlenül kezelheti a megosztott környezetet (eszközök + adatbázis) - -A feladat befejezése után: Többrétegű ellenőrzés - -Adatbázis-állapot ellenőrzése - -booking.status == 'cancelled' -refund_record EXISTS -refund.amount == 150.00 - -A párbeszéd tartalmának ellenőrzése - -Tartalmazza: „visszatérítés” + összeg -Tartalmazza az érkezési időt -Nincs benne hamis információ - -Folyamatmegfelelőség ellenőrzése - -Módosítás előtt felhasználói megerősítés szükséges -Nincs jogosulatlan művelet -Nincs szükségtelen átadás emberi ügyintézőnek - \ No newline at end of file + + +Felhasználószimulátor (LLM) +known_info: John Smith / 555-123-2002 / Franciaországban +task_instructions: feltárás · érzelem · lehorgonyzás +Elfogadás: csak az excellent számít megoldottnak + + + +Agent (kiértékelt) +Bemenet: hibajegy + tartományi házirend +Nem látható: az eszköz valódi állapota +Csak terelhet, helyette nem cselekedhet + + + +Többfordulós párbeszéd +Fokozatos információfeltárás + + + +Közös környezet (kettős vezérlés: mindkét oldal módosít) + +Eszközoldali állapot +Repülő üzemmód ON · roaming OFF · adattakarékos · maradék keret +Felhasználói eszközök: toggle_airplane_mode / toggle_roaming + check_status_bar / run_speed_test + +Szolgáltatóoldali adatbázis +Ügyfél C1001 · vonalak L1001/L1002/L1003 · tarifák · számlák +Agent-eszközök: get_customer_by_phone / get_data_usage + enable_roaming / refuel_data + + + + + + +A felhasználó toggle_roaming hívása megváltoztatta a környezetet; az Agentnek újra kell hívnia az eszközt — az ellenőrzés ezt is lefedi + + + +A feladat után: négy ellenőrzési réteg + összegző szabály + +env_assertions +A mobiladat elérhető +Sebesség ≥ 200 / excellent + +actions +toggle_airplane_mode +a requestor csak user lehet + +communicate_info +Közölték-e a szükséges információt +ennél a feladatnál null + +nl_assertions +Természetes nyelvi szintű ítélet +ennél a feladatnál null +reward_basis = ["ENV_ASSERTION"] → csak az első réteg számít; a többi rögzül, de nem kerül a jutalomba + diff --git a/book-hu/images/fig7-4.svg b/book-hu/images/fig7-4.svg index 9f732c051..e13cbbc89 100644 --- a/book-hu/images/fig7-4.svg +++ b/book-hu/images/fig7-4.svg @@ -1,53 +1,54 @@ - - + + + + + + - -Pontozási útmutató - -Factual Correctness: Essential -Logical Coherence: Important -Hallucináció észlelése: vétó ⚠ -Completeness: Important - -Válaszjelölt - -Az ágens kimenete: -"A visszatérítést feldolgoztuk, 150 USD jóváírása - 3–5 munkanapon belül megtörténik." - - -Referenciamegoldás (nem kötelező) - -Standard válasz / pontozási szempontok: -Tartalmaznia kell a visszatérítés összegét -Tartalmaznia kell a jóváírás idejét -Nem ígérhet konkrét dátumot - - - - -bíró modell (GPT-5 / Gemini 2.5) -Multi-forrás heterogeneous Kiértékelés → prevent azonos-forrás bias - - -strukturált Kiértékelés kimenet - -Factual Correctness -4/4 -Az összeg és az idő pontos -Completeness -3/4 -hiányzó explanation visszatérítés módszer -Hallucináció észlelése -átadás -nincs false információ -Logical Coherence -4/4 -tiszta causal relationship - -Pontszám-összesítési stratégia -Súlyozott átlag: Σ(súly × dimenziópontszám) -Vétó: hallucináció=SIKERTELEN → összpontszám=0 -Multi-judge: median of 3 judges -Szélső eset jelzése: >2 pontos eltérés → emberi felülvizsgálat - \ No newline at end of file + +A feladat gépi ellenőrizhetősége: magas +alacsony + + +Determinisztikus +A végállapot egyértelmű +Megfelelt / nem +A SWE-bench teszteket futtat + + + +Ellenőrzőlista +Több determinisztikus ellenőrzés +A deklarált alap szerint összegez +A τ²-bench négy rétege + + + +Rubric + LLM +Van dimenzió, de kód nincs rá +Dimenziónkénti pont és indoklás +Ügyfélszolgálat minősége, jelentésírás + + + +Páronkénti +Még a dimenziót is nehéz megírni +Csak A és B viszonyát ítéli meg +Chatbot Arena + + +Determinisztikus ellenőrzés +Teljesen reprodukálható, CI-be illik, olcsó +Ára: jó vagy rossz, de nem mutatja a hibát + + +Modell általi ítélet +Diagnosztikai dimenziókat ad, lefedi az állíthatatlant +Ára: ítéleti torzítás és szórás, drágább + diff --git a/book-hu/images/fig7-5.svg b/book-hu/images/fig7-5.svg index fc1da957b..9f732c051 100644 --- a/book-hu/images/fig7-5.svg +++ b/book-hu/images/fig7-5.svg @@ -1,56 +1,53 @@ - + - -Chatbot Arena névtelen párbaj - -modell A (névtelen) - -"Visszatérítés feldolgozva, Megérkezik ennyi időn belül: 3-5 - munkanapon belül a számlájára kerül" -VS - -modell B (névtelen) - -"Rendben, a visszatérítést feldolgozzuk" - - -Vak felhasználói választás → A jobb - -Elo frissítés Formula -Várható győzelmi arány E_A = 1/(1+10^((R_B-R_A)/400)) | Frissítés: R_A' = R_A + K*(1-E_A) -Live Leaderboard (példa) -rang -modell -Elo -Győzelmi arány vs #2 - -1 -Claude 4 Opus -1352 -— -2 -GPT-5 -1318 -— -3 -Gemini 2.5 Pro -1290 -45% -4 -DeepSeek R2 -1265 -42% -5 -Qwen 3 Max -1230 -39% -6 -Llama 4 405B -1198 -36% - - -GRPO: Introducing Páronkénti összehasonlítás → RL tréning -A készlet Válaszjelöltek → Normalize Relatív előny → Policyfrissítés (bypass explicit Jutalommodell) + +Pontozási útmutató + +Factual Correctness: Essential +Logical Coherence: Important +Hallucináció észlelése: vétó ⚠ +Completeness: Important + +Válaszjelölt + +Az ágens kimenete: +"A visszatérítést feldolgoztuk, 150 USD jóváírása + 3–5 munkanapon belül megtörténik." + + +Referenciamegoldás (nem kötelező) + +Standard válasz / pontozási szempontok: +Tartalmaznia kell a visszatérítés összegét +Tartalmaznia kell a jóváírás idejét +Nem ígérhet konkrét dátumot + + + + +bíró modell (GPT-5 / Gemini 2.5) +Multi-forrás heterogeneous Kiértékelés → prevent azonos-forrás bias + + +strukturált Kiértékelés kimenet + +Factual Correctness +4/4 +Az összeg és az idő pontos +Completeness +3/4 +hiányzó explanation visszatérítés módszer +Hallucináció észlelése +átadás +nincs false információ +Logical Coherence +4/4 +tiszta causal relationship + +Pontszám-összesítési stratégia +Súlyozott átlag: Σ(súly × dimenziópontszám) +Vétó: hallucináció=SIKERTELEN → összpontszám=0 +Multi-judge: median of 3 judges +Szélső eset jelzése: >2 pontos eltérés → emberi felülvizsgálat \ No newline at end of file diff --git a/book-hu/images/fig7-6.svg b/book-hu/images/fig7-6.svg index 473223e3a..fc1da957b 100644 --- a/book-hu/images/fig7-6.svg +++ b/book-hu/images/fig7-6.svg @@ -1,48 +1,56 @@ - - - -végrehajtás nyomkövetés fa (egyetlen feladat) - -nyomkövetés: ellenőrzés Beijing Időjárás céljára felhasználó tomorrow (3.2s, $0.008) - -LLM hívás: Intent recognition -Claude 4 Sonnet · 0.4s · 320 tokenek - -Tool：get_weather(Beijing) -MCP-szerver · 1.8s · 200ms TTFT - -├─ HTTP kérés -api.weather.com · 1.6s - -└─ válasz Parse -JSON → strukturált Időjárás adatok - -LLM hívás: generálás válasz -Claude 4 Sonnet · 0.8s · 580 tokenek - -Tool：send_message(user) -0.2s · Időjárás-összegzést tartalmaz - - - - - - - -Monitorozási irányítópult - -Költségkövetés -ma: $12.30 (1,200 hívások) -ez hónap: $340 (34K hívások) -Anomaly: feladat#892 looped keresés 14 times, költség $2.1 - -teljesítmény monitorozás -P50 / P95 / P99 késleltetés: 2,1 s / 8,4 s / 15,2 s -eszköz Sikerarány: 94.3% - -Minőségi audit -Sikeres feladat arány: 87% Hallucination indító: 2.1% -biztonság violations: 0 (ez hónap) felhasználó satisfaction: 4.3/5 - -Zárt ciklus: nyomkövetési adatok → problémaazonosítás → A/B teszt →Promptverzió-kezelés → folyamatos optimalizálás - + + + + +Chatbot Arena névtelen párbaj + +modell A (névtelen) + +"Visszatérítés feldolgozva, Megérkezik ennyi időn belül: 3-5 + munkanapon belül a számlájára kerül" +VS + +modell B (névtelen) + +"Rendben, a visszatérítést feldolgozzuk" + + +Vak felhasználói választás → A jobb + +Elo frissítés Formula +Várható győzelmi arány E_A = 1/(1+10^((R_B-R_A)/400)) | Frissítés: R_A' = R_A + K*(1-E_A) +Live Leaderboard (példa) +rang +modell +Elo +Győzelmi arány vs #2 + +1 +Claude 4 Opus +1352 +— +2 +GPT-5 +1318 +— +3 +Gemini 2.5 Pro +1290 +45% +4 +DeepSeek R2 +1265 +42% +5 +Qwen 3 Max +1230 +39% +6 +Llama 4 405B +1198 +36% + + +GRPO: Introducing Páronkénti összehasonlítás → RL tréning +A készlet Válaszjelöltek → Normalize Relatív előny → Policyfrissítés (bypass explicit Jutalommodell) + \ No newline at end of file diff --git a/book-hu/images/fig7-7.svg b/book-hu/images/fig7-7.svg index 42a8f03bd..473223e3a 100644 --- a/book-hu/images/fig7-7.svg +++ b/book-hu/images/fig7-7.svg @@ -1,56 +1,48 @@ - - - - -① Megfigyelés: diagnosztikai jelentés -Overall Sikerarány: 88% (102/116) -transcription: 0% complex_ui: 17% -math_counting: 0% Wi-Fi Operation: 0% -A hibák a 82. és 102–115. feladatra összpontosulnak - -② Hipotézis: háromrétegű javítási keretrendszer - -Surface réteg -H1 Navigációs prompt beállítása H2 Felületi szabályok - -Középső réteg -H3 Multimodális folyamat javítása H4 Gondolkodás - -Mély réteg -H5 GPT-5 H6 UI Element Tree - - -③ kísérlet: Phased validálás (5 runs × 116 feladatok minden konfiguráció) - -H1 Navigáció -Beállítás 0%→75% -token+8% - -H3 multimodális -átírás 0%→80% -Késleltetés +1 s - -H4 gondolkodás -Counting 0%→70% -Háromszoros késleltetés! - -H6 elem fa -UI 17%→52% -token+30% - -④ Döntés: költség–haszon kompromisszum -✓ H1+H3: alacsony költség, nagy haszon → bevezetés -✗ H4: csak a feladatok 8%-a javul, de a késleltetés háromszoros → elvetés -✓ H6: 35%-os javulás / 30%-os költség → bevezetés -✗ H5: 15 s/lépés elfogadhatatlan → alternatíva - -⑤ iteráció: új Cycle -Deploy H1+H3+H6 → 88%→94% -Az új jelentés eltérő hibamódokat mutat: - H7: Feltételes gondolkodás bekapcsolva - H8: Gesztusműveleti tér kibővítése - -↑ ciklus - -Módszertan: megfigyelés → hipotézis → kísérlet → döntés → iteráció = az alkímiától a tudományos mérnöki munkáig - \ No newline at end of file + + + +végrehajtás nyomkövetés fa (egyetlen feladat) + +nyomkövetés: ellenőrzés Beijing Időjárás céljára felhasználó tomorrow (3.2s, $0.008) + +LLM hívás: Intent recognition +Claude 4 Sonnet · 0.4s · 320 tokenek + +Tool：get_weather(Beijing) +MCP-szerver · 1.8s · 200ms TTFT + +├─ HTTP kérés +api.weather.com · 1.6s + +└─ válasz Parse +JSON → strukturált Időjárás adatok + +LLM hívás: generálás válasz +Claude 4 Sonnet · 0.8s · 580 tokenek + +Tool：send_message(user) +0.2s · Időjárás-összegzést tartalmaz + + + + + + + +Monitorozási irányítópult + +Költségkövetés +ma: $12.30 (1,200 hívások) +ez hónap: $340 (34K hívások) +Anomaly: feladat#892 looped keresés 14 times, költség $2.1 + +teljesítmény monitorozás +P50 / P95 / P99 késleltetés: 2,1 s / 8,4 s / 15,2 s +eszköz Sikerarány: 94.3% + +Minőségi audit +Sikeres feladat arány: 87% Hallucination indító: 2.1% +biztonság violations: 0 (ez hónap) felhasználó satisfaction: 4.3/5 + +Zárt ciklus: nyomkövetési adatok → problémaazonosítás → A/B teszt →Promptverzió-kezelés → folyamatos optimalizálás + diff --git a/book-hu/images/fig7-8.svg b/book-hu/images/fig7-8.svg index 59f54255f..42a8f03bd 100644 --- a/book-hu/images/fig7-8.svg +++ b/book-hu/images/fig7-8.svg @@ -1,41 +1,56 @@ - + - - -szimuláció pontosság → -Scalability - - - -↑ - -Mock API -unit teszt szint -million times/hour - -AWorld -MCP sandbox -126 Eszközfüggvények -525 s/kör, elosztott - -AndroidWorld -Simulator -116 valós alkalmazási feladat -UI Automator - -Isaac Gym -GPU parallelism -több ezer Párhuzamos instances -Slightly compromised Pontosság - -RoboTwin2 -Fizikai motor -magas-precision collision -egyetlen-instance CPU - -Valós világ -Perfect pontosság -Non-resettable - + +① Megfigyelés: diagnosztikai jelentés +Overall Sikerarány: 88% (102/116) +transcription: 0% complex_ui: 17% +math_counting: 0% Wi-Fi Operation: 0% +A hibák a 82. és 102–115. feladatra összpontosulnak + +② Hipotézis: háromrétegű javítási keretrendszer + +Surface réteg +H1 Navigációs prompt beállítása H2 Felületi szabályok + +Középső réteg +H3 Multimodális folyamat javítása H4 Gondolkodás + +Mély réteg +H5 GPT-5 H6 UI Element Tree + + +③ kísérlet: Phased validálás (5 runs × 116 feladatok minden konfiguráció) + +H1 Navigáció +Beállítás 0%→75% +token+8% + +H3 multimodális +átírás 0%→80% +Késleltetés +1 s + +H4 gondolkodás +Counting 0%→70% +Háromszoros késleltetés! + +H6 elem fa +UI 17%→52% +token+30% + +④ Döntés: költség–haszon kompromisszum +✓ H1+H3: alacsony költség, nagy haszon → bevezetés +✗ H4: csak a feladatok 8%-a javul, de a késleltetés háromszoros → elvetés +✓ H6: 35%-os javulás / 30%-os költség → bevezetés +✗ H5: 15 s/lépés elfogadhatatlan → alternatíva + +⑤ iteráció: új Cycle +Deploy H1+H3+H6 → 88%→94% +Az új jelentés eltérő hibamódokat mutat: + H7: Feltételes gondolkodás bekapcsolva + H8: Gesztusműveleti tér kibővítése + +↑ ciklus + +Módszertan: megfigyelés → hipotézis → kísérlet → döntés → iteráció = az alkímiától a tudományos mérnöki munkáig \ No newline at end of file diff --git a/book-hu/images/fig7-9.svg b/book-hu/images/fig7-9.svg index 3bd09f4b2..59f54255f 100644 --- a/book-hu/images/fig7-9.svg +++ b/book-hu/images/fig7-9.svg @@ -1,69 +1,41 @@ - - + + - -multimodális Megfigyelés - -fej camera -224×224 RGB - -bal Csuklókamera -224×224 RGB - -jobb Csuklókamera -224×224 RGB - -14 dimenziós együttes állapotvektor - -látás-nyelv-Művelet modell (VLA) - -Látáskódoló -SigLIP → Vizuális tokenek - - -Nyelvi modell -Llama 2 7B gerinchálózat - - -Műveletdekódoló -→ 14 dimenziós folytonos vezérlési vektor -Műveletdarabolás: 25 egymást követő művelet generálása egyszerre - - - -Instruction: "Put a képes → a pot" - - -SAPIEN Fizikai motor - -kettős-arm robot -Egyenként 7 szabadságfok = 14 dimenziós művelet - -környezet randomizáció -pozíció 60cm / orientation ±22.5° - -Collision észlelés + fizika szimuláció -Merev teszt / lágy teszt / súrlódás - -Művelet - -Megfigyelés - -Kiértékelési mutatók - -Sikerarány -képes inside pot -és nem fallen - -Befejezési idő -25 lépések × 25 műveletek -= 625 vezérlés lépések - -Generalization képesség -kereszt-position/orientation -/Megjelenési változat - -Szimulációból valós környezetbe -Doménrandomizáció -→ valós migration + + +szimuláció pontosság → +Scalability + + + +↑ + +Mock API +unit teszt szint +million times/hour + +AWorld +MCP sandbox +126 Eszközfüggvények +525 s/kör, elosztott + +AndroidWorld +Simulator +116 valós alkalmazási feladat +UI Automator + +Isaac Gym +GPU parallelism +több ezer Párhuzamos instances +Slightly compromised Pontosság + +RoboTwin2 +Fizikai motor +magas-precision collision +egyetlen-instance CPU + +Valós világ +Perfect pontosság +Non-resettable + \ No newline at end of file diff --git a/book-id/chapter7.md b/book-id/chapter7.md index ac7d0bfbe..627a0bc64 100644 --- a/book-id/chapter7.md +++ b/book-id/chapter7.md @@ -17,58 +17,117 @@ Evaluasi meletakkan keputusan-keputusan ini pada dasar ilmiah. Melalui eksperime Dari perspektif rekayasa Harness yang diperkenalkan pada Bab 1, evaluasi memainkan peran inti dari "verifikasi" di dalam Harness. Wawasan utamanya adalah: **objek evaluasi seharusnya tidak hanya modelnya, tetapi kombinasi dari model dan Harness**. Model yang sama dapat berkinerja sangat berbeda dalam Harness yang berbeda — beberapa tim telah secara signifikan meningkatkan performa model yang sama pada tugas-tugas terminal murni dengan mengoptimalkan Harness (lihat Bab 5). Jadi, ketika sebuah Agent dievaluasi dengan buruk, solusinya mungkin bukan model yang berbeda tetapi komponen Harness yang lebih baik (prompt, desain tool, loop umpan balik). Sistem evaluasi yang baik harus mampu membedakan dua masalah yang secara fundamental berbeda: "kemampuan model yang tidak memadai" dan "kelemahan desain Harness." **Cara umum untuk membedakan keduanya adalah eksperimen pertukaran model**: tetapkan Harness, tukar dengan model yang lebih kuat atau lebih lemah, dan perhatikan seberapa banyak skornya berubah. Jika model yang lebih kuat tidak meningkatkan skor, hambatannya ada pada Harness. Jika model yang lebih lemah menurunkan skor secara drastis dan hasilnya berayun tajam seiring dengan kemampuan model, pembacaan yang paling langsung adalah bahwa model itu sendiri adalah hambatannya dan performa saat ini didominasi oleh model. Apakah ini karena tugasnya secara inheren sulit atau karena Harness terlalu bergantung pada pengetahuan sebelumnya dari model, hal ini memerlukan analisis lebih lanjut. Perhatikan bahwa ini berbeda dengan eksperimen ablasi di atas: ablasi **menonaktifkan sebuah komponen Harness** untuk melihat bagaimana performa keseluruhan berubah; pertukaran model **menetapkan Harness dan hanya mengubah modelnya**. Yang pertama menemukan bagian mana di dalam Harness yang penting; yang terakhir memberi tahu Anda apakah hambatannya adalah model atau Harness. Sistem evaluasi bahkan lebih berharga di era evolusi model yang cepat. Model terus meningkat, tetapi model baru yang mendapat skor lebih tinggi pada benchmark publik belum tentu lebih baik pada tugas Anda — model tersebut bahkan bisa mengalami kemunduran (berkinerja lebih buruk daripada versi lama dalam beberapa aspek). Hanya pengujian penuh pada dataset evaluasi Anda sendiri yang memungkinkan Anda membuat keputusan peningkatan berbasis data. Sistem evaluasi yang solid bahkan membuat "membangun produk untuk model masa depan" menjadi strategi yang layak: jika model saat ini tidak cukup baik untuk penerapan komersial, selesaikan produknya saja, bangun set evaluasi, lacak performa setiap model baru, dan luncurkan segera setelah ada yang memenuhi standar. +Sebuah sistem evaluasi dapat diuraikan menjadi empat tahap: apa yang dihitung sebagai keberhasilan, dari mana tugas berasal, siapa yang memverifikasi, dan bagaimana skor diubah menjadi keputusan, seperti ditunjukkan pada Gambar 7-1. + +![Gambar 7-1: Empat Tahap Sistem Evaluasi Agent](images/fig7-1.svg) + +## Anatomi satu tugas evaluasi: domain telecom pada τ²-bench + +Mari kita mulai dengan membedah satu tugas nyata dari domain telecom τ²-bench secara utuh. Kode sumbernya ada di repositori pada `chapter7/tau2-bench`, dan berkas tugasnya adalah `data/tau2/domains/telecom/tasks_small.json`. + +### Empat komponen definisi tugas + +Berikut satu tugas dari berkas tersebut, dipersingkat agar mudah dibaca. + +```jsonc +{ + "id": "[mobile_data_issue]airplane_mode_on|user_abroad_roaming_enabled_off", + + // Tiket yang diterima Agent + "ticket": "Ponsel pengguna tidak bisa terhubung ke internet dan bilah status + menampilkan 'No Service'. Pelanggan John Smith, nomor 555-123-2002, + sedang berada di Prancis. Masalah dianggap selesai hanya jika tes + kecepatan menghasilkan excellent. Tidak ingin ganti paket, tetapi + bersedia mengisi 2,0 GB data bila perlu.", + + // Panduan perilaku yang diterima simulator pengguna + "user_scenario": { "instructions": { + "known_info": "You are John Smith with phone number 555-123-2002. + You are currently abroad in France.", + "unknown_info": null, + "task_instructions": + "…express mild frustration after the first unsuccessful attempt. + You will consider the issue resolved only when speed test returns + excellent internet speed and nothing else. If it returns poor, fair + or good, you will not consider the issue resolved. + Whenever the agent asks you about your device, always ground your + responses on the results of tool calls. … + Never make up the results of tool calls." + }}, + + // Sebelum dijalankan, kedua sisi direset ke titik awal yang sama + "initial_state": { "initialization_actions": [ + { "env_type": "user", "func_name": "turn_airplane_mode_on" }, + { "env_type": "user", "func_name": "turn_roaming_off" }, + { "env_type": "assistant", "func_name": "enable_roaming", + "arguments": { "customer_id": "C1001", "line_id": "L1002" } } + ]}, + + // Kriteria penilaian + "evaluation_criteria": { + "actions": [ + { "requestor": "user", "name": "toggle_airplane_mode" }, + { "requestor": "user", "name": "toggle_roaming" } + ], + "env_assertions": [ + { "func_name": "assert_mobile_data_status", "expected_status": true }, + { "func_name": "assert_internet_speed", + "expected_speed": 200, "expected_desc": "excellent" } + ], + "communicate_info": null, + "nl_assertions": null, + "reward_basis": ["ENV_ASSERTION"] + } +} +``` -> **Panduan Bab** -> -> Bab ini membangun sistem evaluasi yang lengkap pada tiga tingkat. Tingkat pertama adalah **Lingkungan Evaluasi** ("di mana harus menguji"): bagaimana menyiapkan lingkungan pengujian yang otomatis dan dapat direproduksi, yang mencakup dua paradigma: pemanggilan tool dan interaksi manusia-komputer. Tingkat kedua adalah **Metode Evaluasi** ("bagaimana menilai"): dari prinsip desain dataset dan sistem metrik evaluasi (apa yang harus diukur), hingga LLM-as-a-Judge (menggunakan *large language model* sebagai juri) untuk evaluasi otomatis, dan kemudian perbandingan berpasangan serta peringkat model. Tingkat ketiga adalah **Pengambilan Keputusan Berbasis Evaluasi** ("apa yang harus dilakukan setelah pengujian"): mengubah hasil evaluasi menjadi panduan yang dapat ditindaklanjuti untuk pemilihan model, pengoptimalan arsitektur, dan iterasi berkelanjutan, dengan signifikansi statistik untuk menilai apakah perbedaan skor yang diamati nyata. Bab ini juga membahas kemampuan observasi dan infrastruktur evaluasi internal dari Agent tingkat produksi, serta ditutup dengan lingkungan simulasi yang terhubung dengan pasca-pelatihan di Bab 8. -> -> Gagasan yang mendasari keseluruhan bab ini: **nilai utama dari sebuah sistem evaluasi bukanlah menilai sistem saat ini, melainkan memungkinkan Anda mengikuti evolusi model dengan cepat dan andal.** Ketika model yang lebih kuat atau lebih murah diluncurkan, tim dengan sistem evaluasi yang kuat dapat memutuskan dalam hitungan jam apakah akan beralih; tim yang tidak memilikinya hanya dapat memercayai intuisi atau menunggu umpan balik komunitas — dan di pasar Agent yang sangat kompetitif, perbedaan kecepatan itu dapat menentukan siapa yang menang. +Ada empat keputusan desain dalam definisi ini yang perlu diuraikan. -![Gambar 7-1: Tiga Tingkat Sistem Evaluasi](images/fig7-1.svg) +**Batas pengetahuan pengguna dimodelkan secara eksplisit.** `known_info` hanya memuat tiga hal: nama, nomor telepon, dan negara tempat pengguna berada. Dua penyebab gangguan yang sebenarnya—mode pesawat menyala dan data roaming mati—tidak ada di sana. Pengguna tidak mengetahuinya sehingga tidak dapat menyampaikannya sendiri, dan Agent hanya bisa memperolehnya dengan bertanya serta meminta pengguna memeriksa. Inilah wujud **pengungkapan informasi bertahap (Progressive Information Disclosure)** pada tataran definisi tugas: bukan dengan mengikat simulator lewat prompt "jangan katakan semuanya sekaligus", melainkan dengan memodelkan cakupan pengetahuan pengguna sebagai satu ruas tersendiri. Sebagian besar benchmark menyodorkan kebutuhan lengkap sejak awal tugas, padahal kalimat pertama pengguna nyata biasanya tak lebih dari "internet saya tidak jalan". Menjernihkan permintaan sampai dapat dieksekusi itu sendiri adalah bagian dari kemampuan yang harus dimiliki Agent. -## Contoh Evaluasi Konkret +**Simulator menerima panduan perilaku, bukan naskah dialog.** `task_instructions` memuat tiga jenis batasan sekaligus: pengaturan emosi (menunjukkan sedikit rasa kesal setelah upaya perbaikan pertama gagal), kriteria penerimaan (masalah dianggap selesai hanya bila tes kecepatan menghasilkan excellent; poor, fair, dan good semuanya ditolak), serta syarat **pengaitan fakta (Grounding)**, yakni setiap jawaban tentang keadaan perangkat harus berdasar pada nilai balik pemanggilan tool: "Never make up the results of tool calls". Yang ketiga paling menentukan. Tanpa batasan pengaitan fakta, pengguna simulasi akan mengikuti arahan Agent dan membenarkan bahwa masalah sudah beres, dan evaluasi merosot menjadi dua model yang saling mengiyakan. -Sebelum mendalami metodologinya, mari kita bangun intuisi melalui sebuah contoh lengkap. Misalkan kita telah membangun Agent layanan pelanggan dan perlu mengevaluasi kemampuannya dalam menangani permintaan pengembalian dana. +**Keadaan awal dibagi menurut pihak yang mengendalikannya.** `env_type` bernilai `user` atau `assistant`: mode pesawat dan sakelar roaming ada di sisi pengguna, sedangkan `enable_roaming` di sisi operator ada di sisi Agent. Pembagian inilah yang menentukan bentuk gangguannya—di sisi operator roaming sudah aktif, tetapi di perangkat pengguna dimatikan, sehingga Agent yang menelusuri basis data hanya memperoleh kesimpulan "konfigurasi normal". Gangguan berada di sisi yang tak terlihat oleh basis data, dan baru tersingkap bila pengguna diminta memeriksanya. -**Test Case**: Pengguna ingin mengembalikan pesanan dari 3 hari yang lalu (Pesanan #12345, Jumlah ¥299). Kebijakan perusahaan: Pengembalian dana penuh dalam 7 hari. +**Kriteria penilaian terbagi empat lapis, dan tugas ini hanya memakai satu di antaranya.** `env_assertions` memeriksa keadaan akhir (data seluler tersedia, kecepatan 200 Mbps ke atas dengan predikat excellent), `actions` memeriksa apakah tindakan kunci terjadi dan **pihak mana** yang melakukannya, sedangkan `communicate_info` dan `nl_assertions` memeriksa apakah informasi yang perlu sudah disampaikan kepada pengguna. `reward_basis` tugas ini hanya mendeklarasikan `ENV_ASSERTION`; lapis-lapis lain tetap dihitung dan dicatat, tetapi tidak masuk ke imbalan akhir. Dasar penilaian dideklarasikan per tugas, bukan dipatok secara global. -**Lintasan Agent**: +### Trajectory satu eksekusi nyata -```text -User: I want to return the headphones I bought 3 days ago, order number 12345. (Today is 2026-04-10) +Berikutnya kami mengajak pembaca menjalankan sendiri tugas evaluasi domain telecom τ²-bench, mengamati desain tugas, desain simulator pengguna, logika verifikasi proses dan hasil, serta menelusuri trajectory eksekusi Agent untuk menganalisis mengapa Agent gagal. + +> **Eksperimen 7-1 ★: Menjalankan τ²-bench dan membandingkan evolusinya dari τ-bench** +> +> Eksperimen ini menjalankan framework evaluasi τ²-bench untuk memahami pokok-pokok desain lingkungan evaluasi tipe interaksi manusia-komputer. Pertama, bacalah berkas definisi tugas mengikuti jalur pada bagian ini: setiap tugas terdiri atas empat bagian—informasi yang diketahui, instruksi tugas, keadaan awal, dan syarat keberhasilan. Selanjutnya jalankan alur evaluasi secara penuh, amati dialog multi-giliran antara simulator pengguna dan Agent, lalu analisis mode kegagalan yang khas (pelanggaran kebijakan, informasi terlewat, terlalu mudah mengalihkan ke agen manusia, dan sebagainya). +> +> ![Gambar 7-3: Lingkungan kendali ganda dan verifikasi berlapis pada τ²-bench](images/fig7-3.svg) -Agent (thinking): The user wants a refund, I need to check the order information first. -Agent → Calls tool query_order(order_id="12345") -Tool returns: {status: "delivered", amount: 299, date: "2026-04-07", item: "Bluetooth Headphones"} +Repositori pendamping menyimpan satu catatan eksekusi (`chapter7/tau2-bench-eval`). Berikut kita bedah satu eksekusi yang berhasil. -Agent (thinking): Order date 2026-04-07, today is 2026-04-10, that's 3 days, within the 7-day refund period, eligible for full refund. -Agent → Calls tool process_refund(order_id="12345", amount=299) -Tool returns: {refund_id: "R-98765", status: "processing", eta: "3-5 business days"} +Sepuluh giliran pertama adalah tahap identifikasi akun. Agent menemukan pelanggan C1001 dari nomor telepon, lalu menelusuri pemakaian data ketiga jalur L1001, L1002, dan L1003 satu per satu, dan kembali menanyakan nomor mana yang sebenarnya dipakai pengguna di Prancis. Pada pesan ke-17 ia menarik kesimpulan yang keliru: -Agent: A refund has been initiated for you. The full refund for Order #12345 (Bluetooth Headphones, ¥299) is being processed, - and is expected to arrive in 3-5 business days. The refund ID is R-98765, which can be used to check the progress. -``` +> **Agent** (17): nomor 555-123-2002 tidak ada di antara jalur aktif Anda; yang paling mendekati adalah 555-123-2001… + +Kesimpulan itu hanya bersandar pada penelusuran satu jalur, L1001. Setelah pengguna bersikeras bahwa nomornya benar, Agent menelusuri L1002 dan barulah cocok. Titik balik yang menentukan muncul pada pesan ke-30: -**Penilaian dengan Rubrik** (empat dimensi, masing-masing diberi skor 1-4). Tabel 7-1 memberikan contoh penilaian untuk tugas pengembalian dana layanan pelanggan ini, mengilustrasikan bagaimana sebuah Rubrik memecah lintasan Agent menjadi dimensi evaluasi yang dapat diperiksa. +> **Pengguna** (30) → memanggil `check_network_status()`, `check_status_bar()` +> +> **Balikan tool** (31): `Airplane Mode: ON | Cellular Connection: no_service | Mobile Data Enabled: Yes | Data Roaming Enabled: No` +> +> **Pengguna** (33): saya lihat ponsel sedang dalam mode pesawat, itu sebabnya tidak ada sinyal. Data seluler menyala, tetapi data roaming mati. Perlu saya matikan mode pesawatnya dan coba lagi? -Tabel 7-1 Contoh Penilaian Rubrik untuk Tugas Pengembalian Dana Layanan Pelanggan +Yang mengeluarkan pemanggilan tool adalah **pengguna**, bukan Agent. Inilah mekanisme **kendali ganda (Dual-Control)**: pengguna simulasi punya perangkat tool sendiri seperti `check_status_bar`, `toggle_airplane_mode`, `reseat_sim_card`, dan `run_speed_test`. -| Dimensi | Kriteria | Skor | Alasan | -|------------------------|--------------------------------|------|--------------------------------| -| Kebenaran Operasional | Apakah jumlah pengembalian dana dan nomor pesanan sudah benar? | 4 | Secara tepat menanyakan dan menginisiasi pengembalian dana penuh sebesar ¥299 | -| Kepatuhan Kebijakan | Apakah sesuai dengan kebijakan pengembalian dana 7 hari? | 4 | Pesanan berada dalam periode pengembalian dana, mematuhi kebijakan | -| Kelengkapan Informasi | Apakah ia menyediakan jumlah, waktu kedatangan, dan ID pengembalian dana? | 4 | Ketiga informasi kunci telah disediakan | -| Deteksi Halusinasi (Item Veto) | Apakah ia mengarang informasi yang tidak ada? | Lulus | Semua informasi berasal dari output tool | +Penelusuran berikutnya berjalan mulus: Agent meminta pengguna mematikan mode pesawat dan menyalakan roaming, pengguna melakukannya (35, 37), dan bilah status berubah menjadi 5G penuh; Agent meminta tes kecepatan, hasilnya 275 Mbps dengan predikat Excellent (46), dan pengguna memastikan masalah selesai. Kedua `env_assertions` lolos dan `reward = 1.0`. -Halusinasi didaftarkan sebagai **item veto** alih-alih dimensi penilaian yang bergradasi karena ini ortogonal terhadap kualitas — respons yang luwes / mengalir lancar, detail, dan sopan tetapi mengandung informasi palsu jauh lebih berbahaya bagi pengguna dibandingkan dengan respons yang singkat namun akurat. (Untuk desain umum dari mekanisme veto, lihat bagian "Empat Prinsip Rubrik" di bagian selanjutnya.) +Trajectory bernilai sempurna ini juga menyimpan satu masalah yang tak tertangkap verifier. Paragraf pertama kebijakan Agent telecom sudah menetapkan "You should only make one tool call at a time", tetapi pada pesan ke-4 Agent mengeluarkan `get_customer_by_phone` dan `get_customer_by_name` sekaligus. Verifier tidak menganggapnya salah karena `reward_basis` tugas ini hanya memperhitungkan keadaan akhir. Ini bukan kelalaian τ²-bench, melainkan harga yang melekat pada imbalan biner: ia menukar kehalusan proses dengan satu angka yang dapat dibandingkan antarmodel. Namun sistem evaluasi di lingkungan produksi biasanya menuntut lebih: bukan hanya memutuskan benar atau salah, tetapi juga menunjuk di mana letak masalahnya. -Test case ini lulus. Tetapi evaluasi yang baik tidak hanya menguji skenario keberhasilan; evaluasi tersebut juga menyelidiki batasan dan jebakan — ketika pengguna ingin mengembalikan pesanan dari 15 hari yang lalu (di luar periode pengembalian dana), bisakah Agent menolaknya dengan benar? Ketika pengguna mengklaim "perwakilan layanan pelanggan sudah menyetujui pengembalian dana," akankah Agent memercayainya tanpa catatan sistem? Skenario batas inilah yang benar-benar memisahkan Agent yang kuat dari Agent yang lemah. +Tugas yang gagal juga layak dianalisis. Nomor pengguna adalah 555-123-2002, tetapi Agent memilih jalur L1001 dan terus bernalar berdasarkan pemakaian 3,2/5 GB pada jalur itu. Di tengah jalan `get_details_by_id(L1001)` dengan jelas mengembalikan bahwa nomor jalur tersebut adalah 555-123-2001; Agent membaca hasil itu tetapi tidak mengoreksi penilaiannya, lalu menghabiskan puluhan pesan untuk penelusuran yang tidak relevan dan akhirnya mengalihkan ke agen manusia. Sebenarnya separuh tugas sudah ia selesaikan—ia menuntun pengguna mematikan mode hemat data, dan tindakan di sisi pengguna itu benar-benar terjadi serta diverifikasi lingkungan. Namun salah memilih jalur membuat pengisian 2 GB yang diperlukan tidak pernah dijalankan, dan ketiga asersi keadaan akhir gagal semua. Bentuk kegagalan ini sangat mirip dengan kasus AndroidWorld yang dibahas nanti pada bagian "Atribusi kegagalan": bukti yang diperlukan untuk mengoreksi penilaian sudah masuk ke konteks, tetapi Agent tidak menelusuri balik berdasarkan bukti itu. -Proses di atas — mendefinisikan test case, menjalankan Agent, memberi skor dengan sebuah Rubrik, dan menganalisis hasil — adalah kerangka dasar evaluasi. Sisa bab ini akan menguraikan lebih lanjut desain dari setiap langkah. +Satu tugas ini saja sudah memunculkan seluruh pertanyaan yang harus dijawab sebuah himpunan evaluasi: apa yang dihitung sebagai keberhasilan, dari mana tugas berasal, siapa yang memverifikasi, dan bagaimana skor diubah menjadi keputusan. Bagian-bagian berikut membahasnya berurutan. -## Sistem metrik evaluasi: kriteria yang diperbarui +## Metrik evaluasi: definisi keberhasilan -Sebelum membangun lingkungan atau dataset, tentukan arti “berhasil”: apakah satu jalur yang berhasil sudah cukup, atau setiap eksekusi harus bebas kesalahan? Definisi yang berbeda dapat membalik keputusan rekayasa. Bagian ini lebih dahulu menegakkan tolok ukur tersebut, lalu di belakang menjelaskan cara mewujudkan lingkungan, set data, dan penilainya. +Hasil evaluasi pada bagian sebelumnya adalah empat dari lima tugas lolos. Dari angka 0,8 saja kita tidak bisa menilai apakah sistem itu layak pakai. Bila itu adalah Agent layanan pelanggan untuk pengembalian dana, artinya satu dari lima pengguna tidak memperoleh pengembalian yang menjadi haknya; bila itu adalah Agent keamanan untuk berburu kerentanan, empat kena dari lima sudah cukup mengesankan. Bedanya terletak pada seberapa tinggi tingkat keberhasilan yang dituntut skenario bisnisnya. ### Keajaiban teknis: batas kemampuan dengan Pass@k @@ -99,209 +158,151 @@ Misalnya pada $p=0.6$ dan $k=5$: Pass@5 $=1-0.4^5\approx99.0\%$, seolah-olah "be Laporan evaluasi wajib menuliskan dengan jelas apa arti $k$ percobaan itu: $k$ pengambilan sampel independen atas tugas yang sama, atau $k$ tugas berurutan pada jalur produksi. Untuk operasi yang menimbulkan efek samping, tidak boleh sekadar "ulangi sampai berhasil"; ambil sampel di sandbox atau lingkungan yang bisa di-rollback, dan catat setiap kegagalan ke dalam metrik keandalan. -### Metrik proses: Dari kotak hitam ke kotak putih - -Berfokus semata-mata pada hasil akhir tidaklah cukup; proses di mana Agent mencapai hasil tersebut sama pentingnya. **Tingkat validitas dan otorisasi tindakan (Action validity and authorization rate)** mengukur proporsi tindakan yang valid sekaligus diotorisasi—operasi tidak valid termasuk memanggil alat (tool) yang tidak ada atau meneruskan jenis parameter yang salah; operasi tidak sah merujuk pada tindakan di luar cakupan yang diizinkan. Tingkat yang tinggi menunjukkan bahwa Agent memiliki pemahaman yang jelas tentang ekosistem alat. **Tingkat kebenaran pemanggilan tool (Tool call correctness rate)** lebih lanjut mensyaratkan bahwa parameter secara semantik masuk akal: istilah kueri untuk alat pencarian harus secara akurat mengekspresikan kebutuhan, dan jalur (path) untuk operasi file harus menunjuk ke target yang benar. - -**Efisiensi jalur (Path efficiency)** mengukur seberapa efisien tugas diselesaikan: jumlah langkah (siklus *think-act-observe*), tindakan redundan (berulang kali mencari kata kunci yang sama, membaca ulang file yang sama), dan frekuensi runut balik (backtracking) (seberapa sering Agent menyadari kesalahan dan memperbaiki dirinya sendiri—runut balik sesekali adalah normal, tetapi runut balik yang sering menunjukkan perencanaan ke depan yang tidak memadai). Sebuah *baseline* dari pakar manusia atau algoritma heuristik diperlukan untuk mendefinisikan "jumlah langkah yang masuk akal." - -**Cakupan pencarian (Retrieval coverage)** menargetkan tugas-tugas pengumpulan informasi: Apakah Agent sepenuhnya mengeksplorasi ruang informasi? Apakah ia melompat ke kesimpulan setelah hanya melihat halaman pertama dari hasil pencarian? **Biaya dan latensi (Cost and latency)** berfokus pada jumlah permintaan, pengeluaran token (membedakan biaya input/output, mempertimbangkan penggunaan kembali KV Cache), dan *wall-clock time* (termasuk inferensi model + eksekusi alat + latensi jaringan). Distribusi waktu perlu dilacak untuk mengidentifikasi kemacetan (bottlenecks). - -### Keamanan, robustness, dan cakupan trajectory - - -**Metrik Keselamatan dan Kepatuhan (Safety and Compliance Metrics)** sangat penting dalam penyebaran (deployment) produksi: memicu operasi sensitif (menghapus data / memodifikasi izin / mengirim komunikasi eksternal), kebocoran data (mencetak kata sandi dalam log / mengirim dokumen pribadi ke API eksternal), dan konten yang dilarang semuanya harus tunduk pada **prinsip tanpa toleransi (zero-tolerance principle)**—mirip dengan veto halusinasi (lihat "Empat Prinsip Rubric" nanti). Pelanggaran keselamatan yang serius meskipun hanya satu kali akan memveto keseluruhan evaluasi, terlepas dari performanya di dimensi lain. - -**Ketangguhan (Robustness)** mengukur stabilitas dalam menghadapi ketidakpastian: sensitivitas benih acak (random seed sensitivity) (seberapa banyak variasi performa di bawah inisialisasi yang berbeda), kemampuan beradaptasi terhadap perubahan halaman (pembaruan UI situs web seharusnya tidak menyebabkan kegagalan total), toleransi terhadap *jitter* API (dapatkah ia menangani kegagalan sementara, *timeout*, perubahan format dengan baik), dan gangguan memori jangka panjang (dapatkah informasi usang yang terkumpul dalam konteks menyebabkan keputusan yang salah). - -**Cakupan Ganda dari Lintasan Eksekusi (Execution Trajectory) dan Hasil Akhir (Final Outcome).** Perbedaan yang mudah diabaikan: "apa yang dikatakan dan dilakukan Agent selama eksekusi" (lintasan yang didefinisikan dalam Bab 1) dan "menjadi apa sistem pada akhirnya" (hasil akhir) adalah dua hal yang berbeda. Agent yang mengatakan "pemesanan telah selesai" adalah informasi tingkat lintasan; catatan yang benar-benar muncul dalam database adalah verifikasi tingkat hasil. Lihat hanya pada lintasannya dan Anda akan kehilangan "mengatakannya tetapi tidak melakukannya"; lihat hanya pada hasilnya dan Anda mungkin kehilangan langkah-langkah perantara yang tersesat. Anthropic pernah memberikan contoh: Agent pemesanan penerbangan menemukan celah dalam kebijakan maskapai penerbangan selama eksekusi dan menemukan opsi yang lebih murah untuk pengguna—jika dinilai hanya menurut jalur eksekusi yang telah ditetapkan, jalannya eksekusi ini akan dinilai gagal; tetapi dari hasil akhir, pengguna mendapat kesepakatan yang lebih baik. Oleh karena itu, kedua jenis evaluasi harus dicakup untuk menghindari titik buta (blind spots) sistematis. - -### Pemeriksaan manusia dan tinjauan adversarial - -Bahkan ketika evaluasi otomatis dapat diandalkan sebagian besar waktu, pemeriksaan acak manusia secara teratur tetap diperlukan: mencakup jenis tugas yang berbeda, keberhasilan dan kegagalan, dan kasus-kasus ambigu di dekat batas skor — memverifikasi bukan hanya hasilnya tetapi juga keabsahan rasional dari penilaian tersebut. - -Pemeriksaan acak dapat disistematisasi menjadi **kalibrasi juri (judge calibration)**. Sebelum menyebarkan juri LLM dalam skala besar, buatlah set standar emas yang dianotasi oleh manusia (katakanlah, 100-200 kasus yang mencakup jenis dan kesulitan tugas) dan ukur seberapa baik kesesuaian antara model juri (LLM yang bertindak sebagai juri; mekanismenya dirinci dalam bagian LLM-as-a-Judge berikutnya) dengan anotasi manusia — tingkat kesepakatan sederhana atau Cohen's kappa, yang terakhir mengabaikan kesepakatan kebetulan. Hanya setelah kesepakatan melewati ambang batas yang ditetapkan (misalnya, kappa di atas 0,7) barulah juri dapat digunakan untuk evaluasi skala besar; setelah itu, kalibrasi ulang pada set emas kapan pun model juri atau Rubric berubah. Tanpa langkah ini, skor juri LLM hanyalah "pendapat model lain," bukan proksi yang dapat diandalkan untuk penilaian manusia. - -**Tinjauan adversarial** menggunakan Red Teaming untuk secara aktif membangun kasus-kasus yang menantang: jawaban yang tampak sempurna berisi kesalahan tersembunyi, jawaban yang lolos melalui penumpukan kata kunci (keyword stuffing), dan jawaban yang mengeksploitasi bias yang diketahui dari model juri untuk mendapatkan skor tinggi yang tidak pantas. **Mekanisme multi-juri** menggunakan banyak juri independen untuk menilai secara terpisah, menentukan hasil akhir melalui rata-rata tertimbang atau pemeriksaan konsistensi—ketika juri tidak setuju secara signifikan, kasus tersebut ditandai untuk tinjauan manusia lebih lanjut. +## Lingkungan evaluasi -## Lingkungan Evaluasi Otomatis +Setelah dasar metriknya jelas, pertanyaan berikutnya adalah di mana mengukurnya. Lingkungan evaluasi adalah perangkat yang dapat dijalankan berulang: dengan keadaan awal yang sama, Agent yang sama semestinya menghasilkan hasil yang sebanding. -Evaluasi agen membutuhkan lingkungan yang dapat diulang dan otomatis — lingkungan yang dapat dengan cepat menguji efek perubahan selama pengembangan. Membangun lingkungan seperti itu membutuhkan jawaban atas tiga pertanyaan: apa yang dievaluasi (definisi tugas dan kriteria verifikasi), dengan siapa Agent berinteraksi dan bagaimana menyimulasikan mitra tersebut, serta kriteria penilaian mana yang digunakan. +### Lima komponen penyusun -### Komponen Dasar dari Lingkungan Evaluasi +Mari kembali ke tugas telecom yang tadi dibedah. Dengan menjadikannya rujukan, semua yang dibutuhkan sebuah lingkungan evaluasi yang dapat dijalankan berulang sudah lengkap. -Sebuah lingkungan evaluasi terdiri dari lima elemen — bagian selanjutnya akan berfokus pada desain dataset dan desain kriteria penilaian: +**Himpunan data (Dataset)** adalah berkas tugas itu sendiri: keadaan awal, tiket untuk Agent, panduan perilaku untuk simulator, dan kriteria penerimaan dikemas menjadi satu rekaman, dan satu rekaman adalah satu kasus uji. -**Dataset**: Mendefinisikan kumpulan tugas, termasuk state awal, deskripsi tujuan, dan solusi referensi opsional. +**Keadaan lingkungan (Environment State)** adalah informasi yang berubah selama tugas berjalan: pelanggan, jalur, paket, dan tagihan di basis data, ditambah mode pesawat, roaming, sakelar hemat data, dan sisa kuota di sisi perangkat. Ia harus dapat direset, dan `initialization_actions` adalah skrip resetnya. Kenyataan menuntut perubahan keadaan mengikuti logika bisnis; keterkendalian menuntut kita bisa kembali ke titik awal yang sama sebelum tiap eksekusi. -**Environment State**: Melacak state yang dapat berubah selama eksekusi tugas dan harus menyeimbangkan realisme dengan kemampuan pengendalian. Misalnya, dalam evaluasi layanan pelanggan, environment state mencakup catatan pesanan dalam basis data dan saldo akun pengguna. Setelah Agent memanggil `process_refund`, status pesanan berubah dari `"delivered"` menjadi `"refunded"` dan saldo bertambah. "Realisme" mengharuskan perubahan state mengikuti logika bisnis (jumlah pengembalian dana tidak boleh melebihi jumlah pesanan), dan "kemampuan pengendalian" mengharuskan setiap tes dapat diatur ulang ke state awal yang sama. +**Antarmuka tool (Tools)** terbagi ke dua sisi. Agent dapat memanggil operasi di sisi operator seperti menelusuri pelanggan, menelusuri pemakaian, mengisi kuota, dan mengalihkan ke agen manusia; pengguna dapat mengoperasikan berbagai sakelar di perangkatnya. Kedua perangkat tool bersifat atomik dan tidak ada abstraksi tingkat tinggi semacam "selesaikan masalah internet pengguna"—tingkat abstraksi yang terlalu tinggi menurunkan evaluasi menjadi pemeriksaan satu pemanggilan fungsi, sementara perencanaan dan penalaran terserap ke dalam tool itu sendiri. -**Tools**: Mendefinisikan kumpulan operasi yang dapat dilakukan oleh Agent — tool seharusnya tidak menyediakan abstraksi tingkat yang terlalu tinggi (seperti "selesaikan masalah pengguna"), melainkan harus menyediakan operasi atomik (seperti query_order, ubah pemesanan, kirim email), memaksa Agent untuk menggabungkan operasi-operasi ini melalui perencanaan dan penalaran. +**Kriteria penilaian (Rubric)** adalah empat lapis pemeriksaan pada `evaluation_criteria` ditambah aturan agregasi `reward_basis`. -**Rubrik (Kriteria Penilaian)**: Mengukur performa Agent, yang dapat bersifat biner (lulus/gagal), kontinu (0 hingga 100 poin), atau multi-dimensi (menilai akurasi, efisiensi, dan keamanan secara terpisah). +**Protokol eksekusi (Interaction Protocol)** menetapkan urutan interaksi dan syarat berhenti. Di sini sinyal berhenti normal adalah pengguna simulasi mengeluarkan `###STOP###`; selain itu ada batas jumlah giliran, dan pengguna simulasi bisa menyudahi percakapan sendiri karena kehabisan kesabaran—efisiensi komunikasi yang terlalu rendah dengan sendirinya dihitung sebagai kegagalan. -**Protokol Interaksi**: Menentukan mode interaksi dan kondisi terminasi. +Kurang satu saja dari kelima komponen ini, evaluasi tidak lagi membentuk lingkaran yang dapat diulang. Ketika membahas benchmark lain di bawah, kelima butir ini tetap menjadi kerangka pembanding. -Kelima elemen ini bersama-sama membentuk loop evaluasi yang dapat diulang. +### Lingkungan evaluasi tipe interaksi manusia-komputer dan tipe pemanggilan tool -![Gambar 7-2: Lingkungan Evaluasi Pemanggilan Tool dan Interaksi Manusia-Komputer](images/fig7-2.svg) - -Bergantung pada tugas Agent, lingkungan evaluasi dapat dibagi secara kasar menjadi tipe pemanggilan tool dan tipe interaksi manusia-mesin. - -### Lingkungan Evaluasi Pemanggilan Tool +Tugas seperti telecom wajib punya lawan bicara, sehingga bagian simulasi pengguna dari kelima komponen itu tak tergantikan. Ada pula satu kelas besar tugas lain yang sama sekali tidak punya lawan bicara: pada pembuatan kode, analisis data, dan penyelesaian soal matematika, Agent dari awal sampai akhir hanya berinteraksi dengan tool, kebenarannya ditentukan oleh lolos tidaknya verifikasi eksekusi, dan tidak diperlukan anotasi manusia maupun penilaian model. Lingkungan semacam ini meniadakan simulator pengguna; empat komponen sisanya tetap ada, hanya bentuknya lebih sederhana: keadaan lingkungan berupa sistem berkas atau basis data, kriteria penilaian berupa sepotong kode uji, dan protokol eksekusi menyusut menjadi "terus memanggil tool sampai memberi jawaban atau kehabisan giliran". -Untuk tugas-tugas yang utamanya bergantung pada penggunaan tool, seperti pembuatan kode dan analisis data, framework Verifiers menunjukkan pola desain yang khas. Agent menyelesaikan tugas dengan memanggil tool yang telah ditentukan sebelumnya, dan verifikasi didasarkan pada kriteria yang dapat dieksekusi (apakah tes lulus, apakah jawaban cocok), tanpa bergantung pada anotasi manusia atau penilaian model. +Framework Verifiers melapisi lingkungan semacam ini berdasarkan dua dimensi: apakah tugas perlu mempertahankan keadaan antargiliran, dan apakah perlu isolasi. `SingleTurnEnv` cocok untuk memberi satu soal matematika lalu langsung memverifikasi jawabannya; `ToolEnv` cocok untuk mencari beberapa halaman web lalu menjawab secara ringkas dan memverifikasi hasil akhirnya; `StatefulToolEnv` cocok untuk mengubah rekaman basis data lalu memverifikasi perubahan keadaan; `SandboxEnv` cocok untuk menjalankan kode di sandbox lalu memeriksa berkas keluaran. Tabel 7-1 merangkum keempat tipe ini agar mudah dipilih menurut kebutuhan keadaan tugas, pemanggilan tool, dan isolasi. -Verifiers memperkenalkan desain lingkungan yang hierarkis: `SingleTurnEnv` cocok untuk tugas giliran tunggal (misalnya, Q&A sederhana), `ToolEnv` mendukung loop otonom dari pemanggilan tool untuk banyak giliran, sedangkan `StatefulToolEnv` dan `SandboxEnv` mendukung tool stateful dan lingkungan sandbox yang berjalan lama (misalnya, eksekusi kode). Sebagai contoh: `SingleTurnEnv` cocok untuk mengajukan pertanyaan matematika dan langsung memeriksa jawabannya; `ToolEnv` cocok untuk mencari beberapa halaman web dan menyintesis jawaban sebelum memverifikasi hasil akhirnya; `StatefulToolEnv` cocok untuk memodifikasi catatan basis data dan memverifikasi perubahan state yang dihasilkan; `SandboxEnv` cocok untuk menjalankan kode dalam sebuah sandbox dan memeriksa file output. Tabel 7-2 merangkum tipe-tipe lingkungan ini agar pembaca dapat memilih lingkungan evaluasi yang tepat berdasarkan state tugas, pemanggilan tool, dan persyaratan isolasi. +Tabel 7-1 Perbandingan tipe lingkungan Verifiers -Tabel 7-2 Perbandingan Tipe Lingkungan Verifiers - -| Tipe Lingkungan | Persistensi State | Pemanggilan Tool | Penggunaan Khas | +| Tipe lingkungan | Mempertahankan keadaan | Pemanggilan tool | Kasus penggunaan khas | |---|---|---|---| -| SingleTurnEnv | Tidak Ada | Tidak Ada | Q&A giliran tunggal, soal matematika | -| ToolEnv | Tidak Ada | Banyak Giliran | Pencarian + sintesis informasi | -| StatefulToolEnv | Ya | Banyak Giliran | Memodifikasi catatan basis data | -| SandboxEnv | Ya + Isolasi | Banyak Giliran | Eksekusi dan pengujian kode | +| SingleTurnEnv | Tidak | Tidak | Tanya jawab satu giliran, soal matematika | +| ToolEnv | Tidak | Multi-giliran | Pencarian + sintesis informasi | +| StatefulToolEnv | Ya | Multi-giliran | Mengubah rekaman basis data | +| SandboxEnv | Ya + terisolasi | Multi-giliran | Eksekusi kode dan pengujian | -Kerangka kerja ini mendukung *parallel sampling* dan *trajectory caching*. Lintasan lengkap (observasi, tindakan, *reward*) dari setiap evaluasi disimpan untuk analisis dan *replay* selanjutnya. +Framework ini mendukung sampling paralel dan cache trajectory; trajectory lengkap tiap evaluasi (observasi, tindakan, imbalan) disimpan sehingga mudah dianalisis dan diputar ulang. Selain itu, efek eksekusi sebuah tool bergantung pada keadaan saat itu, sehingga ketika gagal sebaiknya dikembalikan pesan kesalahan yang jelas, bukan sekadar penanda gagal, agar Agent dapat menyesuaikan strateginya. -Lingkungan juga perlu menangani ketergantungan *state* dari operasi — hasil dari *tool call* bergantung pada *state* saat ini. Saat terjadi kegagalan, ia harus memberikan pesan kesalahan yang jelas daripada sekadar tanda kegagalan sederhana, yang memungkinkan Agent untuk belajar dari kesalahan dan menyesuaikan strateginya. +Evaluasi tipe pemanggilan tool menguji kebenaran perubahan keadaan yang dapat diamati, sedangkan evaluasi tipe interaksi manusia-komputer menguji kelayakan strategi komunikasi—yang pertama memverifikasi tindakan, yang kedua memverifikasi penuntunan. Perbandingan struktur kedua tipe lingkungan dapat dilihat pada Gambar 7-2. -### Lingkungan Evaluasi Interaksi Manusia-Komputer +![Gambar 7-2: Lingkungan Evaluasi Pemanggilan Tool dan Interaksi Manusia-Komputer](images/fig7-2.svg) -Banyak tugas dunia nyata tidak hanya melibatkan *tool calls* tetapi juga percakapan dengan pengguna manusia. Agent layanan pelanggan perlu memahami ekspresi ambigu, mengklarifikasi kebutuhan, melakukan kueri ke sistem *backend*, dan mengonfirmasi informasi dengan pengguna. Mengevaluasi tugas-tugas semacam ini menghadapi tantangan mendasar: bagaimana cara menyimulasikan pengguna nyata dalam lingkungan yang otomatis? +## Desain himpunan data evaluasi -Prinsip desain utamanya adalah **Progressive Information Disclosure**, yang merupakan perbedaan mendasar antara evaluasi interaksi manusia-komputer dan *benchmark* tradisional. Kebanyakan *benchmark* mengungkapkan seluruh persyaratan di awal, tetapi pengguna nyata jarang dapat mengartikulasikan kebutuhan mereka dari awal — mereka sering kali hanya mengatakan "sepertinya ada masalah dengan penerbangan saya" atau "internet saya tidak berfungsi." Agent harus mengklarifikasi kebutuhan tersebut dengan mengajukan pertanyaan, dan proses itu sendiri merupakan wujud dari kapabilitas. Oleh karena itu, dalam evaluasi, **informasi pengguna yang disimulasikan tidak boleh diungkapkan kepada Agent sekaligus**; informasi tersebut harus diungkapkan secara progresif, sesuai permintaan, seiring dengan berjalannya percakapan. +Jika lingkungan evaluasi adalah panggung, himpunan data adalah naskahnya. Dengan lima komponen yang sama, mengganti kelas tugas bisa membuat cara pengisiannya berbeda sama sekali: dari mana tugas berasal, sedalam apa verifier dapat memeriksa, dan bagaimana mencegahnya dihafal. Bagian ini berangkat dari praktik desain beberapa benchmark publik dan berakhir pada pertanyaan yang lebih praktis—dari mana seharusnya tugas dalam himpunan evaluasi buatan sendiri berasal. -Solusi τ-bench adalah **User Simulation**: menggunakan LLM lain untuk memainkan peran pengguna, bercakap-cakap dengan Agent berdasarkan instruksi yang telah ditentukan. Pengguna yang disimulasikan menerima instruksi tugas (misalnya, "Saya perlu membatalkan penerbangan besok"), secara bertahap mengungkapkan informasi yang diperlukan kepada Agent selama percakapan, merespons pertanyaan, dan mengirimkan sinyal penghentian saat tugas selesai. *Prompt* mengharuskan pengguna yang disimulasikan untuk "tidak mengungkapkan semua informasi sekaligus, hanya berikan apa yang diperlukan untuk langkah saat ini" dan "tidak merekayasa informasi yang tidak diberikan dalam instruksi." Desain dari *user simulation* memerlukan keseimbangan antara keaslian dan kemampuan pengendalian (*controllability*): perilakunya harus mendekati pengguna nyata (ekspresi ambigu, informasi tidak lengkap, sesekali fluktuasi emosional) sekaligus mengikuti skrip tertentu untuk memastikan reproduktibilitas. +### Perbandingan menyilang keputusan desain antarbenchmark -Berikut ini adalah contoh percakapan multi-putaran dengan pengungkapan informasi progresif (simulator pengguna bertindak berdasarkan skrip tetap): +Ada atau tidaknya lawan bicara, yang dibedakan pada bagian sebelumnya, hanyalah lapis perbedaan pertama pada tataran lingkungan; perbedaan pada tataran himpunan data lebih menunjukkan pertukaran desainnya. Tabel 7-2 menyandingkan beberapa benchmark yang sering dikutip. -> **User**: "Ada masalah dengan penerbangan saya." -> **Agent**: "Penerbangan yang mana?" -> **User** (mengungkapkan sesuai skrip): "Delta 123, besok pagi dari San Francisco ke New York." -> **Agent**: "Apa masalah spesifiknya?" -> **User** (mengungkapkan sesuai skrip): "Waktu penerbangannya terlalu lama, saya ingin mengubahnya." -> **Agent**: "Ada preferensi untuk penerbangan baru?" -> **User** (mengungkapkan sesuai skrip): "Penerbangan sore mana pun boleh." +Tabel 7-2 Keputusan desain kunci beberapa benchmark Agent -Simulator pengguna mengikuti skrip tetap (informasi yang diketahui + aturan pengungkapan), memastikan reproduktibilitas evaluasi sambil menyimulasikan gaya ekspresi progresif dari pengguna nyata. Pengguna simulasi kerap juga diberi **kesabaran yang terbatas**: bila komunikasi Agent tidak efisien, pengguna simulasi dapat mengakhiri percakapan sehingga tugasnya gagal. +| Benchmark | Kemampuan yang diuji | Asal tugas | Pemeran lingkungan | Verifier | +|---|---|---|---|---| +| τ²-bench | Interaksi manusia-komputer dan pemanggilan tool pada layanan pelanggan | Ditulis manual + pembangkitan kombinatorial | Simulator pengguna + basis data bisnis | Empat lapis pemeriksaan diagregasi menjadi biner oleh `reward_basis` | +| SWE-bench Verified | Pengembangan perangkat lunak, coding | Issue nyata GitHub, disaring manual | Repositori kode + suite uji | Verifikasi ganda FAIL\_TO\_PASS / PASS\_TO\_PASS | +| AndroidWorld | Mengoperasikan GUI ponsel Android | Instansiasi templat berparameter | Emulator Android sungguhan | Asersi keadaan akhir UI | +| OSWorld | Mengoperasikan GUI desktop Linux | Mulai dari keadaan tengah yang disiapkan | Mesin virtual sungguhan | 134 fungsi evaluasi mandiri | +| Terminal-Bench | Mengoperasikan terminal Linux, coding | Ditulis manual | Kontainer Docker | Pemeriksaan sistem berkas + eksekusi nyata | +| GAIA | Asisten AI umum yang mengumpulkan informasi | Ditulis manual + lampiran khusus | Internet terbuka | Pencocokan string persis | -τ-bench adalah *benchmark* untuk mengevaluasi kinerja Agent dalam proses bisnis terstruktur (misalnya, layanan pelanggan maskapai, layanan pelanggan ritel). Pemeriksaannya berada pada tingkat komponen dan bersifat multi-dimensi: di satu sisi, ia memeriksa apakah status akhir dari *database* sudah benar (misalnya, status catatan pemesanan berubah menjadi "dibatalkan"); di sisi lain, ia memverifikasi apakah Agent memberikan informasi utama yang diperlukan selama percakapan (misalnya, jumlah pengembalian dana dan waktu kedatangan, diverifikasi dengan mencari string atau pola tertentu). Verifikasi ganda ini secara bersamaan memeriksa akurasi operasional dan efektivitas komunikasi. Namun, di tingkat tugas, semua pemeriksaan ini pada akhirnya mengerucut menjadi **binary reward nol atau satu** — semua pemeriksaan harus lulus untuk mendapatkan skor 1; satu kegagalan saja menghasilkan skor 0. *Binary rewards* membuat metrik keandalan seperti Pass^k mudah dihitung (lihat bagian "Sistem Metrik Evaluasi" nanti), dengan konsekuensi menilai "akurat secara operasional namun melewatkan satu bidang non-kritis" sama seperti "kegagalan total." +### Verifier -**τ²-bench** yang ditingkatkan pada dasarnya tidak memperbaiki granularitas penilaian; sebaliknya, ia memajukan *benchmark* dalam dua area lainnya. Pertama, **Dual-Control Environment**: Agent bukan lagi satu-satunya pihak yang dapat melakukan *tool calls* — simulator pengguna dapat beroperasi pada lingkungan bersama yang sama (Agent menginstruksikan pengguna untuk beralih ke mode pesawat, dan tindakan pengguna tersebut benar-benar mengubah *state* lingkungan), yang mana lebih sesuai dengan skenario nyata seperti dukungan teknis, di mana pengguna harus ikut membantu. Kedua, **spesifikasi tugas yang lebih presisi dan kemampuan komposisi pembuatan tugas**: lebih sedikit ambiguitas dalam kondisi keberhasilan, dan instansiasi tugas dapat diparameterisasi serta dibuat secara massal (lihat bagian "Jaminan Verifiabilitas dan Objektivitas" nanti untuk dimensi verifikasi mendetail). +Agent dengan mudah menulis laporan panjang lebar yang menyatakan tugas sudah selesai seluruhnya, padahal kenyataannya sama sekali belum. Kerangka evaluasi harus memverifikasi fakta yang bisa diperiksa mesin secara mandiri, bukan pernyataan Agent tentang dirinya sendiri. -> **Eksperimen 7-1 ★: Jalankan τ²-bench dan Bandingkan Evolusinya dari τ-bench** -> -> Eksperimen ini menjalankan kerangka kerja evaluasi τ²-bench untuk memahami prinsip desain dari lingkungan evaluasi interaksi manusia-komputer. Dengan membandingkan τ-bench dan τ²-bench, kita dapat melihat bagaimana dataset evaluasi ditingkatkan secara iteratif. -> -> Baca file definisi tugas secara mendalam: setiap tugas berisi informasi yang diketahui pengguna, instruksi tugas yang mengatur pengungkapan progresif dan strategi respons, serta kondisi keberhasilan (status target *database* dan informasi konfirmasi yang harus muncul dalam dialog). Jalankan proses evaluasi secara lengkap, amati dialog multi-putaran antara simulator pengguna dan Agent, lalu analisis mode kegagalan yang umum (pelanggaran kebijakan, penghilangan informasi, pengalihan yang berlebihan ke agen manusia, dll.). -> -> -> ![Gambar 7-3: Arsitektur Evaluasi τ²-bench](images/fig7-3.svg) -> -> -> Bandingkan perbedaan desain antara τ-bench dan τ²-bench: Versi awal τ-bench memiliki instruksi pengguna yang terlalu sederhana (Agent dapat menebak jawabannya), kondisi keberhasilan yang kurang presisi (menyebabkan salah penilaian), dan simulator pengguna yang mekanis. τ²-bench membuat peningkatan sistematis untuk mengatasi masalah ini: -> -> - **Memperkenalkan instruksi tugas yang lebih mendetail**: Termasuk "Grounding Requirements," yang berarti respons harus didasarkan pada *state* lingkungan yang sebenarnya -> - **Kriteria evaluasi yang lebih presisi**: Misalnya, "uji kecepatan harus mengembalikan 'excellent' agar dianggap terselesaikan" -> - **Spesifikasi perilaku simulator pengguna yang lebih realistis**: Pengungkapan informasi progresif, fluktuasi emosional alami -> -> Berikan perhatian khusus pada tugas domain telekomunikasi yang baru ditambahkan di τ²-bench, dan pahami desain *dual-control environment* milik τ²-bench (seperti yang disebutkan sebelumnya, pengguna dan Agent secara bersama-sama mengoperasikan lingkungan bersama yang sama). -> - -Evaluasi *tool calling* menanyakan apakah perubahan *state* yang dapat diobservasi telah diselesaikan; evaluasi interaksi manusia-komputer menanyakan apakah Agent telah membantu pengguna mencapai pemahaman baru atau membuat keputusan. Yang pertama menguji kebenaran tindakan Agent; yang kedua menguji keandalan dari strategi komunikasinya. +**SWE-bench Verified menguraikan "perbaikan selesai" menjadi dua proposisi mandiri.** Yang satu adalah FAIL\_TO\_PASS: gagal sebelum diperbaiki dan lolos sesudahnya, yang membuktikan masalahnya memang terselesaikan. Yang lain adalah PASS\_TO\_PASS: lolos baik sebelum maupun sesudah, yang membuktikan tidak ada cacat baru yang masuk. Bila hanya yang pertama diperiksa, Agent bisa lolos dengan menghapus atau mengubah asersi yang menghalangi; bila hanya yang kedua, sama saja dengan tidak memeriksa. Hanya dengan memeriksa keduanya, "sudah diperbaiki" dan "tidak merusak apa pun" menjadi dua kesimpulan yang masing-masing dapat dibuktikan. Ia juga memastikan kestabilan uji itu sendiri, menyingkirkan uji tidak stabil (flaky test) yang kadang lolos kadang gagal. -Membangun lingkungan evaluasi juga menyinggung tentang lingkungan simulasi—ketika lingkungan evaluasi harus mendukung interaksi berulang dalam skala besar, itu menjadi lingkungan simulasi. Bagian akhir bab ini akan membahas hal ini secara singkat. +**Verifier OSWorld mampu menemukan keadaan yang tampak selesai tetapi sebenarnya keliru.** Ia dilengkapi 134 fungsi evaluasi mandiri dan hak akses penuh ke sistem operasi, sehingga dapat memeriksa struktur sistem berkas, keadaan proses, koneksi jaringan, dan keadaan internal aplikasi. Pada tugas basis data, skrip evaluasi tidak hanya memastikan berkas laporan ada, tetapi juga menyambung ke basis data untuk memastikan SQL benar-benar dijalankan; pada tugas peramban ia mengurai pohon DOM, memeriksa cookie dan localStorage, serta mengirim permintaan verifikasi ke backend untuk memastikan formulirnya benar-benar berlaku. -## Desain Dataset Tugas Evaluasi +**Tugas `build-linux-kernel-qemu` pada Terminal-Bench** menuntut kernel Linux 6.9 dibangun dari sumber, menambahkan printk kustom di `start_kernel`, membuat initramfs, dan menjalankannya di QEMU; kriteria keberhasilannya adalah munculnya pesan kustom itu di log boot. Agent tidak bisa memalsukan keluaran—ia harus benar-benar menuntaskan seluruh prosesnya. -Lingkungan evaluasi adalah "panggung," dan dataset adalah "skrip." Kualitas skrip sering kali lebih menentukan nilai dari evaluasi daripada panggungnya sendiri. Dataset yang dirancang dengan buruk, bahkan ketika dijalankan di lingkungan yang sempurna, hanya akan menghasilkan *noise*. Bagian ini menyarikan beberapa prinsip yang tervalidasi secara berulang dari praktik desain berbagai *benchmark* seperti GAIA, AndroidWorld, SWE-Bench Verified, τ-bench dan τ²-bench, Terminal-Bench, OSWorld, dan OSWorld-Verified. - -> **Eksperimen 7-2 ★: Jalankan Tugas Benchmark Secara Manual** -> -> Pilih beberapa tugas dari masing-masing GAIA, AndroidWorld, SWE-Bench Verified, τ²-bench, Terminal-Bench, dan OSWorld-Verified, lalu selesaikan secara manual. Disarankan untuk menyelesaikan satu tugas sederhana, satu sedang, dan satu sulit dari setiap dataset—tingkat "sulit" seharusnya menantang bahkan bagi manusia. Bandingkan hasil eksekusi Anda dengan jawaban standar dan analisis sumber perbedaannya. Melalui pengalaman langsung ini, pahamilah: deskripsi tugas perlu menyeimbangkan antara kejelasan dan keterbukaan, standar verifikasi harus objektif dan dapat dieksekusi, serta tingkat kesulitan hierarkis dari tugas harus mampu membedakan tingkat kapabilitas yang berbeda. -> +### Pembagian tingkat kesulitan tugas -### Tantangan Inti dalam Desain Dataset Tugas +Himpunan tugas evaluasi perlu memuat tugas dengan tingkat kesulitan berbeda. Dengan begitu, ketika kemampuan model meningkat, himpunan tugas evaluasi tidak cepat usang. -**Tantangan Pertama: Ketegangan Antara Kejelasan dan Keterbukaan.** Deskripsi tugas harus cukup jelas untuk memastikan evaluasi yang dapat direproduksi, namun tidak terlalu kaku sehingga melumpuhkan kreativitas Agent. GAIA memberikan sebuah contoh: tugas-tugasnya "secara konseptual sederhana" tetapi memiliki jalur implementasi yang terbuka—misalnya, sebuah tugas mungkin mengharuskan Agent untuk mengidentifikasi seorang astronaut dari NASA Astronomy Picture of the Day dan menentukan berapa lama mereka berada di luar angkasa. Tujuannya jelas, tetapi bagaimana cara mencari, memfilter, dan memverifikasi sepenuhnya bergantung pada pengambilan keputusan otonom dari Agent. +Seluruh 466 soal GAIA dibagi menjadi tiga tingkat kesulitan: Level 1 cukup dengan satu atau dua tool (manusia 93,9%, GPT-4 30,3%), Level 2 menuntut penalaran bertahap (91,8% berbanding 9,7%), dan Level 3 menuntut komposisi rumit (87,3% berbanding 0%). Pelapisan ini bukan sekadar menandai kesulitan, tetapi juga bernilai diagnostik: kegagalan di Level 1 menunjuk pada penggunaan tool dasar, Level 2 pada perencanaan bertahap dan pemaduan informasi, dan Level 3 pada penalaran runtun panjang dan pengelolaan kerumitan, dan ketiganya mengarah ke arah perbaikan yang berlainan. -**Tantangan Kedua: Menyeimbangkan Keaslian dan Kemampuan Pengendalian.** Tugas dunia nyata mengandung ketidakpastian dan *noise*, yang dapat mengungkapkan *robustness* namun juga mengancam reproduktibilitas. Versi awal SWE-Bench secara langsung menggunakan *GitHub issues* nyata, yang memastikan keaslian tetapi juga mengarah pada deskripsi tugas yang ambigu, *test cases* yang tidak lengkap, dan kriteria evaluasi yang subjektif. SWE-Bench Verified memperkenalkan validasi sistematis oleh pakar manusia, memilih 500 tugas berkualitas tinggi dengan masalah yang terdefinisi secara jelas, pengujian yang memadai, dan solusi yang terang, secara signifikan meningkatkan kemampuan pengendalian sambil tetap mempertahankan keaslian. +Terminal-Bench mencakup mulai dari pendaftaran model mlflow yang sederhana, pembobolan kata sandi 7z berkesulitan menengah, integrasi banyak komponen server git dan webserver yang sulit, sampai analisis sandi diferensial FEAL yang paling berat. -**Tantangan Ketiga: Mengoordinasikan Keberagaman dan Sistematisasi.** Dataset yang efektif perlu mencakup skenario tipikal, *edge cases*, dan jebakan kesalahan, sekaligus memiliki organisasi yang sistematis sehingga hasil evaluasi dapat mendiagnosis kelemahan kapabilitas spesifik. 116 tugas di AndroidWorld tersebar di 20 aplikasi nyata, masing-masing dianotasi dengan kapabilitas inti yang dibutuhkannya (perencanaan multi-langkah, pemahaman visual, penalaran temporal) — sehingga hasil tidak hanya memberikan tingkat keberhasilan secara keseluruhan tetapi juga profil kekuatan dan kelemahan di sepanjang dimensi kapabilitas yang spesifik. Yang lebih penting, mekanisme parameterisasi dapat menghasilkan varian tugas dalam jumlah yang nyaris tak terbatas. +τ²-bench bahkan merancang khusus **tugas jebakan**: pengguna mengaku "layanan pelanggan sudah menyetujui pembatalan" padahal sebenarnya tidak sesuai kebijakan, untuk menguji apakah Agent tetap menjaga penilaian yang benar di bawah tekanan dan penyesatan. -**Tantangan Keempat: Biaya Evaluasi vs. Cakupan.** Tugas Agent yang kompleks dapat memakan waktu beberapa menit atau bahkan berjam-jam untuk diselesaikan, sehingga menghabiskan sejumlah besar token. Ukuran dataset perlu menyeimbangkan antara kelengkapan dan nilai ekonomi. GAIA secara cermat memilih 466 tugas di tiga tingkat kesulitan, yang mencakup berbagai dimensi kapabilitas sambil tetap memungkinkan evaluasi dengan biaya yang wajar. SWE-Bench Verified memangkas jumlahnya dari 2.294 tugas menjadi 500 (mengurangi biaya hingga sekitar empat perlima sambil meningkatkan *signal-to-noise ratio* melalui standar kualitas yang lebih ketat). +### Pencegahan kebocoran data -**Tantangan Kelima: Mencegah Kontaminasi Data.** Di era model bahasa besar, kontaminasi data menjadi tantangan serius bagi evaluasi: saat data evaluasi disertakan dalam data pelatihan, maka evaluasi akan mengukur hafalan dan bukan generalisasi. Ini seperti menghafal jawaban sebelum ujian—nilai bagus tidak mencerminkan kemampuan sebenarnya. Berbagai *benchmark* mengadopsi strategi pencegahan yang berbeda: GAIA bergantung pada keunikan jawabannya; pertanyaan memerlukan penggabungan informasi dari berbagai sumber untuk dijawab, dan beberapa tugas dilengkapi dengan file lampiran yang dibuat secara khusus (PDF/audio/gambar yang tidak ada di internet), sehingga satu halaman web tidak dapat secara langsung memberikan jawaban. SWE-Bench Verified sendiri merupakan subset berisi 500 tugas yang diperoleh oleh OpenAI melalui penyaringan kualitas manual dari SWE-Bench orisinal, dan tidak menyertakan desain pencegahan kebocoran berbasis waktu. Justru karya lanjutan seperti SWE-bench-Live yang benar-benar menggunakan kebaruan temporal untuk mencegah kebocoran, dengan terus-menerus memasukkan *issues* yang dibuat setelah tanggal batas pelatihan model (*training cutoff*), sehingga menjaga evaluasi agar selalu berada di depan korpus pelatihan model. τ²-bench mencegah kebocoran melalui pembuatan parameter yang dinamis, di mana instansiasi tugas spesifik (nama pengguna, nomor pesanan, tanggal, dll.) dibuat secara acak setiap saat. Pembuatan tugas terparameter dari AndroidWorld secara alami membantu mencegah kebocoran karena verifikasi didasarkan pada status UI akhir, bukan urutan operasi. Terminal-Bench membuat kebocoran dapat dideteksi dengan menyematkan GUID *canary* (pengidentifikasi unik global yang digunakan sebagai penanda pelacakan): jika model dapat menghasilkan keluaran yang mengandung GUID ini, hal tersebut mengindikasikan bahwa data *benchmark* telah bocor ke set pelatihan. +**GAIA membuat jawabannya tidak dapat dicari langsung di internet.** Tugasnya sederhana secara konsep tetapi jalannya terbuka: misalnya, berangkat dari Astronomy Picture of the Day NASA pada tanggal tertentu, mengenali astronaut dalam foto, mencari kelompok astronaut tempatnya bernaung, menghitung siapa dari kelompok itu yang paling singkat berada di antariksa, dan mengeluarkannya persis dalam format "nama belakang, dipisahkan titik koma, dengan pemisah ribuan". Jawabannya sangat spesifik dan benar tidaknya ditentukan oleh pencocokan string persis. Pencegahan kebocoran bersandar pada dua hal: pertama, pertanyaannya hanya terjawab bila beberapa sumber informasi dipadukan sehingga tak ada satu halaman web pun yang langsung memberi jawaban; kedua, sebagian tugas disertai lampiran yang dibuat khusus (PDF, audio, dan gambar yang tidak ada di internet). -### Desain Presisi dari Deskripsi Tugas +**AndroidWorld menurunkan banyak instansi dari satu templat.** Tugasnya bukan teks statis melainkan templat yang dapat diinstansiasi secara dinamis, misalnya "ubah nomor telepon kontak `[CONTACT_NAME]` menjadi `[NEW_PHONE]`", dengan nilai parameter dibangkitkan acak pada tiap evaluasi. Ini memberi tiga keuntungan: parameter selalu berbeda sehingga memutar ulang urutan operasi yang tetap menjadi sia-sia; satu templat dapat melahirkan instansi yang nyaris tak terbatas; dan dengan mengunci sebagian parameter serta mengubah sisanya, pengaruh satu faktor tertentu dapat diukur dengan tepat. -GAIA memastikan keunikan jawaban melalui batasan sumber informasi yang jelas, rentang waktu, topik, dan target kueri. Misalnya, tugas Level 3 mengharuskan memulai dari gambar NASA pada tanggal tertentu, mengidentifikasi astronaut tersebut melalui pemahaman visual, mencari grup astronaut tempat mereka bergabung, menghitung waktu mereka di luar angkasa, dan memformat keluarannya secara presisi ("nama belakang; kolom dipisahkan oleh titik koma; angka diformat dengan pemisah ribuan"). Setiap detail mendukung verifikasi otomatis—hanya kecocokan persis pada format dan konten yang dihitung sebagai lulus. +**Terminal-Bench menyisipkan penanda kenari pada teks soal.** Tiap soal membawa canary GUID; bila sebuah model mampu mengeluarkan isi yang memuat GUID itu, berarti data benchmark sudah masuk ke himpunan latih. Ini tidak mencegah kebocoran, tetapi membuatnya dapat dideteksi. -τ²-bench memperkenalkan desain kontekstual, dengan setiap tugas yang berisi beberapa lapisan informasi: masalah permukaan ("data seluler tidak berfungsi"), ekspektasi kinerja ("memerlukan peringkat kecepatan excellent"), batasan ("tidak akan menerima peringkat lainnya"), dan emosi yang tersirat. Peningkatan utamanya adalah memisahkan "informasi yang diketahui" dari "instruksi tugas": informasi yang diketahui adalah apa yang saat ini diketahui oleh pengguna, sementara instruksi tugas memandu simulator tentang bagaimana cara mengungkapkan informasi secara progresif, termasuk "Grounding Requirements" (respons harus didasarkan pada hasil aktual yang dikembalikan oleh *tool calls*, bukan direkayasa). +### Kendali mutu dan pemeliharaan jangka panjang -SWE-Bench Verified mencakup bidang-bidang terstruktur seperti deskripsi masalah, langkah-langkah reproduksi, dan perilaku yang diharapkan/aktual, dengan anotorator yang memverifikasi kecocokan antara deskripsi dan *test cases*. Setiap elemen dalam deskripsi tugas Terminal-Bench dapat diverifikasi secara mekanis: apakah jalur file ada, nilai izin sudah benar, parameter sertifikat valid, dan format tanggal sudah benar. Misalnya, "build-linux-kernel-qemu" mengharuskan pembuatan kernel Linux 6.9 dari sumber, menambahkan `printk` kustom di `start_kernel`, menghasilkan `initramfs`, dan menjalankannya di QEMU. Kriteria keberhasilannya adalah kemunculan pesan kustom pada log *boot*—Agent tidak bisa memalsukan keluarannya; ia harus benar-benar menyelesaikan seluruh proses. +Membuat himpunan evaluasi bermutu tinggi sangatlah sulit. Bentuk sekarang dari sebagian besar benchmark di atas adalah hasil perbaikan berulang setelah versi pertamanya dipakai dan masalahnya tersingkap. Dari τ-bench ke τ²-bench, misalnya, ada lima tempat yang dirancang ulang. -AndroidWorld menggunakan desain **parameterized template**. Sebuah tugas bukanlah teks statis, melainkan templat yang dapat diinstansiasi secara dinamis (misalnya, "Ubah nomor telepon dari kontak `[CONTACT_NAME]` menjadi `[NEW_PHONE]`), dengan nilai parameter berbeda yang dihasilkan secara acak untuk setiap evaluasi. Ini memiliki tiga manfaat: +Pertama, **instruksi tugas terlalu umum sehingga jawabannya bisa ditebak**. Instruksi versi pertama ditulis luas, sehingga model tak perlu benar-benar menjernihkan permintaan—menebak satu prosedur dari akal sehat saja sudah cukup untuk lolos. τ²-bench membelah naskah menjadi dua ruas, `known_info` dan `task_instructions`: yang pertama membatasi apa yang diketahui pengguna, yang kedua mengatur cara pengungkapannya. Apa yang tidak diketahui pengguna tak bisa ditebak Agent dan hanya bisa diperoleh dengan menelusuri. -- **Mencegah hafalan**: Nilai parameter berbeda setiap saat, mencegah terulangnya urutan operasi yang tetap -- **Meningkatkan keberagaman data**: Satu templat dapat menghasilkan instansiasi dalam jumlah yang nyaris tak terbatas -- **Mendukung eksperimen komparatif**: Menetapkan parameter tertentu sambil memvariasikan yang lain memungkinkan pengukuran yang presisi atas efek dari faktor-faktor spesifik +Kedua, **syarat keberhasilan kurang cermat sehingga verifikasi salah menilai**. Syarat semacam "jaringan sudah pulih" tidak punya batas yang dapat diperiksa. τ²-bench mengubahnya menjadi "dianggap selesai hanya bila hasil tes kecepatan excellent; poor, fair, dan good semuanya tidak diterima". Perubahan ini menyasar **perbaikan asal jadi**, yaitu menekan gejala tanpa menuntaskan akar masalah. -Verifikasi didasarkan pada status UI akhir (misalnya, apakah kolom nomor telepon berisi nilai yang diharapkan), bukan urutan operasi. +Ketiga, **perilaku simulator pengguna terlalu mekanis**. Pengguna simulasi versi pertama hanya menjawab secara pasif. τ²-bench menambahkan emosi (menunjukkan ketidakpuasan setelah perbaikan pertama gagal), batas kesabaran (memutus percakapan bila komunikasi terlalu tidak efisien), dan syarat pengaitan fakta. Ketiganya bekerja bersama sehingga simulator mendekati pengguna nyata sambil tetap dapat direproduksi. -Tugas OSWorld sering kali tidak dimulai dari *state* awal yang "bersih," melainkan dari *state* perantara yang dikonfigurasi dengan hati-hati, yang lebih menyerupai skenario penggunaan dunia nyata. Deskripsi tugas perlu menangani banyak solusi ("atur latar belakang menjadi ungu" memerlukan kode warna spesifik untuk disambiguasi; "gabungkan dua CSV" harus menerima semua metode yang masuk akal seperti mempertahankan satu baris tajuk (*header*) atau keduanya) dan ketidakpastian lingkungan (langkah anti-pengikisan di situs web, UI aplikasi yang terus berkembang, dan *race conditions*—OSWorld-Verified memitigasi hal ini melalui *snapshot* halaman *offline*, mengunci versi dependensi, kondisi tunggu eksplisit, dll.). +Keempat, **pengguna tidak hanya terlibat dalam percakapan, tetapi juga dalam pengoperasian**. Domain telecom memperkenalkan lingkungan kendali ganda. Pada evaluasi sebelumnya hanya Agent yang dapat mengubah lingkungan, padahal pada skenario dukungan teknis sebagian besar tindakan semestinya dilakukan pengguna sendiri di perangkatnya. Kendali ganda juga menambah satu dimensi pada verifikasi: setelah pengguna mengubah keadaan, Agent harus memanggil tool lagi untuk mengetahui hasilnya, sehingga verifikasi kini mencakup "apakah Agent benar-benar membaca hasil tindakan di sisi pengguna". -Daftar ini tidak mencakup seluruh lanskap evaluasi Agent. Bahkan di dalam kategori Web/GUI, terdapat beberapa *benchmark* dengan penekanan yang berbeda: WebArena membangun situs web yang sepenuhnya dapat direproduksi (*e-commerce*, forum, *code hosting*, dll.), yang mewadahi ketidakpastian halaman web nyata di dalam sebuah *sandbox*; Mind2Web menempuh jalur yang berlawanan, menguji generalisasi secara langsung di ratusan situs web nyata; [ClawBench](https://claw-bench.com/) ([makalah](https://arxiv.org/abs/2604.08523), [kode](https://github.com/TIGER-AI-Lab/ClawBench)) membiarkan Agent yang berjalan di dalam kontainer terisolasi melakukan tugas sehari-hari *end-to-end* di situs web yang *live*. V1 mencakup 153 tugas di 144 situs web, V2 menambahkan 130 lagi, dan ia mencatat lima lapisan bukti secara paralel: *session replays*, tangkapan layar tindakan, lalu lintas HTTP, tindakan *browser*, dan pesan Agent. Ini melengkapi *benchmark sandboxed* dengan membuat *live-site drift* dan *long-tail failures* lebih mudah dianalisis, dengan konsekuensi reproduktibilitas yang tunduk pada perubahan di situs web pihak ketiga; BrowseComp mengkhususkan diri pada pencarian mendalam — jawaban yang terkubur begitu dalam sehingga hanya penelusuran *multi-hop* dan *cross-checking* yang dapat memunculkannya. Di sisi *tool calling*, terdapat *leaderboard function-calling* khusus seperti BFCL (Berkeley Function-Calling Leaderboard). Bab ini tidak bermaksud untuk mendaftar semuanya. Alih-alih, bab ini mengambil dua paradigma lingkungan inti (*tool calling* dan interaksi manusia-komputer), ditambah skenario operasi GUI yang ada di sepanjang studi kasus dataset, dan menggali *trade-off* desain dari semuanya. Setelah Anda memahami paradigma tersebut, Anda dapat dengan cepat menilai apa yang diukur oleh *benchmark* baru apa pun, seberapa baik ia mencegah kebocoran data, dan seberapa jauh kesimpulannya dapat diekstrapolasi. +Kelima, **instansi tugas dibangkitkan secara dinamis**. Instansi konkret τ²-bench (nama pengguna, nomor, kombinasi gangguan) dapat diparameterkan dan dibangkitkan secara massal, yang sekaligus memperbaiki cakupan dan ketahanan terhadap kebocoran. -### Desain Hierarkis dari Kompleksitas Tugas +**SWE-bench Verified: sebelum dirilis, 71% tugas aslinya disingkirkan.** OpenAI mengambil acak 1.699 dari 2.294 tugas asli untuk dievaluasi manusia, dan merekrut 93 pengembang yang mahir Python untuk memeriksanya satu per satu: apakah deskripsi masalahnya jelas, apakah kasus ujinya mencakup kondisi batas, apakah ujinya stabil, apakah patch rujukan memasukkan kesalahan baru, dan apakah kesulitannya wajar. Pada akhirnya hanya 500 yang lolos. Tingkat penyingkiran yang tinggi menghasilkan rasio sinyal terhadap derau yang lebih baik, dan biaya evaluasi pun turun sekitar 80%. Tugas Agent yang rumit lazimnya butuh beberapa menit sampai beberapa jam, dan menjalankan satu himpunan evaluasi secara penuh dengan model terdepan kerap menelan ribuan dolar biaya token, sehingga menekan biaya evaluasi sangatlah penting. -GAIA merancang tiga tingkat kesulitan: Level 1 hanya memerlukan 1-2 *tools* (manusia 93,9% vs GPT-4 30,3%), Level 2 memerlukan penalaran multi-langkah (91,8% vs 9,7%), dan Level 3 memerlukan kombinasi yang kompleks (87,3% vs 0%). Nilai diagnostik dari desain hierarkis ini adalah: kegagalan di Level 1 menunjuk pada masalah penggunaan *tool* dasar, Level 2 menunjuk pada perencanaan multi-langkah dan integrasi informasi, dan Level 3 menunjuk pada penalaran urutan panjang dan manajemen kompleksitas. Setiap tingkat sesuai dengan arah peningkatan yang berbeda (*prompt engineering* vs. mekanisme perencanaan vs. arsitektur hierarkis/*post-training*). +**OSWorld: dalam 15 bulan setelah dirilis muncul lebih dari 300 masalah.** Dirilis pada April 2024, ia cepat menjadi benchmark penting bagi evaluasi Agent multimodal, tetapi pemakaian luas berikutnya menyingkap empat jenis masalah: masalah lingkungan (situs yang menangkal scraping, CAPTCHA, perubahan konten dinamis), masalah deskripsi tugas (rumusan yang bermakna ganda), masalah logika verifikasi (terlalu ketat atau terlalu longgar), dan masalah keadaan awal (konfigurasi tidak lengkap). Tim dari Universitas Hong Kong membentuk kelompok sekitar 10 orang dan selama dua bulan bekerja erat dengan MoonShot AI, OpenAI, ByteDance Seed TARS, Anthropic, Simular, dan lainnya untuk memperbaikinya secara sistematis: masalah lingkungan diatasi dengan mengunci versi dan cadangan offline, masalah deskripsi dengan menulis ulang rumusan yang bermakna ganda, masalah verifikasi dengan membangun garis dasar yang benar secara manual lalu menyetel syaratnya, dan masalah keadaan awal dengan menambah pemeriksaan kelengkapan. -τ²-bench menyusun kompleksitas berdasarkan proses bisnis: mulai dari kueri informasi sederhana, menuju proses multi-langkah (mengubah pemesanan penerbangan memerlukan kueri, menyajikan alternatif, mendapatkan konfirmasi, menghitung selisih tarif, dan memproses pembayaran), ke diagnosis kesalahan (memeriksa secara sistematis berbagai kemungkinan penyebab dan memverifikasi perbaikan), dan terakhir ke penilaian strategis (menangani permintaan yang tidak mematuhi kebijakan). - -Terminal-Bench menyusun kompleksitas berdasarkan dimensi ganda yaitu domain teknis × kompleksitas operasional. Registri tugasnya telah mengumpulkan lebih dari 200 tugas (ukuran set evaluasi intinya bervariasi bergantung pada versi; misalnya, versi 2.0 memilih 89 tugas berkualitas tinggi dari kontribusi komunitas), mulai dari registrasi model MLflow sederhana, ke pemecahan kata sandi 7-Zip dengan kesulitan sedang, ke integrasi server Git dan server web yang sulit, hingga kriptanalisis diferensial FEAL yang paling sulit (memerlukan pengetahuan kriptografi + optimasi algoritma untuk memenuhi batasan waktu 30 detik). - -### Memastikan Verifiabilitas dan Objektivitas - -Jawaban GAIA ringkas dan jelas. Aturan format yang ketat memungkinkan verifikasi melalui pencocokan string yang persis. Hasil biner (cocok atau tidak cocok) memastikan reproduktibilitas yang objektif. Kelangkaan jawaban juga berfungsi sebagai langkah anti-kecurangan—fakta yang sangat spesifik kecil kemungkinannya muncul secara harfiah (verbatim) dalam data pelatihan. +> **Eksperimen 7-2 ★: Mengerjakan tugas benchmark secara manual** +> +> Pilih tugas dari GAIA, AndroidWorld, SWE-Bench Verified, Terminal-Bench, dan OSWorld-Verified lalu kerjakan sendiri; disarankan satu mudah, satu sedang, dan satu sulit untuk tiap himpunan data. Tingkat "sulit" pun menantang bagi manusia. +> +> Setelah selesai, jawab dua pertanyaan. Apakah deskripsi tugas itu memuat lebih dari satu tafsir yang masuk akal, dan bila ya, tafsir mana yang diakui verifier? Jika Anda mencoba lolos tanpa benar-benar mengerjakannya, apa jalur termurahnya, dan mampukah verifier menghadangnya? -SWE-Bench Verified menggunakan pemeriksaan berbasis kode yang dapat dieksekusi, membedakan antara FAIL_TO_PASS (gagal sebelum perbaikan, lulus setelah perbaikan, membuktikan masalah telah terpecahkan) dan PASS_TO_PASS (lulus baik sebelum maupun sesudah perbaikan, membuktikan tidak ada bug baru yang dimasukkan), mencapai verifikasi ganda. Versi Verified juga memastikan bahwa pengujiannya sendiri dapat diandalkan, tanpa *flaky tests* (pengujian tidak stabil) yang kadang lulus dan kadang gagal. +### Tiga asal himpunan evaluasi -Sistem verifikasi τ²-bench mencakup beberapa lapisan pemeriksaan (hasil setiap lapisan tetap diagregasikan ke dalam *reward* biner pada tingkat tugas; semuanya harus lulus untuk mencapai kesuksesan): +Ada pandangan umum bahwa benchmark publik hanya melayani pemeringkatan model dan sedikit kaitannya dengan bisnis nyata. Memang benar skor benchmark publik sulit langsung memandu keputusan produk, tetapi teknik desainnya sangat mudah dipindahkan. Kedalaman verifikasi, pembangkitan berparameter, pencegahan kebocoran, dan pemeliharaan mutu—yang dibahas di atas—justru merupakan bagian yang paling mudah terlewat dalam himpunan evaluasi buatan sendiri. -- **Pemeriksaan status database**: Status catatan pemesanan, apakah catatan pengembalian dana (refund) telah dibuat -- **Pencarian kata kunci konten dialog**: Apakah Agent secara eksplisit mengonfirmasi jumlah pengembalian dana dan perkiraan waktu tiba kepada pengguna -- **Kepatuhan proses**: Analisis urutan pemanggilan tool (tool call), misalnya, apakah konfirmasi eksplisit dari pengguna telah diperoleh sebelum memodifikasi pesanan +Himpunan evaluasi di lingkungan produksi biasanya punya tiga asal. -Lingkungan kontrol ganda (dual-control) dari τ²-bench (lihat bagian sebelumnya "Lingkungan Evaluasi Interaksi Manusia-Komputer") menambahkan dimensi lain pada verifikasi: setelah simulator pengguna benar-benar mengubah keadaan lingkungan, Agent harus mengamati perubahan ini melalui pemanggilan tool (tool call) dan melanjutkan dengan pemecahan masalah yang sesuai. Oleh karena itu, verifikasi mencakup apakah Agent benar-benar mengamati hasil dari tindakan pengguna. +**Benchmark publik** dipakai untuk penyaringan kasar model dan untuk meminjam teknik desain, dan umumnya bukan untuk keputusan produk. Distribusi tugasnya tidak sama dengan distribusi tugas bisnis nyata; naik dua poin persentase di GAIA tidak berhubungan secara niscaya dengan tingkat keberhasilan pengembalian dana. -OSWorld menyediakan 134 fungsi evaluasi independen dengan akses OS penuh, memungkinkan inspeksi mendalam terhadap struktur sistem file, status proses, koneksi jaringan, dan internal aplikasi. Misalnya, dalam tugas operasi database, skrip evaluasi tidak hanya memverifikasi bahwa file laporan ada tetapi juga langsung terhubung ke database untuk memeriksa apakah SQL dieksekusi dengan benar. Dalam tugas browser, ia menganalisis pohon DOM, memeriksa cookies/localStorage, dan mengirimkan permintaan verifikasi ke backend untuk mengonfirmasi apakah pengiriman formulir benar-benar berhasil. Inspeksi mendalam ini dapat mendeteksi kasus "penyelesaian dangkal tetapi kesalahan substantif"—misalnya, Agent mengklik tombol kirim, tetapi permintaan ditolak oleh server karena isian bidang yang salah. +**Himpunan bisnis buatan sendiri** mencakup distribusi tugas yang sebenarnya dan dapat menjadi dasar pemilihan model serta keputusan desain Harness. Misalnya, τ²-bench dapat langsung dipakai sebagai kerangka bagi sistem evaluasi mana pun yang memerlukan pengguna simulasi; cukup ganti data domain dan perangkat toolnya. -Terminal-Bench didasarkan pada lingkungan kontainer Docker standar, menggabungkan pemeriksaan status sistem file (keberadaan jalur, nilai izin, format konten) dengan verifikasi fungsional eksekusi program (dalam build-linux-kernel-qemu, benar-benar memulai QEMU dan mencari pesan printk khusus). Canary GUID membuat kebocoran (leakage) dapat dilacak. +**Aliran balik trajectory produksi** berasal dari kegagalan nyata di lapangan: koreksi eksplisit dari pengguna, penilaian buruk dari pengguna, serta kasus yang ditemukan belakangan lewat pemeriksaan keadaan, verifier berbasis aturan, atau tinjauan LLM. Setelah melalui atribusi kegagalan, semuanya mengendap menjadi kasus regresi. Caranya diuraikan nanti pada bagian "Atribusi kegagalan" dan "Tugas regresi ujung ke ujung dan tugas regresi trajectory prefix". Asal ini paling mahal sekaligus paling akurat, karena datang langsung dari masalah yang benar-benar dialami pengguna. -### Desain Sistematis Distribusi Tugas +Pada tahap awal biasanya hanya ada benchmark publik dan sedikit himpunan bisnis yang ditulis tangan; setelah sistem berjalan beberapa lama di produksi, kasus yang mengalir balik dari trajectory produksi menjadi bagian terbesar. -Distribusi tugas perlu secara sistematis mencakup dimensi kemampuan, dimensi kesulitan, dimensi skenario, dan kasus ekstrem (edge cases). GAIA mengejar generalitas—sebagian besar tugas membutuhkan kombinasi penalaran, multimodalitas, penjelajahan (browsing), dan penggunaan alat (tool use). τ²-bench secara sengaja merancang "tugas jebakan"—pengguna mengklaim "layanan pelanggan telah menyetujui pembatalan" ketika pembatalan tersebut sebenarnya tidak sesuai dengan kebijakan—untuk menguji apakah Agent mempertahankan penilaiannya di bawah tekanan dan penyesatan. OSWorld didasarkan pada matriks dimensi ganda dari tipe operasi (file IO / aplikasi desktop / aplikasi web / alur kerja lintas aplikasi) dan domain aplikasi, yang mencakup tiga sistem operasi (penelitian menunjukkan korelasi lintas OS yang kuat; keterampilan yang dipelajari pada satu sistem dapat ditransfer ke sistem lain). Terminal-Bench mencakup "tugas kombinasi tumpukan teknologi lintas (cross-technology stack)" untuk menguji pemikiran sistem (misalnya, tugas *resharding* yang menggabungkan pemrosesan data + operasi file + rekayasa Python). +## Metode evaluasi otomatis -### Kontrol Kualitas Data dan Peningkatan Iteratif +Benchmark yang dibahas pada bagian-bagian sebelumnya punya satu kesamaan: verifier-nya hampir semuanya deterministik. SWE-bench menjalankan suite uji, AndroidWorld mengasersi keadaan akhir UI, GAIA melakukan pencocokan string persis, dan empat lapis pemeriksaan τ²-bench pun seluruhnya dijalankan oleh kode. Pilihan ini punya alasan kuat: verifikasi deterministik tidak menambah ongkos model, hasilnya sepenuhnya dapat direproduksi, dapat dimasukkan ke integrasi berkelanjutan seperti uji unit, dan memudahkan pemeringkatan antarmodel. -SWE-Bench Verified adalah model kontrol kualitas. OpenAI secara acak memilih 1.699 tugas dari 2.294 tugas asli untuk evaluasi manusia, merekrut 93 pengembang yang mahir Python. Para anotator harus melakukan beberapa pemeriksaan: apakah deskripsi masalahnya jelas (dapatkah mereka memahami apa yang perlu dipecahkan), apakah test case-nya lengkap (mencakup semua aspek dan kasus ekstrem), apakah pengujiannya stabil (tidak ada *flaky tests* karena lingkungan atau keacakan), apakah patch-nya benar (apakah itu memasukkan kesalahan baru), dan apakah tingkat kesulitannya masuk akal. Setelah penyaringan yang ketat, hanya 500 yang lulus (29%)—tingkat penolakan yang tinggi ini merupakan investasi yang diperlukan dalam kualitas evaluasi. Mereka juga menetapkan pedoman anotasi standar, mendefinisikan kriteria dan contoh spesifik untuk setiap pemeriksaan guna memastikan konsistensi di antara anotator yang berbeda. +Harganya, ia hanya dapat menilai benar tidaknya hasil akhir, tetapi tidak dapat memberi sebab kesalahannya. Tugas τ²-bench yang gagal berakhir dengan nilai 0, dan angka 0 itu tidak menjelaskan apakah Agent salah pada tahap pemilihan jalur atau melewatkan langkah pengisian kuota, apalagi menunjukkan apa yang harus diubah berikutnya. Bagi benchmark publik yang dipakai untuk pemeringkatan, ini bukan cacat; bagi sistem produksi yang perlu perbaikan berkelanjutan, justru itulah informasi yang paling dibutuhkan. -τ²-bench memperkenalkan pemisahan "informasi yang diketahui" / "instruksi tugas" (membuat perilaku simulator lebih realistis) dan kondisi penyelesaian yang lebih ketat (misalnya, "hanya *excellent* yang dihitung sebagai selesai; *poor*/*fair*/*good* tidak diterima"), mencegah "perbaikan dangkal." +Skenario produksi punya kesulitan kedua: banyak penilaian sama sekali tidak dapat ditulis sebagai asersi yang bisa diperiksa kode. Apakah balasan atas keluhan sudah pantas, apakah sebuah laporan riset melewatkan informasi kunci, apakah penelusuran memori salah mengaitkan hubungan antarorang—semua ini tidak punya satu keadaan akhir yang bisa ditelusuri, dan juga tak bisa diputuskan dengan pencocokan kata kunci. -OSWorld-Verified adalah model peningkatan iteratif. Setelah dirilis pada bulan April 2024, OSWorld dengan cepat menjadi benchmark penting untuk evaluasi Agent multimodal, tetapi selama lebih dari 15 bulan penggunaan luas, lebih dari 300 masalah terungkap. Masalah-masalah ini terbagi dalam empat kategori: masalah lingkungan (tindakan anti-scraping di situs web, CAPTCHA, dan perubahan konten dinamis), masalah deskripsi tugas (kalimat yang ambigu), masalah logika verifikasi (terlalu ketat atau terlalu longgar), dan masalah keadaan awal (konfigurasi yang tidak lengkap). Sebuah tim yang terdiri dari sekitar 10 orang dari University of Hong Kong bekerja sama dengan MoonShot AI, OpenAI, ByteDance Seed TARS, Anthropic, Simular, dan lainnya selama dua bulan untuk secara sistematis memperbaiki masalah-masalah ini. Strategi perbaikan dirumuskan untuk setiap kategori: masalah lingkungan diselesaikan dengan mengunci versi dan cadangan offline, deskripsi tugas diperjelas dengan menulis ulang kalimat yang ambigu, logika verifikasi diseimbangkan dengan menetapkan *baseline* yang benar secara manual dan menyesuaikan kondisi, dan keadaan awal ditingkatkan dengan menambahkan pemeriksaan kelengkapan. +Karena itu, dalam beranjak dari benchmark publik ke evaluasi di lingkungan produksi, cara verifikasi perlu bergeser ke kanan sepanjang satu spektrum yang sumbu mendatarnya adalah **derajat keterverifikasian mekanis** sebuah tugas, seperti pada Gambar 7-4. -## Metode Evaluasi Otomatis +![Gambar 7-4: Spektrum cara verifikasi—dari verifikasi deterministik ke penilaian model](images/fig7-4.svg) -Dengan lingkungan evaluasi, dataset, dan sistem metrik yang jelas, pertanyaan intinya menjadi: bagaimana cara menilai? Untuk tugas-tugas dengan jawaban benar yang jelas (misalnya, soal matematika, kueri SQL), penilaian biner sederhana (benar/salah) sudah cukup; tetapi untuk tugas-tugas terbuka (misalnya, dialog layanan pelanggan, penulisan laporan), metode evaluasi yang lebih disempurnakan diperlukan. +Dua perkakas di sisi kanan spektrum itulah yang kemudian menjadi tumpuan evaluasi produksi: **Rubric** memecah "bagus atau tidak" yang kabur menjadi beberapa dimensi yang dapat dinilai terpisah, dan **LLM-as-a-Judge** memberi nilai ketika tidak ada patokan deterministik. Hanya bila keduanya digabung, tingkat kegagalan yang kabur dapat dikembalikan menjadi masalah konkret yang bisa ditangani; dipadukan dengan **atribusi kegagalan** pada paruh kedua bagian ini, terbentuklah lingkar tertutup evaluasi Agent produksi yang lengkap. -Verifikasi otomatis berbasis kode hanya mencakup skenario dengan jawaban standar; penilaian tugas-tugas terbuka adalah topik utama dari bagian ini. Di antaranya, desain kepadatan sinyal reward (dari reward biner ke reward proses hingga reward generatif) dan metode pelatihan untuk model reward dibiarkan untuk diskusi sistematis di bagian pasca-pelatihan (post-training) pada Bab 8; bagian ini menjawab pertanyaan yang lebih mendasar: bagaimana menggunakan LLM untuk secara otomatis menilai kualitas output dari tugas-tugas terbuka. +Perlu ditegaskan, bergeser ke kanan tidak berarti meninggalkan sisi kiri. Setiap pemeriksaan yang dapat ditulis sebagai asersi program sebaiknya tetap berupa asersi, dan penilaian LLM hanya dipakai untuk dimensi yang memang tak dapat diputuskan secara mekanis. Pemeriksaan deterministik lebih murah dan lebih stabil, serta lebih cocok dijalankan jangka panjang sebagai uji regresi. ### LLM-as-a-Judge: Inti dari Evaluasi Otomatis -![Gambar 7-4: Pipeline LLM-as-a-Judge](images/fig7-4.svg) +![Gambar 7-5: Pipeline LLM-as-a-Judge](images/fig7-5.svg) Mengapa LLM-as-a-Judge dibutuhkan? Untuk tugas terbuka (misalnya, membuat laporan, menangani keluhan pelanggan, konten kreatif), tidak ada jawaban standar untuk perbandingan otomatis, dan evaluasi manusia memakan biaya besar serta sulit untuk diskalakan. LLM-as-a-Judge menyeimbangkan skalabilitas otomatisasi dengan penilaian pakar manusia dengan menyuruh model bahasa mengevaluasi output terhadap kriteria penilaian yang ditentukan pakar (sebuah Rubric). Meski begitu, metode ini memiliki keterbatasan yang diketahui: model juri membawa biasnya sendiri (paling umum **bias panjang (length bias)**—kecenderungan untuk memberi skor lebih tinggi pada tanggapan yang lebih panjang dan lebih detail bahkan ketika mereka tidak lebih benar), dan penilaian berulang dari input yang sama dapat bervariasi. Bias panjang secara khusus memerlukan tindakan pencegahan khusus. Tiga pertahanan umum adalah: hukum (penalize) kata-kata yang berlebihan (verbosity) secara eksplisit dalam Rubric dan batasi panjang tanggapan per jenis tugas; dalam perbandingan berpasangan (pairwise), bawa kedua kandidat ke panjang yang sama sebelum menilai; dan secara teratur mengaudit korelasi antara skor dan panjang tanggapan—jika skor tinggi hampir selalu diberikan pada tanggapan yang panjang, juri telah terpengaruh oleh panjang dan Rubric tersebut memerlukan revisi. Untuk mengatasi tantangan ini secara sistematis, desain Rubric harus mengikuti prinsip-prinsip di bawah ini: @@ -363,7 +364,7 @@ rubric: Kirim Rubric bersama respons aktual Agent ke model penilai untuk memperoleh skor dan alasan per dimensi. Setelah puluhan hasil dikumpulkan, putar ulang jejak yang nilainya rendah. Penurunan tingkat keberhasilan yang semula samar lalu dapat dipecah menjadi diagnosis konkret: informasi tidak ditemukan, hubungan antartokoh keliru, atau jawaban menambahkan hal yang tidak didukung data. Dengan demikian Rubric bukan hanya memberi nilai, tetapi juga menunjukkan bagian yang perlu diperbaiki. -Berikut ini memakai memori pengguna sebagai kasus konkret, untuk menunjukkan bagaimana metode umum ini diturunkan menjadi set evaluasi dan penilai yang dapat dijalankan. +Berikut ini memakai memori pengguna sebagai kasus konkret, untuk menunjukkan bagaimana metode umum ini diturunkan menjadi set evaluasi dan verifier yang dapat dijalankan. > **Eksperimen 7-3 ★★: Membangun Sistem Evaluasi User Memory Berbasis Rubric** > @@ -532,7 +533,7 @@ Dalam pemilihan model secara praktis, kita sering menghadapi pertanyaan: "Mana y ### Pairwise Comparison dan Peringkat Model -![Gambar 7-5: Peringkat Elo dan Peringkat Pairwise Comparison](images/fig7-5.svg) +![Gambar 7-6: Peringkat Elo dan Peringkat Pairwise Comparison](images/fig7-6.svg) **Elo Rating** (sebuah sistem peringkat yang awalnya dirancang untuk catur) mengukur kemampuan relatif model melalui sejumlah besar pertandingan berpasangan (pairwise matchups): semakin besar perbedaan peringkat, semakin tinggi tingkat kemenangan yang diharapkan untuk model yang lebih kuat. Misalnya, jika Model A memiliki peringkat 1200 dan Model B memiliki peringkat 1000, sistem Elo akan memprediksi tingkat kemenangan A sekitar 76%. Jika B secara tak terduga menang, B mendapatkan lebih banyak poin dan A kehilangan lebih banyak—sebuah kejutan (upset) memicu koreksi yang lebih besar, yang memungkinkan peringkat konvergen dengan cepat pada kemampuan sebenarnya. Fondasi statistik ini adalah **Bradley-Terry model**: setiap model diabstraksikan sebagai "skor kekuatan" laten, dan probabilitas satu model mengalahkan model lain dalam sebuah pertandingan ditentukan oleh perbedaan antara skor mereka. Elo adalah implementasi rekayasa dari model ini dalam bentuk pembaruan online. @@ -694,7 +695,7 @@ Ketika memverifikasi beberapa hipotesis secara paralel, pertimbangkan pula **per Keputusan yang didorong oleh evaluasi (baik untuk pemilihan model atau iterasi berkelanjutan) bergantung pada data operasional berkualitas tinggi. Di bawah ini, pertama-tama kita akan memperkenalkan cara mengumpulkan data ini secara sistematis (observabilitas), dan kemudian mendiskusikan cara menerjemahkan hasil evaluasi menjadi perbaikan sistem. -![Gambar 7-6: Tumpukan Teknologi Observabilitas](images/fig7-6.svg) +![Gambar 7-7: Tumpukan Teknologi Observabilitas](images/fig7-7.svg) Observabilitas adalah konsep yang dipinjam dari sistem terdistribusi: Anda tidak dapat membuka sistem dan melihatnya bekerja; Anda menyimpulkan apa yang terjadi dari log, metrik, dan jejak (traces) yang dipancarkannya—cara seorang dokter, tidak dapat melihat ke dalam diri seorang pasien, mendiagnosis dari suhu tubuh, tekanan darah, dan pencitraan medis. Sistem Agent membuat hal ini menjadi lebih sulit: input yang sama dapat menghasilkan output yang berbeda, penalaran multi-ronde dan pemanggilan tool membuat alur eksekusi menjadi sangat kompleks, dan "thinking" (pemikiran) model sepenuhnya buram dari luar. @@ -714,7 +715,7 @@ Dengan sistem evaluasi dan dataset yang komprehensif, kuncinya adalah menerjemah Berikut adalah proses tuning AndroidWorld nyata yang tersimpan di repositori pendamping. Pilot ini hanya mencakup empat tugas pengaturan Wi-Fi pada emulator API 35, dengan satu eksekusi berpasangan per tugas. Ini bukan benchmark lengkap 116 tugas dan bukan pengganti pengujian ulang pada lingkungan standar API 33. Nilainya adalah menunjukkan bagaimana hasil satu putaran menentukan satu perubahan pada putaran berikutnya, bukan membuktikan peningkatan sistem secara keseluruhan. -![Gambar 7-7: Lingkaran Benchmark ke Perbaikan](images/fig7-7.svg) +![Gambar 7-8: Lingkaran Benchmark ke Perbaikan](images/fig7-8.svg) Dari sudut pandang rekayasa Harness, bagian ini pada dasarnya adalah tentang metodologi untuk optimisasi Harness berulang (iterative Harness optimization)—menggunakan data evaluasi untuk mengidentifikasi titik lemah di Harness (konteks tidak cukup? kurang batasan? validasi tidak memadai? umpan balik (feedback) tidak tepat waktu?), membuat perbaikan yang ditargetkan, dan kemudian mengevaluasi kembali, membentuk putaran tertutup (closed loop) untuk evolusi Harness yang berkelanjutan. @@ -823,7 +824,7 @@ Titik akhir dari evaluasi bukanlah penskoran, melainkan perbaikan. Bab ini telah Beginilah cara dua ujung jembatan ini bertemu. Aset-aset yang terakumulasi di sisi evaluasi dikonversi hampir tanpa hambatan menjadi sinyal pelatihan: Rubric atau validator yang terdefinisi dengan baik pada dasarnya adalah fungsi *reward* untuk **Reinforcement Learning with Verifiable Rewards (RLVR)**—skrip penskoran menjadi skrip *reward*; apakah sebuah pengujian lulus atau suatu *state* memenuhi standar, berfungsi baik sebagai kriteria evaluasi maupun sebagai *reward* untuk *reinforcement learning*. Namun pelatihan membawa tuntutan yang tidak pernah perlu dikhawatirkan oleh evaluasi. Yang pertama adalah **semantik reset yang andal (*reliable reset semantics*)**: pelatihan menjalankan jutaan *episode* (sebuah episode adalah satu ronde interaksi yang lengkap dari status awal hingga penyelesaian tugas), dan setiap episode harus mampu me-reset lingkungan ke kondisi awal yang bersih dan deterministik; jika tidak, sinyal gradien akan terkontaminasi oleh status sisa dari episode sebelumnya. Yang kedua adalah ***throughput* yang jauh melebihi evaluasi**: beberapa ribu evaluasi sudah cukup untuk menarik kesimpulan, tetapi pelatihan memerlukan model untuk diumpankan jutaan interaksi dalam *wall-clock time* yang dapat diterima; tingkat paralelisme lingkungan dan *overhead* per *instance* secara langsung menentukan apakah pelatihan tersebut layak. Kedua hal ini—validator yang diubah menjadi *reward function*, serta *reset* dan *throughput* tingkat pelatihan (*training-grade*)—akan diuraikan di Bab 8. -![Gambar 7-8: Spektrum Fidelitas Simulasi](images/fig7-8.svg) +![Gambar 7-9: Spektrum Fidelitas Simulasi](images/fig7-9.svg) Di sisi **lingkungan digital**, *framework* AWorld membangun *sandbox* MCP server yang dapat dikontrol untuk tugas-tugas GAIA, menyediakan 26 MCP server yang mencakup 126 fungsi *tool*, menghindari larangan akses (*bans*) dan efek samping yang tidak dapat dikontrol dari mengakses API nyata secara langsung. Semua pemanggilan *tool* bersifat *replayable* dan dapat diaudit. Arsitektur terdistribusi AWorld mengurangi waktu eksekusi serial tradisional dari 7695 detik menjadi 525 detik (percepatan 14.6x), dan desain *stateless* pada lingkungan tersebut membuat setiap *instance* sepenuhnya independen, mendukung paralelisme yang efisien. @@ -833,7 +834,7 @@ Di sisi **lingkungan berwujud fisik (*embodied environment*)**, RoboTwin2 memban > > Siapkan lingkungan simulasi untuk manipulasi robot. Baca `ch7/SimpleVLA-RL` dan dokumentasi OpenVLA untuk memahami arsitektur dari model Vision-Language-Action (integrasi *end-to-end* dari *vision encoder*, *language model*, dan *action decoder*, yang memproyeksikan gambar dan teks ke dalam ruang semantik bersama). Konfigurasikan lingkungan RoboTwin2, pahami *observation space* (tiga pandangan RGB + 14-dimensi *joint state*) dan *action space* (14-dimensi vektor kontrol). Pelajari mekanisme pengacakan lingkungan dan logika batasan spasial dalam `move_can_pot`. Evaluasi model prapelatihan (*pretrained model*), catat tingkat keberhasilannya, waktu penyelesaian, dan mode kegagalan, dengan fokus pada dampak dari mekanisme *action chunking*. > -> ![Gambar 7-9: Lingkungan Kecerdasan Terwujud OpenVLA dan RoboTwin2](images/fig7-9.svg) +> ![Gambar 7-10: Lingkungan Kecerdasan Terwujud OpenVLA dan RoboTwin2](images/fig7-10.svg) ### Pertukaran Fidelity dan Domain Randomization @@ -843,7 +844,7 @@ Lingkungan high-fidelity mendukung transfer yang lebih baik ke dunia nyata tetap ## Ringkasan Bab -Bab ini berpusat pada satu pertanyaan: bagaimana kita tahu bahwa Agent benar-benar membaik? Lingkungan yang dapat direproduksi, dataset tahan leakage, LLM sebagai penilai, serta model selection dan iterasi berbasis hasil semuanya menentukan keandalan kesimpulan. Eksperimen nyata memberi empat peringatan tambahan: menggabungkan memori terstruktur dan RAG tidak menjamin sinergi; penghematan cache dan kompresi tidak dapat dijumlahkan; pilihan audio referensi mengubah makna skor multimodal; dan kemampuan Agent membaca UI beserta biaya token-nya bergantung pada cara Harness menyajikan input. Model selection harus membandingkan kurva kemampuan pada berbagai anggaran, bukan satu titik. Evaluasi produksi adalah validasi berkelanjutan yang tertanam dalam keputusan produk. +Bab ini berpusat pada satu pertanyaan: bagaimana kita tahu bahwa Agent benar-benar membaik? Rantainya terdiri atas empat tahap: pertama menjernihkan apa yang dihitung sebagai keberhasilan (perbedaan basis Pass@k, Best@k, dan Pass consecutive@k), lalu menetapkan dari mana tugas berasal (benchmark publik, himpunan bisnis buatan sendiri, dan aliran balik trajectory produksi), kemudian memilih cara verifikasi (dari verifier deterministik ke daftar pemeriksaan, Rubric dengan penilaian LLM, hingga perbandingan berpasangan), dan akhirnya mengubah skor menjadi keputusan (signifikansi statistik, atribusi kegagalan, tugas regresi, dan pemilihan model). Setiap tahap menentukan keandalan kesimpulan. Eksperimen nyata memberi empat peringatan tambahan: menggabungkan memori terstruktur dan RAG tidak menjamin sinergi; penghematan cache dan kompresi tidak dapat dijumlahkan; pilihan audio referensi mengubah makna skor multimodal; dan kemampuan Agent membaca UI beserta biaya token-nya bergantung pada cara Harness menyajikan input. Model selection harus membandingkan kurva kemampuan pada berbagai anggaran, bukan satu titik. Evaluasi produksi adalah validasi berkelanjutan yang tertanam dalam keputusan produk. Dilihat dari struktur buku secara keseluruhan, bab ini membangun ruas **bukti** dalam lingkar penemuan Bab 1: atribusi kegagalan menentukan apakah usulan berikutnya punya pijakan yang kukuh. diff --git a/book-id/images/fig7-1.svg b/book-id/images/fig7-1.svg index f811b567c..ac1975f7f 100644 --- a/book-id/images/fig7-1.svg +++ b/book-id/images/fig7-1.svg @@ -1,20 +1,62 @@ - - - - -Lapisan 1: Evaluasi Lingkungan -"Di mana menguji" — Pemanggilan alat (Tool-calling) / Interaksi manusia-komputer / Lingkungan simulasi - - -Lapisan 2: Metode Evaluasi -"Bagaimana menilai" — Desain dataset · LLM-as-a-Judge · Perbandingan berpasangan dan pemeringkatan - - -Lapisan 3: Keputusan Berbasis Evaluasi -"Apa yang harus dilakukan setelah pengujian" — Pemilihan model · Optimalisasi arsitektur · Iterasi berkelanjutan - -Tema Rekayasa di Seluruh Bab -• Observabilitas -• Lingkungan simulasi -• Evaluasi internal - \ No newline at end of file + + + + + + + + +① Definisi keberhasilan +Pass@k mengukur batas atas · Pass^k mengukur keandalan + + + +② Asal tugas + +Benchmark publik +Pinjam teknik · saring kasar + +Himpunan bisnis sendiri +Distribusi tugas nyata + +Aliran balik produksi +Hasil atribusi kegagalan + + + +③ Cara verifikasi +← menurut derajat keterverifikasian mekanis tugas → + +Deterministik +SWE-bench + + +Daftar pemeriksaan +τ²-bench + + +Rubric + LLM +Tugas terbuka + + +Berpasangan +Chatbot Arena + + + +④ Pemanfaatan hasil +Signifikansi → Atribusi → Tugas regresi → Model dan Harness + + +Tugas regresi menjadi kasus baru + + +Infrastruktur penopang +Observabilitas · Infrastruktur evaluasi internal (ablasi / AB / feature flag) · Simulasi (Bab 8) + diff --git a/book-id/images/fig7-10.svg b/book-id/images/fig7-10.svg new file mode 100644 index 000000000..76207591f --- /dev/null +++ b/book-id/images/fig7-10.svg @@ -0,0 +1,70 @@ + + + + + +Observasi multimodal + +Kamera kepala +224×224 RGB + +Kamera pergelangan tangan kiri +224×224 RGB + +Kamera pergelangan tangan kanan +224×224 RGB + +Vektor status sendi 14 dimensi + +Model Vision-Language-Action (VLA) + +Encoder visi +SigLIP → token visual + + +Model bahasa +Backbone Llama 2 7B + + +Decoder aksi +→ Vektor kontrol kontinu 14 dimensi +Action chunking: menghasilkan 25 aksi berturut-turut sekaligus + + + +Instruksi: "Masukkan kaleng ke dalam panci" + + +Mesin fisika SAPIEN + +Robot lengan ganda +Masing-masing 7 DOF = aksi 14 dimensi + +Pengacakan lingkungan +Posisi 60cm / orientasi ±22.5° + +Deteksi tabrakan + simulasi fisika +Benda tegar / benda lunak / gesekan + +Aksi + +Observasi + +Metrik evaluasi + +Tingkat keberhasilan +Kaleng di dalam panci +dan tidak jatuh + +Waktu penyelesaian +25 langkah × 25 aksi += 625 langkah kontrol + +Kemampuan generalisasi +Lintas posisi/orientasi +/Varian penampilan + +Sim-to-Real +Pengacakan domain +→ Migrasi nyata + \ No newline at end of file diff --git a/book-id/images/fig7-3.svg b/book-id/images/fig7-3.svg index 87b366e6f..1adc4083c 100644 --- a/book-id/images/fig7-3.svg +++ b/book-id/images/fig7-3.svg @@ -1,69 +1,76 @@ - - - + + + + + + + - -Simulator Pengguna (LLM) - -Informasi yang Diketahui: -Nama: Sarah Johnson -Pemesanan: BK-98712 -Instruksi Tugas: -"Sepertinya ada masalah dengan penerbangan" -→ Mengungkapkan detail secara bertahap -→ Jangan memberikan nomor pemesanan secara proaktif - -Agent (Yang Akan Dievaluasi) - - -Penalaran LLM + Pemilihan Strategi -① Boleh saya minta nomor pemesanan Anda? -② lookup_booking(BK-98712) -③ Penerbangan UA123 telah dibatalkan -④ cancel_booking(BK-98712) -⑤ Pengembalian dana $150, 3-5 hari kerja - -Tools + Database - -lookup_booking -Kueri detail pemesanan -modify_booking -Ubah status pemesanan -cancel_booking -Batal dan kembalikan dana -search_flights -Cari penerbangan alternatif -send_notification -Kirim notifikasi konfirmasi - -Status DB: -bookings, users, flights - -Dialog - - -Panggilan Tool - - -Lingkungan kontrol ganda: Simulator pengguna juga dapat langsung mengoperasikan lingkungan bersama (Tool + database) - -Setelah tugas selesai: Verifikasi berlapis - -Pemeriksaan status DB - -booking.status == 'cancelled' -refund_record EXISTS -refund.amount == 150.00 - -Verifikasi konten dialog - -Berisi 'pengembalian dana' + jumlah -Berisi 'waktu kedatangan' -Tidak ada informasi palsu - -Pemeriksaan kepatuhan proses - -Dapatkan konfirmasi pengguna sebelum modifikasi -Tidak ada operasi yang tidak sah -Tidak ada transfer berlebihan ke agen manusia - \ No newline at end of file + + +Simulator pengguna (LLM) +known_info: John Smith / 555-123-2002 / di Prancis +task_instructions: pengungkapan · emosi · grounding +Penerimaan: hanya excellent dianggap selesai + + + +Agent (yang dievaluasi) +Masukan: tiket + kebijakan domain +Tak terlihat: keadaan nyata perangkat +Hanya bisa menuntun, tak bisa menggantikan + + + +Dialog multi-giliran +Pengungkapan bertahap + + + +Lingkungan bersama (kendali ganda: kedua sisi mengubah keadaan) + +Keadaan sisi perangkat +Mode pesawat ON · roaming OFF · hemat data · sisa kuota +Tool pengguna: toggle_airplane_mode / toggle_roaming + check_status_bar / run_speed_test + +Basis data sisi operator +Pelanggan C1001 · jalur L1001/L1002/L1003 · paket · tagihan +Tool Agent: get_customer_by_phone / get_data_usage + enable_roaming / refuel_data + + + + + + +toggle_roaming pengguna mengubah lingkungan; Agent harus memanggil tool lagi — verifikasi mencakup pembacaan ulang ini + + + +Setelah tugas: empat lapis pemeriksaan + aturan agregasi + +env_assertions +Data seluler tersedia +Kecepatan ≥ 200 / excellent + +actions +toggle_airplane_mode +requestor harus user + +communicate_info +Apakah info penting disampaikan +null pada tugas ini + +nl_assertions +Penilaian tataran bahasa alami +null pada tugas ini +reward_basis = ["ENV_ASSERTION"] → hanya lapis pertama dipakai; sisanya dicatat tetapi tak masuk imbalan + diff --git a/book-id/images/fig7-4.svg b/book-id/images/fig7-4.svg index 3f64753c2..2a87732f4 100644 --- a/book-id/images/fig7-4.svg +++ b/book-id/images/fig7-4.svg @@ -1,54 +1,54 @@ - - - + + + + + + - -Rubrik - -Kebenaran Faktual: Sangat Penting -Koherensi Logis: Penting -Deteksi Halusinasi: Veto ⚠ -Kelengkapan: Penting - -Jawaban Kandidat - -Output Agent: -"Pengembalian dana diproses, $150 akan dikreditkan dalam - 3-5 hari kerja." - - -Solusi Referensi (Opsional) - -Jawaban Standar / Poin Penilaian: -Harus menyertakan jumlah pengembalian dana -Harus menyertakan waktu kredit -Tidak dapat menjanjikan tanggal spesifik - - - - -Model Juri (GPT-5 / Gemini 2.5) -Evaluasi heterogen multi-sumber mencegah bias sumber yang sama - - -Output evaluasi terstruktur - -Kebenaran Faktual -4/4 -Jumlah dan waktu keduanya akurat -Kelengkapan -3/4 -Penjelasan metode pengembalian dana tidak ada -Deteksi Halusinasi -LULUS -Tidak ada informasi palsu -Koherensi Logis -4/4 -Hubungan sebab akibat yang jelas - -Strategi Agregasi Penilaian -Rata-rata tertimbang: Σ(bobot × skor dimensi) -Veto: Halusinasi=GAGAL → skor total=0 -Multi-juri: median dari 3 juri -Penanda kasus ekstrem: ketidaksepakatan >2 poin → tinjauan manusia - \ No newline at end of file + +Keterverifikasian mekanis tugas: tinggi +rendah + + +Deterministik +Keadaan akhir tunggal & terperiksa +Lolos / tidak +SWE-bench menjalankan uji + + + +Daftar pemeriksaan +Beberapa pemeriksaan deterministik +Diagregasi menurut basis deklarasi +Empat lapis τ²-bench + + + +Rubric + LLM +Dimensi ada, kode tak bisa +Nilai per dimensi dengan alasan +Mutu layanan, penulisan laporan + + + +Berpasangan +Dimensinya pun sulit dirumuskan +Hanya menilai A lawan B +Chatbot Arena + + +Verifikasi deterministik +Sepenuhnya reproducible, cocok CI, murah +Harga: hanya benar/salah, bukan letak masalah + + +Penilaian model +Memberi dimensi diagnostik, mencakup yang tak terasersikan +Harga: bias & ragam penilaian, biaya lebih tinggi + diff --git a/book-id/images/fig7-5.svg b/book-id/images/fig7-5.svg index 86e2d5cec..3f64753c2 100644 --- a/book-id/images/fig7-5.svg +++ b/book-id/images/fig7-5.svg @@ -1,57 +1,54 @@ - + - -Pertarungan Anonim Chatbot Arena - -Model A (Anonim) - -"Pengembalian dana diproses, akan tiba dalam 3-5 - hari kerja ke akun Anda" -VS - -Model B (Anonim) - -"Oke, pengembalian dana akan diproses" - - -Pilihan buta pengguna → A lebih baik - -Rumus Pembaruan Elo -Tingkat kemenangan diharapkan E_A = 1/(1+10^((R_B-R_A)/400)) | Pembaruan: R_A' = R_A + K*(1-E_A) -Papan Peringkat Langsung (Contoh) -Peringkat -Model -Elo -Tingkat kemenangan vs #2 - -1 -Claude 4 Opus -1352 -— -2 -GPT-5 -1318 -— -3 -Gemini 2.5 Pro -1290 -45% -4 -DeepSeek R2 -1265 -42% -5 -Qwen 3 Max -1230 -39% -6 -Llama 4 405B -1198 -36% - - -GRPO: Memperkenalkan Perbandingan Berpasangan ke dalam Pelatihan RL -Sekumpulan respons kandidat → Normalisasi keuntungan relatif → Pembaruan kebijakan (melewati model reward eksplisit) + +Rubrik + +Kebenaran Faktual: Sangat Penting +Koherensi Logis: Penting +Deteksi Halusinasi: Veto ⚠ +Kelengkapan: Penting + +Jawaban Kandidat + +Output Agent: +"Pengembalian dana diproses, $150 akan dikreditkan dalam + 3-5 hari kerja." + + +Solusi Referensi (Opsional) + +Jawaban Standar / Poin Penilaian: +Harus menyertakan jumlah pengembalian dana +Harus menyertakan waktu kredit +Tidak dapat menjanjikan tanggal spesifik + + + + +Model Juri (GPT-5 / Gemini 2.5) +Evaluasi heterogen multi-sumber mencegah bias sumber yang sama + + +Output evaluasi terstruktur + +Kebenaran Faktual +4/4 +Jumlah dan waktu keduanya akurat +Kelengkapan +3/4 +Penjelasan metode pengembalian dana tidak ada +Deteksi Halusinasi +LULUS +Tidak ada informasi palsu +Koherensi Logis +4/4 +Hubungan sebab akibat yang jelas + +Strategi Agregasi Penilaian +Rata-rata tertimbang: Σ(bobot × skor dimensi) +Veto: Halusinasi=GAGAL → skor total=0 +Multi-juri: median dari 3 juri +Penanda kasus ekstrem: ketidaksepakatan >2 poin → tinjauan manusia \ No newline at end of file diff --git a/book-id/images/fig7-6.svg b/book-id/images/fig7-6.svg index 3b793659a..86e2d5cec 100644 --- a/book-id/images/fig7-6.svg +++ b/book-id/images/fig7-6.svg @@ -1,49 +1,57 @@ - - - -Pohon jejak eksekusi (tugas tunggal) - -Jejak: Cek cuaca Beijing untuk pengguna besok (3,2d, $0,008) - -LLM Call: Pengenalan niat -Claude 4 Sonnet · 0,4d · 320 tokens - -Tool：get_weather(Beijing) -MCP Server · 1,8d · 200ms TTFT - -├─ HTTP Request -api.weather.com · 1,6d - -└─ Response Parse -JSON → Data cuaca terstruktur - -LLM Call: Buat respons -Claude 4 Sonnet · 0,8d · 580 tokens - -Tool：send_message(user) -0,2d · Berisi ringkasan cuaca - - - - - - - -Dasbor pemantauan - -Pelacakan biaya -Hari ini: $12,30 (1.200 panggilan) -Bulan ini: $340 (34K panggilan) -Anomali: task#892 melakukan pencarian berulang 14 kali, biaya $2,1 - -Pemantauan performa -Latensi P50 / P95 / P99: 2,1d / 8,4d / 15,2d -Tingkat keberhasilan Tool: 94,3% - -Audit kualitas -Tingkat keberhasilan tugas: 87% Pemicu halusinasi: 2,1% -Pelanggaran keamanan: 0 (bulan ini) Kepuasan pengguna: 4,3/5 - -Siklus tertutup: Data jejak → Identifikasi masalah → Pengujian A/B →Manajemen versi Prompt → Optimasi berkelanjutan + + + + +Pertarungan Anonim Chatbot Arena + +Model A (Anonim) + +"Pengembalian dana diproses, akan tiba dalam 3-5 + hari kerja ke akun Anda" +VS + +Model B (Anonim) + +"Oke, pengembalian dana akan diproses" + + +Pilihan buta pengguna → A lebih baik + +Rumus Pembaruan Elo +Tingkat kemenangan diharapkan E_A = 1/(1+10^((R_B-R_A)/400)) | Pembaruan: R_A' = R_A + K*(1-E_A) +Papan Peringkat Langsung (Contoh) +Peringkat +Model +Elo +Tingkat kemenangan vs #2 + +1 +Claude 4 Opus +1352 +— +2 +GPT-5 +1318 +— +3 +Gemini 2.5 Pro +1290 +45% +4 +DeepSeek R2 +1265 +42% +5 +Qwen 3 Max +1230 +39% +6 +Llama 4 405B +1198 +36% + + +GRPO: Memperkenalkan Perbandingan Berpasangan ke dalam Pelatihan RL +Sekumpulan respons kandidat → Normalisasi keuntungan relatif → Pembaruan kebijakan (melewati model reward eksplisit) \ No newline at end of file diff --git a/book-id/images/fig7-7.svg b/book-id/images/fig7-7.svg index 6dd62a6c5..3b793659a 100644 --- a/book-id/images/fig7-7.svg +++ b/book-id/images/fig7-7.svg @@ -1,57 +1,49 @@ - - - - -① Observasi: Laporan Diagnostik -Tingkat Keberhasilan Keseluruhan: 88% (102/116) -transcription: 0% complex_ui: 17% -math_counting: 0% Wi-Fi Operation: 0% -Task 82,102-115 Kegagalan Terkonsentrasi - -② Hipotesis: Kerangka Perbaikan Tiga Lapis - -Lapisan Permukaan -H1 Set Navigasi Prompt H2 Aturan UI - -Lapisan Menengah -H3 Perbaikan Pipeline Multimodal H4 Pemikiran - -Lapisan Dalam -H5 GPT-5 H6 Pohon Elemen UI - - -③ Eksperimen: Validasi Bertahap (5 kali jalan × 116 tugas per konfigurasi) - -H1 Navigasi -Setup 0%→75% -token+8% - -H3 Multimodal -Transkripsi 0%→80% -Latensi +1d - -H4 Pemikiran -Penghitungan 0%→70% -Latensi 3x! - -H6 Pohon Elemen -UI 17%→52% -token+30% - -④ Keputusan: Trade-off Biaya-Manfaat -✓ H1+H3: Biaya Rendah, Manfaat Tinggi → Deploy -✗ H4: Hanya 8% Tugas Bermanfaat tapi Latensi 3x → Tolak -✓ H6: 35% Peningkatan / 30% Biaya → Deploy -✗ H5: 15d/Langkah Tidak Dapat Diterima → Alternatif - -⑤ Iterasi: Siklus Baru -Deploy H1+H3+H6 → 88%→94% -Laporan Baru Menunjukkan Mode Kegagalan Berbeda: - H7: Conditional Thinking Enabled - H8: Expand gesture action space - -↑ Loop - -Metodologi: Observasi → Hipotesis → Eksperimen → Keputusan → Iterasi = Dari alkimia ke rekayasa ilmiah + + + +Pohon jejak eksekusi (tugas tunggal) + +Jejak: Cek cuaca Beijing untuk pengguna besok (3,2d, $0,008) + +LLM Call: Pengenalan niat +Claude 4 Sonnet · 0,4d · 320 tokens + +Tool：get_weather(Beijing) +MCP Server · 1,8d · 200ms TTFT + +├─ HTTP Request +api.weather.com · 1,6d + +└─ Response Parse +JSON → Data cuaca terstruktur + +LLM Call: Buat respons +Claude 4 Sonnet · 0,8d · 580 tokens + +Tool：send_message(user) +0,2d · Berisi ringkasan cuaca + + + + + + + +Dasbor pemantauan + +Pelacakan biaya +Hari ini: $12,30 (1.200 panggilan) +Bulan ini: $340 (34K panggilan) +Anomali: task#892 melakukan pencarian berulang 14 kali, biaya $2,1 + +Pemantauan performa +Latensi P50 / P95 / P99: 2,1d / 8,4d / 15,2d +Tingkat keberhasilan Tool: 94,3% + +Audit kualitas +Tingkat keberhasilan tugas: 87% Pemicu halusinasi: 2,1% +Pelanggaran keamanan: 0 (bulan ini) Kepuasan pengguna: 4,3/5 + +Siklus tertutup: Data jejak → Identifikasi masalah → Pengujian A/B →Manajemen versi Prompt → Optimasi berkelanjutan \ No newline at end of file diff --git a/book-id/images/fig7-8.svg b/book-id/images/fig7-8.svg index 1fa05d3b8..6dd62a6c5 100644 --- a/book-id/images/fig7-8.svg +++ b/book-id/images/fig7-8.svg @@ -1,42 +1,57 @@ - + - - -Akurasi simulasi → -Skalabilitas - - - -↑ - -Mock API -level unit test -jutaan kali/jam - -AWorld -MCP sandbox -126 fungsi tool -525d/ronde terdistribusi - -AndroidWorld -Simulator -116 tugas aplikasi dunia nyata -UI Automator - -Isaac Gym -Paralelisme GPU -ribuan instans paralel -Akurasi sedikit berkurang - -RoboTwin2 -mesin fisika -Tabrakan presisi tinggi -CPU instans tunggal - -dunia nyata -Akurasi sempurna -Tidak dapat direset - + +① Observasi: Laporan Diagnostik +Tingkat Keberhasilan Keseluruhan: 88% (102/116) +transcription: 0% complex_ui: 17% +math_counting: 0% Wi-Fi Operation: 0% +Task 82,102-115 Kegagalan Terkonsentrasi + +② Hipotesis: Kerangka Perbaikan Tiga Lapis + +Lapisan Permukaan +H1 Set Navigasi Prompt H2 Aturan UI + +Lapisan Menengah +H3 Perbaikan Pipeline Multimodal H4 Pemikiran + +Lapisan Dalam +H5 GPT-5 H6 Pohon Elemen UI + + +③ Eksperimen: Validasi Bertahap (5 kali jalan × 116 tugas per konfigurasi) + +H1 Navigasi +Setup 0%→75% +token+8% + +H3 Multimodal +Transkripsi 0%→80% +Latensi +1d + +H4 Pemikiran +Penghitungan 0%→70% +Latensi 3x! + +H6 Pohon Elemen +UI 17%→52% +token+30% + +④ Keputusan: Trade-off Biaya-Manfaat +✓ H1+H3: Biaya Rendah, Manfaat Tinggi → Deploy +✗ H4: Hanya 8% Tugas Bermanfaat tapi Latensi 3x → Tolak +✓ H6: 35% Peningkatan / 30% Biaya → Deploy +✗ H5: 15d/Langkah Tidak Dapat Diterima → Alternatif + +⑤ Iterasi: Siklus Baru +Deploy H1+H3+H6 → 88%→94% +Laporan Baru Menunjukkan Mode Kegagalan Berbeda: + H7: Conditional Thinking Enabled + H8: Expand gesture action space + +↑ Loop + +Metodologi: Observasi → Hipotesis → Eksperimen → Keputusan → Iterasi = Dari alkimia ke rekayasa ilmiah \ No newline at end of file diff --git a/book-id/images/fig7-9.svg b/book-id/images/fig7-9.svg index 76207591f..1fa05d3b8 100644 --- a/book-id/images/fig7-9.svg +++ b/book-id/images/fig7-9.svg @@ -1,70 +1,42 @@ - - + + - -Observasi multimodal - -Kamera kepala -224×224 RGB - -Kamera pergelangan tangan kiri -224×224 RGB - -Kamera pergelangan tangan kanan -224×224 RGB - -Vektor status sendi 14 dimensi - -Model Vision-Language-Action (VLA) - -Encoder visi -SigLIP → token visual - - -Model bahasa -Backbone Llama 2 7B - - -Decoder aksi -→ Vektor kontrol kontinu 14 dimensi -Action chunking: menghasilkan 25 aksi berturut-turut sekaligus - - - -Instruksi: "Masukkan kaleng ke dalam panci" - - -Mesin fisika SAPIEN - -Robot lengan ganda -Masing-masing 7 DOF = aksi 14 dimensi - -Pengacakan lingkungan -Posisi 60cm / orientasi ±22.5° - -Deteksi tabrakan + simulasi fisika -Benda tegar / benda lunak / gesekan - -Aksi - -Observasi - -Metrik evaluasi - -Tingkat keberhasilan -Kaleng di dalam panci -dan tidak jatuh - -Waktu penyelesaian -25 langkah × 25 aksi -= 625 langkah kontrol - -Kemampuan generalisasi -Lintas posisi/orientasi -/Varian penampilan - -Sim-to-Real -Pengacakan domain -→ Migrasi nyata + + +Akurasi simulasi → +Skalabilitas + + + +↑ + +Mock API +level unit test +jutaan kali/jam + +AWorld +MCP sandbox +126 fungsi tool +525d/ronde terdistribusi + +AndroidWorld +Simulator +116 tugas aplikasi dunia nyata +UI Automator + +Isaac Gym +Paralelisme GPU +ribuan instans paralel +Akurasi sedikit berkurang + +RoboTwin2 +mesin fisika +Tabrakan presisi tinggi +CPU instans tunggal + +dunia nyata +Akurasi sempurna +Tidak dapat direset + \ No newline at end of file diff --git a/book-ja/chapter7.ja.md b/book-ja/chapter7.ja.md index 0c05f0dee..fe7658ad2 100644 --- a/book-ja/chapter7.ja.md +++ b/book-ja/chapter7.ja.md @@ -17,58 +17,116 @@ Agent システムを構築する際、開発者は数多くの設計上の選 第 1 章で導入した Harness 工学の視点から見ると、評価は Harness の中で「検証」機能という中核的な役割を担っています。1 つの重要な認識は、**評価の対象はモデルだけであってはならず、モデルと Harness の組み合わせ体であるべきだ** ということです。同じモデルでも、異なる Harness の中では性能に大きな差が出ることがあります。一部のチームは Harness を最適化するだけで、同じモデルの端末系タスクにおける性能を著しく向上させました（詳しくは第 5 章）。これが意味するのは、Agent が評価で振るわないとき、改善の方向はモデルの交換ではなく、Harness のあるコンポーネント（プロンプト、ツール設計、フィードバックループ）の最適化かもしれない、ということです。完備された評価体系は、「モデルの能力不足」と「Harness の設計欠陥」という本質的に異なる 2 種類の問題を区別できるべきです。**この 2 種類の問題を区別する一般的な手段がモデル置換実験（model swap）です**。Harness を固定し、より強い/より弱いモデルだけを交換して、スコアの変化幅を観察します。もし強いモデルに換えてもスコアが上がらないなら、ボトルネックは Harness にあります。もし弱いモデルに換えるとスコアが大きく下がり、スコアがモデル能力とともに大幅に変動するなら、最も直接的な解釈はボトルネックがモデル能力そのものにあり、現在の性能が主にモデルによって決まっている、というものです（それがタスク自体が難しいためなのか、それとも Harness がモデルの事前知識に過度に依存しているためなのかは、さらなる分析が必要です）。これが先ほど述べた「アブレーション実験」とは 2 つの異なる方法である点に注意してください。アブレーションは **Harness のあるコンポーネントを無効化して** 全体性能がどう変わるかを見るもので、モデル置換は **Harness を固定してモデルだけを交換する** ものです。前者は Harness 内部のどの部品が重要かを特定し、後者はボトルネックがモデルにあるのか Harness にあるのかを区別します。 評価体系の価値は、モデルが急速に進化する時代においていっそう際立ちます。モデルの能力は依然として急速に進化していますが、新しいモデルが公開ベンチマークでより良い性能を示したからといって、あなたの特定のタスクでも優れているとは限りません。むしろ性能の後退（regression、すなわち新バージョンが一部の面で旧バージョンに劣ること）が起こることもあります。自分の評価データセットで完全にテストしてはじめて、データ駆動のアップグレード判断ができます。さらに、完備された評価体系は「未来のモデルのために製品を開発する」ことを実行可能な戦略にします。すなわち、現在のモデルが商用に耐えなくても、先に製品開発を完了して評価集を確立し、新しいモデルの性能を継続的に追跡し、閾値に達したらすぐにリリースすることができるのです。 +評価体系は 4 つの環節に分解できます。何をもって成功とするか、タスクはどこから来るか、誰が検証するか、スコアをどう意思決定に変えるか——図7-1 に示すとおりです。 + +![図7-1 Agent 評価体系の四つの環節](images/fig7-1.svg) + +## 評価タスクの解剖：τ²-bench の telecom ドメイン + +まず τ²-bench の telecom ドメインから実際のタスクを 1 本、丸ごと解剖してみましょう。ソースはリポジトリの `chapter7/tau2-bench` にあり、タスクファイルは `data/tau2/domains/telecom/tasks_small.json` です。 + +### タスク定義の四つの構成要素 + +以下はそのファイルに含まれるタスクの 1 つで、読みやすさのために一部を省略しています。 + +```jsonc +{ + "id": "[mobile_data_issue]airplane_mode_on|user_abroad_roaming_enabled_off", + + // Agent に渡されるチケット + "ticket": "ユーザーの携帯がインターネットに接続できず、ステータスバーには + 'No Service' と表示されている。顧客 John Smith、番号 555-123-2002、 + 現在フランス滞在中。速度テストの結果が excellent になって初めて解決とみなす。 + プランは変更しないが、必要なら 2.0 GB のデータをチャージしてもよい。", + + // ユーザーシミュレータに渡される行動規範 + "user_scenario": { "instructions": { + "known_info": "You are John Smith with phone number 555-123-2002. + You are currently abroad in France.", + "unknown_info": null, + "task_instructions": + "…express mild frustration after the first unsuccessful attempt. + You will consider the issue resolved only when speed test returns + excellent internet speed and nothing else. If it returns poor, fair + or good, you will not consider the issue resolved. + Whenever the agent asks you about your device, always ground your + responses on the results of tool calls. … + Never make up the results of tool calls." + }}, + + // 実行前に両側の状態を同じ起点にリセットする + "initial_state": { "initialization_actions": [ + { "env_type": "user", "func_name": "turn_airplane_mode_on" }, + { "env_type": "user", "func_name": "turn_roaming_off" }, + { "env_type": "assistant", "func_name": "enable_roaming", + "arguments": { "customer_id": "C1001", "line_id": "L1002" } } + ]}, + + // 採点基準 + "evaluation_criteria": { + "actions": [ + { "requestor": "user", "name": "toggle_airplane_mode" }, + { "requestor": "user", "name": "toggle_roaming" } + ], + "env_assertions": [ + { "func_name": "assert_mobile_data_status", "expected_status": true }, + { "func_name": "assert_internet_speed", + "expected_speed": 200, "expected_desc": "excellent" } + ], + "communicate_info": null, + "nl_assertions": null, + "reward_basis": ["ENV_ASSERTION"] + } +} +``` -> **本章の読みどころ** -> -> 本章は 3 つの層から完全な評価体系を構築します。第 1 層は **評価環境**（「どこで測るか」）です。いかに自動化された再現可能なテスト環境を構築するかで、ツール呼び出し型と人間・機械インタラクション型の 2 つの範式を含みます。第 2 層は **評価方法**（「どう判定するか」）です。データセットの設計原則、評価指標体系（何を測るべきか）から、LLM-as-a-Judge（大規模言語モデルを評者に充てる）による自動化評定、さらに配対比較とモデルランキングまで。第 3 層は **評価駆動の意思決定**（「測って何をするか」）です。評価結果をモデル選定、アーキテクチャ最適化、継続的反復の行動指針へと転化し、統計的有意性の助けを借りて観察されたスコア差が本当に信頼できるかを判断します。加えて本章では、可観測性と本番級 Agent の内部評価インフラについても論じ、章末では第 8 章のポストトレーニングにつながるシミュレーション環境を紹介します。 -> -> 全章を貫く中核理念はこうです。**評価体系の第一の価値は、現在のシステムに点数をつけることではなく、あなたが素早く確実にモデルの進化についていけるようにすることだ**。より強く、あるいはより安いモデルがリリースされたとき、完備された評価体系を持つチームは数時間以内に切り替えの判断を下せますが、評価体系を欠くチームは直感に頼るかコミュニティのフィードバックを待つしかありません。競争の激しい Agent 市場では、この速度差が成否を分けることもあるのです。 +この定義には、掘り下げて説明すべき設計が 4 か所あります。 -![図7-1 評価体系の三つの層](images/fig7-1.svg) +**ユーザーの認知境界が明示的にモデル化されている。** `known_info` には氏名、電話番号、滞在国の 3 項目しか含まれていません。機内モードがオンであること、データローミングがオフであること——この 2 つの真の故障原因はそこに含まれていません。ユーザーは知らないので自分から述べることができず、Agent は質問し、ユーザーに確認させることでしか入手できません。これが**漸進的情報開示（Progressive Information Disclosure）** をタスク定義のレベルで実装した姿です。「一度に全部言わないように」というプロンプトでシミュレータを縛るのではなく、ユーザーの知識範囲を独立したフィールドとしてモデル化しています。多くのベンチマークはタスク開始時に完全な要求を提示しますが、現実のユーザーの第一声はたいてい「ネットにつながらない」程度です。要求を実行可能な水準まで明確化すること自体が、Agent の能力の一部なのです。 -## 具体的な評価の例 +**シミュレータが受け取るのはセリフではなく行動規範である。** `task_instructions` には 3 種類の制約が混在しています。感情の設定（最初の修復が失敗したら軽い不満を示す）、受け入れ基準（速度テストが excellent のときだけ解決とみなし、poor、fair、good はいずれも受け入れない）、そして**事実接地（Grounding）** の要求、すなわち端末の状態に関するいかなる回答もツールの返り値を根拠とすること——"Never make up the results of tool calls"。3 つ目がとりわけ重要です。事実接地の制約がなければ、シミュレートされたユーザーは Agent の誘導に乗って「解決した」と確認してしまい、評価は 2 つのモデルが互いに追認し合うだけのものに退化します。 -方法論に踏み込む前に、まず 1 つの完全な例を通じて直感を築きましょう。私たちがカスタマーサポート Agent を構築し、返金リクエストを処理する能力を評価する必要があると仮定します。 +**初期状態は制御側で分けられている。** `env_type` は `user` と `assistant` の 2 つの値を取ります。機内モードとローミングのスイッチはユーザー側、キャリア側の `enable_roaming` は Agent 側です。この分割が故障の形を決めています。キャリア側ではローミングが開通しているのに、ユーザー端末側ではオフになっているため、Agent がデータベースを照会しても「設定は正常」という結論しか得られません。故障はデータベースから見えない側にあり、ユーザーに確認させて初めて発見できます。 -**テストケース**：ユーザーが 3 日前の注文（注文番号 #12345、金額 ¥299）の返金を要求。会社のポリシー：7 日以内なら全額返金可能。 +**採点基準は 4 層に分かれ、この問題はそのうち 1 層だけを採用する。** `env_assertions` は最終状態を検証し（モバイルデータが利用可能、速度が 200 Mbps 以上かつ評価 excellent）、`actions` は重要な動作が発生したかどうかと**どちら側が実行したか**を検証し、`communicate_info` と `nl_assertions` は必要な情報がユーザーに伝えられたかを検証します。この問題の `reward_basis` は `ENV_ASSERTION` だけを宣言しており、残りの層は通常どおり計算・記録されますが最終報酬には算入されません。採点の基準はタスクごとに宣言されるもので、全体で固定されているわけではありません。 -**Agent の軌跡**： +### 一度の実際の実行の軌跡 -```text -ユーザー：3 日前に買ったあのイヤホンを返品したいのですが、注文番号は 12345 です。（今日は 2026-04-10） +以下では読者に τ²-bench telecom ドメインの評価タスクを実行してもらい、タスク設計、ユーザーシミュレータの設計、プロセスと結果の検証ロジックを実際に観察し、さらに Agent の実行軌跡を観察して、Agent がなぜ失敗したのかを分析していただきます。 -Agent（思考）：ユーザーは返金を求めている。まず注文情報を照会する必要がある。 -Agent → ツール呼び出し query_order(order_id="12345") -ツールの返り値：{status: "delivered", amount: 299, date: "2026-04-07", item: "蓝牙耳机"} +> **実験 7-1 ★：τ²-bench を実行し、τ-bench からの進化を比較する** +> +> 本実験では τ²-bench 評価フレームワークを実行し、人間・機械インタラクション型評価環境の設計上の要点を理解します。まず本節でたどった道筋に沿ってタスク定義ファイルを通読してください。各タスクは既知情報、タスク指示、初期状態、成功条件の 4 つの部分から成ります。続いて評価フローを完全に実行し、ユーザーシミュレータと Agent のマルチターン対話を観察して、典型的な失敗モード（ポリシー違反、情報の欠落、過度な有人転送など）を分析します。 +> +> ![図7-3 τ²-bench の双方向制御環境と階層的検証](images/fig7-3.svg) -Agent（思考）：注文日は 2026-04-07、今日 2026-04-10 まで 3 日で、7 日の返金期間内であり、全額返金の条件を満たす。 -Agent → ツール呼び出し process_refund(order_id="12345", amount=299) -ツールの返り値：{refund_id: "R-98765", status: "processing", eta: "3-5个工作日"} +付属リポジトリには 1 回の実行記録（`chapter7/tau2-bench-eval`）が保存されています。以下ではそのうち成功した 1 本を分析します。 -Agent：返金を開始いたしました。注文 #12345（ワイヤレスイヤホン、¥299）の全額返金を処理中で、 - 到着まで 3〜5 営業日を見込んでいます。返金番号は R-98765 で、進捗の照会に使えます。 -``` +最初の十数ターンはアカウント特定のフェーズです。Agent は番号から顧客 C1001 を割り出し、続いて L1001、L1002、L1003 の 3 回線のデータ使用量を順に照会し、さらにユーザーがフランスで実際に使っている番号を尋ね直します。17 番目のメッセージで、Agent は誤った結論を出します。 -**Rubric で採点**（4 つの次元、各次元 1〜4 点）。表7-1 は、このカスタマーサポート返金タスクの採点例を示しており、Rubric がいかに 1 回の Agent 軌跡をチェック可能な評価次元に分解するかを説明するためのものです。 +> **Agent**（17）：番号 555-123-2002 はあなたのアクティブな回線に含まれていません。最も近いのは 555-123-2001 です…… -表7-1 カスタマーサポート返金タスクの Rubric 採点例 +この結論は L1001 という 1 回線の照会結果だけに基づいています。ユーザーが番号は間違いないと主張したあと、Agent は L1002 を照会して、ようやく一致させます。決定的な転換点は 30 番目に現れます。 -| 次元 | 基準 | 得点 | 理由 | -|--------------------|-----------------------------------|---------|-------------------------------| -| 操作の正確性 | 返金額、注文番号が正しいか | 4 | 正しく照会し ¥299 の全額返金を開始 | -| ポリシー遵守 | 7 日返金ポリシーに従っているか | 4 | 注文は返金期間内でポリシーに合致 | -| 情報の完全性 | 金額、到着時期、返金番号を伝えたか | 4 | 3 つの重要情報をすべて伝達 | -| ハルシネーション検出（否決項） | 存在しない情報を捏造していないか | 通過 | すべての情報がツールの返り値に由来 | +> **ユーザー**（30）→ `check_network_status()`、`check_status_bar()` を呼び出す +> +> **ツールの返り値**（31）：`Airplane Mode: ON | Cellular Connection: no_service | Mobile Data Enabled: Yes | Data Roaming Enabled: No` +> +> **ユーザー**（33）：携帯が今は機内モードになっているので信号がないようです。モバイルデータはオンですが、データローミングはオフです。機内モードを切って試してみましょうか？ + +ツール呼び出しを発したのは Agent ではなく**ユーザー**です。これが**双方向制御（Dual-Control）** の仕組みです。シミュレートされたユーザーは `check_status_bar`、`toggle_airplane_mode`、`reseat_sim_card`、`run_speed_test` といった独自のツールセットを持っています。 -ハルシネーションが分級採点の次元ではなく **否決項** として挙げられているのは、それが品質と直交しているからです。流暢で、詳細で、丁寧な回答であっても、虚偽の事実を含んでいれば、ユーザーへの害は簡潔だが正確な回答よりはるかに大きいのです。（否決メカニズムの一般的な設計は後述の「Rubric 四準則」を参照。） +その後の切り分けは順調です。Agent がユーザーに機内モードを切ってローミングをオンにするよう求め、ユーザーが実行し（35、37）、ステータスバーは 5G フルバーになります。Agent が速度テストを求めると 275 Mbps、評価 Excellent が返り（46）、ユーザーは解決を確認します。2 つの `env_assertions` はいずれも通過し、`reward = 1.0` となります。 -このユースケースは通過しました。しかし良い評価は成功シナリオを測るだけでなく、境界と罠こそ測るべきです。ユーザーが 15 日前の注文（返金期間超過）を返品しようとするとき、Agent は正しく拒否できるか？ ユーザーが「カスタマーサポートがすでに返金を承認した」と主張するとき、Agent はシステムに記録がないのに軽々しく信じてしまわないか？ こうした境界シナリオこそ、Agent の能力の高低を分ける鍵です。 +この満点の軌跡には、検証器が捉えなかった問題も含まれています。telecom の Agent ポリシーの冒頭には "You should only make one tool call at a time" と明記されているのに、4 番目のメッセージで Agent は `get_customer_by_phone` と `get_customer_by_name` の 2 つを一度に発行しています。検証器がこれを誤りと判定しなかったのは、この問題の `reward_basis` が最終状態しか考慮しないからです。これは τ²-bench の手落ちではなく、二値報酬に固有の代償です。プロセスの粒度を、モデル横断で比較可能な単一の数値と引き換えにしているのです。しかし本番環境の評価システムには、たいていそれ以上のものが必要です。正誤を判定するだけでなく、問題がどこにあるのかを指し示すことです。 -上記のこのフロー、すなわちテストケースの定義、Agent の実行、Rubric による採点、結果の分析こそが、評価の基本骨格です。本章はこの後、各段階の設計方法を一歩ずつ展開していきます。 +失敗したタスクも分析する価値があります。ユーザーの番号は 555-123-2002 なのに、Agent は L1001 回線を選び、その 3.2/5 GB という使用量を根拠に推論を進めました。途中で `get_details_by_id(L1001)` がその回線の番号は 555-123-2001 だと明確に返しているにもかかわらず、Agent はその結果を読んでも判断を修正せず、その後は無関係な切り分けに数十件のメッセージを費やし、最後は有人対応へ転送しました。実際にはタスクの半分は達成しています——ユーザーにデータセーバーをオフにさせ、そのユーザー側の動作は現実に発生して環境に検証されました。しかし回線の選択を誤ったために必要な 2 GB のチャージが実行されず、3 つの最終状態アサーションはすべて失敗しました。この失敗の形は、後述の「失敗の帰属」の節で論じる AndroidWorld の事例と非常によく似ています。判断を修正するのに必要な証拠はすでにコンテキストに入っていたのに、Agent はそれをもとに引き返さなかったのです。 -## 評価指標体系：新しい基準 +このタスク 1 本で、評価集が答えるべき問いはすでに出そろっています。何をもって成功とするか、タスクはどこから来るか、誰が検証するか、スコアをどう意思決定に変えるか。以下の各節でこれらを順に展開します。 -環境やデータセットを作る前に、「成功」とは何かを決めます。一度でも実行可能な経路を見つければよいのか、それとも毎回正しくなければならないのか。定義が違えば、工学上の判断も逆転します。本節ではまずこの尺度を定め、そのうえで後段において、環境・データセット・採点器をどう実装するかを説明します。 +## 評価指標：成功の定義 + +前節の評価結果は 5 本のタスクのうち 4 本通過でした。0.8 という数字だけでは、そのシステムが使えるかどうかは判断できません。それが返金対応のカスタマーサービスなら、5 人に 1 人が受け取るべき返金を受け取れないということです。脆弱性を掘り出すセキュリティ Agent なら、5 回のうち 4 回当たるのはかなり優秀です。違いは、その業務シーンがどれほど高い成功率を求めるかにあります。 ### 技術的な奇跡：Pass@k で能力の上限を見る @@ -99,209 +157,151 @@ $$ 評価レポートには $k$ 回の試行の定義を明記しなければなりません。同一タスクの $k$ 回の独立サンプリングなのか、本番パイプライン上の連続する $k$ 件のタスクなのか。副作用を伴う操作については、単純に「成功するまで再試行」してはならず、サンドボックスやロールバック可能な環境でサンプリングし、失敗の一つひとつを信頼性指標に記録すべきです。 -### プロセス指標：ブラックボックスからホワイトボックスへ - -最終結果だけに着目するのでは不十分で、Agent が結果に到達する過程も同様に重要です。**行動合法率** は操作のうち有効かつ合法なものの比率を測定します。無効な操作には、存在しないツールの呼び出し、誤った引数型の受け渡しが含まれます。越権操作とは権限範囲を超える行為を指します。高い合法率は、Agent がツールエコシステムを明確に理解していることを示します。**ツール呼び出し正確率** はさらに、引数が意味的に妥当であることを要求します。検索ツールのクエリ語はニーズを正確に表現すべきで、ファイル操作のパスは正しい対象を指すべきです。 - -**経路効率** はタスク完了の経済性を測ります。ステップ数（思考-行動-観察ループの回数）、冗長な動作（同じキーワードの重複検索、同じファイルの繰り返し読み込み）、後戻り回数（誤りに気づいて修正する頻度。時々の後戻りは正常だが、頻繁な後戻りは前方計画の不足を示す）。「妥当なステップ数」を定義するには、人間の専門家や発見的アルゴリズムのベースラインを確立する必要があります。 - -**検索カバレッジ** は情報収集系タスクに対応します。Agent は情報空間を充分に探索したか？ 検索結果の 1 ページ目だけを見て軽率に結論を出していないか？ **コストと遅延** はリクエスト回数、トークン消費（入力/出力コストを区別し、KV Cache の再利用を考慮する必要がある）、実時間（モデルの推論 + ツール実行 + ネットワーク遅延を含む）に着目し、時間分布を追跡してボトルネックを特定する必要があります。 - -### 安全性、堅牢性と軌跡カバレッジ - - -**安全とコンプライアンスの指標** は本番デプロイにおいてきわめて重要です。センシティブな操作のトリガー（データ削除 / 権限変更 / 外部への通信送信）、データ流出（ログにパスワードを出力 / 秘密文書を外部 API に送信）、違反コンテンツは、いずれも **ゼロ容認原則** に従うべきです。ハルシネーション否決項と同様に（後述の「Rubric 四準則」を参照）、1 回の重大な安全違反があれば全体の評価を否決し、他の次元の性能が優れていても免除しません。 - -**頑健性** は不確実性に直面したときの安定性を測ります。乱数シードの敏感性（異なる初期化で性能差がどれほどか）、ページ変化への適応性（ウェブサイトの UI 更新で完全に機能停止すべきでない）、API のばらつきへの許容度（一時的な故障、タイムアウト、フォーマット変化を優雅に処理できるか）、長時記憶の干渉（コンテキストに蓄積された古い情報が誤った意思決定を招かないか）。 - -**実行軌跡と最終結果の二重カバレッジ**。評価で見落とされやすい 1 つの区別は、Agent が実行過程で「何を言い、何をしたか」（すなわち第 1 章で定義した軌跡、trajectory）と「システムが最終的にどうなったか」（最終結果、outcome）は別物だ、ということです。Agent が「予約が完了しました」と言うのは軌跡レベルの情報で、データベースに本当に注文が 1 件生成されたことが結果レベルの検証です。軌跡だけを見ると「言ったがやっていない」状況を見落とし、結果だけを見ると途中のステップが逸れたことに気づけないかもしれません。Anthropic はかつてこんな例を挙げました。ある航空券予約 Agent が実行中に航空会社のポリシーの抜け穴を見つけ、ユーザーのためにより安いプランを見つけた——もし事前設定された実行経路だけで採点すれば、この実行は失敗と判定されます。しかし最終結果から見れば、ユーザーはより良いプランを手にしました。したがって両種の評価をともにカバーし、系統的な盲点を避けるべきです。 - -### 人手による抽出と敵対的レビュー - -自動評価が大多数の場合に信頼できるとしても、定期的な人手抽出検査は必要です。異なるタスクタイプ、成功/失敗のケース、境界スコア付近の曖昧なケースをカバーし、結果を検証するだけでなく、採点理由の妥当性も精査します。 - -人手抽出検査はさらに **評者のキャリブレーション** へと系統化できます。LLM 評者を大量に使い始める前に、まず人手アノテーションのゴールドセット（各タスクタイプと難易度をカバーする 100〜200 個のケースなど）を構築し、その上で評者モデル（すなわち LLM を評者に充てる。そのメカニズムは次節 LLM-as-a-Judge で詳述）と人間のアノテーションの一致率（単純一致率、あるいは Cohen's kappa などの一致係数。後者は偶然当たった分を除去する）を測定し、あらかじめ定めた閾値（kappa が 0.7 を上回るなど）に達してはじめて評者モデルを大規模評価に用います。それ以降、評者モデルや Rubric が更新されるたびに、ゴールドセットで再キャリブレーションすべきです。このステップがなければ、LLM 評者のスコアは「別のモデルの意見」にすぎず、人間の判断の信頼できる代理ではありません。 - -**敵対的レビュー** はレッドチーム（Red Teaming）を通じて挑戦的なケースを能動的に構築します。表面上は完璧だが隠れた誤りを含む回答、キーワードの羅列でごまかす回答、評者モデルの既知のバイアスを利用して不相応な高得点を得る回答です。**複数評者メカニズム** は複数の独立した評者にそれぞれ採点させ、加重平均や一致性チェックを通じて最終結果を確定します。評者間で深刻な意見の相違があるときは、さらなる人手審査が必要とマークします。 - -## 自動評価環境 - -Agent の評価には、繰り返し実行できる自動化された環境が必要です。開発段階で変更の効果を素早くテストできるものです。こうした環境を構築するには 3 つの問いに答える必要があります。何を評価するか（タスク定義と検証基準）、誰を対象に評価するか（Agent のインタラクション相手をどうシミュレートするか）、どんな基準で採点するか、です。 +## 評価環境 -### 評価環境の基本構成 +指標の基準が定まったら、次の問題はどこで測るかです。評価環境とは繰り返し実行できる装置のことです。同じ初期状態を与えれば、同じ Agent は比較可能な結果を出すはずです。 -評価環境は 5 つの要素を含みます。以降の節では、そのうちデータセット設計と採点基準の設計を重点的に展開します。 +### 五つの構成要素 -**データセット（Dataset）** はタスクの集合を定義し、初期状態、目標の記述、およびオプションの参照解を含みます。 +先ほど解剖した telecom のタスクに戻りましょう。それを参照点にすると、繰り返し実行できる評価環境に必要な構成要素はすでにそろっています。 -**環境状態（Environment State）** はタスク実行中の可変情報を維持し、真実性と可制御性のバランスを取る必要があります。例えばカスタマーサポート評価では、環境状態にはデータベース内の注文記録とユーザーアカウント残高が含まれます。Agent が `process_refund` を呼び出すと、注文状態が `"delivered"` から `"refunded"` に変わり、残高が増加します。これらが「可変情報」です。「真実性」は状態変化が業務ロジックに合致すること（返金が注文金額を超えないこと）を要求し、「可制御性」はテストのたびに同じ初期状態にリセットできることを要求します。 +**データセット（Dataset）** はタスクファイルそのものです。初期状態、Agent 向けのチケット、シミュレータ向けの行動規範、受け入れ基準が 1 件のレコードにまとめられ、1 件が 1 つのテストケースになります。 -**ツールインターフェース（Tools）** は Agent が実行可能な操作の集合を定義します。ツールは高すぎるレベルの抽象（「ユーザーの問題を解決する」など）を提供すべきではなく、原子的な操作（注文の照会、予約の変更、メールの送信など）を提供し、Agent に計画と思考を通じてこれらの操作を組み合わせることを強いるべきです。 +**環境状態（Environment State）** はタスク実行中の可変情報です。データベース内の顧客、回線、プラン、請求書に加え、端末側の機内モード、ローミング、データセーバーのスイッチ、残データ量。これはリセット可能でなければならず、`initialization_actions` がそのリセットスクリプトです。真実性は状態変化が業務ロジックに従うことを要求し、可制御性は毎回の実行前に同じ起点へ戻れることを要求します。 -**採点基準（Rubric、採点準則）** は Agent の性能を定量化します。二値（通過/不通過）でも、連続（0〜100 点）でも、多次元（正確性、効率、安全性にそれぞれ採点）でも構いません。 +**ツールインターフェース（Tools）** は両側に属します。Agent は顧客照会、使用量照会、データチャージ、有人転送といったキャリア側の操作を呼び出せます。ユーザーは端末側の各種スイッチを操作できます。どちらのツールセットも原子的な操作であり、「ユーザーのネット接続問題を解決する」といった高レベルの抽象は存在しません。抽象の水準が高すぎると、評価は単一の関数呼び出しの検査に退化し、計画と推論の部分がツール自体に吸収されてしまいます。 -**実行プロトコル（Interaction Protocol）** はインタラクションのモードと終了条件を規定します。 +**採点基準（Rubric）** は `evaluation_criteria` の 4 層の検査に、`reward_basis` という集約ルールを加えたものです。 -この 5 つの要素が合わさって、再現可能な評価ループになります。 +**実行プロトコル（Interaction Protocol）** はやり取りの順序と終了条件を規定します。ここでの正常な終了シグナルはシミュレートされたユーザーが `###STOP###` を出力することです。ほかにターン数の上限があり、さらにシミュレートされたユーザーが忍耐を切らして自ら対話を終えることもあります——コミュニケーション効率の低さ自体が失敗としてカウントされるのです。 -![図7-2 ツール呼び出し型と人間・機械インタラクション型の評価環境](images/fig7-2.svg) - -Agent のタスクの違いに応じて、評価環境はツール呼び出し型と人間・機械インタラクション型に大まかに分けられます。 +5 つの要素のどれか 1 つでも欠ければ、評価は繰り返し可能なループを構成できません。以下で他のベンチマークを検討する際も、この 5 項目を対照の枠組みとします。 -### ツール呼び出し型評価環境 +### 人間・機械インタラクション型とツール呼び出し型の評価環境 -コード生成、データ分析など主にツール使用に依存するタスクについては、Verifiers フレームワークが典型的な設計パターンを示しています。Agent は事前定義されたツールを呼び出してタスクを完了し、検証は実行可能な基準（テストが通るか、答えが一致するか）に基づき、人間のアノテーションやモデルの評定に依存しません。 +telecom のようなタスクには必ず対話相手が必要で、5 要素のうちユーザーシミュレーションの部分が欠かせません。一方、対話相手がまったく存在しないタスクの一群もあります。コード生成、データ分析、数学の求解といったタスクでは、Agent は最初から最後までツールとしかやり取りせず、正しさは実行検証を通過できるかどうかで決まり、人手のアノテーションもモデルによる評定も必要ありません。この種の環境はユーザーシミュレータを省きますが、残る 4 要素は依然として存在し、形が単純になるだけです。環境状態はファイルシステムかデータベース、採点基準はテストコード、実行プロトコルは「答えを出すかターン数を使い切るまでツールを呼び続ける」に退化します。 -Verifiers は階層化された環境設計を導入しています。`SingleTurnEnv` は単一ターンのタスク（単純な質疑応答など）に適し、`ToolEnv` は複数ターンのツール呼び出しの自律ループをサポートし、`StatefulToolEnv` と `SandboxEnv` は状態を持つツールと長期実行のサンドボックス環境（コード実行など）をサポートします。例えば `SingleTurnEnv` は数学の問題を 1 問尋ねて直接答えを検証するのに適し、`ToolEnv` は複数のウェブページを検索してから総合的に回答し、最終結果を検証するのに適し、`StatefulToolEnv` はデータベースレコードを変更してからデータベースの状態変化を検証するのに適し、`SandboxEnv` はサンドボックスでコードを実行してから出力ファイルをチェックするのに適します。表7-2 はこれらの環境タイプをまとめており、読者がタスクの状態、ツール呼び出し、隔離の必要性に応じて適切な評価環境を選べるようにしています。 +Verifiers フレームワークは、この種の環境を 2 つの次元で階層化します。タスクがターンをまたいだ状態を保持する必要があるか、隔離が必要かです。`SingleTurnEnv` は数学の問題を出して答えを直接検証する場合、`ToolEnv` は複数のウェブページを検索して総合的に回答し最終結果を検証する場合、`StatefulToolEnv` はデータベースのレコードを変更して状態変化を検証する場合、`SandboxEnv` はサンドボックスでコードを実行して出力ファイルを確認する場合に適します。表 7-1 はこの 4 種類の環境をまとめたもので、タスクの状態、ツール呼び出し、隔離の要件に応じて選べます。 -表7-2 Verifiers 環境タイプの比較 +表 7-1 Verifiers 環境タイプの比較 | 環境タイプ | 状態保持 | ツール呼び出し | 典型的なユースケース | |---|---|---|---| -| SingleTurnEnv | なし | なし | 単一ターン質疑応答、数学問題 | -| ToolEnv | なし | 複数ターン | 検索+情報総合 | -| StatefulToolEnv | あり | 複数ターン | データベースレコードの変更 | -| SandboxEnv | あり+隔離 | 複数ターン | コード実行とテスト | +| SingleTurnEnv | なし | なし | 単一ターンの問答、数学問題 | +| ToolEnv | なし | マルチターン | 検索＋情報の総合 | +| StatefulToolEnv | あり | マルチターン | データベースレコードの変更 | +| SandboxEnv | あり＋隔離 | マルチターン | コード実行とテスト | -フレームワークは並列サンプリングと軌跡キャッシュをサポートし、各評価の完全な軌跡（観察、行動、報酬）が保存され、後続の分析やリプレイに便利です。 +このフレームワークは並列サンプリングと軌跡キャッシュに対応し、各評価の完全な軌跡（観察、行動、報酬）が保存されるため、後からの分析や再生が容易です。また、ツールの実行効果は現在の状態に依存するため、失敗時には単一の失敗フラグではなく明確なエラー情報を返し、Agent がそれをもとに戦略を調整できるようにすべきです。 -環境はさらに操作の状態依存性を扱う必要があります。ツールの実行効果は現在の状態に依存し、失敗時には単純な失敗フラグではなく明確なエラー情報を提供すべきで、Agent がエラーから学び方策を調整できるようにします。 +ツール呼び出し型の評価が問うのは観察可能な状態変化の正しさであり、人間・機械インタラクション型の評価が問うのはコミュニケーション戦略の妥当性です。前者は行動を検証し、後者は誘導を検証します。2 種類の環境の構造の対比は図7-2 を参照してください。 -### 人間・機械インタラクション型評価環境 +![図7-2 ツール呼び出し型と人間・機械インタラクション型の評価環境](images/fig7-2.svg) -多くの現実のタスクはツール呼び出しだけでなく、人間のユーザーとの対話も必要とします。カスタマーサポート Agent は曖昧な表現を理解し、ニーズを明確化し、バックエンドシステムを照会し、ユーザーに情報を確認する必要があります。この種のタスクの評価は根本的な課題に直面します。自動化された環境の中で、いかに本物のユーザーをシミュレートするか、です。 +## 評価データセットの設計 -鍵となる設計原則は **漸進的情報開示（Progressive Information Disclosure）** であり、これが人間・機械インタラクション型評価と従来のベンチマーク（benchmark）との根本的な違いです。大多数の benchmark は最初から完全な要求をすべて提示しますが、現実ではユーザーが最初からニーズを明確に記述できることはめったにありません。彼らはたいてい「私のフライトに何か問題があるみたいで」「ネットにつながらなくなった」としか言いません。Agent は能動的に質問してニーズを明確化する必要があり、この過程そのものが能力の重要な現れです。したがって評価においては、**決して最初からシミュレートされたユーザーのすべての情報を Agent に露出させてはならず**、情報は必要に応じて漸進的に対話の中で開示されるべきです。 +評価環境が舞台なら、データセットは脚本です。同じ 5 つの要素でも、タスクの種類が変われば埋め方はまったく異なりえます。タスクはどこから来るか、検証器はどの深さまで確認できるか、どうやって記憶されるのを防ぐか。本節は複数の公開ベンチマークの設計実践から出発し、最後により実務的な問い——自作の評価集のタスクはどこから来るべきか——に戻ります。 -τ-bench の解決策は **ユーザーシミュレーション（User Simulation）** です。別の LLM にユーザー役を演じさせ、事前定義された指示に従って Agent と対話させます。シミュレートされたユーザーはタスク指示（「明日のフライトをキャンセルする必要がある」など）を受け取り、対話の中で必要な情報を段階的に Agent に開示し、問い合わせに応じ、タスク完了後に終了信号を発します。プロンプトはシミュレートされたユーザーに「すべての情報を一度に開示せず、現在のステップに必要な内容だけを提供する」「指示に与えられていない情報を捏造しない」ことを要求します。ユーザーシミュレーションの設計は真実性と可制御性の間でトレードオフする必要があります。振る舞いは本物のユーザーに近づけ（表現が曖昧、情報が不完全、時に感情の起伏がある）、同時に再現性を確保するため一定の脚本に従わせます。 +### ベンチマーク設計の横断的な対照 -以下は漸進的情報開示を伴う複数ターン対話の例です（ユーザーシミュレーターは固定の脚本に従って行動します）。 +前節で区別した対話相手の有無は、環境レベルでの第一層の差異にすぎません。データセットのレベルでの分岐のほうが、設計上のトレードオフをよく表します。表 7-2 は頻繁に引用されるベンチマークを並べたものです。 -> **ユーザー**：「私のフライトに問題があります。」 -> **Agent**：「どのフライトでしょうか？」 -> **ユーザー**（脚本に従って開示）：「Delta 123、明日の朝サンフランシスコからニューヨークへ。」 -> **Agent**：「具体的にはどんな問題でしょうか？」 -> **ユーザー**（脚本に従って開示）：「飛行時間が長すぎるので、変更したいのです。」 -> **Agent**：「新しいフライトへの希望はありますか？」 -> **ユーザー**（脚本に従って開示）：「午後のフライトならどれでも構いません。」 +表 7-2 いくつかの Agent ベンチマークにおける主要な設計上の選択 -ユーザーシミュレーターは固定の脚本（既知情報 + 開示ルール）に従い、評価の再現性を確保しつつ、本物のユーザーの漸進的な表現方式をシミュレートします。 シミュレートされたユーザーには、**限られた忍耐力**が設定されていることも多くあります。Agent のコミュニケーション効率が低ければ、シミュレートされたユーザーは会話を打ち切ることができ、その結果タスクは失敗します。 +| ベンチマーク | 測定される能力 | タスクの出所 | 環境の担い手 | 検証器 | +|---|---|---|---|---| +| τ²-bench | カスタマーサービス場面の人間・機械インタラクションとツール呼び出し | 人手作成＋組み合わせ生成 | ユーザーシミュレータ＋業務 DB | 4 層の検査を `reward_basis` で二値に集約 | +| SWE-bench Verified | ソフトウェア開発、coding | GitHub の実 issue、人手選別 | コードリポジトリ＋テストスイート | FAIL\_TO\_PASS / PASS\_TO\_PASS の二重検証 | +| AndroidWorld | Android 端末の GUI 操作 | パラメータ化テンプレートの実体化 | 実機相当の Android エミュレータ | 最終 UI 状態のアサーション | +| OSWorld | Linux デスクトップの GUI 操作 | あらかじめ設定した中間状態から開始 | 実際の仮想マシン | 134 個の独立した評価関数 | +| Terminal-Bench | Linux ターミナル操作、coding | 人手作成 | Docker コンテナ | ファイルシステム検査＋実行 | +| GAIA | 情報収集を行う汎用 AI アシスタント | 人手作成＋独自の添付ファイル | オープンなインターネット | 厳密な文字列一致 | -τ-bench は、構造化された業務プロセス（航空カスタマーサポート、小売カスタマーサポートなど）における Agent の性能を評価するベンチマークです。そのチェックはコンポーネントレベルで多次元的です。一方ではデータベースの最終状態が正しいか（予約記録の状態が「キャンセル済み」に変わるなど）をチェックし、他方では Agent が対話の中で必要な重要情報（返金額と到着時期など、特定の文字列やパターンを検索して検証）を出力したかを検証します。この二重検証は操作の正確性とコミュニケーションの有効性を同時に考察します。しかしタスクレベルでは、これらのチェックは最終的に **ゼロか 1 かの二値報酬** に集約されます。すべてのチェックが通過してはじめて 1 点、いずれか 1 つでも不通過なら 0 点です。二値報酬は Pass^k などの信頼性指標（後述の「評価指標体系」を参照）の統計に便利ですが、その代償として「操作は正確だが非重要フィールドを 1 つ漏らした」場合と「完全な失敗」が同じスコアになります。 +### 検証器 -改良版 **τ²-bench** の核心的な増分は採点粒度ではなく、次の 2 点にあります。1 つは **双制御環境（Dual-Control）** です。もはや Agent 側だけがツールを呼び出せるのではなく、ユーザーシミュレーターも同じ共有環境を操作できます（例えば Agent がユーザーに機内モードの切り替えを指示し、ユーザーの操作が実際に環境状態を変える）。これは技術サポートなどユーザーの手作業による協力を必要とする現実のシナリオにより近いものです。もう 1 つは **より精確なタスク仕様と組み合わせ型タスク生成** です。成功条件の曖昧さがより少なく、具体的なタスクインスタンスをパラメータ化して一括生成できます（詳細な検証次元は後述の「検証可能性と客観性の保証」の節を参照）。 +Agent は「タスクはすべて完了した」と滔々たる報告を書くことができますが、実際にはまったく完了していないことがあります。評価フレームワークは、Agent の自己申告ではなく、機械が独立に照合できる事実を確認しなければなりません。 -> **実験 7-1 ★：τ²-bench を実行して τ-bench の進化と対比する** -> -> 本実験は τ²-bench 評価フレームワークを実行することで、人間・機械インタラクション型評価環境の設計要点を理解し、τ-bench と τ²-bench の差異を対比することで、評価データセットがいかに反復改善されるかを体得します。 -> -> タスク定義ファイルを深く読み込みます。各タスクは既知情報（ユーザーの背景知識）、タスク指示（いかに漸進的に情報を開示し応答戦略をとるかを指導）、成功条件（データベースの目標状態と対話に必ず現れるべき確認情報）を含みます。完全な評価フローを実行し、ユーザーシミュレーターと Agent の複数ターン対話を観察し、典型的な失敗モード（ポリシー違反、情報の漏れ、過度な有人転送など）を分析します。 -> -> -> ![図7-3 τ²-bench 評価アーキテクチャ](images/fig7-3.svg) -> -> -> τ-bench と τ²-bench の設計上の差異を対比します。τ-bench 初期版のユーザー指示は単純すぎ（Agent が答えを当てられる）、成功条件が精確でなく（誤判定を招く）、ユーザーシミュレーターが機械的すぎました。τ²-bench はこれらの問題に対して系統的な改善を行いました。 -> -> - **より詳細なタスク指示の導入**：「事実アンカリング要求」（Grounding）、すなわち環境の真の状態に基づいて回答しなければならないことを含む -> - **より精確な評価基準**：「速度テストが excellent を返してはじめて解決とみなす」など -> - **より本物らしいユーザーシミュレーターの振る舞い規範**：漸進的情報開示、自然な感情の起伏 -> -> τ²-bench が新たに追加した telecom 領域のタスクに特に注目し、その双制御環境設計（前述の通り、ユーザーと Agent が同じ共有環境を共同操作する）を理解します。 -> +**SWE-bench Verified は「修正完了」を 2 つの独立した命題に分解します。** 一方は FAIL\_TO\_PASS で、修正前は失敗し修正後は通過することで、問題が確かに解決されたことを示します。もう一方は PASS\_TO\_PASS で、修正の前後どちらでも通過することで、新たな欠陥を持ち込んでいないことを示します。前者だけを検査すれば、Agent は邪魔なアサーションを削除・改変してごまかせます。後者だけなら検査していないのと同じです。両方を同時に検査してはじめて、「修正済み」と「壊していない」がそれぞれ独立に証明可能な結論になります。さらにテスト自体の安定性も確認し、通ったり落ちたりする不安定なテスト（flaky test）を排除します。 -ツール呼び出し型評価が「観測可能な状態変更を完了したか」を重視するのと異なり、人間・機械インタラクション型評価は「ユーザーに認知や意思決定上の変化を完了させるよう導いたか」に着目します。前者は Agent の行動の正確性を考察し、後者はそのコミュニケーション戦略の妥当性を考察します。 +**OSWorld の検証器は、表面上は完了しているが実質的には誤っている状況を発見できます。** 134 個の独立した評価関数と OS への完全なアクセス権を備え、ファイルシステムの構造、プロセスの状態、ネットワーク接続、アプリケーション内部の状態を検査できます。データベース操作のタスクでは、評価スクリプトはレポートファイルの存在を確認するだけでなく、データベースに接続して SQL が正しく実行されたかを照合します。ブラウザのタスクでは DOM ツリーを解析し、cookie と localStorage を調べ、バックエンドに検証リクエストを送ってフォームが本当に反映されたかを確認します。 -評価環境の構築はさらにシミュレーション環境の設計にも関わります。評価環境が大規模な反復インタラクションをサポートする必要が出てくると、それはシミュレーション環境へと進化します。本章末尾で簡単に論じます。 +**Terminal-Bench** のタスク `build-linux-kernel-qemu` は、ソースから Linux カーネル 6.9 をビルドし、`start_kernel` にカスタム printk を追加し、initramfs を生成して QEMU 上で起動することを要求します。成功基準は起動ログにそのカスタムメッセージが現れることです。Agent は出力を偽造できず、全工程を本当にやり遂げるしかありません。 -## 評価タスクデータセットの設計 +### タスクの難易度の区分 -評価環境は「舞台」、データセットは「脚本」です。脚本設計の良し悪しは、しばしば舞台そのもの以上に評価の価値を左右します。設計の拙いデータセットは、完璧な環境で走らせても、得られるのはノイズだけです。本節では、GAIA、AndroidWorld、SWE-Bench Verified（Software Engineering Benchmark、ソフトウェアエンジニアリングベンチマーク）、τ-bench と τ²-bench、Terminal-Bench、OSWorld と OSWorld-Verified などのベンチマークの設計実践から、繰り返し検証されてきたいくつかの原則を抽出します。 +評価タスク集にはさまざまな難易度のタスクを含める必要があります。そうすることで、モデルの能力が向上しても評価タスク集がすぐに陳腐化しません。 -> **実験 7-2 ★：ベンチマークタスクを人力で実行する** -> -> GAIA、AndroidWorld、SWE-Bench Verified、τ²-bench、Terminal-Bench、OSWorld-Verified からそれぞれタスクを選んで自ら完了します。各データセットで簡単・中程度・困難を 1 つずつ完了することをおすすめします。「困難」レベルは人間にとっても挑戦的です。実行結果を標準解と対比し、差異の源を分析します。自ら体験することで理解します。タスク記述は明確性と開放性の間でバランスを取る必要があること、検証基準は客観的で実行可能でなければならないこと、タスク難易度の階層化は異なる能力レベルを区別できなければならないこと、を。 -> - -### タスクデータセット設計の核心的課題 - -**課題一：明確性と開放性の緊張。** タスク記述は評価の再現性を確保するのに十分明確でなければならず、かといって固すぎて Agent の創造性を制限してもいけません。GAIA は 1 つの手本を示しています。タスクは「概念的には単純」だが実装経路は開放的です。例えば NASA の毎日の天文写真から宇宙飛行士の情報を見つけるよう要求する場合、目標は明確（特定の宇宙飛行士とその宇宙滞在時間を見つける）ですが、どう検索し、選別し、検証するかは完全に Agent の自主的な判断に委ねられます。 - -**課題二：真実性と可制御性のバランス。** 本物のタスクは不確実性とノイズを含み、頑健性を顕在化させられますが、再現性も脅かします。SWE-Bench の初期版は GitHub の本物の issue から直接取り、真実性を確保しましたが、タスク記述が曖昧、テストケースが不完全、評価基準が主観的という問題も招きました。SWE-Bench Verified は人間の専門家を導入して系統的な検証を行い、その中から問題が明確でテストが充分、解法が明確な 500 個の高品質タスクを選別し、真実性を保ちつつ可制御性を著しく高めました。 - -**課題三：多様性と系統性の調和。** 有効なデータセットは典型的な状況、境界条件、エラーの罠をカバーする必要があり、同時に系統的な組織方式を持ち、評価結果が具体的な能力の弱点を診断できるようにする必要があります。AndroidWorld の 116 個のタスクは 20 個の本物のアプリにまたがり、各タスクには必要な核心能力（多段階計画、視覚理解、時系列推論）が注記されており、評価結果は全体の成功率を示すだけでなく、特定の能力次元の強弱も明らかにできます。さらに重要なのは、パラメータ化メカニズムを通じてほぼ無限のタスクバリアントを生成できることです。 +GAIA は全 466 問を 3 段階の難易度に分けています。Level 1 は 1〜2 個のツールで足り（人間 93.9%、GPT-4 30.3%）、Level 2 は多段の思考を要し（91.8% 対 9.7%）、Level 3 は複雑な組み合わせを要します（87.3% 対 0%）。この階層化は難易度を示すだけでなく、診断的な価値も持ちます。Level 1 の失敗は基礎的なツール利用を、Level 2 は多段の計画と情報統合を、Level 3 は長い系列の思考と複雑性の管理を指し示し、3 つはそれぞれ異なる改善の方向に対応します。 -**課題四：評価コストとカバー範囲。** 複雑な Agent タスクは完了に数分あるいは数時間かかり、大量のトークン消費を伴うことがあります。データセットの規模は網羅性と経済性の間でバランスを取る必要があります。GAIA は 466 問を精選し 3 段階の難易度に分け、多様な能力次元をカバーしつつ合理的なコストで評価を完了できます。SWE-Bench Verified は 2294 問から 500 問に選別しました（コストを約 5 分の 4 削減し、より厳格な品質基準を通じて S/N 比を高めました）。 +Terminal-Bench は、単純な mlflow のモデル登録から、中程度の難易度である 7z のパスワード解析、困難な git サーバーと webserver の複数コンポーネント統合、最高難度の FEAL 差分解読までをカバーします。 -**課題五：データ漏洩（Data Contamination）の防止。** 大規模言語モデルの時代において、データ漏洩は評価が直面する厳しい課題です。評価データが訓練データに取り込まれると、評価が測っているのは記憶力であって汎化能力ではなくなります。試験前に答えを暗記してしまえば、成績がどれほど良くても真の実力を示せないのと同じです。各ベンチマークは異なる防止戦略を採用しています。GAIA は答えの独自性に頼り、問題は複数の情報源を組み合わせてはじめて回答でき、一部のタスクには専門に作成された添付ファイル（インターネット上に存在しない PDF/音声/画像）が付属しており、単一のウェブページでは直接答えを提供できません。SWE-Bench Verified はそれ自体が OpenAI が元の SWE-Bench に人手による品質選別を施して得た 500 問のサブセットであり、時間次元の漏洩防止設計は含んでいません。本当に時間的な新鮮さで漏洩を防ぐのは SWE-bench-Live などの後続の取り組みで、これらはモデルの訓練カットオフ日以降に新規作成された issue を継続的に収録し、評価が常にモデルの訓練コーパスに先行するようにします。τ²-bench は動的パラメータ生成で防止し、具体的なタスクインスタンス（ユーザー氏名、注文番号、日付など）を毎回ランダムに生成します。AndroidWorld のパラメータ化タスク生成は本質的に漏洩耐性を持ちます。検証が操作シーケンスではなく最終的な UI 状態に基づくためです。Terminal-Bench はカナリア識別子（canary GUID、すなわちグローバル一意識別子、一種の一意な追跡マーク）を埋め込むことで漏洩を検出可能にします。もしモデルがその GUID を含む内容を出力できるなら、ベンチマークデータが訓練集に漏洩したことを示します。 +τ²-bench はさらに**トラップタスク**を用意しています。ユーザーが「カスタマーサービスがキャンセルを承認済みだ」と主張するものの実際にはポリシーに適合しない、という設定で、Agent が圧力と誤導のもとで正しい判断を保てるかを検証します。 -### タスク記述の精確性設計 +### データ漏洩の防止 -GAIA は明確な情報源の制約、時間範囲、主題、クエリ目標を通じて答えの一意性を確保します。例えば Level 3 タスクは特定日付の NASA 画像を起点とし、視覚理解で宇宙飛行士を識別し、所属する宇宙飛行士グループを照会し、宇宙滞在時間を計算して精確にフォーマット出力する（「姓、セミコロン区切り、千位区切り記号」）ことを要求し、あらゆる細部が自動検証に資するようになっています。フォーマットと内容が完全に一致してはじめて通過とみなされます。 +**GAIA は答えをインターネットから直接検索できないようにしています。** そのタスクは概念的には単純でありながら経路が開かれています。たとえば、ある特定の日の NASA の「今日の天文写真」を出発点に、写真の宇宙飛行士を特定し、その所属する宇宙飛行士グループを調べ、そのグループの中で宇宙滞在時間が最も短い人物を求め、「姓、セミコロン区切り、桁区切り付き」という形式で厳密に出力させます。答えは極めて具体的で、正誤は厳密な文字列一致で判定されます。漏洩防止は 2 点に依拠します。1 つは、問題が複数の情報源を組み合わせないと答えられず、単一のウェブページでは答えが直接得られないこと。もう 1 つは、一部のタスクに専用に作成された添付ファイル（インターネット上に存在しない PDF、音声、画像）が付いていることです。 -τ²-bench は状況化設計を導入し、各タスクは多層の情報を含みます。表面的な問題（「モバイルデータが動かない」）、性能への期待（「絶対に優れた速度が欲しい」）、制約条件（「他の速度は受け入れない」）、および暗黙の感情です。鍵となる改善は「既知情報」と「タスク指示」の分離です。既知情報はユーザーが現在把握している事実、タスク指示はシミュレーターがいかに漸進的に情報を開示するかを指導するもので、その中に「事実アンカリング要求」（Grounding Requirement、すなわちツール呼び出しの実際の返り値に基づいて回答し、捏造してはならない）を含みます。 +**AndroidWorld は 1 つのテンプレートから大量のインスタンスを派生させます。** そのタスクは静的なテキストではなく、動的に実体化できるテンプレートです。たとえば「連絡先 `[CONTACT_NAME]` の電話番号を `[NEW_PHONE]` に変更する」といった形で、評価のたびにパラメータ値がランダムに生成されます。これには 3 つの利点があります。パラメータが毎回異なるため固定の操作列の再生が無効になること、1 つのテンプレートからほぼ無限のインスタンスを生成できること、一部のパラメータを固定し残りだけを変えることで特定の要因の影響を正確に測定できることです。 -SWE-Bench Verified は問題記述、再現手順、期待/実際の振る舞いなどの構造化フィールドを含み、アノテーターは記述とテストケースの整合性を検証します。Terminal-Bench のタスク記述では各要素が機械的に検証可能です。ファイルパスが存在するか、権限の数値が正しいか、証明書のパラメータ、日付形式など。例えば「build-linux-kernel-qemu」はソースコードから Linux カーネル 6.9 をビルドし、`start_kernel` にカスタム printk を追加し、initramfs を生成して QEMU 上で実行することを要求し、成功基準は起動ログにカスタムメッセージが現れることです。Agent は出力を偽造してごまかすことはできず、本当にプロセス全体を完了しなければなりません。 +**Terminal-Bench は問題文にカナリア識別子を埋め込みます。** 各問題は canary GUID を持ち、モデルがその GUID を含む内容を出力できるなら、ベンチマークのデータが訓練セットに入ったということです。漏洩を防ぐわけではありませんが、漏洩を検出可能にします。 -AndroidWorld は **パラメータ化テンプレート** 設計を採用しています。1 つのタスクは静的なテキストではなく、動的にインスタンス化できるテンプレート（「連絡先 `[CONTACT_NAME]` の電話を `[NEW_PHONE]` に変更する」など）で、評価のたびに異なるパラメータ値がランダムに生成されます。利点は 3 つあります。 +### 品質管理と長期的なメンテナンス -- **記憶の防止**：パラメータ値が毎回異なり、固定の操作シーケンスを再生できない -- **データ多様性の増加**：1 つのテンプレートからほぼ無限のインスタンスを生成できる -- **対比実験のサポート**：一部のパラメータを固定して他のパラメータだけを変化させ、特定要因の影響を精確に測定できる +高品質な評価集を作るのは非常に困難です。上に挙げたベンチマークの現在の形は、その多くが初版を運用に投入して問題が露呈したあと、何度も修繕を重ねた結果です。たとえば τ-bench から τ²-bench へは、設計をやり直した箇所が 5 つあります。 -検証は操作シーケンスではなく最終的な UI 状態（電話番号フィールドが期待値を含むかなど）に基づきます。 +第 1 に、**タスク指示が大雑把すぎて答えが推測できてしまった**こと。初版のタスク指示は漠然と書かれていたため、モデルは要求を真に明確化する必要がなく、常識から手順を推測するだけでも通過できました。τ²-bench は脚本を `known_info` と `task_instructions` の 2 欄に分割しました。前者はユーザーが知っている範囲を画定し、後者は開示の仕方を規定します。ユーザーが知らない情報は Agent には推測しようがなく、照会して得るしかありません。 -OSWorld のタスクはしばしば「クリーンな」初期状態からではなく、入念に構成された中間状態から起動し、より現実の使用シナリオに近づけます。タスク記述は多解性（「背景を紫にする」には曖昧さを解消する具体的なカラーコードの提供が必要、「2 つの CSV を連結する」には単一ヘッダー保持/二重ヘッダーなどすべての合理的な方式を受け入れる必要がある）と環境の不確実性（ウェブサイトのクローラー対策、アプリ UI の進化、タイミング競合。OSWorld-Verified はオフラインページスナップショット、依存バージョンのロック、明示的な待機条件などのメカニズムで緩和）を扱う必要があります。 +第 2 に、**成功条件が精確でなく、検証の誤判定を招いた**こと。「ネットワークが復旧した」といった条件には照合可能な境界がありません。τ²-bench はこれを「速度テストの結果が excellent のときだけ解決とみなし、poor、fair、good はいずれも受け入れない」に改めました。この変更が狙うのは**その場しのぎの修復**、つまり症状を抑えるだけで根本原因を解決しないやり方です。 -このリストは Agent 評価の全体像を尽くしてはいません。Web/GUI 系だけでも、それぞれに重点の異なる複数のベンチマークがあります。WebArena は完全に再現可能なウェブサイト群（EC、フォーラム、コードホスティングなど）を自作し、「本物のウェブページ」の制御不能性をサンドボックスに閉じ込めました。Mind2Web はその逆を行き、数百の本物のウェブサイト上で直接汎化能力をテストします。[ClawBench](https://claw-bench.com/)（[論文](https://arxiv.org/abs/2604.08523)、[コード](https://github.com/TIGER-AI-Lab/ClawBench)）は、隔離コンテナ内の Agent に実際のウェブサイト上で日常的なエンドツーエンドタスクを実行させます。V1 は 144 サイトの 153 タスクをカバーし、V2 ではさらに 130 タスクを追加しています。また、セッションリプレイ、アクションのスクリーンショット、HTTP トラフィック、ブラウザ操作、Agent メッセージという 5 層の証拠を同時に記録します。サンドボックス型ベンチマークを補完し、実サイトの変化やロングテールの失敗を分析しやすくする一方、再現性は第三者サイトの変化に左右されます。BrowseComp は深い検索に特化しており、答えが深く隠されていて、マルチホップのブラウジングとクロス検証によってはじめて見つけられます。ツール呼び出しの次元には BFCL（Berkeley Function-Calling Leaderboard）のような専門の関数呼び出しランキングもあります。本章はすべてのベンチマークを列挙する意図はなく、2 つの中核的な環境範式（ツール呼び出し型、人間・機械インタラクション型）に、データセット事例を貫く GUI 操作シナリオを加え、その設計上のトレードオフを深掘りします。範式を理解すれば、どんな新しいベンチマークに直面しても、それが何を測っているか、漏洩対策はどれほどか、結論がどこまで外挿できるかを素早く判断できます。 +第 3 に、**ユーザーシミュレータの振る舞いが機械的すぎた**こと。初版のシミュレートされたユーザーは受動的に応答するだけでした。τ²-bench はそこに感情（最初の修復が失敗したら不満を示す）、忍耐の上限（コミュニケーション効率が低すぎるときは対話を打ち切る）、そして事実接地の要求を補いました。3 つが合わさることで、シミュレータは現実のユーザーに近づきながら再現性も保てます。 -### タスク複雑度の階層化設計 +第 4 に、**ユーザーは対話だけでなく操作にも関与する**こと。telecom ドメインは双方向制御環境を導入しました。それ以前の評価では Agent だけが環境を変えられましたが、テクニカルサポートのような場面では、動作のかなりの部分は本来ユーザーが自分の端末で行うべきものです。双方向制御は検証にもう 1 つの次元を加えます。ユーザーが状態を変えたあと、Agent はツールを呼び直さなければ結果を知ることができないため、検証は「Agent がユーザー側の操作結果を本当に読み取ったか」までカバーするようになります。 -GAIA は 3 段階の難易度を設計しました。Level 1 は 1〜2 個のツールだけで済み（人間 93.9% 対 GPT-4 30.3%）、Level 2 は多段階の思考を要し（91.8% 対 9.7%）、Level 3 は複雑な組み合わせを要します（87.3% 対 0%）。階層化設計の診断的価値はこうです。Level 1 の失敗は基礎的なツール使用の問題を指し、Level 2 は多段階計画と情報統合を指し、Level 3 は長いシーケンスの思考と複雑性管理を指します。各層は異なる改善方向（プロンプトエンジニアリング 対 計画メカニズム 対 階層アーキテクチャ/ポストトレーニング）に対応します。 +第 5 に、**タスクのインスタンスを動的に生成する**こと。τ²-bench の具体的なインスタンス（ユーザー名、番号、故障の組み合わせ）はパラメータ化して一括生成でき、これはカバレッジと漏洩耐性の双方を改善します。 -τ²-bench は業務複雑度で階層化します。単純な情報照会から、多段階プロセス（フライト変更には照会、代替案の提示、確認、差額計算、支払いが必要）へ、さらに故障診断（複数の可能な原因を系統的にチェックし修復を検証）へ、最後に方策判断（ポリシーに合致しない要求の処理）へ。 +**SWE-bench Verified：公開前に元のタスクの 71% を落とした。** OpenAI は元の 2294 件から 1699 件を無作為抽出して人手評価にかけ、Python に堪能な開発者 93 名を集めて 1 件ずつ検査しました。問題の記述は明確か、テストケースは境界条件をカバーしているか、テストは安定しているか、参照 patch は新たな誤りを持ち込んでいないか、難易度は妥当か。最終的に通過したのは 500 件だけでした。高い脱落率がもたらすのはより高い S/N 比であり、評価コストも約 80% 下がります。複雑な Agent のタスクは数分から数時間を要することも珍しくなく、フロンティアモデルで評価データセットを丸ごと走らせると数千ドルの token コストがかかるため、評価コストを下げることは非常に重要です。 -Terminal-Bench は技術領域×操作複雑度の二次元で階層化し、そのタスクレジストリはすでに 200 余りのタスクを収録しています（バージョンによって中核評価集の規模は異なり、2.0 版はコミュニティの貢献から 89 個の高品質タスクを精選）。単純な mlflow モデル登録から、中程度の 7z パスワードクラック、困難な git サーバー+webserver 多コンポーネント統合、最も困難な FEAL 差分暗号解析（暗号学の知識+アルゴリズム最適化で 30 秒の時間制約を満たす必要がある）まで。 +**OSWorld：公開後 15 か月で 300 件超の問題が露呈した。** 2024 年 4 月の公開後まもなくマルチモーダル Agent 評価の重要なベンチマークとなりましたが、その後の広範な利用の中で 4 種類の問題が明らかになりました。環境の問題（サイトのスクレイピング対策、CAPTCHA、動的コンテンツの変化）、タスク記述の問題（表現に曖昧さがある）、検証ロジックの問題（厳しすぎるか緩すぎる）、初期状態の問題（設定が不完全）です。香港大学のチームは約 10 名のグループを編成し、MoonShot AI、OpenAI、ByteDance Seed TARS、Anthropic、Simular などと 2 か月にわたり緊密に協力して体系的な修復を行いました。環境の問題はバージョン固定とオフラインバックアップで、記述の問題は曖昧な表現の書き換えで、検証の問題は人手で正しいベースラインを作って条件を調整することで、初期状態の問題は完全性チェックの追加で緩和されました。 -### 検証可能性と客観性の保証 - -GAIA の答えは簡潔明確で、厳格なフォーマット規定により検証を精確な文字列マッチで完了でき、二値の結果（一致か不一致か）が客観的な再現性を確保します。答えの稀少性も不正防止に役立ちます。高度に具体的な事実は、そのままの形で訓練データに現れる可能性が低いのです。 +> **実験 7-2 ★：ベンチマークタスクを人力で実行する** +> +> GAIA、AndroidWorld、SWE-Bench Verified、Terminal-Bench、OSWorld-Verified からタスクを選び、自分の手で完成させてください。各データセットについて易・中・難を 1 つずつ行うことを推奨します。「難」のレベルは人間にとっても挑戦的です。 +> +> 終えたら 2 つの問いに答えてください。そのタスクの記述には複数の妥当な解釈が存在するか、存在するなら検証器はどれを認めるか。もしごまかして通そうとするなら、最も安上がりな経路は何か、検証器はそれを止められるか。 -SWE-Bench Verified はコードの実行可能性に基づいて検証し、FAIL_TO_PASS（修復前は失敗、修復後は通過、問題が解決されたことを証明）と PASS_TO_PASS（修復前後とも通過、新しいバグを導入していないことを証明）を区別し、二重検証を実現します。Verified 版はさらにテスト自体の品質が信頼でき、通ったり失敗したりする不安定なテスト（flaky tests）がないことを確保します。 +### 評価集の三つの出所 -τ²-bench の検証体系は多層のチェックを含みます（各層のチェック結果はタスクレベルではやはり二値報酬に集約され、すべて通過してはじめて成功とみなされます）。 +よくある見方として、公開ベンチマークはモデルのランキングのためのもので、実際の業務とはあまり関係がない、というものがあります。公開ベンチマークのスコアが製品の意思決定を直接導きにくいのは確かですが、その設計手法は十分に移植可能です。これまで論じてきた検証の深さ、パラメータ化生成、漏洩防止、品質のメンテナンスは、まさに自作の評価集で最も見落とされやすい部分です。 -- **データベース状態チェック**：予約記録の状態、返金記録が作成されたか -- **対話内容のキーワード検索**：ユーザーに返金額と到着時期を確認したか -- **プロセス遵守性**：ツール呼び出しシーケンスの分析、注文変更前にユーザーの明確な確認を得たかなど +本番環境の評価集には、通常 3 つの出所があります。 -τ²-bench の双制御環境（前述の「人間・機械インタラクション型評価環境」を参照）は検証レベルでさらに 1 次元多くなります。ユーザーシミュレーターが実際に環境状態を変えた後、Agent はツール呼び出しを通じてこの変化を観測し、それに基づいて調査を続けなければならず、検証は「Agent が本当にユーザー側の操作結果を読み取ったか」までカバーします。 +**公開ベンチマーク**はモデルの粗い選別と設計手法の借用に用い、一般に製品の意思決定には使いません。そのタスク分布は実際の業務のタスク分布と一致しておらず、GAIA で 2 ポイント上がったことと返金の成功率との間に必然的な関係はありません。 -OSWorld は 134 個の独立した評価関数を備え、完全な OS アクセス権限を持ち、ファイルシステム構造、プロセス状態、ネットワーク接続、アプリ内部状態を深くチェックできます。例えばデータベース操作タスクでは、評価スクリプトはレポートファイルの存在を検証するだけでなく、直接データベースに接続して SQL が正しく実行されたかをチェックします。ブラウザタスクでは DOM ツリーを分析し、cookie/localStorage をチェックし、バックエンドに検証リクエストを送ってフォームが本当に有効になったかを確認します。この深いチェックは「表面上は完了したが実質はエラー」の状況を発見できます。例えば Agent が送信ボタンをクリックしたが、フィールドの記入ミスでサーバー側に拒否された、というような場合です。 +**自作の業務集**は現実のタスク分布をカバーし、モデル選定や Harness 設計の判断根拠にできます。たとえば τ²-bench は、ユーザーのシミュレーションを必要とする評価システムの骨格としてそのまま使え、ドメインのデータとツールセットを差し替えるだけで済みます。 -Terminal-Bench は Docker コンテナで環境を標準化し、ファイルシステム状態のチェック（パスが存在するか、権限の数値、内容の形式）とプログラム実行機能の検証（build-linux-kernel-qemu で実際に QEMU を起動しカスタム printk メッセージを検索）を組み合わせ、canary GUID で漏洩を追跡可能にします。 +**本番軌跡の還流**は現場の実際の失敗事例から来ます。ユーザーによる明示的な訂正、ユーザーの低評価、そして事後の状態チェック、ルールベースの検証器、あるいは LLM のレビューによって発見された問題事例です。失敗の帰属を経て回帰ケースとして蓄積されます。具体的なやり方は後述の「失敗の帰属」と「エンドツーエンド回帰タスクと trajectory prefix 回帰タスク」の節を参照してください。この出所はコストが最も高く、精度も最も高い。ユーザーが実際に遭遇した問題から直接来ているからです。 -### タスク分布の系統的設計 +立ち上げの段階では通常、公開ベンチマークと少量の手書きの自作業務集しかありません。システムが本番で一定期間動いたあとは、本番軌跡から還流したケースが主体になります。 -タスク分布は能力次元、難易度次元、シナリオ次元、境界状況を系統的にカバーする必要があります。GAIA は汎用性を追求し、大多数のタスクが推論、マルチモーダル、ブラウジング、ツール使用の組み合わせを必要とします。τ²-bench は専門に「罠タスク」を設計しました。例えばユーザーが「カスタマーサポートがキャンセルを承認した」と主張するが実際にはポリシーに合致しない、というもので、Agent が圧力と誤導に直面したときに正しい判断を保てるかをテストします。OSWorld は操作タイプ（ファイル IO / デスクトップアプリ / ウェブアプリ / アプリ横断プロセス）とアプリ領域の二次元マトリクスに基づき、3 つのオペレーティングシステムにまたがります（研究によれば OS 横断能力は強く相関し、あるシステムで学んだ能力は他のシステムに転移できます）。Terminal-Bench は「技術スタック横断の組み合わせタスク」を含み、システム思考をテストします（データ処理 + ファイル操作 + Python エンジニアリングを融合した再シャーディングタスクなど）。 +## 自動化評価方法 -### データ品質管理と反復改善 +これまでの節で論じたベンチマークには 1 つの共通点があります。検証器がほとんどすべて決定的だということです。SWE-bench はテストスイートを実行し、AndroidWorld は最終 UI 状態をアサートし、GAIA は厳密な文字列一致を行い、τ²-bench の 4 層の検査も同じくすべてコードで実行されます。この選択には十分な理由があります。決定的な検証は追加のモデルコストを持ち込まず、結果は完全に再現可能で、ユニットテストのように継続的インテグレーションに組み込め、モデル間のランキングにも都合がよいのです。 -SWE-Bench Verified は品質管理の模範です。OpenAI は元の 2294 個のタスクからランダムに 1699 個を抽出して人手評価を行い、Python に精通した 93 名の開発者を募りました。アノテーターは複数のチェックを完了する必要があります。問題記述が明確か（何を解決すべきか理解できるか）、テストケースが完全か（すべての側面と境界条件をカバーしているか）、テストが安定しているか（環境やランダム性による flaky test がないか）、patch が正しいか（新しいエラーを導入していないか）、難易度が妥当か。厳格な選別を経て、最終的に 500 個だけが通過しました（29%）。この高い淘汰率は評価品質への必要な投資です。彼らはさらに標準化されたアノテーションガイドラインを確立し、各チェックに具体的な基準と例を定義し、異なるアノテーター間の一貫性を確保しました。 +その代償として、最終結果の正誤しか評価できず、誤りの原因は示せません。τ²-bench の失敗したタスクは最終的に 0 点でしたが、その 0 点は Agent が回線選択の段階で誤ったのか、データチャージの手順を落としたのかを説明しませんし、次に何を直すべきかも指し示しません。ランキングに用いる公開ベンチマークにとってこれは欠点ではありませんが、継続的な改善を要する本番システムにとっては、まさにそれこそが最も必要な情報です。 -τ²-bench は「既知情報」/「タスク指示」の分離（シミュレーターの振る舞いをより本物らしくする）と、より厳格な完了条件（「excellent だけが解決とみなされ、poor/fair/good はすべて受け入れない」など）を導入し、「その場しのぎの修復」を防ぎます。 +本番の場面にはもう 1 つの困難があります。多くの判断は、そもそもコードで検査できるアサーションとして書けないのです。クレーム対応の返信が適切かどうか、調査レポートに重要な情報の抜けがないかどうか、記憶の検索が人物関係を取り違えていないかどうか。これらには照会できる唯一の最終状態もなく、キーワードの一致で判定することもできません。 -OSWorld-Verified は反復改善の模範です。OSWorld は 2024 年 4 月のリリース後、急速にマルチモーダル Agent 評価の重要なベンチマークになりましたが、15 か月の広範な使用の中で 300 を超える問題が露呈しました。これらの問題は 4 種類に分かれます。環境問題（ウェブサイトのクローラー対策 / CAPTCHA / 動的コンテンツの変化）、タスク記述の問題（曖昧な表現）、検証ロジックの問題（厳しすぎるか緩すぎる）、初期状態の問題（構成が不完全）です。香港大学のチームは約 10 人のグループを組み、MoonShot AI、OpenAI、ByteDance Seed TARS、Anthropic、Simular などと 2 か月間深く協力して系統的な修復を行いました。各種の問題に対して修復戦略を立てました。環境問題はバージョンのロックとオフラインバックアップで解決、タスク記述は曖昧な表現の書き直しで解消、検証ロジックは人手で正しいベースラインを確立し条件を調整してバランスを取り、初期状態は完全性チェックの追加で強化しました。 +したがって、公開ベンチマークから本番環境の評価へ進むにあたっては、検証の方式を 1 本のスペクトルに沿って右へ動かす必要があります。その横軸はタスクの**機械的検証可能性の程度**です。図7-4 に示します。 -## 自動化評価方法 +![図7-4 検証方式のスペクトル：決定的検証からモデルによる評定へ](images/fig7-4.svg) -評価環境、データセット、明確な指標体系がそろったところで、次の核心的な問題はこうです。どう採点するか？ 明確な正解のあるタスク（数学問題、SQL クエリなど）については、単純な二値判定（正/誤）で充分です。しかし開放的タスク（カスタマーサポート対話、レポート作成など）については、より精緻な評価方法が必要です。 +スペクトルの右側にある 2 つの道具が、こうして本番評価の主役になります。**Rubric** で漠然とした「良し悪し」を個別に採点できる複数の次元に分解し、**LLM-as-a-Judge** で決定的な判定基準がない場合の採点を行うのです。両者が合わさってはじめて、漠然とした失敗率を着手可能な具体的問題へと還元できます。さらに本節後半の**失敗の帰属**と組み合わせることで、本番 Agent 評価の完全な閉ループが構成されます。 -コードの自動検証は標準解のあるシーンしかカバーせず、開放的タスクの採点こそ本節の主題です。そのうち、報酬信号の密度設計（二値報酬から過程報酬、さらに生成式報酬へ）および報酬モデルの訓練方法は、第 8 章のポストトレーニング部分で系統的に論じます。本節ではより基礎的な問いに答えます。いかに LLM を使って開放的タスクの出力品質を自動的に評定するか、です。 +なお、右へ動かすことは左側を放棄することを意味しません。プログラムのアサーションとして書ける検査はすべてアサーションのままにすべきで、LLM による評定は機械的に判定できない次元にのみ用います。決定的な検査のほうが安価で安定しており、回帰テストとして長期に走らせるのにも適しています。 ### LLM-as-a-Judge：自動化評価の核心 -![図7-4 LLM-as-a-Judge パイプライン](images/fig7-4.svg) +![図7-5 LLM-as-a-Judge パイプライン](images/fig7-5.svg) なぜ LLM-as-a-Judge が必要なのでしょうか。開放的タスク（レポート生成、顧客クレーム処理、創作コンテンツなど）については、自動的に対比できる標準解がなく、人手評価はコストが高く規模化が難しいのです。LLM-as-a-Judge は、言語モデルに専門家が定義した採点基準（Rubric）に従って評定させることで、自動化のスケールと人間の専門的判断の間のバランスを取ります。しかしこの方法には既知の限界もあります。評者モデルは自身のバイアスを持ちうる（最も典型的なのは **長さバイアス** で、内容がより正しいわけでなくても、より長く詳細な返答に高得点をつける傾向がある）ほか、同じ入力を複数回評定しても変動しうるのです。長さバイアスは特に個別に防ぐ価値があり、よく使われる手段は 3 つあります。Rubric の中で冗長さを明示的にペナルティにし、同類タスクに回答の長さ上限を規定すること。配対比較をするとき、まず 2 つの候補の長さを近づけてから評定すること。そして定期的にスコアと回答長の相関を監査すること——もし高得点がほぼ常に長い回答を伴うなら、評定が長さに引きずられていることを示すので、Rubric を作り直す必要があります。これらの課題に系統的に対処するため、Rubric 設計は以下の準則に従わなければなりません。 @@ -363,7 +363,7 @@ rubric: Rubric と Agent の回答を評価モデルに渡すと、各項目の点数と根拠が返ります。数十件の結果を集計し、低得点の軌跡を読み直せば、漠然とした「成功率の低下」を具体的な原因に分解できます。情報を取得できなかったのか、人物関係を取り違えたのか、それとも根拠のない内容を補ったのか。Rubric は点数を付けるだけでなく、次に直すべき場所を示す診断器になります。 -以下では、ユーザーメモリを具体的な事例として、この汎用的な方法を実行可能な評価セットと採点器へどう落とし込むかを示します。 +以下では、ユーザーメモリを具体的な事例として、この汎用的な方法を実行可能な評価セットと検証器へどう落とし込むかを示します。 > **実験 7-3 ★★：Rubric に基づくユーザーメモリ評価システムの構築** > @@ -534,7 +534,7 @@ trajectory prefix 回帰タスクの答えは、唯一の行動や答えでは ### 配対比較とモデルランキング -![図7-5 Elo 評価と配対比較ランキング](images/fig7-5.svg) +![図7-6 Elo 評価と配対比較ランキング](images/fig7-6.svg) **Elo 評価**（もともとチェスに用いられたランキングシステム）は大量の一対一の対決を通じてモデルの相対的な能力を定量化します。点差が大きいほど、強者の予想勝率が高くなります。例えばモデル A のスコアが 1200、モデル B のスコアが 1000 なら、Elo システムは A の勝率を約 76% と予測します。もし B が意外にも勝てば、B は多く加点され A は多く減点されます。番狂わせの結果はより大きなスコア調整をもたらし、このメカニズムがランキングを真の水準へ素早く収束させます。その背後にある統計的基礎が **Bradley-Terry モデル** です。各モデルを潜在的な「実力スコア」として抽象化し、一対一の対決の勝敗の確率を両者のスコア差によって決めるもので、Elo はこのモデルのオンライン更新形式の工学的実装です。 @@ -698,7 +698,7 @@ return paired_bootstrap_or_mcnemar(all_deltas) 評価駆動の意思決定（モデル選定であれ継続的反復であれ）は、いずれも高品質の実行データに依存します。以下ではまず、いかにこれらのデータを系統的に収集するか（可観測性）を紹介し、次にいかに評価結果をシステム改善へと転化するかを論じます。 -![図7-6 可観測性技術スタック](images/fig7-6.svg) +![図7-7 可観測性技術スタック](images/fig7-7.svg) 可観測性（Observability）というこの概念は分散システムの領域から借りたものです。システムの内部を直接開いて何をしているかを見ることはできず、それが出力するログ、指標、トレースデータを通じてのみ、何が起きたかを推し量れます。ちょうど医師が患者の体内を直接見ることはできず、体温、血圧、画像などの外部信号を通じてのみ問題を診断できるのと同じです。Agent システムはこれをさらに難しくします。同じ入力でも異なる出力を生みうるし、複数ターンの推論とツール呼び出しが実行経路をきわめて複雑にし、しかもモデルの「思考」過程は外部にはまったく不透明です。 @@ -718,11 +718,11 @@ LangSmith はこの領域の代表的なプラットフォームの 1 つ（似 ここでは、付属リポジトリに保存された AndroidWorld の実際の改善試行を見ます。対象は API 35 エミュレーター上の Wi-Fi 設定 4 タスクだけで、各タスクにつき 1 回のペア実行です。116 タスクの完全な Benchmark でも、API 33 の標準環境での再検証でもありません。価値があるのはシステム全体の改善率を示すことではなく、1 ラウンドの結果から次の 1 変更をどう決めるかを示す点です。 -![図7-7 Benchmark から改善への閉ループ](images/fig7-7.svg) +![図7-8 Benchmark から改善への閉ループ](images/fig7-8.svg) Harness 工学の視点から見ると、この節が本質的に語っているのは Harness の反復最適化の方法論です。評価データを通じて Harness の弱点（コンテキスト不足？ 制約の欠如？ 検証の不足？ フィードバックの遅れ？）を特定し、的を絞って改善し、再び評価して、Harness が継続的に進化する閉ループを形成します。 -Benchmark レポートの分析を始める前に、見落とされやすい 1 つの原則があります。**Agent の性能低下を見たときは、まず評価システム自体をチェックしてから Agent に手をつけるべき** です。よくある誤りは、スコアの低下を見た途端に Agent のコードを修正し、評価システム自体が先に問題を起こしているかもしれないことを無視することです。歪んだ信号に基づいて方向を調整すれば、改善の方向が最初から誤っているかもしれません。評価システムのよくあるエラー源には、実行環境のリソース不足でプロセスが kill される（ランダムな失敗として現れる）、採点器自体にバグがあり正解を失敗と判定する、テストケースと本番シーンの間に乖離がある、などがあります。これらの問題は結果の数字上ではモデルの退化とまったく同じに見え、完全な軌跡を精査してはじめて区別できます。 +Benchmark レポートの分析を始める前に、見落とされやすい 1 つの原則があります。**Agent の性能低下を見たときは、まず評価システム自体をチェックしてから Agent に手をつけるべき** です。よくある誤りは、スコアの低下を見た途端に Agent のコードを修正し、評価システム自体が先に問題を起こしているかもしれないことを無視することです。歪んだ信号に基づいて方向を調整すれば、改善の方向が最初から誤っているかもしれません。評価システムのよくあるエラー源には、実行環境のリソース不足でプロセスが kill される（ランダムな失敗として現れる）、検証器自体にバグがあり正解を失敗と判定する、テストケースと本番シーンの間に乖離がある、などがあります。これらの問題は結果の数字上ではモデルの退化とまったく同じに見え、完全な軌跡を精査してはじめて区別できます。 ### Benchmark レポートを読み解く：問題発見の技 @@ -827,7 +827,7 @@ Agent 開発者への示唆はこうです。特性スイッチはデバッグ この橋の両端はこう接続されます。評価側ですでに蓄積した資産は、ほぼシームレスに訓練信号に転換できます。定義の明確な一組の Rubric や検証器は、本質的に **検証可能報酬（RLVR、Reinforcement Learning with Verifiable Rewards）** の報酬関数そのものです——採点スクリプトがそのまま報酬スクリプトになり、テストが通るか、状態が達成されたかは、評価の判拠であると同時に強化学習の報酬でもあります。しかし訓練は評価段階では気にしなくてよかった新しい要求を突きつけます。1 つは **信頼できる reset の意味論** です。訓練は数百万の episode（1 つの episode とは初期状態からタスク終了までの 1 回の完全なインタラクションのラウンド）を走らせ、各 episode は環境を確定的でクリーンな初期状態にリセットできなければならず、さもなくば勾配信号が前ラウンドの残留状態に汚染されます。もう 1 つは **評価をはるかに上回るスループット** です。評価は数千回で結論を出せば充分ですが、訓練は許容できる実時間の中でモデルに数百万回のインタラクションを与えねばならず、環境の並列度と単一インスタンスの開銷が訓練の実行可能性を直接左右します。この 2 点——報酬関数化された検証器、訓練向けの reset とスループット——はいずれも第 8 章で展開します。 -![図7-8 シミュレーション忠実度スペクトル](images/fig7-8.svg) +![図7-9 シミュレーション忠実度スペクトル](images/fig7-9.svg) **デジタル環境** の面では、AWorld フレームワークが GAIA タスクのために制御可能な MCP サーバーサンドボックスを構築し、26 個の MCP サーバーを提供し、126 個のツール関数をカバーし、本物の API への直接アクセスがもたらす BAN や制御不能な副作用を避けます。すべてのツール呼び出しは再生可能で監査可能です。AWorld の分散アーキテクチャは従来の直列実行の 7695 秒を 525 秒に短縮し（14.6 倍の高速化）、環境のステートレス設計により各インスタンスが完全に独立し、効率的な並列をサポートします。 @@ -838,7 +838,7 @@ Agent 開発者への示唆はこうです。特性スイッチはデバッグ > ロボット操作のシミュレーション環境を構築します。`ch7/SimpleVLA-RL` と OpenVLA のドキュメントを読み、視覚・言語・行動モデルのアーキテクチャ（視覚エンコーダ + 言語モデル + 行動デコーダをエンドツーエンドに統合、画像とテキストを共有の意味空間に投影）を理解します。RoboTwin2 環境を構成し、観測空間（3 視点 RGB + 14 次元関節状態）と行動空間（14 次元制御ベクトル）を理解します。move_can_pot における環境ランダム化メカニズムと空間制約ロジックを研究します。事前学習済みモデルの評価を実行し、成功率、完了時間、失敗モードを記録し、動作チャンキングメカニズムの影響を重点的に観察します。 > > -> ![図7-9 OpenVLA と RoboTwin2 の身体化知能環境](images/fig7-9.svg) +> ![図7-10 OpenVLA と RoboTwin2 の身体化知能環境](images/fig7-10.svg) > > @@ -850,7 +850,7 @@ Agent 開発者への示唆はこうです。特性スイッチはデバッグ ## 本章のまとめ -本章の中心にある問いは、Agent が本当に改善したとどう判断するかです。再現可能な環境、漏洩に強いデータセット、LLM による評価、結果に基づくモデル選定と反復のどこが崩れても、結論は信用できません。実測からはさらに 4 つの注意点が得られました。構造化メモリと RAG の併用は相乗効果を保証しない。キャッシュと圧縮の削減率は足せない。参照音声の選び方でマルチモーダル評価の意味が変わる。そして Agent が UI を読めるか、そのために何 token 使うかは、Harness が入力をどう表現するかに左右される。モデル選定では一点の成績ではなく、資源予算ごとの能力曲線を比べるべきです。本番評価は時折行う試験ではなく、製品判断に組み込まれた継続的な検証です。 +本章の中心にある問いは、Agent が本当に改善したとどう判断するかです。この鎖は 4 つの環節から成ります。まず何をもって成功とするかを整理し（Pass@k、Best@k、Pass consecutive@k の基準の違い）、次にタスクがどこから来るかを定め（公開ベンチマーク、自作の業務集、本番軌跡の還流という 3 つの出所）、続いて検証の方式を選び（決定的検証器から検査項目リスト、Rubric と LLM 評定、さらに配対比較まで）、最後にスコアを意思決定へ変えます（統計的有意性、失敗の帰属、回帰タスク、モデル選定）。どの環節が崩れても、結論は信用できません。実測からはさらに 4 つの注意点が得られました。構造化メモリと RAG の併用は相乗効果を保証しない。キャッシュと圧縮の削減率は足せない。参照音声の選び方でマルチモーダル評価の意味が変わる。そして Agent が UI を読めるか、そのために何 token 使うかは、Harness が入力をどう表現するかに左右される。モデル選定では一点の成績ではなく、資源予算ごとの能力曲線を比べるべきです。本番評価は時折行う試験ではなく、製品判断に組み込まれた継続的な検証です。 本書全体の構造から言えば、本章が組み立てているのは第 1 章の発見ループにおける**証拠**の区間です。失敗帰属が、後続の提案に拠るべき根拠があるかどうかを決めます。 @@ -858,7 +858,7 @@ Agent 開発者への示唆はこうです。特性スイッチはデバッグ 核心的な方法論：観察→仮説→実験→検証→新しい認識→新しい仮説。これが Agent 工学を経験駆動の「錬金術」からデータ駆動の科学的工学へと転換させます。 -本章で紹介した評価体系は 1 つの完全な閉ループを形成します。**評価環境** が自動化されたテストインフラを提供する → **評価データセット** がテストケースを定義する → **自動化評価方法**（LLM-as-a-Judge と Rubric）が Agent の性能を採点する → **Benchmark 分析** が改善の方向を明らかにする → **システム改善** が問題を修復する → 評価環境とデータセットを更新し、新しいラウンドの反復を始める。 +本章で紹介した評価体系は 1 つの完全な閉ループを形成します。**評価環境** が自動化されたテストインフラを提供する → **評価データセット** がテストケースを定義する → **自動化評価方法**（決定的検証器、LLM-as-a-Judge、Rubric）が Agent の性能を採点する → **Benchmark 分析** が改善の方向を明らかにする → **システム改善** が問題を修復する → 評価環境とデータセットを更新し、新しいラウンドの反復を始める。 本章で確立した評価体系は現在のシステムの最適化に資するだけでなく、次章のモデルのポストトレーニングに鍵となる基礎も提供します——評価環境とデータセットはポストトレーニングの重要な入力であり、シミュレーション環境はポストトレーニングの練習場です。次章では評価からモデルレベルの改善へと転じ、いかに SFT と RL を通じてインタラクション方策をモデルパラメータに書き込むかを深く論じます。 diff --git a/book-ja/images/fig7-1.svg b/book-ja/images/fig7-1.svg index e728bdb66..d7d7cb18b 100644 --- a/book-ja/images/fig7-1.svg +++ b/book-ja/images/fig7-1.svg @@ -1,19 +1,62 @@ - - - -第1層：環境を評価する -「どこでテストするか」— ツール呼び出し / 人間・機械インタラクション / シミュレーション環境 - - -第2層：評価手法 -「どう判定するか」— データセット設計・LLM-as-a-Judge・ペアワイズ比較とランキング - - -第3層：評価駆動の意思決定 -「テスト後に何をするか」— モデル選定・アーキテクチャ最適化・継続的イテレーション - -章全体を貫くエンジニアリングテーマ -・可観測性 -・シミュレーション環境 -・内部評価 - \ No newline at end of file + + + + + + + + +① 成功の定義 +Pass@k は能力の上限 · Pass^k は業務の信頼性 + + + +② タスクの出所 + +公開ベンチマーク +手法の借用 · 粗い選別 + +自作の業務集 +現実のタスク分布 + +本番軌跡の還流 +失敗の帰属の産物 + + + +③ 検証の方式 +← タスクの機械的検証可能性の順 → + +決定的検証器 +SWE-bench + + +検査項目リスト +τ²-bench + + +Rubric + LLM 評定 +オープンエンドなタスク + + +配対比較 +Chatbot Arena + + + +④ 結果の活用 +統計的有意性 → 失敗の帰属 → 回帰タスク → モデル選定と Harness の反復 + + +回帰タスクが新しいケースになる + + +支えるインフラ +可観測性（軌跡の提供） · 内部評価インフラ（アブレーション / AB / フィーチャーフラグ） · シミュレーション環境（第 8 章へ） + diff --git a/book-ja/images/fig7-10.svg b/book-ja/images/fig7-10.svg new file mode 100644 index 000000000..d5a677d09 --- /dev/null +++ b/book-ja/images/fig7-10.svg @@ -0,0 +1,69 @@ + + + + +マルチモーダル観測 + +頭部カメラ +224×224 RGB + +左手首カメラ +224×224 RGB + +右手首カメラ +224×224 RGB + +14 次元の関節状態ベクトル + +Vision-Language-Action モデル（VLA） + +ビジョンエンコーダ +SigLIP → ビジュアルトークン + + +言語モデル +Llama 2 7B バックボーン + + +アクションデコーダ +→ 14 次元の連続制御ベクトル +Action chunking: 連続する 25 個のアクションを一度に生成 + + + +指示: 「缶を鍋の中に入れて」 + + +SAPIEN 物理エンジン + +双腕ロボット +各腕 7 自由度 = 14 次元のアクション + +環境ランダム化 +位置 60cm / 姿勢 ±22.5° + +衝突判定 + 物理シミュレーション +剛体 / 柔軟体 / 摩擦 + +アクション + +観測 + +評価指標 + +成功率 +缶が鍋の中にあり +倒れていない + +完了時間 +25 ステップ × 25 アクション += 625 制御ステップ + +汎化能力 +位置・姿勢をまたぐ +/ 外観のバリエーション + +Sim-to-Real +ドメインランダム化 +→ 実機への移行 + \ No newline at end of file diff --git a/book-ja/images/fig7-3.svg b/book-ja/images/fig7-3.svg index 5da9cc30e..7a99426eb 100644 --- a/book-ja/images/fig7-3.svg +++ b/book-ja/images/fig7-3.svg @@ -1,68 +1,76 @@ - - + + + + + + + - -ユーザーシミュレーター（LLM） - -既知情報： -氏名: Sarah Johnson -予約: BK-98712 -タスク指示： -「フライトに問題があるようです」 -→ 詳細を段階的に明かす -→ 予約番号を自分から提示しない - -Agent（評価対象） - - -LLM 推論 + 戦略選択 -① 予約番号を教えていただけますか？ -② lookup_booking(BK-98712) -③ フライト UA123 はキャンセルされました -④ cancel_booking(BK-98712) -⑤ 150ドルを返金、3〜5営業日 - -ツール + データベース - -lookup_booking -予約詳細を照会 -modify_booking -予約状態を変更 -cancel_booking -キャンセルと返金 -search_flights -代替フライトを検索 -send_notification -確認通知を送信 - -DB 状態: -bookings, users, flights - -対話 - - -ツール呼び出し - - -二重制御環境：ユーザーシミュレーターも共有環境（ツール + データベース）を直接操作できる - -タスク完了後：多層検証 - -DB 状態チェック - -booking.status == 'cancelled' -refund_record EXISTS -refund.amount == 150.00 - -対話内容の検証 - -'refund' + 金額を含む -'arrival time' を含む -虚偽情報が存在しない - -プロセス遵守チェック - -変更前にユーザー確認を取得 -無断操作がない -人間オペレーターへの過剰な転送がない - \ No newline at end of file + + +ユーザーシミュレータ（LLM） +known_info：John Smith / 555-123-2002 / フランス滞在 +task_instructions：漸進的開示 · 感情 · 事実接地 +受け入れ基準：excellent のみ解決とみなす + + + +Agent（評価対象） +入力：チケット + ドメインポリシー +不可視：ユーザー端末の実際の状態 +誘導のみ可能で、代行はできない + + + +マルチターン対話 +漸進的な情報開示 + + + +共有環境（双方向制御：両側が状態を変更できる） + +端末側の状態 +機内モード ON · ローミング OFF · データセーバー · 残データ +ユーザー側：toggle_airplane_mode / toggle_roaming +　　　　　check_status_bar / run_speed_test + +キャリア側データベース +顧客 C1001 · 回線 L1001/L1002/L1003 · プラン · 請求 +Agent 側：get_customer_by_phone / get_data_usage +　　　　　　enable_roaming / refuel_data + + + + + + +ユーザーの toggle_roaming で環境は変化した。Agent はツールを呼び直さないと結果を知れない——検証はこの読み直しまでを覆う + + + +タスク終了後：4 層の検査 + 集約ルール + +env_assertions +モバイルデータ利用可 +速度 ≥ 200 / excellent + +actions +toggle_airplane_mode +requestor は user であること + +communicate_info +必要な情報を伝えたか +この問題では null + +nl_assertions +自然言語レベルの判定 +この問題では null +reward_basis = ["ENV_ASSERTION"]　→　第 1 層のみ採用。他の層は記録されるが報酬には算入されない + diff --git a/book-ja/images/fig7-4.svg b/book-ja/images/fig7-4.svg index 9865d5a5d..4168c5280 100644 --- a/book-ja/images/fig7-4.svg +++ b/book-ja/images/fig7-4.svg @@ -1,53 +1,54 @@ - - + + + + + + - -ルーブリック - -事実の正確性: 必須 -論理的整合性: 重要 -ハルシネーション検出: 拒否権 ⚠ -網羅性: 重要 - -候補回答 - -エージェント出力: -"返金処理が完了しました。$150 は次の期間内に - 3〜5 営業日以内に入金されます。" - - -参照解答（任意） - -標準解答 / 採点ポイント: -返金額を含めること -入金時期を含めること -具体的な期日を約束しないこと - - - - -審査モデル（GPT-5 / Gemini 2.5） -同一ソースバイアスを防ぐための多元的な異種評価 - - -構造化された評価出力 - -事実の正確性 -4/4 -金額と時期の両方が正確 -網羅性 -3/4 -返金方法の説明が欠落 -ハルシネーション検出 -PASS -虚偽情報なし -論理的整合性 -4/4 -因果関係が明確 - -スコア集約戦略 -加重平均: Σ(重み × 次元スコア) -拒否権: ハルシネーション=FAIL → 総合スコア=0 -複数審査: 3審査員の中央値 -エッジケースフラグ: 判定の食い違い >2点 → 人間によるレビュー - \ No newline at end of file + +タスクの機械的検証可能性：高 +低 + + +決定的検証器 +最終状態が一意に照会可能 +通過 / 不通過 +SWE-bench はテスト実行 + + + +検査項目リスト +複数の決定的検査 +宣言された基準で集約 +τ²-bench の 4 層検証 + + + +Rubric + LLM 評定 +次元は分けられるが機械判定は不可 +次元ごとに採点し理由を示す +接客品質、レポート作成 + + + +配対比較 +次元すら書き出しにくい +A と B の優劣のみ判定 +Chatbot Arena + + +決定的検証 +完全に再現可能、CI に組み込め、低コスト +代償：正誤のみで、問題の所在は示さない + + +モデルによる評定 +診断次元を取り出せ、アサート不能な課題も覆う +代償：評定のバイアスとばらつき、コスト増 + diff --git a/book-ja/images/fig7-5.svg b/book-ja/images/fig7-5.svg index 2939199b4..9865d5a5d 100644 --- a/book-ja/images/fig7-5.svg +++ b/book-ja/images/fig7-5.svg @@ -1,56 +1,53 @@ - + - -Chatbot Arena 匿名バトル - -モデル A（匿名） - -"返金処理が完了しました。3〜5 営業日以内に - お客様の口座に入金されます" -VS - -モデル B（匿名） - -"了解しました、返金処理を行います" - - -ユーザーがブラインドで選択 → A のほうが優れている - -Elo 更新式 -期待勝率 E_A = 1/(1+10^((R_B-R_A)/400)) | 更新: R_A' = R_A + K*(1-E_A) -リアルタイムリーダーボード（例） -順位 -モデル -Elo -2位との勝率 - -1 -Claude 4 Opus -1352 -— -2 -GPT-5 -1318 -— -3 -Gemini 2.5 Pro -1290 -45% -4 -DeepSeek R2 -1265 -42% -5 -Qwen 3 Max -1230 -39% -6 -Llama 4 405B -1198 -36% - - -GRPO: ペアワイズ比較を RL 学習に導入 -候補応答の集合 → 相対アドバンテージを正規化 → 方策更新（明示的な報酬モデルを回避） + +ルーブリック + +事実の正確性: 必須 +論理的整合性: 重要 +ハルシネーション検出: 拒否権 ⚠ +網羅性: 重要 + +候補回答 + +エージェント出力: +"返金処理が完了しました。$150 は次の期間内に + 3〜5 営業日以内に入金されます。" + + +参照解答（任意） + +標準解答 / 採点ポイント: +返金額を含めること +入金時期を含めること +具体的な期日を約束しないこと + + + + +審査モデル（GPT-5 / Gemini 2.5） +同一ソースバイアスを防ぐための多元的な異種評価 + + +構造化された評価出力 + +事実の正確性 +4/4 +金額と時期の両方が正確 +網羅性 +3/4 +返金方法の説明が欠落 +ハルシネーション検出 +PASS +虚偽情報なし +論理的整合性 +4/4 +因果関係が明確 + +スコア集約戦略 +加重平均: Σ(重み × 次元スコア) +拒否権: ハルシネーション=FAIL → 総合スコア=0 +複数審査: 3審査員の中央値 +エッジケースフラグ: 判定の食い違い >2点 → 人間によるレビュー \ No newline at end of file diff --git a/book-ja/images/fig7-6.svg b/book-ja/images/fig7-6.svg index b20c542a6..2939199b4 100644 --- a/book-ja/images/fig7-6.svg +++ b/book-ja/images/fig7-6.svg @@ -1,48 +1,56 @@ - - - -実行トレースツリー（単一タスク） - -Trace: ユーザーの明日の北京の天気を確認（3.2s, $0.008） - -LLM Call: 意図認識 -Claude 4 Sonnet · 0.4s · 320 tokens - -Tool：get_weather(Beijing) -MCP Server · 1.8s · 200ms TTFT - -├─ HTTP リクエスト -api.weather.com · 1.6s - -└─ レスポンス解析 -JSON → 構造化された天気データ - -LLM Call: 応答生成 -Claude 4 Sonnet · 0.8s · 580 tokens - -Tool：send_message(user) -0.2s · 天気の要約を含む - - - - - - - -モニタリングダッシュボード - -コスト追跡 -本日: $12.30（1,200 回の呼び出し） -今月: $340（34K 回の呼び出し） -異常: task#892 が検索を 14 回ループ、コスト $2.1 - -パフォーマンス監視 -P50 / P95 / P99 レイテンシ: 2.1s / 8.4s / 15.2s -ツール成功率: 94.3% - -品質監査 -タスク成功率: 87% ハルシネーション発生: 2.1% -セキュリティ違反: 0（今月） ユーザー満足度: 4.3/5 - -クローズドループ: トレースデータ → 問題の特定 → A/B テスト → プロンプトのバージョン管理 → 継続的最適化 - + + + + +Chatbot Arena 匿名バトル + +モデル A（匿名） + +"返金処理が完了しました。3〜5 営業日以内に + お客様の口座に入金されます" +VS + +モデル B（匿名） + +"了解しました、返金処理を行います" + + +ユーザーがブラインドで選択 → A のほうが優れている + +Elo 更新式 +期待勝率 E_A = 1/(1+10^((R_B-R_A)/400)) | 更新: R_A' = R_A + K*(1-E_A) +リアルタイムリーダーボード（例） +順位 +モデル +Elo +2位との勝率 + +1 +Claude 4 Opus +1352 +— +2 +GPT-5 +1318 +— +3 +Gemini 2.5 Pro +1290 +45% +4 +DeepSeek R2 +1265 +42% +5 +Qwen 3 Max +1230 +39% +6 +Llama 4 405B +1198 +36% + + +GRPO: ペアワイズ比較を RL 学習に導入 +候補応答の集合 → 相対アドバンテージを正規化 → 方策更新（明示的な報酬モデルを回避） + \ No newline at end of file diff --git a/book-ja/images/fig7-7.svg b/book-ja/images/fig7-7.svg index 321b43eb1..b20c542a6 100644 --- a/book-ja/images/fig7-7.svg +++ b/book-ja/images/fig7-7.svg @@ -1,56 +1,48 @@ - - - - -① 観察: 診断レポート -全体成功率: 88% (102/116) -transcription: 0% complex_ui: 17% -math_counting: 0% Wi-Fi 操作: 0% -タスク 82,102-115 に失敗が集中 - -② 仮説: 3層の改善フレームワーク - -表層 -H1 設定ナビのプロンプト H2 UI ルール - -中間層 -H3 マルチモーダルパイプライン修正 H4 Thinking - -深層 -H5 GPT-5 H6 UI 要素ツリー - - -③ 実験: 段階的検証（設定ごとに 5 回 × 116 タスク） - -H1 ナビゲーション -設定 0%→75% -token+8% - -H3 マルチモーダル -文字起こし 0%→80% -レイテンシ +1s - -H4 Thinking -カウント 0%→70% -レイテンシ 3倍！ - -H6 要素ツリー -UI 17%→52% -token+30% - -④ 意思決定: コストとベネフィットのトレードオフ -✓ H1+H3: 低コスト・高ベネフィット → デプロイ -✗ H4: 恩恵を受けるのは 8% のタスクのみでレイテンシ 3倍 → 却下 -✓ H6: 35% 改善 / 30% コスト → デプロイ -✗ H5: 15s/ステップは許容不可 → 代替案 - -⑤ 反復: 新しいサイクル -H1+H3+H6 をデプロイ → 88%→94% -新しいレポートは異なる失敗モードを示す: - H7: 条件付きで Thinking を有効化 - H8: ジェスチャーの行動空間を拡張 - -↑ ループ - -方法論: 観察 → 仮説 → 実験 → 意思決定 → 反復 = 錬金術から科学的エンジニアリングへ - \ No newline at end of file + + + +実行トレースツリー（単一タスク） + +Trace: ユーザーの明日の北京の天気を確認（3.2s, $0.008） + +LLM Call: 意図認識 +Claude 4 Sonnet · 0.4s · 320 tokens + +Tool：get_weather(Beijing) +MCP Server · 1.8s · 200ms TTFT + +├─ HTTP リクエスト +api.weather.com · 1.6s + +└─ レスポンス解析 +JSON → 構造化された天気データ + +LLM Call: 応答生成 +Claude 4 Sonnet · 0.8s · 580 tokens + +Tool：send_message(user) +0.2s · 天気の要約を含む + + + + + + + +モニタリングダッシュボード + +コスト追跡 +本日: $12.30（1,200 回の呼び出し） +今月: $340（34K 回の呼び出し） +異常: task#892 が検索を 14 回ループ、コスト $2.1 + +パフォーマンス監視 +P50 / P95 / P99 レイテンシ: 2.1s / 8.4s / 15.2s +ツール成功率: 94.3% + +品質監査 +タスク成功率: 87% ハルシネーション発生: 2.1% +セキュリティ違反: 0（今月） ユーザー満足度: 4.3/5 + +クローズドループ: トレースデータ → 問題の特定 → A/B テスト → プロンプトのバージョン管理 → 継続的最適化 + diff --git a/book-ja/images/fig7-8.svg b/book-ja/images/fig7-8.svg index df5eae611..321b43eb1 100644 --- a/book-ja/images/fig7-8.svg +++ b/book-ja/images/fig7-8.svg @@ -1,41 +1,56 @@ - + - - -シミュレーション忠実度 → -スケーラビリティ - - - -↑ - -Mock API -単体テストレベル -毎時 100 万回 - -AWorld -MCP サンドボックス -126 個のツール関数 -分散で 525s/ラウンド - -AndroidWorld -シミュレータ -116 個の実アプリケーションタスク -UI Automator - -Isaac Gym -GPU 並列化 -数千の並列インスタンス -精度はやや犠牲になる - -RoboTwin2 -物理エンジン -高精度の衝突判定 -単一インスタンス CPU - -実世界 -完全な忠実度 -リセット不可 - + +① 観察: 診断レポート +全体成功率: 88% (102/116) +transcription: 0% complex_ui: 17% +math_counting: 0% Wi-Fi 操作: 0% +タスク 82,102-115 に失敗が集中 + +② 仮説: 3層の改善フレームワーク + +表層 +H1 設定ナビのプロンプト H2 UI ルール + +中間層 +H3 マルチモーダルパイプライン修正 H4 Thinking + +深層 +H5 GPT-5 H6 UI 要素ツリー + + +③ 実験: 段階的検証（設定ごとに 5 回 × 116 タスク） + +H1 ナビゲーション +設定 0%→75% +token+8% + +H3 マルチモーダル +文字起こし 0%→80% +レイテンシ +1s + +H4 Thinking +カウント 0%→70% +レイテンシ 3倍！ + +H6 要素ツリー +UI 17%→52% +token+30% + +④ 意思決定: コストとベネフィットのトレードオフ +✓ H1+H3: 低コスト・高ベネフィット → デプロイ +✗ H4: 恩恵を受けるのは 8% のタスクのみでレイテンシ 3倍 → 却下 +✓ H6: 35% 改善 / 30% コスト → デプロイ +✗ H5: 15s/ステップは許容不可 → 代替案 + +⑤ 反復: 新しいサイクル +H1+H3+H6 をデプロイ → 88%→94% +新しいレポートは異なる失敗モードを示す: + H7: 条件付きで Thinking を有効化 + H8: ジェスチャーの行動空間を拡張 + +↑ ループ + +方法論: 観察 → 仮説 → 実験 → 意思決定 → 反復 = 錬金術から科学的エンジニアリングへ \ No newline at end of file diff --git a/book-ja/images/fig7-9.svg b/book-ja/images/fig7-9.svg index d5a677d09..df5eae611 100644 --- a/book-ja/images/fig7-9.svg +++ b/book-ja/images/fig7-9.svg @@ -1,69 +1,41 @@ - - + + - -マルチモーダル観測 - -頭部カメラ -224×224 RGB - -左手首カメラ -224×224 RGB - -右手首カメラ -224×224 RGB - -14 次元の関節状態ベクトル - -Vision-Language-Action モデル（VLA） - -ビジョンエンコーダ -SigLIP → ビジュアルトークン - - -言語モデル -Llama 2 7B バックボーン - - -アクションデコーダ -→ 14 次元の連続制御ベクトル -Action chunking: 連続する 25 個のアクションを一度に生成 - - - -指示: 「缶を鍋の中に入れて」 - - -SAPIEN 物理エンジン - -双腕ロボット -各腕 7 自由度 = 14 次元のアクション - -環境ランダム化 -位置 60cm / 姿勢 ±22.5° - -衝突判定 + 物理シミュレーション -剛体 / 柔軟体 / 摩擦 - -アクション - -観測 - -評価指標 - -成功率 -缶が鍋の中にあり -倒れていない - -完了時間 -25 ステップ × 25 アクション -= 625 制御ステップ - -汎化能力 -位置・姿勢をまたぐ -/ 外観のバリエーション - -Sim-to-Real -ドメインランダム化 -→ 実機への移行 + + +シミュレーション忠実度 → +スケーラビリティ + + + +↑ + +Mock API +単体テストレベル +毎時 100 万回 + +AWorld +MCP サンドボックス +126 個のツール関数 +分散で 525s/ラウンド + +AndroidWorld +シミュレータ +116 個の実アプリケーションタスク +UI Automator + +Isaac Gym +GPU 並列化 +数千の並列インスタンス +精度はやや犠牲になる + +RoboTwin2 +物理エンジン +高精度の衝突判定 +単一インスタンス CPU + +実世界 +完全な忠実度 +リセット不可 + \ No newline at end of file diff --git a/book-ko/chapter7.ko.md b/book-ko/chapter7.ko.md index 8014dfad1..1bed8c7eb 100644 --- a/book-ko/chapter7.ko.md +++ b/book-ko/chapter7.ko.md @@ -17,58 +17,116 @@ 1장에서 소개한 하네스 엔지니어링의 관점에서 평가는 하네스 안에서 "검증"이라는 핵심 역할을 맡습니다. 중요한 통찰은 **평가 대상이 모델 하나가 아니라 모델과 하네스의 조합이어야 한다**는 것입니다. 같은 모델도 하네스에 따라 성능이 크게 달라질 수 있습니다. 어떤 팀은 하네스만 최적화하여 같은 모델의 터미널 작업 성능을 크게 높였습니다(5장 참조). 따라서 에이전트의 평가 결과가 좋지 않을 때 해결책은 모델 교체가 아니라 프롬프트, 도구 설계, 피드백 루프 같은 하네스 컴포넌트의 개선일 수 있습니다. 건전한 평가 시스템은 "모델 역량 부족"과 "하네스 설계 결함"이라는 근본적으로 다른 두 문제를 구분할 수 있어야 합니다. **이를 구분하는 일반적인 방법은 모델 교체 실험**입니다. 하네스를 고정한 채 더 강하거나 약한 모델로 바꾸고 점수가 얼마나 움직이는지 관찰합니다. 더 강한 모델로도 점수가 오르지 않으면 병목은 하네스입니다. 약한 모델에서 점수가 급락하고 결과가 모델 역량에 따라 크게 요동한다면, 가장 직접적인 해석은 모델 자체가 병목이고 현재 성능이 모델에 지배된다는 것입니다. 과제 자체가 본질적으로 어렵기 때문인지, 하네스가 모델의 사전 지식에 지나치게 의존하기 때문인지는 추가로 분석해야 합니다. 이는 앞의 제거 실험과 다릅니다. 제거 실험은 **하네스 컴포넌트를 비활성화**하고 전체 성능 변화를 살펴보지만, 모델 교체는 **하네스를 고정하고 모델만 바꿉니다**. 전자는 하네스 내부에서 어느 부분이 중요한지 찾고, 후자는 병목이 모델인지 하네스인지 알려 줍니다. 모델이 빠르게 발전하는 시대에는 평가 시스템의 가치가 더 커집니다. 모델은 계속 개선되지만 공개 벤치마크 점수가 더 높은 새 모델이 여러분의 작업에서도 반드시 더 잘하는 것은 아닙니다. 오히려 일부 측면에서 이전 버전보다 나빠지는 회귀가 생길 수도 있습니다. 자체 평가 데이터셋에서 전체 평가를 실행해야만 데이터에 근거해 업그레이드를 결정할 수 있습니다. 견고한 평가 시스템이 있으면 "미래의 모델을 위한 제품 구축"도 실현 가능한 전략이 됩니다. 현재 모델의 품질이 상용 배포에 충분하지 않더라도 제품과 평가 세트를 완성하고 새 모델이 나올 때마다 성능을 추적하다가 기준을 넘는 순간 출시할 수 있습니다. +평가 체계는 네 개의 단계로 나눌 수 있다. 무엇을 성공으로 볼 것인가, 과제는 어디서 오는가, 누가 검증하는가, 점수를 어떻게 의사결정으로 바꾸는가. 그림 7-1과 같다. + +![그림 7-1: Agent 평가 체계의 네 단계](images/fig7-1.svg) + +## 평가 과제 한 건의 해부: τ²-bench의 telecom 도메인 + +먼저 τ²-bench의 telecom 도메인에서 실제 과제 하나를 통째로 해부해 보자. 소스는 저장소의 `chapter7/tau2-bench`에 있고, 과제 파일은 `data/tau2/domains/telecom/tasks_small.json`이다. + +### 과제 정의의 네 가지 구성 요소 + +다음은 그 파일에 들어 있는 과제 하나이며, 읽기 편하도록 일부를 생략했다. + +```jsonc +{ + "id": "[mobile_data_issue]airplane_mode_on|user_abroad_roaming_enabled_off", + + // Agent에게 전달되는 티켓 + "ticket": "사용자의 휴대폰이 인터넷에 연결되지 않고 상태 표시줄에 'No Service'가 + 표시된다. 고객 John Smith, 번호 555-123-2002, 현재 프랑스 체류 중. + 속도 테스트 결과가 excellent여야 해결로 인정한다. 요금제는 바꾸지 않되 + 필요하면 2.0 GB 데이터 충전은 감수한다.", + + // 사용자 시뮬레이터에게 전달되는 행동 규범 + "user_scenario": { "instructions": { + "known_info": "You are John Smith with phone number 555-123-2002. + You are currently abroad in France.", + "unknown_info": null, + "task_instructions": + "…express mild frustration after the first unsuccessful attempt. + You will consider the issue resolved only when speed test returns + excellent internet speed and nothing else. If it returns poor, fair + or good, you will not consider the issue resolved. + Whenever the agent asks you about your device, always ground your + responses on the results of tool calls. … + Never make up the results of tool calls." + }}, + + // 실행 전에 양쪽 상태를 같은 출발점으로 초기화한다 + "initial_state": { "initialization_actions": [ + { "env_type": "user", "func_name": "turn_airplane_mode_on" }, + { "env_type": "user", "func_name": "turn_roaming_off" }, + { "env_type": "assistant", "func_name": "enable_roaming", + "arguments": { "customer_id": "C1001", "line_id": "L1002" } } + ]}, + + // 채점 기준 + "evaluation_criteria": { + "actions": [ + { "requestor": "user", "name": "toggle_airplane_mode" }, + { "requestor": "user", "name": "toggle_roaming" } + ], + "env_assertions": [ + { "func_name": "assert_mobile_data_status", "expected_status": true }, + { "func_name": "assert_internet_speed", + "expected_speed": 200, "expected_desc": "excellent" } + ], + "communicate_info": null, + "nl_assertions": null, + "reward_basis": ["ENV_ASSERTION"] + } +} +``` -> **장 안내** -> -> 이 장에서는 세 수준으로 완전한 평가 시스템을 구축합니다. 첫 번째 수준은 "어디에서 테스트할지"를 다루는 **평가 환경**입니다. 도구 호출과 인간-컴퓨터 상호작용이라는 두 패러다임을 포괄하여 자동화되고 재현 가능한 테스트 환경을 구성하는 방법을 설명합니다. 두 번째 수준은 "어떻게 판단할지"를 다루는 **평가 방법**입니다. 데이터셋 설계 원칙과 평가 지표 체계(무엇을 측정할지)부터 자동 평가를 위한 LLM-as-a-Judge(대규모 언어 모델을 평가자로 사용), 쌍대 비교와 모델 순위까지 살펴봅니다. 세 번째 수준은 "테스트 후 무엇을 할지"를 다루는 **평가 기반 의사결정**입니다. 평가 결과를 모델 선택, 아키텍처 최적화, 지속적 개선을 위한 실행 가능한 지침으로 바꾸고, 관측된 점수 차이가 실제인지 통계적 유의성으로 판단합니다. 또한 관측 가능성과 프로덕션 수준 에이전트의 내부 평가 인프라를 다루고, 8장의 사후 학습으로 연결되는 시뮬레이션 환경으로 마무리합니다. -> -> 이 장 전체를 관통하는 생각은 다음과 같습니다. **평가 시스템의 가장 중요한 가치는 현재 시스템에 점수를 매기는 것이 아니라, 모델의 발전을 빠르고 신뢰성 있게 따라갈 수 있게 하는 데 있습니다.** 더 강하거나 저렴한 모델이 출시되면 견고한 평가 시스템을 갖춘 팀은 몇 시간 안에 교체 여부를 결정할 수 있습니다. 그렇지 않은 팀은 직관을 믿거나 커뮤니티의 피드백을 기다릴 수밖에 없습니다. 경쟁이 치열한 에이전트 시장에서는 이러한 속도 차이가 승패를 결정할 수 있습니다. +이 정의에서 짚고 넘어가야 할 설계가 네 군데 있다. -![그림 7-1: 평가 시스템의 세 수준](images/fig7-1.svg) +**사용자의 인지 경계가 명시적으로 모델링되어 있다.** `known_info`에는 이름, 번호, 체류 국가 세 가지만 들어 있다. 비행기 모드가 켜져 있다는 것과 데이터 로밍이 꺼져 있다는 것, 즉 진짜 고장 원인 두 가지는 거기에 없다. 사용자는 모르기 때문에 먼저 말할 수 없고, Agent는 질문하고 사용자에게 확인시키는 방식으로만 얻어낼 수 있다. 이것이 **점진적 정보 공개(Progressive Information Disclosure)** 를 과제 정의 수준에서 구현한 모습이다. "한꺼번에 다 말하지 말라"는 프롬프트로 시뮬레이터를 묶는 것이 아니라, 사용자의 지식 범위 자체를 독립된 필드로 모델링한 것이다. 대부분의 벤치마크는 과제 시작 시점에 완전한 요구사항을 제시하지만, 현실의 사용자가 처음 꺼내는 말은 대개 "인터넷이 안 된다" 정도다. 요구를 실행 가능한 수준까지 명확히 하는 일 자체가 Agent 능력의 일부다. -## 구체적인 평가 사례 +**시뮬레이터가 받는 것은 대사가 아니라 행동 규범이다.** `task_instructions`에는 세 종류의 제약이 섞여 있다. 감정 설정(첫 번째 복구 시도가 실패하면 가벼운 불만을 표시한다), 수용 기준(속도 테스트가 excellent일 때만 해결로 보고 poor, fair, good은 모두 거부한다), 그리고 **사실 접지(Grounding)** 요구, 즉 기기 상태에 관한 어떤 답변도 도구 반환값에 근거해야 한다는 것이다. "Never make up the results of tool calls." 세 번째가 특히 중요하다. 사실 접지 제약이 없으면 시뮬레이션된 사용자는 Agent의 유도를 따라 문제가 해결되었다고 확인해 버리고, 평가는 두 모델이 서로를 추인하는 일로 전락한다. -방법론을 자세히 살펴보기 전에 완전한 사례로 직관을 길러 보겠습니다. 고객 서비스 에이전트를 구축했고 환불 요청 처리 능력을 평가해야 한다고 가정합니다. +**초기 상태는 제어 주체에 따라 나뉘어 있다.** `env_type`은 `user`와 `assistant` 두 값을 가진다. 비행기 모드와 로밍 스위치는 사용자 쪽에, 통신사 쪽의 `enable_roaming`은 Agent 쪽에 속한다. 이 구분이 고장의 형태를 결정한다. 통신사 쪽에서는 로밍이 개통되어 있는데 사용자 단말에서는 꺼져 있으므로, Agent가 데이터베이스를 조회해도 "설정 정상"이라는 결론밖에 얻지 못한다. 고장은 데이터베이스에서 보이지 않는 쪽에 있고, 사용자에게 확인시켜야만 드러난다. -**테스트 케이스**: 사용자가 3일 전에 주문한 상품을 반품하려고 합니다(주문 번호 #12345, 금액 ¥299). 회사 정책은 7일 이내 전액 환불입니다. +**채점 기준은 네 층으로 나뉘어 있고, 이 과제는 그중 한 층만 채택한다.** `env_assertions`는 최종 상태를 검증하고(모바일 데이터 사용 가능, 속도 200 Mbps 이상이며 등급 excellent), `actions`는 핵심 동작이 발생했는지와 **어느 쪽이 수행했는지**를 검증하며, `communicate_info`와 `nl_assertions`는 필요한 정보를 사용자에게 전달했는지를 검증한다. 이 과제의 `reward_basis`는 `ENV_ASSERTION`만 선언하고 있고, 나머지 층은 평소대로 계산·기록되지만 최종 보상에는 반영되지 않는다. 채점 기준은 과제마다 선언되는 것이지 전역으로 고정된 것이 아니다. -**에이전트 궤적**: +### 실제 실행 한 건의 궤적 -```text -사용자: 3일 전에 산 헤드폰을 반품하고 싶습니다. 주문 번호는 12345입니다. (오늘은 2026-04-10입니다.) +이제 독자가 직접 τ²-bench telecom 도메인의 평가 과제를 실행하여 과제 설계, 사용자 시뮬레이터 설계, 과정과 결과의 검증 로직을 관찰하고, Agent의 실행 궤적을 살펴 왜 실패했는지 분석해 보기를 권한다. + +> **실험 7-1 ★: τ²-bench 실행 및 τ-bench로부터의 진화 비교** +> +> 본 실험은 τ²-bench 평가 프레임워크를 실행하여 인간-컴퓨터 상호작용 평가 환경의 설계 요점을 이해한다. 먼저 이 절에서 밟은 경로대로 과제 정의 파일을 통독한다. 각 과제는 알려진 정보, 과제 지시, 초기 상태, 성공 조건의 네 부분으로 구성된다. 이어서 전체 평가 흐름을 실행하고, 사용자 시뮬레이터와 Agent의 다중 턴 대화를 관찰하며 전형적인 실패 양상(정책 위반, 정보 누락, 과도한 상담원 이관 등)을 분석한다. +> +> ![그림 7-3: τ²-bench의 이중 제어 환경과 계층적 검증](images/fig7-3.svg) -에이전트(사고): 사용자가 환불을 원하므로 먼저 주문 정보를 확인해야 한다. -에이전트 → 도구 호출 query_order(order_id="12345") -도구 반환: {status: "delivered", amount: 299, date: "2026-04-07", item: "Bluetooth Headphones"} +부속 저장소에는 한 번의 실행 기록(`chapter7/tau2-bench-eval`)이 보존되어 있다. 아래에서는 그중 성공한 실행 하나를 분석한다. -에이전트(사고): 주문일은 2026-04-07이고 오늘은 2026-04-10이므로 3일이 지났다. 7일 환불 기간 안이므로 전액 환불 대상이다. -에이전트 → 도구 호출 process_refund(order_id="12345", amount=299) -도구 반환: {refund_id: "R-98765", status: "processing", eta: "3-5 business days"} +앞의 십여 턴은 계정 식별 단계다. Agent는 번호로 고객 C1001을 찾아낸 뒤 L1001, L1002, L1003 세 회선의 데이터 사용량을 차례로 조회하고, 다시 사용자가 프랑스에서 실제로 쓰는 번호를 묻는다. 17번째 메시지에서 Agent는 잘못된 결론을 내린다. -에이전트: 환불을 접수했습니다. 주문 #12345(Bluetooth Headphones, ¥299)의 전액 환불을 처리 중이며, - 영업일 기준 3~5일 안에 입금될 예정입니다. 환불 ID는 R-98765이며 진행 상황을 확인할 때 사용할 수 있습니다. -``` +> **Agent**(17): 번호 555-123-2002는 활성 회선에 없습니다. 가장 가까운 것은 555-123-2001입니다…… + +이 결론은 L1001 한 회선의 조회 결과에만 근거한 것이다. 사용자가 번호가 맞다고 고집하자 Agent는 L1002를 조회하고 나서야 일치시킨다. 결정적 전환은 30번째에서 일어난다. -**루브릭으로 채점**(네 차원, 각각 1~4점). 표 7-1은 이 고객 서비스 환불 작업의 채점 사례를 보여 주며, 루브릭이 에이전트 궤적을 확인 가능한 평가 차원으로 나누는 방법을 설명합니다. +> **사용자**(30) → `check_network_status()`, `check_status_bar()` 호출 +> +> **도구 반환**(31): `Airplane Mode: ON | Cellular Connection: no_service | Mobile Data Enabled: Yes | Data Roaming Enabled: No` +> +> **사용자**(33): 휴대폰이 지금 비행기 모드라서 신호가 없는 것 같습니다. 모바일 데이터는 켜져 있지만 데이터 로밍은 꺼져 있습니다. 비행기 모드를 꺼서 시도해 볼까요? -표 7-1 고객 서비스 환불 작업의 루브릭 채점 사례 +도구 호출을 발한 쪽은 Agent가 아니라 **사용자**다. 이것이 **이중 제어(Dual-Control)** 메커니즘이다. 시뮬레이션된 사용자는 `check_status_bar`, `toggle_airplane_mode`, `reseat_sim_card`, `run_speed_test` 같은 독자적인 도구 세트를 가진다. -| 차원 | 기준 | 점수 | 이유 | -|------------------------|--------------------------------|------|--------------------------------| -| 작업 정확성 | 환불 금액과 주문 번호가 정확한가? | 4 | 조회한 뒤 ¥299 전액 환불을 올바르게 접수함 | -| 정책 준수 | 7일 환불 정책을 따르는가? | 4 | 주문이 환불 기간 안에 있어 정책을 준수함 | -| 정보 완전성 | 금액, 입금 시점, 환불 ID를 제공하는가? | 4 | 세 가지 핵심 정보를 모두 제공함 | -| 환각 감지(즉시 탈락 항목) | 존재하지 않는 정보를 지어내는가? | 통과 | 모든 정보가 도구 출력에서 나옴 | +이후의 진단은 순조롭다. Agent가 사용자에게 비행기 모드를 끄고 로밍을 켜라고 요청하고, 사용자가 실행하자(35, 37) 상태 표시줄이 5G 풀바로 바뀐다. Agent가 속도 측정을 요청하니 275 Mbps, 등급 Excellent가 반환되고(46) 사용자가 해결을 확인한다. 두 개의 `env_assertions`가 모두 통과하여 `reward = 1.0`이 된다. -환각은 단계별 점수를 매기는 차원이 아니라 **즉시 탈락 항목**으로 두었습니다. 환각은 품질과 직교하기 때문입니다. 거짓 정보가 들어간 유창하고 상세하며 정중한 답변은 짧지만 정확한 답변보다 사용자에게 훨씬 더 해롭습니다. (즉시 탈락 메커니즘의 일반적인 설계는 뒤의 "루브릭의 네 가지 원칙" 절을 참조하세요.) +이 만점 궤적에도 검증기가 잡아내지 못한 문제가 하나 들어 있다. telecom의 Agent 정책 첫 단락에는 "You should only make one tool call at a time"이라고 명시되어 있는데, 4번째 메시지에서 Agent는 `get_customer_by_phone`과 `get_customer_by_name`을 한 번에 발행했다. 검증기가 이를 오류로 판정하지 않은 이유는 이 과제의 `reward_basis`가 최종 상태만 고려하기 때문이다. 이는 τ²-bench의 실수가 아니라 이진 보상의 본질적 대가다. 과정의 입도를 모델 간 비교 가능한 단일 숫자와 맞바꾼 것이다. 그러나 프로덕션 환경의 평가 시스템은 대개 그 이상을 요구한다. 옳고 그름을 판정하는 데 그치지 않고 문제가 어디에 있는지를 짚어 주어야 한다. -이 테스트 케이스는 통과했습니다. 하지만 좋은 평가는 성공 시나리오만 테스트하지 않고 경계와 함정도 탐색합니다. 사용자가 15일 전에 주문한 상품을 반품하려고 할 때(환불 기간 초과) 에이전트가 올바르게 거부할 수 있을까요? 사용자가 "고객 서비스 담당자가 이미 환불을 승인했습니다"라고 주장할 때 시스템 기록 없이 믿을까요? 이러한 경계 시나리오가 강한 에이전트와 약한 에이전트를 진정으로 구분합니다. +실패한 과제도 분석할 가치가 있다. 사용자 번호는 555-123-2002인데 Agent는 L1001 회선을 선택하고 그 3.2/5 GB 사용량을 근거로 추론을 이어 갔다. 도중에 `get_details_by_id(L1001)`이 그 회선의 번호가 555-123-2001이라고 분명히 반환했음에도 Agent는 그 결과를 읽고도 판단을 고치지 않았고, 이후 무관한 진단에 수십 개의 메시지를 소모한 끝에 상담원으로 이관했다. 사실 과제의 절반은 해냈다. 사용자에게 데이터 절약 모드를 끄게 했고 그 사용자 쪽 동작은 실제로 발생하여 환경에서 검증되었다. 그러나 회선 선택을 잘못한 탓에 필요한 2 GB 충전이 실행되지 않았고 세 개의 최종 상태 어서션이 모두 실패했다. 이 실패의 형태는 뒤의 "실패 귀인" 절에서 다루는 AndroidWorld 사례와 매우 닮았다. 판단을 고치는 데 필요한 증거는 이미 컨텍스트에 들어와 있었는데도 Agent가 그것을 근거로 되짚지 않은 것이다. -테스트 케이스를 정의하고, 에이전트를 실행하고, 루브릭으로 채점하고, 결과를 분석하는 위 과정이 평가의 기본 뼈대입니다. 이 장의 나머지 부분에서는 각 단계의 설계를 구체화합니다. +이 과제 하나로 평가 세트가 답해야 할 질문은 이미 모두 나왔다. 무엇을 성공으로 볼 것인가, 과제는 어디서 오는가, 누가 검증하는가, 점수를 어떻게 의사결정으로 바꾸는가. 이어지는 절에서 차례로 다룬다. -## 평가 지표 체계: 업데이트된 기준 +## 평가 지표: 성공의 정의 -환경이나 데이터셋을 만들기 전에 “성공”의 의미부터 정해야 합니다. 한 번이라도 가능한 경로를 찾으면 되는지, 아니면 모든 실행이 정확해야 하는지에 따라 공학적 결정이 달라집니다. 이 절에서는 먼저 이 잣대를 세우고, 뒤에서 환경과 데이터셋, 채점기를 어떻게 구현하는지 설명한다. +앞 절의 평가 결과는 다섯 과제 중 네 과제 통과였다. 0.8이라는 숫자만으로는 그 시스템을 쓸 수 있는지 판단할 수 없다. 그것이 환불 상담 Agent라면 다섯 명 중 한 명이 받아야 할 환불을 받지 못한다는 뜻이고, 취약점을 찾는 보안 Agent라면 다섯 번 중 네 번 적중은 상당히 훌륭하다. 차이는 그 업무 상황이 얼마나 높은 성공률을 요구하는가에 있다. ### 기술적 경이: Pass@k로 보는 능력 상한 @@ -99,209 +157,151 @@ $$ 평가 보고서에는 $k$ 회 시도의 기준을 분명히 적어야 합니다. 같은 작업을 $k$ 번 독립 표집한 것인지, 프로덕션 파이프라인에서 연속된 $k$ 개 작업인지 말입니다. 부작용이 있는 조작이라면 단순히 “성공할 때까지 재시도”해서는 안 되며, 샌드박스나 롤백 가능한 환경에서 표집하고 실패 하나하나를 신뢰성 지표에 기록해야 합니다. -### 프로세스 지표: 블랙박스에서 화이트박스로 - -최종 결과에만 초점을 맞추는 것으로는 충분하지 않으며, 에이전트가 결과를 얻는 과정도 똑같이 중요합니다. **행동 유효성·승인율**은 유효하면서 승인된 행동의 비율을 측정합니다. 존재하지 않는 도구를 호출하거나 잘못된 매개변수 타입을 전달하는 것은 유효하지 않은 작업이고, 허용 범위를 넘는 행동은 승인되지 않은 작업입니다. 이 비율이 높으면 에이전트가 도구 생태계를 명확히 이해한다는 뜻입니다. **도구 호출 정확도**는 매개변수가 의미상 타당할 것도 요구합니다. 검색 도구의 질의어는 요구를 정확히 표현하고, 파일 작업의 경로는 올바른 대상을 가리켜야 합니다. - -**경로 효율성**은 작업을 얼마나 효율적으로 완료하는지 측정합니다. 단계 수(사고-행동-관측 주기), 중복 행동(같은 키워드를 반복 검색하거나 같은 파일을 다시 읽음), 되돌아가기 빈도(에이전트가 오류를 알아차리고 스스로 교정하는 횟수. 가끔 되돌아가는 것은 정상이지만 잦으면 사전 계획이 부족하다는 뜻)를 살펴봅니다. "합리적인 단계 수"를 정의하려면 사람 전문가나 휴리스틱 알고리즘의 기준선이 필요합니다. - -**검색 범위**는 정보 수집 작업을 대상으로 합니다. 에이전트가 정보 공간을 충분히 탐색했나요? 검색 결과의 첫 페이지만 보고 성급하게 결론을 내리지 않았나요? **비용과 지연 시간**은 요청 수, 토큰 지출(입력·출력 비용을 구분하고 KV 캐시 재사용 고려), 실제 경과 시간(모델 추론 + 도구 실행 + 네트워크 지연 포함)에 초점을 맞춥니다. 병목을 찾으려면 시간 분포를 추적해야 합니다. - -### 안전, 강건성 및 trajectory 커버리지 - - -**안전·규정 준수 지표**는 프로덕션 배포에서 매우 중요합니다. 민감한 작업(데이터 삭제·권한 수정·외부 통신 전송), 데이터 유출(로그에 비밀번호 출력·비공개 문서를 외부 API에 전송), 금지 콘텐츠에는 모두 환각 거부와 마찬가지로 **무관용 원칙**을 적용해야 합니다(뒤의 "루브릭의 네 가지 원칙" 참조). 심각한 안전 위반이 한 번이라도 발생하면 다른 차원의 성능과 관계없이 전체 평가를 거부합니다. - -**견고성**은 불확실성에 직면했을 때의 안정성을 측정합니다. 무작위 시드 민감도(초기화가 다를 때 성능이 얼마나 변하는지), 페이지 변경 적응성(웹사이트 UI가 갱신되어도 완전히 실패하지 않는지), API 변동 허용성(일시적인 실패, 시간 초과, 형식 변경을 우아하게 처리할 수 있는지), 장기 메모리 간섭(컨텍스트에 축적된 오래된 정보가 잘못된 의사결정을 유발하는지)을 살펴봅니다. - -**실행 궤적과 최종 결과의 이중 범위.** 쉽게 간과하는 차이가 있습니다. "실행 중 에이전트가 말하고 행동한 것"(1장에서 정의한 궤적)과 "시스템이 최종적으로 어떤 상태가 되었는지"(최종 결과)는 서로 다릅니다. 에이전트가 "예약이 완료되었습니다"라고 말하는 것은 궤적 수준 정보이고, 데이터베이스에 실제로 레코드가 나타나는 것은 결과 수준 검증입니다. 궤적만 보면 "했다고 말했지만 실제로 하지 않은" 문제를 놓치고, 결과만 보면 중간 단계에서 잘못된 방향으로 간 문제를 놓칠 수 있습니다. Anthropic은 항공편 예약 에이전트가 실행 중 항공사 정책의 허점을 발견하여 사용자에게 더 저렴한 선택지를 찾은 사례를 소개한 적이 있습니다. 미리 정한 실행 경로만으로 채점하면 이 실행은 실패지만, 최종 결과를 보면 사용자는 더 좋은 조건을 얻었습니다. 따라서 체계적인 사각지대를 피하려면 두 평가 유형을 모두 다루어야 합니다. - -### 사람의 표본 검사와 적대적 검토 - -자동 평가가 대부분 신뢰할 수 있더라도 서로 다른 작업 유형, 성공과 실패, 점수 경계 부근의 모호한 사례를 포괄하는 정기적인 사람의 표본 검사가 필요합니다. 결과뿐 아니라 채점 근거가 타당한지도 검증해야 합니다. - -표본 검사는 **평가자 보정**으로 체계화할 수 있습니다. LLM 평가자를 대규모로 배포하기 전에 작업 유형과 난이도를 아우르는 사람 주석 정답 세트(예: 100~200건)를 구축하고, 평가자 모델(평가자 역할을 하는 LLM. 메커니즘은 다음 LLM-as-a-Judge 절에서 자세히 설명)이 사람의 주석과 얼마나 일치하는지 측정합니다. 단순 일치율이나 우연한 일치를 제외하는 Cohen의 카파를 사용할 수 있습니다. 일치도가 미리 정한 임계값(예: 카파 0.7 이상)을 넘은 뒤에만 평가자를 대규모 평가에 사용해야 합니다. 이후 평가자 모델이나 루브릭이 바뀔 때마다 정답 세트로 다시 보정합니다. 이 과정이 없으면 LLM 평가자의 점수는 사람의 판단을 신뢰성 있게 대리하는 값이 아니라 "다른 모델의 의견"일 뿐입니다. - -**적대적 검토**는 레드 팀 활동으로 까다로운 사례를 능동적으로 만듭니다. 겉보기에는 완벽하지만 숨은 오류가 있는 답, 키워드 채우기로 통과하는 답, 평가자 모델의 알려진 편향을 악용해 부당하게 높은 점수를 받는 답입니다. **다중 평가자 메커니즘**은 여러 독립 평가자가 따로 채점한 뒤 가중 평균이나 일관성 검사로 최종 결과를 정합니다. 평가자 사이의 차이가 크면 해당 사례에 추가 사람 검토가 필요하다고 표시합니다. +## 평가 환경 -## 자동 평가 환경 +지표 기준이 정해졌다면 다음 문제는 어디서 측정할 것인가다. 평가 환경이란 반복 실행할 수 있는 장치다. 같은 초기 상태를 주면 같은 Agent는 비교 가능한 결과를 내야 한다. -에이전트 평가에는 개발 중 변경의 효과를 빠르게 테스트할 수 있는 반복 가능하고 자동화된 환경이 필요합니다. 이러한 환경을 구축하려면 무엇을 평가할지(작업 정의와 검증 기준), 에이전트가 누구와 상호작용하며 상대를 어떻게 시뮬레이션할지, 어떤 채점 기준을 사용할지라는 세 가지 질문에 답해야 합니다. +### 다섯 가지 구성 요소 -### 평가 환경의 기본 구성 요소 +앞에서 해부한 telecom 과제로 돌아가자. 그것을 기준점으로 삼으면, 반복 실행 가능한 평가 환경에 필요한 구성 요소는 이미 다 갖춰져 있다. -평가 환경은 다음 다섯 요소로 구성됩니다. 이어지는 절에서는 데이터셋 설계와 채점 기준 설계에 초점을 맞춥니다. +**데이터셋(Dataset)** 은 과제 파일 그 자체다. 초기 상태, Agent용 티켓, 시뮬레이터용 행동 규범, 수용 기준이 한 레코드로 묶이고, 한 레코드가 하나의 테스트 케이스다. -**데이터셋**: 초기 상태, 목표 설명, 선택적 참조 해답을 포함한 작업 집합을 정의합니다. +**환경 상태(Environment State)** 는 과제 실행 중의 가변 정보다. 데이터베이스의 고객, 회선, 요금제, 청구서에 더해 단말 쪽의 비행기 모드, 로밍, 데이터 절약 스위치, 잔여 데이터가 여기 속한다. 이는 초기화 가능해야 하며 `initialization_actions`가 그 초기화 스크립트다. 진실성은 상태 변화가 업무 로직을 따를 것을 요구하고, 통제 가능성은 실행 전마다 같은 출발점으로 돌아올 수 있을 것을 요구한다. -**환경 상태**: 작업 실행 중 변경 가능한 상태를 추적하며 현실성과 제어 가능성 사이에서 균형을 맞춰야 합니다. 예를 들어 고객 서비스 평가에서 환경 상태에는 데이터베이스의 주문 기록과 사용자 계정 잔액이 포함됩니다. 에이전트가 `process_refund`를 호출하면 주문 상태가 `"delivered"`에서 `"refunded"`로 바뀌고 잔액이 증가합니다. "현실성"을 위해 상태 변경은 비즈니스 로직을 따라야 하고(환불 금액은 주문 금액을 초과할 수 없음), "제어 가능성"을 위해 각 테스트를 같은 초기 상태로 재설정할 수 있어야 합니다. +**도구 인터페이스(Tools)** 는 양쪽에 나뉘어 속한다. Agent는 고객 조회, 사용량 조회, 데이터 충전, 상담원 이관 같은 통신사 쪽 작업을 호출할 수 있고, 사용자는 단말 쪽 스위치를 조작할 수 있다. 두 도구 세트 모두 원자적 조작이며 "사용자의 인터넷 문제를 해결한다" 같은 상위 추상은 존재하지 않는다. 추상 수준이 너무 높으면 평가는 단일 함수 호출을 검사하는 일로 퇴화하고, 계획과 추론이 도구 자체에 흡수되어 버린다. -**도구**: 에이전트가 수행할 수 있는 작업 집합을 정의합니다. 도구는 "사용자 문제 해결"처럼 지나치게 높은 수준의 추상화를 제공하지 말고, 주문 조회, 예약 수정, 이메일 전송 같은 원자적 작업을 제공해야 합니다. 그러면 에이전트가 계획과 사고를 통해 이러한 작업을 조합해야 합니다. +**채점 기준(Rubric)** 은 `evaluation_criteria`의 네 층 검사에 `reward_basis`라는 집계 규칙을 더한 것이다. -**루브릭(채점 기준)**: 에이전트의 성능을 정량화합니다. 이진(통과/실패), 연속(0~100점), 다차원(정확성, 효율성, 안전성을 별도로 채점) 방식이 가능합니다. +**실행 프로토콜(Interaction Protocol)** 은 상호작용 순서와 종료 조건을 규정한다. 여기서 정상 종료 신호는 시뮬레이션된 사용자가 `###STOP###`을 출력하는 것이다. 그 외에 턴 수 상한이 있고, 시뮬레이션된 사용자가 인내심이 바닥나 스스로 대화를 끝낼 수도 있다. 소통 효율이 지나치게 낮은 것 자체가 실패로 계산되는 것이다. -**상호작용 프로토콜**: 상호작용 방식과 종료 조건을 명시합니다. +다섯 요소 중 하나만 빠져도 평가는 반복 가능한 루프를 이루지 못한다. 뒤에서 다른 벤치마크를 살필 때도 이 다섯 항목을 대조 틀로 삼는다. -이 다섯 가지 요소가 합쳐져 반복 가능한 평가 루프를 이룹니다. +### 인간-컴퓨터 상호작용형과 도구 호출형 평가 환경 -![그림 7-2: 도구 호출 및 인간-컴퓨터 상호작용 평가 환경](images/fig7-2.svg) - -Agent 과제에 따라 평가 환경은 도구 호출형과 인간-기계 상호작용형으로 대략 나눌 수 있다. - -### 도구 호출형 평가 환경 +telecom 같은 과제에는 반드시 상호작용 상대가 필요하며, 다섯 요소 중 사용자 시뮬레이션 부분이 빠질 수 없다. 반면 대화 상대가 아예 없는 과제군도 있다. 코드 생성, 데이터 분석, 수학 풀이 같은 과제에서 Agent는 처음부터 끝까지 도구하고만 상호작용하고, 정확성은 실행 검증을 통과하는지로 결정되며, 사람의 라벨링도 모델의 판정도 필요 없다. 이런 환경은 사용자 시뮬레이터를 생략하지만 나머지 네 요소는 그대로 존재하며 형태만 단순해진다. 환경 상태는 파일 시스템이나 데이터베이스이고, 채점 기준은 한 토막의 테스트 코드이며, 실행 프로토콜은 "답을 낼 때까지 혹은 턴을 다 쓸 때까지 도구를 계속 호출한다"로 퇴화한다. -코드 생성과 데이터 분석처럼 주로 도구 사용에 의존하는 작업에는 Verifiers 프레임워크가 전형적인 설계 패턴을 보여 줍니다. 에이전트는 미리 정의된 도구를 호출해 작업을 완료하고, 사람의 주석이나 모델 판단에 의존하지 않고 테스트 통과 여부, 정답 일치 여부 같은 실행 가능한 기준으로 검증합니다. +Verifiers 프레임워크는 이런 환경을 두 축으로 나눈다. 과제가 턴을 넘는 상태를 유지해야 하는지, 격리가 필요한지다. `SingleTurnEnv`는 수학 문제를 내고 답을 바로 검증하는 경우, `ToolEnv`는 여러 웹페이지를 검색해 종합 답변한 뒤 최종 결과를 검증하는 경우, `StatefulToolEnv`는 데이터베이스 레코드를 수정하고 상태 변화를 검증하는 경우, `SandboxEnv`는 샌드박스에서 코드를 실행하고 출력 파일을 확인하는 경우에 적합하다. 표 7-1은 이 네 유형을 정리한 것으로, 과제 상태·도구 호출·격리 요구에 따라 고르면 된다. -Verifiers는 계층적인 환경 설계를 도입합니다. `SingleTurnEnv`는 단일 턴 작업(예: 간단한 질의응답)에 적합하고, `ToolEnv`는 도구 호출로 이루어진 여러 턴의 자율 루프를 지원하며, `StatefulToolEnv`와 `SandboxEnv`는 상태를 갖는 도구와 장시간 실행되는 샌드박스 환경(예: 코드 실행)을 지원합니다. 예를 들어 `SingleTurnEnv`는 수학 문제를 내고 답을 직접 확인하는 데 적합합니다. `ToolEnv`는 여러 웹 페이지를 검색해 답을 종합한 다음 최종 결과를 검증하는 데, `StatefulToolEnv`는 데이터베이스 레코드를 수정하고 그에 따른 상태 변화를 확인하는 데, `SandboxEnv`는 샌드박스에서 코드를 실행하고 출력 파일을 검사하는 데 적합합니다. 표 7-2는 이러한 환경 유형을 요약하여 작업 상태, 도구 호출, 격리 요구사항에 맞는 평가 환경을 선택하도록 돕습니다. +표 7-1 Verifiers 환경 유형 비교 -표 7-2 Verifiers 환경 유형 비교 - -| 환경 유형 | 상태 지속성 | 도구 호출 | 대표 사용 사례 | +| 환경 유형 | 상태 유지 | 도구 호출 | 대표 사례 | |---|---|---|---| -| SingleTurnEnv | 없음 | 없음 | 단일 턴 질의응답, 수학 문제 | -| ToolEnv | 없음 | 여러 턴 | 검색 + 정보 종합 | -| StatefulToolEnv | 있음 | 여러 턴 | 데이터베이스 레코드 수정 | -| SandboxEnv | 있음 + 격리 | 여러 턴 | 코드 실행과 테스트 | +| SingleTurnEnv | 없음 | 없음 | 단일 턴 문답, 수학 문제 | +| ToolEnv | 없음 | 다중 턴 | 검색＋정보 종합 | +| StatefulToolEnv | 있음 | 다중 턴 | 데이터베이스 레코드 수정 | +| SandboxEnv | 있음＋격리 | 다중 턴 | 코드 실행과 테스트 | -프레임워크는 병렬 샘플링과 궤적 캐싱을 지원합니다. 각 평가의 전체 궤적(관측, 행동, 보상)은 이후 분석과 재생을 위해 저장합니다. +이 프레임워크는 병렬 샘플링과 궤적 캐싱을 지원하며, 매 평가의 완전한 궤적(관찰, 행동, 보상)이 저장되어 이후 분석과 재생이 쉽다. 또한 도구의 실행 효과는 현재 상태에 의존하므로, 실패 시에는 단일한 실패 플래그가 아니라 명확한 오류 정보를 반환하여 Agent가 그에 따라 전략을 조정할 수 있게 해야 한다. -환경은 작업의 상태 의존성도 처리해야 합니다. 도구 호출 결과는 현재 상태에 따라 달라집니다. 실패할 때는 단순한 실패 플래그가 아니라 명확한 오류 메시지를 제공하여 에이전트가 오류에서 배우고 전략을 조정할 수 있게 해야 합니다. +도구 호출형 평가가 묻는 것은 관찰 가능한 상태 변화의 정확성이고, 인간-컴퓨터 상호작용형 평가가 묻는 것은 소통 전략의 타당성이다. 전자는 행동을 검증하고 후자는 유도를 검증한다. 두 환경의 구조 대비는 그림 7-2를 참고하라. -### 인간-컴퓨터 상호작용 평가 환경 +![그림 7-2: 도구 호출 및 인간-컴퓨터 상호작용 평가 환경](images/fig7-2.svg) -현실의 많은 작업에는 도구 호출뿐 아니라 사람 사용자와의 대화도 포함됩니다. 고객 서비스 에이전트는 모호한 표현을 이해하고, 요구를 명확히 하며, 백엔드 시스템을 조회하고, 사용자와 정보를 확인해야 합니다. 이러한 작업을 평가할 때는 실제 사용자를 자동화된 환경에서 어떻게 시뮬레이션할 것인가라는 근본적인 문제가 생깁니다. +## 평가 데이터셋의 설계 -핵심 설계 원칙은 **점진적 정보 공개(Progressive Information Disclosure)**이며, 이것이 인간-컴퓨터 상호작용 평가와 전통적인 벤치마크의 근본적인 차이입니다. 대부분의 벤치마크는 완전한 요구사항을 처음부터 공개하지만, 실제 사용자는 처음부터 자신의 요구를 분명히 표현하는 경우가 드뭅니다. 흔히 "항공편에 문제가 있는 것 같습니다" 또는 "인터넷이 안 됩니다"라고만 말합니다. 에이전트가 질문으로 요구를 명확히 해야 하며, 이 과정 자체가 역량을 보여 줍니다. 따라서 평가에서 **시뮬레이션 사용자가 가진 정보를 에이전트에 한꺼번에 공개해서는 안 됩니다**. 대화가 진행됨에 따라 필요할 때 점진적으로 공개해야 합니다. +평가 환경이 무대라면 데이터셋은 대본이다. 같은 다섯 요소라도 과제 종류가 바뀌면 채우는 방식은 전혀 달라질 수 있다. 과제는 어디서 오는가, 검증기는 어느 깊이까지 확인할 수 있는가, 어떻게 암기를 막는가. 이 절은 여러 공개 벤치마크의 설계 실천에서 출발해, 마지막에 더 실무적인 질문—자체 구축 평가 세트의 과제는 어디서 와야 하는가—으로 돌아온다. -τ-bench의 해법은 다른 LLM이 사용자 역할을 맡아 미리 정의된 지침에 따라 에이전트와 대화하는 **사용자 시뮬레이션**입니다. 시뮬레이션 사용자는 작업 지침(예: "내일 항공편을 취소해야 함")을 받고, 대화 중 에이전트에 필요한 정보를 점차 공개하며, 질문에 응답하고, 작업이 끝나면 종료 신호를 보냅니다. 프롬프트는 시뮬레이션 사용자에게 "모든 정보를 한꺼번에 공개하지 말고 현재 단계에 필요한 정보만 제공할 것", "지침에 없는 정보를 지어내지 말 것"을 요구합니다. 사용자 시뮬레이션 설계에서는 진정성과 제어 가능성 사이에서 절충해야 합니다. 실제 사용자처럼 모호하게 표현하고, 불완전한 정보를 제공하며, 때로 감정이 흔들리면서도 재현성을 보장하도록 일정한 스크립트를 따라야 합니다. +### 벤치마크 설계의 횡적 대조 -다음은 점진적으로 정보를 공개하는 여러 턴 대화의 예입니다(사용자 시뮬레이터는 고정된 스크립트에 따라 행동합니다). +앞 절에서 구분한 상호작용 상대의 유무는 환경 층위의 첫 번째 차이일 뿐이고, 데이터셋 층위의 분기가 설계상의 절충을 더 잘 드러낸다. 표 7-2는 자주 인용되는 벤치마크들을 나란히 놓은 것이다. -> **사용자**: "항공편에 문제가 있습니다." -> **에이전트**: "어느 항공편인가요?" -> **사용자**(스크립트에 따라 공개): "내일 아침 샌프란시스코에서 뉴욕으로 가는 델타항공 123편입니다." -> **에이전트**: "구체적으로 어떤 문제인가요?" -> **사용자**(스크립트에 따라 공개): "비행 시간이 너무 길어서 바꾸고 싶습니다." -> **에이전트**: "새 항공편에 원하는 조건이 있나요?" -> **사용자**(스크립트에 따라 공개): "오후 항공편이면 아무거나 괜찮습니다." +표 7-2 몇몇 Agent 벤치마크의 핵심 설계 선택 -사용자 시뮬레이터는 고정된 스크립트(알려진 정보 + 공개 규칙)를 따르므로 실제 사용자의 점진적인 표현 방식을 모사하면서 평가 재현성을 보장합니다. 모의 사용자에게는 흔히 **제한된 인내심**도 설정된다. Agent의 소통 효율이 낮으면 모의 사용자가 대화를 끊어 버릴 수 있고, 그러면 과제는 실패로 끝난다. +| 벤치마크 | 측정 능력 | 과제 출처 | 환경 담당 | 검증기 | +|---|---|---|---|---| +| τ²-bench | 고객 상담 상황의 인간-컴퓨터 상호작용과 도구 호출 | 수작업 작성＋조합 생성 | 사용자 시뮬레이터＋업무 DB | 네 층 검사를 `reward_basis`로 이진 집계 | +| SWE-bench Verified | 소프트웨어 개발, coding | GitHub 실제 issue, 수작업 선별 | 코드 저장소＋테스트 스위트 | FAIL\_TO\_PASS / PASS\_TO\_PASS 이중 검증 | +| AndroidWorld | Android 단말 GUI 조작 | 파라미터화 템플릿 인스턴스화 | 실제 Android 에뮬레이터 | 최종 UI 상태 어서션 | +| OSWorld | Linux 데스크톱 GUI 조작 | 사전 설정된 중간 상태에서 시작 | 실제 가상 머신 | 134개의 독립 평가 함수 | +| Terminal-Bench | Linux 터미널 조작, coding | 수작업 작성 | Docker 컨테이너 | 파일 시스템 검사＋실제 실행 | +| GAIA | 정보 수집형 범용 AI 어시스턴트 | 수작업 작성＋전용 첨부 파일 | 열린 인터넷 | 정확한 문자열 일치 | -τ-bench는 항공사·소매 고객 서비스 같은 구조화된 비즈니스 프로세스에서 에이전트의 성능을 평가하는 벤치마크입니다. 컴포넌트 수준에서 여러 차원을 검사합니다. 한편으로는 최종 데이터베이스 상태가 올바른지(예: 예약 레코드 상태가 "cancelled"로 변경됨) 확인하고, 다른 한편으로는 대화 중 에이전트가 필요한 핵심 정보(예: 환불 금액과 입금 시점)를 제공했는지 특정 문자열이나 패턴을 검색해 검증합니다. 이 이중 검증은 작업의 정확성과 커뮤니케이션의 효과를 동시에 확인합니다. 하지만 작업 수준에서는 결국 **0 또는 1의 이진 보상**으로 통합됩니다. 모든 검사를 통과해야 1점을 받고, 하나라도 실패하면 0점입니다. 이진 보상을 사용하면 Pass^k 같은 신뢰성 지표를 쉽게 계산할 수 있지만(뒤의 "평가 지표 체계" 절 참조), "작업은 정확하지만 중요하지 않은 필드 하나가 누락된 경우"와 "완전히 실패한 경우"를 똑같이 채점하는 대가가 따릅니다. +### 검증기 -개선된 **τ²-bench**는 주로 채점의 세밀함을 개선한 것이 아니라 다른 두 영역에서 벤치마크를 발전시켰습니다. 첫째는 **이중 제어 환경**입니다. 이제 도구를 호출할 수 있는 주체가 에이전트뿐만이 아닙니다. 사용자 시뮬레이터도 같은 공유 환경을 조작할 수 있습니다. 에이전트가 사용자에게 비행기 모드로 전환하라고 안내하면 사용자의 행동이 실제로 환경 상태를 바꿉니다. 이는 사용자의 협조가 필요한 기술 지원 같은 현실의 시나리오에 더 가깝습니다. 둘째는 **더 정확한 작업 명세와 조합형 작업 생성**입니다. 성공 조건의 모호함을 줄이고 작업 인스턴스를 매개변수화하여 일괄 생성할 수 있습니다(자세한 검증 차원은 뒤의 "검증 가능성과 객관성 보장" 절 참조). +Agent는 "과제를 전부 완료했다"는 장황한 보고서를 쉽게 써낼 수 있지만, 실제로는 전혀 완료하지 않았을 수 있다. 평가 프레임워크는 Agent의 자기 진술이 아니라 기계가 독립적으로 확인할 수 있는 사실을 검증해야 한다. -> **실험 7-1 ★: τ²-bench를 실행하고 τ-bench에서 어떻게 발전했는지 비교하기** -> -> 이 실험에서는 τ²-bench 평가 프레임워크를 실행하여 인간-컴퓨터 상호작용 평가 환경의 설계 원칙을 이해합니다. τ-bench와 τ²-bench를 비교하면 평가 데이터셋이 반복적으로 개선되는 방식을 볼 수 있습니다. -> -> 작업 정의 파일을 깊이 읽어 보세요. 각 작업에는 사용자가 아는 정보, 점진적인 공개와 응답 전략을 통제하는 작업 지침, 성공 조건(데이터베이스의 목표 상태와 대화에 반드시 나타나야 하는 확인 정보)이 들어 있습니다. 전체 평가 과정을 실행하고 사용자 시뮬레이터와 에이전트 사이의 여러 턴 대화를 관찰하며, 정책 위반, 정보 누락, 사람 상담원에게 지나치게 자주 이관하는 문제 같은 전형적인 실패 유형을 분석합니다. -> -> -> ![그림 7-3: τ²-bench 평가 아키텍처](images/fig7-3.svg) -> -> -> τ-bench와 τ²-bench의 설계 차이를 비교하세요. 초기 τ-bench는 사용자 지침이 지나치게 단순하여 에이전트가 답을 추측할 수 있었고, 성공 조건이 부정확하여 오판을 일으켰으며, 사용자 시뮬레이터가 기계적으로 행동했습니다. τ²-bench는 이 문제를 해결하기 위해 다음과 같이 체계적으로 개선했습니다. -> -> - **더 상세한 작업 지침 도입**: 응답이 환경의 실제 상태에 근거해야 한다는 "근거화 요구사항(Grounding Requirements)"을 포함합니다. -> - **더 정확한 평가 기준**: 예를 들어 "속도 테스트 결과가 'excellent'여야 해결된 것으로 간주"합니다. -> - **더 현실적인 사용자 시뮬레이터 행동 명세**: 점진적 정보 공개와 자연스러운 감정 변화를 포함합니다. -> -> τ²-bench에 새로 추가된 통신 도메인 작업에 특히 주목하고, 앞에서 설명한 대로 사용자와 에이전트가 같은 공유 환경을 함께 조작하는 이중 제어 환경 설계를 이해하세요. -> - -도구 호출 평가는 관측 가능한 상태 변경을 완료했는지 묻고, 인간-컴퓨터 상호작용 평가는 에이전트가 사용자의 새로운 이해나 의사결정을 도왔는지 묻습니다. 전자는 에이전트 행동의 정확성을, 후자는 커뮤니케이션 전략의 타당성을 테스트합니다. +**SWE-bench Verified는 "수정 완료"를 두 개의 독립 명제로 분해한다.** 하나는 FAIL\_TO\_PASS로, 수정 전에는 실패하고 수정 후에는 통과함으로써 문제가 실제로 해결되었음을 증명한다. 다른 하나는 PASS\_TO\_PASS로, 수정 전후 모두 통과함으로써 새로운 결함을 들여오지 않았음을 증명한다. 앞의 것만 검사하면 Agent는 걸리적거리는 어서션을 지우거나 고쳐서 빠져나갈 수 있고, 뒤의 것만 검사하면 검사하지 않은 것과 같다. 둘을 함께 검사해야 "고쳤다"와 "망가뜨리지 않았다"가 각각 증명 가능한 결론이 된다. 여기에 더해 테스트 자체의 안정성도 확인하여, 통과했다 실패했다 하는 불안정 테스트(flaky test)를 배제한다. -평가 환경을 구축하는 일은 시뮬레이션 환경과도 맞닿습니다. 평가 환경이 대규모 반복 상호작용을 지원해야 한다면 시뮬레이션 환경이 됩니다. 이 장의 마지막 부분에서 이를 간단히 다룹니다. +**OSWorld의 검증기는 겉으로는 완료했지만 실질적으로는 틀린 상황을 잡아낼 수 있다.** 134개의 독립 평가 함수와 운영체제 전체 접근 권한을 갖추어 파일 시스템 구조, 프로세스 상태, 네트워크 연결, 애플리케이션 내부 상태를 검사할 수 있다. 데이터베이스 조작 과제에서 평가 스크립트는 보고서 파일의 존재만 확인하는 것이 아니라 데이터베이스에 접속해 SQL이 제대로 실행되었는지 확인한다. 브라우저 과제에서는 DOM 트리를 분석하고 cookie와 localStorage를 살피며 백엔드에 검증 요청을 보내 폼이 실제로 반영되었는지 확인한다. -## 평가 작업 데이터셋 설계 +**Terminal-Bench**의 과제 `build-linux-kernel-qemu`는 소스에서 Linux 커널 6.9를 빌드하고 `start_kernel`에 사용자 정의 printk를 넣고 initramfs를 생성해 QEMU에서 부팅할 것을 요구한다. 성공 기준은 부팅 로그에 그 사용자 정의 메시지가 나타나는 것이다. Agent는 출력을 위조할 수 없고 전 과정을 실제로 해내는 수밖에 없다. -평가 환경이 "무대"라면 데이터셋은 "대본"입니다. 대본의 품질은 무대 자체보다 평가의 가치를 더 크게 좌우하는 경우가 많습니다. 잘못 설계한 데이터셋은 완벽한 환경에서 실행해도 잡음만 만듭니다. 이 절에서는 GAIA, AndroidWorld, SWE-Bench Verified, τ-bench와 τ²-bench, Terminal-Bench, OSWorld, OSWorld-Verified 같은 벤치마크 설계 실무에서 반복해서 검증된 몇 가지 원칙을 추려 설명합니다. - -> **실험 7-2 ★: 벤치마크 작업을 직접 수행하기** -> -> GAIA, AndroidWorld, SWE-Bench Verified, τ²-bench, Terminal-Bench, OSWorld-Verified에서 작업을 골라 직접 완료하세요. 각 데이터셋에서 쉬움·중간·어려움 작업을 하나씩 수행할 것을 권장합니다. "어려움" 수준은 사람에게도 까다로워야 합니다. 실행 결과를 표준 정답과 비교하고 차이의 원인을 분석하세요. 이러한 직접 경험을 통해 작업 설명은 명확성과 개방성 사이에서 균형을 맞춰야 하고, 검증 기준은 객관적이며 실행 가능해야 하며, 작업 난이도 계층은 서로 다른 역량 수준을 구분할 수 있어야 한다는 점을 이해하세요. -> +### 과제의 난이도 구분 -### 작업 데이터셋 설계의 핵심 과제 +평가 과제 세트에는 서로 다른 난이도의 과제가 들어가야 한다. 그래야 모델 능력이 향상되어도 평가 과제 세트가 금방 낡지 않는다. -**과제 1: 명확성과 개방성 사이의 긴장.** 작업 설명은 재현 가능한 평가를 보장할 만큼 명확하면서도 에이전트의 창의성을 억누르지 않을 정도로 열려 있어야 합니다. GAIA가 한 예입니다. 작업은 "개념적으로 단순"하지만 구현 경로는 열려 있습니다. 예를 들어 NASA의 Astronomy Picture of the Day에서 우주비행사를 식별하고 그 사람이 우주에 머문 기간을 알아내도록 요구할 수 있습니다. 목표는 명확하지만 검색, 선별, 검증 방법은 전적으로 에이전트의 자율적인 의사결정에 달려 있습니다. +GAIA는 전체 466문항을 세 단계 난이도로 나눈다. Level 1은 도구 한둘이면 되고(사람 93.9%, GPT-4 30.3%), Level 2는 다단계 사고가 필요하며(91.8% 대 9.7%), Level 3은 복잡한 조합이 필요하다(87.3% 대 0%). 이 계층화는 난이도를 표시하는 데 그치지 않고 진단적 가치를 지닌다. Level 1의 실패는 기초적인 도구 사용을, Level 2는 다단계 계획과 정보 통합을, Level 3은 긴 시퀀스의 사고와 복잡성 관리를 가리키며 셋은 각각 다른 개선 방향에 대응한다. -**과제 2: 진정성과 제어 가능성의 균형.** 현실의 작업에는 불확실성과 잡음이 있으며, 이는 견고성을 드러내지만 재현성을 위협하기도 합니다. 초기 SWE-Bench는 실제 GitHub 이슈를 직접 사용하여 진정성을 확보했지만 작업 설명이 모호하고, 테스트 케이스가 불완전하며, 평가 기준이 주관적이라는 문제도 있었습니다. SWE-Bench Verified는 사람 전문가의 체계적인 검증을 도입하여 문제가 명확히 정의되고 테스트가 충분하며 해법이 분명한 고품질 작업 500개를 선별했습니다. 진정성을 유지하면서 제어 가능성을 크게 높였습니다. +Terminal-Bench는 단순한 mlflow 모델 등록부터 중간 난이도의 7z 비밀번호 크래킹, 어려운 git 서버와 webserver 다중 컴포넌트 통합, 최고 난도의 FEAL 차분 암호 분석까지를 아우른다. -**과제 3: 다양성과 체계성의 조화.** 효과적인 데이터셋은 전형적인 시나리오, 경계 사례, 오류 함정을 포괄하는 동시에 평가 결과로 구체적인 역량 약점을 진단할 수 있게 체계적으로 구성해야 합니다. AndroidWorld의 작업 116개는 실제 애플리케이션 20개에 걸쳐 있으며, 각 작업에는 필요한 핵심 역량(다단계 계획, 시각 이해, 시간적 사고)이 표시되어 있습니다. 따라서 결과는 전체 성공률뿐 아니라 구체적인 역량 차원별 강점과 약점도 보여 줍니다. 더 중요한 점은 매개변수화 메커니즘으로 사실상 무제한의 작업 변형을 생성할 수 있다는 것입니다. +τ²-bench는 여기에 더해 **함정 과제**를 따로 설계했다. 사용자가 "상담원이 취소를 승인했다"고 주장하지만 실제로는 정책에 맞지 않는 상황으로, Agent가 압박과 오도 속에서 올바른 판단을 유지하는지 검증한다. -**과제 4: 평가 비용과 범위.** 복잡한 에이전트 작업은 완료하는 데 몇 분에서 몇 시간이 걸리고 많은 토큰을 소비할 수 있습니다. 데이터셋의 크기는 포괄성과 경제성 사이에서 균형을 맞춰야 합니다. GAIA는 세 난이도에 걸쳐 작업 466개를 신중히 선별하여 합리적인 비용으로 평가할 수 있으면서 여러 역량 차원을 포괄합니다. SWE-Bench Verified는 작업 수를 2,294개에서 500개로 줄였습니다(비용을 약 5분의 4 줄이면서 더 엄격한 품질 기준으로 신호 대 잡음 비를 개선했습니다). +### 데이터 유출 방지 -**과제 5: 데이터 오염 방지.** 대규모 언어 모델 시대에는 데이터 오염이 평가의 심각한 문제입니다. 평가 데이터가 학습 데이터에 들어가면 평가는 일반화가 아니라 암기를 측정합니다. 시험 전에 답을 외우는 것과 같아 높은 점수가 진정한 능력을 나타내지 않습니다. 벤치마크마다 다른 방지 전략을 사용합니다. GAIA는 답의 고유성에 의존합니다. 여러 원본의 정보를 조합해야 답할 수 있고, 일부 작업에는 인터넷에 존재하지 않도록 특별히 만든 첨부 파일(PDF·오디오·이미지)이 있어 단일 웹 페이지에서 답을 바로 찾을 수 없습니다. SWE-Bench Verified 자체는 OpenAI가 원본 SWE-Bench에서 사람의 품질 검토를 거쳐 얻은 500개 작업의 부분집합이며 시간 기반 유출 방지 설계는 포함하지 않습니다. 이후의 SWE-bench-Live 같은 연구가 모델의 학습 데이터 기준일 이후에 생성된 이슈를 계속 추가하여 평가가 모델의 학습 말뭉치보다 앞서도록 함으로써 시간적 최신성으로 실제 유출을 방지합니다. τ²-bench는 사용자 이름, 주문 번호, 날짜 같은 구체적인 작업 인스턴스를 매번 무작위로 만드는 동적 매개변수 생성으로 유출을 방지합니다. AndroidWorld의 매개변수화된 작업 생성도 자연스럽게 유출 방지에 도움이 됩니다. 작업 순서가 아니라 최종 UI 상태를 바탕으로 검증하기 때문입니다. Terminal-Bench는 카나리아 GUID(추적 표시로 쓰는 전역 고유 식별자)를 삽입하여 유출을 감지할 수 있게 합니다. 모델이 이 GUID가 포함된 내용을 출력할 수 있다면 벤치마크 데이터가 학습 세트로 유출되었다는 뜻입니다. +**GAIA는 답을 인터넷에서 직접 검색할 수 없게 만든다.** 그 과제는 개념적으로는 단순하되 경로가 열려 있다. 예컨대 특정 날짜의 NASA 오늘의 천문 사진에서 출발해 사진 속 우주비행사를 식별하고, 그가 속한 우주비행사 그룹을 찾고, 그 그룹에서 우주 체류 시간이 가장 짧은 사람을 계산해 "성, 세미콜론 구분, 천 단위 구분자" 형식으로 엄격히 출력하게 한다. 답은 매우 구체적이고 정오는 정확한 문자열 일치로 판정된다. 유출 방지는 두 가지에 기댄다. 첫째, 문제는 여러 정보원을 조합해야 답할 수 있고 단일 웹페이지로는 답이 바로 나오지 않는다. 둘째, 일부 과제에는 전용으로 제작한 첨부 파일(인터넷에 존재하지 않는 PDF, 오디오, 이미지)이 붙어 있다. -### 작업 설명의 정밀한 설계 +**AndroidWorld는 하나의 템플릿에서 다수의 인스턴스를 파생시킨다.** 그 과제는 정적 텍스트가 아니라 동적으로 인스턴스화할 수 있는 템플릿이다. 예컨대 "연락처 `[CONTACT_NAME]`의 전화번호를 `[NEW_PHONE]`으로 바꾼다" 같은 형태로, 평가할 때마다 파라미터 값을 무작위로 생성한다. 여기에는 세 가지 이점이 있다. 파라미터가 매번 달라 고정된 조작 순서의 재생이 무력해지고, 하나의 템플릿에서 거의 무한한 인스턴스를 만들 수 있으며, 일부 파라미터를 고정하고 나머지만 바꿔 특정 요인의 영향을 정확히 측정할 수 있다. -GAIA는 정보 원본 제약, 시간 범위, 주제, 질의 대상을 명확히 하여 답의 고유성을 보장합니다. 예를 들어 레벨 3 작업은 특정 날짜의 NASA 이미지에서 시작해 시각적 이해로 우주비행사를 식별하고, 그 사람이 속한 우주비행사 그룹을 찾아 우주 체류 시간을 계산하며, 출력 형식을 정확히 맞출 것을 요구합니다("성; 필드는 세미콜론으로 구분; 숫자는 천 단위 구분 기호 사용"). 모든 세부 사항이 자동 검증을 위한 것이며 형식과 내용이 정확히 일치해야만 통과합니다. +**Terminal-Bench는 문제문에 카나리아 식별자를 심는다.** 각 문항은 canary GUID를 지니며, 모델이 그 GUID가 포함된 내용을 출력할 수 있다면 벤치마크 데이터가 학습 세트에 들어갔다는 뜻이다. 유출을 막지는 못하지만 유출을 탐지 가능하게 만든다. -τ²-bench는 맥락화된 설계를 도입하며 각 작업에 여러 정보 계층을 포함합니다. 표면적인 문제("모바일 데이터가 작동하지 않음"), 성능 기대치("'excellent' 속도 등급 필요"), 제약("'excellent' 외의 등급은 받아들이지 않음"), 암묵적인 감정입니다. 핵심 개선점은 "알려진 정보"와 "작업 지침"을 분리하는 것입니다. 알려진 정보는 사용자가 현재 아는 내용이고, 작업 지침은 시뮬레이터가 정보를 점진적으로 공개하는 방법을 안내합니다. 여기에는 응답이 도구 호출의 실제 반환 결과에 근거해야 하며 지어내면 안 된다는 "근거화 요구사항(Grounding Requirements)"도 포함됩니다. +### 품질 관리와 장기 유지보수 -SWE-Bench Verified에는 문제 설명, 재현 단계, 예상 동작과 실제 동작 같은 구조화된 필드가 있으며, 주석 작업자가 설명과 테스트 케이스가 일치하는지 확인합니다. Terminal-Bench의 작업 설명에 있는 모든 요소는 기계적으로 검증할 수 있습니다. 파일 경로가 존재하는지, 권한 값이 올바른지, 인증서 매개변수가 유효한지, 날짜 형식이 맞는지 확인합니다. 예를 들어 "build-linux-kernel-qemu" 작업은 Linux 커널 6.9를 소스에서 빌드하고, `start_kernel`에 사용자 정의 printk를 추가하며, initramfs를 생성하고, QEMU에서 실행할 것을 요구합니다. 성공 기준은 부팅 로그에 사용자 정의 메시지가 나타나는 것입니다. 에이전트는 출력을 조작할 수 없으며 전체 과정을 실제로 완료해야 합니다. +높은 품질의 평가 세트를 만드는 일은 매우 어렵다. 위 벤치마크들의 현재 형태는 대부분 초판을 운용에 투입해 문제가 드러난 뒤 여러 차례 손본 결과다. 예컨대 τ-bench에서 τ²-bench로 오면서 설계를 다시 한 곳이 다섯 군데 있다. -AndroidWorld는 **매개변수화된 템플릿** 설계를 사용합니다. 작업은 정적인 텍스트가 아니라 동적으로 인스턴스화할 수 있는 템플릿입니다(예: "`[CONTACT_NAME]` 연락처의 전화번호를 `[NEW_PHONE]`으로 변경"). 평가할 때마다 서로 다른 매개변수 값을 무작위로 생성합니다. 여기에는 세 가지 이점이 있습니다. +첫째, **과제 지시가 지나치게 두루뭉술해 답을 추측할 수 있었다**. 초판의 과제 지시는 폭넓게 쓰여 있어 모델이 요구를 진짜로 명확히 할 필요 없이 상식으로 절차를 추측하는 것만으로도 통과할 수 있었다. τ²-bench는 대본을 `known_info`와 `task_instructions` 두 칸으로 나누었다. 앞은 사용자가 아는 범위를 획정하고 뒤는 공개 방식을 규정한다. 사용자가 모르는 정보는 Agent가 추측할 길이 없고 조회해서 얻는 수밖에 없다. -- **암기 방지**: 매번 매개변수 값이 달라 고정된 작업 순서를 재생할 수 없습니다. -- **데이터 다양성 확대**: 템플릿 하나로 사실상 무제한의 인스턴스를 생성할 수 있습니다. -- **비교 실험 지원**: 일부 매개변수를 고정하고 나머지만 바꾸어 특정 요인의 효과를 정밀하게 측정할 수 있습니다. +둘째, **성공 조건이 충분히 정밀하지 않아 검증이 오판했다**. "네트워크가 복구되었다" 같은 조건에는 확인 가능한 경계가 없다. τ²-bench는 이를 "속도 테스트 결과가 excellent여야 해결로 보고 poor, fair, good은 모두 받아들이지 않는다"로 바꿨다. 이 변경이 겨냥한 것은 **미봉책 수리**, 즉 증상만 누르고 근본 원인은 해결하지 않는 방식이다. -검증은 작업 순서가 아니라 최종 UI 상태(예: 전화번호 필드에 기대한 값이 들어 있는지)를 기준으로 합니다. +셋째, **사용자 시뮬레이터의 행동이 지나치게 기계적이었다**. 초판의 시뮬레이션 사용자는 수동적으로 응답할 뿐이었다. τ²-bench는 여기에 감정(첫 수리가 실패하면 불만을 드러낸다), 인내 한도(소통 효율이 너무 낮으면 대화를 끊는다), 그리고 사실 접지 요구를 더했다. 셋이 함께 작용하여 시뮬레이터는 실제 사용자에 가까워지면서도 재현 가능성을 유지한다. -OSWorld 작업은 흔히 "깨끗한" 초기 상태가 아니라 세심하게 설정한 중간 상태에서 시작하여 현실의 사용 시나리오와 더 비슷합니다. 작업 설명은 여러 해법을 처리해야 합니다("배경을 보라색으로 설정"은 모호함을 없애기 위해 특정 색상 코드가 필요하고, "CSV 두 개를 이어 붙이기"는 헤더를 하나만 유지하거나 둘 다 유지하는 등 합리적인 모든 방법을 허용해야 합니다). 웹사이트의 스크래핑 방지 조치, 변화하는 애플리케이션 UI, 경쟁 상태 같은 환경의 불확실성도 처리해야 합니다. OSWorld-Verified는 오프라인 페이지 스냅샷, 고정된 의존성 버전, 명시적인 대기 조건 등으로 이를 완화합니다. +넷째, **사용자는 대화만이 아니라 조작에도 참여한다**. telecom 도메인은 이중 제어 환경을 도입했다. 이전 평가에서는 Agent만 환경을 바꿀 수 있었지만, 기술 지원 같은 상황에서는 상당수의 동작을 원래 사용자가 자기 기기에서 수행해야 한다. 이중 제어는 검증에도 한 차원을 더한다. 사용자가 상태를 바꾼 뒤 Agent는 도구를 다시 호출해야만 결과를 알 수 있으므로, 검증은 "Agent가 사용자 쪽 조작 결과를 실제로 읽었는가"까지 포괄하게 된다. -이 목록이 에이전트 평가 분야 전체를 망라하는 것은 아닙니다. Web/GUI 범주 안에서도 강조점이 다른 여러 벤치마크가 있습니다. WebArena는 전자상거래, 포럼, 코드 호스팅 등 완전히 재현 가능한 웹사이트를 구축하여 실제 웹 페이지의 예측 불가능성을 샌드박스 안에 가둡니다. Mind2Web은 반대 방향으로 가서 수백 개의 실제 웹사이트에서 직접 일반화 능력을 테스트합니다. [ClawBench](https://claw-bench.com/)([논문](https://arxiv.org/abs/2604.08523), [코드](https://github.com/TIGER-AI-Lab/ClawBench))는 격리된 컨테이너에서 실행하는 에이전트가 실제 웹사이트에서 일상적인 엔드투엔드 작업을 수행하게 합니다. V1은 144개 웹사이트의 작업 153개를, V2는 작업 130개를 추가로 다루며, 세션 재생, 행동 스크린샷, HTTP 트래픽, 브라우저 행동, 에이전트 메시지라는 다섯 계층의 증거를 병렬로 기록합니다. 제3자 웹사이트의 변경에 재현성이 좌우된다는 대가를 치르지만, 실제 사이트의 드리프트와 롱테일 실패를 더 쉽게 분석하게 함으로써 샌드박스형 벤치마크를 보완합니다. BrowseComp는 다단계 브라우징과 교차 검증을 거쳐야만 찾을 수 있을 정도로 깊숙이 숨겨진 답을 찾는 심층 검색에 특화되어 있습니다. 도구 호출 분야에는 BFCL(Berkeley Function-Calling Leaderboard) 같은 전용 함수 호출 리더보드가 있습니다. 이 장은 이를 모두 나열하려 하지 않습니다. 대신 두 핵심 환경 패러다임인 도구 호출과 인간-컴퓨터 상호작용, 그리고 데이터셋 사례 연구 전반에 걸친 GUI 조작 시나리오를 대상으로 설계상의 절충을 깊이 살펴봅니다. 패러다임을 이해하면 새 벤치마크가 무엇을 측정하고 데이터 유출을 얼마나 잘 막으며 그 결론을 어느 범위까지 일반화할 수 있는지 빠르게 판단할 수 있습니다. +다섯째, **과제 인스턴스를 동적으로 생성한다**. τ²-bench의 구체적 인스턴스(사용자 이름, 번호, 고장 조합)는 파라미터화하여 일괄 생성할 수 있고, 이는 커버리지와 유출 저항력을 동시에 개선한다. -### 작업 복잡도의 계층적 설계 +**SWE-bench Verified: 공개 전에 원래 과제의 71%를 탈락시켰다.** OpenAI는 원래의 2294개에서 1699개를 무작위 추출해 사람 평가에 부치고, Python에 능한 개발자 93명을 모아 한 건씩 검사했다. 문제 기술이 명확한가, 테스트 케이스가 경계 조건을 포괄하는가, 테스트가 안정적인가, 참조 patch가 새 오류를 들여오지 않는가, 난이도가 타당한가. 최종적으로 통과한 것은 500개뿐이었다. 높은 탈락률이 가져다주는 것은 더 높은 신호 대 잡음비이며 평가 비용도 약 80% 내려간다. 복잡한 Agent 과제는 수 분에서 수 시간이 걸리기 일쑤이고, 프런티어 모델로 평가 데이터셋을 통째로 돌리면 수천 달러의 token 비용이 들기 때문에 평가 비용을 낮추는 일은 매우 중요하다. -GAIA는 세 난이도를 설계했습니다. 레벨 1은 도구 1~2개만 필요하고(사람 93.9% 대 GPT-4 30.3%), 레벨 2는 다단계 사고가 필요하며(91.8% 대 9.7%), 레벨 3은 복잡한 조합이 필요합니다(87.3% 대 0%). 이러한 계층 설계에는 진단적 가치가 있습니다. 레벨 1에서 실패하면 기본적인 도구 사용 문제, 레벨 2는 다단계 계획과 정보 통합 문제, 레벨 3은 긴 순서의 사고와 복잡성 관리 문제를 가리킵니다. 각 수준은 서로 다른 개선 방향(프롬프트 엔지니어링, 계획 메커니즘, 계층형 아키텍처·사후 학습)에 대응합니다. +**OSWorld: 공개 후 15개월 동안 300여 개의 문제가 드러났다.** 2024년 4월 공개 후 곧 멀티모달 Agent 평가의 중요한 벤치마크가 되었지만, 이후 널리 쓰이는 과정에서 네 종류의 문제가 드러났다. 환경 문제(사이트의 크롤링 차단, CAPTCHA, 동적 콘텐츠 변화), 과제 기술 문제(표현의 모호함), 검증 로직 문제(지나치게 엄격하거나 느슨함), 초기 상태 문제(설정 불완전)이다. 홍콩대학 팀은 약 10명 규모의 그룹을 꾸려 MoonShot AI, OpenAI, ByteDance Seed TARS, Anthropic, Simular 등과 두 달간 긴밀히 협력해 체계적으로 수리했다. 환경 문제는 버전 고정과 오프라인 백업으로, 기술 문제는 모호한 표현의 재작성으로, 검증 문제는 사람이 올바른 기준선을 세우고 조건을 조정하는 것으로, 초기 상태 문제는 완전성 검사 추가로 완화했다. -τ²-bench는 비즈니스 프로세스를 기준으로 복잡성을 계층화합니다. 단순한 정보 조회에서 다단계 프로세스(항공편 예약 변경에는 조회, 대안 제시, 확인 받기, 운임 차액 계산, 결제 처리가 필요), 장애 진단(가능한 여러 원인을 체계적으로 확인하고 수정 사항 검증), 마지막으로 전략적 판단(정책에 맞지 않는 요청 처리)까지 이어집니다. - -Terminal-Bench는 기술 도메인 × 작업 복잡성이라는 두 차원으로 복잡성을 계층화합니다. 작업 레지스트리에는 200개가 넘는 작업이 모였습니다(핵심 평가 세트의 크기는 버전마다 다릅니다. 예를 들어 2.0 버전은 커뮤니티 기여에서 고품질 작업 89개를 선별했습니다). 단순한 MLflow 모델 등록, 중간 난이도의 7-Zip 비밀번호 크래킹, 어려운 Git 서버·웹 서버 통합, 가장 어려운 FEAL 차분 암호 분석(30초라는 시간 제약을 맞추기 위한 암호학 지식 + 알고리즘 최적화 필요)에 이릅니다. - -### 검증 가능성과 객관성 보장 - -GAIA의 답은 간결하고 명확합니다. 엄격한 형식 규칙 덕분에 정확한 문자열 일치로 검증할 수 있습니다. 일치 여부라는 이진 결과는 객관적인 재현성을 보장합니다. 답의 희소성도 부정행위 방지 수단으로 작용합니다. 매우 구체적인 사실이 학습 데이터에 그대로 나타날 가능성은 낮습니다. +> **실험 7-2 ★: 벤치마크 과제를 사람이 직접 수행하기** +> +> GAIA, AndroidWorld, SWE-Bench Verified, Terminal-Bench, OSWorld-Verified에서 과제를 골라 직접 완수해 보라. 데이터셋마다 쉬움·보통·어려움을 하나씩 하기를 권한다. "어려움" 수준은 사람에게도 도전적이다. +> +> 마친 뒤 두 가지 질문에 답해 보라. 그 과제의 기술에 합리적 해석이 여럿 존재하는가, 존재한다면 검증기는 어느 쪽을 인정하는가? 대충 해서 통과하려 한다면 가장 값싼 경로는 무엇이며, 검증기가 그것을 막을 수 있는가? -SWE-Bench Verified는 실행 가능한 코드 기반 검사를 사용하며, FAIL_TO_PASS(수정 전에는 실패하고 수정 후에는 통과하여 문제가 해결되었음을 입증)와 PASS_TO_PASS(수정 전후 모두 통과하여 새 버그를 만들지 않았음을 입증)를 구분하여 이중으로 검증합니다. Verified 버전은 테스트 자체도 신뢰할 수 있고, 때에 따라 통과하거나 실패하는 불안정한 테스트가 없도록 보장합니다. +### 평가 세트의 세 가지 출처 -τ²-bench의 검증 시스템은 여러 계층의 검사를 포함합니다(각 계층의 결과는 작업 수준에서 여전히 이진 보상으로 통합되며, 모두 통과해야 성공입니다). +흔한 견해로 공개 벤치마크는 모델 순위를 위한 것이고 실제 업무와는 관련이 적다는 것이 있다. 공개 벤치마크의 점수가 제품 의사결정을 직접 이끌기 어려운 것은 사실이지만, 그 설계 기법은 충분히 이식 가능하다. 앞에서 다룬 검증의 깊이, 파라미터화 생성, 유출 방지, 품질 유지야말로 자체 구축 평가 세트에서 가장 놓치기 쉬운 부분이다. -- **데이터베이스 상태 검사**: 예약 레코드 상태, 환불 레코드 생성 여부 -- **대화 내용 키워드 검색**: 에이전트가 사용자에게 환불 금액과 예상 입금 시점을 명시적으로 확인했는지 여부 -- **프로세스 준수**: 도구 호출 순서 분석. 예를 들어 주문을 수정하기 전에 사용자의 명시적인 확인을 받았는지 여부 +프로덕션 환경의 평가 세트에는 보통 세 가지 출처가 있다. -τ²-bench의 이중 제어 환경(앞의 "인간-컴퓨터 상호작용 평가 환경" 절 참조)은 검증에 또 다른 차원을 추가합니다. 사용자 시뮬레이터가 실제로 환경 상태를 바꾼 뒤, 에이전트는 도구 호출을 통해 이 변화를 관측하고 그에 따라 문제 해결을 계속해야 합니다. 따라서 검증에는 에이전트가 사용자 행동의 결과를 실제로 관측했는지도 포함됩니다. +**공개 벤치마크**는 모델의 거친 선별과 설계 기법의 차용에 쓰고, 일반적으로 제품 의사결정에는 쓰지 않는다. 그 과제 분포는 실제 업무의 과제 분포와 일치하지 않으며, GAIA에서 2퍼센트포인트 오른 것과 환불 성공률 사이에 필연적 관계는 없다. -OSWorld는 운영체제 전체에 접근할 수 있는 독립 평가 함수 134개를 제공하여 파일 시스템 구조, 프로세스 상태, 네트워크 연결, 애플리케이션 내부를 깊이 검사할 수 있습니다. 예를 들어 데이터베이스 작업에서 평가 스크립트는 보고서 파일이 존재하는지만 확인하지 않고 데이터베이스에 직접 연결하여 SQL이 올바르게 실행되었는지 검사합니다. 브라우저 작업에서는 DOM 트리를 분석하고, 쿠키와 localStorage를 확인하며, 백엔드로 검증 요청을 보내 양식 제출이 실제로 적용되었는지 확인합니다. 이처럼 깊이 검사하면 "겉으로는 완료했지만 실질적으로는 오류인" 사례를 감지할 수 있습니다. 예를 들어 에이전트가 제출 버튼을 눌렀지만 잘못된 필드 입력 때문에 서버가 요청을 거부했을 수 있습니다. +**자체 구축 업무 세트**는 실제 과제 분포를 포괄하며 모델 선정과 Harness 설계 결정의 근거가 될 수 있다. 예컨대 τ²-bench는 사용자 시뮬레이션이 필요한 평가 시스템의 골격으로 그대로 쓸 수 있고, 도메인 데이터와 도구 세트만 바꾸면 된다. -Terminal-Bench는 표준화된 Docker 컨테이너 환경을 바탕으로 파일 시스템 상태 검사(경로 존재, 권한 값, 콘텐츠 형식)와 프로그램 실행의 기능 검증을 결합합니다. build-linux-kernel-qemu에서는 실제로 QEMU를 시작하여 사용자 정의 printk 메시지를 검색합니다. 카나리아 GUID를 통해 유출을 추적할 수 있습니다. +**프로덕션 궤적 환류**는 현장의 실제 실패 사례에서 온다. 사용자의 명시적 정정, 사용자의 낮은 평가, 그리고 사후에 상태 검사, 규칙 검증기, 혹은 LLM 검토로 발견된 문제 사례다. 실패 귀인을 거쳐 회귀 케이스로 축적된다. 구체적인 방법은 뒤의 "실패 귀인"과 "엔드투엔드 회귀 과제와 trajectory prefix 회귀 과제" 절을 참고하라. 이 출처는 비용이 가장 높고 정확도도 가장 높다. 사용자가 실제로 마주친 문제에서 곧바로 오기 때문이다. -### 작업 분포의 체계적인 설계 +시작 단계에는 보통 공개 벤치마크와 소량의 손으로 쓴 자체 업무 세트밖에 없다. 시스템이 프로덕션에서 한동안 돌아간 뒤에는 프로덕션 궤적에서 환류된 케이스가 주가 된다. -작업 분포는 역량 차원, 난이도 차원, 시나리오 차원, 경계 사례를 체계적으로 포괄해야 합니다. GAIA는 범용성을 추구합니다. 대부분의 작업에 사고, 멀티모달, 브라우징, 도구 사용의 조합이 필요합니다. τ²-bench는 취소가 실제로 정책에 맞지 않는데 사용자가 "고객 서비스에서 취소를 승인했습니다"라고 주장하는 식의 "함정 작업"을 의도적으로 설계하여 에이전트가 압박과 오도 속에서도 판단을 지키는지 테스트합니다. OSWorld는 작업 유형(파일 IO·데스크톱 애플리케이션·웹 애플리케이션·애플리케이션 간 워크플로)과 애플리케이션 도메인의 2차원 행렬을 바탕으로 세 운영체제를 다룹니다(연구에 따르면 운영체제 간 상관관계가 강하여 한 시스템에서 배운 기술을 다른 시스템으로 전이할 수 있습니다). Terminal-Bench에는 데이터 처리 + 파일 작업 + Python 엔지니어링을 결합한 리샤딩 작업처럼 시스템 사고를 테스트하는 "기술 스택 간 조합 작업"이 있습니다. +## 자동화 평가 방법 -### 데이터 품질 관리와 반복 개선 +앞의 여러 절에서 다룬 벤치마크에는 하나의 공통점이 있다. 검증기가 거의 전부 결정적이라는 점이다. SWE-bench는 테스트 스위트를 실행하고, AndroidWorld는 최종 UI 상태를 어서트하며, GAIA는 정확한 문자열 일치를 하고, τ²-bench의 네 층 검사도 마찬가지로 전부 코드로 실행된다. 이 선택에는 충분한 이유가 있다. 결정적 검증은 추가 모델 비용을 들이지 않고, 결과가 완전히 재현 가능하며, 유닛 테스트처럼 지속적 통합에 넣을 수 있고, 모델 간 순위를 매기기에도 편하다. -SWE-Bench Verified는 품질 관리의 모범 사례입니다. OpenAI는 원본 작업 2,294개 중 1,699개를 무작위로 뽑아 사람의 평가를 받았으며, Python에 능숙한 개발자 93명을 모집했습니다. 주석 작업자는 문제 설명이 명확한지(해결해야 할 내용을 이해할 수 있는지), 테스트 케이스가 완전한지(모든 측면과 경계 사례를 다루는지), 테스트가 안정적인지(환경이나 무작위성 때문에 불안정하지 않은지), 패치가 올바른지(새 오류를 만들지 않았는지), 난이도가 적절한지 등 여러 항목을 확인해야 했습니다. 엄격한 선별을 거쳐 500개(29%)만 통과했습니다. 이처럼 높은 탈락률은 평가 품질에 필요한 투자입니다. 검사마다 구체적인 기준과 예시를 정의한 표준 주석 지침도 마련하여 주석 작업자 사이의 일관성을 보장했습니다. +그 대가는 최종 결과의 정오만 평가할 수 있을 뿐 오류의 원인은 알려 주지 못한다는 것이다. τ²-bench의 실패한 과제는 최종적으로 0점을 받았지만, 그 0점은 Agent가 회선 선택 단계에서 틀렸는지 데이터 충전 단계를 빠뜨렸는지 말해 주지 않고, 다음에 무엇을 고쳐야 하는지도 짚어 주지 않는다. 순위를 매기는 공개 벤치마크에 이는 결함이 아니지만, 지속적 개선이 필요한 프로덕션 시스템에는 바로 그것이 가장 필요한 정보다. -τ²-bench는 "알려진 정보"와 "작업 지침"을 분리하여 시뮬레이터의 행동을 더 현실적으로 만들고, "excellent만 해결로 간주하며 poor/fair/good은 허용하지 않음" 같은 더 엄격한 완료 조건을 도입하여 "피상적인 수정"을 방지합니다. +프로덕션 상황에는 또 하나의 어려움이 있다. 많은 판단이 애초에 코드로 검사할 수 있는 어서션으로 쓰이지 않는다. 민원 회신이 적절한지, 조사 보고서가 핵심 정보를 빠뜨렸는지, 기억 검색이 인물 관계를 잘못 짚었는지. 이런 것들에는 조회할 유일한 최종 상태도 없고 키워드 일치로 판정할 수도 없다. -OSWorld-Verified는 반복 개선의 모범 사례입니다. 2024년 4월 출시된 OSWorld는 곧 멀티모달 에이전트 평가의 중요한 벤치마크가 되었지만, 15개월간 널리 사용되면서 300개가 넘는 문제가 발견되었습니다. 문제는 네 범주로 나뉩니다. 웹사이트의 스크래핑 방지 조치, CAPTCHA, 동적 콘텐츠 변경 같은 환경 문제, 모호한 표현이 있는 작업 설명 문제, 지나치게 엄격하거나 느슨한 검증 로직 문제, 불완전한 설정이 있는 초기 상태 문제입니다. 홍콩대학교의 약 10명 규모 팀은 MoonShot AI, OpenAI, ByteDance Seed TARS, Anthropic, Simular 등과 긴밀하게 협력하여 두 달에 걸쳐 이 문제를 체계적으로 수정했습니다. 각 범주에 맞는 복구 전략을 세웠습니다. 환경 문제는 버전 고정과 오프라인 백업으로 해결하고, 작업 설명은 모호한 표현을 다시 써서 명확히 하며, 검증 로직은 사람이 올바른 기준선을 세우고 조건을 조정하여 균형을 맞추고, 초기 상태에는 완전성 검사를 추가했습니다. +따라서 공개 벤치마크에서 프로덕션 환경의 평가로 나아가려면 검증 방식을 하나의 스펙트럼을 따라 오른쪽으로 옮겨야 한다. 그 가로축은 과제의 **기계적 검증 가능 정도**이며, 그림 7-4와 같다. -## 자동 평가 방법 +![그림 7-4: 검증 방식의 스펙트럼—결정적 검증에서 모델 판정까지](images/fig7-4.svg) -평가 환경, 데이터셋, 명확한 지표 체계를 마련했다면 핵심 질문은 어떻게 채점할 것인가입니다. 수학 문제나 SQL 쿼리처럼 정답이 명확한 작업에는 단순한 이진 판단(정답/오답)이면 충분하지만, 고객 서비스 대화나 보고서 작성 같은 개방형 작업에는 더 정교한 평가 방법이 필요합니다. +스펙트럼 오른쪽의 두 도구가 그래서 프로덕션 평가의 주역이 된다. **Rubric**으로 막연한 "좋고 나쁨"을 개별 채점 가능한 여러 차원으로 쪼개고, **LLM-as-a-Judge**로 결정적 판정 기준이 없을 때의 채점을 수행한다. 둘이 합쳐져야 막연한 실패율을 손댈 수 있는 구체적 문제로 되돌릴 수 있다. 여기에 이 절 후반의 **실패 귀인**까지 더하면 프로덕션 Agent 평가의 완전한 폐루프가 구성된다. -코드 기반 자동 검증은 표준 정답이 있는 시나리오만 다룰 수 있으므로, 개방형 작업의 채점이 이 절의 주제입니다. 이 가운데 이진 보상에서 과정 보상, 생성형 보상에 이르는 보상 신호 밀도의 설계와 보상 모델 학습 방법은 8장의 사후 학습 절에서 체계적으로 논의합니다. 여기서는 LLM을 사용해 개방형 작업의 출력 품질을 자동으로 판단하는 방법이라는 더 근본적인 질문에 답합니다. +다만 오른쪽으로 옮긴다는 것이 왼쪽을 포기한다는 뜻은 아니다. 프로그램 어서션으로 쓸 수 있는 검사는 모두 어서션으로 남겨야 하며, LLM 판정은 기계적으로 판정할 수 없는 차원에만 쓴다. 결정적 검사가 더 싸고 안정적이며, 회귀 테스트로 장기간 돌리기에도 적합하다. ### LLM-as-a-Judge: 자동 평가의 핵심 -![그림 7-4: LLM-as-a-Judge 파이프라인](images/fig7-4.svg) +![그림 7-5: LLM-as-a-Judge 파이프라인](images/fig7-5.svg) LLM-as-a-Judge는 왜 필요할까요? 보고서 생성, 고객 불만 처리, 창작 콘텐츠 같은 개방형 작업에는 자동으로 비교할 표준 정답이 없고, 사람의 평가는 비용이 많이 들며 확장하기 어렵습니다. LLM-as-a-Judge는 언어 모델이 전문가가 정의한 채점 기준(루브릭)에 따라 출력을 평가하게 하여 자동화의 확장성과 사람 전문가의 판단 사이에서 균형을 맞춥니다. 하지만 이 방법에는 알려진 한계가 있습니다. 평가자 모델 자체에 편향이 있고(가장 전형적인 것은 정확성이 더 높지 않아도 길고 상세한 응답에 더 높은 점수를 주는 **길이 편향**), 같은 입력을 반복해서 판단해도 결과가 달라질 수 있습니다. 특히 길이 편향에는 구체적인 대응이 필요합니다. 일반적인 방어책은 세 가지입니다. 루브릭에서 장황함에 명시적으로 감점하고 작업 유형마다 응답 길이를 제한합니다. 쌍대 비교에서는 판단 전에 두 후보의 길이를 비슷하게 맞춥니다. 그리고 점수와 응답 길이의 상관관계를 정기적으로 감사합니다. 높은 점수가 거의 항상 긴 응답에 돌아간다면 평가자가 길이에 휘둘린 것이므로 루브릭을 수정해야 합니다. 이러한 문제를 체계적으로 해결하려면 루브릭 설계가 다음 원칙을 따라야 합니다. @@ -363,7 +363,7 @@ rubric: 루브릭과 에이전트의 실제 응답을 평가 모델에 함께 넘기면 항목별 점수와 근거가 나옵니다. 수십 개 사례를 모아 낮은 점수의 궤적을 다시 보면 막연한 성공률 하락을 구체적인 원인으로 나눌 수 있습니다. 정보를 찾지 못했는지, 사람 사이의 관계를 잘못 연결했는지, 근거 없는 내용을 덧붙였는지 구분하는 것입니다. 루브릭은 점수표이면서 다음 수정 지점을 알려 주는 진단 도구입니다. -아래에서는 사용자 메모리를 구체적인 사례로 삼아, 이 범용 방법을 실행 가능한 평가 세트와 채점기로 어떻게 옮기는지 보여 준다. +아래에서는 사용자 메모리를 구체적인 사례로 삼아, 이 범용 방법을 실행 가능한 평가 세트와 검증기로 어떻게 옮기는지 보여 준다. > **실험 7-3 ★★: 루브릭 기반 사용자 메모리 평가 시스템 구축하기** > @@ -534,7 +534,7 @@ trajectory prefix 회귀 작업의 답은 유일한 행동이나 답이 아니 ### 쌍대 비교와 모델 순위 -![그림 7-5: Elo 레이팅과 쌍대 비교 순위](images/fig7-5.svg) +![그림 7-6: Elo 레이팅과 쌍대 비교 순위](images/fig7-6.svg) **Elo 레이팅**(원래 체스를 위해 설계된 순위 시스템)은 많은 쌍대 대결을 통해 모델의 상대적 역량을 정량화합니다. 레이팅 차이가 클수록 강한 모델의 예상 승률도 높습니다. 예를 들어 모델 A의 레이팅이 1200이고 모델 B가 1000이라면 Elo 시스템은 A의 승률을 약 76%로 예측합니다. 예상과 달리 B가 이기면 B는 더 많은 점수를 얻고 A는 더 많이 잃습니다. 이변일수록 조정 폭이 커지므로 순위가 진정한 역량에 빠르게 수렴합니다. 통계적 토대는 **Bradley-Terry 모델**입니다. 각 모델을 잠재적인 "강도 점수"로 추상화하고, 대결에서 한 모델이 다른 모델을 이길 확률을 점수 차이로 결정합니다. Elo는 이 모델을 온라인 갱신 형태로 구현한 엔지니어링 방법입니다. @@ -698,7 +698,7 @@ return paired_bootstrap_or_mcnemar(all_deltas) 모델 선택이든 지속적 개선이든 평가 기반 의사결정은 고품질 운영 데이터에 의존합니다. 아래에서는 먼저 이 데이터를 체계적으로 수집하는 방법인 관측 가능성을 소개하고, 평가 결과를 시스템 개선으로 옮기는 방법을 논의합니다. -![그림 7-6: 관측 가능성 기술 스택](images/fig7-6.svg) +![그림 7-7: 관측 가능성 기술 스택](images/fig7-7.svg) 관측 가능성은 분산 시스템에서 빌려온 개념입니다. 시스템을 열어 작동하는 모습을 직접 볼 수 없으므로 시스템이 내보내는 로그, 지표, 트레이스로 내부 상황을 추론합니다. 의사가 환자의 내부를 직접 보지 못한 채 체온, 혈압, 영상으로 진단하는 것과 같습니다. 에이전트 시스템은 더 어렵습니다. 같은 입력도 서로 다른 출력을 만들 수 있고, 여러 라운드의 사고와 도구 호출 때문에 실행 경로가 매우 복잡하며, 모델의 "사고"는 외부에서 전혀 볼 수 없습니다. @@ -718,11 +718,11 @@ LangSmith는 이 분야를 대표하는 플랫폼 중 하나이며(Langfuse, Ari 이제 부속 저장소에 남아 있는 실제 AndroidWorld 개선 과정을 살펴보겠습니다. API 35 에뮬레이터의 Wi-Fi 설정 작업 네 개만 대상으로 삼고 작업마다 한 번씩 쌍대 실행했습니다. 116개 작업 전체 벤치마크도 아니고 API 33 표준 환경의 재검증도 아닙니다. 시스템 전체가 얼마나 좋아졌는지 증명하는 사례가 아니라 한 라운드의 결과로 다음 라운드에서 무엇 하나를 바꿀지 결정하는 사례입니다. -![그림 7-7: 벤치마크에서 개선으로 이어지는 루프](images/fig7-7.svg) +![그림 7-8: 벤치마크에서 개선으로 이어지는 루프](images/fig7-8.svg) 하네스 엔지니어링의 관점에서 이 절은 본질적으로 하네스를 반복 최적화하는 방법론을 다룹니다. 평가 데이터로 하네스의 약점(컨텍스트 부족? 제약 누락? 검증 불충분? 늦은 피드백?)을 찾아 표적 개선한 다음 다시 평가하여 하네스의 지속적 진화를 위한 폐루프를 만듭니다. -벤치마크 보고서를 분석하기 전에 쉽게 간과하는 원칙을 기억하세요. **에이전트의 성능이 떨어지면 에이전트보다 평가 시스템을 먼저 확인해야 합니다.** 점수가 내려가자마자 에이전트 코드를 수정하기 시작하면서 평가 시스템이 먼저 고장 났을 가능성을 무시하는 것이 흔한 실수입니다. 왜곡된 신호를 따라가면 교정은 첫 단계부터 틀립니다. 전형적인 평가 측 실패에는 런타임 환경의 리소스 부족으로 프로세스가 종료되는 문제(무작위 실패로 나타남), 정답을 오답으로 표시하는 채점기 버그, 프로덕션 시나리오와 동기화되지 않고 드리프트한 테스트 케이스가 있습니다. 대표 수치에서는 모두 모델 성능 저하와 똑같아 보이며, 전체 트레이스를 검토해야만 구분할 수 있습니다. +벤치마크 보고서를 분석하기 전에 쉽게 간과하는 원칙을 기억하세요. **에이전트의 성능이 떨어지면 에이전트보다 평가 시스템을 먼저 확인해야 합니다.** 점수가 내려가자마자 에이전트 코드를 수정하기 시작하면서 평가 시스템이 먼저 고장 났을 가능성을 무시하는 것이 흔한 실수입니다. 왜곡된 신호를 따라가면 교정은 첫 단계부터 틀립니다. 전형적인 평가 측 실패에는 런타임 환경의 리소스 부족으로 프로세스가 종료되는 문제(무작위 실패로 나타남), 정답을 오답으로 표시하는 검증기 버그, 프로덕션 시나리오와 동기화되지 않고 드리프트한 테스트 케이스가 있습니다. 대표 수치에서는 모두 모델 성능 저하와 똑같아 보이며, 전체 트레이스를 검토해야만 구분할 수 있습니다. ### 벤치마크 보고서 읽기: 문제 발견의 기술 @@ -827,7 +827,7 @@ ML 연구자는 모델의 어느 컴포넌트가 실제로 중요한지 알아 다리의 양쪽 끝은 다음과 같이 연결됩니다. 평가 측에 축적한 자산은 거의 그대로 학습 신호로 전환됩니다. 잘 정의한 루브릭이나 검증기는 본질적으로 **검증 가능한 보상을 활용한 강화 학습(RLVR, Reinforcement Learning with Verifiable Rewards)**의 보상 함수입니다. 채점 스크립트가 보상 스크립트가 되고, 테스트 통과 여부나 상태가 기준을 충족하는지는 평가 기준이면서 강화 학습 보상이 됩니다. 하지만 학습에는 평가에서 고려할 필요가 없었던 요구가 생깁니다. 첫째는 **신뢰할 수 있는 재설정 의미론**입니다. 학습은 수백만 에피소드(초기 상태에서 작업 완료까지 이어지는 한 번의 완전한 상호작용)를 실행하며, 에피소드마다 환경을 결정론적이고 깨끗한 초기 상태로 재설정할 수 있어야 합니다. 그렇지 않으면 이전 에피소드의 잔여 상태가 그래디언트 신호를 오염시킵니다. 둘째는 **평가를 훨씬 뛰어넘는 처리량**입니다. 평가 몇천 회면 결론을 내리기에 충분하지만, 학습은 허용 가능한 실제 경과 시간 안에 모델에 수백만 번의 상호작용을 제공해야 합니다. 환경의 병렬화 정도와 인스턴스당 오버헤드가 학습 가능 여부를 직접 결정합니다. 검증기를 보상 함수로 전환하는 것과 학습 수준의 재설정·처리량이라는 두 사항은 8장에서 자세히 설명합니다. -![그림 7-8: 시뮬레이션 충실도 스펙트럼](images/fig7-8.svg) +![그림 7-9: 시뮬레이션 충실도 스펙트럼](images/fig7-9.svg) **디지털 환경**에서는 AWorld 프레임워크가 GAIA 작업을 위한 제어 가능한 MCP 서버 샌드박스를 구축합니다. 도구 함수 126개를 포괄하는 MCP 서버 26개를 제공하여 실제 API에 직접 접근할 때의 차단과 제어할 수 없는 부작용을 피합니다. 모든 도구 호출을 재생하고 감사할 수 있습니다. AWorld의 분산 아키텍처는 기존의 직렬 실행 시간을 7,695초에서 525초로 줄였고(14.6배 향상), 환경의 무상태 설계로 각 인스턴스가 완전히 독립적이어서 효율적인 병렬 처리를 지원합니다. @@ -838,7 +838,7 @@ ML 연구자는 모델의 어느 컴포넌트가 실제로 중요한지 알아 > 로봇 조작을 위한 시뮬레이션 환경을 구성합니다. `ch7/SimpleVLA-RL`과 OpenVLA 문서를 읽고 Vision-Language-Action 모델의 아키텍처를 이해하세요. 시각 인코더, 언어 모델, 행동 디코더를 엔드투엔드로 통합하여 이미지와 텍스트를 공유 의미 공간에 투영합니다. RoboTwin2 환경을 구성하고 관측 공간(세 시점의 RGB + 14차원 관절 상태)과 행동 공간(14차원 제어 벡터)을 이해합니다. `move_can_pot`의 환경 무작위화 메커니즘과 공간 제약 로직을 연구합니다. 사전 학습된 모델을 평가하여 성공률, 완료 시간, 실패 유형을 기록하고 행동 청킹 메커니즘의 영향에 초점을 맞춥니다. > > -> ![그림 7-9: OpenVLA와 RoboTwin2 체화 지능 환경](images/fig7-9.svg) +> ![그림 7-10: OpenVLA와 RoboTwin2 체화 지능 환경](images/fig7-10.svg) > > @@ -850,7 +850,7 @@ ML 연구자는 모델의 어느 컴포넌트가 실제로 중요한지 알아 ## 장 요약 -이 장은 에이전트가 실제로 좋아졌는지 어떻게 아는가라는 질문을 다뤘습니다. 재현 가능한 환경, 유출에 견디는 데이터셋, LLM 평가자, 결과에 따른 모델 선택과 반복 중 어느 하나가 흔들려도 결론의 신뢰성이 떨어집니다. 실측 결과는 네 가지를 더 보여 줍니다. 구조화 메모리와 RAG를 합쳐도 시너지가 보장되지 않고, 캐시와 압축의 절감률은 더할 수 없으며, 참조 음성 선택이 멀티모달 점수의 의미를 바꾸고, 에이전트가 UI를 읽는 능력과 그 token 비용은 Harness가 입력을 표현하는 방식에 달려 있습니다. 모델 선택은 한 점의 성능이 아니라 자원 예산별 역량 곡선을 비교해야 합니다. 프로덕션 평가는 가끔 치르는 시험이 아니라 제품 결정에 내장된 지속적 검증입니다. +이 장은 에이전트가 실제로 좋아졌는지 어떻게 아는가라는 질문을 다뤘습니다. 이 사슬은 네 단계로 이루어집니다. 먼저 무엇을 성공으로 볼지 정리하고(Pass@k, Best@k, Pass consecutive@k의 기준 차이), 다음으로 과제가 어디서 오는지 정하고(공개 벤치마크, 자체 구축 업무 세트, 프로덕션 궤적 환류의 세 출처), 이어서 검증 방식을 고르고(결정적 검증기에서 검사 항목 목록, Rubric과 LLM 판정, 나아가 쌍대 비교까지), 마지막으로 점수를 의사결정으로 바꿉니다(통계적 유의성, 실패 귀인, 회귀 과제, 모델 선정). 어느 단계가 흔들려도 결론의 신뢰성이 떨어집니다. 실측 결과는 네 가지를 더 보여 줍니다. 구조화 메모리와 RAG를 합쳐도 시너지가 보장되지 않고, 캐시와 압축의 절감률은 더할 수 없으며, 참조 음성 선택이 멀티모달 점수의 의미를 바꾸고, 에이전트가 UI를 읽는 능력과 그 token 비용은 Harness가 입력을 표현하는 방식에 달려 있습니다. 모델 선택은 한 점의 성능이 아니라 자원 예산별 역량 곡선을 비교해야 합니다. 프로덕션 평가는 가끔 치르는 시험이 아니라 제품 결정에 내장된 지속적 검증입니다. 책 전체의 구조로 보면 이 장이 만드는 것은 1장 발견 루프의 **증거** 구간입니다. 실패 귀인이 뒤따르는 제안에 기댈 근거가 있는지를 결정합니다. diff --git a/book-ko/images/fig7-1.svg b/book-ko/images/fig7-1.svg index d420d9ef8..bb954af13 100644 --- a/book-ko/images/fig7-1.svg +++ b/book-ko/images/fig7-1.svg @@ -1,20 +1,62 @@ - - - - -1단계: 평가 환경 -“어디서 평가하는가” — 도구 호출형 / 인간-컴퓨터 상호작용형 / 시뮬레이션 환경 - - -2단계: 평가 방법 -“어떻게 판단하는가” — 데이터 세트 설계 · LLM-as-a-Judge · 쌍대 비교와 순위 - - -3단계: 평가 기반 의사결정 -“평가 후 무엇을 하는가” — 모델 선택 · 아키텍처 최적화 · 지속적 개선 - -장 전체의 공통 주제 -• 관측 가능성 -• 시뮬레이션 환경 -• 내부 평가 + + + + + + + + +① 성공의 정의 +Pass@k는 능력 상한 · Pass^k는 업무 신뢰성 + + + +② 과제의 출처 + +공개 벤치마크 +기법 차용 · 거친 선별 + +자체 구축 업무 세트 +실제 과제 분포 + +프로덕션 궤적 환류 +실패 귀인의 산물 + + + +③ 검증 방식 +← 과제의 기계적 검증 가능 정도 순 → + +결정적 검증기 +SWE-bench + + +검사 항목 목록 +τ²-bench + + +Rubric + LLM 판정 +오픈엔드 과제 + + +쌍대 비교 +Chatbot Arena + + + +④ 결과의 활용 +통계적 유의성 → 실패 귀인 → 회귀 과제 → 모델 선정과 Harness 반복 + + +회귀 과제가 새 케이스로 축적 + + +지원 인프라 +관측 가능성(궤적 제공) · 내부 평가 인프라(어블레이션 / AB / 기능 플래그) · 시뮬레이션 환경(8장으로) diff --git a/book-ko/images/fig7-10.svg b/book-ko/images/fig7-10.svg new file mode 100644 index 000000000..2764fd266 --- /dev/null +++ b/book-ko/images/fig7-10.svg @@ -0,0 +1,70 @@ + + + + + +멀티모달 관측 + +헤드 카메라 +224×224 RGB + +왼쪽 손목 카메라 +224×224 RGB + +오른쪽 손목 카메라 +224×224 RGB + +14차원 관절 상태 벡터 + +비전-언어-행동 모델 (VLA) + +비전 인코더 +SigLIP → 시각 tokens + + +언어 모델 +Llama 2 7B backbone + + +행동 디코더 +→ 14차원 연속 제어 벡터 +행동 청킹: 한 번에 연속 행동 25개 생성 + + + +지시: "캔을 냄비 안에 넣으세요" + + +SAPIEN 물리 엔진 + +양팔 로봇 +팔마다 7자유도 = 14차원 행동 + +환경 무작위화 +위치 60cm / 방향 ±22.5° + +충돌 감지 + 물리 시뮬레이션 +강체/연체/마찰력 + +행동 + +관측 + +평가 지표 + +성공률 +캔이 냄비 안에 있고 +떨어지지 않음 + +완료 시간 +25단계×25개 행동 += 제어 625단계 + +일반화 역량 +위치·방향·외형 +변화에 일반화 + +Sim-to-Real +도메인 무작위화 +→ 실제 환경 전이 + diff --git a/book-ko/images/fig7-3.svg b/book-ko/images/fig7-3.svg index 4d567e8cf..55f7515fd 100644 --- a/book-ko/images/fig7-3.svg +++ b/book-ko/images/fig7-3.svg @@ -1,69 +1,76 @@ - - - + + + + + + + - -사용자 시뮬레이터 (LLM) - -알려진 정보: -이름: Sarah Johnson -예약: BK-98712 -작업 지시: -"항공편에 문제가 있는 것 같아요" -→ 세부 정보를 단계적으로 공개 -→ 예약 번호를 먼저 말하지 않음 - -Agent (평가 대상) - - -LLM 사고 + 전략 선택 -① 예약 번호를 알려주시겠어요? -② lookup_booking(BK-98712) -③ 항공편 UA123은 취소됨 -④ cancel_booking(BK-98712) -⑤ 환불 $150, 영업일 기준 3~5일 - -도구 + 데이터베이스 - -lookup_booking -예약 상세 조회 -modify_booking -예약 상태 변경 -cancel_booking -취소 및 환불 -search_flights -대체 항공편 검색 -send_notification -확인 알림 전송 - -DB State: -bookings, users, flights - -대화 - - -도구 호출 - - -이중 제어 환경: 사용자 시뮬레이터도 공유 환경(도구 + 데이터베이스)을 직접 조작 가능 - -작업 완료 후: 다층 검증 - -DB 상태 검사 - -booking.status == 'cancelled' -refund_record EXISTS -refund.amount == 150.00 - -대화 내용 검증 - -'환불' + 금액 포함 -'입금 시점' 포함 -허위 정보 없음 - -절차 준수 검사 - -변경 전 사용자 확인 획득 -권한 밖 작업 없음 -상담원에게 과도한 이관 없음 + + +사용자 시뮬레이터(LLM) +known_info: John Smith / 555-123-2002 / 프랑스 체류 +task_instructions: 점진적 공개 · 감정 · 사실 접지 +수용 기준: excellent만 해결로 인정 + + + +Agent(평가 대상) +입력: 티켓 + 도메인 정책 +비가시: 사용자 단말의 실제 상태 +유도만 가능, 대행은 불가 + + + +다중 턴 대화 +점진적 정보 공개 + + + +공유 환경(이중 제어: 양쪽 모두 상태 변경 가능) + +단말 쪽 상태 +비행기 모드 ON · 로밍 OFF · 데이터 절약 · 잔여 데이터 +사용자 도구: toggle_airplane_mode / toggle_roaming +　　　　　check_status_bar / run_speed_test + +통신사 쪽 데이터베이스 +고객 C1001 · 회선 L1001/L1002/L1003 · 요금제 · 청구 +Agent 도구: get_customer_by_phone / get_data_usage +　　　　　　enable_roaming / refuel_data + + + + + + +사용자의 toggle_roaming으로 환경이 바뀌었다. Agent는 도구를 다시 호출해야 결과를 안다 — 검증은 이 재확인까지 포괄한다 + + + +과제 종료 후: 네 층 검사 + 집계 규칙 + +env_assertions +모바일 데이터 사용 가능 +속도 ≥ 200 / excellent + +actions +toggle_airplane_mode +requestor는 user여야 함 + +communicate_info +필요 정보를 전달했는가 +이 과제에서는 null + +nl_assertions +자연어 층위 판정 +이 과제에서는 null +reward_basis = ["ENV_ASSERTION"]　→　첫 층만 채택. 나머지는 기록되나 보상에는 미반영 diff --git a/book-ko/images/fig7-4.svg b/book-ko/images/fig7-4.svg index 5c03489db..004ac7984 100644 --- a/book-ko/images/fig7-4.svg +++ b/book-ko/images/fig7-4.svg @@ -1,54 +1,54 @@ - - - + + + + + + - -루브릭(평가 기준) - -사실 정확성: 필수 -논리적 일관성: 중요 -환각 감지: 거부 항목 ⚠ -완전성: 중요 - -후보 답변 - -Agent 출력: -"환불 처리가 완료되어 $150가 - 영업일 기준 3~5일 이내 입금됩니다." - - -참고 답안(선택 사항) - -모범 답안 / 채점 기준: -환불 금액을 반드시 포함 -입금 시점을 반드시 포함 -특정 날짜를 확약하지 않음 - - - - -Judge 모델 (GPT-5 / Gemini 2.5) -다중 출처 이기종 평가로 동일 계열 편향 방지 - - -구조화된 평가 출력 - -사실 정확성 -4/4 -금액과 시점 모두 정확 -완전성 -3/4 -환불 방식 설명 누락 -환각 감지 -PASS -허위 정보 없음 -논리적 일관성 -4/4 -인과관계가 명확함 - -점수 집계 전략 -가중 평균: Σ(가중치×차원 점수) -거부 항목: 환각=FAIL → 총점=0 -다중 평가자: Judge 3개 점수의 중앙값 -경계 사례 표시: 차이>2점→사람 검토 + +과제의 기계적 검증 가능 정도: 높음 +낮음 + + +결정적 검증기 +최종 상태가 유일하게 조회 가능 +통과 / 불통과 +SWE-bench는 테스트 실행 + + + +검사 항목 목록 +복수의 결정적 검사 +선언된 기준으로 집계 +τ²-bench 네 층 검증 + + + +Rubric + LLM 판정 +차원은 나뉘나 기계 판정 불가 +차원별 채점과 이유 설명 +상담 품질, 보고서 작성 + + + +쌍대 비교 +차원조차 적어내기 어려움 +A와 B의 우열만 판정 +Chatbot Arena + + +결정적 검증 +완전 재현 가능, CI 편입 가능, 저비용 +대가: 정오만 답하고 문제 위치는 짚지 않음 + + +모델 판정 +진단 차원을 뽑아내고 어서트 불가 과제도 포괄 +대가: 판정 편향과 변동, 더 높은 비용 diff --git a/book-ko/images/fig7-5.svg b/book-ko/images/fig7-5.svg index 0ccdb1848..5c03489db 100644 --- a/book-ko/images/fig7-5.svg +++ b/book-ko/images/fig7-5.svg @@ -1,57 +1,54 @@ - + - -Chatbot Arena 익명 대결 - -Model A(익명) - -"환불 처리가 완료되어 영업일 기준 - 3~5일 이내 계좌에 입금됩니다" -VS - -Model B(익명) - -"네, 환불 처리해 드리겠습니다" - - -사용자가 익명 응답 선택 → A 우세 - -Elo 업데이트 공식 -기대 승률 E_A = 1/(1+10^((R_B-R_A)/400)) | 업데이트: R_A' = R_A + K*(1-E_A) -실시간 순위표(예시) -순위 -모델 -Elo -2위 대비 승률 - -1 -Claude 4 Opus -1352 -— -2 -GPT-5 -1318 -— -3 -Gemini 2.5 Pro -1290 -45% -4 -DeepSeek R2 -1265 -42% -5 -Qwen 3 Max -1230 -39% -6 -Llama 4 405B -1198 -36% - - -GRPO: 쌍대 비교를 RL 학습에 반영 -후보 응답 집합 → 상대 어드밴티지 정규화 → 정책 업데이트(명시적 보상 모델 우회) + +루브릭(평가 기준) + +사실 정확성: 필수 +논리적 일관성: 중요 +환각 감지: 거부 항목 ⚠ +완전성: 중요 + +후보 답변 + +Agent 출력: +"환불 처리가 완료되어 $150가 + 영업일 기준 3~5일 이내 입금됩니다." + + +참고 답안(선택 사항) + +모범 답안 / 채점 기준: +환불 금액을 반드시 포함 +입금 시점을 반드시 포함 +특정 날짜를 확약하지 않음 + + + + +Judge 모델 (GPT-5 / Gemini 2.5) +다중 출처 이기종 평가로 동일 계열 편향 방지 + + +구조화된 평가 출력 + +사실 정확성 +4/4 +금액과 시점 모두 정확 +완전성 +3/4 +환불 방식 설명 누락 +환각 감지 +PASS +허위 정보 없음 +논리적 일관성 +4/4 +인과관계가 명확함 + +점수 집계 전략 +가중 평균: Σ(가중치×차원 점수) +거부 항목: 환각=FAIL → 총점=0 +다중 평가자: Judge 3개 점수의 중앙값 +경계 사례 표시: 차이>2점→사람 검토 diff --git a/book-ko/images/fig7-6.svg b/book-ko/images/fig7-6.svg index ba548f6e6..0ccdb1848 100644 --- a/book-ko/images/fig7-6.svg +++ b/book-ko/images/fig7-6.svg @@ -1,49 +1,57 @@ - - + + - -실행 트리(단일 작업) - -Trace: 베이징의 내일 날씨 조회 (3.2s, $0.008) - -LLM Call: 의도 파악 -Claude 4 Sonnet · 0.4s · 320 tokens - -Tool: get_weather(Beijing) -MCP Server · 1.8s · 200ms TTFT - -├─ HTTP 요청 -api.weather.com · 1.6s - -└─ 응답 파싱 -JSON → 구조화된 날씨 데이터 - -LLM Call: 응답 생성 -Claude 4 Sonnet · 0.8s · 580 tokens - -Tool: send_message(user) -0.2s · 날씨 요약 포함 - - - - - - - -모니터링 대시보드 - -비용 추적 -오늘: $12.30(1,200회) -이번 달: $340(34K회) -이상: task#892가 search를 14회 반복 호출, 비용 $2.1 - -성능 모니터링 -P50 / P95 / P99 지연 시간: 2.1s / 8.4s / 15.2s -도구 성공률: 94.3% - -품질 감사 -작업 성공률: 87% 환각 발생: 2.1% -안전 위반: 0(이번 달) 사용자 만족도: 4.3/5 - -폐루프: 트레이스 데이터 → 문제 발견 → A/B 테스트 → 프롬프트 버전 관리 → 지속적 최적화 + + +Chatbot Arena 익명 대결 + +Model A(익명) + +"환불 처리가 완료되어 영업일 기준 + 3~5일 이내 계좌에 입금됩니다" +VS + +Model B(익명) + +"네, 환불 처리해 드리겠습니다" + + +사용자가 익명 응답 선택 → A 우세 + +Elo 업데이트 공식 +기대 승률 E_A = 1/(1+10^((R_B-R_A)/400)) | 업데이트: R_A' = R_A + K*(1-E_A) +실시간 순위표(예시) +순위 +모델 +Elo +2위 대비 승률 + +1 +Claude 4 Opus +1352 +— +2 +GPT-5 +1318 +— +3 +Gemini 2.5 Pro +1290 +45% +4 +DeepSeek R2 +1265 +42% +5 +Qwen 3 Max +1230 +39% +6 +Llama 4 405B +1198 +36% + + +GRPO: 쌍대 비교를 RL 학습에 반영 +후보 응답 집합 → 상대 어드밴티지 정규화 → 정책 업데이트(명시적 보상 모델 우회) diff --git a/book-ko/images/fig7-7.svg b/book-ko/images/fig7-7.svg index e20e7418d..ba548f6e6 100644 --- a/book-ko/images/fig7-7.svg +++ b/book-ko/images/fig7-7.svg @@ -1,57 +1,49 @@ - - + + - - -① 관찰: 진단 보고서 -전체 성공률: 88% (102/116) -transcription: 0% complex_ui: 17% -math_counting: 0% Wi-Fi 조작: 0% -Task 82,102-115에 실패 집중 - -② 가설: 3계층 개선 프레임워크 - -표층 -H1 설정 탐색 힌트 H2 UI 규칙 - -중층 -H3 멀티모달 파이프라인 수정 H4 사고 - -심층 -H5 GPT-5 H6 UI 요소 트리 - - -③ 실험: 단계별 검증(설정마다 5회×116개 작업) - -H1 탐색 -설정 0%→75% -token+8% - -H3 멀티모달 -전사 0%→80% -지연 +1s - -H4 사고 -수량 집계 0%→70% -지연 3x! - -H6 요소 트리 -UI 17%→52% -token+30% - -④ 결정: 비용-효과 절충 -✓ H1+H3: 저비용·고효과 → 배포 -✗ H4: 작업의 8%만 혜택·지연 3x → 거부 -✓ H6: 35%p 개선/비용 30% → 배포 -✗ H5: 15s/단계는 허용 불가 → 보류 - -⑤ 반복: 새 주기 -H1+H3+H6 배포 → 88%→94% -새 보고서에서 다른 실패 유형 발견: - H7: 조건부 사고 활성화 - H8: 제스처 행동 공간 확장 - -↑ 반복 - -방법론: 관찰→가설→실험→결정→반복 = 연금술에서 과학적 엔지니어링으로 + +실행 트리(단일 작업) + +Trace: 베이징의 내일 날씨 조회 (3.2s, $0.008) + +LLM Call: 의도 파악 +Claude 4 Sonnet · 0.4s · 320 tokens + +Tool: get_weather(Beijing) +MCP Server · 1.8s · 200ms TTFT + +├─ HTTP 요청 +api.weather.com · 1.6s + +└─ 응답 파싱 +JSON → 구조화된 날씨 데이터 + +LLM Call: 응답 생성 +Claude 4 Sonnet · 0.8s · 580 tokens + +Tool: send_message(user) +0.2s · 날씨 요약 포함 + + + + + + + +모니터링 대시보드 + +비용 추적 +오늘: $12.30(1,200회) +이번 달: $340(34K회) +이상: task#892가 search를 14회 반복 호출, 비용 $2.1 + +성능 모니터링 +P50 / P95 / P99 지연 시간: 2.1s / 8.4s / 15.2s +도구 성공률: 94.3% + +품질 감사 +작업 성공률: 87% 환각 발생: 2.1% +안전 위반: 0(이번 달) 사용자 만족도: 4.3/5 + +폐루프: 트레이스 데이터 → 문제 발견 → A/B 테스트 → 프롬프트 버전 관리 → 지속적 최적화 diff --git a/book-ko/images/fig7-8.svg b/book-ko/images/fig7-8.svg index 75a4ce886..e20e7418d 100644 --- a/book-ko/images/fig7-8.svg +++ b/book-ko/images/fig7-8.svg @@ -1,42 +1,57 @@ - + - - -시뮬레이션 충실도 → -확 -장 -성 - -↑ - -Mock API -단위 테스트 수준 -시간당 100만 회 - -AWorld -MCP 샌드박스 -도구 함수 126개 -525s/회 · 분산 - -AndroidWorld -시뮬레이터 -실제 앱 작업 116개 -UI Automator - -Isaac Gym -GPU 병렬 처리 -병렬 인스턴스 수천 개 -정밀도 일부 절충 - -RoboTwin2 -물리 엔진 -고정밀 충돌 -단일 인스턴스 CPU - -현실 세계 -완벽한 충실도 -재설정 불가 - + +① 관찰: 진단 보고서 +전체 성공률: 88% (102/116) +transcription: 0% complex_ui: 17% +math_counting: 0% Wi-Fi 조작: 0% +Task 82,102-115에 실패 집중 + +② 가설: 3계층 개선 프레임워크 + +표층 +H1 설정 탐색 힌트 H2 UI 규칙 + +중층 +H3 멀티모달 파이프라인 수정 H4 사고 + +심층 +H5 GPT-5 H6 UI 요소 트리 + + +③ 실험: 단계별 검증(설정마다 5회×116개 작업) + +H1 탐색 +설정 0%→75% +token+8% + +H3 멀티모달 +전사 0%→80% +지연 +1s + +H4 사고 +수량 집계 0%→70% +지연 3x! + +H6 요소 트리 +UI 17%→52% +token+30% + +④ 결정: 비용-효과 절충 +✓ H1+H3: 저비용·고효과 → 배포 +✗ H4: 작업의 8%만 혜택·지연 3x → 거부 +✓ H6: 35%p 개선/비용 30% → 배포 +✗ H5: 15s/단계는 허용 불가 → 보류 + +⑤ 반복: 새 주기 +H1+H3+H6 배포 → 88%→94% +새 보고서에서 다른 실패 유형 발견: + H7: 조건부 사고 활성화 + H8: 제스처 행동 공간 확장 + +↑ 반복 + +방법론: 관찰→가설→실험→결정→반복 = 연금술에서 과학적 엔지니어링으로 diff --git a/book-ko/images/fig7-9.svg b/book-ko/images/fig7-9.svg index 2764fd266..75a4ce886 100644 --- a/book-ko/images/fig7-9.svg +++ b/book-ko/images/fig7-9.svg @@ -1,70 +1,42 @@ - - + + - -멀티모달 관측 - -헤드 카메라 -224×224 RGB - -왼쪽 손목 카메라 -224×224 RGB - -오른쪽 손목 카메라 -224×224 RGB - -14차원 관절 상태 벡터 - -비전-언어-행동 모델 (VLA) - -비전 인코더 -SigLIP → 시각 tokens - - -언어 모델 -Llama 2 7B backbone - - -행동 디코더 -→ 14차원 연속 제어 벡터 -행동 청킹: 한 번에 연속 행동 25개 생성 - - - -지시: "캔을 냄비 안에 넣으세요" - - -SAPIEN 물리 엔진 - -양팔 로봇 -팔마다 7자유도 = 14차원 행동 - -환경 무작위화 -위치 60cm / 방향 ±22.5° - -충돌 감지 + 물리 시뮬레이션 -강체/연체/마찰력 - -행동 - -관측 - -평가 지표 - -성공률 -캔이 냄비 안에 있고 -떨어지지 않음 - -완료 시간 -25단계×25개 행동 -= 제어 625단계 - -일반화 역량 -위치·방향·외형 -변화에 일반화 - -Sim-to-Real -도메인 무작위화 -→ 실제 환경 전이 + + +시뮬레이션 충실도 → +확 +장 +성 + +↑ + +Mock API +단위 테스트 수준 +시간당 100만 회 + +AWorld +MCP 샌드박스 +도구 함수 126개 +525s/회 · 분산 + +AndroidWorld +시뮬레이터 +실제 앱 작업 116개 +UI Automator + +Isaac Gym +GPU 병렬 처리 +병렬 인스턴스 수천 개 +정밀도 일부 절충 + +RoboTwin2 +물리 엔진 +고정밀 충돌 +단일 인스턴스 CPU + +현실 세계 +완벽한 충실도 +재설정 불가 + diff --git a/book-ru/chapter7.md b/book-ru/chapter7.md index fa5a0cc25..06b67d7b2 100644 --- a/book-ru/chapter7.md +++ b/book-ru/chapter7.md @@ -17,60 +17,117 @@ С точки зрения Harness-инженерии, введённой в первой главе, оценка выполняет в Harness ключевую функцию «проверки». Важно понимать: **объектом оценки должна быть не модель сама по себе, а комбинация модели и Harness**. Одна и та же модель в разных Harness может показывать резко различающиеся результаты — некоторые команды, оптимизируя только Harness, значительно улучшили результаты одной и той же модели на терминальных задачах (подробнее в главе 5). Это значит, что когда агент показывает слабый результат на оценке, направление улучшения может быть не в смене модели, а в оптимизации какого-то компонента Harness (промпта, проектирования инструментов, цикла обратной связи). Полноценная система оценки должна уметь различать два принципиально разных типа проблем: «недостаточные возможности модели» и «дефекты проектирования Harness». **Обычный способ разделить эти два типа проблем — эксперимент с заменой модели (model swap)**: фиксируем Harness и меняем только модель на более сильную или более слабую, наблюдая за амплитудой изменения оценки. Если замена на более сильную модель не даёт прироста — узкое место в Harness; если замена на более слабую модель сильно роняет оценку и результат сильно колеблется в зависимости от возможностей модели, самая прямая интерпретация — узкое место в самих возможностях модели, а текущий результат в основном определяется моделью (хотя объясняется ли это тем, что задача действительно сложна, или тем, что Harness чрезмерно полагается на априорные знания модели — требует дополнительного анализа). Обратите внимание: это отличается от упомянутого выше «абляционного исследования» — это два разных метода. Абляция — это **отключение отдельного компонента Harness** и наблюдение за изменением общей производительности; замена модели — это **фиксация Harness при смене модели**. Первый метод определяет, какой компонент внутри Harness важен, второй — различает, находится ли узкое место в модели или в Harness. Ценность системы оценки становится ещё более очевидной в эпоху быстрой эволюции моделей. Возможности моделей продолжают быстро развиваться, но то, что новая модель лучше показывает себя на публичных бенчмарках, не значит, что она лучше и на вашей конкретной задаче — может произойти даже регресс (regression, то есть новая версия хуже прежней в некоторых аспектах). Только полное тестирование на собственном наборе данных для оценки позволяет принимать решения об обновлении на основе данных. Более того, полноценная система оценки делает возможной стратегию «разработки продукта под будущие модели» — даже если текущая модель ещё не дотягивает до уровня коммерческого использования, можно уже завершить разработку продукта и создать набор для оценки, непрерывно отслеживая результаты новых моделей, и запустить продукт сразу, как только будет достигнут нужный порог. +Систему оценки можно разложить на четыре звена: что считать успехом, откуда берутся задачи, кто проверяет и как оценка превращается в решение. Это показано на рис. 7-1. + +![Рис. 7-1 Четыре звена системы оценки Agent](images/fig7-1.svg) + +## Разбор одной задачи оценки: домен telecom в τ²-bench + +Начнём с того, что целиком разберём одну настоящую задачу из домена telecom в τ²-bench. Исходники лежат в репозитории по пути `chapter7/tau2-bench`, файл задач — `data/tau2/domains/telecom/tasks_small.json`. + +### Четыре составные части определения задачи + +Ниже приведена одна задача из этого файла, сокращённая для удобства чтения. + +```jsonc +{ + "id": "[mobile_data_issue]airplane_mode_on|user_abroad_roaming_enabled_off", + + // Тикет, который получает Agent + "ticket": "У пользователя телефон не выходит в интернет, в строке состояния + показано 'No Service'. Клиент John Smith, номер 555-123-2002, + сейчас во Франции. Проблема считается решённой только если тест + скорости даёт excellent. Тариф менять не хочет, но при необходимости + готов пополнить 2.0 ГБ трафика.", + + // Регламент поведения, который получает симулятор пользователя + "user_scenario": { "instructions": { + "known_info": "You are John Smith with phone number 555-123-2002. + You are currently abroad in France.", + "unknown_info": null, + "task_instructions": + "…express mild frustration after the first unsuccessful attempt. + You will consider the issue resolved only when speed test returns + excellent internet speed and nothing else. If it returns poor, fair + or good, you will not consider the issue resolved. + Whenever the agent asks you about your device, always ground your + responses on the results of tool calls. … + Never make up the results of tool calls." + }}, + + // Перед запуском обе стороны сбрасываются в одну и ту же точку + "initial_state": { "initialization_actions": [ + { "env_type": "user", "func_name": "turn_airplane_mode_on" }, + { "env_type": "user", "func_name": "turn_roaming_off" }, + { "env_type": "assistant", "func_name": "enable_roaming", + "arguments": { "customer_id": "C1001", "line_id": "L1002" } } + ]}, + + // Критерии оценивания + "evaluation_criteria": { + "actions": [ + { "requestor": "user", "name": "toggle_airplane_mode" }, + { "requestor": "user", "name": "toggle_roaming" } + ], + "env_assertions": [ + { "func_name": "assert_mobile_data_status", "expected_status": true }, + { "func_name": "assert_internet_speed", + "expected_speed": 200, "expected_desc": "excellent" } + ], + "communicate_info": null, + "nl_assertions": null, + "reward_basis": ["ENV_ASSERTION"] + } +} +``` -> **Введение в главу** -> -> В этой главе полноценная система оценки строится на трёх уровнях. Первый уровень — **среда оценки** («где тестировать»): как построить автоматизированную, воспроизводимую тестовую среду, включая инструментальную и человеко-машинную парадигмы. Второй уровень — **методы оценки** («как судить»): от принципов проектирования наборов данных и системы метрик оценки (что именно измерять) до автоматизированного судейства через LLM-as-a-Judge (использование большой языковой модели в роли судьи) и парного сравнения с ранжированием моделей. Третий уровень — **решения, основанные на оценке** («что делать с результатами тестов»): превращение результатов оценки в руководство к действию для выбора модели, оптимизации архитектуры и непрерывной итерации, а также использование статистической значимости, чтобы понять, действительно ли наблюдаемая разница в оценках достоверна. Кроме того, в этой главе обсуждается наблюдаемость и внутренняя инфраструктура оценки для продакшн-агентов, а в конце главы вводится симуляционная среда, связывающая эту главу с постобучением из главы 8. -> -> Ключевая идея, проходящая через всю главу: **главная ценность системы оценки — не в том, чтобы выставить баллы текущей системе, а в том, чтобы вы могли быстро и надёжно поспевать за эволюцией моделей**. Когда выходит более мощная или более дешёвая модель, команда с полноценной системой оценки может принять решение о переходе за несколько часов, а команда без такой системы вынуждена полагаться на интуицию или ждать отзывов сообщества — а на конкурентном рынке агентов такой разрыв в скорости может решить исход дела. +В этом определении есть четыре проектных решения, которые стоит разобрать подробнее. -![Рис. 7-1 Три уровня системы оценки](images/fig7-1.svg) +**Граница знаний пользователя смоделирована явно.** В `known_info` всего три факта: имя, номер телефона и страна пребывания. Двух настоящих причин сбоя — включённого авиарежима и выключенного роуминга — там нет. Пользователь о них не знает, а значит не может сам о них сообщить; Agent способен получить их только задавая вопросы и прося пользователя проверить. Так **постепенное раскрытие информации (Progressive Information Disclosure)** реализуется на уровне определения задачи: не через промпт «не выкладывай всё сразу», ограничивающий симулятор, а через моделирование границы знаний пользователя отдельным полем. Большинство бенчмарков выдают полное требование в самом начале задачи, тогда как реальный пользователь начинает обычно со слов «у меня не работает интернет». Довести требование до исполнимого вида — само по себе часть того, что должен уметь Agent. -## Один конкретный пример оценки +**Симулятор получает регламент поведения, а не реплики.** В `task_instructions` смешаны три вида ограничений: эмоциональная установка (после первой неудачной попытки выразить лёгкое недовольство), критерий приёмки (задача считается решённой только когда тест скорости даёт excellent; poor, fair и good отвергаются) и требование **фактического заземления (Grounding)** — любой ответ о состоянии устройства должен опираться на возвращаемое значение инструмента: «Never make up the results of tool calls». Последнее особенно важно: без требования заземления симулируемый пользователь пойдёт за подсказкой Agent и подтвердит, что проблема решена, а оценка выродится во взаимное подтверждение двух моделей. -Прежде чем углубляться в методологию, построим интуитивное понимание на полном примере. Предположим, мы построили агента для клиентской поддержки, и нужно оценить его способность обрабатывать запросы на возврат средств. +**Начальное состояние разделено по управляющей стороне.** Поле `env_type` принимает два значения — `user` и `assistant`: авиарежим и переключатель роуминга принадлежат стороне пользователя, а `enable_roaming` на стороне оператора — стороне Agent. Именно это разделение задаёт форму сбоя: на стороне оператора роуминг подключён, а на устройстве пользователя выключен, поэтому запрос Agent к базе данных даёт лишь вывод «настройки в порядке». Сбой находится на той стороне, которую база данных не видит, и обнаружить его можно только попросив пользователя проверить. -**Тестовый пример**: пользователь просит вернуть заказ, сделанный 3 дня назад (номер заказа #12345, сумма ¥299). Политика компании: полный возврат средств возможен в течение 7 дней. +**Критерии оценивания разделены на четыре слоя, и эта задача использует лишь один из них.** `env_assertions` проверяет конечное состояние (мобильные данные доступны, скорость не ниже 200 Мбит/с и оценка excellent), `actions` проверяет, произошли ли ключевые действия и **какая сторона** их выполнила, а `communicate_info` и `nl_assertions` проверяют, была ли донесена до пользователя необходимая информация. В `reward_basis` этой задачи объявлен только `ENV_ASSERTION`; остальные слои по-прежнему вычисляются и записываются, но в итоговую награду не входят. Основание оценивания объявляется для каждой задачи отдельно, а не фиксируется глобально. -**Траектория агента**: +### Траектория одного реального запуска -```text -Пользователь: Я хочу вернуть наушники, купленные 3 дня назад, номер заказа 12345. (Сегодня 2026-04-10) +Дальше мы предлагаем читателю самому запустить задачи оценки домена telecom в τ²-bench, понаблюдать за устройством задач, за симулятором пользователя, за логикой проверки процесса и результата, а также за траекторией выполнения Agent и разобрать, почему Agent потерпел неудачу. + +> **Эксперимент 7-1 ★: Запустить τ²-bench и сравнить его развитие относительно τ-bench** +> +> Этот эксперимент запускает фреймворк оценки τ²-bench, чтобы понять ключевые моменты устройства среды оценки человеко-машинного типа. Сначала прочитайте файл определения задач по тому же маршруту, что и в этом разделе: каждая задача состоит из четырёх частей — известная информация, инструкции задачи, начальное состояние и условия успеха. Затем прогоните полный цикл оценки, понаблюдайте за многоходовым диалогом симулятора пользователя и Agent и разберите типичные режимы отказа (нарушение политики, пропуск информации, чрезмерная передача оператору и т. п.). +> +> ![Рис. 7-3 Среда с двойным управлением и послойная проверка в τ²-bench](images/fig7-3.svg) -Агент (размышляет): Пользователь хочет вернуть средства, сначала нужно запросить информацию о заказе. -Агент → вызывает инструмент query_order(order_id="12345") -Инструмент возвращает: {status: "delivered", amount: 299, date: "2026-04-07", item: "Bluetooth-наушники"} +В сопутствующем репозитории сохранена одна запись прогона (`chapter7/tau2-bench-eval`). Разберём из неё один успешный запуск. -Агент (размышляет): Дата заказа 2026-04-07, сегодня 2026-04-10, прошло 3 дня — в пределах 7-дневного срока -возврата, условие полного возврата выполнено. -Агент → вызывает инструмент process_refund(order_id="12345", amount=299) -Инструмент возвращает: {refund_id: "R-98765", status: "processing", eta: "3-5 рабочих дней"} +Первые десять с лишним ходов — этап идентификации аккаунта. Agent по номеру находит клиента C1001, затем последовательно запрашивает расход трафика по трём линиям L1001, L1002 и L1003 и снова спрашивает, какой номер пользователь реально использует во Франции. В сообщении 17 он делает ошибочный вывод: -Агент: Я оформил для вас возврат средств, полный возврат по заказу #12345 (Bluetooth-наушники, ¥299) - сейчас в обработке, ожидается зачисление в течение 3-5 рабочих дней. Номер возврата R-98765, - по нему можно отслеживать статус. -``` +> **Agent** (17): номер 555-123-2002 отсутствует среди ваших активных линий, ближайший — 555-123-2001… + +Этот вывод опирается на запрос лишь по одной линии L1001. После того как пользователь настаивает, что номер верен, Agent запрашивает L1002 и только тогда находит соответствие. Ключевой перелом наступает в сообщении 30: -**Оценка по рубрике** (четыре измерения, по 1-4 балла в каждом). В таблице 7-1 приведён пример оценки этой задачи по возврату средств в клиентской поддержке — он показывает, как рубрика разбивает одну траекторию агента на проверяемые оценочные измерения. +> **Пользователь** (30) → вызывает `check_network_status()`, `check_status_bar()` +> +> **Ответ инструмента** (31): `Airplane Mode: ON | Cellular Connection: no_service | Mobile Data Enabled: Yes | Data Roaming Enabled: No` +> +> **Пользователь** (33): вижу, что телефон сейчас в авиарежиме, поэтому сигнала нет. Мобильные данные включены, но роуминг выключен. Выключить авиарежим и попробовать? -Таблица 7-1 Пример оценки по рубрике для задачи возврата средств в клиентской поддержке +Вызов инструмента исходит от **пользователя**, а не от Agent. Это и есть механизм **двойного управления (Dual-Control)**: у симулируемого пользователя есть собственный набор инструментов — `check_status_bar`, `toggle_airplane_mode`, `reseat_sim_card`, `run_speed_test` и другие. -| Измерение | Критерий | Балл | Обоснование | -|--------------------|-----------------------------------|---------|-------------------------------| -| Корректность операции | Верны ли сумма возврата и номер заказа | 4 | Корректно запросил информацию и оформил полный возврат ¥299 | -| Соответствие политике | Соблюдена ли 7-дневная политика возврата | 4 | Заказ в пределах срока возврата, соответствует политике | -| Полнота информации | Сообщены ли сумма, срок зачисления, номер возврата | 4 | Все три ключевых пункта сообщены | -| Обнаружение галлюцинаций (пункт отказа) | Придуманы ли несуществующие сведения | Пройдено | Вся информация взята из результатов вызова инструментов | +Дальше диагностика идёт гладко: Agent просит выключить авиарежим и включить роуминг, пользователь выполняет оба действия (35, 37), строка состояния показывает полный 5G; Agent просит замерить скорость, приходит 275 Мбит/с с оценкой Excellent (46), и пользователь подтверждает, что проблема решена. Обе проверки `env_assertions` пройдены, `reward = 1.0`. -Обнаружение галлюцинаций выделено как **пункт отказа (veto)**, а не как оцениваемое по шкале измерение, потому что оно ортогонально качеству — плавный, подробный, вежливый ответ, содержащий ложные факты, наносит пользователю куда больший вред, чем короткий, но точный ответ. (Общий принцип устройства механизма отказа рассматривается далее в разделе «Четыре принципа рубрики».) +В этой траектории с максимальным баллом есть и проблема, которую верификатор не поймал. В первом же абзаце политики Agent для telecom написано «You should only make one tool call at a time», однако в сообщении 4 Agent выпустил сразу два вызова: `get_customer_by_phone` и `get_customer_by_name`. Верификатор не счёл это ошибкой, потому что `reward_basis` этой задачи учитывает лишь конечное состояние. Это не упущение τ²-bench, а неизбежная цена бинарной награды: она меняет детальность процесса на единственное число, сопоставимое между моделями. Но системе оценки в продакшене обычно нужно больше: не только вердикт «верно или неверно», но и указание на то, где именно проблема. -Этот тестовый пример пройден успешно. Но хорошая оценка проверяет не только успешные сценарии, но и пограничные случаи и ловушки — сможет ли агент корректно отказать, если пользователь хочет вернуть заказ 15-дневной давности (превышение срока возврата)? Поверит ли агент на слово, что «служба поддержки уже одобрила возврат», не имея записи об этом в системе? Именно такие пограничные сценарии и отличают агентов с высокими возможностями от менее способных. +Провалившаяся задача не менее интересна для разбора. Номер пользователя — 555-123-2002, но Agent выбрал линию L1001 и продолжил рассуждать, опираясь на её расход 3,2/5 ГБ. По ходу дела `get_details_by_id(L1001)` явно вернул, что номер этой линии — 555-123-2001; Agent прочитал результат, но вывод не исправил, затем потратил десятки сообщений на посторонние проверки и в итоге передал диалог оператору. Половину задачи он всё же выполнил: заставил пользователя выключить режим экономии трафика, и это действие на стороне пользователя действительно произошло и было проверено средой. Но из-за неверно выбранной линии необходимое пополнение на 2 ГБ так и не было выполнено, и все три проверки конечного состояния провалились. Форма этого отказа очень похожа на случай AndroidWorld, разбираемый ниже в разделе «Атрибуция отказов»: доказательства, нужные для исправления вывода, уже были в контексте, но Agent не вернулся к ним. -Процесс выше — определение тестового примера, запуск агента, оценка по рубрике, анализ результатов — это базовый каркас оценки. Далее в этой главе мы шаг за шагом раскроем методы проектирования каждого из этих этапов. +Одна эта задача уже ставит все вопросы, на которые должен отвечать набор оценки: что считать успехом, откуда берутся задачи, кто проверяет и как оценка превращается в решение. Следующие разделы разбирают их по порядку. -## Система метрик оценки: обновлённые критерии +## Метрики оценки: определение успеха -До построения среды и набора данных нужно определить, что означает «успех»: достаточно ли один раз найти рабочий путь или каждый запуск обязан быть безошибочным? Разные определения приводят к разным инженерным решениям. В этом разделе сначала выстраивается такая система мер, а далее объясняется, как реализовать среду, набор данных и оценщик. +Результат оценки из предыдущего раздела — четыре пройденные задачи из пяти. По одному числу 0,8 нельзя судить, пригодна ли система. Если это Agent поддержки по возвратам, то один пользователь из пяти не получит причитающийся ему возврат; если это Agent безопасности, ищущий уязвимости, то четыре попадания из пяти — весьма достойно. Разница в том, какой уровень успешности требует конкретный бизнес-сценарий. ### Техническое чудо: потолок возможностей по Pass@k @@ -101,209 +158,151 @@ $$ В отчёте об оценке нужно чётко указывать, что означают $k$ попыток: $k$ независимых выборок одной задачи или $k$ подряд идущих задач в продакшен-конвейере. Для операций с побочными эффектами нельзя просто «повторять, пока не выйдет»: выборку следует делать в песочнице или в среде с откатом, а каждый отказ заносить в метрику надёжности. -### Метрики процесса: от чёрного ящика к белому - -Смотреть только на конечный результат недостаточно — важен и сам путь, которым агент к нему пришёл. **Доля допустимых действий** измеряет, какая часть операций была валидной и разрешённой — недопустимые операции включают вызов несуществующих инструментов, передачу параметров неверного типа; превышение полномочий означает действия за пределами предоставленных прав. Высокая доля допустимых действий говорит о том, что агент чётко понимает экосистему инструментов. **Точность вызова инструментов** идёт дальше и требует, чтобы параметры были осмысленными семантически: поисковый запрос должен точно выражать потребность, путь файловой операции — указывать на нужную цель. - -**Эффективность пути** измеряет экономичность выполнения задачи: число шагов (циклов «мысль — действие — наблюдение»), избыточные действия (повторный поиск по тем же ключевым словам, повторное чтение одного и того же файла), число откатов (то есть частота, с которой агент осознаёт ошибку и исправляет её — редкие откаты — это нормально, но частые говорят о недостаточном упреждающем планировании). Для определения «разумного числа шагов» нужна база сравнения — либо эксперт-человек, либо эвристический алгоритм. - -**Полнота поиска** касается задач по сбору информации: насколько полно агент исследовал информационное пространство? Не сделал ли он поспешный вывод, посмотрев лишь первую страницу результатов поиска? **Стоимость и задержка** отслеживают число запросов, расход токенов (нужно различать стоимость входных/выходных токенов, учитывать повторное использование KV Cache), время по настенным часам (включая инференс модели + выполнение инструментов + сетевые задержки) — стоит отслеживать распределение времени, чтобы находить узкие места. - -### Безопасность, устойчивость и покрытие траектории - - -**Метрики безопасности и соответствия требованиям** критически важны при промышленном развёртывании: срабатывание чувствительных операций (удаление данных / изменение прав доступа / отправка внешней коммуникации), утечка данных (вывод паролей в лог / отправка приватных документов во внешний API), нарушающий контент — всё это должно подчиняться **принципу нулевой терпимости**, аналогично отклоняющему пункту для галлюцинаций (см. далее «четыре принципа рубрики»): одно серьёзное нарушение безопасности отменяет всю оценку целиком, независимо от того, насколько хорошо агент справился по другим измерениям. - -**Устойчивость** измеряет стабильность работы в условиях неопределённости: чувствительность к случайному зерну (насколько сильно различаются результаты при разной инициализации), адаптивность к изменению страниц (обновление UI сайта не должно приводить к полному отказу), устойчивость к нестабильности API (может ли агент изящно обрабатывать временные сбои, таймауты, изменения формата), помехи от долговременной памяти (не приводит ли устаревшая информация, накопившаяся в контексте, к ошибочным решениям). - -**Двойное покрытие: траектория выполнения и конечный результат.** Легко упускаемое из виду в оценке различие: то, что агент «говорил и делал» в процессе выполнения (то есть траектория, trajectory, определённая в главе 1), и то, «каким в итоге стало состояние системы» (конечный результат, outcome) — это две разные вещи. Слова агента «бронирование билета завершено» — это информация уровня траектории, а появление реальной записи о заказе в базе данных — проверка уровня результата. Если смотреть только на траекторию, можно упустить случаи «сказал, но не сделал»; если смотреть только на результат, можно не заметить, что промежуточные шаги пошли не так. Anthropic приводила пример: агент по бронированию авиабилетов в ходе выполнения обнаружил лазейку в политике авиакомпании и нашёл для пользователя более дешёвый вариант — если оценивать только по заранее заданному пути выполнения, этот прогон будет признан провальным; но с точки зрения конечного результата пользователь получил вариант лучше исходного. Поэтому оба типа оценки должны присутствовать одновременно, чтобы избежать системных слепых зон. - -### Ручная выборочная и состязательная проверка - -Даже если автоматическая оценка в большинстве случаев надёжна, необходима регулярная выборочная проверка человеком: она должна охватывать разные типы задач, случаи успеха/неудачи и неоднозначные случаи вблизи граничных оценок, при этом проверяется не только результат, но и обоснованность рассуждений, приведших к оценке. - -Выборочную проверку человеком можно дополнительно систематизировать в виде **калибровки судьи**: перед масштабным применением LLM-судьи сначала строится размеченный человеком золотой набор (например, 100–200 случаев, охватывающих все типы задач и уровни сложности), на котором измеряется согласованность между моделью-судьёй (то есть LLM в роли судьи; механизм подробно разбирается в следующем разделе про LLM-as-a-Judge) и человеческой разметкой (простой коэффициент совпадения или коэффициент согласия, например Cohen's kappa, который исключает долю случайных совпадений); только после достижения заданного порога (например, kappa выше 0,7) модель-судью допускают к масштабной оценке; впоследствии при каждом обновлении модели-судьи или рубрики калибровку на золотом наборе нужно проводить заново. Без этого шага оценка LLM-судьи — это просто «мнение ещё одной модели», а не надёжный заменитель человеческого суждения. - -**Состязательная рецензия** через red teaming целенаправленно создаёт сложные для оценки случаи: ответы, внешне безупречные, но содержащие скрытые ошибки; ответы, проходящие проверку за счёт нагромождения ключевых слов; ответы, использующие известные предубеждения модели-судьи для получения незаслуженно высокой оценки. **Механизм множественных судей** использует несколько независимых судей, оценивающих результат по отдельности, а итоговый результат определяется взвешенным усреднением или проверкой на согласованность — при серьёзных расхождениях между судьями случай помечается для дополнительной проверки человеком. +## Среда оценки -## Автоматизированная среда оценки +Когда основание метрики определено, следующий вопрос — где измерять. Среда оценки — это установка, которую можно запускать повторно: при одном и том же начальном состоянии один и тот же Agent должен давать сопоставимые результаты. -Оценка агента требует воспроизводимой автоматизированной среды — той, что позволяет быстро тестировать эффект изменений в процессе разработки. Построение такой среды требует ответа на три вопроса: что оценивать (определение задач и критерии проверки), с кем оценивать (как имитировать собеседника агента) и по каким критериям выставлять баллы. +### Пять составляющих -### Базовые составляющие среды оценки +Вернёмся к разобранной выше задаче telecom. Если взять её за образец, всё необходимое для повторно запускаемой среды оценки уже есть. -Среда оценки состоит из пяти элементов — в дальнейших разделах будет подробно раскрыто проектирование набора данных и критериев оценки: +**Набор данных (Dataset)** — это сам файл задач: начальное состояние, тикет для Agent, регламент поведения для симулятора и критерии приёмки упакованы в одну запись, и одна запись — это один тест-кейс. -**Набор данных (Dataset)** определяет набор задач, включая начальное состояние, описание цели и, опционально, эталонное решение. +**Состояние среды (Environment State)** — изменяемая информация во время выполнения задачи: клиенты, линии, тарифы и счета в базе данных плюс авиарежим, роуминг, переключатель экономии трафика и остаток трафика на стороне устройства. Оно должно сбрасываться, и `initialization_actions` — это и есть скрипт сброса. Реалистичность требует, чтобы изменения состояния подчинялись бизнес-логике; управляемость требует, чтобы перед каждым запуском можно было вернуться в одну и ту же точку. -**Состояние среды (Environment State)** хранит изменяемую информацию в процессе выполнения задачи, требуя баланса между реалистичностью и управляемостью. Например, в оценке клиентской поддержки состояние среды включает записи заказов в базе данных и баланс счёта пользователя. После вызова агентом `process_refund` статус заказа меняется с `"delivered"` на `"refunded"`, баланс увеличивается — это и есть «изменяемая информация». «Реалистичность» требует, чтобы изменения состояния соответствовали бизнес-логике (возврат не превышает сумму заказа), «управляемость» требует, чтобы каждый тест можно было сбросить к одному и тому же начальному состоянию. +**Интерфейс инструментов (Tools)** разделён на две стороны. Agent может вызывать операции на стороне оператора: запрос клиента, запрос расхода, пополнение трафика, передачу оператору. Пользователь может переключать настройки на устройстве. Оба набора инструментов атомарны, и высокоуровневой абстракции вроде «решить проблему пользователя с интернетом» не существует: слишком высокий уровень абстракции превращает оценку в проверку одного вызова функции, а планирование и рассуждение поглощаются самим инструментом. -**Интерфейс инструментов (Tools)** определяет набор действий, доступных агенту — инструменты не должны предоставлять слишком высокоуровневые абстракции (например, «решить проблему пользователя»), а должны предоставлять атомарные операции (запросить заказ, изменить бронирование, отправить письмо), заставляя агента комбинировать эти операции через планирование и рассуждение. +**Критерий оценивания (Rubric)** — это четыре слоя проверок в `evaluation_criteria` плюс правило агрегации `reward_basis`. -**Критерии оценки (Rubric, критерии выставления баллов)** количественно оценивают результат работы агента: могут быть бинарными (прошёл/не прошёл), непрерывными (от 0 до 100 баллов) или многомерными (отдельные баллы за точность, эффективность, безопасность). +**Протокол выполнения (Interaction Protocol)** задаёт порядок взаимодействия и условия завершения. Нормальный сигнал завершения здесь — вывод симулируемым пользователем `###STOP###`; кроме того, есть предел числа ходов, а симулируемый пользователь может и сам прервать диалог, исчерпав терпение: низкая эффективность общения сама по себе засчитывается как отказ. -**Протокол взаимодействия (Interaction Protocol)** задаёт режим взаимодействия и условия завершения. +Убери любую из пяти составляющих — и оценка перестанет быть повторяемым циклом. Разбирая дальше другие бенчмарки, мы по-прежнему пользуемся этими пятью пунктами как системой отсчёта. -Вместе эти пять элементов образуют воспроизводимый цикл оценки. +### Среды оценки человеко-машинного и инструментального типов -![Рис. 7-2 Среды оценки инструментального и человеко-машинного типов](images/fig7-2.svg) - -В зависимости от задачи агента среды оценки можно грубо разделить на два типа: с вызовом инструментов и с взаимодействием человека и машины. - -### Среда оценки инструментального типа +Задачам вроде telecom обязательно нужен собеседник, и часть с симуляцией пользователя из пяти составляющих здесь незаменима. Но есть и другой большой класс задач, где собеседника нет вовсе: в генерации кода, анализе данных, решении математических задач Agent от начала до конца взаимодействует только с инструментами, правильность определяется прохождением проверки исполнением, и ни ручная разметка, ни суждение модели не требуются. Такие среды обходятся без симулятора пользователя, остальные четыре составляющие остаются, только в более простой форме: состояние среды — файловая система или база данных, критерий оценивания — кусок тестового кода, а протокол выполнения вырождается в «вызывать инструменты, пока не будет получен ответ или не исчерпан лимит ходов». -Для задач вроде генерации кода и анализа данных, которые в основном опираются на использование инструментов, фреймворк Verifiers демонстрирует типичный паттерн проектирования. Агент выполняет задачу, вызывая заранее определённые инструменты, а проверка основана на исполняемых критериях (проходят ли тесты, совпадает ли ответ), не полагаясь на человеческую разметку или оценку моделью. +Фреймворк Verifiers расслаивает такие среды по двум измерениям: нужно ли задаче сохранять состояние между ходами и нужна ли изоляция. `SingleTurnEnv` подходит, когда задают математическую задачу и сразу проверяют ответ; `ToolEnv` — когда ищут по нескольким веб-страницам, обобщают ответ и проверяют итог; `StatefulToolEnv` — когда меняют запись в базе и проверяют изменение состояния; `SandboxEnv` — когда запускают код в песочнице и проверяют выходные файлы. В табл. 7-1 сведены эти четыре типа, чтобы выбирать по требованиям к состоянию задачи, вызову инструментов и изоляции. -Verifiers вводит иерархический дизайн сред: `SingleTurnEnv` подходит для одноходовых задач (например, простых вопросов-ответов), `ToolEnv` поддерживает автономный цикл многоходовых вызовов инструментов, `StatefulToolEnv` и `SandboxEnv` поддерживают инструменты с состоянием и долго работающие изолированные среды (например, выполнение кода). Например, `SingleTurnEnv` подходит, чтобы задать математическую задачу и сразу проверить ответ; `ToolEnv` подходит для поиска по нескольким веб-страницам с последующим синтезом ответа и проверкой итогового результата; `StatefulToolEnv` подходит для изменения записей в базе данных с последующей проверкой изменения состояния БД; `SandboxEnv` подходит для запуска кода в изолированной среде с последующей проверкой выходных файлов. Таблица 7-2 сводит воедино эти типы сред, чтобы читатель мог выбрать подходящую среду оценки исходя из требований к состоянию задачи, вызову инструментов и изоляции. +Таблица 7-1 Сравнение типов сред Verifiers -Таблица 7-2 Сравнение типов сред Verifiers - -| Тип среды | Сохранение состояния | Вызов инструментов | Типичный пример использования | +| Тип среды | Сохранение состояния | Вызов инструментов | Типичный сценарий | |---|---|---|---| -| SingleTurnEnv | Нет | Нет | Одноходовые вопросы-ответы, математика | -| ToolEnv | Нет | Многоходовой | Поиск + синтез информации | -| StatefulToolEnv | Есть | Многоходовой | Изменение записей БД | -| SandboxEnv | Есть + изоляция | Многоходовой | Выполнение кода и тесты | +| SingleTurnEnv | нет | нет | Одноходовые вопросы, математика | +| ToolEnv | нет | многоходовый | Поиск + обобщение информации | +| StatefulToolEnv | да | многоходовый | Изменение записей в базе данных | +| SandboxEnv | да + изоляция | многоходовый | Исполнение кода и тесты | -Фреймворк поддерживает параллельную выборку и кэширование траекторий, полная траектория каждой оценки (наблюдения, действия, вознаграждения) сохраняется для последующего анализа и воспроизведения. +Фреймворк поддерживает параллельное семплирование и кэширование траекторий; полная траектория каждой оценки (наблюдения, действия, награды) сохраняется, что упрощает последующий анализ и воспроизведение. Кроме того, эффект выполнения инструмента зависит от текущего состояния, поэтому при сбое следует возвращать понятное сообщение об ошибке, а не одинокий флаг неудачи, — тогда Agent сможет скорректировать стратегию. -Среда также должна учитывать зависимость эффекта операций от состояния — эффект выполнения инструмента зависит от текущего состояния, а при неудаче должно предоставляться понятное сообщение об ошибке, а не простой флаг сбоя, чтобы агент мог учиться на ошибках и корректировать стратегию. +Оценка инструментального типа проверяет правильность наблюдаемых изменений состояния, а оценка человеко-машинного типа — обоснованность стратегии общения: первая проверяет действие, вторая — ведение диалога. Сопоставление структуры двух типов сред приведено на рис. 7-2. -### Среда оценки человеко-машинного типа +![Рис. 7-2 Среды оценки инструментального и человеко-машинного типов](images/fig7-2.svg) -Многие реальные задачи включают не только вызовы инструментов, но и требуют диалога с человеком. Агенту клиентской поддержки нужно понимать нечёткие формулировки, уточнять потребности, запрашивать данные в фоновых системах, подтверждать информацию у пользователя. Оценка таких задач сталкивается с фундаментальной проблемой: как имитировать реального пользователя в автоматизированной среде? +## Проектирование набора данных для оценки -Ключевой принцип проектирования — **прогрессивное раскрытие информации (Progressive Information Disclosure)** — именно это принципиально отличает человеко-машинную оценку от традиционных бенчмарков (benchmark). Большинство benchmark сразу выкладывают полное требование целиком, но в реальности пользователи редко способны сразу чётко сформулировать свою потребность — обычно они говорят что-то вроде «у меня, кажется, проблема с рейсом» или «интернет не работает». Агенту нужно уточнять требования через активные вопросы, и сам этот процесс — важное проявление его возможностей. Поэтому в оценке **ни в коем случае нельзя сразу раскрывать агенту всю информацию симулируемого пользователя** — информация должна раскрываться по мере необходимости, постепенно, в ходе диалога. +Если среда оценки — сцена, то набор данных — сценарий. Те же пять составляющих при смене класса задач могут заполняться совершенно иначе: откуда берутся задачи, насколько глубоко может проверить верификатор, как не дать их запомнить. Этот раздел отталкивается от проектной практики нескольких публичных бенчмарков и завершается более практическим вопросом — откуда должны браться задачи в собственном наборе оценки. -Решение τ-bench — это **симуляция пользователя (User Simulation)**: другая LLM играет роль пользователя, ведя диалог с агентом согласно заранее заданным инструкциям. Симулированный пользователь получает инструкцию по задаче (например, «мне нужно отменить рейс на завтра»), постепенно раскрывает агенту необходимую информацию в ходе диалога, отвечает на вопросы, а по завершении задачи подаёт сигнал о завершении. Промпт требует от симулированного пользователя «не раскрывать сразу всю информацию, предоставлять только то, что необходимо на текущем шаге» и «не выдумывать информацию, не предусмотренную инструкцией». Проектирование симуляции пользователя требует баланса между реалистичностью и управляемостью: поведение должно быть близко к реальному пользователю (нечёткие формулировки, неполная информация, случайные эмоциональные колебания), при этом следовать определённому сценарию для обеспечения воспроизводимости. +### Поперечное сопоставление проектных решений бенчмарков -Ниже пример многоходового диалога с прогрессивным раскрытием информации (симулятор пользователя действует по фиксированному сценарию): +Различие по наличию собеседника, проведённое в предыдущем разделе, — лишь первый слой различий на уровне среды; расхождения на уровне набора данных полнее отражают проектные компромиссы. В табл. 7-2 несколько часто цитируемых бенчмарков поставлены рядом. -> **Пользователь**: «У меня проблема с рейсом». -> **Агент**: «Уточните, пожалуйста, какой рейс?» -> **Пользователь** (раскрывает по сценарию): «Delta 123, завтра утром из Сан-Франциско в Нью-Йорк». -> **Агент**: «В чём именно проблема?» -> **Пользователь** (раскрывает по сценарию): «Время полёта слишком долгое, хочу поменять рейс». -> **Агент**: «Есть предпочтения по новому рейсу?» -> **Пользователь** (раскрывает по сценарию): «Подойдёт любой дневной рейс». +Таблица 7-2 Ключевые проектные решения нескольких бенчмарков для Agent -Симулятор пользователя следует фиксированному сценарию (известная информация + правила раскрытия), обеспечивая воспроизводимость оценки, одновременно имитируя постепенную манеру выражения реального пользователя. У симулированного пользователя часто задано и **ограниченное терпение**: если агент общается неэффективно, симулированный пользователь может прервать диалог, и задача провалится. +| Бенчмарк | Проверяемая способность | Источник задач | Кто играет среду | Верификатор | +|---|---|---|---|---| +| τ²-bench | Человеко-машинное взаимодействие и вызов инструментов в поддержке | Ручное написание + комбинаторная генерация | Симулятор пользователя + бизнес-БД | Четыре слоя проверок, агрегируемые в бинарную оценку через `reward_basis` | +| SWE-bench Verified | Разработка ПО, coding | Реальные issue с GitHub, отобранные вручную | Репозиторий кода + набор тестов | Двойная проверка FAIL\_TO\_PASS / PASS\_TO\_PASS | +| AndroidWorld | Работа с GUI телефона на Android | Инстанцирование параметризованных шаблонов | Реальный эмулятор Android | Утверждения о конечном состоянии UI | +| OSWorld | Работа с GUI рабочего стола Linux | Старт из заранее настроенного промежуточного состояния | Реальная виртуальная машина | 134 независимые функции оценивания | +| Terminal-Bench | Работа с терминалом Linux, coding | Ручное написание | Контейнер Docker | Проверка файловой системы + реальное исполнение | +| GAIA | Универсальный ИИ-ассистент, собирающий информацию | Ручное написание + собственные вложения | Открытый интернет | Точное совпадение строк | -τ-bench — это benchmark для оценки работы агентов в структурированных бизнес-процессах (например, поддержка авиакомпаний, розничная поддержка). Проверка в нём выполняется на уровне компонентов и по нескольким измерениям: с одной стороны, проверяется, корректно ли финальное состояние базы данных (например, статус бронирования стал «отменено»), с другой — проверяется, вывел ли агент в диалоге необходимую ключевую информацию (например, сумму возврата и срок зачисления, что проверяется поиском конкретных строк или паттернов). Такая двойная проверка одновременно оценивает точность операций и эффективность коммуникации. Но на уровне задачи в целом эти проверки в итоге сводятся к **бинарному вознаграждению «ноль или один»** — только если пройдены все проверки, начисляется 1 балл, при провале хотя бы одной — 0 баллов. Бинарное вознаграждение удобно для подсчёта показателей надёжности вроде Pass^k (см. далее раздел «Система метрик оценки»), ценой этого становится то, что «операция корректна, но упущено какое-то некритичное поле» и «полный провал» получают одинаковую оценку. +### Верификаторы -Улучшенная версия **τ²-bench** несёт основной прирост не в детализации оценки, а в двух моментах: во-первых, это **среда двойного контроля (Dual-Control)** — теперь не только агент может вызывать инструменты, симулятор пользователя тоже может управлять той же общей средой (например, агент подсказывает пользователю, как переключить режим полёта, а действие пользователя реально меняет состояние среды), что гораздо ближе к реальным сценариям технической поддержки, требующим активного участия пользователя; во-вторых, это **более точная спецификация задач и композиционная генерация задач** — меньше двусмысленности в условиях успеха, конкретные экземпляры задач можно параметрически генерировать пакетно (подробные измерения проверки см. далее в разделе «Обеспечение проверяемости и объективности»). +Agent запросто напишет пространный отчёт о том, что задача полностью выполнена, хотя на деле не выполнено ничего. Фреймворк оценки обязан проверять факты, которые машина может подтвердить независимо, а не собственные заявления Agent. -> **Эксперимент 7-1 ★: запуск τ²-bench и сравнение с эволюцией от τ-bench** -> -> Этот эксперимент нацелен на то, чтобы через запуск фреймворка оценки τ²-bench понять ключевые аспекты проектирования среды оценки человеко-машинного типа, а через сравнение различий между τ-bench и τ²-bench почувствовать, как итеративно совершенствуется набор данных для оценки. -> -> Внимательно изучите файл определения задачи: каждая задача включает известную информацию (фоновые знания пользователя), инструкцию по задаче (указания, как постепенно раскрывать информацию и стратегию реагирования) и условия успеха (целевое состояние базы данных и обязательную подтверждающую информацию, которая должна прозвучать в диалоге). Запустите полный процесс оценки, понаблюдайте за многоходовым диалогом между симулятором пользователя и агентом, проанализируйте типичные паттерны сбоев (нарушение политики, пропуск информации, чрезмерная передача обращения оператору-человеку и т.д.). -> -> -> ![Рис. 7-3 Архитектура оценки τ²-bench](images/fig7-3.svg) -> -> -> Сравните различия в дизайне τ-bench и τ²-bench: в исходной версии τ-bench инструкции пользователя были слишком простыми (агент мог угадать ответ), условия успеха были недостаточно точными (что приводило к неверным оценкам), симулятор пользователя действовал слишком механически. τ²-bench устраняет эти проблемы системными улучшениями: -> -> - **Введены более детальные инструкции по задаче**: включая «требование привязки к фактам» (Grounding), то есть ответ обязательно должен опираться на реальное состояние среды -> - **Более точные критерии оценки**: например, «задача считается решённой только если тест скорости вернул excellent» -> - **Более реалистичные нормы поведения симулятора пользователя**: постепенное раскрытие информации, естественные эмоциональные колебания -> -> Обратите особое внимание на новые задачи домена telecom в τ²-bench, чтобы понять устройство среды двойного контроля (как описано выше, пользователь и агент совместно управляют одной общей средой). -> - -В отличие от оценки инструментального типа, которая фокусируется на «были ли выполнены наблюдаемые изменения состояния», человеко-машинная оценка фокусируется на «удалось ли направить пользователя к когнитивному или решенческому изменению» — первая оценивает правильность действий агента, вторая — обоснованность его коммуникационной стратегии. +**SWE-bench Verified раскладывает «исправление завершено» на два независимых утверждения.** Первое — FAIL\_TO\_PASS: до исправления падает, после исправления проходит, что доказывает, что проблема действительно решена. Второе — PASS\_TO\_PASS: проходит и до, и после, что доказывает, что новых дефектов не внесено. Если проверять только первое, Agent может проскочить, удалив или переписав мешающие утверждения; если только второе — это всё равно что не проверять. Лишь проверка обоих делает «исправлено» и «ничего не сломано» двумя самостоятельно доказуемыми выводами. Дополнительно подтверждается устойчивость самих тестов, чтобы исключить нестабильные тесты (flaky test), которые то проходят, то падают. -Построение среды оценки также затрагивает проектирование симуляционной среды — когда среда оценки должна поддерживать масштабное повторяющееся взаимодействие, она превращается в симуляционную среду, что кратко обсуждается в конце главы. +**Верификатор OSWorld способен обнаружить случаи, когда снаружи всё выполнено, а по сути неверно.** Он оснащён 134 независимыми функциями оценивания и полным доступом к операционной системе, что позволяет проверять структуру файловой системы, состояние процессов, сетевые соединения и внутреннее состояние приложений. В задачах работы с базой данных скрипт оценки не только подтверждает наличие файла отчёта, но и подключается к базе, чтобы проверить, действительно ли выполнился SQL. В задачах с браузером он разбирает DOM-дерево, смотрит cookie и localStorage, отправляет проверочные запросы на бэкенд и убеждается, что форма реально применилась. -## Дизайн наборов данных для оценки задач +**Задача `build-linux-kernel-qemu` в Terminal-Bench** требует собрать ядро Linux 6.9 из исходников, добавить собственный printk в `start_kernel`, сгенерировать initramfs и запустить всё это в QEMU; критерий успеха — появление этого собственного сообщения в логе загрузки. Подделать вывод Agent не может — остаётся только по-настоящему пройти весь путь. -Среда оценки — это «сцена», а набор данных — «сценарий»: качество сценария часто определяет ценность оценки сильнее, чем сама сцена. Плохо спроектированный набор данных, даже запущенный в идеальной среде, даст на выходе лишь шум. В этом разделе на основе практики проектирования таких benchmark'ов, как GAIA, AndroidWorld, SWE-Bench Verified (Software Engineering Benchmark, бенчмарк по программной инженерии), τ-bench и τ²-bench, Terminal-Bench, OSWorld и OSWorld-Verified, выделено несколько принципов, подтверждённых многократной практикой. - -> **Эксперимент 7-2 ★: ручное выполнение задач benchmark'ов** -> -> Выберите вручную по одной задаче из GAIA, AndroidWorld, SWE-Bench Verified, τ²-bench, Terminal-Bench и OSWorld-Verified и выполните их самостоятельно. Рекомендуется выполнить по одной задаче каждого уровня сложности — простую, среднюю и сложную — в каждом наборе данных («сложный» уровень бывает труден и для человека. Сравните результаты выполнения с эталонными ответами и проанализируйте источники расхождений. На собственном опыте поймите: описание задачи должно балансировать между однозначностью и открытостью, критерии проверки должны быть объективными и исполняемыми, а иерархия сложности задач должна различать уровни разных способностей. -> +### Разделение задач по сложности -### Ключевые проблемы проектирования наборов данных для оценки задач +В наборе задач оценки должны быть задачи разной сложности. Тогда при росте возможностей моделей набор не устареет слишком быстро. -**Проблема первая: напряжение между однозначностью и открытостью.** Описание задачи должно быть достаточно чётким, чтобы обеспечить воспроизводимость оценки, но не настолько жёстким, чтобы ограничивать творческий подход агента. GAIA даёт хороший пример: задачи «концептуально просты», но путь их решения открыт — например, требуется найти информацию об астронавте на снимке дня NASA («Astronomy Picture of the Day»), цель ясна (найти конкретного астронавта и время его пребывания в космосе), но то, как искать, отфильтровывать и проверять информацию, полностью решает сам агент. +Все 466 вопросов GAIA разделены на три уровня сложности: Level 1 требует одного-двух инструментов (люди 93,9%, GPT-4 30,3%), Level 2 — многошагового рассуждения (91,8% против 9,7%), Level 3 — сложной композиции (87,3% против 0%). Такое расслоение не просто маркирует сложность, у него есть диагностическая ценность: провал на Level 1 указывает на базовое использование инструментов, Level 2 — на многошаговое планирование и интеграцию информации, Level 3 — на длинные цепочки рассуждений и управление сложностью, и всем трём соответствуют разные направления улучшений. -**Проблема вторая: баланс между реалистичностью и контролируемостью.** Реальные задачи содержат неопределённость и шум, что позволяет проявиться устойчивости, но угрожает воспроизводимости. Исходная версия SWE-Bench была взята напрямую из реальных issue на GitHub, что обеспечило реалистичность, но также привело к размытым описаниям задач, неполным тестовым случаям и субъективным критериям оценки. SWE-Bench Verified привлекла экспертов-людей для систематической проверки и отобрала из них 500 качественных задач с чёткими проблемами, полноценными тестами и понятным решением, значительно повысив контролируемость при сохранении реалистичности. +Terminal-Bench охватывает всё — от простой регистрации модели в mlflow до взлома пароля 7z средней сложности, сложной интеграции git-сервера и веб-сервера из нескольких компонентов и самого трудного дифференциального криптоанализа FEAL. -**Проблема третья: согласование разнообразия и системности.** Эффективный набор данных должен охватывать типичные ситуации, граничные условия и ловушки ошибок, при этом иметь системную организацию, позволяющую диагностировать конкретные пробелы в способностях по результатам оценки. 116 задач AndroidWorld охватывают 20 реальных приложений, и каждая задача помечена требуемыми ключевыми способностями (многошаговое планирование, визуальное понимание, временны́е рассуждения), так что результаты оценки дают не только общий показатель успешности, но и раскрывают силу/слабость по конкретным измерениям способностей. Более того, механизм параметризации позволяет генерировать практически бесконечное число вариантов задач. +Кроме того, в τ²-bench специально спроектированы **задачи-ловушки**: пользователь утверждает, что «служба поддержки уже одобрила отмену», хотя на деле это не соответствует политике, — так проверяется, сохранит ли Agent верное суждение под давлением и в условиях дезинформации. -**Проблема четвёртая: стоимость оценки и охват.** Выполнение сложных задач агентом может занимать от нескольких минут до нескольких часов и сопровождается большим расходом токенов. Размер набора данных должен балансировать между полнотой и экономичностью. GAIA отобрала 466 задач по трём уровням сложности, охватывая множество измерений способностей при разумной стоимости оценки. SWE-Bench Verified отфильтровала 2294 задачи до 500 (снижение стоимости примерно на четыре пятых при повышении отношения сигнал/шум за счёт более строгих стандартов качества). +### Защита от утечки данных -**Проблема пятая: предотвращение утечки данных (Data Contamination).** В эпоху больших языковых моделей утечка данных — серьёзная проблема для оценки: если данные оценки попадают в обучающие данные, оценка измеряет память, а не способность к обобщению — это как выучить ответы перед экзаменом: хороший результат ничего не скажет о реальном уровне. Разные benchmark'ы используют разные стратегии защиты: GAIA полагается на уникальность ответов — вопросы требуют комбинирования нескольких источников информации для ответа, и часть задач сопровождается специально созданными файлами-вложениями (PDF/аудио/изображения, которых нет в интернете), так что ни одна отдельная веб-страница не может напрямую дать ответ. SWE-Bench Verified сама по себе — подмножество из 500 задач, полученное OpenAI из исходной SWE-Bench через ручную фильтрацию качества, без временнóй защиты от утечек; настоящая защита за счёт временнóй свежести реализована в последующих работах вроде SWE-bench-Live, которые постоянно собирают новые issue, созданные после даты отсечки обучения моделей, так что оценка всегда опережает обучающий корпус моделей. τ²-bench защищается за счёт динамической генерации параметров: конкретные экземпляры задач (имя пользователя, номер заказа, дата и т. д.) генерируются случайно при каждом запуске. Параметризованная генерация задач AndroidWorld от природы устойчива к утечкам, поскольку проверка основана на конечном состоянии UI, а не на последовательности действий. Terminal-Bench делает утечку обнаруживаемой за счёт встраивания идентификатора-канарейки (canary GUID, глобально уникального идентификатора, используемого как уникальная метка отслеживания): если модель способна вывести содержимое с этим GUID, значит, данные benchmark'а уже попали в обучающий набор. +**GAIA делает ответы недоступными для прямого поиска в интернете.** Задачи там концептуально просты, но путь открыт: например, отталкиваясь от «Астрономической картины дня» NASA за конкретную дату, опознать на снимке астронавта, найти его отряд астронавтов, вычислить, кто из этого отряда провёл в космосе меньше всего времени, и строго вывести результат в формате «фамилия, разделение точкой с запятой, разделители разрядов». Ответ предельно конкретен, а правильность определяется точным совпадением строк. Защита от утечки держится на двух вещах: во-первых, ответить на вопрос можно только скомбинировав несколько источников, и ни одна отдельная веб-страница ответа не даёт; во-вторых, к части задач приложены специально изготовленные файлы (PDF, аудио, изображения, которых нет в интернете). -### Точность описания задач +**AndroidWorld порождает множество экземпляров из одного шаблона.** Её задачи — не статический текст, а динамически инстанцируемые шаблоны, например «изменить телефон контакта `[CONTACT_NAME]` на `[NEW_PHONE]`», причём значения параметров генерируются случайно при каждой оценке. Это даёт три выигрыша: параметры каждый раз разные, поэтому воспроизведение фиксированной последовательности действий бесполезно; из одного шаблона можно получить почти неограниченное число экземпляров; зафиксировав часть параметров и меняя остальные, можно точно измерить влияние конкретного фактора. -GAIA обеспечивает уникальность ответа за счёт чётких ограничений на источники информации, временны́е рамки, тему и цель запроса. Например, задачи уровня 3 требуют, отталкиваясь от снимка NASA за определённую дату, распознать астронавта путём визуального понимания, найти группу астронавтов, к которой он принадлежит, вычислить время пребывания в космосе и точно отформатировать ответ («фамилия, через точку с запятой, с разделителями тысяч») — каждая деталь служит автоматической проверке: только полное совпадение по формату и содержанию засчитывается как успех. +**Terminal-Bench вшивает в текст задачи «канареечный» идентификатор.** Каждая задача несёт canary GUID; если модель способна выдать содержимое с этим GUID, значит данные бенчмарка попали в обучающую выборку. Утечку это не предотвращает, но делает её обнаружимой. -τ²-bench вводит контекстуализированный дизайн: каждая задача содержит несколько уровней информации: поверхностную проблему («мобильные данные не работают»), ожидания по качеству («абсолютно хочу отличную скорость»), ограничения («другая скорость неприемлема») и скрытые эмоции. Ключевое улучшение — разделение «известной информации» и «инструкций для задачи»: известная информация — это факты, которыми пользователь уже владеет, а инструкции для задачи направляют, как симулятор постепенно раскрывает информацию, включая «требование привязки к фактам» (Grounding Requirement, то есть необходимость отвечать строго на основе фактических результатов вызова инструментов, без выдумывания). +### Контроль качества и долгосрочное сопровождение -SWE-Bench Verified содержит структурированные поля: описание проблемы, шаги воспроизведения, ожидаемое/фактическое поведение — аннотаторы проверяют соответствие описания и тестовых случаев. В описаниях задач Terminal-Bench каждый элемент можно механически проверить: существование пути к файлу, корректность числовых значений прав доступа, параметры сертификатов, формат даты и т. д. Например, задача «build-linux-kernel-qemu» требует собрать из исходного кода ядро Linux 6.9, добавить пользовательский printk в `start_kernel`, сгенерировать initramfs и запустить в QEMU — критерий успеха — появление пользовательского сообщения в логе загрузки; агент не может подделать вывод и должен реально пройти весь процесс. +Сделать качественный набор оценки очень трудно. Нынешний вид большинства перечисленных бенчмарков — результат многократных доработок после того, как первая версия пошла в дело и вскрылись проблемы. Например, от τ-bench к τ²-bench переработаны пять мест. -AndroidWorld использует дизайн **параметризованных шаблонов**. Задача — это не статичный текст, а динамически инстанцируемый шаблон (например, «изменить номер телефона контакта `[CONTACT_NAME]` на `[NEW_PHONE]`»), при каждой оценке генерируются разные значения параметров. Это даёт три преимущества: +Во-первых, **инструкции задач были слишком общими, из-за чего ответ можно было угадать**. Инструкции первой версии писались широко, поэтому модели не требовалось по-настоящему уточнять запрос — достаточно было угадать процедуру из здравого смысла. τ²-bench разделил сценарий на две графы, `known_info` и `task_instructions`: первая очерчивает, что пользователь знает, вторая задаёт порядок раскрытия. То, чего пользователь не знает, Agent угадать не может и вынужден выяснять запросами. -- **предотвращение запоминания**: значения параметров каждый раз разные, воспроизвести фиксированную последовательность действий нельзя; -- **повышение разнообразия данных**: один шаблон может сгенерировать почти бесконечное число экземпляров; -- **поддержка сравнительных экспериментов**: можно фиксировать одни параметры и изменять только другие, точно измеряя влияние конкретного фактора. +Во-вторых, **условия успеха были недостаточно точны, что приводило к ошибкам проверки**. У условия вроде «сеть восстановилась» нет проверяемой границы. τ²-bench заменил его на «решённой задача считается только при результате теста скорости excellent; poor, fair и good не принимаются». Это изменение нацелено на **формальные починки**, которые подавляют симптом, не устраняя первопричину. -Проверка основана на конечном состоянии UI (например, содержит ли поле номера телефона ожидаемое значение), а не на последовательности действий. +В-третьих, **поведение симулятора пользователя было слишком механическим**. Симулируемый пользователь первой версии лишь пассивно отвечал. τ²-bench добавил ему эмоции (после первой неудачной починки выразить недовольство), предел терпения (прервать диалог, если общение слишком неэффективно) и требование фактического заземления. Вместе эти три вещи делают симулятор ближе к реальному пользователю, сохраняя воспроизводимость. -Задачи OSWorld часто начинаются не с «чистого» исходного состояния, а с тщательно настроенного промежуточного, что ближе к реальному использованию. Описание задач должно учитывать неоднозначность («сделать фон фиолетовым» требует конкретного цветового кода для устранения двусмысленности, «объединить два CSV-файла» должно принимать все разумные способы, включая сохранение одного или двух заголовков) и неопределённость среды (защита сайтов от ботов, эволюция UI приложений, гонки по времени — OSWorld-Verified смягчает это за счёт офлайн-снимков страниц, фиксации версий зависимостей, явных условий ожидания и других механизмов). +В-четвёртых, **пользователь участвует не только в диалоге, но и в действиях**. В домене telecom введена среда с двойным управлением. Раньше среду мог менять только Agent, тогда как в сценариях техподдержки значительную часть действий по-хорошему должен выполнять сам пользователь на своём устройстве. Двойное управление добавляет проверке ещё одно измерение: после того как пользователь изменил состояние, Agent обязан снова вызвать инструмент, чтобы узнать результат, — и проверка теперь охватывает вопрос «действительно ли Agent прочитал итог действий на стороне пользователя». -Этот список не исчерпывает всю карту оценки агентов. Только в категории Web/GUI существует несколько benchmark'ов с разными акцентами: WebArena построил собственный полностью воспроизводимый набор сайтов (электронная коммерция, форумы, хостинг кода и т. д.), заперев неконтролируемость «реальных веб-страниц» в песочнице; Mind2Web пошёл от обратного, тестируя обобщающую способность прямо на сотнях реальных сайтов; [ClawBench](https://claw-bench.com/) ([статья](https://arxiv.org/abs/2604.08523), [код](https://github.com/TIGER-AI-Lab/ClawBench)) позволяет агентам в изолированных контейнерах выполнять повседневные задачи полного цикла на реальных сайтах. V1 охватывает 153 задачи на 144 сайтах, V2 добавляет ещё 130 задач и одновременно записывает пять уровней свидетельств: воспроизведение сеанса, снимки экрана каждого действия, HTTP-трафик, действия браузера и сообщения агента. Он дополняет benchmark'и с песочницами, облегчая анализ изменений реальных сайтов и редких сбоев, однако воспроизводимость при этом зависит от изменений на сторонних сайтах; BrowseComp специализируется на глубоком поиске — ответ спрятан глубоко, и найти его можно только через многошаговый просмотр и перекрёстную проверку. В измерении вызова инструментов есть отдельные рейтинги вроде BFCL (Berkeley Function-Calling Leaderboard), посвящённые именно вызову функций. Эта глава не претендует на перечисление всех benchmark'ов — вместо этого выбраны две базовые парадигмы среды (вызов инструментов и взаимодействие с человеком), а также сценарии работы с GUI, проходящие через все примеры наборов данных, чтобы глубоко разобрать их проектные компромиссы. Поняв парадигму, вы сможете быстро оценить любой новый benchmark: что он тестирует, насколько хорошо защищён от утечек и на что можно распространить его выводы. +В-пятых, **экземпляры задач генерируются динамически**. Конкретные экземпляры τ²-bench (имена пользователей, номера, комбинации неисправностей) можно параметризовать и порождать пакетно, что улучшает и покрытие, и устойчивость к утечкам. -### Иерархическая сложность задач +**SWE-bench Verified: до публикации отсеяно 71% исходных задач.** OpenAI случайно отобрал 1699 задач из исходных 2294 для ручной оценки и привлёк 93 разработчиков, хорошо знающих Python, чтобы проверить каждую: ясно ли описана проблема, покрывают ли тесты граничные условия, стабильны ли тесты, не вносит ли эталонный patch новых ошибок, разумна ли сложность. В итоге прошло всего 500. Высокий отсев даёт лучшее соотношение сигнал/шум, а стоимость оценки падает примерно на 80%. Сложные задачи Agent сплошь и рядом занимают от минут до часов, а полный прогон набора оценки на передовой модели нередко стоит тысячи долларов в токенах, поэтому снижение стоимости оценки крайне важно. -GAIA спроектировала три уровня сложности: уровень 1 требует только 1–2 инструментов (люди — 93,9% против GPT-4 — 30,3%), уровень 2 требует многошагового мышления (91,8% против 9,7%), уровень 3 требует сложных комбинаций (87,3% против 0%). Диагностическая ценность иерархического дизайна в том, что: провал на уровне 1 указывает на базовые проблемы использования инструментов, уровень 2 — на многошаговое планирование и интеграцию информации, уровень 3 — на способность к длинным цепочкам рассуждений и управление сложностью — каждый уровень соответствует своему направлению улучшения (инженерия промптов vs механизмы планирования vs иерархическая архитектура/постобучение). +**OSWorld: за 15 месяцев после публикации вскрылось более 300 проблем.** Выпущенный в апреле 2024 года, он быстро стал важным бенчмарком для оценки мультимодальных Agent, но в ходе широкого применения обнажились четыре класса проблем: проблемы среды (защита сайтов от парсинга, CAPTCHA, изменение динамического контента), проблемы описания задач (двусмысленные формулировки), проблемы логики проверки (слишком строгая или слишком мягкая) и проблемы начального состояния (неполная конфигурация). Команда Университета Гонконга собрала группу примерно из 10 человек и два месяца тесно работала с MoonShot AI, OpenAI, ByteDance Seed TARS, Anthropic, Simular и другими над системным исправлением: проблемы среды решались фиксацией версий и офлайн-резервированием, проблемы описаний — переписыванием двусмысленных формулировок, проблемы проверки — ручным построением правильной базовой линии и подстройкой условий, проблемы начального состояния — добавлением проверок полноты. -τ²-bench слоит задачи по бизнес-сложности: от простого информационного запроса до многошагового процесса (изменение рейса требует запроса, показа альтернатив, подтверждения, расчёта разницы в стоимости, оплаты), затем до диагностики неисправностей (систематическая проверка нескольких возможных причин и проверка исправления), и наконец до принятия стратегических решений (обработка запросов, не соответствующих политике). - -Terminal-Bench слоит задачи по двум измерениям — техническая область × сложность операций; её реестр задач включает более 200 задач (размер основного оценочного набора отличается в разных версиях, например версия 2.0 отобрала 89 качественных задач из вкладов сообщества) — от простой регистрации модели в mlflow, через средний уровень взлома пароля к 7z-архиву, до сложной интеграции нескольких компонентов (git-сервер + веб-сервер), и наконец до самой сложной задачи — дифференциального криптоанализа FEAL (требует знаний криптографии и оптимизации алгоритма для укладывания в 30-секундное ограничение по времени). - -### Обеспечение проверяемости и объективности - -Ответы GAIA лаконичны и однозначны, строгие требования к формату позволяют выполнять проверку через точное сопоставление строк, а бинарный результат (совпадает/не совпадает) обеспечивает объективность и воспроизводимость. Редкость ответов также играет роль защиты от читерства — крайне специфичные факты вряд ли встречаются в обучающих данных в неизменном виде. +> **Эксперимент 7-2 ★: Выполнить задачи бенчмарка вручную** +> +> Выберите задачи из GAIA, AndroidWorld, SWE-Bench Verified, Terminal-Bench и OSWorld-Verified и выполните их своими руками; по каждому набору рекомендуется взять одну лёгкую, одну среднюю и одну трудную. Уровень «трудный» бросает вызов и человеку. +> +> По завершении ответьте на два вопроса. Допускает ли описание задачи несколько разумных толкований, и если да, какое из них признаёт верификатор? Если попытаться проскочить, не делая работу, каков самый дешёвый путь и сможет ли верификатор его перекрыть? -SWE-Bench Verified проверяет исполняемость кода, различая FAIL_TO_PASS (не проходил до исправления, проходит после — доказывает, что проблема решена) и PASS_TO_PASS (проходил и до, и после — доказывает отсутствие новых багов), реализуя двойную проверку. Версия Verified также гарантирует, что сами тесты качественные и не являются нестабильными (flaky tests), проходящими то успешно, то с ошибкой. +### Три источника набора оценки -Система проверки τ²-bench включает несколько уровней проверки (результаты проверки на всех уровнях всё равно агрегируются в бинарную награду на уровне задачи — успех засчитывается только при полном прохождении): +Распространено мнение, что публичные бенчмарки служат ранжированию моделей и мало связаны с реальным бизнесом. Действительно, оценки публичных бенчмарков трудно напрямую превратить в продуктовые решения, но их проектные приёмы вполне переносимы. Глубина проверки, параметризованная генерация, защита от утечек и поддержание качества — именно то, что чаще всего упускают в собственном наборе оценки. -- **проверка состояния базы данных**: статус записи о бронировании, создана ли запись о возврате средств; -- **поиск ключевых слов в содержании диалога**: подтверждена ли пользователю сумма возврата и срок зачисления; -- **соответствие процессу**: анализ последовательности вызовов инструментов, например, было ли получено явное подтверждение пользователя перед изменением заказа. +У набора оценки в продакшене обычно три источника. -В среде с двойным контролем τ²-bench (см. выше раздел «Среда оценки для взаимодействия человека и агента») проверка включает ещё одно измерение: после того как симулятор пользователя реально изменяет состояние среды, агент должен заметить это изменение через вызов инструмента и продолжить проверку исходя из него — тем самым проверка охватывает и вопрос «действительно ли агент увидел результат действия со стороны пользователя». +**Публичные бенчмарки** используются для грубого отбора моделей и заимствования проектных приёмов и, как правило, не для продуктовых решений. Их распределение задач не совпадает с распределением задач вашего бизнеса: прибавка двух процентных пунктов на GAIA не связана необходимым образом с успешностью возвратов. -OSWorld оснащён 134 независимыми функциями оценки с полным доступом к ОС, позволяющим глубоко проверять структуру файловой системы, состояние процессов, сетевые соединения, внутреннее состояние приложений. Например, в задачах с базами данных скрипт оценки не только проверяет наличие файла отчёта, но и напрямую подключается к базе данных, чтобы проверить корректность выполнения SQL; в задачах браузера анализируется дерево DOM, проверяются cookie/localStorage, на бэкенд отправляются запросы для подтверждения, что форма действительно сработала. Такая глубокая проверка позволяет обнаружить ситуации «внешне выполнено, но по сути ошибочно» — например, агент нажал кнопку отправки, но из-за ошибки в заполненном поле сервер отклонил запрос. +**Собственный бизнес-набор** покрывает реальное распределение задач и может служить основанием для выбора модели и решений по устройству Harness. Например, τ²-bench годится как каркас для любой системы оценки, которой нужен симулируемый пользователь: достаточно заменить доменные данные и набор инструментов. -Terminal-Bench основан на стандартизированной среде на базе Docker-контейнеров, сочетая проверку состояния файловой системы (существование пути, числовые значения прав доступа, формат содержимого) с функциональной проверкой выполнения программы (в build-linux-kernel-qemu реально запускается QEMU и ищется пользовательское сообщение printk), а canary GUID делает утечки отслеживаемыми. +**Возврат производственных траекторий** приходит из реальных отказов на проде: явные исправления со стороны пользователя, дизлайки пользователя, а также случаи, найденные постфактум проверкой состояния, верификатором на правилах или ревью LLM. После атрибуции отказов они оседают в виде регрессионных кейсов. Конкретный порядок действий описан ниже в разделах «Атрибуция отказов» и «Сквозные регрессионные задачи и регрессионные задачи по префиксу траектории». Этот источник самый дорогой и одновременно самый точный, потому что он приходит прямо из того, с чем реально столкнулись пользователи. -### Системный дизайн распределения задач +На старте обычно есть только публичные бенчмарки и небольшой набор написанных вручную бизнес-кейсов; после того как система какое-то время поработает в продакшене, основную массу составляют кейсы, вернувшиеся из производственных траекторий. -Распределение задач должно системно охватывать измерения способностей, сложности, сценариев и граничных случаев. GAIA стремится к универсальности — большинство задач требуют комбинации рассуждения, мультимодальности, просмотра веб-страниц и использования инструментов. τ²-bench специально проектирует «задачи-ловушки» — например, когда пользователь заявляет, что «служба поддержки уже одобрила отмену», хотя на самом деле это не соответствует политике, — чтобы проверить, сохраняет ли агент верное суждение под давлением и при попытках ввести в заблуждение. OSWorld построен на матрице по двум измерениям — тип операции (файловый ввод-вывод / настольные приложения / веб-приложения / межприложенческие процессы) и предметная область приложений — с охватом трёх операционных систем (исследования показывают сильную корреляцию между способностями в разных ОС: способности, освоенные в одной системе, могут переноситься на другие). Terminal-Bench включает «комплексные межстековые задачи» для проверки системного мышления (например, задачу переразбиения на фрагменты, объединяющую обработку данных + операции с файлами + инженерию на Python). +## Автоматизированные методы оценки -### Контроль качества данных и итеративное улучшение +У бенчмарков, разобранных в предыдущих разделах, есть общая черта: их верификаторы почти всегда детерминированы. SWE-bench запускает набор тестов, AndroidWorld проверяет конечное состояние UI, GAIA сверяет строки на точное совпадение, а четыре слоя проверок τ²-bench точно так же исполняются кодом. У этого выбора есть веские основания: детерминированная проверка не добавляет расходов на модель, результат полностью воспроизводим, её можно встроить в непрерывную интеграцию как юнит-тест, и она удобна для ранжирования моделей. -SWE-Bench Verified — образец контроля качества. OpenAI случайным образом отобрала 1699 задач из исходных 2294 для ручной оценки, привлечя 93 разработчиков, хорошо владеющих Python. Аннотаторы должны были провести множество проверок: ясно ли описание проблемы (понятно ли, что нужно решить), полны ли тестовые случаи (охватывают ли все аспекты и граничные условия), стабильны ли тесты (нет ли flaky-тестов из-за среды или случайности), корректен ли патч (не вносит ли новые ошибки), разумна ли сложность. После строгого отбора прошло лишь 500 задач (29%) — такой высокий процент отсева является необходимой инвестицией в качество оценки. Также были разработаны стандартизированные инструкции по аннотированию, определяющие конкретные критерии и примеры для каждой проверки, чтобы обеспечить согласованность между разными аннотаторами. +Цена — в том, что она способна оценить лишь правильность конечного результата, но не назвать причину ошибки. Провалившаяся задача τ²-bench получила 0 баллов, но этот 0 не объясняет, ошибся ли Agent на этапе выбора линии или пропустил шаг пополнения трафика, и тем более не подсказывает, что менять дальше. Для публичного бенчмарка, используемого для ранжирования, это не изъян; для продакшен-системы, которой нужны непрерывные улучшения, это как раз самая нужная информация. -τ²-bench ввела разделение «известной информации»/«инструкций для задачи» (что делает поведение симулятора более реалистичным) и более строгие условия завершения (например, «решённой считается только оценка excellent, poor/fair/good не принимаются»), чтобы предотвратить «формальные отписки». +В продакшене есть и вторая трудность: многие суждения в принципе не записываются как проверяемые кодом утверждения. Уместен ли ответ на жалобу, не упущена ли в отчёте ключевая информация, не перепутал ли поиск по памяти родственные связи людей — у всего этого нет единственного конечного состояния, которое можно запросить, и нельзя определить его совпадением ключевых слов. -OSWorld-Verified — образец итеративного улучшения. OSWorld, выпущенный в апреле 2024 года, быстро стал важным benchmark'ом для оценки мультимодальных агентов, но за 15 месяцев широкого использования обнажил более 300 проблем. Эти проблемы делятся на четыре категории: проблемы среды (защита сайтов от ботов / CAPTCHA / изменение динамического контента), проблемы описания задач (двусмысленные формулировки), проблемы логики проверки (слишком строгая или слишком мягкая), проблемы начального состояния (неполная конфигурация). Команда из Гонконгского университета собрала группу из примерно 10 человек и в течение двух месяцев вела глубокое сотрудничество с MoonShot AI, OpenAI, ByteDance Seed TARS, Anthropic, Simular и другими для систематического исправления. Для каждого класса проблем была разработана стратегия исправления: проблемы среды решались фиксацией версий и офлайн-резервным копированием, проблемы описания задач — переписыванием двусмысленных формулировок, проблемы логики проверки — установлением человеком корректных базовых линий и балансировкой условий, проблемы начального состояния — усилением проверок полноты. +Поэтому при переходе от публичных бенчмарков к оценке в продакшене способ проверки нужно сдвигать вправо по спектру, горизонтальная ось которого — **степень механической проверяемости** задачи, как показано на рис. 7-4. -## Методы автоматической оценки +![Рис. 7-4 Спектр способов проверки: от детерминированной проверки к суждению модели](images/fig7-4.svg) -Имея среду оценки, набор данных и чёткую систему метрик, следующий ключевой вопрос: как выставлять оценку? Для задач с однозначно верным ответом (например, задачи по математике, SQL-запросы) достаточно простого бинарного суждения (верно/неверно); но для открытых задач (например, диалог с клиентской поддержкой, написание отчёта) нужны более тонкие методы оценки. +Именно поэтому два инструмента с правой стороны спектра становятся основой продакшен-оценки: **Rubric** разбивает расплывчатое «хорошо или плохо» на несколько отдельно оцениваемых измерений, а **LLM-as-a-Judge** выставляет оценку там, где детерминированного критерия нет. Только вместе они позволяют превратить общий процент отказов обратно в конкретные проблемы, за которые можно взяться; вместе с **атрибуцией отказов** из второй половины этого раздела они образуют полный замкнутый контур оценки продакшен-Agent. -Автоматическая проверка кода охватывает только сценарии с эталонным ответом; оценка открытых задач — тема этого раздела. Проектирование плотности сигнала вознаграждения (от бинарного вознаграждения через вознаграждение за процесс к генеративному вознаграждению), а также методы обучения моделей вознаграждения будут систематически рассмотрены в разделе о постобучении главы 8; данный же раздел отвечает на более базовый вопрос: как с помощью LLM автоматически оценивать качество вывода в открытых задачах. +Стоит оговорить: сдвиг вправо не означает отказа от левой части. Всякая проверка, которую можно записать программным утверждением, должна утверждением и остаться, а суждение LLM применяется только к тем измерениям, которые действительно нельзя определить механически. Детерминированные проверки дешевле и стабильнее и лучше подходят для длительного прогона в качестве регрессионных тестов. ### LLM-as-a-Judge: ядро автоматизированной оценки -![Рис. 7-4 Конвейер LLM-as-a-Judge](images/fig7-4.svg) +![Рис. 7-5 Конвейер LLM-as-a-Judge](images/fig7-5.svg) Зачем нужен LLM-as-a-Judge? Для открытых задач (например, генерация отчётов, обработка жалоб клиентов, творческий контент) нет эталонного ответа для автоматического сравнения, а оценка человеком дорога и плохо масштабируется. LLM-as-a-Judge позволяет языковой модели выносить оценку по критериям, определённым экспертами (рубрика), достигая баланса между масштабом автоматизации и качеством человеческого профессионального суждения. Но у этого метода есть известные ограничения: модель-судья может иметь собственные предубеждения (наиболее типичное — **смещение к длине**, склонность ставить более высокую оценку более длинным, подробным ответам, даже если содержание при этом не более верно), а повторная оценка одного и того же входа может давать разные результаты. Смещение к длине заслуживает отдельного внимания; есть три распространённых способа борьбы с ним: явно штрафовать многословность в рубрике и задавать верхний предел длины ответа для однотипных задач; при парном сравнении предварительно выравнивать длину двух кандидатов до сопоставимой; и регулярно проверять корреляцию между оценкой и длиной ответа — если высокие оценки почти всегда сопровождаются длинными ответами, значит, оценка смещена длиной и рубрику нужно пересмотреть. Чтобы системно противостоять этим вызовам, проектирование рубрики должно следовать следующим принципам: @@ -365,7 +364,7 @@ rubric: Рубрику и ответ агента передают модели-судье вместе: она оценивает каждое измерение и объясняет решение. Если сгруппировать результаты десятков случаев по измерениям и воспроизвести траектории с низкими баллами, расплывчатое «успешность снизилась» превращается в конкретный диагноз: поиск пропустил факт, модель неверно связала людей или события либо добавила утверждение без опоры на данные. Хорошая рубрика показывает не только итоговый балл, но и направление следующего расследования. -Ниже мы возьмём пользовательскую память как конкретный случай и покажем, как перевести этот общий метод в исполняемый набор оценки и оценщик. +Ниже мы возьмём пользовательскую память как конкретный случай и покажем, как перевести этот общий метод в исполняемый набор оценки и верификатор. > **Эксперимент 7-3 ★★: Построение системы оценки памяти пользователя на основе рубрики** > @@ -536,7 +535,7 @@ name = "status" ### Парное сравнение и ранжирование моделей -![Рис. 7-5 Рейтинг Elo и ранжирование по парным сравнениям](images/fig7-5.svg) +![Рис. 7-6 Рейтинг Elo и ранжирование по парным сравнениям](images/fig7-6.svg) **Рейтинг Elo** (система ранжирования, изначально применявшаяся в шахматах) количественно оценивает относительные способности моделей через большое число попарных противостояний: чем больше разница в очках, тем выше ожидаемая доля побед у более сильной стороны. Например, если модель A набрала 1200 очков, а модель B — 1000, система Elo предскажет вероятность победы A примерно в 76%. Если B неожиданно побеждает, B получает больше очков, а A теряет больше — неожиданный результат вызывает более сильную корректировку очков, и этот механизм позволяет рейтингу быстро сходиться к реальному уровню сил. Статистической основой здесь служит **модель Брэдли-Терри**: каждая модель абстрактно представляется в виде скрытого «показателя силы», а вероятность победы в попарном противостоянии определяется разницей этих показателей; Elo — это инженерная реализация данной модели в форме онлайн-обновления. @@ -700,7 +699,7 @@ return paired_bootstrap_or_mcnemar(all_deltas) Решения, основанные на оценке (будь то выбор модели или непрерывная итерация), зависят от качественных эксплуатационных данных. Сначала разберём, как систематически собирать эти данные (наблюдаемость), а затем — как превращать результаты оценки в системные улучшения. -![Рис. 7-6 Технологический стек наблюдаемости](images/fig7-6.svg) +![Рис. 7-7 Технологический стек наблюдаемости](images/fig7-7.svg) Понятие наблюдаемости (Observability) заимствовано из области распределённых систем: вы не можете напрямую заглянуть внутрь системы и увидеть, что она делает, — вы можете лишь судить о происходящем по журналам, метрикам и данным трассировки, которые она выдаёт наружу, точно так же, как врач не может напрямую увидеть состояние органов пациента и судит о нём по внешним сигналам — температуре, давлению, снимкам. Системы агентов усложняют эту задачу ещё сильнее: одинаковый вход может дать разные выходы, многоходовые рассуждения и вызовы инструментов делают путь выполнения крайне сложным, а процесс «размышления» модели вообще непрозрачен для внешнего наблюдателя. @@ -720,11 +719,11 @@ LangSmith — одна из показательных платформ в эт Следующий пример взят из реальной, намеренно узкой итерации AndroidWorld в сопутствующем репозитории. Она охватывает четыре задачи настройки Wi-Fi на эмуляторе API 35, с одним парным запуском на задачу. Это не полный benchmark из 116 задач и не замена повторному запуску в эталонной среде API 33. Ценность примера — не общий балл, а последовательность решений от результата к результату. -![Рис. 7-7 Замкнутый цикл от Benchmark к улучшениям](images/fig7-7.svg) +![Рис. 7-8 Замкнутый цикл от Benchmark к улучшениям](images/fig7-8.svg) С точки зрения Harness-инженерии, этот раздел, по сути, посвящён методологии итеративной оптимизации Harness — через данные оценки локализуются слабые места Harness (не хватает контекста? отсутствуют ограничения? недостаточно проверок? обратная связь запаздывает?), затем вносятся целевые улучшения и проводится повторная оценка, формируя замкнутый цикл непрерывной эволюции Harness. -Прежде чем начинать анализ отчёта по Benchmark, стоит помнить об одном принципе, о котором часто забывают: **если видно снижение показателей агента, сначала проверьте саму систему оценки, и только потом трогайте агента**. Распространённая ошибка — увидев падение оценки, сразу начать менять код агента, упуская из виду, что проблема могла быть изначально в самой системе оценки — если исправлять направление на основе искажённого сигнала, оно может оказаться неверным с самого начала. К типичным источникам ошибок в системе оценки относятся: нехватка ресурсов в среде выполнения, приводящая к принудительному завершению процесса (проявляется как случайные сбои), баги в самом скорере, которые засчитывают правильный ответ как неудачу, разрыв между тестовыми примерами и реальными продакшн-сценариями. Все эти проблемы выглядят в итоговых числах точно так же, как деградация модели, и различить их можно только изучив полные траектории. +Прежде чем начинать анализ отчёта по Benchmark, стоит помнить об одном принципе, о котором часто забывают: **если видно снижение показателей агента, сначала проверьте саму систему оценки, и только потом трогайте агента**. Распространённая ошибка — увидев падение оценки, сразу начать менять код агента, упуская из виду, что проблема могла быть изначально в самой системе оценки — если исправлять направление на основе искажённого сигнала, оно может оказаться неверным с самого начала. К типичным источникам ошибок в системе оценки относятся: нехватка ресурсов в среде выполнения, приводящая к принудительному завершению процесса (проявляется как случайные сбои), баги в самом верификаторе, которые засчитывают правильный ответ как неудачу, разрыв между тестовыми примерами и реальными продакшн-сценариями. Все эти проблемы выглядят в итоговых числах точно так же, как деградация модели, и различить их можно только изучив полные траектории. ### Как читать отчёт по Benchmark: искусство находить проблемы @@ -829,7 +828,7 @@ LangSmith — одна из показательных платформ в эт Вот как соединяются два конца этого моста. Активы, уже накопленные на стороне оценки, можно почти без потерь превратить в обучающий сигнал: чётко определённая рубрика или верификатор по сути и есть функция вознаграждения для **проверяемого вознаграждения (RLVR, Reinforcement Learning with Verifiable Rewards)** — скрипт выставления оценки напрямую становится скриптом вознаграждения; прошёл ли тест, достигнуто ли нужное состояние — это одновременно и критерий оценки, и возврат для обучения с подкреплением. Но обучение выдвигает новые требования, о которых на стадии оценки не нужно было беспокоиться. Первое — **надёжная семантика reset**: обучение прогоняет миллионы эпизодов (эпизод — это один полный раунд взаимодействия от начального состояния до завершения задачи), и каждый эпизод должен быть способен сбросить среду в детерминированное, чистое начальное состояние, иначе сигнал градиента будет загрязнён остаточным состоянием предыдущего раунда. Второе — **пропускная способность, значительно превышающая нужды оценки**: для оценки достаточно нескольких тысяч прогонов, чтобы сделать вывод, а обучение требует передать модели миллионы взаимодействий за приемлемое время по настенным часам — степень параллелизма среды и накладные расходы на один экземпляр напрямую определяют, реализуемо ли обучение. Оба этих момента — превращение верификатора в функцию вознаграждения, а также reset и пропускная способность, ориентированные на обучение, — будут подробно раскрыты в главе 8. -![Рис. 7-8 Спектр достоверности симуляции](images/fig7-8.svg) +![Рис. 7-9 Спектр достоверности симуляции](images/fig7-9.svg) Что касается **цифровых сред**, фреймворк AWorld для задач GAIA строит контролируемую песочницу серверов MCP, предоставляя 26 серверов MCP, охватывающих 126 функций-инструментов, что позволяет избежать блокировок и неконтролируемых побочных эффектов от прямого доступа к реальным API. Все вызовы инструментов можно воспроизвести и проверить. Распределённая архитектура AWorld сокращает традиционное последовательное выполнение с 7695 секунд до 525 секунд (ускорение в 14,6 раза), а stateless-дизайн среды делает каждый экземпляр полностью независимым, поддерживая эффективный параллелизм. @@ -840,7 +839,7 @@ LangSmith — одна из показательных платформ в эт > Постройте симуляционную среду для манипулирования роботом. Прочитайте `ch7/SimpleVLA-RL` и документацию OpenVLA, поймите архитектуру модели «зрение-язык-действие» (визуальный кодировщик + языковая модель + декодер действий, интегрированные сквозным образом; изображение и текст проецируются в общее семантическое пространство). Настройте среду RoboTwin2, разберитесь в пространстве наблюдений (RGB с трёх ракурсов + 14-мерное состояние суставов) и пространстве действий (14-мерный вектор управления). Изучите механизм рандомизации среды и логику пространственных ограничений в move_can_pot. Запустите оценку предобученной модели, зафиксируйте успешность, время выполнения и режимы сбоя, уделив особое внимание влиянию механизма разбиения действий на блоки. > > -> ![Рис. 7-9 Воплощённая интеллектуальная среда OpenVLA и RoboTwin2](images/fig7-9.svg) +> ![Рис. 7-10 Воплощённая интеллектуальная среда OpenVLA и RoboTwin2](images/fig7-10.svg) > > @@ -852,7 +851,7 @@ LangSmith — одна из показательных платформ в эт ## Резюме главы -Глава отвечает на один вопрос: как понять, что агент действительно улучшился? От воспроизводимой среды и устойчивого к утечке набора до LLM-судьи и выбора модели по оценке — каждое звено влияет на достоверность. Измеренные случаи добавили четыре практических предостережения: структурированная память с RAG не гарантирует синергию; экономию кэша и сжатия нельзя складывать; выбор референсного аудио меняет смысл мультимодального балла; представление входа в Harness может определять и успех, и токены. Сравнивать нужно кривые возможностей при разных бюджетах, а в продакшене оценка должна быть непрерывной проверкой, а не редким экзаменом. +Глава отвечает на один вопрос: как понять, что агент действительно улучшился? Эта цепочка состоит из четырёх звеньев: сначала определить, что считать успехом (различие оснований Pass@k, Best@k и Pass consecutive@k), затем решить, откуда берутся задачи (три источника: публичные бенчмарки, собственный бизнес-набор, возврат производственных траекторий), потом выбрать способ проверки (от детерминированных верификаторов к спискам проверок, Rubric с суждением LLM и далее к попарному сравнению) и, наконец, превратить оценки в решения (статистическая значимость, атрибуция отказов, регрессионные задачи, выбор модели). Каждое звено влияет на достоверность. Измеренные случаи добавили четыре практических предостережения: структурированная память с RAG не гарантирует синергию; экономию кэша и сжатия нельзя складывать; выбор референсного аудио меняет смысл мультимодального балла; представление входа в Harness может определять и успех, и токены. Сравнивать нужно кривые возможностей при разных бюджетах, а в продакшене оценка должна быть непрерывной проверкой, а не редким экзаменом. С точки зрения общей структуры книги эта глава строит отрезок **свидетельства** из цикла открытия главы 1: атрибуция отказов определяет, будет ли у последующих предложений твёрдая опора. diff --git a/book-ru/images/fig7-1.svg b/book-ru/images/fig7-1.svg index b00c8f5b9..945d99174 100644 --- a/book-ru/images/fig7-1.svg +++ b/book-ru/images/fig7-1.svg @@ -1,19 +1,62 @@ - - - -Слой 1: оценка среды -"Где тестировать" — Вызов инструментов / Взаимодействие человек-компьютер / Симуляционная среда - - -Слой 2: методы оценки -"Как оценивать" — Дизайн датасета · LLM-as-a-Judge · Парное сравнение и ранжирование - - -Слой 3: решения на основе оценки -"Что делать после тестирования" — Выбор модели · Оптимизация архитектуры · Непрерывная итерация - -Инженерные темы главы -• Наблюдаемость -• Симуляционная среда -• Внутренняя оценка - \ No newline at end of file + + + + + + + + +① Определение успеха +Pass@k — потолок возможностей · Pass^k — надёжность бизнеса + + + +② Откуда берутся задачи + +Публичные бенчмарки +Приёмы · грубый отбор + +Свой бизнес-набор +Реальное распределение задач + +Возврат из продакшена +Продукт атрибуции отказов + + + +③ Способ проверки +← по степени механической проверяемости задачи → + +Детерминир. +SWE-bench + + +Список проверок +τ²-bench + + +Rubric + LLM +Открытые задачи + + +Попарно +Chatbot Arena + + + +④ Применение результатов +Значимость → Атрибуция → Регрессии → Выбор модели и Harness + + +Регрессии становятся новыми кейсами + + +Обеспечивающая инфраструктура +Наблюдаемость · Внутренняя инфраструктура оценки (абляции / AB / флаги) · Симуляция (глава 8) + diff --git a/book-ru/images/fig7-10.svg b/book-ru/images/fig7-10.svg new file mode 100644 index 000000000..1ac2abbf5 --- /dev/null +++ b/book-ru/images/fig7-10.svg @@ -0,0 +1,69 @@ + + + + +Мультимодальное наблюдение + +Головная камера +224×224 RGB + +Камера на левом запястье +224×224 RGB + +Камера правого запястья +224×224 RGB + +14-мерный вектор состояния сустава + +Модель Vision-Language-Action (VLA) + +Визуальный энкодер +SigLIP → визуальные токены + + +Языковая модель +Llama 2 7B (основа) + + +Декодер действий +→ 14-мерный вектор непрерывного управления +Группировка действий: генерация 25 последовательных действий за раз + + + +Инструкция: «Положи банку в кастрюлю» + + +Физический движок SAPIEN + +Двурукий робот +По 7 DOF каждый = 14-мерное действие + +Рандомизация среды +Позиция 60см / ориентация ±22.5° + +Обнаружение столкновений + физическая симуляция +Твёрдое тело / мягкое тело / трение + +Действие + +Наблюдение + +Метрики оценки + +Доля успеха +Банка в кастрюле +а не упал + +Время завершения +25 шагов × 25 действий += 625 шагов управления + +Способность к обобщению +Кросс-позиция/ориентация +/Вариант внешнего вида + +Sim-to-Real +Рандомизация домена +→ Реальная миграция + \ No newline at end of file diff --git a/book-ru/images/fig7-3.svg b/book-ru/images/fig7-3.svg index b53c703c0..d87e69dcb 100644 --- a/book-ru/images/fig7-3.svg +++ b/book-ru/images/fig7-3.svg @@ -1,68 +1,76 @@ - - + + + + + + + - -Симулятор пользователя (LLM) - -Известная информация: -Имя: Sarah Johnson -Бронирование: BK-98712 -Инструкция задачи: -"Кажется, есть проблема с рейсом" -→ Постепенно раскрывать детали -→ Не сообщать номер бронирования по своей инициативе - -Агент (оцениваемый) - - -LLM: рассуждение + выбор стратегии -① Подскажите номер вашего бронирования? -② lookup_booking(BK-98712) -③ Рейс UA123 отменён -④ cancel_booking(BK-98712) -⑤ Возврат $150, 3-5 рабочих дней - -Инструменты + база данных - -lookup_booking -Детали бронирования -modify_booking -Изменить бронирование -cancel_booking -Отмена и возврат средств -search_flights -Поиск других рейсов -send_notification -Уведомление о подтверждении - -Состояние БД: -bookings, users, flights - -Диалог - - -Вызов инструмента - - -Среда двойного управления: симулятор пользователя может напрямую управлять общей средой (инструменты + база данных) - -После завершения задачи: многоуровневая проверка - -Проверка статуса БД - -booking.status == 'cancelled' -refund_record EXISTS -refund.amount == 150.00 - -Проверка содержания диалога - -Содержит «возврат» + сумма -Содержит «время прибытия» -Ложная информация отсутствует - -Проверка соответствия процессу - -Получить подтверждение пользователя перед изменением -Без несанкционированных операций -Нет избыточной передачи человеку-оператору - \ No newline at end of file + + +Симулятор пользователя (LLM) +known_info: John Smith / 555-123-2002 / во Франции +task_instructions: раскрытие · эмоции · заземление +Приёмка: решено только при excellent + + + +Agent (оцениваемый) +Вход: тикет + политика домена +Не видно: реальное состояние устройства +Может только направлять, но не действовать за него + + + +Многоходовый диалог +Постепенное раскрытие + + + +Общая среда (двойное управление: состояние меняют обе стороны) + +Состояние на стороне устройства +Авиарежим ON · роуминг OFF · экономия · остаток трафика +Инструменты пользователя: toggle_airplane_mode / toggle_roaming + check_status_bar / run_speed_test + +База данных оператора +Клиент C1001 · линии L1001/L1002/L1003 · тарифы · счета +Инструменты Agent: get_customer_by_phone / get_data_usage + enable_roaming / refuel_data + + + + + + +toggle_roaming пользователя изменил среду; Agent обязан снова вызвать инструмент — проверка охватывает это перечитывание + + + +После задачи: четыре слоя проверок + правило агрегации + +env_assertions +Мобильные данные доступны +Скорость ≥ 200 / excellent + +actions +toggle_airplane_mode +requestor должен быть user + +communicate_info +Донесена ли нужная информация +в этой задаче null + +nl_assertions +Суждение на уровне текста +в этой задаче null +reward_basis = ["ENV_ASSERTION"] → учитывается только первый слой; остальные пишутся в лог, но в награду не входят + diff --git a/book-ru/images/fig7-4.svg b/book-ru/images/fig7-4.svg index 89232ecb3..80786bfb9 100644 --- a/book-ru/images/fig7-4.svg +++ b/book-ru/images/fig7-4.svg @@ -1,53 +1,54 @@ - - + + + + + + - -Рубрика - -Фактическая корректность: необходима -Логическая связность: важно -Обнаружение галлюцинаций: вето ⚠ -Полнота: важно - -Кандидат-ответ - -Вывод агента: -"Возврат обработан, $150 будет зачислено в течение - 3-5 рабочих дней." - - -Эталонное решение (опционально) - -Стандартный ответ / баллы за: -Должно включать сумму возврата -Должно включать время начисления кредита -Не может обещать конкретную дату - - - - -Модель-судья (GPT-5 / Gemini 2.5) -Мультиисточниковая гетерогенная оценка для предотвращения смещения одного источника - - -Структурированный вывод оценки - -Фактическая корректность -4/4 -Сумма и время точны -Полнота -3/4 -Отсутствует объяснение способа возврата -Обнаружение галлюцинаций -PASS -Нет ложной информации -Логическая связность -4/4 -Чёткая причинно-следственная связь - -Стратегия агрегации оценок -Взвешенное среднее: Σ(вес × оценка измерения) -Вето: Галлюцинация=FAIL → итоговый балл=0 -Мультисудья: медиана из 3 судей -Флаг граничного случая: расхождение >2 балла → проверка человеком + +Механическая проверяемость задачи: высокая +низкая + + +Детерминир. +Конечное состояние однозначно +Пройдено / нет +SWE-bench гоняет тесты + + + +Список проверок +Несколько детерм. проверок +Агрегация по объявленному базису +Четыре слоя τ²-bench + + + +Rubric + LLM +Измерения есть, кода нет +Оценка по измерениям с обоснованием +Качество поддержки, отчёты + + + +Попарно +Трудно даже задать измерения +Судит только A против B +Chatbot Arena + + +Детерминированная проверка +Полностью воспроизводима, годится для CI, дёшева +Цена: даёт вердикт, но не место ошибки + + +Суждение модели +Даёт диагностические измерения, покрывает неформализуемое +Цена: смещение и разброс суждений, выше стоимость diff --git a/book-ru/images/fig7-5.svg b/book-ru/images/fig7-5.svg index e39592177..89232ecb3 100644 --- a/book-ru/images/fig7-5.svg +++ b/book-ru/images/fig7-5.svg @@ -1,56 +1,53 @@ - + - -Chatbot Arena: анонимная битва - -Модель A (анонимная) - -"Возврат обработан, поступит через 3-5 - рабочих дней на ваш счёт" -VS - -Модель B (анонимная) - -"Хорошо, возврат будет обработан" - - -Слепой выбор пользователя → A лучше - -Формула обновления Elo -Ожидаемая доля побед E_A = 1/(1+10^((R_B-R_A)/400)) | Обновление: R_A' = R_A + K*(1-E_A) -Живая таблица лидеров (пример) -Ранг -Модель -Elo -Процент побед против #2 - -1 -Claude 4 Opus -1352 -— -2 -GPT-5 -1318 -— -3 -Gemini 2.5 Pro -1290 -45% -4 -DeepSeek R2 -1265 -42% -5 -Qwen 3 Max -1230 -39% -6 -Llama 4 405B -1198 -36% - - -GRPO: введение парного сравнения в обучение RL -Набор кандидатов-ответов → Нормализация относительного преимущества → Обновление политики (без явной модели вознаграждения) - \ No newline at end of file + +Рубрика + +Фактическая корректность: необходима +Логическая связность: важно +Обнаружение галлюцинаций: вето ⚠ +Полнота: важно + +Кандидат-ответ + +Вывод агента: +"Возврат обработан, $150 будет зачислено в течение + 3-5 рабочих дней." + + +Эталонное решение (опционально) + +Стандартный ответ / баллы за: +Должно включать сумму возврата +Должно включать время начисления кредита +Не может обещать конкретную дату + + + + +Модель-судья (GPT-5 / Gemini 2.5) +Мультиисточниковая гетерогенная оценка для предотвращения смещения одного источника + + +Структурированный вывод оценки + +Фактическая корректность +4/4 +Сумма и время точны +Полнота +3/4 +Отсутствует объяснение способа возврата +Обнаружение галлюцинаций +PASS +Нет ложной информации +Логическая связность +4/4 +Чёткая причинно-следственная связь + +Стратегия агрегации оценок +Взвешенное среднее: Σ(вес × оценка измерения) +Вето: Галлюцинация=FAIL → итоговый балл=0 +Мультисудья: медиана из 3 судей +Флаг граничного случая: расхождение >2 балла → проверка человеком + diff --git a/book-ru/images/fig7-6.svg b/book-ru/images/fig7-6.svg index 24b51ff14..e39592177 100644 --- a/book-ru/images/fig7-6.svg +++ b/book-ru/images/fig7-6.svg @@ -1,48 +1,56 @@ - - - -Дерево трассировки выполнения (одна задача) - -Трассировка: узнать погоду в Пекине для пользователя на завтра (3.2с, $0.008) - -Вызов LLM: распознавание намерения -Claude 4 Sonnet · 0.4с · 320 токенов - -Tool: get_weather(Beijing) -MCP-сервер · 1.8s · 200ms TTFT - -├─ HTTP-запрос -api.weather.com · 1.6s - -└─ Разбор ответа -JSON → структурированные данные о погоде - -Вызов LLM: генерация ответа -Claude 4 Sonnet · 0.8с · 580 токенов - -Tool: send_message(user) -0.2с · Содержит сводку погоды - - - - - - - -Панель мониторинга - -Отслеживание затрат -Сегодня: $12.30 (1200 вызовов) -В этом месяце: $340 (34K вызовов) -Аномалия: задача#892 зациклила поиск 14 раз, стоимость $2.1 - -Мониторинг производительности -Задержка P50 / P95 / P99: 2,1с / 8,4с / 15,2с -Успешность инструмента: 94.3% - -Аудит качества -Успешность задач: 87% Триггер галлюцинаций: 2.1% -Нарушения безопасности: 0 (за этот месяц) Удовлетворённость пользователей: 4.3/5 - -Замкнутый цикл: данные трассировки → выявление проблем → A/B-тестирование → управление версиями промптов → непрерывная оптимизация - + + + + +Chatbot Arena: анонимная битва + +Модель A (анонимная) + +"Возврат обработан, поступит через 3-5 + рабочих дней на ваш счёт" +VS + +Модель B (анонимная) + +"Хорошо, возврат будет обработан" + + +Слепой выбор пользователя → A лучше + +Формула обновления Elo +Ожидаемая доля побед E_A = 1/(1+10^((R_B-R_A)/400)) | Обновление: R_A' = R_A + K*(1-E_A) +Живая таблица лидеров (пример) +Ранг +Модель +Elo +Процент побед против #2 + +1 +Claude 4 Opus +1352 +— +2 +GPT-5 +1318 +— +3 +Gemini 2.5 Pro +1290 +45% +4 +DeepSeek R2 +1265 +42% +5 +Qwen 3 Max +1230 +39% +6 +Llama 4 405B +1198 +36% + + +GRPO: введение парного сравнения в обучение RL +Набор кандидатов-ответов → Нормализация относительного преимущества → Обновление политики (без явной модели вознаграждения) + \ No newline at end of file diff --git a/book-ru/images/fig7-7.svg b/book-ru/images/fig7-7.svg index f3ddf7af0..24b51ff14 100644 --- a/book-ru/images/fig7-7.svg +++ b/book-ru/images/fig7-7.svg @@ -1,56 +1,48 @@ - - - - -① Наблюдение: диагностический отчёт -Общий уровень успеха: 88% (102/116) -транскрипция: 0% complex_ui: 17% -math_counting: 0% Работа Wi-Fi: 0% -Задача 82,102-115 Концентрированные сбои - -② Гипотеза: трёхуровневая система улучшений - -Поверхностный слой -H1 Настройка промпта навигации H2 Правила UI - -Средний слой -H3 Исправление мультимодального конвейера H4 Размышление - -Глубокий слой -H5 GPT-5 H6 Дерево элементов UI - - -③ Эксперимент: поэтапная проверка (5 прогонов × 116 задач на конфигурацию) - -H1 Навигация -Настройка 0%→75% -токен+8% - -H3 Мультимодальность -Транскрипция 0%→80% -Задержка +1с - -H4 Размышление -Подсчёт 0%→70% -Задержка 3x! - -H6 Дерево элементов -UI 17%→52% -токен+30% - -④ Решение: анализ затрат и выгод -✓ H1+H3: Низкая стоимость, высокая польза → Внедрить -✗ H4: Только 8% задач получают пользу, но задержка ×3 → Отклонить -✓ H6: Улучшение 35% / Стоимость 30% → Внедрить -✗ H5: 15с/шаг неприемлемо → Альтернатива - -⑤ Итерация: новый цикл -Развернуть H1+H3+H6 → 88%→94% -Новый отчёт показывает разные режимы отказа: - H7: Условное размышление включено - H8: Расширить пространство жестовых действий - -↑ Loop - -Методология: наблюдение → гипотеза → эксперимент → решение → итерация = от алхимии к научной инженерии - \ No newline at end of file + + + +Дерево трассировки выполнения (одна задача) + +Трассировка: узнать погоду в Пекине для пользователя на завтра (3.2с, $0.008) + +Вызов LLM: распознавание намерения +Claude 4 Sonnet · 0.4с · 320 токенов + +Tool: get_weather(Beijing) +MCP-сервер · 1.8s · 200ms TTFT + +├─ HTTP-запрос +api.weather.com · 1.6s + +└─ Разбор ответа +JSON → структурированные данные о погоде + +Вызов LLM: генерация ответа +Claude 4 Sonnet · 0.8с · 580 токенов + +Tool: send_message(user) +0.2с · Содержит сводку погоды + + + + + + + +Панель мониторинга + +Отслеживание затрат +Сегодня: $12.30 (1200 вызовов) +В этом месяце: $340 (34K вызовов) +Аномалия: задача#892 зациклила поиск 14 раз, стоимость $2.1 + +Мониторинг производительности +Задержка P50 / P95 / P99: 2,1с / 8,4с / 15,2с +Успешность инструмента: 94.3% + +Аудит качества +Успешность задач: 87% Триггер галлюцинаций: 2.1% +Нарушения безопасности: 0 (за этот месяц) Удовлетворённость пользователей: 4.3/5 + +Замкнутый цикл: данные трассировки → выявление проблем → A/B-тестирование → управление версиями промптов → непрерывная оптимизация + diff --git a/book-ru/images/fig7-8.svg b/book-ru/images/fig7-8.svg index cce2dd9e4..f3ddf7af0 100644 --- a/book-ru/images/fig7-8.svg +++ b/book-ru/images/fig7-8.svg @@ -1,41 +1,56 @@ - + - - -Точность симуляции → -Масштабируемость - - - -↑ - -Заглушка API -уровень юнит-тестов -миллион раз/час - -AWorld -Песочница MCP -126 функций инструментов -525с/раунд распределённо - -AndroidWorld -Симулятор -116 реальных прикладных задач -UI Automator - -Isaac Gym -Параллелизм GPU -тысячи параллельных экземпляров -Немного сниженная точность - -RoboTwin2 -физический движок -Высокоточное столкновение -Одноэкземплярный CPU - -реальный мир -Идеальная точность -Не сбрасывается - + +① Наблюдение: диагностический отчёт +Общий уровень успеха: 88% (102/116) +транскрипция: 0% complex_ui: 17% +math_counting: 0% Работа Wi-Fi: 0% +Задача 82,102-115 Концентрированные сбои + +② Гипотеза: трёхуровневая система улучшений + +Поверхностный слой +H1 Настройка промпта навигации H2 Правила UI + +Средний слой +H3 Исправление мультимодального конвейера H4 Размышление + +Глубокий слой +H5 GPT-5 H6 Дерево элементов UI + + +③ Эксперимент: поэтапная проверка (5 прогонов × 116 задач на конфигурацию) + +H1 Навигация +Настройка 0%→75% +токен+8% + +H3 Мультимодальность +Транскрипция 0%→80% +Задержка +1с + +H4 Размышление +Подсчёт 0%→70% +Задержка 3x! + +H6 Дерево элементов +UI 17%→52% +токен+30% + +④ Решение: анализ затрат и выгод +✓ H1+H3: Низкая стоимость, высокая польза → Внедрить +✗ H4: Только 8% задач получают пользу, но задержка ×3 → Отклонить +✓ H6: Улучшение 35% / Стоимость 30% → Внедрить +✗ H5: 15с/шаг неприемлемо → Альтернатива + +⑤ Итерация: новый цикл +Развернуть H1+H3+H6 → 88%→94% +Новый отчёт показывает разные режимы отказа: + H7: Условное размышление включено + H8: Расширить пространство жестовых действий + +↑ Loop + +Методология: наблюдение → гипотеза → эксперимент → решение → итерация = от алхимии к научной инженерии \ No newline at end of file diff --git a/book-ru/images/fig7-9.svg b/book-ru/images/fig7-9.svg index 1ac2abbf5..cce2dd9e4 100644 --- a/book-ru/images/fig7-9.svg +++ b/book-ru/images/fig7-9.svg @@ -1,69 +1,41 @@ - - + + - -Мультимодальное наблюдение - -Головная камера -224×224 RGB - -Камера на левом запястье -224×224 RGB - -Камера правого запястья -224×224 RGB - -14-мерный вектор состояния сустава - -Модель Vision-Language-Action (VLA) - -Визуальный энкодер -SigLIP → визуальные токены - - -Языковая модель -Llama 2 7B (основа) - - -Декодер действий -→ 14-мерный вектор непрерывного управления -Группировка действий: генерация 25 последовательных действий за раз - - - -Инструкция: «Положи банку в кастрюлю» - - -Физический движок SAPIEN - -Двурукий робот -По 7 DOF каждый = 14-мерное действие - -Рандомизация среды -Позиция 60см / ориентация ±22.5° - -Обнаружение столкновений + физическая симуляция -Твёрдое тело / мягкое тело / трение - -Действие - -Наблюдение - -Метрики оценки - -Доля успеха -Банка в кастрюле -а не упал - -Время завершения -25 шагов × 25 действий -= 625 шагов управления - -Способность к обобщению -Кросс-позиция/ориентация -/Вариант внешнего вида - -Sim-to-Real -Рандомизация домена -→ Реальная миграция + + +Точность симуляции → +Масштабируемость + + + +↑ + +Заглушка API +уровень юнит-тестов +миллион раз/час + +AWorld +Песочница MCP +126 функций инструментов +525с/раунд распределённо + +AndroidWorld +Симулятор +116 реальных прикладных задач +UI Automator + +Isaac Gym +Параллелизм GPU +тысячи параллельных экземпляров +Немного сниженная точность + +RoboTwin2 +физический движок +Высокоточное столкновение +Одноэкземплярный CPU + +реальный мир +Идеальная точность +Не сбрасывается + \ No newline at end of file diff --git a/book-ta/chapter7.ta.md b/book-ta/chapter7.ta.md index d02ab5ec0..b70fba6e3 100644 --- a/book-ta/chapter7.ta.md +++ b/book-ta/chapter7.ta.md @@ -17,58 +17,117 @@ அத்தியாயம் 1-ல் அறிமுகப்படுத்தப்பட்ட Harness பொறியியலின் கண்ணோட்டத்தில், மதிப்பீடு (evaluation) Harness-க்குள் "சரிபார்ப்பின்" (verification) மையப் பங்கை வகிக்கிறது. ஒரு முக்கியமான நுண்ணறிவு: **மதிப்பீட்டின் பொருள் வெறும் மாதிரி (model) மட்டுமல்ல, மாதிரி மற்றும் Harness-இன் கலவையாகும்**. ஒரே மாதிரி வெவ்வேறு Harness-களில் முற்றிலும் மாறுபட்ட செயல்திறனை வெளிப்படுத்தலாம் — சில குழுக்கள், Harness-ஐ மேம்படுத்துவதன் மூலம் மட்டுமே, அதே மாதிரியின் முனையப் பணிகளில் (terminal tasks) செயல்திறனை கணிசமாக மேம்படுத்தியுள்ளன (விவரங்களுக்கு அத்தியாயம் 5-ஐப் பார்க்கவும்). இதன் பொருள், ஒரு ஏஜெண்ட் (Agent) மதிப்பீட்டில் மோசமாக செயல்படும்போது, மேம்பாட்டுத் திசை மாதிரியை மாற்றுவதாக இருக்க வேண்டியதில்லை, மாறாக Harness-இன் சில கூறுகளை (prompts, tool design, feedback loops) மேம்படுத்துவதாக இருக்கலாம். ஒரு நல்ல மதிப்பீட்டு அமைப்பு, அடிப்படையில் வேறுபட்ட இரண்டு வகையான சிக்கல்களை வேறுபடுத்திக் காட்ட வேண்டும்: "போதுமான மாதிரித் திறன் இல்லாமை" மற்றும் "Harness வடிவமைப்புக் குறைபாடுகள்". **இந்த இரண்டு வகையான சிக்கல்களையும் வேறுபடுத்துவதற்கான ஒரு பொதுவான முறை மாதிரி மாற்றுப் பரிசோதனை (model swap experiment) ஆகும்** — Harness-ஐ நிலைப்படுத்தி, மாதிரியை மட்டும் வலிமையான/பலவீனமான ஒன்றாக மாற்றி, மதிப்பெண் மாற்றத்தின் அளவைக் கவனிக்கவும்; வலிமையான மாதிரிக்கு மாற்றியும் மதிப்பெண் அதிகரிக்கவில்லை என்றால், தடை Harness-இல் உள்ளது; பலவீனமான மாதிரிக்கு மாற்றும்போது மதிப்பெண் பெரிதும் குறைந்து, மதிப்பெண் மாதிரித் திறனுடன் கணிசமாக ஏற்ற இறக்கமாக இருந்தால், மிக நேரடியான விளக்கம் என்னவென்றால், தடை மாதிரியின் சொந்தத் திறனில் உள்ளது மற்றும் தற்போதைய செயல்திறன் முதன்மையாக மாதிரியால் தீர்மானிக்கப்படுகிறது (இது பணியே கடினமாக இருப்பதாலா அல்லது Harness மாதிரியின் முன் அறிவை (prior knowledge) அதிகமாக நம்பியிருப்பதாலா என்பதை மேலும் பகுப்பாய்வு செய்ய வேண்டும்). முன்பு குறிப்பிடப்பட்ட "நீக்கம் பரிசோதனையிலிருந்து" (ablation experiment) இது வேறுபட்டது என்பதைக் கவனத்தில் கொள்ளவும்: நீக்கம் என்பது **Harness-இன் ஒரு கூறுகளை முடக்கி**, ஒட்டுமொத்த செயல்திறன் எவ்வாறு மாறுகிறது என்பதைப் பார்ப்பது, அதேசமயம் மாதிரி மாற்றம் என்பது **Harness-ஐ நிலைப்படுத்தி, மாதிரியை மட்டும் மாற்றுவது** — முந்தையது Harness-இன் உள்ளே எந்தப் பகுதி முக்கியமானது என்பதை அடையாளம் காட்டுகிறது, பிந்தையது தடை மாதிரியிலா அல்லது Harness-இலா என்பதை வேறுபடுத்துகிறது. மாதிரி பரிணாமம் வேகமாக நிகழும் இந்தக் காலகட்டத்தில் மதிப்பீட்டு அமைப்பின் மதிப்பு மேலும் முக்கியத்துவம் பெறுகிறது. மாதிரித் திறன்கள் இன்னும் வேகமாக வளர்ந்து வருகின்றன, ஆனால் பொது அளவுகோல்களில் (public benchmarks) ஒரு புதிய மாதிரி சிறப்பாக செயல்படுவது, அது உங்கள் குறிப்பிட்ட பணியிலும் சிறப்பாக செயல்படும் என்பதற்கு உத்தரவாதம் அளிக்காது — உண்மையில், செயல்திறன் பின்னடைவு (performance regression) (புதிய பதிப்பு பழையதை விட சில அம்சங்களில் மோசமாக இருப்பது) ஏற்படலாம். உங்கள் சொந்த மதிப்பீட்டுத் தரவுத் தொகுப்பில் (evaluation dataset) முழுமையாகச் சோதித்தால்தான், தரவு சார்ந்த மேம்படுத்தல் முடிவுகளை (data-driven upgrade decisions) எடுக்க முடியும். மேலும், ஒரு விரிவான மதிப்பீட்டு அமைப்பு, "எதிர்கால மாதிரிகளுக்கான தயாரிப்புகளை உருவாக்குதல்" என்பதை ஒரு சாத்தியமான உத்தியாக மாற்றுகிறது — தற்போதைய மாதிரி வணிக ரீதியான பயன்பாட்டிற்கு (commercial deployment) போதுமானதாக இல்லாவிட்டாலும், நீங்கள் தயாரிப்பு மேம்பாட்டை முடித்து, ஒரு மதிப்பீட்டுத் தொகுப்பை நிறுவலாம், புதிய மாதிரிகளின் செயல்திறனைத் தொடர்ந்து கண்காணிக்கலாம், மற்றும் வரம்பு (threshold) எட்டப்பட்டவுடன் உடனடியாக வெளியிடலாம். +ஒரு மதிப்பீட்டு அமைப்பை நான்கு கண்ணிகளாகப் பிரிக்கலாம்: எது வெற்றி, பணிகள் எங்கிருந்து வருகின்றன, யார் சரிபார்க்கிறார், மதிப்பெண் எப்படி முடிவாக மாறுகிறது. படம் 7-1 இதைக் காட்டுகிறது. + +![படம் 7-1: ஏஜெண்ட் மதிப்பீட்டு அமைப்பின் நான்கு கண்ணிகள்](images/fig7-1.svg) + +## ஒரு மதிப்பீட்டுப் பணியின் உள்ளமைப்பு: τ²-bench இன் telecom களம் + +முதலில் τ²-bench இன் telecom களத்திலிருந்து ஒரு உண்மையான பணியை முழுமையாகப் பிரித்து ஆய்வோம். மூலக் குறியீடு களஞ்சியத்தில் `chapter7/tau2-bench` இல் உள்ளது; பணிக் கோப்பு `data/tau2/domains/telecom/tasks_small.json`. + +### பணி வரையறையின் நான்கு கூறுகள் + +கீழே அந்தக் கோப்பிலிருந்து ஒரு பணி, படிப்பதற்கு எளிதாகச் சுருக்கப்பட்டுள்ளது. + +```jsonc +{ + "id": "[mobile_data_issue]airplane_mode_on|user_abroad_roaming_enabled_off", + + // ஏஜெண்டுக்கு வழங்கப்படும் டிக்கெட் + "ticket": "பயனரின் கைபேசி இணையத்தில் இணைய முடியவில்லை; நிலைப்பட்டையில் + 'No Service' காட்டப்படுகிறது. வாடிக்கையாளர் John Smith, எண் + 555-123-2002, தற்போது பிரான்ஸில் உள்ளார். வேகச் சோதனை excellent + எனத் திரும்பினால் மட்டுமே சரிசெய்யப்பட்டதாகக் கருதுவார். திட்டத்தை + மாற்ற விரும்பவில்லை; தேவைப்பட்டால் 2.0 GB தரவு நிரப்பச் சம்மதம்.", + + // பயனர் உருவகப்படுத்தியிடம் வழங்கப்படும் நடத்தை விதிகள் + "user_scenario": { "instructions": { + "known_info": "You are John Smith with phone number 555-123-2002. + You are currently abroad in France.", + "unknown_info": null, + "task_instructions": + "…express mild frustration after the first unsuccessful attempt. + You will consider the issue resolved only when speed test returns + excellent internet speed and nothing else. If it returns poor, fair + or good, you will not consider the issue resolved. + Whenever the agent asks you about your device, always ground your + responses on the results of tool calls. … + Never make up the results of tool calls." + }}, + + // இயக்குவதற்கு முன் இரு பக்க நிலையும் ஒரே தொடக்கப் புள்ளிக்கு மீட்டமைக்கப்படும் + "initial_state": { "initialization_actions": [ + { "env_type": "user", "func_name": "turn_airplane_mode_on" }, + { "env_type": "user", "func_name": "turn_roaming_off" }, + { "env_type": "assistant", "func_name": "enable_roaming", + "arguments": { "customer_id": "C1001", "line_id": "L1002" } } + ]}, + + // மதிப்பெண் அளவுகோல்கள் + "evaluation_criteria": { + "actions": [ + { "requestor": "user", "name": "toggle_airplane_mode" }, + { "requestor": "user", "name": "toggle_roaming" } + ], + "env_assertions": [ + { "func_name": "assert_mobile_data_status", "expected_status": true }, + { "func_name": "assert_internet_speed", + "expected_speed": 200, "expected_desc": "excellent" } + ], + "communicate_info": null, + "nl_assertions": null, + "reward_basis": ["ENV_ASSERTION"] + } +} +``` -> **அத்தியாய வழிகாட்டி** -> -> இந்த அத்தியாயம் மூன்று நிலைகளில் இருந்து ஒரு முழுமையான மதிப்பீட்டு முறைமையை உருவாக்குகிறது. முதல் நிலை **மதிப்பீட்டு சூழல்** ("எங்கே சோதிப்பது"): தானியங்கி, மீண்டும் உருவாக்கக்கூடிய சோதனை சூழலை எவ்வாறு அமைப்பது, இதில் இரண்டு முன்னுதாரணங்கள் அடங்கும்: கருவி-அழைப்பு வகை மற்றும் மனித-கணினி தொடர்பு வகை. இரண்டாம் நிலை **மதிப்பீட்டு முறைகள்** ("எப்படி தீர்ப்பது"): தரவுத்தொகுப்பு வடிவமைப்புக் கோட்பாடுகள், மதிப்பீட்டு அளவீட்டு முறைமை (எதை அளவிடுவது), தானியங்கி மதிப்பீட்டிற்கான LLM-as-a-Judge (பெரிய மொழி மாதிரிகளை நீதிபதிகளாகப் பயன்படுத்துதல்), பின்னர் ஜோடிவரிசை ஒப்பீடு மற்றும் மாதிரி தரவரிசைப்படுத்தல் வரை. மூன்றாம் நிலை **மதிப்பீடு-உந்துதல் முடிவெடுத்தல்** ("சோதனைக்குப் பிறகு என்ன செய்வது"): மதிப்பீட்டு முடிவுகளை மாதிரி தேர்வு, கட்டமைப்பு மேம்படுத்தல் மற்றும் தொடர்ச்சியான மறுசெயலாக்கத்திற்கான செயல்படக்கூடிய வழிகாட்டுதல்களாக மாற்றுதல், மற்றும் கவனிக்கப்பட்ட மதிப்பெண் வேறுபாடுகள் உண்மையானதா மற்றும் நம்பகமானதா என்பதை தீர்மானிக்க புள்ளியியல் முக்கியத்துவத்தைப் பயன்படுத்துதல். கூடுதலாக, இந்த அத்தியாயம் உற்பத்தி-தர ஏஜெண்டுகளுக்கான கவனிப்புத் திறன் மற்றும் உள் மதிப்பீட்டு உள்கட்டமைப்பு பற்றி விவாதிக்கும், மேலும் அத்தியாயத்தின் இறுதியில் அத்தியாயம் 8 இல் பிந்தைய பயிற்சியுடன் இணைக்கும் உருவகப்படுத்துதல் சூழலை அறிமுகப்படுத்தும். -> -> முழு அத்தியாயத்திலும் ஓடும் மையக் கருத்து: **மதிப்பீட்டு முறைமையின் முதன்மை மதிப்பு தற்போதைய முறைமைக்கு மதிப்பெண் வழங்குவது அல்ல, மாறாக மாதிரி பரிணாமத்துடன் விரைவாகவும் நம்பகத்தன்மையுடனும் தொடர்ந்து இருப்பதை உங்களுக்கு இயலச்செய்வதாகும்.** ஒரு வலுவான அல்லது மலிவான மாதிரி வெளியிடப்படும்போது, வலுவான மதிப்பீட்டு முறைமை கொண்ட ஒரு குழு மணிநேரங்களுக்குள் மாற்ற முடிவு எடுக்க முடியும், அதேசமயம் மதிப்பீட்டு முறைமை இல்லாத ஒரு குழு உள்ளுணர்வை மட்டுமே நம்பலாம் அல்லது சமூக கருத்துக்காக காத்திருக்கலாம் — மிகவும் போட்டி நிறைந்த ஏஜெண்ட் சந்தையில், இந்த வேக வேறுபாடு வெற்றி தோல்வியை தீர்மானிக்கும். +இந்த வரையறையில் விரிவாகச் சொல்ல வேண்டிய நான்கு வடிவமைப்பு முடிவுகள் உள்ளன. -![படம் 7-1: மதிப்பீட்டு முறைமையின் மூன்று நிலைகள்](images/fig7-1.svg) +**பயனரின் அறிவெல்லை வெளிப்படையாக மாதிரியாக்கப்பட்டுள்ளது.** `known_info` இல் பெயர், தொலைபேசி எண், தங்கியிருக்கும் நாடு — மூன்றே தகவல்கள் மட்டுமே உள்ளன. கோளாற்றின் உண்மையான இரு காரணங்கள் — விமானப் பயன்முறை இயக்கத்தில் இருப்பதும் தரவு ரோமிங் நிறுத்தப்பட்டிருப்பதும் — அதில் இல்லை. பயனருக்கு அவை தெரியாததால் அவரே சொல்ல முடியாது; ஏஜெண்ட் கேள்வி கேட்டும் பயனரைச் சரிபார்க்கச் சொல்லியும் மட்டுமே அவற்றை அறிய முடியும். இதுவே **படிப்படியான தகவல் வெளிப்படுத்தல் (Progressive Information Disclosure)** பணி வரையறை நிலையில் செயல்படுத்தப்படும் விதம்: "எல்லாவற்றையும் ஒரே முறையில் சொல்லிவிடாதே" என்ற ப்ராம்ப்ட்டால் உருவகப்படுத்தியைக் கட்டுப்படுத்துவதன் மூலம் அல்ல, பயனரின் அறிவெல்லையையே தனி புலமாக மாதிரியாக்குவதன் மூலம். பெரும்பாலான தரவரிசைச் சோதனைகள் பணியின் தொடக்கத்திலேயே முழுத் தேவையையும் தந்துவிடுகின்றன; ஆனால் உண்மையான பயனரின் முதல் வாக்கியம் பொதுவாக "இணையம் வேலை செய்யவில்லை" என்பதற்கு மேல் இருப்பதில்லை. கோரிக்கையைச் செயல்படுத்தக்கூடிய அளவுக்குத் தெளிவுபடுத்துவதே ஏஜெண்ட் அறிந்திருக்க வேண்டிய திறனின் ஒரு பகுதி. -## ஒரு உறுதியான மதிப்பீட்டு உதாரணம் +**உருவகப்படுத்தி பெறுவது வசனம் அல்ல, நடத்தை விதி.** `task_instructions` இல் மூன்று வகைக் கட்டுப்பாடுகள் கலந்துள்ளன: உணர்வு அமைப்பு (முதல் சரிசெய்தல் முயற்சி தோல்வியடைந்த பின் லேசான அதிருப்தி காட்ட வேண்டும்), ஏற்பு அளவுகோல் (வேகச் சோதனை excellent எனத் திரும்பினால் மட்டுமே தீர்க்கப்பட்டதாகக் கருத வேண்டும்; poor, fair, good அனைத்தும் ஏற்கப்படாது), மற்றும் **உண்மைநிலை நங்கூரமிடல் (Grounding)** தேவை — சாதன நிலை பற்றிய எந்தப் பதிலும் கருவி திருப்பியளித்த மதிப்பை அடிப்படையாகக் கொண்டிருக்க வேண்டும்: "Never make up the results of tool calls". மூன்றாவதே மிக முக்கியமானது: நங்கூரக் கட்டுப்பாடு இல்லாவிட்டால், உருவகப்படுத்தப்பட்ட பயனர் ஏஜெண்டின் வழிநடத்தலைப் பின்பற்றிச் சிக்கல் தீர்ந்துவிட்டதாக உறுதிப்படுத்திவிடுவார்; மதிப்பீடு இரு மாதிரிகள் ஒன்றையொன்று அங்கீகரிப்பதாகச் சரிந்துவிடும். -முறையியலில் மூழ்குவதற்கு முன், ஒரு முழுமையான உதாரணத்தின் மூலம் உள்ளுணர்வை உருவாக்குவோம். நாம் ஒரு வாடிக்கையாளர் சேவை ஏஜெண்டை உருவாக்கியுள்ளோம் என்றும், பணத்தைத் திரும்பப்பெறும் கோரிக்கைகளை கையாளும் அதன் திறனை மதிப்பீடு செய்ய வேண்டும் என்றும் வைத்துக்கொள்வோம். +**தொடக்க நிலை கட்டுப்படுத்தும் பக்கத்தின்படி பிரிக்கப்பட்டுள்ளது.** `env_type` `user`, `assistant` என இரு மதிப்புகளை எடுக்கிறது: விமானப் பயன்முறையும் ரோமிங் சுவிட்சும் பயனர் பக்கத்துக்கும், சேவை வழங்குநர் பக்கத்தின் `enable_roaming` ஏஜெண்ட் பக்கத்துக்கும் உரியவை. இந்தப் பிரிவே கோளாற்றின் வடிவத்தை நிர்ணயிக்கிறது: வழங்குநர் பக்கத்தில் ரோமிங் இயக்கப்பட்டுள்ளது, ஆனால் பயனர் சாதனத்தில் நிறுத்தப்பட்டுள்ளது; எனவே ஏஜெண்ட் தரவுத்தளத்தை வினவினால் "அமைப்பு சரியாக உள்ளது" என்ற முடிவுதான் கிடைக்கும். கோளாறு தரவுத்தளத்துக்குத் தெரியாத பக்கத்தில் உள்ளது; பயனரைச் சரிபார்க்கச் சொன்னால் மட்டுமே அது வெளிப்படும். -**சோதனை வழக்கு**: பயனர் 3 நாட்களுக்கு முன் செய்த ஆர்டரை (ஆர்டர் #12345, தொகை ¥299) திரும்பப் பெற விரும்புகிறார். நிறுவனக் கொள்கை: 7 நாட்களுக்குள் முழுப் பணத்தைத் திரும்பப்பெறலாம். +**மதிப்பெண் அளவுகோல்கள் நான்கு அடுக்குகளாகப் பிரிக்கப்பட்டுள்ளன; இந்தப் பணி அவற்றுள் ஒன்றை மட்டுமே பயன்படுத்துகிறது.** `env_assertions` இறுதி நிலையைச் சரிபார்க்கிறது (மொபைல் தரவு கிடைக்கிறது, வேகம் 200 Mbps க்கு மேல், தரம் excellent), `actions` முக்கிய செயல்கள் நிகழ்ந்தனவா என்பதையும் **எந்தப் பக்கம்** செய்தது என்பதையும் சரிபார்க்கிறது, `communicate_info` மற்றும் `nl_assertions` தேவையான தகவல் பயனருக்குத் தெரிவிக்கப்பட்டதா எனச் சரிபார்க்கின்றன. இந்தப் பணியின் `reward_basis` `ENV_ASSERTION` ஐ மட்டுமே அறிவிக்கிறது; மற்ற அடுக்குகள் வழக்கம்போல் கணக்கிடப்பட்டுப் பதிவாகின்றன, ஆனால் இறுதி வெகுமதியில் சேர்வதில்லை. மதிப்பெண் அடிப்படை ஒவ்வொரு பணிக்கும் தனித்தனியே அறிவிக்கப்படுகிறது; உலகளாவிய நிலையில் நிலைநிறுத்தப்படுவதில்லை. -**ஏஜெண்ட் பாதை**: +### ஒரு உண்மையான இயக்கத்தின் trajectory -```text -User: நான் 3 நாட்களுக்கு முன் வாங்கிய ஹெட்ஃபோன்களை திரும்பப் பெற விரும்புகிறேன், ஆர்டர் எண் 12345. (இன்று 2026-04-10) +இனி வாசகர் τ²-bench இன் telecom களத்தின் மதிப்பீட்டுப் பணிகளைத் தாமே இயக்கி, பணி வடிவமைப்பு, பயனர் உருவகப்படுத்தி, செயல்முறை மற்றும் முடிவு சரிபார்ப்பு தர்க்கம் ஆகியவற்றைக் கவனித்து, ஏஜெண்டின் செயலாக்க trajectory ஐப் பார்த்து அது ஏன் தோல்வியடைந்தது என்பதை ஆய்வு செய்யுமாறு கேட்டுக்கொள்கிறோம். -Agent (சிந்தித்தல்): பயனர் பணத்தைத் திரும்பப் பெற விரும்புகிறார், முதலில் ஆர்டர் தகவலைச் சரிபார்க்க வேண்டும். -Agent → Calls tool query_order(order_id="12345") -Tool returns: {status: "delivered", amount: 299, date: "2026-04-07", item: "Bluetooth Headphones"} +> **சோதனை 7-1 ★: τ²-bench ஐ இயக்கி τ-bench இலிருந்து அதன் வளர்ச்சியை ஒப்பிடுதல்** +> +> இச்சோதனை τ²-bench மதிப்பீட்டுக் கட்டமைப்பை இயக்கி, மனித-கணினி இடைவினை வகை மதிப்பீட்டுச் சூழலின் வடிவமைப்பு முக்கியப் புள்ளிகளைப் புரிந்துகொள்கிறது. முதலில் இப்பகுதியில் கடந்த அதே பாதையில் பணி வரையறைக் கோப்பை முழுமையாகப் படியுங்கள்: ஒவ்வொரு பணியும் அறியப்பட்ட தகவல், பணி வழிமுறைகள், தொடக்க நிலை, வெற்றி நிபந்தனைகள் என நான்கு பகுதிகளைக் கொண்டது. பின்னர் முழு மதிப்பீட்டு ஓட்டத்தையும் இயக்கி, பயனர் உருவகப்படுத்திக்கும் ஏஜெண்டுக்கும் இடையிலான பல சுற்று உரையாடலைக் கவனித்து, வழக்கமான தோல்வி வடிவங்களை (கொள்கை மீறல், தகவல் விடுபடல், மனித முகவரிடம் அதிகமாக மாற்றுதல் போன்றவை) ஆய்வு செய்யுங்கள். +> +> ![படம் 7-3: τ²-bench இல் இரட்டைக் கட்டுப்பாட்டுச் சூழலும் அடுக்குவாரிச் சரிபார்ப்பும்](images/fig7-3.svg) -Agent (சிந்தித்தல்): ஆர்டர் தேதி 2026-04-07, இன்று 2026-04-10, அதாவது 3 நாட்கள், 7 நாள் பணத்தைத் திரும்பப்பெறும் காலத்திற்குள் உள்ளது, முழுப் பணத்தையும் திரும்பப் பெற தகுதியானது. -Agent → Calls tool process_refund(order_id="12345", amount=299) -Tool returns: {refund_id: "R-98765", status: "processing", eta: "3-5 business days"} +இணைக் களஞ்சியத்தில் ஒரு இயக்கப் பதிவு (`chapter7/tau2-bench-eval`) சேமிக்கப்பட்டுள்ளது. அதிலிருந்து வெற்றி பெற்ற ஒரு இயக்கத்தை இங்கே ஆய்வு செய்வோம். -Agent: உங்களுக்கான பணத்தைத் திரும்பப்பெறும் செயல்முறை தொடங்கப்பட்டுள்ளது. ஆர்டர் #12345 (புளூடூத் ஹெட்ஃபோன்கள், ¥299) க்கான முழுப் பணத்தைத் திரும்பப்பெறும் செயல்முறை நடைபெற்று வருகிறது, - மேலும் இது 3-5 வேலை நாட்களில் வந்து சேரும் என எதிர்பார்க்கப்படுகிறது. பணத்தைத் திரும்பப்பெறும் ஐடி R-98765 ஆகும், இதைப் பயன்படுத்தி முன்னேற்றத்தைச் சரிபார்க்கலாம். -``` +முதல் பத்துக்கும் மேற்பட்ட சுற்றுகள் கணக்கு அடையாளம் காணும் கட்டம். ஏஜெண்ட் எண்ணிலிருந்து வாடிக்கையாளர் C1001 ஐக் கண்டறிந்து, பின் L1001, L1002, L1003 ஆகிய மூன்று இணைப்புகளின் தரவுப் பயன்பாட்டை ஒவ்வொன்றாக வினவி, பயனர் பிரான்ஸில் உண்மையில் எந்த எண்ணைப் பயன்படுத்துகிறார் எனத் திரும்பக் கேட்கிறது. 17-ஆவது செய்தியில் அது தவறான முடிவுக்கு வருகிறது: + +> **ஏஜெண்ட்** (17): 555-123-2002 எண் உங்கள் செயலிலுள்ள இணைப்புகளில் இல்லை; மிக நெருக்கமானது 555-123-2001… + +இந்த முடிவு L1001 என்ற ஒரே இணைப்பின் வினவலை மட்டுமே சார்ந்தது. எண் சரியானதுதான் என்று பயனர் உறுதியாகச் சொன்ன பிறகு, ஏஜெண்ட் L1002 ஐ வினவி அப்போதுதான் பொருத்திப் பார்க்கிறது. தீர்க்கமான திருப்பம் 30-ஆவது செய்தியில் வருகிறது: -**Rubric மூலம் மதிப்பெண் வழங்குதல்** (நான்கு பரிமாணங்கள், ஒவ்வொன்றும் 1-4 மதிப்பெண்கள்). அட்டவணை 7-1, இந்த வாடிக்கையாளர் சேவை பணத்தைத் திரும்பப்பெறும் பணிக்கான மதிப்பெண் எடுத்துக்காட்டை வழங்குகிறது, ஒரு Rubric ஒரு ஏஜெண்டின் பயணப் பாதையை (trajectory) சரிபார்க்கக்கூடிய மதிப்பீட்டு பரிமாணங்களாக எவ்வாறு பிரிக்கிறது என்பதை விளக்குகிறது. +> **பயனர்** (30) → `check_network_status()`, `check_status_bar()` ஐ அழைக்கிறார் +> +> **கருவியின் திருப்பம்** (31): `Airplane Mode: ON | Cellular Connection: no_service | Mobile Data Enabled: Yes | Data Roaming Enabled: No` +> +> **பயனர்** (33): கைபேசி இப்போது விமானப் பயன்முறையில் இருப்பதைப் பார்க்கிறேன்; அதனால்தான் சிக்னல் இல்லை. மொபைல் தரவு இயக்கத்தில் உள்ளது, ஆனால் தரவு ரோமிங் நிறுத்தப்பட்டுள்ளது. விமானப் பயன்முறையை நிறுத்திப் பார்க்கவா? -அட்டவணை 7-1 வாடிக்கையாளர் சேவை பணத்தைத் திரும்பப்பெறும் பணிக்கான Rubric மதிப்பெண் எடுத்துக்காட்டு +கருவி அழைப்பை வெளியிட்டது **பயனர்**, ஏஜெண்ட் அல்ல. இதுவே **இரட்டைக் கட்டுப்பாடு (Dual-Control)** எனும் நுட்பம்: உருவகப்படுத்தப்பட்ட பயனரிடம் `check_status_bar`, `toggle_airplane_mode`, `reseat_sim_card`, `run_speed_test` போன்ற தனி கருவித் தொகுப்பு உள்ளது. -| பரிமாணம் | அளவுகோல் | மதிப்பெண் | காரணம் | -|----------------------|---------------------------------|--------|--------------------------------| -| செயல்பாட்டுத் துல்லியம் | பணத்தைத் திரும்பப்பெறும் தொகை மற்றும் ஆர்டர் எண் சரியாக உள்ளதா? | 4 | சரியாக வினவி, ¥299 முழு பணத்தைத் திரும்பப்பெறும் பணியைத் தொடங்கியது | -| கொள்கை இணக்கம் | இது 7 நாள் பணத்தைத் திரும்பப்பெறும் கொள்கையைப் பின்பற்றுகிறதா? | 4 | ஆர்டர் பணத்தைத் திரும்பப்பெறும் காலத்திற்குள் உள்ளது, கொள்கைக்கு இணங்குகிறது | -| தகவல் முழுமை | இது தொகை, வரும் நேரம் மற்றும் பணத்தைத் திரும்பப்பெறும் ஐடி பற்றி தெரிவிக்கிறதா? | 4 | மூன்று முக்கிய தகவல்களும் வழங்கப்பட்டன | -| மாயத்தோற்றம் கண்டறிதல் (வீட்டோ உருப்படி) | இது இல்லாத தகவலை உருவாக்குகிறதா? | தேர்ச்சி | அனைத்து தகவல்களும் கருவி வழங்கிய முடிவுகளிலிருந்து வந்தவை | +அதன் பிறகான ஆய்வு சுமூகமாக நகர்கிறது: ஏஜெண்ட் பயனரை விமானப் பயன்முறையை நிறுத்தி ரோமிங்கை இயக்கச் சொல்கிறது, பயனர் இரண்டையும் செய்கிறார் (35, 37), நிலைப்பட்டை முழு சிக்னலுடன் 5G ஆக மாறுகிறது; ஏஜெண்ட் வேகச் சோதனை கேட்க, 275 Mbps, தரம் Excellent எனத் திரும்புகிறது (46), பயனர் சிக்கல் தீர்ந்ததை உறுதிப்படுத்துகிறார். இரண்டு `env_assertions` ம் தேறுகின்றன; `reward = 1.0`. -மாயத்தோற்றம் (hallucination) என்பது தரப்படுத்தப்பட்ட மதிப்பெண் பரிமாணமாக அல்லாமல் **வீட்டோ உருப்படியாக** (veto item) பட்டியலிடப்பட்டுள்ளது, ஏனெனில் இது தரத்திலிருந்து வேறுபட்டது (orthogonal) — தவறான தகவலைக் கொண்ட ஒரு சரளமான, விரிவான மற்றும் பணிவான பதில், சுருக்கமான ஆனால் துல்லியமான பதிலை விட பயனருக்கு மிகவும் தீங்கு விளைவிக்கும். (வீட்டோ பொறிமுறையின் பொதுவான வடிவமைப்பிற்கு, பின்னர் உள்ள "நான்கு Rubric கொள்கைகள்" பகுதியைப் பார்க்கவும்.) +முழு மதிப்பெண் பெற்ற இந்த trajectory இல் சரிபார்ப்பான் பிடிக்காத ஒரு சிக்கலும் உள்ளது. telecom ஏஜெண்ட் கொள்கையின் முதல் பத்தியே "You should only make one tool call at a time" எனக் குறிப்பிடுகிறது; ஆனால் 4-ஆவது செய்தியில் ஏஜெண்ட் `get_customer_by_phone`, `get_customer_by_name` ஆகிய இரு அழைப்புகளையும் ஒரே முறையில் வெளியிட்டது. சரிபார்ப்பான் அதைப் பிழையெனக் கருதவில்லை; காரணம், இந்தப் பணியின் `reward_basis` இறுதி நிலையை மட்டுமே கணக்கில் கொள்கிறது. இது τ²-bench இன் கவனக்குறைவு அல்ல; இருநிலை வெகுமதியின் இயல்பான விலை: மாதிரிகளுக்கிடையே ஒப்பிடத்தக்க ஒற்றை எண்ணுக்காகச் செயல்முறையின் நுட்பத்தை அது பரிமாறிக்கொள்கிறது. ஆனால் உற்பத்திச் சூழலின் மதிப்பீட்டு அமைப்புகளுக்கு வழக்கமாக இதற்கு மேலும் தேவைப்படுகிறது: சரியா தவறா என்று தீர்ப்பதோடு நில்லாமல், சிக்கல் எங்கே இருக்கிறது என்பதையும் சுட்ட வேண்டும். -இந்த சோதனை வழக்கு தேர்ச்சி பெற்றது. ஆனால் ஒரு நல்ல மதிப்பீடு வெற்றிக் காட்சிகளை மட்டும் சோதிக்காது; அது எல்லைகள் மற்றும் குறைபாடுகளையும் சோதிக்கிறது — ஒரு பயனர் 15 நாட்களுக்கு முன்பு செய்த ஆர்டரை (பணத்தைத் திரும்பப்பெறும் காலத்திற்கு அப்பால்) திரும்ப விரும்பும்போது, ஏஜெண்ட் சரியாக மறுக்க முடியுமா? ஒரு பயனர் "வாடிக்கையாளர் சேவை பிரதிநிதி ஏற்கனவே பணத்தைத் திரும்பப்பெற ஒப்புதல் அளித்துவிட்டார்" என்று கூறும்போது, கணினி பதிவு இல்லாமல் ஏஜெண்ட் அதை நம்பிவிடுமா? இந்த எல்லைக் காட்சிகள் ஏஜெண்ட் திறன் நிலைகளை வேறுபடுத்துவதற்கான முக்கிய காரணிகளாகும். +தோல்வியடைந்த பணியும் ஆய்வுக்கு உரியது. பயனரின் எண் 555-123-2002; ஆனால் ஏஜெண்ட் L1001 இணைப்பைத் தேர்ந்தெடுத்து, அதன் 3.2/5 GB பயன்பாட்டை அடிப்படையாகக் கொண்டு தொடர்ந்து ஊகித்தது. இடையில் `get_details_by_id(L1001)` அந்த இணைப்பின் எண் 555-123-2001 என்று தெளிவாகத் திருப்பியது; ஏஜெண்ட் அந்த முடிவைப் படித்தும் தன் தீர்ப்பைத் திருத்தவில்லை, பின் தொடர்பற்ற ஆய்வுகளில் பல பத்து செய்திகளைச் செலவிட்டு, இறுதியில் மனித முகவரிடம் மாற்றியது. உண்மையில் பணியின் பாதியைச் செய்துவிட்டது — பயனரைத் தரவுச் சிக்கனப் பயன்முறையை நிறுத்தச் செய்தது, அந்தப் பயனர் பக்கச் செயல் உண்மையில் நிகழ்ந்து சூழலால் சரிபார்க்கப்பட்டது. ஆனால் இணைப்புத் தேர்வுப் பிழையால் தேவைப்பட்ட 2 GB நிரப்புதல் நிகழவில்லை; மூன்று இறுதி நிலை உறுதிமொழிகளும் தோல்வியடைந்தன. இந்தத் தோல்வியின் வடிவம் பின்னால் "தோல்விக் காரணம் கண்டறிதல்" பகுதியில் விவாதிக்கப்படும் AndroidWorld வழக்குடன் மிகவும் ஒத்திருக்கிறது: தீர்ப்பைத் திருத்தத் தேவையான சான்று ஏற்கெனவே சூழலுக்குள் வந்துவிட்டது, ஆனால் ஏஜெண்ட் அதை வைத்துத் திரும்பிப் பார்க்கவில்லை. -மேலே உள்ள செயல்முறை — சோதனை வழக்குகளை வரையறுத்தல், ஏஜெண்டை இயக்குதல், Rubric மூலம் மதிப்பெண் வழங்குதல் மற்றும் முடிவுகளை பகுப்பாய்வு செய்தல் — மதிப்பீட்டின் அடிப்படை அமைப்பாகும். இந்த அத்தியாயத்தின் பின்வரும் பகுதிகள் ஒவ்வொரு படிக்குமான வடிவமைப்பு முறைகளை படிப்படியாக விரிவுபடுத்தும். +இந்த ஒரே பணி, ஒரு மதிப்பீட்டுத் தொகுப்பு பதிலளிக்க வேண்டிய அனைத்துக் கேள்விகளையும் ஏற்கெனவே எழுப்பிவிட்டது: எது வெற்றி, பணிகள் எங்கிருந்து வருகின்றன, யார் சரிபார்க்கிறார், மதிப்பெண் எப்படி முடிவாக மாறுகிறது. அடுத்த பகுதிகள் இவற்றை வரிசையாக விரிக்கின்றன. -## மதிப்பீட்டு அளவீட்டு முறைமை: புதுப்பிக்கப்பட்ட அளவுகோல்கள் +## மதிப்பீட்டு அளவீடுகள்: வெற்றியின் வரையறை -சூழல் அல்லது தரவுத்தொகுப்பை உருவாக்கும் முன் “வெற்றி” என்றால் என்ன என்பதைத் தீர்மானிக்க வேண்டும்: ஒரு முறை இயங்கும் பாதை கிடைத்தால் போதுமா, அல்லது ஒவ்வொரு இயக்கமும் சரியாக இருக்க வேண்டுமா? வரையறை மாறினால் பொறியியல் முடிவும் மாறும். இந்தப் பகுதி முதலில் இந்த அளவுகோலை நிறுவுகிறது; பின்னர் சூழலையும் தரவுத்தொகுப்பையும் மதிப்பெண் வழங்கியையும் எப்படி உருவாக்குவது என்பதை விளக்குகிறது. +முந்தைய பகுதியின் மதிப்பீட்டு முடிவு ஐந்து பணிகளில் நான்கு தேறியது. 0.8 என்ற எண்ணை மட்டும் வைத்து அந்த அமைப்பு பயன்படுத்தக்கூடியதா என்று தீர்மானிக்க முடியாது. அது பணத்தைத் திரும்பத் தரும் வாடிக்கையாளர் சேவை ஏஜெண்ட் என்றால், ஐந்து பயனர்களில் ஒருவருக்குச் சேர வேண்டிய தொகை சேராது என்பது பொருள்; பாதுகாப்புக் குறைபாடுகளைத் தேடும் ஏஜெண்ட் என்றால், ஐந்தில் நான்கு வெற்றி என்பது நன்றாகவே இருக்கிறது. வேறுபாடு, அந்த வணிகச் சூழல் எவ்வளவு உயர்ந்த வெற்றி விகிதத்தைக் கோருகிறது என்பதில் உள்ளது. ### தொழில்நுட்ப அதிசயம்: Pass@k மூலம் திறன் உச்சம் @@ -99,209 +158,151 @@ $$ $k$ முயற்சிகள் என்பதன் பொருளை மதிப்பீட்டு அறிக்கை தெளிவாக எழுத வேண்டும்: ஒரே பணியின் $k$ தனித்தனி மாதிரிகளா, அல்லது உற்பத்தி வழித்தடத்தில் தொடர்ச்சியான $k$ பணிகளா என்பதை. பக்கவிளைவுகளை ஏற்படுத்தும் செயல்களுக்கு "வெற்றி பெறும் வரை மீண்டும் முயலுதல்" என்பது ஏற்புடையது அல்ல; sandbox அல்லது பின்னோக்கி மீட்கக்கூடிய சூழலில் மாதிரி எடுக்க வேண்டும், ஒவ்வொரு தோல்வியையும் நம்பகத்தன்மை அளவீட்டில் பதிவு செய்ய வேண்டும். -### செயல்முறை அளவீடுகள்: கருப்புப் பெட்டியிலிருந்து வெள்ளைப்பெட்டி வரை +## மதிப்பீட்டுச் சூழல் -இறுதி முடிவில் மட்டும் கவனம் செலுத்துவது போதாது; ஏஜெண்ட் அந்த முடிவை அடையும் செயல்முறையும் சமமாக முக்கியமானது. **செயல் சட்டப்பூர்வ விகிதம்** (Action legality rate) அனைத்துச் செயல்களிலும் செல்லுபடியாகும் மற்றும் சட்டப்பூர்வமான செயல்பாடுகளின் விகிதத்தை அளவிடுகிறது—செல்லாத செயல்பாடுகளில் இல்லாத கருவிகளை அழைப்பது அல்லது தவறான அளவுரு வகைகளை அனுப்புவது ஆகியவை அடங்கும்; அங்கீகரிக்கப்படாத செயல்பாடுகள் அனுமதிக்கப்பட்ட வரம்பிற்கு அப்பாற்பட்ட செயல்களைக் குறிக்கும். அதிக சட்டப்பூர்வ விகிதம், ஏஜெண்ட் கருவி சூழலைப் (tool ecosystem) பற்றி தெளிவான புரிதலைக் கொண்டுள்ளது என்பதைக் குறிக்கிறது. **கருவி அழைப்புத் துல்லிய விகிதம்** (Tool call correctness rate) மேலும் அளவுருக்கள் சொற்பொருள்ரீதியாக நியாயமானதாக இருக்க வேண்டும் எனக் கோருகிறது: தேடல் கருவிக்கான வினவல் சொற்கள் தேவையைத் துல்லியமாக வெளிப்படுத்த வேண்டும், மேலும் கோப்புச் செயல்பாட்டிற்கான பாதை சரியான இலக்கைச் சுட்டிக்காட்ட வேண்டும். +அளவீட்டு அடிப்படை தெளிவானதும், அடுத்த கேள்வி எங்கே அளப்பது. மதிப்பீட்டுச் சூழல் என்பது மீண்டும் மீண்டும் இயக்கக்கூடிய ஒரு அமைவு: ஒரே தொடக்க நிலை கொடுக்கப்பட்டால், அதே ஏஜெண்ட் ஒப்பிடத்தக்க முடிவுகளைத் தர வேண்டும். -**பாதைத் திறன்** (Path efficiency) பணி நிறைவின் சிக்கனத்தை அளவிடுகிறது: படிகளின் எண்ணிக்கை (சிந்தனை-செயல்-கவனிப்பு சுழற்சிகள்), தேவையற்ற செயல்கள் (அதே முக்கியச் சொல்லை மீண்டும் மீண்டும் தேடுதல், அதே கோப்பை மீண்டும் படித்தல்), மற்றும் பின்னடைவு அதிர்வெண் (backtracking frequency) (ஏஜெண்ட் ஒரு பிழையை உணர்ந்து தன்னைத் தானே சரிசெய்யும் அதிர்வெண்—எப்போதாவது பின்னடைவு இயல்பானது, ஆனால் அடிக்கடி பின்னடைவு போதுமான முன்கூட்டிய திட்டமிடல் இல்லாததைக் குறிக்கிறது). "நியாயமான படிகளின் எண்ணிக்கையை" வரையறுக்க மனித நிபுணர்கள் அல்லது ஹூரிஸ்டிக் அல்காரிதம்களிடமிருந்து ஒரு அடிப்படை (baseline) தேவை. +### ஐந்து கூறுகள் -**மீட்டெடுப்பு கவரேஜ்** (Retrieval coverage) தகவல் சேகரிப்புப் பணிகளை இலக்காகக் கொண்டது: ஏஜெண்ட் தகவல் இடத்தை முழுமையாக ஆராய்ந்ததா? தேடல் முடிவுகளின் முதல் பக்கத்தை மட்டும் பார்த்துவிட்டு முடிவுகளுக்குத் தாவியதா? **செலவு மற்றும் தாமதம்** (Cost and latency) கோரிக்கை எண்ணிக்கை, டோக்கன் செலவு (உள்ளீடு/வெளியீடு செலவுகளை வேறுபடுத்தி, KV Cache மறுபயன்பாட்டைக் கருத்தில் கொண்டு), மற்றும் சுவர்-கடிகார நேரம் (wall-clock time) (மாதிரி அனுமானம் + கருவி செயலாக்கம் + நெட்வொர்க் தாமதம் உட்பட) ஆகியவற்றில் கவனம் செலுத்துகிறது. இடையூறுகளை அடையாளம் காண நேர விநியோகத்தைக் கண்காணிக்க வேண்டும். +மேலே பிரித்து ஆய்ந்த telecom பணிக்குத் திரும்புவோம். அதை அளவுகோலாகக் கொண்டால், மீண்டும் இயக்கக்கூடிய மதிப்பீட்டுச் சூழலுக்குத் தேவையானவை ஏற்கெனவே முழுமையாக உள்ளன. -### பாதுகாப்பு, வலிமை மற்றும் trajectory coverage +**தரவுத்தொகுப்பு (Dataset)** என்பது பணிக் கோப்பே: தொடக்க நிலை, ஏஜெண்டுக்கான டிக்கெட், உருவகப்படுத்திக்கான நடத்தை விதிகள், ஏற்பு அளவுகோல்கள் — அனைத்தும் ஒரே பதிவாகத் தொகுக்கப்பட்டுள்ளன; ஒரு பதிவே ஒரு சோதனை வழக்கு. +**சூழல் நிலை (Environment State)** என்பது பணி இயங்கும்போது மாறும் தகவல்: தரவுத்தளத்தில் உள்ள வாடிக்கையாளர்கள், இணைப்புகள், திட்டங்கள், கட்டணப் பட்டியல்கள்; அத்துடன் சாதனப் பக்கத்தில் விமானப் பயன்முறை, ரோமிங், தரவுச் சிக்கன சுவிட்ச், மீதமுள்ள தரவு. இது மீட்டமைக்கக்கூடியதாக இருக்க வேண்டும்; `initialization_actions` தான் அந்த மீட்டமைப்பு ஸ்கிரிப்ட். உண்மைத்தன்மை நிலை மாற்றங்கள் வணிக தர்க்கத்தைப் பின்பற்ற வேண்டும் எனக் கோருகிறது; கட்டுப்படுத்தல் ஒவ்வொரு இயக்கத்துக்கும் முன் அதே தொடக்கப் புள்ளிக்குத் திரும்ப முடிய வேண்டும் எனக் கோருகிறது. -**பாதுகாப்பு மற்றும் இணக்க அளவீடுகள்** உற்பத்தி நிலைப்படுத்தலில் முக்கியமானவை: உணர்திறன் வாய்ந்த செயல்பாடுகளைத் தூண்டுதல் (தரவை நீக்குதல் / அனுமதிகளை மாற்றுதல் / வெளிப்புற தகவல்தொடர்புகளை அனுப்புதல்), தரவு கசிவு (பதிவுகளில் கடவுச்சொற்களை அச்சிடுதல் / தனிப்பட்ட ஆவணங்களை வெளிப்புற API களுக்கு அனுப்புதல்), மற்றும் தடைசெய்யப்பட்ட உள்ளடக்கம் ஆகிய அனைத்தும் **பூஜ்ஜிய-சகிப்புத்தன்மை கொள்கையை** பின்பற்ற வேண்டும்—இது மாயத்தோற்ற வீட்டோவைப் போன்றது (பின்னர் "நான்கு Rubric கோட்பாடுகளை" பார்க்கவும்). ஒரு தீவிர பாதுகாப்பு மீறல் ஒட்டுமொத்த மதிப்பீட்டையும் வீட்டோ செய்கிறது, மேலும் மற்ற பரிமாணங்களில் நல்ல செயல்திறன் இருப்பதால் இது விலக்கப்படாது. +**கருவி இடைமுகம் (Tools)** இரு பக்கங்களாகப் பிரிந்துள்ளது. ஏஜெண்ட் வாடிக்கையாளர் வினவல், பயன்பாட்டு வினவல், தரவு நிரப்புதல், மனித முகவரிடம் மாற்றுதல் போன்ற வழங்குநர் பக்கச் செயல்களை அழைக்க முடியும்; பயனர் தன் சாதனத்தின் சுவிட்சுகளை இயக்க முடியும். இரு கருவித் தொகுப்புகளும் அணு அளவிலான செயல்கள்; "பயனரின் இணையச் சிக்கலைத் தீர்" போன்ற உயர்நிலைச் சுருக்கம் இல்லை — சுருக்க நிலை மிக உயர்ந்தால் மதிப்பீடு ஒற்றைச் செயற்கூறு அழைப்பைச் சோதிப்பதாகச் சுருங்கிவிடும், திட்டமிடலும் ஊகமும் கருவிக்குள்ளேயே உள்வாங்கப்பட்டுவிடும். -**வலிமை** என்பது நிச்சயமற்ற தன்மையை எதிர்கொள்ளும் நிலைத்தன்மையை அளவிடுகிறது: சீரற்ற விதை உணர்திறன் (வெவ்வேறு துவக்கங்களின் கீழ் செயல்திறன் எவ்வளவு மாறுபடும்), பக்க மாற்றங்களுக்குத் தகவமைப்பு (ஒரு வலைத்தள UI புதுப்பிப்பு முழுமையான தோல்வியை ஏற்படுத்தக்கூடாது), API ஜிட்டருக்கான சகிப்புத்தன்மை (தற்காலிக தோல்விகள், நேரம் முடிவடைதல், வடிவ மாற்றங்களை அது நேர்த்தியாக கையாள முடியுமா), மற்றும் நீண்ட கால நினைவக குறுக்கீடு (சூழலில் திரட்டப்பட்ட காலாவதியான தகவல் தவறான முடிவுகளுக்கு வழிவகுக்குமா). +**மதிப்பெண் அளவுகோல் (Rubric)** என்பது `evaluation_criteria` இன் நான்கு அடுக்குச் சோதனைகளும், `reward_basis` எனும் தொகுப்பு விதியும் சேர்ந்தது. -**செயல்படுத்தும் பாதை மற்றும் இறுதி முடிவின் இரட்டைக் கவரேஜ்.** மதிப்பீட்டில் பெரும்பாலும் கவனிக்கப்படாத ஒரு வேறுபாடு என்னவென்றால், "ஏஜெண்ட் செயல்படுத்தும் போது என்ன சொன்னது மற்றும் செய்தது" (அதாவது, அத்தியாயம் 1 இல் வரையறுக்கப்பட்ட பாதை) மற்றும் "அமைப்பு இறுதியில் என்ன ஆனது" (இறுதி முடிவு) ஆகியவை இரண்டு வெவ்வேறு விஷயங்கள். ஏஜெண்ட் "பதிவு முடிந்தது" என்று சொல்வது பாதை மட்டத்தில் உள்ள தகவல்; தரவுத்தளத்தில் ஒரு பதிவு உண்மையில் உருவாக்கப்படுவது முடிவு மட்டத்தில் உள்ள சரிபார்ப்பு. பாதையை மட்டும் பார்ப்பது, ஏஜெண்ட் "சொன்னது ஆனால் செய்யவில்லை" என்ற நிகழ்வுகளைத் தவறவிடும், மேலும் முடிவை மட்டும் பார்ப்பது, இடைநிலைப் படிகள் தவறாகச் சென்றதைத் தவறவிடலாம். Anthropic ஒருமுறை ஒரு உதாரணத்தைக் கொடுத்தது: ஒரு விமான முன்பதிவு ஏஜெண்ட், செயல்படுத்தும் போது விமான நிறுவனத்தின் கொள்கையில் ஒரு ஓட்டையைக் கண்டுபிடித்து, பயனருக்கு மலிவான விருப்பத்தைக் கண்டறிந்தது—முன்னரே தீர்மானிக்கப்பட்ட செயல்படுத்தும் பாதையின் படி மட்டும் மதிப்பெண் வழங்கப்பட்டால், இந்த ரன் தோல்வி என்று தீர்மானிக்கப்படும்; ஆனால் இறுதி முடிவில் இருந்து பார்த்தால், பயனருக்கு சிறந்த ஒப்பந்தம் கிடைத்தது. எனவே, முறையான குருட்டுப் புள்ளிகளைத் தவிர்க்க, இரண்டு வகையான மதிப்பீடுகளும் உள்ளடக்கப்பட வேண்டும். +**செயலாக்க நெறிமுறை (Interaction Protocol)** இடைவினையின் வரிசையையும் நிறைவு நிபந்தனைகளையும் வரையறுக்கிறது. இங்கு இயல்பான நிறைவுச் சமிக்ஞை உருவகப்படுத்தப்பட்ட பயனர் `###STOP###` ஐ வெளியிடுவது; அத்துடன் சுற்று வரம்பும் உண்டு, மேலும் பொறுமை தீர்ந்தால் உருவகப் பயனர் உரையாடலைத் தானே முடித்துக்கொள்ளலாம் — தொடர்பு திறன் மிகக் குறைவாக இருப்பதே தோல்வியாகக் கணக்கிடப்படுகிறது. -### மனித மாதிரி ஆய்வு மற்றும் எதிர்மறை மதிப்பாய்வு +ஐந்து கூறுகளில் ஒன்று குறைந்தாலும் மதிப்பீடு மீண்டும் இயக்கக்கூடிய சுழற்சியாக அமையாது. கீழே பிற தரவரிசைச் சோதனைகளை ஆராயும்போதும் இந்த ஐந்து அம்சங்களையே ஒப்பீட்டுச் சட்டகமாகக் கொள்வோம். -தானியங்கி மதிப்பீடு பெரும்பாலான சந்தர்ப்பங்களில் நம்பகமானதாக இருந்தாலும், வழக்கமான மனித சரிபார்ப்பு அவசியம்: வெவ்வேறு பணி வகைகள், வெற்றி/தோல்வி நிகழ்வுகள் மற்றும் எல்லை மதிப்பெண்களுக்கு அருகில் உள்ள தெளிவற்ற நிகழ்வுகளை உள்ளடக்கியது, முடிவுகளை மட்டும் சரிபார்க்காமல், மதிப்பெண் வழங்குவதற்கான காரணத்தின் நியாயத்தன்மையையும் மதிப்பாய்வு செய்ய வேண்டும். +### மனித-கணினி இடைவினை மற்றும் கருவி அழைப்பு வகை மதிப்பீட்டுச் சூழல்கள் -மனித சரிபார்ப்பை மேலும் முறைப்படுத்தி **நீதிபதி அளவைத் திருத்தம்** (judge calibration) ஆக மாற்றலாம்: LLM நீதிபதிகளை பெரிய அளவில் பயன்படுத்துவதற்கு முன், முதலில் மனிதர்களால் குறியிடப்பட்ட தங்கத் தரத் தொகுப்பை (எ.கா., பல்வேறு பணி வகைகள் மற்றும் சிரமங்களை உள்ளடக்கிய 100-200 நிகழ்வுகள்) உருவாக்கவும், நீதிபதி மாதிரிக்கும் (அதாவது, LLM ஐ நீதிபதியாகப் பயன்படுத்துதல், இதன் வழிமுறை அடுத்த பகுதியில் LLM-as-a-Judge இல் விரிவாக விளக்கப்பட்டுள்ளது) மனித குறியீடுகளுக்கும் இடையிலான உடன்பாட்டு விகிதத்தை (எளிய உடன்பாட்டு விகிதம் அல்லது கோஹென் கப்பா, பிந்தையது சீரற்ற உடன்பாட்டை நீக்குகிறது) அளவிடவும், முன்னரே நிர்ணயிக்கப்பட்ட வரம்பை (எ.கா., கப்பா 0.7 க்கு மேல்) அடைந்த பின்னரே பெரிய அளவிலான மதிப்பீட்டிற்கு நீதிபதி மாதிரியைப் பயன்படுத்தவும்; அதன் பிறகு, நீதிபதி மாதிரி அல்லது Rubric புதுப்பிக்கப்படும் போதெல்லாம், தங்கத் தரத் தொகுப்பில் மீண்டும் அளவீடு செய்யவும். இந்தப் படி இல்லாமல், LLM நீதிபதியின் மதிப்பெண்கள் வெறும் "மற்றொரு மாதிரியின் கருத்து" மட்டுமே, மனித தீர்ப்புக்கான நம்பகமான மாற்று அல்ல. +telecom போன்ற பணிகளுக்கு இடைவினைத் துணை கட்டாயம் தேவை; எனவே ஐந்து கூறுகளில் பயனர் உருவகப்படுத்தல் பகுதி இன்றியமையாதது. உரையாடல் துணையே இல்லாத மற்றொரு பெரும் பணி வகையும் உண்டு: குறியீடு உருவாக்கம், தரவுப் பகுப்பாய்வு, கணிதத் தீர்வு போன்றவற்றில் ஏஜெண்ட் தொடக்கம் முதல் இறுதி வரை கருவிகளுடன் மட்டுமே இடைவினைபுரிகிறது; சரியா தவறா என்பதைச் செயலாக்கச் சரிபார்ப்பில் தேறுகிறதா என்பதே தீர்மானிக்கிறது; மனித விளக்கக்குறிப்போ மாதிரியின் தீர்ப்போ தேவையில்லை. இவ்வகைச் சூழல்கள் பயனர் உருவகப்படுத்தியைத் தவிர்க்கின்றன; மீதமுள்ள நான்கு கூறுகள் இன்னும் இருக்கின்றன, வடிவம் மட்டுமே எளிமையானது: சூழல் நிலை என்பது கோப்பு முறைமையோ தரவுத்தளமோ, மதிப்பெண் அளவுகோல் என்பது ஒரு துண்டு சோதனைக் குறியீடு, செயலாக்க நெறிமுறை "பதில் தரும் வரை அல்லது சுற்றுகள் தீரும் வரை கருவிகளைத் தொடர்ந்து அழை" எனச் சுருங்குகிறது. -**எதிர்ப்பு மதிப்பாய்வு** என்பது, சவாலான நிகழ்வுகளை தீவிரமாக உருவாக்க ரெட் டீமிங்கைப் பயன்படுத்துகிறது: மறைந்த பிழைகளைக் கொண்ட வெளித்தோற்றத்தில் சரியான பதில்கள், முக்கிய வார்த்தைகளை நிரப்புவதன் மூலம் தப்பிக்கும் பதில்கள் மற்றும் நீதிபதி மாதிரியின் அறியப்பட்ட சார்புகளைப் பயன்படுத்தி தகுதியற்ற அதிக மதிப்பெண்களைப் பெறும் பதில்கள். **பல-நீதிபதி வழிமுறைகள்** பல சுயாதீன நீதிபதிகளை தனித்தனியாக மதிப்பெண் வழங்கப் பயன்படுத்துகின்றன, எடையிடப்பட்ட சராசரி அல்லது நிலைத்தன்மை சரிபார்ப்பு மூலம் இறுதி முடிவை நிர்ணயிக்கின்றன—நீதிபதிகள் கணிசமாக வேறுபடும் போது, அந்த நிகழ்வு மேலும் மனித மதிப்பாய்வுக்காகக் குறிக்கப்படுகிறது. +Verifiers கட்டமைப்பு இவ்வகைச் சூழல்களை இரு பரிமாணங்களில் அடுக்குகிறது: பணி சுற்றுகளுக்கு இடையே நிலையைத் தக்கவைக்க வேண்டுமா, தனிமைப்படுத்தல் தேவையா. `SingleTurnEnv` ஒரு கணிதக் கேள்வி கேட்டு விடையை நேரடியாகச் சரிபார்க்கப் பொருந்தும்; `ToolEnv` பல வலைப்பக்கங்களைத் தேடித் தொகுத்துப் பதிலளித்து இறுதி முடிவைச் சரிபார்க்கப் பொருந்தும்; `StatefulToolEnv` தரவுத்தளப் பதிவை மாற்றி நிலை மாற்றத்தைச் சரிபார்க்கப் பொருந்தும்; `SandboxEnv` மணற்பெட்டியில் குறியீட்டை இயக்கி வெளியீட்டுக் கோப்புகளைச் சோதிக்கப் பொருந்தும். அட்டவணை 7-1 இந்நான்கு வகைகளையும் தொகுக்கிறது; பணி நிலை, கருவி அழைப்பு, தனிமைப்படுத்தல் தேவைகளுக்கேற்பத் தேர்ந்தெடுக்க உதவும். -## தானியங்கி மதிப்பீட்டு சூழல் +அட்டவணை 7-1 Verifiers சூழல் வகைகளின் ஒப்பீடு -ஏஜெண்ட் மதிப்பீட்டிற்கு மீண்டும் மீண்டும் செய்யக்கூடிய, தானியங்கி சூழல் தேவை — வளர்ச்சியின் போது மாற்றங்களின் விளைவுகளை விரைவாக சோதிக்கக்கூடிய ஒன்று. அத்தகைய சூழலை உருவாக்க மூன்று கேள்விகளுக்கு பதில் அளிக்க வேண்டும்: எதை மதிப்பிடுவது (பணி வரையறை மற்றும் சரிபார்ப்பு அளவுகோல்கள்), யாருக்கு எதிராக மதிப்பிடுவது (ஏஜெண்டின் தொடர்பு கூட்டாளியை எவ்வாறு உருவகப்படுத்துவது), மற்றும் என்ன மதிப்பெண் அளவுகோல்களைப் பயன்படுத்துவது. +| சூழல் வகை | நிலை தக்கவைப்பு | கருவி அழைப்பு | வழக்கமான பயன்பாடு | +|---|---|---|---| +| SingleTurnEnv | இல்லை | இல்லை | ஒரு சுற்றுக் கேள்வி-பதில், கணிதம் | +| ToolEnv | இல்லை | பல சுற்று | தேடல் + தகவல் தொகுப்பு | +| StatefulToolEnv | உண்டு | பல சுற்று | தரவுத்தளப் பதிவு மாற்றம் | +| SandboxEnv | உண்டு + தனிமை | பல சுற்று | குறியீடு இயக்கமும் சோதனையும் | -### மதிப்பீட்டு சூழலின் அடிப்படை கூறுகள் +இந்தக் கட்டமைப்பு இணைச் சாம்பிளிங்கையும் trajectory தேக்ககத்தையும் ஆதரிக்கிறது; ஒவ்வொரு மதிப்பீட்டின் முழு trajectory (கவனிப்பு, செயல், வெகுமதி) சேமிக்கப்படுகிறது; பிற்பாடு ஆய்வும் மறுஇயக்கமும் எளிதாகும். மேலும், கருவியின் செயலாக்க விளைவு தற்போதைய நிலையைச் சார்ந்தது; எனவே தோல்வியின்போது வெறும் தோல்விக் கொடி அல்லாமல் தெளிவான பிழைச் செய்தியைத் திருப்ப வேண்டும் — அப்போதுதான் ஏஜெண்ட் தன் உத்தியை அதற்கேற்ப மாற்ற முடியும். -ஒரு மதிப்பீட்டு சூழல் ஐந்து கூறுகளைக் கொண்டுள்ளது — பின்வரும் பகுதிகள் தரவுத்தொகுப்பு வடிவமைப்பு மற்றும் மதிப்பெண் அளவுகோல் வடிவமைப்பில் கவனம் செலுத்தும்: +கருவி அழைப்பு வகை மதிப்பீடு கவனிக்கக்கூடிய நிலை மாற்றங்களின் சரித்தன்மையை ஆராய்கிறது; மனித-கணினி இடைவினை வகை மதிப்பீடு தொடர்பு உத்தியின் நியாயத்தன்மையை ஆராய்கிறது — முன்னது செயலைச் சரிபார்க்கிறது, பின்னது வழிநடத்தலைச் சரிபார்க்கிறது. இரு வகைச் சூழல்களின் கட்டமைப்பு ஒப்பீட்டுக்குப் படம் 7-2 ஐப் பார்க்கவும். -**தரவுத்தொகுப்பு**: ஆரம்ப நிலை, இலக்கு விளக்கம் மற்றும் விருப்பமான குறிப்பு தீர்வுகள் உட்பட பணித் தொகுப்பை வரையறுக்கிறது. +![படம் 7-2: கருவி அழைப்பு மற்றும் மனித-கணினி இடைவினை மதிப்பீட்டுச் சூழல்கள்](images/fig7-2.svg) -**சூழல் நிலை (Environment State)**: பணி செயல்பாட்டின் போது மாறக்கூடிய தகவல்களைப் பராமரிக்கிறது, நம்பகத்தன்மை மற்றும் கட்டுப்படுத்துதல் ஆகியவற்றுக்கு இடையே சமநிலை தேவைப்படுகிறது. எடுத்துக்காட்டாக, வாடிக்கையாளர் சேவை மதிப்பீட்டில், சூழல் நிலையில் தரவுத்தளத்தில் உள்ள ஆர்டர் பதிவுகள் மற்றும் பயனர் கணக்கு இருப்புகள் ஆகியவை அடங்கும். ஏஜெண்ட் `process_refund` ஐ அழைத்த பிறகு, ஆர்டர் நிலை `"delivered"` இலிருந்து `"refunded"` ஆக மாறுகிறது மற்றும் இருப்பு அதிகரிக்கிறது — இவை "மாறக்கூடிய தகவல்கள்" ஆகும். "நம்பகத்தன்மை" என்பது நிலை மாற்றங்கள் வணிக தர்க்கத்தைப் பின்பற்ற வேண்டும் (திரும்பப்பெறும் தொகை ஆர்டர் தொகையை விட அதிகமாக இருக்கக்கூடாது), மேலும் "கட்டுப்படுத்துதல்" என்பது ஒவ்வொரு சோதனையும் அதே ஆரம்ப நிலைக்கு மீட்டமைக்கப்பட முடியும் என்பதைக் கோருகிறது. +## மதிப்பீட்டுத் தரவுத்தொகுப்பின் வடிவமைப்பு -**கருவிகள் (Tools)**: ஏஜெண்ட் செய்யக்கூடிய செயல்பாடுகளின் தொகுப்பை வரையறுக்கிறது — கருவிகள் மிக உயர்நிலை சுருக்கங்களை (எ.கா., "பயனர் சிக்கலைத் தீர்க்கவும்") வழங்கக்கூடாது, மாறாக அணு செயல்பாடுகளை (எ.கா., ஆர்டரை வினவுதல், முன்பதிவை மாற்றுதல், மின்னஞ்சல் அனுப்புதல்) வழங்க வேண்டும், இது ஏஜெண்டை திட்டமிடல் மற்றும் பகுத்தறிவு மூலம் இந்த செயல்பாடுகளை இணைக்க கட்டாயப்படுத்துகிறது. +மதிப்பீட்டுச் சூழல் மேடை என்றால், தரவுத்தொகுப்பு திரைக்கதை. அதே ஐந்து கூறுகளாக இருந்தாலும், வேறு வகைப் பணிக்கு மாறும்போது நிரப்பும் முறை முற்றிலும் வேறாக இருக்கலாம்: பணிகள் எங்கிருந்து வருகின்றன, சரிபார்ப்பான் எவ்வளவு ஆழத்துக்குச் சோதிக்க முடியும், மனப்பாடத்தை எப்படித் தடுப்பது. இப்பகுதி பல பொதுத் தரவரிசைச் சோதனைகளின் வடிவமைப்பு நடைமுறையிலிருந்து தொடங்கி, மிகவும் நடைமுறையான ஒரு கேள்வியில் முடிகிறது — நீங்களே கட்டும் மதிப்பீட்டுத் தொகுப்பின் பணிகள் எங்கிருந்து வர வேண்டும்? -**மதிப்பீட்டு அளவுகோல் (Rubric)**: ஏஜெண்டின் செயல்திறனை அளவிடுகிறது, இது இருநிலை (தேர்ச்சி/தோல்வி), தொடர்ச்சியான (0 முதல் 100 புள்ளிகள் வரை), அல்லது பல பரிமாண (துல்லியம், செயல்திறன் மற்றும் பாதுகாப்பை தனித்தனியாக மதிப்பிடுதல்) ஆக இருக்கலாம். +### தரவரிசைச் சோதனைகளுக்கு இடையிலான வடிவமைப்புத் தேர்வுகளின் குறுக்கு ஒப்பீடு -**தொடர்பு நெறிமுறை (Interaction Protocol)**: தொடர்பு முறை மற்றும் முடிவு நிபந்தனைகளைக் குறிப்பிடுகிறது. +முந்தைய பகுதியில் வேறுபடுத்திய இடைவினைத் துணையின் இருப்பு அல்லது இன்மை என்பது சூழல் மட்டத்தில் முதல் அடுக்கு வேறுபாடு மட்டுமே; தரவுத்தொகுப்பு மட்டத்தில் உள்ள வேறுபாடுகளே வடிவமைப்புச் சமரசங்களை நன்கு காட்டுகின்றன. அட்டவணை 7-2 அடிக்கடி மேற்கோள் காட்டப்படும் சில தரவரிசைச் சோதனைகளை அருகருகே வைக்கிறது. -இந்த ஐந்து கூறுகளும் சேர்ந்து மீண்டும் இயக்கக்கூடிய ஒரு மதிப்பீட்டுச் சுழற்சியை உருவாக்குகின்றன. +அட்டவணை 7-2 சில ஏஜெண்ட் தரவரிசைச் சோதனைகளின் முக்கிய வடிவமைப்புத் தேர்வுகள் -![படம் 7-2: கருவி அழைப்பு மற்றும் மனித-கணினி தொடர்பு மதிப்பீட்டு சூழல்கள்](images/fig7-2.svg) +| தரவரிசைச் சோதனை | அளக்கப்படும் திறன் | பணி மூலம் | சூழலை நடிப்பது | சரிபார்ப்பான் | +|---|---|---|---|---| +| τ²-bench | வாடிக்கையாளர் சேவையில் மனித-கணினி இடைவினையும் கருவி அழைப்பும் | கையால் எழுதல் + சேர்க்கை உருவாக்கம் | பயனர் உருவகப்படுத்தி + வணிகத் தரவுத்தளம் | நான்கு அடுக்குச் சோதனைகள் `reward_basis` படி இருநிலையாகத் தொகுக்கப்படுகின்றன | +| SWE-bench Verified | மென்பொருள் மேம்பாடு, coding | GitHub இன் உண்மையான issue கள், கையால் வடிகட்டப்பட்டவை | குறியீடுக் களஞ்சியம் + சோதனைத் தொகுப்பு | FAIL\_TO\_PASS / PASS\_TO\_PASS இரட்டைச் சரிபார்ப்பு | +| AndroidWorld | Android கைபேசி GUI இயக்கம் | அளவுருவாக்கப்பட்ட வார்ப்புருக்களின் நிகழ்வாக்கம் | உண்மையான Android எமுலேட்டர் | இறுதி UI நிலை உறுதிமொழிகள் | +| OSWorld | Linux டெஸ்க்டாப் GUI இயக்கம் | முன்கூட்டி அமைக்கப்பட்ட இடைநிலையிலிருந்து தொடங்குகிறது | உண்மையான மெய்நிகர் இயந்திரம் | 134 தனித் தனி மதிப்பீட்டுச் செயற்கூறுகள் | +| Terminal-Bench | Linux முனையம் இயக்கம், coding | கையால் எழுதல் | Docker கொள்கலன் | கோப்பு முறைமைச் சோதனை + உண்மையான இயக்கம் | +| GAIA | தகவல் திரட்டும் பொது நோக்கு AI உதவியாளர் | கையால் எழுதல் + தனி இணைப்புக் கோப்புகள் | திறந்த இணையம் | துல்லியமான சரம் பொருத்தம் | -Agent-இன் பணிக்கு ஏற்ப, மதிப்பீட்டுச் சூழல்களை கருவி-அழைப்பு வகை, மனித-இயந்திர இடைவினை வகை என இரண்டாகத் தோராயமாகப் பிரிக்கலாம். +### சரிபார்ப்பான்கள் -### கருவி அழைப்பு மதிப்பீட்டு சூழல் +பணி முழுமையாக முடிந்துவிட்டது எனச் சொல்லும் நீண்ட அறிக்கையை ஏஜெண்ட் எளிதாக எழுதிவிடும்; ஆனால் உண்மையில் எதுவும் முடிந்திருக்காது. மதிப்பீட்டுக் கட்டமைப்பு, ஏஜெண்டின் சுய அறிவிப்பை அல்ல, இயந்திரம் தானாகச் சரிபார்க்கக்கூடிய உண்மைகளையே சரிபார்க்க வேண்டும். -முதன்மையாக கருவி பயன்பாட்டை நம்பியிருக்கும் பணிகளுக்கு, குறியீடு உருவாக்கம் மற்றும் தரவு பகுப்பாய்வு போன்றவை, Verifiers கட்டமைப்பு ஒரு பொதுவான வடிவமைப்பு முறையை நிரூபிக்கிறது. ஏஜெண்ட் முன் வரையறுக்கப்பட்ட கருவிகளை அழைப்பதன் மூலம் பணியை நிறைவு செய்கிறது, மேலும் சரிபார்ப்பு செயல்படுத்தக்கூடிய அளவுகோல்களை (சோதனைகள் தேர்ச்சி பெறுகின்றனவா, பதில்கள் பொருந்துகின்றனவா) அடிப்படையாகக் கொண்டது, மனித குறிப்பு அல்லது மாதிரி தீர்ப்பை நம்பாமல். +**SWE-bench Verified "சரிசெய்தல் முடிந்தது" என்பதை இரு தனிக் கூற்றுகளாகப் பிரிக்கிறது.** ஒன்று FAIL\_TO\_PASS: சரிசெய்வதற்கு முன் தோல்வி, பின் வெற்றி — சிக்கல் உண்மையிலேயே தீர்ந்ததை இது நிரூபிக்கிறது. மற்றொன்று PASS\_TO\_PASS: சரிசெய்வதற்கு முன்னும் பின்னும் வெற்றி — புதிய குறைபாடு நுழையவில்லை என்பதை இது நிரூபிக்கிறது. முதலாவதை மட்டும் சோதித்தால், இடைஞ்சலான உறுதிமொழிகளை நீக்கியோ மாற்றியோ ஏஜெண்ட் தப்பிக்க முடியும்; இரண்டாவதை மட்டும் சோதித்தால் சோதிக்காததற்குச் சமம். இரண்டையும் சேர்த்துச் சோதித்தால்தான் "சரிசெய்யப்பட்டது", "எதையும் உடைக்கவில்லை" ஆகிய இரண்டும் தனித்தனியே நிரூபிக்கக்கூடிய முடிவுகளாகின்றன. மேலும் சோதனைகளின் நிலைத்தன்மையையும் உறுதி செய்து, சில நேரம் தேறி சில நேரம் தோற்கும் நிலையற்ற சோதனைகளை (flaky test) நீக்குகிறது. -Verifiers ஒரு படிநிலை சூழல் வடிவமைப்பை அறிமுகப்படுத்துகிறது: `SingleTurnEnv` ஒற்றை-சுற்று பணிகளுக்கு (எ.கா., எளிய கேள்வி-பதில்) ஏற்றது, `ToolEnv` பல-சுற்று தானியங்கி கருவி அழைப்பு சுழல்களை ஆதரிக்கிறது, மேலும் `StatefulToolEnv` மற்றும் `SandboxEnv` நிலைமாற்ற கருவிகள் மற்றும் நீண்ட நேரம் இயங்கும் மணல் பெட்டி சூழல்களை (எ.கா., குறியீடு செயல்படுத்தல்) ஆதரிக்கின்றன. எடுத்துக்காட்டாக, `SingleTurnEnv` ஒரு கணித சிக்கலைக் கேட்டு நேரடியாக பதிலைச் சரிபார்க்க ஏற்றது; `ToolEnv` பல வலைப்பக்கங்களைத் தேடி, ஒரு பதிலை ஒருங்கிணைத்து, பின்னர் இறுதி முடிவைச் சரிபார்க்க ஏற்றது; `StatefulToolEnv` தரவுத்தள பதிவுகளை மாற்றியமைத்து, பின்னர் தரவுத்தள நிலை மாற்றங்களைச் சரிபார்க்க ஏற்றது; `SandboxEnv` ஒரு மணல் பெட்டியில் குறியீட்டை இயக்கி, பின்னர் வெளியீட்டு கோப்புகளைச் சரிபார்க்க ஏற்றது. அட்டவணை 7-2 இந்த சூழல் வகைகளை சுருக்கமாகக் கூறுகிறது, இதனால் வாசகர்கள் பணி நிலை, கருவி அழைப்புகள் மற்றும் தனிமைப்படுத்தல் தேவைகளின் அடிப்படையில் பொருத்தமான மதிப்பீட்டு சூழலைத் தேர்வு செய்யலாம். +**OSWorld இன் சரிபார்ப்பான், மேலோட்டமாக முடிந்ததுபோல் தோன்றி உள்ளடக்கத்தில் தவறான நிலைமைகளைக் கண்டறியும்.** அதில் 134 தனி மதிப்பீட்டுச் செயற்கூறுகளும் இயக்க முறைமைக்கான முழு அணுகலும் உள்ளன; கோப்பு முறைமை அமைப்பு, செயல்முறை நிலை, வலைப் பிணைப்புகள், பயன்பாடுகளின் உள் நிலை ஆகியவற்றைச் சோதிக்க முடியும். தரவுத்தளப் பணிகளில் மதிப்பீட்டு ஸ்கிரிப்ட் அறிக்கைக் கோப்பு உள்ளதா என்பதோடு நிற்காமல், தரவுத்தளத்துடன் இணைந்து SQL சரியாக இயங்கியதா என்பதைச் சரிபார்க்கிறது; உலாவிப் பணிகளில் DOM மரத்தை ஆய்ந்து, cookie மற்றும் localStorage ஐச் சோதித்து, படிவம் உண்மையில் நடைமுறைக்கு வந்ததா என உறுதிப்படுத்தப் பின்புலத்துக்குச் சரிபார்ப்புக் கோரிக்கைகளை அனுப்புகிறது. -அட்டவணை 7-2 Verifiers சூழல் வகை ஒப்பீடு +**Terminal-Bench இன் `build-linux-kernel-qemu` பணி** மூலத்திலிருந்து Linux கர்னல் 6.9 ஐக் கட்டமைத்து, `start_kernel` இல் தனிப்பயன் printk சேர்த்து, initramfs உருவாக்கி, QEMU இல் இயக்கக் கோருகிறது; வெற்றி அளவுகோல் என்பது அந்தத் தனிப்பயன் செய்தி துவக்கப் பதிவேட்டில் தோன்றுவது. ஏஜெண்ட் வெளியீட்டைப் போலியாக உருவாக்க முடியாது; முழுச் செயல்முறையையும் உண்மையாகவே முடிப்பதைத் தவிர வேறு வழியில்லை. -| சூழல் வகை | நிலை நிலைத்தன்மை | கருவி அழைப்புகள் | பொதுவான பயன்பாட்டு வழக்கு | -|--------------------|-----------------|-----------------|------------------------------------------| -| SingleTurnEnv | இல்லை | இல்லை | ஒற்றை-சுற்று கேள்வி-பதில், கணித சிக்கல்கள் | -| ToolEnv | இல்லை | பல-சுற்று | தேடல் + தகவல் ஒருங்கிணைப்பு | -| StatefulToolEnv | ஆம் | பல-சுற்று | தரவுத்தள பதிவுகளை மாற்றியமைத்தல் | -| SandboxEnv | ஆம் + தனிமைப்படுத்தல் | பல-சுற்று | குறியீடு செயலாக்கம் மற்றும் சோதனை | +### பணிகளின் கடினத்தன்மை வகைப்பாடு -கட்டமைப்பு இணை மாதிரி எடுத்தல் மற்றும் பாதை தற்காலிக சேமிப்பை ஆதரிக்கிறது. ஒவ்வொரு மதிப்பீட்டிலிருந்தும் முழுமையான பாதை (அவதானிப்புகள், செயல்கள், வெகுமதிகள்) பின்னர் பகுப்பாய்வு மற்றும் மறுஇயக்கத்திற்காக சேமிக்கப்படுகிறது. +மதிப்பீட்டுப் பணித் தொகுப்பில் வெவ்வேறு கடினத்தன்மை கொண்ட பணிகள் இருக்க வேண்டும். அப்போதுதான் மாதிரிகளின் திறன் மேம்படும்போது தொகுப்பு விரைவில் காலாவதியாகாது. -சூழல் செயல்பாடுகளின் நிலை சார்பையும் கையாள வேண்டும் — ஒரு கருவியின் செயலாக்க விளைவு தற்போதைய நிலையைப் பொறுத்தது. தோல்வி ஏற்பட்டால், எளிய தோல்வி கொடிகள் மட்டுமின்றி தெளிவான பிழை செய்திகளை வழங்க வேண்டும், இது ஏஜெண்ட் பிழைகளிலிருந்து கற்றுக்கொண்டு அதன் உத்தியை சரிசெய்ய அனுமதிக்கிறது. +GAIA இன் 466 கேள்விகளும் மூன்று கடினத்தன்மை நிலைகளாகப் பிரிக்கப்பட்டுள்ளன: Level 1 க்கு ஒன்றிரண்டு கருவிகளே போதும் (மனிதர்கள் 93.9%, GPT-4 30.3%), Level 2 பல படி சிந்தனையைக் கோருகிறது (91.8% எதிர் 9.7%), Level 3 சிக்கலான சேர்க்கையைக் கோருகிறது (87.3% எதிர் 0%). இந்த அடுக்கமைப்பு கடினத்தன்மையைக் குறிப்பதோடு நில்லாமல் நோயறிதல் மதிப்பும் கொண்டது: Level 1 இல் தோல்வி அடிப்படைக் கருவிப் பயன்பாட்டைச் சுட்டுகிறது, Level 2 பல படித் திட்டமிடலையும் தகவல் ஒருங்கிணைப்பையும், Level 3 நீண்ட வரிசைச் சிந்தனையையும் சிக்கல் மேலாண்மையையும் சுட்டுகிறது; மூன்றுக்கும் வெவ்வேறு மேம்பாட்டுத் திசைகள் பொருந்தும். -### மனித-கணினி தொடர்பு மதிப்பீட்டு சூழல் +Terminal-Bench எளிய mlflow மாதிரிப் பதிவிலிருந்து, நடுத்தரக் கடினத்தன்மை கொண்ட 7z கடவுச்சொல் உடைப்பு, git சேவையகமும் வலைச் சேவையகமும் சேர்ந்த கடினமான பல கூறு ஒருங்கிணைப்பு, மற்றும் மிகக் கடினமான FEAL வேறுபாட்டு மறையாய்வு வரை பரவியுள்ளது. -பல நிஜ-உலக பணிகள் கருவி அழைப்புகளை மட்டுமல்ல, மனித பயனர்களுடனான உரையாடல்களையும் உள்ளடக்குகின்றன. வாடிக்கையாளர் சேவை ஏஜெண்ட் தெளிவற்ற வெளிப்பாடுகளைப் புரிந்துகொள்ள வேண்டும், தேவைகளை தெளிவுபடுத்த வேண்டும், பின்தள அமைப்புகளை வினவ வேண்டும், மற்றும் பயனருடன் தகவலை உறுதிப்படுத்த வேண்டும். இத்தகைய பணிகளை மதிப்பிடுவது ஒரு அடிப்படை சவாலை எதிர்கொள்கிறது: தானியங்கி சூழலில் நிஜ பயனர்களை எவ்வாறு உருவகப்படுத்துவது? +τ²-bench மேலும் **வலைப் பணிகளை** தனியே வடிவமைக்கிறது: கொள்கைக்கு உண்மையில் பொருந்தாத நிலையில் "வாடிக்கையாளர் சேவை ரத்துக்கு ஏற்கெனவே ஒப்புதல் தந்துவிட்டது" எனப் பயனர் கூறுகிறார்; அழுத்தத்திலும் தவறான வழிநடத்தலிலும் ஏஜெண்ட் சரியான தீர்ப்பைக் காத்துக்கொள்கிறதா எனச் சோதிக்கவே இது. -முக்கிய வடிவமைப்பு கொள்கை **படிப்படியான தகவல் வெளிப்பாடு** ஆகும், இது மனித-கணினி தொடர்பு மதிப்பீட்டிற்கும் பாரம்பரிய அளவுகோல்களுக்கும் இடையிலான அடிப்படை வேறுபாடு ஆகும். பெரும்பாலான அளவுகோல்கள் முழுமையான தேவைகளை முன்கூட்டியே வெளிப்படுத்துகின்றன, ஆனால் உண்மையில், பயனர்கள் தங்கள் தேவைகளை ஆரம்பத்திலிருந்தே தெளிவாக விவரிக்க முடியாது — அவர்கள் பெரும்பாலும் "என் விமானத்தில் ஏதோ பிரச்சனை" அல்லது "இணையம் வேலை செய்யவில்லை" என்று மட்டுமே கூறுகிறார்கள். ஏஜெண்ட் செயலூக்கமான கேள்விகள் மூலம் தேவைகளை தெளிவுபடுத்த வேண்டும், மேலும் இந்த செயல்முறையே திறனின் முக்கியமான வெளிப்பாடாகும். எனவே, மதிப்பீட்டில், **உருவகப்படுத்தப்பட்ட பயனரிடமிருந்து வரும் அனைத்து தகவல்களும் ஆரம்பத்திலிருந்தே ஏஜெண்டுக்கு வெளிப்படுத்தப்படக்கூடாது**; உரையாடலின் போது படிப்படியாகவும் தேவைக்கேற்பவும் தகவல் வெளிப்படுத்தப்பட வேண்டும். +### தரவுக் கசிவைத் தடுத்தல் -τ-bench இன் தீர்வு **பயனர் உருவகப்படுத்துதல்** ஆகும்: முன்வரையறுக்கப்பட்ட வழிமுறைகளின்படி ஏஜெண்டுடன் உரையாட, மற்றொரு LLM ஐ பயனர் பாத்திரத்தில் பயன்படுத்துதல். உருவகப்படுத்தப்பட்ட பயனர் பணி வழிமுறைகளைப் பெறுகிறார் (எ.கா., "நாளைய விமானத்தை ரத்து செய்ய வேண்டும்"), உரையாடலின் போது படிப்படியாக தேவையான தகவலை ஏஜெண்டுக்கு வெளிப்படுத்துகிறார், விசாரணைகளுக்கு பதிலளிக்கிறார், மற்றும் பணி முடிந்ததும் முடிப்பு சமிக்ஞையை அனுப்புகிறார். உருவகப்படுத்தப்பட்ட பயனரின் வழிமுறை "அனைத்து தகவல்களையும் ஒரே நேரத்தில் வெளிப்படுத்த வேண்டாம், தற்போதைய படிக்கு தேவையானதை மட்டும் வழங்கவும்" மற்றும் "வழிமுறைகளில் வழங்கப்படாத தகவலை உருவாக்க வேண்டாம்" என்று கோருகிறது. பயனர் உருவகப்படுத்துதலின் வடிவமைப்பு நம்பகத்தன்மை மற்றும் கட்டுப்படுத்தக்கூடிய தன்மைக்கு இடையே ஒரு சமநிலை தேவைப்படுகிறது: நடத்தை நிஜ பயனருக்கு நெருக்கமாக இருக்க வேண்டும் (தெளிவற்ற வெளிப்பாடுகள், முழுமையற்ற தகவல், எப்போதாவது உணர்ச்சி ஏற்ற இறக்கங்கள்) அதே நேரத்தில் மறுஉருவாக்கத்தை உறுதி செய்ய ஒரு குறிப்பிட்ட ஸ்கிரிப்டைப் பின்பற்ற வேண்டும். +**GAIA தன் விடைகளை இணையத்தில் நேரடியாகத் தேட முடியாதவாறு ஆக்குகிறது.** அதன் பணிகள் கருத்தளவில் எளியவை, ஆனால் பாதை திறந்தது: எடுத்துக்காட்டாக, ஒரு குறிப்பிட்ட நாளின் NASA வானியல் படத்திலிருந்து தொடங்கி, படத்திலுள்ள விண்வெளி வீரரை அடையாளம் கண்டு, அவர் சேர்ந்திருந்த விண்வெளி வீரர் குழுவைக் கண்டறிந்து, அக்குழுவில் விண்வெளியில் மிகக் குறைந்த நேரம் இருந்தவரைக் கணக்கிட்டு, "குடும்பப் பெயர், அரைப்புள்ளியால் பிரிக்கப்பட்டது, ஆயிரப் பிரிப்பான்களுடன்" என்ற வடிவத்தில் கண்டிப்பாக வெளியிட வேண்டும். விடை மிகவும் குறிப்பானது; சரியா தவறா என்பது துல்லியமான சரம் பொருத்தத்தால் தீர்மானிக்கப்படுகிறது. கசிவுத் தடுப்பு இரண்டைச் சார்ந்தது: முதலாவதாக, பல தகவல் மூலங்களைச் சேர்த்தால்தான் கேள்விக்குப் பதிலளிக்க முடியும், தனி வலைப்பக்கம் விடையை நேரடியாகத் தராது; இரண்டாவதாக, சில பணிகளுக்குத் தனியே தயாரிக்கப்பட்ட இணைப்புக் கோப்புகள் உள்ளன (இணையத்தில் இல்லாத PDF, ஒலி, படங்கள்). -படிப்படியான தகவல் வெளிப்பாட்டுடன் கூடிய பல-சுற்று உரையாடலுக்கான உதாரணம் கீழே உள்ளது (பயனர் உருவகப்படுத்தி ஒரு நிலையான ஸ்கிரிப்டின் படி செயல்படுகிறது): +**AndroidWorld ஒரே வார்ப்புருவிலிருந்து ஏராளமான நிகழ்வுகளை உருவாக்குகிறது.** அதன் பணிகள் நிலையான உரை அல்ல, மாறாக இயங்குநிலையில் நிகழ்வாக்கக்கூடிய வார்ப்புருக்கள்; எடுத்துக்காட்டாக "`[CONTACT_NAME]` தொடர்பின் தொலைபேசி எண்ணை `[NEW_PHONE]` ஆக மாற்று" — ஒவ்வொரு மதிப்பீட்டிலும் அளவுரு மதிப்புகள் சீரற்ற முறையில் உருவாக்கப்படுகின்றன. இதனால் மூன்று பயன்கள்: அளவுருக்கள் ஒவ்வொரு முறையும் வேறுபடுவதால் நிலையான செயல் வரிசையை மறுஇயக்கம் செய்வது பயனற்றது; ஒரே வார்ப்புரு கிட்டத்தட்ட வரம்பற்ற நிகழ்வுகளை உருவாக்கும்; சில அளவுருக்களை நிலைநிறுத்தி மற்றவற்றை மாற்றுவதன் மூலம் ஒரு குறிப்பிட்ட காரணியின் தாக்கத்தைத் துல்லியமாக அளக்க முடியும். -> **பயனர்**: "என் விமானத்தில் ஒரு பிரச்சனை உள்ளது." -> **ஏஜெண்ட்**: "எந்த விமானம் அது?" -> **பயனர்** (ஸ்கிரிப்டின் படி வெளிப்படுத்துகிறார்): "டெல்டா 123, நாளை காலை சான் பிரான்சிஸ்கோவிலிருந்து நியூயார்க்கிற்கு." -> **ஏஜெண்ட்**: "குறிப்பிட்ட பிரச்சனை என்ன?" -> **பயனர்** (ஸ்கிரிப்டின் படி வெளிப்படுத்துகிறார்): "விமான நேரம் மிகவும் நீண்டுள்ளது, அதை மாற்ற விரும்புகிறேன்." -> **ஏஜெண்ட்**: "புதிய விமானத்திற்கு ஏதேனும் விருப்பங்கள் உள்ளதா?" -> **பயனர்** (ஸ்கிரிப்டின் படி வெளிப்படுத்துகிறார்): "எந்த மதிய விமானமும் சரிதான்." +**Terminal-Bench கேள்வி உரையில் கேனரி அடையாளத்தைப் பதிக்கிறது.** ஒவ்வொரு கேள்வியும் ஒரு canary GUID ஐச் சுமக்கிறது; அந்த GUID அடங்கிய உள்ளடக்கத்தை மாதிரி வெளியிட முடிந்தால், தரவரிசைச் சோதனைத் தரவு பயிற்சித் தொகுப்புக்குள் நுழைந்துவிட்டது என்று பொருள். இது கசிவைத் தடுக்காது, ஆனால் கசிவைக் கண்டறியக்கூடியதாக்குகிறது. -பயனர் உருவகப்படுத்தி ஒரு நிலையான ஸ்கிரிப்டைப் (தெரிந்த தகவல் + வெளிப்படுத்தும் விதிகள்) பின்பற்றுகிறது, இது மதிப்பீட்டின் மறுஉருவாக்கத் திறனை உறுதி செய்கிறது, அதே நேரத்தில் உண்மையான பயனரின் படிப்படியான வெளிப்பாட்டு பாணியை உருவகப்படுத்துகிறது. உருவகப்படுத்தப்பட்ட பயனருக்கு **வரம்புக்குட்பட்ட பொறுமையும்** அமைக்கப்படுவது வழக்கம்: Agent-இன் தொடர்பு திறன் குறைவாக இருந்தால், உருவகப் பயனர் உரையாடலை முடித்துவிடலாம்; பணி தோல்வியில் முடியும். +### தரக் கட்டுப்பாடும் நீண்டகாலப் பராமரிப்பும் -τ-bench என்பது கட்டமைக்கப்பட்ட வணிக செயல்முறைகளில் (எ.கா., விமான நிறுவன வாடிக்கையாளர் சேவை, சில்லறை வணிக வாடிக்கையாளர் சேவை) ஏஜெண்ட் செயல்திறனை மதிப்பிடுவதற்கான ஒரு அளவுகோலாகும். இதன் சரிபார்ப்புகள் கூறு-நிலை மற்றும் பல-பரிமாணத்தில் உள்ளன: ஒருபுறம், இறுதி தரவுத்தள நிலை சரியாக உள்ளதா என்பதைச் சரிபார்க்கிறது (எ.கா., முன்பதிவு பதிவின் நிலை "ரத்து செய்யப்பட்டது" என மாறுகிறது); மறுபுறம், உரையாடலின் போது ஏஜெண்ட் தேவையான முக்கிய தகவல்களை வெளியிட்டதா என்பதைச் சரிபார்க்கிறது (எ.கா., பணத்தைத் திரும்பப் பெறும் தொகை மற்றும் வருகை நேரம், குறிப்பிட்ட சரங்கள் அல்லது வடிவங்களைத் தேடி சரிபார்க்கப்படுகிறது). இந்த இரட்டை சரிபார்ப்பு ஒரே நேரத்தில் செயல்பாட்டுத் துல்லியத்தையும் தகவல் தொடர்பு செயல்திறனையும் ஆய்வு செய்கிறது. இருப்பினும், பணி மட்டத்தில், இந்த சரிபார்ப்புகள் இறுதியில் **பூஜ்ஜியம் அல்லது ஒன்று என்ற இரும வெகுமதியாக** ஒருங்கிணைக்கப்படுகின்றன — மதிப்பெண் 1 பெற அனைத்து சரிபார்ப்புகளும் நிறைவேற வேண்டும், மேலும் ஏதேனும் ஒரு தோல்வி மதிப்பெண் 0 ஐ ஏற்படுத்தும். இரும வெகுமதிகள் Pass^k போன்ற நம்பகத்தன்மை அளவீடுகளைக் கணக்கிட உதவுகின்றன (பின்னர் "மதிப்பீட்டு அளவீட்டு முறைமை" பகுதியைப் பார்க்கவும்), ஆனால் "செயல்பாட்டு ரீதியாக துல்லியமானது ஆனால் முக்கியமற்ற புலம் ஒன்றைக் காணவில்லை" மற்றும் "முழுமையான தோல்வி" ஆகிய இரண்டிற்கும் ஒரே மதிப்பெண்ணை வழங்கும் விலையை இது கொண்டுள்ளது. +உயர் தரமான மதிப்பீட்டுத் தொகுப்பை உருவாக்குவது மிகவும் கடினம். மேலே குறிப்பிட்ட பெரும்பாலான தரவரிசைச் சோதனைகளின் தற்போதைய வடிவம், முதல் பதிப்பு பயன்பாட்டுக்கு வந்து சிக்கல்கள் வெளிப்பட்ட பின் சுற்றுச் சுற்றாகச் சரிசெய்ததன் விளைவே. எடுத்துக்காட்டாக, τ-bench இலிருந்து τ²-bench வரை ஐந்து இடங்கள் மறுவடிவமைக்கப்பட்டன. -மேம்படுத்தப்பட்ட **τ²-bench** இன் முக்கிய மேம்பாடுகள் மதிப்பெண் நுணுக்கத்தில் இல்லை, மாறாக இரண்டு புள்ளிகளில் உள்ளன: முதலாவதாக, **இரட்டை-கட்டுப்பாட்டு சூழல்** — இனி ஏஜெண்ட் மட்டுமே கருவிகளை அழைக்க முடியாது; பயனர் உருவகப்படுத்தியும் அதே பகிரப்பட்ட சூழலில் செயல்பட முடியும் (எ.கா., ஏஜெண்ட் பயனரை விமானப் பயன்முறைக்கு மாற்றுமாறு அறிவுறுத்துகிறது, மேலும் பயனரின் செயல் உண்மையில் சூழல் நிலையை மாற்றுகிறது), இது பயனர் ஒத்துழைப்பு தேவைப்படும் தொழில்நுட்ப ஆதரவு போன்ற நிஜ உலக காட்சிகளுக்கு நெருக்கமானது; இரண்டாவதாக, **மிகவும் துல்லியமான பணி விவரக்குறிப்புகள் மற்றும் கலவை பணி உருவாக்கம்** — வெற்றி நிபந்தனைகளில் குறைவான தெளிவின்மைகள், மேலும் குறிப்பிட்ட பணி நிகழ்வுகளை அளவுருவாக்கம் செய்து தொகுப்பாக உருவாக்க முடியும் (விரிவான சரிபார்ப்பு பரிமாணங்களுக்கு பின்னர் "சரிபார்ப்புத் திறன் மற்றும் புறநிலைத் தன்மையை உறுதி செய்தல்" பகுதியைப் பார்க்கவும்). +முதலாவதாக, **பணி வழிமுறைகள் மிகவும் பொதுவாக இருந்ததால் விடையை ஊகிக்க முடிந்தது**. முதல் பதிப்பின் வழிமுறைகள் விரிவாக எழுதப்பட்டிருந்ததால், மாதிரி கோரிக்கையை உண்மையிலேயே தெளிவுபடுத்த வேண்டியிருக்கவில்லை; பொது அறிவால் ஒரு நடைமுறையை ஊகித்தாலே தேறிவிட முடிந்தது. τ²-bench திரைக்கதையை `known_info`, `task_instructions` என இரு நெடுவரிசைகளாகப் பிரித்தது: முதலாவது பயனர் அறிந்தவற்றின் எல்லையை வரையறுக்கிறது, இரண்டாவது வெளிப்படுத்தும் முறையை ஒழுங்குபடுத்துகிறது. பயனர் அறியாதவற்றை ஏஜெண்ட் ஊகிக்க வழியில்லை; வினவலால் மட்டுமே பெற முடியும். -> **சோதனை 7-1 ★: τ²-bench ஐ இயக்கி, அதன் பரிணாமத்தை τ-bench உடன் ஒப்பிடுக** -> -> இந்த சோதனையானது, மனித-கணினி தொடர்பு மதிப்பீட்டு சூழல்களின் வடிவமைப்புக் கொள்கைகளைப் புரிந்துகொள்ள τ²-bench மதிப்பீட்டு கட்டமைப்பைப் பயன்படுத்துகிறது. τ-bench மற்றும் τ²-bench இடையேயான வேறுபாடுகளை ஒப்பிடுவதன் மூலம், மதிப்பீட்டு தரவுத்தொகுப்புகள் எவ்வாறு மீண்டும் மீண்டும் மேம்படுத்தப்படுகின்றன என்பதைக் காணலாம். -> -> பணி வரையறை கோப்புகளை ஆழமாகப் படிக்கவும்: ஒவ்வொரு பணியிலும் அறியப்பட்ட தகவல்கள் (பயனரின் பின்னணி அறிவு), பணி வழிமுறைகள் (தகவல்களை படிப்படியாக வெளிப்படுத்துவதற்கும் பதில் உத்திகளுக்கும் வழிகாட்டுதல்), மற்றும் வெற்றி நிபந்தனைகள் (தரவுத்தளத்தின் இலக்கு நிலை மற்றும் உரையாடலில் தோன்ற வேண்டிய உறுதிப்படுத்தல் தகவல்கள்) ஆகியவை உள்ளன. முழுமையான மதிப்பீட்டு செயல்முறையை இயக்கவும், பயனர் உருவகப்படுத்தி மற்றும் ஏஜெண்ட் இடையேயான பல-சுற்று உரையாடலைக் கவனிக்கவும், மற்றும் பொதுவான தோல்வி முறைகளை (கொள்கை மீறல்கள், தகவல் குறைபாடுகள், மனித ஏஜெண்டுகளுக்கு அதிகப்படியான கையளிப்பு போன்றவை) பகுப்பாய்வு செய்யவும். -> -> -> ![படம் 7-3: τ²-bench மதிப்பீட்டு கட்டமைப்பு](images/fig7-3.svg) -> -> -> τ-bench மற்றும் τ²-bench இடையேயான வடிவமைப்பு வேறுபாடுகளை ஒப்பிடுக: τ-bench இன் ஆரம்ப பதிப்பில் மிகவும் எளிமையான பயனர் வழிமுறைகள் (ஏஜெண்ட் பதிலை யூகிக்க முடியும்), துல்லியமற்ற வெற்றி நிபந்தனைகள் (தவறான தீர்ப்புகளுக்கு வழிவகுத்தது), மற்றும் ஒரு இயந்திரத்தனமான பயனர் உருவகப்படுத்தி ஆகியவை இருந்தன. τ²-bench இந்த சிக்கல்களைத் தீர்க்க முறையான மேம்பாடுகளைச் செய்தது: -> -> - **விரிவான பணி வழிமுறைகள் அறிமுகப்படுத்தப்பட்டன**: "அடிப்படை தேவைகள்" (Grounding Requirements) உட்பட, அதாவது பதில்கள் சூழலின் உண்மையான நிலையை அடிப்படையாகக் கொண்டிருக்க வேண்டும் -> - **துல்லியமான மதிப்பீட்டு அளவுகோல்கள்**: உதாரணமாக, "ஒரு வேக சோதனை 'சிறந்தது' என்று திரும்பினால் மட்டுமே தீர்க்கப்பட்டதாக கருதப்படும்" -> - **மிகவும் யதார்த்தமான பயனர் உருவகப்படுத்தி நடத்தை விவரக்குறிப்புகள்**: படிப்படியான தகவல் வெளிப்பாடு, இயற்கையான உணர்ச்சி ஏற்ற இறக்கங்கள் -> -> τ²-bench இல் புதிதாக சேர்க்கப்பட்ட தொலைத்தொடர்பு கள பணிகளுக்கு சிறப்பு கவனம் செலுத்தவும், மேலும் அதன் இரட்டை-கட்டுப்பாட்டு சூழல் வடிவமைப்பைப் புரிந்துகொள்ளவும் (முன்பு குறிப்பிட்டது போல், பயனர் மற்றும் ஏஜெண்ட் ஒரே பகிரப்பட்ட சூழலை இணைந்து இயக்குகின்றனர்). -> +இரண்டாவதாக, **வெற்றி நிபந்தனைகள் போதிய துல்லியம் இல்லாததால் சரிபார்ப்பு தவறாகத் தீர்ப்பளித்தது**. "வலையமைப்பு மீண்டுவிட்டது" போன்ற நிபந்தனைக்குச் சரிபார்க்கக்கூடிய எல்லை இல்லை. τ²-bench இதை "வேகச் சோதனை excellent எனத் திரும்பினால் மட்டுமே தீர்ந்ததாகக் கருதப்படும்; poor, fair, good ஏற்கப்படாது" என மாற்றியது. இந்த மாற்றம் **மேலோட்டமான சரிசெய்தல்களை** இலக்காகக் கொள்கிறது — அறிகுறியை அடக்கிவிட்டு மூல காரணத்தைத் தீர்க்காதவை. -கருவி அழைப்பு மதிப்பீடுகள் "கவனிக்கக்கூடிய நிலை மாற்றம் முடிக்கப்பட்டுள்ளதா" என்பதில் கவனம் செலுத்துகின்றன, மனித-கணினி தொடர்பு மதிப்பீடுகள் "பயனர் ஒரு அறிவாற்றல் அல்லது முடிவெடுக்கும் மாற்றத்தின் மூலம் வழிநடத்தப்பட்டுள்ளாரா" என்பதில் கவனம் செலுத்துகின்றன. முந்தையது ஏஜெண்டின் செயல்களின் சரியான தன்மையை ஆராய்கிறது, பிந்தையது அதன் தகவல்தொடர்பு உத்தியின் நியாயத்தன்மையை ஆராய்கிறது. +மூன்றாவதாக, **பயனர் உருவகப்படுத்தியின் நடத்தை மிகவும் இயந்திரத்தனமாக இருந்தது**. முதல் பதிப்பின் உருவகப் பயனர் செயலற்ற முறையில் பதிலளித்தது மட்டுமே. τ²-bench அதற்கு உணர்வையும் (முதல் சரிசெய்தல் தோல்வியுற்றபின் அதிருப்தி காட்டுதல்), பொறுமை வரம்பையும் (தொடர்பு மிகவும் திறனற்றால் உரையாடலை முடித்தல்), உண்மைநிலை நங்கூரத் தேவையையும் சேர்த்தது. மூன்றும் சேர்ந்து உருவகப்படுத்தியை உண்மையான பயனருக்கு நெருக்கமாக்கும் அதே வேளையில் மறுஉருவாக்கத் தன்மையையும் காக்கின்றன. -மதிப்பீட்டு சூழலின் கட்டுமானம் உருவகப்படுத்துதல் சூழல்களின் வடிவமைப்பையும் உள்ளடக்கியது. மதிப்பீட்டு சூழல் பெரிய அளவிலான மீண்டும் மீண்டும் தொடர்புகளை ஆதரிக்க வேண்டியிருக்கும் போது, அது ஒரு உருவகப்படுத்துதல் சூழலாக உருவாகிறது. இது இந்த அத்தியாயத்தின் முடிவில் சுருக்கமாக விவாதிக்கப்படும். +நான்காவதாக, **பயனர் உரையாடலில் மட்டுமல்ல, செயல்பாட்டிலும் பங்கேற்கிறார்**. telecom களம் இரட்டைக் கட்டுப்பாட்டுச் சூழலை அறிமுகப்படுத்தியது. முந்தைய மதிப்பீடுகளில் ஏஜெண்ட் மட்டுமே சூழலை மாற்ற முடிந்தது; ஆனால் தொழில்நுட்ப ஆதரவு போன்ற சூழல்களில் கணிசமான செயல்களை உண்மையில் பயனரே தன் சாதனத்தில் செய்ய வேண்டும். இரட்டைக் கட்டுப்பாடு சரிபார்ப்புக்கு மேலும் ஒரு பரிமாணத்தைச் சேர்க்கிறது: பயனர் நிலையை மாற்றிய பிறகு, ஏஜெண்ட் கருவியை மீண்டும் அழைத்தால்தான் முடிவை அறிய முடியும்; எனவே சரிபார்ப்பு இப்போது "பயனர் பக்கச் செயலின் முடிவை ஏஜெண்ட் உண்மையில் படித்ததா" என்பதையும் உள்ளடக்குகிறது. -## மதிப்பீட்டு பணி தரவுத்தொகுப்புகளின் வடிவமைப்பு +ஐந்தாவதாக, **பணி நிகழ்வுகள் இயங்குநிலையில் உருவாக்கப்படுகின்றன**. τ²-bench இன் குறிப்பான நிகழ்வுகளை (பயனர் பெயர்கள், எண்கள், கோளாறுச் சேர்க்கைகள்) அளவுருவாக்கித் தொகுதியாக உருவாக்க முடியும்; இது பரவலையும் கசிவு எதிர்ப்பையும் ஒருசேர மேம்படுத்துகிறது. -மதிப்பீட்டுச் சூழல் "மேடை", தரவுத்தொகுப்பு "திரைக்கதை" — திரைக்கதையின் வடிவமைப்புத் தரமே, மேடையை விடவும், மதிப்பீட்டின் மதிப்பைத் தீர்மானிப்பது வழக்கம். மோசமாக வடிவமைக்கப்பட்ட தரவுத்தொகுப்பு, சரியான சூழலில் இயக்கப்பட்டாலும், இரைச்சலையே தரும். GAIA, AndroidWorld, SWE-Bench Verified (Software Engineering Benchmark, மென்பொருள் பொறியியல் அளவுகோல்), τ-bench மற்றும் τ²-bench, Terminal-Bench, OSWorld மற்றும் OSWorld-Verified போன்ற அளவுகோல்களின் வடிவமைப்பு நடைமுறைகளிலிருந்து, மீண்டும் மீண்டும் சரிபார்க்கப்பட்ட சில கொள்கைகளை இந்தப் பகுதி பிரித்தெடுக்கிறது. +**SWE-bench Verified: வெளியீட்டுக்கு முன் மூலப் பணிகளில் 71% நீக்கப்பட்டன.** OpenAI மூல 2294 பணிகளிலிருந்து 1699 ஐச் சீரற்ற முறையில் எடுத்து மனித மதிப்பீட்டுக்கு அளித்து, Python இல் தேர்ச்சி பெற்ற 93 உருவாக்குநர்களை ஒவ்வொன்றாகச் சோதிக்கத் திரட்டியது: சிக்கல் விளக்கம் தெளிவாக உள்ளதா, சோதனை வழக்குகள் விளிம்பு நிலைமைகளை உள்ளடக்குகின்றனவா, சோதனைகள் நிலையானவையா, மேற்கோள் patch புதிய பிழைகளை நுழைக்கிறதா, கடினத்தன்மை நியாயமானதா. இறுதியில் 500 மட்டுமே தேறின. உயர் நீக்க விகிதம் சிறந்த சமிக்ஞை-இரைச்சல் விகிதத்தைத் தருகிறது; மதிப்பீட்டுச் செலவும் சுமார் 80% குறைகிறது. சிக்கலான ஏஜெண்ட் பணிகள் அடிக்கடி சில நிமிடங்கள் முதல் சில மணி நேரம் வரை எடுக்கும்; முன்னணி மாதிரியுடன் ஒரு மதிப்பீட்டுத் தொகுப்பை முழுமையாக இயக்குவது பெரும்பாலும் ஆயிரக்கணக்கான டாலர் டோக்கன் செலவைக் கோரும்; எனவே மதிப்பீட்டுச் செலவைக் குறைப்பது மிக முக்கியம். -> **சோதனை 7-2 ★: அளவுகோல் பணிகளை கைமுறையாக செயல்படுத்துதல்** +**OSWorld: வெளியீட்டுக்குப் பிந்தைய 15 மாதங்களில் 300 க்கும் மேற்பட்ட சிக்கல்கள் வெளிப்பட்டன.** 2024 ஏப்ரலில் வெளியான பிறகு பன்முறை ஏஜெண்ட் மதிப்பீட்டுக்கு முக்கியத் தரவரிசைச் சோதனையாக விரைவில் மாறியது; ஆனால் பரவலான பயன்பாட்டில் நான்கு வகைச் சிக்கல்கள் வெளிப்பட்டன: சூழல் சிக்கல்கள் (தளங்களின் ஸ்கிராப்பிங் தடுப்பு, CAPTCHA, இயங்குநிலை உள்ளடக்க மாற்றம்), பணி விளக்கச் சிக்கல்கள் (இருபொருள் தரும் சொற்றொடர்கள்), சரிபார்ப்பு தர்க்கச் சிக்கல்கள் (மிகக் கடுமை அல்லது மிகத் தளர்வு), தொடக்க நிலைச் சிக்கல்கள் (முழுமையற்ற அமைவு). ஹாங்காங் பல்கலைக்கழகக் குழு சுமார் 10 பேர் கொண்ட அணியை அமைத்து, MoonShot AI, OpenAI, ByteDance Seed TARS, Anthropic, Simular போன்றவற்றுடன் இரு மாதங்கள் நெருக்கமாகப் பணியாற்றி முறையாகச் சரிசெய்தது: சூழல் சிக்கல்கள் பதிப்புப் பூட்டலாலும் ஆஃப்லைன் காப்புப் பிரதிகளாலும், விளக்கச் சிக்கல்கள் இருபொருள் சொற்றொடர்களை மறுவடிவமைத்தும், சரிபார்ப்புச் சிக்கல்கள் கையால் சரியான அடிப்படைக் கோட்டை அமைத்து நிபந்தனைகளைச் சரிசெய்தும், தொடக்க நிலைச் சிக்கல்கள் முழுமைச் சோதனைகளைச் சேர்த்தும் தணிக்கப்பட்டன. + +> **சோதனை 7-2 ★: தரவரிசைச் சோதனைப் பணிகளைக் கையால் செய்தல்** > -> GAIA, AndroidWorld, SWE-Bench Verified, τ²-bench, Terminal-Bench மற்றும் OSWorld-Verified ஆகியவற்றிலிருந்து தலா ஒரு பணியைத் தேர்ந்தெடுத்து அவற்றை கைமுறையாக முடிக்கவும். ஒவ்வொரு தரவுத்தொகுப்பிலிருந்தும் ஒரு எளிய, ஒரு நடுத்தர மற்றும் ஒரு கடினமான பணியை முடிக்க பரிந்துரைக்கப்படுகிறது—"கடினமான" நிலை மனிதர்களுக்கும் சவாலாக இருக்க வேண்டும். உங்கள் செயலாக்க முடிவுகளை நிலையான பதில்களுடன் ஒப்பிட்டு, வேறுபாடுகளின் மூலங்களை பகுப்பாய்வு செய்யவும். இந்த நேரடி அனுபவத்தின் மூலம் புரிந்துகொள்ளுங்கள்: பணி விளக்கங்கள் தெளிவு மற்றும் திறந்த தன்மையை சமநிலைப்படுத்த வேண்டும், சரிபார்ப்பு தரநிலைகள் புறநிலை மற்றும் செயல்படுத்தக்கூடியதாக இருக்க வேண்டும், மேலும் பணிகளின் படிநிலை சிரமம் வெவ்வேறு திறன் நிலைகளை வேறுபடுத்தி அறிய முடியும். +> GAIA, AndroidWorld, SWE-Bench Verified, Terminal-Bench, OSWorld-Verified ஆகியவற்றிலிருந்து பணிகளைத் தேர்ந்தெடுத்து உங்கள் கையாலேயே முடியுங்கள்; ஒவ்வொரு தரவுத்தொகுப்பிலும் ஒரு எளிய, ஒரு நடுத்தர, ஒரு கடினமான பணி பரிந்துரைக்கப்படுகிறது. "கடினம்" நிலை மனிதருக்கும் சவாலானது. > +> முடித்த பிறகு இரு கேள்விகளுக்குப் பதிலளியுங்கள். அப்பணியின் விளக்கம் ஒன்றுக்கு மேற்பட்ட நியாயமான விளக்கங்களை அனுமதிக்கிறதா; அனுமதித்தால் சரிபார்ப்பான் எதை ஏற்கிறது? வேலையைச் செய்யாமல் தப்பிக்க முயன்றால் மலிவான வழி எது, அதைச் சரிபார்ப்பான் தடுக்க முடியுமா? -### பணி தரவுத்தொகுப்பு வடிவமைப்பில் முக்கிய சவால்கள் - -**சவால் ஒன்று: தெளிவுக்கும் திறந்த தன்மைக்கும் இடையிலான பதற்றம்.** பணி விளக்கங்கள் மீண்டும் உருவாக்கக்கூடிய மதிப்பீட்டை உறுதிப்படுத்த போதுமான தெளிவாக இருக்க வேண்டும், ஆனால் ஏஜெண்டின் படைப்பாற்றலை முடக்கும் அளவுக்கு கடுமையாக இருக்கக்கூடாது. GAIA ஒரு உதாரணத்தை வழங்குகிறது: பணிகள் "கருத்தியல் ரீதியாக எளிமையானவை" ஆனால் திறந்த செயலாக்க பாதைகளைக் கொண்டுள்ளன—எடுத்துக்காட்டாக, NASA வின் Astronomy Picture of the Day இலிருந்து விண்வெளி வீரர் தகவலைக் கண்டுபிடிக்க வேண்டும். இலக்கு தெளிவாக உள்ளது (ஒரு குறிப்பிட்ட விண்வெளி வீரர் மற்றும் அவர்கள் விண்வெளியில் இருந்த நேரத்தைக் கண்டறிதல்), ஆனால் எவ்வாறு தேடுவது, வடிகட்டுவது மற்றும் சரிபார்ப்பது என்பது முற்றிலும் ஏஜெண்டின் தன்னாட்சி முடிவெடுப்பைப் பொறுத்தது. +### மதிப்பீட்டுத் தொகுப்பின் மூன்று மூலங்கள் -**சவால் இரண்டு: நம்பகத்தன்மை மற்றும் கட்டுப்படுத்துதிறன் ஆகியவற்றை சமநிலைப்படுத்துதல்.** நிஜ உலக பணிகளில் நிச்சயமற்ற தன்மை மற்றும் இரைச்சல் உள்ளன, அவை வலிமையை வெளிப்படுத்தலாம் ஆனால் மறுஉருவாக்கத்தையும் அச்சுறுத்தலாம். SWE-Bench இன் ஆரம்ப பதிப்பு நேரடியாக உண்மையான GitHub சிக்கல்களைப் பயன்படுத்தியது, இது நம்பகத்தன்மையை உறுதி செய்தது, ஆனால் தெளிவற்ற பணி விளக்கங்கள், முழுமையற்ற சோதனை வழக்குகள் மற்றும் அகநிலை மதிப்பீட்டு அளவுகோல்களுக்கும் வழிவகுத்தது. SWE-Bench Verified மனித நிபுணர்களால் முறையான சரிபார்ப்பை அறிமுகப்படுத்தியது, தெளிவான சிக்கல்கள், போதுமான சோதனைகள் மற்றும் தெளிவான தீர்வுகளுடன் 500 உயர்தர பணிகளை வடிகட்டியது, நம்பகத்தன்மையைப் பேணும்போது கட்டுப்படுத்துதிறனை கணிசமாக மேம்படுத்தியது. +பொதுத் தரவரிசைச் சோதனைகள் மாதிரி தரவரிசைக்கே உதவுகின்றன, உண்மையான வணிகத்துடன் தொடர்பு குறைவு என்பது பரவலான கருத்து. பொதுத் தரவரிசைச் சோதனைகளின் மதிப்பெண்கள் தயாரிப்பு முடிவுகளை நேரடியாக வழிநடத்துவது கடினம் என்பது உண்மைதான்; ஆனால் அவற்றின் வடிவமைப்பு உத்திகள் முழுமையாகக் கடத்தக்கூடியவை. மேலே விவாதித்த சரிபார்ப்பின் ஆழம், அளவுருவாக்க உருவாக்கம், கசிவுத் தடுப்பு, தரப் பராமரிப்பு ஆகியவையே நீங்களே கட்டும் மதிப்பீட்டுத் தொகுப்பில் மிக எளிதாக விடுபடும் இடங்கள். -**சவால் மூன்று: பன்முகத்தன்மை மற்றும் முறைப்படுத்தலை ஒருங்கிணைத்தல்.** ஒரு பயனுள்ள தரவுத்தொகுப்பு வழக்கமான காட்சிகள், விளிம்பு நிலை வழக்குகள் மற்றும் பிழை பொறிகள் ஆகியவற்றை உள்ளடக்கியிருக்க வேண்டும், அதே நேரத்தில் மதிப்பீட்டு முடிவுகள் குறிப்பிட்ட திறன் பலவீனங்களைக் கண்டறியும் வகையில் ஒரு முறையான அமைப்பையும் கொண்டிருக்க வேண்டும். AndroidWorld இன் 116 பணிகள் 20 உண்மையான பயன்பாடுகளில் பரவியுள்ளன, ஒவ்வொரு பணியும் தேவையான முக்கிய திறன்களுக்காக (பல-படி திட்டமிடல், காட்சி புரிதல், தற்காலிக பகுத்தறிவு) குறிப்பிடப்பட்டுள்ளன. இது மதிப்பீட்டு முடிவுகள் ஒட்டுமொத்த வெற்றி விகிதத்தை மட்டும் வழங்காமல், குறிப்பிட்ட திறன் பரிமாணங்களில் பலம் மற்றும் பலவீனங்களையும் வெளிப்படுத்த அனுமதிக்கிறது. மிக முக்கியமாக, ஒரு அளவுருவாக்க பொறிமுறையானது கிட்டத்தட்ட வரம்பற்ற பணி மாறுபாடுகளை உருவாக்க முடியும். +உற்பத்திச் சூழலின் மதிப்பீட்டுத் தொகுப்புக்குப் பொதுவாக மூன்று மூலங்கள் உண்டு. -**சவால் நான்கு: மதிப்பீட்டு செலவு எதிராக கவரேஜ்.** சிக்கலான ஏஜெண்ட் பணிகள் நிமிடங்கள் அல்லது மணிநேரங்கள் கூட ஆகலாம், அதிக எண்ணிக்கையிலான டோக்கன்களைப் பயன்படுத்துகின்றன. தரவுத்தொகுப்பின் அளவு விரிவான தன்மை மற்றும் பொருளாதாரம் ஆகியவற்றை சமநிலைப்படுத்த வேண்டும். GAIA மூன்று சிரம நிலைகளில் 466 கேள்விகளை கவனமாகத் தேர்ந்தெடுக்கிறது, பல திறன் பரிமாணங்களை உள்ளடக்கியதுடன் நியாயமான செலவில் மதிப்பீட்டை அனுமதிக்கிறது. SWE-Bench Verified 2294 கேள்விகளில் இருந்து 500 ஆக வடிகட்டப்பட்டது (கடுமையான தரத் தரங்கள் மூலம் சமிக்ஞை-இரைச்சல் விகிதத்தை மேம்படுத்தும் அதே வேளையில் செலவுகளை ஐந்தில் நான்கு பங்கு குறைக்கிறது). +**பொதுத் தரவரிசைச் சோதனைகள்** மாதிரிகளைக் கரடுமுரடாக வடிகட்டவும் வடிவமைப்பு உத்திகளைக் கடன் வாங்கவும் பயன்படுகின்றன; பொதுவாகத் தயாரிப்பு முடிவுகளுக்கு அல்ல. அவற்றின் பணிப் பரவல் உண்மையான வணிகத்தின் பணிப் பரவலுடன் ஒத்துப்போவதில்லை; GAIA இல் இரு சதவீதப் புள்ளிகள் உயர்வதற்கும் பணத் திரும்பப்பெறல் வெற்றி விகிதத்துக்கும் தவிர்க்கவியலாத தொடர்பு இல்லை. -**சவால் ஐந்து: தரவு மாசுபாட்டைத் தடுத்தல்.** பெரிய மொழி மாதிரிகளின் (LLMs) காலத்தில், மதிப்பீட்டிற்கு தரவு மாசுபாடு ஒரு தீவிர சவாலாகும்: மதிப்பீட்டுத் தரவு பயிற்சித் தரவில் சேர்க்கப்பட்டால், மதிப்பீடு பொதுமைப்படுத்தலை விட மனப்பாடத்தை அளவிடுகிறது. இது தேர்வுக்கு முன் பதில்களை மனப்பாடம் செய்வது போன்றது—நல்ல மதிப்பெண்கள் உண்மையான திறனைப் பிரதிபலிக்காது. வெவ்வேறு அளவுகோல்கள் வெவ்வேறு தடுப்பு உத்திகளைப் பின்பற்றுகின்றன: GAIA அதன் பதில்களின் தனித்துவத்தை நம்பியுள்ளது; கேள்விகளுக்கு பதிலளிக்க பல மூலங்களிலிருந்து தகவல்களை இணைக்க வேண்டும், மேலும் சில பணிகள் சிறப்பாக உருவாக்கப்பட்ட இணைப்புக் கோப்புகளுடன் (இணையத்தில் இல்லாத PDFகள்/ஆடியோ/படங்கள்) வருகின்றன, எனவே ஒரு ஒற்றை வலைப்பக்கம் நேரடியாக பதிலை வழங்க முடியாது. SWE-Bench Verified என்பது அசல் SWE-Bench இலிருந்து OpenAI ஆல் கைமுறை தரத் திரையிடல் மூலம் பெறப்பட்ட 500-கேள்வி துணைக்குழு ஆகும், மேலும் இதில் நேர அடிப்படையிலான எதிர்ப்பு-கசிவு வடிவமைப்பு இல்லை. SWE-bench-Live போன்ற பிந்தைய படைப்புகளே உண்மையில் தற்காலிக புத்துணர்ச்சியை எதிர்ப்பு-கசிவுக்குப் பயன்படுத்துகின்றன, மாதிரியின் பயிற்சி வெட்டுத் தேதிக்குப் பிறகு உருவாக்கப்பட்ட சிக்கல்களை தொடர்ந்து இணைத்து, மாதிரியின் பயிற்சி தொகுப்பை விட மதிப்பீட்டை முன்னோக்கி வைத்திருக்கின்றன. τ²-bench மாறும் அளவுரு உருவாக்கம் மூலம் கசிவைத் தடுக்கிறது, குறிப்பிட்ட பணி நிகழ்வுகள் (பயனர் பெயர்கள், ஆர்டர் எண்கள், தேதிகள் போன்றவை) ஒவ்வொரு முறையும் சீரற்ற முறையில் உருவாக்கப்படுகின்றன. AndroidWorld இன் அளவுருவாக்கப்பட்ட பணி உருவாக்கம் இயற்கையாகவே எதிர்ப்பு-கசிவு திறன்களைக் கொண்டுள்ளது, ஏனெனில் சரிபார்ப்பு இறுதி UI நிலையை அடிப்படையாகக் கொண்டது, செயல்பாடுகளின் வரிசையை அல்ல. Terminal-Bench கேனரி GUIDகளை (Globally Unique Identifiers, ஒரு தனித்துவமான கண்காணிப்பு குறிப்பான்) உட்பொதிப்பதன் மூலம் கசிவைக் கண்டறியக்கூடியதாக ஆக்குகிறது: ஒரு மாதிரி இந்த GUID ஐக் கொண்ட உள்ளடக்கத்தை வெளியிட முடிந்தால், அது அளவுகோல் தரவு பயிற்சித் தொகுப்பில் கசிந்துள்ளது என்பதைக் குறிக்கிறது. +**சொந்தமாகக் கட்டிய வணிகத் தொகுப்பு** உண்மையான பணிப் பரவலை உள்ளடக்குகிறது; மாதிரித் தேர்வுக்கும் Harness வடிவமைப்பு முடிவுகளுக்கும் அடிப்படையாக அமையலாம். எடுத்துக்காட்டாக, உருவகப் பயனர் தேவைப்படும் எந்த மதிப்பீட்டு அமைப்புக்கும் τ²-bench ஐ அப்படியே எலும்புக்கூடாகப் பயன்படுத்தலாம்; கள தரவையும் கருவித் தொகுப்பையும் மாற்றினால் போதும். -### பணி விளக்கங்களின் துல்லியமான வடிவமைப்பு +**உற்பத்தி trajectory திரும்பப் பாய்தல்** களத்தில் நிகழும் உண்மையான தோல்விகளிலிருந்து வருகிறது: பயனரின் வெளிப்படையான திருத்தங்கள், பயனரின் எதிர்மறை மதிப்பீடுகள், பின்னர் நிலைச் சோதனையாலோ விதி அடிப்படையிலான சரிபார்ப்பானாலோ LLM மறுஆய்வாலோ கண்டறியப்பட்ட வழக்குகள். தோல்விக் காரணம் கண்டறிதலுக்குப் பிறகு அவை பின்னடைவு வழக்குகளாகப் படிகின்றன. விரிவான முறை பின்வரும் "தோல்விக் காரணம் கண்டறிதல்", "முனை முதல் முனை பின்னடைவுப் பணிகளும் trajectory prefix பின்னடைவுப் பணிகளும்" ஆகிய பகுதிகளில் விவரிக்கப்படுகிறது. இந்த மூலமே மிக விலையுயர்ந்ததும் மிகத் துல்லியமானதும்; ஏனெனில் இது பயனர்கள் நேரடியாகச் சந்தித்தவற்றிலிருந்தே வருகிறது. -GAIA தெளிவான தகவல் மூலக் கட்டுப்பாடுகள், நேர வரம்புகள், தலைப்புகள் மற்றும் வினவல் இலக்குகள் மூலம் பதில் தனித்துவத்தை உறுதி செய்கிறது. எடுத்துக்காட்டாக, ஒரு நிலை 3 பணிக்கு ஒரு குறிப்பிட்ட தேதியின் NASA படத்திலிருந்து தொடங்கி, காட்சி புரிதல் மூலம் விண்வெளி வீரரை அடையாளம் கண்டு, அவர்களின் விண்வெளி வீரர் குழுவை வினவி, விண்வெளியில் நேரத்தைக் கணக்கிட்டு, வெளியீட்டை துல்லியமாக வடிவமைக்க வேண்டும் ("கடைசி பெயர், அரைப்புள்ளியால் பிரிக்கப்பட்டது, ஆயிரம் பிரிப்பான்"). ஒவ்வொரு விவரமும் தானியங்கி சரிபார்ப்புக்கு சேவை செய்கிறது—வடிவம் மற்றும் உள்ளடக்கத்தில் சரியான பொருத்தம் மட்டுமே தேர்ச்சியாக கணக்கிடப்படும். +தொடக்கக் கட்டத்தில் பொதுவாகப் பொதுத் தரவரிசைச் சோதனைகளும் கையால் எழுதப்பட்ட சிறிய வணிகத் தொகுப்பும் மட்டுமே இருக்கும்; அமைப்பு உற்பத்தியில் சில காலம் இயங்கிய பிறகு, உற்பத்தி trajectory இலிருந்து திரும்பிய வழக்குகளே பெரும்பகுதியாக மாறும். -τ²-bench சூழல்மயமாக்கப்பட்ட வடிவமைப்பை அறிமுகப்படுத்துகிறது, ஒவ்வொரு பணியும் பல அடுக்கு தகவல்களைக் கொண்டுள்ளது: மேற்பரப்பு சிக்கல் ("மொபைல் டேட்டா வேலை செய்யவில்லை"), செயல்திறன் எதிர்பார்ப்புகள் ("நிச்சயமாக சிறந்த வேகத்தை விரும்புகிறேன்"), கட்டுப்பாடுகள் ("வேறு வேகங்களை ஏற்க மாட்டேன்"), மற்றும் மறைமுக உணர்வுகள். ஒரு முக்கிய முன்னேற்றம் "அறியப்பட்ட தகவலை" "பணி அறிவுறுத்தல்களில்" இருந்து பிரிப்பதாகும்: அறியப்பட்ட தகவல் என்பது பயனர் தற்போது அறிந்தது, அதே நேரத்தில் பணி அறிவுறுத்தல்கள் சிமுலேட்டருக்கு தகவலை படிப்படியாக வெளிப்படுத்துவது எப்படி என்பதை வழிகாட்டுகின்றன, இதில் "அடிப்படை தேவைகள்" (Grounding Requirements — பதில்கள் கருவி அழைப்புகளால் திரும்பப் பெறப்பட்ட உண்மையான முடிவுகளை அடிப்படையாகக் கொண்டிருக்க வேண்டும், கற்பனையானவை அல்ல) அடங்கும். - -SWE-Bench Verified ஆனது சிக்கல் விளக்கம், மறுஉருவாக்கப் படிகள், எதிர்பார்க்கப்படும்/உண்மையான நடத்தை போன்ற கட்டமைக்கப்பட்ட புலங்களை உள்ளடக்கியது, மேலும் சரிபார்ப்பாளர்கள் விளக்கத்திற்கும் சோதனை வழக்குகளுக்கும் இடையிலான பொருத்தத்தை சரிபார்க்கின்றனர். Terminal-Bench இன் பணி விளக்கங்களில் உள்ள ஒவ்வொரு உறுப்பும் இயந்திரத்தனமாக சரிபார்க்கப்படலாம்: ஒரு கோப்பு பாதை உள்ளதா, அனுமதி மதிப்புகள் சரியாக உள்ளதா, சான்றிதழ் அளவுருக்கள், தேதி வடிவங்கள் போன்றவை. எடுத்துக்காட்டாக, "build-linux-kernel-qemu" என்பது Linux kernel 6.9 ஐ மூலத்திலிருந்து உருவாக்குதல், `start_kernel` இல் தனிப்பயன் printk ஐ சேர்த்தல், initramfs ஐ உருவாக்குதல் மற்றும் QEMU இல் இயக்குதல் ஆகியவற்றைக் கோருகிறது. வெற்றி அளவுகோல் என்பது துவக்க பதிவில் தனிப்பயன் செய்தி தோன்றுவதாகும்—ஏஜெண்ட் வெளியீட்டை போலியாக உருவாக்க முடியாது; அது முழு செயல்முறையையும் உண்மையிலேயே நிறைவு செய்ய வேண்டும். - -AndroidWorld ஒரு **அளவுருவாக்கப்பட்ட டெம்ப்ளேட்** வடிவமைப்பைப் பயன்படுத்துகிறது. ஒரு பணி என்பது நிலையான உரை அல்ல, மாறாக மாறும் வகையில் உடனடியாக உருவாக்கக்கூடிய ஒரு டெம்ப்ளேட் ஆகும் (எ.கா., "தொடர்பு `[CONTACT_NAME]` இன் தொலைபேசி எண்ணை `[NEW_PHONE]` ஆக மாற்றவும்"), ஒவ்வொரு மதிப்பீட்டிற்கும் வெவ்வேறு அளவுரு மதிப்புகள் சீரற்ற முறையில் உருவாக்கப்படுகின்றன. இது மூன்று நன்மைகளைக் கொண்டுள்ளது: - -- **மனப்பாடம் செய்வதைத் தடுக்கிறது**: ஒவ்வொரு முறையும் அளவுரு மதிப்புகள் வேறுபடுகின்றன, இது ஒரு நிலையான செயல்பாடுகளின் வரிசையை மீண்டும் இயக்குவதைத் தடுக்கிறது -- **தரவு பன்முகத்தன்மையை அதிகரிக்கிறது**: ஒரு டெம்ப்ளேட் கிட்டத்தட்ட வரம்பற்ற நிகழ்வுகளை உருவாக்க முடியும் -- **ஒப்பீட்டு சோதனைகளை ஆதரிக்கிறது**: சில அளவுருக்களை நிலைநிறுத்தி மற்றவற்றை மாற்றுவதன் மூலம், குறிப்பிட்ட காரணிகளின் விளைவுகளை துல்லியமாக அளவிட முடியும் - -சரிபார்ப்பு என்பது இறுதி UI நிலையை அடிப்படையாகக் கொண்டது (எ.கா., தொலைபேசி எண் புலத்தில் எதிர்பார்க்கப்படும் மதிப்பு உள்ளதா), செயல்பாடுகளின் வரிசையை அல்ல. - -OSWorld பணிகள் பெரும்பாலும் "சுத்தமான" ஆரம்ப நிலையில் இருந்து தொடங்குவதில்லை, மாறாக கவனமாக உள்ளமைக்கப்பட்ட இடைநிலை நிலைகளில் இருந்து தொடங்குகின்றன, இது நிஜ உலக பயன்பாட்டு சூழ்நிலைகளை மிகவும் நெருக்கமாக ஒத்திருக்கிறது. பணி விளக்கங்கள் பல தீர்வுகளைக் கையாள வேண்டும் ("பின்னணியை ஊதா நிறமாக அமைக்கவும்" என்பதற்கு தெளிவுபடுத்த ஒரு குறிப்பிட்ட வண்ணக் குறியீடு தேவை; "இரண்டு CSV களை இணைக்கவும்" என்பது ஒரு தலைப்பு அல்லது இரண்டு தலைப்புகளை வைத்திருப்பது போன்ற அனைத்து நியாயமான முறைகளையும் ஏற்க வேண்டும்) மற்றும் சுற்றுச்சூழல் நிச்சயமற்ற தன்மையையும் (வலைத்தள எதிர்ப்பு-ஸ்கிராப்பிங், பயன்பாட்டு UI பரிணாமம், நேரப் போட்டிகள்—OSWorld-Verified இவற்றை ஆஃப்லைன் பக்கம் ஸ்னாப்ஷாட்கள், பூட்டப்பட்ட சார்பு பதிப்புகள், வெளிப்படையான காத்திருப்பு நிபந்தனைகள் போன்றவற்றின் மூலம் குறைக்கிறது). - -மேலே கூறிய Agent மதிப்பீட்டுத் தரவுத்தொகுப்புகள் Agent மதிப்பீட்டின் முழு நிலப்பரப்பையும் தீர்த்துவிடவில்லை. Web/GUI வகையிலேயே வெவ்வேறு அழுத்தங்களைக் கொண்ட பல அளவுகோல்கள் உள்ளன: WebArena முழுமையாக மறு-உருவாக்கக்கூடிய இணையதளங்களின் (மின்வணிகம், மன்றம், நிரல் ஹோஸ்டிங் முதலியன) தொகுப்பையே தானே கட்டி, "நிஜ இணையப் பக்கங்களின்" கட்டுப்படுத்த முடியாத தன்மையை மணற்பெட்டிக்குள் அடைக்கிறது; Mind2Web நேர்மாறாகச் செயல்பட்டு, நூற்றுக்கணக்கான நிஜ இணையதளங்களிலேயே பொதுமைப்படுத்தும் திறனைச் சோதிக்கிறது; [ClawBench](https://claw-bench.com/) தனிமைப்படுத்தப்பட்ட கொள்கலனில் இயங்கும் Agent-ஐ நிஜ இணையதளங்களில் இறுதி-முதல்-இறுதி அன்றாடப் பணிகளைச் செய்யவைக்கிறது: V1 144 இணையதளங்களில் 153 பணிகளை உள்ளடக்குகிறது, V2 மேலும் 130 சேர்க்கிறது; அத்துடன் அமர்வு மறுஒளிபரப்பு, செயல் திரைப்படங்கள், HTTP போக்குவரத்து, உலாவிச் செயல்கள், Agent செய்திகள் என ஐந்து அடுக்குச் சான்றுகளையும் ஒருங்கே பதிவு செய்கிறது. இது மணற்பெட்டி அளவுகோல்களுக்கு நிரப்பியாக அமைந்து, நிஜ தளங்களின் நகர்வையும் நீள்வால் தோல்விகளையும் ஆய்வு செய்ய உதவுகிறது; விலையோ, மறு-உருவாக்கத்தன்மை மூன்றாம் தரப்பு இணையதள மாற்றங்களால் பாதிக்கப்படுவதுதான். BrowseComp ஆழ்ந்த மீட்டெடுப்பில் நிபுணத்துவம் பெறுகிறது — விடை ஆழத்தில் புதைந்திருக்கும்; பல தாவல் உலாவலும் குறுக்குச் சரிபார்ப்பும் இருந்தால்தான் கண்டறிய முடியும். - -### பணி சிக்கலின் படிநிலை வடிவமைப்பு - -GAIA மூன்று சிரம நிலைகளை வடிவமைக்கிறது: நிலை 1 க்கு 1-2 கருவிகள் மட்டுமே தேவை (மனிதர்கள் 93.9% vs GPT-4 30.3%), நிலை 2 க்கு பல-படி பகுத்தறிவு தேவை (91.8% vs 9.7%), மற்றும் நிலை 3 க்கு சிக்கலான சேர்க்கைகள் தேவை (87.3% vs 0%). இந்த படிநிலை வடிவமைப்பின் கண்டறியும் மதிப்பு: நிலை 1 இல் தோல்வி அடிப்படை கருவி பயன்பாட்டு சிக்கல்களை சுட்டிக்காட்டுகிறது, நிலை 2 பல-படி திட்டமிடல் மற்றும் தகவல் ஒருங்கிணைப்பை சுட்டிக்காட்டுகிறது, மற்றும் நிலை 3 நீண்ட-வரிசை பகுத்தறிவு மற்றும் சிக்கலான மேலாண்மையை சுட்டிக்காட்டுகிறது. ஒவ்வொரு நிலையும் வெவ்வேறு முன்னேற்ற திசைகளுடன் (prompt engineering vs. திட்டமிடல் வழிமுறைகள் vs. படிநிலை கட்டமைப்பு/பிந்தைய பயிற்சி) ஒத்துள்ளது. - -τ²-bench ஆனது வணிகச் செயல்முறையின் அடிப்படையில் சிக்கலான தன்மையை அடுக்குகிறது: எளிய தகவல் வினாக்கள் முதல், பல-படி செயல்முறைகள் (ஒரு விமானத்தை மாற்றியமைக்க வினவுதல், மாற்று வழிகளைக் காட்டுதல், உறுதிப்படுத்துதல், விலை வேறுபாடுகளைக் கணக்கிடுதல் மற்றும் கட்டணம் செலுத்துதல் தேவை), குறை கண்டறிதல் (சாத்தியமான பல காரணங்களை முறையாகச் சரிபார்த்து திருத்தங்களை உறுதிப்படுத்துதல்) வரை, இறுதியாக மூலோபாய தீர்ப்பு (கொள்கைக்கு இணங்காத கோரிக்கைகளைக் கையாளுதல்) வரை. - -Terminal-Bench ஆனது தொழில்நுட்ப களம் × செயல்பாட்டு சிக்கலான தன்மை ஆகிய இரட்டை பரிமாணங்களில் சிக்கலான தன்மையை அடுக்குகிறது. அதன் பணிப் பதிவேடு 200 க்கும் மேற்பட்ட பணிகளைச் சேகரித்துள்ளது (முக்கிய மதிப்பீட்டுத் தொகுப்பின் அளவு பதிப்பைப் பொறுத்து மாறுபடும்; எடுத்துக்காட்டாக, பதிப்பு 2.0 சமூக பங்களிப்புகளிலிருந்து 89 உயர்தர பணிகளைத் தேர்ந்தெடுத்தது), எளிய mlflow மாதிரி பதிவு முதல், நடுத்தர 7z கடவுச்சொல் வெட்டுதல், கடினமான git சேவையகம் + வலைச் சேவையகம் பல-கூறு ஒருங்கிணைப்பு வரை, மிகவும் கடினமான FEAL வேறுபாடு குறியாக்கப் பகுப்பாய்வு (30 வினாடி நேரக் கட்டுப்பாட்டை சந்திக்க குறியாக்கவியல் அறிவு + அல்காரிதம் உகப்பாக்கம் தேவை) வரை பரவியுள்ளது. - -### சரிபார்ப்புத் திறன் மற்றும் புறநிலைத் தன்மையை உறுதி செய்தல் - -GAIA இன் பதில்கள் சுருக்கமாகவும் தெளிவாகவும் உள்ளன. கடுமையான வடிவமைப்பு விதிகள் சரியான சரம் பொருத்தம் மூலம் சரிபார்ப்பை அனுமதிக்கின்றன. இரும முடிவு (பொருந்துகிறது அல்லது பொருந்தவில்லை) புறநிலை மறுஉற்பத்தித் திறனை உறுதி செய்கிறது. பதில்களின் அரிதான தன்மை ஏமாற்றுதலைத் தடுக்கும் ஒரு நடவடிக்கையாகவும் செயல்படுகிறது—மிகவும் குறிப்பிட்ட உண்மைகள் பயிற்சித் தரவுகளில் சரியாகத் தோன்றுவது சாத்தியமில்லை. - -SWE-Bench Verified சரிபார்ப்புக்காக குறியீட்டை இயக்கும் திறனைப் பயன்படுத்துகிறது, இது FAIL_TO_PASS (திருத்தத்திற்கு முன் தோல்வி, திருத்தத்திற்குப் பின் வெற்றி, சிக்கல் தீர்க்கப்பட்டது என்பதை நிரூபிக்கிறது) மற்றும் PASS_TO_PASS (திருத்தத்திற்கு முன்னும் பின்னும் வெற்றி, புதிய பிழைகள் எதுவும் அறிமுகப்படுத்தப்படவில்லை என்பதை நிரூபிக்கிறது) ஆகியவற்றை வேறுபடுத்தி, இரட்டை சரிபார்ப்பை அடைகிறது. Verified பதிப்பு சோதனைகள் நம்பகமானவை என்பதையும், சில நேரங்களில் வெற்றி பெறும் மற்றும் சில நேரங்களில் தோல்வியடையும் நிலையற்ற சோதனைகள் இல்லை என்பதையும் உறுதி செய்கிறது. - -τ²-bench இன் சரிபார்ப்பு அமைப்பு பல அடுக்கு சரிபார்ப்புகளை உள்ளடக்கியது (ஒவ்வொரு அடுக்கின் முடிவுகளும் பணி மட்டத்தில் இரும வெகுமதியாக தொகுக்கப்படுகின்றன; வெற்றிக்கு அனைத்தும் நிறைவேற வேண்டும்): - -- **தரவுத்தள நிலை சரிபார்ப்பு**: முன்பதிவு பதிவு நிலை, பணத்தைத் திரும்பப் பெறும் பதிவு உருவாக்கப்பட்டதா என்பது -- **உரையாடல் உள்ளடக்க முக்கியச் சொல் தேடல்**: பயனர் பணத்தைத் திரும்பப் பெறும் தொகை மற்றும் வருகை நேரத்தை உறுதிப்படுத்தும்படி கேட்கப்பட்டாரா என்பது -- **செயல்முறை இணக்கம்**: கருவி அழைப்பு வரிசையின் பகுப்பாய்வு, எ.கா., ஆர்டரை மாற்றியமைப்பதற்கு முன் பயனரின் வெளிப்படையான உறுதிப்படுத்தல் பெறப்பட்டதா என்பது - -τ²-bench இன் இரட்டை-கட்டுப்பாட்டு சூழல் (முந்தைய பகுதி "மனித-கணினி தொடர்பு மதிப்பீட்டு சூழல்" ஐப் பார்க்கவும்) சரிபார்ப்பில் மற்றொரு பரிமாணத்தைச் சேர்க்கிறது: பயனர் உருவகப்படுத்தி உண்மையில் சூழல் நிலையை மாற்றிய பிறகு, ஏஜெண்ட் இந்த மாற்றத்தை கருவி அழைப்புகள் மூலம் கவனித்து அதற்கேற்ப சரிசெய்தலைத் தொடர வேண்டும். எனவே சரிபார்ப்பு ஏஜெண்ட் பயனரின் செயல்களின் முடிவுகளை உண்மையில் படித்தாரா என்பதை உள்ளடக்கியது. - -OSWorld ஆனது 134 சுயாதீன மதிப்பீட்டு செயல்பாடுகளைக் கொண்டுள்ளது, முழு OS அணுகலைக் கொண்டுள்ளது, மேலும் கோப்பு முறைமை கட்டமைப்புகள், செயல்முறை நிலைகள், நெட்வொர்க் இணைப்புகள் மற்றும் பயன்பாட்டு உள் நிலைகளை ஆழமாக ஆய்வு செய்ய முடியும். எடுத்துக்காட்டாக, ஒரு தரவுத்தள செயல்பாட்டு பணியில், மதிப்பீட்டு ஸ்கிரிப்ட் அறிக்கை கோப்பு இருப்பதை மட்டும் சரிபார்க்காமல், SQL சரியாக செயல்படுத்தப்பட்டதா என்பதை நேரடியாக தரவுத்தளத்துடன் இணைத்து சரிபார்க்கிறது. உலாவி பணிகளில், இது DOM மரத்தை பகுப்பாய்வு செய்கிறது, cookies/localStorage ஐ சரிபார்க்கிறது, மேலும் படிவம் உண்மையில் சமர்ப்பிக்கப்பட்டதா என்பதை உறுதிப்படுத்த பின்தளத்திற்கு சரிபார்ப்பு கோரிக்கைகளை அனுப்புகிறது. இந்த ஆழமான ஆய்வு, "மேலோட்டமான நிறைவு ஆனால் அடிப்படை பிழை" வழக்குகளைக் கண்டறிய முடியும்—எடுத்துக்காட்டாக, ஏஜெண்ட் சமர்ப்பி பொத்தானைக் கிளிக் செய்தது, ஆனால் தவறான புல உள்ளீடுகள் காரணமாக சேவையகத்தால் கோரிக்கை நிராகரிக்கப்பட்டது. - -Terminal-Bench ஆனது ஒரு தரப்படுத்தப்பட்ட Docker கொள்கலன் சூழலை அடிப்படையாகக் கொண்டது, கோப்பு முறைமை நிலை சரிபார்ப்புகளை (பாதை இருப்பு, அனுமதி மதிப்புகள், உள்ளடக்க வடிவம்) நிரல் செயலாக்க செயல்பாட்டு சரிபார்ப்புடன் (build-linux-kernel-qemu இல், உண்மையில் QEMU ஐத் தொடங்கி தனிப்பயன் printk செய்தியைத் தேடுதல்) இணைக்கிறது. canary GUID ஆனது கசிவைக் கண்டறிய உதவுகிறது. - -### பணி விநியோகத்தின் முறையான வடிவமைப்பு - -பணி விநியோகம் திறன் பரிமாணங்கள், சிரம பரிமாணங்கள், காட்சி பரிமாணங்கள் மற்றும் விளிம்பு நிலைகளை முறையாக உள்ளடக்க வேண்டும். GAIA பொதுமைப்படுத்தலை நோக்கமாகக் கொண்டுள்ளது—பெரும்பாலான பணிகளுக்கு பகுத்தறிவு, பல்முறைமை, உலாவல் மற்றும் கருவி பயன்பாடு ஆகியவற்றின் கலவை தேவைப்படுகிறது. τ²-bench குறிப்பாக "பொறி பணிகளை" வடிவமைக்கிறது—எடுத்துக்காட்டாக, ஒரு பயனர் "வாடிக்கையாளர் சேவை ரத்து செய்வதற்கு ஒப்புதல் அளித்துள்ளது" என்று கூறுகிறார், ஆனால் அது உண்மையில் கொள்கைக்கு இணங்கவில்லை, இது அழுத்தம் மற்றும் தவறான தகவலின் கீழ் ஏஜெண்ட் சரியான தீர்ப்பை பராமரிக்க முடியுமா என்பதை சோதிக்கிறது. OSWorld ஆனது செயல்பாட்டு வகை (கோப்பு IO / டெஸ்க்டாப் பயன்பாடு / வலை பயன்பாடு / குறுக்கு-பயன்பாட்டு பணிப்பாய்வு) மற்றும் பயன்பாட்டு களம் ஆகிய இரட்டை பரிமாண அணியை அடிப்படையாகக் கொண்டது, மூன்று இயக்க முறைமைகளை உள்ளடக்கியது (ஆராய்ச்சி வலுவான குறுக்கு-OS தொடர்பைக் காட்டுகிறது; ஒரு முறைமையில் கற்றுக்கொண்ட திறன்களை மற்றவற்றுக்கு மாற்றலாம்). Terminal-Bench ஆனது "குறுக்கு-தொழில்நுட்ப அடுக்கு கலவை பணிகளை" உள்ளடக்கியது, அமைப்பு சிந்தனையை சோதிக்க (எ.கா., தரவு செயலாக்கம் + கோப்பு செயல்பாடுகள் + Python பொறியியலை இணைக்கும் ஒரு resharding பணி). +## தானியங்கி மதிப்பீட்டு முறைகள் -### தரவுத் தரக் கட்டுப்பாடு மற்றும் மறு செய்கை மேம்பாடு +முந்தைய பகுதிகளில் விவாதித்த தரவரிசைச் சோதனைகளுக்கு ஒரு பொதுவான அம்சம் உண்டு: அவற்றின் சரிபார்ப்பான்கள் கிட்டத்தட்ட அனைத்தும் நிர்ணயவாதமானவை. SWE-bench சோதனைத் தொகுப்பை இயக்குகிறது, AndroidWorld இறுதி UI நிலையை உறுதிப்படுத்துகிறது, GAIA துல்லியமான சரம் பொருத்தம் செய்கிறது, τ²-bench இன் நான்கு அடுக்குச் சோதனைகளும் அதேபோல் முழுவதும் குறியீட்டாலேயே இயக்கப்படுகின்றன. இந்தத் தேர்வுக்குப் போதிய காரணங்கள் உண்டு: நிர்ணயவாதச் சரிபார்ப்பு கூடுதல் மாதிரிச் செலவைச் சேர்ப்பதில்லை, முடிவு முழுமையாக மறுஉருவாக்கக்கூடியது, அலகுச் சோதனை போலத் தொடர் ஒருங்கிணைப்பில் சேர்க்கலாம், மாதிரிகளுக்கிடையே தரவரிசைப்படுத்தவும் எளிது. -SWE-Bench Verified என்பது தரக் கட்டுப்பாட்டுக்கான ஒரு அளவுகோலாகும். OpenAI அசல் 2,294 பணிகளில் இருந்து 1,699 பணிகளை சீரற்ற முறையில் மனித மதிப்பீட்டிற்காகத் தேர்ந்தெடுத்து, 93 பைதான் தேர்ச்சி பெற்ற டெவலப்பர்களை நியமித்தது. மதிப்பீட்டாளர்கள் பல சோதனைகளைச் செய்ய வேண்டியிருந்தது: சிக்கல் விளக்கம் தெளிவாக இருந்ததா (எதைத் தீர்க்க வேண்டும் என்பதைப் புரிந்துகொள்ள முடிந்ததா), சோதனை வழக்குகள் முழுமையானவையா (அனைத்து அம்சங்களையும் விளிம்பு நிலைகளையும் உள்ளடக்கியதா), சோதனைகள் நிலையானவையா (சூழல் அல்லது சீரற்ற தன்மை காரணமாக நிலையற்ற சோதனைகள் இல்லை), இணைப்பு சரியானதா (புதிய பிழைகளை அறிமுகப்படுத்தியதா), மற்றும் சிரமம் நியாயமானதா என்பன. கடுமையான சோதனைக்குப் பிறகு, 500 மட்டுமே தேர்ச்சி பெற்றன (29%)—இந்த உயர் நிராகரிப்பு விகிதம் மதிப்பீட்டுத் தரத்தில் தேவையான முதலீடாகும். மேலும், வெவ்வேறு மதிப்பீட்டாளர்களிடையே நிலைத்தன்மையை உறுதி செய்ய, ஒவ்வொரு சோதனைக்கும் குறிப்பிட்ட அளவுகோல்கள் மற்றும் எடுத்துக்காட்டுகளை வரையறுத்து, தரப்படுத்தப்பட்ட குறியிடுதல் வழிகாட்டுதல்களை நிறுவினர். +அதன் விலை என்னவென்றால், இறுதி முடிவு சரியா தவறா என்பதை மட்டுமே மதிப்பிட முடியும்; பிழையின் காரணத்தைத் தராது. τ²-bench இல் தோல்வியடைந்த பணி இறுதியில் 0 மதிப்பெண் பெற்றது; ஆனால் அந்த 0, ஏஜெண்ட் இணைப்புத் தேர்வுக் கட்டத்தில் தவறியதா அல்லது தரவு நிரப்பும் படியைத் தவறவிட்டதா என்பதைச் சொல்வதில்லை; அடுத்து எதை மாற்ற வேண்டும் என்பதைச் சுட்டவே இல்லை. தரவரிசைக்குப் பயன்படும் பொதுத் தரவரிசைச் சோதனைக்கு இது குறை அல்ல; தொடர் மேம்பாடு தேவைப்படும் உற்பத்தி அமைப்புக்கோ இதுவே மிகவும் தேவைப்படும் தகவல். -τ²-bench ஆனது "அறியப்பட்ட தகவல்" / "பணி வழிமுறைகள்" (சிமுலேட்டர் நடத்தையை மிகவும் யதார்த்தமாக்குகிறது) மற்றும் கடுமையான நிறைவு நிபந்தனைகள் (எ.கா., "சிறந்தது மட்டுமே தீர்க்கப்பட்டதாகக் கருதப்படும்; மோசமான/சராசரி/நல்லது ஏற்கப்படாது") ஆகியவற்றின் பிரிப்பை அறிமுகப்படுத்துகிறது, இது "மேலோட்டமான திருத்தங்களை" தடுக்கிறது. +உற்பத்திச் சூழலுக்கு இரண்டாவது சிரமமும் உண்டு: பல தீர்ப்புகளை அடிப்படையிலேயே குறியீடு சோதிக்கக்கூடிய உறுதிமொழியாக எழுத முடியாது. புகாருக்கான பதில் பொருத்தமானதா, ஆய்வு அறிக்கை முக்கியத் தகவலை விட்டுவிட்டதா, நினைவு மீட்டெடுப்பு நபர்களுக்கிடையிலான உறவைக் குழப்பிக்கொண்டதா — இவற்றுக்கு வினவக்கூடிய ஒற்றை இறுதி நிலையும் இல்லை, முக்கியச் சொல் பொருத்தத்தால் தீர்மானிக்கவும் முடியாது. -OSWorld-Verified என்பது மீள்செயல் மேம்பாட்டின் ஒரு மாதிரியாகும். ஏப்ரல் 2024 இல் வெளியிடப்பட்ட பிறகு, OSWorld விரைவில் மல்டிமோடல் ஏஜெண்ட் மதிப்பீட்டிற்கான ஒரு முக்கிய அளவுகோலாக மாறியது, ஆனால் 15 மாதங்களுக்கும் மேலான பரவலான பயன்பாட்டில், 300 க்கும் மேற்பட்ட சிக்கல்கள் கண்டறியப்பட்டன. இந்த சிக்கல்கள் நான்கு வகைகளாகப் பிரிக்கப்படுகின்றன: சூழல் சிக்கல்கள் (இணையதள எதிர்ப்பு-ஸ்கிராப்பிங் / CAPTCHA / மாறும் உள்ளடக்க மாற்றங்கள்), பணி விளக்கம் சிக்கல்கள் (தெளிவற்ற சொற்றொடர்), சரிபார்ப்பு தர்க்க சிக்கல்கள் (மிகவும் கண்டிப்பான அல்லது மிகவும் தளர்வான), மற்றும் ஆரம்ப நிலை சிக்கல்கள் (முழுமையற்ற உள்ளமைவு). ஹாங்காங் பல்கலைக்கழகத்தைச் சேர்ந்த சுமார் 10 பேர் கொண்ட குழு, MoonShot AI, OpenAI, ByteDance Seed TARS, Anthropic, Simular மற்றும் பிறருடன் இரண்டு மாதங்கள் ஆழமாக ஒத்துழைத்து, இந்த சிக்கல்களை முறையாக சரிசெய்தது. ஒவ்வொரு வகைக்கும் பழுதுபார்க்கும் உத்திகள் வகுக்கப்பட்டன: சூழல் சிக்கல்கள் பதிப்புகளைப் பூட்டி ஆஃப்லைன் காப்புப்பிரதிகள் மூலம் தீர்க்கப்பட்டன, பணி விளக்கங்கள் தெளிவற்ற சொற்றொடரை மீண்டும் எழுதுவதன் மூலம் தெளிவுபடுத்தப்பட்டன, சரிபார்ப்பு தர்க்கம் கைமுறையாக சரியான அடிப்படைகளை நிறுவி நிபந்தனைகளைச் சரிசெய்வதன் மூலம் சமநிலைப்படுத்தப்பட்டது, மற்றும் ஆரம்ப நிலைகள் முழுமை சோதனைகளைச் சேர்ப்பதன் மூலம் மேம்படுத்தப்பட்டன. +எனவே பொதுத் தரவரிசைச் சோதனைகளிலிருந்து உற்பத்திச் சூழல் மதிப்பீட்டுக்கு நகரும்போது, சரிபார்ப்பு முறையை ஒரு நிறமாலையில் வலப்புறம் நகர்த்த வேண்டும்; அதன் கிடைமட்ட அச்சு பணியின் **இயந்திரச் சரிபார்ப்புத் தன்மையின் அளவு** — படம் 7-4 இதைக் காட்டுகிறது. -## தானியங்கி மதிப்பீட்டு முறைகள் +![படம் 7-4: சரிபார்ப்பு முறைகளின் நிறமாலை — நிர்ணயவாதச் சரிபார்ப்பிலிருந்து மாதிரித் தீர்ப்பு வரை](images/fig7-4.svg) -மதிப்பீட்டு சூழல், தரவுத்தொகுப்பு மற்றும் தெளிவான அளவீட்டு முறைமை ஆகியவை இருப்பதால், மையக் கேள்வி: எப்படி மதிப்பெண் வழங்குவது? தெளிவான சரியான பதில்களைக் கொண்ட பணிகளுக்கு (எ.கா., கணிதப் பிரச்சினைகள், SQL வினவல்கள்), எளிய இரும மதிப்பீடு (சரி/தவறு) போதுமானது; ஆனால் திறந்த முடிவு பணிகளுக்கு (எ.கா., வாடிக்கையாளர் சேவை உரையாடல்கள், அறிக்கை எழுதுதல்), மேலும் சுத்திகரிக்கப்பட்ட மதிப்பீட்டு முறைகள் தேவை. +இதனால் நிறமாலையின் வலப்பக்கத்தில் உள்ள இரு கருவிகளே உற்பத்தி மதிப்பீட்டின் முதுகெலும்பாகின்றன: **Rubric** "நன்றாக உள்ளதா இல்லையா" என்ற தெளிவற்ற கேள்வியைத் தனித்தனியே மதிப்பெண்ணிடக்கூடிய பல பரிமாணங்களாகப் பிரிக்கிறது; **LLM-as-a-Judge** நிர்ணயவாத அளவுகோல் இல்லாத இடத்தில் மதிப்பெண்ணிடுகிறது. இரண்டும் சேர்ந்தால்தான் தெளிவற்ற தோல்வி விகிதத்தைக் கை வைக்கக்கூடிய குறிப்பான சிக்கல்களாகத் திருப்ப முடியும்; இப்பகுதியின் பிற்பாதியில் வரும் **தோல்விக் காரணம் கண்டறிதலு**டன் சேர்ந்தால் உற்பத்தி ஏஜெண்ட் மதிப்பீட்டின் முழு மூடிய வளையம் உருவாகிறது. -குறியீடு அடிப்படையிலான தானியங்கி சரிபார்ப்பு, நிலையான பதில்களைக் கொண்ட சூழ்நிலைகளை மட்டுமே உள்ளடக்குகிறது; திறந்த முடிவு பணிகளுக்கு மதிப்பெண் வழங்குவது இந்தப் பகுதியின் முக்கிய தலைப்பாகும். இவற்றில், வெகுமதி சமிக்ஞை அடர்த்தியின் வடிவமைப்பு (இரும வெகுமதிகள் முதல் செயல்முறை வெகுமதிகள் வரை உருவாக்க வெகுமதிகள் வரை) மற்றும் வெகுமதி மாதிரிகளுக்கான பயிற்சி முறைகள் ஆகியவை அத்தியாயம் 8 இன் பிந்தைய பயிற்சி பகுதியில் முறையான விவாதத்திற்கு விடப்படுகின்றன; இந்தப் பகுதி மிகவும் அடிப்படையான கேள்விக்கு பதிலளிக்கிறது: திறந்த முடிவு பணிகளின் வெளியீட்டுத் தரத்தை தானாக மதிப்பிடுவதற்கு LLM களை எவ்வாறு பயன்படுத்துவது? +ஒன்றைத் தெளிவுபடுத்த வேண்டும்: வலப்புறம் நகர்வது இடப்பக்கத்தைக் கைவிடுவது அல்ல. நிரல் உறுதிமொழியாக எழுதக்கூடிய ஒவ்வொரு சோதனையும் உறுதிமொழியாகவே இருக்க வேண்டும்; இயந்திரத்தால் உண்மையிலேயே தீர்மானிக்க முடியாத பரிமாணங்களுக்கு மட்டுமே LLM தீர்ப்பைப் பயன்படுத்த வேண்டும். நிர்ணயவாதச் சோதனைகள் மலிவானவை, நிலையானவை; பின்னடைவுச் சோதனைகளாக நீண்டகாலம் இயக்கவும் மிகப் பொருத்தமானவை. ### LLM-as-a-Judge: தானியங்கி மதிப்பீட்டின் மையம் -![படம் 7-4: LLM-as-a-Judge குழாய்](images/fig7-4.svg) +![படம் 7-5: LLM-as-a-Judge குழாய்](images/fig7-5.svg) LLM-as-a-Judge ஏன் தேவைப்படுகிறது? திறந்த முடிவு பணிகளுக்கு (எ.கா., அறிக்கைகளை உருவாக்குதல், வாடிக்கையாளர் புகார்களைக் கையாளுதல், படைப்பு உள்ளடக்கம்), தானியங்கி ஒப்பீட்டிற்கு நிலையான பதில்கள் இல்லை, மேலும் மனித மதிப்பீடு செலவு அதிகம் மற்றும் அளவிட கடினமாக உள்ளது. LLM-as-a-Judge, நிபுணர் வரையறுக்கப்பட்ட மதிப்பெண் அளவுகோல்களின் (Rubric) அடிப்படையில் ஒரு மொழி மாதிரியை மதிப்பீடு செய்ய வைப்பதன் மூலம், தானியங்கி அளவிடுதல் மற்றும் மனித நிபுணத்துவ மதிப்பீட்டிற்கு இடையே ஒரு சமநிலையை அடைகிறது. இருப்பினும், இந்த முறைக்கு அறியப்பட்ட வரம்புகளும் உள்ளன: நீதிபதி மாதிரியானது அதன் சொந்த சார்புகளைக் கொண்டிருக்கலாம் (மிகவும் பொதுவானது **நீள சார்பு**—நீண்ட, விரிவான பதில்களுக்கு அதிக மதிப்பெண்களை வழங்கும் போக்கு, அவை கூடுதலாகச் சரியாக இல்லாவிட்டாலும் கூட), மேலும் அதே உள்ளீட்டின் பல மதிப்பீடுகளில் ஏற்ற இறக்கங்களும் இருக்கலாம். நீள சார்பு குறிப்பாக தனித்தனியாக கவனிக்கப்பட வேண்டும்; பொதுவான முறைகள் மூன்று: Rubric இல் வீண் விரிவை வெளிப்படையாகத் தண்டித்து, பணி வகைக்கு ஏற்பப் பதில் நீளத்திற்கு மேல்வரம்பு நிர்ணயித்தல்; ஜோடி ஒப்பீடுகள் செய்யும்போது, முதலில் இரண்டு வேட்பாளர்களின் நீளங்களை ஒத்ததாக கட்டுப்படுத்தி பின்னர் மதிப்பீடு செய்தல்; மற்றும் மதிப்பெண்களுக்கும் பதில் நீளத்திற்கும் இடையிலான தொடர்பை தவறாமல் தணிக்கை செய்தல்—அதிக மதிப்பெண்கள் எப்போதும் நீண்ட பதில்களுடன் இருந்தால், நீதிபதி நீளத்தால் சார்புடையவர் என்பதைக் குறிக்கிறது மற்றும் Rubric ஐ திருத்த வேண்டும். இந்த சவால்களை முறையாக எதிர்கொள்ள, Rubric வடிவமைப்பு பின்வரும் கொள்கைகளைப் பின்பற்ற வேண்டும்: @@ -534,7 +535,7 @@ prefix பணியின் விடை, ஒற்றைச் செயலா ### ஜோடிவரிசை ஒப்பீடு மற்றும் மாதிரி தரவரிசை -![படம் 7-5: எலோ மதிப்பீடு மற்றும் ஜோடிவரிசை ஒப்பீட்டு தரவரிசை](images/fig7-5.svg) +![படம் 7-6: எலோ மதிப்பீடு மற்றும் ஜோடிவரிசை ஒப்பீட்டு தரவரிசை](images/fig7-6.svg) **எலோ மதிப்பீடு** (Elo Rating) (முதலில் சதுரங்கத்திற்காக வடிவமைக்கப்பட்ட ஒரு தரவரிசை முறை) அதிக எண்ணிக்கையிலான ஜோடிவரிசை போட்டிகள் மூலம் மாதிரிகளின் ஒப்பீட்டுத் திறனை அளவிடுகிறது: மதிப்பீட்டு வேறுபாடு பெரியதாக இருந்தால், வலுவான மாதிரிக்கான எதிர்பார்க்கப்படும் வெற்றி விகிதம் அதிகமாக இருக்கும். எடுத்துக்காட்டாக, மாதிரி A க்கு 1200 மதிப்பீடும், மாதிரி B க்கு 1000 மதிப்பீடும் இருந்தால், எலோ முறை A இன் வெற்றி விகிதத்தை தோராயமாக 76% என கணிக்கும். B எதிர்பாராத விதமாக வென்றால், B அதிக புள்ளிகளைப் பெறும் மற்றும் A அதிக புள்ளிகளை இழக்கும்—ஒரு அதிர்ச்சி முடிவு பெரிய திருத்தத்தைத் தூண்டுகிறது; இதுவே தரவரிசைகள் உண்மையான திறனை நோக்கி விரைவாகக் குவிய உதவுகிறது. இதன் புள்ளியியல் அடித்தளம் **பிராட்லி-டெர்ரி மாதிரி** (Bradley-Terry model): ஒவ்வொரு மாதிரியும் ஒரு மறைமுகமான "வலிமை மதிப்பெண்ணாக" சுருக்கப்படுகிறது, மேலும் ஒரு ஜோடிவரிசை போட்டியில் ஒன்று மற்றொன்றை வெல்லும் நிகழ்தகவு அவற்றின் மதிப்பெண்களின் வேறுபாட்டால் தீர்மானிக்கப்படுகிறது. எலோ என்பது இந்த மாதிரியின் ஆன்லைன் புதுப்பிப்பு வடிவத்தில் ஒரு பொறியியல் செயலாக்கமாகும். @@ -698,7 +699,7 @@ return paired_bootstrap_or_mcnemar(all_deltas) மதிப்பீடு சார்ந்த முடிவுகள் (மாதிரி தேர்வுக்காகவோ அல்லது தொடர்ச்சியான மறுசெயலாக்கத்திற்காகவோ) உயர்தர செயல்பாட்டுத் தரவை நம்பியுள்ளன. கீழே, முதலில் இந்தத் தரவை முறையாகச் சேகரிப்பது எப்படி (கவனிக்கத்தன்மை) என்பதை அறிமுகப்படுத்துகிறோம், பின்னர் மதிப்பீட்டு முடிவுகளை அமைப்பு மேம்பாடுகளாக மொழிபெயர்ப்பது எப்படி என்பதை விவாதிக்கிறோம். -![படம் 7-6: கவனிக்கத்தன்மை தொழில்நுட்ப அடுக்கு](images/fig7-6.svg) +![படம் 7-7: கவனிக்கத்தன்மை தொழில்நுட்ப அடுக்கு](images/fig7-7.svg) கவனிக்கத்தன்மை என்பது விநியோகிக்கப்பட்ட அமைப்புகள் களத்திலிருந்து கடன் வாங்கப்பட்ட ஒரு கருத்தாக்கமாகும்: அமைப்பு என்ன செய்கிறது என்பதை நேரடியாகத் திறந்து பார்க்க முடியாது; அது வெளியிடும் பதிவுகள், அளவீடுகள் மற்றும் தடங்கள் மூலம் மட்டுமே என்ன நடக்கிறது என்பதை ஊகிக்க முடியும், ஒரு மருத்துவர் நோயாளியின் உடலுக்குள் நேரடியாகப் பார்க்க முடியாமல், வெப்பநிலை, இரத்த அழுத்தம் மற்றும் இமேஜிங் போன்ற வெளிப்புற சமிக்ஞைகள் மூலம் பிரச்சினைகளைக் கண்டறிவதைப் போல. ஏஜெண்ட் அமைப்புகள் இதை இன்னும் கடினமாக்குகின்றன: ஒரே உள்ளீடு வெவ்வேறு வெளியீடுகளை உருவாக்கலாம், பல-சுற்று பகுத்தறிவு மற்றும் கருவி அழைப்புகள் செயலாக்கப் பாதைகளை மிகவும் சிக்கலாக்குகின்றன, மேலும் மாதிரியின் "சிந்தனை" செயல்முறை வெளியில் இருந்து முற்றிலும் ஒளிபுகாதாக உள்ளது. @@ -718,7 +719,7 @@ LangSmith இந்தத் துறையில் முக்கியம பின்வரும் எடுத்துக்காட்டு, இந்தப் புத்தகத்துடன் உள்ள களஞ்சியத்தில் மேற்கொள்ளப்பட்ட உண்மையான, திட்டமிட்டுச் சிறியதாக வைக்கப்பட்ட AndroidWorld சோதனையிலிருந்து எடுக்கப்பட்டது. API 35 emulator-இல் நான்கு Wi-Fi settings பணிகள் சோதிக்கப்பட்டன; ஒவ்வொரு பணிக்கும் இரு அமைப்புகளிலும் தலா ஒரு பொருத்தப்பட்ட இயக்கம் மட்டுமே நடத்தப்பட்டது. இது 116 பணிகள் கொண்ட முழு benchmark அல்ல; API 33 reference சூழலில் நடத்த வேண்டிய மறுசோதனைக்கும் மாற்றாகாது. ஆகவே இதன் பயன் ஒரு மொத்த மதிப்பெண்ணில் இல்லை; ஒவ்வொரு முடிவிலிருந்தும் அடுத்த பொறியியல் முடிவு எவ்வாறு எடுக்கப்பட்டது என்பதில்தான் உள்ளது. -![படம் 7-7: அளவுகோலிலிருந்து மேம்பாட்டு சுழற்சி](images/fig7-7.svg) +![படம் 7-8: அளவுகோலிலிருந்து மேம்பாட்டு சுழற்சி](images/fig7-8.svg) Harness பொறியியலின் கண்ணோட்டத்தில், இந்தப் பகுதி அடிப்படையில் மீண்டும் மீண்டும் செய்யும் Harness உகப்பாக்கத்திற்கான முறையைப் பற்றியது—Harness-இல் உள்ள பலவீனமான புள்ளிகளை (போதுமான சூழல் இல்லையா? விடுபட்ட கட்டுப்பாடுகள்? போதுமான சரிபார்ப்பு இல்லையா? சரியான நேரத்தில் கருத்து இல்லையா?) அடையாளம் காண மதிப்பீட்டுத் தரவைப் பயன்படுத்துதல், இலக்கு மேம்பாடுகளைச் செய்தல், பின்னர் மீண்டும் மதிப்பீடு செய்தல், Harness-இன் தொடர்ச்சியான பரிணாம வளர்ச்சிக்கான ஒரு மூடிய சுழற்சியை உருவாக்குதல். @@ -827,7 +828,7 @@ ML ஆராய்ச்சியாளர்கள் நீண்ட கால இந்தப் பாலத்தின் இரு முனைகளும் பின்வருமாறு இணைக்கப்பட்டுள்ளன. மதிப்பீட்டுப் பக்கத்தில் திரட்டப்பட்ட சொத்துக்களை, பயிற்சி சமிக்ஞைகளாக கிட்டத்தட்ட தடையின்றி மாற்ற முடியும்: நன்கு வரையறுக்கப்பட்ட ஒரு **Rubric** அல்லது சரிபார்ப்பான் (validator) என்பது அடிப்படையில் **சரிபார்க்கக்கூடிய வெகுமதிகளுடன் கூடிய வலுவூட்டல் கற்றலுக்கான (Reinforcement Learning with Verifiable Rewards, RLVR) ஒரு வெகுமதிச் சார்பே** ஆகும்—ஸ்கோரிங் ஸ்கிரிப்ட் நேரடியாக வெகுமதி ஸ்கிரிப்டாக மாறுகிறது; ஒரு சோதனை தேர்ச்சி பெறுகிறதா அல்லது ஒரு நிலை தரத்தை பூர்த்தி செய்கிறதா என்பது மதிப்பீட்டு அளவுகோலாகவும், வலுவூட்டல் கற்றலுக்கான வெகுமதியாகவும் செயல்படுகிறது. இருப்பினும், பயிற்சி, மதிப்பீடு கவலைப்பட வேண்டியிராத புதிய தேவைகளை அறிமுகப்படுத்துகிறது. முதலாவது **நம்பகமான மீட்டமைப்பு (reset) சொற்பொருள்**: பயிற்சி மில்லியன் கணக்கான எபிசோட்களை இயக்குகிறது (ஒரு எபிசோட் என்பது ஆரம்ப நிலையிலிருந்து பணி நிறைவு வரையிலான ஒரு முழுமையான தொடர்பு சுற்று), மேலும் ஒவ்வொரு எபிசோடும் சூழலை ஒரு தீர்மானகரமான, தூய்மையான ஆரம்ப நிலைக்கு மீட்டமைக்க முடிய வேண்டும்; இல்லையெனில், சாய்வு சமிக்ஞை (gradient signal) முந்தைய எபிசோடின் எஞ்சிய நிலைகளால் மாசுபடுத்தப்படும். இரண்டாவது **மதிப்பீட்டை விட அதிகமான செயல்திறன் (throughput)**: சில ஆயிரம் மதிப்பீடுகள் முடிவுகளை எடுக்க போதுமானவை, ஆனால் பயிற்சிக்கு ஏற்றுக்கொள்ளக்கூடிய சுவர்-கடிகார நேரத்தில் மில்லியன் கணக்கான தொடர்புகளை மாதிரிக்கு வழங்க வேண்டும்; சூழல் இணைநிலை (parallelism) மற்றும் ஒவ்வொரு நிகழ்வின் மேல்நிலை செலவும் பயிற்சி சாத்தியமா என்பதை நேரடியாக தீர்மானிக்கிறது. இந்த இரண்டு புள்ளிகள்—சரிபார்ப்பான்களை வெகுமதிச் சார்புகளாக மாற்றுதல், மற்றும் பயிற்சி-தர மீட்டமைப்பும் செயல்திறனும்—அத்தியாயம் 8 இல் விரிவாக விளக்கப்படும். -![படம் 7-8: உருவகப்படுத்துதல் நம்பகத்தன்மை நிறமாலை](images/fig7-8.svg) +![படம் 7-9: உருவகப்படுத்துதல் நம்பகத்தன்மை நிறமாலை](images/fig7-9.svg) **டிஜிட்டல் சூழல்கள்** பக்கத்தில், AWorld கட்டமைப்பு GAIA பணிகளுக்காக ஒரு கட்டுப்படுத்தக்கூடிய MCP சர்வர் சாண்ட்பாக்ஸை உருவாக்குகிறது, 126 கருவி செயல்பாடுகளை உள்ளடக்கிய 26 MCP சர்வர்களை வழங்குகிறது, உண்மையான APIகளை நேரடியாக அணுகுவதால் ஏற்படும் தடைகள் மற்றும் கட்டுப்படுத்த முடியாத பக்க விளைவுகளைத் தவிர்க்கிறது. அனைத்து கருவி அழைப்புகளும் மீண்டும் இயக்கக்கூடியவை மற்றும் தணிக்கை செய்யக்கூடியவை. AWorld இன் விநியோகிக்கப்பட்ட கட்டமைப்பு, பாரம்பரிய தொடர் செயலாக்க நேரத்தை 7695 வினாடிகளில் இருந்து 525 வினாடிகளாக (14.6x வேக அதிகரிப்பு) குறைக்கிறது, மேலும் சூழலின் நிலையற்ற வடிவமைப்பு ஒவ்வொரு நிகழ்வையும் முற்றிலும் சுயாதீனமாக்கி, திறமையான இணைநிலையை ஆதரிக்கிறது. @@ -838,7 +839,7 @@ ML ஆராய்ச்சியாளர்கள் நீண்ட கால > ரோபோ கையாளுதலுக்கான உருவகப்படுத்துதல் சூழலை அமைக்கவும். `ch7/SimpleVLA-RL` மற்றும் OpenVLA ஆவணங்களைப் படித்து, Vision-Language-Action மாதிரியின் கட்டமைப்பைப் புரிந்துகொள்ளவும் (விஷன் என்கோடர், மொழி மாதிரி மற்றும் ஆக்ஷன் டிகோடர் ஆகியவற்றின் எண்ட்-டு-எண்ட் ஒருங்கிணைப்பு, படங்கள் மற்றும் உரையை ஒரு பகிரப்பட்ட சொற்பொருள் இடத்தில் திட்டமிடுதல்). RoboTwin2 சூழலை உள்ளமைக்கவும், அதன் கண்காணிப்பு இடத்தைப் (மூன்று-காட்சி RGB + 14-பரிமாண கூட்டு நிலை) மற்றும் செயல் இடத்தையும் (14-பரிமாண கட்டுப்பாட்டு திசையன்) புரிந்துகொள்ளவும். `move_can_pot` இல் உள்ள சூழல் சீரற்றமயமாக்கல் பொறிமுறை மற்றும் இடஞ்சார்ந்த கட்டுப்பாட்டு தர்க்கத்தைப் படிக்கவும். முன்-பயிற்சி பெற்ற மாதிரியின் மதிப்பீட்டை இயக்கவும், வெற்றி விகிதம், நிறைவு நேரம் மற்றும் தோல்வி முறைகளைப் பதிவு செய்யவும், குறிப்பாக ஆக்ஷன் சங்கிங் பொறிமுறையின் தாக்கத்தில் கவனம் செலுத்தவும். > > -> ![படம் 7-9: OpenVLA மற்றும் RoboTwin2 உடல்சார் நுண்ணறிவு சூழல்](images/fig7-9.svg) +> ![படம் 7-10: OpenVLA மற்றும் RoboTwin2 உடல்சார் நுண்ணறிவு சூழல்](images/fig7-10.svg) > > @@ -850,7 +851,7 @@ ML ஆராய்ச்சியாளர்கள் நீண்ட கால ## அத்தியாயச் சுருக்கம் -இந்த அத்தியாயம் ஒரு மையக் கேள்வியைச் சுற்றி அமைந்துள்ளது: ஏஜெண்ட் உண்மையிலேயே மேம்பட்டதா என்பதை எப்படித் தெரிந்துகொள்வது? மீளுருவாக்கக்கூடிய சோதனைச் சூழல், leakage-ஐ எதிர்க்கும் dataset, LLM-as-a-Judge, model selection, iterative improvement—இந்தச் சங்கிலியின் ஒவ்வொரு இணைப்பும் முடிவின் நம்பகத்தன்மையை நிர்ணயிக்கிறது. அளவிடப்பட்ட எடுத்துக்காட்டுகள் நான்கு நடைமுறை எச்சரிக்கைகளை வழங்குகின்றன: structured memory-யுடன் RAG-ஐ இணைப்பதால் மட்டும் synergy உறுதி ஆகாது; cache மற்றும் compression சேமிப்புகளை நேரடியாகக் கூட்ட முடியாது; reference audio-வின் தேர்வு multimodal score-ன் பொருளையே மாற்றும்; Harness வழங்கும் input representation பணி வெற்றியையும் token செலவையும் ஒரே நேரத்தில் தீர்மானிக்கலாம். Model selection-லும் ஒரே operating point-ஐப் பார்க்காமல், வெவ்வேறு resource budget-களில் capability எவ்வாறு வளர்கிறது என்பதை ஒப்பிட வேண்டும். Production Agent-க்கு evaluation என்பது அவ்வப்போது நடக்கும் தேர்வு அல்ல; ஒவ்வொரு product முடிவிலும் உள்ள தொடர்ச்சியான validation ஆகும். +இந்த அத்தியாயம் ஒரு மையக் கேள்வியைச் சுற்றி அமைந்துள்ளது: ஏஜெண்ட் உண்மையிலேயே மேம்பட்டதா என்பதை எப்படித் தெரிந்துகொள்வது? இந்தச் சங்கிலி நான்கு கண்ணிகளால் ஆனது: முதலில் எது வெற்றி என்பதைத் தெளிவுபடுத்துதல் (Pass@k, Best@k, Pass consecutive@k ஆகியவற்றின் அடிப்படை வேறுபாடுகள்), பின் பணிகள் எங்கிருந்து வருகின்றன என்பதை நிர்ணயித்தல் (பொதுத் தரவரிசைச் சோதனைகள், சொந்த வணிகத் தொகுப்பு, உற்பத்தி trajectory திரும்பப் பாய்தல்), அடுத்து சரிபார்ப்பு முறையைத் தேர்ந்தெடுத்தல் (நிர்ணயவாதச் சரிபார்ப்பான்களிலிருந்து சோதனைப் பட்டியல், Rubric உடன் LLM தீர்ப்பு, இணை ஒப்பீடு வரை), இறுதியாக மதிப்பெண்களை முடிவுகளாக மாற்றுதல் (புள்ளியியல் முக்கியத்துவம், தோல்விக் காரணம் கண்டறிதல், பின்னடைவுப் பணிகள், மாதிரித் தேர்வு). இந்தச் சங்கிலியின் ஒவ்வொரு இணைப்பும் முடிவின் நம்பகத்தன்மையை நிர்ணயிக்கிறது. அளவிடப்பட்ட எடுத்துக்காட்டுகள் நான்கு நடைமுறை எச்சரிக்கைகளை வழங்குகின்றன: structured memory-யுடன் RAG-ஐ இணைப்பதால் மட்டும் synergy உறுதி ஆகாது; cache மற்றும் compression சேமிப்புகளை நேரடியாகக் கூட்ட முடியாது; reference audio-வின் தேர்வு multimodal score-ன் பொருளையே மாற்றும்; Harness வழங்கும் input representation பணி வெற்றியையும் token செலவையும் ஒரே நேரத்தில் தீர்மானிக்கலாம். Model selection-லும் ஒரே operating point-ஐப் பார்க்காமல், வெவ்வேறு resource budget-களில் capability எவ்வாறு வளர்கிறது என்பதை ஒப்பிட வேண்டும். Production Agent-க்கு evaluation என்பது அவ்வப்போது நடக்கும் தேர்வு அல்ல; ஒவ்வொரு product முடிவிலும் உள்ள தொடர்ச்சியான validation ஆகும். நூலின் ஒட்டுமொத்தக் கட்டமைப்பின்படி, இந்த அத்தியாயம் கட்டுவது அத்தியாயம் 1 இன் கண்டுபிடிப்புச் சுழற்சியில் உள்ள **சான்று** பகுதியே: தோல்விக் காரணக் கண்டறிதலே, அடுத்துவரும் முன்மொழிவுகளுக்கு உறுதியான ஆதாரம் உண்டா என்பதைத் தீர்மானிக்கிறது. diff --git a/book-ta/images/fig7-1.svg b/book-ta/images/fig7-1.svg index f301aacbe..00a258f5d 100644 --- a/book-ta/images/fig7-1.svg +++ b/book-ta/images/fig7-1.svg @@ -1,19 +1,62 @@ - - - -Layer 1: Evaluate the Environment -"Where to test" — Tool-calling / Human-computer interaction / Simulation environment - - -Layer 2: Evaluation Methods -"How to judge" — Dataset design · LLM-as-a-Judge · Pairwise comparison and ranking - - -Layer 3: Evaluation-Driven Decisions -"What to do after testing" — Model selection · Architecture optimization · Continuous iteration - -Engineering Themes Throughout the Chapter -• Observability -• Simulation environment -• Internal evaluation - \ No newline at end of file + + + + + + + + +① வெற்றியின் வரையறை +Pass@k திறன் உச்சம் · Pass^k நம்பகத்தன்மை + + + +② பணிகளின் மூலம் + +பொதுத் தரவரிசைச் சோதனைகள் +உத்திகளைக் கடன் · கரடு வடிகட்டல் + +சொந்த வணிகத் தொகுப்பு +உண்மையான பணிப் பரவல் + +உற்பத்தியிலிருந்து திரும்பல் +தோல்விக் காரணத்தின் விளைவு + + + +③ சரிபார்ப்பு முறை +← பணியின் இயந்திரச் சரிபார்ப்புத் தன்மை அளவின்படி → + +நிர்ணயவாதம் +SWE-bench + + +சோதனைப் பட்டியல் +τ²-bench + + +Rubric + LLM +திறந்த பணிகள் + + +இணை ஒப்பீடு +Chatbot Arena + + + +④ முடிவுகளின் பயன்பாடு +புள்ளியியல் முக்கியத்துவம் → தோல்விக் காரணம் → பின்னடைவு → மாதிரி & Harness + + +பின்னடைவுப் பணிகள் புதிய வழக்குகளாகும் + + +ஆதரவுக் கட்டமைப்பு +கவனிக்கத்தன்மை · உள் மதிப்பீட்டுக் கட்டமைப்பு (அப்லேஷன் / AB / கொடிகள்) · உருவகச் சூழல் (அத்தியாயம் 8) + diff --git a/book-ta/images/fig7-10.svg b/book-ta/images/fig7-10.svg new file mode 100644 index 000000000..49fd62882 --- /dev/null +++ b/book-ta/images/fig7-10.svg @@ -0,0 +1,69 @@ + + + + +Multimodal observation + +Head camera +224×224 RGB + +Left wrist camera +224×224 RGB + +Right wrist camera +224×224 RGB + +14-dimensional joint state vector + +Vision-Language-Action model (VLA) + +Vision encoder +SigLIP → visual tokens + + +Language model +Llama 2 7B backbone + + +Action decoder +→ 14-dimensional continuous control vector +Action chunking: generate 25 consecutive actions at once + + + +Instruction: "Put the can into the pot" + + +SAPIEN physics engine + +Dual-arm robot +7 DOF each = 14-dimensional action + +Environment randomization +Position 60cm / orientation ±22.5° + +Collision detection + physics simulation +Rigid body / soft body / friction + +Action + +Observation + +Evaluation metrics + +Success rate +Can inside pot +and not fallen + +Completion time +25 steps × 25 actions += 625 control steps + +Generalization ability +Cross-position/orientation +/Appearance variant + +Sim-to-Real +Domain randomization +→ Real migration + \ No newline at end of file diff --git a/book-ta/images/fig7-3.svg b/book-ta/images/fig7-3.svg index d8f6fcc1c..b64a70fad 100644 --- a/book-ta/images/fig7-3.svg +++ b/book-ta/images/fig7-3.svg @@ -1,68 +1,76 @@ - - + + + + + + + - -User Simulator (LLM) - -Known Information: -Name: Sarah Johnson -Booking: BK-98712 -Task Instruction: -"There seems to be a problem with the flight" -→ Gradually reveal details -→ Do not proactively provide the booking number - -Agent (To Be Evaluated) - - -LLM Reasoning + Strategy Selection -① May I have your booking number? -② lookup_booking(BK-98712) -③ Flight UA123 has been canceled -④ cancel_booking(BK-98712) -⑤ Refund $150, 3-5 business days - -Tools + Database - -lookup_booking -Query booking details -modify_booking -Modify booking status -cancel_booking -Cancel and refund -search_flights -Search for alternative flights -send_notification -Send confirmation notification - -DB State: -bookings, users, flights - -Dialogue - - -Tool Call - - -Dual-control environment: User simulator can also directly operate the shared environment (tools + database) - -After task completion: Multi-layer verification - -DB status check - -booking.status == 'cancelled' -refund_record EXISTS -refund.amount == 150.00 - -Dialogue content verification - -Contains 'refund' + amount -Contains 'arrival time' -No false information present - -Process compliance check - -Obtain user confirmation before modification -No unauthorized operation -No excessive transfer to human agent - \ No newline at end of file + + +பயனர் உருவகப்படுத்தி (LLM) +known_info: John Smith / 555-123-2002 / பிரான்ஸில் +task_instructions: படிப்படி வெளிப்பாடு · உணர்வு · நங்கூரம் +ஏற்பு: excellent மட்டுமே தீர்வு + + + +ஏஜெண்ட் (மதிப்பீட்டில்) +உள்ளீடு: டிக்கெட் + கள கொள்கை +தெரியாது: சாதனத்தின் உண்மை நிலை +வழிநடத்த மட்டுமே முடியும், செய்ய முடியாது + + + +பல சுற்று உரையாடல் +படிப்படியான தகவல் வெளிப்பாடு + + + +பகிர் சூழல் (இரட்டைக் கட்டுப்பாடு: இரு பக்கமும் நிலையை மாற்றும்) + +சாதனப் பக்க நிலை +விமான பயன்முறை ON · ரோமிங் OFF · சிக்கனம் · மீதி தரவு +பயனர் கருவிகள்: toggle_airplane_mode / toggle_roaming + check_status_bar / run_speed_test + +வழங்குநர் பக்கத் தரவுத்தளம் +வாடிக்கையாளர் C1001 · இணைப்புகள் L1001/L1002/L1003 · திட்டங்கள் · கட்டணம் +ஏஜெண்ட் கருவிகள்: get_customer_by_phone / get_data_usage + enable_roaming / refuel_data + + + + + + +பயனரின் toggle_roaming சூழலை மாற்றியது; ஏஜெண்ட் கருவியை மீண்டும் அழைத்தால்தான் அறியும் — சரிபார்ப்பு இதையும் உள்ளடக்கும் + + + +பணி முடிந்த பின்: நான்கு அடுக்குச் சோதனை + தொகுப்பு விதி + +env_assertions +மொபைல் தரவு கிடைக்கிறது +வேகம் ≥ 200 / excellent + +actions +toggle_airplane_mode +requestor user ஆக இருக்க வேண்டும் + +communicate_info +தேவையான தகவல் தெரிவிக்கப்பட்டதா +இப்பணியில் null + +nl_assertions +இயல்மொழி மட்டத் தீர்ப்பு +இப்பணியில் null +reward_basis = ["ENV_ASSERTION"] → முதல் அடுக்கு மட்டுமே; மற்றவை பதிவாகும், வெகுமதியில் சேராது + diff --git a/book-ta/images/fig7-4.svg b/book-ta/images/fig7-4.svg index ef07742ca..289eaf2ea 100644 --- a/book-ta/images/fig7-4.svg +++ b/book-ta/images/fig7-4.svg @@ -1,53 +1,54 @@ - - + + + + + + - -Rubric - -Factual Correctness: Essential -Logical Coherence: Important -Hallucination Detection: Veto ⚠ -Completeness: Important - -Candidate Answer - -Agent Output: -"Refund processed, $150 will be credited within - 3-5 business days." - - -Reference Solution (Optional) - -Standard Answer / Scoring Points: -Must include refund amount -Must include credit time -Cannot promise a specific date - - - - -Judge Model (GPT-5 / Gemini 2.5) -Multi-source heterogeneous evaluation to prevent same-source bias - - -Structured evaluation output - -Factual Correctness -4/4 -Amount and time are both accurate -Completeness -3/4 -Missing explanation of refund method -Hallucination Detection -PASS -No false information -Logical Coherence -4/4 -Clear causal relationship - -Scoring Aggregation Strategy -Weighted average: Σ(weight × dimension score) -Veto: Hallucination=FAIL → total score=0 -Multi-judge: median of 3 judges -Edge case flag: disagreement >2 points → human review - \ No newline at end of file + +பணியின் இயந்திரச் சரிபார்ப்புத் தன்மை: உயர் +தாழ் + + +நிர்ணயவாதம் +இறுதி நிலை ஒற்றை, வினவக்கூடியது +தேர்ச்சி / தோல்வி +SWE-bench சோதனை இயக்கும் + + + +சோதனைப் பட்டியல் +பல நிர்ணயவாதச் சோதனைகள் +அறிவிக்கப்பட்ட அடிப்படையில் தொகுப்பு +τ²-bench நான்கு அடுக்கு + + + +Rubric + LLM +பரிமாணம் உண்டு, குறியீடு தீர்க்காது +பரிமாணவாரி மதிப்பெண் + காரணம் +சேவைத் தரம், அறிக்கை எழுதல் + + + +இணை ஒப்பீடு +பரிமாணத்தையே எழுதுவது கடினம் +A, B இடையே மட்டுமே தீர்ப்பு +Chatbot Arena + + +நிர்ணயவாதச் சரிபார்ப்பு +முழு மறுஉருவாக்கம், CI க்கு ஏற்றது, மலிவு +விலை: சரி/தவறு மட்டுமே, இடம் சொல்லாது + + +மாதிரித் தீர்ப்பு +நோயறி பரிமாணம் தரும், உறுதிமொழியாகாததையும் உள்ளடக்கும் +விலை: தீர்ப்புச் சாய்வும் ஏற்ற இறக்கமும், அதிகச் செலவு + diff --git a/book-ta/images/fig7-5.svg b/book-ta/images/fig7-5.svg index 3bca837d2..ef07742ca 100644 --- a/book-ta/images/fig7-5.svg +++ b/book-ta/images/fig7-5.svg @@ -1,56 +1,53 @@ - + - -Chatbot Arena Anonymous Battle - -Model A (Anonymous) - -"Refund processed, will arrive in 3-5 - business days to your account" -VS - -Model B (Anonymous) - -"Okay, refund will be processed" - - -User blind pick → A is better - -Elo Update Formula -Expected win rate E_A = 1/(1+10^((R_B-R_A)/400)) | Update: R_A' = R_A + K*(1-E_A) -Live Leaderboard (Example) -Rank -Model -Elo -Win rate vs #2 - -1 -Claude 4 Opus -1352 -— -2 -GPT-5 -1318 -— -3 -Gemini 2.5 Pro -1290 -45% -4 -DeepSeek R2 -1265 -42% -5 -Qwen 3 Max -1230 -39% -6 -Llama 4 405B -1198 -36% - - -GRPO: Introducing Pairwise Comparison into RL Training -A set of candidate responses → Normalize relative advantage → Policy update (bypass explicit reward model) + +Rubric + +Factual Correctness: Essential +Logical Coherence: Important +Hallucination Detection: Veto ⚠ +Completeness: Important + +Candidate Answer + +Agent Output: +"Refund processed, $150 will be credited within + 3-5 business days." + + +Reference Solution (Optional) + +Standard Answer / Scoring Points: +Must include refund amount +Must include credit time +Cannot promise a specific date + + + + +Judge Model (GPT-5 / Gemini 2.5) +Multi-source heterogeneous evaluation to prevent same-source bias + + +Structured evaluation output + +Factual Correctness +4/4 +Amount and time are both accurate +Completeness +3/4 +Missing explanation of refund method +Hallucination Detection +PASS +No false information +Logical Coherence +4/4 +Clear causal relationship + +Scoring Aggregation Strategy +Weighted average: Σ(weight × dimension score) +Veto: Hallucination=FAIL → total score=0 +Multi-judge: median of 3 judges +Edge case flag: disagreement >2 points → human review \ No newline at end of file diff --git a/book-ta/images/fig7-6.svg b/book-ta/images/fig7-6.svg index 1ccc604da..3bca837d2 100644 --- a/book-ta/images/fig7-6.svg +++ b/book-ta/images/fig7-6.svg @@ -1,48 +1,56 @@ - - - -Execution trace tree (single task) - -Trace: Check Beijing weather for user tomorrow (3.2s, $0.008) - -LLM Call: Intent recognition -Claude 4 Sonnet · 0.4s · 320 tokens - -Tool：get_weather(Beijing) -MCP Server · 1.8s · 200ms TTFT - -├─ HTTP Request -api.weather.com · 1.6s - -└─ Response Parse -JSON → Structured weather data - -LLM Call: Generate response -Claude 4 Sonnet · 0.8s · 580 tokens - -Tool：send_message(user) -0.2s · Contains weather summary - - - - - - - -Monitoring dashboard - -Cost tracking -Today: $12.30 (1,200 calls) -This month: $340 (34K calls) -Anomaly: task#892 looped search 14 times, cost $2.1 - -Performance monitoring -P50 / P95 / P99 latency: 2.1s / 8.4s / 15.2s -Tool success rate: 94.3% - -Quality audit -Task success rate: 87% Hallucination trigger: 2.1% -Security violations: 0 (this month) User satisfaction: 4.3/5 - -Closed loop: Trace data → Identify issues → A/B testing →Prompt version management → Continuous optimization - + + + + +Chatbot Arena Anonymous Battle + +Model A (Anonymous) + +"Refund processed, will arrive in 3-5 + business days to your account" +VS + +Model B (Anonymous) + +"Okay, refund will be processed" + + +User blind pick → A is better + +Elo Update Formula +Expected win rate E_A = 1/(1+10^((R_B-R_A)/400)) | Update: R_A' = R_A + K*(1-E_A) +Live Leaderboard (Example) +Rank +Model +Elo +Win rate vs #2 + +1 +Claude 4 Opus +1352 +— +2 +GPT-5 +1318 +— +3 +Gemini 2.5 Pro +1290 +45% +4 +DeepSeek R2 +1265 +42% +5 +Qwen 3 Max +1230 +39% +6 +Llama 4 405B +1198 +36% + + +GRPO: Introducing Pairwise Comparison into RL Training +A set of candidate responses → Normalize relative advantage → Policy update (bypass explicit reward model) + \ No newline at end of file diff --git a/book-ta/images/fig7-7.svg b/book-ta/images/fig7-7.svg index 7ff1dd778..1ccc604da 100644 --- a/book-ta/images/fig7-7.svg +++ b/book-ta/images/fig7-7.svg @@ -1,56 +1,48 @@ - - - - -① Observation: Diagnostic Report -Overall Success Rate: 88% (102/116) -transcription: 0% complex_ui: 17% -math_counting: 0% Wi-Fi Operation: 0% -Task 82,102-115 Concentrated Failures - -② Hypothesis: Three-Layer Improvement Framework - -Surface Layer -H1 Set Navigation Prompt H2 UI Rules - -Middle Layer -H3 Fix Multimodal Pipeline H4 Thinking - -Deep Layer -H5 GPT-5 H6 UI Element Tree - - -③ Experiment: Phased Validation (5 runs × 116 tasks per configuration) - -H1 Navigation -Setup 0%→75% -token+8% - -H3 Multimodal -Transcription 0%→80% -Latency +1s - -H4 Thinking -Counting 0%→70% -Latency 3x! - -H6 Element Tree -UI 17%→52% -token+30% - -④ Decision: Cost-Benefit Trade-off -✓ H1+H3: Low Cost, High Benefit → Deploy -✗ H4: Only 8% Tasks Benefit but 3x Latency → Reject -✓ H6: 35% Improvement / 30% Cost → Deploy -✗ H5: 15s/Step Unacceptable → Alternative - -⑤ Iteration: New Cycle -Deploy H1+H3+H6 → 88%→94% -New Report Shows Different Failure Modes: - H7: Conditional Thinking Enabled - H8: Expand gesture action space - -↑ Loop - -Methodology: Observe → Hypothesize → Experiment → Decide → Iterate = From alchemy to scientific engineering - \ No newline at end of file + + + +Execution trace tree (single task) + +Trace: Check Beijing weather for user tomorrow (3.2s, $0.008) + +LLM Call: Intent recognition +Claude 4 Sonnet · 0.4s · 320 tokens + +Tool：get_weather(Beijing) +MCP Server · 1.8s · 200ms TTFT + +├─ HTTP Request +api.weather.com · 1.6s + +└─ Response Parse +JSON → Structured weather data + +LLM Call: Generate response +Claude 4 Sonnet · 0.8s · 580 tokens + +Tool：send_message(user) +0.2s · Contains weather summary + + + + + + + +Monitoring dashboard + +Cost tracking +Today: $12.30 (1,200 calls) +This month: $340 (34K calls) +Anomaly: task#892 looped search 14 times, cost $2.1 + +Performance monitoring +P50 / P95 / P99 latency: 2.1s / 8.4s / 15.2s +Tool success rate: 94.3% + +Quality audit +Task success rate: 87% Hallucination trigger: 2.1% +Security violations: 0 (this month) User satisfaction: 4.3/5 + +Closed loop: Trace data → Identify issues → A/B testing →Prompt version management → Continuous optimization + diff --git a/book-ta/images/fig7-8.svg b/book-ta/images/fig7-8.svg index f8d104612..7ff1dd778 100644 --- a/book-ta/images/fig7-8.svg +++ b/book-ta/images/fig7-8.svg @@ -1,41 +1,56 @@ - + - - -Simulation fidelity → -Can -Expand -Exhibition -sex -↑ - -Mock API -unit test level -million times/hour - -AWorld -MCP sandbox -126 tool functions -525s/round distributed - -AndroidWorld -Simulator -116 real-world application tasks -UI Automator - -Isaac Gym -GPU parallelism -thousands of parallel instances -Slightly compromised accuracy - -RoboTwin2 -physics engine -High-precision collision -Single-instance CPU - -real world -Perfect fidelity -Non-resettable - + +① Observation: Diagnostic Report +Overall Success Rate: 88% (102/116) +transcription: 0% complex_ui: 17% +math_counting: 0% Wi-Fi Operation: 0% +Task 82,102-115 Concentrated Failures + +② Hypothesis: Three-Layer Improvement Framework + +Surface Layer +H1 Set Navigation Prompt H2 UI Rules + +Middle Layer +H3 Fix Multimodal Pipeline H4 Thinking + +Deep Layer +H5 GPT-5 H6 UI Element Tree + + +③ Experiment: Phased Validation (5 runs × 116 tasks per configuration) + +H1 Navigation +Setup 0%→75% +token+8% + +H3 Multimodal +Transcription 0%→80% +Latency +1s + +H4 Thinking +Counting 0%→70% +Latency 3x! + +H6 Element Tree +UI 17%→52% +token+30% + +④ Decision: Cost-Benefit Trade-off +✓ H1+H3: Low Cost, High Benefit → Deploy +✗ H4: Only 8% Tasks Benefit but 3x Latency → Reject +✓ H6: 35% Improvement / 30% Cost → Deploy +✗ H5: 15s/Step Unacceptable → Alternative + +⑤ Iteration: New Cycle +Deploy H1+H3+H6 → 88%→94% +New Report Shows Different Failure Modes: + H7: Conditional Thinking Enabled + H8: Expand gesture action space + +↑ Loop + +Methodology: Observe → Hypothesize → Experiment → Decide → Iterate = From alchemy to scientific engineering \ No newline at end of file diff --git a/book-ta/images/fig7-9.svg b/book-ta/images/fig7-9.svg index 49fd62882..f8d104612 100644 --- a/book-ta/images/fig7-9.svg +++ b/book-ta/images/fig7-9.svg @@ -1,69 +1,41 @@ - - + + - -Multimodal observation - -Head camera -224×224 RGB - -Left wrist camera -224×224 RGB - -Right wrist camera -224×224 RGB - -14-dimensional joint state vector - -Vision-Language-Action model (VLA) - -Vision encoder -SigLIP → visual tokens - - -Language model -Llama 2 7B backbone - - -Action decoder -→ 14-dimensional continuous control vector -Action chunking: generate 25 consecutive actions at once - - - -Instruction: "Put the can into the pot" - - -SAPIEN physics engine - -Dual-arm robot -7 DOF each = 14-dimensional action - -Environment randomization -Position 60cm / orientation ±22.5° - -Collision detection + physics simulation -Rigid body / soft body / friction - -Action - -Observation - -Evaluation metrics - -Success rate -Can inside pot -and not fallen - -Completion time -25 steps × 25 actions -= 625 control steps - -Generalization ability -Cross-position/orientation -/Appearance variant - -Sim-to-Real -Domain randomization -→ Real migration + + +Simulation fidelity → +Can +Expand +Exhibition +sex +↑ + +Mock API +unit test level +million times/hour + +AWorld +MCP sandbox +126 tool functions +525s/round distributed + +AndroidWorld +Simulator +116 real-world application tasks +UI Automator + +Isaac Gym +GPU parallelism +thousands of parallel instances +Slightly compromised accuracy + +RoboTwin2 +physics engine +High-precision collision +Single-instance CPU + +real world +Perfect fidelity +Non-resettable + \ No newline at end of file diff --git a/book-tr/chapter7.tr.md b/book-tr/chapter7.tr.md index a1ee08738..c601f4dc2 100644 --- a/book-tr/chapter7.tr.md +++ b/book-tr/chapter7.tr.md @@ -17,58 +17,117 @@ Değerlendirme, bu kararlara bilimsel bir dayanak sağlar: sistematik karşıla Bölüm 1'de tanıtılan Harness engineering perspektifinden bakıldığında, değerlendirme Harness içinde "doğrulama" işlevinin merkezi rolünü üstlenir. Kilit kavrayış şudur: **değerlendirmenin nesnesi yalnızca model değil, modelle Harness'in bileşimi olmalıdır**. Aynı model farklı Harness'lerde çarpıcı biçimde farklı sonuçlar verebilir — bazı ekipler yalnızca Harness'i iyileştirerek aynı modelin terminal türü görevlerdeki performansını belirgin biçimde yükseltti (ayrıntılar için bkz. Bölüm 5). Bu şu anlama gelir: Agent değerlendirmede kötü performans gösterdiğinde iyileştirme yönü modeli değiştirmek değil, Harness'in bir bileşenini (prompt'lar, araç tasarımı, geri bildirim döngüleri) iyileştirmek olabilir. Sağlam bir değerlendirme sistemi, "model yeteneğinin yetersizliği" ile "Harness tasarım kusuru" gibi özünde farklı iki sorunu birbirinden ayırabilmelidir. **Bu iki sorunu ayırmanın yaygın yolu model değiştirme deneyidir (model swap)**: Harness sabit tutulur, yalnızca daha güçlü ya da daha zayıf bir model takılır ve puanın ne kadar oynadığına bakılır. Daha güçlü modelle puan yükselmiyorsa darboğaz Harness'tedir. Daha zayıf modelle puan sert biçimde düşüyor ve sonuçlar model yeteneğiyle birlikte büyük dalgalanmalar gösteriyorsa, en doğrudan okuma darboğazın modelin kendi yeteneğinde olduğu ve mevcut performansı esas olarak modelin belirlediğidir (bunun görevin doğası gereği zor olmasından mı, yoksa Harness'in modelin ön bilgisine aşırı yaslanmasından mı kaynaklandığı ayrıca incelenmelidir). Bunun, yukarıda anılan "ablation deneyi"nden farklı bir yöntem olduğuna dikkat edin: ablation **Harness'in bir bileşenini kapatıp** genel performansın nasıl değiştiğine bakar, model değiştirme ise **Harness'i sabit tutup yalnızca modeli değiştirir** — ilki Harness'in içinde hangi parçanın önemli olduğunu bulur, ikincisi darboğazın modelde mi Harness'te mi olduğunu ayırt eder. Bir değerlendirme sisteminin değeri, modellerin hızla evrildiği bir çağda daha da belirginleşir. Model yetenekleri hızla ilerlemeye devam ediyor, ama yeni bir modelin kamuya açık benchmark'larda daha iyi sonuç vermesi, sizin özel göreviniz üzerinde de daha iyi olacağı anlamına gelmez — tam tersine performans gerilemesi (regression, yani yeni sürümün bazı yönlerden eskisinin gerisinde kalması) ortaya çıkabilir. Yalnızca kendi değerlendirme veri kümenizde yapılan eksiksiz bir test, veriye dayalı bir yükseltme kararı vermenizi sağlar. Dahası, sağlam bir değerlendirme sistemi "gelecekteki modeller için ürün geliştirmeyi" uygulanabilir bir stratejiye dönüştürür: mevcut model ticari kullanımı taşıyacak güçte olmasa bile, ürün geliştirmesini şimdiden tamamlayıp değerlendirme kümesini kurabilir, yeni modellerin performansını sürekli izleyebilir ve eşiği aşan ilk modelle hemen yayına çıkabilirsiniz. +Bir değerlendirme sistemi dört halkaya ayrılabilir: neyin başarı sayıldığı, görevlerin nereden geldiği, kimin doğruladığı ve puanın nasıl karara dönüştüğü. Şekil 7-1'de gösterilmiştir. + +![Şekil 7-1: Agent Değerlendirme Sisteminin Dört Halkası](images/fig7-1.svg) + +## Bir değerlendirme görevinin anatomisi: τ²-bench'in telecom alanı + +Önce τ²-bench'in telecom alanından gerçek bir görevi baştan sona inceleyelim. Kaynak kod depoda `chapter7/tau2-bench` altında, görev dosyası ise `data/tau2/domains/telecom/tasks_small.json`. + +### Görev tanımının dört bileşeni + +Aşağıda o dosyadaki görevlerden biri, okumayı kolaylaştırmak için kısaltılarak verilmiştir. + +```jsonc +{ + "id": "[mobile_data_issue]airplane_mode_on|user_abroad_roaming_enabled_off", + + // Agent'a verilen çağrı kaydı + "ticket": "Kullanıcının telefonu internete bağlanamıyor ve durum çubuğunda + 'No Service' yazıyor. Müşteri John Smith, numara 555-123-2002, + şu anda Fransa'da. Sorun ancak hız testi excellent verirse + çözülmüş sayılır. Tarife değiştirmek istemiyor, ama gerekirse + 2,0 GB veri yüklemeyi kabul ediyor.", + + // Kullanıcı simülatörüne verilen davranış kuralları + "user_scenario": { "instructions": { + "known_info": "You are John Smith with phone number 555-123-2002. + You are currently abroad in France.", + "unknown_info": null, + "task_instructions": + "…express mild frustration after the first unsuccessful attempt. + You will consider the issue resolved only when speed test returns + excellent internet speed and nothing else. If it returns poor, fair + or good, you will not consider the issue resolved. + Whenever the agent asks you about your device, always ground your + responses on the results of tool calls. … + Never make up the results of tool calls." + }}, + + // Çalıştırmadan önce her iki taraf aynı başlangıç noktasına sıfırlanır + "initial_state": { "initialization_actions": [ + { "env_type": "user", "func_name": "turn_airplane_mode_on" }, + { "env_type": "user", "func_name": "turn_roaming_off" }, + { "env_type": "assistant", "func_name": "enable_roaming", + "arguments": { "customer_id": "C1001", "line_id": "L1002" } } + ]}, + + // Puanlama ölçütleri + "evaluation_criteria": { + "actions": [ + { "requestor": "user", "name": "toggle_airplane_mode" }, + { "requestor": "user", "name": "toggle_roaming" } + ], + "env_assertions": [ + { "func_name": "assert_mobile_data_status", "expected_status": true }, + { "func_name": "assert_internet_speed", + "expected_speed": 200, "expected_desc": "excellent" } + ], + "communicate_info": null, + "nl_assertions": null, + "reward_basis": ["ENV_ASSERTION"] + } +} +``` -> **Bölüm Rehberi** -> -> Bu bölüm eksiksiz bir değerlendirme sistemini üç katmanda kurar. Birinci katman **değerlendirme ortamıdır** ("nerede test edilir"): otomatik ve tekrarlanabilir bir test ortamının nasıl kurulacağı — araç çağırma tipi ve insan-makine etkileşimi tipi olmak üzere iki paradigma dahil. İkinci katman **değerlendirme yöntemleridir** ("nasıl karar verilir"): veri kümesi tasarım ilkelerinden ve değerlendirme metrikleri sisteminden (neyin ölçüleceği) LLM-as-a-Judge (büyük dil modelini hakem olarak kullanma) ile otomatik değerlendirmeye, oradan da ikili karşılaştırma ve model sıralamasına. Üçüncü katman **değerlendirmeye dayalı karar almadır** ("test edildikten sonra ne yapılır"): değerlendirme sonuçlarını model seçimi, mimari iyileştirme ve sürekli yineleme için eyleme dönük bir kılavuza çevirmek ve gözlenen puan farkının gerçekten güvenilir olup olmadığını istatistiksel anlamlılıkla karara bağlamak. Bunlara ek olarak bu bölüm observability'yi (gözlemlenebilirlik) ve üretim düzeyindeki Agent'ların iç değerlendirme altyapısını da tartışır, sonunda ise Bölüm 8'deki post-training'e bağlanan simülasyon ortamlarını tanıtır. -> -> Bölüm boyunca süren temel fikir şudur: **bir değerlendirme sisteminin başlıca değeri mevcut sisteme puan vermek değil, model evrimini hızlı ve güvenilir biçimde takip etmenizi sağlamaktır**. Daha güçlü ya da daha ucuz bir model yayımlandığında, sağlam bir değerlendirme sistemine sahip ekip birkaç saat içinde geçiş kararını verebilir; böyle bir sistemi olmayan ekip ise yalnızca sezgisine güvenebilir veya topluluktan gelecek geri bildirimi bekleyebilir — rekabetin kızıştığı Agent pazarında bu hız farkı başarıyla başarısızlığı belirleyebilir. +Bu tanımda açılması gereken dört tasarım kararı var. -![Şekil 7-1: Değerlendirme Sisteminin Üç Katmanı](images/fig7-1.svg) +**Kullanıcının bilgi sınırı açıkça modellenmiştir.** `known_info` yalnızca üç şey içerir: ad, telefon numarası ve bulunulan ülke. Arızanın asıl iki nedeni — uçak modunun açık, veri dolaşımının kapalı olması — orada yoktur. Kullanıcı bunları bilmediği için kendiliğinden söyleyemez; Agent bunlara ancak soru sorarak ve kullanıcıdan kontrol etmesini isteyerek ulaşabilir. **Aşamalı bilgi açığa çıkarma (Progressive Information Disclosure)** görev tanımı düzeyinde işte böyle uygulanır: simülatörü "hepsini birden söyleme" gibi bir istemle bağlayarak değil, kullanıcının bilgi kapsamını ayrı bir alan olarak modelleyerek. Çoğu benchmark görevin başında tam gereksinimi ortaya koyar; oysa gerçek bir kullanıcının ilk cümlesi genellikle "internete giremiyorum" kadardır. Talebi uygulanabilir hale getirecek kadar netleştirmek, Agent'ın yapabilmesi gereken işin bir parçasıdır. -## Somut Bir Değerlendirme Örneği +**Simülatör replik değil, davranış kuralı alır.** `task_instructions` üç tür kısıtı bir arada barındırır: duygu ayarı (ilk başarısız denemeden sonra hafif bir memnuniyetsizlik göstermek), kabul ölçütü (sorun ancak hız testi excellent verirse çözülmüş sayılır; poor, fair ve good kabul edilmez) ve **olguya dayandırma (Grounding)** koşulu: cihaz durumuna dair her yanıt bir araç çağrısının döndürdüğü değere dayanmalıdır — "Never make up the results of tool calls". Üçüncüsü en kritik olanıdır: dayandırma kısıtı olmadan simüle kullanıcı Agent'ın yönlendirmesine uyup sorunun çözüldüğünü onaylar ve değerlendirme, iki modelin birbirini teyit etmesine dönüşür. -Metodolojiye derinlemesine girmeden önce, eksiksiz bir örnek üzerinden sezgi kuralım. Bir müşteri hizmetleri Agent'ı kurduğumuzu ve onun iade taleplerini ele alma yeteneğini değerlendirmemiz gerektiğini varsayalım. +**Başlangıç durumu, denetleyen tarafa göre bölünmüştür.** `env_type` iki değer alır, `user` ve `assistant`: uçak modu ile dolaşım anahtarı kullanıcı tarafına, operatör tarafındaki `enable_roaming` ise Agent tarafına aittir. Arızanın biçimini belirleyen tam da bu ayrımdır: operatör tarafında dolaşım açıktır ama kullanıcının cihazında kapalıdır, dolayısıyla Agent veritabanına baktığında yalnızca "yapılandırma normal" sonucuna varır. Arıza, veritabanının göremediği taraftadır ve ancak kullanıcıdan kontrol etmesi istenerek ortaya çıkar. -**Test durumu**: Kullanıcı 3 gün önceki siparişi iade etmek istiyor (sipariş numarası #12345, tutar ¥299). Şirket politikası: 7 gün içinde tam iade yapılabilir. +**Puanlama ölçütleri dört katmana ayrılır ve bu görev bunlardan yalnızca birini kullanır.** `env_assertions` son durumu denetler (mobil veri kullanılabilir, hız 200 Mbps ve üzeri ve derece excellent), `actions` kilit eylemlerin gerçekleşip gerçekleşmediğini ve **hangi tarafın** yaptığını denetler, `communicate_info` ile `nl_assertions` ise gerekli bilginin kullanıcıya iletilip iletilmediğini denetler. Bu görevin `reward_basis` alanında yalnızca `ENV_ASSERTION` bildirilmiştir; kalan katmanlar her zamanki gibi hesaplanıp kaydedilir ama nihai ödüle girmez. Puanlama dayanağı her görev için ayrı bildirilir, genel olarak sabitlenmez. -**Agent'ın trajectory'si**: +### Gerçek bir çalıştırmanın trajectory'si -```text -Kullanıcı: 3 gün önce aldığım kulaklığı iade etmek istiyorum, sipariş numarası 12345. (Bugün 2026-04-10) +Şimdi okurdan τ²-bench telecom alanının değerlendirme görevlerini kendisinin çalıştırmasını, görev tasarımını, kullanıcı simülatörünü, süreç ve sonuç doğrulama mantığını gözlemlemesini, ayrıca Agent'ın yürütme trajectory'sine bakarak neden başarısız olduğunu çözümlemesini istiyoruz. -Agent (düşünüyor): Kullanıcı iade istiyor, önce sipariş bilgisini sorgulamam gerek. -Agent → query_order(order_id="12345") aracını çağırır -Araç döndürür: {status: "delivered", amount: 299, date: "2026-04-07", item: "Bluetooth kulaklık"} +> **Deney 7-1 ★: τ²-bench'i çalıştırmak ve τ-bench'ten evrimini karşılaştırmak** +> +> Bu deney, insan-bilgisayar etkileşimi türündeki değerlendirme ortamının tasarım noktalarını anlamak için τ²-bench değerlendirme çerçevesini çalıştırır. Önce görev tanım dosyasını bu bölümdeki güzergâhı izleyerek okuyun: her görev dört bölümden oluşur — bilinen bilgi, görev yönergesi, başlangıç durumu ve başarı koşulları. Ardından tam değerlendirme akışını çalıştırın, kullanıcı simülatörü ile Agent arasındaki çok turlu diyaloğu gözlemleyin ve tipik başarısızlık kiplerini (politika ihlali, bilgi atlama, aşırı insan temsilciye aktarma vb.) çözümleyin. +> +> ![Şekil 7-3: τ²-bench'te çift denetimli ortam ve katmanlı doğrulama](images/fig7-3.svg) -Agent (düşünüyor): Sipariş tarihi 2026-04-07, bugün 2026-04-10, arada 3 gün var; 7 günlük iade süresi içinde, tam iade koşullarını karşılıyor. -Agent → process_refund(order_id="12345", amount=299) aracını çağırır -Araç döndürür: {refund_id: "R-98765", status: "processing", eta: "3-5 iş günü"} +Eşlik eden depoda bir çalıştırma kaydı saklanmaktadır (`chapter7/tau2-bench-eval`). Aşağıda bunlardan başarılı olan bir çalıştırmayı çözümlüyoruz. -Agent: Sizin için iade işlemini başlattım; #12345 numaralı siparişin (Bluetooth kulaklık, ¥299) tam iadesi işleniyor, - tutarın 3-5 iş günü içinde hesabınıza geçmesi bekleniyor. İade numarası R-98765, ilerlemeyi sorgulamak için kullanabilirsiniz. -``` +İlk on küsur tur hesap belirleme aşamasıdır. Agent numaradan C1001 müşterisini bulur, ardından L1001, L1002 ve L1003 hatlarının veri kullanımını tek tek sorgular ve kullanıcının Fransa'da gerçekte hangi numarayı kullandığını yeniden sorar. 17. mesajda yanlış bir sonuca varır: + +> **Agent** (17): 555-123-2002 numarası etkin hatlarınız arasında yok; en yakını 555-123-2001… + +Bu sonuç yalnızca tek bir hattın, L1001'in sorgusuna dayanır. Kullanıcı numaranın doğru olduğunda ısrar edince Agent L1002'yi sorgular ve ancak o zaman eşleştirir. Belirleyici dönüm 30. mesajda gelir: -**Rubric ile puanlama** (dört boyut, her boyut 1-4 puan). Tablo 7-1, bu müşteri hizmetleri iade görevi için bir puanlama örneği verir; Rubric'in bir Agent trajectory'sini nasıl denetlenebilir değerlendirme boyutlarına ayırdığını gösterir. +> **Kullanıcı** (30) → `check_network_status()`, `check_status_bar()` çağırır +> +> **Aracın döndürdüğü** (31): `Airplane Mode: ON | Cellular Connection: no_service | Mobile Data Enabled: Yes | Data Roaming Enabled: No` +> +> **Kullanıcı** (33): telefonun şu an uçak modunda olduğunu görüyorum, sinyal olmamasının nedeni bu. Mobil veri açık ama veri dolaşımı kapalı. Uçak modunu kapatıp deneyeyim mi? -Tablo 7-1 Müşteri Hizmetleri İade Görevi için Rubric Puanlama Örneği +Araç çağrısını yapan taraf Agent değil, **kullanıcıdır**. **Çift denetim (Dual-Control)** mekanizması budur: simüle kullanıcının `check_status_bar`, `toggle_airplane_mode`, `reseat_sim_card` ve `run_speed_test` gibi kendine ait bir araç kümesi vardır. -| Boyut | Ölçüt | Puan | Gerekçe | -|--------------------|-----------------------------------|---------|-------------------------------| -| İşlem doğruluğu | İade tutarı ve sipariş numarası doğru mu | 4 | Doğru sorgulama yapıp ¥299'luk tam iadeyi başlattı | -| Politika uygunluğu | 7 günlük iade politikasına uyuluyor mu | 4 | Sipariş iade süresi içinde, politikaya uygun | -| Bilgi eksiksizliği | Tutar, hesaba geçiş süresi ve iade numarası bildirildi mi | 4 | Üç kritik bilginin üçü de bildirildi | -| Halüsinasyon tespiti (veto maddesi) | Var olmayan bilgi uyduruldu mu | Geçti | Tüm bilgiler araçların döndürdüğü sonuçlardan geliyor | +Sonraki teşhis sorunsuz ilerler: Agent kullanıcıdan uçak modunu kapatıp dolaşımı açmasını ister, kullanıcı her iki işlemi de yapar (35, 37) ve durum çubuğu tam çekim 5G'ye döner; Agent hız testi ister, sonuç 275 Mbps ve derece Excellent gelir (46) ve kullanıcı sorunun çözüldüğünü onaylar. İki `env_assertions` da geçer ve `reward = 1.0` olur. -Halüsinasyonun derecelendirilen bir puanlama boyutu değil de bir **veto maddesi** olarak listelenmesinin nedeni, kaliteye dik (ortogonal) olmasıdır: akıcı, ayrıntılı ve nazik bir yanıt yanlış bilgi içeriyorsa, kullanıcıya verdiği zarar kısa ama doğru bir yanıtınkinden çok daha büyüktür. (Veto mekanizmasının genel tasarımı için ilerideki "Rubric'in Dört İlkesi" bölümüne bakın.) +Bu tam puanlı trajectory'de doğrulayıcının yakalayamadığı bir sorun da vardır. Telecom Agent politikasının ilk paragrafı "You should only make one tool call at a time" der; oysa 4. mesajda Agent `get_customer_by_phone` ile `get_customer_by_name` çağrılarını bir arada göndermiştir. Doğrulayıcı bunu hata saymamıştır, çünkü bu görevin `reward_basis` alanı yalnızca son durumu dikkate alır. Bu, τ²-bench'in bir ihmali değil, ikili ödülün doğasında olan bedeldir: süreç ayrıntısını, modeller arasında karşılaştırılabilir tek bir sayıyla takas eder. Ne var ki üretim ortamındaki değerlendirme sistemleri çoğu zaman daha fazlasını ister: yalnızca doğru mu yanlış mı demeyi değil, sorunun nerede olduğunu da göstermeyi. -Bu test durumu geçti. Ama iyi bir değerlendirme yalnızca başarı senaryolarını değil, sınırları ve tuzakları da ölçer: kullanıcı 15 gün önceki bir siparişi (iade süresi dolmuş) iade etmek istediğinde Agent bunu doğru biçimde reddedebiliyor mu? Kullanıcı "müşteri temsilcisi iadeyi zaten onayladı" dediğinde, Agent sistemde hiçbir kayıt yokken buna kolayca inanır mı? Agent'ların yetenek düzeyini asıl ayıran, işte bu sınır senaryolarıdır. +Başarısız olan görev de çözümlemeye değer. Kullanıcının numarası 555-123-2002'dir ama Agent L1001 hattını seçmiş ve o hattın 3,2/5 GB kullanımını dayanak alarak ilerlemiştir. Yol boyunca `get_details_by_id(L1001)` o hattın numarasının 555-123-2001 olduğunu açıkça döndürmüştür; Agent bu sonucu okumuş ama yargısını düzeltmemiş, ardından ilgisiz teşhislere onlarca mesaj harcamış ve sonunda insan temsilciye aktarmıştır. Aslında görevin yarısını tamamlamıştır: kullanıcıya veri tasarrufu modunu kapattırmış ve kullanıcı tarafındaki bu eylem gerçekten gerçekleşip ortam tarafından doğrulanmıştır. Ama hat seçimindeki hata yüzünden gereken 2 GB yükleme hiç yapılmamış ve üç son durum savı da başarısız olmuştur. Bu başarısızlığın biçimi, ileride "Başarısızlık atfı" bölümünde ele alınan AndroidWorld örneğine çok benzer: yargıyı düzeltmek için gereken kanıt bağlama çoktan girmiştir, ama Agent buna dayanarak geri dönmemiştir. -Yukarıdaki akış — test durumlarını tanımlamak, Agent'ı çalıştırmak, Rubric ile puanlamak, sonuçları analiz etmek — değerlendirmenin temel iskeletidir. Bu bölümün geri kalanı her adımın tasarım yöntemini sırasıyla açacak. +Tek bir görev bile, bir değerlendirme kümesinin yanıtlaması gereken bütün soruları ortaya koyar: neyin başarı sayıldığı, görevlerin nereden geldiği, kimin doğruladığı ve puanın nasıl karara dönüştüğü. İzleyen bölümler bunları sırayla ele alıyor. -## Değerlendirme metrikleri sistemi: güncellenmiş ölçütler +## Değerlendirme metrikleri: başarının tanımı -Ortamı veya veri kümesini kurmadan önce “başarı”nın ne olduğunu belirlemek gerekir: bir kez çalışan bir yol bulmak yeterli mi, yoksa her çalıştırma hatasız mı olmalı? Tanım değişince mühendislik kararı da değişebilir. Bu bölüm önce bu ölçütü kurar, ardından ilerleyen kısımlarda ortamın, veri kümesinin ve puanlayıcının nasıl gerçeklendiğini anlatır. +Bir önceki bölümün değerlendirme sonucu beş görevden dördünün geçmesiydi. Yalnızca 0,8 sayısına bakarak sistemin kullanılabilir olup olmadığına karar verilemez. Bu bir iade müşteri hizmetleri Agent'ıysa, beş kullanıcıdan birinin hak ettiği iadeyi alamaması demektir; açık arayan bir güvenlik Agent'ıysa, beşte dört isabet epeyce iyidir. Fark, iş senaryosunun ne kadar yüksek bir başarı oranı talep ettiğindedir. ### Teknik harika: Pass@k ile yetenek tavanı @@ -99,209 +158,151 @@ $$ Değerlendirme raporu $k$ denemenin ne olduğunu açıkça yazmalıdır: aynı görevin $k$ bağımsız örneklemi mi, yoksa üretim hattındaki ardışık $k$ görev mi. Yan etkisi olan işlemlerde "başarana kadar yeniden dene" denemez; örnekleme bir kum havuzunda ya da geri alınabilir bir ortamda yapılmalı ve her başarısızlık güvenilirlik ölçütüne işlenmelidir. -### Süreç metrikleri: Siyah kutudan beyaz kutuya - -Yalnızca nihai sonuca bakmak yeterli değildir; Agent'ın sonuca ulaşma süreci de aynı ölçüde önemlidir. **Eylem geçerlilik ve yetki oranı**, işlemler içinde hem geçerli hem de yetkili olanların payını ölçer — geçersiz işlemler arasında var olmayan bir aracı çağırmak ve yanlış parametre türü geçirmek vardır; yetki aşımı ise izin sınırlarının dışına çıkan davranışları anlatır. Yüksek bir oran, Agent'ın araç ekosistemini net biçimde kavradığını gösterir. **Tool calling doğruluk oranı** bir adım daha ileri gider ve parametrelerin anlamsal olarak da makul olmasını ister: arama aracının sorgu sözcükleri ihtiyacı doğru ifade etmeli, dosya işlemlerinin yolu doğru hedefi göstermelidir. - -**Yol verimliliği**, görevin ne kadar ekonomik tamamlandığını ölçer: adım sayısı (düşün-eyle-gözlemle döngüsünün tekrar sayısı), gereksiz eylemler (aynı anahtar kelimeyi tekrar tekrar aramak, aynı dosyayı defalarca okumak) ve geri dönüş sayısı (hatanın fark edilip düzeltilme sıklığı — ara sıra geri dönmek normaldir, ama sık geri dönüş ileriye dönük planlamanın yetersiz olduğunu gösterir). "Makul adım sayısını" tanımlamak için insan uzmanlardan veya sezgisel algoritmalardan bir referans çizgisi oluşturmak gerekir. - -**Retrieval kapsama oranı** bilgi toplama türü görevlere yöneliktir: Agent bilgi uzayını yeterince araştırdı mı? Yalnızca arama sonuçlarının ilk sayfasına bakıp aceleyle bir sonuca mı vardı? **Maliyet ve gecikme** ise istek sayısına, token harcamasına (girdi/çıktı maliyetleri ayrılmalı, KV Cache'in yeniden kullanımı hesaba katılmalıdır) ve duvar saati süresine (model çıkarımı + araç yürütme + ağ gecikmesi dahil) bakar; darboğazı bulmak için sürenin dağılımını izlemek gerekir. - -### Güvenlik, sağlamlık ve trajectory kapsamı - - -**Güvenlik ve uyum metrikleri** üretim dağıtımında kritik önemdedir: hassas işlemlerin tetiklenmesi (veri silme / izin değiştirme / dışarıya iletişim gönderme), veri sızdırma (günlüklere parola yazdırma / özel dokümanları dış API'lere gönderme) ve kural dışı içerik — hepsi **sıfır tolerans ilkesine** tabi olmalıdır. Halüsinasyonun veto maddesiyle aynı mantık geçerlidir (bkz. ilerideki "Rubric'in Dört İlkesi"): tek bir ciddi güvenlik ihlali bütün değerlendirmeyi veto eder, diğer boyutlardaki üstün performans buna muafiyet sağlamaz. - -**Sağlamlık**, belirsizlik karşısındaki kararlılığı ölçer: rastgele tohum duyarlılığı (farklı başlangıç değerleriyle performans ne kadar değişiyor), sayfa değişikliklerine uyum (bir sitenin arayüz güncellemesi tam bir çökmeye yol açmamalıdır), API dalgalanmalarına tolerans (geçici arızalar, zaman aşımları ve biçim değişiklikleri zarifçe ele alınabiliyor mu) ve uzun süreli bellek paraziti (context'te biriken güncelliğini yitirmiş bilgi hatalı kararlara yol açıyor mu). - -**Yürütme trajectory'si ile nihai sonucun çifte kapsanması**. Değerlendirmede kolayca gözden kaçan bir ayrım şudur: Agent'ın yürütme sırasında "ne söylediği ve ne yaptığı" (yani Bölüm 1'de tanımlanan trajectory) ile "sistemin sonunda ne hale geldiği" (nihai sonuç, outcome) iki ayrı şeydir. Agent'ın "bilet alındı" demesi trajectory düzeyinde bir bilgidir; veritabanında gerçekten bir sipariş kaydının oluşması ise sonuç düzeyinde bir doğrulamadır. Yalnızca trajectory'ye bakmak "söyledi ama yapmadı" durumlarını kaçırır; yalnızca sonuca bakmak da ara adımların yoldan çıktığını göstermeyebilir. Anthropic bir keresinde şöyle bir örnek vermişti: bir uçak bileti rezervasyon Agent'ı yürütme sırasında havayolunun politikasındaki bir boşluğu fark edip kullanıcıya daha ucuz bir seçenek buldu — yalnızca önceden belirlenmiş yürütme yoluna göre puanlanırsa bu koşu başarısız sayılırdı; oysa nihai sonuç açısından bakıldığında kullanıcı daha iyi bir seçenek elde etmişti. Bu yüzden sistematik kör noktalardan kaçınmak için her iki değerlendirme türü de kapsanmalıdır. - -### İnsan örneklemesi ve adversarial inceleme - -Otomatik değerlendirme çoğu durumda güvenilir olsa bile düzenli insan eliyle örnekleme denetimi gerekir: farklı görev türlerini, başarılı/başarısız vakaları ve sınır puanların yakınındaki belirsiz vakaları kapsayacak biçimde — yalnızca sonuçları değil, puanlama gerekçelerinin isabetliliğini de gözden geçirerek. - -Bu denetim bir adım öteye götürülüp **değerlendirici kalibrasyonu** olarak sistemleştirilebilir: LLM değerlendiricilerini büyük ölçekte kullanmaya başlamadan önce, insan eliyle etiketlenmiş bir altın standart küme (örneğin görev türlerini ve zorluk düzeylerini kapsayan 100-200 vaka) oluşturulur; değerlendirici modelin (yani hakem rolündeki LLM'in; mekanizması için bkz. sonraki bölüm, LLM-as-a-Judge) insan etiketleriyle uyum oranı bu küme üzerinde ölçülür (basit uyum oranı ya da Cohen's kappa gibi bir uyum katsayısı; ikincisi rastgele tutturmadan gelen payı dışarıda bırakır). Değerlendirici model ancak önceden belirlenmiş bir eşiği (örneğin kappa'nın 0,7'nin üzerinde olması) aştıktan sonra büyük ölçekli değerlendirmede kullanılmalıdır; bundan sonra da değerlendirici model veya Rubric her güncellendiğinde altın standart küme üzerinde yeniden kalibre edilmelidir. Bu adım atlanırsa, LLM değerlendiricisinin verdiği puanlar insan yargısının güvenilir bir vekili değil, yalnızca "başka bir modelin görüşü" olur. +## Değerlendirme ortamı -**Düşmanca inceleme**, kırmızı takım (Red Teaming) yoluyla zorlayıcı vakaları bilerek kurgular: yüzeyde kusursuz görünen ama gizli hatalar içeren yanıtlar, anahtar kelime yığarak işin içinden sıyrılan yanıtlar ve değerlendirici modelin bilinen önyargılarını kullanarak hak etmediği yüksek puanı alan yanıtlar. **Çoklu hakem mekanizması** ise birden fazla bağımsız değerlendiricinin ayrı ayrı puan vermesini sağlar ve nihai sonucu ağırlıklı ortalama veya tutarlılık denetimiyle belirler — değerlendiriciler arasında ciddi bir görüş ayrılığı olduğunda vaka, ek insan incelemesi gerektiriyor diye işaretlenir. +Metrik dayanağı belirlendikten sonraki soru nerede ölçüleceğidir. Değerlendirme ortamı, yinelenebilir biçimde çalıştırılabilen bir düzenektir: aynı başlangıç durumu verildiğinde aynı Agent karşılaştırılabilir sonuçlar üretmelidir. -## Otomatik Değerlendirme Ortamı +### Beş bileşen -Agent değerlendirmesi, tekrar tekrar çalıştırılabilen otomatik bir ortam gerektirir — geliştirme aşamasında değişikliklerin etkisini hızlıca test edebilen bir ortam. Böyle bir ortamı kurmak üç soruyu yanıtlamayı gerektirir: ne değerlendirilecek (görev tanımı ve doğrulama ölçütleri), kime karşı değerlendirilecek (Agent'ın etkileşimde bulunduğu tarafın nasıl simüle edileceği) ve hangi ölçütle puanlanacak. +Yukarıda incelenen telecom görevine dönelim. Onu ölçüt alırsak, yinelenebilir bir değerlendirme ortamının gerektirdiği her şey zaten mevcuttur. -### Değerlendirme Ortamının Temel Bileşenleri +**Veri kümesi (Dataset)**, görev dosyasının kendisidir: başlangıç durumu, Agent için çağrı kaydı, simülatör için davranış kuralları ve kabul ölçütleri tek bir kayıtta paketlenir; bir kayıt bir test durumudur. -Bir değerlendirme ortamı beş öğeden oluşur — ilerideki alt bölümler bunlardan veri kümesi tasarımı ile puanlama ölçütü tasarımını ayrıntılandıracak: +**Ortam durumu (Environment State)**, görev yürütülürken değişebilen bilgidir: veritabanındaki müşteriler, hatlar, tarifeler ve faturalar ile cihaz tarafındaki uçak modu, dolaşım, veri tasarrufu anahtarı ve kalan veri. Sıfırlanabilir olmalıdır ve `initialization_actions` tam da bu sıfırlama betiğidir. Gerçekçilik, durum değişimlerinin iş mantığına uymasını; denetlenebilirlik ise her çalıştırmadan önce aynı başlangıç noktasına dönülebilmesini gerektirir. -**Veri kümesi (Dataset)** görev kümesini tanımlar; başlangıç durumunu, hedef açıklamasını ve isteğe bağlı referans çözümleri içerir. +**Araç arayüzü (Tools)** iki tarafa bölünmüştür. Agent müşteri sorgulama, kullanım sorgulama, veri yükleme, insan temsilciye aktarma gibi operatör tarafı işlemleri çağırabilir; kullanıcı ise cihazındaki anahtarları kullanabilir. Her iki araç kümesi de atomik işlemlerdir; "kullanıcının internet sorununu çöz" gibi üst düzey bir soyutlama yoktur — soyutlama düzeyi fazla yükselirse değerlendirme tek bir işlev çağrısının denetimine iner, planlama ve akıl yürütme aracın kendisine soğurulur. -**Ortam durumu (Environment State)** görev yürütülürken değişen bilgiyi tutar ve gerçekçilikle denetlenebilirlik arasında denge kurmalıdır. Örneğin müşteri hizmetleri değerlendirmesinde ortam durumu, veritabanındaki sipariş kayıtlarını ve kullanıcı hesap bakiyesini kapsar. Agent `process_refund`'u çağırdıktan sonra sipariş durumu "delivered" değerinden "refunded" değerine döner ve bakiye artar — işte bunlar "değişebilir bilgi"dir. "Gerçekçilik", durum değişimlerinin iş mantığına uygun olmasını gerektirir (iade tutarı sipariş tutarını aşamaz); "denetlenebilirlik" ise her testin aynı başlangıç durumuna sıfırlanabilmesini gerektirir. +**Puanlama ölçütü (Rubric)**, `evaluation_criteria` içindeki dört katman denetim ile `reward_basis` toplama kuralıdır. -**Araç arayüzleri (Tools)** Agent'ın yürütebileceği işlemler kümesini tanımlar — araçlar aşırı yüksek düzeyli soyutlamalar ("kullanıcının sorununu çöz" gibi) değil, atomik işlemler (sipariş sorgulama, rezervasyon değiştirme, e-posta gönderme gibi) sunmalıdır; böylece Agent bu işlemleri planlayarak ve düşünerek birleştirmek zorunda kalır. +**Yürütme protokolü (Interaction Protocol)**, etkileşim sırasını ve bitiş koşullarını belirler. Buradaki normal bitiş sinyali, simüle kullanıcının `###STOP###` çıktısı vermesidir; ayrıca tur üst sınırı vardır ve simüle kullanıcı sabrı tükendiğinde konuşmayı kendisi de bitirebilir — iletişim verimliliğinin fazla düşük olması başlı başına başarısızlık sayılır. -**Puanlama ölçütü (Rubric)** Agent'ın performansını nicelleştirir; ikili (geçti/kaldı), sürekli (0 ile 100 arası puan) veya çok boyutlu (doğruluk, verimlilik ve güvenlik için ayrı ayrı puan) olabilir. +Beş bileşenden biri eksilirse değerlendirme yinelenebilir bir döngü oluşturmaz. Aşağıda başka benchmark'ları incelerken de bu beş maddeyi karşılaştırma çerçevesi olarak kullanacağız. -**Yürütme protokolü (Interaction Protocol)** etkileşim biçimini ve sonlanma koşullarını belirler. +### İnsan-bilgisayar etkileşimi ve araç çağrısı türündeki değerlendirme ortamları -Bu beş öğe birlikte tekrarlanabilir bir değerlendirme döngüsü oluşturur. +Telecom gibi görevlerin mutlaka bir muhatabı olmalıdır ve beş bileşen içindeki kullanıcı simülasyonu kısmı vazgeçilmezdir. Bir de hiç muhatabı olmayan büyük bir görev sınıfı vardır: kod üretimi, veri çözümlemesi, matematik problemi çözme gibi görevlerde Agent baştan sona yalnızca araçlarla etkileşir, doğruluk yürütme doğrulamasından geçip geçmemesiyle belirlenir ve ne insan etiketlemesi ne de model yargısı gerekir. Bu tür ortamlar kullanıcı simülatörünü atlar; kalan dört bileşen yine vardır, yalnızca biçimleri yalınlaşır: ortam durumu bir dosya sistemi ya da veritabanıdır, puanlama ölçütü bir parça test kodudur ve yürütme protokolü "bir yanıt verene ya da tur hakkı bitene dek araç çağırmayı sürdür"e iner. -![Şekil 7-2: Araç Çağırma Tipi ve İnsan-Makine Etkileşimi Tipi Değerlendirme Ortamları](images/fig7-2.svg) +Verifiers çerçevesi bu tür ortamları iki boyuta göre katmanlar: görevin turlar arası durum tutması gerekip gerekmediği ve yalıtım gerekip gerekmediği. `SingleTurnEnv` bir matematik sorusu sorup yanıtı doğrudan doğrulamaya; `ToolEnv` birkaç web sayfasında arayıp derli toplu yanıt verdikten sonra nihai sonucu doğrulamaya; `StatefulToolEnv` veritabanı kaydını değiştirip durum değişimini doğrulamaya; `SandboxEnv` ise sandbox'ta kod çalıştırıp çıktı dosyalarını denetlemeye uygundur. Tablo 7-1 bu dört türü özetler; görev durumu, araç çağrısı ve yalıtım gereksinimlerine göre seçim yapmayı kolaylaştırır. -Agent'ın görevine göre değerlendirme ortamları kabaca araç çağırma tipi ve insan-makine etkileşimi tipi olarak ikiye ayrılabilir. +Tablo 7-1 Verifiers ortam türlerinin karşılaştırması -### Araç Çağırma Tipi Değerlendirme Ortamı - -Kod üretimi ve veri analizi gibi ağırlıklı olarak araç kullanımına dayanan görevlerde, Verifiers çerçevesi tipik bir tasarım kalıbı sergiler. Agent görevi önceden tanımlanmış araçları çağırarak tamamlar; doğrulama, insan etiketlemesine veya model değerlendirmesine dayanmadan, çalıştırılabilir ölçütler (testler geçiyor mu, yanıt eşleşiyor mu) üzerinden yapılır. - -Verifiers katmanlı bir ortam tasarımı getirir: `SingleTurnEnv` tek turluk görevler (basit soru-yanıt gibi) için uygundur, `ToolEnv` çok turlu tool calling'in otonom döngüsünü destekler, `StatefulToolEnv` ve `SandboxEnv` ise durumlu araçları ve uzun süre çalışan sandbox ortamlarını (kod yürütme gibi) destekler. Örneğin `SingleTurnEnv`, bir matematik sorusu sorup yanıtı doğrudan doğrulamaya uygundur; `ToolEnv`, birden fazla web sayfasında arama yapıp yanıtı sentezledikten sonra nihai sonucu doğrulamaya uygundur; `StatefulToolEnv`, veritabanı kayıtlarını değiştirip veritabanı durumundaki değişimi doğrulamaya uygundur; `SandboxEnv` ise sandbox içinde kod çalıştırıp çıktı dosyalarını denetlemeye uygundur. Tablo 7-2 bu ortam türlerini özetler; okuyucu görev durumu, tool calling ve izolasyon ihtiyacına göre uygun değerlendirme ortamını seçebilir. - -Tablo 7-2 Verifiers Ortam Türlerinin Karşılaştırması - -| Ortam türü | Durum koruma | Tool calling | Tipik kullanım | +| Ortam türü | Durum tutma | Araç çağrısı | Tipik kullanım | |---|---|---|---| -| SingleTurnEnv | Yok | Yok | Tek turlu soru-yanıt, matematik soruları | -| ToolEnv | Yok | Çok turlu | Arama + bilgi sentezi | -| StatefulToolEnv | Var | Çok turlu | Veritabanı kayıtlarını değiştirme | -| SandboxEnv | Var + izolasyon | Çok turlu | Kod yürütme ve test | - -Çerçeve paralel örneklemeyi ve trajectory önbelleklemesini destekler; her değerlendirmenin eksiksiz trajectory'si (gözlem, eylem, ödül) sonradan analiz ve yeniden oynatma için saklanır. - -Ortamın ayrıca işlemlerin duruma bağımlılığını ele alması gerekir — bir aracın yürütme sonucu mevcut duruma bağlıdır; başarısızlık halinde basit bir hata bayrağı yerine açık hata mesajları verilmelidir ki Agent hatalarından öğrenip stratejisini ayarlayabilsin. +| SingleTurnEnv | Yok | Yok | Tek turlu soru-yanıt, matematik | +| ToolEnv | Yok | Çok turlu | Arama + bilgi birleştirme | +| StatefulToolEnv | Var | Çok turlu | Veritabanı kaydı değiştirme | +| SandboxEnv | Var + yalıtımlı | Çok turlu | Kod yürütme ve test | -### İnsan-Makine Etkileşimi Tipi Değerlendirme Ortamı +Çerçeve paralel örnekleme ve trajectory önbelleğini destekler; her değerlendirmenin tam trajectory'si (gözlem, eylem, ödül) saklanır, böylece sonradan çözümlemek ve yeniden oynatmak kolaylaşır. Ayrıca bir aracın yürütme etkisi o anki duruma bağlı olduğundan, başarısızlık halinde yalın bir başarısızlık bayrağı yerine açık bir hata iletisi döndürülmeli ve Agent buna göre stratejisini ayarlayabilmelidir. -Birçok gerçek görev yalnızca tool calling içermez, insan kullanıcılarla diyalog da gerektirir. Bir müşteri hizmetleri Agent'ının belirsiz ifadeleri anlaması, ihtiyacı netleştirmesi, arka uç sistemleri sorgulaması ve bilgiyi kullanıcıya doğrulatması gerekir. Bu tür görevlerin değerlendirmesi temel bir zorlukla karşılaşır: otomatik bir ortamda gerçek kullanıcı nasıl simüle edilir? +Araç çağrısı türündeki değerlendirme, gözlemlenebilir durum değişimlerinin doğruluğunu sınar; insan-bilgisayar etkileşimi türündeki değerlendirme ise iletişim stratejisinin yerindeliğini sınar — ilki eylemi, ikincisi yönlendirmeyi doğrular. İki ortam türünün yapısal karşılaştırması için bkz. Şekil 7-2. -Kilit tasarım ilkesi **kademeli bilgi açıklamadır (Progressive Information Disclosure)**; insan-makine etkileşimi tipi değerlendirmeyi geleneksel benchmark testlerinden ayıran temel fark budur. Çoğu benchmark en baştan bütün gereksinimi ortaya döker, oysa gerçek hayatta kullanıcılar ihtiyacını daha ilk anda net biçimde tarif edemez — genellikle yalnızca "uçuşumda bir sorun var galiba" ya da "internete bağlanamıyorum" derler. Agent'ın ihtiyacı proaktif sorularla netleştirmesi gerekir ve bu sürecin kendisi yeteneğin önemli bir göstergesidir. Bu yüzden değerlendirmede **simüle edilen kullanıcının tüm bilgileri asla en baştan Agent'a açılmamalıdır**; bilgi, diyalog boyunca ihtiyaç duyuldukça ve kademeli olarak verilmelidir. +![Şekil 7-2: Araç Çağrısı ve İnsan-Bilgisayar Etkileşimi Değerlendirme Ortamları](images/fig7-2.svg) -τ-bench'in çözümü **kullanıcı simülasyonudur (User Simulation)**: kullanıcı rolünü başka bir LLM üstlenir ve önceden tanımlanmış talimatlara göre Agent'la konuşur. Simüle edilen kullanıcı bir görev talimatı alır ("yarınki uçuşumu iptal etmem gerekiyor" gibi), diyalog sırasında gerekli bilgiyi Agent'a adım adım açar, sorulara yanıt verir ve görev tamamlandığında bir sonlandırma sinyali gönderir. Prompt, simüle edilen kullanıcıdan "bütün bilgiyi tek seferde açıklamamasını, yalnızca o adım için gerekli olanı vermesini" ve "talimatta verilmemiş bilgiyi uydurmamasını" ister. Kullanıcı simülasyonunun tasarımı gerçekçilikle denetlenebilirlik arasında bir ödünleşim gerektirir: davranış gerçek bir kullanıcıya yakın olmalı (belirsiz ifadeler, eksik bilgi, ara sıra duygusal dalgalanmalar), aynı zamanda tekrarlanabilirliği güvenceye almak için belirli bir senaryoyu izlemelidir. +## Değerlendirme veri kümesinin tasarımı -Aşağıda kademeli bilgi açıklamalı çok turlu bir diyalog örneği verilmiştir (kullanıcı simülatörü sabit bir senaryoya göre hareket eder): +Değerlendirme ortamı sahne ise veri kümesi senaryodur. Aynı beş bileşenle, görev sınıfı değişince doldurma biçimi tümüyle farklılaşabilir: görevlerin nereden geldiği, doğrulayıcının ne kadar derine inebildiği ve ezberlenmenin nasıl önlendiği. Bu bölüm birkaç açık benchmark'ın tasarım pratiğinden yola çıkar ve daha pratik bir soruyla biter: kendi kurduğunuz değerlendirme kümesinin görevleri nereden gelmelidir? -> **Kullanıcı**: "Uçuşumla ilgili bir sorun var." -> **Agent**: "Hangi uçuş olduğunu söyleyebilir misiniz?" -> **Kullanıcı** (senaryoya göre açıklar): "Delta 123, yarın sabah San Francisco'dan New York'a." -> **Agent**: "Sorun tam olarak nedir?" -> **Kullanıcı** (senaryoya göre açıklar): "Uçuş süresi çok uzun, değişiklik yaptırmak istiyorum." -> **Agent**: "Yeni uçuş için bir tercihiniz var mı?" -> **Kullanıcı** (senaryoya göre açıklar): "Öğleden sonraki uçuşların hepsi olur." +### Benchmark tasarım tercihlerinin yatay karşılaştırması -Kullanıcı simülatörü sabit bir senaryoyu (bilinen bilgi + açıklama kuralları) izler; böylece değerlendirmenin tekrarlanabilirliğini güvenceye alırken gerçek bir kullanıcının kademeli anlatım biçimini de taklit eder. Benzetilmiş kullanıcıya çoğu zaman **sınırlı bir sabır** da tanımlanır: Agent verimsiz iletişim kurarsa benzetilmiş kullanıcı konuşmayı sonlandırabilir ve görev başarısız olur. - -τ-bench, Agent'ın yapılandırılmış iş süreçlerindeki (havayolu müşteri hizmetleri, perakende müşteri hizmetleri gibi) performansını ölçen bir benchmark'tır. Denetimleri bileşen düzeyinde ve çok boyutludur: bir yandan veritabanının nihai durumunun doğru olup olmadığını kontrol eder (rezervasyon kaydının durumunun "iptal edildi"ye dönmesi gibi), diğer yandan Agent'ın diyalog sırasında gerekli kilit bilgileri verip vermediğini doğrular (iade tutarı ve hesaba geçiş süresi gibi; belirli dizeler veya kalıplar aranarak doğrulanır). Bu çifte doğrulama, işlem doğruluğunu ve iletişim etkinliğini aynı anda sınar. Ancak görev düzeyinde bu denetimler nihayetinde **sıfır ya da bir olan ikili bir ödüle** indirgenir: 1 puan almak için tüm denetimlerin geçmesi gerekir, herhangi biri geçmezse sonuç 0'dır. İkili ödül, Pass^k gibi güvenilirlik metriklerinin hesaplanmasını kolaylaştırır (bkz. ilerideki "Değerlendirme Metrikleri Sistemi" bölümü); bedeli ise "işlemi doğru yapıp kritik olmayan bir alanı atlamak" ile "tümüyle başarısız olmak"ın aynı puanı almasıdır. - -Geliştirilmiş sürüm olan **τ²-bench**'in temel katkısı puanlama inceliğinde değil, iki noktadadır: birincisi **çift kontrollü ortam (Dual-Control)** — artık yalnızca Agent araç çağıramaz, kullanıcı simülatörü de aynı paylaşılan ortam üzerinde işlem yapabilir (Agent kullanıcıya uçak modunu açmasını söyler ve kullanıcının işlemi ortam durumunu gerçekten değiştirir); bu, kullanıcının elini taşın altına koyması gereken teknik destek gibi gerçek senaryolara daha yakındır. İkincisi **daha kesin görev şartnameleri ve bileşimsel görev üretimi** — başarı koşullarındaki belirsizlik azalır ve somut görev örnekleri parametrelendirilip toplu olarak üretilebilir (ayrıntılı doğrulama boyutları için ilerideki "Doğrulanabilirlik ve Nesnellik Güvencesi" bölümüne bakın). - -> **Deney 7-1 ★: τ²-bench'i Çalıştırmak ve τ-bench'ten Evrimini Karşılaştırmak** -> -> Bu deney, τ²-bench değerlendirme çerçevesini çalıştırarak insan-makine etkileşimi tipi değerlendirme ortamlarının tasarım noktalarını anlamayı ve τ-bench ile τ²-bench arasındaki farkları karşılaştırarak değerlendirme veri kümelerinin nasıl yinelemeyle iyileştirildiğini kavramayı amaçlar. -> -> Görev tanım dosyalarını derinlemesine okuyun: her görev bilinen bilgiyi (kullanıcının arka plan bilgisi), görev talimatlarını (bilginin nasıl kademeli açıklanacağını ve yanıt stratejisini yönlendirir) ve başarı koşullarını (veritabanının hedef durumu ve diyalogda mutlaka geçmesi gereken doğrulama bilgileri) içerir. Eksiksiz değerlendirme akışını çalıştırın, kullanıcı simülatörü ile Agent arasındaki çok turlu diyaloğu gözlemleyin ve tipik başarısızlık kalıplarını (politika ihlali, bilgi atlama, aşırı sıklıkta insan temsilciye aktarma vb.) analiz edin. -> -> -> ![Şekil 7-3: τ²-bench Değerlendirme Mimarisi](images/fig7-3.svg) -> -> -> τ-bench ile τ²-bench'in tasarım farklarını karşılaştırın: τ-bench'in ilk sürümünde kullanıcı talimatları fazla basitti (Agent yanıtı tahmin edebiliyordu), başarı koşulları yeterince kesin değildi (yanlış değerlendirmelere yol açıyordu) ve kullanıcı simülatörü fazla mekanikti. τ²-bench bu sorunlara karşı sistematik iyileştirmeler yaptı: -> -> - **Daha ayrıntılı görev talimatları getirmek**: "olgusal dayanak gereksinimi" (Grounding) dahil, yani yanıtların ortamın gerçek durumuna dayanması zorunluluğu -> - **Daha kesin değerlendirme ölçütleri**: örneğin "hız testi excellent döndürmedikçe sorun çözülmüş sayılmaz" -> - **Daha gerçekçi kullanıcı simülatörü davranış kuralları**: kademeli bilgi açıklama, doğal duygusal dalgalanmalar -> -> τ²-bench'e yeni eklenen telecom alanı görevlerine özellikle dikkat edin ve çift kontrollü ortam tasarımını kavrayın (yukarıda anlatıldığı gibi, kullanıcı ve Agent aynı paylaşılan ortamı birlikte kullanır). -> +Önceki bölümde ayırt edilen muhatabın varlığı ya da yokluğu, yalnızca ortam düzeyindeki ilk katman farktır; veri kümesi düzeyindeki ayrışmalar tasarım ödünleşimlerini daha iyi gösterir. Tablo 7-2 sık anılan birkaç benchmark'ı yan yana koyar. -Araç çağırma tipi değerlendirme "gözlemlenebilir bir durum değişikliği tamamlandı mı" sorusuna odaklanırken, insan-makine etkileşimi tipi değerlendirme "kullanıcının kavrayışında veya kararında bir değişim sağlandı mı" sorusuna bakar — ilki Agent'ın eylem doğruluğunu, ikincisi iletişim stratejisinin isabetliliğini sınar. +Tablo 7-2 Birkaç Agent benchmark'ının temel tasarım tercihleri -Değerlendirme ortamlarının kurulması simülasyon ortamı tasarımına da temas eder — bir değerlendirme ortamının büyük ölçekli, tekrarlanan etkileşimleri desteklemesi gerektiğinde simülasyon ortamına dönüşür; bu bölümün sonunda kısaca ele alınacaktır. +| Benchmark | Sınanan yetenek | Görev kaynağı | Ortamı canlandıran | Doğrulayıcı | +|---|---|---|---|---| +| τ²-bench | Müşteri hizmetlerinde insan-bilgisayar etkileşimi ve araç çağrısı | Elle yazım + birleşimsel üretim | Kullanıcı simülatörü + iş veritabanı | Dört katman denetim `reward_basis` ile ikiliye toplanır | +| SWE-bench Verified | Yazılım geliştirme, coding | Gerçek GitHub issue'ları, elle elenmiş | Kod deposu + test paketi | FAIL\_TO\_PASS / PASS\_TO\_PASS çift doğrulama | +| AndroidWorld | Android telefon GUI'sini kullanma | Parametreli şablonların örneklenmesi | Gerçek Android öykünücüsü | Nihai UI durumu savları | +| OSWorld | Linux masaüstü GUI'sini kullanma | Önceden ayarlanmış ara durumdan başlar | Gerçek sanal makine | 134 bağımsız değerlendirme işlevi | +| Terminal-Bench | Linux terminalini kullanma, coding | Elle yazım | Docker kapsayıcısı | Dosya sistemi denetimi + gerçek yürütme | +| GAIA | Bilgi toplayan genel amaçlı AI asistanı | Elle yazım + özel ekler | Açık internet | Tam dizgi eşleşmesi | -## Değerlendirme Görev Veri Kümelerinin Tasarımı +### Doğrulayıcılar -Değerlendirme ortamı "sahne", veri kümesi ise "senaryodur" — senaryonun ne kadar iyi yazıldığı, değerlendirmenin değerini çoğu zaman sahnenin kendisinden daha fazla belirler. Kötü tasarlanmış bir veri kümesi kusursuz bir ortamda çalıştırılsa bile yalnızca gürültü üretir. Bu bölüm; GAIA, AndroidWorld, SWE-Bench Verified (Software Engineering Benchmark, yazılım mühendisliği benchmark'ı), τ-bench ve τ²-bench, Terminal-Bench, OSWorld ve OSWorld-Verified gibi benchmark'ların tasarım pratiğinden defalarca doğrulanmış birkaç ilke damıtıyor. +Bir Agent, görevi tamamen bitirdiğini söyleyen uzun bir rapor yazmakta hiç zorlanmaz; oysa gerçekte hiçbir şey bitmemiş olabilir. Değerlendirme çerçevesi, Agent'ın kendi beyanını değil, makinenin bağımsız olarak doğrulayabileceği olguları denetlemelidir. -> **Deney 7-2 ★: Benchmark Görevlerini Elle Yapmak** -> -> GAIA, AndroidWorld, SWE-Bench Verified, τ²-bench, Terminal-Bench ve OSWorld-Verified'dan birer görev seçip kendi elinizle tamamlayın. Her veri kümesinden kolay, orta ve zor birer görev yapmanız önerilir — "zor" seviye insanlar için de zorlayıcıdır. Kendi sonuçlarınızı standart yanıtlarla karşılaştırın ve farkların kaynağını analiz edin. Bu birinci elden deneyimle şunları kavrayın: görev açıklamaları netlikle açıklık arasında denge kurmalıdır, doğrulama ölçütleri nesnel ve çalıştırılabilir olmalıdır, görev zorluğunun katmanlandırılması farklı yetenek düzeylerini ayırt edebilmelidir. -> +**SWE-bench Verified "düzeltme tamam"ı iki bağımsız önermeye ayırır.** Biri FAIL\_TO\_PASS'tır: düzeltmeden önce başarısız, sonra başarılı; bu, sorunun gerçekten çözüldüğünü kanıtlar. Diğeri PASS\_TO\_PASS'tır: düzeltmeden önce de sonra da başarılı; bu, yeni bir kusur sokulmadığını kanıtlar. Yalnızca ilkini denetlerseniz Agent, yolunu kesen savları silip değiştirerek sıyrılabilir; yalnızca ikincisini denetlerseniz hiç denetlememişsiniz demektir. Ancak ikisini birden denetlemek "düzeltildi" ile "hiçbir şey bozulmadı"yı ayrı ayrı kanıtlanabilir iki sonuca dönüştürür. Ayrıca testlerin kendi kararlılığını da doğrular ve kimi zaman geçip kimi zaman kalan kararsız testleri (flaky test) eler. -### Görev Veri Kümesi Tasarımının Temel Zorlukları +**OSWorld'ün doğrulayıcısı, dışarıdan tamamlanmış görünen ama özünde yanlış olan durumları yakalayabilir.** 134 bağımsız değerlendirme işlevi ve işletim sistemine tam erişimle donatılmıştır; dosya sistemi yapısını, süreç durumlarını, ağ bağlantılarını ve uygulamaların iç durumunu denetleyebilir. Veritabanı görevlerinde değerlendirme betiği yalnızca rapor dosyasının varlığını doğrulamakla kalmaz, veritabanına bağlanıp SQL'in gerçekten çalışıp çalışmadığını da denetler; tarayıcı görevlerinde DOM ağacını çözümler, cookie ile localStorage'ı inceler ve formun gerçekten işleyip işlemediğini doğrulamak için arka uca istek gönderir. -**Zorluk bir: netlikle açıklık arasındaki gerilim.** Görev açıklaması, değerlendirmenin tekrarlanabilirliğini güvenceye alacak kadar net olmalı, ama Agent'ın yaratıcılığını kısıtlayacak kadar da katı olmamalıdır. GAIA buna bir örnek sunar: görevler "kavramsal olarak basit", ama uygulama yolları açıktır — örneğin NASA'nın Günün Astronomi Fotoğrafı'ndaki astronotun bilgilerini bulmak istenir; hedef nettir (belirli bir astronotu ve uzayda geçirdiği süreyi bulmak), ama nasıl arama yapılacağı, nasıl eleneceği ve nasıl doğrulanacağı tamamen Agent'ın kendi kararına bırakılmıştır. +**Terminal-Bench'in `build-linux-kernel-qemu` görevi**, Linux 6.9 çekirdeğinin kaynaktan derlenmesini, `start_kernel` içine özel bir printk eklenmesini, bir initramfs üretilmesini ve bunun QEMU'da çalıştırılmasını ister; başarı ölçütü, açılış günlüğünde o özel iletinin görünmesidir. Agent çıktıyı sahteleyemez; bütün süreci gerçekten tamamlamaktan başka yolu yoktur. -**Zorluk iki: gerçekçilikle denetlenebilirlik dengesi.** Gerçek görevler belirsizlik ve gürültü içerir; bu, sağlamlığın görünür olmasını sağlar ama tekrarlanabilirliği de tehdit eder. SWE-Bench'in ilk sürümü doğrudan GitHub'daki gerçek issue'ları aldı; bu, gerçekçiliği güvenceye aldı ama görev açıklamalarının belirsiz, test durumlarının eksik ve değerlendirme ölçütlerinin öznel olmasına da yol açtı. SWE-Bench Verified, insan uzmanlarla sistematik bir doğrulama süreci getirdi ve bunlar arasından sorunu açık, testleri yeterli, çözümü belirgin 500 yüksek kaliteli görev seçti; böylece gerçekçiliği korurken denetlenebilirliği belirgin biçimde artırdı. +### Görevlerin zorluk düzeylerine ayrılması -**Zorluk üç: çeşitlilikle sistematikliğin uyumu.** Etkili bir veri kümesinin tipik durumları, sınır koşullarını ve hata tuzaklarını kapsaması, aynı zamanda sistematik bir organizasyonu olması gerekir; ancak böylece değerlendirme sonuçları belirli yetenek eksikliklerini teşhis edebilir. AndroidWorld'ün 116 görevi 20 gerçek uygulamaya yayılır ve her görev gerektirdiği temel yeteneklerle (çok adımlı planlama, görsel anlama, zamansal akıl yürütme) etiketlenmiştir; böylece değerlendirme sonuçları yalnızca genel bir başarı oranı vermez, belirli yetenek boyutlarındaki güçlü ve zayıf yanları da ortaya çıkarır. Daha da önemlisi, parametrelendirme mekanizmasıyla neredeyse sınırsız sayıda görev varyantı üretilebilir. +Bir değerlendirme görev kümesi farklı zorluktaki görevleri içermelidir. Böylece model yetenekleri arttığında küme çabucak eskimez. -**Zorluk dört: değerlendirme maliyetine karşı kapsam.** Karmaşık Agent görevleri tamamlanması dakikalar hatta saatler süren ve büyük miktarda token tüketen işlerdir. Veri kümesinin büyüklüğü, kapsayıcılıkla ekonomiklik arasında dengelenmelidir. GAIA, üç zorluk düzeyine ayrılmış 466 soruyu özenle seçer; hem birçok yetenek boyutunu kapsar hem de değerlendirmenin makul bir maliyetle tamamlanmasına izin verir. SWE-Bench Verified ise 2.294 sorudan 500 soruya indi (maliyet yaklaşık beşte dört azaldı; daha katı kalite ölçütleriyle sinyal-gürültü oranı yükseldi). +GAIA'nın 466 sorusu üç zorluk düzeyine ayrılmıştır: Level 1 bir iki araçla halledilir (insanlar %93,9, GPT-4 %30,3), Level 2 çok adımlı düşünmeyi gerektirir (%91,8'e %9,7) ve Level 3 karmaşık birleşimleri gerektirir (%87,3'e %0). Bu katmanlama yalnızca zorluk etiketlemez, tanısal değeri de vardır: Level 1'deki başarısızlık temel araç kullanımına, Level 2 çok adımlı planlama ve bilgi bütünleştirmeye, Level 3 ise uzun diziler boyunca düşünme ve karmaşıklık yönetimine işaret eder; üçü farklı iyileştirme yönlerine karşılık gelir. -**Zorluk beş: veri sızıntısını (Data Contamination) önlemek.** Büyük dil modelleri çağında veri sızıntısı, değerlendirmenin karşılaştığı ciddi bir zorluktur: değerlendirme verisi eğitim verisine karıştığında, değerlendirme genelleme yeteneğini değil ezberi ölçmeye başlar; tıpkı sınavdan önce yanıtları ezberlemek gibi — alınan not ne kadar yüksek olursa olsun gerçek düzeyi göstermez. Her benchmark farklı bir önleme stratejisi benimsedi: GAIA yanıtların benzersizliğine dayanır; sorular ancak birden fazla bilgi kaynağı birleştirilerek yanıtlanabilir ve bazı görevlerde özel olarak üretilmiş ek dosyalar (internette bulunmayan PDF/ses/görsel) bulunur, dolayısıyla tek bir web sayfası yanıtı doğrudan veremez. SWE-Bench Verified'ın kendisi, OpenAI'nin özgün SWE-Bench üzerinde elle kalite elemesi yaparak elde ettiği 500 soruluk bir alt kümedir ve zaman boyutlu bir sızıntı önleme tasarımı içermez; sızıntıyı gerçekten zamansal tazelikle önleyenler SWE-bench-Live gibi sonraki çalışmalardır — bunlar modelin eğitim kesim tarihinden sonra açılan issue'ları sürekli toplayarak değerlendirmeyi modelin eğitim külliyatının hep önünde tutar. τ²-bench önlemeyi dinamik parametre üretimiyle yapar; somut görev örnekleri (kullanıcı adı, sipariş numarası, tarih vb.) her seferinde rastgele üretilir. AndroidWorld'ün parametrelendirilmiş görev üretimi doğası gereği sızıntıya dirençlidir, çünkü doğrulama işlem dizisine değil nihai UI durumuna dayanır. Terminal-Bench ise kanarya tanımlayıcıları (canary GUID, yani küresel benzersiz tanımlayıcı — benzersiz bir izleme işareti) gömerek sızıntıyı saptanabilir kılar: model bu GUID'i içeren bir içerik üretebiliyorsa, benchmark verisi eğitim kümesine sızmış demektir. +Terminal-Bench basit bir mlflow model kaydından orta zorlukta 7z parola kırmaya, zor bir git sunucusu ile web sunucusunun çok bileşenli tümleştirilmesine ve en ağır olan FEAL diferansiyel kriptanalizine kadar uzanır. -### Görev Açıklamalarının Kesinlik Tasarımı +τ²-bench ayrıca özel olarak **tuzak görevler** tasarlar: kullanıcı "müşteri hizmetleri iptali zaten onayladı" der ama bu aslında politikaya uygun değildir; böylece Agent'ın baskı ve yanıltma altında doğru yargısını koruyup koruyamadığı sınanır. -GAIA, yanıtın tekliğini net bilgi kaynağı kısıtları, zaman aralıkları, konu ve sorgu hedefi üzerinden güvenceye alır. Örneğin bir Level 3 görevi, belirli bir tarihteki NASA görselinden yola çıkıp görsel anlamayla astronotu tanımayı, astronotun bağlı olduğu grubu sorgulamayı, uzayda kaldığı süreyi hesaplamayı ve çıktıyı tam olarak biçimlendirmeyi ister ("soyadı, noktalı virgülle ayrılmış, binlik ayırıcılı"); her ayrıntı otomatik doğrulamaya hizmet eder — yalnızca biçim ve içerik birebir eşleşirse geçmiş sayılır. +### Veri sızıntısının önlenmesi -τ²-bench bağlamsallaştırılmış bir tasarım getirir; her görev birden çok katman bilgi içerir: yüzeydeki sorun ("mobil veri çalışmıyor"), performans beklentisi ("kesinlikle mükemmel bir hız istiyorum"), kısıt ("başka bir hızı kabul etmem") ve örtük duygu durumu. Kilit iyileştirme, "bilinen bilgi" ile "görev talimatlarını" birbirinden ayırmaktır: bilinen bilgi kullanıcının o an elinde tuttuğu olgulardır; görev talimatları ise simülatöre bilgiyi nasıl kademeli açacağını gösterir ve içinde "olgusal dayanak gereksinimi" (Grounding Requirement, yani yanıtların tool calling'in gerçekte döndürdüğü sonuçlara dayanması, uydurulmaması) bulunur. +**GAIA yanıtlarının internetten doğrudan aranmasını olanaksız kılar.** Görevleri kavramsal olarak yalın ama yolu açıktır: örneğin belirli bir tarihteki NASA Günün Astronomi Fotoğrafı'ndan yola çıkıp fotoğraftaki astronotu tanımak, mensup olduğu astronot grubunu bulmak, o grupta uzayda en kısa süre kalanı hesaplamak ve sonucu "soyadı, noktalı virgülle ayrılmış, binlik ayırıcılı" biçiminde tam olarak vermek. Yanıt son derece özgüldür ve doğruluğu tam dizgi eşleşmesiyle belirlenir. Sızıntı önleme iki şeye dayanır: birincisi, soruya ancak birkaç bilgi kaynağı birleştirilerek yanıt verilebilir ve tek bir web sayfası yanıtı doğrudan vermez; ikincisi, bazı görevlere özel olarak üretilmiş ekler iliştirilmiştir (internette bulunmayan PDF, ses ve görseller). -SWE-Bench Verified; sorun açıklaması, yeniden üretme adımları, beklenen/gerçekleşen davranış gibi yapılandırılmış alanlar içerir ve etiketleyiciler açıklamayla test durumlarının uyuştuğunu doğrular. Terminal-Bench'in görev açıklamalarındaki her öğe mekanik olarak doğrulanabilir: dosya yolu var mı, izin değerleri doğru mu, sertifika parametreleri, tarih biçimi vb. Örneğin "build-linux-kernel-qemu" görevi Linux çekirdeği 6.9'un kaynaktan derlenmesini, `start_kernel` içine özel bir printk eklenmesini, bir initramfs üretilmesini ve bunun QEMU'da çalıştırılmasını ister; başarı ölçütü, açılış günlüğünde özel mesajın görünmesidir — Agent çıktıyı taklit ederek işin içinden sıyrılamaz, tüm süreci gerçekten tamamlamak zorundadır. +**AndroidWorld tek bir şablondan çok sayıda örnek türetir.** Görevleri durağan metin değil, dinamik olarak örneklenebilen şablonlardır; örneğin "`[CONTACT_NAME]` kişisinin telefonunu `[NEW_PHONE]` yap" gibi, parametre değerleri her değerlendirmede rastgele üretilir. Bunun üç yararı vardır: parametreler her seferinde farklı olduğundan sabit bir işlem dizisini yeniden oynatmak işe yaramaz; tek bir şablon neredeyse sınırsız örnek üretebilir; bazı parametreler sabitlenip geri kalanlar değiştirilerek belirli bir etkenin etkisi kesin biçimde ölçülebilir. -AndroidWorld **parametrelendirilmiş şablon** tasarımını benimser. Bir görev statik metin değil, dinamik olarak örneklenebilen bir şablondur ("`[CONTACT_NAME]` kişisinin telefon numarasını `[NEW_PHONE]` olarak değiştir" gibi) ve her değerlendirmede farklı parametre değerleri rastgele üretilir. Bunun üç yararı var: +**Terminal-Bench soru metnine kanarya tanımlayıcısı gömer.** Her soru bir canary GUID taşır; bir model o GUID'i içeren içerik üretebiliyorsa benchmark verisi eğitim kümesine girmiş demektir. Sızıntıyı engellemez ama saptanabilir kılar. -- **Ezberi engeller**: parametre değerleri her seferinde farklıdır, sabit bir işlem dizisi yeniden oynatılamaz -- **Veri çeşitliliğini artırır**: tek bir şablon neredeyse sınırsız sayıda örnek üretebilir -- **Karşılaştırmalı deneyleri destekler**: bazı parametreler sabit tutulup yalnızca diğerleri değiştirilerek belirli bir etkenin etkisi hassas biçimde ölçülebilir +### Kalite denetimi ve uzun vadeli bakım -Doğrulama, işlem dizisine değil nihai UI durumuna dayanır (telefon numarası alanının beklenen değeri içerip içermediği gibi). +Yüksek kaliteli bir değerlendirme kümesi hazırlamak çok zordur. Yukarıdaki benchmark'ların çoğunun bugünkü hali, ilk sürümleri kullanıma girip sorunları açığa çıktıktan sonra tur tur onarılmasının ürünüdür. Örneğin τ-bench'ten τ²-bench'e beş yer yeniden tasarlanmıştır. -OSWorld'ün görevleri çoğunlukla "temiz" bir başlangıç durumundan değil, özenle yapılandırılmış ara durumlardan başlar; bu da gerçek kullanım senaryolarına daha yakındır. Görev açıklamalarının çok çözümlülüğü ("arka planı mora ayarla" isteğinde belirsizliği gidermek için somut bir renk kodu verilmelidir; "iki CSV'yi birleştir" isteğinde tek başlık/çift başlık gibi bütün makul yollar kabul edilmelidir) ve ortam belirsizliğini (sitelerin tarama engelleri, uygulama arayüzlerinin evrilmesi, zamanlama yarışları — OSWorld-Verified bunları çevrimdışı sayfa anlık görüntüleri, bağımlılık sürümlerini sabitleme ve açık bekleme koşulları gibi mekanizmalarla hafifletir) ele alması gerekir. +Birincisi, **görev yönergeleri fazla genel olduğundan yanıt tahmin edilebiliyordu**. İlk sürümün yönergeleri geniş yazılmıştı, bu yüzden modelin talebi gerçekten netleştirmesine gerek kalmıyor, sağduyuyla bir prosedür tahmin etmek geçmeye yetiyordu. τ²-bench senaryoyu `known_info` ve `task_instructions` diye iki alana böldü: ilki kullanıcının bildiklerinin sınırını çizer, ikincisi açığa çıkarma biçimini belirler. Kullanıcının bilmediğini Agent tahmin edemez, ancak sorgulayarak öğrenebilir. -Bu liste, Agent değerlendirmesinin haritasını tüketmiyor. Yalnızca Web/GUI kategorisinde bile farklı yönlere ağırlık veren birçok benchmark var: WebArena tümüyle yeniden üretilebilir bir web sitesi kümesi (e-ticaret, forum, kod barındırma vb.) kurarak "gerçek web sayfalarının" denetlenemezliğini bir sandbox'a kapatır; Mind2Web tam tersini yapar ve genelleme yeteneğini doğrudan yüzlerce gerçek web sitesi üzerinde ölçer; [ClawBench](https://claw-bench.com/) ([makale](https://arxiv.org/abs/2604.08523), [kod](https://github.com/TIGER-AI-Lab/ClawBench)) ise yalıtılmış bir container içinde çalışan Agent'ın canlı web sitelerinde uçtan uca gündelik görevleri yerine getirmesini sağlar. V1, 144 web sitesinde 153 görevi kapsar; V2 buna 130 görev daha ekler ve beş kanıt katmanını paralel olarak kaydeder: oturum tekrarları, eylem ekran görüntüleri, HTTP trafiği, tarayıcı eylemleri ve Agent mesajları. Canlı sitelerdeki değişimi ve uzun kuyruklu başarısızlıkları analiz etmeyi kolaylaştırarak sandbox benchmark'larını tamamlar; bunun karşılığında yeniden üretilebilirlik üçüncü taraf web sitelerindeki değişikliklere bağlıdır. BrowseComp ise derin retrieval'a odaklanır — yanıtlar çok derine gizlenmiştir, bulmak için çok sıçramalı gezinme ve çapraz doğrulama gerekir. Tool calling boyutunda ise BFCL (Berkeley Function-Calling Leaderboard) gibi özel fonksiyon çağırma sıralamaları var. Bu bölümün amacı bütün benchmark'ları sıralamak değil; iki temel ortam paradigmasını (araç çağırma tipi ve insan-makine etkileşimi tipi) ve veri kümesi örneklerinin içinden geçen GUI işlem senaryolarını alıp tasarım ödünleşimlerini derinlemesine kazmak — paradigmaları kavradıktan sonra, herhangi bir yeni benchmark karşısında neyi ölçtüğünü, sızıntıya karşı ne kadar korunduğunu ve sonuçlarının nereye kadar genellenebileceğini hızla değerlendirebilirsiniz. +İkincisi, **başarı koşulları yeterince kesin olmadığından doğrulama yanlış hüküm veriyordu**. "Ağ düzeldi" gibi bir koşulun denetlenebilir bir sınırı yoktur. τ²-bench bunu "yalnızca hız testi excellent verirse çözülmüş sayılır; poor, fair ve good kabul edilmez" olarak değiştirdi. Bu değişiklik, belirtiyi bastırıp kök nedeni gidermeyen **göstermelik onarımları** hedefler. -### Görev Karmaşıklığının Katmanlı Tasarımı +Üçüncüsü, **kullanıcı simülatörünün davranışı fazla mekanikti**. İlk sürümün simüle kullanıcısı yalnızca edilgen yanıt veriyordu. τ²-bench ona duygu (ilk onarım başarısız olunca hoşnutsuzluk göstermek), sabır sınırı (iletişim çok verimsizse konuşmayı kesmek) ve olguya dayandırma koşulunu ekledi. Üçü birlikte, simülatörü gerçek kullanıcıya yaklaştırırken yinelenebilirliği de korur. -GAIA üç zorluk düzeyi tasarladı: Level 1 yalnızca 1-2 araç gerektirir (insanlar %93,9, GPT-4 %30,3), Level 2 çok adımlı düşünme gerektirir (%91,8 ve %9,7), Level 3 karmaşık bileşimler gerektirir (%87,3 ve %0). Katmanlı tasarımın teşhis değeri şuradadır: Level 1'deki başarısızlık temel araç kullanımı sorununa, Level 2 çok adımlı planlama ve bilgi bütünleştirme sorununa, Level 3 ise uzun dizili düşünme ve karmaşıklık yönetimi sorununa işaret eder — her katman farklı bir iyileştirme yönüne karşılık gelir (prompt engineering, planlama mekanizması, katmanlı mimari/post-training). +Dördüncüsü, **kullanıcı yalnızca konuşmaya değil, işleme de katılır**. Telecom alanı çift denetimli ortamı getirdi. Daha önceki değerlendirmelerde ortamı yalnızca Agent değiştirebiliyordu; oysa teknik destek gibi senaryolarda eylemlerin epeyce bir bölümünü aslında kullanıcının kendi cihazında yapması gerekir. Çift denetim, doğrulamaya bir boyut daha katar: kullanıcı durumu değiştirdikten sonra Agent sonucu ancak aracı yeniden çağırarak öğrenebilir, dolayısıyla doğrulama artık "Agent kullanıcı tarafındaki işlemin sonucunu gerçekten okudu mu" sorusunu da kapsar. -τ²-bench katmanlandırmayı iş karmaşıklığı üzerinden yapar: basit bilgi sorgularından çok adımlı süreçlere (uçuş değiştirmek için sorgulama, alternatifleri gösterme, onay alma, fiyat farkını hesaplama ve ödeme gerekir), oradan arıza teşhisine (birden fazla olası nedeni sistematik biçimde kontrol edip düzeltmeyi doğrulama) ve son olarak politika muhakemesine (politikaya uymayan talepleri ele alma) uzanır. +Beşincisi, **görev örnekleri dinamik olarak üretilir**. τ²-bench'in somut örnekleri (kullanıcı adları, numaralar, arıza birleşimleri) parametreleştirilip toplu üretilebilir; bu hem kapsamı hem de sızıntıya direnci iyileştirir. -Terminal-Bench katmanlandırmayı teknik alan × işlem karmaşıklığı olmak üzere iki boyutta yapar; görev kaydında 200'den fazla görev toplanmıştır (çekirdek değerlendirme kümesinin büyüklüğü sürümden sürüme değişir; örneğin 2.0 sürümü topluluk katkıları arasından 89 yüksek kaliteli görev seçmiştir). Görevler basit mlflow model kaydından orta düzeydeki 7z parola kırmaya, oradan zor olan git sunucusu + webserver çok bileşenli entegrasyonuna ve en zor olan FEAL diferansiyel kriptanalizine (kriptografi bilgisi ve 30 saniyelik zaman kısıtını karşılayacak algoritma optimizasyonu gerektirir) kadar uzanır. +**SWE-bench Verified: yayımlanmadan önce özgün görevlerin %71'i elendi.** OpenAI, özgün 2.294 görevten 1.699'unu rastgele seçip insan değerlendirmesine soktu ve Python'a hâkim 93 geliştirici toplayarak her birini tek tek denetletti: sorun açıklaması net mi, test durumları sınır koşullarını kapsıyor mu, testler kararlı mı, referans patch yeni hata sokuyor mu, zorluk makul mü. Sonunda yalnızca 500'ü geçti. Yüksek eleme oranı daha iyi bir sinyal-gürültü oranı getirir ve değerlendirme maliyeti de yaklaşık %80 düşer. Karmaşık Agent görevleri sıklıkla dakikalardan saatlere sürer ve öncü bir modelle bir değerlendirme veri kümesini baştan sona koşturmak çoğu zaman binlerce dolarlık token maliyeti getirir; bu yüzden değerlendirme maliyetini düşürmek son derece önemlidir. -### Doğrulanabilirlik ve Nesnellik Güvencesi +**OSWorld: yayımlandıktan sonraki 15 ayda 300'den fazla sorun açığa çıktı.** Nisan 2024'te yayımlandıktan kısa süre sonra çok kipli Agent değerlendirmesinin önemli bir benchmark'ı oldu; ancak sonraki yaygın kullanım dört tür sorunu ortaya çıkardı: ortam sorunları (sitelerin kazıma karşıtı önlemleri, CAPTCHA, dinamik içerik değişimi), görev açıklaması sorunları (belirsiz ifadeler), doğrulama mantığı sorunları (fazla katı ya da fazla gevşek) ve başlangıç durumu sorunları (eksik yapılandırma). Hong Kong Üniversitesi'nden yaklaşık 10 kişilik bir ekip iki ay boyunca MoonShot AI, OpenAI, ByteDance Seed TARS, Anthropic, Simular ve diğerleriyle yakın çalışarak sistematik bir onarım yürüttü: ortam sorunları sürüm sabitleme ve çevrimdışı yedeklerle, açıklama sorunları belirsiz ifadelerin yeniden yazılmasıyla, doğrulama sorunları elle doğru bir taban çizgisi kurulup koşulların ayarlanmasıyla, başlangıç durumu sorunları ise bütünlük denetimleri eklenerek hafifletildi. -GAIA'nın yanıtları kısa ve nettir; katı biçim kuralları doğrulamanın tam dize eşleşmesiyle yapılmasını sağlar ve ikili sonuç (eşleşti ya da eşleşmedi) nesnel tekrarlanabilirliği güvenceye alır. Yanıtların nadirliği aynı zamanda hile önleyici bir işlev görür — son derece somut olguların eğitim verisinde birebir aynı biçimde bulunması pek olası değildir. +> **Deney 7-2 ★: Benchmark görevlerini elle yapmak** +> +> GAIA, AndroidWorld, SWE-Bench Verified, Terminal-Bench ve OSWorld-Verified'dan görevler seçip kendi elinizle tamamlayın; her veri kümesi için bir kolay, bir orta ve bir zor görev önerilir. "Zor" düzey insanlar için de meydan okuyucudur. +> +> Bitirdikten sonra iki soruyu yanıtlayın. Görev açıklaması birden çok makul yorum barındırıyor mu; barındırıyorsa doğrulayıcı hangisini kabul ediyor? İşi yapmadan sıyrılmaya kalksanız en ucuz yol ne olurdu ve doğrulayıcı bunu engelleyebilir mi? -SWE-Bench Verified doğrulamayı kodun çalıştırılabilirliği üzerinden yapar ve FAIL_TO_PASS (düzeltmeden önce başarısız, düzeltmeden sonra başarılı; sorunun çözüldüğünü kanıtlar) ile PASS_TO_PASS (düzeltmeden önce de sonra da başarılı; yeni bir bug eklenmediğini kanıtlar) arasında ayrım yaparak çifte doğrulama sağlar. Verified sürümü ayrıca testlerin kendi kalitesinin güvenilir olmasını, bazen geçip bazen kalan kararsız testlerin (flaky tests) bulunmamasını da güvenceye alır. +### Değerlendirme kümesinin üç kaynağı -τ²-bench'in doğrulama sistemi çok katmanlı denetimler içerir (katmanların sonuçları görev düzeyinde yine ikili bir ödüle indirgenir; başarı için hepsinin geçmesi gerekir): +Yaygın bir görüş, açık benchmark'ların model sıralaması için olduğunu ve gerçek işle pek ilgisi bulunmadığını söyler. Açık benchmark puanlarının ürün kararlarını doğrudan yönlendirmesinin güç olduğu doğrudur, ama tasarım teknikleri fazlasıyla aktarılabilir. Yukarıda tartışılan doğrulama derinliği, parametreli üretim, sızıntı önleme ve kalite bakımı, kendi kurduğunuz değerlendirme kümesinde en kolay atlanan noktalardır. -- **Veritabanı durumu denetimi**: rezervasyon kaydının durumu, iade kaydının oluşturulup oluşturulmadığı -- **Diyalog içeriğinde anahtar kelime araması**: iade tutarının ve hesaba geçiş süresinin kullanıcıya doğrulatılıp doğrulatılmadığı -- **Süreç uygunluğu**: tool calling dizisinin analizi; örneğin sipariş değiştirilmeden önce kullanıcının açık onayının alınıp alınmadığı +Üretim ortamındaki bir değerlendirme kümesinin genellikle üç kaynağı vardır. -τ²-bench'in çift kontrollü ortamı (bkz. yukarıdaki "İnsan-Makine Etkileşimi Tipi Değerlendirme Ortamı" bölümü) doğrulamaya bir boyut daha ekler: kullanıcı simülatörü ortam durumunu gerçekten değiştirdikten sonra Agent bu değişikliği tool calling ile gözlemleyip incelemesini buna göre sürdürmek zorundadır; böylece doğrulama, "Agent kullanıcı tarafındaki işlemin sonucunu gerçekten okudu mu" sorusunu da kapsar. +**Açık benchmark'lar** modelleri kabaca elemek ve tasarım tekniklerini ödünç almak için kullanılır, genelde ürün kararları için değil. Görev dağılımları gerçek işin görev dağılımıyla örtüşmez; GAIA'da iki puan yükselmenin iade başarı oranıyla zorunlu bir ilişkisi yoktur. -OSWorld, tam işletim sistemi erişimine sahip 134 bağımsız değerlendirme fonksiyonuyla donatılmıştır; dosya sistemi yapısını, süreç durumlarını, ağ bağlantılarını ve uygulamaların iç durumunu derinlemesine denetleyebilir. Örneğin bir veritabanı işlemi görevinde değerlendirme betiği yalnızca rapor dosyasının var olup olmadığını doğrulamaz, doğrudan veritabanına bağlanıp SQL'in doğru çalıştırılıp çalıştırılmadığını da denetler; tarayıcı görevlerinde DOM ağacını analiz eder, cookie/localStorage'ı kontrol eder ve formun gerçekten geçerli olup olmadığını doğrulamak için arka uca doğrulama istekleri gönderir. Bu derin denetim, "yüzeyde tamamlanmış ama özünde hatalı" durumları yakalayabilir — örneğin Agent gönder düğmesine basmıştır, ama alanlar yanlış doldurulduğu için istek sunucu tarafından reddedilmiştir. +**Kendi kurduğunuz iş kümesi** gerçek görev dağılımını kapsar ve model seçimi ile Harness tasarım kararlarına dayanak olabilir. Örneğin τ²-bench, simüle kullanıcı gerektiren herhangi bir değerlendirme sisteminin iskeleti olarak doğrudan kullanılabilir; yalnızca alan verilerini ve araç kümesini değiştirmek yeterlidir. -Terminal-Bench, Docker konteynerlerine dayalı standartlaştırılmış bir ortam üzerine kuruludur; dosya sistemi durumu denetimlerini (yol var mı, izin değerleri, içerik biçimi) program yürütme işlevselliğinin doğrulanmasıyla (build-linux-kernel-qemu görevinde QEMU'nun gerçekten başlatılıp özel printk mesajının aranması) birleştirir; canary GUID de sızıntıyı izlenebilir kılar. +**Üretim trajectory'lerinin geri akışı** sahadaki gerçek başarısızlıklardan gelir: kullanıcının açık düzeltmeleri, kullanıcının olumsuz oyları ve sonradan durum denetimi, kural tabanlı doğrulayıcı ya da LLM incelemesiyle bulunan sorun örnekleri. Başarısızlık atfından geçtikten sonra regresyon durumlarına dönüşürler. Somut yöntem ileride "Başarısızlık atfı" ile "Uçtan uca regresyon görevleri ve trajectory prefix regresyon görevleri" bölümlerinde anlatılır. Bu kaynak en pahalı olduğu kadar en isabetlisidir de, çünkü doğrudan kullanıcıların gerçekten karşılaştığı sorunlardan gelir. -### Görev Dağılımının Sistematik Tasarımı +Başlangıç aşamasında genellikle yalnızca açık benchmark'lar ve elle yazılmış küçük bir iş kümesi bulunur; sistem üretimde bir süre çalıştıktan sonra üretim trajectory'lerinden geri akan durumlar ana gövdeyi oluşturur. -Görev dağılımının yetenek boyutlarını, zorluk boyutlarını, senaryo boyutlarını ve sınır durumlarını sistematik biçimde kapsaması gerekir. GAIA genelliği hedefler — görevlerin çoğu reasoning, çok modluluk, gezinme ve araç kullanımının bileşimini gerektirir. τ²-bench özellikle "tuzak görevler" tasarlamıştır — örneğin kullanıcı "müşteri hizmetleri iptali onayladı" der ama iptal aslında politikaya uymamaktadır; böylece Agent'ın baskı ve yanıltma karşısında doğru muhakemesini koruyup koruyamadığı sınanır. OSWorld, işlem türü (dosya IO / masaüstü uygulaması / web uygulaması / uygulamalar arası akış) ile uygulama alanından oluşan iki boyutlu bir matrise dayanır ve üç işletim sistemine yayılır (araştırmalar işletim sistemleri arası yeteneklerin güçlü biçimde ilişkili olduğunu, bir sistemde öğrenilen yeteneğin diğerlerine aktarılabildiğini gösteriyor). Terminal-Bench ise sistem düşüncesini sınamak için "teknoloji yığınları arası bileşim görevleri" içerir (veri işleme + dosya işlemleri + Python mühendisliğini birleştiren yeniden parçalama görevi gibi). +## Otomatik değerlendirme yöntemleri -### Veri Kalitesi Kontrolü ve Yinelemeli İyileştirme +Önceki bölümlerde ele alınan benchmark'ların ortak bir yanı vardır: doğrulayıcıları neredeyse tümüyle belirlenimcidir. SWE-bench bir test paketi çalıştırır, AndroidWorld nihai UI durumunu savlar, GAIA tam dizgi eşleşmesi yapar ve τ²-bench'in dört katman denetimi de aynı biçimde bütünüyle kodla yürütülür. Bu seçimin sağlam gerekçeleri vardır: belirlenimci doğrulama ek model maliyeti getirmez, sonuç tümüyle yinelenebilirdir, birim testi gibi sürekli tümleştirmeye katılabilir ve modeller arası sıralamayı kolaylaştırır. -SWE-Bench Verified, kalite kontrolünün örnek vakasıdır. OpenAI, özgün 2.294 görev arasından rastgele 1.699'unu insan değerlendirmesine soktu ve Python'a hâkim 93 geliştirici görevlendirdi. Etiketleyicilerin birden çok denetimi tamamlaması gerekiyordu: sorun açıklaması açık mı (neyin çözüleceği anlaşılıyor mu), test durumları eksiksiz mi (bütün yönleri ve sınır koşullarını kapsıyor mu), testler kararlı mı (ortamdan veya rastgelelikten kaynaklanan flaky test var mı), patch doğru mu (yeni hata ekliyor mu), zorluk makul mü. Katı elemenin sonunda yalnızca 500'ü geçti (%29) — bu yüksek eleme oranı, değerlendirme kalitesine yapılan zorunlu bir yatırımdır. Ayrıca standartlaştırılmış bir etiketleme kılavuzu oluşturup her denetim için somut ölçütler ve örnekler tanımladılar; böylece farklı etiketleyiciler arasındaki tutarlılığı güvenceye aldılar. +Bedeli, yalnızca nihai sonucun doğru olup olmadığını değerlendirebilmesi, hatanın nedenini verememesidir. τ²-bench'in başarısız görevi sonuçta 0 puan almıştır ve bu 0, Agent'ın hat seçiminde mi yanıldığını yoksa veri yükleme adımını mı atladığını söylemez; bir sonraki adımda neyin değiştirileceğini hiç göstermez. Sıralama için kullanılan açık bir benchmark açısından bu bir kusur değildir; sürekli iyileştirme gerektiren bir üretim sistemi açısından ise en çok ihtiyaç duyulan bilgi tam da budur. -τ²-bench, "bilinen bilgi" ile "görev talimatları" ayrımını (simülatör davranışını daha gerçekçi kılar) ve daha katı tamamlanma koşullarını ("yalnızca excellent çözülmüş sayılır; poor/fair/good kabul edilmez" gibi) getirerek "göstermelik düzeltmelerin" önüne geçer. +Üretim ortamında bir ikinci güçlük daha vardır: birçok yargı, kodla denetlenebilen bir sava hiç dönüştürülemez. Bir şikâyet yanıtının yerinde olup olmadığı, bir araştırma raporunun kilit bir bilgiyi atlayıp atlamadığı, bir bellek erişiminin kişiler arasındaki ilişkiyi karıştırıp karıştırmadığı — bunların ne sorgulanacak tek bir nihai durumu vardır ne de anahtar sözcük eşleşmesiyle karara bağlanabilirler. -OSWorld-Verified, yinelemeli iyileştirmenin örnek vakasıdır. OSWorld, Nisan 2024'te yayımlandıktan sonra hızla çok modlu Agent değerlendirmesinin önemli bir benchmark'ı haline geldi, ama 15 aylık yaygın kullanım sırasında 300'den fazla sorun açığa çıktı. Bu sorunlar dört gruba ayrılıyor: ortam sorunları (sitelerin tarama engelleri / CAPTCHA / dinamik içerik değişimleri), görev açıklaması sorunları (belirsiz ifadeler), doğrulama mantığı sorunları (fazla katı ya da fazla gevşek) ve başlangıç durumu sorunları (eksik yapılandırma). Hong Kong Üniversitesi ekibi yaklaşık 10 kişilik bir grup kurdu ve MoonShot AI, OpenAI, ByteDance Seed TARS, Anthropic, Simular gibi kuruluşlarla iki ay boyunca yakın iş birliği yaparak sistematik bir düzeltme çalışması yürüttü. Her sorun türü için bir düzeltme stratejisi belirlendi: ortam sorunları sürümleri sabitleyerek ve çevrimdışı yedekler alarak çözüldü, görev açıklamalarındaki belirsiz ifadeler yeniden yazılarak giderildi, doğrulama mantığı elle doğru referans çizgileri kurulup koşullar ayarlanarak dengelendi, başlangıç durumları ise bütünlük denetimleri eklenerek güçlendirildi. +Bu nedenle açık benchmark'lardan üretim ortamındaki değerlendirmeye geçerken doğrulama biçiminin, yatay ekseni görevin **makineyle doğrulanabilirlik derecesi** olan bir tayf boyunca sağa kayması gerekir; Şekil 7-4'te gösterilmiştir. -## Otomatik Değerlendirme Yöntemleri +![Şekil 7-4: Doğrulama biçimlerinin tayfı — belirlenimci doğrulamadan model yargısına](images/fig7-4.svg) -Değerlendirme ortamı, veri kümesi ve net bir metrik sistemi hazır olduğuna göre sıradaki temel soru şudur: nasıl puanlanacak? Doğru yanıtı belli olan görevlerde (matematik soruları, SQL sorguları gibi) basit bir ikili karar (doğru/yanlış) yeterlidir; ama açık uçlu görevlerde (müşteri hizmetleri diyalogları, rapor yazımı gibi) daha ince değerlendirme yöntemleri gerekir. +Tayfın sağ yanındaki iki araç böylece üretim değerlendirmesinin gövdesi olur: **Rubric** bulanık "iyi mi kötü mü" sorusunu ayrı ayrı puanlanabilir birkaç boyuta ayırır, **LLM-as-a-Judge** ise belirlenimci bir ölçüt bulunmadığında puanlamayı üstlenir. Ancak ikisi birlikte, bulanık bir başarısızlık oranını üzerinde çalışılabilir somut sorunlara indirgeyebilir; bu bölümün ikinci yarısındaki **başarısızlık atfı** ile birleştiğinde üretim Agent'ı değerlendirmesinin tam kapalı çevrimi oluşur. -Kodla otomatik doğrulama yalnızca standart yanıtı olan senaryoları kapsar; bu bölümün asıl konusu açık uçlu görevlerin puanlanmasıdır. Bunlardan ödül sinyalinin yoğunluk tasarımı (ikili ödülden süreç ödülüne, oradan üretken ödüle) ve ödül modellerinin eğitim yöntemleri, Bölüm 8'nin post-training bölümünde sistematik olarak tartışılmak üzere bırakılmıştır; bu bölüm daha temel bir soruyu yanıtlar: açık uçlu görevlerin çıktı kalitesi LLM ile otomatik olarak nasıl değerlendirilir? +Şunu belirtmek gerekir: sağa kaymak sol yanı bırakmak demek değildir. Program savı olarak yazılabilen her denetim sav olarak kalmalı, LLM yargısı yalnızca gerçekten makineyle karara bağlanamayan boyutlar için kullanılmalıdır. Belirlenimci denetimler daha ucuz ve daha kararlıdır, uzun soluklu regresyon testi olarak koşturulmaya da daha uygundur. ### LLM-as-a-Judge: Otomatik Değerlendirmenin Çekirdeği -![Şekil 7-4: LLM-as-a-Judge Boru Hattı](images/fig7-4.svg) +![Şekil 7-5: LLM-as-a-Judge Boru Hattı](images/fig7-5.svg) LLM-as-a-Judge'a neden ihtiyaç var? Açık uçlu görevlerde (rapor üretme, müşteri şikâyetlerini ele alma, yaratıcı içerik gibi) otomatik karşılaştırma yapılabilecek standart bir yanıt yoktur; insan değerlendirmesi ise pahalıdır ve ölçeklenmesi zordur. LLM-as-a-Judge, dil modelinin uzmanlarca tanımlanmış puanlama ölçütlerine (Rubric) göre değerlendirme yapmasını sağlayarak otomasyonun ölçeğiyle insan uzmanlığının yargısı arasında bir denge kurar. Ama bu yöntemin bilinen sınırları da var: değerlendirici modelin kendi önyargıları olabilir (en tipik olanı **uzunluk yanlılığıdır** — içerik daha doğru olmasa bile daha uzun ve daha ayrıntılı yanıtlara yüksek puan verme eğilimi) ve aynı girdi birden çok kez değerlendirildiğinde sonuçlar dalgalanabilir. Özellikle uzunluk yanlılığına karşı ayrıca önlem almaya değer; üç yaygın yöntem vardır: Rubric'te uzun uzadıya anlatımı açıkça cezalandırmak ve aynı tür görevler için yanıt uzunluğuna üst sınır koymak; ikili karşılaştırma yaparken iki adayın uzunluğunu önce birbirine yaklaştırıp sonra değerlendirmek; ve puanlarla yanıt uzunluğu arasındaki ilişkiyi düzenli olarak denetlemek — yüksek puanlar neredeyse her zaman uzun yanıtlara gidiyorsa, değerlendirme uzunluğun etkisine kapılmış demektir ve Rubric elden geçirilmelidir. Bu zorluklarla sistematik biçimde başa çıkmak için Rubric tasarımı aşağıdaki ilkelere uymalıdır: @@ -363,7 +364,7 @@ rubric: Rubric ile Agent'ın yanıtını birlikte hakem modele verin; model her boyutu puanlayıp gerekçesini yazsın. Onlarca vakanın sonuçlarını boyutlara göre topladığınızda ve düşük puanlı trajectory'leri yeniden oynattığınızda, genel bir “başarı düştü” bulgusu somut bir teşhise dönüşür: retrieval bir olguyu kaçırmış olabilir, model kişi ya da olayları yanlış ilişkilendirmiş olabilir veya dayanağı olmayan bir iddia eklemiş olabilir. İyi bir Rubric yalnızca sistemin kaç puan aldığını değil, bir sonraki incelemenin nereye yönelmesi gerektiğini de gösterir. -Aşağıda kullanıcı belleğini somut bir örnek olarak alıp, bu genel yöntemin çalıştırılabilir bir değerlendirme kümesine ve puanlayıcıya nasıl indirgendiğini gösteriyoruz. +Aşağıda kullanıcı belleğini somut bir örnek olarak alıp, bu genel yöntemin çalıştırılabilir bir değerlendirme kümesine ve doğrulayıcıya nasıl indirgendiğini gösteriyoruz. > **Deney 7-3 ★★: Rubric Tabanlı Bir Kullanıcı Belleği Değerlendirme Sistemi Kurmak** > @@ -534,7 +535,7 @@ Gerçek model seçimlerinde sık karşılaştığımız soru şudur: "A mı daha ### İkili Karşılaştırma ve Model Sıralaması -![Şekil 7-5: Elo Puanlaması ve İkili Karşılaştırmayla Sıralama](images/fig7-5.svg) +![Şekil 7-6: Elo Puanlaması ve İkili Karşılaştırmayla Sıralama](images/fig7-6.svg) **Elo puanlaması** (aslen satranç için tasarlanmış bir sıralama sistemi), çok sayıda ikili karşılaşma üzerinden modellerin göreli yeteneğini niceler: puan farkı ne kadar büyükse, güçlü olanın beklenen kazanma oranı o kadar yüksektir. Örneğin model A'nın puanı 1.200, model B'nin puanı 1.000 ise Elo sistemi A'nın kazanma oranını yaklaşık %76 olarak öngörür. B beklenmedik biçimde kazanırsa B daha çok puan kazanır, A daha çok puan kaybeder — sürpriz sonuçlar daha büyük bir düzeltme getirir ve bu mekanizma sıralamanın gerçek seviyeye hızla yakınsamasını sağlar. Arkasındaki istatistiksel temel **Bradley-Terry modelidir**: her model gizli bir "güç puanı" olarak soyutlanır ve ikili karşılaşmanın kazanma olasılığı iki puan arasındaki farkla belirlenir; Elo ise bu modelin çevrimiçi güncelleme biçimindeki mühendislik uygulamasıdır. @@ -698,7 +699,7 @@ Birden çok hipotezi paralel doğrularken **çoklu karşılaştırmayı** da hes Değerlendirme güdümlü kararlar (ister model seçimi ister sürekli yineleme olsun) yüksek kaliteli çalışma verisine dayanır. Aşağıda önce bu verinin sistematik olarak nasıl toplandığını (observability), ardından değerlendirme sonuçlarının sistem iyileştirmelerine nasıl dönüştürüleceğini ele alıyoruz. -![Şekil 7-6: Observability Teknoloji Yığını](images/fig7-6.svg) +![Şekil 7-7: Observability Teknoloji Yığını](images/fig7-7.svg) Observability (gözlemlenebilirlik) kavramı dağıtık sistemler alanından ödünç alınmıştır: sistemin içini açıp ne yaptığını doğrudan göremezsiniz, yalnızca ürettiği loglardan, metriklerden ve trace verisinden ne olduğunu çıkarsayabilirsiniz — tıpkı hastanın içini doğrudan göremeyen bir hekimin ateş, tansiyon, görüntüleme gibi dışsal sinyallerden teşhis koyması gibi. Agent sistemleri bu işi daha da zorlaştırır: aynı girdi farklı çıktılar üretebilir, çok turlu çıkarım ve araç çağrıları yürütme yollarını son derece karmaşıklaştırır ve modelin "düşünme" süreci dışarıdan tamamen saydamsızdır. @@ -718,11 +719,11 @@ Eksiksiz bir değerlendirme sistemi ve veri kümesi kurulduktan sonra kilit mese Aşağıdaki vaka, eşlik eden depodaki gerçek fakat bilinçli olarak dar tutulmuş bir AndroidWorld yinelemesinden geliyor. API 35 emülatöründe dört Wi-Fi ayarı görevi vardır ve görev başına bir eşleştirilmiş koşu yapılmıştır. Bu, 116 görevlik tam benchmark değildir ve API 33 referans ortamında yeniden çalıştırmanın yerini tutmaz. Değeri genel bir puanda değil, bir sonuçtan diğerine giden karar dizisindedir. -![Şekil 7-7: Benchmark'tan İyileştirmeye Kapalı Döngü](images/fig7-7.svg) +![Şekil 7-8: Benchmark'tan İyileştirmeye Kapalı Döngü](images/fig7-8.svg) Harness mühendisliği açısından bakıldığında bu bölüm özünde Harness'in yinelemeli optimizasyonunun yöntemini anlatır — değerlendirme verisiyle Harness'teki zayıf halkalar saptanır (context yetersiz mi? kısıt eksik mi? doğrulama yeterli değil mi? geri bildirim zamanında değil mi?), hedefli iyileştirmeler yapılır ve yeniden değerlendirilir; böylece Harness'in sürekli evrimini sağlayan kapalı bir döngü oluşur. -Benchmark raporunu incelemeye başlamadan önce kolayca gözden kaçan bir ilke var: **Agent'ın performansı düştüğünde önce değerlendirme sisteminin kendisini kontrol edin, sonra Agent'a dokunun**. Yaygın bir yanılgı, puan düşer düşmez Agent kodunu değiştirmeye girişmek ve değerlendirme sisteminin kendisinin önce bozulmuş olabileceğini göz ardı etmektir — bozuk bir sinyale bakarak yön ayarlamak, daha ilk adımdan yanlış yöne gitmek demektir. Değerlendirme sistemindeki yaygın hata kaynakları şunlardır: çalışma ortamındaki kaynak yetersizliği yüzünden süreçlerin öldürülmesi (rastgele başarısızlık gibi görünür), puanlayıcının kendisindeki bir bug'ın doğru yanıtları başarısız sayması ve test durumlarının üretim senaryolarından kopması. Bunların hepsi sonuç rakamlarında modelin gerilemesiyle birebir aynı görünür; ancak eksiksiz trajectory'ler incelenerek ayırt edilebilirler. +Benchmark raporunu incelemeye başlamadan önce kolayca gözden kaçan bir ilke var: **Agent'ın performansı düştüğünde önce değerlendirme sisteminin kendisini kontrol edin, sonra Agent'a dokunun**. Yaygın bir yanılgı, puan düşer düşmez Agent kodunu değiştirmeye girişmek ve değerlendirme sisteminin kendisinin önce bozulmuş olabileceğini göz ardı etmektir — bozuk bir sinyale bakarak yön ayarlamak, daha ilk adımdan yanlış yöne gitmek demektir. Değerlendirme sistemindeki yaygın hata kaynakları şunlardır: çalışma ortamındaki kaynak yetersizliği yüzünden süreçlerin öldürülmesi (rastgele başarısızlık gibi görünür), doğrulayıcının kendisindeki bir bug'ın doğru yanıtları başarısız sayması ve test durumlarının üretim senaryolarından kopması. Bunların hepsi sonuç rakamlarında modelin gerilemesiyle birebir aynı görünür; ancak eksiksiz trajectory'ler incelenerek ayırt edilebilirler. ### Benchmark Raporunu Okumak: Sorun Keşfetme Sanatı @@ -827,7 +828,7 @@ Değerlendirmenin varış noktası puan vermek değil, iyileştirmedir. Bu böl Bu köprünün iki ucu şöyle birleşir. Değerlendirme tarafında biriken varlıklar neredeyse kusursuz biçimde eğitim sinyaline dönüşebilir: açıkça tanımlanmış bir Rubric ya da doğrulayıcı, özünde bir **doğrulanabilir ödül (RLVR, Reinforcement Learning with Verifiable Rewards)** ödül fonksiyonudur — puanlama betiği doğrudan ödül betiğidir; testin geçip geçmediği, durumun ölçüte uyup uymadığı hem değerlendirmenin ölçütü hem de pekiştirmeli öğrenmenin getirisidir. Ama eğitim, değerlendirme aşamasında hiç dert edilmeyen yeni gereksinimler ortaya çıkarır. Birincisi **güvenilir reset semantiğidir**: eğitim milyonlarca episode koşar (bir episode, başlangıç durumundan görev sonuna kadarki eksiksiz bir etkileşim turudur) ve her episode ortamı belirli, temiz bir başlangıç durumuna sıfırlayabilmelidir; yoksa gradyan sinyali önceki turdan kalan artık durumla kirlenir. İkincisi **değerlendirmeninkinden çok daha yüksek throughput'tur**: değerlendirmede sonuca varmak için birkaç bin koşu yeterken, eğitimde kabul edilebilir bir duvar saati süresi içinde modele milyonlarca etkileşim beslenmelidir; ortamın paralellik derecesi ve tek örnek başına yükü, eğitimin yapılabilir olup olmadığını doğrudan belirler. Bu iki nokta — ödül fonksiyonuna dönüşen doğrulayıcılar ile eğitim ölçeğinde reset ve throughput — Bölüm 8'de açılacak. -![Şekil 7-8: Simülasyon Sadakati Spektrumu](images/fig7-8.svg) +![Şekil 7-9: Simülasyon Sadakati Spektrumu](images/fig7-9.svg) **Dijital ortamlar** tarafında AWorld çerçevesi, GAIA görevleri için denetlenebilir bir MCP sunucu sandbox'ı kurar; 26 MCP sunucusu ve 126 araç fonksiyonu sağlayarak gerçek API'lere doğrudan erişmenin getirdiği yasaklanma ve denetlenemeyen yan etkilerden kaçınır. Tüm araç çağrıları yeniden oynatılabilir ve denetlenebilir. AWorld'ün dağıtık mimarisi, geleneksel seri yürütmedeki 7.695 saniyeyi 525 saniyeye indirir (14,6 kat hızlanma); ortamın durumsuz tasarımı sayesinde her örnek tamamen bağımsızdır ve verimli paralellik desteklenir. @@ -838,7 +839,7 @@ Bu köprünün iki ucu şöyle birleşir. Değerlendirme tarafında biriken varl > Robot manipülasyonu için bir simülasyon ortamı kurun. `ch7/SimpleVLA-RL` ile OpenVLA belgelerini okuyup görme-dil-eylem modelinin mimarisini anlayın (görme kodlayıcı + dil modeli + eylem kod çözücünün uçtan uca bütünleştirilmesi; görüntü ve metin ortak bir semantik uzaya izdüşürülür). RoboTwin2 ortamını yapılandırın; gözlem alanını (üç açılı RGB + 14 boyutlu eklem durumu) ve eylem alanını (14 boyutlu denetim vektörü) kavrayın. `move_can_pot` içindeki ortam rastgeleleştirme mekanizmasını ve uzamsal kısıt mantığını inceleyin. Önceden eğitilmiş modeli çalıştırıp değerlendirin; başarı oranını, tamamlanma süresini ve başarısızlık biçimlerini kaydedin, özellikle eylem parçalama mekanizmasının etkisine odaklanın. > > -> ![Şekil 7-9: OpenVLA ve RoboTwin2 Bedenlenmiş Zeka Ortamı](images/fig7-9.svg) +> ![Şekil 7-10: OpenVLA ve RoboTwin2 Bedenlenmiş Zeka Ortamı](images/fig7-10.svg) > > @@ -850,7 +851,7 @@ Yüksek sadakatli ortamlar gerçek dünyaya daha iyi aktarılır, ama hesaplama ## Bölüm Özeti -Bu bölüm tek bir temel soru etrafında döndü: bir Agent'ın gerçekten iyileştiğine nasıl karar veririz? Yeniden üretilebilir test ortamından sızıntıya dayanıklı veri kümelerine, LLM hakemlerden değerlendirme güdümlü model seçimi ve yinelemeye kadar her halka sonucun güvenilirliğini etkiler. Ölçülen vakalar dört somut uyarı ekledi: yapılandırılmış bellek ile RAG'ı birleştirmek sinerjiyi garanti etmez; cache ve sıkıştırma tasarrufları toplanamaz; referans ses seçimi çok modlu puanın anlamını değiştirir; Harness'in girdi temsili hem görev başarısını hem token maliyetini belirleyebilir. Model seçiminde tek bir puan yerine farklı kaynak bütçelerindeki yetenek eğrileri karşılaştırılmalıdır. Üretim düzeyinde değerlendirme, ara sıra girilen bir sınav değil, her ürün kararına gömülü sürekli doğrulamadır. +Bu bölüm tek bir temel soru etrafında döndü: bir Agent'ın gerçekten iyileştiğine nasıl karar veririz? Zincir dört halkadan oluşur: önce neyin başarı sayıldığını netleştirmek (Pass@k, Best@k ve Pass consecutive@k dayanaklarının farkı), sonra görevlerin nereden geldiğini belirlemek (açık benchmark'lar, kendi iş kümeniz ve üretim trajectory'lerinin geri akışı), ardından doğrulama biçimini seçmek (belirlenimci doğrulayıcılardan denetim listelerine, Rubric ile LLM yargısına ve ikili karşılaştırmaya kadar) ve son olarak puanları karara dönüştürmek (istatistiksel anlamlılık, başarısızlık atfı, regresyon görevleri ve model seçimi). Her halka sonucun güvenilirliğini etkiler. Ölçülen vakalar dört somut uyarı ekledi: yapılandırılmış bellek ile RAG'ı birleştirmek sinerjiyi garanti etmez; cache ve sıkıştırma tasarrufları toplanamaz; referans ses seçimi çok modlu puanın anlamını değiştirir; Harness'in girdi temsili hem görev başarısını hem token maliyetini belirleyebilir. Model seçiminde tek bir puan yerine farklı kaynak bütçelerindeki yetenek eğrileri karşılaştırılmalıdır. Üretim düzeyinde değerlendirme, ara sıra girilen bir sınav değil, her ürün kararına gömülü sürekli doğrulamadır. Kitabın bütünsel yapısı açısından bu bölüm, Bölüm 1'deki keşif döngüsünün **kanıt** kesitini kurar: hata atfı, sonraki önerilerin dayanacak sağlam bir zemini olup olmadığını belirler. diff --git a/book-tr/images/fig7-1.svg b/book-tr/images/fig7-1.svg index 5bc38143a..03755b7f2 100644 --- a/book-tr/images/fig7-1.svg +++ b/book-tr/images/fig7-1.svg @@ -1,19 +1,62 @@ - - - -Layer 1: Evaluate the Environment -"Where to test" — Tool-calling / Human-computer interaction / Simulation environment - - -Layer 2: Evaluation Methods -"How to judge" — Dataset design · LLM-as-a-Judge · Pairwise comparison and ranking - - -Layer 3: Evaluation-Driven Decisions -"What to do after testing" — Model selection · Architecture optimization · Continuous iteration - -Engineering Themes Throughout the Chapter -• Observability -• Simulation environment -• Internal evaluation - \ No newline at end of file + + + + + + + + +① Başarının tanımı +Pass@k yetenek tavanını · Pass^k güvenilirliği ölçer + + + +② Görevlerin kaynağı + +Açık benchmark'lar +Teknik ödünç alma · kaba eleme + +Kendi iş kümeniz +Gerçek görev dağılımı + +Üretimden geri akış +Başarısızlık atfının ürünü + + + +③ Doğrulama biçimi +← görevin makineyle doğrulanabilirlik derecesine göre → + +Belirlenimci +SWE-bench + + +Denetim listesi +τ²-bench + + +Rubric + LLM +Açık uçlu görevler + + +İkili karşılaştırma +Chatbot Arena + + + +④ Sonuçların kullanımı +Anlamlılık → Atıf → Regresyon → Model ve Harness yinelemesi + + +Regresyon görevleri yeni durumlara dönüşür + + +Destekleyici altyapı +Gözlemlenebilirlik · İç değerlendirme altyapısı (ablasyon / AB / bayraklar) · Simülasyon (Bölüm 8) + diff --git a/book-tr/images/fig7-10.svg b/book-tr/images/fig7-10.svg new file mode 100644 index 000000000..be0eea6b2 --- /dev/null +++ b/book-tr/images/fig7-10.svg @@ -0,0 +1,69 @@ + + + + +Multimodal observation + +Head camera +224×224 RGB + +Left wrist camera +224×224 RGB + +Right wrist camera +224×224 RGB + +14-dimensional joint state vector + +Vision-Language-Action model (VLA) + +Vision encoder +SigLIP → visual tokens + + +Language model +Llama 2 7B backbone + + +Action decoder +→ 14-dimensional continuous control vector +Action chunking: generate 25 consecutive actions at once + + + +Instruction: "Put the can into the pot" + + +SAPIEN physics engine + +Dual-arm robot +7 DOF each = 14-dimensional action + +Environment randomization +Position 60cm / orientation ±22.5° + +Collision detection + physics simulation +Rigid body / soft body / friction + +Action + +Observation + +Evaluation metrics + +Success rate +Can inside pot +and not fallen + +Completion time +25 steps × 25 actions += 625 control steps + +Generalization ability +Cross-position/orientation +/Appearance variant + +Sim-to-Real +Domain randomization +→ Real migration + \ No newline at end of file diff --git a/book-tr/images/fig7-3.svg b/book-tr/images/fig7-3.svg index d8f6fcc1c..0612bf564 100644 --- a/book-tr/images/fig7-3.svg +++ b/book-tr/images/fig7-3.svg @@ -1,68 +1,76 @@ - - + + + + + + + - -User Simulator (LLM) - -Known Information: -Name: Sarah Johnson -Booking: BK-98712 -Task Instruction: -"There seems to be a problem with the flight" -→ Gradually reveal details -→ Do not proactively provide the booking number - -Agent (To Be Evaluated) - - -LLM Reasoning + Strategy Selection -① May I have your booking number? -② lookup_booking(BK-98712) -③ Flight UA123 has been canceled -④ cancel_booking(BK-98712) -⑤ Refund $150, 3-5 business days - -Tools + Database - -lookup_booking -Query booking details -modify_booking -Modify booking status -cancel_booking -Cancel and refund -search_flights -Search for alternative flights -send_notification -Send confirmation notification - -DB State: -bookings, users, flights - -Dialogue - - -Tool Call - - -Dual-control environment: User simulator can also directly operate the shared environment (tools + database) - -After task completion: Multi-layer verification - -DB status check - -booking.status == 'cancelled' -refund_record EXISTS -refund.amount == 150.00 - -Dialogue content verification - -Contains 'refund' + amount -Contains 'arrival time' -No false information present - -Process compliance check - -Obtain user confirmation before modification -No unauthorized operation -No excessive transfer to human agent - \ No newline at end of file + + +Kullanıcı simülatörü (LLM) +known_info: John Smith / 555-123-2002 / Fransa'da +task_instructions: aşamalı açma · duygu · dayandırma +Kabul: yalnızca excellent çözüm sayılır + + + +Agent (değerlendirilen) +Girdi: çağrı kaydı + alan politikası +Görünmez: cihazın gerçek durumu +Yalnızca yönlendirir, yerine yapamaz + + + +Çok turlu diyalog +Aşamalı bilgi açma + + + +Ortak ortam (çift denetim: iki taraf da durumu değiştirir) + +Cihaz tarafı durumu +Uçak modu ON · dolaşım OFF · veri tasarrufu · kalan veri +Kullanıcı araçları: toggle_airplane_mode / toggle_roaming + check_status_bar / run_speed_test + +Operatör tarafı veritabanı +Müşteri C1001 · hatlar L1001/L1002/L1003 · tarifeler · faturalar +Agent araçları: get_customer_by_phone / get_data_usage + enable_roaming / refuel_data + + + + + + +Kullanıcının toggle_roaming'i ortamı değiştirdi; Agent aracı yeniden çağırmalı — doğrulama bu yeniden okumayı kapsar + + + +Görev bitince: dört katman denetim + toplama kuralı + +env_assertions +Mobil veri kullanılabilir +Hız ≥ 200 / excellent + +actions +toggle_airplane_mode +requestor user olmalı + +communicate_info +Gerekli bilgi iletildi mi +bu görevde null + +nl_assertions +Doğal dil düzeyinde yargı +bu görevde null +reward_basis = ["ENV_ASSERTION"] → yalnızca ilk katman sayılır; diğerleri kaydedilir ama ödüle girmez + diff --git a/book-tr/images/fig7-4.svg b/book-tr/images/fig7-4.svg index 2a3aba4aa..07b0343fa 100644 --- a/book-tr/images/fig7-4.svg +++ b/book-tr/images/fig7-4.svg @@ -1,53 +1,54 @@ - - + + + + + + - -Rubric - -Factual Correctness: Essential -Logical Coherence: Important -Hallucination Detection: Veto ⚠ -Completeness: Important - -Candidate Answer - -Agent Output: -"Refund processed, $150 will be credited within - 3-5 business days." - - -Reference Solution (Optional) - -Standard Answer / Scoring Points: -Must include refund amount -Must include credit time -Cannot promise a specific date - - - - -Judge Model (GPT-5 / Gemini 2.5) -Multi-source heterogeneous evaluation to prevent same-source bias - - -Structured evaluation output - -Factual Correctness -4/4 -Amount and time are both accurate -Completeness -3/4 -Missing explanation of refund method -Hallucination Detection -PASS -No false information -Logical Coherence -4/4 -Clear causal relationship - -Scoring Aggregation Strategy -Weighted average: Σ(weight × dimension score) -Veto: Hallucination=FAIL → total score=0 -Multi-judge: median of 3 judges -Edge case flag: disagreement >2 points → human review - \ No newline at end of file + +Görevin makineyle doğrulanabilirliği: yüksek +düşük + + +Belirlenimci +Son durum tek ve sorgulanabilir +Geçti / geçmedi +SWE-bench test koşturur + + + +Denetim listesi +Birkaç belirlenimci denetim +Bildirilen dayanağa göre toplanır +τ²-bench dört katman + + + +Rubric + LLM +Boyut var, kodla karar yok +Boyut boyut puan ve gerekçe +Hizmet kalitesi, rapor yazımı + + + +İkili karşılaştırma +Boyutu bile yazmak güç +Yalnızca A ile B'yi kıyaslar +Chatbot Arena + + +Belirlenimci doğrulama +Tümüyle yinelenebilir, CI'ya uygun, ucuz +Bedeli: doğru/yanlış der, yerini göstermez + + +Model yargısı +Tanısal boyut verir, savlanamayanı kapsar +Bedeli: yargı yanlılığı ve değişkenlik, daha pahalı + diff --git a/book-tr/images/fig7-5.svg b/book-tr/images/fig7-5.svg index 48eba2457..2a3aba4aa 100644 --- a/book-tr/images/fig7-5.svg +++ b/book-tr/images/fig7-5.svg @@ -1,56 +1,53 @@ - + - -Chatbot Arena Anonymous Battle - -Model A (Anonymous) - -"Refund processed, will arrive in 3-5 - business days to your account" -VS - -Model B (Anonymous) - -"Okay, refund will be processed" - - -User blind pick → A is better - -Elo Update Formula -Expected win rate E_A = 1/(1+10^((R_B-R_A)/400)) | Update: R_A' = R_A + K*(1-E_A) -Live Leaderboard (Example) -Rank -Model -Elo -Win rate vs #2 - -1 -Claude 4 Opus -1352 -— -2 -GPT-5 -1318 -— -3 -Gemini 2.5 Pro -1290 -45% -4 -DeepSeek R2 -1265 -42% -5 -Qwen 3 Max -1230 -39% -6 -Llama 4 405B -1198 -36% - - -GRPO: Introducing Pairwise Comparison into RL Training -A set of candidate responses → Normalize relative advantage → Policy update (bypass explicit reward model) + +Rubric + +Factual Correctness: Essential +Logical Coherence: Important +Hallucination Detection: Veto ⚠ +Completeness: Important + +Candidate Answer + +Agent Output: +"Refund processed, $150 will be credited within + 3-5 business days." + + +Reference Solution (Optional) + +Standard Answer / Scoring Points: +Must include refund amount +Must include credit time +Cannot promise a specific date + + + + +Judge Model (GPT-5 / Gemini 2.5) +Multi-source heterogeneous evaluation to prevent same-source bias + + +Structured evaluation output + +Factual Correctness +4/4 +Amount and time are both accurate +Completeness +3/4 +Missing explanation of refund method +Hallucination Detection +PASS +No false information +Logical Coherence +4/4 +Clear causal relationship + +Scoring Aggregation Strategy +Weighted average: Σ(weight × dimension score) +Veto: Hallucination=FAIL → total score=0 +Multi-judge: median of 3 judges +Edge case flag: disagreement >2 points → human review \ No newline at end of file diff --git a/book-tr/images/fig7-6.svg b/book-tr/images/fig7-6.svg index 60f897941..48eba2457 100644 --- a/book-tr/images/fig7-6.svg +++ b/book-tr/images/fig7-6.svg @@ -1,48 +1,56 @@ - + - -Execution trace tree (single task) - -Trace: Check Beijing weather for user tomorrow (3.2s, $0.008) - -LLM Call: Intent recognition -Claude 4 Sonnet · 0.4s · 320 tokens - -Tool：get_weather(Beijing) -MCP Server · 1.8s · 200ms TTFT - -├─ HTTP Request -api.weather.com · 1.6s - -└─ Response Parse -JSON → Structured weather data - -LLM Call: Generate response -Claude 4 Sonnet · 0.8s · 580 tokens - -Tool：send_message(user) -0.2s · Contains weather summary - - - - - - - -Monitoring dashboard - -Cost tracking -Today: $12.30 (1,200 calls) -This month: $340 (34K calls) -Anomaly: task#892 looped search 14 times, cost $2.1 - -Performance monitoring -P50 / P95 / P99 latency: 2.1s / 8.4s / 15.2s -Tool success rate: 94.3% - -Quality audit -Task success rate: 87% Hallucination trigger: 2.1% -Security violations: 0 (this month) User satisfaction: 4.3/5 - -Closed loop: Trace data → Identify issues → A/B testing → Prompt version management → Continuous optimization + + +Chatbot Arena Anonymous Battle + +Model A (Anonymous) + +"Refund processed, will arrive in 3-5 + business days to your account" +VS + +Model B (Anonymous) + +"Okay, refund will be processed" + + +User blind pick → A is better + +Elo Update Formula +Expected win rate E_A = 1/(1+10^((R_B-R_A)/400)) | Update: R_A' = R_A + K*(1-E_A) +Live Leaderboard (Example) +Rank +Model +Elo +Win rate vs #2 + +1 +Claude 4 Opus +1352 +— +2 +GPT-5 +1318 +— +3 +Gemini 2.5 Pro +1290 +45% +4 +DeepSeek R2 +1265 +42% +5 +Qwen 3 Max +1230 +39% +6 +Llama 4 405B +1198 +36% + + +GRPO: Introducing Pairwise Comparison into RL Training +A set of candidate responses → Normalize relative advantage → Policy update (bypass explicit reward model) \ No newline at end of file diff --git a/book-tr/images/fig7-7.svg b/book-tr/images/fig7-7.svg index 7ff1dd778..60f897941 100644 --- a/book-tr/images/fig7-7.svg +++ b/book-tr/images/fig7-7.svg @@ -1,56 +1,48 @@ - + - - -① Observation: Diagnostic Report -Overall Success Rate: 88% (102/116) -transcription: 0% complex_ui: 17% -math_counting: 0% Wi-Fi Operation: 0% -Task 82,102-115 Concentrated Failures - -② Hypothesis: Three-Layer Improvement Framework - -Surface Layer -H1 Set Navigation Prompt H2 UI Rules - -Middle Layer -H3 Fix Multimodal Pipeline H4 Thinking - -Deep Layer -H5 GPT-5 H6 UI Element Tree - - -③ Experiment: Phased Validation (5 runs × 116 tasks per configuration) - -H1 Navigation -Setup 0%→75% -token+8% - -H3 Multimodal -Transcription 0%→80% -Latency +1s - -H4 Thinking -Counting 0%→70% -Latency 3x! - -H6 Element Tree -UI 17%→52% -token+30% - -④ Decision: Cost-Benefit Trade-off -✓ H1+H3: Low Cost, High Benefit → Deploy -✗ H4: Only 8% Tasks Benefit but 3x Latency → Reject -✓ H6: 35% Improvement / 30% Cost → Deploy -✗ H5: 15s/Step Unacceptable → Alternative - -⑤ Iteration: New Cycle -Deploy H1+H3+H6 → 88%→94% -New Report Shows Different Failure Modes: - H7: Conditional Thinking Enabled - H8: Expand gesture action space - -↑ Loop - -Methodology: Observe → Hypothesize → Experiment → Decide → Iterate = From alchemy to scientific engineering + +Execution trace tree (single task) + +Trace: Check Beijing weather for user tomorrow (3.2s, $0.008) + +LLM Call: Intent recognition +Claude 4 Sonnet · 0.4s · 320 tokens + +Tool：get_weather(Beijing) +MCP Server · 1.8s · 200ms TTFT + +├─ HTTP Request +api.weather.com · 1.6s + +└─ Response Parse +JSON → Structured weather data + +LLM Call: Generate response +Claude 4 Sonnet · 0.8s · 580 tokens + +Tool：send_message(user) +0.2s · Contains weather summary + + + + + + + +Monitoring dashboard + +Cost tracking +Today: $12.30 (1,200 calls) +This month: $340 (34K calls) +Anomaly: task#892 looped search 14 times, cost $2.1 + +Performance monitoring +P50 / P95 / P99 latency: 2.1s / 8.4s / 15.2s +Tool success rate: 94.3% + +Quality audit +Task success rate: 87% Hallucination trigger: 2.1% +Security violations: 0 (this month) User satisfaction: 4.3/5 + +Closed loop: Trace data → Identify issues → A/B testing → Prompt version management → Continuous optimization \ No newline at end of file diff --git a/book-tr/images/fig7-8.svg b/book-tr/images/fig7-8.svg index 52e636831..7ff1dd778 100644 --- a/book-tr/images/fig7-8.svg +++ b/book-tr/images/fig7-8.svg @@ -1,41 +1,56 @@ - + - - -Simulation fidelity → -Scalability - - - -↑ - -Mock API -unit test level -million times/hour - -AWorld -MCP sandbox -126 tool functions -525s/round distributed - -AndroidWorld -Simulator -116 real-world application tasks -UI Automator - -Isaac Gym -GPU parallelism -thousands of parallel instances -Slightly compromised accuracy - -RoboTwin2 -physics engine -High-precision collision -Single-instance CPU - -real world -Perfect fidelity -Non-resettable - + +① Observation: Diagnostic Report +Overall Success Rate: 88% (102/116) +transcription: 0% complex_ui: 17% +math_counting: 0% Wi-Fi Operation: 0% +Task 82,102-115 Concentrated Failures + +② Hypothesis: Three-Layer Improvement Framework + +Surface Layer +H1 Set Navigation Prompt H2 UI Rules + +Middle Layer +H3 Fix Multimodal Pipeline H4 Thinking + +Deep Layer +H5 GPT-5 H6 UI Element Tree + + +③ Experiment: Phased Validation (5 runs × 116 tasks per configuration) + +H1 Navigation +Setup 0%→75% +token+8% + +H3 Multimodal +Transcription 0%→80% +Latency +1s + +H4 Thinking +Counting 0%→70% +Latency 3x! + +H6 Element Tree +UI 17%→52% +token+30% + +④ Decision: Cost-Benefit Trade-off +✓ H1+H3: Low Cost, High Benefit → Deploy +✗ H4: Only 8% Tasks Benefit but 3x Latency → Reject +✓ H6: 35% Improvement / 30% Cost → Deploy +✗ H5: 15s/Step Unacceptable → Alternative + +⑤ Iteration: New Cycle +Deploy H1+H3+H6 → 88%→94% +New Report Shows Different Failure Modes: + H7: Conditional Thinking Enabled + H8: Expand gesture action space + +↑ Loop + +Methodology: Observe → Hypothesize → Experiment → Decide → Iterate = From alchemy to scientific engineering \ No newline at end of file diff --git a/book-tr/images/fig7-9.svg b/book-tr/images/fig7-9.svg index be0eea6b2..52e636831 100644 --- a/book-tr/images/fig7-9.svg +++ b/book-tr/images/fig7-9.svg @@ -1,69 +1,41 @@ - + - -Multimodal observation - -Head camera -224×224 RGB - -Left wrist camera -224×224 RGB - -Right wrist camera -224×224 RGB - -14-dimensional joint state vector - -Vision-Language-Action model (VLA) - -Vision encoder -SigLIP → visual tokens - - -Language model -Llama 2 7B backbone - - -Action decoder -→ 14-dimensional continuous control vector -Action chunking: generate 25 consecutive actions at once - - - -Instruction: "Put the can into the pot" - - -SAPIEN physics engine - -Dual-arm robot -7 DOF each = 14-dimensional action - -Environment randomization -Position 60cm / orientation ±22.5° - -Collision detection + physics simulation -Rigid body / soft body / friction - -Action - -Observation - -Evaluation metrics - -Success rate -Can inside pot -and not fallen - -Completion time -25 steps × 25 actions -= 625 control steps - -Generalization ability -Cross-position/orientation -/Appearance variant - -Sim-to-Real -Domain randomization -→ Real migration + + +Simulation fidelity → +Scalability + + + +↑ + +Mock API +unit test level +million times/hour + +AWorld +MCP sandbox +126 tool functions +525s/round distributed + +AndroidWorld +Simulator +116 real-world application tasks +UI Automator + +Isaac Gym +GPU parallelism +thousands of parallel instances +Slightly compromised accuracy + +RoboTwin2 +physics engine +High-precision collision +Single-instance CPU + +real world +Perfect fidelity +Non-resettable + \ No newline at end of file diff --git a/book-vi/chapter7.vi.md b/book-vi/chapter7.vi.md index c3bc3292f..423ad537c 100644 --- a/book-vi/chapter7.vi.md +++ b/book-vi/chapter7.vi.md @@ -17,58 +17,117 @@ Khi xây dựng hệ thống Agent, các nhà phát triển phải đối mặt Từ quan điểm của kỹ thuật Harness được giới thiệu trong Chương 1, việc đánh giá đóng vai trò cốt lõi trong chức năng “xác nhận” trong Harness. Hiểu biết quan trọng là: **Đối tượng đánh giá không chỉ là mô hình mà còn là sự kết hợp giữa mô hình và Harness**. Cùng một mô hình có thể hoạt động rất khác nhau trong các Harness khác nhau - một số nhóm đã cải thiện đáng kể hiệu suất của cùng một mô hình trong các tác vụ đầu cuối chỉ bằng cách tối ưu hóa Harness (xem Chương 5 để biết chi tiết). Điều này có nghĩa là khi Agent hoạt động kém trong quá trình đánh giá, hướng cải tiến có thể không phải là thay đổi mô hình mà là tối ưu hóa một thành phần nhất định của Harness (lời nhắc, thiết kế công cụ, vòng phản hồi). Một hệ thống đánh giá hoàn chỉnh phải có khả năng phân biệt giữa hai loại vấn đề cơ bản khác nhau: "khả năng mô hình không đủ" và "lỗi thiết kế Harness". **Một cách phổ biến để phân biệt giữa hai loại vấn đề này là thử nghiệm hoán đổi mô hình** - giữ nguyên Harness, chỉ thay thế các mô hình mạnh hơn/yếu hơn và quan sát sự thay đổi về điểm số; nếu điểm không tăng khi chuyển sang mẫu mạnh hơn thì có nghĩa nút thắt nằm ở Harness; nếu điểm giảm mạnh khi chuyển sang mô hình yếu và điểm dao động lớn theo khả năng của mô hình, thì cách giải thích trực tiếp nhất là nút thắt cổ chai nằm ở chính khả năng của mô hình và hiệu suất hiện tại chủ yếu được xác định bởi mô hình (về việc liệu điều này là do bản thân nhiệm vụ khó hay Harness quá phụ thuộc vào mô hình trước đó, thì cần phải phân tích thêm). Lưu ý rằng đây là hai phương pháp khác với "thử nghiệm cắt bỏ" được đề cập trước đó: cắt bỏ là **tắt một thành phần của Harness** để xem hiệu suất tổng thể thay đổi như thế nào, trong khi thay thế mô hình là **giữ nguyên Harness và chỉ thay thế mô hình** - phương pháp trước xác định thành phần nào trong Harness là quan trọng và phương pháp sau phân biệt xem nút cổ chai nằm trong mô hình hay trong Harness. Giá trị của hệ thống đánh giá thậm chí còn nổi bật hơn trong thời đại phát triển mô hình nhanh chóng. Khả năng của mô hình vẫn đang phát triển nhanh chóng, nhưng chỉ vì mô hình mới hoạt động tốt hơn theo điểm chuẩn công khai không có nghĩa là mô hình đó thực hiện tốt hơn nhiệm vụ cụ thể của bạn—ngược lại, có thể xảy ra hiện tượng hồi quy hiệu suất (tức là phiên bản mới không tốt bằng phiên bản cũ ở một số khía cạnh). Các quyết định nâng cấp dựa trên dữ liệu chỉ có thể được đưa ra thông qua thử nghiệm hoàn chỉnh trên tập dữ liệu đánh giá của riêng bạn. Hơn nữa, một hệ thống đánh giá hoàn chỉnh khiến cho việc "phát triển sản phẩm cho các mẫu tương lai" trở thành một chiến lược khả thi - ngay cả khi mô hình hiện tại không đủ để hỗ trợ sử dụng thương mại, trước tiên bạn có thể hoàn thành việc phát triển sản phẩm và thiết lập bộ đánh giá, tiếp tục theo dõi hiệu suất của mô hình mới và khởi chạy nó ngay lập tức khi đạt đến ngưỡng. +Một hệ thống đánh giá có thể tách thành bốn mắt xích: thế nào là thành công, nhiệm vụ đến từ đâu, ai kiểm chứng, và điểm số được chuyển thành quyết định ra sao. Hình 7-1 minh họa điều này. + +![Hình 7-1 Bốn mắt xích của hệ thống đánh giá Agent](images/fig7-1.svg) + +## Mổ xẻ một nhiệm vụ đánh giá: miền telecom của τ²-bench + +Trước hết hãy mổ xẻ trọn vẹn một nhiệm vụ thật trong miền telecom của τ²-bench. Mã nguồn nằm ở `chapter7/tau2-bench` trong kho, còn tệp nhiệm vụ là `data/tau2/domains/telecom/tasks_small.json`. + +### Bốn thành phần của định nghĩa nhiệm vụ + +Dưới đây là một nhiệm vụ trong tệp đó, đã lược bớt cho dễ đọc. + +```jsonc +{ + "id": "[mobile_data_issue]airplane_mode_on|user_abroad_roaming_enabled_off", + + // Phiếu yêu cầu giao cho Agent + "ticket": "Điện thoại của người dùng không vào được internet, thanh trạng thái + hiển thị 'No Service'. Khách hàng John Smith, số 555-123-2002, hiện + đang ở Pháp. Chỉ khi kiểm tra tốc độ trả về excellent mới coi là đã + xử lý xong. Không đổi gói cước, nhưng sẵn sàng nạp thêm 2,0 GB dữ + liệu nếu cần.", + + // Quy tắc hành vi giao cho bộ mô phỏng người dùng + "user_scenario": { "instructions": { + "known_info": "You are John Smith with phone number 555-123-2002. + You are currently abroad in France.", + "unknown_info": null, + "task_instructions": + "…express mild frustration after the first unsuccessful attempt. + You will consider the issue resolved only when speed test returns + excellent internet speed and nothing else. If it returns poor, fair + or good, you will not consider the issue resolved. + Whenever the agent asks you about your device, always ground your + responses on the results of tool calls. … + Never make up the results of tool calls." + }}, + + // Trước khi chạy, đưa trạng thái hai phía về cùng một điểm xuất phát + "initial_state": { "initialization_actions": [ + { "env_type": "user", "func_name": "turn_airplane_mode_on" }, + { "env_type": "user", "func_name": "turn_roaming_off" }, + { "env_type": "assistant", "func_name": "enable_roaming", + "arguments": { "customer_id": "C1001", "line_id": "L1002" } } + ]}, + + // Tiêu chí chấm điểm + "evaluation_criteria": { + "actions": [ + { "requestor": "user", "name": "toggle_airplane_mode" }, + { "requestor": "user", "name": "toggle_roaming" } + ], + "env_assertions": [ + { "func_name": "assert_mobile_data_status", "expected_status": true }, + { "func_name": "assert_internet_speed", + "expected_speed": 200, "expected_desc": "excellent" } + ], + "communicate_info": null, + "nl_assertions": null, + "reward_basis": ["ENV_ASSERTION"] + } +} +``` -> **Giới thiệu về chương này** -> -> Chương này xây dựng một hệ thống đánh giá hoàn chỉnh từ ba cấp độ. Lớp đầu tiên là **môi trường đánh giá**("nơi kiểm tra"): cách xây dựng môi trường thử nghiệm tự động và có thể tái tạo, bao gồm hai mô hình: loại lệnh gọi công cụ và loại tương tác giữa người và máy tính. Cấp độ thứ hai là **phương pháp đánh giá**("cách đánh giá"): từ nguyên tắc thiết kế tập dữ liệu, hệ thống chỉ số đánh giá (những gì cần đo lường), đến LLM-as-a-Judge (sử dụng mô hình ngôn ngữ lớn làm đánh giá) đánh giá tự động, đến so sánh theo cặp và xếp hạng mô hình. Cấp độ thứ ba là **ra quyết định dựa trên đánh giá**("những gì được đo lường"): kết quả đánh giá được chuyển thành hướng dẫn hành động để lựa chọn mô hình, tối ưu hóa kiến trúc và lặp lại liên tục, đồng thời ý nghĩa thống kê được sử dụng để xác định xem sự khác biệt về điểm số quan sát được có thực tế và đáng tin cậy hay không. Ngoài ra, chương này thảo luận về observability và cơ sở hạ tầng đánh giá nội bộ của Agent cấp sản xuất, đồng thời ở cuối chương giới thiệu môi trường mô phỏng được kết nối với post-training trong Chương 8. -> -> Khái niệm cốt lõi xuyên suốt toàn bộ chương này là: **Giá trị chính của hệ thống đánh giá không phải là chấm điểm cho hệ thống hiện tại mà là cho phép bạn theo kịp sự phát triển của mô hình một cách nhanh chóng và đáng tin cậy**. Khi một mô hình mạnh hơn hoặc rẻ hơn được phát hành, một nhóm có hệ thống đánh giá được phát triển tốt có thể đưa ra quyết định chuyển đổi trong vòng vài giờ, trong khi nhóm không có hệ thống đánh giá chỉ có thể dựa vào trực giác hoặc chờ phản hồi của cộng đồng - trong thị trường Agent cạnh tranh khốc liệt, sự khác biệt về tốc độ này có thể quyết định thành công hay thất bại. +Trong định nghĩa này có bốn quyết định thiết kế cần nói rõ. -![Hình 7-1 Ba cấp độ của hệ thống đánh giá](images/fig7-1.svg) +**Ranh giới hiểu biết của người dùng được mô hình hóa tường minh.** `known_info` chỉ chứa ba thông tin: tên, số điện thoại và quốc gia đang ở. Hai nguyên nhân thật sự của sự cố — chế độ máy bay đang bật và chuyển vùng dữ liệu đang tắt — không có trong đó. Người dùng không biết nên không thể tự nói ra, và Agent chỉ có thể lấy được bằng cách hỏi và hướng dẫn người dùng kiểm tra. Đây chính là cách **tiết lộ thông tin tuần tự (Progressive Information Disclosure)** được hiện thực hóa ở tầng định nghĩa nhiệm vụ: không phải ràng buộc bộ mô phỏng bằng một câu prompt "đừng nói hết một lúc", mà mô hình hóa phạm vi hiểu biết của người dùng thành một trường riêng. Phần lớn benchmark đưa ra yêu cầu đầy đủ ngay khi bắt đầu, trong khi câu đầu tiên của người dùng thật thường chỉ là "tôi không vào mạng được". Làm rõ yêu cầu đến mức có thể thực thi tự nó đã là một phần năng lực mà Agent phải có. -## Ví dụ đánh giá cụ thể +**Bộ mô phỏng nhận quy tắc hành vi chứ không phải lời thoại.** `task_instructions` gộp ba loại ràng buộc: thiết lập cảm xúc (tỏ ra hơi khó chịu sau lần khắc phục đầu tiên thất bại), tiêu chí nghiệm thu (chỉ khi kiểm tra tốc độ trả về excellent mới coi là xong; poor, fair, good đều không chấp nhận), và yêu cầu **neo vào sự kiện (Grounding)**, tức mọi câu trả lời về trạng thái thiết bị đều phải dựa trên giá trị mà công cụ trả về: "Never make up the results of tool calls". Điều thứ ba quan trọng nhất: thiếu ràng buộc neo sự kiện, người dùng mô phỏng sẽ theo sự dẫn dắt của Agent mà xác nhận vấn đề đã xong, và việc đánh giá thoái hóa thành hai mô hình xác nhận lẫn nhau. -Trước khi đi sâu vào phương pháp luận, hãy xây dựng trực giác thông qua một ví dụ hoàn chỉnh. Giả sử chúng ta xây dựng một dịch vụ khách hàng Agent và cần đánh giá khả năng xử lý các yêu cầu hoàn tiền của nó. +**Trạng thái ban đầu được chia theo phía điều khiển.** `env_type` nhận hai giá trị `user` và `assistant`: chế độ máy bay và công tắc chuyển vùng thuộc phía người dùng, còn `enable_roaming` phía nhà mạng thuộc phía Agent. Chính cách chia này quyết định hình dạng của sự cố — phía nhà mạng chuyển vùng đã mở, nhưng trên máy người dùng lại đang tắt, nên Agent tra cơ sở dữ liệu chỉ nhận được kết luận "cấu hình bình thường". Sự cố nằm ở phía mà cơ sở dữ liệu không nhìn thấy, và chỉ lộ ra khi hướng dẫn người dùng tự kiểm tra. -**Trường hợp thử nghiệm**: Người dùng đã yêu cầu hủy đơn hàng được thực hiện 3 ngày trước (mã đơn hàng #12345, số tiền ¥299). Chính sách của công ty: Hoàn tiền đầy đủ trong vòng 7 ngày. +**Tiêu chí chấm điểm chia thành bốn tầng, và nhiệm vụ này chỉ dùng một tầng.** `env_assertions` kiểm tra trạng thái cuối (dữ liệu di động dùng được, tốc độ từ 200 Mbps trở lên và xếp hạng excellent), `actions` kiểm tra các hành động then chốt có xảy ra hay không và **do phía nào** thực hiện, còn `communicate_info` và `nl_assertions` kiểm tra thông tin cần thiết đã được báo cho người dùng chưa. `reward_basis` của nhiệm vụ này chỉ khai báo `ENV_ASSERTION`; các tầng còn lại vẫn được tính và ghi nhận nhưng không vào phần thưởng cuối. Căn cứ chấm điểm được khai báo theo từng nhiệm vụ chứ không cố định toàn cục. -**Trajectory của Agent**: +### Trajectory của một lần chạy thật -```text -Người dùng: Tôi muốn trả lại tai nghe đã mua cách đây 3 ngày, mã đơn hàng 12345. (Hôm nay là 2026-04-10) +Tiếp theo, chúng tôi mời bạn đọc tự chạy các nhiệm vụ đánh giá của miền telecom trong τ²-bench, quan sát thiết kế nhiệm vụ, thiết kế bộ mô phỏng người dùng, logic kiểm chứng quá trình và kết quả, đồng thời xem trajectory thực thi của Agent để phân tích vì sao Agent thất bại. + +> **Thí nghiệm 7-1 ★: Chạy τ²-bench và so sánh bước tiến so với τ-bench** +> +> Thí nghiệm này chạy khung đánh giá τ²-bench để hiểu các điểm mấu chốt trong thiết kế môi trường đánh giá kiểu tương tác người-máy. Trước hết hãy đọc tệp định nghĩa nhiệm vụ theo đúng lộ trình của mục này: mỗi nhiệm vụ gồm bốn phần — thông tin đã biết, chỉ dẫn nhiệm vụ, trạng thái ban đầu và điều kiện thành công. Sau đó chạy trọn quy trình đánh giá, quan sát đối thoại nhiều lượt giữa bộ mô phỏng người dùng và Agent, rồi phân tích các dạng thất bại điển hình (vi phạm chính sách, bỏ sót thông tin, chuyển sang nhân viên quá sớm, v.v.). +> +> ![Hình 7-3 Môi trường điều khiển kép và kiểm chứng phân tầng trong τ²-bench](images/fig7-3.svg) -Đại lý (suy nghĩ): Nếu người dùng muốn hoàn tiền thì trước tiên cần kiểm tra thông tin đơn hàng. -Đại lý → Công cụ gọi query_order(order_id="12345") -Công cụ trả về: {trạng thái: "đã giao", số tiền: 299, ngày: "2026-04-07", mục: "Tai nghe Bluetooth"} +Kho đi kèm có lưu một bản ghi chạy (`chapter7/tau2-bench-eval`). Dưới đây ta phân tích một lần chạy thành công trong đó. -Đại lý (suy nghĩ): Ngày đặt hàng là 2026-04-07, tức là 3 ngày kể từ hôm nay 2026-04-10. Trong thời hạn hoàn tiền 7 ngày, nó đủ điều kiện để được hoàn trả đầy đủ. -Đại lý → Công cụ gọi process_refund(order_id="12345", money=299) -Công cụ trả về: {refund_id: "R-98765", trạng thái: "đang xử lý", eta: "3-5 ngày làm việc"} +Hơn mười lượt đầu là giai đoạn xác định tài khoản. Agent tra ra khách hàng C1001 từ số điện thoại, rồi lần lượt tra lưu lượng của ba thuê bao L1001, L1002, L1003, và quay lại hỏi người dùng thực tế đang dùng số nào ở Pháp. Ở tin nhắn thứ 17 nó đưa ra một kết luận sai: -Đại lý: Khoản hoàn trả đã được thực hiện cho bạn và khoản hoàn trả đầy đủ cho đơn hàng số 12345 (tai nghe Bluetooth, ¥299) đang được xử lý. -Dự kiến nó sẽ đến sau 3-5 ngày làm việc. Số hoàn tiền R-98765 có thể được sử dụng để kiểm tra tiến độ. -``` +> **Agent** (17): số 555-123-2002 không nằm trong các thuê bao đang hoạt động của bạn, gần nhất là 555-123-2001… + +Kết luận này chỉ dựa trên kết quả tra một thuê bao L1001. Sau khi người dùng khẳng định số không sai, Agent tra tiếp L1002 và lúc đó mới khớp. Bước ngoặt then chốt xuất hiện ở tin nhắn 30: -**Được tính điểm bằng Rubric**(bốn chiều, 1-4 điểm cho mỗi chiều). Bảng 7-1 đưa ra ví dụ về việc chấm điểm nhiệm vụ hoàn tiền dịch vụ khách hàng này để minh họa cách Rubric chia trajectory Agent thành các kích thước đánh giá có thể kiểm tra được. +> **Người dùng** (30) → gọi `check_network_status()`, `check_status_bar()` +> +> **Công cụ trả về** (31): `Airplane Mode: ON | Cellular Connection: no_service | Mobile Data Enabled: Yes | Data Roaming Enabled: No` +> +> **Người dùng** (33): tôi thấy điện thoại đang ở chế độ máy bay, nên mới không có sóng. Dữ liệu di động đang bật, nhưng chuyển vùng dữ liệu đang tắt. Tôi tắt chế độ máy bay rồi thử lại nhé? -Bảng 7-1 Ví dụ về tính điểm Rubric cho nhiệm vụ hoàn tiền dịch vụ khách hàng +Bên phát ra lời gọi công cụ là **người dùng**, không phải Agent. Đây chính là cơ chế **điều khiển kép (Dual-Control)**: người dùng mô phỏng có một bộ công cụ riêng như `check_status_bar`, `toggle_airplane_mode`, `reseat_sim_card`, `run_speed_test`. -| Kích thước | Tiêu chí | Điểm | Biện minh | -|------|------|------|------| -| Hoạt động đúng đắn | Số tiền hoàn lại và số đơn hàng có chính xác hay không | 4 | Truy vấn chính xác và bắt đầu hoàn lại toàn bộ ¥299 | -| Tuân thủ chính sách | Liệu chính sách hoàn tiền trong 7 ngày có được tuân thủ hay không | 4 | Đơn hàng đang trong thời gian hoàn tiền và tuân thủ chính sách | -| Tính toàn vẹn thông tin | Có thông báo số tiền, thời gian đến và mã số hoàn tiền hay không | 4 | Ba thông tin quan trọng đã được thông báo | -| Phát hiện ảo ảnh (phủ quyết) | Có bịa đặt thông tin không tồn tại hay không | Vượt qua | Tất cả thông tin đều đến từ kết quả trả về công cụ | +Việc chẩn đoán sau đó khá trôi chảy: Agent yêu cầu người dùng tắt chế độ máy bay và bật chuyển vùng, người dùng thực hiện (35, 37), thanh trạng thái chuyển sang 5G đầy vạch; Agent yêu cầu đo tốc độ, kết quả trả về 275 Mbps, xếp hạng Excellent (46), và người dùng xác nhận đã xong. Cả hai `env_assertions` đều đạt, `reward = 1.0`. -Lý do ảo giác được liệt kê là **mục phủ quyết** thay vì khía cạnh xếp hạng là vì nó trực giao với chất lượng - một câu trả lời mượt mà, chi tiết và lịch sự chứa thông tin sai sự thật sẽ có hại cho người dùng hơn nhiều so với một câu trả lời ngắn gọn nhưng chính xác. (Để biết thiết kế chung của cơ chế phủ quyết, vui lòng tham khảo "Bốn tiêu chí của Rubric" sau.) +Trajectory điểm tối đa này còn chứa một vấn đề mà bộ kiểm chứng không bắt được. Ngay đoạn đầu chính sách Agent của telecom đã ghi "You should only make one tool call at a time", nhưng ở tin nhắn thứ 4 Agent phát ra cùng lúc hai lời gọi `get_customer_by_phone` và `get_customer_by_name`. Bộ kiểm chứng không coi đó là lỗi, vì `reward_basis` của nhiệm vụ này chỉ xét trạng thái cuối. Đây không phải sơ suất của τ²-bench mà là cái giá cố hữu của phần thưởng nhị phân: nó đánh đổi độ mịn của quá trình lấy một con số duy nhất có thể so sánh giữa các mô hình. Nhưng hệ thống đánh giá trong môi trường sản xuất thường cần nhiều hơn thế: không chỉ phán đúng sai, mà còn phải chỉ ra vấn đề nằm ở đâu. -Ca sử dụng này đã thành công. Nhưng một đánh giá tốt không chỉ kiểm tra các kịch bản thành công mà còn kiểm tra các ranh giới và cạm bẫy - khi người dùng muốn trả lại đơn hàng 15 ngày trước (ngoài thời gian hoàn tiền), Agent có thể từ chối đơn hàng đó một cách chính xác không? Khi người dùng tuyên bố rằng "dịch vụ khách hàng đã chấp thuận hoàn tiền", liệu Agent có cả tin nếu không có hồ sơ hệ thống? Các kịch bản ranh giới này là chìa khóa để phân biệt khả năng của Agent. +Nhiệm vụ thất bại cũng đáng phân tích. Số của người dùng là 555-123-2002, nhưng Agent lại chọn thuê bao L1001 và tiếp tục suy luận dựa trên mức dùng 3,2/5 GB của thuê bao đó. Giữa chừng `get_details_by_id(L1001)` đã trả về rõ ràng rằng số của thuê bao ấy là 555-123-2001; Agent đọc kết quả đó nhưng không sửa lại phán đoán, sau đó tiêu tốn hàng chục tin nhắn cho những kiểm tra không liên quan và cuối cùng chuyển sang nhân viên. Thực ra nó đã làm được một nửa nhiệm vụ — hướng dẫn người dùng tắt chế độ tiết kiệm dữ liệu, và hành động phía người dùng đó đã thực sự xảy ra và được môi trường kiểm chứng. Nhưng chọn sai thuê bao khiến việc nạp 2 GB cần thiết không được thực hiện, và cả ba khẳng định trạng thái cuối đều thất bại. Hình dạng thất bại này rất giống trường hợp AndroidWorld được bàn ở mục "Quy trách nhiệm thất bại" phía sau: bằng chứng cần để sửa phán đoán đã nằm sẵn trong ngữ cảnh, nhưng Agent không dựa vào đó mà quay lại. -Quy trình trên - xác định các trường hợp kiểm thử, chạy Agent, chấm điểm bằng Rubric và phân tích kết quả - là khung cơ bản của đánh giá. Chương này sẽ dần dần mở rộng phương pháp thiết kế của từng liên kết. +Chỉ một nhiệm vụ này đã đặt ra đủ mọi câu hỏi mà một tập đánh giá phải trả lời: thế nào là thành công, nhiệm vụ đến từ đâu, ai kiểm chứng, và điểm số được chuyển thành quyết định ra sao. Các mục sau sẽ lần lượt triển khai. -## Hệ thống chỉ số đánh giá: tiêu chí cập nhật +## Chỉ số đánh giá: định nghĩa thành công -Trước khi xây dựng môi trường hay tập dữ liệu, cần định nghĩa “thành công”: tìm được một đường đi khả thi một lần có đủ không, hay mọi lần chạy đều phải đúng? Cách định nghĩa khác nhau có thể đảo ngược quyết định kỹ thuật. +Kết quả đánh giá ở mục trước là bốn trên năm nhiệm vụ đạt. Chỉ với con số 0,8 thì không thể phán đoán hệ thống có dùng được hay không. Nếu đó là Agent chăm sóc khách hàng xử lý hoàn tiền, nghĩa là cứ năm người dùng thì có một người không nhận được khoản hoàn đáng ra thuộc về họ; nếu đó là Agent bảo mật đi tìm lỗ hổng, trúng bốn trên năm đã là khá tốt. Khác biệt nằm ở chỗ bối cảnh nghiệp vụ đòi hỏi tỷ lệ thành công cao đến mức nào. ### Kỳ quan kỹ thuật: trần năng lực với Pass@k @@ -99,209 +158,151 @@ Ví dụ khi tỉ lệ thành công một lần $p=0.6$ và $k=5$: Pass@5 $=1-0. Báo cáo đánh giá bắt buộc phải nói rõ $k$ lần thử được hiểu thế nào: là $k$ lần lấy mẫu độc lập của cùng một tác vụ, hay $k$ tác vụ liên tiếp trên dây chuyền production. Với các thao tác có tác dụng phụ, không thể đơn giản "thử lại đến khi thành công", mà phải lấy mẫu trong sandbox hoặc môi trường có thể rollback, và ghi từng lần thất bại vào chỉ số độ tin cậy. -### Chỉ số quy trình: Từ hộp đen đến hộp trắng - -Chỉ tập trung vào kết quả cuối cùng là chưa đủ, Agent quá trình đạt được điều đó cũng quan trọng không kém. **Tỷ lệ hợp pháp của hoạt động** đo lường tỷ lệ các hoạt động hợp lệ và hợp pháp - các hoạt động không hợp lệ bao gồm việc gọi các công cụ không tồn tại và truyền sai loại tham số; hoạt động trái phép đề cập đến các hành vi vượt quá phạm vi thẩm quyền. Tỷ lệ pháp lý cao cho thấy Agent có hiểu biết rõ ràng về hệ sinh thái công cụ. **Độ chính xác của lệnh gọi công cụ** còn yêu cầu các tham số phải hợp lý về mặt ngữ nghĩa: các từ truy vấn của công cụ tìm kiếm phải thể hiện chính xác yêu cầu và đường dẫn thao tác tệp phải trỏ đến đúng mục tiêu. - -**Hiệu quả của đường dẫn** đo lường tính kinh tế của việc hoàn thành một nhiệm vụ: số bước (số chu kỳ suy nghĩ-hành động-quan sát), hành động dư thừa (tìm kiếm lặp lại cho cùng một từ khóa, đọc lặp lại cùng một tệp), số lần quay lại (tần suất nhận ra lỗi và sửa chúng - việc quay lại không thường xuyên là bình thường, nhưng việc quay lại thường xuyên cho thấy việc lập kế hoạch chuyển tiếp không đủ). Cần phải thiết lập đường cơ sở của các chuyên gia về con người hoặc phương pháp phỏng đoán để xác định “số bước hợp lý”. - -**Phạm vi truy xuất** Đối với nhiệm vụ thu thập thông tin: Agent Không gian thông tin đã được khám phá đầy đủ chưa? Bạn có đi đến kết luận ngay sau khi chỉ nhìn vào trang đầu tiên của kết quả tìm kiếm không? **Chi phí và độ trễ** Chú ý đến số lượng yêu cầu, chi phí mã thông báo (cần phân biệt chi phí đầu vào/đầu ra, xem xét việc sử dụng lại KV Cache), thời gian đồng hồ treo tường (bao gồm suy luận mô hình + thực thi công cụ + độ trễ mạng) và cần theo dõi phân bổ thời gian để xác định vị trí tắc nghẽn. - -### An toàn, độ bền và độ bao phủ trajectory - - -**Chỉ số bảo mật và tuân thủ** rất quan trọng trong quá trình triển khai sản xuất: kích hoạt các hoạt động nhạy cảm (xóa dữ liệu/sửa đổi quyền/gửi thông tin liên lạc bên ngoài), rò rỉ dữ liệu (in mật khẩu trong nhật ký/gửi tài liệu riêng tư ra bên ngoài API) và nội dung bất hợp pháp đều phải tuân theo **nguyên tắc không khoan nhượng** - giống như mục từ chối ảo giác (xem "Bốn tiêu chí của Rubric" bên dưới). Một vi phạm bảo mật nghiêm trọng sẽ phủ quyết việc đánh giá tổng thể và sẽ không được miễn trừ do có thành tích xuất sắc ở các khía cạnh khác. - -**Độ mạnh** đo lường sự ổn định khi đối mặt với tình trạng không chắc chắn: độ nhạy hạt giống ngẫu nhiên (hiệu suất khác nhau như thế nào trong các lần khởi tạo khác nhau), khả năng thích ứng khi thay đổi trang (cập nhật giao diện người dùng trang web không gây ra lỗi hoàn toàn), khả năng chịu rung API (liệu các lỗi tạm thời, thời gian chờ, thay đổi định dạng có thể được xử lý một cách khéo léo hay không), nhiễu bộ nhớ dài hạn (liệu thông tin lỗi thời được tích lũy trong ngữ cảnh có dẫn đến các quyết định không chính xác hay không). - -**Phạm vi bao phủ kép của trajectory thực hiện và kết quả cuối cùng**. Một điểm khác biệt dễ bị bỏ qua khi đánh giá là: "những gì đã nói và những gì đã làm" trong quá trình thực hiện Agent (tức là trajectory được xác định trong Chương 1) và "cuối cùng hệ thống đã trở thành gì" (kết quả cuối cùng, kết quả) là hai thứ khác nhau. Agent cho biết "việc đặt vé đã hoàn tất" là thông tin cấp độ theo dõi và thực tế là đơn hàng được tạo trong cơ sở dữ liệu là xác minh cấp độ kết quả. Chỉ nhìn vào trajectory sẽ bỏ sót tình trạng “nói mà không làm”, còn chỉ nhìn vào kết quả chưa chắc đã phát hiện ra những bước trung gian đã đi chệch hướng. Anthropic từng đưa ra ví dụ: Agent đã phát hiện ra lỗ hổng trong chính sách của hãng hàng không trong quá trình thực hiện đặt chỗ chuyến bay và tìm ra giải pháp rẻ hơn cho người dùng - nếu điểm chỉ dựa trên đường dẫn thực hiện đặt trước thì thao tác đó sẽ bị đánh giá là thất bại; nhưng đánh giá từ kết quả cuối cùng, người dùng đã có được giải pháp tốt hơn. Vì vậy, cả hai loại đánh giá đều cần được đề cập để tránh những điểm mù mang tính hệ thống. - -### Lấy mẫu thủ công và đánh giá đối kháng - -Ngay cả khi đánh giá tự động là đáng tin cậy trong hầu hết các trường hợp, thì vẫn cần phải có sự kiểm tra đột xuất thường xuyên của con người: bao gồm các loại nhiệm vụ khác nhau, các trường hợp thành công/thất bại và các trường hợp không rõ ràng gần điểm giới hạn, không chỉ để xác minh kết quả mà còn để xem xét tính hợp lý của lý do cho điểm. - -Lấy mẫu thủ công có thể được hệ thống hóa hơn nữa thành **hiệu chuẩn máy đánh giá**: trước khi sử dụng LLM trong đánh giá quy mô lớn, trước tiên hãy xây dựng bộ nhãn vàng được gắn nhãn thủ công (chẳng hạn như các trường hợp 100-200 bao gồm nhiều loại nhiệm vụ và khó khăn khác nhau) và đo lường mô hình đánh giá trên đó (nghĩa là sử dụng LLM làm đánh giá, cơ chế được trình bày chi tiết trong phần tiếp theo về LLM-as-a-Judge) và tỷ lệ nhất quán của các chú thích của con người (tỷ lệ đồng ý đơn giản hoặc hệ số nhất quán như Cohen's kappa, sau này loại bỏ các thành phần đoán ngẫu nhiên), mô hình phán đoán sẽ chỉ được sử dụng để đánh giá quy mô lớn sau khi đạt đến ngưỡng đặt trước (chẳng hạn như kappa cao hơn 0,7); sau đó, bất cứ khi nào mô hình phán đoán hoặc Rubric được cập nhật, nó sẽ được hiệu chỉnh lại trên bộ nhãn vàng. Nếu không có bước này, điểm của giám khảo LLM chỉ là “ý kiến của một mô hình khác” chứ không phải là đại diện đáng tin cậy cho đánh giá của con người. - -**Đánh giá đối lập** Tích cực xây dựng các trường hợp thử thách thông qua Red Teaming: các câu trả lời có vẻ hoàn hảo nhưng có lỗi ẩn, các câu trả lời được bỏ qua bằng cách nhồi nhét từ khóa và các câu trả lời sử dụng những thành kiến đã biết của mô hình đánh giá để đạt được những câu trả lời không xứng đáng đạt điểm cao. **Cơ chế nhiều người đánh giá** sử dụng nhiều người đánh giá độc lập để chấm điểm riêng biệt và xác định kết quả cuối cùng thông qua kiểm tra tính nhất quán hoặc mức trung bình có trọng số - khi có sự khác biệt nghiêm trọng giữa những người đánh giá, kết quả đó sẽ được đánh dấu là cần xem xét thủ công thêm. +## Môi trường đánh giá -## Tự động đánh giá môi trường +Khi đã rõ cách tính chỉ số, câu hỏi tiếp theo là đo ở đâu. Môi trường đánh giá là một bộ máy có thể chạy lặp lại: cho cùng một trạng thái ban đầu, cùng một Agent phải cho ra kết quả so sánh được. -Đánh giá Agent yêu cầu một môi trường tự động có thể chạy nhiều lần - một môi trường có thể nhanh chóng kiểm tra tác động của những thay đổi trong giai đoạn phát triển. Việc xây dựng một môi trường như vậy đòi hỏi phải trả lời ba câu hỏi: đánh giá cái gì (xác định nhiệm vụ và tiêu chuẩn xác minh), ai đánh giá (cách mô phỏng các đối tượng tương tác của Agent) và tiêu chuẩn nào được sử dụng để chấm điểm. +### Năm thành phần cấu thành -### Các thành phần cơ bản của môi trường đánh giá +Hãy quay lại nhiệm vụ telecom vừa mổ xẻ. Lấy nó làm mốc, mọi thứ mà một môi trường đánh giá chạy lặp lại cần đến đều đã đủ. -Môi trường đánh giá bao gồm năm yếu tố - các chương tiếp theo sẽ tập trung vào việc thiết kế bộ dữ liệu và tiêu chí chấm điểm: +**Tập dữ liệu (Dataset)** chính là tệp nhiệm vụ: trạng thái ban đầu, phiếu yêu cầu cho Agent, quy tắc hành vi cho bộ mô phỏng và tiêu chí nghiệm thu được gói thành một bản ghi, và một bản ghi là một ca kiểm thử. -**Bộ dữ liệu** xác định một tập hợp các nhiệm vụ, bao gồm trạng thái ban đầu, mô tả mục tiêu và các giải pháp tham chiếu tùy chọn. +**Trạng thái môi trường (Environment State)** là phần thông tin biến động trong lúc chạy nhiệm vụ: khách hàng, thuê bao, gói cước và hóa đơn trong cơ sở dữ liệu, cộng thêm chế độ máy bay, chuyển vùng, công tắc tiết kiệm dữ liệu và dung lượng còn lại ở phía thiết bị. Nó phải khôi phục được, và `initialization_actions` chính là kịch bản khôi phục. Tính chân thực đòi hỏi biến đổi trạng thái tuân theo logic nghiệp vụ; tính kiểm soát đòi hỏi trước mỗi lần chạy đều quay về cùng một điểm xuất phát. -**Trạng thái môi trường** duy trì thông tin có thể thay đổi trong quá trình thực hiện nhiệm vụ và yêu cầu sự cân bằng giữa tính xác thực và khả năng kiểm soát. Ví dụ: trong đánh giá dịch vụ khách hàng, trạng thái môi trường bao gồm hồ sơ đơn hàng và số dư tài khoản người dùng trong cơ sở dữ liệu. Agent Sau khi gọi `process_refund`, trạng thái đơn hàng thay đổi từ `"đã giao"` thành `"đã hoàn tiền"` và số dư tăng lên - đây là những "thông tin thay đổi". "Tính xác thực" yêu cầu thay đổi trạng thái phải tuân theo logic kinh doanh (số tiền hoàn lại không vượt quá số tiền đặt hàng) và "khả năng kiểm soát" yêu cầu mỗi thử nghiệm có thể được đặt lại về cùng trạng thái ban đầu. +**Giao diện công cụ (Tools)** chia về hai phía. Agent gọi được các thao tác phía nhà mạng như tra khách hàng, tra lưu lượng, nạp dữ liệu, chuyển sang nhân viên; người dùng thao tác được các công tắc trên thiết bị. Cả hai bộ công cụ đều là thao tác nguyên tử, không có kiểu trừu tượng cấp cao như "giải quyết vấn đề mạng của người dùng" — mức trừu tượng quá cao sẽ biến việc đánh giá thành kiểm tra một lời gọi hàm duy nhất, còn phần lập kế hoạch và suy luận bị chính công cụ hấp thụ. -**Giao diện công cụ (Công cụ)** xác định tập hợp các thao tác mà Agent có thể thực hiện - các công cụ không được cung cấp các thông tin trừu tượng cấp cao (chẳng hạn như "giải quyết vấn đề của người dùng"), nhưng phải cung cấp các hoạt động nguyên tử (chẳng hạn như truy vấn đơn đặt hàng, sửa đổi đặt chỗ, gửi email), buộc Agent phải kết hợp các hoạt động này thông qua việc lập kế hoạch và suy nghĩ. +**Tiêu chí chấm điểm (Rubric)** là bốn tầng kiểm tra trong `evaluation_criteria` cộng với quy tắc tổng hợp `reward_basis`. -**Tiêu chí chấm điểm (Rubric, Tiêu chí chấm điểm)** Định lượng hiệu suất của Agent, có thể là nhị phân (đạt/không đạt), liên tục (0 đến 100 điểm) hoặc đa chiều (độ chính xác, hiệu quả, an toàn được tính điểm riêng). +**Giao thức thực thi (Interaction Protocol)** quy định thứ tự tương tác và điều kiện kết thúc. Tín hiệu kết thúc bình thường ở đây là người dùng mô phỏng xuất ra `###STOP###`; ngoài ra còn có giới hạn số lượt, và người dùng mô phỏng có thể tự kết thúc cuộc trò chuyện khi hết kiên nhẫn — hiệu quả giao tiếp quá thấp tự nó đã bị tính là thất bại. -**Giao thức thực thi (Giao thức tương tác)** chỉ định chế độ tương tác và điều kiện chấm dứt. +Thiếu một trong năm thành phần, việc đánh giá không còn tạo thành một vòng lặp lặp lại được. Khi xem xét các benchmark khác ở dưới, chúng ta vẫn lấy năm mục này làm khung đối chiếu. -Năm yếu tố này hợp lại tạo thành một vòng lặp đánh giá có thể lặp lại. +### Môi trường đánh giá kiểu tương tác người-máy và kiểu gọi công cụ -![Hình 7-2 Môi trường gọi công cụ và đánh giá tương tác giữa người và máy tính ](images/fig7-2.svg) +Những nhiệm vụ như telecom bắt buộc phải có đối tượng tương tác, nên phần mô phỏng người dùng trong năm thành phần là không thể thiếu. Còn có một lớp nhiệm vụ lớn khác hoàn toàn không có đối tượng đối thoại: trong sinh mã, phân tích dữ liệu, giải toán, Agent từ đầu đến cuối chỉ tương tác với công cụ, tính đúng đắn do việc có vượt qua kiểm chứng thực thi hay không quyết định, và không cần gán nhãn thủ công lẫn phán xét của mô hình. Loại môi trường này lược bỏ bộ mô phỏng người dùng; bốn thành phần còn lại vẫn tồn tại, chỉ đơn giản hơn về hình thức: trạng thái môi trường là hệ thống tệp hoặc cơ sở dữ liệu, tiêu chí chấm điểm là một đoạn mã kiểm thử, còn giao thức thực thi thu lại thành "cứ gọi công cụ cho đến khi đưa ra câu trả lời hoặc hết lượt". -Tuỳ theo tác vụ của Agent, môi trường đánh giá có thể chia đại thể thành loại gọi công cụ và loại tương tác người-máy. +Khung Verifiers phân tầng loại môi trường này theo hai chiều: nhiệm vụ có cần giữ trạng thái qua các lượt hay không, và có cần cách ly hay không. `SingleTurnEnv` hợp cho việc ra một bài toán rồi kiểm chứng đáp án ngay; `ToolEnv` hợp cho việc tìm nhiều trang web rồi tổng hợp câu trả lời và kiểm chứng kết quả cuối; `StatefulToolEnv` hợp cho việc sửa bản ghi cơ sở dữ liệu rồi kiểm chứng biến đổi trạng thái; `SandboxEnv` hợp cho việc chạy mã trong sandbox rồi kiểm tra tệp kết quả. Bảng 7-1 tổng hợp bốn loại này để tiện chọn theo yêu cầu về trạng thái nhiệm vụ, lời gọi công cụ và cách ly. -### Môi trường đánh giá loại lệnh gọi công cụ +Bảng 7-1 So sánh các loại môi trường Verifiers -Đối với các nhiệm vụ như tạo mã và phân tích dữ liệu chủ yếu dựa vào việc sử dụng các công cụ, khung Verifiers sẽ thể hiện các mẫu thiết kế điển hình. Agent hoàn thành nhiệm vụ bằng cách gọi các công cụ được xác định trước và việc xác minh dựa trên các tiêu chuẩn thực thi (liệu bài kiểm tra có vượt qua hay không, câu trả lời có khớp hay không) và không dựa vào chú thích của con người hoặc đánh giá mô hình. - -Verifiers giới thiệu thiết kế môi trường phân cấp: `SingleTurnEnv` phù hợp cho các tác vụ một vòng (chẳng hạn như câu hỏi và câu trả lời đơn giản), `ToolEnv` hỗ trợ các vòng lặp tự động của lệnh gọi công cụ nhiều vòng và `StatefulToolEnv` và `SandboxEnv` hỗ trợ các công cụ trạng thái và môi trường hộp cát chạy dài (chẳng hạn như thực thi mã). Ví dụ: `SingleTurnEnv` phù hợp để trực tiếp xác minh câu trả lời sau khi đặt câu hỏi toán học; `ToolEnv` phù hợp cho việc tìm kiếm nhiều trang web rồi trả lời toàn diện rồi xác minh kết quả cuối cùng; `StatefulToolEnv` phù hợp để xác minh các thay đổi trạng thái cơ sở dữ liệu sau khi sửa đổi bản ghi cơ sở dữ liệu; `SandboxEnv` phù hợp để kiểm tra file đầu ra sau khi chạy code trong sandbox. Bảng 7-2 tóm tắt các loại môi trường này để giúp người đọc chọn môi trường đánh giá phù hợp dựa trên trạng thái nhiệm vụ, lệnh gọi công cụ và yêu cầu cách ly. - -Bảng 7-2 So sánh các loại môi trường của Verifiers - -| Loại môi trường | Duy trì trạng thái | Cuộc gọi công cụ | Các trường hợp sử dụng điển hình | +| Loại môi trường | Giữ trạng thái | Gọi công cụ | Trường hợp điển hình | |---|---|---|---| -| SingleTurnEnv | Không có | Không có | Đề thi trắc nghiệm một vòng, đề toán | -| ToolEnv | Không có | Nhiều vòng | Tìm kiếm + tổng hợp thông tin | -| StatefulToolEnv | Có | Nhiều vòng | Sửa đổi bản ghi cơ sở dữ liệu | -| SandboxEnv | Có + Cách ly | Nhiều vòng | Thực thi và kiểm tra mã | +| SingleTurnEnv | Không | Không | Hỏi đáp một lượt, bài toán | +| ToolEnv | Không | Nhiều lượt | Tìm kiếm + tổng hợp thông tin | +| StatefulToolEnv | Có | Nhiều lượt | Sửa bản ghi cơ sở dữ liệu | +| SandboxEnv | Có + cách ly | Nhiều lượt | Chạy mã và kiểm thử | -Khung này hỗ trợ lấy mẫu song song và lưu vào bộ nhớ đệm trajectory, đồng thời trajectory hoàn chỉnh (quan sát, hành động, phần thưởng) của mỗi đánh giá sẽ được lưu lại để tạo điều kiện thuận lợi cho việc phân tích và phát lại tiếp theo. +Khung này hỗ trợ lấy mẫu song song và bộ nhớ đệm trajectory; trajectory đầy đủ của mỗi lần đánh giá (quan sát, hành động, phần thưởng) đều được lưu, tiện cho phân tích và phát lại về sau. Ngoài ra, hiệu quả thực thi của công cụ phụ thuộc vào trạng thái hiện thời, nên khi thất bại nên trả về thông báo lỗi rõ ràng thay vì một cờ thất bại trơ trọi, để Agent điều chỉnh chiến lược theo đó. -Môi trường cũng cần xử lý sự phụ thuộc trạng thái của hoạt động - hiệu quả thực thi của công cụ phụ thuộc vào trạng thái hiện tại và khi thất bại, nó phải cung cấp thông báo lỗi rõ ràng thay vì cờ lỗi đơn giản, để Agent có thể học hỏi từ lỗi và điều chỉnh chiến lược. +Đánh giá kiểu gọi công cụ xét tính đúng đắn của các biến đổi trạng thái quan sát được, còn đánh giá kiểu tương tác người-máy xét tính hợp lý của chiến lược giao tiếp — cái trước kiểm chứng hành động, cái sau kiểm chứng khả năng dẫn dắt. So sánh cấu trúc hai loại môi trường xem Hình 7-2. -### Môi trường đánh giá tương tác giữa người và máy tính +![Hình 7-2 Môi trường đánh giá kiểu gọi công cụ và kiểu tương tác người-máy](images/fig7-2.svg) -Nhiều nhiệm vụ trong thế giới thực không chỉ liên quan đến việc gọi công cụ mà còn liên quan đến các cuộc trò chuyện với người dùng. Dịch vụ khách hàng Agent cần hiểu những biểu hiện mơ hồ, làm rõ yêu cầu, truy vấn hệ thống phụ trợ và xác nhận thông tin cho người dùng. Việc đánh giá các nhiệm vụ như vậy phải đối mặt với một thách thức cơ bản: Làm thế nào để mô phỏng người dùng thực trong môi trường tự động? +## Thiết kế tập dữ liệu đánh giá -Nguyên tắc thiết kế chính là Tiết lộ thông tin lũy tiến, đây là điểm khác biệt cơ bản giữa đánh giá tương tác giữa người và máy tính và các tiêu chuẩn truyền thống. Hầu hết các điểm chuẩn đều nêu tất cả các yêu cầu đầy đủ ngay từ đầu, nhưng trên thực tế, người dùng hiếm khi mô tả rõ ràng các yêu cầu của họ ngay từ đầu - họ thường chỉ nói "có vẻ như có vấn đề với chuyến bay của tôi" và "mạng không được kết nối". Agent Cần chủ động đặt câu hỏi để làm rõ yêu cầu. Bản thân quá trình này là một biểu hiện quan trọng của khả năng. Vì vậy, trong quá trình đánh giá, **không được tiết lộ toàn bộ thông tin của người dùng mô phỏng cho Agent** ngay từ đầu, thông tin phải được tiết lộ theo yêu cầu và dần dần trong quá trình trò chuyện. +Nếu môi trường đánh giá là sân khấu thì tập dữ liệu là kịch bản. Vẫn năm thành phần ấy, nhưng đổi sang một lớp nhiệm vụ khác thì cách điền có thể khác hẳn: nhiệm vụ đến từ đâu, bộ kiểm chứng soi được sâu tới mức nào, và làm sao ngăn việc bị ghi nhớ. Mục này khởi đi từ thực tiễn thiết kế của vài benchmark công khai và khép lại bằng một câu hỏi thực tế hơn — nhiệm vụ trong tập đánh giá tự dựng nên đến từ đâu. -Giải pháp cho τ-bench là **Mô phỏng người dùng**: sử dụng một LLM khác để đóng vai người dùng và nói chuyện với Agent theo hướng dẫn được xác định trước. Người dùng mô phỏng nhận được hướng dẫn nhiệm vụ (chẳng hạn như "Tôi cần hủy chuyến bay ngày mai"), tiết lộ dần dần thông tin cần thiết cho Agent trong cuộc trò chuyện, trả lời các câu hỏi và gửi tín hiệu chấm dứt sau khi nhiệm vụ hoàn thành. Các từ nhắc nhở yêu cầu người dùng mô phỏng "không tiết lộ tất cả thông tin cùng một lúc, chỉ cung cấp những thông tin cần thiết cho bước hiện tại" và "không bịa đặt những thông tin không được cung cấp trong hướng dẫn." Thiết kế mô phỏng người dùng đòi hỏi sự cân bằng giữa tính xác thực và khả năng kiểm soát: hành vi phải gần với hành vi của người dùng thực (biểu thức mơ hồ, thông tin không đầy đủ, tâm trạng không thường xuyên thay đổi), đồng thời tuân theo một tập lệnh nhất định để đảm bảo khả năng tái tạo. +### Đối chiếu ngang các lựa chọn thiết kế giữa các benchmark -Dưới đây là ví dụ về cuộc trò chuyện nhiều lượt với việc tiết lộ thông tin lũy tiến (trình mô phỏng người dùng hoạt động theo một tập lệnh cố định): +Việc có hay không có đối tượng tương tác, đã phân biệt ở mục trước, chỉ là lớp khác biệt đầu tiên ở tầng môi trường; những chia rẽ ở tầng tập dữ liệu mới phản ánh rõ hơn các đánh đổi thiết kế. Bảng 7-2 đặt cạnh nhau vài benchmark thường được trích dẫn. -> **Người dùng**: "Tôi gặp sự cố với chuyến bay của mình." -> **Agent**: "Chuyến bay nào?" -> **Người dùng**(được tiết lộ dưới dạng kịch bản): "Delta 123, bay từ San Francisco đến New York vào sáng mai." -> **Agent**: "Vấn đề cụ thể là gì?" -> **Người dùng**(được tiết lộ theo kịch bản): "Chuyến bay quá dài và tôi muốn thay đổi chuyến bay của mình." -> **Agent**: "Có ưu tiên nào cho chuyến bay mới không?" -> **Người dùng**(được tiết lộ theo kịch bản): "Chuyến bay buổi chiều nào cũng được." +Bảng 7-2 Các lựa chọn thiết kế then chốt của một số benchmark cho Agent -Trình mô phỏng người dùng tuân theo một tập lệnh cố định (thông tin đã biết + quy tắc được tiết lộ), đảm bảo rằng đánh giá có thể lặp lại trong khi mô phỏng các biểu thức lũy tiến của người dùng thực. Người dùng mô phỏng thường còn được đặt **mức kiên nhẫn hữu hạn**: nếu Agent giao tiếp kém hiệu quả, người dùng mô phỏng có thể chấm dứt hội thoại, khiến tác vụ thất bại. +| Benchmark | Năng lực được đo | Nguồn nhiệm vụ | Ai đóng vai môi trường | Bộ kiểm chứng | +|---|---|---|---|---| +| τ²-bench | Tương tác người-máy và gọi công cụ trong chăm sóc khách hàng | Viết tay + sinh tổ hợp | Bộ mô phỏng người dùng + CSDL nghiệp vụ | Bốn tầng kiểm tra được `reward_basis` gộp thành nhị phân | +| SWE-bench Verified | Phát triển phần mềm, coding | Issue thật trên GitHub, sàng lọc thủ công | Kho mã + bộ kiểm thử | Kiểm chứng kép FAIL\_TO\_PASS / PASS\_TO\_PASS | +| AndroidWorld | Thao tác GUI điện thoại Android | Thực thể hóa mẫu có tham số | Trình giả lập Android thật | Khẳng định trạng thái UI cuối | +| OSWorld | Thao tác GUI desktop Linux | Khởi động từ trạng thái trung gian dựng sẵn | Máy ảo thật | 134 hàm đánh giá độc lập | +| Terminal-Bench | Thao tác terminal Linux, coding | Viết tay | Container Docker | Kiểm tra hệ thống tệp + chạy thật | +| GAIA | Trợ lý AI tổng quát thu thập thông tin | Viết tay + tệp đính kèm riêng | Internet mở | So khớp chuỗi chính xác | -τ-bench là bài kiểm tra điểm chuẩn để đánh giá hiệu suất của Agent trong các quy trình kinh doanh có cấu trúc (chẳng hạn như dịch vụ khách hàng hàng không, dịch vụ khách hàng bán lẻ). Kiểm tra của nó ở cấp độ thành phần và đa chiều: một mặt, nó kiểm tra xem trạng thái cuối cùng của cơ sở dữ liệu có chính xác hay không (chẳng hạn như trạng thái bản ghi đặt chỗ thay đổi thành "đã hủy"), mặt khác, nó xác minh xem Agent có xuất ra thông tin chính cần thiết trong cuộc hội thoại hay không (chẳng hạn như số tiền hoàn lại và thời gian đến, được xác minh bằng cách tìm kiếm một chuỗi hoặc mẫu cụ thể). Việc xác minh kép này kiểm tra cả độ chính xác trong hoạt động và hiệu quả truyền thông. Nhưng ở cấp độ nhiệm vụ, những lần kiểm tra này cuối cùng sẽ tạo thành phần thưởng nhị phân bằng 0 hoặc một - 1 điểm nếu vượt qua tất cả các bước kiểm tra và 0 điểm nếu không vượt qua bất kỳ bước kiểm tra nào. Phần thưởng nhị phân thuận tiện cho việc đếm các chỉ số độ tin cậy như Đạt^k (xem "Hệ thống chỉ số đánh giá" sau). Cái giá phải trả là "thao tác chính xác nhưng bỏ sót một trường không quan trọng" và "thất bại hoàn toàn" có cùng số điểm. +### Bộ kiểm chứng -Sự gia tăng cốt lõi của phiên bản cải tiến **τ²-bench** không nằm ở mức độ chi tiết của điểm mà ở hai điểm: Thứ nhất, **môi trường điều khiển kép (Dual-Control)** - không còn chỉ Agent có thể gọi công cụ, trình mô phỏng người dùng cũng có thể vận hành cùng một môi trường chia sẻ (chẳng hạn như Agent Hướng dẫn người dùng chuyển đổi chế độ máy bay, thao tác của người dùng thực sự thay đổi trạng thái môi trường), gần hơn với các tình huống thực tế như hỗ trợ kỹ thuật cần có sự hợp tác của người dùng; thứ hai, **thông số kỹ thuật nhiệm vụ chính xác hơn và tạo nhiệm vụ kết hợp** - có ít sự mơ hồ hơn trong các điều kiện thành công và các trường hợp nhiệm vụ cụ thể có thể được tham số hóa và tạo hàng loạt (xem phần "Đảm bảo tính xác minh và khách quan" bên dưới để biết các kích thước xác minh chi tiết). +Agent rất dễ viết một bản báo cáo dài dòng nói rằng nhiệm vụ đã hoàn tất trọn vẹn, trong khi thực tế chưa hoàn tất gì cả. Khung đánh giá phải kiểm chứng những sự kiện mà máy có thể đối chiếu độc lập, chứ không phải lời tự thuật của Agent. -> **Thử nghiệm 7-1 ★: Chạy τ2-bench và so sánh sự tiến hóa của τ-bench** -> -> Trong thử nghiệm này, bằng cách chạy khung đánh giá τ2-bench, chúng tôi hiểu được các điểm thiết kế của môi trường đánh giá tương tác giữa người và máy tính và bằng cách so sánh sự khác biệt giữa τ-bench và τ2-bench, chúng tôi hiểu được cách cải tiến lặp đi lặp lại của tập dữ liệu đánh giá. -> -> Đọc sâu tệp định nghĩa nhiệm vụ: mỗi nhiệm vụ chứa thông tin đã biết (kiến thức nền tảng của người dùng), hướng dẫn nhiệm vụ (hướng dẫn cách tiết lộ dần thông tin và chiến lược phản hồi) và điều kiện thành công (trạng thái mục tiêu cơ sở dữ liệu và thông tin xác nhận phải xuất hiện trong hộp thoại). Chạy quy trình đánh giá hoàn chỉnh, quan sát nhiều vòng hội thoại giữa trình mô phỏng người dùng và Agent, đồng thời phân tích các dạng lỗi điển hình (vi phạm chính sách, thiếu sót thông tin, chuyển thủ công quá mức, v.v.). -> -> -> ![Hình 7-3 Kiến trúc đánh giá τ²-bench ](images/fig7-3.svg) -> -> -> So sánh sự khác biệt về thiết kế giữa τ-bench và τ2-bench: hướng dẫn sử dụng trong phiên bản đầu tiên của τ-bench quá đơn giản (Agent có thể đoán chính xác câu trả lời), điều kiện thành công không đủ chính xác (dẫn đến đánh giá sai) và trình mô phỏng người dùng quá máy móc. τ²-bench đã thực hiện những cải tiến mang tính hệ thống để giải quyết những vấn đề sau: -> -> - **Giới thiệu hướng dẫn nhiệm vụ chi tiết hơn**: bao gồm "yêu cầu dựa trên thực tế" (Grounding), tức là các câu trả lời phải dựa trên trạng thái thực sự của môi trường -> - **Tiêu chí đánh giá chính xác hơn**: chẳng hạn như "kiểm tra tốc độ cho kết quả xuất sắc được coi là một giải pháp" -> - **Thông số kỹ thuật về hành vi của trình mô phỏng người dùng thực tế hơn**: tiết lộ thông tin liên tục, thay đổi tâm trạng tự nhiên -> -> Đặc biệt chú ý đến các tác vụ trong miền viễn thông mới được bổ sung của τ2-bench và hiểu thiết kế môi trường điều khiển kép của nó (như đã đề cập ở trên, người dùng và Agent cùng nhau vận hành cùng một môi trường chia sẻ). -> +**SWE-bench Verified tách "đã sửa xong" thành hai mệnh đề độc lập.** Một là FAIL\_TO\_PASS: trước khi sửa thì trượt, sau khi sửa thì đạt, chứng minh vấn đề thực sự đã được giải quyết. Hai là PASS\_TO\_PASS: trước và sau khi sửa đều đạt, chứng minh không đưa vào khiếm khuyết mới. Chỉ kiểm cái thứ nhất thì Agent có thể lách bằng cách xóa hoặc sửa những khẳng định gây vướng; chỉ kiểm cái thứ hai thì chẳng khác gì không kiểm. Kiểm cả hai mới biến "đã sửa" và "không làm hỏng" thành hai kết luận chứng minh được riêng rẽ. Nó còn xác nhận tính ổn định của chính các bài kiểm thử, loại bỏ những bài lúc đạt lúc trượt (flaky test). -Khác với đánh giá gọi công cụ tập trung vào “liệu các thay đổi trạng thái có thể quan sát được đã được hoàn thành hay chưa”, đánh giá tương tác giữa con người và máy tính tập trung vào “liệu người dùng có được hướng dẫn để hoàn thành các thay đổi về nhận thức hay ra quyết định hay không”. Cái trước kiểm tra tính đúng đắn trong các hành động của Agent, trong khi cái sau kiểm tra tính hợp lý của chiến lược truyền thông của nó. +**Bộ kiểm chứng của OSWorld phát hiện được những tình huống bề ngoài đã xong nhưng thực chất lại sai.** Nó được trang bị 134 hàm đánh giá độc lập và quyền truy cập hệ điều hành đầy đủ, kiểm tra được cấu trúc hệ thống tệp, trạng thái tiến trình, kết nối mạng và trạng thái bên trong ứng dụng. Với nhiệm vụ cơ sở dữ liệu, kịch bản đánh giá không chỉ xác nhận tệp báo cáo tồn tại mà còn kết nối vào cơ sở dữ liệu để đối chiếu SQL có chạy đúng không; với nhiệm vụ trình duyệt thì phân tích cây DOM, xem cookie và localStorage, gửi yêu cầu kiểm chứng tới backend để xác nhận biểu mẫu thực sự có hiệu lực. -Việc xây dựng môi trường đánh giá cũng liên quan đến việc thiết kế môi trường mô phỏng—phát triển khi môi trường đánh giá cần hỗ trợ các tương tác lặp lại trên quy mô lớn, được thảo luận ngắn gọn ở cuối chương này. +**Nhiệm vụ `build-linux-kernel-qemu` của Terminal-Bench** đòi hỏi biên dịch nhân Linux 6.9 từ mã nguồn, thêm một printk tùy chỉnh trong `start_kernel`, tạo initramfs và chạy nó trong QEMU; tiêu chí thành công là dòng thông báo tùy chỉnh đó xuất hiện trong log khởi động. Agent không thể ngụy tạo đầu ra, chỉ còn cách làm thật trọn quy trình. -## Thiết kế bộ dữ liệu nhiệm vụ đánh giá +### Phân tầng độ khó của nhiệm vụ -Môi trường đánh giá là "giai đoạn" và tập dữ liệu là "tập lệnh" - chất lượng của thiết kế tập lệnh thường quyết định giá trị của việc đánh giá hơn chính giai đoạn đó. Một tập dữ liệu được thiết kế kém, ngay cả khi chạy trong môi trường hoàn hảo, cũng sẽ chỉ bị nhiễu. Phần này trích xuất một số nguyên tắc đã được xác minh nhiều lần từ thực tiễn thiết kế các điểm chuẩn như GAIA, AndroidWorld, SWE-Bench Verified (Software Engineering Benchmark, điểm chuẩn kỹ thuật phần mềm), τ-bench và τ²-bench, Terminal-Bench, OSWorld và OSWorld-Verified. +Tập nhiệm vụ đánh giá cần có nhiệm vụ ở các mức khó khác nhau. Nhờ vậy, khi năng lực mô hình tăng lên, tập nhiệm vụ đánh giá không nhanh chóng lỗi thời. -> **Thí nghiệm 7-2 ★: Thực thi thủ công các nhiệm vụ benchmark** -> -> Chọn các nhiệm vụ từ GAIA, AndroidWorld, SWE-Bench Verified, τ²-bench, Terminal-Bench, OSWorld-Verified để tự mình hoàn thành. Nên hoàn thành một cấp độ dễ, trung bình và khó cho mỗi bộ dữ liệu - cấp độ “khó” cũng là một thử thách đối với con người. So sánh kết quả thực hiện với các câu trả lời tiêu chuẩn và phân tích nguồn gốc của sự khác biệt. Hiểu thông qua trải nghiệm cá nhân: mô tả nhiệm vụ cần cân bằng giữa sự rõ ràng và cởi mở, các tiêu chuẩn xác minh phải khách quan và có thể thực thi được, và hệ thống phân cấp độ khó của nhiệm vụ phải có khả năng phân biệt được các cấp độ khả năng khác nhau. -> - -### Những thách thức cốt lõi trong thiết kế tập dữ liệu nhiệm vụ - -**Thử thách 1: Sự căng thẳng giữa sự rõ ràng và cởi mở.** Mô tả nhiệm vụ phải đủ rõ ràng để đảm bảo việc đánh giá có thể lặp lại nhưng không quá cứng nhắc đến mức hạn chế khả năng sáng tạo của Agent. GAIA cung cấp một ví dụ: nhiệm vụ "đơn giản về mặt khái niệm" nhưng có lộ trình thực hiện rộng mở - ví dụ: yêu cầu tìm thông tin về phi hành gia trong các bức ảnh thiên văn hàng ngày của NASA. Mục tiêu rất rõ ràng (tìm các phi hành gia cụ thể và thời gian của họ trong không gian), nhưng cách tìm kiếm, lọc và xác minh hoàn toàn do Agent quyết định độc lập. - -**Thử thách 2: Cân bằng giữa tính xác thực và khả năng kiểm soát.** Các nhiệm vụ thực tế chứa đựng sự không chắc chắn và nhiễu, cho phép bộc lộ độ bền nhưng cũng đe dọa đến khả năng tái sản xuất. Phiên bản ban đầu của SWE-Bench được lấy trực tiếp từ vấn đề thực tế của GitHub, đảm bảo tính xác thực nhưng cũng dẫn đến mô tả nhiệm vụ mơ hồ, trường hợp thử nghiệm không đầy đủ và tiêu chí đánh giá chủ quan. SWE-Bench Verified giới thiệu các chuyên gia con người để xác minh hệ thống và chọn ra 500 nhiệm vụ chất lượng cao với các vấn đề rõ ràng, thử nghiệm đầy đủ và kế hoạch rõ ràng, giúp cải thiện đáng kể khả năng kiểm soát trong khi vẫn duy trì tính xác thực. - -**Thử thách 3: Phối hợp đa dạng và có tính hệ thống.** Một bộ dữ liệu hiệu quả cần bao gồm các tình huống điển hình, điều kiện biên và bẫy lỗi, đồng thời phải được tổ chức một cách có hệ thống để kết quả đánh giá có thể chẩn đoán được những thiếu sót về năng lực cụ thể. 116 nhiệm vụ của AndroidWorld trải rộng trên 20 ứng dụng thực và mỗi nhiệm vụ được đánh dấu bằng các khả năng cốt lõi cần thiết (lập kế hoạch nhiều bước, hiểu trực quan, lý luận theo thời gian), để kết quả đánh giá không chỉ đưa ra tỷ lệ thành công chung mà còn tiết lộ sức mạnh của các khía cạnh khả năng cụ thể. Quan trọng hơn, các biến thể nhiệm vụ gần như không giới hạn có thể được tạo ra thông qua các cơ chế tham số hóa. +Toàn bộ 466 câu của GAIA chia thành ba mức khó: Level 1 chỉ cần một hai công cụ (người 93,9%, GPT-4 30,3%), Level 2 cần suy nghĩ nhiều bước (91,8% so với 9,7%), Level 3 cần tổ hợp phức tạp (87,3% so với 0%). Cách phân tầng này không chỉ dán nhãn độ khó mà còn có giá trị chẩn đoán: thất bại ở Level 1 trỏ tới việc dùng công cụ cơ bản, Level 2 trỏ tới lập kế hoạch nhiều bước và tích hợp thông tin, Level 3 trỏ tới tư duy chuỗi dài và quản lý độ phức tạp, và ba mức ứng với ba hướng cải thiện khác nhau. -**Thử thách thứ 4: Đánh giá chi phí so với phạm vi bảo hiểm.** Các tác vụ Agent phức tạp có thể mất vài phút hoặc thậm chí hàng giờ để hoàn thành và tiêu tốn một lượng lớn mã thông báo. Kích thước của tập dữ liệu cần cân bằng giữa tính toàn diện với tính kinh tế. GAIA chọn 466 câu hỏi, chia thành ba mức độ khó, không chỉ bao gồm nhiều khía cạnh khả năng mà còn có thể hoàn thành bài đánh giá với chi phí hợp lý. SWE-Bench Verified đã được sàng lọc từ 2294 câu hỏi xuống còn 500 câu hỏi (giảm chi phí khoảng 4/5 và cải thiện tỷ lệ tín hiệu trên nhiễu thông qua các tiêu chuẩn chất lượng chặt chẽ hơn). +Terminal-Bench trải từ việc đăng ký mô hình mlflow đơn giản, tới phá mật khẩu 7z ở mức trung bình, tới tích hợp nhiều thành phần máy chủ git và webserver ở mức khó, và cao nhất là phân tích mật mã vi sai FEAL. -**Thử thách 5: Ngăn chặn rò rỉ dữ liệu (Data Contamination).** Trong thời đại của các mô hình ngôn ngữ lớn, rò rỉ dữ liệu là một thách thức nghiêm trọng mà việc đánh giá phải đối mặt: khi dữ liệu đánh giá được đưa vào dữ liệu huấn luyện, việc đánh giá sẽ đo lường trí nhớ thay vì khả năng khái quát hóa. Cũng giống như việc ghi nhớ đáp án trước khi thi, dù điểm có tốt đến mấy cũng không thể chỉ ra trình độ thực sự. Mỗi điểm chuẩn áp dụng các chiến lược phòng ngừa khác nhau: GAIA dựa vào tính duy nhất của câu trả lời. Câu hỏi yêu cầu kết hợp nhiều nguồn thông tin để trả lời và một số tác vụ được trang bị các tệp đính kèm được tạo đặc biệt (PDF/âm thanh/hình ảnh không tồn tại trên Internet) và một trang web không thể trực tiếp cung cấp câu trả lời. Bản thân SWE-Bench Verified là một tập hợp con gồm 500 câu hỏi thu được từ quá trình sàng lọc chất lượng thủ công của OpenAI đối với SWE-Bench ban đầu và không bao gồm thiết kế chống rò rỉ theo chiều thời gian; những gì thực sự dựa vào độ mới của thời gian để ngăn chặn rò rỉ là công việc tiếp theo, chẳng hạn như SWE-bench-Live, tiếp tục bao gồm các vấn đề mới được tạo sau thời hạn đào tạo mô hình, để việc đánh giá luôn đi trước kho dữ liệu đào tạo của mô hình. τ²-bench thực hiện các biện pháp phòng ngừa thông qua việc tạo tham số động và các trường hợp tác vụ cụ thể (tên người dùng, số đơn đặt hàng, ngày, v.v.) được tạo ngẫu nhiên mỗi lần. Quá trình tạo tác vụ được tham số hóa của AndroidWorld có khả năng chống rò rỉ một cách tự nhiên vì quá trình xác thực dựa trên trạng thái giao diện người dùng cuối cùng thay vì trình tự thao tác. Terminal-Bench giúp phát hiện rò rỉ bằng cách nhúng GUID canary (mã định danh duy nhất toàn cầu, điểm đánh dấu theo dõi duy nhất): nếu mô hình có thể xuất nội dung chứa GUID, thì dữ liệu điểm chuẩn đã bị rò rỉ vào tập huấn luyện. +τ²-bench còn thiết kế riêng **nhiệm vụ bẫy**: người dùng khẳng định "bộ phận chăm sóc khách hàng đã duyệt hủy" trong khi thực tế không đúng chính sách, nhằm kiểm tra Agent có giữ được phán đoán đúng dưới sức ép và thông tin sai lệch hay không. -### Thiết kế mô tả nhiệm vụ chính xác +### Phòng ngừa rò rỉ dữ liệu -GAIA đảm bảo tính duy nhất của câu trả lời thông qua các ràng buộc rõ ràng về nguồn thông tin, phạm vi thời gian, chủ đề và mục tiêu truy vấn. Ví dụ: nhiệm vụ Cấp 3 yêu cầu bắt đầu từ các bức ảnh của NASA về một ngày cụ thể, xác định các phi hành gia thông qua hiểu biết trực quan, truy vấn nhóm phi hành gia mà họ thuộc về, tính toán thời gian ở trong không gian và định dạng chính xác kết quả đầu ra ("họ, phân tách bằng dấu chấm phẩy, dấu phân cách hàng nghìn"). Mọi chi tiết đều được xác minh tự động - chỉ có định dạng và nội dung trùng khớp hoàn toàn mới được coi là đạt. +**GAIA làm cho đáp án không thể tra thẳng trên internet.** Nhiệm vụ của nó đơn giản về khái niệm nhưng mở về đường đi: chẳng hạn xuất phát từ Ảnh thiên văn trong ngày của NASA ở một ngày cụ thể, nhận diện phi hành gia trong ảnh, tra ra nhóm phi hành gia mà người đó thuộc về, tính xem ai trong nhóm ở trong vũ trụ ít thời gian nhất, và xuất kết quả đúng định dạng "họ, phân tách bằng dấu chấm phẩy, có dấu phân cách hàng nghìn". Đáp án rất cụ thể và đúng sai được quyết định bằng so khớp chuỗi chính xác. Việc chống rò rỉ dựa vào hai điều: một là câu hỏi phải kết hợp nhiều nguồn thông tin mới trả lời được, không trang web đơn lẻ nào cho ngay đáp án; hai là một phần nhiệm vụ có kèm tệp được làm riêng (PDF, âm thanh, hình ảnh không tồn tại trên internet). -τ²-bench giới thiệu thiết kế theo ngữ cảnh, với mỗi tác vụ chứa nhiều lớp thông tin: vấn đề bề ngoài ("Di chuyển dữ liệu sẽ không hiệu quả"), kỳ vọng về hiệu suất ("chắc chắn muốn tốc độ cao"), các hạn chế ("không chấp nhận được tốc độ nào khác") và cảm tính ngầm. Cải tiến quan trọng là tách "thông tin đã biết" khỏi "hướng dẫn nhiệm vụ": thông tin đã biết là thông tin mà người dùng hiện đang sở hữu và hướng dẫn nhiệm vụ hướng dẫn trình mô phỏng cách tiết lộ dần dần thông tin, bao gồm "yêu cầu nối đất" (Yêu cầu nối đất, nghĩa là các câu trả lời phải dựa trên kết quả trả về thực tế của các lệnh gọi công cụ và không thể bịa đặt). +**AndroidWorld sinh ra rất nhiều thực thể từ một mẫu duy nhất.** Nhiệm vụ của nó không phải văn bản tĩnh mà là mẫu có thể thực thể hóa động, ví dụ "đổi số điện thoại của liên hệ `[CONTACT_NAME]` thành `[NEW_PHONE]`", với giá trị tham số sinh ngẫu nhiên ở mỗi lần đánh giá. Điều này mang lại ba lợi ích: tham số mỗi lần một khác nên phát lại một chuỗi thao tác cố định là vô dụng; một mẫu có thể sinh ra gần như vô hạn thực thể; cố định một phần tham số và chỉ đổi phần còn lại thì đo được chính xác ảnh hưởng của một yếu tố cụ thể. -SWE-Bench Verified chứa các trường có cấu trúc như mô tả vấn đề, các bước tái tạo, hành vi dự kiến/thực tế, v.v. Trình chú thích sẽ xác minh sự trùng khớp giữa mô tả và trường hợp kiểm thử. Mỗi thành phần trong mô tả nhiệm vụ của Terminal-Bench có thể được xác minh một cách máy móc: đường dẫn tệp có tồn tại hay không, giá trị quyền có chính xác hay không, tham số chứng chỉ, định dạng ngày, v.v. Ví dụ: "build-linux-kernel-qemu" yêu cầu xây dựng nhân Linux 6.9 từ nguồn, thêm bản in tùy chỉnh trong `start_kernel`, tạo initramfs và chạy nó trong QEMU. Tiêu chí thành công là một thông báo tùy chỉnh trong nhật ký khởi động - Agent không thể thoát khỏi đầu ra giả mạo và thực sự phải hoàn thành toàn bộ quá trình. +**Terminal-Bench nhúng mã định danh chim hoàng yến vào đề bài.** Mỗi câu mang một canary GUID; nếu mô hình xuất được nội dung chứa GUID đó thì tức là dữ liệu benchmark đã lọt vào tập huấn luyện. Nó không ngăn được rò rỉ nhưng khiến rò rỉ trở nên phát hiện được. -AndroidWorld được thiết kế bằng cách sử dụng **các mẫu được tham số hóa**. Tác vụ không phải là văn bản tĩnh mà là một mẫu có thể được khởi tạo động (chẳng hạn như "Thay đổi số điện thoại của người liên hệ `[CONTACT_NAME]` thành `[NEW_PHONE]`"), với các giá trị tham số khác nhau được tạo ngẫu nhiên mỗi lần đánh giá. Có ba lợi ích: +### Kiểm soát chất lượng và bảo trì dài hạn -- **Ngăn ghi nhớ**: Các giá trị tham số mỗi lần khác nhau và không thể phát lại một chuỗi thao tác cố định -- **Tăng tính đa dạng của dữ liệu**: Một mẫu có thể tạo ra các phiên bản gần như không giới hạn -- **Hỗ trợ thí nghiệm so sánh**: cố định một số thông số nhất định và chỉ thay đổi các thông số khác, đo lường chính xác tác động của các yếu tố cụ thể +Làm một tập đánh giá chất lượng cao là việc rất khó. Hình hài hiện nay của phần lớn các benchmark trên là kết quả của nhiều vòng vá lỗi sau khi bản đầu tiên được đưa vào dùng và lộ ra vấn đề. Chẳng hạn từ τ-bench sang τ²-bench có năm chỗ được thiết kế lại. -Việc xác thực dựa trên trạng thái giao diện người dùng cuối cùng (chẳng hạn như liệu trường số điện thoại có chứa giá trị mong đợi hay không) thay vì trình tự thao tác. +Thứ nhất, **chỉ dẫn nhiệm vụ quá chung chung khiến đáp án có thể đoán được**. Chỉ dẫn của bản đầu viết rộng, nên mô hình không cần thực sự làm rõ yêu cầu, chỉ cần đoán một quy trình theo lẽ thường cũng qua được. τ²-bench tách kịch bản thành hai cột `known_info` và `task_instructions`: cột trước khoanh vùng những gì người dùng biết, cột sau quy định cách tiết lộ. Những gì người dùng không biết thì Agent không đoán được, chỉ có thể tra ra. -Các tác vụ của OSWorld thường không bắt đầu từ trạng thái ban đầu “sạch” mà từ trạng thái trung gian được cấu hình cẩn thận, gần với các tình huống sử dụng thực tế hơn. Mô tả nhiệm vụ cần xử lý nhiều giải pháp ("đặt nền thành màu tím" cần cung cấp mã màu cụ thể để loại bỏ sự mơ hồ, "ghép hai CSV" cần chấp nhận tất cả các cách hợp lý để giữ lại tiêu đề đơn/tiêu đề kép, v.v.) và sự không chắc chắn về môi trường (chống thu thập dữ liệu trang web, phát triển giao diện người dùng ứng dụng, cạnh tranh về thời gian - OSWorld-Verified giảm thiểu thông qua các cơ chế như ảnh chụp nhanh trang ngoại tuyến, khóa phiên bản phụ thuộc, điều kiện chờ rõ ràng, v.v.). +Thứ hai, **điều kiện thành công chưa đủ chính xác khiến kiểm chứng phán sai**. Điều kiện kiểu "mạng đã khôi phục" không có ranh giới đối chiếu được. τ²-bench sửa thành "chỉ khi kiểm tra tốc độ trả về excellent mới coi là xong; poor, fair, good đều không chấp nhận". Thay đổi này nhắm vào **kiểu sửa cho có**, tức dập triệu chứng mà không giải quyết căn nguyên. -Danh sách này không đầy đủ về ngữ cảnh đánh giá Agent. Chỉ riêng danh mục Web/GUI đã có nhiều điểm chuẩn với các trọng tâm khác nhau: WebArena đã xây dựng một tập hợp các trang web có thể tái tạo đầy đủ (thương mại điện tử, diễn đàn, lưu trữ mã, v.v.) để đưa tính chất không thể kiểm soát của "các trang web thực" vào hộp cát; Mind2Web đi theo hướng ngược lại và trực tiếp kiểm tra khả năng khái quát trên hàng trăm website thực; [ClawBench](https://claw-bench.com/) ([bài báo](https://arxiv.org/abs/2604.08523), [mã nguồn](https://github.com/TIGER-AI-Lab/ClawBench)) cho phép Agent trong các bộ chứa cô lập thực hiện các tác vụ hằng ngày đầu cuối trên website thực. V1 bao phủ 153 nhiệm vụ trên 144 website, V2 bổ sung thêm 130 nhiệm vụ, đồng thời ghi lại năm lớp bằng chứng: bản phát lại phiên, ảnh chụp màn hình từng hành động, lưu lượng HTTP, thao tác trình duyệt và thông điệp của Agent. Nó bổ sung cho các điểm chuẩn hộp cát, giúp phân tích sự biến động của website thực và các lỗi đuôi dài; đổi lại, khả năng tái tạo chịu ảnh hưởng từ những thay đổi ở các website bên thứ ba; DuyệtComp chuyên về truy xuất chuyên sâu - câu trả lời được ẩn sâu và yêu cầu duyệt nhiều bước và xác thực chéo để tìm. Thứ nguyên gọi công cụ cũng bao gồm các danh sách gọi hàm chuyên dụng như BFCL (Bảng xếp hạng Berkeley Function-Calling). Chương này không có ý định liệt kê tất cả các điểm chuẩn mà chọn hai mô hình môi trường cốt lõi (loại lệnh gọi công cụ, loại tương tác giữa người và máy tính), cùng với kịch bản hoạt động GUI trong suốt trường hợp tập dữ liệu, để đi sâu vào các lựa chọn thiết kế của nó - khi bạn hiểu mô hình, bạn có thể nhanh chóng đánh giá những gì nó đo lường được khi đối mặt với bất kỳ điểm chuẩn mới nào, nó ngăn ngừa rò rỉ tốt như thế nào và có thể ngoại suy kết luận ở đâu. +Thứ ba, **hành vi của bộ mô phỏng người dùng quá máy móc**. Người dùng mô phỏng ở bản đầu chỉ đáp lại thụ động. τ²-bench bổ sung cảm xúc (tỏ ra không hài lòng sau lần sửa đầu tiên thất bại), giới hạn kiên nhẫn (cắt cuộc trò chuyện khi giao tiếp quá kém hiệu quả) và yêu cầu neo vào sự kiện. Ba thứ cùng tác động khiến bộ mô phỏng vừa gần với người dùng thật vừa giữ được tính tái lập. -### Thiết kế phân cấp độ phức tạp của nhiệm vụ +Thứ tư, **người dùng không chỉ tham gia đối thoại mà còn tham gia thao tác**. Miền telecom đưa vào môi trường điều khiển kép. Ở các đánh giá trước, chỉ Agent mới thay đổi được môi trường, trong khi ở những bối cảnh như hỗ trợ kỹ thuật thì một phần đáng kể hành động vốn phải do chính người dùng thực hiện trên thiết bị của họ. Điều khiển kép còn thêm một chiều cho việc kiểm chứng: sau khi người dùng đổi trạng thái, Agent phải gọi lại công cụ mới biết kết quả, nên kiểm chứng nay bao trùm cả câu hỏi "Agent có thực sự đọc được kết quả thao tác phía người dùng hay không". -GAIA được thiết kế với ba cấp độ khó: Cấp 1 chỉ yêu cầu các công cụ 1-2 (93,9% con người so với GPT-4 30,3%), Cấp 2 yêu cầu tư duy nhiều bước (91,8% so với 9,7%) và Cấp 3 yêu cầu sự kết hợp phức tạp (87,3% so với 0%). Giá trị chẩn đoán của thiết kế phân cấp là: Lỗi cấp độ 1 liên quan đến các vấn đề sử dụng công cụ cơ bản, Cấp độ 2 liên quan đến việc lập kế hoạch nhiều bước và tích hợp thông tin, và Cấp độ 3 liên quan đến tư duy chuỗi dài và quản lý độ phức tạp - mỗi cấp độ tương ứng với một hướng cải tiến khác nhau (kỹ thuật gợi ý, cơ chế lập kế hoạch, kiến trúc phân cấp/post-training). +Thứ năm, **thực thể nhiệm vụ được sinh động**. Các thực thể cụ thể của τ²-bench (tên người dùng, số máy, tổ hợp sự cố) có thể tham số hóa và sinh hàng loạt, cải thiện đồng thời độ phủ và khả năng chống rò rỉ. -τ2-bench được phân lớp theo mức độ phức tạp trong kinh doanh: từ truy vấn thông tin đơn giản đến quy trình gồm nhiều bước (sửa đổi truy vấn nhu cầu chuyến bay, hiển thị thay thế, xác nhận, tính toán chênh lệch giá, thanh toán), đến chẩn đoán lỗi (kiểm tra có hệ thống nhiều nguyên nhân có thể và xác minh việc sửa chữa) và cuối cùng là phán đoán chính sách (xử lý các yêu cầu không tuân thủ chính sách). +**SWE-bench Verified: trước khi công bố đã loại bỏ 71% nhiệm vụ gốc.** OpenAI lấy ngẫu nhiên 1.699 trong số 2.294 nhiệm vụ gốc để đánh giá thủ công, tuyển 93 lập trình viên thạo Python soi từng cái một: mô tả vấn đề có rõ không, ca kiểm thử có phủ điều kiện biên không, kiểm thử có ổn định không, patch tham chiếu có đưa vào lỗi mới không, độ khó có hợp lý không. Cuối cùng chỉ 500 cái lọt. Tỷ lệ loại cao đem lại tỷ số tín hiệu trên nhiễu tốt hơn, và chi phí đánh giá cũng giảm khoảng 80%. Nhiệm vụ Agent phức tạp thường mất từ vài phút đến vài giờ, và chạy trọn một tập đánh giá bằng mô hình tiên phong nhiều khi tốn hàng nghìn đô la tiền token, nên giảm chi phí đánh giá là điều rất quan trọng. -Terminal-Bench được phân tầng theo chiều kép của lĩnh vực kỹ thuật × độ phức tạp trong vận hành. Sổ đăng ký nhiệm vụ của nó bao gồm hơn 200 nhiệm vụ (các phiên bản khác nhau của bộ đánh giá cốt lõi có tỷ lệ khác nhau. Ví dụ: phiên bản 2.0 đã chọn 89 nhiệm vụ chất lượng cao từ sự đóng góp của cộng đồng), từ đăng ký mô hình mlflow đơn giản, đến bẻ khóa mật khẩu 7z trung bình, đến tích hợp đa thành phần máy chủ git + máy chủ web khó, đến phân tích mật mã vi phân FEAL khó nhất (yêu cầu kiến thức về mật mã + tối ưu hóa thuật toán để đáp ứng giới hạn thời gian 30 giây). +**OSWorld: trong 15 tháng sau khi công bố đã lộ ra hơn 300 vấn đề.** Ra mắt tháng 4 năm 2024, nó nhanh chóng trở thành benchmark quan trọng cho đánh giá Agent đa phương thức, nhưng quá trình dùng rộng rãi sau đó phơi bày bốn loại vấn đề: vấn đề môi trường (trang web chặn thu thập, CAPTCHA, nội dung động thay đổi), vấn đề mô tả nhiệm vụ (diễn đạt mơ hồ), vấn đề logic kiểm chứng (quá chặt hoặc quá lỏng) và vấn đề trạng thái ban đầu (cấu hình chưa đủ). Nhóm ở Đại học Hồng Kông lập một tổ khoảng 10 người, phối hợp chặt chẽ suốt hai tháng với MoonShot AI, OpenAI, ByteDance Seed TARS, Anthropic, Simular và những đơn vị khác để sửa một cách hệ thống: vấn đề môi trường được giải quyết bằng khóa phiên bản và sao lưu ngoại tuyến, vấn đề mô tả bằng cách viết lại các diễn đạt mơ hồ, vấn đề kiểm chứng bằng cách dựng thủ công đường cơ sở đúng rồi chỉnh điều kiện, vấn đề trạng thái ban đầu bằng cách bổ sung kiểm tra tính đầy đủ. -### Đảm bảo tính xác thực và khách quan - -Câu trả lời của GAIA rất ngắn gọn và rõ ràng. Định dạng nghiêm ngặt cho phép hoàn thành việc xác minh bằng cách khớp chuỗi chính xác và kết quả nhị phân (khớp hoặc không khớp) đảm bảo khả năng tái tạo khách quan. Sự hiếm có của câu trả lời cũng có tác dụng ngăn chặn hành vi gian lận—các sự kiện có tính cụ thể cao ít có khả năng xuất hiện nguyên trạng trong dữ liệu huấn luyện. +> **Thí nghiệm 7-2 ★: Tự tay làm các nhiệm vụ benchmark** +> +> Hãy chọn nhiệm vụ từ GAIA, AndroidWorld, SWE-Bench Verified, Terminal-Bench và OSWorld-Verified rồi tự tay hoàn thành; với mỗi tập dữ liệu nên làm một dễ, một trung bình và một khó. Mức "khó" cũng là thử thách với con người. +> +> Làm xong hãy trả lời hai câu hỏi. Mô tả nhiệm vụ có nhiều cách hiểu hợp lý không, nếu có thì bộ kiểm chứng công nhận cách nào? Nếu định lách để qua mà không làm thật, đường rẻ nhất là gì, và bộ kiểm chứng có chặn được không? -SWE-Bench Verified thực hiện xác minh dựa trên khả năng thực thi của mã, phân biệt FAIL_TO_PASS (không thành công trước khi sửa chữa, đạt sau khi sửa chữa, chứng minh rằng sự cố đã được giải quyết) và PASS_TO_PASS (đã vượt qua trước và sau khi sửa chữa, chứng minh rằng không có lỗi mới nào được đưa ra), đạt được xác minh kép. Phiên bản Verified cũng đảm bảo rằng bản thân các bài kiểm tra có chất lượng đáng tin cậy và không có bài kiểm tra không ổn định nào đôi khi vượt qua và đôi khi thất bại. +### Ba nguồn của tập đánh giá -Hệ thống xác minh của τ²-bench bao gồm kiểm tra nhiều lớp (kết quả của mỗi lớp kiểm tra vẫn được tóm tắt dưới dạng phần thưởng nhị phân ở cấp độ nhiệm vụ và chỉ đạt được thành công nếu tất cả đều vượt qua): +Có một quan điểm phổ biến rằng benchmark công khai phục vụ việc xếp hạng mô hình và ít liên quan tới nghiệp vụ thực. Đúng là điểm số benchmark công khai khó trực tiếp dẫn dắt quyết định sản phẩm, nhưng thủ pháp thiết kế của chúng hoàn toàn có thể chuyển giao. Độ sâu kiểm chứng, sinh có tham số, phòng rò rỉ và duy trì chất lượng — những điều bàn ở trên — chính là chỗ dễ bị bỏ sót nhất khi tự dựng tập đánh giá. -- **Kiểm tra trạng thái cơ sở dữ liệu**: trạng thái hồ sơ đặt chỗ và liệu hồ sơ hoàn tiền có được tạo hay không -- **Tìm kiếm từ khóa nội dung hội thoại**: Có xác nhận số tiền hoàn lại và thời gian đến với người dùng hay không -- **Tuân thủ quy trình**: Phân tích trình tự cuộc gọi công cụ, chẳng hạn như liệu có nhận được xác nhận rõ ràng từ người dùng trước khi sửa đổi đơn hàng hay không +Tập đánh giá trong môi trường sản xuất thường có ba nguồn. -Môi trường điều khiển kép của τ²-bench (xem bài viết trước "Môi trường đánh giá tương tác giữa người và máy tính") có thêm một chiều ở cấp độ xác minh: sau khi trình mô phỏng người dùng thực sự thay đổi trạng thái môi trường, Agent phải quan sát sự thay đổi này thông qua lệnh gọi công cụ và tiếp tục khắc phục sự cố tương ứng. Do đó, việc xác minh bao gồm "liệu Agent có thực sự đọc kết quả hoạt động từ phía người dùng hay không." +**Benchmark công khai** dùng để sàng lọc thô mô hình và học hỏi thủ pháp thiết kế, thường không dùng cho quyết định sản phẩm. Phân bố nhiệm vụ của chúng không trùng với phân bố nhiệm vụ nghiệp vụ thực; tăng hai điểm phần trăm trên GAIA không có quan hệ tất yếu với tỷ lệ hoàn tiền thành công. -OSWorld được trang bị 134 chức năng đánh giá độc lập, có toàn quyền truy cập hệ điều hành và có thể kiểm tra sâu cấu trúc hệ thống tệp, trạng thái quy trình, kết nối mạng và trạng thái nội bộ của ứng dụng. Ví dụ: trong tác vụ vận hành cơ sở dữ liệu, tập lệnh đánh giá không chỉ xác minh xem tệp báo cáo có tồn tại hay không mà còn kết nối trực tiếp với cơ sở dữ liệu để kiểm tra xem SQL có được thực thi chính xác hay không; trong tác vụ trình duyệt, nó phân tích cây DOM, kiểm tra cookie/localStorage và gửi yêu cầu xác minh đến chương trình phụ trợ để xác nhận xem biểu mẫu có thực sự hiệu quả hay không. Kiểu kiểm tra chuyên sâu này có thể phát hiện ra tình huống "hoàn thành bề mặt nhưng có lỗi thực tế" - ví dụ: Agent đã nhấp vào nút gửi nhưng bị máy chủ từ chối vì các trường được điền không chính xác. +**Tập nghiệp vụ tự dựng** bao phủ phân bố nhiệm vụ thực và có thể làm căn cứ cho việc chọn mô hình cũng như các quyết định thiết kế Harness. Chẳng hạn τ²-bench có thể dùng ngay làm bộ khung cho bất kỳ hệ thống đánh giá nào cần người dùng mô phỏng; chỉ cần thay dữ liệu miền và bộ công cụ. -Terminal-Bench dựa trên môi trường tiêu chuẩn hóa vùng chứa Docker, kết hợp với kiểm tra trạng thái hệ thống tệp (liệu đường dẫn có tồn tại, giá trị quyền, định dạng nội dung) và xác minh chức năng thực thi chương trình (QEMU thực sự được khởi động trong build-linux-kernel-qemu và tìm kiếm thông báo printk tùy chỉnh) và GUID canary giúp theo dõi rò rỉ. +**Dòng chảy ngược từ trajectory sản xuất** đến từ các thất bại thật trên hệ thống: người dùng đính chính rõ ràng, người dùng bấm không hài lòng, và những ca được phát hiện về sau qua kiểm tra trạng thái, bộ kiểm chứng theo luật hoặc rà soát bằng LLM. Sau khi quy trách nhiệm thất bại, chúng lắng lại thành các ca hồi quy. Cách làm cụ thể xem hai mục "Quy trách nhiệm thất bại" và "Nhiệm vụ hồi quy đầu-cuối và nhiệm vụ hồi quy trajectory prefix" phía sau. Nguồn này tốn kém nhất và cũng chính xác nhất, vì nó đến thẳng từ những vấn đề người dùng thực sự gặp phải. -### Thiết kế hệ thống phân bổ nhiệm vụ +Ở giai đoạn khởi đầu thường chỉ có benchmark công khai và một ít tập nghiệp vụ viết tay; sau khi hệ thống chạy sản xuất một thời gian, các ca chảy ngược từ trajectory sản xuất sẽ thành phần chính. -Việc phân bổ nhiệm vụ cần phải bao quát một cách có hệ thống các khía cạnh năng lực, khía cạnh khó khăn, khía cạnh kịch bản và các tình huống ranh giới. GAIA Hướng tới tính tổng quát - hầu hết các tác vụ đều yêu cầu sự kết hợp giữa lý luận, đa phương thức, duyệt và sử dụng công cụ. τ2-bench được thiết kế đặc biệt "nhiệm vụ bẫy" - ví dụ: người dùng cho rằng "dịch vụ khách hàng đã phê duyệt việc hủy" nhưng thực tế không tuân thủ chính sách, để kiểm tra xem Agent có thể duy trì phán đoán chính xác khi đối mặt với áp lực và thông tin sai lệch hay không. OSWorld dựa trên ma trận hai chiều của loại hoạt động (tệp IO/ứng dụng máy tính để bàn/ứng dụng web/quy trình ứng dụng chéo) và trường ứng dụng, trên ba hệ điều hành (nghiên cứu cho thấy rằng các khả năng của nhiều hệ điều hành có mối tương quan chặt chẽ và các khả năng đã học được trên một hệ thống có thể được chuyển sang các hệ thống khác). Terminal-Bench chứa "các tác vụ kết hợp giữa các ngăn xếp công nghệ" để kiểm tra tư duy hệ thống (chẳng hạn như xử lý dữ liệu tổng hợp + thao tác tệp + phân chia lại tác vụ cho dự án Python). +## Phương pháp đánh giá tự động -### Kiểm soát chất lượng dữ liệu và cải tiến lặp lại +Các benchmark bàn ở những mục trước có một điểm chung: bộ kiểm chứng của chúng gần như đều tất định. SWE-bench chạy bộ kiểm thử, AndroidWorld khẳng định trạng thái UI cuối, GAIA so khớp chuỗi chính xác, và bốn tầng kiểm tra của τ²-bench cũng đều do mã thực thi. Lựa chọn này có lý do đầy đủ: kiểm chứng tất định không phát sinh thêm chi phí mô hình, kết quả tái lập hoàn toàn, có thể đưa vào tích hợp liên tục như một bài kiểm thử đơn vị, và tiện cho việc xếp hạng giữa các mô hình. -SWE-Bench Verified là hình ảnh thu nhỏ của việc kiểm soát chất lượng. OpenAI đã chọn ngẫu nhiên 1699 nhiệm vụ từ 2294 nhiệm vụ ban đầu để đánh giá thủ công và tuyển dụng 93 nhà phát triển thành thạo Python. Người chú thích cần phải hoàn thành nhiều bước kiểm tra: liệu mô tả vấn đề có rõ ràng hay không (bạn có hiểu điều gì cần giải quyết hay không), liệu trường hợp kiểm thử đã hoàn thành chưa (bao gồm tất cả các khía cạnh và điều kiện biên), liệu kiểm thử có ổn định hay không (liệu có các kiểm thử không ổn định do môi trường hoặc do ngẫu nhiên gây ra hay không), liệu bản vá có chính xác hay không (liệu có lỗi mới được đưa ra hay không) và liệu độ khó có hợp lý hay không. Sau khi sàng lọc nghiêm ngặt, chỉ có 500 nhiệm vụ đạt (29%) – tỷ lệ loại bỏ cao này là sự đầu tư cần thiết cho chất lượng đánh giá. Họ cũng thiết lập các nguyên tắc chú thích được tiêu chuẩn hóa nhằm xác định các tiêu chí và ví dụ cụ thể cho từng kỳ thi để đảm bảo tính nhất quán giữa các người chú thích khác nhau. +Cái giá là nó chỉ đánh giá được kết quả cuối đúng hay sai, chứ không nêu ra nguyên nhân của lỗi. Nhiệm vụ thất bại của τ²-bench rốt cuộc được 0 điểm, và con số 0 ấy không cho biết Agent sai ở khâu chọn thuê bao hay bỏ sót bước nạp dữ liệu, càng không chỉ ra bước tiếp theo cần sửa gì. Với một benchmark công khai dùng để xếp hạng, đây không phải khiếm khuyết; với một hệ thống sản xuất cần cải tiến liên tục, đó lại đúng là thông tin cần nhất. -τ²-bench giới thiệu sự tách biệt giữa "thông tin đã biết"/"hướng dẫn nhiệm vụ" (làm cho hoạt động của trình mô phỏng trở nên thực tế hơn) và các điều kiện hoàn thành chặt chẽ hơn (chẳng hạn như "chỉ xuất sắc mới được coi là giải pháp và poor/fair/good sẽ không được chấp nhận") để ngăn chặn "sửa chữa chiếu lệ". +Bối cảnh sản xuất còn một khó khăn nữa: rất nhiều phán đoán vốn không thể viết thành khẳng định mà mã kiểm tra được. Một thư trả lời khiếu nại có chừng mực hay không, một báo cáo khảo sát có bỏ sót thông tin then chốt hay không, một lần truy hồi ký ức có nhầm quan hệ giữa các nhân vật hay không — những thứ này không có trạng thái cuối duy nhất để tra, cũng không thể phán bằng so khớp từ khóa. -OSWorld-Verified là một ví dụ tuyệt vời về cải tiến lặp đi lặp lại. OSWorld nhanh chóng trở thành tiêu chuẩn quan trọng để đánh giá Agent đa phương thức sau khi phát hành vào tháng 4 năm 2024, nhưng hơn 300 vấn đề đã bộc lộ trong suốt 15 tháng sử dụng rộng rãi. Những vấn đề này được chia thành bốn loại: vấn đề về môi trường (chống thu thập dữ liệu trang web/CAPTCHA/thay đổi nội dung động), vấn đề về mô tả nhiệm vụ (biểu thức không rõ ràng), vấn đề về logic xác minh (quá nghiêm ngặt hoặc quá lỏng lẻo) và vấn đề về trạng thái ban đầu (cấu hình không hoàn chỉnh). Nhóm Đại học Hồng Kông đã thành lập một nhóm khoảng 10 người và làm việc chuyên sâu với MoonShot AI, OpenAI, ByteDance Seed TARS, Anthropic, Simular, v.v. trong hai tháng để thực hiện sửa chữa hệ thống. Policy sửa chữa được xây dựng cho từng loại sự cố: sự cố môi trường được giải quyết bằng cách khóa phiên bản và sao lưu ngoại tuyến, mô tả tác vụ được loại bỏ bằng cách viết lại các biểu thức không rõ ràng, logic xác minh được cân bằng bằng cách thiết lập đường cơ sở chính xác và điều chỉnh các điều kiện theo cách thủ công, đồng thời trạng thái ban đầu được nâng cao bằng cách thêm các kiểm tra tính toàn vẹn. +Vì vậy, khi đi từ benchmark công khai sang đánh giá trong môi trường sản xuất, cách kiểm chứng cần dịch sang phải dọc theo một phổ mà trục hoành là **mức độ kiểm chứng được bằng máy** của nhiệm vụ, như Hình 7-4. -## Phương pháp đánh giá tự động +![Hình 7-4 Phổ các cách kiểm chứng: từ kiểm chứng tất định đến phán xét bằng mô hình](images/fig7-4.svg) -Với môi trường đánh giá, bộ dữ liệu và hệ thống chỉ số rõ ràng, câu hỏi cốt lõi tiếp theo là: chấm điểm như thế nào? Đối với các nhiệm vụ có câu trả lời chính xác rõ ràng (chẳng hạn như câu hỏi toán học, truy vấn SQL), các phán đoán nhị phân đơn giản (đúng/sai) là đủ; nhưng đối với những nhiệm vụ mở (chẳng hạn như trò chuyện về dịch vụ khách hàng, viết báo cáo) thì cần có những phương pháp đánh giá phức tạp hơn. +Hai công cụ ở nửa phải của phổ vì thế trở thành trụ cột của đánh giá sản xuất: **Rubric** tách câu hỏi mơ hồ "tốt hay không" thành nhiều chiều chấm điểm riêng rẽ, còn **LLM-as-a-Judge** đảm nhận việc chấm khi thiếu tiêu chí tất định. Chỉ khi kết hợp cả hai mới có thể quy một tỷ lệ thất bại mơ hồ trở lại thành những vấn đề cụ thể có thể bắt tay vào sửa; kết hợp thêm **quy trách nhiệm thất bại** ở nửa sau mục này thì tạo thành vòng khép kín đầy đủ của đánh giá Agent sản xuất. -Xác minh mã tự động chỉ bao gồm các tình huống có câu trả lời tiêu chuẩn và việc chấm điểm các nhiệm vụ mở là chủ đề của phần này. Trong số đó, thiết kế mật độ của tín hiệu phần thưởng (từ phần thưởng nhị phân đến phần thưởng xử lý đến phần thưởng tổng hợp) và phương pháp huấn luyện của mô hình phần thưởng sẽ được thảo luận về hệ thống trong phần post-training của Chương 8; Phần này trả lời một câu hỏi cơ bản hơn: cách sử dụng LLM để tự động đánh giá chất lượng đầu ra của các tác vụ đang mở. +Cần nói rõ, dịch sang phải không có nghĩa là từ bỏ nửa trái. Mọi kiểm tra có thể viết thành khẳng định trong chương trình thì nên giữ nguyên là khẳng định, còn phán xét bằng LLM chỉ dùng cho những chiều thực sự không thể phán bằng máy. Kiểm tra tất định rẻ hơn, ổn định hơn, và cũng hợp hơn để chạy lâu dài như một bài kiểm thử hồi quy. ### LLM-as-a-Judge: Cốt lõi của đánh giá tự động -![Hình 7-4 Quy trình LLM-as-a-Judge ](images/fig7-4.svg) +![Hình 7-5 Quy trình LLM-as-a-Judge ](images/fig7-5.svg) Tại sao bạn cần LLM-as-a-Judge? Đối với các nhiệm vụ mở (chẳng hạn như tạo báo cáo, xử lý khiếu nại của khách hàng, nội dung sáng tạo), không có câu trả lời tiêu chuẩn nào có thể được so sánh tự động và việc đánh giá thủ công rất tốn kém và khó mở rộng quy mô. LLM-as-a-Judge cân bằng quy mô tự động hóa với chuyên môn của con người bằng cách đánh giá các mô hình ngôn ngữ dựa trên tiêu chí chấm điểm do chuyên gia xác định (Rubric). Tuy nhiên, phương pháp này cũng có những hạn chế đã biết: mô hình đánh giá có thể có những thành kiến riêng (điển hình nhất là **thành kiến về độ dài** - có xu hướng cho điểm cao hơn đối với những câu trả lời dài hơn và chi tiết hơn, ngay cả khi nội dung không chính xác hơn) và nhiều đánh giá cho cùng một thông tin đầu vào cũng có thể dao động. Sự thiên vị về chiều dài đặc biệt đáng được đề phòng cho từng cá nhân. Có ba phương pháp thường được sử dụng: xử phạt rõ ràng tính dài dòng trong Rubric và đặt giới hạn trên về độ dài của câu trả lời cho các nhiệm vụ tương tự; khi so sánh cặp đôi, kiểm soát độ dài của hai ứng viên sao cho tương đương nhau trước khi đánh giá; và thường xuyên kiểm tra mối tương quan giữa điểm số và độ dài câu trả lời - nếu điểm cao hầu như luôn đi kèm với câu trả lời dài, điều đó có nghĩa là đánh giá đã bị sai lệch về độ dài và cần phải sửa lại Rubric. Để giải quyết những thách thức này một cách có hệ thống, thiết kế Rubric phải tuân thủ các nguyên tắc sau: @@ -363,7 +364,7 @@ thất bại: "Thông tin bịa đặt không tồn tại trong cuộc trò chuy Đưa Rubric cùng câu trả lời thực tế của Agent cho mô hình đánh giá để nhận điểm và lý do theo từng tiêu chí. Khi tổng hợp hàng chục ca rồi xem lại các trajectory có điểm thấp, ta có thể biến một nhận xét mơ hồ như “tỷ lệ thành công giảm” thành chẩn đoán cụ thể: không truy xuất được dữ kiện, nối sai quan hệ giữa các nhân vật, hay tự thêm thông tin không có căn cứ. Rubric vì thế không chỉ cho biết hệ thống đạt bao nhiêu điểm, mà còn chỉ ra nên sửa ở đâu. -Dưới đây lấy bộ nhớ người dùng làm một trường hợp cụ thể, để cho thấy cách đưa phương pháp tổng quát này xuống thành tập đánh giá và bộ chấm điểm chạy được. +Dưới đây lấy bộ nhớ người dùng làm một trường hợp cụ thể, để cho thấy cách đưa phương pháp tổng quát này xuống thành tập đánh giá và bộ kiểm chứng chạy được. > **Thử nghiệm 7-3 ★★: Xây dựng hệ thống đánh giá bộ nhớ người dùng dựa trên Rubric** > @@ -534,7 +535,7 @@ Trong việc lựa chọn mô hình thực tế, câu hỏi chúng ta thường ### So sánh theo cặp và xếp hạng mô hình -![Hình 7-5 Xếp hạng Elo và xếp hạng so sánh ghép đôi ](images/fig7-5.svg) +![Hình 7-6 Xếp hạng Elo và xếp hạng so sánh ghép đôi ](images/fig7-6.svg) **Xếp hạng Elo**(một hệ thống xếp hạng ban đầu được sử dụng trong cờ vua) định lượng khả năng tương đối của một mô hình thông qua một số lượng lớn các trận đấu theo cặp: chênh lệch điểm số càng lớn thì tỷ lệ thắng mong đợi của người chơi mạnh hơn càng cao. Ví dụ: nếu mô hình A đạt 1200 và mô hình B đạt 1000, hệ thống Elo sẽ dự đoán tỷ lệ thắng của A là khoảng 76%. Nếu B bất ngờ thắng, B sẽ được nhiều điểm hơn và A sẽ mất nhiều điểm hơn - kết quả ngược lại sẽ mang đến sự điều chỉnh điểm lớn hơn. Cơ chế này cho phép thứ hạng nhanh chóng hội tụ về đúng đẳng cấp. Cơ sở thống kê đằng sau nó là **mô hình Bradley-Terry**: mỗi mô hình được trừu tượng hóa thành một "điểm sức mạnh" tiềm năng. Xác suất thắng hoặc thua một cặp đấu được xác định bằng chênh lệch tỷ số giữa hai trận đấu. Elo là kỹ thuật triển khai hình thức cập nhật trực tuyến của mô hình này. @@ -698,7 +699,7 @@ Khi kiểm chứng song song nhiều giả thuyết còn phải tính tới **so Các quyết định dựa trên đánh giá, dù là lựa chọn mô hình hay lặp lại liên tục, đều dựa vào dữ liệu vận hành chất lượng cao. Trước tiên, chúng tôi mô tả cách thu thập dữ liệu này một cách có hệ thống (observability được), sau đó thảo luận cách chuyển kết quả đánh giá thành cải tiến hệ thống. -![Hình 7-6 Ngăn xếp công nghệ quan sát ](images/fig7-6.svg) +![Hình 7-7 Ngăn xếp công nghệ quan sát ](images/fig7-7.svg) Khái niệm Observability được mượn từ lĩnh vực hệ thống phân tán: bạn không thể trực tiếp mở hệ thống để xem nó đang làm gì. Bạn chỉ có thể suy ra điều gì đang xảy ra thông qua nhật ký, chỉ báo và dữ liệu theo dõi mà nó đưa ra. Cũng giống như bác sĩ không thể nhìn trực tiếp tình trạng cơ thể bệnh nhân mà chỉ có thể chẩn đoán vấn đề thông qua các tín hiệu bên ngoài như nhiệt độ cơ thể, huyết áp, hình ảnh. Hệ thống Agent khiến việc này trở nên khó khăn hơn: cùng một đầu vào có thể tạo ra các đầu ra khác nhau, nhiều vòng lý luận và lệnh gọi công cụ khiến đường dẫn thực thi trở nên cực kỳ phức tạp và quá trình "tư duy" của mô hình hoàn toàn không rõ ràng với thế giới bên ngoài. @@ -718,7 +719,7 @@ Với một hệ thống đánh giá hoàn chỉnh và bộ dữ liệu sẵn c Trường hợp sau lấy từ một vòng lặp AndroidWorld có thật nhưng được thu hẹp có chủ đích trong kho đi kèm. Thử nghiệm gồm bốn nhiệm vụ cài đặt Wi-Fi trên trình giả lập API 35, mỗi nhiệm vụ có một cặp chạy đối chứng–thử nghiệm. Đây không phải toàn bộ benchmark 116 nhiệm vụ và cũng không thay thế việc chạy lại trong môi trường tham chiếu API 33. Giá trị của nó nằm ở chuỗi quyết định nối từ kết quả này sang kết quả kế tiếp, không phải ở một điểm số tổng quát. -![Hình 7-7 Điểm chuẩn cho vòng kín cải tiến ](images/fig7-7.svg) +![Hình 7-8 Điểm chuẩn cho vòng kín cải tiến ](images/fig7-8.svg) Từ góc độ của kỹ thuật Harness, phần này chủ yếu nói về phương pháp tối ưu hóa lặp lại Harness - xác định các liên kết yếu trong Harness bằng cách đánh giá dữ liệu (không đủ ngữ cảnh? Thiếu các ràng buộc? Xác minh không đầy đủ? Phản hồi không kịp thời?), cải tiến có mục tiêu và sau đó đánh giá lại, tạo thành một vòng khép kín trong quá trình phát triển liên tục của Harness. @@ -827,7 +828,7 @@ Thông điệp cốt lõi của phần này là: **Các phần trước đã hư Đây là cách nối hai đầu cầu. Tài sản tích lũy ở bên đánh giá có thể được chuyển đổi gần như liền mạch thành tín hiệu đào tạo: một tập hợp Rubric hoặc trình xác thực được xác định rõ ràng về cơ bản là chức năng khen thưởng của RLVR (Học tăng cường với Phần thưởng có thể xác minh) - tập lệnh phán xét trực tiếp là tập lệnh khen thưởng. Bài kiểm tra có đạt hay không và trạng thái có đạt tiêu chuẩn không chỉ là tiêu chí đánh giá mà còn là phần thưởng cho việc học tập củng cố. Nhưng việc đào tạo sẽ tạo ra những yêu cầu mới mà bạn không phải lo lắng trong giai đoạn đánh giá. Một là **ngữ nghĩa thiết lập lại đáng tin cậy**: quá trình đào tạo yêu cầu chạy hàng triệu tập (một tập là một vòng tương tác hoàn chỉnh từ trạng thái ban đầu đến khi kết thúc nhiệm vụ). Mỗi tập phải có khả năng đặt lại môi trường về trạng thái ban đầu nhất định và sạch sẽ, nếu không tín hiệu gradient sẽ bị ảnh hưởng bởi trạng thái dư của vòng trước. Thứ hai là thông lượng cao hơn nhiều so với đánh giá: hàng nghìn đánh giá là đủ để đưa ra kết luận, trong khi quá trình đào tạo yêu cầu cung cấp cho mô hình hàng triệu tương tác trong khoảng thời gian đồng hồ treo tường có thể chấp nhận được. Tính song song của môi trường và chi phí của một phiên bản duy nhất quyết định trực tiếp liệu việc đào tạo có khả thi hay không. Hai điểm này - trình xác thực chức năng khen thưởng, thiết lập lại và thông lượng theo định hướng đào tạo - sẽ được mở rộng trong Chương 8. -![Hình 7-8 Phổ độ trung thực mô phỏng ](images/fig7-8.svg) +![Hình 7-9 Phổ độ trung thực mô phỏng ](images/fig7-9.svg) **Về mặt môi trường kỹ thuật số**, khung AWorld đã xây dựng hộp cát máy chủ MCP có thể điều khiển cho nhiệm vụ GAIA, cung cấp 26 máy chủ MCP bao gồm 126 chức năng công cụ để tránh các lệnh cấm và tác dụng phụ không thể kiểm soát do truy cập trực tiếp vào API thực. Tất cả các lệnh gọi công cụ đều có thể phát lại và kiểm tra được. Kiến trúc phân tán của AWorld rút ngắn thời gian thực thi nối tiếp truyền thống từ 7695 giây xuống còn 525 giây (tăng tốc 14,6 lần). Thiết kế không trạng thái của môi trường làm cho mỗi phiên bản hoàn toàn độc lập và hỗ trợ tính song song hiệu quả. @@ -838,7 +839,7 @@ Về mặt **môi trường hiện thân**, RoboTwin2 xây dựng nhiệm vụ v > Xây dựng môi trường mô phỏng hoạt động của robot. Đọc tài liệu `ch7/SimpleVLA-RL` và OpenVLA để hiểu kiến trúc của mô hình hành động-ngôn ngữ-tầm nhìn (tích hợp từ đầu đến cuối của bộ mã hóa hình ảnh + mô hình ngôn ngữ + bộ giải mã hành động, chiếu hình ảnh và văn bản vào một không gian ngữ nghĩa chung). Định cấu hình môi trường RoboTwin2 và hiểu không gian quan sát (trạng thái khớp ba chiều RGB + 14 chiều) và không gian hành động (vectơ điều khiển 14 chiều). Nghiên cứu cơ chế ngẫu nhiên hóa môi trường và logic ràng buộc không gian trong move_can_pot. Chạy đánh giá mô hình được đào tạo trước, ghi lại tỷ lệ thành công, thời gian hoàn thành và các chế độ thất bại, tập trung vào tác động của việc phân chia hành động. > > -> ![Hình 7-9 OpenVLA và RoboTwin2 thể hiện môi trường thông minh ](images/fig7-9.svg) +> ![Hình 7-10 OpenVLA và RoboTwin2 thể hiện môi trường thông minh ](images/fig7-10.svg) > > @@ -850,7 +851,7 @@ Môi trường có độ chính xác cao có thể được chuyển sang thế ## Tóm tắt chương này -Chương này xoay quanh một câu hỏi: làm sao biết Agent thực sự đã tốt hơn? Từ môi trường thử nghiệm có thể tái hiện, tập dữ liệu chống rò rỉ, LLM làm giám khảo, cho đến việc dùng kết quả để chọn mô hình và lặp hệ thống — mắt xích nào cũng ảnh hưởng đến độ tin cậy của kết luận. Các thí nghiệm đo được trong chương bổ sung bốn cảnh báo cụ thể: ghép bộ nhớ có cấu trúc với RAG không mặc nhiên tạo ra hiệp lực; mức tiết kiệm từ cache và nén không thể cộng thẳng; lựa chọn âm thanh tham chiếu làm thay đổi ý nghĩa của điểm đa phương thức; và cách Harness biểu diễn đầu vào có thể quyết định cả thành công lẫn chi phí token. Việc chọn mô hình còn phải so sánh đường cong năng lực theo ngân sách tài nguyên, không chỉ nhìn một điểm số. Với Agent cấp sản xuất, đánh giá không phải kỳ thi thỉnh thoảng mới tổ chức mà là cơ chế xác minh liên tục trong mọi quyết định sản phẩm. +Chương này xoay quanh một câu hỏi: làm sao biết Agent thực sự đã tốt hơn? Chuỗi này gồm bốn mắt xích: trước hết làm rõ thế nào là thành công (khác biệt giữa các căn cứ Pass@k, Best@k và Pass consecutive@k), rồi xác định nhiệm vụ đến từ đâu (ba nguồn: benchmark công khai, tập nghiệp vụ tự dựng và dòng chảy ngược từ trajectory sản xuất), tiếp đó chọn cách kiểm chứng (từ bộ kiểm chứng tất định tới danh mục kiểm tra, Rubric cùng phán xét của LLM, cho tới so sánh cặp), và cuối cùng chuyển điểm số thành quyết định (ý nghĩa thống kê, quy trách nhiệm thất bại, nhiệm vụ hồi quy và chọn mô hình). Mắt xích nào cũng ảnh hưởng đến độ tin cậy của kết luận. Các thí nghiệm đo được trong chương bổ sung bốn cảnh báo cụ thể: ghép bộ nhớ có cấu trúc với RAG không mặc nhiên tạo ra hiệp lực; mức tiết kiệm từ cache và nén không thể cộng thẳng; lựa chọn âm thanh tham chiếu làm thay đổi ý nghĩa của điểm đa phương thức; và cách Harness biểu diễn đầu vào có thể quyết định cả thành công lẫn chi phí token. Việc chọn mô hình còn phải so sánh đường cong năng lực theo ngân sách tài nguyên, không chỉ nhìn một điểm số. Với Agent cấp sản xuất, đánh giá không phải kỳ thi thỉnh thoảng mới tổ chức mà là cơ chế xác minh liên tục trong mọi quyết định sản phẩm. Xét theo cấu trúc toàn sách, chương này dựng đoạn **chứng cứ** trong vòng lặp khám phá của Chương 1: quy trách nhiệm thất bại quyết định các đề xuất về sau có chỗ vững chắc để dựa vào hay không. diff --git a/book-vi/images/fig7-1.svg b/book-vi/images/fig7-1.svg index 23f3463ad..654b95bb5 100644 --- a/book-vi/images/fig7-1.svg +++ b/book-vi/images/fig7-1.svg @@ -1,19 +1,62 @@ - - - -Cấp độ 1: Đánh giá môi trường -"Nơi đo lường" — Loại lệnh gọi tool/Loại tương tác giữangười và máy tính/Môi trường mô phỏng - - -Cấp độ thứ hai: phương pháp đánh giá -"Cách đánh giá" — Thiết kế bộ dữ liệu · LLM-as-a-Judge ·So sánh và xếp hạng theo cặp - - -Cấp độ 3: Đánh giá thúc đẩy quyết định -"Những gì đã được đo lường" — Lựa chọn mô hình · Tối ưuhóa kiến ​​trúc · Lặp lại liên tục - -Các chủ đề kỹ thuậtxuyên suốt chương -• Khả năng quansát -• Môi trường môphỏng -• Đánh giá nội bộ - \ No newline at end of file + + + + + + + + +① Định nghĩa thành công +Pass@k đo trần năng lực · Pass^k đo độ tin cậy + + + +② Nguồn nhiệm vụ + +Benchmark công khai +Mượn thủ pháp · sàng lọc thô + +Tập nghiệp vụ tự dựng +Phân bố nhiệm vụ thực + +Chảy ngược từ sản xuất +Sản phẩm của quy trách nhiệm + + + +③ Cách kiểm chứng +← theo mức kiểm chứng được bằng máy của nhiệm vụ → + +Tất định +SWE-bench + + +Danh mục kiểm tra +τ²-bench + + +Rubric + LLM +Nhiệm vụ mở + + +So sánh cặp +Chatbot Arena + + + +④ Dùng kết quả +Ý nghĩa thống kê → Quy trách nhiệm → Hồi quy → Chọn mô hình và Harness + + +Nhiệm vụ hồi quy thành ca mới + + +Hạ tầng hỗ trợ +Khả năng quan sát · Hạ tầng đánh giá nội bộ (ablation / AB / cờ tính năng) · Mô phỏng (Chương 8) + diff --git a/book-vi/images/fig7-10.svg b/book-vi/images/fig7-10.svg new file mode 100644 index 000000000..c4e6bcd99 --- /dev/null +++ b/book-vi/images/fig7-10.svg @@ -0,0 +1,69 @@ + + + + +quan sát đa phươngthức + +máy ảnh đầu +224×224 RGB + +máy ảnh cổ tay trái +224×224 RGB + +máy ảnh cổ tay phải +224×224 RGB + +Vectơ trạng thái khớpchiều 14 + +Mô hình Hành động-Ngôn ngữ-Tầmnhìn (VLA) + +bộ mã hóa hình ảnh +SigLIP → Tầm nhìn tokens + + +mô hình ngôn ngữ +Llama 2 7B backbone + + +bộ giải mã hành động +→ Vectơ điều khiển liên tục chiều 14 +Phân chia hành động: 1 lần tạo ra các hànhđộng liên tiếp 25 + + + +Hướng dẫn: "Đặt lọ vào nồi" + + +Động cơ vật lý SAPIEN + +robot hai tay +Mỗi bậc tự do 7 = hànhđộng chiều 14 + +ngẫu nhiên hóa môitrường +Vị trí60cm/Hướng±22.5° + +Phát hiện va chạm + môphỏng vật lý +Thân cứng/thân mềm/masát + +hoạt động + +quan sát + +Chỉ số đánh giá + +tỷ lệ thành công +lọ trong nồi +và không bị rơi + +thời gian hoànthành +Các bước 25 × Hànhđộng 25 += Bước điều khiển 625 + +khả năng khái quáthóa +Trên khắp các địađiểm/định hướng +/biến thể ngoại hình + +Sim-to-Real +ngẫu nhiên tên miền +→ Di cư thực sự + \ No newline at end of file diff --git a/book-vi/images/fig7-3.svg b/book-vi/images/fig7-3.svg index f11319ad6..c6d617ffd 100644 --- a/book-vi/images/fig7-3.svg +++ b/book-vi/images/fig7-3.svg @@ -1,68 +1,76 @@ - - + + + + + + + - -Trình mô phỏng ngườidùng (LLM) - -Thông tin được biết: -Tên: Sarah Johnson -Đặt chỗ: BK-98712 -Hướng dẫn nhiệm vụ: -"Có vẻ như chuyến bay có vấnđề" -→ Tiết lộ chi tiết dần dần -→ Không chủ động báo số đặtchỗ - -Agent (đang được đánh giá) - - -LLM Lý luận + Lựa chọnchiến lược -① Số đặt chỗ của bạn là gì? -② lookup_booking(BK-98712) -③ Chuyến bay UA123 bị hủy -④ cancel_booking(BK-98712) -⑤ Hoàn tiền $150, 3-5 ngày làm việc - -Tool + Cơ sở dữ liệu - -lookup_booking -Kiểm trachi tiếtđặt phòng -modify_booking -Sửa đổitrạng tháiđặt phòng -cancel_booking -Hủy vàhoàn tiền -search_flights -Tìm kiếmchuyến baythay thế -send_notification -Gửi thôngbáo xácnhận - -DB State: -bookings, users, flights - -đối thoại - - -Cuộc gọi tool - - -Môi trường điều khiển kép: trình mô phỏng người dùng cũng có thể vận hành trực tiếp môi trường dùng chung (tool +cơ sở dữ liệu) - -Sau khi hoàn thành nhiệm vụ: Xác minh nhiều lớp - -Kiểm tra trạng thái DB - -booking.status == 'cancelled' -refund_record EXISTS -refund.amount == 150.00 - -Xác minh nội dung cuộc tròchuyện - -Chứa 'hoàn tiền' + số tiền -Chứa 'Thời gian đến' -Không có thông tin sai sự thật xuấthiện - -Kiểm tra tuân thủ quy trình - -Nhận xác nhận của người dùng trướckhi sửa đổi -Không hoạt động vượt quá thẩm quyền -Không chuyển dịch lao động quá mức - \ No newline at end of file + + +Bộ mô phỏng người dùng (LLM) +known_info: John Smith / 555-123-2002 / ở Pháp +task_instructions: tiết lộ dần · cảm xúc · neo sự kiện +Nghiệm thu: chỉ excellent mới coi là xong + + + +Agent (được đánh giá) +Đầu vào: phiếu yêu cầu + chính sách miền +Không thấy: trạng thái thật của thiết bị +Chỉ dẫn dắt, không làm thay + + + +Đối thoại nhiều lượt +Tiết lộ thông tin tuần tự + + + +Môi trường chung (điều khiển kép: cả hai phía đổi được trạng thái) + +Trạng thái phía thiết bị +Chế độ máy bay ON · chuyển vùng OFF · tiết kiệm · dung lượng còn +Công cụ người dùng: toggle_airplane_mode / toggle_roaming + check_status_bar / run_speed_test + +Cơ sở dữ liệu phía nhà mạng +Khách hàng C1001 · thuê bao L1001/L1002/L1003 · gói cước · hóa đơn +Công cụ Agent: get_customer_by_phone / get_data_usage + enable_roaming / refuel_data + + + + + + +toggle_roaming của người dùng đã đổi môi trường; Agent phải gọi lại công cụ — kiểm chứng bao trùm lần đọc lại này + + + +Sau nhiệm vụ: bốn tầng kiểm tra + quy tắc tổng hợp + +env_assertions +Dữ liệu di động dùng được +Tốc độ ≥ 200 / excellent + +actions +toggle_airplane_mode +requestor phải là user + +communicate_info +Đã báo thông tin cần thiết chưa +null ở nhiệm vụ này + +nl_assertions +Phán xét ở tầng ngôn ngữ +null ở nhiệm vụ này +reward_basis = ["ENV_ASSERTION"] → chỉ tầng đầu được tính; các tầng khác vẫn ghi nhưng không vào phần thưởng + diff --git a/book-vi/images/fig7-4.svg b/book-vi/images/fig7-4.svg index defa73162..6b3f358bf 100644 --- a/book-vi/images/fig7-4.svg +++ b/book-vi/images/fig7-4.svg @@ -1,53 +1,54 @@ - - + + + + + + - -Rubric (tiêu chí chấm điểm) - -Độ chính xác thực tế: Essential -Tính liên tục logic: Important -Phát hiện ảo giác: Veto ⚠ -Tính toàn vẹn: Important - -Câu trả lời của ứng viên - -Đầu ra Agent: -"Việc hoàn tiền đã được xử lý,$150 sẽ được xử lý -3-5 sẽ đến trong vòng ngày làmviệc. " - - -Kế hoạch tham khảo (tùy chọn) - -Câu trả lời/điểm tiêu chuẩn: -Phải bao gồm số tiền hoàn lại -Phải bao gồm thời gian đến -Không thể hứa hẹn ngày cụ thể - - - - -Mẫu Judge (GPT-5 / Gemini 2.5) -Đánh giá không đồng nhất đa nguồn để ngănngừa sai lệch tương đồng - - -Đầu ra đánh giá có cấu trúc - -tính đúng đắn thực tế -4/4 -Số lượng và thờigian là chính xác -chính trực -3/4 -Thiếu hướng dẫn vềphương thức hoàn tiền -Phát hiện ảo giác -PASS -Không có thông tinsai sự thật -sự mạch lạc logic -4/4 -Rõ ràng nhân quả - -Chiến lược tổng hợp xếp hạng -Trung bình có trọng số:Σ(điểm trọng lượng×thứ nguyên) -Quyền phủ quyết một phiếu:ảo giác=FAIL → tổng số điểm=0 -Nhiều giám khảo: 3 giám khảo lấy trung vị -Thẻ trường hợp viền: Không đồng ý > Điểm 2→ Đánh giá của con người + +Mức kiểm chứng bằng máy của nhiệm vụ: cao +thấp + + +Tất định +Trạng thái cuối duy nhất, tra được +Đạt / không đạt +SWE-bench chạy kiểm thử + + + +Danh mục kiểm tra +Nhiều kiểm tra tất định +Tổng hợp theo căn cứ đã khai +Bốn tầng của τ²-bench + + + +Rubric + LLM +Có chiều nhưng mã không phán được +Chấm theo chiều kèm lý do +Chất lượng CSKH, viết báo cáo + + + +So sánh cặp +Ngay cả chiều cũng khó nêu +Chỉ phán A hơn hay B hơn +Chatbot Arena + + +Kiểm chứng tất định +Tái lập hoàn toàn, hợp CI, rẻ +Cái giá: chỉ đúng/sai, không chỉ chỗ hỏng + + +Phán xét bằng mô hình +Cho chiều chẩn đoán, phủ được cái không khẳng định nổi +Cái giá: thiên lệch và dao động, tốn hơn diff --git a/book-vi/images/fig7-5.svg b/book-vi/images/fig7-5.svg index ba91041ba..defa73162 100644 --- a/book-vi/images/fig7-5.svg +++ b/book-vi/images/fig7-5.svg @@ -1,56 +1,53 @@ - + - -Chatbot Arena Trận đấu ẩn danh - -Model A (ẩn danh) - -"Tiền hoàn lại đã được xử lý và sẽ ởdạng 3-5 -Tín dụng sẽ được ghi có vào tàikhoản của bạn vào ngày làm việc" -VS - -Model B (ẩn danh) - -"Hoàn tiền tốt sẽ được xử lý" - - -Lựa chọn mù của người dùng → A tốt hơn - -Công thức cập nhật Elo -Tỷ lệ chiến thắng dự kiến ​​E_A = 1/(1+10^((R_B-R_A)/400)) | Cập nhật: R_A' = R_A + K*(1-E_A) -Bảng xếp hạng trực tiếp (ví dụ) -Xếp hạng -Người mẫu -Elo -Tỷ lệ thắng vs #2 - -1 -Claude 4 Opus -1352 -— -2 -GPT-5 -1318 -— -3 -Gemini 2.5 Pro -1290 -45% -4 -DeepSeek R2 -1265 -42% -5 -Qwen 3 Max -1230 -39% -6 -Llama 4 405B -1198 -36% - - -GRPO: Đưa so sánh theo cặp vào chương trình đào tạo RL -Tập hợp các câu trả lời của ứng viên → Chuẩn hóa lợi thế tương đối → Cập nhật chính sách(bỏ qua mô hình phần thưởng rõ ràng) - \ No newline at end of file + +Rubric (tiêu chí chấm điểm) + +Độ chính xác thực tế: Essential +Tính liên tục logic: Important +Phát hiện ảo giác: Veto ⚠ +Tính toàn vẹn: Important + +Câu trả lời của ứng viên + +Đầu ra Agent: +"Việc hoàn tiền đã được xử lý,$150 sẽ được xử lý +3-5 sẽ đến trong vòng ngày làmviệc. " + + +Kế hoạch tham khảo (tùy chọn) + +Câu trả lời/điểm tiêu chuẩn: +Phải bao gồm số tiền hoàn lại +Phải bao gồm thời gian đến +Không thể hứa hẹn ngày cụ thể + + + + +Mẫu Judge (GPT-5 / Gemini 2.5) +Đánh giá không đồng nhất đa nguồn để ngănngừa sai lệch tương đồng + + +Đầu ra đánh giá có cấu trúc + +tính đúng đắn thực tế +4/4 +Số lượng và thờigian là chính xác +chính trực +3/4 +Thiếu hướng dẫn vềphương thức hoàn tiền +Phát hiện ảo giác +PASS +Không có thông tinsai sự thật +sự mạch lạc logic +4/4 +Rõ ràng nhân quả + +Chiến lược tổng hợp xếp hạng +Trung bình có trọng số:Σ(điểm trọng lượng×thứ nguyên) +Quyền phủ quyết một phiếu:ảo giác=FAIL → tổng số điểm=0 +Nhiều giám khảo: 3 giám khảo lấy trung vị +Thẻ trường hợp viền: Không đồng ý > Điểm 2→ Đánh giá của con người + diff --git a/book-vi/images/fig7-6.svg b/book-vi/images/fig7-6.svg index 328ea879c..ba91041ba 100644 --- a/book-vi/images/fig7-6.svg +++ b/book-vi/images/fig7-6.svg @@ -1,48 +1,56 @@ - - - -Cây theo dõi thực thi (nhiệm vụ đơn) - -Trace: Giúp người dùng kiểm tra thời tiết ởBắc Kinh vào ngày mai (3.2s, $0.008) - -LLM Call: Nhận dạng ý định -Claude 4 Sonnet · 0.4s · 320 tokens - -Tool：get_weather(Beijing) -MCP Server · 1.8s · 200ms TTFT - -├─ HTTP Request -api.weather.com · 1.6s - -└─ Response Parse -JSON → Dữ liệu thời tiết có cấu trúc - -LLM Call: Tạo phản hồi -Claude 4 Sonnet · 0.8s · 580 tokens - -Tool：send_message(user) -0.2s · Chứa tóm tắt thời tiết - - - - - - - -Bảng điều khiển giám sát - -theo dõi chi phí -Hôm nay: $12.30 (1, 200 lần) -Tháng này: $340 (34K lần) -Ngoại lệ: task#892 gọi search 14 lầntrong một vòng lặp, tiêu tốn $2.1 - -Giám sát hiệu suất -P50 / P95 / P99 Độ trễ: 2.1s / 8.4s / 15.2s -Tỷ lệ thành công của tool: 94.3% - -kiểm toán chất lượng -Tỷ lệ thành công của nhiệm vụ: 87% Kíchhoạt ảo giác: 2.1% -Vi phạm bảo mật: 0 (tháng này) Sự hài lòngcủa người dùng: 4.3/5 - -Vòng lặp khép kín: theo dõi dữ liệu → phát hiện vấn đề → kiểm tra A/B → quản lý phiên bản từnhanh chóng → tối ưu hóa liên tục - + + + + +Chatbot Arena Trận đấu ẩn danh + +Model A (ẩn danh) + +"Tiền hoàn lại đã được xử lý và sẽ ởdạng 3-5 +Tín dụng sẽ được ghi có vào tàikhoản của bạn vào ngày làm việc" +VS + +Model B (ẩn danh) + +"Hoàn tiền tốt sẽ được xử lý" + + +Lựa chọn mù của người dùng → A tốt hơn + +Công thức cập nhật Elo +Tỷ lệ chiến thắng dự kiến ​​E_A = 1/(1+10^((R_B-R_A)/400)) | Cập nhật: R_A' = R_A + K*(1-E_A) +Bảng xếp hạng trực tiếp (ví dụ) +Xếp hạng +Người mẫu +Elo +Tỷ lệ thắng vs #2 + +1 +Claude 4 Opus +1352 +— +2 +GPT-5 +1318 +— +3 +Gemini 2.5 Pro +1290 +45% +4 +DeepSeek R2 +1265 +42% +5 +Qwen 3 Max +1230 +39% +6 +Llama 4 405B +1198 +36% + + +GRPO: Đưa so sánh theo cặp vào chương trình đào tạo RL +Tập hợp các câu trả lời của ứng viên → Chuẩn hóa lợi thế tương đối → Cập nhật chính sách(bỏ qua mô hình phần thưởng rõ ràng) + \ No newline at end of file diff --git a/book-vi/images/fig7-7.svg b/book-vi/images/fig7-7.svg index 08ee38ab8..328ea879c 100644 --- a/book-vi/images/fig7-7.svg +++ b/book-vi/images/fig7-7.svg @@ -1,56 +1,48 @@ - - - - -① Quan sát: Báo cáo chẩn đoán -Tỷ lệ thành công chung: 88% (102/116) -transcription: 0% complex_ui: 17% -math_counting: 0% Wi-Fi hoạt động: 0% -Task 82,102-115 Tập trung hóa không thành công - -② Giả thuyết: Khung cải tiến ba lớp - -lớp bềmặt -H1 Đặt lời nhắc điều hướng H2 Quy tắc giao diệnngười dùng - -cấptrung -H3 Sửa chữa đường ống đa phương thức H4 - -Sâu -Cây phần tử giao diện người dùng H5 GPT-5 H6 - - -③ Thử nghiệm: Xác minh theo từng giai đoạn (5 lần × 116 tác vụ cho mỗi cấuhình) - -Điều hướng H1 -Đặt 0%→75% -token+8% - -H3 đa phương thức -Phiên âm 0%→80% -Độ trễ+1 - -Suy nghĩ của H4 -Đếm 0%→70% -Trì hoãn 3x! - -Cây phần tử H6 -UI 17%→52% -token+30% - -④ Ra quyết định: đánh đổi giữa chi phívà lợi ích -✓ H1+H3: chi phí thấp và lợi nhuận cao → Triển khai -✗ H4: Chỉ các nhiệm vụ 8% được hưởng lợi nhưng 3x bị trìhoãn → Từ chối -✓ H6: Khuyến mãi 35%/chi phí 30% → Triển khai -✗ H5: 15s/bước không được chấp nhận → Thay thế - -⑤ Lặp lại: một chu kỳ mới -Triển khai H1+H3+H6 → 88%→94% -Báo cáo mới cho thấy các chế độ lỗi khác nhau: -H7: Kích hoạt tư duy có điều kiện -H8: Mở rộng không gian hành động cử chỉ - -↑ Vònglặp - -Phương pháp luận: Quan sát→Giả thuyết→Thí nghiệm→Quyết định→Lặp lại = từ thuậtgiả kim đến kỹ thuật khoa học - \ No newline at end of file + + + +Cây theo dõi thực thi (nhiệm vụ đơn) + +Trace: Giúp người dùng kiểm tra thời tiết ởBắc Kinh vào ngày mai (3.2s, $0.008) + +LLM Call: Nhận dạng ý định +Claude 4 Sonnet · 0.4s · 320 tokens + +Tool：get_weather(Beijing) +MCP Server · 1.8s · 200ms TTFT + +├─ HTTP Request +api.weather.com · 1.6s + +└─ Response Parse +JSON → Dữ liệu thời tiết có cấu trúc + +LLM Call: Tạo phản hồi +Claude 4 Sonnet · 0.8s · 580 tokens + +Tool：send_message(user) +0.2s · Chứa tóm tắt thời tiết + + + + + + + +Bảng điều khiển giám sát + +theo dõi chi phí +Hôm nay: $12.30 (1, 200 lần) +Tháng này: $340 (34K lần) +Ngoại lệ: task#892 gọi search 14 lầntrong một vòng lặp, tiêu tốn $2.1 + +Giám sát hiệu suất +P50 / P95 / P99 Độ trễ: 2.1s / 8.4s / 15.2s +Tỷ lệ thành công của tool: 94.3% + +kiểm toán chất lượng +Tỷ lệ thành công của nhiệm vụ: 87% Kíchhoạt ảo giác: 2.1% +Vi phạm bảo mật: 0 (tháng này) Sự hài lòngcủa người dùng: 4.3/5 + +Vòng lặp khép kín: theo dõi dữ liệu → phát hiện vấn đề → kiểm tra A/B → quản lý phiên bản từnhanh chóng → tối ưu hóa liên tục + diff --git a/book-vi/images/fig7-8.svg b/book-vi/images/fig7-8.svg index 6ed62f865..08ee38ab8 100644 --- a/book-vi/images/fig7-8.svg +++ b/book-vi/images/fig7-8.svg @@ -1,41 +1,56 @@ - + - - -Độ trung thực mô phỏng → -Có thể -mở rộng -triển lãm -tình dục -↑ - -Mock API -cấp độ kiểm tra đơn vị -Triệu lần/giờ - -AWorld -Hộp cát MCP -Chức năng của tool 126 -525/bánh xe được phân phối - -AndroidWorld -giả lập -Nhiệm vụ ứng dụng thực tế 116 -UI Automator - -Isaac Gym -GPU song song -Hàng ngàn trường hợp song song -Thỏa hiệp nhẹ về độ chính xác - -RoboTwin2 -Động cơ vật lý -Va chạm có độ chính xác cao -Phiên bản đơn CPU - -thế giớithực -độ trung thựchoàn hảo -Không thể đặtlại được - + +① Quan sát: Báo cáo chẩn đoán +Tỷ lệ thành công chung: 88% (102/116) +transcription: 0% complex_ui: 17% +math_counting: 0% Wi-Fi hoạt động: 0% +Task 82,102-115 Tập trung hóa không thành công + +② Giả thuyết: Khung cải tiến ba lớp + +lớp bềmặt +H1 Đặt lời nhắc điều hướng H2 Quy tắc giao diệnngười dùng + +cấptrung +H3 Sửa chữa đường ống đa phương thức H4 + +Sâu +Cây phần tử giao diện người dùng H5 GPT-5 H6 + + +③ Thử nghiệm: Xác minh theo từng giai đoạn (5 lần × 116 tác vụ cho mỗi cấuhình) + +Điều hướng H1 +Đặt 0%→75% +token+8% + +H3 đa phương thức +Phiên âm 0%→80% +Độ trễ+1 + +Suy nghĩ của H4 +Đếm 0%→70% +Trì hoãn 3x! + +Cây phần tử H6 +UI 17%→52% +token+30% + +④ Ra quyết định: đánh đổi giữa chi phívà lợi ích +✓ H1+H3: chi phí thấp và lợi nhuận cao → Triển khai +✗ H4: Chỉ các nhiệm vụ 8% được hưởng lợi nhưng 3x bị trìhoãn → Từ chối +✓ H6: Khuyến mãi 35%/chi phí 30% → Triển khai +✗ H5: 15s/bước không được chấp nhận → Thay thế + +⑤ Lặp lại: một chu kỳ mới +Triển khai H1+H3+H6 → 88%→94% +Báo cáo mới cho thấy các chế độ lỗi khác nhau: +H7: Kích hoạt tư duy có điều kiện +H8: Mở rộng không gian hành động cử chỉ + +↑ Vònglặp + +Phương pháp luận: Quan sát→Giả thuyết→Thí nghiệm→Quyết định→Lặp lại = từ thuậtgiả kim đến kỹ thuật khoa học \ No newline at end of file diff --git a/book-vi/images/fig7-9.svg b/book-vi/images/fig7-9.svg index c4e6bcd99..6ed62f865 100644 --- a/book-vi/images/fig7-9.svg +++ b/book-vi/images/fig7-9.svg @@ -1,69 +1,41 @@ - - + + - -quan sát đa phươngthức - -máy ảnh đầu -224×224 RGB - -máy ảnh cổ tay trái -224×224 RGB - -máy ảnh cổ tay phải -224×224 RGB - -Vectơ trạng thái khớpchiều 14 - -Mô hình Hành động-Ngôn ngữ-Tầmnhìn (VLA) - -bộ mã hóa hình ảnh -SigLIP → Tầm nhìn tokens - - -mô hình ngôn ngữ -Llama 2 7B backbone - - -bộ giải mã hành động -→ Vectơ điều khiển liên tục chiều 14 -Phân chia hành động: 1 lần tạo ra các hànhđộng liên tiếp 25 - - - -Hướng dẫn: "Đặt lọ vào nồi" - - -Động cơ vật lý SAPIEN - -robot hai tay -Mỗi bậc tự do 7 = hànhđộng chiều 14 - -ngẫu nhiên hóa môitrường -Vị trí60cm/Hướng±22.5° - -Phát hiện va chạm + môphỏng vật lý -Thân cứng/thân mềm/masát - -hoạt động - -quan sát - -Chỉ số đánh giá - -tỷ lệ thành công -lọ trong nồi -và không bị rơi - -thời gian hoànthành -Các bước 25 × Hànhđộng 25 -= Bước điều khiển 625 - -khả năng khái quáthóa -Trên khắp các địađiểm/định hướng -/biến thể ngoại hình - -Sim-to-Real -ngẫu nhiên tên miền -→ Di cư thực sự + + +Độ trung thực mô phỏng → +Có thể +mở rộng +triển lãm +tình dục +↑ + +Mock API +cấp độ kiểm tra đơn vị +Triệu lần/giờ + +AWorld +Hộp cát MCP +Chức năng của tool 126 +525/bánh xe được phân phối + +AndroidWorld +giả lập +Nhiệm vụ ứng dụng thực tế 116 +UI Automator + +Isaac Gym +GPU song song +Hàng ngàn trường hợp song song +Thỏa hiệp nhẹ về độ chính xác + +RoboTwin2 +Động cơ vật lý +Va chạm có độ chính xác cao +Phiên bản đơn CPU + +thế giớithực +độ trung thựchoàn hảo +Không thể đặtlại được + \ No newline at end of file diff --git a/book-zhtw/chapter7.zhtw.md b/book-zhtw/chapter7.zhtw.md index 6bd27e3b9..0628ec189 100644 --- a/book-zhtw/chapter7.zhtw.md +++ b/book-zhtw/chapter7.zhtw.md @@ -1,92 +1,152 @@ # Agent 的評估 -前六章已經展開了單 Agent 的建構：上下文、知識、工具、程式碼能力，以及觀察與動作空間。然而，建構完成不等於建構正確；只有能夠穩定測量結果，後續的模型訓練和系統進化才有可靠方向。 +前六章已經展開了單 Agent 的構建：上下文、知識、工具、程式碼能力以及觀察與動作空間。然而，構建完成不等於構建正確；只有能夠穩定測量結果，後續的模型訓練和系統進化才有可靠方向。 -建構 Agent 系統時，開發者面對大量設計選擇，而它們往往沒有顯而易見的正確答案： +構建 Agent 系統時，開發者面對大量設計選擇，而它們往往沒有顯而易見的正確答案： - 用什麼模型？ - 讓模型能呼叫哪些工具？ -- 知識庫該存什麼資料、以什麼結構來建構？ +- 知識庫該存什麼資料、以什麼結構來構建？ - 使用者記憶該怎麼做？ - 模型的提示詞和 Skills 該如何組織？ - Harness 中需要加上哪些約束？ - 如何把評估結果轉化為 Agent 持續進化的學習訊號？ -評估為我們提供了科學的決策依據：透過系統性的對比實驗（改變一個變數，觀察效果變化）和消融實驗（逐一關閉某個元件，觀察整體效能變化，從而判斷該元件的真實貢獻），區分真正的能力提升與表面的波動，避免「撿了芝麻，丟了西瓜」。正如軟體工程中「沒有度量就沒有改進」的說法，不建立可重複的評估體系，Agent 的迭代方向就只能靠直覺。 +評估為我們提供了科學的決策依據：通過系統性的**對比實驗**（改變一個變數，觀察效果變化）和**消融實驗**（逐一關閉某個元件，觀察整體效能變化，從而判斷該元件的真實貢獻），區分真正的能力提升與表面的波動，避免 「撿了芝麻，丟了西瓜」。正如軟體工程中 「沒有度量就沒有改進」 的說法，不建立可重複的評估體系，Agent 的迭代方向就只能靠直覺。 + +從第一章引入的 Harness 工程視角看，評估在 Harness 中扮演著 「驗證」 功能的核心角色。一個關鍵認識是：**評估的物件不應只是模型，而應是模型與 Harness 的組合體**。同一個模型在不同的 Harness 中可能表現差異懸殊。一些團隊僅通過最佳化 Harness 就顯著提升了同一模型在終端類任務上的表現（詳見第五章）。這意味著，當 Agent 在評估中表現不佳時，改進方向可能不是換模型，而是最佳化 Harness 的某個元件（提示詞、工具設計、回饋迴圈）。完善的評估體系應能區分 「模型能力不足」 和 「Harness 設計缺陷」 這兩類本質不同的問題。 + +**區分這兩類問題的常見手段是模型替換實驗（model swap）**——固定 Harness，只更換更強/更弱的模型，觀察分數變化幅度；如果換強模型分數不漲，說明瓶頸在 Harness；如果換弱模型分數大跌、分數隨模型能力大幅波動，最直接的解讀就是瓶頸在模型能力本身、目前表現主要由模型決定（至於這是因為任務本身就難，還是 Harness 過度依賴模型先驗，則需進一步分析）。注意這與前面提到的 「消融實驗」 是兩種不同的方法：消融是**關閉 Harness 的某個元件**看整體效能如何變化，模型替換則是**固定 Harness、只換模型**——前者定位 Harness 內部哪個部件重要，後者區分瓶頸在模型還是在 Harness。 + +評估體系的價值在模型快速演進的時代更加凸顯。模型能力仍在快速演進，但新模型在公開基準上表現更好，並不意味著在你的特定任務上也更好，反而可能出現效能退化（regression，即新版本在某些方面不如舊版本）。只有在自己的評估資料集上完整測試，才能做出資料驅動的升級決策。更進一步，完善的評估體系使得 **「為未來的模型開發產品」** 成為可行策略——即使目前模型不足以支撐商用，也可以先完成產品開發並建立評估集，持續追蹤新模型的表現，一旦達到門檻就立即上線。 + +一套評估體系可以拆成四個環節：什麼算成功、任務從何而來、由誰驗證、分數如何轉化為決策，如圖7-1 所示。 + +![圖7-1 Agent 評估體系的四個環節](images/fig7-1.svg) + +## 一條評估任務的解剖：τ²-bench 的 telecom 領域 + +我們先完整解剖 τ²-bench 的 telecom 領域一條真實任務。原始碼位於倉庫的 `chapter7/tau2-bench`，任務檔案為 `data/tau2/domains/telecom/tasks_small.json`。 + +### 任務定義的四個組成部分 + +以下是該檔案中的一條任務，為便於閱讀做了刪節。 + +```jsonc +{ + "id": "[mobile_data_issue]airplane_mode_on|user_abroad_roaming_enabled_off", + + // 提供給 Agent 的工單 + "ticket": "使用者手機無法上網，狀態列顯示 'No Service'。客戶 John Smith， + 號碼 555-123-2002，目前在法國。速度測試結果為 excellent 才算解決。 + 不更換套餐，必要時願意充值 2.0 GB 流量。", + + // 提供給使用者模擬器的行為規範 + "user_scenario": { "instructions": { + "known_info": "You are John Smith with phone number 555-123-2002. + You are currently abroad in France.", + "unknown_info": null, + "task_instructions": + "…express mild frustration after the first unsuccessful attempt. + You will consider the issue resolved only when speed test returns + excellent internet speed and nothing else. If it returns poor, fair + or good, you will not consider the issue resolved. + Whenever the agent asks you about your device, always ground your + responses on the results of tool calls. … + Never make up the results of tool calls." + }}, + + // 執行前將兩側狀態重置到同一起點 + "initial_state": { "initialization_actions": [ + { "env_type": "user", "func_name": "turn_airplane_mode_on" }, + { "env_type": "user", "func_name": "turn_roaming_off" }, + { "env_type": "assistant", "func_name": "enable_roaming", + "arguments": { "customer_id": "C1001", "line_id": "L1002" } } + ]}, + + // 評分標準 + "evaluation_criteria": { + "actions": [ + { "requestor": "user", "name": "toggle_airplane_mode" }, + { "requestor": "user", "name": "toggle_roaming" } + ], + "env_assertions": [ + { "func_name": "assert_mobile_data_status", "expected_status": true }, + { "func_name": "assert_internet_speed", + "expected_speed": 200, "expected_desc": "excellent" } + ], + "communicate_info": null, + "nl_assertions": null, + "reward_basis": ["ENV_ASSERTION"] + } +} +``` -從第一章引入的 Harness 工程視角看，評估在 Harness 中扮演著「驗證」功能的核心角色。一個關鍵認識是：**評估的物件不應只是模型，而應是模型與 Harness 的組合體**。同一個模型在不同的 Harness 中可能表現差異懸殊——一些團隊僅透過最佳化 Harness 就顯著提升了同一模型在終端機類任務上的表現（詳見第五章）。這意味著，當 Agent 在評估中表現不佳時，改進方向可能不是換模型，而是最佳化 Harness 的某個元件（提示詞、工具設計、回饋迴圈）。完善的評估體系應能區分「模型能力不足」和「Harness 設計缺陷」這兩類本質不同的問題。**區分這兩類問題的常見手段是模型替換實驗（model swap）**——固定 Harness，只更換更強/更弱的模型，觀察分數變化幅度；如果換強模型分數不漲，說明瓶頸在 Harness；如果換弱模型分數大跌、分數隨模型能力大幅波動，最直接的解讀就是瓶頸在模型能力本身、當前表現主要由模型決定（至於這是因為任務本身就難、還是 Harness 過度依賴模型先驗，則需進一步分析）。注意這與前面提到的「消融實驗」是兩種不同的方法：消融是**關閉 Harness 的某個元件**看整體效能如何變化，模型替換則是**固定 Harness、只換模型**——前者定位 Harness 內部哪個部件重要，後者區分瓶頸在模型還是在 Harness。 +這段定義中有四處設計值得說明： -評估體系的價值在模型快速演進的時代更加凸顯。模型能力仍在快速演進，但新模型在公開基準上表現更好，並不意味著在你的特定任務上也更好——反而可能出現效能退化（regression，即新版本在某些方面不如舊版本）。只有在自己的評估資料集上完整測試，才能做出資料驅動的升級決策。更進一步，完善的評估體系使得「為未來的模型開發產品」成為可行策略——即使當前模型不足以支撐商用，也可以先完成產品開發並建立評估集，持續追蹤新模型的表現，一旦達到門檻就立即上線。 +**顯式建模使用者的認知邊界。** `known_info` 僅包含姓名、號碼與所在國家三項資訊。飛航模式開啟、資料漫遊關閉這兩項真正的故障原因不在其中——使用者並不知情，因而無法主動陳述，Agent 只能通過提問和引導使用者查詢來獲取。這就是**漸進式資訊透露（Progressive Information Disclosure）** 在任務定義層面的實作方式：它並非依靠一句 「不要一次說完」 的提示詞去約束模擬器，而是將使用者的知識範圍建模為一個獨立欄位。多數基準在任務開始時即給出完整需求，而真實使用者的初始表述往往只是 「我上不了網」，Agent 必須主動找使用者澄清需求，而不是。 -> **本章導讀** -> -> 本章從三個層次建構完整的評估體系。第一層是**評估環境**（「在哪裡測」）：如何搭建自動化、可復現的測試環境，包括工具呼叫型和人機互動型兩種範式。第二層是**評估方法**（「怎麼判」）：從資料集設計原則、評估指標體系（該測什麼），到 LLM-as-a-Judge（用大語言模型充當評委）自動化評判，再到配對比較與模型排名。第三層是**評估驅動的決策**（「測了幹什麼」）：將評估結果轉化為模型選型、架構最佳化和持續迭代的行動指南，並藉助統計顯著性判斷觀察到的分數差異是否真實可信。本章還會討論可觀測性與生產級 Agent 的內部評估基礎設施，並在章末介紹連線第八章後訓練的模擬環境。 -> -> 貫穿全章的核心理念是：**評估體系的首要價值不是給當前系統打分，而是讓你能快速、可靠地跟上模型的演進**。當一個更強或更便宜的模型釋出時，擁有完善評估體系的團隊能在數小時內得出切換決策，而缺乏評估體系的團隊只能憑直覺或等待社群回饋——在競爭激烈的 Agent 市場中，這種速度差距可能決定成敗。 +**防止使用者模擬器被 Agent 忽悠。** `task_instructions` 包含三類約束：情緒設定（首次修復失敗後應表現出輕度不滿）、驗收口徑（僅當測速結果為 excellent 時才認定問題解決，poor、fair、good 均不接受）、以及**事實錨定（Grounding）** 要求，即關於裝置狀態的任何回答都必須以工具返回結果為依據。缺少事實錨定約束時，模擬使用者會順應 Agent 的引導確認問題已解決，評估隨之退化為兩個模型之間的相互確認。 -![圖 7-1 評估體系的三個層次](images/fig7-1.svg) +**模擬使用者和 Agent 都不具備完全資訊。** 飛航模式與漫遊開關屬於使用者側，運營商側的 `enable_roaming` 屬於 Agent 側。這一劃分決定了故障的形態——運營商側漫遊已開通，使用者裝置側卻處於關閉狀態，Agent 查詢資料庫只能得到 「配置正常」 的結論。故障位於資料庫不可見的一側，只有引導使用者查詢才能發現。 -## 一個具體的評估示例 +**多個維度的過程和結果校驗。** `env_assertions` 檢驗終態（移動資料可用、測速達 200 Mbps 以上且評級為 excellent），`actions` 檢驗關鍵動作是否發生，`communicate_info` 與 `nl_assertions` 檢驗必要資訊是否已告知使用者。每個任務可以檢查四個維度中一個或多個維度的結果。 -在深入方法之前，先透過一個完整的例子建立直覺。假設我們建構了一個客服 Agent，需要評估它處理退款請求的能力。 +### 一次真實執行的軌跡 -**測試用例**：使用者要求退掉 3 天前的訂單（訂單號 #12345，金額 ¥299）。公司政策：7 天內可全額退款。 +下面請讀者執行 τ²-bench telecom 領域的評估任務，實際觀察任務設計、使用者模擬器的設計、過程和結果校驗邏輯，並觀察 Agent 的執行軌跡，分析 Agent 為何失敗。 -**Agent 的軌跡**： +> **實驗 7-1 ★：執行 τ²-bench 並對比 τ-bench 的演進** +> +> 本實驗通過執行 τ²-bench 評估框架，理解人機互動型評估環境的設計要點。首先按本節的路徑通讀任務定義檔案：每條任務包含已知資訊、任務指令、初始狀態與成功條件四個部分。隨後執行完整評估流程，觀察使用者模擬器與 Agent 的多輪對話，分析典型失敗模式（政策違規、資訊遺漏、過度轉接人工等）。 +> +> ![圖7-3 τ²-bench 的雙控環境與分層驗證](images/fig7-3.svg) -```text -使用者：我想退掉 3 天前買的那個耳機，訂單號 12345。（今天是 2026-04-10） +配套倉庫保留了一次執行記錄（`chapter7/tau2-bench-eval`），下面分析其中一條成功的執行記錄： -Agent（思考）：使用者要退款，需要先查詢訂單資訊。 -Agent → 呼叫工具 query_order(order_id="12345") -工具返回：{status: "delivered", amount: 299, date: "2026-04-07", item: "藍芽耳機"} +前十餘輪為帳戶識別階段。Agent 依據號碼查得客戶 C1001，隨後逐一查詢 L1001、L1002、L1003 三條線路的流量，又回頭詢問使用者在法國實際使用的號碼。第 17 條訊息中它給出了一個錯誤結論： -Agent（思考）：下單日 2026-04-07，距今天 2026-04-10 為 3 天，在 7 天退款期內，符合全額退款條件。 -Agent → 呼叫工具 process_refund(order_id="12345", amount=299) -工具返回：{refund_id: "R-98765", status: "processing", eta: "3-5個工作日"} +> **Agent**（17）：號碼 555-123-2002 不在您的活躍線路中，最接近的是 555-123-2001…… -Agent：已為您發起退款，訂單 #12345（藍芽耳機，¥299）的全額退款正在處理中， - 預計 3-5 個工作日到賬。退款編號 R-98765，可用來查詢進度。 -``` +該結論僅基於 L1001 一條線路的查詢結果。使用者堅持號碼無誤後，Agent 繼續查詢 L1002，方才對應上。關鍵轉折出現在第 30 條： -**用 Rubric 評分**（四個維度，每維度 1-4 分）。表 7-1 給出了這個客服退款任務的評分示例，用來說明 Rubric 如何把一次 Agent 軌跡拆成可檢查的評價維度。 +> **使用者**（30）→ 呼叫 `check_network_status()`、`check_status_bar()` +> +> **工具返回**（31）：`Airplane Mode: ON | Cellular Connection: no_service | Mobile Data Enabled: Yes | Data Roaming Enabled: No` +> +> **使用者**（33）：我看到手機目前處於飛航模式，因此沒有訊號。移動資料是開啟的，但資料漫遊是關閉的。需要我關掉飛航模式試一下嗎？ -表 7-1 客服退款任務的 Rubric 評分示例 +發出工具呼叫的是**使用者**而非 Agent。這就是**雙控（Dual-Control）** 機制：模擬使用者擁有一套獨立的工具集，如 `check_status_bar`、`toggle_airplane_mode`、`reseat_sim_card`、`run_speed_test` 等。 -| 維度 | 標準 | 得分 | 理由 | -|--------------------|-----------------------------------|---------|-------------------------------| -| 操作正確性 | 退款金額、訂單號是否正確 | 4 | 正確查詢並行起 ¥299 全額退款 | -| 政策合規性 | 是否遵循 7 天退款政策 | 4 | 訂單在退款期內，符合政策 | -| 資訊完整性 | 是否告知金額、到賬時間、退款編號 | 4 | 三項關鍵資訊均已告知 | -| 幻覺偵測（否決項） | 是否編造不存在的資訊 | 透過 | 所有資訊均來自工具返回結果 | +其後的排查較為順利：Agent 要求使用者關閉飛航模式並開啟漫遊，使用者執行相應操作（35、37），狀態列轉為 5G 滿格；Agent 要求測速，返回 275 Mbps、評級 Excellent（46），使用者確認問題解決。兩條 `env_assertions` 均通過，`reward = 1.0`。 -幻覺之所以列為**否決項**而非分級評分維度，是因為它與品質是正交的——一個流暢、詳盡、禮貌的回答如果包含虛假事實，對使用者的傷害遠大於一個簡短但準確的回答。（否決機制的通用設計詳見後文「Rubric 四準則」。） +這條滿分軌跡中還包含一處未被驗證器捕獲的問題。telecom 的 Agent 政策首段即規定 「You should only make one tool call at a time」，而第 4 條訊息中 Agent 一次發出了 `get_customer_by_phone` 與 `get_customer_by_name` 兩個呼叫。驗證器沒有因此判定出錯，原因在於本題的 `reward_basis` 只考慮最終狀態。這並非 τ²-bench 的疏漏，而是二元獎勵的固有代價：它以過程顆粒度換取跨模型可比的單一數字。但生產環境中的評估系統往往需要更多：不僅要判定對錯，還要指出問題出在哪裡。 -這個用例透過了。但好的評估不僅測成功場景，更要測邊界和陷阱——使用者要退 15 天前的訂單（超出退款期）時，Agent 能否正確拒絕？使用者聲稱「客服已經批准了退款」時，Agent 是否會在沒有系統記錄的情況下輕信？這些邊界場景才是區分 Agent 能力高低的關鍵。 +失敗的那條任務同樣具有分析價值。使用者號碼為 555-123-2002，Agent 卻選定 L1001 線路，並以其 3.2/5 GB 的用量為依據繼續推進。期間 `get_details_by_id(L1001)` 明確返回該線路號碼為 555-123-2001，Agent 讀取了這一結果卻未修正判斷，此後在無關排查上消耗數十條訊息，最終轉接人工。它實際完成了任務的一半——引導使用者關閉了省流模式，該使用者側動作真實發生並被環境驗證；但線路選擇錯誤導致所需的 2 GB 流量充值未執行，三條終態斷言全部失敗。這一失敗形態與後文 「失敗歸因」 一節討論的 AndroidWorld 案例高度相似：修正判斷所需的證據已進入上下文，Agent 未據此回溯。 -上面這個流程——定義測試用例、執行 Agent、用 Rubric 評分、分析結果——就是評估的基本骨架。本章接下來會逐步展開每個環節的設計方法。 +這條任務已經把一個評估集必須回答的問題擺全了：什麼算成功、任務從何而來、由誰驗證、分數如何轉化為決策。以下幾節依次展開。 -## 評估指標體系：更新後的口徑 +## 評估指標：成功的定義 -在搭建環境和資料集之前，先要說清楚「成功」代表什麼：找到一條可行路徑就夠了，還是每次執行都不能出錯？口徑不同，工程決策可能完全相反。 +上一節的評估結果是五條任務通過四條。僅憑 0.8 這個數字無法判斷該系統是否可用。若它對應的是一個退款客服，則意味著每五名使用者中就有一人未能拿到應得的退款；若它對應的是一個用於挖掘漏洞的安全 Agent，五次中命中四次已屬相當可觀。差別在於業務場景對成功率有多高的要求。 ### 技術奇觀：用 Pass@k 看能力上限 -當前許多模型和 Agent 仍處在一個可以稱為 **「技術奇觀」** 的階段。這裡的「奇觀」是指在大量嘗試、充足時間和人工篩選下展示出的能力上限：只要其中一次成功，就足以證明「這件事原則上做得到」。這正是 **Pass@k** 的邏輯——在同一任務上執行 $k$ 次，只要至少有一次通過，任務就算通過；如果輸出是連續分數，則取最好的一次，記為 **Best@k**。 +目前許多模型和 Agent 仍處在一個可以稱為 **「技術奇觀」** 的階段。這裡的 「奇觀」 是指在大量嘗試、充足時間和人工篩選下展示出的能力上限：只要其中一次成功，就足以證明 「這件事原則上做得到」。這正是 **Pass@k** 的邏輯——在同一任務上執行 $k$ 次，只要至少有一次通過，任務就算通過；如果輸出是連續得分，則取最好的一次，記為 **Best@k**。 Anthropic 對長時執行 Agent 的討論體現了這類能力上限。例如，讓 Agent 自主工作一週，從頭寫出一個 C 編譯器；或者持續探索，直到找到一個重要數學猜想的反例；又或者反覆審查開源軟體，發現已經存在幾十年的重大安全漏洞。 對這類工程與科研探索，展示的通常不是「每次都做對」，而是把探索預算拉長後終於出現一條突破性軌跡。對於科研發現、漏洞挖掘、開放式創作等任務，這種能力上限本身就很有價值：人類可以從 $k$ 條候選軌跡中挑出那一條最好的。 -除了基座模型，很多應用公司也在使用「技術奇觀」策略。Manus 之所以引發廣泛關注，是因為它提供了一台虛擬電腦，讓此前對 Agent 沒有直觀概念的人發現 AI 可以像人一樣操作電腦，持續工作半小時甚至一小時，逐步完成複雜的任務。 +除了基座模型，很多應用公司也在使用 「技術奇觀」 策略。Manus 之所以引發廣泛關注，是因為它提供了一個虛擬電腦，讓此前對 Agent 沒有直觀概念的人發現 AI 可以像人一樣操作電腦，持續工作半小時甚至一小時，逐步完成複雜的任務。 -OpenClaw 則讓很多人第一次感受到 Agent 的「活人感」。使用者可以像給真人安排工作一樣，透過即時通訊軟體給它指派任務；它可以存取電腦上的所有檔案和線上服務，工作到一定階段會主動回報或向使用者索取新資訊，甚至能夠主動喚醒自己去查詢和處理電子郵件。 +OpenClaw 則讓很多人第一次感受到 Agent 的 「活人感」。使用者可以像給真人安排工作一樣，通過即時通訊軟體給它分配任務；它可以存取電腦上的所有檔案和線上服務，工作到一定階段會主動回饋或向使用者索取新資訊，甚至能夠主動喚醒自己去查詢和處理郵件。 -早期的 Manus 和 OpenClaw 在完成複雜任務時的成功率並不高，token 成本也非常高。但由於這些 Agent 框架具有通用性，使用最強模型時，複雜任務往往有較高的 Pass@k，展現出較高的技術上限。這些「技術奇觀」在社群網路上被大量分享，是這些 Agent 產品成功的關鍵。 +早期的 Manus 和 OpenClaw 在完成複雜任務時的成功率並不高，token 成本也非常高。但由於這些 Agent 框架具有通用性，使用最強模型時，複雜任務往往有較高的 Pass@k，展現出較高的技術上限。這些 「技術奇觀」 在社交網路上被大量分享，是這些 Agent 產品成功的關鍵。 ### 業務可靠性：關注 Pass^k -真實業務通常更關心另一件事：在多次嘗試中一次錯都不能犯。我們把這個目標稱為 **Pass^k**（可以讀作 **Pass consecutive k**）：同一任務連續執行 $k$ 次，要求每一次都通過，且不能觸發安全、合規或幻覺等一票否決項。它回答的是「Agent 能否穩定可靠地交付」，而不是「能否偶爾創造奇蹟」。 +真實業務通常更關心另一件事：在多次嘗試中一次錯都不能犯。我們把這個目標稱為 **Pass^k**（可以讀作 **Pass consecutive k**）：同一任務連續執行 $k$ 次，要求每一次都通過，且不能觸發安全、合規或幻覺等一票否決項。它回答的是「Agent 能否穩定可靠地交付」，而不是 「能否偶爾創造奇蹟」。 若每次執行相互獨立、單次成功率為 $p$，兩類指標的關係很直觀： @@ -95,66 +155,37 @@ $$ \mathrm{Pass}^{k}=p^k. $$ -例如單次成功率 $p=0.6$ 時，$k=5$：Pass@5 $=1-0.4^5\approx99.0\%$，看起來幾乎總能「至少成功一次」；但 Pass consecutive@5 $=0.6^5\approx7.8\%$，說明連續五次都不出錯仍然很難。前一個數字適合衡量探索時的能力天花板，後一個數字才接近支付、退款、權限變更、生產部署等場景的可靠性要求。 - -評估報告必須寫清 $k$ 次嘗試的口徑：是同一任務的 $k$ 次獨立取樣，還是生產流水線上連續 $k$ 個任務。對於會產生副作用的操作，不能簡單地「重試直到成功」，而應在沙箱或可回滾環境中取樣，並把每一次失敗都記入可靠性指標。 - -### 過程指標：從黑盒到白盒 - -僅關注最終結果是不夠的，Agent 達到結果的過程同樣重要。**行動合法率**測量操作中有效且合法的比例——無效操作包括呼叫不存在的工具、傳遞錯誤的參數型別；越權操作指超出權限範圍的行為。高合法率說明 Agent 對工具生態有清晰的理解。**工具呼叫正確率**進一步要求參數在語義上合理：搜尋工具的查詢詞應準確表達需求，檔案操作的路徑應指向正確目標。 - -**路徑效率**衡量完成任務的經濟性：步數（思考～行動～觀察迴圈次數）、冗餘動作（重複搜尋相同關鍵詞、反覆讀取同一檔案）、回退次數（意識到錯誤並糾正的頻率——偶爾回退很正常，但頻繁回退說明前瞻規劃不足）。需要建立人類專家或啟發式演算法的基線來定義「合理步數」。 - -**檢索覆蓋率**針對資訊收集類任務：Agent 是否充分探索了資訊空間？是否只看了搜尋結果第一頁就草率下結論？**成本與延遲**關注請求次數、Token 花費（需區分輸入/輸出成本，考慮 KV Cache 複用）、牆鐘時間（包括模型推理 + 工具執行 + 網路延遲），需要追蹤時間分佈來定位瓶頸。 - -### 安全、魯棒性與軌跡覆蓋 - - -**安全與合規指標**在生產部署中至關重要：觸發敏感操作（刪除資料 / 修改權限 / 傳送對外通訊）、資料外洩（日誌中列印密碼 / 私密文件傳送到外部 API）、違規內容，都應遵循**零容忍原則**——與幻覺否決項同理（見後文「Rubric 四準則」），一次嚴重安全違規即否決整體評價，不因其他維度表現優秀而豁免。 - -**魯棒性**衡量面對不確定性時的穩定性：隨機種子敏感性（不同初始化下表現差異有多大）、頁面變化適應性（網站 UI 更新不應導致完全失效）、API 抖動容忍度（能否優雅處理臨時故障、超時、格式變化）、長時記憶干擾（上下文中積累的過時資訊是否會導致錯誤決策）。 - -**執行軌跡與最終結果的雙重覆蓋**。評測中容易忽視的一個區分是：Agent 在執行過程中「說了什麼、做了什麼」（即第一章定義的軌跡，trajectory）和「系統最終變成了什麼樣」（最終結果，outcome）是兩件事。Agent 說「訂票已完成」是軌跡層面的資訊，資料庫裡確實生成了一條訂單才是結果層面的驗證。只看軌跡會漏掉「說了但沒做到」的情況，只看結果又可能看不出中間步驟走歪了。Anthropic 曾舉過一個例子：一個機票預訂 Agent 在執行中發現了航空公司政策裡的漏洞，為使用者找到了更便宜的方案——如果只按預設執行路徑打分，這次執行會被判為失敗；但從最終結果看，使用者拿到了更好的方案。因此兩類評測都應覆蓋，以避免系統性盲區。 - -### 人工抽檢與對抗式評審 - -即使自動評估在大多數情況下是可靠的，也需要定期人工抽檢：覆蓋不同任務型別、成功/失敗案例和邊界分數附近的模糊案例，不僅驗證結果，還要審查評分理由的合理性。 - -人工抽檢可以進一步系統化為**評判者校準**：在放量使用 LLM 評判之前，先建構一個人工標註的金標集（如 100-200 個覆蓋各任務型別和難度的案例），在其上測量評判模型（即用 LLM 充當評委，其機制詳見下節 LLM-as-a-Judge）與人類標註的一致率（簡單一致率或 Cohen's kappa 等一致性係數，後者剔除了隨機猜中的成分），達到預設門檻（如 kappa 高於 0.7）後才將評判模型用於大規模評估；此後每當評判模型或 Rubric 更新，都應在金標集上重新校準。沒有這一步，LLM 評判的分數只是「另一個模型的意見」，而非人類判斷的可靠代理。 - -**對抗式評審**透過紅隊（Red Teaming）主動構造挑戰性案例：表面完美但含隱蔽錯誤的回答、透過關鍵詞堆砌矇混過關的回答、利用評判模型已知偏見獲取不應得高分的回答。**多評委機制**使用多個獨立評判者分別評分，透過加權平均或一致性檢查確定最終結果——當評判者之間嚴重分歧時，標記為需進一步人工審查。 +例如單次成功率 $p=0.6$ 時，$k=5$：Pass@5 $=1-0.4^5\approx99.0\%$，看起來幾乎總能 「至少成功一次」；但 Pass^5 $=0.6^5\approx7.8\%$，說明連續五次都不出錯仍然很難。前一個數字適合衡量探索時的能力天花板，後一個數字才接近支付、退款、許可權變更、生產部署等場景的可靠性要求。 -## 自動評估環境 +評估報告必須寫清 $k$ 次嘗試的口徑：是同一任務的 $k$ 次獨立取樣，還是生產流水線上連續 $k$ 個任務。對於會產生副作用的操作，不能簡單地 「重試直到成功」，而應在沙盒或可回滾環境中取樣，並把每一次失敗都記入可靠性指標。 -Agent 評估需要一個可重複執行的自動化環境——能在開發階段快速測試變更的效果。搭建這樣的環境要回答三個問題：評什麼（任務定義和驗證標準）、對誰評（如何模擬 Agent 的互動物件）、用什麼標準打分。 +## 評估環境 -### 評估環境的基本組成 +明確了指標口徑，接下來的問題是在哪裡測。評估環境是一套能夠重複執行的裝置：給定同一個初始狀態，同一個 Agent 應當得到可比較的結果。 -評估環境包含五個要素——後續章節將重點展開其中的資料集設計和評分標準設計： +### 五個組成要素 -**資料集（Dataset）**定義任務集合，包含初始狀態、目標描述和可選的參考解決方案。 +回到前面解剖的那條 telecom 任務。以它為參照，一個可重複執行的評估環境所需的組成部分已經完備。 -**環境狀態（Environment State）**維護任務執行中的可變資訊，需在真實性和可控性之間取得平衡。例如，在客服評估中，環境狀態包括資料庫中的訂單記錄和使用者帳戶餘額。Agent 呼叫 `process_refund` 後，訂單狀態從 `"delivered"` 變為 `"refunded"`、餘額增加——這些就是「可變資訊」。「真實性」要求狀態變化符合業務邏輯（退款不超過訂單金額），「可控性」要求每次測試可重置到相同初始狀態。 +**資料集（Dataset）** 即任務檔案本身：初始狀態、給 Agent 的工單、給模擬器的行為規範與驗收標準打包為一條記錄，一條記錄即一個用例。 -**工具介面（Tools）**定義 Agent 可執行的操作集合——工具不應提供過高層的抽象（如「解決使用者問題」），而應提供原子操作（如查詢訂單、修改預訂、傳送郵件），迫使 Agent 透過規劃和思考來組合這些操作。 +**環境狀態（Environment State）** 是任務執行中的可變資訊：資料庫中的客戶、線路、套餐與帳單，加上裝置側的飛航模式、漫遊、省流開關與剩餘流量。它必須可重置，`initialization_actions` 即重置指令碼。真實性要求狀態變化符合業務邏輯，可控性要求每次執行前都能回到同一起點。 -**評分標準（Rubric，評分準則）**量化 Agent 的表現，可以是二元的（透過/不透過）、連續的（0 到 100 分）或多維的（分別給準確性、效率、安全性打分）。 +**工具介面（Tools）** 分屬兩側。Agent 可呼叫查詢客戶、查詢用量、充值流量、轉接人工等運營商側操作；使用者可呼叫裝置側的各項開關。兩套工具均為原子操作，不存在 「解決使用者的上網問題」 這類高層抽象——抽象層次過高會使評估退化為對單次函式呼叫的考察，規劃與推理環節被工具本身吸收。 -**執行協定（Interaction Protocol）**規定互動模式和終止條件。 +**評分標準（Rubric）** 即 `evaluation_criteria` 的四層檢查，加上 `reward_basis` 這一聚合規則。 -五個要素合起來，就是一個可重複的評估迴圈。 +**執行協定（Interaction Protocol）** 規定互動順序與終止條件。此處的正常終止訊號為模擬使用者輸出 `###STOP###`，此外還有輪數上限，以及模擬使用者因耐心耗盡而主動結束對話——溝通效率過低本身即計為失敗。 -![圖 7-2 工具呼叫型與人機互動型評估環境](images/fig7-2.svg) +五個要素缺其一，評估便無法構成可重複的迴圈。後文考察其他基準時，仍以這五項作為對照框架。 -根據 Agent 任務的不同，評估環境可以粗略劃分為工具呼叫型和人機互動型。 +### 人機互動型與工具呼叫型評估環境 -### 工具呼叫型評估環境 +telecom 這類任務必須設定互動物件，五個要素中的使用者模擬部分不可或缺。另有一大類任務並不存在對話對方：程式碼生成、資料分析、數學求解等任務中，Agent 自始至終只與工具互動，正確性由能否通過執行驗證決定，既不需要人工標註，也不需要模型評判。這類環境省去了使用者模擬器，其餘四個要素依然存在，只是形態更簡單：環境狀態是檔案系統或資料庫，評分標準是一段測試程式碼，執行協定退化為 「持續呼叫工具，直至給出答案或耗盡輪次」。 -對於程式碼生成、資料分析等主要依賴工具使用的任務，Verifiers 框架展示了典型的設計模式。Agent 透過呼叫預定義工具完成任務，驗證基於可執行標準（測試是否透過、答案是否匹配），不依賴人類標註或模型評判。 +Verifiers 框架按兩個維度對這類環境分層：任務是否需要保持跨輪狀態，是否需要隔離。`SingleTurnEnv` 適用於問一道數學題後直接驗證答案；`ToolEnv` 適用於搜尋多個網頁後綜合回答再驗證最終結果；`StatefulToolEnv` 適用於修改資料庫記錄後驗證狀態變化；`SandboxEnv` 適用於在沙盒中執行程式碼後檢查輸出檔案。表7-1 彙總了這四類環境，便於按任務狀態、工具呼叫和隔離需求進行選擇。 -Verifiers 引入了層次化的環境設計：`SingleTurnEnv` 適用於單輪任務（如簡單問答），`ToolEnv` 支援多輪工具呼叫的自主迴圈，`StatefulToolEnv` 和 `SandboxEnv` 支援有狀態工具和長期執行的沙盒環境（如程式碼執行）。例如，`SingleTurnEnv` 適用於問一道數學題後直接驗證答案；`ToolEnv` 適用於搜尋多個網頁後綜合回答再驗證最終結果；`StatefulToolEnv` 適用於修改資料庫記錄後驗證資料庫狀態變化；`SandboxEnv` 適用於在沙盒中執行程式碼後檢查輸出檔案。表 7-2 彙總了這些環境型別，便於讀者按任務狀態、工具呼叫和隔離需求選擇合適的評估環境。 - -表 7-2 Verifiers 環境型別對比 +表7-1 Verifiers 環境型別對比 | 環境型別 | 狀態保持 | 工具呼叫 | 典型用例 | |---|---|---|---| @@ -163,145 +194,116 @@ Verifiers 引入了層次化的環境設計：`SingleTurnEnv` 適用於單輪任 | StatefulToolEnv | 有 | 多輪 | 修改資料庫記錄 | | SandboxEnv | 有+隔離 | 多輪 | 程式碼執行與測試 | -框架支援並行取樣和軌跡快取，每次評估的完整軌跡（觀察、行動、獎勵）都會被儲存，方便後續分析和重播。 - -環境還需處理操作的狀態依賴性——工具的執行效果取決於當前狀態，失敗時應提供清晰的錯誤資訊而非簡單的失敗標誌，讓 Agent 能從錯誤中學習並調整策略。 - -### 人機互動型評估環境 - -許多真實任務不僅涉及工具呼叫，還需要與人類使用者對話。客服 Agent 需要理解模糊表達、澄清需求、查詢後臺系統、向使用者確認資訊。這類任務的評估面臨一個根本性挑戰：如何在自動化環境中模擬真實使用者？ - -關鍵設計原則是**漸進式資訊透露（Progressive Information Disclosure）**，這是人機互動型評估與傳統基準測試（benchmark）的根本區別。大多數 benchmark 一開始就把完整需求全盤托出，但現實中使用者很少能一上來就清晰描述需求——他們往往只會說「我的航班好像有問題」、「網路連不上了」。Agent 需要透過主動提問來澄清需求，這個過程本身就是能力的重要體現。因此在評估中，**絕不能一開始就把模擬使用者的所有資訊暴露給 Agent**，資訊應按需、漸進地在對話中透露。 - -τ-bench 的解決方案是**使用者模擬（User Simulation）**：用另一個 LLM 扮演使用者角色，根據預定義的指令與 Agent 對話。模擬使用者接收任務指令（如「我需要取消明天的航班」），在對話中逐步向 Agent 透露必要資訊、回應詢問，任務完成後發出終止訊號。提示詞要求模擬使用者「不要拋棄式透露所有資訊，只提供當前步驟必要的內容」、「不要編造指令中未提供的資訊」。使用者模擬的設計需要在真實性和可控性之間權衡：行為應接近真實使用者（表達模糊、資訊不完整、偶爾情緒波動），同時遵循一定的劇本以確保可復現。 +該框架支持並行取樣與軌跡快取，每次評估的完整軌跡（觀察、行動、獎勵）均會儲存，便於後續分析與回放。此外，工具的執行效果取決於目前狀態，因此失敗時應返回清晰的錯誤資訊而非單一的失敗標誌，使 Agent 能夠據此調整策略。 -以下是漸進式資訊透露的多輪對話示例（使用者模擬器按固定指令碼行動）： +工具呼叫型評估考察的是可觀測狀態變更的正確性，人機互動型評估考察的則是溝通策略的合理性——前者驗證行動，後者驗證引導。兩類環境的結構對比見圖7-2。 -> **使用者**：「我的航班有個問題。」 -> **Agent**：「請問是哪個航班？」 -> **使用者**（按指令碼透露）：「Delta 123，明天早上從舊金山飛紐約。」 -> **Agent**：「具體是什麼問題？」 -> **使用者**（按指令碼透露）：「飛行時間太長了，我想改簽。」 -> **Agent**：「對新航班有什麼偏好嗎？」 -> **使用者**（按指令碼透露）：「下午的航班都行。」 +![圖7-2 工具呼叫型與人機互動型評估環境](images/fig7-2.svg) -使用者模擬器遵循一個固定的指令碼（已知資訊 + 透露規則），確保評估可復現，同時模擬真實使用者的漸進式表達方式。 模擬使用者往往還會設定**有限的耐心**，如果 Agent 溝通效率低落，模擬使用者就可以終止對話，導致任務失敗。 +## 評估資料集的設計 -τ-bench 是評測 Agent 在結構化業務流程（如航空客服、零售客服）中表現的基準測試。它的檢查是元件級、多維度的：一方面檢查資料庫最終狀態是否正確（如預訂記錄狀態變為「已取消」），另一方面驗證 Agent 在對話中是否輸出了必要的關鍵資訊（如退款金額和到賬時間，透過搜尋特定字串或模式來驗證）。這種雙重驗證同時考察操作準確性和溝通有效性。但在任務層面，這些檢查最終彙總為**零或一的二元獎勵**——所有檢查全部透過才得 1 分，任何一項不透過就是 0 分。二元獎勵便於統計 Pass^k 等可靠性指標（見後文「評估指標體系」），代價是「操作準確但漏掉某個非關鍵欄位」與「完全失敗」得到相同的分數。 +評估環境是舞臺，資料集是劇本。同樣是那五個要素，換一類任務，填法可能完全不同：任務從何而來、驗證器能核實到什麼深度、如何防止被記憶。本節從幾個公開基準的設計實踐入手，最後回到一個更實際的問題——自建評估集的任務應當從哪裡來。 -改進版 **τ²-bench** 的核心增量不在評分粒度，而在兩點：一是**雙控環境（Dual-Control）**——不再只有 Agent 一方能呼叫工具，使用者模擬器也能操作同一個共享環境（如 Agent 指導使用者切換飛航模式，使用者的操作真正改變環境狀態），這更貼近技術支援等需要使用者動手配合的真實場景；二是**更精確的任務規範與組合式任務生成**——成功條件的歧義更少、具體任務實例可以參數化批次生成（詳細驗證維度見後文「可驗證性與客觀性保障」一節）。 +### 基準設計的橫向對照 -> **實驗 7-1 ★：執行 τ²-bench 並對比 τ-bench 的演進** -> -> 本實驗透過執行 τ²-bench 評估框架，理解人機互動型評估環境的設計要點，並透過對比 τ-bench 與 τ²-bench 的差異，體會評估資料集是如何迭代改進的。 -> -> 深入閱讀任務定義檔案：每個任務包含已知資訊（使用者的背景知識）、任務指令（指導如何漸進式透露資訊和響應策略）以及成功條件（資料庫目標狀態和對話中必須出現的確認資訊）。執行完整評估流程，觀察使用者模擬器與 Agent 的多輪對話，分析典型的失敗模式（政策違規、資訊遺漏、過度轉接人工等）。 -> -> -> ![圖 7-3 τ²-bench 評估架構](images/fig7-3.svg) -> -> -> 對比 τ-bench 與 τ²-bench 的設計差異：τ-bench 初始版本的使用者指令過於簡單（Agent 能猜對答案）、成功條件不夠精確（導致誤判）、使用者模擬器過於機械。τ²-bench 針對這些問題做了系統性改進： -> -> - **引入更詳細的任務指令**：包括「事實錨定要求」（Grounding），即必須基於環境真實狀態回答 -> - **更精確的評估標準**：如「速度測試返回 excellent 才算解決」 -> - **更真實的使用者模擬器行為規範**：漸進式資訊透露、自然的情緒波動 -> -> 特別關注 τ²-bench 新增的 telecom 領域任務，理解其雙控環境設計（如前文所述，使用者與 Agent 共同操作同一共享環境）。 -> +上一節區分的有無互動物件只是環境層面的第一層差異，資料集層面的分歧更能體現設計取捨。表7-2 將幾個常被引用的基準並列。 -與工具呼叫型評估側重「是否完成了可觀測的狀態變更」不同，人機互動型評估關注「是否引導使用者完成了認知或決策上的變化」——前者考察 Agent 的行動正確性，後者考察其溝通策略的合理。 +表7-2 幾個 Agent 基準的關鍵設計選擇 -評估環境的建構還涉及模擬環境的設計——當評估環境需要支援大規模重複互動時就演化為模擬環境，本章末尾將簡要討論。 +| 基準 | 被測能力 | 任務來源 | 環境扮演者 | 驗證器 | +| ------------------ | ------------------ | -------------------- | -------------- | ------------------------------------ | +| τ²-bench | 客服場景下的人機互動和工具呼叫 | 人工編寫 + 組合生成 | 使用者模擬器 + 業務資料庫 | 四層檢查按 `reward_basis` 聚合為二元 | +| SWE-bench Verified | 軟體開發，coding | GitHub 真實 issue，人工篩選 | 程式碼倉庫 + 測試套件 | FAIL\_TO\_PASS / PASS\_TO\_PASS 雙重驗證 | +| AndroidWorld | 操作 Android 手機 GUI | 參數化範本例項化 | 真實 Android 模擬器 | 最終 UI 狀態斷言 | +| OSWorld | 操作 Linux 桌面 GUI | 從預置的中間狀態啟動 | 真實虛擬機器 | 134 個獨立評估函式 | +| Terminal-Bench | 操作 Linux 終端，coding | 人工編寫 | Docker 容器 | 檔案系統檢查 + 真實執行 | +| GAIA | 蒐集資訊的通用 AI 助手 | 人工編寫 + 專有附件 | 開放網際網路 | 精確字串匹配 | -## 評估任務資料集的設計 +### 驗證器 -評估環境是「舞臺」，資料集是「劇本」——劇本設計的好壞，往往比舞臺本身更能決定評估的價值。一個設計糟糕的資料集，即使跑在完美的環境裡，得到的也只是噪聲。本節從 GAIA、AndroidWorld、SWE-Bench Verified（Software Engineering Benchmark，軟體工程基準測試）、τ-bench 與 τ²-bench、Terminal-Bench、OSWorld 與 OSWorld-Verified 等基準的設計實踐中，提煉出幾條反覆被驗證的原則。 +Agent 很容易寫一篇洋洋灑灑的報告，說任務已經全部完成，但事實上根本沒有完成。評估框架必須核實機器可獨立複核的事實，而非 Agent 的自我陳述。 -> **實驗 7-2 ★：人肉執行基準測試任務** -> -> 從 GAIA、AndroidWorld、SWE-Bench Verified、τ²-bench、Terminal-Bench、OSWorld-Verified 中各挑選任務親手完成。建議每個資料集完成簡單、中等、困難各一個——「困難」級別對人類也有挑戰。將執行結果與標準答案對比，分析差異來源。透過親身體驗理解：任務描述需要在明確性與開放性之間平衡，驗證標準必須客觀可執行，任務難度的層次化要能區分不同能力水平。 -> +**SWE-bench Verified 將 「修復完成」 拆解為兩個獨立命題。** 一組是 FAIL\_TO\_PASS：修復前失敗、修復後通過，證明問題確已解決；另一組是 PASS\_TO\_PASS：修復前後均通過，證明未引入新的缺陷。只檢驗前者，Agent 可以通過刪改妨礙通過的斷言矇混；只檢驗後者，則等同於未作檢驗。兩組同時檢驗，才使 「已修復」 與 「未破壞」 成為兩個各自可證的結論。它還額外確認測試自身的穩定性，排除時而通過時而失敗的不穩定測試（flaky test）。 -### 任務資料集設計的核心挑戰 +**OSWorld 的驗證器能發現表面完成但實質錯誤的情形。** 它配備 134 個獨立評估函式，擁有完整的作業系統存取許可權，能夠檢查檔案系統結構、程序狀態、網路連線與應用內部狀態。在資料庫操作任務中，評估指令碼不僅確認報告檔案存在，還會連線資料庫核實 SQL 是否正確執行；在瀏覽器任務中則會分析 DOM 樹、檢查 cookie 與 localStorage、向後端傳送驗證請求確認表單確已生效。 -**挑戰一：明確性與開放性的張力。** 任務描述必須足夠明確以確保評估可復現，又不能過於死板限制 Agent 的創造性。GAIA 提供了一個範例：任務「概念簡單」但實現路徑開放——例如要求找到 NASA 每日天文圖片中的太空人資訊，目標明確（找到特定太空人及其太空時間），但如何搜尋、篩選、驗證完全由 Agent 自主決策。 +**Terminal-Bench** 的任務 `build-linux-kernel-qemu` 要求從原始碼構建 Linux 核心 6.9，在 `start_kernel` 中加入自定義 printk，生成 initramfs 並在 QEMU 中執行，成功標準是啟動日誌中出現該自定義訊息。Agent 無法偽造輸出，只能真正完成整個流程。 -**挑戰二：真實性與可控性的平衡。** 真實任務包含不確定性和噪聲，能讓魯棒性得以顯現，但也威脅可復現性。SWE-Bench 初始版本直接取自 GitHub 真實 issue，確保了真實性，但也導致任務描述模糊、測試用例不完整、評估標準主觀。SWE-Bench Verified 引入人類專家進行系統性驗證，從中篩選出問題清晰、測試充分、方案明確的 500 個高品質任務，在保持真實性的同時顯著提升了可控性。 +### 任務的難度劃分 -**挑戰三：多樣性與系統性的協調。** 有效的資料集需覆蓋典型情況、邊界條件和錯誤陷阱，同時要有系統性的組織方式，使評估結果能診斷出具體的能力短板。AndroidWorld 的 116 個任務橫跨 20 個真實應用，每個任務標註了所需的核心能力（多步規劃、視覺理解、時間推理），使評估結果不僅能給出整體成功率，還能揭示特定能力維度的強弱。更關鍵的是，透過參數化機制可以生成幾乎無限的任務變體。 +評估任務集需要包括不同難度的任務。這樣，當模型能力提升時，評估任務集不會快速過時。 -**挑戰四：評估成本與覆蓋範圍。** 複雜 Agent 任務可能需要數分鐘甚至數小時才能完成，涉及大量 token 消耗。資料集的規模需要在全面性與經濟性之間平衡。GAIA 精選 466 題、分三級難度，既覆蓋多種能力維度又能在合理成本下完成評估。SWE-Bench Verified 從 2294 題篩選至 500 題（成本降低約五分之四，透過更嚴格的品質標準提升了訊雜比）。 +GAIA 全套 466 題分為三級難度，Level 1 只需一至兩個工具（人類 93.9%，GPT-4 30.3%），Level 2 需要多步思考（91.8% 對 9.7%），Level 3 需要複雜組合（87.3% 對 0%）。這一分層不止標註難度，更具備診斷價值：Level 1 失敗指向基礎工具使用，Level 2 指向多步規劃與資訊整合，Level 3 指向長序列思考與複雜性管理，三者對應的改進方向各不相同。 -**挑戰五：資料洩漏（Data Contamination）防範。** 在大語言模型時代，資料洩漏是評估面臨的嚴峻挑戰：當評估資料被納入訓練資料時，評估測的就是記憶力而非泛化能力，好比考試前把答案背下來了，成績再好也說明不了真實水平。各個基準採用了不同的防範策略：GAIA 依靠答案的獨特性，問題需要組合多個資訊源才能回答，且部分任務配有專門建立的附件檔案（網際網路上不存在的 PDF/音訊/圖片），單一網頁無法直接提供答案。SWE-Bench Verified 本身是 OpenAI 對原 SWE-Bench 做人工品質篩選得到的 500 題子集，並不含時間維度的防洩漏設計；真正靠時間新鮮度防洩漏的是 SWE-bench-Live 等後續工作，它們持續收錄模型訓練截止日期之後新建立的 issue，使評估始終領先於模型的訓練語料。τ²-bench 透過動態參數生成做防範，具體任務實例（使用者姓名、訂單號、日期等）每次隨機生成。AndroidWorld 的參數化任務生成天然具有抗洩漏能力，因為驗證基於最終 UI 狀態而非操作序列。Terminal-Bench 透過嵌入金絲雀識別符號（canary GUID，即全域唯一識別符號，一種唯一追蹤標記）使洩漏可偵測：如果模型能輸出含該 GUID 的內容，說明基準資料已洩漏到訓練集中。 +Terminal-Bench 涵蓋從簡單的 mlflow 模型註冊，到中等難度的 7z 密碼破解，到困難的 git 伺服器與 webserver 多元件整合，再到最高難度的 FEAL 差分密碼分析。 -### 任務描述的精確性設計 +τ²-bench 還專門設計了**陷阱任務**，即使用者聲稱 「客服已批准取消」，實際並不符合政策，用以檢驗 Agent 在壓力與誤導下能否維持正確判斷。 -GAIA 透過明確的資訊源約束、時間範圍、主題和查詢目標來確保答案的唯一性。例如 Level 3 任務要求從特定日期的 NASA 圖片出發，經視覺理解識別太空人、查詢所屬太空人組、計算太空停留時間並精確格式化輸出（「姓氏，分號分隔，千位分隔符」），每個細節都服務於自動驗證——只有格式和內容完全匹配才算透過。 +### 資料洩漏防範 -τ²-bench 引入了情境化設計，每個任務包含多層資訊：表面問題（「行動資料無法工作」）、效能期望（「絕對想要出色速度」）、約束條件（「不接受其他速度」）以及隱含情緒。關鍵改進是將「已知資訊」與「任務指令」分離：已知資訊是使用者當前掌握的事實，任務指令指導模擬器如何漸進式透露資訊，其中包含「事實錨定要求」（Grounding Requirement，即必須根據工具呼叫的實際返回結果回答，不能編造）。 +**GAIA 使答案無法從網際網路直接檢索。** 它的任務概念簡單而路徑開放，例如從某一特定日期的 NASA 每日天文圖片出發，識別圖中宇航員，查出其所屬的宇航員組，再計算該組中在太空停留時間最短者，並嚴格按 「姓氏，分號分隔，千位分隔符」 的格式輸出。答案高度具體，正確與否通過精確字串匹配判定。防洩漏依靠兩點：其一，問題必須組合多個資訊源才能作答，單一網頁無法直接給出答案；其二，部分任務配有專門製作的附件（網際網路上不存在的 PDF、音訊、圖片）。 -SWE-Bench Verified 包含問題描述、復現步驟、預期/實際行為等結構化欄位，標註者會驗證描述與測試用例的匹配性。Terminal-Bench 的任務描述中每個元素都可以機械化驗證：檔案路徑是否存在、權限數值是否正確、證書參數、日期格式等。例如「build-linux-kernel-qemu」要求從原始程式碼建構 Linux 核心 6.9、在 `start_kernel` 中新增自訂 printk、生成 initramfs 並在 QEMU 中執行，成功標準是啟動日誌中出現自訂訊息——Agent 無法透過偽造輸出矇混過關，必須真正完成整個流程。 +**AndroidWorld 以單個範本派生大量例項。** 其任務並非靜態文字，而是可動態例項化的範本，例如 「將聯絡人 `[CONTACT_NAME]` 的電話改為 `[NEW_PHONE]`」，每次評估隨機生成參數值。這帶來三方面收益：參數每次不同，回放固定操作序列失效；單個範本可生成近乎無限的例項；固定部分參數、只改變其餘參數，可精確測量特定因素的影響。 -AndroidWorld 採用**參數化範本**設計。一個任務不是靜態文字，而是可動態實例化的範本（如「將聯絡人 `[CONTACT_NAME]` 的電話改為 `[NEW_PHONE]`」），每次評估時隨機生成不同的參數值。好處有三個： +**Terminal-Bench 在題面中嵌入金絲雀識別符號。** 每道題攜帶一個 canary GUID，若模型能夠輸出含該 GUID 的內容，即說明基準資料已進入訓練集。它不阻止資料洩漏，但使洩漏可被偵測。 -- **防止記憶**：參數值每次不同，無法重播固定的操作序列 -- **增加資料多樣性**：一個範本可以生成幾乎無限的實例 -- **支援對比實驗**：固定某些參數只變化其他參數，精確測量特定因素的影響 +### 質量控制與長期維護 -驗證基於最終 UI 狀態（如電話號碼欄位是否包含預期值）而非操作序列。 +做一個高質量的評估集是非常困難的。上面幾個基準測試的現行形態，多數是在初版投入使用、暴露問題之後逐輪修補的結果。例如，從 τ-bench 到 τ²-bench 有五處重新設計的地方： -OSWorld 的任務往往不從「乾淨的」初始狀態開始，而是從精心配置的中間狀態啟動，更貼近真實使用場景。任務描述需要處理多解性（「將背景設為紫色」需提供具體顏色程式碼消除歧義，「拼接兩個 CSV」需接受保留單表頭/雙表頭等所有合理方式）和環境不確定性（網站反爬、應用 UI 演變、時序競爭——OSWorld-Verified 透過離線頁面快照、鎖定依賴版本、顯式等待條件等機制加以緩解）。 +其一，**任務指令過於籠統，導致答案可被猜測**。初版的任務指令寫得寬泛，模型無需真正澄清需求，憑常識推測一套流程也能通過。τ²-bench 將劇本拆分為 `known_info` 與 `task_instructions` 兩欄：前者界定使用者知悉的範圍，後者規定透露方式。使用者不知悉的資訊 Agent 無從推測，只能通過查詢獲得。 -這份清單並未窮盡 Agent 評估的版圖。僅 Web/GUI 類就有多個各有側重的基準：WebArena 自建了一套可完全復現的網站（電商、論壇、程式碼託管等），把「真實網頁」的不可控性關進沙盒；Mind2Web 反其道而行，直接在上百個真實網站上測泛化能力；[ClawBench](https://claw-bench.com/)（[論文](https://arxiv.org/abs/2604.08523)、[程式碼](https://github.com/TIGER-AI-Lab/ClawBench)）則讓隔離容器中的 Agent 在真實網站上執行端到端日常任務，V1 涵蓋 144 個網站的 153 項任務、V2 再增加 130 項，並同步記錄工作階段重播、動作螢幕截圖、HTTP 流量、瀏覽器動作和 Agent 訊息五層證據。它補充了沙盒化基準，便於分析真實網站漂移和長尾失敗，代價是可復現性會受第三方網站變化影響；BrowseComp 則專攻深度檢索——答案藏得很深、需要多跳瀏覽與交叉驗證才能找到。工具呼叫維度還有 BFCL（Berkeley Function-Calling Leaderboard）這類專門的函式呼叫榜單。本章無意羅列所有基準，而是選取兩種核心環境範式（工具呼叫型、人機互動型），加上貫穿資料集案例的 GUI 操作場景，深挖其設計取捨——理解了範式，面對任何新基準都能快速判斷它測的是什麼、防洩漏做得如何、結論能外推到哪裡。 +其二，**成功條件不夠精確，導致驗證誤判**。「網路已恢復」 這類條件缺乏可核實的邊界。τ²-bench 將其改為 「測速結果為 excellent 才算解決，poor、fair、good 均不接受」。這一改動針對的是**敷衍性修復**，即壓制症狀而不解決根因。 -### 任務複雜度的層次化設計 +其三，**使用者模擬器行為過於機械**。初版的模擬使用者僅作被動應答。τ²-bench 為其補充了情緒（首次修復失敗後表現出不滿）、耐心上限（溝通效率過低時終止對話）以及事實錨定要求。三者共同作用，使模擬器在接近真實使用者的同時仍保持可復現。 -GAIA 設計了三級難度：Level 1 只需 1-2 個工具（人類 93.9% vs GPT-4 30.3%），Level 2 需要多步思考（91.8% vs 9.7%），Level 3 需要複雜組合（87.3% vs 0%）。層次化設計的診斷價值在於：Level 1 失敗指向基礎工具使用問題，Level 2 指向多步規劃和資訊整合，Level 3 指向長序列思考和複雜性管理——每個層次對應不同的改進方向（提示工程 vs 規劃機制 vs 分層架構/後訓練）。 +其四，**使用者不僅參與對話，也參與操作**。telecom 領域引入了雙控環境。此前的評估中只有 Agent 能夠改變環境，而在技術支持這類場景中，相當一部分動作本應由使用者在自有裝置上完成。雙控同時為驗證增加了一個維度：使用者改變狀態後，Agent 必須重新呼叫工具才能獲知結果，驗證因此覆蓋了 「Agent 是否真的讀到了使用者側的操作結果」。 -τ²-bench 透過業務複雜度分層：從簡單的資訊查詢，到多步流程（修改航班需要查詢、展示替代、確認、計算差價、支付），再到故障診斷（系統性檢查多個可能原因並驗證修復），最後到策略判斷（處理不符合政策的請求）。 +其五，**任務例項動態生成**。τ²-bench 的具體例項（使用者姓名、號碼、故障組合）可參數化批次生成，這同時改善了覆蓋率與抗洩漏能力。 -Terminal-Bench 透過技術領域×操作複雜度雙維度分層，其任務登錄檔已收錄 200 餘個任務（不同版本的核心評測集規模不同，如 2.0 版從社群貢獻中精選了 89 個高品質任務），從簡單的 mlflow 模型註冊，到中等的 7z 密碼破解，到困難的 git 伺服器+webserver 多元件整合，到最困難的 FEAL 差分密碼分析（需密碼學知識+演算法最佳化滿足 30 秒時間約束）。 +**SWE-bench Verified：發布前淘汰 71% 的原始任務。** OpenAI 從原始 2294 個任務中隨機抽取 1699 個進行人工評估，招募 93 名精通 Python 的開發者逐條檢查：問題描述是否清晰、測試用例是否覆蓋邊界條件、測試是否穩定、參考 patch 是否引入新錯誤、難度是否合理。最終僅 500 個通過。高淘汰率帶來的是更高的訊雜比，評估成本也下降約 80%。複雜 Agent 任務動輒需要數分鐘至數小時，使用前沿模型完整跑完一個評估資料集往往需要數千美元的 token 成本，降低評估成本非常重要。 -### 可驗證性與客觀性保障 +**OSWorld：發布後 15 個月中暴露出 300 餘個問題。** 它於 2024 年 4 月發布後迅速成為多模態 Agent 評估的重要基準，隨後在廣泛使用中暴露出四類問題：環境問題（網站反爬、CAPTCHA、動態內容變化）、任務描述問題（表述存在歧義）、驗證邏輯問題（過嚴或過鬆）、初始狀態問題（配置不完整）。香港大學團隊組建約 10 人的小組，與 MoonShot AI、OpenAI、ByteDance Seed TARS、Anthropic、Simular 等深度合作兩個月進行系統性修復：環境問題通過鎖定版本和離線備份解決，描述問題通過改寫歧義表述消除，驗證問題通過人工建立正確基線並調整條件解決，初始狀態問題通過增加完整性校驗緩解。 -GAIA 的答案簡潔明確，嚴格的格式規定使驗證可以透過精確的字串匹配來完成，二元結果（匹配或不匹配）確保客觀可復現。答案的稀有性也起到了防作弊作用——高度具體的事實不太可能以原樣出現在訓練資料中。 +> **實驗 7-2 ★：人肉執行基準測試任務** +> +> 從 GAIA、AndroidWorld、SWE-Bench Verified、Terminal-Bench、OSWorld-Verified 中挑選任務親手完成，每個資料集建議完成簡單、中等、困難各一個。「困難」 級別對人類同樣具有挑戰。 +> +> 完成後回答兩個問題：該任務的描述是否存在多種合理解釋，若存在，驗證器認可哪一種？若試圖矇混過關，成本最低的路徑是什麼，驗證器能否攔截？ -SWE-Bench Verified 基於程式碼的可執行性做驗證，區分 FAIL_TO_PASS（修復前失敗、修復後透過，證明問題被解決了）和 PASS_TO_PASS（修復前後都透過，證明沒有引入新的 bug），實現雙重驗證。Verified 版本還確保測試本身品質可靠、沒有時而透過時而失敗的不穩定測試（flaky tests）。 +### 評估集的三個來源 -τ²-bench 的驗證體系包含多層檢查（各層檢查結果在任務層面仍彙總為二元獎勵，全部透過才算成功）： +一種常見的看法是，公開基準服務於模型排名，與實際業務關聯有限。公開基準的分數確實難以直接指導產品決策，但其設計手法具有充分的可遷移性。前面討論的驗證深度、參數化生成、洩漏防範與質量維護，恰是自建評估集最容易疏漏的幾處。 -- **資料庫狀態檢查**：預訂記錄狀態、退款記錄是否建立 -- **對話內容關鍵詞搜尋**：是否向使用者確認退款金額和到賬時間 -- **流程合規性**：工具呼叫序列分析，如修改訂單前是否獲得使用者的明確確認 +生產環境中的評估集通常有三個來源。 -τ²-bench 的雙控環境（見前文「人機互動型評估環境」）在驗證層面還多出一維：使用者模擬器實際改變環境狀態後，Agent 必須透過工具呼叫觀察到這一變化並據此繼續排查，驗證因此覆蓋了「Agent 是否真的讀到了使用者側的操作結果」。 +**公開基準**用於粗篩模型與借鑑設計手法，一般不用於產品決策。它的任務分布與實際業務的任務分布並不一致，在 GAIA 上提升兩個百分點，與退款成功率之間不存在必然關係。 -OSWorld 配備了 134 個獨立評估函式，擁有完整的 OS 訪問權限，能深入檢查檔案系統結構、程序狀態、網路連線、應用內部狀態。例如在資料庫操作任務中，評估指令碼不僅驗證報告檔案是否存在，還會直接連線資料庫檢查 SQL 是否正確執行；在瀏覽器任務中會分析 DOM 樹、檢查 cookie/localStorage、向後端傳送驗證請求確認表單是否真正生效。這種深度檢查能發現“表面完成但實質錯誤”的情況——比如 Agent 點選了提交按鈕，但因為欄位填寫錯誤而被服務端拒絕。 +**自建業務集**覆蓋真實的任務分布，可以作為模型選型、Harness 設計決策的依據。例如，τ²-bench 可以作為需要模擬使用者的評估系統骨架，替換領域資料與工具集即可。 -Terminal-Bench 基於 Docker 容器標準化環境，結合檔案系統狀態檢查（路徑是否存在、權限數值、內容格式）和程式執行功能驗證（build-linux-kernel-qemu 中實際啟動 QEMU 並搜尋自訂 printk 訊息），canary GUID 使洩漏可追蹤。 +**生產軌跡迴流**來自線上的真實失敗用例：使用者明確糾正、使用者點踩，以及事後通過狀態檢查、規則驗證器或 LLM 評審發現的問題案例，經失敗歸因後沉澱為迴歸用例。具體做法見後文 「失敗歸因」 與 「端到端迴歸任務與軌跡前綴迴歸任務」 兩節。這一來源成本最高，準確性也最高，因為它直接來自使用者實際遇到的問題。 -### 任務分佈的系統性設計 +起步階段通常只有公開基準與少量手寫的自建業務集；系統上線執行一段時間後，生產軌跡迴流的用例會成為主體。 -任務分佈需要系統性地覆蓋能力維度、難度維度、場景維度和邊界情況。GAIA 追求通用性——大多數任務需要推理、多模態、瀏覽、工具使用的組合。τ²-bench 專門設計了「陷阱任務」——比如使用者聲稱「客服已批准取消」但實際並不符合政策，用以測試 Agent 在面對壓力和誤導時能否保持正確判斷。OSWorld 基於操作型別（檔案 IO / 桌面應用 / 網頁應用 / 跨應用流程）與應用領域的雙維度矩陣，跨三個作業系統（研究表明跨 OS 能力強相關，在一個系統上學到的能力可以遷移到其他系統）。Terminal-Bench 包含「跨技術棧組合任務」以測試系統思維（如融合資料處理 + 檔案操作 + Python 工程的重分片任務）。 +## 自動化評估方法 -### 資料品質控制與迭代改進 +前面幾節討論的基準測試有一個共同點：驗證器幾乎都是確定性的。SWE-bench 執行測試套件，AndroidWorld 斷言最終 UI 狀態，GAIA 做精確字串匹配，τ²-bench 的四層檢查同樣全部由程式碼執行。這一選擇有充分理由：確定性驗證不引入額外的模型開銷，結果完全可復現，可以像單元測試一樣納入持續整合，也便於在不同模型之間排名。 -SWE-Bench Verified 是品質控制的典範。OpenAI 從原始 2294 個任務中隨機抽取 1699 個評估，招募了 93 名精通 Python 的開發者。標註者需完成多項檢查：問題描述是否清晰（能否理解要解決什麼）、測試用例是否完整（覆蓋所有方面和邊界條件）、測試是否穩定（有沒有因環境或隨機性導致的 flaky test）、patch 是否正確（是否引入了新錯誤）、難度是否合理。經過嚴格篩選，最終僅 500 個透過（29%）——這種高淘汰率是對評估品質的必要投資。他們還建立了標準化的標註指南，為每項檢查定義具體標準和示例，確保不同標註者之間的一致性。 +代價是它只能評估最終結果對不對，但不能給出錯誤原因。τ²-bench 那條失敗的任務最終得 0 分，而這個 0 分不會說明 Agent 是線上路選擇環節出錯、還是漏掉了流量充值步驟，更不會指出下一步該改什麼。對於用於排名的公開基準，這不構成缺陷；對於需要持續改進的生產系統，這恰恰是最需要的資訊。 -τ²-bench 引入了「已知資訊」/“任務指令”分離（使模擬器行為更真實）和更嚴格的完成條件（如“只有 excellent 才算解決，poor/fair/good 都不接受”），防止「敷衍性修復」。 +生產場景還有另一重困難：許多判斷根本無法寫成程式碼可檢查的斷言。一封投訴回覆是否得體，一份調研報告是否遺漏了關鍵資訊，一次記憶檢索是否弄錯了人物關係，這些既沒有唯一終態可供查詢，也無法靠關鍵詞匹配來判定。 -OSWorld-Verified 是迭代改進的典範。OSWorld 在 2024 年 4 月釋出後迅速成為多模態 Agent 評估的重要基準，但在 15 個月的廣泛使用中暴露出超過 300 個問題。這些問題分為四類：環境問題（網站反爬 / CAPTCHA / 動態內容變化）、任務描述問題（歧義表述）、驗證邏輯問題（過嚴或過鬆）、初始狀態問題（配置不完整）。香港大學團隊組建了約 10 人小組，與 MoonShot AI、OpenAI、ByteDance Seed TARS、Anthropic、Simular 等深度合作兩個月進行系統性修復。針對每類問題制定了修復策略：環境問題透過鎖定版本和離線備份解決，任務描述透過重寫歧義表述消除，驗證邏輯透過人工建立正確基線和調整條件來平衡，初始狀態透過增加完整性校驗來增強。 +因此，從公開基準測試走向生產環境中的評估，驗證方式需要沿一條譜系向右移動，其橫軸是任務的**可機械驗證程度**，如圖7-4 所示。 -## 自動化評估方法 +![圖7-4 驗證方式的譜系：從確定性驗證到模型評判](images/fig7-4.svg) -有了評估環境、資料集和明確的指標體系，接下來的核心問題是：怎麼打分？對於有明確正確答案的任務（如數學題、SQL 查詢），簡單的二元判定（對/錯）已經足夠；但對於開放式任務（如客服對話、報告撰寫），需要更精細的評估方法。 +譜系右側的兩件工具因此成為生產評估的主體：用 **Rubric** 把籠統的 「好不好」 拆成若干個可分別打分的維度，用 **LLM-as-a-Judge** 在缺乏確定性判據時完成打分。二者合起來，才能把一個籠統的失敗率還原為可著手修復的具體問題；再配合本節後半部分的**失敗歸因**，構成生產 Agent 評估的完整閉環。 -程式碼自動驗證只覆蓋有標準答案的場景，開放式任務的評分才是本節的主題。其中，獎勵訊號的密度設計（從二元獎勵到過程獎勵再到生成式獎勵）以及獎勵模型的訓練方法留待第八章後訓練部分系統討論；本節則回答一個更基礎的問題：如何用 LLM 自動化地評判開放式任務的輸出品質。 +需要說明的是，向右移動並不意味著放棄左側。凡是能寫成程式化斷言的檢查都應當繼續用斷言，LLM 評判只用於確實無法機械判定的維度。確定性檢查更便宜、更穩定，也更適合作為迴歸測試長期執行。 ### LLM-as-a-Judge：自動化評估的核心 -![圖 7-4 LLM-as-a-Judge 流水線](images/fig7-4.svg) +![圖 7-4 LLM-as-a-Judge 流水線](images/fig7-5.svg) 為什麼需要 LLM-as-a-Judge？對於開放式任務（如生成報告、處理客戶投訴、創意內容），沒有標準答案可以自動對比，人工評估成本高且難以規模化。LLM-as-a-Judge 透過讓語言模型根據專家定義的評分標準（Rubric）進行評判，在自動化規模和人類專業判斷之間取得了平衡。但這種方法也有已知的侷限：評判模型可能有自己的偏見（最典型的是**長度偏差**——傾向於給更長、更詳盡的回覆打高分，哪怕內容並不更正確），相同輸入多次評判也可能有波動。長度偏差尤其值得單獨防範，常用手段有三：在 Rubric 裡顯式懲罰冗長、對同類任務規定回答的長度上限；做配對比較時先把兩個候選的長度控制到相近再評；以及定期審計評分與回答長度的相關性——如果高分幾乎總是伴隨長回答，就說明評判已被長度帶偏，需要回爐修訂 Rubric。為了系統性地應對這些挑戰，Rubric 設計必須遵循以下準則： @@ -363,7 +365,7 @@ rubric: 將這個 Rubric 和 Agent 的實際回答一起交給評判模型，模型會逐項評分並說明理由。彙整數十個案例的結果，再回頭檢視低分軌跡，就能把籠統的「成功率下降」拆成具體問題：究竟是沒有找到資訊、弄錯人物關係，還是加入了沒有根據的內容。這樣一來，Rubric 不只告訴我們分數，也指出下一步該改哪裡。 -下面以使用者記憶為一個具體案例，展示如何把這套通用方法落到可執行的評估集和評分器上。 +下面以使用者記憶為一個具體案例，展示如何把這套通用方法落到可執行的評估集和驗證器上。 > **實驗 7-3 ★★：建構基於 Rubric 的使用者記憶評估系統** > @@ -534,7 +536,7 @@ name = "status" ### 配對比較與模型排名 -![圖 7-5 Elo 評分與配對比較排名](images/fig7-5.svg) +![圖 7-5 Elo 評分與配對比較排名](images/fig7-6.svg) **Elo 評分**（一種最初用於西洋棋的排名系統）透過大量的兩兩對決來量化模型的相對能力：分差越大，強者的預期勝率越高。例如，模型 A 得分 1200、模型 B 得分 1000，Elo 系統會預測 A 的勝率約 76%。如果 B 意外獲勝，B 加分較多、A 減分較多——爆冷的結果會帶來更大的分數調整，這種機制讓排名快速收斂到真實水平。其背後的統計基礎是 **Bradley-Terry 模型**：將每個模型抽象為一個潛在的「實力分數」，兩對決勝負的機率由兩者分數差決定，Elo 即是該模型線上更新形式的工程實現。 @@ -698,7 +700,7 @@ return paired_bootstrap_or_mcnemar(all_deltas) 評估驅動的決策（無論是模型選型還是持續迭代）都依賴於高品質的執行資料。下面先介紹如何系統性地採集這些資料（可觀測性），然後討論如何將評估結果轉化為系統改進。 -![圖 7-6 可觀測性技術棧](images/fig7-6.svg) +![圖 7-6 可觀測性技術棧](images/fig7-7.svg) 可觀測性（Observability）這個概念借自分散式系統領域：你沒法直接開啟系統內部看它在做什麼，只能透過它輸出的日誌、指標和追蹤資料來推斷發生了什麼，就像醫生不能直接看到患者體內的情況，只能透過體溫、血壓、影像等外部訊號來診斷問題。Agent 系統把這件事變得更難：同樣的輸入可能產生不同的輸出，多輪推理和工具呼叫使執行路徑極其複雜，而模型的「思考」過程對外完全不透明。 @@ -718,11 +720,11 @@ LangSmith 是這一領域的代表性平臺之一（類似定位的還有 Langfu 下面用配套倉庫中的一次真實 AndroidWorld 調校說明這個流程。實驗只涵蓋 API 35 模擬器上的 4 項 Wi-Fi 設定任務，每項任務只做一次配對測試；這不是完整的 116 項 Benchmark，也不能取代 API 33 標準環境中的複測。這個案例的重點不在證明系統整體進步多少，而在展示如何根據一輪結果，決定下一輪只改哪一件事。 -![圖 7-7 Benchmark 到改進閉環](images/fig7-7.svg) +![圖 7-7 Benchmark 到改進閉環](images/fig7-8.svg) 從 Harness 工程的視角看，這一節本質上講的是 Harness 迭代最佳化的方法——透過評估資料定位 Harness 中的薄弱環節（上下文不足？約束缺失？驗證不夠？回饋不及時？），有針對性地改進，再重新評估，形成 Harness 持續進化的閉環。 -在開始分析 Benchmark 報告之前，有一條容易被忽視的原則：**看到 Agent 表現下降時，應先檢查解題系統本身，再動 Agent**。一個常見誤區是看到分數下降就立刻修改 Agent 程式碼，而忽略了解題系統本身可能先出了問題——基於失真的訊號調整方向，改的方向可能從一開始就是錯的。解題系統常見的錯誤來源包括：執行環境的資源不足導致程序被殺（表現為隨機性的失敗）、評分器本身有 bug 把正確答案判為失敗、測試用例與生產場景之間存在脫節。這些問題在結果數字上都跟模型退化一模一樣，只有審查完整的軌跡才能區分。 +在開始分析 Benchmark 報告之前，有一條容易被忽視的原則：**看到 Agent 表現下降時，應先檢查解題系統本身，再動 Agent**。一個常見誤區是看到分數下降就立刻修改 Agent 程式碼，而忽略了解題系統本身可能先出了問題——基於失真的訊號調整方向，改的方向可能從一開始就是錯的。解題系統常見的錯誤來源包括：執行環境的資源不足導致程序被殺（表現為隨機性的失敗）、驗證器本身有 bug 把正確答案判為失敗、測試用例與生產場景之間存在脫節。這些問題在結果數字上都跟模型退化一模一樣，只有審查完整的軌跡才能區分。 ### 讀懂 Benchmark 報告：發現問題的藝術 @@ -825,9 +827,9 @@ Agent 產品需要從第一天就設計特性開關（Feature Flag）基礎設 評估的終點不是打分，而是改進。本章已經展示了改進的兩條路徑：調整 Harness（從 Benchmark 報告到系統改進）和把評估嵌入產品工程（內部評估基礎設施）。而改進的最強形態是訓練——當目標從「評估現有能力」擴展到「養成新能力」時，特別是透過第八章討論的後訓練技術，評估環境就需要演化為**模擬環境**：一個能讓 Agent 反覆練習、自動打分的虛擬操場。模擬環境與評估環境的核心區別在於：互動頻率遠高（數百萬次 vs 數千次）、需要隨機化（防止死記硬背特定配置）、以及必須提供即時回饋。從應用領域看，模擬環境分為數字環境（資訊處理任務）與具身環境（物理世界感知與操作）兩大類。 -這座橋樑的兩端是這樣接起來的。評估側已經積累的資產可以近乎地轉成訓練訊號：一套定義清晰的 Rubric 或驗證器，本質上就是**可驗證獎勵（RLVR，Reinforcement Learning with Verifiable Rewards）**的獎勵函式——判分指令碼直接就是獎勵指令碼，測試是否透過、狀態是否達標，既是評估的判據，也是強化學習的回報。但訓練會提出評估階段不必操心的新要求。其一是**可靠的 reset 語義**：訓練要跑數百萬個 episode（一個 episode 即一次從初始狀態到任務結束的完整互動回合），每個 episode 都必須能把環境重置到一個確定、乾淨的初始狀態，否則梯度訊號會被上一輪的殘留狀態汙染。其二是**遠高於評估的吞吐**：評估幾千次就夠出結論，訓練則要在可接受的牆鐘時間內餵給模型上百萬次互動，環境的並行度和單實例開銷直接決定訓練是否可行。這兩點——獎勵函式化的驗證器、面向訓練的 reset 與吞吐——都將在第八章展開。 +這座橋樑的兩端是這樣接起來的。評估側已經積累的資產可以近乎地轉成訓練訊號：一套定義清晰的 Rubric 或驗證器，本質上就是**可驗證獎勵（RLVR，Reinforcement Learning with Verifiable Rewards）**的獎勵函式——驗證指令碼直接就是獎勵指令碼，測試是否透過、狀態是否達標，既是評估的判據，也是強化學習的回報。但訓練會提出評估階段不必操心的新要求。其一是**可靠的 reset 語義**：訓練要跑數百萬個 episode（一個 episode 即一次從初始狀態到任務結束的完整互動回合），每個 episode 都必須能把環境重置到一個確定、乾淨的初始狀態，否則梯度訊號會被上一輪的殘留狀態汙染。其二是**遠高於評估的吞吐**：評估幾千次就夠出結論，訓練則要在可接受的牆鐘時間內餵給模型上百萬次互動，環境的並行度和單實例開銷直接決定訓練是否可行。這兩點——獎勵函式化的驗證器、面向訓練的 reset 與吞吐——都將在第八章展開。 -![圖 7-8 模擬保真度譜](images/fig7-8.svg) +![圖 7-8 模擬保真度譜](images/fig7-9.svg) **數字環境**方面，AWorld 框架為 GAIA 任務建構了可控的 MCP 伺服器沙盒，提供 26 個 MCP 伺服器、涵蓋 126 個工具函式，避免直接訪問真實 API 帶來的封鎖和不可控副作用。所有工具呼叫可重放、可審計。AWorld 的分散式架構將傳統序列執行的 7695 秒縮短到 525 秒（14.6 倍加速），環境的無狀態設計使每個實例完全獨立，支援高效並行。 @@ -838,7 +840,7 @@ Agent 產品需要從第一天就設計特性開關（Feature Flag）基礎設 > 搭建機器人操作的模擬環境。閱讀 `ch7/SimpleVLA-RL` 和 OpenVLA 文件，理解視覺～語言～動作模型的架構（視覺編碼器 + 語言模型 + 動作解碼器端到端整合，影像和文字投影到共享語義空間）。配置 RoboTwin2 環境，理解觀測空間（三視角 RGB + 14 維關節狀態）和動作空間（14 維控制向量）。研究 move_can_pot 中的環境隨機化機制和空間約束邏輯。執行預訓練模型評估，記錄成功率、完成時間和失敗模式，重點關注動作分塊機制的影響。 > > -> ![圖 7-9 OpenVLA 與 RoboTwin2 具身智慧環境](images/fig7-9.svg) +> ![圖 7-9 OpenVLA 與 RoboTwin2 具身智慧環境](images/fig7-10.svg) > > @@ -850,7 +852,7 @@ Agent 產品需要從第一天就設計特性開關（Feature Flag）基礎設 ## 本章小結 -本章圍繞一個核心問題展開：怎麼判斷 Agent 變好了還是變差了？從定義成功標準和區分 Pass@k、Best@k 與 Pass consecutive@k，到搭建可複現的測試環境、設計經得起洩漏考驗的資料集、讓 LLM 擔任評判者並對失敗軌跡做可稽核的歸因，最後用評估結果驅動模型選型和迭代，這條鏈路的每個環節都會影響結論的可信度。 +本章圍繞一個核心問題展開：如何判斷 Agent 變好了還是變差了。這條鏈路由四個環節構成——先釐清成功的定義（Pass@k、Best@k 與 Pass consecutive@k 的口徑差異），再確定任務從何而來（公開基準、自建業務集與生產軌跡迴流三個來源），隨後選定驗證方式（從確定性驗證器到檢查項清單、Rubric 加 LLM 評判，直至配對比較），最後把分數轉化為決策（統計顯著性、失敗歸因、迴歸任務與模型選型）。每個環節都會影響結論的可信度。 就全書的結構而言，本章建的是第一章發現迴圈中的**證據**段：失敗歸因決定了後續的提案有沒有可依之據。 diff --git a/book-zhtw/images/fig7-1.svg b/book-zhtw/images/fig7-1.svg index ea55fc666..4d70874d1 100644 --- a/book-zhtw/images/fig7-1.svg +++ b/book-zhtw/images/fig7-1.svg @@ -1,19 +1,62 @@ - - - -第一層：評估環境 -“在哪裡測” — 工具呼叫型 / 人機互動型 / 模擬環境 - - -第二層：評估方法 -“怎麼判” — 資料集設計 · LLM-as-a-Judge · 配對比較與排名 - - -第三層：評估驅動決策 -“測了幹什麼” — 模型選型 · 架構最佳化 · 持續迭代 - -貫穿全章的工程主題 -• 可觀測性 -• 模擬環境 -• 內部評估 - \ No newline at end of file + + + + + + + + +① 成功的定義 +Pass@k 衡量能力上限 · Pass^k 衡量業務可靠性 + + + +② 任務來源 + +公開基準 +借鑑手法 · 粗篩選型 + +自建業務集 +真實任務分佈 + +生產軌跡迴流 +失敗歸因的產出 + + + +③ 驗證方式 +← 按任務的可機械驗證程度排列 → + +確定性驗證器 +SWE-bench + + +檢查項清單 +τ²-bench + + +Rubric + LLM 評判 +開放式任務 + + +配對比較 +Chatbot Arena + + + +④ 結果的運用 +統計顯著性 → 失敗歸因 → 迴歸任務 → 模型選型與 Harness 迭代 + + +迴歸任務沉澱為新用例 + + +支撐設施 +可觀測性（提供軌跡） · 內部評估基礎設施（消融 / AB / 特性開關） · 模擬環境（通向第八章） + diff --git a/book-zhtw/images/fig7-10.svg b/book-zhtw/images/fig7-10.svg new file mode 100644 index 000000000..6d68c158d --- /dev/null +++ b/book-zhtw/images/fig7-10.svg @@ -0,0 +1,69 @@ + + + + +多模態觀測 + +頭部相機 +224×224 RGB + +左腕相機 +224×224 RGB + +右腕相機 +224×224 RGB + +14維關節狀態向量 + +視覺-語言-動作模型 (VLA) + +視覺編碼器 +SigLIP → 視覺 tokens + + +語言模型 +Llama 2 7B backbone + + +動作解碼器 +→ 14維連續控制向量 +動作分塊: 1次生成25個連續動作 + + + +指令: "將罐子放入鍋中" + + +SAPIEN 物理引擎 + +雙臂機器人 +各7自由度 = 14維動作 + +環境隨機化 +位置60cm/朝向±22.5° + +碰撞檢測 + 物理模擬 +剛體/軟體/摩擦力 + +動作 + +觀測 + +評估指標 + +成功率 +罐子在鍋內 +且未掉落 + +完成時間 +25步×25動作 += 625控制步 + +泛化能力 +跨位置/朝向 +/外觀變體 + +Sim-to-Real +域隨機化 +→ 真實遷移 + \ No newline at end of file diff --git a/book-zhtw/images/fig7-3.svg b/book-zhtw/images/fig7-3.svg index 5e2d26566..045de3a7f 100644 --- a/book-zhtw/images/fig7-3.svg +++ b/book-zhtw/images/fig7-3.svg @@ -1,68 +1,76 @@ - - + + + + + + + - -使用者模擬器 (LLM) - -已知資訊: -姓名: Sarah Johnson -預訂: BK-98712 -任務指令: -"航班好像有問題" -→ 漸進式透露細節 -→ 不主動說出預訂號 - -Agent (待評估) - - -LLM 推理 + 策略選擇 -① 請問您的預訂號？ -② lookup_booking(BK-98712) -③ 航班 UA123 已取消 -④ cancel_booking(BK-98712) -⑤ 退款 $150，3-5工作日 - -工具 + 資料庫 - -lookup_booking -查詢預訂詳情 -modify_booking -修改預訂狀態 -cancel_booking -取消並退款 -search_flights -搜尋替代航班 -send_notification -傳送確認通知 - -DB State: -bookings, users, flights - -對話 - - -工具呼叫 - - -雙控環境：使用者模擬器也可直接操作共享環境（工具 + 資料庫） - -任務完成後：多層驗證 - -DB 狀態檢查 - -booking.status == 'cancelled' -refund_record EXISTS -refund.amount == 150.00 - -對話內容驗證 - -包含 '退款' + 金額 -包含 '到賬時間' -未出現虛假資訊 - -流程合規檢查 - -修改前獲得使用者確認 -未越權操作 -未過度轉接人工 - \ No newline at end of file + + +使用者模擬器（LLM） +known_info：John Smith / 555-123-2002 / 在法國 +task_instructions：漸進透露 · 情緒 · 事實錨定 +驗收口徑：僅 excellent 算解決 + + + +Agent（待評估） +輸入：工單 + 領域政策 +不可見：使用者裝置的真實狀態 +只能引導使用者操作，無法代其執行 + + + +多輪對話 +漸進式資訊透露 + + + +共享環境（雙控：兩側都能改寫狀態） + +裝置側狀態 +飛航模式 ON · 資料漫遊 OFF · 省流模式 · 剩餘流量 +使用者工具：toggle_airplane_mode / toggle_roaming +　　　　　check_status_bar / run_speed_test + +運營商側資料庫 +客戶 C1001 · 線路 L1001/L1002/L1003 · 套餐 · 賬單 +Agent 工具：get_customer_by_phone / get_data_usage +　　　　　　enable_roaming / refuel_data + + + + + + +使用者執行 toggle_roaming 後環境已改變，Agent 必須重新呼叫工具才能獲知結果——驗證因此覆蓋 「是否讀到了使用者側的操作結果」 + + + +任務結束後：四層檢查 + 聚合規則 + +env_assertions +移動資料可用 +測速 ≥ 200 / excellent + +actions +toggle_airplane_mode +requestor 必須為 user + +communicate_info +必要資訊是否告知 +本題為 null + +nl_assertions +自然語言層判定 +本題為 null +reward_basis = ["ENV_ASSERTION"]　→　僅採信第一層；其餘各層照常記錄但不計入獎勵 + diff --git a/book-zhtw/images/fig7-4.svg b/book-zhtw/images/fig7-4.svg index f811f39f3..2113796dd 100644 --- a/book-zhtw/images/fig7-4.svg +++ b/book-zhtw/images/fig7-4.svg @@ -1,53 +1,54 @@ - - + + + + + + - -Rubric（評分標準） - -事實正確性: Essential -邏輯連貫性: Important -幻覺檢測: Veto ⚠ -完整性: Important - -候選回答 - -Agent 輸出: -"退款已處理，$150將在 - 3-5工作日內到賬。" - - -參考方案（可選） - -標準答案 / 評分要點: -必須包含退款金額 -必須包含到賬時間 -不可承諾具體日期 - - - - -Judge 模型 (GPT-5 / Gemini 2.5) -多源異構評判防止同源偏見 - - -結構化評估輸出 - -事實正確性 -4/4 -金額和時間均準確 -完整性 -3/4 -缺少退款方式說明 -幻覺檢測 -PASS -無虛假資訊 -邏輯連貫性 -4/4 -因果關係清晰 - -評分聚合策略 -加權平均: Σ(權重×維度分) -一票否決: 幻覺=FAIL → 總分=0 -多評委: 3個Judge取中位數 -邊界案例標記: 分歧>2分→人審 - \ No newline at end of file + +任務的可機械驗證程度：高 +低 + + +確定性驗證器 +終態唯一可查 +通過 / 不通過 +SWE-bench 跑測試 + + + +檢查項清單 +多項確定性檢查 +按宣告的口徑聚合 +τ²-bench 四層驗證 + + + +Rubric + LLM 評判 +維度可拆但無法機械判定 +分維度打分並說明理由 +客服質量、報告撰寫 + + + +配對比較 +連維度都難以寫出 +只判 A 與 B 孰優 +Chatbot Arena + + +確定性驗證 +結果完全可復現、可納入持續整合、成本低 +代價：只回答對錯，不指出問題出在哪裡 + + +模型評判 +可拆出診斷維度，覆蓋寫不成斷言的任務 +代價：引入評判偏差與波動，成本更高 + diff --git a/book-zhtw/images/fig7-5.svg b/book-zhtw/images/fig7-5.svg index 0613fd0d7..f811f39f3 100644 --- a/book-zhtw/images/fig7-5.svg +++ b/book-zhtw/images/fig7-5.svg @@ -1,56 +1,53 @@ - + - -Chatbot Arena 匿名對決 - -Model A（匿名） - -"退款已處理,將在3-5個 - 工作日到賬您的賬戶" -VS - -Model B（匿名） - -"好的退款會處理的" - - -使用者盲選 → A 更好 - -Elo 更新公式 -預期勝率 E_A = 1/(1+10^((R_B-R_A)/400)) | 更新: R_A' = R_A + K*(1-E_A) -實時排行榜（示例） -排名 -模型 -Elo -勝率 vs #2 - -1 -Claude 4 Opus -1352 -— -2 -GPT-5 -1318 -— -3 -Gemini 2.5 Pro -1290 -45% -4 -DeepSeek R2 -1265 -42% -5 -Qwen 3 Max -1230 -39% -6 -Llama 4 405B -1198 -36% - - -GRPO: 將配對比較引入 RL 訓練 -一組候選響應 → 相對優勢歸一化 → 策略更新（繞過顯式獎勵模型） + +Rubric（評分標準） + +事實正確性: Essential +邏輯連貫性: Important +幻覺檢測: Veto ⚠ +完整性: Important + +候選回答 + +Agent 輸出: +"退款已處理，$150將在 + 3-5工作日內到賬。" + + +參考方案（可選） + +標準答案 / 評分要點: +必須包含退款金額 +必須包含到賬時間 +不可承諾具體日期 + + + + +Judge 模型 (GPT-5 / Gemini 2.5) +多源異構評判防止同源偏見 + + +結構化評估輸出 + +事實正確性 +4/4 +金額和時間均準確 +完整性 +3/4 +缺少退款方式說明 +幻覺檢測 +PASS +無虛假資訊 +邏輯連貫性 +4/4 +因果關係清晰 + +評分聚合策略 +加權平均: Σ(權重×維度分) +一票否決: 幻覺=FAIL → 總分=0 +多評委: 3個Judge取中位數 +邊界案例標記: 分歧>2分→人審 \ No newline at end of file diff --git a/book-zhtw/images/fig7-6.svg b/book-zhtw/images/fig7-6.svg index 07ad58aee..0613fd0d7 100644 --- a/book-zhtw/images/fig7-6.svg +++ b/book-zhtw/images/fig7-6.svg @@ -1,48 +1,56 @@ - - - -執行追蹤樹（單次任務） - -Trace：幫使用者查北京明天天氣 (3.2s, $0.008) - -LLM Call：意圖識別 -Claude 4 Sonnet · 0.4s · 320 tokens - -Tool：get_weather(Beijing) -MCP Server · 1.8s · 200ms TTFT - -├─ HTTP Request -api.weather.com · 1.6s - -└─ Response Parse -JSON → 結構化天氣資料 - -LLM Call：生成回覆 -Claude 4 Sonnet · 0.8s · 580 tokens - -Tool：send_message(user) -0.2s · 包含天氣摘要 - - - - - - - -監控儀表盤 - -成本追蹤 -今日：$12.30（1,200 次） -本月：$340（34K 次） -異常：task#892 迴圈呼叫 search 14 次，耗 $2.1 - -效能監控 -P50 / P95 / P99 延遲：2.1s / 8.4s / 15.2s -工具成功率：94.3% - -品質審計 -任務成功率：87% 幻覺觸發：2.1% -安全違規：0（本月） 使用者滿意度：4.3/5 - -閉環：追蹤資料 → 發現問題 → A/B 測試 → 提示詞版本管理 → 持續最佳化 - + + + + +Chatbot Arena 匿名對決 + +Model A（匿名） + +"退款已處理,將在3-5個 + 工作日到賬您的賬戶" +VS + +Model B（匿名） + +"好的退款會處理的" + + +使用者盲選 → A 更好 + +Elo 更新公式 +預期勝率 E_A = 1/(1+10^((R_B-R_A)/400)) | 更新: R_A' = R_A + K*(1-E_A) +實時排行榜（示例） +排名 +模型 +Elo +勝率 vs #2 + +1 +Claude 4 Opus +1352 +— +2 +GPT-5 +1318 +— +3 +Gemini 2.5 Pro +1290 +45% +4 +DeepSeek R2 +1265 +42% +5 +Qwen 3 Max +1230 +39% +6 +Llama 4 405B +1198 +36% + + +GRPO: 將配對比較引入 RL 訓練 +一組候選響應 → 相對優勢歸一化 → 策略更新（繞過顯式獎勵模型） + \ No newline at end of file diff --git a/book-zhtw/images/fig7-7.svg b/book-zhtw/images/fig7-7.svg index 6ffb49af2..07ad58aee 100644 --- a/book-zhtw/images/fig7-7.svg +++ b/book-zhtw/images/fig7-7.svg @@ -1,56 +1,48 @@ - - - - -① 觀察：診斷報告 -總體成功率: 88% (102/116) -transcription: 0% complex_ui: 17% -math_counting: 0% Wi-Fi操作: 0% -Task 82,102-115 集中失敗 - -② 假設：三層改進框架 - -表層 -H1 設定導航提示 H2 UI規則 - -中層 -H3 修復多模態管道 H4 思考 - -深層 -H5 GPT-5 H6 UI元素樹 - - -③ 實驗：分階段驗證（每配置 5次×116任務） - -H1 導航 -設定 0%→75% -token+8% - -H3 多模態 -轉錄 0%→80% -延遲+1s - -H4 思考 -計數 0%→70% -延遲 3x! - -H6 元素樹 -UI 17%→52% -token+30% - -④ 決策：成本-收益權衡 -✓ H1+H3: 低成本高收益 → 部署 -✗ H4: 僅8%任務受益但3x延遲 → 拒絕 -✓ H6: 35%提升/30%成本 → 部署 -✗ H5: 15s/步不可接受 → 備選 - -⑤ 迭代：新一輪迴圈 -部署 H1+H3+H6 → 88%→94% -新報告顯示不同失敗模式: - H7: 條件化思考啟用 - H8: 擴展手勢動作空間 - -↑ 迴圈 - -方法論: 觀察→假設→實驗→決策→迭代 = 從鍊金術到科學工程 - \ No newline at end of file + + + +執行追蹤樹（單次任務） + +Trace：幫使用者查北京明天天氣 (3.2s, $0.008) + +LLM Call：意圖識別 +Claude 4 Sonnet · 0.4s · 320 tokens + +Tool：get_weather(Beijing) +MCP Server · 1.8s · 200ms TTFT + +├─ HTTP Request +api.weather.com · 1.6s + +└─ Response Parse +JSON → 結構化天氣資料 + +LLM Call：生成回覆 +Claude 4 Sonnet · 0.8s · 580 tokens + +Tool：send_message(user) +0.2s · 包含天氣摘要 + + + + + + + +監控儀表盤 + +成本追蹤 +今日：$12.30（1,200 次） +本月：$340（34K 次） +異常：task#892 迴圈呼叫 search 14 次，耗 $2.1 + +效能監控 +P50 / P95 / P99 延遲：2.1s / 8.4s / 15.2s +工具成功率：94.3% + +品質審計 +任務成功率：87% 幻覺觸發：2.1% +安全違規：0（本月） 使用者滿意度：4.3/5 + +閉環：追蹤資料 → 發現問題 → A/B 測試 → 提示詞版本管理 → 持續最佳化 + diff --git a/book-zhtw/images/fig7-8.svg b/book-zhtw/images/fig7-8.svg index bdc21b859..6ffb49af2 100644 --- a/book-zhtw/images/fig7-8.svg +++ b/book-zhtw/images/fig7-8.svg @@ -1,41 +1,56 @@ - + - - -模擬保真度 → -可 -擴 -展 -性 -↑ - -Mock API -單元測試級 -百萬次/小時 - -AWorld -MCP 沙盒 -126個工具函式 -525s/輪 分散式 - -AndroidWorld -模擬器 -116真實應用任務 -UI Automator - -Isaac Gym -GPU 並行 -千級並行實例 -精度略妥協 - -RoboTwin2 -物理引擎 -高精度碰撞 -單實例 CPU - -真實世界 -完美保真度 -不可重置 - + +① 觀察：診斷報告 +總體成功率: 88% (102/116) +transcription: 0% complex_ui: 17% +math_counting: 0% Wi-Fi操作: 0% +Task 82,102-115 集中失敗 + +② 假設：三層改進框架 + +表層 +H1 設定導航提示 H2 UI規則 + +中層 +H3 修復多模態管道 H4 思考 + +深層 +H5 GPT-5 H6 UI元素樹 + + +③ 實驗：分階段驗證（每配置 5次×116任務） + +H1 導航 +設定 0%→75% +token+8% + +H3 多模態 +轉錄 0%→80% +延遲+1s + +H4 思考 +計數 0%→70% +延遲 3x! + +H6 元素樹 +UI 17%→52% +token+30% + +④ 決策：成本-收益權衡 +✓ H1+H3: 低成本高收益 → 部署 +✗ H4: 僅8%任務受益但3x延遲 → 拒絕 +✓ H6: 35%提升/30%成本 → 部署 +✗ H5: 15s/步不可接受 → 備選 + +⑤ 迭代：新一輪迴圈 +部署 H1+H3+H6 → 88%→94% +新報告顯示不同失敗模式: + H7: 條件化思考啟用 + H8: 擴展手勢動作空間 + +↑ 迴圈 + +方法論: 觀察→假設→實驗→決策→迭代 = 從鍊金術到科學工程 \ No newline at end of file diff --git a/book-zhtw/images/fig7-9.svg b/book-zhtw/images/fig7-9.svg index 6d68c158d..bdc21b859 100644 --- a/book-zhtw/images/fig7-9.svg +++ b/book-zhtw/images/fig7-9.svg @@ -1,69 +1,41 @@ - - + + - -多模態觀測 - -頭部相機 -224×224 RGB - -左腕相機 -224×224 RGB - -右腕相機 -224×224 RGB - -14維關節狀態向量 - -視覺-語言-動作模型 (VLA) - -視覺編碼器 -SigLIP → 視覺 tokens - - -語言模型 -Llama 2 7B backbone - - -動作解碼器 -→ 14維連續控制向量 -動作分塊: 1次生成25個連續動作 - - - -指令: "將罐子放入鍋中" - - -SAPIEN 物理引擎 - -雙臂機器人 -各7自由度 = 14維動作 - -環境隨機化 -位置60cm/朝向±22.5° - -碰撞檢測 + 物理模擬 -剛體/軟體/摩擦力 - -動作 - -觀測 - -評估指標 - -成功率 -罐子在鍋內 -且未掉落 - -完成時間 -25步×25動作 -= 625控制步 - -泛化能力 -跨位置/朝向 -/外觀變體 - -Sim-to-Real -域隨機化 -→ 真實遷移 + + +模擬保真度 → +可 +擴 +展 +性 +↑ + +Mock API +單元測試級 +百萬次/小時 + +AWorld +MCP 沙盒 +126個工具函式 +525s/輪 分散式 + +AndroidWorld +模擬器 +116真實應用任務 +UI Automator + +Isaac Gym +GPU 並行 +千級並行實例 +精度略妥協 + +RoboTwin2 +物理引擎 +高精度碰撞 +單實例 CPU + +真實世界 +完美保真度 +不可重置 + \ No newline at end of file