CAG и KAG: Улучшенные методы дополнения генерации после RAG

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Доброго времени суток, уважаемые хабровчане. Меня зовут Кирилл Кухарев и я являюсь разработчиком в компании Raft. Про RAG в блоге нашей компании написано уже внушительное количество статей. Если кто-то не знаком с этой технологией или только начинает изучать, рекомендую обратить ваше внимание на статью Игоря про архитектуру RAG, статью Сони про выбор фреймворков для создания RAG и статью Никиты тоже про RAG, но обо всем по чуть-чуть. Если говорить вкратце, то технология RAG - это как библиотекарь и писатель в одном лице. Когда вы задаете ему вопрос, то он сначала копается в огромной библиотеке (например, в одной или нескольких базах данных или корпусах документов), чтобы найти необходимую информацию, а затем использует генеративную модель, чтобы создать ответ на основе информации, которую нашел.

CAG - это что за покемон ?

Теперь представьте, что библиотекарь, которого часто спрашивают одну и ту же информацию уже не ищет ее в библиотеке, а выдает ее "на лету". Это и есть Cache-Augmented Generation (CAG). Вместо того чтобы каждый раз брать информацию из базы знаний, CAG проверяет свой кэш.

Сравнение RAG и CAG из официального репозитория
Сравнение RAG и CAG из официального репозитория

Ключевой концепцией CAG является Key-Value(KV) кэш. Когда LLM обрабатывает запрос пользователя, она создает пары ключ-значение, где ключ - это метка, а значение - это информация, связанная с этой меткой. Обычно, после завершения генерации ответа, все созданные пары просто удаляются. CAG не удаляет эти метки, а использует для последующих запросов. Таким образом взяв коллекцию документов, мы вычисляем кэш KV для всех этих документов, сохраняем его и используем в процессе вывода. Далее процесс делится на три этапа:

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

  • Инференс. Во время инференса (когда поступает вопрос от пользователя) загружается кэш KV и вопрос. Затем LLM использует этот кэш для генерации ответов. Таким образом, отсутствует задержка при получении ответа.

  • Очистка кэша. Кэш KV растет в процессе вывода (каждый раз, когда мы вешаем новые токены, особенно если мы рассматриваем несколько взаимодействий между пользователем и LLM). Чтобы избежать перенасыщения количества входных данных, которые может принять LLM (длина контекста), мы можем использовать усечение как простой метод очистки кэша. Таким образом, нам не придется каждый раз заново инициализировать кэш.

Например авторы этой статьи используют 2 набора данных для создания собственного набора и дальнейшего сравнения RAG и CAG:

  • Stanford Question Answering Dataset (SQuAD) 1.0 Содержит более 100 000 вопросов по статьям Википедии, где ответом является фрагмент текста, взятый из статьи.

  • HotPotQA dataset. Состоит из более 100 000 пар вопрос-ответ.

Набор данных для сравнения CAG и RAG
Набор данных для сравнения CAG и RAG

Затем авторы используя модель Llama 3.1 8B Instruction (128K токенов длины контекста) проверили с помощью BERTScore, что модель адекватно отвечает на вопросы. Они составили свою систему из двух версий RAG (одна с использованием разреженных векторов, другая - с использованием плотных векторов).

Ликбез по векторам

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

Оценка качества ответов на основе метрики точности  top k
Оценка качества ответов на основе метрики точности top k

Несмотря на то, что CAG показал высокие результаты, авторы не берут во внимание тот факт, что:

  1. Было проведено мало экспериментов;

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

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

Ключевыми недостатками CAG является ограничение контекстного окна LLM и высокая стоимость запросов из-за большого количества информации (токенов) в запросе.

Парировать данный недостаток можно тем фактом, что контекст передовых больших языковых моделей постоянно растет и стоимость запросов к моделям (как локальным - расход мощностей на вычисления, так и по API) снижается. Более того, если вы общаетесь с LLM последних версий по API, то могли заметить, что в них появляется подход Prompt Caching. Например у моделей OpenAI стоимость запросов снижается практически в 2 раза при отправке запроса с теми токенами, которые модель уже видела (например, системный промпт).

