Практические соображения в проектировании приложения RAG

Практические аспекты проектирования приложения RAG

Это вторая часть анализа RAG:

• часть 1: Недостатки RAG
• часть 2: Практические аспекты проектирования приложения с применением RAG

Архитектура RAG (Retrieval Augmented Generation) доказала свою эффективность в преодолении ограничения на длину ввода LLM и проблемы ограничения знаний. В современном техническом стеке LLM, RAG является одной из основных составляющих для укоренения приложения на локальном знании, смягчения галлюцинаций и сделать приложения LLM проверяемыми. Существует множество примеров, как построить приложение RAG. Кроме того, есть различные типы векторных баз данных.

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

Повестка дня

• От 2D к 3D улучшение согласованности генерации текста в 3D с выравненными геометрическими условиями.
• Раскрытие прозрачности ИИ как группировка функций Anthropic улучшает интерпретируемость нейронных сетей
• Oracle представляет видение будущего, основанное на искусственном интеллекте и облачных технологиях

· Идеальный LLM-базовый уровень · Ожидания от производительности RAG · Сохранение информации · Преимущества и недостатки RAG · К лучшему RAG-приложению ∘ Обращайтесь к LLM с вниманием ∘ Сохранение модели встраивания на одной странице ∘ Важна стратегия сегментирования ∘ Сокращение потери информации ∘ Эмпатия LLM · Заключительные слова · Ссылки

Идеальный LLM-базовый уровень

Предположим у нас есть генеративная LLM с неограниченной длиной ввода, длина входной строки не влияет на точность генеративной LLM. Кроме этого, она ведет себя так же, как и все популярные LLM-модели. Давайте назовем эту модель идеальной LLM. Мы считаем ее идеальной не потому, что она имеет отличную производительность, а потому, что она обладает желаемой неограниченной длиной ввода, что в наши дни невозможно. Неограниченная длина ввода действительно привлекательная особенность. Фактически, уже существуют несколько амбициозных проектов, которые работают над моделями LLM с невероятной длиной ввода. Один из них исследует возможность LLM с длиной ввода в 1 миллион токенов! Однако, я боюсь, что даже ограничение в 1 миллион токенов может быть недостаточно в приложении, потому что оно всего лишь эквивалентно 4-5 МБ. Это все еще меньше, чем количество документов в реальном бизнесе.

Теперь вопрос: если у вас была такая идеальная LLM, все же рассмотрели бы вы архитектуру RAG? Идеальная LLM с неограниченной длиной ввода снижает необходимость в создании сложного RAG. Однако, вероятно да, все же нужно рассмотреть архитектуру RAG. Архитектура RAG помогает не только преодолеть ограничение на длину ввода LLM, но и снижает затраты на вызов LLM и улучшает скорость обработки. Генеративные LLM-модели должны обрабатывать контент последовательно. Чем длиннее ввод, тем медленнее обработка.

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

Ожидание производительности RAG

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

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

Поскольку все три фактора меньше 100%, ожидаемая точность RAG-приложения ниже, чем у приложения на основе той же идеальной LLM-модели. Если RAG не разработан правильно, его производительность снижается существенно. Это первое понятие, которое следует иметь в виду, когда мы начинаем думать о дизайне нашего RAG-приложения. В противном случае, неожиданная производительность нас удивит.

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

Сохранение информации

Легко понять, что модель LLM и семантический поиск не могут достичь 100% точности. Позвольте мне объяснить, что такое коэффициент сохранения информации в RAG.

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

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

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

1. Контекстная информация:

В большинстве случаев текст содержит несколько уровней контекстной информации. Например, книга “The Elements of Statistical Learning” состоит из 18 глав, каждая из которых фокусируется на определенной теме. В них есть подтемы и подподтемы в каждой главе и т. д. Люди привыкли воспринимать текст в контексте. Стратегия фрагментации отделяет контент от его контекста.

2. Позиционная информация:

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

3. последовательная информация:

Естественный текст часто использует явные и неявные лингвистические связи для связи тем. Например, история может начинаться с “в начале”, затем продолжаться с “тогда”, “поэтому”, “после этого” и так далее, пока не закончится с “в конечном итоге”, “наконец” и т.д. С использованием стратегии сегментации эта связь уже не является полной. Здесь отсутствуют не только загадки, но и порядок последовательности перемешивается.

