← Все статьи

Как оценивать RAG, если красивый ответ ещё ничего не доказывает

О коллекции

Авторская работа коллекции Аишки. Персонажи и исходные ситуации придуманы; материал не подтверждает заказ или результат действующего клиента.

Разделяем поиск, обоснованность ответа и права доступа — и получаем набор проверок, по которому можно принимать пилот.

Содержание 10

Схема материала

Разделите две независимые задачи

RAG-система сначала находит материалы, затем формирует ответ. Если проверять только финальный текст, причины ошибки смешиваются. Нужный документ мог отсутствовать в базе, не попасть в выдачу, быть обрезан при сборке контекста или неверно интерпретирован моделью. Поэтому сохраняйте список найденных фрагментов отдельно от ответа и оценивайте этапы независимо. Для каждого неудачного примера должно быть понятно, где возникла проблема. Иначе замена модели будет дорогим способом маскировать недостатки загрузчика или схемы индекса.

Соберите вопросы раньше, чем выберете стек

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

Оцените найденные фрагменты

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

Проверьте опору каждого утверждения

Ответ со ссылкой не обязательно подтверждён источником. Модель может поставить правильную цитату рядом с неподтверждённым выводом. Разбейте проверку на значимые утверждения: срок, сумма, ограничение, последовательность действий. Для каждого найдите фрагмент, который действительно его поддерживает. Если источник допускает несколько толкований, ответ должен обозначить неопределённость или попросить уточнение. Не требуйте совпадения с единственной идеальной фразой: оценивайте смысл, полноту и отсутствие добавленных фактов. Автоматическая оценка помогает сортировать примеры, но требует ручной калибровки.

Минимальный пример для обсуждения

Python
def can_use_fragment(fragment, allowed_document_ids):
    return (fragment.document_id in allowed_document_ids
            and not fragment.is_deleted
            and fragment.version == fragment.current_version)

context = [f for f in candidates if can_use_fragment(f, allowed_ids)]

Отказ — тоже успешный результат

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

Права доступа входят в качество

Фильтрация только на странице источника недостаточна: фрагмент уже мог попасть в контекст модели. Проверяйте разрешения до поиска или до передачи кандидатов генератору, затем повторно перед показом ответа. При изменении членства в группе старый кэш не должен сохранять доступ. Добавьте тесты на удалённый документ, отозванное разрешение, совпадающие названия файлов и переход по цитате другим пользователем. Логи тоже не должны превращаться в обходной канал доступа. Для приёмки важен результат всей цепочки, а не наличие поля ACL в схеме.

Сделайте проверку повторяемой

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

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

Проверить перед применением

  • ☐Определены задача и последствия ошибки.
  • ☐Известно происхождение данных и разрешённый способ их использования.
  • ☐Проверки можно повторить на той же версии входных материалов.
  • ☐Ограничения результата перечислены рядом с выводом.

Обсуждение

Задайте вопрос об этой работе, обсудите решение или поделитесь своим опытом.

Обсуждение открыто для всех участников.

Загружаем комментарии…