Как оценивать качество LLM-приложения и снижать долю галлюцинаций?
Короткий ответ
- Галлюцинация — уверенный ответ, не подтверждённый источниками
- Нужен eval-набор: реальные запросы плюс эталонные ответы
- Автооценка LLM-судьёй по рубрике, с валидацией на людях
- Метрики: faithfulness, релевантность, полнота, формат
- Снижение: RAG с цитированием, разрешение ответа «не знаю»
- Структурные проверки выхода и фактчек критичных полей
- Регрессионные прогоны на каждое изменение промпта и модели
Качество LLM-приложения измеряется регулярными прогонами eval-набора с LLM-судьёй, откалиброванным по людям, а галлюцинации давятся заземлением на источники и правом отвечать «не знаю».
Как сказать вслух
пример ответаПервым делом я собираю оценочный набор из реальных запросов с эталонными ответами — без него любые правки промпта это гадание. Оцениваю автоматически: более сильная модель-судья проверяет ответы по рубрике — опирается ли ответ на источники, отвечает ли на вопрос, — и периодически сверяю судью с оценками людей. Галлюцинации снижаю заземлением: модель отвечает только по найденным документам с цитатами и имеет явное право сказать «не знаю». И каждое изменение промпта или модели гоняю через этот набор как через регрессионные тесты.
Подробный ответ
Основной ответ
Оценка LLM-приложения строится как инженерный процесс. База — eval-набор: сотни реальных или реалистичных запросов с эталонами или рубриками оценки, включая edge-кейсы и провокации на галлюцинации. Автооценка — LLM-as-a-judge: сильная модель оценивает ответы по явной рубрике (faithfulness — подтверждён ли ответ источниками, relevance, полнота, соблюдение формата и тона); судью обязательно калибруют по выборке человеческих оценок и следят за его смещениями (позиция, длина ответа). Детерминированные проверки дополняют: валидность JSON, наличие обязательных полей, запрещённые утверждения. Снижение галлюцинаций: заземление через RAG с обязательным цитированием источников, инструкция и примеры ответа «недостаточно информации», снижение temperature для фактологических задач, декомпозиция сложных запросов, самопроверка ответа вторым проходом, фактчек критичных полей (цены, даты) по базе. Всё это оформляется в регрессионный пайплайн: любое изменение промпта, модели или индекса прогоняется по eval-набору до релиза, плюс мониторинг качества и фидбека в проде.
Ключевые моменты
- Eval-набор прежде всего. Без фиксированного набора с эталонами улучшения промптов — анекдоты; набор пополняется из прод-логов и инцидентов.
- LLM-судья с калибровкой. Судья масштабирует оценку, но его согласие с людьми надо измерить, а смещения — знать и гасить рубрикой.
- Заземление и право на отказ. Ответ только по источникам с цитатами и легальное «не знаю» — два главных рычага против галлюцинаций.
- Оценка как CI. Прогон eval-набора на каждое изменение — аналог регрессионных тестов; без него релизы ломают качество незаметно.
Практический контекст
К 2026 году это один из главных вопросов для DS и ML-инженеров в продуктах с LLM: команды осознали, что без evals развитие встаёт. Интервьюер смотрит на системность: есть ли у кандидата процесс, а не только набор трюков промптинга. Сильный рассказ опирается на опыт: как собирали набор, как ловили расхождение судьи с людьми, какой процент галлюцинаций считали приемлемым для своего домена.
Частые ошибки
- Оценивают качество «на глаз» по нескольким примерам и правят промпт без регрессионных прогонов
- Слепо доверяют LLM-судье, не проверив его согласованность с человеческими оценками
- Борются с галлюцинациями только промптом, без заземления на источники и права ответить «не знаю»