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