Оценка качества RAG
Автор: Ai Flowi · Опубликовано
Оценка качества RAG проверяет, находит ли поиск нужные подтверждающие материалы и правильно ли сгенерированный ответ их использует. Отдельно оценивайте полноту найденных фрагментов, опору ответа на источники и полезность: ответ, выглядящий точным, может скрывать плохой поиск, а релевантные фрагменты всё равно могут привести к неподтверждённому ответу. Начните с размеченных вопросов и фрагментов источников, прежде чем добавлять автоматический компонент оценки.
Эта процедура использует компоненты каталога AI Flowi Workflow для организации предлагаемого оценочного запуска. Они описаны в каталоге; не проходили производственное тестирование Ai Flowi. Описанные здесь выходы компонентов оценки — условия их интерфейсов, а не измеренные результаты качества или баллы сравнительных тестов.
1. Создайте корпус вопросов с разметкой подтверждающих материалов
Храните каждый случай в CSV с постоянным идентификатором, вопросом, меткой возможности ответа, утверждённой версией источника, идентификаторами необходимых фрагментов и кратким критерием приёмки. Создавайте разметку по документам, а не по текущему ответу чат-бота. Включайте вопросы, требующие исключения вместе с основным правилом; иначе система, теряющая исключения, может выглядеть приемлемой.
Для импорта размеченного корпуса следуйте интерфейсу Load CSV и справочнику преобразования Data → DataFrame.
Идентификатор случая должен обозначать вопрос вместе с версией источника. При изменении правила сохраните прежнюю запись случая и создайте новую версию разметки подтверждающих материалов. Иначе изменение ожидаемого ответа может выглядеть как ухудшение модели, даже если она правильно следовала новому правилу. Сохраняйте в наборе случаи с неудачными поисковыми запросами; их незаметное исключение сводит сравнение только к ответам, которые удалось получить.
| Категория случая | Эталонная разметка подтверждений | Выявляемый сбой |
|---|---|---|
| Правило и исключение представлены в источнике | Необходимы оба идентификатора фрагментов. | Поиск или генерация теряет исключение. |
| Запрос без возможности ответа | Нет утверждённого подтверждающего фрагмента. | Ответ выдумывается на основе несвязанного текста. |
| Конфликт версий | Два источника противоречат друг другу и требуют проверки. | Противоречие скрывается в связно изложенном ответе. |
| Отвлекающий фрагмент, похожий на релевантный | Подходит только фрагмент о запрошенной теме. | Поверхностное сходство формулировок получает более высокий приоритет, чем применимые подтверждающие материалы. |
2. Зафиксируйте фактические входы поиска и ответа
Передайте вопрос в Knowledge Base.search_query с фиксированными knowledge_base и top_k; сохраняйте метаданные с помощью include_metadata. Сохраните Results рядом с идентификатором случая. Создание базы и проверка фрагментов описаны в существующем руководстве по поиску. Для формирования ответа используйте отдельную схему чат-бота с опорой на источники и фиксируйте текст, действительно переданный модели.
Фрагмент источника в базе данных — не то же самое, что фрагмент в промпте. Запишите найденные строки, отформатированный контекст и итоговый ответ. Если форматирование обрезает необходимое исключение, пометьте это как сбой формирования контекста. Не вините генератор за сведения, не дошедшие до его входа, и не считайте утверждение обоснованным лишь потому, что источник существует где-то ещё.
3. Настройте входы оценки для каждого случая
Настройка оценки по случаям: пример конфигурации, а не зафиксированный тест
| Компонент | Входы из каталога для настройки | Проверка перед продолжением |
|---|---|---|
| Load CSV и Data → DataFrame | csv_file: проверенный корпус; затем data_list: JSON List. | Убедитесь, что каждая полученная строка содержит один идентифицируемый случай. |
| Batch Run | df: подготовленная таблица промптов; column_name: проверенный столбец промптов; output_column_name: candidate_answer; model: настроенный LanguageModel. | Это обработка столбца; она не подтверждает автоматический запуск поиска для каждой строки. |
| Cleanlab RAG Evaluator | query: вопрос случая; context: фактически переданные подтверждения; response: сохранённый ответ; model: поддерживаемая настроенная модель; quality_preset: "base"; api_key: ваши учётные данные. | Проверяйте trust_score и объяснения вместе с разметкой источников. |
| LangWatch Evaluator | evaluator_name: настроенный компонент оценки поставщика; input: вопрос; output: ответ; contexts: подтверждающие материалы; expected_output: проверенный текст критерия приёмки. | В экспорте нет вариантов названия компонента оценки; настройте поставщика перед пробным запуском. |
Вам нужны собственные учётные записи у поставщиков моделей и оценки, все необходимые API-ключи и разрешение на передачу синтетического корпуса этим сервисам. Поставщики выставляют счета отдельно. Каталог содержит типизированные входы оценки, но не полный сценарий оркестрации от поиска до пакетного выполнения. Начните с одного случая, явно сопоставьте его фактические значения и проверьте каждую границу перед запуском всего набора.
4. Как различать полноту поиска, опору на источники и полезность при оценке RAG?
Для полноты поиска сравнивайте идентификаторы возвращённых фрагментов с эталонными. Для опоры на источники проверяйте, подтверждается ли каждое существенное утверждение ответа фактически переданным контекстом. Для полезности проверяйте, отвечает ли текст на вопрос и сохраняет ли применимые условия. Эти проверки могут расходиться: отказ от ответа уместен в случае без подтверждений, но недостаточен там, где ответ есть в источниках.
Cleanlab RAG Evaluator экспортирует переключатели run_context_sufficiency, run_query_ease, run_response_groundedness и run_response_helpfulness. Включите проверки, соответствующие вашим критериям, и сохраните other_scores, trust_explanation и evaluation_summary для изучения. Экспорт не определяет шкалу оценок, калибровку или универсальные пороги прохождения; числовой результат не является окончательным подтверждением истинности ответа.
У Cleanlab Evaluator есть входы prompt и response для общей оценки ответов. У него нет отдельного интерфейса context и query, предусмотренного для компонента оценки RAG. Выберите интерфейс, соответствующий материалам, которые хотите оценивать, и сохраняйте проверку фрагментов человеком, даже когда автоматическое объяснение звучит убедительно.
5. Сравнивайте версии по идентификатору случая
Зафиксируйте корпус, версии источников и критерии оценки. Измените один параметр поиска или промпта и сравните прежние и новые результаты для тех же случаев. В Table Operations задайте operation как экспортируемый вариант "Merge", merge_on_column как идентификатор случая, а merge_how как "outer". Перед объединением результатов проверьте уникальность идентификаторов.
Для примера сравнения представьте случай, где есть исходный ответ, но нет ответа нового варианта из-за сбоя нового поискового запроса. Внешнее объединение должно сохранить этот случай для разбора сбоя. Внутреннее объединение исключило бы его и могло бы создать впечатление, что новый вариант лучше. Это ожидаемое свойство сравнения, а не зафиксированный результат Table Operations; перед обобщением изменений изучите фактически объединённые строки.
Сохраняйте выбранную модель, число результатов поиска, текст промпта и настройки оценки с каждым запуском. Изменение компонента оценки может изменить суждение даже при неизменных ответах. Проверяйте случаи с улучшениями и ухудшениями, а также неудачные запросы и отсутствующие выходы. Не скрывайте усреднением ошибки на вопросах без ответа в источниках и не считайте тайм-аут компонента оценки успешным ответом.
6. Используйте синтетические случаи как кандидатов, а не эталон истины
aGenerate может подготовить искусственные строки по schema, instructions и необязательной таблице source. Запросите варианты формулировок вопросов и отвлекающие примеры, затем проверьте их по утверждённым фрагментам перед включением в корпус. Отличайте сгенерированные варианты от случаев с ручной разметкой. Созданный моделью список эталонных ответов может повторять то же непонимание, что и проверяемая система.
Список проверок оценки платформы описывает выбор и тестирование конструктора; это руководство оценивает конкретную задачу поиска и ответа. Выбор инструментов агентом требует отдельных наблюдений, как объясняется в оценке ИИ-агентов. Не превращайте оценку ответа в заявление о правах доступа, правильности работы инструментов или надёжности развёртывания.
7. После оценки проверьте обработку резервного ответа
Cleanlab Remediator предоставляет score, threshold, fallback_text и show_untrustworthy_response. Используйте порог только после изучения вывода выбранного компонента оценки и проверки размеченных случаев. Обязательный вход score принимает number; проверьте совместимость с фактическим числовым выходом. Правило резервного ответа не восстанавливает отсутствующие фрагменты и не делает неверный ответ правильным.
Не используйте этот предлагаемый набор проверок как автономное условие выпуска для чувствительных решений. Перед изменением пользовательского процесса изучите ошибки, полноту источников и расхождения компонентов оценки. Сохраняйте прежние выходы, чтобы резервный ответ можно было проверить, не показывая пользователям недоверенный ответ.
Бюджет оценки
Тарифы: Go от USD8 в месяц при годовой оплате (USD10 помесячно), Plus от USD16 (USD20 помесячно), Pro 100 от USD80 (USD100 помесячно), Pro 200 от USD160 (USD200 помесячно) и Pro 500 от USD400 (USD500 помесячно), от 5,000 до 250,000 Flowi Tokens в месяц с возможностью пополнения; 1 токен за каждый запуск узла; использование сторонних API и моделей не включено.
Строки набора данных, повторные запуски и вызовы компонентов оценки добавляют расход ресурсов независимо от разговора с рабочим чат-ботом. Оценивайте их по наблюдаемому пути выполнения, а не только по числу случаев.