Глава 9 — Триада оценки RAG

Девятый пост поглавного разбора LLM Primer III: Enhancing Enterprise AI with RAG. О том, как три разных отказа сворачиваются в один симптом — и как поле изобретает трёхголовую метрику, наконец говорящую команде, какой симптом какой.

Почему существует эта глава

RAG-система способна отказать в трёх разных местах, и снаружи отказы выглядят одинаково. Ретривер достал не тот контекст. Модель проигнорировала правильный контекст. Модель уважила контекст, но ответила на другой вопрос, чем тот, что был задан. Любая продакшен-команда хотя бы однажды пыталась чинить один из этих отказов, измеряя другой. Глава — о маленьком упорном словаре, не допускающем этой ошибки.

Это также глава про сдвиг. Классический информационный поиск оценивался против размеченной правды — запросы с известно правильными документами, precision и recall, считаемые против разметки. RAG работает в мире, где такой разметки не существует. Вопросы открытые, ответы порождающие, релевантный контекст — это то, что модели понадобится в этот момент. Триаду спроектировали под этот мир. Она измеряет согласованность между стадиями, а не согласие с эталоном.

Если коротко: здоровье — это три числа, а не одно: Context Relevance для поиска, Groundedness для генерации, Answer Relevance для соответствия вопроса и ответа, — все три считаются reference-free LLM-судьёй, которого команда обязана держать честным.

9.1 Почему три сигнала, а не один

Инстинкт новой команды — оценивать финальный ответ. Пользователь набрал вопрос, система выдала ответ; либо он верный, либо нет. Инстинкт отказывает, потому что финальный ответ — это композит всех стадий, и когда он отказывает, композит ничего не говорит, какую стадию чинить. Правильный документ был пропущен? Был найден, но проигнорирован? Был использован, но ответ был на другой вопрос? Три разных бага, три разных починки, один неотличимый симптом.

Триада разделяет пайплайн на три места, где информация либо выживает, либо теряется. Поиск, заземление, ответ. У каждого своя метрика: Context Relevance, Groundedness, Answer Relevance. Структура полезна не тем, что три исчерпывают всё — они не исчерпывают, — а тем, что они независимы. Система может быть высокой по одной и низкой по другой, и когда так, команда знает, куда смотреть. При выпуске новой модели эмбеддингов должна сдвинуться Context Relevance. При выпуске нового промпта — Groundedness. Когда сдвигается та метрика, что должна сдвинуться, команда знает, что изменение сработало. Один сквозной балл сворачивает всё это во что-то, что нельзя отладить.

9.2 Context Relevance — нашли ли вы правильный контекст?

Context Relevance спрашивает, о том ли вопросе найденные чанки, предложение за предложением, по оценке LLM-судьи. Она ловит precision поиска — долю окна контекста, потраченную на релевантный материал. Высокая оценка значит, что ретривер не тратит токены впустую. Низкая значит, что он приносит шум, и модель платит за этот шум и латентностью, и качеством, потому что длинные нерелевантные контексты неоднократно показывали деградацию генерации.

Чего Context Relevance не ловит — это recall: были ли действительно найдены все чанки, которые модели понадобились бы. Ретривер, вернувший один идеальный чанк и больше ничего, оценивается идеально, даже если для ответа нужно было два и второй пропустили. Recall — отдельная задача, измеряемая против курируемых золотых наборов, где ответ-несущие документы известны. Глава также называет два артефакта, которые стоит знать: агрессивный чанкинг раздувает Context Relevance, не обязательно улучшая ответ, а невзвешенное усреднение по фиксированному top-k способно сделать ретривер плохо выглядящим, когда нерелевантные чанки на позициях 4–10 едва влияют на модель.

9.3 Groundedness — уважила ли модель контекст?

