# Qdrant: переключить поиск на новую коллекцию через алиас

Источник: https://modelium.tech/zhurnal/qdrant-alias-pereklyuchenie-kollekcii/

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

**Уровень: технический; документация сверена 17 октября 2026 года.** Нужен уже работающий Qdrant и право менять коллекции. Modelium не выполнял переключение на живом сервере: команды ниже проверены как синтаксический пример, а не как результат запуска Qdrant. Для первого знакомства с ним начните с [локального Qdrant](/zhurnal/qdrant-lokalno/). [s1](#src-s1) [s3](#src-s3)

## Что именно переключает алиас?

Представьте, что поиск в вашем приложении обращается к имени `docs_active`, а это **алиас** коллекции `docs_v1`. Вы заранее подготовили `docs_v2` и хотите направить запросы к ней, не меняя имя в приложении. Qdrant разрешает обращаться к коллекции по алиасу и атомарно менять его цель: один запрос на изменение алиасов удаляет прежнюю связь и создаёт новую. Два отдельных запроса для этого не равнозначны. [s1](#src-s1) [s3](#src-s3)

Само переназначение **не** копирует документы, не создаёт векторы и не обновляет модель, которая превращает новый поисковый запрос в вектор (embedding-модель). Если вы меняете именно эту модель, подготовьте новую коллекцию и согласуйте переход приложения на новую модель запросов: атомарность алиаса не гарантирует атомарности всей пары «приложение + модель поиска». Это наш вывод из разделения этапов в руководстве Qdrant, а не обещание бесшовной миграции. [s2](#src-s2)

## Что проверить до изменения рабочего адреса?

Используйте закрытый тестовый Qdrant, а не боевой кластер; в примере ниже имена `docs_v1`, `docs_v2` и `docs_active` **учебные**. Убедитесь, что обе коллекции существуют, `docs_active` сейчас указывает на `docs_v1`, а приложение обращается именно к алиасу, не к жёстко прописанной `docs_v1`. Список связей возвращает `GET /aliases`; сведения о конкретной коллекции — `GET /collections/{collection_name}`. На локальном тестовом сервере первое чтение: `curl -fsS 'http://127.0.0.1:6333/aliases'`. В ответе проверьте `result.aliases`: до изменения ожидайте пару `alias_name: docs_active`, `collection_name: docs_v1`. Не запускайте POST, если текущая цель не та. [s1](#src-s1)

Если перестраиваете векторы для другой модели, пересчитайте их из исходных данных, сравните число и контрольные ID, а затем проверьте выдачу по нескольким вашим вопросам на **обеих** коллекциях. Новые записи во время подготовки должны попадать в обе; для удалений и частичных обновлений документация требует отдельного механизма либо паузы. На этапе поиска обновите модель векторизации **запросов**, иначе сопоставление со старой/новой коллекцией может потерять смысл. Не выдавайте пример миграции Qdrant с Cloud Inference за полностью локальную схему: для офлайна требуется отдельная проверка каждого компонента. [s2](#src-s2)

Зафиксируйте цель алиаса и контрольную выдачу до изменения, сохраните план возврата к `docs_v1` и не удаляйте её сразу. Snapshot коллекции не содержит алиасов — его маршрут отдельно описан в [гайде о резервной копии](/zhurnal/qdrant-snapshots/). На сервере с API-ключом добавьте требуемый заголовок `api-key` безопасным способом; не вставляйте секрет в публичный текст или снимки экрана. [s1](#src-s1)

## Как переназначить алиас и проверить ответ?

**Только на собственном тестовом Qdrant**, где обе коллекции подготовлены, выполните один запрос: `curl -fsS -X POST 'http://127.0.0.1:6333/collections/aliases' -H 'Content-Type: application/json' -d '{"actions":[{"delete_alias":{"alias_name":"docs_active"}},{"create_alias":{"collection_name":"docs_v2","alias_name":"docs_active"}}]}'`. Ожидайте ответ со `status: ok` и `result: true`. Не разбивайте действия на два POST: Qdrant документирует атомарность общего запроса. [s1](#src-s1) [s3](#src-s3)

Снова вызовите `curl -fsS 'http://127.0.0.1:6333/aliases'` и проверьте в `result.aliases` пару `docs_active → docs_v2`. Затем отправьте тот же **контрольный запрос через алиас** и напрямую к `docs_v2`; сравните идентификаторы документов и ответы приложения с заранее сохранённым эталоном. `status: ok` сам по себе показывает только результат операции над алиасом, не качество поиска. Если чтение алиаса или контрольный поиск не прошли, остановите дальнейшую миграцию и разберите точный ответ API. [s1](#src-s1) [s2](#src-s2) [s3](#src-s3)

Для возврата при ошибке, **пока **`**docs_v1**`** ещё доступна и совместима с моделью запросов**, повторите одну атомарную операцию с `delete_alias` для `docs_active` и `create_alias` для `docs_v1`, затем опять проверьте `GET /aliases` и контрольный поиск. Если приложение уже переключилось на другую embedding-модель, сначала согласуйте его возврат: один откат алиаса может не восстановить правильные ответы. Это инструкция по документации, не испытанный план аварийного восстановления Modelium. [s1](#src-s1) [s2](#src-s2)

**Следующий шаг:** проведите [проверку качества поиска](/zhurnal/ocenka-kachestva-rag/) на фиксированном наборе вопросов и сравните результаты обеих коллекций до изменения рабочего алиаса. [s2](#src-s2)

## Источники

1. [Qdrant — Collections: Collection Aliases](https://qdrant.tech/documentation/manage-data/collections/) — получено 2026-10-17
2. [Qdrant — Migrate to a New Embedding Model](https://qdrant.tech/documentation/tutorials-operations/embedding-model-migration/) — получено 2026-10-17
3. [Qdrant REST API — Update collection aliases](https://api.qdrant.tech/api-reference/aliases/update-aliases) — получено 2026-10-17