CoRAG: динамическое моделирование цепочек RAG с использованием MCTS (деревьев Монте-Карло)

Резюме основных вкладов CORAG

CORAG (ограничение по стоимости) Поиск Optimisation for Retrieval-Augmented Generation) - это инновационная система Retrieval Augmented Generation (RAG), разработанная для решения существующих RAG Ключевые проблемы методологии. Ниже перечислены основные вклады CORAG:

1. Всестороннее рассмотрение межблочных ассоциаций::
   • инновационный центр: CORAG - это первый фреймворк, который ввел оптимизацию порядка сочетания блоков в задаче RAG. В отличие от традиционных подходов, CORAG больше не рассматривает каждый текстовый блок независимо или рассматривает блоки только на уровне кластеризации, но вместо этого использует Поиск по дереву Монте-Карло (MCTS) для последовательного поиска оптимального порядка комбинаций блоков. Такой подход полностью отражает сложные ассоциации между блоками, позволяет избежать избыточной информации и гарантирует, что выбранные комбинации блоков полностью отвечают на запрос пользователя.
   • доминированиеТаким образом, CORAG может генерировать более точные и релевантные ответы, повышая качество генерации.
2. Решение проблемы немонотонности блочной полезности::
   • инновационный центрCORAG будет бюджетное ограничение интегрируется в процесс оптимизации портфеля блоков, а не рассматривает исчерпание бюджета как условие завершения. Этот подход учитывает полезность блока немонотонностьТо есть добавление большего количества блоков не всегда улучшает качество конечного результата.
   • доминирование: Динамически регулируя использование бюджета в процессе оптимизации, CORAG может избежать чрезмерного включения нерелевантных или избыточных блоков, тем самым повышая точность и релевантность генерируемых ответов.
3. Адаптация к различным областям запросов::
   • инновационный центрCORAG представил Настройка агентаАгент использует Сравнительное обучение для динамической адаптации конфигурации MCTS к различным областям запросов. Агент рекомендует оптимальный Модель ретранслятора ответить пением Конфигурация MCTS.
   • доминирование: Такой подход обеспечивает CORAG гибкость в обработке широкого спектра типов запросов, от простых запросов по ключевым словам до сложных проблем рассуждений, гарантируя высокое качество ответов в различных сценариях применения.
4. Эффективные и масштабируемые стратегии поиска::
   • инновационный центрCORAG использует MCTS для поиска узлов с техника параллельного расширения Ускоряет процесс поиска. Этот подход сокращает экспоненциальное пространство поиска до линейного и эффективно уравновешивает исследования ответить пением использовать.
   • доминированиеCORAG способен обрабатывать большие массивы данных, сохраняя при этом эффективность поиска и соблюдая баланс между вычислительными затратами и качеством поиска.
5. Значительный прирост производительности::
   • экспериментальная проверка: Экспериментальные результаты показывают, что CORAG превосходит существующие базовые методы на нескольких эталонных наборах данных, улучшая оценки ROUGE примерно на 30%. CORAG также отличается эффективностью, обеспечивая высокое качество ответов в условиях жестких ограничений по стоимости.

Пример рабочего процесса CORAG

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

Шаг 1: Ввод запроса пользователя

• импорт: Пользователь отправляет в систему CORAG запрос на естественном языке, например:

  "请解释光合作用的过程，并列出影响其效率的因素。"
  

• экспорт: Запрос передается в Модуль встраивания запросов Обработка.

Шаг 2: Генерация встраивания запросов

• импорт: Текст запроса пользователя.
• иметь дело с: Использование предварительно обученных Модели встраивания(например, BGE-M3) преобразует текст запроса в векторное представление.
• экспорт: Запрос вектора встраивания (например, 1024-мерного вектора).

  Query Embedding: [0.123, -0.456, 0.789, ..., -0.012]
  

Шаг 3: Настройка предсказания агента

• импорт: вектор вложения запроса [0.123, -0.456, 0.789, ..., -0.012].
• иметь дело с::
  1. извлечение признаков: Вектор встраивания поступает в Настройка агента (используется в форме номинального выражения) сеть кодирования Извлечение признаков выполняется в
  2. Предсказание ретранслятора: кодированное предсказание выходного сигнала сети для оптимального Модель ретранслятораНапример bge-reranker-large.
  3. Прогнозирование конфигурации MCTS: В то же время сеть кодирования предсказывает оптимальный MCTS Параметры конфигурациитакие как количество итераций, коэффициент стоимости и коэффициент исследования.
• экспорт::
  • Модель оптимального перестановщика::bge-reranker-large
  • Параметры конфигурации MCTS::
    • Количество итераций:: 15
    • фактор стоимости: 0.2
    • Фактор разведки: 2.5

  Optimal Reranker: bge-reranker-large
  MCTS Configuration:
  - Iterations: 15
  - Cost Coefficient: 0.2
  - Exploration Coefficient: 2.5
  

Шаг 4: Извлечение потенциальных текстовых блоков

• импорт::
  • Вектор встраивания запросов [0.123, -0.456, 0.789, ..., -0.012].
  • векторная база данных(например, содержащие предварительно сегментированные текстовые блоки и векторы их вложения).
• иметь дело с: Используйте вектор вложения запроса для Поиск сходстваизвлеките из базы данных векторов наиболее релевантные потенциальные текстовые блоки. Ниже приведены примеры первых пяти найденных текстовых блоков:Текстовый блок 1::

  光合作用是植物、藻类和某些细菌利用光能将二氧化碳和水转化为葡萄糖和氧气的过程。
  

  Текстовый блок 2::

  光合作用主要发生在植物叶片的叶绿体中，分为光反应和碳反应两个阶段。
  

  Текстовый блок 3::

  影响光合作用效率的因素包括光照强度、二氧化碳浓度、温度和水分供应等。
  

  Текстовый блок 4::

  光照强度对光合作用的影响呈正相关，但过强的光照会导致光抑制现象，降低光合作用效率。
  

  Текстовый блок 5::

  二氧化碳是光合作用的原料之一，其浓度直接影响光合作用的速率。
  

• экспорт: Список потенциальных текстовых блоков и их векторов встраивания.

  Retrieved Chunks:
  - Chunk 1: "光合作用是植物、藻类和某些细菌利用光能将二氧化碳和水转化为葡萄糖和氧气的过程。"
  - Chunk 2: "光合作用主要发生在植物叶片的叶绿体中，分为光反应和碳反应两个阶段。"
  - Chunk 3: "影响光合作用效率的因素包括光照强度、二氧化碳浓度、温度和水分供应等。"
  - Chunk 4: "光照强度对光合作用的影响呈正相关，但过强的光照会导致光抑制现象，降低光合作用效率。"
  - Chunk 5: "二氧化碳是光合作用的原料之一，其浓度直接影响光合作用的速率。"
  

Шаг 5: Поиск по дереву MCTS

• импорт::
  • Список потенциальных текстовых блоков::
    • Чанк 1: ...
    • Чанк 2: ...
    • Чанк 3: ...
    • Чанк 4: ...
    • Чанк 5: ...
  • Параметры конфигурации MCTS::
    • Количество итераций:: 15
    • фактор стоимости: 0.2
    • Фактор разведки: 2.5
  • Модель ретранслятора::bge-reranker-large
