2026-06-10 · Обновлено 2026-07-22

[!NOTE] Автоматический перевод Эта статья была автоматически переведена с оригинальной английской версии.

Оценка работы ИИ-агенты в продакшене: от Трейсы до наборов тестов

Чат-бот предоставляет вам лишь один ответ для оценки. Агент же передаёт целое дерево решений: планы, tool calls, попытки повтора и момент, когда он принял решение о завершении работы.

Для учёта такой разницы требуется иной метод оценки. Итоговый ответ может казаться корректным даже в тех случаях, когда агент пропустил необходимый инструмент, выполнил один и тот же вызов 17 раз, неправильно интерпретировал результат или выбрал путь, запрещённый правилами производственной среды. Оценивание, основанное исключительно на ответе, скрывает эти сбои.

Кратко: Агенту эвалы требуются три уровня метрик: метрики результата, метрики траектории и метрики компонентов. Структура разработки должна строиться по следующему циклу: трейс -> маркировка -> кластеризация -> удаление дубликатов -> версионированный датасет -> проверка в рамках CI -> онлайн-мониторинг. Для определения порядка выполнения инструментов, аргументов, логических циклов и неизменяемых свойств следует применять детерминистичные проверки. Использовать LLM джаджи допускается только в тех случаях, когда результат проверки зависит от интерпретации; такие джаджи необходимо сформировать с использованием подхода Schema-Guided Ризонинг (SGR), а затем откалибровать их на основе человеческих меток перед тем, как начинать полагаться на них.

Почему агенты эвалы отличаются друг от друга

Традиционные LLM эвалы обычно оценивают лишь одну пару «вход — выход»: релевантность, точность воспроизведения, корректность, безопасность и, возможно, стиль. Агенты же добавляют элементы планирование, tool calls, механизмы повторных попыток и проверки завершения работы, в результате чего каждый шаг становится потенциальной точкой возникновения сбоев.

Найдите агента по возврату средств. Лог-файл может оказаться корректным, даже если трейс содержит ошибку:

lookup_order -> issue_refund -> final_answer

Результат эвал соответствует требованиям. Траектория эвал должна дать отрицательный результат, поскольку verify_identity Никогда ранее не запускался. issue_refund. Для агентов, использующих инструменты, тесты типа «только ответ» эвалы являются простыми проверками на наличие критических сбоев: они выявляют полную неработоспособность, но не фиксируют никаких других проблем.

Есть ещё одна проблема: ошибки накапливаются. Если в рабочем процессе предусмотрено 20 обязательных шагов, каждый из которых выполняется независимо, и у каждого шага одинаковая надёжность в 95%, то общий уровень успешного завершения процесса составляет примерно 36%:

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

Два исследовательских коллектива подготовили количественные оценки по этому вопросу.

tau-bench агенту задаются задачи по обслуживанию пассажиров авиакомпании и розничных клиентов. Агент ведёт разговор с симулированным пользователем, выполняет вызов APIs и обязан соблюдать доменную политику. После завершения разговора оценщик проверяет, достигла ли база данных указанного состояния с аннотациями. Даже при наличии правдоподобной транскрипции с неверными строками тест считается неудачным.

При такой оценке даже GPT-4o смог решить менее половины задач. В статье также были представлены pass^k: выполнить ту же задачу k считать прохождение только тогда, когда агент добивается успеха во всех операциях k запускается.

результаты тестирования в режиме ритейла, которые казались приемлемыми при одной попытке, упали ниже 25% при k = 8. Тот же агент выполнял одну и ту же задачу восемь раз и получал в основном разные результаты. Одиночный запуск эвал не позволяет выявить такую несогласованность.

