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

Часть первая тут.

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

Для решения проблемы можно двигаться в нескольких направлениях.

1. Чтобы модель сама определяла, пользоваться ей результатами RAG или нет

На таком подходе основана методология FLARE (Forward Looking Active Retrieval Augmented Generation), которая сочетает в себе методы поиска для получения соответствующей информации из внешних источников данных с RAG и генеративными моделями и стремится смягчить галлюцинации путем интеграции внешней проверенной информации в процессе генерации.

Задача FLARE - ответить на 2 вопроса:

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

2. Что получить? FLARE не просто извлекает контент, но и оценивает следующее предложение, чтобы заранее получить данные и для него тоже.

Существует два типа FLARE - instruct и direct

FLARE Instruct. Этот режим предлагает модели генерировать определенные запросы для поиска информации. Модель приостанавливает генерацию, извлекает необходимые данные, а затем возобновляет работу, интегрируя новую информацию.

FLARE Direct. Модель использует сгенерированный контент в качестве прямого запроса для извлечения, когда она встречает токены с низкой достоверностью.

Пример работы с Flare можно найти в документации LlamaIndex.

“Можете ли вы рассказать мне о пути автора в мире стартапов?” - задается вопросом автор примера, используя в качестве датасета биографию Пола Грехема.

И вот какой результат выдает метод:

Текущий ответ: Прогнозный ответ: Автор начал свой путь в мире стартапов с помощью [Поиск (Чем автор занимался в мире стартапов?)]

Здесь мы видим, что метод возвращает начало фразы, а затем тут же самостоятельно задается новым вопросом для поиска - чем же автор занимался в мире стартапов?

Следующим шагом ответ на него также находится в документе:

Обновленный прогнозный ответ: Автор начал свой путь в мире стартапов, основав Y Combinator (YC), акселератор стартапов, который пакетно предоставлял финансирование и поддержку стартапам. Они стремились решить проблемы в индустрии венчурного капитала, делая большее количество мелких инвестиций, финансируя более молодых и более технических основателей и позволяя основателям оставаться генеральными директорами. Автор также написал Hacker News, агрегатор новостей, изначально предназначенный для основателей стартапов, на новой версии языка программирования Arc.

Далее модель делает второй шаг, отталкиваясь от только что построенного ответа и задаваясь новым вопросом: с какими известными стартапами работал автор?

Текущий ответ: Автор начал свой путь в мире стартапов с того, что стал соучредителем Y Combinator (YC), акселератора стартапов, который пакетно предоставлял финансирование и поддержку стартапам. Они стремились решить проблемы в индустрии венчурного капитала, делая большее количество мелких инвестиций, финансируя более молодых и более технических основателей и позволяя основателям оставаться генеральными директорами. Автор также написал Hacker News, агрегатор новостей, изначально предназначенный для основателей стартапов, на новой версии языка программирования Arc. Прогнозный ответ: с тех пор автор занимался наставничеством и консультированием многочисленных стартапов, помогая им расти и добиваться успеха в своих отраслях. [Поиск(С какими известными стартапами работал автор?)] Обновленный прогнозный ответ: с тех пор автор занимался наставничеством и консультированием многочисленных стартапов, помогая им расти и добиваться успеха в соответствующих отраслях. В число известных стартапов, с которыми работал автор, входят Reddit, Джастин Кан и Эммет Шир (который впоследствии основал Twitch), Аарон Шварц (который помог написать спецификацию RSS) и Сэм Альтман (который позже стал вторым президентом YC). Текущий ответ: Автор начал свой путь в мире стартапов с того, что стал соучредителем Y Combinator (YC), акселератора стартапов, который пакетно предоставлял финансирование и поддержку стартапам. Они стремились решить проблемы в индустрии венчурного капитала, делая большее количество мелких инвестиций, финансируя более молодых и более технических основателей и позволяя основателям оставаться генеральными директорами. Автор также написал Hacker News, агрегатор новостей, изначально предназначенный для основателей стартапов, на новой версии языка программирования Arc. С тех пор автор занимался наставничеством и консультированием многочисленных стартапов, помогая им расти и добиваться успеха в своих отраслях. В число известных стартапов, с которыми работал автор, входят Reddit, Джастин Кан и Эммет Шир (который впоследствии основал Twitch), Аарон Шварц (который помог написать спецификацию RSS) и Сэм Альтман (который позже стал вторым президентом YC). Упреждающий ответ: готово

И наконец итоговый ответ пользователю:

Свой путь в мире стартапов автор начал с того, что стал соучредителем Y Combinator (YC), акселератора стартапов, который порционно обеспечивал финансирование и поддержку стартапов. Они стремились решить проблемы в индустрии венчурного капитала, делая большее количество мелких инвестиций, финансируя более молодых и более технических основателей и позволяя основателям оставаться генеральными директорами. Автор также написал Hacker News, агрегатор новостей, изначально предназначенный для основателей стартапов, на новой версии языка программирования Arc. С тех пор автор занимался наставничеством и консультированием многочисленных стартапов, помогая им расти и добиваться успеха в своих отраслях. В число известных стартапов, с которыми работал автор, входят Reddit, Джастин Кан и Эммет Шир (который впоследствии основал Twitch), Аарон Шварц (который помог написать спецификацию RSS) и Сэм Альтман (который позже стал вторым президентом YC).

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

