Оценка LLM-приложений в LangSmith: трассировка, датасеты и регрессионные тесты

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

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

Что именно фиксирует LangSmith

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

Для каждого шага могут сохраняться:

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

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

Представим RAG-сервис, отвечающий по внутренней документации. Пользователь получает устаревшую инструкцию. В трейсе можно отдельно проверить:

как был преобразован исходный вопрос;

какие документы нашёл ретривер;
3. какой текст попал в контекст модели;
4. какую инструкцию получила модель;
5. на каком основании был сформирован ответ.

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

Чем трассировка отличается от оценки

Наблюдаемость и оценка решают связанные, но разные задачи. Трейс объясняет, как был обработан отдельный запрос. Эксперимент показывает, как определённая версия системы работает на наборе примеров.

Задача	Подход в LangSmith	Что получает команда	Когда применять
Найти причину единичной ошибки	Просмотр трейса и вложенных операций	Проблемный шаг, входы, выходы и задержки	При разборе инцидента или жалобы
Проверить новую версию	Эксперимент на датасете	Метрики и результаты по каждому примеру	Перед релизом
Сравнить модели или инструкции	Несколько экспериментов на одном датасете	Разницу в качестве, стоимости и задержке	При выборе конфигурации
Собрать реальные сложные случаи	Добавление продакшен-примеров в датасет	Набор сценариев для повторной проверки	После анализа ошибок
Организовать ручную проверку	Аннотация результатов и обратная связь	Оценки экспертов по единым критериям	Для субъективных или рискованных ответов

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

Как подготовить рабочий датасет

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

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

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

Набор из 20 тщательно отобранных примеров часто полезнее 200 однотипных вопросов. Он не даст полной статистической картины, зато быстро выявит грубые регрессии.

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

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

Какие оценщики использовать

LangSmith поддерживает несколько способов проверки результатов. Выбор зависит от того, можно ли формально описать правильный ответ.

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

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

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

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

Надёжная схема обычно сочетает несколько сигналов:

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

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

Как сравнивать версии приложения

Эксперимент в LangSmith запускает выбранную версию приложения на примерах датасета и сохраняет результаты вместе с оценками. Чтобы сравнение было полезным, между запусками следует менять один основной фактор.

Например:

• модель A против модели B;
• старая инструкция против новой;
• два алгоритма поиска документов;
• разный размер извлекаемого контекста;
• прежняя и новая версия инструмента.

Если одновременно заменить модель, ретривер и системную инструкцию, определить причину изменения метрик будет трудно.

Допустим, ассистент поддержки использует более дорогую модель и правильно обрабатывает 43 из 50 контрольных примеров. Команда рассматривает переход на более экономичную модель. После запуска на том же наборе корректными оказываются 39 примеров. Одного общего результата недостаточно: нужно открыть различающиеся случаи и проверить категории ошибок.

Возможны несколько выводов:

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

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

Практический процесс перед релизом

Для небольшого LLM-продукта рабочий цикл можно построить из семи шагов.

Подключить трассировку в тестовой среде.

Проверить, что секреты и персональные данные не попадают в сохранённые входы и выходы.
3. Собрать датасет из основных сценариев и известных ошибок.
4. Добавить детерминированные проверки формата и обязательных полей.
5. Настроить модельную оценку только для критериев, которые нельзя проверить кодом.
6. Запустить текущую версию и зафиксировать базовый результат.
7. После изменения приложения повторить эксперимент и разобрать все регрессии.

Для командного решения удобно использовать короткий релизный чек-лист:

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

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

Подключение трассировки

Для Python-проекта сначала устанавливают пакет LangSmith:

bash
pip install langsmith

В приложениях на LangChain трассировку можно включить через переменные окружения:

bash
export LANGSMITH_TRACING=true
export LANGSMITH_API_KEY=»«
export LANGSMITH_PROJECT=»support-assistant-dev»

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

LangSmith не ограничен приложениями на LangChain. Для собственного стека можно использовать SDK и вручную размечать функции или отдельные операции. Это полезно, если приложение напрямую обращается к API модели, использует несколько провайдеров либо сочетает LLM с внутренними сервисами.

После подключения стоит выполнить один контролируемый запрос и проверить:

• появился ли трейс в нужном проекте;
• правильно ли отображается вложенность операций;
• видны ли ошибки инструментов;
• сохраняются ли нужные метаданные;
• отсутствуют ли пароли, токены доступа и персональные данные.

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

Конфиденциальность и стоимость

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

Минимальные меры предосторожности:

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

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

Ограничения модельной оценки

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

Риск снижают следующие меры:

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

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

Когда LangSmith оправдан

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

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

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

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

Источники

• Анонс LangSmith командой LangChain: https://blog.langchain.dev/announcing-langsmith/
• Документация LangSmith: https://docs.smith.langchain.com/
• Руководство по оценке приложений: https://docs.smith.langchain.com/evaluation
• Руководство по трассировке: https://docs.smith.langchain.com/tracing
• Официальный SDK LangSmith: https://github.com/langchain-ai/langsmith-sdk