• иметь дело с::
  1. Инициализация корневого узла: Корневой узел представляет собой пустое состояние, когда ни один текстовый блок не выделен.
  2. Итеративное расширение::
     • опция: Использование Алгоритм UCB Выберите узел с наибольшей текущей полезностью. Например, для первой итерации выбирается чанк 3, поскольку он имеет наибольшую релевантность запросу.
     • удлинители: Сгенерируйте все возможные дочерние узлы (новые комбинации текстовых блоков). Например, дочерними узлами чанка 3 могут быть чанк 1, чанк 2, чанк 4 и чанк 5.
     • оценка: Использование Модель ретранслятора bge-reranker-large Параллельно оценивайте полезность всех новых комбинаций. Например, оцените полезность таких комбинаций, как Чанк 3 + Чанк 1, Чанк 3 + Чанк 2 и так далее.
     • обновление: Обновление полезности узла и количества доступов и распространение обновлений вверх.
  3. итерация: Повторяйте шаги выбора, расширения, оценки и обновления до тех пор, пока не будет достигнуто максимальное количество итераций (15).
  4. Условия расторжения договора: Достигнуто максимальное количество итераций.
• экспорт: Оптимальный порядок объединения текстовых блоков.

  Optimal Chunk Combination:
  - Chunk 3: "影响光合作用效率的因素包括光照强度、二氧化碳浓度、温度和水分供应等。"
  - Chunk 1: "光合作用是植物、藻类和某些细菌利用光能将二氧化碳和水转化为葡萄糖和氧气的过程。"
  - Chunk 2: "光合作用主要发生在植物叶片的叶绿体中，分为光反应和碳反应两个阶段。"
  

  принимать к сведению: Во время процесса MCTS CORAG динамически корректирует порядок комбинаций в соответствии с полезностью и, наконец, выбирает оптимальный порядок комбинаций.

Шаг 6: Создание окончательного ответа

• импорт::
  • Оптимальный порядок объединения текстовых блоков::
    • Часть 3: "Факторы, влияющие на эффективность фотосинтеза, включают интенсивность света, концентрацию углекислого газа, температуру и наличие воды".
    • Часть 1: "Фотосинтез - это процесс, в ходе которого растения, водоросли и некоторые бактерии используют энергию света для преобразования углекислого газа и воды в глюкозу и кислород".
    • Чанк 2: "Фотосинтез происходит в основном в хлоропластах листьев растений и делится на две фазы: реакцию света и реакцию углерода".
  • запрос пользователя:: "Объясните процесс фотосинтеза и перечислите факторы, влияющие на его эффективность".
• иметь дело с::
  1. Советы по строительству: Сочетание оптимального порядка объединения текстовых блоков с пользовательскими запросами для построения LLM подсказки ввода. Пример:

     用户查询：请解释光合作用的过程，并列出影响其效率的因素。
     相关信息：
     1. 影响光合作用效率的因素包括光照强度、二氧化碳浓度、温度和水分供应等。
     2. 光合作用是植物、藻类和某些细菌利用光能将二氧化碳和水转化为葡萄糖和氧气的过程。
     3. 光合作用主要发生在植物叶片的叶绿体中，分为光反应和碳反应两个阶段。
     

  2. Генерирование ответа: Использование LLM(например, Llama3) Сформируйте окончательный ответ на подсказку.
• экспорт: Окончательный ответ на естественном языке.

  Final Response:
  "光合作用是植物、藻类和某些细菌利用光能将二氧化碳和水转化为葡萄糖和氧气的过程。它主要发生在植物叶片的叶绿体中，分为光反应和碳反应两个阶段。影响光合作用效率的因素包括光照强度、二氧化碳浓度、温度和水分供应等。"
  

Шаг 7: Вывод ответа

• импорт: Окончательный ответ на естественном языке.
• иметь дело с: Представьте ответ пользователю.
• экспорт: В пользовательском интерфейсе отображается результат ответа.

резюме

На примере вышеприведенного рабочего процесса принцип работы CORAG можно кратко описать в виде следующих шагов:

1. Генерация встраивания запросов: Преобразование запроса пользователя в векторное представление.
2. Настройка предсказания агента: Предсказание оптимальной модели перегруппировки и параметров конфигурации MCTS.
3. Извлеките потенциальные текстовые блоки: Извлеките наиболее подходящий блок текста из базы данных векторов.
4. MCTS Поиск по дереву: Используйте MCTS для поиска оптимального порядка объединения текстовых блоков.
5. Создать окончательный ответ: Используйте LLM для создания окончательного ответа на основе оптимального сочетания текстовых блоков.
6. выходной сигнал: Представьте ответ пользователю.

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

оригинальный текст:: https://arxiv.org/pdf/2411.00744

Надпись:: CORAG: система оптимизации поиска с ограничениями по стоимости для генерации улучшений поиска

авторЗитинг Ванг, Хайтао Юань, Вэй Донг (Наньянский технологический университет), Гао Конг (Наньянский технологический университет), Фейфей Ли (Alibaba Group)

рефераты

Большие языковые модели (БЯМ) продемонстрировали отличные возможности в генеративных задачах, но зачастую трудно получить доступ к актуальной информации, что может привести к разочарованию. Генерация с расширением поиска (RAG) решает эту проблему путем интеграции знаний из внешних баз данных для получения более точных и релевантных ответов. Из-за ограничения контекстного окна в LLM нецелесообразно напрямую вводить в модель весь контекст внешней базы данных. Вместо этого выборочно извлекается только наиболее релевантная информация, т. е. "куски" (chunks). Однако современные исследования в области RAG сталкиваются с тремя ключевыми проблемами. Во-первых, существующие решения обычно выбирают каждый чанк независимо, игнорируя потенциальные ассоциации между ними. Во-вторых, на практике полезность фрагментов является "немонотонной", что означает, что добавление большего количества фрагментов может снизить общую полезность. Традиционные подходы делают акцент на максимизации количества включенных блоков, что может непреднамеренно ухудшить производительность. В-третьих, каждый тип пользовательского запроса обладает уникальными характеристиками, требующими индивидуальной обработки, что недостаточно учитывается в существующих решениях.

Для преодоления этих проблем мы предлагаем CORAG, систему оптимизации поиска с ограничениями по стоимости, для создания улучшений поиска. Мы используем стратегию поиска на основе дерева Монте-Карло (MCTS), чтобы последовательно находить оптимальные комбинации блоков, тем самым всесторонне учитывая ассоциации между блоками. Кроме того, вместо того чтобы рассматривать исчерпание бюджета как условие завершения, мы интегрируем бюджетные ограничения в процесс оптимизации комбинаций блоков, что эффективно решает проблему немонотонности полезности блоков. Кроме того, благодаря разработке конфигурационных агентов наша система предсказывает оптимальную конфигурацию для каждого типа запроса, что повышает адаптивность и эффективность. Экспериментальные результаты показывают, что производительность нашего фреймворка выросла до 301 TP3T по сравнению с базовой моделью, что подчеркивает эффективность, масштабируемость и применимость фреймворка для приложений с длинным контекстом.

PVLDB Reference Format.

Зитинг Ванг, Хайтао Юань, Вэй Дун, Гао Конг и Фейфей Ли. CORAG: система оптимизации поиска с ограничением затрат для генерации с расширением поиска. . pvldb, 14(1): xxx-xxx, 2020.
doi:XX.XX/XXX.XX

Рисунок 1: Пример порядка комбинирования блоков данных.

1 Введение

