2023 Обзор старых статей: руководство по процессу построения и оценки системы RAG

Расширенная генерация поиска (RAG) становится одним из самых популярных применений больших языковых моделей (LLM) и векторных баз данных. RAG создается путем извлечения данных из векторных баз данных, таких как WeaviateПриложения RAG широко используются в чат-ботах и системах вопросов и ответов.

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

1. индексирование
2. получить (данные)
3. создание

Оценка RAG является сложной задачей из-за сложности взаимодействия между этими компонентами и трудности сбора тестовых данных. В данной статье будет продемонстрировано интересное развитие в использовании LLM для оценки и текущее состояние компонентов RAG.

в двух словах: Мы вдохновлены сотрудничеством с Рагас Диалог между Джитином Джеймсом и Шаухулом Эсом, создателями Эти диалоги, написанные Рагас и новые разработки в области LLM по оценке RAG-систем, впервые предложенные ARES, заставили нас задуматься о существующих метриках и оценить настраиваемые параметры RAG. В ходе нашего исследования мы рассмотрели возможные формы экспериментального программного обеспечения для отслеживания RAG и уточнили, чем RAG-системы отличаются от Agent-систем и как они оцениваются.

Наши записи в блоге содержат следующие пять основных разделов:

• Оценка LLM: Новые тенденции в оценке производительности RAG с помощью LLM, включая нулевые выборки, малое количество выборок и точную настройку размера оценщика LLM.
• Показатели RAG: Общие метрики, используемые для оценки генерации, поиска и индексации, а также их взаимодействия.
• Параметры настройки для RAG: Какие решения влияют на работу системы RAG существенно по-разному?
• составление расписания: Как управлять отслеживанием конфигурации эксперимента для системы RAG?
• От RAG к оценке агента: Мы определяем RAG как трехэтапный процесс индексирования, поиска и генерации. В этом разделе описывается, когда система RAG трансформируется в систему Agent и как оценить их различия.

Оценка LLM

Давайте начнем с самой новой и самой захватывающей части - оценки LLM! История машинного обучения в значительной степени зависела от ручного аннотирования данных, например, определения того, является ли отзыв на Yelp положительным или отрицательным, или релевантна ли статья запросу "Кто главный тренер Boston Celtics?". LLM постепенно становится все более эффективным в аннотировании данных с меньшими затратами ручного труда. Это ключевая **"новая тенденция "**, которая ускоряет рост приложений RAG.

оставить (кому-л.) Рагас Наиболее распространенной техникой, впервые примененной в таких фреймворках, как Zero Sample LLM Evaluation, является Zero Sample LLM Evaluation. Оценка LLM с нулевой выборкой включает в себя запрос большой языковой модели с шаблонами, такими как "Пожалуйста, оцените релевантность этих результатов поиска по шкале от 1 до 10. Запрос - {query}, а результаты поиска - {search_results}". На следующем рисунке показано, как LLM может быть использована для оценки производительности системы RAG.

При оценке LLM с нулевой выборкой есть три основные возможности настройки: 1. расчетные метрики, такие как precision, recall или nDCG, 2. конкретный язык этих подсказок и 3. языковая модель, используемая для оценки, например, GPT-4, Coral, Llama-2, Mistral и так далее. Основной проблемой на данный момент является стоимость использования LLM для оценки. Например, оценка 10 результатов поиска с помощью GPT-4 (при условии, что на каждый результат приходится 500 лексем, плюс 100 лексем на запрос и команду, итого около 6000 лексем) обойдется примерно в 1000 долларов за один результат. Токен 0,005, или 3 доллара за оценку 100 запросов.

