Руководство по 12 стратегиям настройки готовых к производству приложений RAG

Гайд по 12 стратегиям оптимизации готовых к производству приложений RAG

Как улучшить производительность вашей конвейерной системы Retrieval-Augmented Generation (RAG) при помощи этих «гиперпараметров» и стратегий настройки

Tuning Strategies for Retrieval-Augmented Generation Applications — Стратегии настройки для приложений Retrieval-Augmented Generation

Data Science – это экспериментальная наука. Она начинается с «теоремы о невозможности общей формулы», которая утверждает, что не существует универсального алгоритма, наилучшим образом решающего все проблемы. И это ведет к использованию данными учеными систем отслеживания экспериментов, чтобы помочь им настроить гиперпараметры своих проектов по машинному обучению (ML) и достичь наилучшей производительности.

В этой статье рассматривается конвейерная система Retrieval-Augmented Generation (RAG) глазами ученого в области обработки данных. Она обсуждает потенциальные «гиперпараметры», с помощью которых можно улучшить производительность вашей конвейерной системы RAG. Аналогично экспериментам в глубоком обучении, где, например, техники аугментации данных не являются гиперпараметром, а регулирующим элементом, который можно настроить и экспериментировать с ним, в этой статье также рассмотрены различные стратегии, которые можно применить и которые не являются гиперпараметрами per se.

Retrieval-Augmented Generation (RAG): от теории к реализации LangChain

От теории первоначальной научной статьи к ее реализации на языке Python с использованием технологий OpenAI, Weaviate и LangChain

towardsdatascience.com

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

А на этапе инференса (поиск и генерация) в конвейере RAG вы можете настраивать:

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

Стадия поглощения

Стадия поглощения представляет собой этап подготовки к построению конвейера RAG, аналогичный этапам очистки данных и предварительной обработки в конвейере ML. Обычно стадия поглощения включает следующие шаги:

Сбор данных
Разделение данных на фрагменты
Генерация векторных вложений фрагментов
Хранение векторных вложений и фрагментов в векторной базе данных

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

Очистка данных

Как и в любом конвейере Data Science, качество ваших данных имеет существенное влияние на результаты вашего конвейера RAG [8, 9]. Перед переходом к следующим шагам убедитесь, что ваши данные соответствуют следующим критериям:

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

Разделение на фрагменты

Разделение ваших документов является важным этапом подготовки внешнего источника знаний в конвейере RAG, который может повлиять на производительность [1, 8, 9]. Это методика генерации логически связанных фрагментов информации, обычно путем разбиения длинных документов на более маленькие секции (но также может объединять более маленькие фрагменты в связные абзацы).

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

Идеальная длина вашего фрагмента (chunk_size) зависит от вашего случая использования: Если ваш случай использования – это ответы на вопросы, вам могут понадобиться более короткие конкретные фрагменты, но если ваш случай использования – это краткое изложение, вам могут понадобиться более длинные фрагменты. Кроме того, если фрагмент слишком короткий, в нем может не быть достаточно контекста. С другой стороны, если фрагмент слишком длинный, он может содержать слишком много несвязанной информации.

Кроме того, вам нужно подумать о “перекатывающемся окне” между фрагментами (overlap), чтобы ввести дополнительный контекст.

Модели вложения

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

Чтобы получить представление о доступных альтернативных моделях вложения, вы можете посмотреть Рейтинг Massive Text Embedding Benchmark (MTEB), который включает 164 модели вложения текста (на момент написания статьи).

Рейтинг MTEB – пространство Hugging Face от mteb

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

huggingface.co

Хотя вы можете использовать универсальные модели вложения “из коробки”, в некоторых случаях имеет смысл настраивать вашу модель вложения под ваш конкретный случай использования, чтобы избежать проблем, связанных с использованием модели в неподходящей области [9]. В результате экспериментов, проведенных LlamaIndex, настройка вашей модели вложения может привести к OpenAI’s text-ebmedding-ada-002 в данный момент нельзя настроить).

Метаданные

Когда вы сохраняете векторные вложения в векторную базу данных, некоторые векторные базы данных позволяют сохранять их вместе с метаданными (или данными, которые не являются векторизованными). Аннотирование векторных вложений может быть полезным для дополнительной послеобработки результатов поиска, такой как фильтрация метаданных [1, 3, 8, 9]. Например, вы можете добавить метаданные, такие как дата, глава или подглава ссылки.

Мультииндексация

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

