Оцінка поведінки агента: результати, траєкторії та зворотний зв’язок щодо продукції
Як оцінювати агентські системи поза межами кінцевої відповіді: прив’язати LangChain, LangGraph та LangSmith до ролей, оцінювати траєкторії та контекст, а також враховувати проблеми під час роботи у процесі оцінювання.
Джерела: Building Better Agentic AI Systems: What I Learned About Deep Agents, LangSmith Engine & Evals
Щоб змусити штучного інтелекту працювати у демо-версії за допомогою сучасних моделей та фреймворків, потрібен один день. Справжні труднощі починаються, коли такий агент потрапляє у реальний продукт: він обирає неправильний інструмент, отримує обмежений контекст, обирає маршрут, який ніхто не планував, або повертає відповідь, яка здається правильною, але не є такою. У цій статті розглядається інженерний цикл життя, який робить такі системи надійними, з акцентом на оцінку: що вимірювати, на якому рівні та як перетворювати кожну проблему в продакшені на захід, який запобігає її повторенню. У прикладах використовується екосистема LangChain (LangChain, LangGraph, LangSmith та Deep Agents), але ці ідеї застосовні до будь-якої стеку.
Основну функцію LLM легко уявити: надходить запит, відбувається один виклик моделі, і надходить відповідь.
User → Prompt → LLM → Response
Агент – це щось окреме. Маючи мету, він може розділити роботу на завдання, отримати документи, викликати API, запустити інструменти, зберігати стан, передати частину роботи іншому агенту, перевірити проміжні результати, відновитися після помилок та потім обрати свій наступний крок. Спрощений огляд цього потоку керування:
USER GOAL
│
▼
AGENT
│
PLAN
│
┌──────────────┼──────────────┐
│ │ │
▼ ▼ ▼
TOOLS MEMORY SUBAGENT
│ │ │
└──────────────┼──────────────┘
│
▼
DECIDE / ACT
│
More work needed?
↙ ↘
YES NO
│ │
└── LOOP ▼
RESULT
Зверніть увагу на цикл унизу: агент постійно вирішує, чи потрібна додаткова робота, і кожна ітерація може впливати на інструменти, пам’ять чи підагентів. У цей момент ви вже не надсилаєте відповідь моделі; ви запускаєте систему. Це має значення для якості, адже кінцева відповідь є настільки ж хорошою, наскільки хорошим є ланцюжок рішень, які її створили. Правильна модель із поганим кроком отримання даних чи хороший план, виконаний з неправильним інструментом, все одно призводять до поганого результату.
Призначення ролей: LangChain, LangGraph та LangSmith
Практичний спосіб зрозуміти три основні продукти LangChain — це пов’язати кожен з них із інженерною проблемою, яку він вирішує.
- LangChain забезпечує функціонал, пов’язаний із моделлю: її інтеграцію, інструменти, можливості пошуку та підключення до зовнішніх даних. Його запитання: що має вміти робити додаток?
- LangGraph керує оркестрацією, коли робочі процеси стають агентними, з урахуванням стану, умовних гілок, циклів, викликів інструментів, кроків схвалення людиною та координації кількох агентів. Його запитання: як має виконуватися робочий процес?
- LangSmith відстежує те, що відбувається після запуску системи: які інструменти були використані, який контекст бачила модель, де з’явилась затримка, який крок не спрацював, чому було прийнято певне рішення та чи справді нова версія краща за стару. Його запитання: що насправді сталось, і чи це було добре?
Якщо все це поєднати, процес протікає від бізнес-цілі через необхідні можливості та механізми координації до кінцевого результату, який потім спостерігають та оцінюють, щоб команда могла з нього почерпнути досвід.
BUSINESS GOAL
│
▼
LANGCHAIN
Models • Tools • Data
│
▼
LANGGRAPH
State • Flow • Decisions
│
▼
AGENT SYSTEM
│
▼
RESULT
│
▼
LANGSMITH
Observe • Trace • Eval
│
▼
LEARN
Останній стрілочний знак є найважливішим. Спостереження — це не кінцевий етап; воно сприяє навчанню. Якщо розмежування між LangChain та LangGraph все ще залишається нечітким, наша порівняльна стаття „Ланцюги та станові графи“ детально розглядає це питання.
Використання агентів для покращення агентів: двигун LangSmith
Трекінг точно показує, що робив агент, але сам по собі він нічого не виправляє. Хтось все одно мусить його прочитати, з’ясувати, що пішло не так, перевірити, чи та сама проблема зустрічається ще де-небудь, знайти кореневу причину, змінити систему та підтвердити, що ця зміна не пошкодила щось інше. Це можливо для кількох запусків, але безнадійно при тисячах треків з реального використання.
LangSmith Engine — нова функція LangSmith на момент написання цього тексту — застосовує агента для такого аналізу. Він сканує треки з реального використання на наявність повторюваних закономірностей та проблем, групує пов’язані проблеми, допомагає їх діагностувати та пропонує способи покращення. Найважливіше те, що знайдені ним проблеми можна передати на оцінку, тож проблема, виявлена сьогодні, стає предметом прямої перевірки завтра. Концептуально цей процес виглядає так:
PRODUCTION AGENT
│
▼
TRACES
│
▼
LANGSMITH ENGINE
│
▼
Detect Patterns
│
▼
Diagnose Issues
│
▼
Suggest Improvement
│
▼
Add Evals
│
▼
Regression Testing
│
▼
Review / Deploy
│
└────────► Observe Again
Кожен етап звужує проблему: необроблені дані стають шаблонами, шаблони — діагнозами, діагнози — кандидатами на виправлення, а ці виправлення проходять додаткову перевірку та тести на регресію перед тим, як їх перегляне людина та впровадить. Потім цикл починається знову з нових даних.
Зміна полягає у способі обробки цих даних. Замість того, щоб використовувати їх лише під час інцидентів, вони стають основою для постійного вдосконалення. Саме так вже працює розвинена інженерія якості у традиційному програмному забезпеченні: помилка в продакшені не повинна закінчуватися просто виправленням, а має супроводжуватися тестом, який запобігає повторному виникненню такої ж проблеми. Однак автоматизований діагноз не усуває потреби в перегляді. Пропоновані виправлення до скриптів чи визначень інструментів можуть мати побічні ефекти, тому етапи перегляду та тестів на регресію залишаються частиною процесу.
Глибокі агенти для завдань довгострокового характеру
Деякі запити приховують велику кількість роботи. Розгляньмо запит з області інженерії якості такого типу. При отриманні нової вимоги до продукту агент має переглянути відповідну документацію, позначити найбільш ризиковані сценарії використання, скласти тестові сценарії для них, дослідити код, який реалізує ці сценарії, та описати свої висновки.
Щоб його виконати, агенту потрібно планувати дії, читати файли, отримувати необхідні знання, викликати інструменти, можливо, запускати код, зберігати проміжні результати, делегувати окремі завдання та пам’ятати про те, що він вже дізнався. Структура цієї роботи:
Understand Goal
│
▼
Create Plan
│
┌─────────────┼─────────────┐
│ │ │
▼ ▼ ▼
Read Files Use Tools Search Knowledge
│ │ │
└─────────────┼─────────────┘
│
Delegate Work
│
▼
SUBAGENTS
│
▼
Combine Findings
│
▼
RESULT
Deep Agents — це інструмент від LangChain, призначений для такої довгострокової роботи. Він об’єднує функції планування, роботи з інструментами, обробки файлів, керування контекстом, навичками, пам’яттю та підагентами, тож вам не доводиться самостійно створювати кожен з цих елементів.
Цікавим є не те, що агент може робити більше, а те, як структурована його автономія. Надання агенту двадцяти інструментів не робить його кращим; часто це погіршує вибір інструментів. Розподіл кожного завдання між п’ятьма підагентами також не автоматично покращує архітектуру, оскільки кожна передача коштує токенів та може призвести до втрати контексту. Чим більш здатними стають базові елементи, тим більше значення набувають рішення щодо їх використання. Корисним стандартом є додавати підагента лише тоді, коли підзавдання потребує ізольованого контексту або іншого набору інструментів, та тримати список інструментів кожного агента якомога меншим, наскільки це дозволяє завдання.
Керування агентами — це окрема проблема: керовані глибокі агенти
Створення здатного агента та його надійна робота в умовах продакшну — це дві окремі інженерні задачі. Агент, який працює протягом тривалого часу, може потребувати здатності переживати перерви, зберігати свій стан, працювати з файлами, безпечно виконувати код, передавати інформацію про прогрес до користувацького інтерфейсу, зберігати пам’ять та генерувати достатню кількість даних для телеметрії, щоб інженери могли відтворити те, що сталось.
Managed Deep Agents — це послуга з хостингу в межах того ж екосистеми на момент написання цього тексту, яка орієнтована саме на цей операційний рівень. Взаємозв’язок між ними можна представити як поведінку агента зверху та інфраструктуру часу виконання знизу:
DEEP AGENT
Planning • Tools • Files • Subagents
│
▼
Agent Behavior
│
▼
MANAGED DEEP AGENTS Durable Execution
Persistence
Sandboxes
Memory
Streaming
Identity
Tracing / Evaluation
Агент визначає свою поведінку через планування, інструменти, файли та підагентів. Рівень керування забезпечує стабільну роботу, збереження даних, сандбокси, пам’ять, стрімінг, ідентифікацію та відстеження з можливістю оцінки. Цей загальний принцип залишається актуальним як у випадку використання керованих сервісів, так і при роботі з власними рішеннями: інтелектуальна модель є одним з компонентів архітектури штучного інтелекту в промислових умовах, а інфраструктура, яка її підтримує, потребує такої ж уваги. Наше порівняння механізмів роботи та складених фреймворків розглядає компроміс між створенням власних рішень та їх використанням.
Чому агенти порушують традиційні методи тестування
Традиційне тестування ґрунтується на детермінізмі. Для функції надається відомий вхід, отримується результат, який потім перевіряється.
Input → Function → Output → Assertion
Якщо викликати API з фіксованим запитом, можна перевірити код статусу, схему відповіді, дані навантаження, заголовки та бізнес-правила. Агенти не підходять під цю модель. Попросіть одного з них дослідити інцидент у продакшені та знайти ймовірну причину. У одному випадку він спочатку читає журнали, а потім запитує базу даних; у іншому — переглядає документацію, викликає API тільки після цього читає журнали. Шляхи різні, проте обидва можуть дійти правильного висновку.
Можливий також зворотний варіант, який ще небезпечніший: остаточна відповідь, яка здається правильною, хоча агент спирався на ненадійне джерело, використовував непридатний інструмент або дійшов правильного висновку з неправильних причин. Перевірка точного збігу результату не дозволяє розрізнити ці випадки. Саме цю прогалину заповнюють оцінки.
Що вимірює оцінка
Практичне визначення: оцінка показує, наскільки добре система ШІ виконала завдання з урахуванням стандартів, важливих для конкретної роботи. Критерії визначаються самим завданням, а не фреймворком.
Візьмемо агента, який генерує тестові сценарії на основі вимог. Те, що він повернув десять тестових випадків у форматі JSON, майже нічого не говорить. Значущими є показники якості:
GENERATED TESTS
│
▼
EVALUATE
│
┌────────────────┼────────────────┐
│ │ │
Coverage Correctness Relevance
│ │ │
├──────── Hallucination ──────────┤
│ │
└──────────── Duplication ─────────┘
│
▼
QUALITY SIGNAL
На практиці ці аспекти перетворюються на конкретні запитання:
- Чи дійсно тести охоплюють всі вимоги?
- Чи кожен з них є до них релевантним?
- Чи вигадав агент поведінку, якої немає у продукті?
- Чи пропустив він важливий негативний чи крайній сценарій?
- Чи є кілька з десяти тестів фактично дублікатами?
Кожне запитання може слугувати критерієм оцінки: деякі з них є детермінованими (виявлення дублікатів за допомогою нормалізованого тексту чи ембеддингів), деякі потребують бази даних з прикладами (перевірка відповідності відомим вимогам), а деякі зазвичай потребують оцінки від ШІ-судді чи людських міток (галюцинації у функціоналі). Структурні перевірки, такі як коректність схеми, все ще варто проводити, але як базовий критерій, а не як визначення успіху.
Три аспекти оцінки: відповідь, крок та траєкторія
При роботі з агентами не обов’язково оцінювати лише кінцевий результат. Існує принаймні три корисні критерії:
- Кінцева відповідь: чи є відповідь правильною, повною та релевантною?
- Один крок: наприклад, чи обрав агент правильний інструмент для цієї підзадачі з обґрунтуванням?
Ось типова траєкторія для агента, який відповідає на запитання:
User Goal
│
▼
Agent
│
├── Search Documentation
│
├── Query Database
│
├── Call API
│
└── Generate Answer
Кінцевою відповіддю є лише останній вузол. Для багатьох додатків маршрут має таке ж значення, як і кінцева точка — наприклад, чи звертався агент до документації перед запитом до продакшн-даних, чи здійснив він API-запит, який не мав підстав робити. Оцінка траєкторії стає необхідною, коли агенти можуть змінювати дані, створювати заявки, виконувати код, запускати робочі процеси чи діяти всередині корпоративних систем, адже шкідлива проміжна дія є невдачею, навіть якщо кінцеве повідомлення виглядає коректно. Перевірки траєкторії можуть бути суворими (точна очікувана послідовність), поміркованими (необхідні кроки присутні в будь-якому порядку, заборонені кроки відсутні) або оцінюватися за допомогою моделі; помірковані перевірки зазвичай є правильною відправною точкою, враховуючи описану вище варіабельність маршруту.
Офлайн- та онлайн-оцінки як один цикл
Оцінка природно ділиться на два режими, які відповідають знайомим практикам програмування.
Офлайн: звільнення гейтів для відомих випадків
Під час офлайн-оцінки спочатку аналізуються підготовлені набори даних та сценарії перед випуском. Ви виконуєте репрезентативні випадки з кандидатською версією агента, оцінюєте їх, порівнюєте з поточною версією та вирішуєте, чи розповсюджувати її.
Known Dataset
│
▼
Agent Version
│
▼
Run Evals
│
▼
Compare Results
│
▼
Release Decision
Це еквівалент набору тестів на регресію в системах CI для агентів. Оскільки результати роботи моделі варіюються між запусками, корисно виконувати кожен випадок більше одного разу та порівнювати розподіли оцінок, а не окремі результати.
Онлайн: навчання на реальному трафіку
Онлайн-оцінка вимірює те, що відбувається у продакшені, де саме з’являються несподіванки. Користувачі ставлять запити, яких ніхто не передбачив, зовнішні інструменти виходять з ладу, контекст надходить неповним, дані змінюються під час роботи, а агенти обирають траєкторії, яких немає в жодних наборах даних. Оцінка зразків живих слідів виявляє такі випадки.
Закриття циклу
Ці два режими стають набагато кориснішими, коли вони підключені: кожна значуща проблема у роботі продукту, виявлена онлайн, додається до офлайн-набору даних, щоб наступна версія могла бути протестована за її допомогою.
OFFLINE EVALS
│
▼
BUILD
│
▼
DEPLOY
│
▼
PRODUCTION TRACES
│
▼
ONLINE EVALS
│
▼
DISCOVER FAILURE
│
▼
ADD FAILURE TO DATASET
│
└────────► OFFLINE EVALS
З часом офлайн-система перестає відображати те, що команда уявляла про дії користувачів, і починає відображати те, що вони насправді роблять. Будьте уважні щодо конфіденційності під час копіювання даних з продакшну до наборів даних; приховуйте або синтезуйте конфіденційні поля, перш ніж вони стануть постійними даними для тестування.
Поведінка агента як новий показник якості
Усе це не замінює традиційного тестування. Тестування інтерфейсу користувача, API, інтеграції, перевірки даних, продуктивності та безпеки залишається необхідним для будь-якого надійного продукту. Системи з агентами додають ще один рівень – якість поведінки агента. Цей рівень ставить власні запитання:
- Чи був вибраний інструмент правильним?
Якщо організувати ці запитання у вигляді моделі, вони суттєво відрізняються від класичної піраміди тестування:
AGENT QUALITY
│
┌─────────────────┼─────────────────┐
│ │ │
OUTCOME TRAJECTORY CONTEXT
QUALITY QUALITY QUALITY
│ │ │
▼ ▼ ▼
Correctness Tool Usage Groundedness
Relevance Decisions Relevance
Completeness Efficiency Freshness
│
┌────────┴────────┐
│ │
MEMORY RECOVERY
│ │
▼ ▼
Accuracy Failure Handling
Relevance Retry Behavior
Якість результату враховує правильність, релевантність та повноту. Якість траєкторії охоплює використання інструментів, прийняття рішень та ефективність, а також поділяється на аспекти пам’яті (точність та релевантність отриманих даних) та відновлення (обробка помилок та поведінка під час спроби знову). Якість контексту враховує обґрунтованість, релевантність та актуальність інформації. Кожен листок може відповідати одному або кільком оцінювачам, і разом вони дають набагато більш повну картину, ніж просте позитивне/негативне оцінювання кінцевої відповіді. Для реалізації цього потрібні нові підходи до тестування агентів, забезпечення прозорості, оцінки траєкторій, наборів тестів на регресію ШІ, оцінки продуктивності та постійного вдосконалення, що є сферою все більшого перетину завдань інженерів якості та інженерів ШІ. Щодо аспекту безпеки цієї ж проблеми, дивіться наш посібник про LangChain guardrails та middleware.
Практичні зміни для ваших власних проєктів агентів
Урок, який ми можемо з цього винести, — не приймати кожну нову функцію. Скоріше навпаки: потрібно бути обережнішими щодо архітектури.
- Визначайте критерії оцінки під час проектування агента, а не після його випуску.
- Розглядайте можливість спостереження як частину початкової архітектури, а не як додаток пізніше.
- Надсилайте дані з робочого середовища до відділу інженерії як зворотний зв’язок, а не лише як докази інцидентів.
- Переконайтеся, що кожна значуща проблема в робочому середовищі буде врахована під час майбутньої оцінки.
- Підбирайте рівень складності відповідно до проблеми. Іноді достатньо простого агента; іноді доцільна оркестрація за допомогою LangGraph; іноді завдання справді виграє від підагентів, постійного контексту чи повноцінного інструментарію агента.
Технології мають слідувати за проблемою, а не навпаки.
Цикл вдосконалення
Фреймворки з’являються та зникають; постійною є ідея циклу.
LEARN
│
▼
BUILD
│
▼
OBSERVE
│
▼
EVALUATE
│
▼
IMPROVE
│
└──────────► LEARN AGAIN
Ви вивчаєте певну концепцію та будуєте щось на основі неї. Процес створення виявляє те, чого ви не зрозуміли. Його запуск розкриває проблеми, яких ви не передбачили. Оцінка замінює припущення на докази, докази сприяють покращенню, а покращення зазвичай вказує на те, що потрібно навчитися далі.
Ключові висновки
- Агент — це система рішень; оцінюйте саме рішення, а не лише кінцевий результат.
- Надайте кожному інструменту чітке завдання: LangChain для функціональності, LangGraph для оркестрації, LangSmith для спостереження та оцінки.
- Оцінюйте на трьох рівнях: відповідь, крок та траєкторія; використовуйте більш лояльні перевірки траєкторії, коли існують різні коректні шляхи.
- Поєднуйте онлайн- та офлайн-оцінки, щоб збої в продакшені ставали прикладами регресії.
Моделі, фреймворки та продукти в цій галузі швидко змінюються, тому перевіряйте актуальну документацію щодо таких функцій, як LangSmith Engine та Managed Deep Agents. Саме систематичне спостереження, вимірювання та внесення отриманих уроків назад у систему допоможуть зберегти довіру до ваших агентів попри постійну зміну навколишнього середовища.