Хотя ЛЛМ продемонстрировали отличные способности в генеративных задачах, они часто сталкиваются с трудностями в получении актуальной информации, что может привести к галлюцинациям [10, 38]. Для решения этих проблем в качестве ключевого решения появился RAG. Интегрируя внешние источники данных в LLM, RAG может предоставить более точную, релевантную и актуальную информацию. В настоящее время RAG активно изучается в контексте LLM, особенно в задачах, требующих обновления внешних знаний, таких как задачи вопросов и ответов [2, 22, 29], поиск медицинской информации [1, 32] и анализ временных рядов [12, 26, 40]. Внешние источники данных обычно настолько велики, что подавать их непосредственно в LLM нецелесообразно. Для решения этой проблемы данные обычно разбиваются на непересекающиеся фрагменты и хранятся в векторной базе данных, а затем пользователь запрашивает наиболее полезные фрагменты, чтобы построить подсказки для LLM. Поэтому разработка эффективных и точных поисковых структур и алгоритмов для поиска наиболее релевантных фрагментов стала важной темой исследований и широко изучалась в сообществах баз данных [39, 48] и машинного обучения [2, 35, 43].

Однако существующие подходы сопряжены с тремя основными проблемами.

Задача 1: Связи между блоками. В настоящее время существует два основных подхода к определению наиболее релевантных блоков. Первый подход формулирует задачу как задачу приближенных k ближайших соседей (AKNN) [41, 45], где каждому блоку присваивается балл и выбираются приближенные k лучших блоков, ранжированных по баллу. Второй подход кластеризует блоки и возвращает все блоки в наиболее релевантном кластере в ответ на запрос [22, 29]. Однако оба метода игнорируют потенциальные ассоциации между блоками: первый метод полностью игнорирует ассоциации, а второй лишь поверхностно рассматривает все блоки в каждом кластере, считая их одинаково релевантными. В результате эти методы вносят существенную избыточность в выбранные блоки, когда несколько блоков передают схожую или избыточную информацию.

Например, как показано на рис. 1, при запросе высоты и истории Эйфелевой башни, если каждый блок рассматривается независимо, жадный метод выбирает блоки χ3 и χ1, поскольку они имеют первые два самых высоких балла. Однако эти два блока предоставляют только информацию об истории, чего недостаточно для полного ответа на запрос. Для лучшего ответа на запрос необходимо включить блоки, содержащие имя строителя, например χ4. С другой стороны, кластерный подход вернет все χ1, χ2, χ3 и χ4, что приведет к избыточности. Оптимальным решением будет выбор χ3 и χ4, поскольку они предоставляют необходимую информацию без избыточности. Кроме того, исследования [11, 19, 42] показали, что порядок блоков влияет на производительность LLM, и этот фактор также игнорируется существующими методами. Например, в случае Эйфелевой башни при выборе блоков χ3 и χ4 размещение χ4 на первой позиции дает более высокую оценку по сравнению с противоположным порядком. Однако определение оптимального порядка комбинаций блоков является сложной задачей, поскольку в обоих случаях пространство поиска растет экспоненциально с увеличением числа доступных блоков. В данной работе мы продемонстрировали, что эта задача является NP-трудной (см. раздел 2.1).

Задача 2: немонотонность полезности. Текущее решение основано на предположении, что включение большего количества блоков всегда дает лучший конечный результат. В частности, в подходе на основе AKNN каждый раз детерминированно выбирается ровно k блоков. В подходе, основанном на кластеризации, задается пороговое расстояние между кластерами и запросами, и возвращаются все кластеры в пределах этого порога. В обоих случаях возвращается как можно больше блоков. Однако на практике полезность блоков не является монотонной. Более конкретно, слишком большое количество блоков размывает ключевую информацию, добавляя связанное с краями содержимое, создавая шум, который снижает ясность. Кроме того, конфликты или тонкие различия между блоками могут запутать модель и снизить качество ответа. Например, как показано на рисунке 1, добавление блока χ1 снижает полезность при выборе χ3 и χ4, что подчеркивает тот факт, что на практике показатели полезности обычно не являются монотонными.

Задача 3: разнообразие запросов. Существуют различные типы пользовательских запросов, каждый из которых требует своей стратегии ранжирования, основанной на его уникальных характеристиках [47]. В современных системах RAG оценка полезности блока обычно определяется назначенной моделью реранжировщика. На сегодняшний день существуют различные модели реранжировщиков, но мы наблюдаем, что их производительность сильно варьируется в зависимости от типа запроса, и ни одна фиксированная модель реранжировщика не превосходит другие во всех вариантах запросов (подробнее см. эксперименты в разделе 6.3.4). Существующие подходы [20, 46] обычно опираются на статические модели реранжировщиков для ранжирования блоков и не обладают достаточной гибкостью для адаптации к различным контекстам запросов.

Постановка проблемы: Существует ли система RAG, которая в полной мере учитывает ассоциации между блоками и немонотонность коммунальных услуг и при этом способна удовлетворить все типы запросов?

1.1 Наш вклад

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

- Мы представляем первый фреймворк RAG, который учитывает порядок комбинаций блоков в задаче RAG. Вместо того чтобы рассматривать каждый блок отдельно или на уровне кластеризации, мы используем MCTS для последовательного поиска оптимального порядка сочетания блоков. Идея высокого уровня заключается в следующем: сначала мы инициализируем корневой узел. Затем, в ходе итераций, мы расширяем дерево, выбирая узел с наибольшей полезностью и вычисляя полезность узлов его расширения. После каждого расширения мы обновляем полезность во всем дереве политик. В этом процессе решение каждой итерации зависит от выбранных блоков, что позволяет нам полностью учесть ассоциации между блоками. Кроме того, MCTS сокращает экспоненциальное пространство поиска до линейного, и мы применяем технику параллельного расширения для дальнейшего повышения эффективности вычислений. С помощью этой разработки мы решаем задачу 1.
- В отличие от предыдущих схем RAG, в которых исчерпание бюджета рассматривается как условие завершения, мы предлагаем новую формулировку, в которой бюджетные ограничения интегрированы в процесс оптимизации комбинаций блоков, чтобы полностью учесть немонотонность полезности блоков, что позволяет решить задачу 2. Кроме того, отдавая приоритет высококоррелированным, дешевым блокам и учитывая длину маркера, мы дополнительно снижаем вычислительные затраты.
- Мы предлагаем агент, основанный на сравнительном обучении, который динамически адаптирует конфигурацию MCTS к запросу, подстраивая модель и конфигурацию реранжировщика под конкретную область запроса. Этот подход обеспечивает гибкость и устойчивость к динамическим, специфическим для области запросам, адаптируясь к вызову 3.
- Кроме того, мы провели комплексные эксперименты, сравнив наш фреймворк с несколькими современными методами. Результаты подтверждают эффективность, действенность и масштабируемость нашего подхода и повышают производительность на 30% по сравнению с базовым вариантом.

2 Подготовительные знания

В этом разделе мы сначала вводим определения некоторых ключевых понятий, таких как порядок блока и комбинации блоков, как в разделе 2.1. Далее мы приводим NP-трудное доказательство проблемы оптимизации порядка блоков. Наконец, в разделе 2.3 мы обсуждаем связанные работы.

2.1 Основные понятия

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

Определение 2.1 (блок). Пусть C представляет собой корпус документов, а блок χ определяется как непрерывный блок текста, извлеченный из C. Формально, блок χ состоит из последовательности лексем (t1, t2, ... , tn), где каждый ti - это лексема в C, а размер n задается пользователем.

В системе RAG каждый блок встраивается в векторное представление с помощью модели встраивания, которая передает семантическое значение блока и позволяет находить контекстно схожий контент. Когда поступает новый запрос, векторная база данных выполняет поиск по сходству, чтобы выявить наиболее семантически релевантные запросу блоки. Эти извлеченные блоки затем передаются генератору (например, большой языковой модели) для создания окончательного ответа на основе извлеченного контента. В частности, чем больше лексем содержит блок, тем выше затраты генератора. Таким образом, мы определяем стоимость блока как cost(χ) = |χ|, которая равна количеству лексем в блоке.

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