Поскольку такие фреймворки, как Ragas, продвигают оценку LLM с нулевой выборкой, люди начинают сомневаться в необходимости оценки LLM с меньшей выборкой. Поскольку оценка LLM с нулевой выборкой "достаточно хороша", ее может быть достаточно, чтобы служить в качестве Северной звезды для настройки системы RAG. Как показано на рисунке ниже, оценка RAGAS состоит из четырех подсказок LLM с нулевой выборкой для каждой из двух генерируемых метрик:Верность ответить пением Релевантность ответа (Релевантность ответа), а также два показателя поиска:Контекстная точность (Контекстная точность) ответить пением Контекстный вызов (Context Recall).

 источник (информации и т.д.)

Переход от оценки LLM с нулевой выборкой к оценке с меньшей выборкой прост. Мы включили в шаблоны инструкций аннотированные примеры релевантности результатов поиска запросу, что также известно как контекстное обучение. Открытие этой техники стало одним из ключевых прорывов GPT-3.

Например, добавление в пример 5 ручных оценок релевантности добавит 30 000 жетонов к запросу. При тех же затратах, что и выше, мы оцениваем увеличение цены с 3 до 15 долларов за 100 запросов. Обратите внимание, что это простой пример оценки и не основан на реальной модели ценообразования для LLM. Важно учитывать, что добавление примеров меньшего объема может потребовать более длинных контекстных моделей, которые обычно устанавливают цену выше LLM для небольших вводимых данных.

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

существовать ARES: В автоматизированной системе оценки генеративных систем с расширенным поиском Саад-Фалкон и др. обнаружили, что обучение собственного оценщика LLM может превзойти использование подсказок с нулевой выборкой. Изначально ARES требует три входных данных: коллекцию абзацев из целевого корпуса, 150 или более точек проверки человеческих предпочтений и 5 недовыборочных примеров запросов в домене. ARES использует эти недовыборочные примеры для генерации большого количества синтетических данных запросов, отфильтрованных по принципу соответствия циклу: т. е. при поиске по синтетическому запросу можно ли получить документ, который породил синтетический запрос? . Затем ARES генерирует данные для контекстуальная значимость, иПодлинность ответов ответить пением Актуальность ответов Тонкая настройка легких классификаторов.

Авторская экспериментальная доработка DeBERTa-v3-largeМодель содержит более экономичные 437 миллионов параметров, при этом каждая головка классификатора использует базовую языковую модель, что в сумме дает три головки классификации. В результате разделения синтетических данных на обучающий и тестовый наборы, оценка системы ARES показала, что точно настроенная модель значительно превосходит GPT-3.5-turbo-16k с нулевой и малой выборкой. Более подробную информацию (например, инновационное использование доверительных интервалов в прогнозировании (PPI) и детали экспериментов) см. Саад-Фалкон и др.Диссертация.

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

Показатели RAG

Мы представляем метрики RAG с точки зрения верхнего уровня генерации, поиска и индексирования. Затем мы представляем параметры настройки RAG с точки зрения нижнего уровня построения индексов, настройки методов поиска и вариантов генерации.

Другая причина представления метрик RAG с точки зрения верхнего уровня заключается в том, что ошибки индексирования передаются поиску и генерации, но ошибки генерации (например, определяемые нами уровни) не влияют на ошибки индексирования. В современном состоянии оценки RAG редко проводится сквозная оценка стека RAG, и часто предполагается, что контекст оракула возможно термин "контролируемая интерференция" (CIT)(например, эксперимент Lost in the Middle) для определения правдивости и релевантности ответов. Аналогично, вкрапления обычно оцениваются с помощью индекса жестокости, который не учитывает ошибку приблизительного ближайшего соседа. Ошибка приблизительного ближайшего соседа обычно измеряется путем нахождения оптимальной точки точности с точки зрения компромисса между запросом в секунду и отзывом, причем отзыв ANN - это истинные ближайшие соседи запроса, а не документы, помеченные как "релевантные" запросу.

Формирование индикаторов

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