Алгоритмы индексации

Для обеспечения молниеносного поиска сходства в масштабе, векторные базы данных и библиотеки векторной индексации используют приближенный поиск ближайших соседей (Approximate Nearest Neighbor – ANN) вместо поиска k-ближайших соседей (k-nearest neighbor – kNN). Как следует из названия, алгоритмы ANN приближают ближайших соседей и могут быть менее точными, чем алгоритм kNN.

Есть разные алгоритмы ANN, с которыми вы можете экспериментировать, такие как Facebook Faiss (кластеризация), Spotify Annoy (деревья), Google ScaNN (сжатие векторов) и HNSWLIB (проксимальные графы). Кроме того, у многих из этих алгоритмов ANN есть некоторые параметры, которые вы можете настроить, такие как ef, efConstruction и maxConnections для HNSW [1].

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

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

Обзор оценки RAG | Weaviate – векторная база данных

Узнайте о новых тенденциях в оценке RAG и текущем состоянии искусства.

weaviate.io

Стадия вывода (Извлечение и Генерация)

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

Преобразования запроса

Поскольку поисковый запрос для получения дополнительного контекста в конвейере RAG также встроен в векторное пространство, его фразирование также может влиять на результаты поиска. Таким образом, если ваш поисковый запрос не дает удовлетворительных результатов, вы можете экспериментировать с различными техниками преобразования запроса [5, 8, 9], такими как:

Перефразировка: Используйте LLM для перефразировки запроса и попробуйте еще раз.
Гипотетическое векторное представление документа (HyDE): Используйте LLM для создания гипотетического ответа на поисковый запрос и используйте оба для поиска.
Подзапросы: Разбить более длинные запросы на несколько более коротких запросов.

Параметры поиска

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

В последнем случае вам необходимо экспериментировать с взвешиванием агрегации разреженных и плотных методов поиска в гибридном поиске [1, 4, 9]. Таким образом, потребуется настройка параметра alpha, который контролирует взвешивание между семантическим (alpha = 1) и поиском на основе ключевых слов (alpha = 0).

Улучшение производительности поиска в конвейерах RAG с гибридным поиском

Как найти более релевантные результаты поиска, объединяя традиционный поиск по ключевым словам с современным векторным поиском

towardsdatascience.com

Также важную роль будет играть количество результатов поиска для извлечения. Количество извлеченных контекстов будет влиять на длину используемого контекстного окна (см. Техника формулировки задания). Кроме того, если вы используете модель повторной ранжировки, вам нужно учитывать, сколько контекстов будет вводиться в модель (см. Модели повторной ранжировки).

Обратите внимание, что хотя используемая мера сходства для семантического поиска представляет собой параметр, который вы можете изменить, вы не должны экспериментировать с ним, а установить его в соответствии с используемой моделью вложения (например, модель вложения текста text-embedding-ada-002 поддерживает косинусное сходство, а модель multi-qa-MiniLM-l6-cos-v1 поддерживает косинусное сходство, скалярное произведение и евклидово расстояние).

Расширенные стратегии поиска

Этот раздел технически может быть отдельной статьей. В этом обзоре мы постараемся сделать его максимально лаконичным. Для более подробного объяснения следующих методов я рекомендую этот курс DeepLearning.AI:

Создание и оценка расширенных приложений RAG

Изучите методы, такие как поиск в окне предложения и автоматическое объединение результата поиска, улучшающие производительность вашей конвейера RAG…

www.deeplearning.ai

Основная идея этого раздела заключается в том, что фрагменты для поиска не обязательно должны быть такими же, как фрагменты, используемые для генерации. Идеально, вы должны встраивать более мелкие фрагменты для поиска (см. Формирование фрагментов), но извлекать более крупные контексты. [7]

Поиск в окне предложения: Извлекайте не только соответствующее предложение, но и окно подходящих предложений перед и после извлеченного.
Автоматическое объединение результата поиска: Документы организованы в древовидной структуре. Во время запроса отдельные, но связанные более мелкие фрагменты могут быть объединены в более крупный контекст.

Модели переоценки рейтинга

В то время как семантический поиск извлекает контекст на основе его семантической близости с поисковым запросом, “наиболее похожее” не обязательно означает “наиболее релевантное”. Модели переоценки рейтинга, такие как модель переоценки Cohere, могут помочь устранить нерелевантные результаты поиска, рассчитывая оценку релевантности запроса для каждого извлеченного контекста [1, 9].

