Разработка RAG с векторной базой данных Qdrant

Почему RAG Qdrant ошибается на узких запросах

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

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

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

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

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

Что меняется после внедрения RAG Qdrant

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

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

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

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

Способы организации поиска: сравнение подходов

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

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

Этапы внедрения: от аудита до передачи

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

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

Такой порядок даёт эффект накопительно: к моменту запуска у вас есть не только работающий поиск по документам, но и понятная процедура его сопровождения.

Документация и артефакты на выходе

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

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

Такой комплект сокращает разбор инцидента до минут и снимает зависимость от конкретных людей: новый инженер входит в проект по документам, а не по звонкам.

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

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

На один вопрос уходило 12–15 минут, а доля ошибочных ответов доходила до трети: человек либо брал отменённую редакцию, либо не находил нужный пункт и отвечал по памяти.

Что изменили

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

Отдельно выставили порог уверенности: если близких фрагментов нет, система отвечает «в корпусе нет ответа» вместо правдоподобной выдумки.

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

Чем гибридный поиск отличается от векторного

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

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

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

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

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

Технические сомнения и частые вопросы

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

Корпус обновляется каждую неделю — выдача не поедет?

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

Можно ли развернуть всё в закрытом контуре?

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

Что будет при кратном росте объёма документов?

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

Обсудим задачу и вернёмся с оценкой и планом

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

Дальше мы возвращаемся с пакетом, по которому можно принимать решения, а не с презентацией идеи:

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

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