Когда сходство не имеет значения: создание корпоративных систем RAG за пределами векторного поиска

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

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

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

Как векторный поиск стал стандартом

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

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

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

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

Демо-версии и небольшие базы знаний работают хорошо по этой схеме. Однако в корпоративных средах начинают возникать проблемы.

Похожесть — лишь один из множества показателей

Представьте, что менеджер по закупкам пишет: «Какие условия оплаты действуют в рамках нашего текущего соглашения с Northstar Components?»

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

Каждый из этих элементов семантически связан с поставленным вопросом, однако, возможно, только один-два имеют оперативное значение. Правильный выбор подразумевает необходимость ответа на дополнительные вопросы: к какому юридическому лицу относится «наш» контракт? Какая компания Northstar участвует? Действует ли соглашение по-прежнему, и изменили ли поправки первоначальные условия? Какая юрисдикция им управляет? Имеет ли этот пользователь право на его просмотр? Существует ли подписанная версия, и какой источник имеет наибольшую силу?

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

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

Семь способов, каким образом чистое сходство теряет эффективность

Несколько часто встречающихся паттернов сбоев делают поиск, основанный исключительно на векторах, рискованным.

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

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

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

Проблемы с точными идентификаторами. Модели вкладки оптимизированы с учётом смысла и зачастую плохо справляются с обработкой буквальных строк. Типичными жертвами являются номера деталей, номера счётов, ссылки на пункты договора, коды лекарств, идентификаторы оборудования и номера версий. Поиск по строке «Model AX-1047» не должен возвращать результат «AX-1041», поскольку описания этих элементов схожи между собой. В бизнес-поиске зачастую требуется как семантическая точность, так и буквальная.

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

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

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

Значимость имеет множество аспектов

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

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

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

Как выглядит более надежная архитектура поиска

Надежная система RAG обычно проходит через несколько этапов поиска и проверки.

1. Понимание запроса

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

Возьмём пример запроса «Что изменилось в нашей политике хранения данных в Европе в этом году?» Его не следует обрабатывать как обычный семантический поиск. В нём указан регион, категория документа, временной период и необходимость сравнения версий. Понимание запроса преобразует неструктурированное предложение в структурированный план поиска.

2. Фильтрация метаданных

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

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

3. Гибридный поиск

Гибридный способ поиска сочетает семантический поиск с лексическим поиском. Векторные методы обрабатывают смысл и парафразы, в то время как лексические методы, такие как BM25, работают с точными терминами, идентификаторами и редкими словами. Гибридная система может понять, что «процедура завершения работы» связана с «политикой увольнения», но при этом требовать точного совпадения для «HR-OPS-204».

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

4. Поиск структурированных данных

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

Если кто-то спрашивает: «Сколько открытых заявок превысило сумму в 500 тысяч рупий в этом квартале?», правильным шагом будет обратиться к структурированному источнику, хранящему записи о заявках. Обычный текст, описывающий лишь заявки, не может дать точного количества. Совершенный дизайн направляет каждый вопрос тому механизму, который для него наиболее подходит.

5. Графы знаний и поиск с учетом связей

Некоторые вопросы по своей сути касаются связей между объектами. Граф знаний может моделировать клиентов, поставщиков, продукты, контракты, местоположения, инциденты и нормативные акты, а также связи между ними.

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

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

6. Переранжирование

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

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

7. Сбор контекста

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

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

8. Проверка достоверности доказательств

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

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

Бизнес-правила имеют реальный вес

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

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

Оценка за пределами точности ответа

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

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

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

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

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

Ошибки, которые допускают команды при переходе от векторного поиска

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

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

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

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

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

Практический путь вперед

Для улучшения релевантности не обязательно заменять существующую платформу RAG — её можно развивать постепенно.

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

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

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

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

Правильные доказательства вместо похожего текста

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

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

Следующее поколение систем RAG не победит за счёт поиска всё большего количества похожих текстов. Победители смогут предоставить правильные доказательства нужному пользователю в правильном контексте в нужный момент.