Нужны более релевантные ответы LLM? Решите эти проблемы поиска дополненной генерации (часть 1)

В первой части этой серии из двух частей мы рассмотрим, как неоптимальные модели внедрения, неэффективные стратегии фрагментирования и отсутствие фильтрации метаданных могут затруднить получение релевантных ответов от вашего LLM. Вот как преодолеть эти проблемы. Создание генеративных приложений искусственного интеллекта, использующих (RAG) может создать множество проблем. Давайте рассмотрим устранение неполадок реализаций RAG, которые полагаются на векторные базы данных для извлечения соответствующего контекста, который затем включается в приглашение к большой языковой модели для получения более релевантных результатов. поиск дополненной генерации Мы разобьем этот процесс на две основные части. Первый, о котором мы поговорим в этой первой статье серии, — это конвейер внедрения, который заполняет с вложениями: векторная база данных Здесь мы рассмотрим три основные области, которые могут привести к плохим результатам: неоптимальные модели внедрения, неэффективные стратегии фрагментации и отсутствие фильтрации метаданных. (В следующей статье мы рассмотрим фактическое взаимодействие с LLM и рассмотрим некоторые распространенные проблемы, которые возникают там и могут привести к плохим результатам.) Выбор подходящей модели внедрения Выбор модели внедрения окажет существенное влияние на общую актуальность и удобство использования вашего приложения RAG. По существу, это требует детального понимания возможностей каждой модели и анализа того, как эти возможности соответствуют требованиям вашего приложения. Если вы относительно новичок в RAG и встраиваниях в целом, вам следует знать один из лучших ресурсов: . В этой статье мы сосредоточимся на вариантах использования поиска, но встраивания, конечно, можно использовать для многих других приложений, включая классификацию, кластеризацию и суммирование. Таблица лидеров встраивания MTEB (Massive Text Embedding Benchmark) Таблица лидеров поможет вам определить модели, которые лучше всего подойдут для вашего конкретного случая использования. Одна из наиболее распространенных причин плохой производительности RAG заключается в том, что разработчики, впервые работающие в этой области, выполняют поиск в Google, чтобы найти примеры встроенной генерации. Они часто обнаруживают образцы, в которых используются модели внедрения, такие как Word2Vec, sBERT и RoBERTa, которые являются плохим выбором для случаев использования поиска. Если вы нашли эту статью, потому что занимаетесь отладкой плохих результатов релевантности и использовали что-то вроде sBERT для создания вложений, то мы, вероятно, определили причину ваших проблем с релевантностью. Если да, то следующий вопрос, который у вас, скорее всего, возникнет, — какие модели внедрения вы можете использовать для улучшения результатов поиска по сходству. Не зная особенностей вашего варианта использования, мы бы порекомендовали три: text-embedding-ada-002 (Ада v2) вероятно, является наиболее распространенной отправной точкой для большинства приложений RAG просто потому, что многие разработчики начинают с API Open AI. Ada v2 превосходно работает при поиске данных и была создана для обработки различных типов контента, включая текст и код. Ада v2 от OpenAI Благодаря максимальной длине входной последовательности до 8192 токенов он также позволяет создавать вложения для гораздо более длинных фрагментов текста, чем альтернативные модели. Это одновременно благословение и проклятие. Наличие большого размера последовательности упрощает процесс создания вложений для большей части вашего текстового контента и позволяет модели внедрения выявлять отношения между словами и предложениями в большем объеме текста. Однако это также приводит к поиску по сходству, который может стать более нечетким при сравнении сходства двух длинных документов, когда вы ищете релевантные фрагменты контекста для облегчения процесса генерации. У Ada v2 есть два больших недостатка. Во-первых, его нельзя запустить локально. Для создания встраивания необходимо использовать API OpenAI. Это может не только создать узкие места в случаях, когда вы хотите создать встраивания для многих фрагментов контента, но также добавить стоимость в размере 0,0001 доллара США за 1000 токенов. Во-вторых, каждое из внедрений, созданных на основе модели Open AI, имеет 1536 измерений. Если вы используете облачную базу данных векторов, это может значительно увеличить затраты на хранение векторов. вам нужно простое решение, требующее только вызова API, вам потенциально потребуется векторизовать большие документы, и стоимость не является проблемой. Когда выбирать: jina-embeddings-v2 (Jina v2) Jina v2 — это новая модель внедрения с открытым исходным кодом, которая обеспечивает ту же поддержку 8000 входных последовательностей, что и Ada v2, и на самом деле показывает немного лучшие результаты в случаях использования извлечения данных. Jina v2 предоставляет противоядие от проблем Ada v2. Он имеет под лицензией Apache 2.0 и может запускаться локально, что, конечно, также является недостатком, если вы не хотите запускать для этого собственный код. Он также создает вектор внедрения с половиной размеров Ada v2. открытый исходный код Таким образом, вы не только получаете немного лучшую производительность поиска в тестовых сценариях использования, но также получаете улучшенные результаты при меньших требованиях к памяти и вычислениям с точки зрения векторной базы данных. вы хотите использовать решение с открытым исходным кодом и потенциально нуждаетесь в векторизации больших документов, а также вам удобно запускать конвейеры внедрения локально. Вы хотите снизить затраты на векторную базу данных за счет встраивания меньшей размерности. Когда выбирать: bge-large-en-v1.5 имеет открытый исходный код под лицензией MIT и в настоящее время занимает первое место в рейтинге моделей встраивания в таблице лидеров MTEB для сценариев использования поиска. Благодаря меньшей входной последовательности вам потребуется больше внимания уделять стратегии разбиения на фрагменты, но в конечном итоге она обеспечивает наилучшую общую производительность для вариантов использования извлечения. bge-large-en-v1.5 Когда выбирать: вы хотите использовать решение с открытым исходным кодом и готовы тратить больше времени на стратегии разбиения на фрагменты, чтобы не выходить за пределы ограничений размера входных данных. Вам удобно запускать встраиваемые конвейеры локально. Вам нужна наиболее эффективная модель внедрения для сценариев использования поиска. Хотя это выходит за рамки этой статьи, вы, возможно, захотите углубиться в 15 тестов в таблице лидеров MTEB, чтобы определить тот, который наиболее близко соответствует вашей конкретной ситуации. Хотя определенно существуют закономерности в том, насколько хорошо различные модели внедрения работают в разных тестах, часто в каждом из них есть конкретные модели, которые выделяются. Если вам необходимо уточнить выбор встраивания, это возможная область дальнейшего исследования. Оптимизация стратегии разбиения на части Сегментация или «разбивка» входного текста является ключевым фактором, который существенно влияет на релевантность и точность сгенерированного вывода. Различные стратегии фрагментации предлагают уникальные преимущества и подходят для конкретных типов задач. Здесь мы углубимся в эти методологии и предоставим рекомендации по их применению, учитывая некоторые ключевые соображения: Разбиение на фрагменты фиксированной длины . Если ваш контент сам по себе не очень структурирован и не имеет фиксированной длины, вы обычно предпочитаете использовать более полезную стратегию разбивки на фрагменты, подобную приведенной ниже. Когда использовать . Несмотря на то, что эта стратегия разделения на фрагменты очень проста в реализации, обычно она приводит к плохим результатам в приложениях RAG. Техническое соображение Если вы используете стратегию фиксированной длины в своем приложении RAG и испытываете проблемы с получением соответствующего контекста, вам следует рассмотреть возможность перехода на другой подход к фрагментированию. Дополнительная информация. Разбиение на уровни предложений . Эта стратегия эффективна, когда каждое предложение во входном тексте богато смыслом и контекстом. Это позволяет модели сконцентрироваться на тонкостях каждого предложения, тем самым генерируя более последовательные и контекстуально релевантные ответы. В сценариях использования RAG вы редко будете полагаться на фрагментирование на уровне предложений. Когда использовать Разбиение на блоки на уровне предложений часто включает токенизацию на основе границ предложений, чего можно добиться с помощью библиотек обработки естественного языка (NLP). Техническое соображение . Разбиение на части на уровне предложений может быть особенно полезно при поиске конкретных утверждений, например, в стенограмме собрания, где вы пытаетесь найти семантически схожие утверждения для данного фрагмента текста. Дополнительная информация . Разбиение на уровни абзацев . Используйте эту стратегию, когда входной текст разделен на отдельные разделы или абзацы, каждый из которых отражает отдельную идею или тему. Это позволяет модели сосредоточиться на соответствующей информации в каждом абзаце. Когда использовать Определение границ абзаца обычно включает в себя обнаружение символов новой строки или других разделителей, которые обозначают конец абзаца. Техническое соображение . Разбиение на блоки на уровне абзацев может быть полезно, если у вас есть документы, охватывающие множество различных аспектов одной и той же темы. Например, на странице документации продукта может быть представлена функция продукта, объяснено, когда ее использовать, рассказано о том, как ее настроить, и приведены примеры различных конфигураций. Дополнительная информация . Использование фрагментов на уровне абзацев может помочь вам определить наиболее релевантную часть документа для предоставления LLM в качестве контекста. Разбиение на фрагменты с учетом содержимого Выбирайте эту стратегию, когда релевантность определенных разделов текста имеет первостепенное значение. Например, в юридических документах сегментирование текста по пунктам или разделам может дать больше ответов, зависящих от контекста. Когда использовать . Этот подход может потребовать передовых методов НЛП для понимания семантических границ в тексте. Техническое рассмотрение . Разбиение на фрагменты с учетом содержимого особенно полезно при работе со структурированными или полуструктурированными данными, поскольку определенные фрагменты можно комбинировать с фильтрацией метаданных для более точного поиска. Дополнительная информация . Например, в юридическом документе вам может потребоваться извлечь все положения о гарантиях или возмещении убытков, а при сохранении вложений фрагментов в векторной базе данных вы можете использовать метаданные, чтобы упростить поиск контента заданного типа при построении базы данных. Вариант использования RAG. Рекурсивное разбиение на фрагменты Рекурсивное разбиение на фрагменты делит данные на все более мелкие части, используя иерархический подход. Например, при разбивке текстового документа вы можете сначала разделить текст на абзацы, затем на предложения и, наконец, на слова. Когда использовать . После того как данные разделены на первый набор фрагментов, вы можете рекурсивно применить процесс фрагментирования к каждому из меньших фрагментов, повторяя до тех пор, пока не достигнете наименьшего размера фрагмента, который вас интересует. Реализация рекурсивного разбиения на фрагменты может включать в себя стратегию многоуровневого анализа, при которой фрагменты далее делятся на подфрагменты на основе дополнительных критериев. Если вы используете , его рекурсивная реализация немного проще, чем описано здесь. Техническое соображение . Лангчейн Этот подход позволяет модели понимать контекст на нескольких уровнях, от тем высокого уровня до подробных нюансов, что делает ее особенно полезной для сложных документов, таких как научные статьи, технические руководства или юридические контракты. Это обеспечивает преимущества гибкости, поскольку поиск по сходству может идентифицировать похожий текст как для более широких, так и для более коротких запросов. Дополнительная информация . Однако это также означает, что существует вероятность того, что похожие фрагменты из одного и того же исходного документа могут оказаться перепредставленными при поиске по сходству, особенно если вы выберете более длительное перекрытие между фрагментами в конфигурации вашего разделителя текста. В качестве общего подхода, прежде чем пытаться разбить большой корпус и векторизовать его, вам следует подумать о проведении некоторых специальных экспериментов с вашими данными. Вручную проверьте документы, которые вы хотели бы получить по заданному запросу, определите фрагменты, которые представляют идеальный контекст, который вы хотели бы предоставить LLM, а затем поэкспериментируйте со стратегиями фрагментирования, чтобы увидеть, какой из них дает вам фрагменты, которые, по вашему мнению, будут наиболее релевантными. чтобы LLM имел. Рассмотрение контекстного окна Доступное контекстное окно LLM является важным фактором при выборе стратегии разбиения на фрагменты. Если контекстное окно маленькое, вам придется более избирательно подходить к фрагментам, которые вы вводите в модель, чтобы обеспечить включение наиболее актуальной информации. И наоборот, большее контекстное окно обеспечивает большую гибкость, позволяя включать дополнительный контекст, который может улучшить выходные данные модели, даже если не все из них строго необходимы. Экспериментируя с этими стратегиями разбиения на фрагменты и принимая во внимание эти соображения, вы можете оценить их влияние на релевантность сгенерированных результатов. Ключевым моментом является согласование выбранной стратегии с конкретными требованиями вашего приложения RAG, сохранение семантической целостности входных данных и обеспечение всестороннего понимания контекста. Это позволит вам найти правильный процесс разбиения на блоки для достижения оптимальной производительности. Фильтрация метаданных По мере роста количества вложений в вашем поисковом индексе приблизительные ближайшие соседи (ANN) становятся менее полезными при поиске соответствующего контекста для включения в ваши подсказки. Допустим, вы проиндексировали встраивания для 200 статей в вашей базе знаний. Если вы сможете определить верхнего ближайшего соседа с точностью 1%, вы, скорее всего, получите весьма релевантные результаты, поскольку 1% представляет собой две лучшие статьи из этих 200, и вы получите одну из этих двух. Теперь рассмотрим поисковый индекс, содержащий все статьи в Википедии. Это составит примерно 6,7 миллиона статей. Если ваш ближайший сосед входит в топ-1% большинства похожих статей, это означает, что вы получаете одну из 67 000 наиболее похожих статей. С таким корпусом, как Википедия, это означает, что вы все равно можете оказаться очень далекими от цели. Фильтрация метаданных дает вам возможность сузить фрагменты контента, сначала фильтруя документы, а затем применяя алгоритм ближайшего соседа. В случаях, когда вы имеете дело с большим количеством возможных совпадений, эта первоначальная предварительная фильтрация может помочь вам сузить возможные варианты перед получением ближайших соседей. Далее мы углубимся во взаимодействие с LLM и рассмотрим некоторые распространенные проблемы, которые могут привести к плохим результатам. . Пытаться DataStax Astra БД , единственная векторная база данных для создания приложений искусственного интеллекта производственного уровня на основе данных в реальном времени Крис Латимер, DataStax Также опубликовано здесь