Рагас Для оценки эффективности результатов моделирования большого языка (LLM) введены два показателя: правдоподобность и релевантность ответа.степень доверия Оцените фактическую точность ответов на основе найденного контекста.Актуальность ответов Определите релевантность ответа на вопрос. Ответы могут иметь высокие баллы достоверности, но низкие баллы релевантности ответа. Например, правдоподобный ответ может напрямую повторять контекст, но это приводит к низкой релевантности ответа. Оценка релевантности ответа снижается, если ответ не является полным или содержит дублирующую информацию.

В 2020 году компания Google выпустила МинаЦель Мины - показать, что она может проводить Разумные и конкретные диалога. Для оценки эффективности чат-ботов в открытом домене они ввели метрику оценки Sensibleness and Specificity Average (SSA). Обоснованность ответа бота должна иметь смысл в контексте и быть конкретной (Specificity Average). Это гарантирует, что ответ будет полным и однозначным.2020 Для этого необходимо, чтобы человек общался с чатботом и вручную оценивал его.

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

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

Извлечение индикаторов

Следующий уровень стека оценки - поиск информации. Оценка истории поиска требует от человека аннотации документов, релевантных запросу. Таким образом, чтобы создать аннотацию к 1 запросу, нам может потребоваться аннотировать релевантность 100 документов. Это уже чрезвычайно сложная задача для общих поисковых запросов, и проблема еще более усугубляется при создании поисковых систем, ориентированных на конкретную область (например, юридические контракты, истории болезни пациентов и т. д.).

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

После того как набор данных готов, можно использовать три показателя, которые обычно используются при оценке: nDCG , иОтзыв ответить пением Точность NDCG (Normalised Discount Cumulative Gain) измеряет рейтинг по нескольким тегам релевантности. Например, документ о витамине B12 может не быть самым релевантным результатом для запроса о витамине D, но быть более релевантным, чем документ о Boston Celtics. Из-за дополнительной сложности относительного ранжирования часто используются бинарные метки релевантности (1 - релевантный и 0 - нерелевантный). Recall измеряет количество положительных примеров в результатах поиска, а Precision - долю результатов поиска, которые были помечены как релевантные.

Таким образом, Большая языковая модель может вычислить точность с помощью следующего запроса: "Сколько из следующих результатов поиска относятся к запросу {запрос}? {search_results}". Прокси для Recall также можно получить из подсказки Большой языковой модели: "Содержат ли эти результаты поиска всю информацию, необходимую для ответа на запрос {запрос}? {search_results}". Мы также рекомендуем читателю ознакомиться с некоторыми подсказками в Рагасе здесь (литературный).

Еще одна метрика, которую стоит изучить, - это LLM Wins, где запрос Big Language Modelling звучит так: "На основании запроса {query}, какой набор результатов поиска более релевантен? Набор A {Set_A} или Набор B {Set_B}". Очень важно! Пожалуйста, ограничьте выдачу до 'Set A' или 'Set B'".

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

Индексируемые показатели

Опытные пользователи, знакомые с Weaviate, могут знать, что Контрольные показатели ANNБенчмаркинг-тест вдохновил Разработка API gRPC в Weaviate версии 1.19Эталон ANN измеряет количество запросов в секунду (QPS) в сравнении с показателем Recall и учитывает такие детали, как ограничение работы одного потока. В то время как базы данных обычно оцениваются по времени ожидания и стоимости хранения, индексы случайных векторов в большей степени ориентированы на показатели точности. В отличие от Приближенные вычисления в операторах SQL select Примерно то же самое, но мы предсказываем, что ошибкам, вызванным аппроксимациями, будет уделяться больше внимания по мере роста популярности векторной индексации.

Точность измеряется через Recall. В векторном индексировании recall - это отношение числа истинных ближайших соседей, возвращенных алгоритмом приблизительного индексирования, к числу ближайших соседей, определенных методом перебора. Это аналогично информационному поиску (Information Поиск) отличается от типичного использования термина "recall", который обозначает долю релевантных документов, извлеченных из всех релевантных документов. Оба показателя обычно измеряются с помощью соответствующего параметра @K.

