Проблема появляется после успешного демо

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

Это не значит, что базу обязательно придётся создавать заново. В Qdrant поздно добавленный payload-индекс работает для фильтрации. Но документация уточняет важное ограничение: дополнительные связи фильтруемого HNSW строятся с учётом тех payload-индексов, которые уже существовали при построении графа. Чтобы существующий граф получил эти оптимизации, его нужно перестроить. Перестройка требует ресурсов и времени; на действующем сервисе её надо планировать как изменение с измерением и возможностью отката.

На официальной схеме Qdrant в обложке видно разделение внутри коллекции: payload, payload-индекс и vector-index — не один и тот же объект. Эта разница и определяет порядок работ.

Сначала список вопросов, потом список полей

Не начинайте с команды «проиндексировать все колонки». Возьмите 20–30 реальных вопросов от сотрудников и для каждого запишите, какие ограничения меняют допустимый ответ. Пример: для вопроса о возврате товара могут быть важны организация, филиал, действующая редакция, дата и язык документа. Название автора или цвет папки, вероятно, не участвуют в поисковом условии.

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

Разделите поля на три группы:

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

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

Порядок для новой коллекции

Для Qdrant техническая последовательность выглядит так:

1. Зафиксировать модель фрагмента: идентификатор документа, версия, источник, список фильтрующих полей и способ обновления.
2. Создать коллекцию с выбранной размерностью и типом вектора.
3. Сразу создать payload-индексы для известных фильтров. Тип поля должен соответствовать сравнению: точное совпадение, диапазон, дата или текст.
4. После этого загружать фрагменты и строить векторный индекс.
5. Проверить запросы с одним и несколькими фильтрами, а также качество найденных фрагментов.

Qdrant рекомендует создавать payload-индексы до загрузки именно потому, что фильтруемый HNSW добавляет связи с учётом уже индексированных значений. Но ускорение не бесплатно: индексирование каждого случайного поля может раздувать граф и затягивать загрузку. Для проекта с плотным и разреженным поиском некоторые поля используются только во втором; документация Qdrant описывает возможность не создавать дополнительные HNSW-связи для таких полей. Это настройка для измеренного случая, а не универсальная оптимизация на старте.

Что делать, если база уже загружена

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

Документация Qdrant описывает способ принудительно перестроить HNSW после позднего добавления payload-индекса. Это ресурсная операция, а не кнопка, которую следует нажимать без проверки свободного места и окна обслуживания. Для малого бизнеса цена такого решения — не только железо: пока специалисты занимаются переиндексацией, они не улучшают сам процесс поиска и качество документов. Поэтому раннее определение полей часто дешевле, чем поздняя «оптимизация на всякий случай».

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

Минимальный следующий шаг

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

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

Схема Qdrant из официального репозитория кадрирована до квадрата без растяжения; исходный файл распространяется по лицензии Apache 2.0.