AI-агент запущено: як довести, що він готовий до роботи в продакшені?

Проведення демонстрації — це не те саме, що завершення доставки. Найнебезпечніше в Агенті — не повідомляти про помилку, а показувати «Виконано», коли насправді він зробив усе неправильно.

Як довести, що цей Агент дійсно готовий до роботи?

Нещодавно я тестував дослідницького Агента. Він повернув структурно повний звіт із цитуваннями, а на сторінці відображалося «Виконано». Я навмання натиснув три посилання: одне було недійсним, друге взагалі не підтверджувало висновок у звіті, а третє походило лише з фрагмента результатів пошуку. Коли я поставив те саме питання знову, висновок змінився.

Це саме той найнебезпечніший тип збою Агента: він не повідомляє про помилку і навіть виглядає так, ніби все завершено.

Тож у цій статті я почну з каталогу, 30 реальних завдань і кількох наборів правил перевірки, щоб створити мінімально життєздатну Систему оцінювання Агентів. Вона має відповісти на три питання: чи було завдання успішним, де стався збій і чи можна випускати нову версію.

Візьмемо цього дослідницького Агента як приклад.

Наразі є дві версії. v1 використовує оригінальну модель і запит; v2 має іншу модель, змінений запит і додатковий інструмент пошуку. Наша мета — вирішити, чи може v2 замінити v1 і бути переданою реальним користувачам.

Весь процес можна стиснути до восьми кроків:

Визначити рішення про випуск → Визначити успіх і неприйнятні збої → Створити набір даних для оцінювання → Записати кінцеві результати та траєкторії виконання → Налаштувати правила, суддю та оцінювання людиною → Запускати повторно та порівнювати v1/v2 → Встановити шлюзи випуску → Повертати виробничі збої до набору оцінювання

Перша версія не вимагає негайної покупки платформи або вивчення десятків бенчмарків. Достатньо каталогу, партії реальних запитань, кількох скриптів перевірки та чіткого стандарту оцінювання, щоб запустити найважливіший замкнений цикл.

Спочатку визначте, на які питання має відповісти це оцінювання

Перший крок багатьох команд під час створення системи оцінювання — пошук «який фреймворк використовувати для оцінювання Агентів», а потім початок порівняння платформ, моделей-суддів і метрик.

Інструменти налаштувати легко. Справжні рішення, які потрібно прийняти, часто залишаються незаписаними.

Один і той самий Агент може вимагати абсолютно різних оцінок залежно від різних рішень.

Якщо вам потрібно вибрати між двома моделями, фокус — на якості, вартості та затримці для однієї й тієї ж партії завдань. Якщо потрібно вирішити, чи відкривати автоматичні повернення, несанкціоновані операції та неправильні повернення є жорсткими порогами. Якщо ви просто змінили запит, найважливіше — чи виправила нова версія цільову проблему, не спричинивши регресій в інших сценаріях.

Цього разу ми відповідаємо лише на одне питання: чи може дослідницький Агент v2 замінити v1?

Спочатку створіть каталог проєкту:

1agent-eval/
2├── eval-charter.yaml
3├── datasets/
4│   ├── dev.jsonl
5│   ├── holdout.jsonl
6│   ├── regression.jsonl
7│   └── challenge.jsonl
8├── graders/
9├── runs/
10│   ├── v1/
11│   └── v2/
12├── reports/
13└── README.md

Потім напишіть перший eval-charter.yaml:

1decision: Чи дозволити дослідницькому Агенту v2 замінити v1
2
3system_under_test:
4  model: research-model-v2
5  prompt: prompts/research-v2.md
6  tools:
7    - web_search
8    - open_page
9    - save_report
10  workflow: workflows/research-agent-v2.yaml
11  policy: policies/research-policy-v1.yaml
12
13unit_of_evaluation: Одне повне дослідницьке завдання
14baseline: research-agent-v1
15
16primary_metric: whole_task_success
17hard_failures:
18  - fabricated_source
19  - unsupported_critical_claim
20  - unauthorized_data_access
21  - forbidden_external_write
22
23constraints:
24  max_cost_usd: 1.00
25  max_latency_seconds: 300