В контексте полного стека RAG возникает интересный вопрос:Когда ошибки точности ANN приводят к ошибкам в информационном поиске (IR)? Например, мы можем достичь 1 000 QPS с отзывом 80% или 500 QPS с отзывом 95%, но как это отразится на метриках поиска, упомянутых выше (например, на результатах поиска по отзыву nDCG или Large Language Modelling (LLM))?

Резюме по индикаторам RAG

В итоге мы показали метрики для оценки индексирования, поиска и генерации:

• создание: верность и релевантность ответов, а также эволюция от таких метрик, как масштабное обнаружение галлюцинаций (например, Rationality and Specificity Average, Sensibleness and Specificity Average, SSA).
• получить (данные): Новые возможности для сравнения контекстуальной точности и контекстуального отзыва в оценке LLM, а также обзор человеческой аннотации для измерения отзыва, точности и nDCG.
• индексированиеRecall измеряется количеством истинных ближайших соседей, найденных алгоритмом векторного поиска. Мы считаем, что ключевым вопросом здесь является:Когда ошибки ANN перерастают в ошибки IR?

Все компоненты, как правило, могут быть проданы между производительностью и задержкой или стоимостью. Используя более дорогую языковую модель, мы можем получить более высокое качество генерации; фильтруя результаты с помощью реордера, мы можем получить более высокое качество извлечения; используя больше памяти, мы можем получить более высокое качество индексирования. Как управлять этими компромиссами для повышения производительности, станет ясно по мере того, как мы будем продолжать исследовать "ручки RAG". В заключение отметим, что мы решили представить метрики сверху вниз, от генерации до поиска и индексации, поскольку время оценки ближе к пользовательскому опыту. Мы также представим ручки настройки снизу вверх, от индексации к поиску и генерации, поскольку это больше похоже на опыт разработчика приложений RAG.

Параметры настройки RAG

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

Параметры настройки индекса

Наиболее важным параметром настройки индексации при проектировании системы RAG является настройка сжатия вектора, представленная в Weaviate 1.18 в марте 2023 года как Product Quantization (PQ), алгоритм сжатия вектора, который группирует последовательные фрагменты векторов, объединяет значения в кластеры и снижает точность по центру масс. Например, для представления непрерывного фрагмента из четырех 32-битных чисел с плавающей точкой требуется 16 байт, в то время как фрагмент длиной 4 с восемью центрами масс занимает всего 1 байт, обеспечивая коэффициент сжатия памяти 16:1. Последние достижения в области переупорядочивания PQ значительно снизили потери припоминания из-за сжатия, однако при очень высоких уровнях сжатия его все же следует рассматривать с осторожностью.

Далее используется индекс маршрутизации. Для наборов данных, содержащих менее 10 тыс. векторов, приложения RAG могут удовлетвориться индексацией методом грубой силы. Однако с увеличением количества векторов задержка при индексировании грубой силой становится намного выше, чем при индексировании на основе алгоритмов Proximity Graph, таких как HNSW. Как описано в метриках RAG, производительность HNSW обычно измеряется оптимальной точкой Парето, в которой соотносятся количество запросов в секунду и запоминание. Это достигается путем изменения размера очереди поиска, используемой для вывода. ef чтобы это произошло. Крупнее ef будет выполнять больше сравнений расстояний в процессе поиска, что значительно замедляет его, но дает более точные результаты. Следующие параметры включают в себя параметры, используемые при построении индекса, такие как efConstruction (размер очереди при вставке данных в граф) и maxConnections (количество ребер на узел, хранится вместе с каждым вектором).

