Проєктування плану керування оцінкою для промислових AI-агентів

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

Це піднімає практичне питання: як насправді будується процес оцінки автономних систем? Традиційне програмне забезпечення спирається на тестування на одиниці та інтеграцію. Системи-агенти потребують постійної оцінки траєкторій міркувань, взаємодії з інструментами, меж безпеки, ефективності роботи та змін у поведінці з часом. Оцінка перетворюється на окрему сервісну послугу та більше не є одноразовою тестувальною діяльністю.

У наступному розділі ці ідеї перетворюються на конкретний дизайн: платформа оцінювання промислового рівня, побудована на якісних наборах даних, функції повторного відтворення траєкторій, детерміністичні тести контрактів, оцінка за допомогою ШІ-судді, методи кейс-інжинірингу, постійний аналіз регресії та моніторинг у режимі роботи.

Планувальна площина оцінювання

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

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

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

Час виконання агента керує виконанням

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

Шар інструментів відповідає за детерміністичні побічні ефекти

Час виконання ніколи не впливає безпосередньо на інфраструктуру виробництва. Кожна зовнішня функціональність надається через шар детермінованого виконання з суворо типованими контрактами; MCP є одним із прикладів. Цей шар перевіряє схеми, автентифікує користувачів, авторизує дії, забезпечує дотримання політики виконання, застосовує ліміти на спроби, гарантує ідемпотентність там, де це необхідно, та розділяє проблеми інфраструктури від проблем логіки. Він також визначає межу довіри системи: модель пропонує намір, а шар виконання вирішує, чи може цей намір безпечно стати побічним ефектом.

Шар телеметрії володіє канонічним записом

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

Шар оцінки відповідає за перевірку поведінки

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

Репозиторій оцінок зберігає інституційну пам’ять

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

План керування розгортанням забезпечує управління випусками

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

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

Створення конвеєра

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

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

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

dataset:
  id: refund-policy-v2

input:
  query: "Refund my cancelled subscription."

expected_tools:
  - customer.lookup
   - refund.policy

forbidden_tools:
  - payment.capture

constraints:
  max_latency_ms: 3000
  max_tool_calls: 3

success:
  task_completed: true

На відміну від звичайного тесту одиниці, сценарій визначає очікувану поведінку, а не очікувані формулювання.

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

{ "trace_id": "9ab3...",
"span": "tool.crm.lookup",
"latency_ms": 214,
"tokens_input": 684,
"retry_count": 0,
"status": "success"
}

Будь-яку екзекуцію слід можливо відтворити лише на основі даних телеметрії.

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

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

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

Тестування протягом усього життєвого циклу розробки

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

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

Запити типу pull request запускають набір тестів для оцінки в рамках безперервної інтеграції. Цей набір повторно обробляє типові набори даних, виконує детерміністичні перевірки контрактів інфраструктури та застосовує евалюатори поведінки, які виявляють будь-які проблеми з якістю міркувань, вибором інструментів, затримками чи безпекою ще до здійснення злиття коду:

name: Agent Evaluation
on:
  pull_request:
jobs:
  evaluate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Replay Evaluation Suite
        run: deepeval test run evaluation/
      - name: Fail on Regression
        run: promptfoo eval --config promptfooconfig.yaml

Запити на зміни слід оцінювати за їхньою поведінкою, а не лише за вихідним кодом.

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

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

Важливі показники

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

Ситуація з інструментами

Жоден окремий продукт не забезпечує оцінку рівня продакшну. Команди створюють його з використанням спеціалізованих функцій, які охоплюють інструментування, оцінку поведінки, можливості спостереження за процесами та постійні тести на регресію. Екосистема швидко змінюється, але схема залишається незмінною: інструментування фіксує процес виконання, оцінка перетворює ці дані на сигнали, можливості спостереження вимірюють поточну поведінку, а тести на регресію запобігають повторному виникненню старих проблем. Окремі інструменти з’являються та зникають, проте ці чотири функції залишаються ключовими. Надійність забезпечується інженерними можливостями, а не конкретним інструментом.

Чек-лист перед запуском

Перш ніж автономний агент потрапить у продакшн, команда повинна мати можливість дати позитивну відповідь на кожне з цих запитань.

Структура

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

Видимість

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

Оцінка

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

Безпека

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

Стійкість

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

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

Яке це має значення для команди

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

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

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