К тому же на данном этапе развития LLM можно совместить возможности CAG и RAG. Если ответ на вопрос удается найти в кэше, то он мгновенно возвращается, если нет, то запускается стандартный RAG процесс поиска ответа и генерации.

Когда необходимо использовать CAG?

  • Ваша база знаний помещается в контекстное окно модели.

  • Вам нужны сверхбыстрые ответы.

  • Ваши данные меняются нечасто.

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

  • Вы не видите снижения качества по сравнению с RAG.

KAG или как заставить RAG лучше понимать взаимосвязи сущностей в данных

Knowledge Augmented Generation (KAG) — это фреймворк, который улучшает обработку информации за счет интеграции графов знаний в RAG. Основой KAG является способность представлять знания таким образом, чтобы они были доступны и интерпретируемы для LLM. Используя фреймворк LLMFriSPG, система организует информацию иерархически, вдохновляясь моделью DIKW(data, information, knowledge, wisdom). Эта структура объединяет:

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

KAG состоит из трех основных компонентов - KAG-Builder, KAG-Solver и KAG-Model.

Благодаря KAG производительность LLM повышается в трех ключевых областях:

Сравнение KAG, RAG и CAG

Параметр

RAG

KAG

CAG

Основа поиска

Векторное сходство

Графы знаний + семантическое выравнивание

Кэшированные ответы + семантическое/ключевое совпадение

Логические связи

Ограниченный учет

Полная интеграция через KG

Зависит от кэша: ограниченная, если кэш не содержит связей

Обработка данных

Неструктурированные тексты

Гибрид (структурированные + неструктурированные)

Кэшированные структурированные/неструктурированные данные

Точность в доменах

Средняя (общие сценарии)

Высокая (профессиональные домены)

Высокая для повторяющихся запросов, низкая для новых

Многошаговые рассуждения

Частичная поддержка

Полная поддержка

Ограничена содержимым кэша

Ключевая инновация

Поиск + генерация

Графы знаний + гибридные рассуждения

Повторное использование кэшированных ответов

Преимущества

Простота внедрения

Логическая связность, точность

Скорость, снижение вычислительных затрат

Недостатки

Низкая точность в сложных доменах

Высокие требования к ресурсам

Риск устаревания кэша, ограниченная гибкость

Заключая, можно отметить, что развитие методов CAG и KAG знаменует важный шаг вперёд в эволюции генеративных систем. С одной стороны, CAG благодаря кэшированию позволяет добиться мгновенных ответов и оптимизации вычислительных затрат при повторном использовании уже извлечённой информации. С другой стороны, интеграция графов знаний в KAG открывает новые возможности для точного и логически последовательного вывода, что особенно актуально для специализированных доменов. Несмотря на существующие ограничения – от объёма контекстного окна до высокой стоимости запросов – объединение возможностей RAG, CAG и KAG демонстрирует потенциал для создания гибридных систем, способных обеспечить максимально эффективное использование накопленных данных и интеллектуальное взаимодействие с пользователями. 
А что вы думаете по этому поводу? Буду рад услышать ваш опыт внедрения подобных решений и трудности, которые возникли при внедрении.

Источник: https://habr.com/ru/companies/raft/articles/891368/


Интересные статьи

Интересные статьи

Привет, Хабр! В этой статье хочу рассказать, как мы в ОТП Банке делали новый титульный экран платежей. Это один из первых кейсов, когда в трайбе Digital мы постарались применить продуктовый подход, а ...
Статья, которая рассказывает о процессе выгрузки данных из базы данных Microinvest в систему 1С Битрикс. В ней подробно описываются шаги, необходимые для успешной выгрузки, начиная от подготовки и нас...
Mojo - это новый язык программирования, основанный на Python, который устраняет проблемы с производительностью Python и развертыванием проектов. Я помню, как впервые использовал Visual Basic v1.0. То...
Привет, Хабр!Меня зовут Дмитрий Матлах. Я тимлид в AGIMA. Мы с коллегами обратили внимание, что в сообществе часто возникает вопрос о том, как совместить на одном проекте Bitrix-компоненты и реактивны...
Много всякого сыпется в мой ящик, в том числе и от Битрикса (справедливости ради стоит отметить, что я когда-то регистрировался на их сайте). Но вот мне надоели эти письма и я решил отписатьс...