RAG для бизнеса: как оценить качество поиска и ответа

Коротко

Оцени RAG по слоям: retrieval, grounded generation и полезность для пользователя. Сначала собери небольшой эталонный набор вопросов с ожидаемыми документами и ответами. Затем отдельно измерь, попал ли нужный фрагмент в top-k, не добавила ли модель факты вне контекста и помог ли ответ выполнить задачу.

• Один вопрос может иметь несколько допустимых документов и формулировок ответа.
• Recall@k отвечает за найденный контекст, а не за правдивость финального ответа.
• Groundedness проверяет связь ответа с контекстом, но не заменяет проверку самого контекста.
• Оценивай abstain: ассистент должен уметь сказать “не нашёл”.
• Логи вопросов, retrieval и feedback нужны для постоянного улучшения.

RAG — это цепочка, а не одна модель

В типичном потоке пользовательский вопрос превращается в embedding или поисковый запрос, затем система выбирает несколько чанков, собирает prompt и просит LLM сформировать ответ. Ошибка на любом этапе меняет результат. Плохое разбиение документов может скрыть нужную фразу, слабый retriever не найдёт правильную страницу, а модель может проигнорировать контекст даже после хорошего поиска.

Собери evaluation set до улучшения промпта

Тестовый набор лучше составить из реальных вопросов пользователей, а не только из вопросов, которые удобно придумать разработчику. Для каждого примера сохрани вопрос, роль пользователя, ожидаемый intent, допустимые источники, обязательные факты и критерий полезного ответа. Добавь негативные вопросы: на них система должна корректно отказаться или объяснить, что данных недостаточно.

Не смешивай в один набор все сценарии. FAQ, поиск по регламентам и подготовка сводки требуют разных критериев. Пометь каждый пример типом: lookup, comparison, multi-hop, summarization, refusal. Тогда падение одного класса задач будет видно, а средняя оценка не замаскирует проблему.

case = {
    'id': 'refund_policy_01',
    'question': 'Когда клиенту возвращают деньги за отменённый заказ?',
    'intent': 'lookup',
    'expected_sources': ['returns-policy-v3'],
    'must_include': ['срок', 'условие отмены'],
    'should_abstain': False,
}

Retrieval: Recall@k и MRR

Recall@k показывает, попал ли хотя бы один релевантный документ в первые k результатов. Если нужный регламент найден на позиции 8, Recall@5 будет нулевым, хотя человек мог бы найти ответ при большем списке. MRR учитывает позицию первого релевантного результата и помогает отличить “нашли где-то” от “показали сразу”.

Для multi-hop вопроса одного документа может быть мало. Тогда помечай все необходимые источники и считай, сколько из них попало в контекст. Отдельно следи за долей нерелевантных чанков: слишком широкий top-k увеличивает стоимость и даёт модели больше возможностей выбрать не тот факт.

Ответ может быть красивым и неподтверждённым

Groundedness — это проверка, что утверждения ответа поддерживаются переданным контекстом. Она не отвечает на вопрос, правильный ли сам контекст. Если retriever вернул устаревший документ, модель может идеально пересказать его и всё равно дать бизнесу неверное решение. Поэтому нужна связка: качество источника, качество retrieval и опора ответа на контекст.

Разбей ответ на атомарные claims. Для каждого отметь: подтверждён, противоречит контексту, не проверяется или добавлен без основания. Для критичных процессов автоматическую оценку дополняй ручной разметкой. LLM-as-a-judge полезен как быстрый фильтр, но его оценки нужно сверять с людьми на калибровочной выборке.

Полезность — не только правильность

В рабочем процессе нужно измерять, помог ли ответ выполнить задачу. Пользователь может получить фактически корректное объяснение, но не понять, какой документ открыть, кому написать или какие поля заполнить. Для разных сценариев зафиксируй task success: найден ли нужный регламент, сократилось ли время ответа, не пришлось ли делать повторный поиск.

Онлайн-метрики собирай осторожно. CTR по ссылкам может вырасти из-за любопытства, а не из-за полезности. Доля повторных вопросов может означать как плохой ответ, так и сложность исходной задачи. Сочетай события интерфейса, явный feedback и выборочную ручную проверку диалогов.

Что мониторить после запуска

После запуска качество не застывает. Документы обновляются, меняются названия разделов, появляются новые типы вопросов и растёт база пользователей. Храни версию индекса, retriever, top-k, latency, стоимость и результат проверки. Иначе команда не сможет понять, почему вчерашний ответ стал хуже.

Нужен маршрут для обратной связи. Плохой ответ должен превращаться в evaluation case с исходным вопросом, контекстом и ожидаемым поведением. Через несколько недель это станет живым набором регрессий, который полезнее абстрактного “потестировали на десяти примерах”.

• Доля вопросов с корректным abstain.
• Recall@k по ключевым сценариям.
• Groundedness и citation correctness.
• Latency и стоимость одного ответа.
• Доля повторных вопросов и ручных эскалаций.
• Качество по ролям и чувствительным источникам.

Минимальный план внедрения

Для первого релиза не нужно строить огромную систему оценок. Выбери 30–50 реальных вопросов, разметь источники и обязательные факты, зафиксируй baseline и прогоняй набор после каждого изменения retriever, chunking или prompt. Публикуй не только среднюю оценку, но и пять самых дорогих ошибок с владельцем исправления.