Ответы на самые частые вопросы об оценке агентов

В процессе разработки и выпуска агента вам потребуется способ проверки того, что он ведет себя ожидаемым образом — как на этапе разработки, так и после того, как реальные пользователи начнут им пользоваться.

В традиционном программном обеспечении одни и те же входные данные дают одни и те же выходные, поэтому модульный тест может проверить результат на точное соответствие. Агентов тестировать сложнее по нескольким причинам:

• Результаты варьируются от запуска к запуску, даже при одинаковом запросе.
• Правильных ответов может быть несколько, поэтому проверка на точное совпадение не подходит.
• Агент сам выбирает шаги, поэтому правильный результат может быть получен «неправильным» путем. Например, агент может вызвать инструмент, который ему не нужен, или выполнить действие без разрешения пользователя.

Оценка агентов (agent evals) — это решение данной проблемы. Она оценивает запуски вашего агента с помощью проверок, учитывающих эти вариации. Подобно самим агентам, которых они оценивают, эти тесты не являются универсальными, и лучший набор оценок зависит от команды, их продукта и того, что именно они хотят оптимизировать.

За последние несколько лет работы над LangSmith, платформой LangChain для разработки агентов, наша команда столкнулась с множеством различных вопросов по оценке. В этом блоге мы разберем самые частые вопросы о том, как начать работу с оценкой агентов и какие типы оценок можно использовать в своих рабочих процессах.

С чего начать?

Любая оценка начинается с понимания того, что на самом деле делает ваш агент. Трассировка (trace) — это запись одного запуска вашего агента, включающая его входные данные, выходные данные, а также все вызовы моделей и инструментов между ними. Просмотрите примеры трассировок, чтобы увидеть, как агент обрабатывает запросы и где он ошибается. То, что вы обнаружите, подскажет, что тестировать в первую очередь. Начните с малого.

• Выберите поведение, которое вас беспокоит. Например, для туристического помощника таким поведением может быть проверка того, бронирует ли он дату и ценовой диапазон, которые запросил пользователь.
• Создайте небольшой набор данных из трассировок. Набор данных — это коллекция примеров, где каждый пример является отдельным тестовым случаем с входными данными и часто ожидаемым выходным результатом. Десяти-двадцати примеров одного поведения достаточно для начала, и в LangSmith вы можете добавлять трассировки в набор данных прямо из представления трассировки. Если ваш агент еще не запущен в продакшене, попросите свою команду или небольшую группу доверенных партнеров протестировать его (dogfooding) и работайте с полученными трассировками.
• Запустите базовый тест. Запустите текущую версию агента на наборе данных и сохраните результат как эксперимент. Эксперимент содержит результаты запуска одной версии вашего агента на наборе данных вместе с оценками от ваших инструментов оценки. Вы будете сравнивать производительность будущих версий вашего агента с этим экспериментом.
• Добавляйте новые ошибки по мере их обнаружения. Каждая ошибка, которую вы видите в продакшене или во время тестирования, становится новым примером.

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

В чем разница между офлайн- и онлайн-оценками?

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

Офлайн-оценки запускают вашего агента на наборе данных до того, как вы выпустите изменение. Вы выбираете входные данные для примеров, а также можете включить ожидаемые выходные данные (также называемые эталонными). Используя свой набор данных, вы можете сравнивать результаты экспериментов для разных версий агента. Они лучше всего подходят для тестирования нового промпта, модели или инструмента, а также для предотвращения регрессий до того, как они дойдут до пользователей.

Бенчмарки, такие как Benchmarks, также являются офлайн-оценками, построенными на фиксированном наборе задач, чтобы вы могли сравнивать агентов, модели или версии. Harbor запускает их и записывает результаты в эксперименты LangSmith, о чем мы подробнее расскажем ниже.

