Оценка RAG: Полное руководство по модульному тестированию RAG в CI/CD

Генерация дополненного извлечения (RAG) стала самым популярным способом предоставления LLM дополнительного контекста для создания адаптированных выходных данных. Это отлично подходит для приложений LLM, таких как чат-боты или агенты ИИ, поскольку RAG предоставляет пользователям гораздо более контекстуальный опыт, выходящий за рамки данных, на которых обучались LLM, такие как GPT-4.

Неудивительно, что практикующие LLM столкнулись с проблемами оценки приложений RAG во время разработки. Но благодаря исследованиям, проведенным RAGA, оценка общих характеристик генератора-извлекателя систем RAG в 2024 году является в некоторой степени решенной проблемой. Однако создание приложений RAG до сих пор остается проблемой — вы можете использовать неправильную модель встраивания, плохую стратегию фрагментации или выводить ответы в неправильном формате, что как раз и пытаются решить такие фреймворки, как LlamaIndex.

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

В этом руководстве мы рассмотрим, как настроить полностью автоматизированный набор оценки/тестирования для модульного тестирования приложений RAG в ваших конвейерах CI/CD. Готовы ли вы узнать, как настроить идеальный рабочий процесс разработки RAG?

Давайте приступим.

В одной из своих предыдущих статей я объяснял, что типичная архитектура RAG включает в себя извлекатель — компонент, который выполняет векторный поиск в вашей базе знаний для контекстов извлечения, и генератор — компонент, который берет контексты извлечения из вашего извлекателя для построения подсказки и генерации настраиваемого ответа LLM в качестве конечного результата.

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

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

Контекстная полнота

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

Контекстная точность

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

Релевантность ответа

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

Верность

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

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

Помимо общих метрик оценки RAG, вы можете включить дополнительные метрики оценки LLM в свой конвейер оценки RAG с помощью DeepEval следующим образом. Сначала установите DeepEval:

Затем импортируйте и определите метрики RAGAs:

Используя G-Eval, включите любые дополнительные метрики помимо метрик RAG:

И, наконец, на основе этих метрик определите тестовый случай для оценки вашего приложения RAG:

Все это отлично подходит для быстрого прототипирования, но что, если вы захотите настроить свою LLM-игру и включить оценки в рабочий процесс разработки?

DeepEval — это фреймворк оценки с открытым исходным кодом для LLM (также часто называемый модульным тестированием для LLM или полным набором тестирования для LLM). В предыдущем разделе мы рассмотрели, как для оценки приложений RAG использовать метрики оценки RAG и дополнительные метрики, специфичные для конкретных случаев использования. В этом разделе мы рассмотрим полный пример модульного тестирования с помощью DeepEval.

Предварительные условия

В отличие от других рабочих процессов, основная цель оценки в конвейерах CI/CD — защититься от критических изменений, внесенных в ваше приложение RAG для конкретного коммита на git. Поэтому статический набор данных оценки, который не отражает изменения, внесенные в ваше приложение RAG, не подойдет.

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

Установите DeepEval и, при желании, войдите в систему:

Создайте тестовый файл

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

Для начала создайте тестовый файл:

Инициализируйте метрики оценки

Аналогично предыдущему примеру, инициализируйте метрики оценки в недавно созданном тестовом файле:

Обратите внимание на то, как вы можете опционально определить пороговые значения для каждой метрики. Каждая метрика в DeepEval выводит оценку от 0 до 1, и метрика считается успешной только в том случае, если оценка равна или превышает пороговое значение. С другой стороны, тестовый случай, как мы увидим позже, считается успешным только в том случае, если успешны все метрики.

Определите входные и ожидаемые выходные данные

Здесь вы определите набор входных данных, на которых вы хотите запустить свое приложение RAG во время оценки.

(Примечание: вы также можете импортировать эти данные из файлов CSV или JSON)

Полный пример

Собрав все воедино, мы представляем вам полный пример того, как можно проводить модульное тестирование приложений RAG с помощью DeepEval:

И, наконец, запустите тестовый файл через CLI:

Несколько вещей, которые следует отметить:

Хорошая новость: вы уже выполнили 99% необходимой тяжелой работы. Теперь осталось включить команду запуска теста deepeval в вашу среду CI/CD. Ниже представлен пример того, как можно добавить DeepEval в файлы YAML рабочих процессов GitHub:

Обратите внимание на то, что ваш файл рабочего процесса НЕ обязательно должен быть таким же, как в примере выше, но вы должны понять суть — все будет готово, если вы настроите правильные переменные среды и включите команду запуска теста deepeval в вашу среду CI/CD.

Поздравляем! Вы официально проводите модульное тестирование своего приложения RAG в конвейерах CI/CD! Помните график в начале статьи? Теперь это выглядит так:

Существующие метрики оценки RAG, такие как RAGA, отлично подходят для оценки производительности универсального извлекателя-генератора, но часто не подходят для приложений, специфичных для конкретных вариантов использования. Более того, оценки — это не просто проверка работоспособности, а мера, применяемая для защиты от критических изменений, особенно в среде совместной разработки. Следовательно, включение оценок в конвейеры CI/CD имеет решающее значение для любой серьезной организации, разрабатывающей приложения RAG.

Если вы хотите внедрить собственные метрики оценки для устранения недостатков универсальных метрик RAG и ищете фреймворк тестирования производственного уровня для включения в конвейеры CI/CD, DeepEval является отличным вариантом.

Автор оригинала: Jeffrey Ip

#rag #raga #llm #deepeval