Почему RAG, основанный только на векторах, не справляется с аналитическими вопросами, и эталонная архитектура, которая решает эту проблему

PRISM: эталонная архитектура Couchbase для управляемого интеллектуального анализа документов

Вопрос, который ломает RAG

Задайте системе генерации с дополнением поиска (RAG) вопрос по поиску информации в документе, и она, как правило, справится хорошо. Аналитические вопросы — это то, где первыми появляются проблемы. Задайте такой вопрос по стопке документов SEC объемом от 200 до 500 страниц, и все развалится. Рассмотрим вопрос, который звучит просто:

«Каков был коэффициент быстрой ликвидности 3M на конец третьего квартала 2022 года?»

(Коэффициент быстрой ликвидности — это показатель ликвидности, отражающий, насколько хорошо оборотные активы покрывают краткосрочные обязательства.)

Стандартный конвейер хорошо известен: разбить PDF-файлы на фрагменты, создать эмбеддинги, построить векторный индекс, извлечь 10 лучших фрагментов и позволить LLM ответить. Для этого вопроса такой конвейер дает сбой по трем разным причинам.

• Ошибка области поиска. Какая компания? Какой отчет? Какой период? Если система не определит нужный документ 10-Q до начала поиска, 10 лучших фрагментов могут оказаться из неверного отчета, квартала или компании. Поиск по сходству с радостью выдаст убедительный ответ из документа, о котором вы даже не спрашивали.
• Ошибка доказательств. Фраза «коэффициент быстрой ликвидности» не встречается в отчете. В отчете указаны такие статьи, как «итого оборотные активы», «запасы» и «итого краткосрочные обязательства». Вопрос должен быть переведен в печатные термины, прежде чем поиск сможет их найти, а чисто семантический поиск плохо справляется с сопоставлением точных печатных меток.
• Ошибка интерпретации. Даже имея на руках нужные цифры, существует более одной обоснованной формулы для расчета коэффициента быстрой ликвидности. Некоторые методики вычитают запасы из оборотных активов, другие формируют числитель из денежных средств, дебиторской задолженности и ценных бумаг. В зависимости от методики, один и тот же баланс может оказаться по обе стороны от «здорового» порога. Кто-то, обладающий полномочиями, должен решить, какое определение является верным.

RAG, основанный только на векторах, недостаточен для аналитических вопросов. Для надежных ответов на них нужны четыре вещи: определение области поиска, гибридный поиск, детерминированные вычисления и управляемое обучение. PRISM — это эталонная архитектура, которая объединяет эти четыре элемента на базе Couchbase.

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

Основная идея: распределение работы в зависимости от того, кто с чем справляется лучше

Самое важное проектное решение в PRISM касается ответственности, а не технологий. Каждый участник делает только то, что ему можно доверить.

• LLM планирует область поиска и доказательства, предлагает варианты интерпретации, привязывает цифры к местам, где они были найдены, и пишет итоговый текст. Она никогда не выполняет управляемую арифметику.
• Платформа (Couchbase) хранит документы, векторы, каталог, словарь и утвержденные определения в одном месте, а также объединяет лексический и векторный поиск в одном запросе.
• Код и люди замыкают цикл. Код выполняет арифметические действия и детерминированно проверяет каждое число. Люди утверждают определения и курируют словарь.

Следствие простое: языковые модели отлично умеют читать и писать, но являются ненадежными калькуляторами. Поэтому PRISM позволяет модели читать и писать, а также гарантирует, что числа могут быть проверены.

Пять артефактов

PRISM организует все, что знает, в пять артефактов, разделенных на две группы.

Артефакты данных описывают корпус:

• Каталог: Какой документ? Одна запись на исходный документ: компания, тип формы, финансовый период и исходное имя файла.
• Документы: Что в них сказано? Сами фрагменты с таблицами, эмбеддингами и данными о происхождении на уровне страницы.

Артефакты знаний описывают предметную область:

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

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

Зачем нужен каталог? Почему бы просто не добавить метаданные к каждому фрагменту?

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

• Определение документа — это поиск по ключу, а не поиск по сходству. Поиск «3M, 10-Q, Q3 2022» означает необходимость выбора из нескольких сотен небольших записей. Каталог отвечает на это точно и дешево. Как только документ определен, поиск становится точным фильтром по одному имени файла, а не надеждой на то, что нужные фрагменты окажутся в топе.
• Факты есть не на всех страницах. В отчете компания, форма и период указаны на обложке. Фрагмент из середины баланса не содержит ничего из этого. Штамповка этой информации на каждом фрагменте означает повторение одних и тех же фактов тысячи раз, и каждая копия может исказиться или быть извлечена некорректно.
• Единый источник истины. Если период или имя файла нужно исправить, вы просто редактируете одну запись в каталоге. При наличии метаданных во фрагментах вам пришлось бы переписать тысячи фрагментов и обновить записи индекса за ними.
• Неоднозначность становится видимой. С каталогом планировщик видит, какие отчеты существуют. Если вопрос может относиться к двум отчетам, система может спросить или сообщить об этом, вместо того чтобы молча извлекать данные из неверного.
• Фрагменты остаются компактными. Фрагменты содержат только то, что верно на уровне фрагмента: страницу, строку и столбец, а также ID документа. Меньший объем данных в каждом фрагменте делает векторный индекс более компактным, а документы — проще.

