Qdrant: что это и зачем

Midjourney генерирует 15 миллионов изображений в день. Каждое - вектор из 1024 float32. Найти «похожие» среди 100 миллионов за 10 мс - это не `LIKE '%query%'`. Это HNSW (Hierarchical Navigable Small World) граф. Qdrant написан на Rust, обрабатывает 100k+ RPS, payload filtering работает на уровне HNSW traversal. Pinecone берёт 0.096/h за managed pod. Qdrant self-hosted - бесплатно. Для нагруженного сервиса разрыв - тысячи долларов в месяц.

• **Notion AI Search** - 10M+ пользователей ищут по заметкам по смыслу, не по ключевым словам; фильтрация по workspace на уровне HNSW
• **GitHub Copilot** - code embeddings dim=1536, поиск похожего кода в кодовой базе за миллисекунды
• **Spotify** - ANN поверх 100 миллионов треков для song recommendations; embedding + payload filter по жанру и рынку
• **Cloudflare WAF** - vector embeddings для детекции аномалий в HTTP-трафике в реальном времени

Почему обычные базы данных не справляются

Midjourney генерирует 15 миллионов изображений в день. Каждое - вектор из 1024 float32. Найти «похожие» среди 100 миллионов за 10 мс - это не `LIKE '%query%'`. SQL умеет WHERE, LIKE, полнотекстовый поиск. Смысловое сходство им недоступно.

**Решение - embeddings.** Языковая модель превращает текст в числовой вектор из 1536 float32 - там, где смысловое сходство равно геометрическому расстоянию. Документы про машинное обучение кластеризуются рядом в этом 1536-мерном пространстве - независимо от конкретных слов. GitHub Copilot использует dim=1536 именно так: находит похожий код по смыслу, не по синтаксису.

**Проблема масштаба.** Для 1 миллиона документов brute-force (перебор всех пар) требует 1.5 миллиарда операций на запрос - это 5 секунд при 1 RPS. Vector database решает за 5-20 мс через специализированный индекс. Spotify строит ANN поверх 100 миллионов треков именно так.

**Vector database** - не замена PostgreSQL, а специализированный инструмент для одной задачи: хранить векторы и искать ближайшие за миллисекунды. Часто используется вместе с Postgres: основные данные там, embeddings - в Qdrant.

Архитектура Qdrant: от точки до кластера

**Qdrant** - open-source vector database на Rust (2021). Rust - не маркетинг: нет GC-пауз, нет GIL, предсказуемая latency на p99. HNSW-индекс в Qdrant в 3-5 раз быстрее Python-реализаций при аналогичном recall - именно поэтому Qdrant обрабатывает 100k+ RPS там, где Python-аналог начинает задыхаться.

**Основные понятия Qdrant:**

**Сегменты** - ключевая идея внутри. Коллекция делится на несколько сегментов, каждый со своим HNSW-индексом. Запись идёт в оперативный сегмент, чтение - из проиндексированных. Оптимизатор перестраивает индекс фоново. Нет глобальных блокировок - поэтому Qdrant можно одновременно заливать и запрашивать без деградации latency.

payload filtering в Qdrant работает на уровне HNSW traversal - не после. Это значит, что поиск «похожие документы категории legal» обходит только нужные точки в графе. Не фильтрует 100 кандидатов в конце. Это фундаментальная разница в recall при узких фильтрах.

Qdrant vs конкуренты: выбор vector database

Pinecone берёт 0.096 в час за managed pod. Qdrant self-hosted - бесплатно. При 10 подах для нагруженного RAG-сервиса разрыв - тысячи долларов в месяц. Выбор vector database - это не только техника.

**Ключевое преимущество Qdrant - фильтрация без компромисса по recall.** Большинство vector databases при добавлении фильтров ухудшают качество: индекс строится на всех данных, результаты фильтруются постфактум. Qdrant использует filterable HNSW: поиск обходит только точки, прошедшие фильтр. Notion AI с 10M+ пользователями использует этот подход для фильтрации по workspace.

**pgvector** - хороший выбор для старта: данных < 500K, уже есть PostgreSQL, нет отдельного DevOps. Для production с миллионами документов, сложными фильтрами и latency < 20ms - Qdrant. Cloudflare WAF использует vector embeddings для аномалий именно на кастомном стеке, а не pgvector: масштаб не тот.

**Кто использует Qdrant в production?** Microsoft (Semantic Kernel), Notion (AI search), Dust.tt, десятки YC-стартапов. Qdrant Cloud - managed версия с EU-hosted серверами (важно для GDPR).

Ключевые идеи

• **SQL не понимает смысл** - LIKE и tsvector требуют точных слов; embeddings кодируют смысл в числа, и семантически похожие тексты оказываются рядом в векторном пространстве
• **HNSW - не просто быстро, а принципиально** - brute-force на 1M документов занимает 5 секунд, HNSW - 15 мс; разрыв растёт с масштабом
• **Qdrant = Point (ID + вектор + payload)** - минимальная единица; коллекция хранит тысячи таких точек с HNSW-индексом поверх
• **Filterable HNSW** - фильтр применяется до поиска, не после; recall не деградирует при узких фильтрах (2% данных = те же top-10)
• **Pinecone vs Qdrant** - разница не только техническая: 0.096/h/pod против бесплатного self-hosted при том же recall

Что дальше

Теория без практики - ничто. Следующий урок: запустим Qdrant и сделаем первый запрос.

• Установка и первый запуск — Запустим Docker, исследуем Web UI, сделаем первый REST-запрос
• Embeddings (AI Engineering) — Откуда берутся векторы, которые мы кладём в Qdrant

Вопросы для размышления

• Какие задачи в текущем проекте могли бы выиграть от семантического поиска вместо полнотекстового?
• Если данных 100K и PostgreSQL уже в проекте - стоит ли переходить на Qdrant? Что перевешивает?
• Почему Rust - важное архитектурное решение для vector database, а не просто маркетинг?

Связанные уроки

• qd-02-install — Практика: запустим Qdrant и сделаем первый запрос после освоения теории.
• ml-01-intro — Embeddings - основа vector search; понимание ML помогает осмыслить семантическое пространство.
• ir-01 — Information retrieval - классическое основание, которое vector search расширяет от keyword matching к semantic similarity.
• ds-01-intro — Сегменты и шарды в Qdrant - та же distributed systems архитектура: независимые узлы, HNSW-индексы по сегментам.
• alg-01-big-o — HNSW - это O(log n) поиск в n-мерном пространстве; понимание сложности алгоритмов объясняет 1666x ускорение vs brute-force.
• db-01-intro