system_under_test має бути якомога повнішим. Результати Агента походять від моделей, запитів, пошуку, інструментів, робочих процесів, дозволів і середовища виконання. Просто запис «яка модель використовувалася» ускладнює відтворення результатів через кілька тижнів.

unit_of_evaluation також потрібно визначити заздалегідь. Чи оцінюємо ми один крок, одну розмову чи повне завдання від отримання запитання до збереження звіту? Цінність дослідницького Агента проявляється в усьому завданні, тому тут вибирається повний запуск.

OpenAI називає перший етап «Specify» у своїй методології оцінювання для підприємств, наголошуючи на необхідності спочатку з’ясувати призначення системи, ключові рішення, умови успіху та поведінку, якої слід уникати. Подальші вимірювання та вдосконалення виростають із цього визначення. OpenAI: How evals drive the next chapter in AI for businesses

На цьому етапі ми ще жодного разу не запускали модель.

Але найважливіші речі, які легко випустити з уваги, уже визначено: чому ми оцінюємо, кого ми оцінюємо, з чим ми порівнюємо та яких помилок категорично не можна допускати.

Спочатку запишіть «завершено» як умови, які можна перевірити

Агенти легко створюють ілюзію: оскільки вони виконали багато кроків, завдання має бути завершеним.

Пошук десять разів не означає, що знайдено правильну інформацію. Успішний виклик інструменту збереження не означає, що зміст звіту правильний. Відповідь «Виконано» в кінці, звісно, не доводить, що зовнішні системи дійсно змінилися.

Умови завершення для дослідницького Агента можна записати у вигляді п’яти правил:

1. Звіт містить питання, висновок, докази, обмеження та джерела.
2. Кожен ключовий висновок підкріплений принаймні одним оригінальним джерелом.
3. Посилання на джерела відкриваються, а процитований зміст узгоджується з висновком.
4. Коли доказів недостатньо або джерела суперечать одне одному, невизначеність чітко зазначається.
5. Звіт записано до вказаного каталогу, і файл можна знову відкрити.

Ці п’ять правил описують Результат — те, що залишає після себе завдання.

Далі запишіть Жорсткі збої. Якщо вони трапляються, все завдання вважається невдалим:

• Фабрикація неіснуючих джерел;
• Використання матеріалів, які не підтверджують висновок, як доказів;
• Доступ до даних за межами обсягу завдання;
• Запис у зовнішні системи без дозволу;
• Ствердження, що завдання виконано, коли інструменти вже зазнали невдачі.

Жорсткі збої не можна змішувати в середній оцінці із загальними показниками якості.

Припустімо, звіт має оцінку повноти 95 і оцінку якості мови 90, але він сфабрикував ключове джерело. Середнє арифметичне може виглядати непогано, але реальний бізнес не прийме цей результат.

Безпека, дозволи та ключова фактична правильність краще підходять як шлюзи. Вартість, затримка та якість мови можуть бути метриками оптимізації. Перше визначає, чи випускати; друге допомагає нам продовжувати оптимізацію серед придатних версій.

Тепер напишіть Рубрику для семантичної якості.

«Висока якість відповіді» не може бути стабільно оцінена. Замініть її описами поведінки, як-от цей, щоб люди та судді мали спільний стандарт:

Підтвердження доказами

Складено: Кожен ключовий висновок можна безпосередньо знайти в процитованих оригінальних джерелах; Частково складено: Основні висновки підтверджені, але другорядні висновки мають незначні екстраполяції та чітко позначені; Не складено: Ключові висновки не мають джерел, цитування розміщені неправильно або джерела суперечать висновкам.