Онлайн-оценки оценивают реальные трассировки из продакшена по мере их поступления. Обычно здесь нет эталонного вывода для сравнения, поэтому они полагаются на проверки кода и LLM-судей, которые могут оценить запуск самостоятельно. Они лучше всего подходят для мониторинга качества и поиска проблем, которые пропустил ваш набор данных.

Вам нужны оба типа, и они дополняют друг друга. Ошибки, которые выявляют онлайн-оценки, становятся новыми примерами в вашем офлайн-наборе данных.

В LangSmith есть несколько способов создания набора данных для офлайн-оценок. Вы можете написать примеры с нуля, добавить запуски из существующих трассировок, отправить запуски, которые ваша команда проверила в очереди аннотирования, загрузить CSV или JSONL файл или сгенерировать синтетические примеры на основе нескольких уже имеющихся.

По мере роста вашего набора тестов вам нужно будет решить, добавлять ли примеры в существующий набор данных или начинать новый. Как правило:

• Храните примеры в одном наборе данных, если они тестируют одно и то же поведение с помощью одних и тех же инструментов оценки, чтобы эксперименты оставались сопоставимыми с течением времени.
• Создавайте новый набор данных, когда входные данные выглядят иначе (например, отдельные запросы против полных диалогов), когда вам нужны другие инструменты оценки или когда набор данных служит другой цели, например, небольшой набор, который запускается при каждом pull request, против более крупного, который вы запускаете перед релизом.

В рамках одного набора данных вы также можете использовать разделения (splits) для запуска подмножества примеров.

Какие существуют типы инструментов оценки агентов?

Инструмент оценки (evaluator) — это логика, которая выставляет оценку запуску. Существует четыре распространенных типа. Большинство команд начинают с одного или двух и добавляют остальные со временем.

• Инструменты оценки на основе кода проверяют вещи детерминированно, например, является ли забронированная цена ниже бюджета пользователя. Они быстрые, дешевые и последовательные, хотя их потребность в детерминированных входных и выходных данных ограничивает их полезность.
• LLM-как-судья (LLM-as-a-judge) использует модель для оценки того, что код не может проверить, например, четко ли ответ помощника подтверждает детали рейса.
• Человеческая проверка предполагает, что ваша команда или профильные эксперты оценивают запуски напрямую. Это медленнее, но это лучший сигнал для субъективного качества и для проверки других ваших инструментов оценки. Часто используется на небольшой выборке, чтобы затем информировать суждение LLM-оценщика.
• Парные инструменты оценки (pairwise evaluators) сравнивают два результата бок о бок и выбирают лучший, что полезно, когда вы выбираете между двумя промптами или моделями.

Любой из этих инструментов оценки может быть направлен на разные части запуска агента. Оценка может оценивать:

• Один шаг. Например, был ли вызван search_flights с правильной датой.
• Итоговый ответ. Например, подтверждает ли ответ рейс, который агент фактически забронировал.
• Полный диалог. Например, отражает ли итоговое бронирование все изменения, которые пользователь запрашивал на протяжении нескольких шагов.
• Конечное состояние среды. Например, записи о бронировании в имитационной системе бронирования после того, как агент отработал в своем контейнере. Бенчмарки часто используют эту настройку, и иногда вы можете услышать, как их называют контейнеризированными оценками.

Можно ли доверять LLM-судье?

LLM-судья использует модель для оценки результатов, которые трудно проверить с помощью кода, например, подтверждается ли ответ полученными документами. Судьи гибкие, но они могут быть непоследовательными и отклоняться от суждений вашей команды. Несколько привычек делают их надежными:

• Сравните оценку судьи с оценками людей. Попросите кого-то из вашей команды оценить выборку запусков и проверьте, в каких местах судья не согласен. Корректируйте промпт или примеры судьи до тех пор, пока они не совпадут. Очереди аннотирования в LangSmith упрощают этот процесс. Наша документация по LLM-as-a-judge поможет вам во всем разобраться.
• Задавайте узкие вопросы. В нашем примере с турагентом вопрос «Упоминает ли ответ все пересадки?» оценить проще, чем «Хороший ли это ответ?»
• Определите точную шкалу оценки. Бинарная система (прошел/не прошел) или небольшой набор категорий гораздо более воспроизводимы, чем оценка по шкале от 1 до 10. Судье может быть трудно отличить оценку 6 от 7.

