Разработка RAG с векторной базой данных Milvus — опыт и кейсы

RAG Milvus: почему поиск по документам выдаёт нерелевантные ответы

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

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

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

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

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

Что меняется после внедрения: точность, скорость, устойчивость поиска

До внедрения качество ассистента измеряли «на глаз»: ответы выглядели правдоподобно, но на части вопросов система уверенно пересказывала устаревший документ. Мы зафиксировали базовую линию на наборе из реальных обращений — доля ответов, где найденный фрагмент действительно содержал ответ, составляла около двух третей. После настройки разбиения документов, гибридного поиска и переранжирования кандидатов она поднялась до значений, при которых ручная проверка нужна лишь на少数 сложных случаях.

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

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

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

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

Варианты построения поиска по базе знаний: сравнение подходов

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

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

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

Как мы ведём внедрение: этапы инженерной работы

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

1. Аудит источников данных. Собираем перечень систем, форматы файлов, права доступа, дубли и версии. Отдельно фиксируем, как часто документы меняются и что делать с устаревшими редакциями — иначе поиск будет возвращать отменённые приказы и старые регламенты.
2. Схема индексации документов. Определяем правила разбиения на фрагменты и перекрытие между ними, состав метаданных (подразделение, тип, дата, гриф доступа) и модель векторизации под язык корпуса. На этом шаге закладываем фильтрацию по ролям: сотрудник получает только те документы, к которым у него есть доступ.
3. Сборка векторного хранилища на Milvus. Размечаем коллекции, включаем версионирование и отдельный контур для загрузки обновлений, чтобы переиндексация не останавливала поиск. Так регламент, изменённый утром, попадает в выдачу без простоя сервиса.
4. Настройка поиска. Собираем гибридную выдачу: близость векторов плюс фильтры по метаданным и переранжирование. Задаём порог отсечения — если подходящих фрагментов нет, система честно сообщает об этом вместо ответа по догадке.
5. Приёмка на контрольных вопросах. Готовим набор эталонных пар «вопрос — правильный источник» совместно с вашими экспертами и измеряем попадание в источник и полноту ответа. Промахи разбираем: часть закрывается изменением разбиения, часть — доработкой метаданных.
6. Передача и сопровождение. Отдаём регламент обновления индекса, дашборд качества и порядок действий при появлении нового источника знаний.

Порядок внедрения выстроен так, что каждый следующий этап опирается на проверенный предыдущий, — поэтому спорные места видны до запуска, а не после.

Что передаём заказчику: конфигурации, схемы и регламенты

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

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

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

Кейс: как сократили долю нерелевантных ответов втрое

Заказчик — распределённая база знаний: регламенты, договоры и техдокументация нескольких десятков подразделений, порядка 12 млн фрагментов в одном индексе. Ассистент искал по векторной близости с одинаковым топом для любого вопроса — без учёта подразделения, типа документа и срока его действия.

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

Что перестроили

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

Ранжирование перестроили: к векторному поиску в Milvus добавили лексический, выдачи объединили, а верхние 50 фрагментов переранжировали отдельной моделью, обученной на разметке службы поддержки — какие источники сотрудники действительно открывали.

Метрики до и после

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

Чем отличается RAG Milvus от обычного поиска по ключевым словам?

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

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

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

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

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

Технические сомнения: ограничения, риски и контроль качества

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

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

Как разграничиваются права доступа к разделам?

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

Как часто обновляется индекс?

Инкрементальная переиндексация идёт по событиям изменения документа, полная пересборка — по расписанию. Отменённые версии удаляются, чтобы поиск не выдавал устаревший пункт.

Что с исходными документами и что после передачи?

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

Обсудим задачу: состав работ и что нужно от вас

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

• 15–20 реальных вопросов пользователей, как их задают в работе, с ожидаемым ответом и ссылкой на документ-источник.
• перечень источников знаний: типы файлов, объём, языки, есть ли сканы и таблицы, как часто содержимое обновляется.
• как база пополняется — вручную, выгрузкой из учётной системы или по расписанию: от этого зависит схема обновления индекса и место Milvus в контуре.
• требования к доступам: тестовый контур, права на чтение источников, ограничения по персональным данным и закрытым разделам.
• образец ответа, который вы считаете правильным: цитата из документа, короткая выжимка или пошаговая инструкция.
• профиль нагрузки: сколько сотрудников и запросов в сутки, нужен ли ответ в реальном времени.

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