MAST Исследуется причина сбоев агентов. Авторы проанализировали более 1 600 примеров выполнения трейсы из 7 популярных multi-agent фреймворки и классифицировали эти сбои на 14 типовых моделей. В эту классификацию входят нечеткие определения ролей (в рамках проектирования системы), ситуации, когда один агент игнорирует информацию, переданную другим (несоответствие между агентами), а также случаи объявления успеха без проверки результата (отсутствие верификации). Такие сбои связаны с нарушениями в логике промпты и оркестрация, а также с отсутствием необходимых проверок в харнесс. Более надежная база модель не может выполнять шаг верификации, если он изначально не был реализован; поэтому цель оценки должна включать контрольные механизмы харнесс, действующие вокруг модель.

Разрыв в внедрении

Результаты опроса LangChain показывают, что у многих респондентов уже имеются необходимые ресурсы для улучшения эвалы: 89% сообщили о наличии определённых observability, в то время как 52,4% выполняли работу в оффлайн-режиме с использованием эвалы, а 37,3% — в онлайн-режиме с применением эвалы.

То же самое Состояние инжиниринга агентов Отчеты опросов показывают, что 57,3% респондентов уже используют агенты в реальных проектах. При ответе на вопрос о факторах, препятствующих запуску в производство, 32% назвали проблемы с качеством, а 20% — латентность. Речь идет о опросе, проведенном поставщиком среди своих клиентов, а не об обследовании всех команд, работающих с агентами, однако он выявляет значимый разрыв между сбором трейс данных и их систематической оценкой.

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

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

Выбор метрик по модулю сбоев

Подходящая метрика определяется способом сбоя, а не фреймворк. Полезное разделение включает три уровня:

1. Результат эвалы указывает на то, была ли задача выполнена успешно.
2. Траектория эвалы показывает, соответствовало ли выбранное направление правилам, было ли оно эффективным и корректным.
3. Компонент эвалы определяет, какой инструмент, ретривер, саб-агент или этап принятия решений вызвал сбой.

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

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

Корректность вызова инструмента

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

• Точное совпадение: последовательность должна совпадать полностью. Используйте этот вариант тогда, когда важен порядок элементов, например lookup_order -> verify_identity -> issue_refund.
• Соответствие в порядке последовательности: необходимые инструменты должны появляться в правильном относительном порядке, однако допускаются дополнительные безвредные вызовы.
• Соответствие в произвольном порядке: необходимые инструменты обязаны присутствовать, но их порядок может отличаться.

Для начала достаточно небольшого локального счетчика оценок:

from collections import Counter


def tool_correctness(called: list[str], expected: list[str], mode: str = "in_order") -> float:
    if not expected:
        return 1.0
    if mode == "exact":
        return float(called == expected)
    if mode == "any_order":
        matched = sum((Counter(called) & Counter(expected)).values())
        return matched / len(expected)

    rows = [[0] * (len(expected) + 1) for _ in range(len(called) + 1)]
    for i, tool in enumerate(called):
        for j, wanted in enumerate(expected):
            if tool == wanted:
                rows[i + 1][j + 1] = rows[i][j] + 1
            else:
                rows[i + 1][j + 1] = max(rows[i][j + 1], rows[i + 1][j])
    return rows[-1][-1] / len(expected)


called = ["lookup_order", "check_refund_policy", "issue_refund"]
expected = ["lookup_order", "verify_identity", "issue_refund"]

print(round(tool_correctness(called, expected, "exact"), 3))     # 0.0
print(round(tool_correctness(called, expected, "in_order"), 3))  # 0.667

Этот in_order score представляет собой показатель воспроизводимости длиннейшей общей подпоследовательности: это доля необходимых элементов последовательности, которые были сохранены в правильном порядке. Стоит обратить внимание на то, что этот показатель игнорирует некоторые факторы. Неактуальные вызовы не влияют на его значение, поэтому агент может получить оценку 1.0, совершив в два раза больше вызовов, чем требуется. Если дополнительные вызовы стоят денег или приводят к изменению состояния системы, необходимо одновременно отслеживать показатель точности (число совпавших необходимых вызовов в сумме всех совершённых вызовов) и анализировать их вместе. Воспроизводимость помогает выявить пропущенные шаги, тогда как точность позволяет обнаружить случаи ошибочного поведения агента.

