Обновление базы знаний RAG: чек-лист для Qdrant

Чтобы обновить базу знаний RAG целиком, подготовьте новый набор документов в отдельной коллекции Qdrant, проверьте его напрямую и только затем переключите рабочий alias. Alias — постоянное имя, через которое приложение обращается к выбранной коллекции. Переключение этого имени не обновляет автоматически кэш ответов, историю диалога и другие поисковые системы.

Материал для инженера интеграции и владельца корпоративной базы знаний. Здесь — чек-лист одного выпуска документов при неизменной модели эмбеддингов, то есть модели, превращающей текст в поисковые векторы. Это документированный порядок и предлагаемые контрольные примеры: редакция не выполняла эти запросы на работающем Qdrant. Документация проверена 22 октября 2026 года; открытая API-справка показывает ветку v1.19.x. Совместимость со своей установленной версией нужно проверить отдельно.

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

Содержание

• Границы задачи и исходные данные
• Этап 1. Закрепить состав выпуска
• Этап 2. Собрать отдельную коллекцию
• Этап 3. Проверить документы и поиск
• Этап 4. Переключить рабочий alias
• Этап 5. Проверить ответы приложения
• Этап 6. Подготовить возврат и закрыть выпуск
• Ошибки, при которых выпуск останавливают

Границы задачи и исходные данные

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

Для примера возьмём вымышленного помощника поддержки. В старой инструкции срок возврата — 14 дней, в новой — 30. Один продукт снят с обслуживания; его старая инструкция не должна попадать в новый поисковый контекст. Числа условны и не описывают правовые нормы или реальный сервис.

Подготовьте входные данные:

• Рабочий alias support_live, текущую коллекцию support_r1 и имя новой support_r2. Это условные имена, не встроенные объекты Qdrant.
• Утверждённые исходные документы и перечень отозванных источников.
• Настройки извлечения текста, разбиения на чанки — поисковые фрагменты — и эмбеддингов.
• Учётную запись с нужными правами, тестовую среду и согласованный порядок изменения production.
• Контрольные вопросы с ожидаемыми источниками и варианты доступа пользователей.

Коллекция Qdrant хранит точки с векторами и дополнительными данными. Её настройки должны соответствовать используемым векторам; определения и параметры описаны в руководстве Collections. Общую схему загрузки и поиска можно сверить со статьёй о RAG-системе для бизнеса.

Этап 1. Закрепить состав выпуска

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

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

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

Этап 2. Собрать отдельную коллекцию

• Создайте support_r2 отдельно от рабочей базы. Для этого сценария сохраните модель эмбеддингов и параметры векторов. Подготовьте требуемые индексы для полей фильтрации; копирование содержимого само по себе не означает копирование всей конфигурации.
• Загрузите полный утверждённый набор. Свяжите каждый чанк с исходным документом. Предлагаемые поля payload: document_id, document_version, release_id, source_uri и метки доступа. Это схема приложения, её нужно реализовать в загрузчике.
• Дождитесь применённых изменений. Сохраните фактические статусы операций и проверьте доступность данных для чтения. Не делайте вывод о готовности из одного ответа на отправку партии.

Qdrant различает приём записи и завершение её применения; подробности приведены в описании операций с точками. При включённом prevent_unoptimized часть данных может ждать индексации; wait=true способен увеличить ожидание и привести к таймаутам. Проверяйте настройки и фактическую видимость данных по документации оптимизатора.

Этап завершён, когда загрузчик обработал весь список и новые документы можно прочитать из support_r2. Это ещё не означает, что поиск правильно отвечает на вопросы.

Этап 3. Проверить документы и поиск

• Сверьте количество точек по каждому документу. Используйте ожидаемое число чанков после парсинга и count с exact: true и фильтром document_id. Одного общего количества недостаточно: недостача одного документа может совпасть с дублированием другого. Count points поддерживает точный подсчёт и фильтры.
• Прочитайте содержимое. Через scroll проверьте текст и payload: редакции, ссылки на источники, метки доступа. Для полного обхода проходите все страницы с возвращаемым next_page_offset, а не только первую. Это предусмотрено в Scroll points.
• Выполните поиск напрямую по новой коллекции. Используйте тот же способ кодирования вопроса, фильтры и параметры поиска, что и приложение. Query points описывает запросы к коллекции и отбор результатов.

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

