Як оцінювати AI-агентів у продакшені: 3-шарова система, яку ми застосовуємо до живих трейсів

Як оцінювати AI-агентів у продакшні: трирівнева система, яку ми застосовуємо на живих трейсах

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

Під час одного з прогонів нашого власного контент-пайплайну Techsy у червні 2026 року агент видав ідеальний на вигляд допис у блозі, і оцінка за фінальний результат його пропустила. Чисто. Ось тільки за три кроки до того інструмент створення брифу викликав не той інструмент пошуку внутрішніх посилань, тож половина посилань кластера вела в нікуди. Знати, як оцінювати AI-агентів у продакшні, — означає виставляти бали за весь шлях, який пройшов агент, а не лише за відповідь, на якій він випадково зупинився.

Ключові висновки:

• Оцінюйте всю траєкторію, а не лише остаточну відповідь: правильна відповідь, отримана хибним шляхом, — це все одно провал.
• Валідуйте виклики інструментів за трьома осями: правильний інструмент, правильні аргументи, правильний крок.
• Проганяйте ті самі метрики офлайн і онлайн, на живих продакшн-трейсах, у безперервному циклі.
• Блокуйте деплой через вразливості безпеки (джейлбрейк, PII, зловживання інструментами), а не лише через низькі показники точності.

Чому оцінювання AI-агентів у продакшні відрізняється від оцінювання LLM?

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

Цей посібник передбачає, що ви вже знайомі із загальним оцінюванням LLM. Якщо ні, почніть з нашого повного посібника з оцінювання LLM, а потім поверніться, щоб дізнатися, що змінюється, коли модель стає агентом. (Ще будуєте агентів, яких збираєтеся оцінювати? Наш огляд найкращих фреймворків для AI-агентів розкриває шар, що лежить в основі.)

Чотири речі ламаються щойно ваш LLM починає діяти самостійно:

• Багатокроковість. Агент підтримки може шукати в базі знань, викликати API замовлень, а потім скласти відповідь. Оцінюйте лише відповідь — і ви не бачитимете двох кроків, які її визначили.
• Недетермінованість. Температура, оновлення ваг моделі та затримки інструментів означають, що той самий запит щоразу йде іншим шляхом. Ваше оцінювання має витримувати рухому ціль.
• Становість. Агенти пишуть у бази даних, надсилають листи, повертають кошти за замовлення. Хибна дія — це не невдале речення, а побічний ефект, який не можна скасувати.
• Накопичення помилок. Трохи хибний крок 2 у 12-кроковому запуску отруює все нижче за потоком, а остаточна відповідь може виглядати цілком нормально.

У звіті Galileo «State of Eval Engineering» за лютий 2026 року, що охопив опитування понад 500 практиків, з'ясувалося, що 84,9% команд стикаються з AI-інцидентом протягом шести місяців після релізу. Інженерна команда Anthropic висловлюється прямо у своєму есе про оцінювання агентів: агенти дають збої на рівні кроків, інструментів і намірів, а не лише на фінальному виході.

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

Які метрики насправді важливі для ШІ-агентів у продакшені?

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

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

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

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

Як оцінювати траєкторію агента, а не його кінцеву відповідь?

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

Уявіть трасування як стек-трейс для міркування. Кожен спан — це один крок: отримання даних, виклик інструменту, передача керування субагенту. Спостережність фіксує ці спани, а оцінювання виставляє їм бали. (Ще не маєте трасування? Наш посібник зі спостережності для ШІ описує шар спостереження, поверх якого працює оцінювання, а наше порівняння LangGraph, CrewAI та OpenAI Agents SDK показує, як виглядає трасування в кожному з них.)

Чому варто оцінювати кожен спан, а не лише кінцеву точку? Через ефект накопичення помилок. Якщо на кроці 2 отримано неправильний документ, кроки з 3 по 12 будуватимуться на хибних даних, і вдале випадкове формулювання в кінці все одно може пройти перевірку лише за результатом. Оцінювання на рівні спанів підкаже, що збій стався саме на кроці 2, а не просто десь у процесі.

