Проблемы с тестированием и наблюдаемостью

Одной из главных ошибок является отсутствие автоматических проверок при изменении промптов. Когда промпт не воспринимается как код и правится без полноценного ревью, это приводит к регрессиям: исправление одного сценария ломает соседние. Чтобы этого избежать, необходимо зафиксировать датасет из 30–50 реальных запросов и запускать их в CI на каждый PR. Это обеспечит базовый уровень контроля, хотя для статистической значимости потребуются сотни кейсов.

Другая проблема — недостаточная наблюдаемость (observability). Обычного логирования HTTP-запросов недостаточно для LLM-пайплайна. Если в логах нет данных о том, что вернул поиск, какая версия промпта использовалась и сколько токенов ушло в контекст, разбор инцидентов превращается в гадание. Решением является трассировка всей цепочки вызовов с использованием стандартов вроде OpenTelemetry, которые позволяют видеть выполнение агента как дерево спанов.

Ошибки автоматической оценки (LLM-as-a-Judge)

Использование LLM в качестве «судьи» часто дает ложное чувство контроля. Существует риск системного смещения: модели склонны давать более высокие оценки собственным выводам или проявлять позиционное и многословное смещение. Если метрики судьи стабильно высоки, а жалобы в поддержку растут, значит, инструмент работает некорректно.

Для борьбы с этим необходимо относиться к судье как к производственному компоненту. Процесс должен быть замкнутым: часть трасс размечается людьми, которые калибруют судью. Важно измерять согласие судьи с людьми по шкале Лэндиса и Коха (каппа Коэна). Если согласие не поддерживается регулярной калибровкой, автоматическая оценка превращается в «генератор красивых чисел».

Ловушка готовых метрик

Использование стандартных метрик из библиотек (faithfulness, relevancy, coherence) без привязки к реальности — еще одна распространенная ошибка. Готовые метрики измеряют представления авторов фреймворка, а не реальные проблемы пользователей. Прежде чем настраивать мониторинг, необходимо вручную проанализировать десятки реальных трасс, чтобы понять, какие именно ошибки совершает модель в конкретном доменном контексте.