Зачем нужна оценка RAG

Система RAG может казаться работоспособной, поскольку возвращает беглые и правдоподобные ответы. Но без измерений Вы не знаете, извлекает ли она действительно правильные фрагменты и создаёт ли достоверные ответы. Команды, пропускающие этап оценки, часто месяцами настраивают стратегии разделения текста и форматы запросов, полагаясь на интуицию, а затем обнаруживают, что только ухудшили результат. Строгая оценка превращает разработку RAG из угадывания в инженерную работу.

В RAG есть два отдельных этапа, каждый из которых может отказать независимо: извлечение и генерация. Извлечение завершается неудачно, когда релевантные фрагменты не входят в результаты K лучших: LLM не сможет создать хороший ответ, если нужная информация вообще не была извлечена. Генерация завершается неудачно, когда правильные фрагменты были извлечены, но LLM проигнорировала их, неправильно поняла или добавила выдуманные сведения. Для каждого этапа нужны отдельные метрики, чтобы определить, какой компонент вызывает проблему.

Измерение только качества итогового ответа скрывает источник сбоев. Предположим, Ваша система даёт неправильные ответы в 30 % случаев. Происходит ли это потому, что извлечение не находит нужные фрагменты, или потому, что LLM игнорирует хорошие фрагменты? Если Вам известна только итоговая доля ошибок, Вы не сможете понять, какой компонент нужно исправить. Оснастите измерениями оба этапа отдельно: оценивайте качество извлечения с помощью эталонных наборов данных, а качество генерации — с помощью показателей достоверности.

Для оценки нужен эталонный набор данных: набор пар «вопрос–ответ», для которых известен правильный ответ и, в идеале, документ и фрагмент, из которых он взят. Для минимального пригодного набора оценки соберите 50–100 вопросов, отражающих реальные запросы пользователей. Ответьте на них вручную или изучив исходные документы. Включите разнообразные типы вопросов: поиск фактов, сравнения, многошаговые рассуждения и вопросы не по теме, на которые система должна отказаться отвечать.

Создавать 100 вопросов вручную утомительно. Ускорьте этот процесс с помощью LLM для генерации данных: передайте каждый фрагмент документа GPT-4o и попросите его создать 3–5 разнообразных вопросов, ответы на которые можно найти в этом фрагменте, а также текст ожидаемого ответа. Вручную проверьте выборку, чтобы выявить проблемы с качеством. Такой подход позволяет быстро масштабироваться до тысяч вопросов, однако некоторые особые случаи, о которых спросили бы только реальные пользователи, могут остаться незамеченными.

Доля попаданий@K — это доля вопросов, для которых хотя бы один релевантный фрагмент присутствует среди первых K результатов поиска. Это самая простая и интуитивно понятная метрика поиска. Доля попаданий@5, равная 85%, означает, что для 85 из 100 вопросов релевантный фрагмент оказался среди 5 первых результатов. Отслеживайте долю попаданий отдельно для разных типов документов, длин запросов и тематических категорий, чтобы понять, где ваш механизм поиска испытывает наибольшие трудности.

Достоверность показывает, содержит ли сгенерированный ответ только информацию, которую можно подтвердить в найденном контексте. Недостоверный ответ добавляет факты, которые контекст не подтверждает, — это галлюцинация. Оценивайте достоверность, поручив проверяющей LLM (или человеку-оценщику) сопоставить каждое предложение ответа с контекстом и отметить утверждения, не подтверждённые найденными фрагментами. Для систем, используемых в рабочей среде, целевым показателем является достоверность не ниже 95%.

Релевантность ответа показывает, действительно ли сгенерированный ответ отвечает на вопрос пользователя. Даже очень достоверный ответ может не попасть в цель, если он отвечает на связанный, но другой вопрос. Измеряйте релевантность отдельно от достоверности. Используйте проверяющую LLM, чтобы оценить по шкале от 1 до 5, насколько ответ непосредственно соответствует заданному вопросу. Низкая релевантность ответа часто указывает на проблему в структуре запроса или на то, что в найденном контексте на самом деле нет ответа.

Оценка наиболее полезна, когда вы отслеживаете метрики во времени по мере внесения изменений. Храните результаты оценки в базе данных или электронной таблице с отметками времени и метками версий (например, chunk_size=500, embed=3-small, k=5). Когда вы пробуете новую стратегию разбиения на фрагменты или модель эмбеддингов, проводите ту же оценку и сравнивайте результаты. Это предотвращает регрессии: например, вы можете повысить достоверность, но случайно снизить долю попаданий. Всегда проводите полную оценку перед объединением изменений с рабочей версией.

Помимо конкретных метрик, оценка требует изменения образа мышления: рассматривайте RAG как систему машинного обучения с измеримыми показателями, а не как чат-бота, которого оценивают субъективно, общаясь с ним. Заранее определите критерии успеха (например, доля попаданий@5 > 85%, достоверность > 95%). Сформируйте тестовый набор, который остаётся неизменным и никогда не используется для принятия решений при разработке. Для итераций выделите отдельный набор разработки. Такая дисциплина отличает команды, выпускающие надёжные системы RAG, от команд, выпускающих впечатляющие демонстрации, которые не работают в рабочей среде.

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

Проверьте, насколько хорошо вы усвоили концепции инженерии ИИ из этого урока.

В этом уроке вы узнали: о двух независимых режимах отказа — поиска и генерации, для которых нужны отдельные метрики; о создании эталонного набора данных из троек «вопрос–ответ–фрагмент» для объективной оценки; о доле попаданий как основной метрике поиска, а также о достоверности и релевантности ответа как основных метриках генерации; и о важности отслеживания метрик во времени для предотвращения регрессий. Далее мы реализуем конкретные метрики поиска, включая MRR и NDCG.