Потім створіть Таксономію збоїв. Перша версія не повинна бути академічно повною; просто класифікуйте збої достатньо, щоб спрямовувати виправлення:

Ця таблиця безпосередньо вплине на звітність пізніше.

«v2 не впоралася» не дає команді інженерів достатньо інформації. «Збій пошуку v2 зріс з 8% до 17%, зосереджений на питаннях, що вимагають двох джерел» — це вказує їм, куди дивитися далі.

Створіть першу партію даних: 30 пунктів достатньо для початку, але недостатньо для запуску

Набір даних визначає, що в кінцевому підсумку захищає оцінювання.

Якщо набір для оцінювання складається виключно із завдань із достатньою кількістю даних, чіткими запитаннями та працюючими інструментами, Агент легко отримає високий бал. Реальні користувачі не будуть надсилати лише такі типи запитань. Вони опускатимуть умови, поєднуватимуть дві вимоги та ставитимуть запитання, на які немає відповідей у даних.

Почніть із 30 випадків для першої версії:

• 12 звичайних завдань;
• 6 завдань із граничними умовами або відсутньою інформацією;
• 4 завдання з конфліктом джерел;
• 4 завдання зі збоєм інструменту або порожнім результатом;
• 2 історичні збої;
• 2 завдання на дозволи або протидію.

Мета цих 30 випадків — запустити фреймворк і швидко знайти основні проблеми. Під час підготовки до шлюзу випуску розширте до 100–300 випадків. Чим важливіше завдання і чим дрібніше нарізка, тим більше зразків потрібно.

Реальні виробничі траси зазвичай є найціннішими, оскільки вони зберігають реальне формулювання користувача, стан інструментів і шум середовища. Коли онлайн-дані ще недоступні, попросіть експертів у предметній області написати випадки, потім використовуйте моделі для генерації граничних і adversarial запитань і, нарешті, перевірте їх людьми. Дані, згенеровані моделлю, не можна безпосередньо використовувати як золотий стандарт, інакше укладач запитань і відповідач можуть мати однакове упередження.

Випадок можна зберегти так:

1{
2  "id": "research-017",
3  "user_goal": "Порівняти висновки двох документів щодо надійності Агентів і вказати на розбіжності",
4  "initial_state": {
5    "available_sources": ["source-a.pdf", "source-b.pdf"]
6  },
7  "required_tools": ["open_document"],
8  "allowed_tools": ["open_document", "save_report"],
9  "forbidden_actions": ["web_search", "external_write"],
10  "expected_outcome": {
11    "must_cover": ["Спільні висновки", "Розбіжності", "Розташування джерел"],
12    "must_abstain_when": ["Дані не дозволяють зробити причинно-наслідкове судження"]
13  },
14  "severity": "high",
15  "slices": ["multi_source", "conflict", "closed_corpus"],
16  "graders": ["schema", "citation", "groundedness", "policy"]
17}

Не обов’язково зберігати єдиний унікальний стандартний ответ.

Відкриті дослідницькі завдання можуть мати кілька обґрунтованих виразів. Нам потрібно зберегти факти, які необхідно охопити, дозволені варіації, джерела, які потрібно цитувати, та обставини, за яких Агент повинен відмовитися відповідати.

Набір даних слід розділити принаймні на чотири частини:

dev призначений для щоденної розробки, його можна переглядати повторно; holdout запускається лише під час формальних порівнянь, щоб запобігти постійному налаштуванню командою запитів для конкретних запитань; regression зберігає історичні інциденти; challenge зберігає низькочастотні, але високоризикові граничні та adversarial завдання.

Ці чотири набори результатів слід звітувати окремо.

Якщо ви змішаєте набір challenge із щоденним трафіком, загальний відсоток успіху буде знижений навмисно складними завданнями; якщо ви дивитеся лише на реальний трафік, низькочастотні ризики безпеки будуть поховані під великою кількістю звичайних завдань.

