Оценка поведения агента: результаты, траектории и обратная связь от производства
Как оценивать агентные системы не только по итоговому ответу: соотнести LangChain, LangGraph и LangSmith с определенными ролями, проанализировать траектории оценок и контекст, а также учитывать сбои в процессе работы при оценке.
Источники: Building Better Agentic AI Systems: What I Learned About Deep Agents, LangSmith Engine & Evals
Чтобы заставить ИИ-агента работать в демо-версии с использованием современных моделей и фреймворков, требуется всего один день. Но настоящие трудности начинаются, когда такой агент попадает в реальный продукт: он выбирает неподходящий инструмент, получает ограниченный контекст, следует маршрутом, который никто не планировал, или возвращает ответ, который на первый взгляд кажется правильным, но на самом деле им не является. В этой статье рассматривается жизненный цикл разработки, делающий такие системы надежными, с акцентом на оценку: что измерять, на каком уровне и как превращать каждую неисправность в механизм предотвращения её повторения. В примерах используется экосистема LangChain (LangChain, LangGraph, LangSmith и Deep Agents), но эти принципы применимы к любой технологической стеку.
От одного вызова большой языковой модели к агентной системе
Основная функция большой языковой модели легко представима: поступает запрос, происходит один вызов модели, и приходит ответ.
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 до сих пор неясны, наша статья «Цепочки и графы с состоянием: как выбрать между 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 and middleware.
Практические изменения для ваших собственных проектов агентов
Урок, который можно извлечь из всего этого, заключается не в том, чтобы принимать каждую новую функцию. Скорее наоборот: нужно более тщательно подходить к проектированию архитектуры.
- Определяйте критерии оценки при проектировании агента, а не после его выпуска.
- Рассматривайте возможность отслеживания состояния как часть первоначальной архитектуры, а не как дополнение позже.
- Перенаправляйте данные о работе в производственной среде обратно в отдел инженерии в качестве обратной связи, а не просто в качестве доказательств возникших проблем.
- Убедитесь, что каждая серьезная ошибка в производственной среде будет учтена при будущей оценке.
- Соотносите сложность решения с самой проблемой. Иногда достаточен простой агент; иногда оправдана использование механизмов orchestration вроде LangGraph; иногда задача действительно выигрывает от использования подагентов, постоянного контекста или полноценной архитектуры агента.
Технологии должны следовать за проблемой, а не наоборот.
Цикл улучшений
Фреймворки появляются и исчезают; постоянной остается сама концепция цикла.
LEARN
│
▼
BUILD
│
▼
OBSERVE
│
▼
EVALUATE
│
▼
IMPROVE
│
└──────────► LEARN AGAIN
Вы изучаете ту или иную концепцию и используете её для создания решений. Процесс разработки выявляет то, чего вы не понимали. Его запуск раскрывает проблемы, которых вы не предвидели. Оценка заменяет догадки на факты, факты способствуют улучшениям, а улучшения обычно показывают, что следует изучить дальше.
Основные выводы
- Агент — это система решений; оценивайте сами решения, а не только конечный результат.
- Назначайте каждому инструменту четкую задачу: LangChain — для реализации функций, LangGraph — для организации процессов, LangSmith — для наблюдения и оценки.
- Оценивайте на трех уровнях: ответ, отдельные шаги и общий ход действий; предпочитайте более гибкие проверки хода действий, когда существуют разные варианты развития событий.
- Соединяйте онлайн- и офлайн-оценки, чтобы сбои в производстве превращались в случаи регрессии.
Модели, фреймворки и продукты в этой области быстро меняются, поэтому проверяйте актуальную документацию на наличие таких функций, как LangSmith Engine и Managed Deep Agents. Систематическое наблюдение, измерение и внесение полученных уроков обратно в систему — вот что поможет сохранить доверие к вашим агентам на фоне постоянных изменений в окружающей среде.