метрика корректности инструмента DeepEval предоставляет доступ к тем же настройкам через should_consider_ordering и should_exact_match.

Правильность аргументов

Использование правильного инструмента с неверными аргументами зачастую приводит к худшим результатам, чем использование неправильного инструмента, поскольку трейс выглядит вполне нормально.

В простых случаях осуществляется проверка JSON schema и его точных значений. В семантических случаях сохраняются ожидаемые аргументы, после чего оцениваются различия между фактическими и ожидаемыми значениями:

{
    "trace_id": "tr_2417",
    "input": "Reschedule order A-100 for next Friday.",
    "expected_tools": ["lookup_order", "reschedule_delivery"],
    "expected_arguments": {
        "reschedule_delivery": {
            "order_id": "A-100",
            "date": "2026-06-19"
        }
    }
}

метрика имени инструмента не может зафиксировать 2026-06-17 где требуетась данная политика 2026-06-19. датасет также должен хранить аргументы.

Значение, соответствующее датасет, — это parameter-match: доля ожидаемых (tool, key, value) увеличивает количество верно решённых задач агентом в три раза.

def argument_correctness(called_args: dict, expected_args: dict) -> float:
    total = matched = 0
    for tool, params in expected_args.items():
        for key, want in params.items():
            total += 1
            if called_args.get(tool, {}).get(key) == want:
                matched += 1
    return matched / total if total else 1.0

Точное сравнение равенства подходит для ID, перечислений и дат. Однако оно неэффективно при работе с обычным текстом и числами с плавающей точкой, где == флагирует правильный ответ как неверный. Оценивайте эти поля по своим критериям: совпадение нормализованного строкового значения, парсинг даты и числовая толерантность. Метрика остаётся прежней; меняется только функция сравнения для каждого поля.

Эффективность, циклы и тупики

Агент, который выполняет задачу даже после пяти избыточных tool calls, всё равно указывает на наличие проблемы планирование, при этом его запуск становится более затратным.

Дешевые сигналы, с которых стоит начать:

• Частота избыточных вызовов: ситуация, когда один и тот же tool calls с идентичными аргументами повторяется более двух раз.
• Аномалии структуры Трейс: резкие скачки глубины, количества вызовов инструментов, количества токен, латентность или затрат.
• Сходимость пути: степень близости текущего варианта выполнения к наименьшему известному корректному пути для данной задачи.
• Корректность завершения: определение того, прекратил ли агент работу раньше времени, продолжил её после достижения успеха или объявил о успехе без необходимого изменения состояния.
• Соблюдение плана: если агент формирует план перед действием, необходимо проверить, соблюдался ли им трейс. И хороший план, игнорируемый агентом, и плохой план, строго соблюдаемый им, приводят к провалу по противоположным причинам; разница между планом и трейс помогает определить причину провала.

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

Завершение задачи и оценка результата

С точки зрения концепции «от начала до конца», ключевой вопрос заключается в том: «Получил ли пользователь именно то, о чём просил?»

Два подхода работают наилучшим образом:

• Оценка выполнения задач без использования эталонных данных: извлекается цель из входных данных и джадж определяется, достигла ли комбинация трейс вместе с окончательным ответом этой цели. Такой подход работает онлайн, поскольку в реальных трафиках редко бывают готовые эталонные решения.
• Оценка состояния среды: сравниваются финальные строки базы данных, файлы, заявки, бронирования или записи с аннотированным эталонным состоянием цели. Этот метод надёжнее сопоставления с транскрипцией, поскольку агенты могут находить корректные пути выполнения, которые вы не описали.

Второй вариант предпочтительнее, если его возможно реализовать. Конечным результатом является контракт; протокол выполнения служит лишь доказательством.