“наиболее похожее” не обязательно означает “наиболее релевантное”

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

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

Лингвистико-логические модели (LLM)

LLM является основным компонентом для генерации ответа. Как и с моделями векторизации, существует широкий выбор LLM, из которых вы можете выбрать в зависимости от ваших требований, таких как открытые vs. проприетарные модели, стоимость вывода, длина контекста и т. д. [1].

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

Инженерия запроса

Как вы формулируете или инженерите свой запрос, значительно влияет на завершения LLM [1, 8, 9].

Пожалуйста, опирайтесь только на результаты поиска и ничего больше!

Очень важно! Ваш ответ ДОЛЖЕН быть основан на предоставленных результатах поиска. Пожалуйста, объясните, почему ваш ответ основан на результатах поиска!

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

Как упоминалось в параметрах поиска, количество передаваемых контекстов в запрос является параметром, с которым стоит экспериментировать [1]. В то время как производительность вашей конвейерной системы RAG может улучшиться с увеличением релевантного контекста, вы также можете столкнуться с эффектом “Потерянный в середине” [6], когда релевантный контекст не распознается LLM, если он находится в середине множества контекстов.

Итог

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

Эта статья охватывает следующие стратегии на этапе загрузки данных:

Очистка данных: Гарантируйте, что данные чистые и корректные.
Сегментация: Выбор методики сегментации, размер сегмента (chunk_size) и перекрытие сегментов (overlap).
Модели векторизации: Выбор модели векторизации, включая размерность, и желание ли его доработать.
Метаданные: Использование метаданных и выбор метаданных.
Мульти-индексация: Решение о том, использовать ли несколько индексов для разных коллекций данных.
Алгоритмы индексации: Выбор и настройка алгоритмов ANN и сжатия векторов может быть настроена, но обычно не настраивается практиками.

И следующие стратегии на этапе вычислений (извлечение и генерация):

Преобразования запроса: Экспериментировать с перефразировкой, HyDE или подзапросами.
Параметры извлечения: Выбор техники поиска (alpha, если включен гибридный поиск) и количество полученных результатов поиска.
Расширенные стратегии извлечения: Использование расширенных стратегий извлечения, таких как окно предложения или автоматическое объединение результатов извлечения.
Модели переранжировки: Использование модели переранжировки, выбор модели переранжировки, количество результатов поиска для ввода в модель переранжировки и необходимость настройки модели переранжировки.
LLMs: Выбор LLM и необходимость настройки.
Инженерия запроса: Экспериментировать с различной формулировкой и примерами небольшого объема.

Понравилась эта история?

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

Получайте уведомления на почту при публикации Леони Монигатти.

Получайте уведомления на почту при публикации Леони Монигатти. Регистрируясь, вы создадите аккаунт VoAGI, если у вас его еще нет…

VoAGI.com

Найдите меня на LinkedIn, Twitter и Kaggle!

Ссылки

Литература

[1] Коннор Шортен и Эрика Карденас (2023). Weaviate Blog. Обзор оценки RAG (посещено 27 ноября 2023 года)

[2] Джерри Лью (2023). LlamaIndex Blog. Настройка вложений для RAG с помощью синтетических данных (посещено 28 ноября 2023 года)

[3] Документация LlamaIndex (2023). Построение производительных RAG-приложений для продакшена (посещено 28 ноября 2023 года)

[4] Voyage AI (2023). Вложения определяют качество RAG: кейс-стади Чат.LangChain (посещено 5 декабря 2023 года)

[5] Документация LlamaIndex (2023). Преобразования запроса (посещено 28 ноября 2023 года)

[6] Лю, Н.Ф., Линь, К., Хьюитт, Дж., Паранжапе, А., Бевила́ква, М., Петрони, Ф., & Лянг, П. (2023). Заблудившиеся посередине: Как языковые модели используют длинные контексты. Препринт arXiv arXiv:2307.03172.

[7] DeepLearning.AI (2023). Создание и оценка приложений на основе расширенной модели RAG (доступ от 4 декабря 2023 г.)

[8] Ахмед Бесбес (2023). Towards Data Science. Почему ваша модель RAG непригодна для использования в производственной среде (доступ от 27 ноября 2023 г.)

[9] Мэтт Амброджи (2023). Towards Data Science. 10 способов улучшить производительность систем генерации с использованием моделей с возвратным повышением (доступ от 27 ноября 2023 г.)