Векторный поиск находит близкие по смыслу фрагменты: переводит запрос и документы в числовые представления, сравнивает их и возвращает кандидатов со ссылками на источник. Полезность выдачи проверяют по рабочим вопросам, актуальности фрагмента и доступу пользователя. Такой подход подходит для поиска по корпусу документов, если у каждого фрагмента сохранены источник, редакция и правила доступа.
Механика выдачи
Векторный поиск превращает запрос и фрагменты документов в сравнимые числовые представления, затем возвращает близкие фрагменты. Близость помогает отобрать кандидатов, а полезность ответа проверяют по исходному тексту и задаче пользователя.
Для рабочего поиска сначала определяют корпус, затем делят документы на фрагменты и сохраняют для каждого текст, источник, редакцию и права доступа. Модель эмбеддингов создаёт вектор каждого фрагмента. При запросе тот же согласованный способ представления создаёт вектор вопроса; система ищет близкие записи и возвращает их вместе с метаданными. Этот путь объясняет, почему запрос с другими словами может найти содержательно похожий абзац.
Расстояние между векторами показывает близость в выбранном представлении, а правильность ответа требует отдельной проверки. Два абзаца о возврате товара могут быть близкими, хотя один описывает старый порядок, а другой относится к иному подразделению. Пользователю нужна ссылка на актуальный фрагмент и контекст вокруг него. Для вопроса о точном номере или артикуле полезно дополнить семантический поиск проверкой ключевого слова; универсального правила для всех типов запросов нет.
Статья о выборе векторной базы для RAG помогает выбрать класс хранения. Здесь фокус на пути конкретного вопроса, фильтрации, проверке найденного абзаца и исправлении плохой выдачи. Для начала достаточно небольшого разрешённого набора реальных документов и журнала тестовых запросов; производственную коллекцию ради демонстрации перестраивать незачем.
Корпус и фрагменты
Соберите малый набор документов с известными владельцами: актуальная инструкция, предыдущая редакция и документ с иным кругом доступа. Набор служит только для проверки механизма. На входе нужны исходный файл, дата и статус редакции, раздел, ссылка на место в тексте, группа доступа и согласие владельца на включение в поиск. Если текст получен из скана, пометьте качество распознавания и сохраните страницу оригинала.
Фрагмент должен сохранять законченную мысль. Разрез посреди условия или таблицы отрывает ответ от оговорки, а слишком большой кусок смешивает разные темы. Подберите границу по структуре документа: заголовок, абзац, пункт или строка таблицы вместе с названием столбца. Для каждого фрагмента храните устойчивый идентификатор и связь с редакцией документа. После обновления источника старые фрагменты исключают из актуальной выдачи по управляемому правилу, сохраняя историю для проверки.
| Что хранить | Зачем | Что проверить |
|---|---|---|
| Текст фрагмента | Материал для вектора и показа | Полнота условия и читаемость |
| Источник и редакция | Возврат к оригиналу | Актуальность ссылки |
| Раздел и позиция | Контекст найденного абзаца | Совпадение с нужной темой |
| Метка доступа | Ограничение кандидатов | Право пользователя на источник |
| Модель представления | Повторяемость индекса | Совместимость с вектором запроса |
Один документ может дать несколько кандидатов в верхней части выдачи. Сохраняйте идентификатор исходника, чтобы проверяющий видел разнообразие источников и мог открыть полный раздел. Перед запуском уточните, какая версия считается действующей при параллельных редакциях. Система без такого признака может уверенно показывать устаревший порядок. Для корпоративного поиска отдельно полезна схема прав и источников документов.
Путь запроса
Воспроизведите поиск по настоящим рабочим вопросам, обезличив чувствительные сведения. Запросы должны включать разговорную формулировку, точное название документа, вопрос с несколькими возможными ответами и вопрос, ответа на который в корпусе нет. Последний тип нужен, чтобы увидеть бесполезные совпадения. Для каждого вопроса человек заранее отмечает ожидаемый документ или отсутствие подходящего источника. Такая разметка становится опорой для сравнения версий корпуса и настроек.
- Сервер определяет пользователя и набор разрешённых документов по действующим правам.
- Вопрос преобразуется в вектор с помощью той же согласованной модели, которой подготовлены фрагменты.
- Поиск выбирает близкие фрагменты внутри разрешённого набора и возвращает текст со ссылками.
- Система показывает кандидатов в порядке поиска, а проверяющий открывает оригинал и отмечает релевантность.
- Журнал сохраняет запрос, версию корпуса, найденные идентификаторы и решение проверяющего.
Фильтр доступа работает на сервере и зависит от установленных прав. Перед выдачей источника сервер повторно проверяет полномочия: право может измениться между индексацией и просмотром. Если фрагмент закрыт, система скрывает текст и ссылку; количество закрытых совпадений тоже лучше исключить из пользовательского интерфейса. Ответственный сотрудник разрешает спорные случаи доступа и утверждает изменение правил, а модель может лишь подсказать вероятное место ответа.
Для внедрения ИИ в поиск по документам определите владельца корпуса и согласованный способ разметки вопросов. После этого можно обсуждать интерфейс и объём индекса, сохраняя проверку выдачи как отдельную задачу.
Хотите проверить выдачу на ваших рабочих вопросах?
Ошибки и исключения
Плохая выдача имеет разные причины. Нужный документ мог отсутствовать в корпусе; нужный абзац мог потерять смысл при разрезании; версия могла устареть; вектор мог поставить близкий по теме, но неверный по условию текст выше нужного. Диагностику начинайте с источника и фрагмента. Откройте исходный раздел, посмотрите соседние фрагменты, проверьте права и редакцию, затем сравните результат с ожидаемой разметкой.
Точное имя товара, код, номер пункта или сумма иногда требуют буквального совпадения. В таких случаях проектная схема может соединять векторный поиск с текстовым фильтром и отдельной сортировкой кандидатов. Это решение проверяют на размеченных вопросах. Ссылка на повторную сортировку в RAG полезна, если релевантный фрагмент уже попал в список кандидатов, но стоит низко. При отсутствии исходного документа сортировать нечего.
- Нет подходящего документа: покажите отсутствие подтверждённого источника и отправьте запрос владельцу корпуса.
- Найдена старая редакция: снимите её с актуальной выдачи и проверьте правила обновления индекса.
- Найден закрытый источник: сервер отклоняет показ, а ответственный сверяет метку доступа.
- Фрагмент лишён оговорки: измените границы разреза и повторите тест того же вопроса.
- Точный реквизит потерялся среди похожих тем: добавьте отдельную проверку буквального совпадения.
Число близости нельзя превращать в универсальный порог достоверности. Шкала зависит от модели и способа сравнения, а даже высокий результат может относиться к неподходящей редакции. Если система поверх поиска строит ответ нейросетью, показывайте исходные фрагменты и отделяйте цитату от вывода. Ответственный человек подтверждает спорный вывод после просмотра оригинала; сервер отвечает за полномочия, версию источника и журнал действий.
Проверка релевантности
Приёмка поиска начинается с таблицы вопросов и ожидаемых фрагментов, которую составляют владельцы документов и будущие пользователи. Для каждого вопроса отмечайте, какой источник подходит, какая редакция допустима и что считать частичным ответом. Затем выполните запросы с одними и теми же правами и зафиксируйте выдачу. Проверяющий оценивает первый полезный фрагмент, ошибочные источники, пропуски и случаи, когда ответ отсутствует. Так видно качество поиска отдельно от красивого текста помощника.
После изменения корпуса, разбиения или модели повторите ту же таблицу и сравните результаты по каждому вопросу. Особенно важны пограничные темы и закрытые документы: улучшение для одного подразделения может ухудшить выдачу для другого. Журнал должен позволять восстановить версию корпуса, правила фильтрации и список показанных фрагментов. Результат сравнения утверждает владелец процесса, а спорные оценки разбирают с автором документа. Решение о публикации нового индекса остаётся у ответственного человека.
Возьмите доступные реальные документы и запишите рабочие вопросы вместе с ожидаемыми источниками. Проверьте, открываются ли оригиналы, скрываются ли закрытые фрагменты и находится ли актуальная редакция. Затем меняйте один элемент маршрута за раз.
Критерий приёмки формулируйте предметно: по каждому проверочному вопросу найденный фрагмент позволяет человеку объяснить ответ или явно показывает отсутствие подтверждённого источника. Любой новый документ проходит проверку прав, версии и ссылок до индексации. Если в выдаче пропала важная оговорка, вернитесь к границам фрагмента; если выдача закрывает нужный источник, разбирайте права. Выбор конкретной базы и её производительность обсуждаются отдельно, после подтверждения качества самого поиска.