Определение 2.2 (Оптимальный выбор порядка комбинации блоков). Пусть {χ1, χ2, ... , χk} - набор потенциальных блоков, ℛ - бюджет затрат, Φ = ⟨χφ1, ... χφm⟩ представляет собой порядок потенциальных комбинаций блоков, где каждый χφi - это блок, а индекс φi обозначает его позицию в Φ. Пусть U(Φ) - это оценка полезности, присваиваемая моделью реранжировщика, которая может быть произвольной или составной. Наша цель - найти порядок комбинации блоков, который максимизирует оценки полезности при ограничении затрат на их подачу в LLM для генерации окончательного ответа, т. е. поиск

2.2 Доказательства сложности NP

Чтобы показать, что последовательный выбор комбинации блоков является NP-трудным, мы обобщаем на него проблему максимальной взвешенной гипергруппы (MWHP). Поскольку MWHP является NP-трудной, мы показываем, что любой экземпляр MWHP может быть преобразован в экземпляр оптимизации комбинации блоков за полиномиальное время.

2.2.1 Постановка задачи для MWHP

Дан гиперграф ℋ = (V, E, w1, w2), где V - множество вершин, E - множество гиперэджей, причем каждый гиперэдж содержит подмножество V. w1: v → ℝ и w2: e → ℝ - весовые функции, которые присваивают вес каждой вершине и гиперэджу соответственно. Учитывая подмножество вершин V' ⊆ V, мы говорим, что гиперэдж e принадлежит V', т. е. e ∈ V', если V' покрывает все вершины e. Задача состоит в том, чтобы найти k вершин и максимизировать сумму весов этих вершин и покрываемых ими гиперэджей:

2.2.2 Процесс нормализации

Теперь мы построим соответствующий экземпляр задачи оптимизации комбинации блоков из данного экземпляра MWHP. Для каждой вершины v ∈ V мы создаем соответствующий блок Xv. Мы определяем его стоимость cost(Xv) ≡ 1. Порядок комбинации блоков Φ соответствует подмножеству вершин V, обозначенному как V(Φ) ⊆ V. Мы определяем его полезность как

Наконец, мы задаем B = k и стремимся к тому, чтобы

с Φобозначает решение (4), то ясно, что V(Φ) является решением (2), и редукция может быть выполнена за время O(|V|-|E|).

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

2.3 Похожие работы

2.3.1 Генерация улучшений при извлечении

RAG [14, 20] широко используется для решения наукоемких задач НЛП. В типичном процессе RAG ретривер на основе плотного встраивания ищет релевантную информацию во внешних базах данных, которая затем используется LLM в процессе генерации. Для улучшения этого процесса в ряде работ [5, 18, 22, 35] основное внимание уделялось адаптации ретриверов для лучшего соответствия потребностям LLM в генерации, разработке многоступенчатых методов поиска и отсеиванию нерелевантной информации. Хотя существует множество современных ретриверов [8, 9, 15, 16, 27, 34], оптимизация ретриверов и LLM вместе в рамках сквозного процесса [25, 31] является более перспективной. Например, в исследовании [30] основное внимание уделяется совместному обучению ретривера и LLM одновременно или поэтапно. Однако это требует потери агента для оптимизации и усложняет процесс обучения, особенно если встроенные базы данных необходимо часто переиндексировать, что влечет за собой большие вычислительные затраты. Поэтому такие подходы, как [5], декомпозируют сложные многоэтапные запросы на более мелкие подзапросы, чтобы улучшить полноту ответа без частой переиндексации. Однако эти подходы обычно игнорируют решающую роль порядка сочетания блоков, который может существенно повлиять на общее качество ответа LLM. Насколько нам известно, данная работа является первым подходом, учитывающим порядок сочетания блоков в задаче RAG.

2.3.2 Повторное ранжирование по RAG

Методы повторного ранжирования необходимы для повышения эффективности поиска в процессе RAG [43, 44, 51].

Рисунок 2: Обзор архитектуры системы CORAG

Традиционные методы повторного ранжирования [33, 50] обычно опираются на языковые модели среднего размера, такие как BERT или T5, для ранжирования найденных контекстов. Однако эти модели обычно не в состоянии уловить семантические отношения между запросами и контекстами, особенно в условиях нулевой или малой выборки. Поэтому в недавнем исследовании [43] подчеркивается потенциал LLM с поправкой на команду для улучшения повторного ранжирования контекстов даже при наличии зашумленной или нерелевантной информации. Несмотря на эти достижения, возможности повторного ранжирования LLM в системах RAG остаются недостаточно использованными. В частности, было показано, что ранжирование блоков влияет на производительность LLM [19], что подчеркивает необходимость учета порядка комбинаций блоков в задачах RAG. Однако существующие модели не подходят для ситуаций, когда для оптимального поиска требуется определенная последовательность или комбинация блоков, а не отдельные блоки. Поэтому в будущих исследованиях необходимо лучше использовать LLM для более эффективной последовательности блоков в ответ на запросы в рамках RAG.

2.3.3 Обучение с подкреплением для больших языковых моделей

В последнее время Reinforcement Learning (RL) все чаще используется для решения различных задач управления данными и RAG. Методы RL могут позволить большим языковым моделям улучшить свои генеративные возможности за счет использования внешних источников знаний, таких как поисковые системы [13, 23]. В частности, обратная связь от человека [4, 36, 37] может быть интегрирована, чтобы помочь моделям генерировать более точные и контекстуально релевантные ответы с помощью RL-фреймворка. Кроме того, ряд подходов к оптимизации запросов [17, 21, 49] еще больше улучшает процесс поиска, позволяя использовать производительность модели для настройки запросов и, в конечном счете, улучшать результаты для последующих задач. В данной работе мы применяем облегченную технику RL, MCTS, для оптимизации процесса последовательного поиска комбинации блоков в системах RAG. Мы также представляем конфигурационный агент для управления процессом поиска MCTS. Насколько нам известно, это первый подход к решению данной конкретной задачи.

3 Обзор системы

Как уже упоминалось ранее, существующие системы RAG сталкиваются с тремя основными проблемами: как адекватно учесть ассоциации между блоками и немонотонность последовательной полезности комбинаций блоков, а также адаптироваться к различным областям запросов. Эти проблемы приводят к снижению релевантности результатов. Для решения этих проблем мы представляем CORAG - систему, предназначенную для поиска оптимальных комбинаций блоков, учитывающую как домены запросов, так и бюджеты пользователей. В качестве наиболее важного компонента нашей системы мы представляем модель поиска оптимальных комбинаций блоков. Модель использует дерево политик на основе MCTS для последовательного поиска порядка сочетания блоков, что позволяет нам полностью учитывать ассоциации между блоками (задача 1), а также немонотонность полезности порядка сочетания блоков (задача 2). Кроме того, мы предлагаем модуль вывода конфигурации, который рекомендует оптимальные конфигурации MCTS и реранжировщики для различных областей запросов, решая тем самым задачу 3. Ниже мы приводим краткое описание этих двух модулей.

Поиск оптимальной комбинации блоков: Простой подход к рассмотрению ассоциаций блоков заключается в извлечении потенциальных блоков из базы данных векторов (как показано в шаге 1) и последующем исчерпывающем исследовании всех возможных комбинаций блоков. Однако такой подход приводит к значительным задержкам и вычислительным затратам. Чтобы смягчить эту проблему, мы строим дерево стратегий (показано на этапе 2), которое преобразует поиск оптимальной комбинации блоков в задачу поиска в узлах дерева. В частности, корневой узел дерева стратегий представляет собой начальное пустое состояние, а каждый дочерний узел соответствует определенной комбинации блоков. Например, если корневой узел имеет дочерние узлы, представляющие блоки χ1, то один из его дочерних узлов может представлять комбинацию χ1+χ2, а другой - χ1+χ3

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