Существуют два важных ограничения, делающих такой подход объективным, оба связаны с бенчмарк — методологией, популяризировавшей оценку состояний. Инструмент tau-bench может присвоить положительный балл агенту, который не выполняет никаких действий на определённых задачах типа no-op, поскольку исходное состояние уже соответствовало цели. Кроме того, компания Anthropic сообщила о случае работы модели Opus 4.5, когда она «не справилась» с заданием из tau2-bench, найдя лазейку в правилах, которая на самом деле привела к более выгодному результату для пользователя. Хотя оценка состояний превосходит метод сравнения транскрипций, само целевое состояние по-прежнему является аннотацией, а аннотации подвержены ошибкам. Поэтому необходимо тщательно проверять те случаи, которые проходят оценку слишком легко, а не только те, что проваливаются.

Ротор трейс–эвал

Отказы в производстве руды до того, как начнётся анализ дополнительных случаев эвал.

Цикл:

1. Зафиксировать полную версию трейс.
2. Определить, что именно дало сбой.
3. Сгруппировать похожие случаи сбоев.
4. В каждой группе сохранить один типичный образец в качестве эталона.
5. Сохранять версии датасет.
6. Запустить их в среде CI.
7. Продолжать отслеживать показатели качества для выбранных примеров трейсы в реальном времени.

сопутствующий репозиторий trace2evals реализует полный цикл обработки для несправного агента поддержки. Он собирает данные OpenTelemetry генеративных ИИ спаны, выявляет сбои с помощью детерминистических правил, удаляет дубликаты случаев в версионированный эталонный датасет, а затем повторно запускает каждый такой эталонный пример в среде CI. По умолчанию скрипт не требует наличия ключа API, поэтому make demo передаёт процесс в режиме офлайн.

Сбои в добыче с анализом ошибок

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

1. Открытая кодировка: изучаются от 30 до 50 реальных примеров трейсы, после чего составляются свободные заметки о причинах возникших ошибок.
2. Осевая кодировка: эти заметки группируются в 5–6 определённых категорий сбоев.
3. Присвоение меток всем элементам в соответствии с разработанной таксономией.
4. Расчёт метрик для крупнейших групп.

Не начинайте с таких меток, как reasoning_issue или tool_problem. Они слишком расплывчаты для тестирования. Используйте метки вроде missing_identity_verification, date_argument_mismatch, retried_same_tool_after_429, или stopped_before_database_update. Метка, которая чётко указывает, какие условия должен проверять тест регрессии.

Удалите дубликаты перед публикацией

Цикл добычи трейс содержит подвох: он постоянно добавляет все некорректные трейс. Это приводит к формированию датасет, который является объёмным, ресурсоёмким и узкоспециализированным. В результате в него попадают почти идентичные примеры из марта, тогда как новая форма того же бага, возникшая в июне, остаётся незамеченной.

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

Если кластер сбоев воспроизводится после применения исправления, это означает, что регрессия не произошла. В таком случае следует снова сформировать кластер и расширить набор «золотых» примеров, вместо того чтобы добавлять ещё 15 примеров.

Версионирование датасет

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

Шлюз CI должен фиксировать:

• версия датасет
• версия приложения
• версия промпт
• джадж модель
• джадж промпт
• версия кода эвалуатор

Если будет применён хотя бы один из таких шагов, сравнение «до/после» станет нечётким. A goldens-v3.json При небольших объёмах данных файлы в Git работают без проблем. Встроенные инструменты снапшоты в Langfuse, Phoenix, Braintrust или LangSmith оказываются полезными, когда процесс датасет переходит в режим совместной работы.

Gate CI

Если показатель демонстрирует сбой, это должно приводить к сбою самой сборки; в противном случае набор инструментов эвал остаётся лишь панелью управления, которую никто не читает.

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