Еще одно новое направление, которое мы исследуем, - это влияние смещения распределения на центр масс PQ и взаимосвязь с гибридными алгоритмами кластеризации и индексирования графов, такими как DiskANN возможно IVFOADC+G+P) взаимодействия. Использование метрики recall может быть достаточным для определения необходимости повторной подгонки центра масс, но остается вопрос, какое подмножество векторов использовать для подгонки. Если мы используем самые последние 100 тыс. векторов, которые вызывают падение запоминания, то мы можем оказаться переборщившими с подгонкой под новое распределение, поэтому нам может понадобиться выборка из смеси временных интервалов распределения данных. Эта тема тесно связана с нашим пунктом о непрерывной оптимизации моделей глубокого обучения и может быть рассмотрена далее в разделе "Регулярная оптимизация".

Разбивка данных на части - важный этап перед вставкой данных в Weaviate. В результате разбивки длинные документы преобразуются в более мелкие части. Это улучшает поиск, поскольку каждый фрагмент содержит важную информацию и помогает оставаться в пределах ограничений на количество токенов в Большой языковой модели (LLM). Существует несколько стратегий разбора документов. На рисунке выше показан пример разбора научной статьи на основе ее названия. Например, чанк 1 - это аннотация, чанк 2 - введение и так далее. Существуют также способы объединения фрагментов и создания наложений. К ним относится скользящее окно, которое берет токен из предыдущего блока и использует его в качестве начала следующего блока. Небольшое перекрытие блоков улучшает поиск, поскольку ретривер способен понять предыдущий контекст/блок. На следующем рисунке показана высокоуровневая схема фрагментированного текста.

получить (данные)

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

Большинство разработчиков RAG, скорее всего, сразу же согласятся с используемой моделью встраивания, например, OpenAI, Cohere, Voyager, Jina AI, Sentence Transformers и многие другие варианты! Разработчикам также необходимо учитывать размерность модели и ее влияние на сжатие PQ.

Следующее ключевое решение - как настроить весовые коэффициенты агрегирования для разреженных и плотных методов поиска в гибридном поиске. Веса основаны на параметре alpha.alpha 0 - чистый bm25 Поиск.alpha равным 1, является чистым векторным поиском. Поэтому, задавая alpha Зависит от ваших данных и приложения.

Еще одним новым направлением является эффективность моделей с нулевой выборкой. В настоящее время Weaviate предлагает 2 Модель переупорядочивания Коэра::rerank-english-v2.0 ответить пением rerank-multilingual-v2.0. Как следует из названия, эти модели различаются в первую очередь используемыми обучающими данными и полученными в результате многоязычными возможностями. В будущем мы планируем предоставить больше возможностей для выбора модели, что подразумевает компромисс между производительностью и задержкой, который может иметь смысл для одних приложений, но не для других. В процессе настройки параметров поиска было непросто определить, какой тип способного реордера необходим и сколько результатов поиска нужно реордерировать. Это также одна из самых простых точек входа для тонкой настройки пользовательских моделей в стеке RAG, о чем мы поговорим далее в разделе "Оптимизация регуляторов".

Еще один интересный параметр настройки - многоиндексный поиск. Как и в случае с разбивкой на части, это предполагает структурные изменения в базе данных. Общий вопрос заключается в следующем:В каких случаях вместо фильтра следует использовать отдельный сбор? должен передать blogs ответить пением documentation на два набора, или хранить их вместе в коллекции с source атрибут Document В категории?

Использование фильтров позволяет быстро проверить полезность этих меток, поскольку мы можем добавить несколько меток в каждый блок, а затем проанализировать, как классификатор использует их. Существует ряд интересных идей, например, явное указание источника контекста в контекстном вводе для LLM, например, "Ниже приведены результаты поиска по блогам {search_results}. Здесь представлены результаты поиска по документам {documentation}". Поскольку LLM может обрабатывать более длинные входные данные, мы ожидаем, что объединение контекста из нескольких источников данных станет более распространенным, поэтому появляется еще один важный гиперпараметр: сколько документов извлекается из каждого индекса или фильтра.

создание