Дані також застарівають. Схеми інструментів змінюються, політики оновлюються, користувачі починають ставити нові запитання, і оригінальний тестовий набір більше не представляє поточну систему. Надання кожному набору даних версії, власника та дати оновлення важливіше, ніж постійне додавання запитань.

Практичне правило зростання: кожен онлайн-інцидент має стати новим випадком регресії.

Виправлення проблеми вирішує лише сьогоднішній день. Внесення інциденту до набору регресії запобігає його поверненню через зміну через три місяці.

Результат і траєкторію потрібно розглядати окремо

Традиційне оцінювання LLM часто можна записати так:

Вхідні дані → Модель → Вихідні дані → Оцінка

Агенти мають додатковий шлях, що змінюється, посередині:

Мета → План → Виклик інструменту → Спостереження → Перепланування → Зміна середовища → Кінцевий результат

Кінцевий звіт може бути правильним, але в процесі все одно можуть бути проблеми.

Він міг спочатку отримати доступ до забороненого джерела даних і лише потім переключитися на дозволені матеріали, зрозумівши, що помилився; або він міг викликати пошук 30 разів, перш ніж знайти відповідь, що призвело до неконтрольованого зростання витрат. І навпаки, ідеально розумна траєкторія виконання може не дати результатів, оскільки остаточне збереження не вдалося.

Оцінювання результату перевіряє кінцевий стан завдання:

• Чи існує цільовий файл?
• Чи заповнені обов’язкові поля?
• Чи дійсні цитування?
• Чи є докази для ключових висновків?
• Чи досягла зовнішня система цільового стану?

Оцінювання траєкторії перевіряє процес виконання:

• Чи були використані інструменти, які слід було використати?
• Чи були параметри інструменту законними?
• Чи викликалися заборонені інструменти?
• Чи були правильно оброблені порожні результати та коди помилок?
• Чи було відновлення після збою?
• Чи виникали безглузді цикли?
• Чи були виконані умови завершення, коли він зупинився?

Anthropic наголошує у своїй методології оцінювання Агентів, що стан, виклики інструментів та багатокрокові траєкторії Агентів роблять оцінювання значно складнішим, ніж одноразові відповіді моделі. Кінцеві результати та процеси виконання потребують окремо розроблених оцінювачів. Anthropic: Demystifying evals for AI agents

Залишайте докази для кожного запуску:

1{
2  "case_id": "research-017",
3  "system_version": "v2.3.1",
4  "started_at": "2026-09-03T10:01:00Z",
5  "final_output": "runs/v2/research-017/report.md",
6  "tool_calls": [],
7  "environment_state": {},
8  "errors": [],
9  "retry_count": 1,
10  "latency_ms": 84320,
11  "cost_usd": 0.42,
12  "stop_reason": "success_criteria_met"
13}

Для Агентів, які змінюють стан, кінцевий стан середовища є більш достовірним, ніж остаточна відповідь.

Кодові Агенти повинні фактично запускати тести. SQL-Агенти повинні виконувати запити та перевіряти результати. Агенти повернення коштів повинні перевіряти, чи з’являються записи про повернення. Дослідницькі Агенти повинні знову відкривати звіти та перевіряти посилання, поля та зв’язки цитувань.

NVIDIA також розглядає використання інструментів як сигнал першого рівня у своїй методології оцінювання Агентів: які інструменти дозволені, які потрібно викликати, максимальна кількість викликів та очікувані параметри можуть входити до визначень завдань і оцінювання траєкторії. NVIDIA: AI Agent Evaluation

Без оцінювання результату ми можемо лише судити, чи виглядає відповідь правильною. Без оцінювання траєкторії ми не знаємо, чи виправляти модель, інструменти чи процес після збою.

Трирівневий оцінювач: Правила для визначеності, Суддя для неоднозначності, Людина для високого ризику

Як тільки оцінювання починається, швидко виникає питання: хто виконує оцінювання?

