Глава 12: Метрики тестирования LLM — retrieval и generation 📊📉

Если бы меня попросили описать тестирование LLM одним словом, я бы выбрал «парадокс» 🤔. Потому что каждая метрика, которой вы пользуетесь, врёт. И каждая — по-своему. BLEU не видит смысла. BERTScore не видит фактов. Hallucination rate зависит от того, как вы определяете галлюцинацию. И единственный способ хоть как-то приблизиться к истине — использовать всё это вместе, понимая ограничения каждого инструмента. Как с алгоритмами выборки из главы 5: ни один не идеален, но в комбинации — работают ⚖️.

Метрики тестирования retrieval 🔍. Если у вас RAG, качество ответа наполовину определяется поиском. Recall@k мы уже разобрали в главе 11 — он показывает, нашёл ли поиск нужный документ. Precision@k — сколько из найденного действительно релевантно. MRR — на какой позиции стоит первый правильный результат. nDCG — качество ранжирования с учётом позиции: правильный ответ на первом месте важнее, чем на десятом. Без этих метрик вы будете винить модель в том, что retrieval не нашёл документ. Или хвалить модель за ответ, который она выдумала, потому что поиск ничего не дал. Классическая ситуация: вы меняете chunking, ответы становятся лучше, вы радуетесь 🎉, а на самом деле retrieval просто стал возвращать больше контекста. Через неделю вы меняете эмбеддинги — векторы из главы 2, где «кошка» и «кот» живут рядом — и всё разваливается, потому что вы не измеряли поиск отдельно 🐱.

Метрики тестирования generation ✍️. Faithfulness — соответствует ли ответ фактам из контекста. Answer Relevancy — отвечает ли на вопрос. Groundedness — опирается ли на источник. И hallucination rate — доля ответов с вымышленными фактами. Главная метрика 2026 года: если она выше 10% — у вас проблема, если выше 50% — у вас не проблема, у вас творческий писатель 📝. BLEU и ROUGE пришли из классического NLP, где всё было детерминировано и просто. Ах, были времена 🕰️. Сейчас они плохо коррелируют с человеческой оценкой открытой генерации. BERTScore ловит семантику через эмбеддинги — векторы из главы 2, где «кошка» и «кот» живут рядом. Но семантическая близость не гарантирует фактическую верность. Ответ может быть близок к эталону и всё равно врать. Как модель из главы 1: честный лжец, который не знает, что фантазирует 🎭.

Как считать faithfulness на практике 🎯. Первый подход — разметка людьми: дорого, медленно, но надёжно. Второй — LLM-as-judge: быстро, дёшево, но судья может врать. Третий — гибрид: LLM-судья размечает, люди проверяют выборку. Начните с гибрида. Возьмите сто ответов, прогоните через судью, потом вручную проверьте двадцать случайных. Если совпадение выше 80% — судье можно доверять для быстрой фильтрации. Если ниже — калибруйте рубрику и перепроверяйте 🗳️.

Метрики тестирования safety 🛡️. Safety violations — сколько раз модель нарушила правила. Over-refusal rate — сколько безобидных запросов отвергнуто. Jailbreak success rate, PII leakage, prompt injection success rate. Эти метрики обычно не входят в стандартные фреймворки, и их приходится собирать вручную. Но именно они показывают, готов ли ваш продукт к реальным пользователям, а не к демо на конференции. А демо на конференции, как известно, проходит всегда 🎤.

Немного юмора 😄. BLEU — это коллега, который считает совпадающие слова и не понимает синонимов. BERTScore — коллега, который понимает синонимы, но не проверяет факты. Hallucination rate — коллега, который считает, сколько раз стажёр выдумал, но не уточняет, что считать «выдумкой». Faithfulness — коллега, который сверяет с источником, но сам иногда ошибается. Получается, вы нанимаете четверых ненадёжных коллег и надеетесь, что вместе они надёжнее. А иногда все четверо дружно ошибаются, и вы узнаёте от пользователя в понедельник утром. Но это уже статистика — и о ней следующая глава 📅.

Я часто думаю 🤔, что тестирование LLM — не про поиск идеальной метрики. Это про умение жить с неопределённостью и принимать решения, когда ни один инструмент не даёт полной картины. В этом есть философия — честная, если не утешительная 🧘.