Groundedness, иногда называемая Faithfulness, задаёт обратный вопрос: какую долю утверждений, произведённых моделью, способен подкрепить найденный контекст? Стандартное вычисление раскладывает ответ на атомарные утверждения и спрашивает судью, для каждого: поддерживает ли его контекст? Декомпозиция — то, что важно. Длинный ответ, оценённый целиком, склонен скатываться либо к полностью обоснованному, либо к полностью необоснованному, при этом судья разрешает в направлении общего тона. Атомарные утверждения вынуждают судью оценивать каждое независимо — что ловит частый отказ, когда в основном верный ответ содержит одно предложение, которое контекст никогда не подтверждал.

Глава честна об асимметрии Groundedness: она наказывает изобретение, но не пропуск. Модель, отказавшаяся отвечать, оценивается идеально. Модель, давшая верный, заземлённый ответ, но опустившая важную оговорку из контекста, тоже оценивается хорошо. Это и самая метрика, скорее выводящая на промптовую, а не модельную проблему. Когда Context Relevance высокая, а Groundedness низкая, ответ почти всегда в системном промпте, а не в модели: инструкции слишком мягкие, чтобы удержать модель внутри контекста. Уплотните промпт, прежде чем винить модель.

9.4 Answer Relevance и сдвиг к reference-free

Answer Relevance проще всего понять неверно. Она не меряет корректность и не меряет заземление. Она меряет, обращается ли ответ к заданному вопросу. Фактически верный ответ на чуть иной вопрос оценивается плохо. Вежливый отказ оценивается плохо. Стандартное вычисление — умная инверсия: дан ответ, сгенерировать вопросы, на которые он мог бы быть откликом, и сравнить эти сгенерированные с оригиналом. Если близки — ответ по цели. Если расходятся — модель ушла.

Answer Relevance — это и место, где сдвиг к reference-free кусает больнее всего. Ни одна из этих метрик не считается сравнением с размеченным правильным ответом — пространство допустимых ответов бесконечно и неперечислимо. Поэтому поле сошлось на LLM-as-a-Judge: frontier-модель оценивает каждую метрику по задокументированному промпту. Техника масштабируется. Дешёва. Грубо коррелирует с человеческим суждением. У неё также есть хорошо задокументированные режимы отказа: position bias в попарных сравнениях, length bias, bias семейства модели, дрейф калибровки при тихих апдейтах модели и более глубокая проблема, что судьи и генераторы делят обучающие корпуса и поэтому отказывают коррелированно. Защита не техническая, а операционная: зафиксируйте модель судьи и промпт, калибруйтесь против небольшого вручную размеченного набора, маршрутизируйте небольшую долю оценок к человеческому ревью и относитесь к любой смене судьи как к событию ре-базелайнинга, аннулирующему исторические сравнения.

Стоит запомнить: ценность триады не в абсолютных значениях, которые шумны. Ценность — в структуре отношений между значениями. Когда все три двигаются вместе, система здорова или больна как целое. Когда расходятся, команда узнаёт, куда смотреть. Эта диагностическая сила — то, чего ни один сквозной балл дать не может.

Что подготавливает глава 9

Триада даёт словарь того, что измерять. Она не говорит, как реально гонять измерения — промпты для судьи, логика декомпозиции, выбор эмбеддингов, частота сэмплирования, дашборды, алерты. Ничего из этого не собирается с нуля. За последние два года появилось небольшое число фреймворков, делающих триаду измеримой на практике, у каждого свои мнения о том, как должна ощущаться продакшен-оценка. Глава 10 проходит по ним рядом.

Дальше — Глава 10: Ведущие фреймворки оценки. RAGAS, TruLens, DeepEval и платформы наблюдаемости — для чего каждый, где заканчиваются библиотеки-метрики и начинаются продакшен-платформы и Evaluation Gap, которую ни один пока не закрыл.

Хочется всю картину? Книга проходит по точному вычислению каждой метрики, задокументированным режимам отказа LLM-as-Judge со ссылками, дисциплине калибровки, удерживающей судей честными, и методам атрибуции на уровне чанков, что находятся на фронтире. LLM Primer III на Amazon →