Vector database, или векторная база данных, — это система для хранения и быстрого поиска высокоразмерных векторов. На практике она нужна, когда вы превращаете текст, изображения или другие объекты в embedding-векторы и хотите находить самые похожие элементы без полного перебора.
Английский термин: vector database. Также встречается: векторная база данных, векторная БД. Не путайте её с самим embedding: embedding — это векторное представление объекта, а vector database — система, которая эти векторы хранит, индексирует и возвращает по запросу.
Простыми словами
Грубо говоря, векторную БД можно представить как картотеку, где записи ищутся не по точному слову, а по близости «координат смысла». Если два текста после преобразования в векторы оказываются рядом, система считает их похожими и может вернуть один по запросу к другому.
Поэтому векторная БД особенно полезна там, где пользователь формулирует вопрос своими словами, а нужный ответ лежит в документе с другой формулировкой. Для RAG это типичный сценарий: сначала находите релевантные фрагменты, потом уже передаёте их модели.
Как это работает
Официальные документы Qdrant, Weaviate и Milvus сходятся в главном: речь идёт о хранении и поиске по векторам, а не просто о ещё одной таблице с числами. Weaviate отдельно подчёркивает, что может хранить объекты данных и их vector embeddings, а его поиск включает vector similarity search, hybrid search, фильтры, RAG и reranking.
- Вы берёте объект: абзац документа, карточку товара, вопрос-ответ или изображение.
- Модель преобразует этот объект в embedding-вектор.
- Вектор и связанные данные сохраняются в системе. В Weaviate это описано как хранение объектов и их embeddings.
- Для быстрого поиска строится индекс. Во многих системах используются approximate nearest neighbor-подходы; один из самых известных — графовый HNSW из одноимённой статьи.
- Когда приходит новый запрос, он тоже превращается в вектор.
- База ищет ближайшие векторы, а затем может применить фильтры, hybrid search и reranking, если это поддерживается выбранной системой.
- Полученные фрагменты уходят в приложение, поиск или RAG-пайплайн, где LLM уже строит ответ на основе найденного контекста.
Документы / объекты
↓
embedding-модель
↓
векторы + метаданные
↓
vector database
(хранение + индекс ANN/HNSW)
↓
запрос пользователя
↓
вектор запроса
↓
поиск ближайших соседей
↓
фильтры / hybrid / reranking
↓
найденные фрагменты
↓
RAG / ответ
Важная деталь: HNSW — это не «магия смысла», а способ приблизительного поиска ближайших соседей. То есть система обычно ищет очень близкие результаты быстро, но сама природа ANN-поиска означает компромисс между скоростью и точностью.
Где применяется
- RAG для корпоративной базы знаний. Вы индексируете инструкции, регламенты и FAQ, а затем находите релевантные куски текста перед генерацией ответа. Если вам нужен более строгий контроль качества retrieval-шага, посмотрите Corrective RAG (CRAG).
- Смысловой поиск по документации. Пользователь задаёт вопрос своими словами, а система ищет близкие по embedding-векторам разделы, даже если формулировка в документе отличается.
- Hybrid search в базе знаний или каталоге. По документации Weaviate, vector search можно сочетать с keyword-поиском, фильтрами и reranking. Это полезно, когда важны и смысловая близость, и точные ограничения по метаданным.
- Пайплайны агентов. Для агента векторная БД часто выступает внешней памятью retrieval-слоя: модель не «помнит» документ внутри весов, а достаёт нужные фрагменты по запросу.
Практический пример
Сценарий: RAG по внутренней документации
- Разбейте документы на фрагменты.
- Для каждого фрагмента создайте embedding.
- Сохраните в vector database сам фрагмент, его вектор и метаданные: например, источник, раздел, дату обновления.
- Когда пользователь задаёт вопрос, создайте embedding уже для этого вопроса.
- Запустите vector similarity search. Если нужно, добавьте фильтр по типу документа или используйте hybrid search.
- Отберите несколько лучших результатов и при необходимости примените reranking.
- Передайте найденные фрагменты в LLM как контекст для ответа.
Такой поток подтверждается проверенным пакетом источников: в документации Weaviate описаны vector search, hybrid search, фильтры, RAG и reranking, а текущий Pinecone quickstart показывает упрощённый путь с integrated embedding model, загрузкой records или documents через upsert и проверкой результата поисковым запросом.
Если вам важно понять, откуда вообще берутся хорошие текстовые представления, полезно отдельно разобрать self-attention. Но сама векторная БД не обучает модель и не отвечает за качество генерации; например, параметр temperature относится к генерации ответа, а не к поиску ближайших векторов.
Чем отличается от…
| Термин | Что это | Ключевое отличие |
|---|---|---|
| Векторная БД | Система для хранения и поиска по векторам | Работает вокруг embeddings, индексов ANN, similarity search и часто дополняется фильтрами или hybrid search |
| pgvector | Расширение PostgreSQL для vector similarity search | Это не отдельная БД, а PostgreSQL-extension; удобно, если ваша архитектура уже опирается на Postgres |
| Полнотекстовый поиск | Поиск по словам и их совпадениям | Ищет по текстовым признакам, а не по близости векторов; в ряде систем его можно комбинировать с vector search через hybrid search |
| Векторный индекс | Внутренний механизм поиска | Индекс — это часть решения, например ANN/HNSW; vector database — более широкий слой хранения, индексации и выдачи результатов |
Ограничения и заблуждения
- Заблуждение: «векторная БД сама всё понимает». На самом деле качество выдачи сильно зависит от embedding-модели и от того, как вы подготовили данные.
- Заблуждение: «это то же самое, что память модели». Нет. Это внешний retrieval-слой. Он не заменяет контекстное окно модели, не равен её весам и не связан напрямую с VRAM.
- Заблуждение: «найденный результат всегда самый точный». Многие индексы используют approximate nearest neighbor-поиск. Он очень полезен практически, но это приближённый, а не абсолютно полный перебор.
- Ограничение терминологии. pgvector иногда относят не к «полноценным vector databases», а к vector search extensions для PostgreSQL. Это не ошибка, а различие в классификации.
- Ограничение выбора по цене и регионам. Для managed-сервисов условия часто меняются. В проверенном пакете источников прямо есть оговорки, что тарифы, бесплатные лимиты, billing-модели и доступность по провайдерам или регионам нужно сверять на официальных страницах Qdrant Cloud, Weaviate Cloud и Pinecone.
- Ограничение статьи. Этот материал объясняет термин и механику, но не даёт универсального рейтинга систем: для точного сравнения вам всё равно придётся проверять документацию, тарифы и ограничения конкретного продукта.
Связанные термины и инструменты
- Corrective RAG (CRAG) — следующий уровень после базового retrieval, когда найденный контекст дополнительно проверяется или корректируется.
- Self-attention — полезный соседний термин, если вы хотите понять, как модели строят представления текста.
- Temperature (температура) — параметр генерации, который не следует путать с качеством поиска в vector database.
- VRAM (видеопамять) — не синоним внешней памяти retrieval-системы.
Системы из проверенного пакета источников
- Qdrant — документация описывает систему как решение для эффективного хранения и запроса высокоразмерных векторов; в changelog private cloud указана validated version 1.18.2 от 2026-06-25.
- Weaviate — документация описывает open-source vector database, которая хранит объекты данных и их embeddings; на GitHub releases указана версия v1.37.6 от 2026-05-27.
- Milvus — документация описывает его как column-oriented vector database system; на GitHub releases указана версия v2.6.22 от 2026-08-04.
- pgvector — open-source extension для PostgreSQL с vector similarity search; в changelog указана версия v0.8.6 от 2026-07-29.
- Pinecone — текущий quickstart использует integrated embedding model, upsert документов или записей и проверку результата через поисковые запросы.
Практический вердикт редакции: если вам нужен термин в одном предложении, то vector database — это специализированный слой хранения и поиска по embeddings для retrieval-задач. Если у вас уже есть PostgreSQL, логично посмотреть на pgvector как extension; если нужна отдельная специализированная система, стоит изучать Qdrant, Weaviate или Milvus; если важен managed quickstart, проверьте Pinecone. Но цены, лимиты и доступность регионов обязательно перепроверяйте на официальных страницах: эти условия меняются чаще, чем сама базовая механика vector search.
Источники
- What is Qdrant?
- Weaviate documentation
- Search
- Milvus Documentation
- Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs
- Releases · weaviate/weaviate
- Releases · milvus-io/milvus
- CHANGELOG.md · pgvector/pgvector
- Pinecone Docs: Quickstart
- Pricing for Cloud and Vector Database Solutions
- Cloud Pricing & Payments
- Pricing | Weaviate
- Pricing | Pinecone
Вопросы и ответы
Векторная БД и embedding — это одно и то же?
Нет. Embedding — это векторное представление объекта. Векторная БД — система, которая хранит такие векторы, индексирует их и ищет ближайшие по сходству.
Нужна ли векторная БД для RAG?
Не всегда, но очень часто. Если у вас есть retrieval-шаг с embeddings и вы хотите быстро искать похожие фрагменты, vector database обычно становится центральным компонентом такого пайплайна.
pgvector — это полноценная векторная БД?
Зависит от классификации. По источникам это extension для PostgreSQL с vector similarity search. Поэтому его часто рассматривают как векторный поиск внутри Postgres, а не как отдельную standalone-систему.
Чем vector database лучше обычного поиска по словам?
Не «лучше» всегда, а решает другую задачу. Полнотекстовый поиск ищет совпадения по словам, а vector search ищет близость векторов. На практике их нередко комбинируют через hybrid search.