[Перевод] Оценка RAG: Полное руководство по модульному тестированию RAG в CI/CD12.12.2024 13:00

Генерация дополненного извлечения (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

По причинам, которые обсуждались выше, метрики оценки 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.

© Habrahabr.ru