Входной вопрос или условие	Что искать в результате	Признак готовности
«Какой сейчас срок возврата?»	Новую инструкцию и её редакцию	Контекст содержит условные 30 дней, старой редакции нет
Вопрос по неизменённому продукту	Прежний действующий источник	Документ сохранился в новом выпуске
Вопрос о снятом продукте	Отсутствие исключённой инструкции	Старая инструкция не возвращается; дальнейший ответ определяется правилами приложения
Вопрос пользователя без нужных прав	Только разрешённые фрагменты	Закрытого документа нет в контексте

Фильтры Qdrant отбирают точки по условиям payload, но источник прав и их обязательное применение организует приложение. Операции условий приведены в Filtering; настройки индексов полей — в Indexing. Само наличие поля доступа не обеспечивает разграничение прав.

Этап завершён, когда объяснены расхождения по документам и пройдены заранее выбранные вопросы, включая исключённые источники и права. Методические различия между качеством поиска и качеством ответа разобраны в статье о точности RAG.

Этап 4. Переключить рабочий alias

• Проверьте маршрут приложения. Оно должно обращаться к support_live, а не к жёстко заданной support_r1. Проверьте все поисковые ветки, включая фоновые задачи. Если alias ещё не используется, сначала внедрите этот маршрут отдельно.
• Уточните текущее назначение. Вызовите GET /aliases, найдите support_live и сохраните collection_name. Формат ответа описан в List all aliases.
• Передайте смену назначения одним запросом. Не разбивайте удаление и создание alias на два независимых обращения.

Ниже документированный пример тела для POST /collections/aliases, адаптированный к условным именам. Это не готовая команда: адрес, авторизация и окружение здесь не заданы; запрос редакцией не выполнялся.

{
  "actions": [
    {"delete_alias": {"alias_name": "support_live"}},
    {"create_alias": {
      "collection_name": "support_r2",
      "alias_name": "support_live"
    }}
  ]
}

Поля и endpoint определены в Update collection aliases. Атомарность удаления и создания alias в одном запросе прямо описана в руководстве миграции Qdrant. Она относится к смене назначения alias; из неё не следует атомарность всей RAG-системы или гарантия отсутствия простоя приложения.

Этап завершён, когда повторный GET /aliases показывает support_live → support_r2. Если запрос переключения завершился таймаутом, сначала прочитайте фактическое назначение. Не повторяйте изменение вслепую: ошибка ожидания не является доказательством прежнего состояния.

Этап 5. Проверить ответы приложения

• Повторите контрольные вопросы через обычный интерфейс. Проверьте найденные фрагменты, ссылки и итоговый текст. Успешный прямой поиск не подтверждает, что production-приложение использует тот же маршрут.
• Обновите правила кэша ответов. Предлагаемый вариант — включать версию корпуса в ключ кэша и читать только соответствующий выпуск. Другой вариант — инвалидировать затронутые ответы по связям с документами. Эти механизмы нужно реализовать отдельно; Qdrant рассматривает актуализацию кэша при изменении источников в руководстве Semantic Caching for RAG.
• Разделите новый и продолжающийся диалог. Проверьте оба случая. Приложение может снова передать модели прежний ответ из истории; смена коллекции этот текст не стирает. Заранее определите, как интерфейс отмечает изменившиеся условия и какой источник имеет приоритет.

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

Этап 6. Подготовить возврат и закрыть выпуск

• Сохраните предыдущую коллекцию на согласованный период наблюдения. Подготовьте обратную смену alias на support_r1 и процедуру возврата настроек приложения и кэша.
• Проверьте, допустимо ли возвращать старое содержимое. Если документ отозван из-за ошибочных условий или доступа, технически сохранённая коллекция может быть непригодна для возврата. Тогда безопаснее временно ограничить ответы по затронутой теме и подготовить исправленный выпуск.
• Не принимайте новые изменения незаметно для процедуры возврата. В этом пакетном сценарии во время наблюдения состав заморожен. Если возобновить загрузку только в новую коллекцию, старая уже не будет содержать новые знания.
• Удаляйте старые данные по утверждённой политике. Учтите исходные файлы, другие индексы, резервные копии и кэши отдельно. Переназначение alias не равно удалению данных.

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

Ошибки, при которых выпуск останавливают

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

Как AIrassvet помогает организовать обновление RAG

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

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

Что должно остаться после обновления

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