@pytest.mark.parametrize("golden", GOLDENS, ids=[item["id"] for item in GOLDENS])
def test_agent_regression(golden: dict) -> None:
    answer, fresh_trace = run_agent_and_capture_trace(golden["input"])

    refired = set(flag_failures(fresh_trace)) & set(golden["failure_modes"])
    assert not refired, f"failure mode regressed: {sorted(refired)}"

    assert tool_correctness(
        called=[call["name"] for call in fresh_trace["tool_calls"]],
        expected=golden["expected_tools"],
        mode=golden.get("tool_match", "in_order"),
    ) >= golden.get("tool_threshold", 1.0)

Это различие легко неправильно интерпретировать. Задача датасет — обнаруживать ситуации, когда следующая версия агента повторяет прежнюю ошибку, а не хранить саму ошибку в архиве.

Калибруйте джадж перед тем, как начинать полагаться на него

Использование LLM вместо джадж действительно помогает. Однако с этим тоже легко обмануть самого себя.

G-Эвал Запрашивается у джадж составление чётко прописанных шагов рубрикатора перед проведением оценки. После этого суммируются значения каждого уровня оценки с учётом веса, определяемого соответствующей токен вероятностью ($\text{score} = \sum_i p(s_i)\,s_i$). Данная схема позволяла более точно отслеживать результаты оценок, проводимых людьми, по сравнению с более старыми автоматическими метриками, которые она заменила.

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

MT-Bench Исследования показали, что GPT-4 соглашается с предпочтениями людей примерно в той же степени, в которой сами люди соглашаются друг с другом, что способствовало использованию LLM для оценки того, является ли тот или иной подход общепринятым. Позднее исследования выявили существование смещений, связанных с позицией, длиной текста и субъективными предпочтениями модели. Кроме того, значения Джадж могут меняться при обновлении версий промпт или модель.

JudgeBench Создаются пары ответов, в которых один из вариантов решения является объективно неверным с точки зрения проверяемых фактов, ризонинг, математических формул и кода. На таком наборе тестов GPT-4o показал результат 50,9%, тогда как лучшие модели типа джадж достигли примерно 64%. Вопросы с уверенными, но ошибочными ответами по‑прежнему представляют сложность для систем типа джаджи, основанных на алгоритмах модель.

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

Когда требуется джадж, необходимо сформировать структурированный вывод. Руководство схемой Ризонинг (SGR) определяет путь ризонинг для джадж в виде схемы Pydantic. Затем Structured Outputs или constrained decoding требуют наличия таких полей, как evidence, passed_criteria, failed_criteria, failure_mode, и score.

Необходимо размещать поля с доказательствами перед значением оценки. Затем джадж применяет те же заранее определённые этапы оценочной шкалы в том же порядке полей при каждой обработке и для всех совместимых модель. Рецензент может изучать специально обозначенные поля вместо того, чтобы анализировать целый абзац. Системы интеграции тестирования могут сравнивать стабильные объекты типа JSON, а набор калибровка указывает, на каком этапе оценочной шкалы возникло несоответствие с ручным меткой.

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

Стандартный чек-лист гигиены джадж:

1. По возможности предпочтительнее использовать бинарную оценку «пройдено/не пройдено» — пятибалльные шкалы способствуют созданию иллюзии точности.
2. Заранее отметьте ручным способом от 30 до 50 траекторий перед тем, как составлять окончательный критериальный список.
3. Оценивайте степень согласованности между джадж и человеком с помощью коэффициента Каппа Коэна (который учитывает вероятность случайного совпадения, поэтому джадж, всегда указывающий на «пройдено», будет иметь значение близкое к нулю), либо просто с помощью показателей TPR/TNR.
4. Разбейте общие критерии на более детализированные. Вопрос «Проверил ли агент личность до осуществления возврата tool call?» является более эффективным, чем простое «Была ли траектория качественной?».
5. Формируйте итоговое решение с использованием схемы SGR, в которой указываются доказательства, несоответствующие критерии, модус сбоя и полученная оценка.
6. По возможности используйте джадж из другой семьи модель, чем та, что применяется генератором.
7. Случайным образом меняйте порядок сравнений в парах и берите среднее значение для обоих направлений.
8. Штрафуйте слишком длинные ответы в рамках критериального списка — большая длина не означает автоматически лучшего качества.
9. Зафиксируйте значения джадж, модель, промпт, датасет, а также версии схемы и приложения.
10. Перенастраивайте параметры после изменений в модель, промпт, инструментах, политиках или схемах.

