Отладка RAG путем поиска первого этапа, который не сработал

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

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

Практический цикл оценки должен сохранять весь путь от исходных данных до ответа, который увидел пользователь.

Создавайте примеры с доказательствами, а не только с ответами

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

Примериллюстративного случая может выглядеть следующим образом:

{
  "question": "When should this deployment be rolled back?",
  "required_evidence": ["handbook-v3:section-8"],
  "must_include": ["the failed health-check condition"],
  "must_not_claim": ["every warning requires rollback"],
  "answerable": true
}

Эта запись полезнее, чем одно ожидаемое предложение. Она позволяет предоставить несколько хорошо составленных ответов, сохраняя при этом условия, делающие их корректными.

Добавьте вопросы, на которые корпус не может ответить. В противном случае система, которая всегда генерирует что-то, может казаться более сильной, чем та, которая правильно указывает на отсутствие доказательств.

Сначала проверьте самую раннюю ошибку

Начните с исходного материала. Существует ли необходимая информация в индексированном тексте и принадлежит ли она указанному документу? Если нет, исправьте процесс загрузки исходных данных.

Затем проверьте процесс поиска. Попала ли соответствующая информация в список кандидатов? Если да, пережила ли она фильтрацию, переранжирование и сбор контекста? Это отдельные этапы проверки. Фрагмент, найденный в ходе поиска, но удаленный до генерации ответа, не может служить основой для окончательного результата.

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

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

Используйте показатели, выявляющие различные ошибки

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

Показатели ранжирования помогают отличить доказательства, находящиеся на первом месте, от тех, что расположены ближе к пороговому значению. Однако с метками релевантности нужно обращаться осторожно: один отрывок может упоминать тему, в то время как другой напрямую отвечает на вопрос. Рассматривать их как одинаково полезные может привести к поощрению неправильного поведения.

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

Сохраняйте качество работы в рамках одного эксперимента

Записывайте время ответа, сбои и использование ресурсов вместе с оценками качества. Сохраняйте версию корпуса, настройки поиска, версию запроса и идентификатор модели, чтобы сравнения были понятными.

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

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

Оценка того, что доходит до пользователя

Даже правильный ответ сервера может отобразиться при неверном запросе, если интерфейс принимает устаревшие запросы. Включайте интеракцию поиска в React в тестирование «от начала до конца».

Полезным результатом оценки является конкретное дальнейшее действие: восстановление извлечения информации, расширение процесса поиска, сохранение контекста, корректировка генерации ответа или устранение проблем с его передачей. Это гораздо более эффективный результат, чем простое осознание того, что ответ «кажется неверным».