Как справиться с проблемами актуализации в усиленной генерации извлечения

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

Построение генеративных приложений искусственного интеллекта, использующих retrieval augmented generation (RAG), может вызвать ряд проблем. Давайте рассмотрим устранение неполадок в реализации RAG, которая основана на векторных базах данных для извлечения соответствующего контекста, включаемого в запрос к большой языковой модели для получения более актуальных результатов.

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

Здесь мы рассмотрим три основных области, которые могут привести к низкому качеству результатов: неоптимальные модели вложений, неэффективные стратегии фрагментации и отсутствие фильтрации метаданных. (В следующей статье мы рассмотрим фактическое взаимодействие с LLM и рассмотрим некоторые распространенные проблемы, которые могут привести к плохим результатам.)

Выбор подходящей модели вложения

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

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

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

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

1. текстовое вложение-ada-002 (Ada v2)

Ada v2 от OpenAI вероятно, является наиболее распространенной отправной точкой для большинства приложений RAG только потому, что так много разработчиков начинают с API Open AI. Ada v2 впечатляет своими результатами в случаях использования извлечения и была создана для работы с различными типами контента, включая текст и код. С максимальной длиной вводной последовательности до 8 192 токенов она также позволяет создавать вложения для гораздо более длинных текстовых фрагментов по сравнению со заменяющими ее моделями. Это и благословение и проклятие. Большой размер последовательности упрощает процесс создания вложений для большего количества текстового контента и позволяет вложенной модели идентифицировать связи между словами и предложениями в большем объеме текста.

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

У Ada v2 есть два больших недостатка. Во-первых, ее нельзя запустить локально. Для создания вложения необходимо использовать API OpenAI. Это не только может вызвать узкие места в случаях, когда вам нужно создавать вложения для многих фрагментов контента, но также увеличивает стоимость на $0,0001 за 1 000 токенов. Во-вторых, вложения, созданные на основе модели Open AI, имеют размерность 1536 измерений каждое. Если вы используете векторную базу данных в облаке, это может значительно увеличить затраты на хранение векторов.

Когда выбрать: Вы ищете простое решение, которое требует только вызов API, вам, возможно, нужно векторизовать большие документы, и стоимость не является проблемой.

2. jina-вложение-v2 (Jina v2)

Jina v2 – это новая встраиваемая модель с открытым исходным кодом, которая предоставляет ту же поддержку вводной последовательности в 8000 токенов, что и Ada v2, и фактически имеет немного лучшую результативность в случаях использования извлечения.

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

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

3. bge-large-en-v1.5

bge-large-en-v1.5 был опубликован под лицензией MIT и в настоящее время является моделью векторизации с наибольшим рейтингом на доске лидеров MTEB для случаев поиска. При использовании меньшей последовательности входных данных вы должны внимательно продумать стратегию отрезания, но в конечном итоге это обеспечивает лучшую общую производительность для случаев поиска.

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

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

Оптимизация стратегии отрезания

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

Отрезание фиксированной длины

  • Когда использовать: Если ваш контент сам по себе имеет высокую структурированность и фиксированную длину, вам обычно следует полагаться на более полезную стратегию отрезания, подобные описанным далее.
  • Технические соображения: Хотя эту стратегию очень просто реализовать, она обычно приводит к плохим результатам в случаях использования RAG.
  • Дополнительная информация: Если вы используете фиксированную стратегию отрезания с вашим приложением RAG и испытываете проблемы с извлечением соответствующего контекста, вам следует рассмотреть переход к другому подходу отрезания.

Отрезание на уровне предложений

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

Отрезание на уровне параграфов

  • Когда использовать: Используйте эту стратегию, когда входной текст организован в отдельные разделы или параграфы, каждый из которых содержит отдельную идею или тему. Это позволяет модели сосредоточиться на актуальной информации в каждом параграфе.
  • Технические соображения: Выделение границ параграфов обычно включает обнаружение символов новой строки или других разделителей, указывающих на конец параграфа.
  • Дополнительная информация: Отрезание на уровне параграфов может быть полезным, когда у вас есть документы, охватывающие множество аспектов одной и той же темы. Например, страница документации к продукту может представлять функцию продукта, объяснять, когда ее следует использовать, рассказывать о способах ее настройки и давать примеры различных конфигураций. Использование отрезания на уровне параграфов поможет вам определить наиболее актуальную часть документа для предоставления в качестве контекста для модели.

Отрезание, учитывающее контекст

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

Рекурсивное Чанкирование

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

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

Рассмотрение Контекстного Окна

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

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

Фильтрация Метаданных

С увеличением количества встроенных эмбеддингов в вашем поисковом индексе, приближенные ближайшие соседи (ANN) становятся менее полезными при поиске релевантного контекста для включения в ваши подсказки. Допустим, у вас есть индекс эмбеддингов для 200 статей в вашей базе знаний. Если вы можете определить двух наиболее близких соседей с точностью 1%, то вы, вероятно, найдете довольно релевантные результаты, потому что 1% представляет собой две самые лучшие статьи из этих 200, и вы получите одну из этих двух.

Теперь представьте себе поисковый индекс, содержащий каждую статью в Википедии. Это примерно 6,7 миллионов статей. Если ваш ближайший сосед находится в 1% наиболее похожих статей, это означает, что вы получаете одну из 67 000 наиболее похожих статей. С таким корпусом, это означает, что вы все равно можете сильно ошибиться.

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

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