Оценка генерации с дополненным поиском (RAG): всё, что вам следует знать
Введение
Retrieval Augmented Generation (RAG) стал широко применяемым подходом для реализации приложений генеративного ИИ на базе Large Language Models (LLMs). Интегрируя внешние источники знаний, RAG повышает способность модели предоставлять более точные и контекстуально релевантные ответы на конкретные запросы. Несмотря на свой потенциал, ответы, сгенерированные RAG, не всегда полностью точны или согласуются с извлеченными знаниями.
В недавнем вебинаре Stefan Webb, Developer Advocate в Zilliz, рассмотрел стратегии оценки для RAG-приложений, уделив особое внимание методам оценки производительности LLM и текущим вызовам и ограничениям в этой области.
В этом блоге мы кратко рассмотрим ключевые идеи Stefan, включая обзор различных архитектур RAG-пайплайнов, фреймворков для извлечения и оценки, а также примеры предвзятостей и сбоев в LLM.
Архитектура RAG
Stefan начал выступление с представления фундаментальной концепции семантического поиска, критически важного компонента RAG-приложений. Семантический поиск использует векторные базы данных, такие как Milvus или Zilliz, в качестве систем хранения базы знаний для векторных эмбеддингов. Эти базы данных обеспечивают эффективный поиск по неструктурированным данным для извлечения семантически похожих контекстов, релевантных запросу пользователя. Эта возможность составляет основу RAG-систем, гарантируя, что извлеченные знания тесно соответствуют входному вопросу, тем самым повышая качество сгенерированных ответов.
На рисунке 1 ниже показана базовая, наивная архитектура RAG. В этой схеме система извлекает наиболее релевантные документы на основе их семантического сходства с вопросом пользователя. Затем извлеченная информация форматируется в структурированный prompt с инструкциями и передается в LLM. Модель использует этот контекст, чтобы сгенерировать хорошо обоснованный ответ.
Рисунок 1: Наивный RAG
Рисунок 1: Наивный RAG
Хотя базовый RAG-пайплайн может извлекать релевантные документы и генерировать ответы, его производительность не всегда оптимальна. Некоторым выводам может не хватать точности или релевантности. Чтобы решить эти проблемы, модульный подход к построению RAG-пайплайна позволяет постепенно улучшать каждый этап.
Ниже (как показано на рисунке 2) приведены ключевые техники, которые могут повысить эффективность пайплайна.
Рисунок 2: Модульная архитектура RAG
Рисунок 2: Модульная архитектура RAG (Источник)
Трансляция запроса
Этот шаг направлен на обеспечение того, чтобы запрос пользователя был правильно понят системой. Он преобразует запросы в формат или представление, которое соответствует базовому механизму извлечения.
Multi-query: Разбивает основной запрос на несколько сфокусированных подзапросов для извлечения разнообразной, но релевантной информации.
Step-back: Возвращается к предыдущим шагам пайплайна, когда найдено недостаточно результатов, уточняя запрос для более качественного извлечения.
RAG Fusion: Объединяет результаты нескольких запросов, чтобы предоставить связный и всесторонний контекст для LLM.
Гипотетические документы (HyDE): Предполагает генерацию синтетических документов или гипотетических контекстов, которые могут помочь в извлечении семантически похожих документов из базы знаний, улучшая извлечение для абстрактных или плохо сформулированных запросов.
Маршрутизация запросов
Подход Query Routing направляет запрос к наиболее подходящему механизму извлечения или источнику знаний.
Логическая маршрутизация: Маршрутизирует запросы на основе заранее заданных правил или логических операторов, например фильтрации по метаданным или домену.
Семантическая маршрутизация: Направляет запросы на основе их семантических характеристик в базу данных или систему, наиболее подходящую для их обработки.
Конструирование запросов
Query Construction уточняет, как формулируются запросы, чтобы соответствовать структуре нижележащих баз данных.
Relational DB: Конструирует SQL-подобные запросы для традиционных реляционных баз данных.
Graph DB: Использует графовые обходные запросы Cypher для исследования узлов и связей в графовых базах данных.
Vector DB: Использует эмбеддинги для создания векторизованных запросов для поиска по семантическому сходству.
Индексация
Индексация улучшает организацию и доступность базы знаний.
Оптимизация чанков: Разбивает документы на осмысленные, пригодные для извлечения чанки, сохраняя контекст.
Многопредставленческая индексация: Создает несколько представлений (например, семантическое, синтаксическое) данных для различных потребностей извлечения.
Специализированные эмбеддинги: Использует предметно-специфичные эмбеддинги для улучшения извлечения узкоспециализированной или технической информации.
Иерархическая индексация: Структурирует индекс иерархически для более быстрых и точных поисковых запросов.
Извлечение
Извлекает наиболее релевантные документы или контексты для заданного запроса с использованием продвинутых методов.
Ранжирование: Оценивает извлеченные документы на основе релевантности, обеспечивая приоритизацию лучших совпадений.
Корректирующий RAG: Корректирует ранжирование на основе обратной связи или дополнительных критериев для динамического улучшения результатов.
Повторное извлечение: Итеративно извлекает документы, если первоначальные результаты не соответствуют ожиданиям качества, уточняя процесс до тех пор, пока не будет найден приемлемый результат.
Этот модульный подход к построению RAG-конвейера позволяет независимо тонко настраивать каждый компонент. Решая конкретные задачи на каждом этапе, конвейер становится более надежным, точным и адаптируемым, в конечном счете повышая качество генерируемых результатов.
Оценка базовых моделей
Независимо от того, используется ли наивный или продвинутый подход RAG, оценка производительности каждого RAG-приложения имеет важное значение. Эта оценка помогает выявить сильные и слабые стороны, обеспечивая надежность и релевантность системы. Все LLM, независимо от уровня сложности, требуют строгой оценки производительности для устранения потенциальных ограничений, предвзятостей и неточностей.
Оценка производительности
Но как измерять и оценивать производительность модели? Измерение производительности RAG-приложения требует нюансированного подхода, поскольку необходимо оценивать разные аспекты конвейера. Ниже приведены ключевые соображения и методы эффективного измерения производительности:
Оценка на задаче vs. оценка самой модели
Оценка задач: Измеряет производительность модели на заранее заданном наборе задач, которые часто включают многошаговые (например, MT-Bench) или многозадачные (например, MMLU) сценарии. Каждая задача связана с конкретными эталонными вопросами и справочными ответами.
Самооценка: Сосредоточена на внутренних метриках производительности, таких как то, насколько эффективно модель извлекает и обрабатывает информацию, не обязательно связывая это с практическим вариантом использования. Это полезно для диагностики производительности конвейера.
Сравнение ответов с эталонной истиной и контекстом
Сравнение с эталонной истиной: Оценивает, насколько близко сгенерированный ответ соответствует заранее определенному, точному ответу (эталонной истине). Этот подход хорошо работает для объективных задач, таких как запросы, основанные на фактах.
Контекстуальное сравнение: Проверяет, насколько хорошо ответ согласуется с контекстом, предоставленным извлеченными документами. Это особенно важно для задач, где эталонная истина недоступна или субъективна, с акцентом на связность и релевантность.
Оценка извлечения vs. оценка вывода LLM
Оценка извлечения: Сосредоточена на качестве документов, извлеченных конвейером. Метрики могут включать полноту и точность между извлеченными документами и запросом.
Оценка вывода LLM: Проверяет качество итогового вывода, сгенерированного языковой моделью, учитывая такие факторы, как фактическая согласованность и релевантность запросу и извлеченному контексту.
Человеческая оценка как «золотой стандарт»
- Человеческая оценка остается самым надежным методом оценки производительности, особенно для субъективных или сложных задач. Люди могут оценивать нюансированные аспекты, такие как логическая согласованность, тон и креативность. Однако этот подход плохо масштабируется из-за требований к времени и ресурсам.
Использование LLM для оценки LLM (LLM-as-a-Judge)
- Более продвинутые и эффективные LLM (LLM-as-a-Judge) могут применяться для оценки выводов других LLM, особенно когда эталонная истина недоступна. Эти модели могут оценивать ответы на основе заранее определенных критериев, таких как релевантность и корректность, предлагая масштабируемую альтернативу человеческой оценке. Однако необходимо соблюдать осторожность, чтобы избежать внесения предвзятости со стороны самой оценивающей модели.
Стефан продолжил обсуждение, рассмотрев два подхода к оценке: оценку на основе задач и самооценку. Оценка на основе задач обычно опирается на общедоступные бенчмарки, тогда как самооценка больше сосредоточена на внутренних показателях или интроспекции, таких как изучение качества сгенерированных ответов и релевантности извлеченной информации.
Оценка на основе задач: бенчмарк-подход
Оценка на основе задач основана на использовании стандартных, общедоступных бенчмарков, которые оценивают производительность модели в различных задачах. Эти бенчмарки часто охватывают разные области знаний, возможности ответов на вопросы и навыки ведения диалога. Некоторые примеры включают:
Бенчмарки на основе знаний: Эти бенчмарки сосредоточены на общих знаниях и ответах на вопросы, основанных на фактах.
MMLU: Разнообразный бенчмарк, который тестирует языковые модели в нескольких областях, включая математику, науку и историю.
HellaSwag: Бенчмарк, разработанный для измерения рассуждений на основе здравого смысла.
ARC: Бенчмарк, сосредоточенный на ответах на вопросы с возможностями рассуждения.
Бенчмарки следования инструкциям: Эти бенчмарки оценивают способность модели следовать инструкциям и генерировать релевантные ответы.
Flan: Серия задач, которые оценивают способности следовать инструкциям в LLM.
Self-instruct: Оценивает способность модели генерировать и следовать самостоятельно сгенерированным инструкциям.
NaturalInstructions: Крупномасштабный бенчмарк, сосредоточенный на способности модели следовать инструкциям на естественном языке.
Диалоговые бенчмарки: Эти бенчмарки оценивают способность модели участвовать в связном и релевантном диалоге.
CoQA: Набор данных для диалоговых ответов на вопросы, который тестирует модели на многоходовых диалогах.
MMDialog: Диалоговый бенчмарк, сосредоточенный на качестве диалога в различных сценариях.
OpenAssistant: бенчмарк для разговорного ИИ, который оценивает способность модели вести естественные беседы.
Хотя бенчмарки предоставляют стандартизированные критерии оценки, они часто не способны уловить нюансы человеческого взаимодействия, такие как эмоциональный интеллект, ход беседы и чувствительность к контексту. Например, ответ может быть фактически корректным согласно бенчмарку, но при этом уступать с точки зрения естественности или эмпатии — ключевых элементов, которые люди ценят в реальных разговорах. Кроме того, бенчмарки не всегда могут отражать сложность человеческих предпочтений, которые могут варьироваться в зависимости от контекста, намерения пользователя и эмоционального тона. Именно поэтому человеческая оценка остается "золотым стандартом" при оценивании разговорного ИИ, поскольку она учитывает человеческие предпочтения, которые бенчмарки часто упускают. Однако из-за высокой стоимости и ресурсоемкости человеческой оценки альтернативные методы, такие как оценка на основе интроспекции, могут рассматриваться как более масштабируемые варианты.
Оценка на основе интроспекции
Оценка на основе интроспекции сосредоточена на оценивании качества ответов, генерируемых моделью, и их согласованности с контекстом, стремясь измерить, насколько хорошо выходные данные модели соответствуют ожиданиям, заданным входными данными. Этот тип оценки можно разделить на две основные категории: Оценка на основе генерации и Оценка на основе извлечения. Ниже приведены некоторые примеры соответствующих метрик:
Оценка на основе генерации
Достоверность (Groundedness): Эта метрика измеряет фактическую согласованность сгенерированного ответа с заданным контекстом. Если модель генерирует утверждения, которые не могут быть подтверждены извлеченным контекстом, такие утверждения штрафуются. Достоверность гарантирует, что выходные данные модели одновременно согласованы и основаны на предоставленной информации.
Релевантность ответа: Эта метрика оценивает, насколько хорошо ответ напрямую отвечает на вопрос пользователя или соответствует заданному контексту. Высокорелевантный ответ будет одновременно точным и контекстуально уместным, предоставляя наиболее полезный ответ на запрос.
Оценка на основе извлечения
Релевантность контекста: Измеряет, насколько извлеченные документы или контексты релевантны запросу. В идеале извлеченный контекст должен содержать только информацию, необходимую для ответа на вопрос. Нерелевантная или лишняя информация может снизить качество сгенерированного ответа.
Полнота контекста: Эта метрика оценивает, насколько хорошо извлеченный контекст согласуется с эталонной истиной, часто используя аннотированные ответы в качестве ориентира. Она помогает оценить, были ли релевантные документы извлечены изначально, гарантируя, что у модели достаточно информации для генерации осмысленного ответа.
Для метрик Достоверности, Релевантности ответа и Релевантности контекста отсутствие эталонной истины создает проблему для прямой оценки. Однако при отсутствии эталонной истины альтернативным методом является использование LLM-as-a-Judge. Сильная LLM может использоваться для оценки этих аспектов путем анализа связности, релевантности и фактической обоснованности ответа. Сравнивая сгенерированные ответы с собственным пониманием контекста и релевантности, модель может предоставлять автоматизированную оценку.
Проблемы и ограничения LLM-as-a-Judge
Хотя использование LLM-as-a-Judge может быть полезной альтернативой для оценки метрик, когда эталонная истина недоступна, этот подход создает определенные проблемы и ограничения, которые необходимо учитывать. Сама оценивающая модель может вносить предвзятости, которые могут влиять на качество и справедливость оценки. Ниже приведены некоторые распространенные предвзятости и проблемы, которые необходимо учитывать.
Позиционная предвзятость
Смещение позиции означает склонность оценивающей модели отдавать предпочтение ответам на основе их позиции в ранжировании или порядка, в котором они появляются. Во многих случаях модель может предполагать, что первый или верхний в рейтинге ответ более релевантен или точен, независимо от его фактического качества. Это может приводить к неточным оценкам, особенно в случаях, когда правильный ответ оказывается ниже в рейтинге из-за смещения модели в пользу верхних позиций.
Figure 3: Position Bias
Рисунок 3: Смещение позиции (Источник)
Смещение многословности
Смещение многословности возникает, когда оценивающая модель склонна отдавать предпочтение более длинным, более подробным ответам, даже если они не обязательно более точны или релевантны. В некоторых случаях модель может ошибочно приравнивать многословность к качеству, присваивая более высокие оценки длинным ответам, содержащим ненужную информацию. Это может исказить процесс оценки, особенно в контекстах, где более желательны краткие, ясные ответы.
Figure 4: Verbosity Bias
Рисунок 4: Смещение многословности (Источник)
Ошибочное суждение
Еще одно ограничение — возможность ошибочных суждений. LLM-as-a-Judge, как и любая модель, может ошибаться при оценке качества или релевантности ответа. Например, она может неправильно интерпретировать контекст, упускать тонкие детали или не распознавать нюансы в ответе, что приводит к неверным или вводящим в заблуждение результатам оценки
Figure 5: Wrong Judgement
Рисунок 5: Ошибочное суждение (Источник)
Ошибочное суждение с Chain-of-Thought
Рассуждение Chain-of-Thought (CoT) в оценке на основе LLM вводит сложные механизмы распространения ошибок, которые могут существенно снижать точность оценки. Каждый промежуточный шаг рассуждения выступает потенциальной точкой отказа, где даже незначительное неправильное толкование или логическая несогласованность могут перерасти во все более существенные ошибки в итоговом суждении. Например, если ранний шаг в цепочке рассуждений неверно понимает ключевой контекстуальный нюанс или неправильно взвешивает определенный аспект ответа, последующие шаги рассуждения будут строиться на этой ошибочной основе, экспоненциально усиливая первоначальную ошибку.
Figure 6: Wrong Judgement with Chain-of-thought
Рисунок 6: Ошибочное суждение с Chain-of-thought (Источник)
Эти смещения подчеркивают важность применения стратегий оценки, которые учитывают ограничения подходов LLM-as-a-Judge. Одно из решений — использовать модели LLM, специально дообученные для целей оценки, такие как GroundedAI или Flow-Judge-v0.1. Другая стратегия — по возможности сочетать оценки LLM-as-a-Judge с человеческой оценкой. Люди-оценщики привносят нюансированное понимание и контекстуальную осведомленность, которых может не хватать автоматизированным моделям. Регулярный аудит и итеративные улучшения оценивающих моделей также необходимы для минимизации смещений и повышения надежности.
Фреймворки оценки с открытым исходным кодом
В дополнение к техникам LLM-as-a-Judge, на рынке широко используется несколько фреймворков оценки с открытым исходным кодом для оценки приложений RAG. Эти фреймворки предоставляют структурированные методологии и инструменты для эффективной оценки производительности извлечения и генерации:
RAGAS: фреймворк для оценки систем RAG с метриками, адаптированными для приложений RAG.
DeepEval: Гибкий и надежный инструмент для оценки RAG или систем дообучения по нескольким оценочным метрикам.
ARES: Разработан для оценки моделей RAG с акцентом на релевантность контекста, достоверность ответа и релевантность ответа.
HuggingFace Lighteval: Предоставляет легковесные, расширяемые инструменты для оценки RAG-приложений в различных бэкендах (например, transformers, tgi, vllm или nanotron).
Эти фреймворки упрощают процесс оценки и помогают стандартизировать метрики производительности в разных системах, способствуя сопоставимости и улучшению.
Заключение
Retrieval-Augmented Generation (RAG) — это преобразующий подход к расширению возможностей больших языковых моделей (LLMs). Однако его успех зависит от надежной оценки и постоянного совершенствования. Как подчеркнул Stefan на вебинаре, конвейер RAG сложен и включает несколько этапов — от преобразования запроса до генерации финального ответа. Проблемы существенны — от снижения предвзятости в оценках LLM-as-a-Judge до обеспечения точного поиска и генерации ответов, соответствующих ожиданиям пользователей.
Главный вывод заключается в том, что не существует универсального решения для оценки RAG. Для достижения успеха требуется тонкий, многоаспектный подход, сочетающий различные методы оценки: бенчмарки на основе задач, интроспективные метрики, open-source фреймворки оценки и — когда это возможно — человеческую оценку. Такие инструменты, как RAGAS, DeepEval и ARES, оказывают ценную поддержку, но не являются окончательными ответами. Скорее, они представляют собой развивающиеся инструменты в постоянно продвигающейся области генеративного ИИ.
Заглядывая вперед, будущее RAG заключается в его адаптивности и непрерывном совершенствовании. По мере того как системы ИИ становятся более сложными, способность оценивать и улучшать их производительность будет необходима для раскрытия их полного потенциала. Устраняя текущие ограничения и внедряя инновационные методы оценки, RAG-приложения смогут стабильно предоставлять точную, контекстуально релевантную и заслуживающую доверия информацию, способствуя прогрессу в области ИИ.
Дополнительное чтение
Читать далее
Stop Building AI Data Infra for the Wrong Stage
Learn how AI data infrastructure should evolve from prototype to enterprise scale, and when Vector Lakebase becomes the right architecture for AI apps.
Introducing Customer-Managed Encryption Keys (CMEK) on Zilliz Cloud
We're announcing the general availability of Customer-Managed Encryption Keys (CMEK) on Zilliz Cloud.
Smarter Autoscaling in Zilliz Cloud: Always Optimized for Every Workload
With the latest upgrade, Zilliz Cloud introduces smarter autoscaling—a fully automated, more streamlined, elastic resource management system.