4. описательная информация:

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

Сильные и слабые стороны RAG

Если мы называем RAG, который использует только сегментацию и векторный поиск сходства, “ванильными RAG”, мы можем увидеть, что они могут справляться только с несколькими типами запросов, потому что теряют часть информации о входе, о которой мы говорили ранее: 1. Хороши для узкоспециализированных вопросов, требующих описания. Например, какой предмет обладает определенными характеристиками?

2. Неудачны в случае рассуждения об отношениях, то есть поиск пути от субъекта A к субъекту B или идентификации связанных сущностей.

3. Неудачны при длинномзании суммирования. Например, “Перечислите все сражения Гарри Поттера” или “Сколько сражений у Гарри Поттера?”.

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

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

К лучшему приложению RAG

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

Обращаться с вашим LLM

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

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

Сохранение модели вклада на той же странице

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

1. Запросы пользователя короткие и имеют форму вопросов. Они содержат ограниченное количество семантических признаков. Тогда как встроенные векторы документов длинные и имеют более богатую информацию в своих векторах в различных формах высказываний.
2. Из-за ограниченных семантических признаков в запросе пользователя функция семантического поиска склонна слишком подробно анализировать мелкие детали в запросе. Вектор документа может содержать много шума. Сегментация ухудшает ситуацию, так как многие отношения, контексты и последовательные связи теряются.
3. Модели вложения и генеративные LLM-модели принадлежат к разным семействам. Они обучаются по-разному и имеют разное поведение. Модели вложения не обладают той же степенью рассуждений, что и генеративные LLM-модели. Они даже не так уважительно относятся к лингвистическим деталям, как генеративные LLM-модели. Прямой запрос от пользователя, в худшем случае, приведет к тому, что функция семантического поиска снизится до поиска по ключевым словам.
4. Так как модели вложения и генеративные LLM – это две разные модели, выполняющие разные функции во всем процессе, они “не находятся на одной странице”. Две модели выполняют свою работу в соответствии с собственным пониманием того, что требуется, но не общаются друг с другом. Полученная информация может не быть такой, какую LLM нужно для достижения наилучшего результата. У этих двух моделей нет способа согласования друг с другом.

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

Оригинальный пользовательский запрос: Расскажи мне о Тони Эбботе.

И измененные запросы, переделанные на основе оригинального запроса с использованием Bard:
– Какова политическая биография Тони Эббота?
– Какие наиболее заметные достижения Тони Эббота?
– Каковы политические взгляды Тони Эббота?
– Какие личные интересы Тони Эббота?
– В какие скандалы Тони Эббот был вовлечен?

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

Стратегия разделения на фрагменты важна

Размер фрагмента является одним из нескольких гиперпараметров, настраиваемых для применения RAG. Для достижения лучшего результата рекомендуется использовать меньшие размеры фрагментов. Один из таких анализов был проведен Microsoft [2]:

При разбивке текста мы также можем выбирать разные стратегии разделения. Самый простой способ – разделить по концу слова. Мы также можем попробовать разные стратегии, такие как разделение по концу предложения или абзаца. Для достижения еще лучшего результата мы можем наложить фрагменты на соседние. Сравнение стратегий разделения на фрагменты из анализа Microsoft [2]:

Модели внедрения имеют ограниченные возможности семантического извлечения. Они менее эффективны в представлении многообразных и многоходовых корпусов, чем простые модели. Вот почему RAG предпочитает более короткие фрагменты. Какой же размер фрагмента является наилучшим? В анализе Microsoft наименьший размер фрагмента составлял 512 токенов. Это, вероятно, было вдохновлено исследованием, показавшим, что меньшие фрагменты работают лучше; в некоторых коммерческих приложениях RAG размер фрагмента составлял всего ~100 токенов. Означает ли это, что наименьший размер фрагмента всегда дает лучший результат?

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

Снижение потери информации

Анализ Microsoft показал, что разделение на фрагменты с значительным количеством перекрытий повышает точность. В чем причина и может ли быть найден лучший способ улучшения производительности RAG?