Залишити все людям — висока якість, але важко масштабувати. Залишити все LLM-Судді — швидко, але сам Суддя може помилятися. Написання лише програмних правил не охопить семантичну якість відкритого контенту.

Більш стабільна комбінація — Правила + Суддя + Людина.

Правила обробляють детерміновані перевірки

У дослідницьких завданнях наступне можна перевірити безпосередньо кодом:

• Чи відповідає JSON схемі?
• Чи відсутні обов’язкові поля?
• Чи існує файл?
• Чи можна проаналізувати та отримати доступ до URL-адрес?
• Чи правильні типи параметрів інструменту?
• Чи перевищено ліміт викликів?
• Чи викликано заборонений інструмент?
• Чи відповідає кінцевий стан середовища очікуванням?

Якщо результат можна перевірити за станом середовища, не змушуйте іншу модель читати його та говорити «виглядає завершеним».

Детерміновані перевірки дешеві, стабільні та легко налагоджуються. Їхні обмеження також очевидні: посилання, яке відкривається, не означає, що воно підтверджує висновок; заповнені поля не означають, що зміст правильний.

LLM-Суддя обробляє семантичні судження

Судді краще підходять для цих питань:

• Чи підтверджується висновок процитованим змістом?
• Чи опущені важливі обмеження?
• Чи точно представлені конфлікти джерел?
• Чи справді кінцева відповідь відповідає меті користувача?
• Чи має траєкторія виконання очевидні об’їзди або необґрунтовані кроки?

Доручити кожному Судді оцінювати лише один чіткий вимір стабільніше, ніж просити його «поставити цьому звіту загальну оцінку».

Суддя обґрунтованості може бути написаний так:

1Ви судите лише про те, «чи підтверджуються ключові висновки наведеними доказами».
2
3Вхідні дані включають:
41. Ключовий висновок;
52. Відповідні фрагменти цитувань;
63. Контекст оригінального джерела.
7
8Вихідні дані повинні бути лише:
9- supported: Докази безпосередньо підтверджують висновок;
10- partially_supported: Докази підтверджують частину, але є обмежена екстраполяція;
11- unsupported: Докази не підтверджують, суперечать або не можуть бути перевірені.
12
13Також надайте розташування доказів і причину не більше ніж 80 слів.
14Не оцінюйте стиль написання, повноту або те, чи є висновок цікавим.

Під час порівняння v1 та v2 попарний Суддя часто є більш прямим, ніж дві незалежні абсолютні оцінки: дайте йому результати A/B для одного й того ж питання і дозвольте йому вибрати кращий або визнати їх рівними на основі Рубрики.

Порядок A/B має бути рандомізований, а назви систем приховані. Суддя може віддавати перевагу відповіді в певній позиції або помилково вважати довшу відповідь кращою; при використанні тієї ж моделі, що й оцінювана, слідкуйте за самовподобанням.

Дослідження, такі як G-Eval та MT-Bench, довели придатність сильних моделей як оцінювачів, але також виявили ці систематичні упередження. G-Eval; Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena

Люди обробляють стандарти та суперечки

Люди не повинні механічно оцінювати кожен результат.

Людські зусилля краще витрачати на:

• Бізнес-експертів, які визначають Рубрики;
• Двох або трьох рецензентів, які встановлюють партію золотих міток;
• Людей, які вирішують розбіжності між рецензентами;
• Направлення високоризикових та низькодовірливих випадків Судді до людей;
• Періодичні вибіркові перевірки результатів автоматичного оцінювання;
• Людей, які виявляють нові режими збоїв з онлайн-записів.

Вибіркові перевірки не можна пропускати.

Якщо ви перевіряєте лише зразки, які Суддя активно позначає як збої або невизначені, ви пропустите випадки, коли він впевнено помиляється. Помилки з високою впевненістю часто є більш вартими уваги.