Являются ли оценки (evals) тем же самым, что и бенчмарки?

Бенчмарк — это тип офлайн-оценки, состоящий из набора задач. Задача — это отдельный тестовый случай в бенчмарке, включающий инструкции, среду в контейнере и тестовый скрипт, который оценивает результат. По мере того как агенты становятся более способными, простого LLM-судьи или оценки на основе кода часто бывает недостаточно. Агенты теперь могут выполнять код, редактировать файлы и взаимодействовать со службами. Чтобы моделировать такое многошаговое поведение, бенчмарки создают изолированную инфраструктуру в контейнерах. Это позволяет разработчикам тестировать поведение агента офлайн так же, как агент будет работать в продакшене.

Бенчмарки отличаются от более простых LLM-судей и оценок на основе кода по нескольким параметрам:

• Задачи включают больше шагов. Чтобы выполнить одну задачу, агент может устанавливать пакеты, редактировать файлы и выполнять команды с помощью десятков вызовов инструментов.
• Каждая задача поставляется со своей средой. Агенты теперь могут совершать действия в таких средах, как «песочница» с репозиторием кода, файлами и инструментами. Каждая задача поставляется со своей изолированной средой, в которой работает агент.
• Оценка проверяет действия агента. Тестовый скрипт проверяет состояние среды после запуска, например, прошли ли тесты или существует ли нужный файл. Вы по-прежнему можете просматривать трассировку, но оценка выставляется на основе действий, которые предпринял агент, и состояния, которое он оставил после себя.

Для нашего турагента задача бенчмарка может предоставить агенту имитацию системы бронирования и запрос типа: «Шторм отменил рейс путешественника в Денвер. Перебронируйте его и измените отель в соответствии с новыми данными». После того как агент закончит, тестовый скрипт проверит записи о бронировании в базе данных.

Harbor — это инструмент для оценки с открытым исходным кодом, который предоставляет основу для тестирования таких длительных задач. Это фреймворк, на котором работает Terminal-Bench, и вы можете использовать тот же формат задач для создания бенчмарка для своего собственного агента. Благодаря интеграции с LangSmith каждый запуск Harbor регистрируется как эксперимент в LangSmith. Harbor создает контейнер для каждой задачи, и вы можете использовать трассировки LangSmith, чтобы сделать каждую среду максимально приближенной к той, которую видит ваш агент в продакшене. Результаты бенчмарка затем отображаются вместе с остальными вашими оценками, и вы можете открыть любой запуск, чтобы увидеть полную трассировку рядом с его оценкой.

Мы использовали эту настройку для улучшения Deep Agents в Terminal-Bench 2.0, просматривая трассировки для поиска режимов сбоев, а затем изменяя инструментарий. Мы также использовали его для создания IssueBench, бенчмарка для LangSmith Engine. Каждая задача IssueBench предоставляет Engine пакет трассировок и оценивает, правильно ли он группирует их в нужные кластеры проблем.

Создание бенчмарка для вашего собственного агента выполняется по тем же шагам, что и оценки выше, с несколькими изменениями:

• Собирайте задачи из трассировок. Находите сбои в трассировках LangSmith, затем превращайте каждую из них в задачу Harbor с собственной средой, например, имитацией системы бронирования, заполненной бронированиями пользователя.
• Определите, что считается «хорошим». Создавайте LLM-судей или оценки на основе кода, которые выставляют баллы на основе вашей рубрики.
• Поднимайтесь по шкале оценок. Запускайте агента и используйте оценки для A/B-тестирования изменений. Вы можете настроить цикл агента, который будет выполнять этот процесс за вас. Он будет вносить правки в вашего агента, перезапускать бенчмарк и сохранять или отменять каждое изменение, подобно циклу autoresearch Андрея Карпатого, о котором он рассказывал несколько месяцев назад.

