Как построить надежную RAG: глубокое погружение в 7 точек отказа и оценочные рамки

Retrieval-Augmented Generation (RAG) имеет решающее значение для современной архитектуры ИИ, служа основной рамкой для построения контекстно-осведомленных агентов.

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

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

Анатомия разрыва RAG – 7 точек отказа (FP)

Согласно исследователям Barnett et al., системы Retrieval Augmented Generation (RAG) сталкиваются с семью конкретными точками отказа (FP) на протяжении всей трубы.

Ниже приведена диаграмма, иллюстрирующая эти этапы:

Фигура А. Процессы индексирования и запросов, необходимые для создания системы RAG. Процесс индексирования выполняется во время разработки, а запросы – во время выполнения. Точки отказа, выявленные в этом исследовании, показаны в красных коробках (источник)

Давайте рассмотрим каждую точку отказа, расположенную в порядке последовательности трубы, следующей за прогрессом слева направо, показанным в Фигуре А.

FP1. Отсутствие контента

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

Неисправность происходит, когда большая языковая модель (LLM) предоставляет правдоподобный, но неверный ответ вместо того, чтобы заявить, что она не знает.

FP2. Пропущенные лучшие документы

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

В результате правильная информация никогда не достигает LLM.

FP3. Не в контексте (ограничения стратегии консолидации)

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

Это происходит, когда слишком много документов возвращается и система должна отфильтровать их, чтобы они поместились в контекстное окно LLM, ограничения токенов или ограничения скорости.

FP4. Не извлечено

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

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

FP5. Неправильный формат

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

FP6. Неправильная спецификация

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

Например, LLM генерирует простые ответы на вопрос пользователя с сложной профессиональной целью.

FP7. Неполные ответы

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

Например, когда пользователь задает сложный вопрос, такой как “Каковы ключевые моменты в документах А, Б и В?”, LLM решает только один или два источников.

Как точки отказа компрометируют производительность трубы RAG

Каждая из этих точек отказа влияет на производительность труб RAG:

Неисправности целостности данных и доверия

Когда присутствуют отсутствующие или неверные данные, система больше не является надежным источником информации. Основные точки отказа включают:

• FP1 (Отсутствие контента): Ответ не в документе в первую очередь.
• FP4 (Не извлечено): LLM решает игнорировать правильный ответ в документе.
• FP7 (Неполные): LLM предоставляет полуправду, пропуская важные части.

Бутылочные горлышки поиска и эффективности

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

• FP2 (Пропущенные лучшие): Модель извлечения не может выбрать лучшие вложения.
• FP3 (Ограничения стратегии консолидации): Сценарий, который обрезает документы для соответствия ограничениям LLM, сбрасывает наиболее важные части.

Ошибки пользовательского опыта и форматирования

Хотя правильный, выходной результат с плохой читаемостью или в неправильном формате может компрометировать пользовательский опыт. Основные точки отказа включают:

• FP5 (Неправильный формат): LLM не может следовать конкретному формату вывода, такому как JSON.
• FP6 (Неправильная спецификация): LLM генерирует объемный вывод для простого вопроса да/нет или наоборот (слишком краткий ответ для сложного вопроса).

Оценочная стопка: рамки для смягчения точек отказа

Метрики оценки разработаны для систематического смягчения этих точек отказа.

Этот раздел исследует основные метрики оценки RAG с практическими примерами.

Основные метрики оценки RAG:

• DeepEval
• RAGAS
• TruLens
• Arize Phoenix
• Braintrust

DeepEval – Юнит-тест перед развертыванием

DeepEval рассчитывает взвешенный балл на основе критериев.

LLM в качестве судьи (например, GPT-4o) оценивает каждый критерий против вывода LLM:

DeepEval использует G-eval, рамку цепочки мыслей (CoT), которая принимает многоступенчатый подход к оценке вывода:

1. Определите критерий для измерения (например, “согласованность”, “плавность” или “релевантность”).
2. Сгенерируйте шаги оценки (с использованием оценщика LLM).
3. Следуйте шагу оценки и анализируйте входные и выходные данные LLM.
4. Рассчитайте ожидаемую взвешенную сумму балла каждого критерия.

Общий сценарий в практике

• Ситуация: Помощник технической документации (бот) для сложного программного продукта, кажется, работает каждый раз, когда команда инженеров обновляет кодовую базу.
• Проблема: Нет количественного доказательства того, что бот все еще может ответить на запрос пользователя (Вы просто “думаете”, что это работает…).
• Решение: Интегрируйте функцию PyTest в качестве регрессионного набора CI/CD в Github Action, где DeepEval запускает G-Eval и другие метрики над тестовым случаем:

• Ожидаемые результаты: Если любой балл метрик падает ниже порога (0,85), PyTest вызывает AssertionError – немедленно терпя неудачу в сборке CI, предотвращая тихую регрессию от достижения производства.

Примечание разработчика – Тестовый случай для DeepEval
Набор LLMTestCase объектов определяет тестовый случай, который запускает DeepEval.

На практике этот тестовый случай должен содержать наиболее важные запросы пользователей и помеченные выходные данные с извлеченным контекстом.

Эти могут быть получены из файла JSON или CSV.

RAGAS – Оптимизатор в стоге сена