Для критически важных оценок рекомендуется использовать небольшую группу экспертов вместо одного крупного джадж. PoLL Была протестирована группа из нескольких джаджи, взятых из независимых друг от друга семейств модель, при этом объединялись их результаты оценки. За период в шесть датасеты эта группа показала более высокую точность в воспроизведении человеческих суждений по сравнению с одним экземпляром GPT-4 джадж. Кроме того, она избегала смещения, связанного с самопредпочтением у единственного джадж, и требовала к запуску в семь раз меньше ресурсов. Для принятия решений, касающихся финансов, доступа, безопасности или соблюдения нормативов, следует сохранять участие людей.

Если джадж показывает коэффициент согласия с людьми в 0,55 по шкале Каппы для вашей задачи, не используйте его для блокировки процессов развертывания. Лучше применяйте его для сортировки очередей на рассмотрение. Если же этот показатель близок к 0,75 и стоимость возникновения ошибок умерена, тогда обосновать использование контрольного звена CI гораздо проще.

Блок Гардрейлы встроенный, онлайнный — эвалы анализируется позже

Многие путают их, поскольку оба метода генерируют числовые оценки. Разница заключается в месте их размещения: внутри пути запроса, до отправки ответа или после неё.

Гардрейлы выполняются встроенно. Они обладают высокой скоростью работы, детерминированным поведением и видимы для пользователя. гардрейл может блокировать tool call, маскировать персональные данные, отклонять промпт-инъекция или принудительно запускать повторную попытку перед тем, как ответ покинет вашу систему. Ложноположительный результат является багом в продакшене.

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

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

Если неправильно определить местоположение, это приведёт к проблемам в любом случае:

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

Для систем с высокой производительностью оценивайте небольшую выборку с использованием более мощных джадж, а более крупную выборку — с помощью менее ресурсоемких классификаторов. Устанавливайте оповещения на основе обнаружения кластеров и диапазонов уверенности, а не на основе отдельных шумных оценок.

Выбор инструментов

Ни один инструмент не контролирует весь цикл разработки. Самые мощные технологические стеки используют два компонента: хранилище трейс и запускач CI/эвал.

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

Сокращения для принятия решений:

• Необходимо самостоятельно развернуть трейсинг с поддержкой портабельности OTel: начните с Phoenix или Langfuse.
• Требуется система CI, ориентированная на код: начните с DeepEval.
• Уже выбрано использование LangGraph: LangSmith удобен в таких случаях.
• Нужен сервис для автоматизированного анализа регрессий в PR: Braintrust превосходит все аналоги.
• Приоритет — безопасность и тестирование в режиме красной команды: Promptfoo — лучший инструмент для этой задачи.
• Для исследований в области безопасности или контролируемой работы с бенчмарк: Inspect AI более подходящий выбор.

Выбор инструментов имеет второстепенное значение. Если сбои в продакшене не превращаются в тест-кейсы, вы фактически платите в основном за хранилище трейс.

Практический чек-лист для поэтапного внедрения

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

1. Сначала соберите исторические записи выполнений. Если агент уже существует, соберите трейсы, заявки на поддержку, отчёты об ошибках, отзывы в виде «thumbs-down» сессии, транскрипции ручных тестов качества и записи результатов внутреннего тестирования, прежде чем вносить изменения в реализацию. Если агента пока нет, с момента первого дня ведите журнал каждого прототипа и ручного тестового запуска.