Конфигурация Рассуждения: Простым решением для настройки конфигурации было бы перечисление всех возможных конфигураций или реранжировщиков, параллельное вычисление результатов, а затем выбор наилучшей конфигурации. Однако это привело бы к нереальной стоимости системы RAG. Чтобы оптимизировать конфигурации (т. е. количество итераций, коэффициент стоимости и коэффициент исследования) для процесса поиска по дереву политик, мы вводим конфигурационный агент, который динамически генерирует конфигурации на основе области запроса. Чтобы убедиться в эффективности модели, мы используем сравнительный подход к обучению, используя пары положительных и отрицательных меток: положительные метки соответствуют вложениям запроса от одного лучшего реранжировщика, а отрицательные метки - от другого лучшего реранжировщика. Совместная функция потерь используется для одновременной оптимизации регрессии (для настройки параметров) и контрастного обучения (для улучшения различения меток).

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

4 Поиск комбинации блоков

Как уже говорилось ранее, порядок комбинаций блоков оказывает существенное влияние на эффективность построения подсказок для LLM. Из-за огромного количества потенциальных комбинаций, особенно при большом количестве блоков, перечисление всех возможных порядков комбинаций блоков не представляется возможным. В этом разделе мы предлагаем новый подход, который позволяет достичь хорошего баланса эффективности и точности в задаче поиска оптимального порядка комбинации блоков. В разделе 4.1 мы моделируем проблему как поиск оптимальных узлов в дереве политик (раздел 4.1). Затем мы предлагаем алгоритм на основе MCTS для решения этой задачи поиска узлов (раздел 4.2).

4.1 Моделирование поиска по дереву стратегий

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

Стратегическое дерево. Как показано на рис. 3, мы строим дерево стратегий, чтобы представить порядок всех возможных комбинаций блоков, извлеченных из базы данных векторов. В частности, корневой узел символизирует начальное состояние без каких-либо блоков, а каждый последующий узел изображает блок, выбранный из потенциальных блоков. Таким образом, дочерний узел генерируется из родительского узла путем выбора следующего доступного блока из очереди потенциальных блоков и объединения его в последовательность, установленную узлом-предком. Например, если узел представляет последовательность комбинаций блоков {χ1}, то дочерний узел может содержать последующие последовательности комбинаций, такие как {χ1, χ2}, {χ1, χ3} или {χ1, χ4}. Таким образом, формально мы определяем дерево стратегий следующим образом:

Определение 4.1 (дерево стратегий). Учитывая запрос q и набор потенциальных блоков {χ1, χ2, ... , χn}, мы строим дерево политик T. Корневой узел T представляет собой начальное состояние без каких-либо блоков. Каждый последующий узел, не являющийся корневым, содержит набор блоков путем объединения вновь выбранных блоков из оставшихся потенциальных блоков в последовательность своих родительских узлов. Этот процесс последовательно строит упорядоченную комбинацию блоков в каждом некорневом узле, и мы стремимся найти узел с наивысшей оценкой полезности.

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

Узловая коммунальная служба. Метрика полезности состоит из двух компонентов: выгоды от выбора комбинации блоков и стоимости использования блоков в качестве подсказок для LLM. В частности, выгода оценивается с помощью LLM, которые измеряют сходство между выбранными блоками и запросом. В частности, мы обозначаем их как значения узлов V. Далее мы используем алгоритм Upper Confidence Bound (UCB) [3], чтобы сбалансировать баланс между эксплуатацией (значения узлов V(vi)) и исследованием (количество поисков N(vi)) значений узлов V(vi) и количества поисков N(vi). Для данного узла vi в качестве стоимости мы рассматриваем стоимость маркировки, определенную в разделе 2 и измеряемую отношением стоимости текущей комбинации блоков к общему выделенному бюджету B. Таким образом, полезность узла определяется следующим образом:

Определение 4.2 (Узловая полезность). Учитывая дерево стратегий и бюджет затрат B, полезность узла, не являющегося корнем, определяется как:

где V(vi) - оценочное значение выгоды от комбинации блоков в узле vi, определяемое обучающей моделью, N(vi) - количество посещений узла vi, что способствует исследованию менее посещаемых узлов, а N - общее количество посещений всех узлов в дереве политики для обеспечения баланса между исследованием и эксплуатацией. Кроме того, cost(vi) обозначает стоимость маркировки узла vi, B - общий бюджет маркировки, c регулирует компромисс между исследованием и эксплуатацией, а λ служит штрафным коэффициентом для повышения эффективности затрат.

Моделирование оптимального выбора узла. На основе определенных полезностей узлов задача выбора оптимального порядка сочетания блоков, как описано в разделе 2, переформулируется как выбор оптимального узла в дереве политики T . При заданном бюджетном ограничении B целью является определение узлов vi ⊆ T для максимизации полезности U(vi), при этом общая стоимость, связанная с vi, не должна превышать B. Формально это выражается как:

где V(vi) - предполагаемая польза от комбинации блоков в узле vi, а cost(vi) - связанные с ней затраты. Эта формула позволяет выбрать блок, который максимизирует полезность в рамках заданного бюджета.

Рисунок 3: Рабочий процесс оптимизации блоков на основе MCTS

Алгоритм 1 Поиск дерева стратегий на основе MCTS

4.2 Поиск дерева политик на основе MCTS

Мотивация. Перечисление всех узлов в дереве политик позволит найти оптимальный узел, но приведет к большим вычислительным затратам. Для решения этой проблемы можно применить жадную стратегию, которая итеративно перемещается по дереву, начиная с корневого узла. На каждой итерации выбирается дочерний узел с наибольшей выгодой, и так продолжается до тех пор, пока бюджет не будет исчерпан. Однако такой подход, скорее всего, приведет к неоптимальным результатам. Например, выгода от χ1 может быть немного выше, чем от χ2, но выгода от χ2 + χ3 может быть значительно выше, чем от χ1 + χ3. В этом случае жадный подход может привести к неоптимальным результатам. Поэтому необходимо пересмотреть высокоэффективный родительский узел. В то же время необходимо сократить исследование узлов с низкой эффективностью.

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

Аннотация. Политики на основе MCTS описаны в алгоритме 1. Сначала мы инициализируем корневой узел дерева политик с помощью входных запросов. Если бюджет вычислений не исчерпан, мы итеративно выполняем два ключевых шага: выбор узла и обновление полезности. По достижении предела итераций или бюджета мы останавливаем процесс и рекурсивно перебираем дерево, чтобы найти узел с наибольшей полезностью. В отличие от традиционных стратегий MCTS, которые обычно фокусируются только на корневом узле, наш подход также рассматривает перспективные узлы промежуточного уровня, чтобы максимизировать полезность комбинации блоков.

Подробное объяснение ключевых особенностей. Эти две ключевые функции мы объясняем следующим образом:

1. Выбор узла (алгоритм 2). Мы рекурсивно выбираем узел с наибольшим значением полезности, который с наибольшей вероятностью приведет к оптимальной комбинации блоков. А именно:

Алгоритм 2 Выбор узла

Алгоритм 3 UtilityUpdate