Как оценивать продакшен-трафик без высоких затрат?

Офлайн-оценки выполняются на фиксированном наборе данных, поэтому их стоимость предсказуема. Онлайн-оценки выполняются на реальном трафике, поэтому, если LLM-судья оценивает каждую трассировку, ваши расходы на оценку растут с каждым новым пользователем. Чтобы сохранить их доступность:

• Выбирайте и фильтруйте. Онлайн-оценщики в LangSmith могут оценивать процент трафика или только те трассировки, которые соответствуют фильтру, например, отрицательным отзывам пользователей.
• Используйте проверки кода там, где это возможно. Проверка того, соответствует ли бронирование запрошенной дате или искал ли агент информацию перед бронированием, почти ничего не стоит.
• Используйте более дешевого судью. В нашем эксперименте Jev-as-a-Judge, Jev от TypeSafe AI соответствовал человеческим меткам при каждом решении «прошел/не прошел» и стоил в общей сложности $0,34 по сравнению с $28,17 за Claude Sonnet 4.6.

Расходы на онлайн-оценку сохраняются в LangSmith с течением времени, поэтому команды могут контролировать свои расходы.

Обязательно ли создавать свои собственные оценки агентов?

Нет, особенно когда вы оцениваете типичные проблемы агентов. Хорошее начало — использовать наши готовые шаблоны оценщиков LLM в LangSmith для типичных проверок, таких как галлюцинации или утечка персональных данных (PII). Добавьте один из них в набор данных или проект трассировки и отредактируйте его промпт, чтобы он соответствовал вашему агенту, например, указав судье, что наш турагент никогда не должен бронировать услуги вне бюджета пользователя.

Наш пакет с открытым исходным кодом agentevals также содержит готовые оценщики для сообщений агента и вызовов инструментов. Они могут сравнивать инструменты, которые вызывал ваш агент, со справочным списком или спрашивать у LLM-судьи, имели ли смысл предпринятые шаги.

Вы также можете повторно использовать офлайн-оценщик для разных наборов данных и запускать его как онлайн-оценщик для трассировок в продакшене (работает только в том случае, если оценщику не требуется эталонный вывод).

Для оценок, специфичных для вашего агента, навык Eval Engineering запускается в агентах кодирования, таких как Claude Code или Codex, считывает ваш репозиторий и трассировки и пишет вместе с вами исполняемые оценки.

LangSmith Engine также может автоматически писать оценки для вас, извлекая данные из трассировок продакшена. Когда он идентифицирует кластер проблем, он превращает неудачные трассировки в примеры наборов данных и записывает их эталонные выводы в виде утверждений, таких как «Бронирует рейс на дату, которую запросил пользователь».

Как оценивать многоходовые диалоги?

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

Чтобы оценивать диалоги в LangSmith, передавайте идентификатор потока (thread ID) в метаданных вашей трассировки, чтобы каждый ход был сгруппирован в поток. Поток — это последовательность трассировок из одного и того же диалога. После этого вы можете прикрепить онлайн-оценщиков, которые оценивают весь поток после завершения диалога, с такими вопросами, как «Отразило ли итоговое бронирование все изменения, о которых просил пользователь?» или «Приходилось ли пользователю повторяться?». LangSmith также показывает каждый поток как траекторию, где каждое сообщение и вызов инструмента перечислены один раз в порядке очереди.

Для офлайн-оценок вы можете хранить полные диалоги в качестве примеров в наборе данных или имитировать пользователя с помощью LLM, чтобы вы могли протестировать, как агент справляется с диалогом от начала до конца.

Как оценивать агента помимо его финального вывода?

