LangSmith — сервис команды LangChain, где каждый запуск агента записывается как трасса, а проверка версий идёт на наборах тестовых примеров. Он нужен, когда агент уже делает несколько шагов подряд, и после правки инструкции остаётся гадать, стало лучше или хуже. Для одного разового запроса к модели такая платформа избыточна. Наблюдение за боевым потоком в другом инструменте разобрано в статье про Langfuse, а здесь речь о связке трассы и теста.
Что видно в трассе
Трасса в LangSmith показывает запуск агента по шагам: что пришло на вход, какой инструмент вызвали, что вернула модель и где цепочка оборвалась. Это основа и для разбора ошибки, и для будущих тестов.
Возьмём агента, который готовит черновик ответа по заявке клиента: читает карточку, ищет похожие обращения в базе знаний, собирает текст и просит сотрудника подтвердить отправку. Без записи шагов отличить плохую инструкцию от плохого поиска невозможно: виден только итоговый текст. Трасса раскладывает запуск на вложенные операции, и разбор начинается с вопроса, на каком шаге появилось неверное допущение.
Читайте трассу сверху вниз, как журнал чужой смены. Сначала проверьте вход: какие поля реально попали в запрос, нет ли там лишнего. Затем найдите вызовы инструментов и сравните аргументы с тем, что сотрудник считал бы разумным. Последним смотрите ответ модели. Часто причина обнаруживается раньше текста: поиск вернул устаревшую страницу, а модель добросовестно пересказала её.
Для вашей команды из этого следует правило хранения. Трасса содержит реальные тексты обращений, поэтому доступ к ней нужен узкому кругу людей, а персональные данные до записи лучше сокращать или заменять. Если контур данных закрыт политикой компании, сначала решите, где физически живёт сервис, и лишь потом подключайте его к рабочему потоку. Общую логику проверки действий агента до запуска мы описали в материале про тестирование ИИ-агентов.
К каждой трассе добавляйте метки: версию инструкции, тип обращения, окружение. Без меток через две недели в журнале лежит гора однотипных записей, и ответить, с какой версии начались жалобы, нельзя. С метками тот же вопрос превращается в один фильтр. Привычка метить запуски дешевле любого последующего расследования и настраивается один раз при подключении трассировки к коду приложения.
Набор примеров
Тестовый набор в LangSmith называется датасетом. По документации платформы, это коллекция примеров, а каждый пример хранит входные данные, при необходимости эталонный результат и метаданные. Самый ценный источник примеров — ваши же трассы: заявку, на которой агент ошибся, превращают в тестовый случай, и повторная ошибка сразу попадёт в отчёт.
| Часть примера | Что в ней хранить | Кто отвечает за содержание |
|---|---|---|
| Вход | Обезличенная заявка и список доступных инструментов | Владелец процесса |
| Эталон | Описание допустимого ответа или обязательные факты | Сотрудник, который решает такие заявки |
| Метаданные | Тип обращения, источник случая, дата добавления | Тот, кто ведёт набор |
| Пометка риска | Признак, что ошибка здесь дорогая | Руководитель направления |
Эталон в таком наборе описывает границы приемлемого, а единственной верной фразы там нет. Для черновика поддержки это сохранение сути просьбы, отсутствие новых обязательств и ссылка на найденный источник. Размер набора растёт постепенно: начните с десятка случаев, где агент ошибался или сотрудники спорили, и добавляйте по мере появления новых сбоев. Набор из случайных удачных примеров бесполезен: ловить в нём нечего.
Пополняйте набор из рабочих трасс по одному правилу: каждая жалоба сотрудника или клиента даёт новый пример в течение дня, пока контекст свежий. Через месяц набор покрывает реальные трудные места, а придуманные за столом случаи занимают лишь малую долю. Отдельно держите несколько заведомо простых заявок: они ловят поломки, когда правка инструкции задела базовое поведение.
Оценщики и ревью
Оценщик — это правило, которое ставит результату оценку. Основные виды по документации LangSmith: человеческая проверка (для неё есть очереди аннотаций), детерминированные проверки кодом, LLM-судья и попарное сравнение двух версий. Для агента с действиями начните с кода: проверка, что вызван нужный инструмент, что в ответе есть номер заявки, что длина укладывается в рамки. Такие проверки дёшевы и объяснимы.
LLM-судья добавляется для смысловых критериев, например полноты ответа. Но он тоже модель и ошибается, поэтому его оценки периодически сверяют с разметкой людей. Оценки судьи без такой сверки превращаются в красивую цифру без основания. Подробнее о приёме — в глоссарии, термин LLM-as-judge.
Спорные случаи уходят человеку. Сотрудник открывает пару «вход — ответ», отмечает расхождение с эталоном и пишет причину. Эти пометки возвращаются в набор: так расхождение между судьёй и человеком превращается в новый пример вместо устного разговора в чате.
Критерии судьи формулируйте письменно и коротко: что считается полным ответом, что считается лишним обещанием. Расплывчатая формулировка даёт плавающие оценки, и сравнение версий теряет смысл. Хорошая проверка критерия — дать его двум сотрудникам и сравнить, как они оценят один и тот же ответ.
Какие ошибки агента у вас повторяются чаще всего?
Сравнение версий
Эксперимент в терминах LangSmith — это прогон конкретной версии приложения на датасете, в котором сохраняются выходы, оценки и трассы. Две версии, прогнанные на одном наборе, сравниваются рядом. Это и есть защита от регрессии: правка инструкции, смена модели или добавление инструмента получают проверку на тех же случаях, где раньше было плохо.
- Зафиксируйте версию, которую считаете эталонной, и прогоните набор. Сохраните результат как точку сравнения.
- Внесите одну правку: инструкцию, модель или описание инструмента. Две правки за раз скроют, что именно сработало.
- Повторите прогон на том же наборе и откройте сравнение. Отдельно просмотрите случаи, где оценка упала, даже если средняя выросла.
- Спорные примеры передайте владельцу процесса. Решение о принятии версии записывайте вместе с номером набора.
Прогон до выкладки называется офлайн-оценкой, а проверка живых трасс после выкладки — онлайн-оценкой. Первая отвечает на вопрос, можно ли выпускать, вторая показывает, что происходит с реальными запросами. Для боевой проверки нужны правила отбора: оценивать и хранить каждую трассу незачем.
Читая сравнение, смотрите на распределение оценок, а среднее число оставьте на второй план. Версия, которая улучшила десять лёгких случаев и испортила два дорогих, выглядит победителем по средней оценке и проигрывает по последствиям. Поэтому пометку риска из набора выводите в отчёт отдельной строкой.
Допуск в работу
Агент допускают к реальным заявкам, когда на наборе пройдены обязательные проверки и отдельно разобраны все случаи с пометкой риска. Охрана самих действий в учётных системах лежит за пределами платформы оценки: права на запись, лимиты и подтверждение человеком проверяет сервер вашего приложения. Если для связки используется LangGraph с сохранением состояния, остановку на подтверждении тоже закладывают в граф, а промпт для этого непригоден.
Определите владельца набора. Если набор остаётся ничьим, через месяц он перестаёт отражать реальные заявки, а прогон показывает уверенность на устаревших примерах. Назначьте человека, который раз в неделю добавляет новые сбои из трасс и убирает случаи, потерявшие актуальность. Заведите правило: правка агента попадает в работу только после прогона набора.
Полный контур — трасса, набор, оценщики, сравнение, подтверждение человеком — окупается там, где агент повторяет сотни однотипных операций. На единичных задачах хватит ручной проверки. Если хотите собрать такой контур вокруг своего процесса, посмотрите нашу страницу про ИИ-агентов для бизнеса.
Соберите десять заявок, на которых агент уже ошибался, обезличьте их и положите в первый набор. Опишите для каждой, каким должен быть допустимый ответ, и прогоните текущую версию. Получившийся результат станет точкой отсчёта для любых следующих правок.