Ваш агент чудово впорався із завданням. Чи зробить він це знову?
На сцені це виглядає незручно. У продуктивному середовищі це проблема надійності: робочий процес, який успішно виконався одного разу, може не спрацювати наступного разу, коли користувач зробить той самий запит. Для критично важливих завдань, як-от узгодження фінансової транзакції або перевірка договору на наявність зобов’язань, це може повністю зупинити роботу.
Більшість бенчмарків приховує цю варіативність за середнім показником. В AppWorld агент ReAct на базі GPT-4.1 досяг успіху в 77,4% запусків у п’яти повтореннях. Але успішними були всі п’ять запусків лише для 53,0% завдань — розрив узгодженості у 24,4 процентного пункту.
Більшість бенчмарків повідомляє перше число. Ми створили спосіб вимірювати друге — і покращувати його.
У попередній публікації ми представили ALTK-Evolve — систему, яка перетворює власні минулі траєкторії агента на багаторазово використовувані настанови, автоматично їх узагальнює та додає під час виконання. Вона помітно підвищує успішність виконання завдань, але ці результати також стосувалися лише середнього випадку. У цій публікації ми представляємо настанови узгодженості — новий тип настанов у altk-evolve, створений на основі діагностичного інструмента, який ми називаємо Аналізатором узгодженості і який безпосередньо націлений на цей розрив.
Коротко
- Точність приховує проблему ненадійності. Агент ReAct (GPT-4.1 на AppWorld
test_normal), який у середньому досягає успіху в 77,4% випадків, успішно виконує всі 5 повторних запусків лише для 53,0% завдань — розрив узгодженості у 24,4 процентного пункту. На складних завданнях він сягає 30 пунктів. - Ми створили спеціальний діагностичний інструмент. Аналізатор узгодженості повторно вибирає варіанти з власної записаної траєкторії агента, щоб знаходити схильні до перемикання точки прийняття рішень — кроки, де моделі бракувало одного вибору токена, щоб зробити щось інше. Йому потрібна одна траєкторія і не потрібна еталонна відповідь — він повторно вибирає варіант для кожної точки прийняття рішень у цій траєкторії одним викликом із запитом на k завершень (за замовчуванням k=5), замість повторного виконання всього завдання від початку до кінця.
- Перетворення цього діагнозу на настанови скорочує розрив удвічі — з 24,4 в.п. до 12,0 в.п. (Pass⁵ для того самого завдання +16,0 в.п., для подібного завдання +13,0 в.п.) без втрати середньої точності.
- Повна методологія та оцінювання наведені в технічному звіті на arXiv.
Метрика, яку майже ніхто не публікує
Стандартне оцінювання агентів повідомляє показник Mean@k: запуск бенчмарку k разів і усереднення частки успішних виконань. Часто k=3, іноді лише 1. Це число є в кожній таблиці лідерів, і саме його на практиці означає «77% точності».
Mean@k відповідає на запитання «наскільки добре цей агент працює в середньому?». Але не відповідає на запитання, важливе для реального користувача: чи буде він і надалі добре працювати, якщо я знову поставлю це саме запитання? Для цього потрібен показник Pass^k: частка завдань, у яких агент досягає успіху в усіх k запусках.
⚠️ Pass^k — це не Pass@k. Знайомий показник Pass@k є оптимістичним — він запитує, чи був успішним принаймні один із k запусків; це правильне запитання, коли результат можна перевірити й повторити спробу. Pass^k — його песимістичне дзеркальне відображення: успішними мають бути всі спроби. Ті самі літери, протилежне запитання. Pass^k ≤ Mean@k ≤ Pass@k — завжди.
Агент ReAct на базі GPT-4.1 демонструє Mean@5 на рівні 77,4% — справді сильний результат. Але Pass^5 становить лише 53,0%. Майже чверть бенчмарку — це завдання, які агент іноді може розв’язати, а іноді — ні, хоча між запусками нічого в завданні не змінюється. Цей розрив — Mean@k мінус Pass^k — ми називаємо розривом узгодженості.
Це не проблема можливостей, яку можна вирішити більшою моделлю. Це ортогональна вісь: агент може бути одночасно здібним і непослідовним.
Чому агенти змінюють рішення: різкі та пласкі розподіли
Щоразу, коли агент на базі LLM щось вирішує — який API викликати, який аргумент передати, чи повторити спробу, — це рішення випливає з розподілу ймовірностей наступних токенів. Важливою є форма цього розподілу. Різкий розподіл зосереджує більшу частину маси на одному токені: наступні кандидати сильно відстають, і той самий вибір повторюється від запуску до запуску. Плаский розподіл розподіляє порівнянну масу між кількома майже рівними токенами, і те, який із них переможе, майже визначається підкиданням монети.
Форма визначає, наскільки багато шуму потрібно, щоб змінити результат. Різкі розподіли стійкі — неасоціативність обчислень із плаваючою комою на GPU, пакетна обробка запитів та інші ефекти на боці платформи трохи змінюють числа, але недостатньо, щоб змінити очевидного переможця. Пласкі розподіли вразливі саме до такого зсуву: близькі результати можуть помінятися місцями під впливом невеликих збурень. А оскільки траєкторія містить десятки послідовних рішень, невелика ймовірність зміни на кожному кроці перетворюється на велику ймовірність того, що якийсь запуск піде інакше. Саме звідси береться розрив у 24 пункти.
Ось чому проблема зберігається незалежно від налаштувань декодування. Жадібне декодування та фіксоване початкове значення визначають лише як розподіл перетворюється на токен — вони нічого не говорять про сам розподіл. На хостованій кінцевій точці ймовірності трохи змінюються від запуску до запуску, тому той самий запит до тієї самої моделі за температури нуль може сьогодні розв’язати близьку нічию одним способом, а завтра — іншим.
Наше налаштування: агент ReAct працює за температури 0,0, тому жодна з описаних варіацій не є звичайним семплюванням.
Спочатку діагностика, потім виправлення
Це перетворює проблему на пошук: які кроки в певній траєкторії були пласкими — і що робити, коли ви це знаєте?
Настанови узгодженості виникають із двоетапного конвеєра, який підключається до наявної інфраструктури ALTK-Evolve, але використовує новий сигнал для визначення того, що саме потрібно записати.
1. Виявлення — Аналізатор узгодженості. Отримавши одну записану траєкторію, аналізатор відтворює кожен крок прийняття рішень за допомогою контрольованого повторного семплювання, вимірюючи, наскільки насправді змінюється вихід моделі в цій точці. Конкретно, це один додатковий виклик моделі для кожного кроку прийняття рішень, виконаний один раз офлайн, із параметром семплювання, налаштованим на одночасне отримання k завершень (за замовчуванням k=5). Відтворення здійснюється на вже записаному контексті, без нових викликів інструментів, без нових взаємодій із середовищем і без другого наскрізного запуску завдання. У результаті для кожного кроку прийняття рішень отримується оцінка узгодженості, яка записується в картку оцінювання, щоб точно визначити, які рішення ризикують змінитися під час наступного запуску. Виявлення повністю здійснюється методом «чорної скриньки» — без логітів, внутрішніх даних моделі чи інструментування, окрім уже наявної траєкторії.
2. Генерація — цільові настанови. Кожен позначений крок стає кандидатом на настанову узгодженості у стандартному форматі ALTK-Evolve, тому він інтегрується в наявний конвеєр зберігання та пошуку. Ось реальний приклад, згенерований GPT-4.1 на основі траєкторії завдання AppWorld «Скільки активностей виконано в моєму списку справ відповідно до моєї нотатки в SimpleNote?»:
[Настанова 1] Під час підрахунку маркерів у вигляді прапорців у вмісті нотатки використовуйте зіставлення регулярного виразу, прив’язаного до початку рядка, а не простий підрахунок підрядків — заголовки нотаток часто повторюють символ маркера в рядку з легендою.
[Настанова 2] Завжди перевіряйте результати пошуку для запитів щодо нотаток, знаходячи кілька збігів і підтверджуючи правильну нотатку перед продовженням.
Тут немає специфічних для завдання дрібниць. Помилки під час підрахунку рядків і неперевірені результати пошуку — це точки прийняття рішень, які часто виникають із високою невизначеністю в багатьох завданнях AppWorld. У цьому й полягає суть: аналізатор націлений на нестабільність, а не на помилки, тому він виявляє кроки, які агент цього разу випадково виконав правильно, але легко міг би виконати неправильно наступного разу.
Перегляньте двохвилинну демонстрацію — п’ять паралельних запусків агента розділилися у співвідношенні 3–2 на цьому завданні через невпевненість агента щодо стратегії підрахунку, а потім були запущені знову після додавання цих настанов у контекст: усі п’ять дали однакову відповідь.
Результати: скорочення розриву без втрати точності
Ми провели оцінювання на AppWorld test_normal (168 завдань) з агентом ReAct на базі GPT-4.1, генеруючи настанови узгодженості на основі однієї базової траєкторії для кожного завдання та перевіряючи їх у 5 нових запусках.
Mean@5 (%), сукупний показник — та сама шкала, що й вище для Pass^5.
Розрив узгодженості скорочується приблизно вдвічі. Сукупний Pass^5 зростає з 53,0% до 69,0%, а Mean@5 — з 77,4% до 81,0%, скорочуючи розрив між «виглядає здібним» і «на нього можна покластися» з 24,4 в.п. до 12,0 в.п. Майже третина завдань, які раніше виконувалися непослідовно, стають завданнями, які агент успішно проходить кожного разу.
Найбільше покращення спостерігається в середньому та складному рівнях. Середній рівень: +22,9 в.п. (+44% відносно), складний: +14,3 в.п. (+45% відносно) — у відносному вираженні результати фактично однакові, хоча в абсолютному значенні випереджає середній рівень. Легкий рівень дає +12,2 в.п., оскільки там було найменше простору для покращення. Саме це й мають робити настанови узгодженості: знаходити й стабілізувати конкретні точки прийняття рішень, де власна невпевненість агента впливала на результат.
Mean@5 ніколи не знижується. Збереження середньої точності було обов’язковою вимогою, а не бажаним бонусом: система, яка підвищує Pass^5 ціною зниження Mean@5, лише переміщує ненадійність, а не усуває її. Середня точність зберігається або покращується на кожному рівні складності.
Настанови узагальнюються — вони не виправляють лише одну траєкторію
Застосовані до іншого, але пов’язаного завдання в тому самому сценарії AppWorld — іншого варіанта сценарію, з якого були отримані настанови, — настанови узгодженості все одно підвищують Pass^5 на +13,0 в.п., лише на 3 пункти менше, ніж для того самого завдання. Настанова, отримана з одного запуску, не просто виправляє цей запуск; вона фіксує щось, що переноситься на інші завдання.
Ще переконливіші докази дає слабша модель, gpt-oss-120b. Pass^5 для того самого завдання зріс на +6,0 в.п. від набагато нижчої базової позначки (10,1% → 16,1%), а показник узагальнення для подібного завдання (+8,7 в.п.) фактично перевищив приріст для того самого завдання. Це свідчить, що настанови фіксували справді багаторазово застосовні закономірності помилок, а не запам’ятовували специфіку однієї траєкторії.
Якщо ви запускаєте агента у виробництво
- Публікуйте Pass^k поруч із Mean@k. Середні значення не дають змоги відрізнити надійного агента від щасливого; навіть k=3 виявить розрив, про який ви не знали.
- Очікуйте, що з ускладненням завдань розрив зростатиме. Саме на найскладнішому рівні одне усереднене число найбільше вводить в оману.
- Не починайте одразу зі збільшення моделі. Узгодженість ортогональна до можливостей. Сильніша модель підвищує Mean@k, але не обов’язково зменшує розрив узгодженості.
- Для діагностики не потрібні ані оцінювач, ані повторне виконання в реальному середовищі. Достатньо одного додаткового виклику LLM на кожен крок прийняття рішень (за замовчуванням із семплюванням k=5 завершень) — без еталонної відповіді та без повторного запуску завдання в середовищі. Саме це робить підхід придатним для виробничого трафіку, де часто неможливо повторити завдання наскрізно навіть один раз.
Спробуйте
Спробуйте інструментарій ALTK-Evolve — репозиторій із відкритим кодом тепер містить Аналізатор узгодженості та генерацію настанов узгодженості, використані в цих експериментах, — або прочитайте технічний звіт на arXiv для ознайомлення з повною методологією.
Якщо вам знайомі показники точності, які ви не можете відтворити на власних завданнях, ми хотіли б про це почути — конкретні приклади поведінки ваших агентів, схильної до перемикання, є саме тим видом відгуків, який формує наші подальші розробки. Створіть повідомлення про проблему або розпочніть обговорення.
Додаток: розуміння метрик
- Mean@k. Запустіть завдання k разів і повідомте середню частку успішних виконань — те, що більшість бенчмарків називає «точністю».
- Pass^k. Частка завдань, у яких агент досягає успіху в усіх k незалежних запусках. Завжди ≤ Mean@k. Це те, що відчуває користувач, коли двічі виконує той самий запит.
- Pass@k Успішним є принаймні один із k запусків — оптимістичний відповідник, поширений у статтях про генерацію коду.
- Розрив узгодженості. Mean@k − Pass^k, у процентних пунктах.
Пов’язані матеріали / посилання
- Репозиторій ALTK-Evolve із відкритим кодом — github.com/AgentToolkit/altk-evolve
- Технічний звіт — arXiv
- Демонстрація настанов узгодженості —відео тривалістю 2 хвилини
Спільнота
· Зареєструйтеся або увійдіть, щоб залишити коментар
Перекладено автоматично з англійської. Оригінал статті — за посиланням нижче.