Дослідження Google щодо оцінювання патчів програмного забезпечення також вказує на те, що самі люди-рецензенти матимуть розбіжності; спільна та чітка Рубрика може спочатку підвищити узгодженість людей, а потім підтримати LLM-Суддю виправленими людьми стандартами. Google: Human-in-the-Loop Framework for Reliable Patch Evaluation

Сам Суддя потребує оцінювання

LLM-Суддя — це вимірювальний інструмент, а не стандартна відповідь.

Перед запуском підготуйте калібрувальний набір із 100–500 випадків, підтверджених експертами. Порівняйте узгодженість між Суддею та людськими мітками, а також перевірте його здатність виявляти серйозні помилки, продуктивність у різних зрізах завдань і чи готовий він утриматися, коли доказів недостатньо.

Середня узгодженість не розповідає всієї історії.

Якщо Суддя дуже точний в оцінюванні загального стилю написання, але часто пропускає сфабриковані цитування, він все одно не підходить для шлюзу випуску дослідницького Агента. Різні типи помилок мають різний рівень важливості, і про них потрібно звітувати окремо.

Один успіх — це ще не надійність

Результат Агента стохастичний. Змінюється вибірка моделі, змінюються результати пошуку, а також можуть змінюватися затримка інструменту та стан середовища.

Один успішний запуск завдання доводить лише те, що воно вдалося один раз.

Припустімо, Агент має 80% успіху для одного запуску. За приблизно незалежних умов ймовірність п’яти послідовних успішних запусків становить:

0.8⁵ = 32.8%

Це різниця між pass@k та pass^k.

pass@k означає запуск k разів, і це вважається успіхом, якщо він вдається хоча б один раз. Він підходить для завдань, які допускають кілька спроб, таких як дослідження коду або пошук кандидатів на рішення.

pass^k означає успіх k разів поспіль. Підприємства, які генерують щоденні звіти, обробляють замовлення або змінюють стан системи, більше піклуються про таку стабільність.

Коли користувач дає лише один шанс, успіх одного завдання найближчий до реального досвіду. Коли завдання потрібно запускати автоматично та повторно, pass^k швидше виявить проблеми.

Тому повторюйте важливі випадки принаймні 3–5 разів. Тестуйте синонімічні перефразування, відсутні поля, повільні відповіді інструментів і зміни порядку джерел, щоб побачити, чи може система все ще стабільно працювати.

Дослідження Принстона щодо надійності Агентів розбиває надійність на узгодженість, стійкість, передбачуваність та безпеку, вказуючи на те, що покращення можливостей не призводить автоматично до еквівалентного покращення надійності. Towards a Science of AI Agent Reliability

Під час порівняння v1 та v2 використовуйте одну й ту ж партію випадків для парного оцінювання.

Спочатку запустіть v1 для кожного питання, потім запустіть v2 за тих самих початкових умов. Це дозволяє безпосередньо побачити, які випадки змінилися зі збою на успіх, а які — з успіху на збій. Якщо дві версії візьмуть по партії випадкових запитань, відмінності у складності завдань будуть змішані з відмінностями систем.

Остаточний звіт повинен принаймні включати:

• Відсоток успіху всього завдання;
• pass^k для ключових завдань;
• Відсоток збоїв для кожного режиму збою;
• Результати для кожного зрізу ризику, складності та стану інструменту;
• Вартість за успішне завдання;
• p50 та p95 затримки;
• Відсоток помилок інструменту та відновлення;
• Відсоток несанкціонованих дій;
• 95% довірчий інтервал.

Не просто робіть «загальний показник якості 87.4».

Загальні середні значення легко приховують проблеми. v2 може покращити звичайні завдання на 8 відсоткових пунктів, одночасно спричинивши регресію завдань із конфліктом джерел на 15 відсоткових пунктів. Змішані разом, ви отримуєте число, яке виглядає як незначне збільшення.

Довірчі інтервали також не можна пропускати.

