Vector Database

Vector Database (векторная БД) — специальная база данных для хранения embedding-векторов и быстрого поиска ближайших по смыслу. В отличие от обычной БД, которая ищет точные совпадения, векторная находит соседей в многомерном пространстве. Это основа RAG, семантического поиска, рекомендательных систем и мультимодального поиска. Популярные: Chroma, Qdrant, Weaviate, Pinecone, pgvector.

Коротко

Коротко. Vector Database — это база, которая хранит embedding-вектора и быстро находит самые близкие к данному. Поиск идёт не по строгому совпадению, а по семантической близости через косинусное расстояние или его варианты. Используется в RAG, семантическом поиске, рекомендациях, кросс-модальном поиске. Открытые: Chroma, Qdrant, Weaviate, FAISS, pgvector. Облачные: Pinecone, Weaviate Cloud, Vespa.

Что это такое

2023 год: бум AI-стартапов. Каждый второй — это «GPT для документов». Под капотом — embedding, поиск, LLM. И в этом стеке внезапно оказывается узкое место. Обычные базы (PostgreSQL, MySQL) хранят строки, числа, JSON; искать соседей в 1536-мерном пространстве они не умеют.

Так разрастается отдельная категория — vector databases. Они делают одну специальную вещь: хранят embedding-вектора и быстро (за миллисекунды на миллионах записей) находят те, что ближе всего к запросу.

«Близкие» здесь — в смысле геометрии многомерного пространства. У каждого вектора есть координаты (1536 чисел для OpenAI ada-002, 384 для bge-small). Расстояние между двумя векторами считается через косинус угла между ними или евклидову формулу. Два вектора, чьи смыслы похожи, оказываются ближе друг к другу — Vector DB ищет этих соседей.

К 2026-му Vector DB — это стандартный компонент любого AI-приложения с собственными данными. Сотни тысяч инсталляций Chroma, миллионы в облачных сервисах. По росту рынка обогнали NoSQL в своё время.

Если смотреть не на базу отдельно, а на весь путь от документа до ответа, полезно открыть большой разбор «RAG и AI-поиск в 2026». Там видно, где Vector DB стоит в пайплайне: после embedding и до hybrid search, reranking и финального ответа LLM.

Как это работает

Vector DB хранит две сущности на каждую запись:

1. Вектор — embedding объекта (фрагмента текста, картинки, аудио-клипа).
2. Метаданные — оригинальный текст, ссылка на источник, теги, дата, любой JSON.

При запросе:

1. Пользователь передаёт вектор-запрос (тоже посчитанный embedding-моделью).
2. БД находит top-K ближайших векторов в индексе.
3. Возвращает их вместе с метаданными.

Главная сложность — скорость на больших объёмах. Перебор всех векторов «в лоб» (brute-force) работает только до десятков тысяч. На миллионах и миллиардах нужны специальные индексы:

• HNSW (Hierarchical Navigable Small World). Граф многослойной структуры; поиск идёт сверху вниз. Стандарт для большинства задач. Используют Qdrant, Weaviate, Pinecone.
• IVF (Inverted File Index). Пространство делится на кластеры; поиск идёт только в нескольких ближайших. Быстро, но менее точно.
• PQ (Product Quantization). Сжатие самих векторов для экономии памяти. Часто комбинируют с IVF или HNSW.
• DiskANN. Индекс на SSD вместо RAM; для очень больших баз (миллиарды векторов).

Большинство векторных БД используют ANN (Approximate Nearest Neighbor) — приблизительный поиск. Это компромисс: чуть менее точно, но в сотни раз быстрее. Для практических задач это незаметно.

Метрики близости в порядке популярности:

Метрика	Применение
Cosine similarity	Стандарт для текстовых embeddings
Euclidean (L2)	Когда embeddings не нормализованы
Dot product	Совместим с косинусом, если векторы нормализованы
Manhattan (L1)	Реже, для специфичных задач

Пример на практике

Видеомонтажёр индексирует свою коллекцию из 50 000 кадров (стоковая библиотека + личный архив). Цель: «найди мне кадры с похожим настроением, как этот».

Стек:

• Embedding: CLIP ViT-B/32 (открытая модель, 350 МБ, CPU/GPU).
• Vector DB: Qdrant локально через Docker.
• UI: простой Streamlit интерфейс.

Шаги:

1. Скрипт читает все кадры (50K JPG-файлов). Для каждого вызывает CLIP-encoder, получает 512-мерный embedding.
2. Складывает вектора в Qdrant вместе с путём к файлу и тегами (тематика, цвета, размеры).
3. Создаётся HNSW-индекс по всем 50K векторам — занимает 2 минуты на ноутбуке.
4. Пользователь даёт референс-кадр или текстовый запрос («тёмная улица с дождём»). Тот же CLIP считает embedding.
5. Qdrant выдаёт top-20 ближайших кадров за 15 миллисекунд.