Первое, на чем следует сосредоточиться при генерации, - это выбор большой языковой модели (Large Language Model, LLM). Например, вы можете выбрать модели от OpenAI, Cohere, Facebook и многих вариантов с открытым исходным кодом. Многие LLM-фреймворки (например. LangChain, иLlamaIndex ответить пением Модуль генератора Weaviate) предлагает легкую интеграцию с различными моделями, что является большим плюсом. Выбор модели может зависеть от таких факторов, как необходимость сохранения конфиденциальности данных, стоимость, ресурсы и т. д.

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

Длинные контекстные модели (Long Context Models, LCMs) - это новое направление при выборе LLM для вашего приложения. Улучшает ли добавление большего количества результатов поиска в качестве входных данных качество ответа? Исследование эксперимента "Затерянные посередине" поднимает некоторые тревожные сигналы. На сайте "Затерянные в середине" В ней исследователи из Стэнфорда, Калифорнийского университета в Беркли и Samaya AI провели контролируемые эксперименты, показавшие, что если релевантная информация размещена в середине результата поиска, а не в начале или конце, то языковая модель может не успеть интегрировать ее при формировании ответа. В другой работе, подготовленной исследователями из Google DeepMind, Toyota и Университета Пердью, отмечается:"Большие языковые модели легко отвлекаются на нерелевантный контекст".. Несмотря на потенциал этого направления, на момент написания этой статьи длинный контекст RAG все еще находится на ранней стадии развития. К счастью, такие метрики, как Ragas scores, могут помочь нам быстро протестировать новые системы!

Подобно недавним открытиям в области оценки LLM, о которых мы говорили ранее, генеративный аспект настройки делится на три этапа: 1. Настройка подсказки, 2. Несколько примеров и 3. Тонкая настройка. Настройка подсказок включает в себя адаптацию конкретных лингвистических выражений, таких как "Пожалуйста, ответьте на вопрос, основываясь на предоставленных результатах поиска." против "Пожалуйста, ответьте на вопрос. Важно, пожалуйста, внимательно следуйте приведенным ниже инструкциям. Ваш ответ на вопрос должен быть основан только на предоставленных результатах поиска!!!". Разница между.

Как упоминалось ранее, под образцом понимается набор пар вопросов, контекстов и ответов, составленных вручную, на основе которых создается языковая модель. Недавние исследования (например. "Вектор контекста") еще раз доказывает важность такого бутстрапинга потенциального пространства. В проекте Weaviate Gorilla мы использовали GPT-3.5-turbo для генерации запросов Weaviate, и когда мы добавили естественный язык к переводу запросов в меньшем количестве примеров, производительность значительно возросла.

Наконец, все больше внимания уделяется тонкой настройке LLM для приложений RAG. Вот несколько подходов, которые следует рассмотреть. Возвращаясь к обсуждению оценки LLM, мы можем захотеть сгенерировать обучающие данные, используя более надежный LLM, чтобы построить меньшую, более доступную модель, принадлежащую нам самим. Другая идея заключается в предоставлении человеческой аннотации качества ответов, чтобы LLM можно было точно настроить с помощью следующих команд. Если вас интересует точная настройка модели, ознакомьтесь с материалом Брева о том, как использовать библиотеку HuggingFace PEFT на сайте учебники.

Краткое описание вариантов настройки RAG

Итак, мы описали основные возможности настройки, доступные в системе RAG:

• Индексирование: на самом высоком уровне нам нужно рассмотреть, когда использовать только поиск методом грубой силы, а когда внедрить ANN-индексирование. Это особенно интересно при настройке многопользовательских кейсов с новыми и сильными пользователями. В ANN-индексации у нас есть гиперпараметры для PQ (фрагментация, центр масс и пределы обучения). hNSW включает (ef, efConstruction и maxConnections).
• Поиск: выбор модели встраивания, настройка весов гибридного поиска, выбор реордера и разбиение коллекции на несколько индексов.
• Генерирование: выберите LLM и решите, когда перейти от настройки подсказок к примерам с меньшим количеством образцов или тонкой настройке.

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