Спершу наведемо версію, незалежну від фреймворку (звичайне твердження щодо об'єкта трасування), а потім — скорочений шлях у DeepEval із використанням його метрики на основі трасування Task Completion:

# Незалежно від фреймворку: чи досягла траєкторія мети через валідні кроки?
def score_trace(trace):
    assert trace.steps[-1].status == "success", "final step failed"
    assert all(s.error is None for s in trace.steps), "a mid-run step errored"
    assert "internal_link_lookup" in [s.tool for s in trace.steps], "skipped a required step"
# DeepEval: оцініть увесь багатокроковий трейс на завершеність завдання
from deepeval.tracing import observe
from deepeval.metrics import TaskCompletionMetric

@observe(metrics=[TaskCompletionMetric(threshold=0.7, model="gpt-4o")])
def content_pipeline(topic):
    ...  # your researcher -> brief -> writer -> validator run
    return final_post

Фреймворк-агностичний assert цілком підходить для жорстких, детермінованих перевірок. Task Completion — це інструмент, до якого вдаються, коли успіх розмитіший за просту перевірку на рівність: він витягує з трейсу заплановане завдання й фактично досягнутий результат та оцінює, наскільки добре вони узгоджуються.

Як перевірити, що агент викликав правильний інструмент?

Щоб перевірити виклики інструментів агентом, окремо перевірте три речі: вибір інструменту (чи обрав він правильний інструмент), коректність аргументів (чи передав він правильні параметри та значення) та валідність шляху виконання (чи викликав він цей інструмент на правильному кроці, у правильному порядку). Правильна фінальна відповідь із неправильним викликом інструменту — це баг, який ще не проявився.

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

1. Вибір. Серед доступних інструментів, чи обрав агент правильний? Викликати будь-який інструмент — не те саме, що викликати правильний.
2. Аргументи. Чи передав він правильні параметри? Правильний інструмент із неправильним slug або некоректним форматом дати — це все одно збій.
3. Шлях виконання. Чи викликав він цей інструмент на правильному кроці, у правильному порядку? Повернення коштів до перевірки замовлення — це правильні інструменти в неправильній послідовності.

Метрика Tool Correctness від DeepEval охоплює всі три: вона порівнює tools_called з expected_tools, може зіставляти вхідні параметри, а з should_consider_ordering=True оцінює ще й послідовність.

# Незалежний від фреймворку: правильний інструмент, правильні аргументи, правильний крок
call = trace.steps[2].tool_call
assert call.name == "internal_link_lookup", f"wrong tool: {call.name}"
assert call.args == {"slug": "llm-evals-guide"}, f"wrong args: {call.args}"
# DeepEval: оцінка вибору інструментів + аргументів, з урахуванням порядку
from deepeval.test_case import LLMTestCase, ToolCall, ToolCallParams
from deepeval.metrics import ToolCorrectnessMetric

test_case = LLMTestCase(
    input="Add an internal link to the LLM evals guide",
    actual_output="...",
    tools_called=[ToolCall(name="sitemap_search")],
    expected_tools=[ToolCall(name="internal_link_lookup")],
)
metric = ToolCorrectnessMetric(
    evaluation_params=[ToolCallParams.INPUT_PARAMETERS],
    should_consider_ordering=True,
)
metric.measure(test_case)
print(metric.score, metric.reason)  # 0.0  "expected tool not called"

Ця 0.0 — саме той збій, який ми виявили у власному пайплайні: агент звернувся до sitemap_search, хоча очікуваним інструментом був internal_link_lookup. Готовий допис усе одно пройшов перевірку за оцінкою виводу. Єдиним, що сигналізувало про хибний шлях, була метрика викликів інструментів.

Як запускати оцінювання онлайн, на живих продакшн-трасах?

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

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

1. Офлайн. Виконуйте метрики на еталонному наборі даних у CI. Зупиняйте збірку при регресії.
2. Контроль якості перед розгортанням. Контрольна точка, за яку відповідає людина: чи долає це планку точності та планку безпеки (розділ шість)?
3. Онлайн. Оцінюйте живі продакшн-траси в реальному часі тими самими метриками.
4. Курування. Автоматично збирайте реальні траси (особливо невдалі) назад у ваші набори даних для оцінювання.
5. Повторний запуск. Ваш еталонний набір зростає з реальності, а не з 20 прикладів, які ви написали вручну першого дня.

Підключення онлайн-оцінювання — це те саме інструментування, що й для трасування, плюс збір метрик. Confident AI запускає понад 50 скорерів із DeepEval на живих трасах і сумісний з OpenTelemetry, тому LangGraph, CrewAI, OpenAI та Vercel AI SDK експортують дані без кастомних адаптерів:

# Ті самі метрики, які ви запускали в розробці, тепер оцінюють живий продакшн-трафік
from deepeval.tracing import observe, update_current_span
from deepeval.test_case import LLMTestCase

@observe(metric_collection="Production Agent Quality")
def support_agent(query: str) -> str:
    answer = run_agent(query)  # your live agent
    update_current_span(
        test_case=LLMTestCase(input=query, actual_output=answer)
    )
    return answer
# Метрики колекції тепер застосовуються до кожного трейсу в реальному часі.

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

Контролюйте безпеку, а не лише точність

Бар'єр безпеки блокує розгортання через вразливість, а не лише через низький показник точності. Для агентів це означає змагальні та red-team оцінювання, що перевіряють на джейлбрейки, зловживання інструментами та витік PII, і які виконуються як перед розгортанням, так і онлайн. Джейлбрейк — це не низький бал, який можна усереднити. Це блокувальник релізу.

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

Потім виконайте змагальні оцінювання для цих категорій. OWASP Top 10 для LLM-застосунків, NIST AI Risk Management Framework та MITRE ATLAS дають вам спільну термінологію; red-teaming дає вам тест. DeepTeam, open-source фреймворк для red-teaming від тієї ж команди, яка стоїть за DeepEval, містить понад 120 вразливостей у 8 категоріях і понад 20 векторах атаки, кожна з яких відображена на OWASP, NIST AI RMF та MITRE ATLAS.

Один чесний нюанс щодо інструментарію: DeepTeam OSS — це безкоштовний шлях, який покриває набір вразливостей; керований модуль red-teaming у платформі Confident AI — це функція рівня Enterprise, а не те, що включає план Starter за $9,99. Так чи інакше, вбудуйте red-teaming як першокласний бар'єр, а не як запізнілу думку, яку ви проганяєте раз перед запуском.

Що ми виявили, запустивши це на власному пайплайні

Ми використовуємо цю трирівневу систему на власному мультиагентному контент-пайплайні: чотири агенти (дослідник, розробник брифу, автор контенту, валідатор) передають роботу по ланцюжку. Інтегрувавши DeepEval v4.0.5 у цей пайплайн протягом червня та липня 2026 року, працюючи з нашим робочим простором Confident AI, ми й виявили ту помилку зі вступу. Результат скорера виглядав так:

ToolCorrectnessMetric  score=0.00  threshold=0.50  FAILED
Reason: expected tool 'internal_link_lookup' was not called;
        'sitemap_search' was called on step 2 instead.

Допис уже пройшов оцінку якості результату. У готовій статті нічого не виглядало неправильним. Лише оцінка траєкторії виявила зламаний крок — саме той клас помилок, який перевірка лише за результатом пропускає.

Якщо ви стежите за практиками на r/LLMDevs, r/MachineLearning чи r/LocalLLaMA, ті самі кілька скарг виникають постійно, і вони майже один до одного збігаються з тим, що трирівнева система створена виявляти:

• Проблема «працює в понеділок — падає в середу». Недетермінізм змушує той самий вхідний запит іти іншим шляхом від запуску до запуску, тож команди звикають ігнорувати нестабільні оцінки. Оцінювання на рівні спанів на живих трейсах краще за більший золотий набір даних.
• Втома від золотих датасетів. Тижні, витрачені на ручне розмічування набору, який одна зміна в міркуваннях робить застарілим. Автоматичне курування продакшн-трейсів краще за ручне ведення статичного файлу.
• Недовіра до LLM-судді. Постійно повторювана скарга полягає в тому, що суддя має ті самі сліпі зони, що й агент, — саме тому команди тримають людину в циклі.

Останній пункт — найважливіший. Доменні експерти анотують результати, щодо яких суддя не впевнений, і ці мітки повертаються у вирівнювання метрик — той самий замкнений цикл, який ми описали в нашому огляді Confident AI, суміжний із тим, як ми працюємо з пам'яттю агентів. Суддя масштабується; люди зберігають його чесним.

Яка платформа підійде вашому стеку?

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

Лідером для ентерпрайз-сценаріїв і крос-командного використання є Confident AI. Він покриває повний життєвий цикл якості в одному місці (оцінювання на етапі розробки, продакшн-спостережність, адверсаріальна безпека через DeepTeam, організаційний гейт якості), а його справжня перевага — no-code доступ для команди: інженери налаштовують інтеграцію один раз, після чого PM, QA та доменні експерти самостійно запускають повні цикли оцінювання. Вхід — $9,99/користувач/міс із безкоштовним планом. Він посідає #1 у нашому огляді інструментів оцінювання LLM та #2 у нашому порівнянні платформ AI-спостережності, тож це не вперше, коли він очолює наші рейтинги.

Окремо позиціонується DeepEval — провідний open-source фреймворк, створений тією ж командою, з 50+ скорерами та нативним тестуванням у pytest. Confident AI — це платформа; DeepEval — це OSS-бібліотека, а не скорочена версія платформи. Обирайте його, якщо:

• DeepEval: якщо вам потрібен стандарт з відкритим кодом і ви працюєте в Python та pytest.
• Langfuse: якщо вам потрібне трасування з відкритим кодом, яке можна розгорнути на власному сервері.
• LangSmith: якщо ваш стек повністю побудований на LangChain і LangGraph.
• Arize Phoenix: якщо вам потрібне трасування на основі OpenTelemetry, повністю з відкритим кодом.
• Braintrust: якщо вам потрібні комплексні оцінки плюс експерименти зі щедрим безплатним тарифом.
• Promptfoo: якщо ви працюєте в CLI і хочете мати red-teaming у тому самому інструменті.
• Ragas: якщо ваш агент — це, по суті, RAG-конвеєр і вам потрібні метрики, специфічні для пошуку.
• Galileo: якщо вам потрібен готовий керований індекс галюцинацій та якості з коробки.
• Maxim: якщо вам потрібен робочий процес симуляції та оцінки для багатоходових агентів.
• W&B Weave: якщо ви вже працюєте в Weights & Biases і хочете мати трасування поруч із вашими навчальними прогонами.

Одне чесне обмеження Confident AI: керований модуль red-teaming і розгортання на власному сервері доступні лише на рівні Enterprise, а резидентність даних у США/ЄС — це функція тарифів Team/Enterprise, а не універсальний перемикач під час реєстрації. Одиночний розробник, який випускає одного агента, може почати з безплатного DeepEval OSS і додати платформу, коли цілій команді знадобиться запускати оцінки.

Про автора

Мерт Батур Гюрбюз, співзасновник Techsy.io (Бірмінгемський університет). Мерт Батур Гюрбюз — співзасновник Techsy.io, де команда створює AI-агентів, системи автоматизації та голосові/SDR-конвеєри для B2B-клієнтів. Він навчається в Бірмінгемському університеті та пише про стек інструментів для LLM, який команда Techsy реально використовує у продакшені. Підключайтесь у LinkedIn.

Поширені запитання

Що таке оцінювання ШІ-агентів?

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

Як оцінювати траєкторію агента на противагу його фінальному результату?

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

Як перевірити, що агент викликав потрібний інструмент?

Окремо перевіряють три речі: вибір інструменту (чи правильний інструмент обрано для завдання), коректність аргументів (чи правильні параметри та значення) і валідність шляху виконання (чи правильний крок і порядок). Фреймворки на кшталт метрики Tool Correctness від DeepEval порівнюють фактично викликані інструменти з очікуваними, зіставляють вхідні параметри й можуть оцінювати порядок викликів, якщо цю опцію увімкнено.

Які метрики найважливіші для AI-агентів у продакшені?

Насамперед — рівень успішного виконання завдань і вартість одного успішного завдання, а вже потім — перцентилі затримки (p50, p90, p99), точність викликів інструментів, достовірність, частота втручання людини, дрейф і частота проходження перевірок безпеки. Вартість успішного завдання важливіша за просту вартість, адже звичайна вартість одного завдання непомітно заохочує агентів, які швидко й дешево зазнають невдачі.

Яка різниця між офлайн- та онлайн-оцінюванням агентів?

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

Як часто потрібно повторно запускати оцінювання агентів?

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

Як виявити джейлбрейки та витоки PII до релізу?

Запускайте адверсаріальні red-team оцінювання як гейт перед деплоєм і продовжуйте їх онлайн-моніторинг. Зіставляйте режими відмов із OWASP Top 10 для LLM, NIST AI RMF та MITRE ATLAS, а потім симулюйте атаки на кожну категорію за допомогою фреймворку на кшталт open-source DeepTeam. Блокуйте реліз за будь-якої вразливості, яка проходить, а не лише за низького середнього балу.

Чи варто створювати власну платформу оцінки AI-агентів чи купувати готову?

Використовуйте інструменти з відкритим кодом (DeepEval для метрик, Promptfoo для CLI-тестування та ред-тімінгу), якщо ви соло-розробник або невелика інженерна команда, якій зручно працювати з кодом. Купуйте платформу на кшталт Confident AI, коли всій команді потрібен доступ без коду на рівні організації, кероване тестування безпеки та стандартизована спостережність у продакшені для всіх проєктів. Більшість команд починають з OSS, а згодом переходять на готові платформи.

Чи надійний LLM-як-суддя для оцінювання агентів?

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

Тришарова система — одним подихом

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

Починайте з того шару, який болить найбільше: якщо ви релізите наосліп — спершу підключіть онлайн-оцінку; якщо релізите небезпечно — спершу побудуйте шлюз безпеки. Зберіть це на основі DeepEval і Promptfoo з відкритим кодом або купіть платформу на кшталт Confident AI, якщо всій команді потрібен no-code доступ і керована безпека. А якщо ви хочете, щоб інженери підключили весь цей цикл за вас — саме цим наша команда займається щотижня.