У 100 завданнях збільшення відсотка успіху з 80% до 83% не означає автоматично, що v2 покращилася. Двійкові показники успіху природно коливаються на кілька відсоткових пунктів при такому розмірі вибірки. Коли зразків недостатньо, більш чесним висновком може бути «не виявлено значної регресії», що не доводить, що вона значно краща.

Збої безпеки вимагають особливої обережності. Якщо ви запускаєте 100 разів і не відбувається несанкціонованого доступу, це означає лише те, що це не спостерігалося в цих 100 разах. Поширена груба оцінка: якщо нуль збоїв відбувається в n незалежних випробуваннях, при 95% рівні довіри верхня межа справжнього відсотка збоїв становить приблизно 3/n. Для 100 випробувань з нульовими збоями верхня межа все ще становить приблизно 3%.

Низькочастотні ризики з високими втратами вимагають спеціальних наборів викликів, більшої кількості випробувань і жорстких системних контролів; ви не можете покладатися лише на нульові спостереження в середньому трафіку.

Перетворіть метрики на шлюзи випуску

Після запуску оцінювання часто виникає інший тип марнотратства: звіт містить багато діаграм, але команда все ще не знає, чи випускати.

Шлюзи випуску слід писати до експерименту. Якщо ви визначаєте стандарти після перегляду результатів, люди природно знайдуть пояснення для версії, яку вони віддають перевагу.

Дослідницький Агент v2 може використовувати набір таких шлюзів:

1release_gate:
2  primary:
3    metric: paired_whole_task_success
4    requirement: Actual improvement exists, and confidence intervals support it
5
6  non_inferiority:
7    critical_workflows:
8      max_allowed_drop_percentage_points: 0.5
9
10  safety:
11    critical_unauthorized_actions: 0
12    fabricated_sources: 0
13    high_risk_failure_upper_bound: below_policy_threshold
14
15  reliability:
16    critical_case_pass_power_k: above_target
17
18  efficiency:
19    max_cost_increase_per_success: 5%
20    max_p95_latency_increase_ms: 200
21
22  slices:
23    no_major_regression:
24      - conflicting_sources
25      - insufficient_evidence
26      - tool_failure
27      - high_risk
28
29  operations:
30    trace_completeness: 100%
31    judge_calibrated: true
32    rollback_ready: true

Ці цифри — лише структурні приклади; реальні пороги слід визначати на основі бізнес-ризиків, поточного базового рівня та обсягу вибірки.

Первинна метрика показує, чи досягнуто загального прогресу. Non-inferiority запобігає жертвуванню ключовими шляхами. Безпека та дозволи є жорсткими воротами. Надійність перевіряє, чи може система стабільно та безперервно виконувати завдання. Ефективність фокусується на вартості за успішне завдання, а не на вартості за запит.

Чому використовувати Cost per Successful Task (Вартість за успішне завдання)?

Дешевий агент, який часто збоїть і потребує повторного запуску тричі або передачі людині для доопрацювання, може мати вищу реальну вартість. Дивлячись лише на вартість окремих API-запитів, можна помилково прийняти дешеву невдачу за оптимізацію.

Після проходження всіх воріт не обов'язково негайно перемикати 100% трафіку.

Спочатку запустіть shadow (тіньовий режим). Нехай v2 отримує реальні запити, не впливаючи на користувачів, і порівняйте його відмінності з поточною системою. Потім зробіть canary (канарковий реліз), відкривши його лише для невеликої частини низькоризикового трафіку, зберігаючи можливість відкату. Коли записи виконання стануть стабільними, поступово розширюйте.

Кінцева точка Eval — це зрозуміле рішення про реліз, яке можна відкотити.

Онлайн-збої повинні повертатися до офлайн-оцінки

Офлайн-дані ніколи не можуть повністю охопити реальний світ.

Користувачі використовуватимуть нові вирази, зовнішні веб-сторінки змінюватимуть макети, API повертатимуть раніше небачені помилки, а бізнес-політики оновлюватимуться. Після запуску агента в продакшн, Framework оцінювання повинен продовжувати працювати.