• Выберите. Мы определяем узел с максимальным значением полезности. Если 𝑣 еще не расширен, мы генерируем все возможные узлы-потомки и включаем их в дерево стратегий. Если 𝑣 уже расширен, мы выбираем узел-потомок с наибольшей полезностью для дальнейшего исследования.
• Расширения. Выбрав узел с наибольшей полезностью, мы расширяем его, генерируя все потенциальные дочерние узлы. Каждый дочерний узел представляет собой новый порядок возможных комбинаций блоков. Наш подход использует параллельное расширение, которое вычисляет и оценивает несколько дочерних узлов одновременно. Этот параллелизм использует способность сети значений обрабатывать множество комбинаций при вычислительных затратах, аналогичных затратам на один узел, что повышает эффективность поиска.
• Рассчитанная полезность. Мы вычисляем значение полезности для каждого нового дочернего узла, используя формулу полезности. Модель реранжировщика R параллельно обрабатывает несколько комбинаций блоков для получения.

5 Настройка агента

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

5.1 Схема моделирования

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

На рисунке 4 представлен обзор нашего сконфигурированного агента, который состоит из двух основных модулей, отвечающих за преобразование входных данных в граф признаков. Во-первых, модуль встраивания входных данных генерирует вкрапления входного запроса. Затем сеть кодирования обрабатывает эти вкрапления для создания карт признаков, которые затем используются для получения различных конфигураций настроек MCTS.

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

(1) Введите запрос, встроенный в. Чтобы эффективно отразить факторы различных запросов, учитывая разнообразие типов запросов, таких как явные факты, неявные факты, интерпретируемая рациональность и скрытая рациональность [47], мы используем модель встраивания BGE-M3 [6] для генерации вкраплений для каждого запроса. Эти вкрапления расширяют рамки обучения, сопоставляя похожие типы запросов с одной и той же категорией реранкера. Представленные в 1024-мерном пространстве, вкрапления отражают основные семантические особенности, позволяя сети кодирования эффективно сравнивать и классифицировать их. Этот шаг помогает улучшить поисковую релевантность различных типов запросов. Кроме того, при использовании одной и той же модели вкраплений генерируются аннотированные вкрапления оптимального рераундера, включая их уникальные особенности и связанные с ними метаданные, что позволяет модели приводить запросы в соответствие с оптимальным рераундером.

(2) Генерация карт признаков с помощью кодированных сетей: технология Чтобы оптимизировать задачу выбора ре-ранкера и рекомендовать лучший ре-ранкер для каждого запроса разных типов, мы используем сети кодирования для эффективного обучения представлениям, которые полезны как для классификации, так и для предсказания конфигурации. Для этой задачи мы используем сиамскую сеть, состоящую из трех полностью связанных слоев. Она обрабатывает входные вкрапления запросов размерности d = 1024 и обучается результатам классификации и предсказаниям конфигурации MCTS (т. е. количеству итераций и λ). Ветви сети кодирования имеют общие веса, и каждая ветвь применяет линейное преобразование с последующей активацией RELU. Последовательно первый скрытый слой уменьшает размерность до 512, второй - до 256, а третий - до 128. Последний выходной слой обеспечивает классификационные прогнозы, определяющие лучший реранжировщик для каждого запроса, а также регрессионные результаты, которые используются для прогнозирования наиболее эффективных конфигураций MCTS для управления процессом поиска. Классификационный вывод определяет лучший реранжировщик для каждого запроса, а регрессионный вывод определяет лучшие настройки конфигурации MCTS.

5.2 Совместное обучение

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

5.2.1 Потери при классификации и регрессии.

Учитывая предсказанную метку реранкера Y(pred) и соответствующую ей фактическую оптимальную метку реранкера Y(true), потери классификации L(cla) рассчитываются следующим образом.

где F(cla) представляет собой потерю перекрестной энтропии между предсказанными и реальными метками реранкера. Эта функция потерь помогает точно классифицировать оптимальный реранжировщик для каждого запроса. Аналогично, потери регрессии L(reg) определяются как.

где 𝐹reg - среднеквадратичная ошибка (MSE) между предсказанным параметром MCTS 𝑝pred и фактическим параметром MCTS 𝑝true. Эта метрика обеспечивает точное предсказание конфигурации MCTS с точки зрения количества итераций и 𝜆.

Рисунок 4: Обзор агента конфигурации

5.2.2 Контрастивное обучение.

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

Подготовка к сравнению. Чтобы подготовить обучающий набор данных, мы должны определить оптимальный реранкер и конфигурацию для каждого запроса. В данном исследовании оптимальные реранкеры и соответствующие конфигурации для каждого запроса были определены в ходе обширных экспериментов с различными настройками. Затем на основе этих оптимальных аннотаций реранкеров создаются пары запросов. Положительные пары состоят из запросов с одним и тем же оптимальным реранкером, что облегчает минимизацию их вложения в пространство признаков. Напротив, отрицательные пары состоят из запросов с разными реранкерами, цель которых - максимизировать расстояние вложения между ними. Поскольку некоторые ранжировщики одинаково работают с определенными запросами, мы выбираем только те случаи, когда ROUGE-L отличается более чем на 10%, чтобы сформировать наш обучающий набор данных.

Потеря контраста. Как показано на рис. 4, для данной положительной пары (𝑥𝑖, 𝑥+𝑖) и отрицательная пара (𝑥𝑗, 𝑥-𝑗), мы сначала используем модель кодирования для создания соответствующих карт признаков. Эти карты признаков затем используются для вычисления потери контрастности 𝐿con. В частности, этот процесс можно представить следующим образом:

Среди них.𝑓𝜃(𝑥) обозначает функцию встраивания.𝐹con это функция сходства, применяемая к двум типам пар: положительным парам (с похожими реордерами) и отрицательным парам (с разными реордерами). Эта функция потерь предназначена для обеспечения того, чтобы запросы с одинаковыми реордерами были ближе в пространстве встраивания, а запросы с разными реордерами - дальше.

5.2.3 Весь процесс обучения.

Наконец, общая функция потерь L(total) представляет собой сумму потерь при сравнении, классификации и регрессии.

В частности, потеря контрастности Lcon(θ) способствует тому, что вложения запросов с одинаковым оптимальным реранкером сближаются, а вложения запросов с разными реранкерами отдаляются. Потеря классификации Lcla(θ) помогает модели правильно идентифицировать реранкеры с помощью перекрестной энтропии, а потеря регрессии Lreg(θ) минимизирует ошибку в предсказании оптимальной конфигурации MCTS.

Примечания. После вычисления суммарных потерь Ltotal параметры сети θ обновляются с помощью градиентного спуска со скоростью обучения η. Этот процесс оптимизации повторяется в течение нескольких циклов E и партий, что обеспечивает улучшение прогнозов как классификатора, так и параметров с течением времени.

6 экспериментов

Цель экспериментального исследования - ответить на следующие вопросы.
- RQ1 Как наш CORAG сравнивается с другими методами в трубопроводах RAG с ограниченными затратами?
- Насколько эффективен RQ2 CORAG при различных размерах блоков?
- RQ3 Каковы текущие узкие места в RAG?
- Какие узкие места существуют в RAG?
- RQ4 Насколько масштабируема CORAG при различных размерах наборов данных?
- RQ5 Насколько эффективен каждый дизайн в CORAG?

6.1 Экспериментальная установка

Окружающая среда. Мы интегрировали нашу систему с популярным RAG-фреймворком LlamaIndex. Эксперименты проводились на Linux-сервере, оснащенном процессором Intel Core i7-13700K (12 ядер, 24 потока, 5,3 ГГц), 64 ГБ оперативной памяти и NVMe SSD емкостью 1 ТБ. Модуль Configuration Agent был реализован на графическом процессоре NVIDIA RTX 4090 с 24 ГБ VRAM с помощью PyTorch 2.0.

Таблица 1: Статистические данные, использованные в эксперименте.

