Embeddings и векторный поиск: из чего складывается релевантность
Векторный поиск помогает найти документ по смыслу, даже когда слова в вопросе отличаются от формулировки в базе. Для этого текст превращается в числовой вектор — embedding, а система ищет близкие векторы. Однако математическая близость не равна правильному ответу. Результат зависит от того, как документ разбит, какие метаданные к нему добавлены и что произошло с правами, версиями и порогом релевантности.
Как строится индекс
Сначала документ очищают от технического мусора и делят на фрагменты. К каждому фрагменту нужно добавить заголовок, источник, дату действия, владельца, отдел и уровень доступа. Embedding-модель превращает этот блок в вектор фиксированной длины. Вопрос пользователя преобразуется совместимой моделью, после чего индекс возвращает ближайшие кандидаты.
Индекс и запрос обязаны использовать одну версию модели или совместимый формат. При обновлении embedding-модели старые и новые векторы нельзя молча смешивать: часть документов будет оцениваться в другом пространстве. Пометьте индекс версией и перестройте его целиком либо используйте два явно разделённых контура.
Почему смысл помогает, но не решает всё
Если в регламенте написано «оформление возврата», а сотрудник спрашивает «как вернуть товар», точный поиск может пропустить нужную строку, тогда как embedding найдёт перефразирование. Но при двух похожих правилах для разных регионов смысловое сходство не выберет правильную область действия. Нужны фильтры по региону, дате и роли до передачи кандидата генератору.
Вектор не понимает автоматически, что один документ отменяет другой. Если в фрагмент не попала дата или заголовок, модель увидит красивый, но неполный абзац. Поэтому вместе с правилом храните исключение, единицы измерения и ссылку на внутренний оригинал.
Разбиение без потери контекста
Слишком маленький кусок превращает исключение в бесхозную строку; слишком большой приносит много нерелевантного текста и увеличивает стоимость ответа. Для инструкции держите в одном фрагменте заголовок, правило и ближайшее исключение. Для таблицы добавляйте названия столбцов, период и единицы. Списки не разрывайте посередине пункта.
Размер фрагмента проверяйте на реальных вопросах, а не выбирайте универсальное число символов. Сделайте две версии разбиения и сравните, в какой чаще находится полный эталонный ответ. Пустые страницы, повторяющиеся колонтитулы и навигацию лучше исключить до векторизации, иначе они создают ложные совпадения.
Порог и отсутствие ответа
Поиск возвращает оценку похожести, но значение 0,75 не является общим стандартом качества. Подберите порог на размеченных вопросах, где известен правильный фрагмент. Добавьте запросы, на которые в базе нет ответа: система должна уверенно отказаться, а не передать генератору случайно близкий документ.
Фиксируйте порог вместе с версией индекса. После смены модели, разбиения или набора документов распределение оценок меняется. Если ближайший кандидат ниже порога, покажите пользователю отсутствие основания и предложите уточнить вопрос; молчаливое заполнение пробела создаёт ложную уверенность.
Зачем нужен гибридный поиск
Семантический поиск хорош для перефразирования, а обычный полнотекстовый — для номеров договоров, артикулов, кодов и точных названий. Гибридный маршрут собирает кандидатов обоими способами, удаляет недоступные документы и только потом применяет ранжирование. Для номера AB-00127 точное совпадение должно иметь приоритет над фрагментом, где просто встречается слово «договор».
Фильтр доступа выполняйте на сервере до генерации, а не прячьте в интерфейсе. Высокий балл не даёт права прочитать закрытый документ. Тестируйте роли отдельно: один и тот же вопрос должен вернуть разные наборы разрешённых фрагментов.
Как измерить качество выдачи
Составьте двадцать–тридцать вопросов с эталонным фрагментом и добавьте опечатки, синонимы, конфликтующие версии и вопросы вне области. Измерьте recall@k: попал ли нужный фрагмент в первые k результатов. Отдельно посчитайте ложные совпадения и долю случаев, когда найден правильный документ, но не та его версия.
Сохраняйте список кандидатов до генерации ответа. Если эталон не попал в выдачу, ищите причину в OCR, разбиении, метаданных или фильтре. Если документ найден, но итог неверен, проблема уже находится в инструкции генератора или проверке фактов. Такое разделение экономит время и не позволяет обвинять модель в ошибке индекса.
Обновления, стоимость и задержка
При изменении документа создавайте новую версию, а старую помечайте архивной. Не оставляйте две активные копии с одним названием. В журнале храните файл, владельца, версию embedding-модели, время индексации и число фрагментов. После переиндексации повторяйте контрольные вопросы и проверяйте даты в выдаче.
Расход возникает при построении векторов и поиске по большому индексу. Удаляйте дубли, не векторизуйте навигацию и кэшируйте запросы, для которых набор документов не изменился. Измеряйте задержку вместе с recall: быстрый результат, который ведёт к неверному регламенту, экономит только секунды.
Приватность
Embedding сохраняет статистическое представление смысла чувствительного текста и не должен считаться безобидным набором чисел. Защищайте векторную базу теми же ролями, что и оригиналы, ограничивайте резервные копии и проверяйте условия хранения стороннего сервиса. Не отправляйте индекс наружу только потому, что в нём нет читаемых предложений.
Чек-лист
- Версии модели индекса и запроса совместимы.
- Фрагменты сохраняют заголовки, исключения и единицы.
- Метаданные содержат дату, владельца и права.
- Порог проверен на вопросах с ответом и без него.
- Точные идентификаторы ищутся гибридным способом.
- Фильтр доступа применяется до генерации.
- Измерены recall@k, ложные совпадения и старые версии.
- Переиндексация и журналирование воспроизводимы.
- Векторная база защищена как исходные документы.
Разбор одного запроса до ответа модели
Чтобы найти причину ошибки, разложите запрос сотрудника на четыре записи: исходная формулировка, очищенный текст для embedding, список кандидатов и фрагмент, который получил генератор. Например, вопрос «какой лимит действует для филиала на Урале?» должен сохранить регион и слово «лимит»; если очистка оставила только «какой лимит действует», фильтр уже не сможет выбрать нужное правило.
Затем вручную проверьте первые пять кандидатов. У каждого отметьте дату действия, подразделение и статус документа. Если правильный фрагмент оказался шестым, проблема в ранжировании или пороге. Если его нет совсем, не повышайте порог вслепую: сравните разбиение, OCR и метаданные. А если правильный фрагмент найден, но ответ его искажает, переносите расследование на инструкцию генератора.
Такой журнал полезнее общей оценки «поиск работает». Он показывает, на каком слое возник сбой, и позволяет повторить тест после смены embedding-модели. Для чувствительных баз добавьте ещё одну проверку: кандидат с высоким баллом, но без нужной роли, должен быть удалён до того, как его увидит генератор.
Embeddings измеряют смысловое сходство, но не обещают релевантность. Надёжный RAG складывается из аккуратного разбиения, метаданных, гибридной выдачи, порога и проверки прав. Только после этих слоёв генератору стоит поручать формулировку ответа.