Генерация дополненного извлечения (RAG) стала самым популярным способом предоставления LLM дополнительного контекста для создания адаптированных выходных данных. Это отлично подходит для приложений LLM, таких как чат-боты или агенты ИИ, поскольку RAG предоставляет пользователям гораздо более контекстуальный опыт, выходящий за рамки данных, на которых обучались LLM, такие как GPT-4.
Неудивительно, что практикующие LLM столкнулись с проблемами оценки приложений RAG во время разработки. Но благодаря исследованиям, проведенным RAGA, оценка общих характеристик генератора-извлекателя систем RAG в 2024 году является в некоторой степени решенной проблемой. Однако создание приложений RAG до сих пор остается проблемой — вы можете использовать неправильную модель встраивания, плохую стратегию фрагментации или выводить ответы в неправильном формате, что как раз и пытаются решить такие фреймворки, как LlamaIndex.
Но теперь, по мере того как архитектуры RAG становятся все более сложными, а сотрудничество между специалистами LLM в этих проектах усиливается, возникновение критических изменений становится более частым, чем когда-либо.
В этом руководстве мы рассмотрим, как настроить полностью автоматизированный набор оценки/тестирования для модульного тестирования приложений RAG в ваших конвейерах CI/CD. Готовы ли вы узнать, как настроить идеальный рабочий процесс разработки RAG?
Давайте приступим.
Коротко об оценке RAG
В одной из своих предыдущих статей я объяснял, что типичная архитектура RAG включает в себя извлекатель — компонент, который выполняет векторный поиск в вашей базе знаний для контекстов извлечения, и генератор — компонент, который берет контексты извлечения из вашего извлекателя для построения подсказки и генерации настраиваемого ответа LLM в качестве конечного результата.
Высокопроизводительная система RAG получается из высокопроизводительных извлекателя и генератора. Поэтому метрики оценки RAG обычно фокусируются на оценке этих двух компонентов. Основное предположение заключается в том, что приложение RAG может преуспеть только в том случае, если извлекатель успешно извлекает правильные и релевантные контексты, и если генератор может эффективно использовать эти контексты для получения желаемых результатов (т. е. фактически правильных и релевантных результатов).
Общие метрики RAG
По причинам, которые обсуждались выше, метрики оценки RAG, как правило, фокусируются на извлекателе и генераторе. В частности, RAGA является популярным способом оценки общих характеристик RAG и предлагает следующие метрики извлечения (метрики для извлекателя). Давайте рассмотрим общие метрики оценки RAG:
Контекстная полнота
Контекстная полнота измеряет, насколько хорошо контекст извлечения инкапсулирует информацию в ожидаемый результат. Контекстная полнота касается извлекателя и требует ожидаемого результата в качестве целевой метки. Некоторых это может сбить с толку, но причина, по которой требуется ожидаемый результат, заключается в том, что не имеет смысла использовать фактический результат в качестве основной истины. Подумайте об этом: как вы можете определить качество контекста извлечения, если не знаете, какого идеального результата ожидать?
Контекстная точность
Контекстная точность — это метрика, которая измеряет, насколько хорошо ваш извлекатель RAG ранжирует контекст извлечения на основе релевантности. Это важно, потому что LLM склонны больше рассматривать узлы, которые находятся ближе к концу шаблона подсказки. Это означает, что неправильное переранжирование приведет к тому, что ваш LLM сосредоточится на «неправильных» узлах извлечения, что может привести к галлюцинациям или нерелевантным ответам в дальнейшем.
Релевантность ответа
Релевантность ответа измеряет, насколько релевантно ваш генератор RAG, который часто представляет собой просто LLM и саму подсказку, способен генерировать ответы. Обратите внимание, что релевантность ответа напрямую связана с качеством извлекателя, поскольку для генерации выходных данных в конвейере RAG требуется информация из контекста извлечения. Если контекст извлечения вводит в заблуждение или нерелевантен, вы гарантированно получите менее релевантные ответы.
Верность
Верность измеряет степень галлюцинаций, создаваемых вашим генератором RAG, используя контекст извлечения в качестве основной истины. Подобно релевантности ответа, степень верности зависит от релевантности контекста извлечения.
Метрики RAG, в конце концов, не такие уж и идеальные
Помимо эффективности их самая сильная сторона заключается в их независимой от варианта использования природе. Независимо от того, создаете ли вы чат-бота для финансовых консультантов или приложение для извлечения данных, эти метрики будут работать так, как и ожидалось. По иронии судьбы, несмотря на независимость от варианта использования, вы вскоре обнаружите, что эти метрики в конечном итоге слишком общие. Чат-боту для финансовых консультантов могут потребоваться дополнительные метрики, такие как смещение при обработке клиентских данных, в то время как приложению для извлечения данных могут потребоваться метрики, чтобы гарантировать соответствие выходных данных формату JSON.
Помимо общих метрик оценки RAG, вы можете включить дополнительные метрики оценки LLM в свой конвейер оценки RAG с помощью DeepEval следующим образом. Сначала установите DeepEval:
pip install deepevalЗатем импортируйте и определите метрики RAGAs:
from deepeval.metrics.ragas import ( RAGASContextualPrecisionMetric, RAGASFaithfulnessMetric, RAGASContextualRecallMetric, RAGASAnswerRelevancyMetric, ) contextual_precision = RAGASContextualPrecisionMetric() contextual_recall = RAGASContextualRecallMetric() answer_relevancy = RAGASAnswerRelevancyMetric() faithfulness = RAGASFaithfulnessMetric()Используя G-Eval, включите любые дополнительные метрики помимо метрик RAG:
from deepeval.metrics import GEval from deepeval.test_case import LLMTestCaseParams bias = GEval( name="Bias", criteria="Coherence - determine if the actual output has an inherent bias against Asian culture.", evaluation_params=[LLMTestCaseParams.ACTUAL_OUTPUT], )И, наконец, на основе этих метрик определите тестовый случай для оценки вашего приложения RAG:
from deepeval import evaluate from deepeval.test_case import LLMTestCase test_case = LLMTestCase( input="", actual_output="", expected_output="", retrieval_context=[""] ) evaluate( test_cases=[test_case], metrics=[ contextual_precision, contextual_recall, answer_relevancy, faithfulness, bias ] )Все это отлично подходит для быстрого прототипирования, но что, если вы захотите настроить свою LLM-игру и включить оценки в рабочий процесс разработки?
Модульное тестирование приложений RAG с помощью DeepEval
DeepEval — это фреймворк оценки с открытым исходным кодом для LLM (также часто называемый модульным тестированием для LLM или полным набором тестирования для LLM). В предыдущем разделе мы рассмотрели, как для оценки приложений RAG использовать метрики оценки RAG и дополнительные метрики, специфичные для конкретных случаев использования. В этом разделе мы рассмотрим полный пример модульного тестирования с помощью DeepEval.
Предварительные условия
В отличие от других рабочих процессов, основная цель оценки в конвейерах CI/CD — защититься от критических изменений, внесенных в ваше приложение RAG для конкретного коммита на git. Поэтому статический набор данных оценки, который не отражает изменения, внесенные в ваше приложение RAG, не подойдет.
Поэтому не нужно заранее готовить набор данных оценки, содержащий фактические выходные данные и контексты извлечения вашего приложения RAG. Вместо этого подготовьте набор входных данных и ожидаемых выходных данных, с которыми вы хотите протестировать соответствующие фактические выходные данные вашего приложения RAG, поскольку во время оценки мы запустим наше приложение RAG.
Установите DeepEval и, при желании, войдите в систему:
pip install deepeval deepeval loginСоздайте тестовый файл
В предыдущем разделе мы показали, как использовать функцию оценки DeepEval, но сейчас мы собираемся отказаться от этого подхода и вместо этого использовать интеграцию DeepEval с Pytest.
Для начала создайте тестовый файл:
touch test_rag.pyИнициализируйте метрики оценки
Аналогично предыдущему примеру, инициализируйте метрики оценки в недавно созданном тестовом файле:
from deepeval.metrics.ragas import ( RAGASContextualPrecisionMetric, RAGASFaithfulnessMetric, RAGASContextualRecallMetric, RAGASAnswerRelevancyMetric, ) from deepeval.metrics import BiasMetric bias = BiasMetric(threshold= 0.5 ) contextual_precision = RAGASContextualPrecisionMetric(threshold= 0.5 ) contextual_recall = RAGASContextualRecallMetric(threshold= 0.5 ) answer_relevancy = RAGASAnswerRelevancyMetric(threshold= 0.5 ) faithfulness = RAGASFaithfulnessMetric(threshold= 0.5 )Обратите внимание на то, как вы можете опционально определить пороговые значения для каждой метрики. Каждая метрика в DeepEval выводит оценку от 0 до 1, и метрика считается успешной только в том случае, если оценка равна или превышает пороговое значение. С другой стороны, тестовый случай, как мы увидим позже, считается успешным только в том случае, если успешны все метрики.
Определите входные и ожидаемые выходные данные
Здесь вы определите набор входных данных, на которых вы хотите запустить свое приложение RAG во время оценки.
... # Replace this with your own data input_output_pairs = [ { "input": "...", "expected_output": "...", }, { "input": "...", "expected_output": "...", } ](Примечание: вы также можете импортировать эти данные из файлов CSV или JSON)
Полный пример
Собрав все воедино, мы представляем вам полный пример того, как можно проводить модульное тестирование приложений RAG с помощью DeepEval:
import pytest from deepeval import assert_test from deepeval.metrics.ragas import ( RAGASContextualPrecisionMetric, RAGASFaithfulnessMetric, RAGASContextualRecallMetric, RAGASAnswerRelevancyMetric, ) from deepeval.metrics import BiasMetric from deepeval.test_case import LLMTestCase ####################################### # Initialize metrics with thresholds ## ####################################### bias = BiasMetric(threshold= 0.5 ) contextual_precision = RAGASContextualPrecisionMetric(threshold= 0.5 ) contextual_recall = RAGASContextualRecallMetric(threshold= 0.5 ) answer_relevancy = RAGASAnswerRelevancyMetric(threshold= 0.5 ) faithfulness = RAGASFaithfulnessMetric(threshold= 0.5 ) ####################################### # Specify evaluation metrics to use ### ####################################### evaluation_metrics = [ bias, contextual_precision, contextual_recall, answer_relevancy, faithfulness ] ####################################### # Specify inputs to test RAG app on ### ####################################### input_output_pairs = [ { "input": "", "expected_output": "", }, { "input": "", "expected_output": "", } ] ####################################### # Loop through input output pairs ##### ####################################### @pytest.mark.parametrize( "input_output_pair", input_output_pairs, ) def test_llamaindex(input_output_pair: Dict): input = input_output_pair.get("input", None) expected_output = input_output_pair.get("expected_output", None) # Hypothentical RAG application for demonstration only. # Replace this with your own RAG implementation. # The idea is you'll be generating LLM outputs and # getting the retrieval context at evaluation time for each input actual_output = rag_application.query(input) retrieval_context = rag_application.get_retrieval_context() test_case = LLMTestCase( input=input, actual_output=actual_output, retrieval_context=retrieval_context, expected_output=expected_output ) # assert test case assert_test(test_case, evaluation_metrics)И, наконец, запустите тестовый файл через CLI:
deepeval test run test_rag.pyНесколько вещей, которые следует отметить:
-
Большинство метрик оцениваются с использованием моделей OpenAI GPT по умолчанию, поэтому не забудьте установить свой ключ API OpenAI в качестве переменной среды.
-
Вы можете определить пороговые значения прохождения и указать модель оценки, которую вы хотите использовать для каждой метрики.
-
Тестовый пример считается успешным только тогда, когда успешны все метрики оценки.
-
Вы можете включить столько метрик, сколько захотите. Полный список метрик можно найти здесь.
-
Для более чистого кода вы можете импортировать пары входных и ожидаемых выходных данных из файлов CSV/JSON.
-
Мы использовали декораторы Pytest (@pytest.mark.parametrize) для циклического перебора пар входных и выходных данных при выполнении модульных тестов.
-
Фактический контекст выходных данных и извлечения генерируется динамически. В приведенном выше примере мы использовали гипотетическую реализацию RAG, но вам придется заменить ее собственным приложением RAG. (Пользователи LlamaIndex могут найти отличный пример в документации DeepEval).
Модульное тестирование RAG в конвейерах CI/CD
Хорошая новость: вы уже выполнили 99% необходимой тяжелой работы. Теперь осталось включить команду запуска теста deepeval в вашу среду CI/CD. Ниже представлен пример того, как можно добавить DeepEval в файлы YAML рабочих процессов GitHub:
name: RAG Deployment Evaluations on: push: jobs: test: runs-on: ubuntu-latest steps: # Some extra steps to setup and install dependencies ... # Optional Login - name: Login to Confident env: CONFIDENT_API_KEY: ${{ secrets.CONFIDENT_API_KEY }} run: poetry run deepeval login --confident-api-key "$CONFIDENT_API_KEY" - name: Run deepeval tests env: OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }} run: poetry run deepeval test run test_rag.pyОбратите внимание на то, что ваш файл рабочего процесса НЕ обязательно должен быть таким же, как в примере выше, но вы должны понять суть — все будет готово, если вы настроите правильные переменные среды и включите команду запуска теста deepeval в вашу среду CI/CD.
Поздравляем! Вы официально проводите модульное тестирование своего приложения RAG в конвейерах CI/CD! Помните график в начале статьи? Теперь это выглядит так:
Заключение
Существующие метрики оценки RAG, такие как RAGA, отлично подходят для оценки производительности универсального извлекателя-генератора, но часто не подходят для приложений, специфичных для конкретных вариантов использования. Более того, оценки — это не просто проверка работоспособности, а мера, применяемая для защиты от критических изменений, особенно в среде совместной разработки. Следовательно, включение оценок в конвейеры CI/CD имеет решающее значение для любой серьезной организации, разрабатывающей приложения RAG.
Если вы хотите внедрить собственные метрики оценки для устранения недостатков универсальных метрик RAG и ищете фреймворк тестирования производственного уровня для включения в конвейеры CI/CD, DeepEval является отличным вариантом. Он включает в себя более 14 метрик оценки, поддерживает параллельное выполнение тестов и достаточно глубоко интегрирован с Confident AI, первой в мире инфраструктурой оценки с открытым исходным кодом для LLM.
ссылка на оригинал статьи https://habr.com/ru/articles/865420/
Добавить комментарий