RAGAS (Оценка Retrieval Augmented Generation) направлена на оценку RAG без аннотированного набора данных, генерируя синтетические тестовые наборы.

Затем он вычисляет флагманские метрики:

Фигура Б. Диаграмма оценочной триады RAGAS, соединяющей Вопрос, Контекст и Ответ через метрики Точности, Полноты, Верности и Релевантности (создано Kuriko IWAI)

Флагманские метрики категоризированы в три группы:

• Труба извлечения (черная сплошная линия, Фигура Б): Точность контекста, полнота контекста.
• Труба генерации (черная пунктирная линия, Фигура Б): Верность, релевантность ответа.
• Истина (красная коробка, Фигура Б): Семантическое сходство ответа, правильность ответа.

Общий сценарий в практике

• Ситуация: Система RAG для юридических контрактов пропускает ключевые положения. Вы не уверены, является ли проблема поисковой (извлекательной) или чтением (генераторной).
• Проблема: Нет представления об оптимальном top-k (количество извлеченных фрагментов).
• Решение: Используйте RAGAS для создания синтетического тестового набора с 100 парами вопросов и доказательств. Затем запустите трубу RAG над тестовым набором, чтобы рассчитать полноту контекста и точность контекста:
• Ожидаемый результат: В зависимости от результатов метрик, план действий может быть следующим:

Таблица 1. Диагностический план действий RAGAS – отображение баллов на корректировки системы.

TruLens – Специалист по обратной связи

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

Он также использует оценку LLM, отражающую, насколько хорошо ответ удовлетворяет намерению запроса, используя 4-балльную шкалу Лайкерта (0-3), что делает его превосходным для ранжирования качества различных результатов поиска.

Общий сценарий в практике

• Ситуация: Бот-медицинский советник отвечает на вопрос пользователя правильно, но добавляет совет, который не находится в базе PDF.
• Проблема: Дополнительный совет может быть полезным, но не обоснованным.
• Решение: Используйте TruLens, чтобы реализовать функцию обратной связи по обоснованности с порогом, таким как балл > 0,8.

• Ожидаемые результаты: Когда LLM генерирует ответ, содержащий информацию, не присутствующую в извлеченных фрагментах, TruLens флагирует запись в вашем панеле управления.

Arize Phoenix – Тихий картограф отказов

Arize Phoenix – это инструмент открытого исходного кода для наблюдения и оценки, разработанный для оценки выходных данных LLM, включая сложные системы RAG.

Разработанный на OpenTelemetry компанией Arize AI, он фокусируется на наблюдаемости, рассматривая оценку LLM как подмножину MLOps.

В контексте оценки RAG Phoenix превосходит в анализе вложений, используя Унифицированное приближение и проекцию (UMAP), чтобы уменьшить высокоразмерные векторные вложения до 2D/3D-пространства.

Этот анализ вложений математически раскрывает, являются ли неудавшиеся запросы семантически сгруппированы вместе, что указывает на пробел в векторном хранилище.

Общий сценарий в практике

• Ситуация: Бот поддержки клиентов работает отлично для возвратов, но дает бессмысленные ответы на запросы гарантий.
• Проблема: Дыра в векторном хранилище (Не могу найти в журналах).
• Решение: Используйте Arize Phoenix, чтобы сгенерировать визуализацию вложений UMAP (UEV), 3D-карту для векторного хранилища – чтобы наложить запросы пользователей на фрагменты документов.
• Ожидаемые результаты: Визуально увидеть кластер запросов пользователей, приземляющихся в темной зоне, где нет документов, указывающих на то, что некоторые документы были забыты для загрузки в векторное хранилище.

Braintrust – Сеть безопасности регрессии запросов

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

Общий сценарий в практике

• Ситуация: Команда инженеров обновляет запрос с “Ответьте на вопрос” (Случай А) до более сложного 500-словного системного инструктажа (Случай Б).
• Проблема: Улучшение запроса для Случая Б может случайно сломать Случай А.
• Решение: Используйте Braintrust, чтобы создать золотой набор данных с набором N идеальных примеров (например, N = 50). Дайте Braintrust запустить сравнение бок о бок (SxS) каждый раз, когда команда обновляет одно слово в запросе:

• Ожидаемый результат: Отчет о различиях, показывающий, какие случаи стали лучше/хуже для каждого из золотого набора данных (N = 50).

Заключение

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

Стратегия реализации: отображение метрик на точки отказа

Хотя нет универсального решения, Таблица 2 показывает, какие метрики оценки применять для каждой точки отказа, рассмотренной в этой статье:

Таблица 2. Матрица смягчения точки отказа – какой инструмент решает какую точку отказа?

DeepEval и RAGAS могут использовать свои метрики верности для измерения неисправностей целостности данных (FP1, FP4, FP7).

TruLens использует свою точность контекста / полноту для измерения релевантности контекста к выходным данным – эффективно оценивая FP2.

Arize Phoenix предоставляет визуальный след процесса извлечения, что делает легко видимым, был ли документ, извлеченный во время консолидации, потерян (FP3).

Для ошибок пользовательского опыта DeepEval создает пользовательские метрики для оценки ошибок пользовательского опыта, в то время как Braintrust превосходит в сравнении набора истины.