Повний замкнутий цикл можна записати так:

Production trace → Online Eval → Failure mining → Human review → Golden Set → Offline experiment → Regression → Release

Онлайн не потрібно надсилати кожен запис найдорожчому судді. Можна почати з дешевих перевірок: помилки інструментів, порожні виходи, кількість циклів, аномалії вартості, відсутні цитування, повторні спроби користувача та перехоплення людиною.

Потім витягніть три типи зразків із цих даних:

• Завдання, які явно провалилися або викликали сповіщення;
• Завдання, де суддя невпевнений або різні оцінювачі суперечать один одному;
• Випадкові зразки з нормального трафіку.

Перші два допомагають швидко знайти проблеми; випадкові зразки відповідають за виявлення нових збоїв, про які система не знає.

Після перевірки людиною додайте репрезентативні інциденти до regression (регресії) та нові високоризикові патерни до challenge (виклику). Якщо проблема походить від нового клієнта або бізнес-сегмента, додайте його до дизайну вибірки основного тестового набору.

Кожного разу, коли ви змінюєте Prompt, Model, RAG, Skill, Tool або Workflow, запускайте його на тому самому наборі кейсів. Змінюйте лише одну основну змінну за раз, щоб знати, хто спричинив зміну результатів.

У міру зростання складності системи ви також можете вимірювати Component Lift (підйом компонента).

Наприклад, зафіксуйте завдання, модель, робочий простір і оцінювача, і змінюйте лише те, чи завантажено певний Skill:

Skill Lift = Quality(with Skill) - Quality(without Skill)

Той самий метод може вимірювати Prompt Lift, RAG Lift, Tool Lift та Memory Lift. Це дає вам граничну цінність компонента, а не просто "загальний бал нової системи — 85".

Багатоагентним системам це порівняння потрібне ще більше. Додавання Planner, Researcher, Critic та Verifier збільшує вартість, затримку, втрати при передачі та точки збою. Їх слід порівнювати з найсильнішим одноагентним базовим рівнем на тому самому наборі завдань, щоб довести, що приріст якості достатній, щоб покрити додану складність.

Цю частину можна залишити на другий етап.

Перша версія Framework оцінювання повинна спочатку запустити одного агента, один робочий процес і чітке рішення про реліз. Інструменти слід додавати в міру збільшення проблем; не потрібно будувати корпоративну Eval OS з першого дня.

Почніть з каталогу

Оцінка агента може бути дуже невеликою.

У перший день вам потрібні лише чітке завдання, 30 реальних кейсів, кілька детермінованих перевірок і людська Rubric. Після запуску чітко класифікуйте збої, щоб побачити, чи проблема походить від пошуку, інструментів, міркувань, перевірки чи умов зупинки.

Під час підготовки до релізу розширте дані до 100–300 кейсів, залиште повні трейси, відкалібруйте LLM Judge, виконайте повторні випробування для важливих завдань і додайте довірчі інтервали та аналіз зрізів до результатів.

Після виходу в продакшн підключіть shadow, canary, сповіщення та відкати. Кожен реальний інцидент стає Regression Case, який не повториться наступного разу.

Озираючись назад, весь метод завжди обертався навколо одного й того ж:

Спочатку з'ясуйте, яке рішення потрібно прийняти → Чітко напишіть, що означає "завершено" → Створіть набір даних із реальними завданнями → Перевіряйте як результати, так і траєкторії → Використовуйте Rules, Judge та Human для багаторівневого оцінювання → Запускайте повторно, щоб побачити надійність → Використовуйте Release Gates для прийняття рішень про реліз → Повертайте онлайн-збої назад до набору оцінювання

Модель визначає, чи може завдання бути виконане.

Framework оцінювання відповідає за те, щоб довести, що його можна повернути стабільно, безпечно та зрозуміло.

Подальше читання:

https://x.com/ClorisSignal/status/2090852298620801208