Причина перекрытия состоит в том, что перекрытие помогает связывать смежные фрагменты и предоставлять лучшую контекстную информацию для фрагмента. Однако даже очень агрессивное перекрытие в 25% может повысить точность только на 1,5%, с 42,4% до 43,9%. Это означает, что это не самый эффективный способ оптимизации производительности RAG. Мы не можем дальше улучшать производительность RAG, повышая перекрытие. Помните, что перекрытие фрагментов не является вариантом для маленьких фрагментов.

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

Стратегия разделения перекрытия заключалась в том, чтобы последние несколько предложений предыдущего блока могли предоставить больше контекстной информации. И, как мы можем понять, последние несколько предложений могут не быть высоко репрезентативными. Вместо перекрытия, мы, вероятно, можем использовать сгенерированное ЛЛМ-ом краткое содержание предыдущего блока.

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

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

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

Не такой замысловатый, как RAG с Knowledge Graph, база данных с поддержкой векторного поиска также является очень важным компонентом в арсенале. База данных, например, pgvector, позволяет хранить сложную информацию в виде столбцов с сохранением функций семантического поиска. Она намного легче интегрируется с другими корпоративными системами и гораздо более гибкая, чем граф знаний.

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

LLM Эмпатия

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

• Есть ли у ЛЛМ всю необходимую информацию?
• Информация организована в дружественном для ЛЛМ способе?

Рассмотрим следующий пример:

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

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

проект AКонтакт клиента: СтивЧлены команды:человек Ачеловек Бэлектронная почта человека Аэлектронная почта человека Броль человека Ароль человека Бописание человека Аописание человека Бпроект B...

Если люди испытывают путаницу, чтобы понять, кто есть кто, то и RAG также испытывает трудности. Чтобы улучшить организацию информации, мы использовали код Python, чтобы агрегировать информацию вместе согласно свойствам HTML, разделили каждый проект и имена членов команды в отдельный текстовый файл и поместили информацию о каждом человеке в собственный файл:

файл project_A.txt:имя проекта: project_AКонтакт клиента: СтивЧлены команды:Адам СмитДжобс Маскфайл person_A.txt:имя: Адам Смитэлектронная почта: adam.smith@xxx.comроль: инженерописание: хобби/страсть: скалолазание...

Сгенерированные текстовые файлы являются небольшими, что, казалось бы, не соответствует практике разделения на блоки RAG. Причиной этому было то, что очень концентрированные файлы избежали проблемы разделения и полностью уменьшили шум. С новыми сгенерированными файлами RAG не возникают проблемы с ответом на вопросы типа “кто работает над проектом x?” и “какое хобби у Адама Смита?”.

Однако RAG испытывает трудности, когда мы меняем вопрос на обратный: “Над каким проектом работает Адам Смит?” Мы видим, что Адам Смит отображается среди участников проекта. Мы не очень уверены, почему модель встраивания не может это обнаружить. Чтобы помочь ЛЛМ добиться результата, мы можем подчеркнуть информацию. Мы добавили строку в файле человека, которая явно указывает на участие в проекте:

файл person_A.txt:имя: Адам Смитэлектронная почта: adam.smith@xxx.comроль: инженерописание: хобби/страсть: скалолазаниепроект: project_A

И эта дополнительная строка делает приложение RAG способным отвечать на вышеуказанные вопросы с точностью 100%.

Заключение

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

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

Ссылки

Устойчивость к подсказкам: как измерять и улучшать

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

pub.towardsai.net

Azure Cognitive Search: превосходство векторного поиска с гибридными возможностями поиска и ранжирования

Как найти лучший контент для питания ваших генеративных ИИ-моделей? В этой статье мы покажем вам, как использовать Azure…

techcommunity.microsoft.com

Что нам нужно знать, прежде чем принять векторную базу данных

Чтобы продолжить наш путь к применимому генеративному ИИ, я хотел бы обсудить некоторые проблемы…

VoAGI.com

Недостатки RAG

В последнее время рост больших языковых моделей (LLM) вызвал большой интерес к системам RAG. Многие практикующие…

VoAGI.com