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