Набор данных.Чтобы оценить производительность CORAG в различных сценариях, мы провели эксперименты на двух различных наборах данных с разной направленностью задач: (1) WikiPassageQA [7] - это эталон вопросов и ответов, содержащий 4 165 вопросов и более 100 000 фрагментов текста, предназначенный для оценки поиска на уровне абзацев. (2) MARCO [24] - это обширный набор данных, посвященный задачам обработки естественного языка с основным акцентом на вопросы и ответы и поиск информации. Как показано в таблице 1, и WikiPassageQA, и MARCO содержат высококачественные вопросы и аннотации к абзацам, что делает их подходящими для оценки эффективности поиска. В наших экспериментах мы побуждаем LLM генерировать истинные ответы для каждого набора данных. Например, если мы используем Llama3 для оценки эффективности CORAG, мы также используем Llama3 для генерирования истинных ответов в той же экспериментальной установке, чтобы сохранить справедливость и соответствие характеристикам LLM.

Базовый уровень.Мы сравниваем производительность CORAG с двумя типичными базовыми версиями RAG:

- RAPTOR [29]: RAPTOR строит иерархическое дерево резюме документа путем рекурсивного встраивания, кластеризации и обобщения блоков текста для достижения многоуровневой абстракции. Этот подход соответствует подходу на основе кластеризации, рассмотренному в разделе 1. Мы завершаем построение дерева в рамках приблизительных бюджетных ограничений.
- NaiveRAG: это базовый метод поиска релевантных блоков. Сначала из базы данных векторов извлекаются блоки-кандидаты на основе поиска сходства векторов, а затем они ранжируются с помощью модели реранжирования. Этот метод представляет собой метод AKNN, упомянутый в разделе 1. Чтобы удовлетворить ограничение на стоимость, мы используем жадную стратегию распределения бюджета для получения блоков до тех пор, пока бюджет не будет полностью исчерпан.

Кроме того, мы удаляем конфигурационный агент из нашего подхода в качестве базового, чтобы оценить его влияние на производительность CORAG, называя эту версию CORAG w/o Agent. Наконец, мы реализуем подход под названием CORAG Upper, который устанавливает верхнюю границу, исследуя все возможные комбинации блоков и выбирая наилучший порядок. Из-за большого количества потенциальных комбинаций в случае CORAG Upper мы ограничиваем поиск комбинациями, состоящими менее чем из шести блоков.

Примечания.Другие подходы, такие как GraphRAG [22], в значительной степени зависят от частых обращений к LLM для обобщения блоков и построения индексов, что влечет за собой огромные затраты (например, миллиарды токенов), которые превышают наши строгие ограничения на затраты. Поэтому эти подходы не подходят для решения нашей задачи. Для корректного сравнения мы исключили эти типы RAG-подходов из наших экспериментов.

Параметры гиперпараметров: гиперпараметры для CORAG определяются автоматически конфигурационным агентом, в то время как NaiveRAG не требует никаких гиперпараметров. Для остальных базовых методов мы обеспечиваем согласованность, используя одинаковые гиперпараметры для корректного сравнения. В частности, мы установили коэффициент разведки на 2,4, количество итераций - на 10, а коэффициент стоимости λ - на 0,1. Предварительные эксперименты показывают, что такая конфигурация оптимизирует базовую производительность. Мы также проведем дальнейшие исследования абляции, чтобы подтвердить эти настройки.

Настройки параметров обучения. В нашем подходе конфигурационный агент обучается с помощью контрастного обучения. При этом используются такие гиперпараметры, как потеря контраста (margin=1,0), скорость обучения (lr=0,001), размер партии (32), количество циклов (num_epochs=60) и модель встраивания (т.е. BAAI/bge-m3 [6]).

Метрики оценки. Мы оцениваем эффективность, сравнивая оценки Rouge истинных ответов и сгенерированных ответов, используя в качестве метрик оценки Rouge-1, Rouge-2 и Rouge-L. Чтобы оценить эффективность, мы измеряем время ожидания, необходимое для ответа на запросы с использованием различных методов.

Рисунок 5: Сравнение эффективности

6.2 Сравнение производительности

6.2.1 RQ1: Сравнение ружей.

Как показано на рис. 2, мы сравниваем производительность CORAG с несколькими базовыми методами на различных наборах данных, в основном на WikiPassageQA и MARCO. оценка проводится при трех различных размерах блоков, с использованием метрик Rouge-1, Rouge-2 и Rouge-L для оценки улучшения ответов, генерируемых LLM, благодаря нашему методу поиска. corag превосходит основные методы RAG (например, NaiveRAG и RAPTOR) на 251 TP3 T. Основными методами RAG (например, NaiveRAG и RAPTOR) со значительным улучшением примерно на 251 TP3 T. Неудивительно, что CORAG не превышает верхнюю границу, которая представляет собой крайний случай, когда все возможные порядки комбинаций перечисляются исчерпывающе, что явно неэффективно и непрактично. В заключение следует отметить, что CORAG превосходит базовый вариант, повышая релевантность поиска при эффективном сокращении пространства поиска.

6.2.2 RQ2: Оценка эффективности.

Как показано на рис. 5, поскольку CORAG основан на древовидном алгоритме поиска, агент помогает предсказать лучший реранжировщик и параметры для заданного запроса. Поэтому очень важно оценить влияние различных размеров блоков и наборов данных на эффективность задачи оптимизации поиска. Мы проверили эффективность, используя различные наборы данных и размеры блоков, и заметили, что NaiveRAG, использующий традиционные методы поиска, достигает более короткого времени поиска, но более низких показателей Rouge. CORAG показывает хорошие результаты по Rouge, но значительно менее эффективен, поскольку исследует все пространство поиска. Аналогично, RAPTOR использует внешний LLM для обобщения и демонстрирует низкую эффективность. В отличие от этого, наш подход CORAG обеспечивает эффективный компромисс между эффективностью и релевантностью поиска.

6.2.3 Вопрос 3: Декомпозиция производительности.

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

Таблица 2: Сравнение Rouge на наборах данных WikiPassage QA и MARCO

6.2.4 Вопрос 4: Оценка масштабируемости

CORAG демонстрирует отличную масштабируемость, особенно при работе с большими наборами данных (такими как WikiPassageQA и MARCO), содержащими большое количество абзацев. Количество фрагментов можно легко увеличить до 100 тыс. и более, разбив каждый абзац на 256 помеченных фрагментов. Несмотря на значительное увеличение объема данных, время поиска увеличивается всего на 101 TP3T по сравнению с традиционным подходом, что свидетельствует об эффективности нашей системы в решении масштабных задач поиска. Примечательно, что наша система превосходит метод CORAG Upper, требуя лишь десятую часть времени поиска и обеспечивая при этом конкурентоспособные оценки ROUGE. Такой эффективный баланс между производительностью и вычислительными затратами подчеркивает способность системы эффективно сокращать пространство поиска, обеспечивая быстрый поиск даже в огромных массивах данных. Таким образом, наш подход хорошо подходит для сценариев, требующих обработки больших объемов данных и высокой точности поиска.

Рисунок 6: Декомпозиция производительности

Таблица 3: Сравнение производительности при различных бюджетах

6.3 RQ5: Исследования абляции

6.3.1 Исследования абляции с различными бюджетами

Как показано в таблице 3, мы оценивали CORAG как систему с ограниченными затратами и исследовали влияние различных бюджетов на общую производительность. Используя набор данных MARCO, мы установили бюджетные ограничения на 1024, 2048 и 8192 маркера и оценили результаты с помощью ROUGE. CORAG неизменно превосходит все базовые системы на этих бюджетных уровнях. Примечательно, что средняя стоимость маркировки CORAG остается ниже каждого бюджетного ограничения, что говорит о том, что полезность блоков не является монотонной, как было показано в Задаче 2. При увеличении бюджета CORAG получает преимущества от расширения пространства поиска и может включать больше релевантной информации, а не просто увеличивать количество блоков.

