Векторные базы данных в 2026: обзор технологии и ключевых сервисов
Векторная база данных — специализированное хранилище, оптимизированное для поиска похожих объектов в многомерном пространстве. Если классическая база отвечает на вопрос «найди записи, где поле = 100», векторная отвечает на вопрос «найди записи, наиболее похожие на этот вектор из 1536 чисел». За последние три года векторные БД из академической экзотики превратились в обязательный компонент любой LLM-системы — без них не работают RAG, семантический поиск, рекомендательные системы.
В этой статье — как устроены векторные базы данных, какие алгоритмы поиска используются, какие метрики близости применяются для разных задач, обзор ключевых игроков рынка в 2026 году и практические рекомендации по выбору базы под конкретную нагрузку.
Что такое векторная база данных
Векторная база данных (vector database) — система хранения и поиска объектов, представленных в виде векторов фиксированной размерности. Вектор — массив чисел с плавающей точкой, обычно от 128 до 4096 измерений. Каждое измерение отражает какую-то характеристику объекта, но в современных эмбеддингах эти характеристики не интерпретируемы человеком — они результат обучения нейросетевой модели.
Главная операция векторной БД — k-nearest neighbors (k-NN) search: «найди k объектов, чьи векторы наиболее близки к данному». Близость измеряется математически — через косинусное сходство, евклидово расстояние или скалярное произведение.
Векторные БД появились задолго до эры LLM (Milvus — 2019, Pinecone — 2019, Weaviate — 2019), но массовое применение получили после релиза ChatGPT в конце 2022 года. RAG-системы создали лавинообразный спрос на инфраструктуру для семантического поиска.
Зачем нужна (vs реляционные БД)
| Параметр | Реляционные БД | Векторные БД |
|---|---|---|
| Тип запросов | WHERE с точными условиями | K-NN поиск по близости |
| Структура данных | Строки и столбцы | Векторы + метаданные |
| Индексы | B-tree, Hash | HNSW, IVF, ScaNN |
| Размер на запись | Десятки байт | Килобайты |
| Производительность | Миллионы записей | Миллиарды векторов |
| Latency для поиска | Миллисекунды | 10–100 мс |
| Тип близости | Точное совпадение | Семантическая |
Попытка делать векторный поиск в реляционной БД упирается в производительность: для каждого запроса нужно сравнить вектор с каждой записью в таблице. На 1 миллионе записей это становится непрактично медленно. Векторные БД используют специализированные индексы, которые позволяют отвечать на запросы за миллисекунды даже на сотнях миллионов векторов.
Эмбеддинги: основа векторных БД
Эмбеддинг — векторное представление объекта (текста, изображения, аудио), полученное через нейросетевую модель. Близкие по смыслу объекты получают близкие векторы.
Свойства качественного эмбеддинга:
- Семантическая близость. «Кошка» и «котёнок» имеют близкие векторы, «кошка» и «трактор» — далёкие.
- Линейная композиция. Векторные операции часто отражают семантические: «король» − «мужчина» + «женщина» ≈ «королева».
- Инвариантность к мелким изменениям. «Купить ноутбук» и «приобрести лэптоп» дают близкие векторы.
- Чувствительность к контексту. «Банк реки» и «банк-кредитор» дают разные векторы благодаря контекстному эмбеддингу.
Качество эмбеддингов критично для всей системы. Плохая embedding-модель сделает любую векторную БД бесполезной: поиск будет возвращать нерелевантные результаты независимо от технологии хранения.
Алгоритмы поиска: HNSW, IVF, ScaNN
Точный k-NN-поиск (brute force) сравнивает запрос со всеми векторами в базе. Сложность — O(n×d), где n — число векторов, d — размерность. На больших объёмах это непрактично.
Решение — приближённый поиск (Approximate Nearest Neighbors, ANN). Он жертвует точностью (находит «почти ближайших», а не строго ближайших) ради скорости. На практике точность 95–99% при ускорении в десятки и сотни раз — приемлемый компромисс.
HNSW (Hierarchical Navigable Small World)
Самый популярный алгоритм для векторных БД в 2026 году. Использует многоуровневый граф, где векторы связаны рёбрами с близкими соседями. Поиск идёт сверху вниз: сначала по «грубому» уровню с дальними связями, затем уточняется на нижних уровнях.
Преимущества: высокая точность, низкая латентность, подходит для большинства задач. Недостатки: память (граф занимает место), сложность обновлений (вставка нового вектора может потребовать перестройки связей).
IVF (Inverted File Index)
Векторы делятся на кластеры (через k-means). Каждый кластер имеет centroid. При поиске запрос сначала сравнивается с centroids, выбираются ближайшие кластеры, и только в них происходит поиск.
Преимущества: экономия памяти, проще управлять обновлениями. Недостатки: ниже точность, чем у HNSW; точность зависит от качества кластеризации.
IVF + PQ (Product Quantization)
IVF в комбинации с квантизацией. PQ сжимает векторы, разбивая их на под-векторы и заменяя каждый на ближайший из небольшого «словаря». Дополнительно экономит память за счёт небольшой потери точности.
ScaNN (Scalable Nearest Neighbors)
Алгоритм Google, используется в Vertex AI. Сочетает анизотропную квантизацию с продвинутыми техниками отсева. Часто показывает лучшие результаты в бенчмарках по соотношению скорость / точность.
DiskANN
Алгоритм Microsoft, оптимизированный для хранения индекса на SSD, а не в памяти. Позволяет работать с базами в миллиарды векторов на скромном железе.
Метрики близости: cosine, dot product, Euclidean
Способов измерить «близость» двух векторов несколько. Выбор зависит от природы данных и embedding-модели.
| Метрика | Формула (упрощённо) | Применение |
|---|---|---|
| Cosine similarity | cos(θ) = (A·B) / (|A|×|B|) | Текстовые эмбеддинги, стандарт |
| Dot product | A·B = Σ(aᵢ × bᵢ) | Когда эмбеддинги нормализованы |
| Euclidean (L2) | √Σ(aᵢ − bᵢ)² | Геометрические данные, изображения |
| Manhattan (L1) | Σ|aᵢ − bᵢ| | Редко, специфические случаи |
| Hamming | Количество отличающихся битов | Бинарные эмбеддинги |
Cosine similarity — самая популярная для текстовых задач. Она измеряет угол между векторами, игнорируя их длину. Это удобно для текстов, потому что длина вектора часто отражает не семантику, а лишь характеристики обучения модели.
Если эмбеддинги уже нормализованы (длина = 1), cosine similarity математически эквивалентна dot product, но dot product вычисляется быстрее. Поэтому многие БД хранят нормализованные векторы и используют dot product для скорости.
Метаданные и фильтрация
Векторные БД хранят не только векторы, но и связанные с ними метаданные: источник документа, дата создания, тип, теги, права доступа. Это позволяет комбинировать векторный поиск с фильтрами.
Пример запроса: «Найди 5 наиболее похожих документов на эту тему, но только из категории „юридические“ за последний год».
Реализация фильтрации:
- Pre-filter. Сначала отсеиваются документы по метаданным, затем векторный поиск среди оставшихся. Точнее, но медленнее для больших фильтров.
- Post-filter. Сначала векторный поиск, затем фильтрация результата. Быстрее, но может вернуть мало результатов после фильтра.
- Hybrid. Современные БД комбинируют подходы в зависимости от селективности фильтра.
Качество фильтрации — серьёзное различие между векторными БД. Pinecone, Qdrant, Weaviate в 2026 году поддерживают сложную фильтрацию с боковыми условиями. ChromaDB и pgvector — базовую.
Pinecone
Лидер managed-сегмента. Полностью облачный сервис без необходимости управлять инфраструктурой.
Особенности:
- Serverless и pod-based варианты развёртывания
- Автоматическое масштабирование
- Высокая производительность на больших объёмах
- Простой API
- Интеграция с LangChain, LlamaIndex из коробки
Стоимость: serverless начинается от $0 (free tier) и масштабируется по использованию. Pod-based — от $70/мес. На больших объёмах может быть дорогим.
Когда выбирать: managed-решение для production без желания управлять инфраструктурой. Подходит для команд, ценящих простоту над контролем.
Weaviate
Open-source с опциональным managed cloud. Гибкая база с продвинутыми возможностями.
Особенности:
- Встроенные модули для embedding’а (можно не использовать внешние модели)
- GraphQL API в дополнение к REST
- Поддержка multi-modal данных (текст + изображения)
- Hybrid search (BM25 + векторный) из коробки
- Высокая гибкость схемы данных
Стоимость: self-hosted — бесплатно (стоимость инфраструктуры). Weaviate Cloud — от $25/мес.
Когда выбирать: команды, которым нужна гибкость и продвинутые функции. Хорошо подходит для сложных приложений с разнородными данными.
Qdrant
Open-source векторная БД, написанная на Rust. Высокая производительность и низкое потребление памяти.
Особенности:
- Лучшая в классе производительность на benchmarks
- Расширенные фильтры (полноценные boolean expressions)
- Точная настройка HNSW-параметров
- Quantization для экономии памяти
- Sparse vectors (для гибридного поиска)
Стоимость: self-hosted — бесплатно. Qdrant Cloud — от $0 (free tier) с масштабированием по использованию.
Когда выбирать: команды, ценящие производительность и контроль над параметрами. Хороший выбор для российского и белорусского рынка благодаря open-source природе.
Milvus
Open-source enterprise-grade векторная БД. Распределённая архитектура, готовая к большим нагрузкам.
Особенности:
- Горизонтальное масштабирование
- Поддержка миллиардов векторов
- GPU-ускорение для индексации
- Несколько индексных алгоритмов (HNSW, IVF, DiskANN)
- Cloud-native архитектура (Kubernetes-friendly)
Стоимость: self-hosted — бесплатно. Zilliz Cloud (managed Milvus) — от $0 с масштабированием.
Когда выбирать: enterprise-сценарии с миллиардами векторов, требования к горизонтальному масштабированию.
ChromaDB
Минималистичная open-source БД, оптимизированная для прототипирования и небольших production-нагрузок.
Особенности:
- Простой Python-API
- Локальный режим (embedded в приложение)
- Server-режим для multi-client сценариев
- Хорошая документация для начинающих
Стоимость: self-hosted — бесплатно. Chroma Cloud (anniversary 2024) — managed-сервис.
Когда выбирать: прототипы, эксперименты, малые production-проекты. Идеальный «первый выбор» для команд, начинающих с RAG.
pgvector
Расширение для PostgreSQL, добавляющее векторный поиск к классической реляционной БД.
Особенности:
- Интеграция в существующую Postgres-инфраструктуру
- Возможность сложных JOIN’ов с реляционными таблицами
- Поддержка HNSW (с версии 0.5)
- Используется в Supabase, Neon, AWS Aurora
Стоимость: бесплатно при self-hosted Postgres. Managed Postgres-сервисы взимают стандартную плату за БД.
Когда выбирать: команды, уже использующие Postgres и не желающие добавлять отдельную систему. Производительность ниже специализированных БД, но достаточна для большинства задач.
Сравнительная таблица
| База | Тип | Подходит для | Слабые места |
|---|---|---|---|
| Pinecone | SaaS | Production без управления инфры | Стоимость на больших объёмах |
| Weaviate | Open + cloud | Гибкие приложения, multi-modal | Более крутая кривая обучения |
| Qdrant | Open + cloud | Высокая производительность | Меньше экосистема, чем у конкурентов |
| Milvus | Open + cloud | Enterprise, миллиарды векторов | Сложная для малых проектов |
| ChromaDB | Open | Прототипы, малый production | Не для больших нагрузок |
| pgvector | Postgres extension | Существующий Postgres-стек | Производительность ниже специализированных |
| Vespa | Open | Поисковые движки | Сложная конфигурация |
| Elasticsearch + ELSER | Open + cloud | Текстовый поиск + векторы | Векторный функционал менее зрелый |
| Vertex AI Vector Search | Google Cloud | GCP-проекты | Lock-in на Google |
| Azure AI Search | Microsoft Cloud | Azure-проекты | Lock-in на Microsoft |
Как выбрать векторную БД
Размер данных
- До 100 000 векторов. ChromaDB, pgvector — простота важнее производительности.
- 100 000 – 10 миллионов. Pinecone, Qdrant, Weaviate — золотая середина.
- 10 миллионов – 1 миллиард. Pinecone Pod-based, Qdrant, Milvus, Weaviate.
- Свыше 1 миллиарда. Milvus, специализированные решения, often custom builds.
Требования к latency
- До 1 секунды (синхронный RAG): почти любая база справится.
- Меньше 100 мс (real-time приложения): Qdrant, Pinecone, специализированный тюнинг.
- Меньше 10 мс (высоконагруженные продукты): Milvus с GPU, Pinecone Serverless, кастомные решения.
Стиль развёртывания
- Managed (без админов): Pinecone, Weaviate Cloud, Qdrant Cloud, Vertex AI.
- Self-hosted: Qdrant, Milvus, Weaviate self-hosted, ChromaDB.
- Расширение существующей БД: pgvector, Elasticsearch.
Privacy и compliance
- Высокие требования к локализации данных: self-hosted решения. Для российского рынка — Qdrant, Milvus, pgvector на собственных серверах.
- Standard SaaS: Pinecone (US), Weaviate Cloud (US + EU).
Типичные ошибки
- Выбор БД до выбора embedding-модели. Размерность векторов и метрика близости зависят от модели. Сначала определитесь, какие эмбеддинги использовать.
- Игнорирование стоимости на масштабе. Pinecone выгоден на старте, но на миллионах векторов может стоить тысячи USD/мес.
- Использование тяжёлой БД для прототипа. Milvus для проекта на 10 000 векторов — overengineering. ChromaDB закроет задачу за час.
- Отсутствие фильтрации. Без метаданных и фильтров RAG-системы выдают много нерелевантных результатов.
- Слепое доверие к defaults. Параметры HNSW (M, ef_construction) значительно влияют на качество. Дефолты — компромисс, не оптимум.
- Игнорирование hybrid search. Чистый векторный поиск пропускает запросы с точными терминами. BM25 + векторы работают лучше.
- Нагрузочное тестирование не на реальных данных. Производительность сильно зависит от характера данных. Тестируйте на представительной выборке.
- Отсутствие мониторинга качества. Запустили в production — забыли. Качество retrieval деградирует со временем, нужны метрики и регулярный анализ.
- Vendor lock-in без необходимости. Pinecone, Vertex AI создают зависимость от провайдера. Open-source альтернативы дают свободу.
- Игнорирование стоимости embedding’ов. Embedding миллиона документов через OpenAI API — десятки долларов. На больших объёмах это серьёзные расходы.
Часто задаваемые вопросы
Нужна ли векторная БД для маленького проекта?
Для проекта с парой сотен документов хватает поиска через cosine similarity на in-memory массивах. Векторная БД нужна, когда документов больше 10 000 или требуется параллельный доступ от множества пользователей.
Можно ли использовать одну векторную БД для разных приложений?
Да, через концепцию collections / namespaces. Каждое приложение работает со своим логическим разделом базы. Это снижает операционные расходы по сравнению с поднятием отдельных БД.
Какую размерность векторов выбрать?
Стандарт для текстовых эмбеддингов — 768, 1024 или 1536. Выше — больше «информации» в векторе, но дороже хранение и поиск. Часто оптимум — 1024.
Как мигрировать между векторными БД?
Большинство БД поддерживают экспорт в JSON или Parquet. Векторы переносятся as-is, метаданные требуют адаптации схемы. Главное — не нужно пересчитывать embedding’и, что экономит время и деньги.
Что такое sparse vectors?
Векторы с большим количеством нулей — традиционные BM25-векторы или модели типа SPLADE. Используются в hybrid search вместе с dense vectors. Pinecone, Qdrant, Weaviate поддерживают sparse vectors начиная с 2023–2024 годов.
Векторная БД заменяет реляционную?
Не заменяет, а дополняет. Реляционная БД хранит структурированные данные с строгими отношениями. Векторная БД работает с семантическим поиском. Чаще всего работают параллельно: метаданные в Postgres, векторы в Qdrant, с привязкой через ID.
Заключение
Векторные базы данных перестали быть нишевым инструментом и стали стандартным компонентом современного AI-стека. Выбор конкретной базы — не вопрос «какая лучше», а вопрос «какая подходит под конкретные требования к масштабу, latency, бюджету и операционной модели». Для прототипа достаточно ChromaDB. Для крупного production — Pinecone, Qdrant, Milvus. Для команд с существующей Postgres-инфраструктурой — pgvector. Понимание базовых концепций (эмбеддинги, ANN-алгоритмы, метрики близости) важнее знания конкретного продукта: технологии меняются быстро, но принципы остаются.