2. Найти способ отличать правильные ответы от неправильных

Corrective RAG (CRAG)

CRAG состоит из трех основных компонентов:

1. Генеративная модель: отвечает за создание предварительной последовательности генерации авторегрессионным способом.

2. Модель поиска: средство поиска, которое выбирает соответствующие отрывки из источника знаний на основе предварительного создания и контекста.

3. Оркестратор: контролирует итерацию между генератором и приемником, ранжирует кандидатов на создание и определяет окончательную выходную последовательность. Оркестратор — это клей, который связывает ретривер и генератор в CRAG. Он поддерживает состояние незавершенного текста, сгенерированного на данный момент, запрашивает кандидатов из генератора для расширения этого текста, извлекает знания с использованием обновленного контекста, оценивает кандидатов как с точки зрения текстовой вероятности, так и с точки зрения фактического выравнивания, и, наконец, выбирает верхнего кандидата для добавления к выходным данным на каждый шаг поколения. [2]

Но самым важным компонентом CRAG является оценщик ретривера, он количественно определяет степень достоверности каждого документа ( Верно, Неверно , Неоднозначно ), на основе которой могут быть инициированы различные действия по извлечению знаний.

Когда поиск успешен

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

Когда поиск не успешен

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

Неопределенность

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

CRAG имеет безусловные плюсы для применения:

• улучшает согласованность фактов.

• ощутимо снижает число галлюцинаций, как описали в статье исследователи, им удалось добиться 84% случаев, когда результаты содержали достоверные факты.

• модульность метода позволяет гибко интегрировать любые модели ретриверов, генераторов и других компонентов.

Из узких мест можно выделить 2:

• многоходовая стратегия и необходимость искать информацию на внешних ресурсах существенно замедляют его относительно простого RAG.

• охват источников знаний имеет решающее значение для качества поиска.

Пример реализации метода от авторов можно найти тут

Внедрение метода в llamaIndex тут

3. Исключать лишнюю информацию за счет размеров эмбеддингов

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

Разработчики векторной базы Pinecone предложили свои стратегии выбора длины эмбеддингов [3], приведу здесь несколько доводов:

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

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

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

1. Каков характер индексируемого контента?

   Работаете ли вы с длинными документами, такими как статьи или книги, или с более коротким контентом, например твитами или мгновенными сообщениями?

2. Какую модель эмбеддингов вы используете и на каких размерах фрагментов она работает оптимально?

3. Каковы ваши ожидания относительно длины и сложности пользовательских запросов?

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

4. Как полученные результаты будут использоваться в вашем конкретном приложении?

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

Для самостоятельных экспериментов рекомендую демо, собранное на документах arxiv, которое показывает, как меняются результаты поиска в зависимости от выбора той или иной длины.

RAPTOR

Архитектура RAPTOR состоит из трех основных компонентов: процесса построения дерева, методов поиска и системы запросов и ответов.

Процесс построения дерева RAPTOR начинается с сегментирования корпуса поиска на короткие, смежные тексты примерно по 100 токенов каждый. Эти фрагменты текста затем встраиваются с помощью SBERT, образуя конечные узлы древовидной структуры [4].

Для группировки похожих фрагментов текста RAPTOR использует алгоритм кластеризации, основанный на моделях гауссовой смеси (GMM). GMM предполагают, что точки данных генерируются из смеси нескольких гауссовых распределений, что позволяет использовать мягкую кластеризацию, при которой узлы могут принадлежать нескольким кластерам, не требуя фиксированного количества кластеров. Чтобы смягчить проблемы, связанные с высокой размерностью векторных вложений, RAPTOR использует аппроксимацию и проекцию равномерного многообразия (UMAP) для уменьшения размерности.

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

RAPTOR имеет несколько сильных сторон:

• Иерархическая структура, учитывающая разные уровни абстракции

• Масштабируемость

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

Узким местом всех методов с несколькими уровнями векторов является необходимость строить кратно большее количество векторов, чем в обычном RAG.

Пример реализации метода от авторов тут

Реализация в llamaIndex тут

4. Искать не среди ответов, а среди вопросов

Попросить LLM сгенерировать вопрос для каждого фрагмента текста и построить на этих вопросах эмбеддинги, чтобы искать не среди ответов, а среди вопросов, а затем по найденному вопросу обращаться к исходному. Этот подход улучшает качество поиска благодаря более высокому семантическому сходству между запросом и гипотетическим вопросом по сравнению с тем, что мы имели бы для реального фрагмента. Существует также подход с обратной логикой, называемый HyDE[5], когда мы просим LLM сгенерировать гипотетический ответ на основе запроса, а затем используем его эмбеддинг вместе с эмбеддингом запроса для повышения качества поиска.

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

Реализация в llamaIndex тут

Заключение

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

Использованные источники:

[1] - Active Retrieval Augmented Generation

[2] - Corrective Retrieval Augmented Generation

[3] - Chunking Strategies for LLM Applications

[4] - RAPTOR: RECURSIVE ABSTRACTIVE PROCESSING FOR TREE-ORGANIZED RETRIEVAL

[5] - Precise Zero-Shot Dense Retrieval without Relevance Label