7 ошибок при оценке качества LLM в продакшене: разбор ОТУС с кодом и паттернами

Автор разбора Сергей Прощаев, Tech Lead и руководитель направления Java/Kotlin-разработки в секторе FinTech и e-commerce, а также преподаватель курсов разработки и архитектуры в ОТУС, описал семь конкретных ошибок, с которыми сталкиваются инженерные команды. Материал вышел не как абстрактная методичка, а как набор паттернов из реального продакшена финтех-сервиса.

Что именно разобрано?

Прощаев начинает с типичной ситуации: функция на основе языковой модели работает в продакшене три месяца, метрики на дашборде в норме, ошибок сервера нет, средняя оценка ответа от модели-«судьи» составляет 4,3 из 5. Но служба поддержки каждую неделю приносит скриншоты, где ассистент отвечает уверенно и неправильно.

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

Автоматические проверки качества ответов Прощаев называет «эвалами» (evals, от evaluation, то есть автоматическая оценка качества ответов модели). Именно так этот термин используется в индустрии.

Первые две ошибки: «на глаз» и пустые логи

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

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

Принципиальный момент в подходе Прощаева: сначала детерминированные проверки (assert, то есть жёсткое правило «результат должен быть таким»), потом модель-судья. По его оценке, около 70% проверок можно закрыть обычными правилами, и только остаток отдавать модели. Это дешевле, стабильнее и объяснимее.

Ошибка вторая: в логах только вход и выход. Когда приходит жалоба на конкретный диалог, инженер находит пару «запрос и ответ» и упирается в стену. Что вернул поиск? Какая версия промпта была в тот момент? Сколько токенов (единиц текста, которыми оперирует модель) ушло в контекст? Неизвестно. Разбор одного случая занимает часы, а вывод в постмортеме звучит: «модель иногда галлюцинирует» (галлюцинация, это когда модель уверенно выдумывает то, чего не было).

Решение: трассировать всю цепочку, а не только финальный вызов. Прощаев ссылается на OpenTelemetry (открытый стандарт мониторинга приложений), который получил статус graduated в CNCF (фонде облачных вычислений) 21 мая 2026 года. Конвенции GenAI описывают выполнение ИИ-агента как дерево спанов (записей о каждом шаге операции): вызов агента, внутри него вызов модели и вызов каждого инструмента.

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

Статус OK ничего не гарантирует, а что считать валидным ответом инструмента, знает только ваш домен: где-то это непустой список, где-то конкретное поле, где-то допустим и 204. : Сергей Прощаев, Tech Lead, ОТУС

Почему оценка качества LLM становится инвестиционной темой?

Разбор Прощаева, технический, но за ним стоит рыночный сигнал. Команды массово выводят LLM-функции в продакшен, а инструменты контроля качества отстают. Это создаёт нишу: кто даст готовый стек для оценки качества LLM (трейсинг, эвалы, структурированные логи), тот заберёт бюджеты, которые сейчас уходят на ручной разбор инцидентов.

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

Примеры в разборе написаны на Python, хотя основной сервис у команды на Kotlin. Прощаев объясняет это тем, что обвязка вокруг LLM почти везде живёт на Python: там же eval-раннеры и инструментация. Его цель: чтобы эвалы правились без него, теми, кто ближе к данным.

Что делать с этим прямо сейчас, по ролям?

• Автору на Дзене. Если вы используете языковую модель для генерации текстов, заведите файл с 20-30 типовыми запросами и проверяйте каждый раз, когда меняете промпт. Это ваш «дымовой тест»: он не гарантирует идеал, но ловит грубые поломки до публикации.

• Маркетологу. Оценка качества LLM перестаёт быть задачей «потом разберёмся». Если ваш чат-бот или ассистент отвечает клиентам, а у вас нет автоматических проверок, вы узнаете о проблемах от пользователей, а не из мониторинга. Паттерн «сначала детерминированные правила, потом модель-судья» применим и без глубоких технических знаний.

• Предпринимателю в РФ. Подход Прощаева не привязан к конкретному провайдеру. Те же паттерны работают с YandexGPT и GigaChat: фиксированный датасет, трейсинг цепочки, структурированные логи. OpenTelemetry, открытый стандарт, доступен без ограничений.

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