6.3.2 Исследования абляции с различными коэффициентами разведки

Как показано на рис. 7, мы провели исследование абляции, чтобы оценить влияние различных коэффициентов разведки на производительность системы, в частности, тестируя значения C 0, 1, 2 и 3. Результаты показывают, что коэффициент разведки около 2 обеспечивает наилучшую производительность, достигая оптимального баланса между разведкой и эксплуатацией в процессе поиска. Этот баланс позволяет системе эффективно обнаруживать релевантную информацию, сохраняя при этом фокус на высокопотенциальных блоках, что в конечном итоге приводит к улучшению реакции RAG. Напротив, более низкие коэффициенты разведки приводили к неоптимальным результатам из-за недостаточной разведки, а более высокие коэффициенты разведки приводили к неоптимальным результатам из-за чрезмерного перераспределения внимания. Эти результаты подчеркивают критическую роль коэффициента разведки в эффективности процесса поиска CORAG и указывают на важность тщательной настройки параметров.

Рисунок 7: Сравнение ROUGE между различными значениями C

6.3.3 Исследования абляции с различными факторами стоимости

Как показано на рис. 8, для оценки влияния различных коэффициентов затрат на производительность системы было проведено исследование абляции, в частности тестировались значения 0, 0.1, 0.2 и 0.3. Результаты показывают, что введение коэффициентов затрат в утилиту приводит к небольшому снижению оценки ROUGE. Это снижение связано с тем, что в отсутствие ограничений по затратам CORAG стремится производить более длинные продукты, хотя и за счет снижения эффективности затрат. Однако, несмотря на небольшое снижение оценки ROUGE, оно остается в пределах 51 TP3T, что вполне приемлемо. Эти результаты подчеркивают важность эффективной настройки коэффициентов стоимости для баланса между богатством вывода и ограничениями стоимости, что еще больше подчеркивает роль нашего конфигурационного агента в обеспечении эффективной настройки конфигурации для оптимизации производительности CORAG.

Рисунок 8: Сравнение ROUGE для различных значений лямбды

6.3.4 Исследования абляции с использованием различных перестановочных устройств

Для того чтобы оценить влияние различных реорганизаторов на эффективность поиска, мы провели исследование абляции с использованием шести широко известных моделей реорганизаторов: jina-reranker-v1-turbo-en, jina-reranker-v2-base-multilingual, bge-reranker-v2-m3, bge-. Эти перестановщики были оценены на наборе данных MARCO с помощью модели llama3-8B, настроенной с фиксированным коэффициентом затрат 0.1, коэффициентом исследования 2.4 и ограничением бюджета 1024.

Таблица 4: Сравнение производительности при использовании различных реорганизаторов

Результаты, приведенные в Таблице 4, показывают, что между различными реранжировщиками существуют различия в производительности, что подчеркивает важность тщательного выбора реранжировщиков для оптимизации работы системы RAG в условиях конкретных операционных ограничений. Среди перегруппировщиков gte-multilingual-reranker-base и bge-reranker-large показывают стабильно высокую производительность в задаче QA, что говорит о высокой эффективности этих моделей перегруппировки в захвате релевантной информации для различных запросов QA. Мы наблюдаем, что при увеличении размера блока в исследовании абляции каждый отдельный реранжировщик отстает от агента по количеству рекомендуемых реранжировщиков для различных запросов. Это говорит о том, что агент конфигурации эффективно использует разнообразие реранжировщиков, динамически изменяя конфигурацию для улучшения результатов поиска. Способность конфигурационного агента рекомендовать лучшие варианты перестановки и конфигурации параметров подчеркивает его роль в максимизации производительности системы RAG, особенно в условиях ограниченного бюджета.

6.4 Тематические исследования

На рисунке 9 показаны три примера, сравнивающие качество поиска CORAG и традиционного подхода NaiveRAG, которые показывают, почему наш подход превосходит базовый. Из-за простого поиска по принципу top-k и переупорядочивания NaiveRAG часто пропускает важную информацию, относящуюся к смыслу запроса, поскольку обычно извлекает фрагменты на основе совпадения ключевых слов, а не релевантности запросу. Например, для запроса "Являются ли листовые цветы кустарниками?" NaiveRAG извлекает содержимое, содержащее совпадающие ключевые слова, но не предоставляет фактическую классификацию цветка-листочка. В отличие от этого, стратегия комбинирования блоков CORAG извлекает контекст, включающий категорию цветка-листочка, что позволяет LLM дать более точный ответ. В другом случае NaiveRAG извлек термины и юридические статьи, включающие "оксифлуорфен", но не смог понять смысл запроса, в то время как CORAG предоставил контент, связывающий оксифлуорфен со случаями использования в хлопке, что потребовало поиска, который NaiveRAG не смог выполнить. Векторный поиск по сходству не смог уловить логические связи между блоками. Наконец, для запроса "Откуда берутся бактерии?" NaiveRAG извлекает блоки, содержащие ключевое слово "бактерии", но не рассматривает их происхождение, тогда как CORAG дает более полный ответ, включая происхождение бактерий и условия их размножения. Эти примеры показывают, что CORAG лучше справляется с поиском логически связанной информации, что делает его более подходящим, чем NaiveRAG, для запросов, требующих большего, чем простое сопоставление ключевых слов.

Рисунок 9: Исследование CORAG

7 Анализ RAG и вариантов будущего дизайна

7.1 Недостатки нынешней системы RAG

Мы проводим анализ существующей системы RAG, выявляя проблемы с производительностью, возникающие на этапах поиска (S1), улучшения (S2) и создания (S3).

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

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

S3: Накладные расходы на генерацию Эффективная разработка подсказок для оптимальных комбинаций блоков требует значительных вычислительных ресурсов. Уточнение и сжатие подсказок по конкретным запросам необходимы для снижения накладных расходов при сохранении релевантности и краткости ввода. Адаптивные стратегии для обработки различных типов запросов и специфических требований области обеспечивают эффективность подсказок без ущерба для качества вывода.

7.2 Варианты дизайна

Для решения вышеупомянутых проблем были выбраны следующие конструктивные решения, призванные оптимизировать работу системы RAG:

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

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

P3: Проект "Динамический наконечник Выбор реорганизатора в зависимости от типа запроса и использование адаптивных шаблонов подсказок может повысить релевантность поиска в LLM. Динамические структуры подсказок, согласованные с намерением запроса и контекстом конкретной области, могут поддерживать качество вывода в условиях ограниченных ресурсов. Этот подход к разработке адаптивных подсказок позволяет достичь эффективного баланса между эффективностью и качеством поиска, учитывая динамическую природу запросов в системах RAG.

8 Заключение

Учитывая немонотонность полезности блоков, корреляцию между блоками и разнообразие различных областей запросов, мы предлагаем CORAG - систему оптимизации поиска на основе обучения. Сначала мы моделируем порядок комбинаций блоков как дерево политик и исследуем это дерево с помощью MCTS, стремясь найти оптимальный порядок комбинаций блоков. Мы вводим конфигурационный агент, который точно предсказывает оптимальную конфигурацию и перегруппировщик для данного запроса. Кроме того, мы разработали стратегию параллельного расширения запросов для расширения нескольких узлов на каждой итерации. Экспериментальные результаты показывают, что наш подход значительно превосходит современные подходы в рамках ограничений по стоимости, а также превосходит по эффективности.