Короче говоря, каталог отвечает на вопрос «какой документ?» до того, как будут извлечены какие-либо фрагменты. Затем фрагменты должны ответить только на вопрос «что в них сказано?»

От PDF к поисковым доказательствам

PRISM начинает работу с отчетами в формате PDF, хранящимися в Amazon S3. Он намеренно не анализирует и не разбивает их самостоятельно. Эта работа принадлежит рабочему процессу Couchbase AI Data Plane™, который считывает PDF-файлы из S3, анализирует текст, таблицы и метаданные страниц, разбивает их на фрагменты и генерирует плотные векторные эмбеддинги с помощью развернутой модели эмбеддингов. Он также сохраняет данные о происхождении, включая номера страниц, координаты строк и столбцов, а также ID документов. Результаты попадают в Couchbase Capella. Во время запроса та же модель эмбеддингов преобразует запросы пользователей, поэтому документы и вопросы находятся в одном векторном пространстве.

Отдельный облегченный проход считывает первые страницы каждого документа для создания его каталожной записи: компании, формы, финансового периода и имени файла. Ему не требуется анализ макета, поэтому он выполняется быстро. Наконец, по фрагментам создается гибридный поисковый индекс, объединяющий лексический поиск BM25 с векторным поиском kNN, а также структурированные фильтры метаданных.

Гибридный поиск в одном запросе

Именно здесь Couchbase выполняет основную часть работы. Аналитические вопросы требуют одновременного использования двух разных видов поиска:

• Лексический канал (BM25 плюс анкоры) улавливает точные печатные термины, идентификаторы и финансовые метки. «Итого текущие обязательства» должны соответствовать «Итого текущие обязательства», а не близкому по смыслу перефразированию.
• Семантический канал (вектор kNN) улавливает перефразирования, связанную лексику и концептуальное намерение, например, собственные слова пользователя для обозначения метрики.

Couchbase 8.5 (скоро в продаже) запускает оба канала в одном вызове SEARCH() и объединяет их результаты на сервере, поэтому приложению не нужно самостоятельно склеивать два списка результатов. Объединенный список становится финальной десяткой фрагментов доказательств, которые передаются в LLM.

То, как объединяются два списка, является выбором во время выполнения запроса, и существует несколько стратегий:

Два параметра формируют результат. Веса каналов (усиление запроса верхнего уровня и усиление kNN) контролируют, насколько важны лексические доказательства по сравнению с семантическими. Окно кандидатов контролирует, сколько результатов из каждого канала участвует в объединении.

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

Управляемый поток, от начала до конца

Вот как эти части работают вместе, когда пользователь задает вопрос о коэффициенте быстрой ликвидности.

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

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

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

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

Обоснованный ответ. Только в этот момент LLM пишет ответ в виде текста, построенного вокруг чисел, которые уже были вычислены и проверены. Она объясняет, а не вычисляет.

Тот же поток обрабатывает последующие вопросы, такие как «сравни это со 2-м кварталом». Новый вопрос проходит через те же этапы планирования, разрешения, извлечения и проверки, поэтому ответ получается таким же обоснованным, как и первый.

Управление, которое масштабируется

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

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

Почему это должно быть на одной платформе

Для каждой части этой архитектуры требуется своя структура данных: документы, векторы, небольшие записи каталога, карты словарей и утвержденные определения. В PRISM все они живут в Couchbase Capella, в одном бакете и области, и запрашиваются с помощью одного SQL++ и поискового интерфейса. Гибридный поиск не требует второй системы, а поиск по каталогу и извлечение фрагментов находятся рядом. Эмбеддинги и загрузка данных поступают из Couchbase AI Data Plane, поэтому весь путь от PDF до доказательств остается внутри одной платформы.

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

Начало работы с PRISM

PRISM демонстрирует, как Couchbase Capella и Couchbase AI Data Plane могут превратить сложные коллекции PDF в управляемые, обоснованные интеллектуальные данные. Изучите ресурсы ниже, чтобы увидеть эталонную архитектуру в действии, ознакомиться с реализацией и начать разработку на Couchbase Capella уже сегодня:

• Посмотрите демо: ознакомьтесь с полной настройкой и пошаговым разбором архитектуры в видеоролике PRISM Demo.
• Изучите код: получите доступ к эталонной реализации с открытым исходным кодом на GitHub.
• Узнайте об AI Data Plane: узнайте, как Couchbase AI Data Plane автоматизирует парсинг, разбиение на фрагменты и векторизацию.

Попробуйте Couchbase Capella: создавайте свои собственные приложения с управляемым поиском и ИИ с помощью бесплатной пробной версии Couchbase Capella.