Размер базы: 50K × 512 × 4 байта = 100 МБ векторов + индекс. На SSD влезает легко.

Когда количество кадров доходит до миллиона, vacuum-CPU становится медленным — добавляется GPU для embedding'а или переход на облако (Pinecone).

В ComfyUI ровно тот же подход собирается визуально: ноды CLIP Image Encode, Qdrant Search, Image Loader из найденного пути. Идеально для поиска похожих по стилю изображений в большом архиве.

С чем часто путают

• Vector DB и обычная БД — обычная БД ищет точные совпадения по ключу/индексу. Vector DB ищет «похожие» по геометрии в многомерном пространстве. Это разные задачи; современные решения часто их совмещают (фильтр по метаданным + векторный поиск).
• Vector DB и embedding-модель — модель создаёт вектора. БД их хранит и ищет. Разные компоненты, обычно из разных репозиториев.
• Vector DB и RAG — RAG это пайплайн, использующий Vector DB как один из компонентов. БД сама по себе не «делает RAG», она хранит и ищет.
• Vector DB и semantic search — semantic search это use-case; Vector DB — инструмент его реализации.
• HNSW и kNN — kNN это математическая задача «найти K ближайших». HNSW — алгоритм её приближённого решения. На малых данных можно использовать брутфорс kNN; на больших — нужны индексы типа HNSW.

Частые ошибки и заблуждения

• «Vector DB — это новое модное название для NoSQL». Не совсем. NoSQL это документные БД (MongoDB), key-value (Redis), графовые (Neo4j). Vector DB — отдельная категория, заточенная под ANN-поиск.
• «Самая большая БД — самая лучшая». На малых объёмах (до 100K векторов) Pinecone или Weaviate избыточны. Chroma или pgvector хватит. На миллионах — стоит сравнивать по скорости, цене и features.
• «Поиск всегда точный». ANN — приблизительный. На стандартных настройках recall 95–99%. Точнее можно — за счёт скорости. Для критичных задач есть exact-mode (брутфорс).
• «Все embedding-модели совместимы с любой Vector DB». Совместимы по интерфейсу (вектор → вектор), но не по пространству. Нельзя индексировать одной моделью и искать другой — это разные «системы координат».
• «Достаточно посчитать embedding и сохранить». Метаданные часто важнее вектора. Без них вы не сможете отфильтровать «только этого автора», «после 2024-го», «только опубликованные».

Связанные термины

• Embedding — что хранится в Vector DB.
• RAG — главный потребитель Vector DB.
• ANN (Approximate Nearest Neighbor) — алгоритмы поиска внутри.
• HNSW — самый популярный ANN-алгоритм.
• Cosine similarity — основная метрика близости.
• Hybrid search — комбинация векторного и keyword-поиска.
• Reranking — пересортировка результатов более точной моделью.
• pgvector — расширение PostgreSQL для векторов.

Частые вопросы

Сколько векторов поместится в памяти? В Chroma in-memory: 1536-мерные вектора в FP32 = 6 КБ каждый. На 16 ГБ RAM — ~2.5 миллиона векторов с метаданными. С квантизацией (PQ) — в 4–8 раз больше.

Чем Qdrant отличается от Pinecone? Qdrant — open-source, можно запускать локально или self-hosted. Pinecone — managed cloud-сервис, без локальной установки. По API и features близки.

Можно ли использовать PostgreSQL вместо Vector DB? Да, через расширение pgvector. Удобно, если уже есть Postgres-инфраструктура. На крупных объёмах (10M+ векторов) специализированные БД быстрее.

Что такое hybrid search? Параллельный запрос в keyword-индекс (BM25) и векторный, потом смешивание результатов. Обычно даёт лучший recall на смешанных запросах (например, «iPhone 15 Pro отзывы»).

Как обновлять вектор существующей записи? Все Vector DB поддерживают upsert: если запись с таким id есть — обновить вектор и метаданные. Это типичная операция при изменении документа в RAG.

Главное

Vector Database — узкоспециализированный инструмент для одной задачи: хранить embedding'и и быстро искать соседей. Это фундамент RAG, семантического поиска, рекомендательных систем и кросс-модального поиска. Для домашних проектов хватит Chroma или pgvector; для production — Qdrant или Pinecone. Выбор сводится к комбинации скорости, точности (recall), цены и фичей (фильтры, hybrid search, multi-tenancy). Без векторной БД построить современный AI-стек уже почти невозможно, и эта категория осталась с нами надолго.