Обеспечение надежности хранилища векторов: жизненный цикл, арендная модель, метаданные, гибридный поиск
Работа векторного хранилища для RAG в производственной среде: жизненный цикл документов, обновление эмбеддингов, фильтры арендаторов, гибридный поиск по точным идентификаторам, метаданные и отслеживание.
Источники: Vector Store Operations: What Keeps RAG Retrieval Correct in Production
Техник на месте обращается к внутреннему сотруднику службы поддержки с вопросом о том, как заменить гидравлический насос. Ответ кажется правильным: указана правильная семья оборудования, правильный тип насоса, шаги выполнены разумно. Однако он устарел уже на полгода. В текущем бюллетене требуется обновление прошивки перед установкой насоса, но в старом бюллетене об этом ничего не говорится. Оба бюллетеня хранятся в хранилище данных. Новый был правильно индексирован, но старый так и не был удален. Система не выдумала ничего — ей просто предоставили устаревшие данные.
Именно такие вопросы определяют, можно ли доверять системе поиска.
- Какая версия документа может быть получена в настоящее время?
- Сколько времени проходит после утверждения, прежде чем обновление становится доступным для поиска?
- Может ли один клиент увидеть контент другого клиента?
- Что происходит, когда пользователь ищет точный номер детали, а не общее описание?
Всё это не связано с качеством модели. Речь идёт о повседневной работе хранилища векторов.
Конкретная настройка: техническая поддержка для нескольких клиентов
Представьте платформу поддержки, используемую дилерами оборудования в нескольких странах. На ней хранятся руководства по продуктам, информация о ремонте, каталоги запчастей, условия гарантии, инструкции по техническому обслуживанию и заметки, написанные отдельными дилерами. Техник может спросить, какая процедура замены одобрена для гидравлического насоса MX-204 версии 5.2 в его регионе.
Это не простой семантический поиск. Система должна понимать цель обслуживания, сохранять точные идентификаторы, такие как версия MX-204 5.2, без изменений, возвращать текущую процедуру ремонта, применять соответствующую региональную политику и исключать всё, что относится к другим дилерам или учётным записям. Простой запрос на поиск по сходству не может обеспечить такие гарантии. Слой поиска должен функционировать как управляемая информационная служба.
Рассматривайте индексацию как управление выпуском документов
В первых версиях технологии RAG индексация обычно рассматривается как единое действие: загрузка, разбиение на части, встраивание, запись, готово. После этого документ остаётся доступным для поиска до тех пор, пока кто-то не заметит проблему. Следующие сбои легко предсказуемы.
- Пересмотренное руководство сосуществует со своим предшественником.
- Черновик политики становится доступным для поиска ещё до его утверждения.
- Процедура удаления отменена, поэтому документ остается доступным, так как процесс удаления отсутствует.
- Сбой в работе конвейера приводит к тому, что документ индексируется частично, в результате чего можно получить только фрагменты информации.
Для корпуса поддержки наименьший полезный набор состояний жизненного цикла выглядит следующим образом:
- Черновик: получен, ещё не одобрен для поиска.
- Кандидат: индексирован и находится в процессе проверки.
- Активный: одобрен и готов к поиску.
- Заменённый: заменён более новой версией, сохраняется для аудита, скрыт от обычных запросов.
- На карантине: задержан из-за сбоев в проверке, анализе метаданных или рассмотрении содержимого.
- Удалённый: исключён из корпуса, а также из основного хранилища, если это требуют правила.
Существует одно важное правило: поиск должен касаться только документов в активном состоянии. Его необходимо обеспечивать с помощью фильтров метаданных, а не привычек названия файлов или инструкций в запросе.
Каждый документ также требует стабильного идентификатора документа и отдельного идентификатора версии. Первый обозначает логический объект, например определенное информационное сообщение, а второй — конкретную его редакцию. Утверждение новой редакции активирует новую версию и отмечает предыдущую как устаревшую, причем этот процесс должен происходить атомарно. Благодаря этому система перестает возвращать содержимое, которое было релевантным, но больше не действительно.
Обновление эмбеддингов: поэтапное, с версионированием, обратимое
Обновление эмбеддингов часто описывается как задача, которую необходимо выполнять каждый раз при изменении модели. На самом деле существует более разнообразные триггеры:
- Изменяется исходный документ.
- Политика достигает своей даты вступления в силу или истечения срока действия.
- Схема метаданных расширяется.
- Стратегия разбиения на части улучшается.
- Модель встраивания обновляется.
- Документ отзывается или переклассифицируется.
- Права пользователя меняются.
Каждому случаю требуется отдельный ответ. Для пересмотренного бюллетеня может потребоваться лишь обновление на уровне раздела. Новая модель встраивания может потребовать полной перестройки всей системы. Появление нового поля метаданных требует контролируемого восполнения данных, а отзыв документа должен немедленно привести к его удалению из активного индекса.
Поэтому процесс обновления должен отслеживать четыре версии: исходную редакцию, логику разбиения на части, модель встраивания и схему метаданных, используемую для фильтрации. Без такой прослеживаемости никто не сможет объяснить, почему две части ведут себя по-разному при поиске.
На практике входящий файл сравнивается с действующей версией с помощью хэша содержимого или структурированного отчета о различиях. Измененные разделы снова делятся на чанки и вставляются заново, в то время как неизменные разделы остаются прежними, если только версия чанкирования или вставки не изменилась.
При крупных обновлениях моделей требуется более безопасная процедура: создается параллельный кандидатский индекс, выполняются запросы на оценку для обоих индексов, проверяются механизмы контроля доступа, и трафик перенаправляется только тогда, когда новый индекс работает приемлемо. Важный вопрос заключается не в том, показала ли новая модель лучшие результаты на тестах, а в том, возвращает ли новый индекс правильные, одобренные данные для запросов, которые действительно отправляют пользователи.
Обеспечивайте соблюдение правил аренды до получения данных, а не после
Опасная, но распространённая ошибка проектирования в системах RAG с несколькими арендаторами — фильтрация по арендатору после поиска. Система сначала собирает широкий набор результатов, а затем удаляет те, которые принадлежат другим организациям. Это слишком поздно. Фильтры арендаторов и доступа должны определять диапазон возможных результатов ещё до начала поиска по векторам или ключевым словам.
В платформе поддержки контент делится на три группы.
- Глобальный контент: руководства производителей и общие инструкции по безопасности.
- Контент дилеров: внутренние руководства по обслуживанию, коммерческие соглашения и местные инструкции по эксплуатации.
- Контент клиентов: история использования активов, условия контрактов и конфиденциальные записи об эксплуатации.
Им не обязательно использовать одинаковую структуру хранения. Глобальный контент может использовать общий корпус данных. Контент дилера может использовать индекс, защищённый обязательными фильтрами для конкретных пользователей. Крайне чувствительные клиенты могут нуждаться в собственных коллекциях или изолированных индексах в зависимости от требований регулирования, контрактов и уровня риска.
Информация о пользователе, его роли, регионе, правах на доступ к продуктам и уровне конфиденциальности должна поступать из авторизованной сессии, а не из формулировок запроса. Техник, вводящий в запрос имя другого дилера, не должен иметь возможности изменить фильтры. Фактически запрос на поиск предусматривает поиск только тех данных, к которым имеет доступ авторизованный пользователь, и только после этого начинается семантическое или поисковое ранжирование по ключевым словам. Это обеспечивает конфиденциальность и устраняет нерелевантные результаты.
Гибридный поиск для точных идентификаторов
Плотный векторный поиск проявляет себя наилучшим образом, когда люди описывают проблему на обычном языке, например, спрашивая, какая версия прошивки требуется перед установкой заменительного насоса на MX-204. Номера деталей, коды контроллеров и строки версий ведут себя иначе, и лексический индекс гораздо лучше справляется с их точным сопоставлением.
В случае с MX-204 лексический поиск может выдать именно ту информацию, поскольку в ней содержатся идентификаторы контроллера и насоса, тогда как плотный поиск предоставляет связанные рекомендации по техническому обслуживанию. Затем алгоритм переоценки может отдать предпочтение документу, в котором указаны требования к прошивке и утвержденная последовательность действий.
Когда качество поиска низкое, добавление большего количества данных в контекст редко помогает. Увеличение числа элементов в группе top-k в основном приводит к появлению шума, задержкам и повышению вероятности получения правдоподобного, но необоснованного ответа. Лучше выяснить, на каком этапе возникла проблема.
- Был ли нужный документ недоступен?
- Не исключил ли его неисправный фильтр метаданных?
- Не пропустила ли лексическая поисковая система альтернативный формат номера детали?
- Не отдал ли ранжировщик предпочтение более общему документу перед более специфичным?
Каждая из этих проблем является измеримой системной проблемой.
Метаданные как плоскость управления
Метаданные часто рассматриваются как необязательные теги, добавляемые во время загрузки. В реальных условиях они определяют, что может быть извлечено системой. Полезная схема охватывает пять областей.
- Идентификация: исходный документ, система, откуда поступил фрагмент, и хеш содержимого.
- Жизненный цикл: версия, статус утверждения, даты вступления в силу и истечения срока действия, а также порядок приоритетности.
- Доступ: идентификатор арендатора, регион, полномочия роли, доступ к продукту, класс конфиденциальности и юридические ограничения.
- Извлечение: тип документа, язык, модель оборудования, семейство компонентов, линейка продуктов и категория содержимого.
Благодаря такой структуре вопросы, которые иначе были бы сложными для решения, превращаются в простые запросы. Какие активные документы всё ещё используют старую модель встраивания? Какие процедуры ремонта истекают сроком в следующем месяце? У каких фрагментов отсутствуют метаданные региона? У какого арендатора самый высокий процент пустых результатов? Какие источниковые системы вызывают наибольшее количество сбоев при загрузке?
Метаданные должны быть проверены перед тем, как документ попадёт в активный корпус. Фрагмент без информации об арендаторе, состоянии жизненного цикла, линейке продуктов или статусе утверждения не должен становиться доступным для поиска только потому, что было создано его встраивание. Многие системы RAG теряют надёжность именно на этом этапе: база данных работает так, как задумано, но модель метаданных слишком примитивна, чтобы отражать реальные правила организации, касающиеся доступа, жизненного цикла и политик.
Возможность отслеживания, позволяющая выявить несрабатывающую стадию
Когда пользователь сообщает о неверном ответе, может произойти множество проблем. Правильный источник информации мог так и не быть индексирован, или быть индексирован, но отмечен как неактивный, или быть отфильтрован. Он мог попасть в список кандидатов, но занять слишком низкую позицию. Он мог попасть в контекст модели, но быть проигнорирован. Или же модель могла сгенерировать что-то, что не подтверждается имеющимися доказательствами. Для каждого случая требуется свое решение.
Поэтому зрелая служба по поиску записывает весь путь обработки:
- Запрос и контекст пользователя.
- Фильтры доступа и жизненного цикла, которые были применены.
- Кандидаты из детального и лексического анализа.
- Результаты слияния рейтингов и выводы системы переоценки.
- Итоговые доказательства, переданные модели.
- Цитаты, использованные в ответе.
Полезными мерами являются задержка между одобрением источника и активацией индекса, доля активного контента в текущей версии встраивания, документы с более чем одной активной версией, показатели отсутствия результатов по типам запросов, уровень покрытия тестов с известными ответами, коэффициенты отклонения фильтров и любые попытки доступа между арендаторами.
Полезным показателем является уровень покрытия кандидатов: для запроса с известным ответом появлялсясь ли правильный источник среди кандидатов перед переранжированием? Если нет, стоит проверить процесс индексации, фильтрации или проектирование поиска. Если он появлялся, но занимал низкую позицию, следует рассмотреть варианты объединения данных или переранжирования. Если он занимал высокую позицию, но ответ его проигнорировал, проблема заключается в генерации текста или составлении промпта. Разделение этапов помогает командам не пытаться исправить всё путем редактирования промпта.
Рутинные действия
Хранилище векторов требует такого же строгого контроля, как и любая сервисная система для обработки данных в промышленных условиях. Ежедневные проверки должны включать анализ сбоев при загрузке данных, задержек в обновлении информации, документов, застрявших в режиме ожидания или в карантине, отсутствия обязательных метаданных, а также задержек в процессе утверждения для индексации. Еженедельные анализы должны охватывать качество получения результатов по различным типам запросов — от разговорных вопросов до простых кодов, названий продуктов, поиска информации по правилам, поиска на других языках и нечетких запросов.
Любые изменения в способах разбиения данных на чанки, моделях эмбеддингов, схеме метаданных или политиках доступа должны сначала тестироваться в тестовой среде. Для оценки необходимы реальные запросы пользователей, примеры с известными ответами, тесты контроля доступа, а также запросы, предназначенные для выявления утечек информации у арендаторов или устаревшего контента.
Цель не в получении большего количества документов. Она заключается в том, чтобы в нужный момент передать правильные, одобренные доказательства правильному пользователю. Хранилище векторов — это не пассивная база данных, находящаяся за чат-ботом, поскольку именно оно решает, какие доказательства могут повлиять на формирование ответа. Если устаревшие документы остаются активными, фильтры арендаторов становятся необязательными, идентификаторы исчезают при семантическом сопоставлении, а метаданные не могут отражать бизнес-правила; в таких случаях система становится ненадежной, независимо от мощности модели.
Связанные материалы
- Семантическое поиск с ChromaDB и векторными представлениями для многопроцессной платформы — Переход многопроцессной корпоративной платформы на реальный семантический поиск: разбиение текста с учетом слов, косинусное расстояние в ChromaDB, тестовые слои и следующий шаг в развитии RetrievalAgent.