составление расписания

Учитывая последние достижения в области оценки больших языковых моделей (Large Language Model, LLM) и обзор некоторых настраиваемых параметров, появляется интересная возможность объединить все это с системой отслеживания экспериментов. Например, простой оркестратор с интуитивно понятным API мог бы использоваться для выполнения следующих действий: 1. запрос полного тестирования 5 LLM, 2 встроенных моделей и 5 конфигураций индексирования; 2. запуск экспериментов; 3. возвращение высококачественного отчета пользователю.Weights & Biases проложила замечательный путь отслеживания экспериментов для обучения моделей глубокого обучения. Мы ожидаем, что интерес к экспериментальной поддержке RAG с настраиваемыми параметрами и метриками, описанными в этой статье, будет быстро расти.

Мы придерживаемся двух направлений развития в этой области. С одной стороны, существующие LLM с нулевой выборкой (например, GPT-4, Command, Claude, а также варианты с открытым исходным кодом Llama-2 и Mistral) не столь эффективны, чтобы иметь контекст оракула В то время он показал неплохие результаты. Так что у нас есть огромная возможность Сосредоточьтесь на поисковой части . Это требует поиска компромисса между ошибками ANN, встроенными моделями, гибридными весами поиска и перестановкой PQ или HNSW в нескольких конфигурациях, как описано ранее в этой статье.

В Weaviate 1.22 появились асинхронные индексы и соответствующие API состояния узлов. Мы надеемся, что благодаря партнерским отношениям, направленным на оценку RAG и настройку оркестровки, они смогут определять время завершения построения индексов и запускать тесты. Это особенно интересно при настройке интерфейсов оркестрации для каждого арендатора на основе этих состояний узлов, где одни арендаторы могут полагаться на поиск методом грубой силы, а другим необходимо найти правильную модель встраивания и конфигурацию HNSW для своих данных.

Кроме того, мы можем захотеть ускорить тестирование, распараллелив распределение ресурсов. Например, одновременная оценка 4 моделей встраивания. Как упоминалось ранее, еще одной интересной частью является настройка чанков или других символических метаданных, которые могут поступать от импортера данных. Например, набор данных Weaviate Verba содержит 3 папки Weaviate's Blogs, иDocumentation ответить пением Video Расшифровка. Если мы хотим сравнить размеры чанков 100 и 300, нет необходимости повторно вызывать веб-краулер. Нам может понадобиться другой формат, либо данные, хранящиеся в ведрах хранилища S3 или иным способом, с соответствующими метаданными, но это более экономичный способ экспериментировать.

С другой стороны, мы имеем тонкую настройку модели и непрерывное обучение на основе градиента, а не вставку или обновление данных. Наиболее распространенными моделями, используемыми в RAG, являются встроенные модели, переупорядоченные модели и, конечно, LLM. Поддержание моделей машинного обучения в актуальном состоянии с учетом новых данных уже давно является предметом внимания фреймворков непрерывного обучения и оркестров MLops, которые управляют переобучением, тестированием и развертыванием новых моделей. Начиная с непрерывного обучения LLM, одним из главных преимуществ системы RAG является возможность продлить дату "отсечения" базы знаний LLM, чтобы она была синхронизирована с вашими данными. может ли LLM делать это напрямую? Мы считаем, что не совсем ясно, насколько хорошо непрерывное обучение взаимодействует с простым обновлением информации через RAG. В некоторых исследованиях (например, MEMIT) проводились эксперименты по анализу причинно-следственных связей при присвоении веса, в ходе которых такие факты, как "Леброн Джеймс играет в баскетбол", обновлялись до "Леброн Джеймс играет в футбол". " и так далее. Это довольно продвинутая техника, и другой возможностью может быть просто маркировка фрагментов, используемых в обучении (например, "Леброн Джеймс играет в баскетбол"), и их повторное обучение с использованием учебных данных с расширенным поиском, содержащих новую информацию. Это важная область, за которой мы внимательно следим.