Агенты выполняют множество шагов, поэтому итоговый ответ отражает лишь часть произошедшего. Помимо финального ответа, вам может потребоваться проверить:

• Путь, то есть последовательность сообщений и вызовов инструментов, созданных агентом.
• Финальное состояние, например, запись о бронировании, созданная нашим туристическим агентом, файл, который он записал, или изменения, внесенные в репозиторий.

По мере того как ваши рабочие агенты становятся все более сложными, вам может потребоваться специализированная система оценки (eval harness). В частности, это актуально, когда результатом работы агента являются изменения в среде. Допустим, агенту по программированию поручено исправить ошибку. LLM-судья может прочитать ответ агента, но надежной проверкой будет запуск тестов репозитория после завершения работы агента. Чтобы это сработало, для каждого запуска теста нужна собственная чистая копия репозитория, чтобы запуски не влияли друг на друга. Harbor настраивает это за вас. Вы можете запускать агентов, созданных с помощью Deep Agents в LangSmith Sandboxes, и регистрировать каждый запуск вместе с его трассировкой в эксперименте LangSmith. Узнайте больше в Harbor x LangChain.

Можно ли отслеживать и оценивать агента в LangSmith, если он не создан с использованием LangChain, LangGraph или Deep Agents?

Да! LangSmith не зависит от фреймворка, поэтому вы можете отслеживать и оценивать агента, созданного с помощью любого фреймворка или вообще без него. Есть несколько способов отправки трассировок:

• Интеграции с фреймворками. LangSmith имеет интеграции для популярных агентских фреймворков, таких как OpenAI Agents SDK, Claude Agent SDK и другие.
• Обертки провайдеров моделей. Если вы вызываете провайдера модели напрямую, оберните клиент для OpenAI или Anthropic, и каждый вызов модели будет отслежен.
• Декоратор @traceable. Добавьте его к своим собственным функциям, например, к инструменту поиска рейсов для туристического помощника, чтобы отслеживать любой шаг вашего агента.

Как только ваши трассировки окажутся в LangSmith, оценки будут работать одинаково для любого фреймворка. Вы можете добавлять трассировки в набор данных, проводить офлайн-эксперименты, передавая своего агента в функцию evaluate() SDK, и подключать онлайн-оценщики к производственному трафику.

Как перейти с существующего стека оценки?

Вам не нужно начинать все сначала. Большая часть того, что вы уже создали, переносится в LangSmith:

• Наборы данных. Загрузите существующие тестовые примеры в виде файла CSV или JSONL или создайте их с помощью SDK.
• Оценщики кода. Существующие функции оценки обычно требуют лишь небольших изменений, чтобы работать как оценщики LangSmith. Если ваши оценки уже работают как тесты, интеграции pytest и Vitest позволят вам сохранить эту настройку.
• LLM-судьи. Вставьте свой существующий промпт судьи в оценщик «LLM-как-судья» в пользовательском интерфейсе или сохраните его в коде.
• Трассировка. LangSmith работает с любым фреймворком, поэтому вы можете отправлять трассировки от своего текущего агента, не переписывая его.

Как сообщать о результатах?

Офлайн-эксперименты показывают, привел ли каждый релиз к улучшению. Онлайн-панели оценки показывают, как производительность сохраняется в рабочей среде с течением времени. В LangSmith вы можете напрямую сравнивать результаты экспериментов и создавать пользовательские панели мониторинга для таких метрик, как стоимость токенов, задержка и оценки оценщиков с течением времени. Бенчмарк дает стабильную оценку для сравнения моделей или версий агентов между релизами.

Далее

Если вы хотите углубиться в тему, прочитайте «Как мы создаем оценки для Deep Agents», попробуйте краткое руководство по оценке в LangSmith или ознакомьтесь с нашим курсом LangChain Academy по основам LangSmith.

Предпочитаете живое обучение? Я проведу виртуальный семинар по оценке агентов 28 октября 2026 года. Зарегистрируйтесь здесь!