2. Внедрите инструменты для отслеживания состояния трейс. Записывайте сообщения, tool calls, аргументы, результаты работы инструментов, ошибки, показатели количества токен, латентность, затраты, обратную связь пользователей, версию приложения, версию промпт, версию модель, версию схемы инструмента, а также итоговое состояние среды. Используйте OpenTelemetry Стандарты генеративных ИИ или средство в стиле OpenInference спаны, если требуется портабельность. Используйте Langfuse, LangSmith, Phoenix или Braintrust, если необходим интерфейс трейс и готовый рабочий процесс датасет сразу же.

3. Преобразуйте реальные сбои в примеры тестовых случаев. Перед тем как подвести краткое резюме с использованием модель, ознакомьтесь с информацией о трейсы. Для каждого полезного сбоя необходимо сохранять данные входных параметров, идентификатор исходного трейс, ожидаемое состояние, требуемые инварианты инструмента, способ возникновения сбоя, степень серьёзности и примечания проверяющего. Langfuse позволяет связывать элементы датасет с реальной производственной средой трейсы, а LangSmith может генерировать датасеты на основе отслеженных запусков. Обязательно сохраняйте ссылку на исходный код, чтобы случай оставался подлежащим аудиту.

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

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

6. Создайте небольшую сбалансированную датасет. В неё должны входить примеры успешного выполнения, сбоев, отклонений запросов, граничных случаев, ситуаций с длинными циклами обработки, случаев, чувствительных к правилам, а также корректные альтернативные пути решения. Не стоит создавать идеальный вариант в виде «точной копии оригинального транскрипта»; такой идеальный вариант должен содержать необходимый результат, допустимые инварианты и способы возникновения сбоев.

7. Сначала добавьте детерминистические проверки. Порядок выполнения необходимых инструментов должен соответствовать установленной политике: сначала происходит валидация схемы и передача обязательных аргументов, затем сравнение конечного состояния, ограничение количества итераций, соблюдение верхних пределов токен и латентность, а также проверка инвариантов, специфичных для конкретной задачи; все эти операции должны выполняться до начала любых джадж.

8. Добавьте один SGR-образный джадж. Используйте его исключительно для той части данных, которая требует интерпретации. Произведите калибровку с использованием ручных меток. Если модель не может отличить хорошие и плохие примеры в наборе калибровка, скорректируйте критерии оценки перед тем, как подключать её к системе CI.

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

Ваш первый набор эвал будет содержать скрытые ошибки, которые трудно заметить. Тем не менее выпускайте его в продакшн. Набор инструментов, который используется ежедневно, гораздо проще отладить, чем идеальный документ с описанием архитектуры, который никогда не помешает принять неудачный pull‑request.

Список литературы

• репозиторий демонстрационных примеров для trace2evals
• LangChain — современные подходы к разработке агентов
• Anthropic — разбор Эвалы для ИИ-агенты
• Хамель Хусейн — Практическое руководство по быстрому улучшению продуктов AI
• OpenTelemetry семантические конвенции для генеративных систем AI системы
• Корректность инструмента DeepEval
• Завершение задачи DeepEval
• Руководство схемой Ризонинг в vLLM: Structured Outputs с использованием xgrammar и Pydantic
• Langfuse датасеты и система версионирования
• LangSmith — программно создавать и управлять датасеты
• Команда экспертов — систематическая оценка
• Phoenix LLM эвалы
• Интеграция с GitHub Action для Promptfoo
• tau-bench: Бенчмарк для тестирования взаимодействия инструментов, агентов и пользователей в реальных прикладных средах
• Почему сбоют системы Multi-Agent LLM?
• G-Эвал: Оценка NLG с использованием GPT-4 с улучшенной согласованностью с поведением человека
• Оценка LLM в качестве Джадж с использованием MT-Bench и Chatbot Arena
• Замена Джаджи на Juries: оценка поколений LLM с использованием группы из разнообразных Модели
• JudgeBench: инструмент Бенчмарк для оценки Джаджи, основанных на LLM
• Смещение из-за самопредпочтения в LLM как форме Джадж