Как упоминалось ранее, мы также рассматриваем возможность интегрировать этот тип непрерывной настройки непосредственно в Weaviate с помощью PQ-центроидов. Центроиды PQ для первых K векторов, впервые попадающих в Weaviate, могут быть подвержены значительным изменениям в распределении данных. Непрерывное обучение моделей машинного обучения страдает от печально известной проблемы "катастрофического забывания", когда обучение на последней партии данных ухудшает производительность на более ранних партиях. Это одно из соображений, которое мы учитывали при разработке обновления центра масс PQ.

От RAG к оценке агента

В этой статье мы сосредоточимся на RAG Вместо Агент Оценка. По нашему мнению.RAG определяется как процесс индексирования, поиска и генерации, а также как Агенты Область применения системы более открыта. На диаграмме ниже показано, как мы видим основные компоненты, такие как планирование, память и инструменты, которые в совокупности обеспечивают значительные возможности вашей системы, но в то же время усложняют ее оценку.

Обычно следующим шагом для приложений RAG является добавление расширенного механизма запросов. Читатели, которые впервые сталкиваются с этой концепцией, могут ознакомиться с нашими сериями статей LlamaIndex и Weaviate, в которых приводятся примеры кода на Python, как начать работу. Существует множество различных движков расширенных запросов, таких как движки запросов с подзапросами, SQL-маршрутизаторы, движки самокорректирующихся запросов и другие. Мы также рассматриваем возможные формы API promptToQuery или экстрактора поисковых запросов в модуле Weaviate. Каждый механизм запросов имеет свои преимущества в процессе поиска информации, поэтому давайте рассмотрим некоторые из них и способы их оценки.

Механизм многоходовых запросов (также известный какМеханизм запроса подвыпусков) идеально подходит для разбиения сложных проблем на подпроблемы. На диаграмме выше мы имеем запрос "Что такое Ref2Vec в Weaviate?" Чтобы ответить на этот вопрос, вам нужно знать, что такое Ref2Vec и Weaviate соответственно. Чтобы ответить на этот вопрос, необходимо знать, что такое Ref2Vec и Weaviate, соответственно. Поэтому для получения соответствующего контекста необходимо дважды обратиться к базе данных для обоих вопросов. Затем два ответа объединяются для получения одного результата. Оценка производительности механизма многоходовых запросов может быть проведена путем анализа подвопросов. Важно, чтобы LLM создавал релевантные подвопросы, точно отвечал на каждый вопрос и объединял два ответа для получения фактологически точного и релевантного результата. Кроме того, если вы задаете сложные вопросы, лучше всего использовать механизм многоходовых запросов.

Многоходовые задачи в первую очередь зависят от точности подвопросов. Мы могли бы использовать здесь аналогичную оценку LLM со следующей подсказкой: "Дан вопрос {запрос}. Система решила разбить его на подвопросы {sub_question_1} и {sub_question_2}. Имеет ли смысл такая декомпозиция вопроса?" Затем мы выполняем две отдельные оценки RAG для каждого подвопроса и оцениваем, может ли LLM объединить ответы на каждый вопрос, чтобы ответить на исходный вопрос.

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

Подводя итог обсуждению "От RAG к оценке агентов", мы считаем, что в настоящее время невозможно определить, каковы общие модели использования агентов. Мы намеренно показали многоходовые движки запросов и маршрутизаторы запросов, потому что их относительно легко понять. Как только мы добавим более открытые оценки, связанные с циклами планирования, использованием инструментов и тем, как оценить способность модели форматировать API-запросы инструментов, а также подсказки по управлению мета-внутренней памятью, такие как в MemGPT, будет сложно обеспечить общую абстракцию для оценки Агентов.

вынести вердикт

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