COMRAD404 / GLOSSARY

Vector Database (векторная БД)

Vector Database

Vector database, или векторная БД, — система для хранения и поиска высокоразмерных векторов. В статье — простое объяснение, схема работы, применение в RAG и отличия от pgvector и полнотекстового поиска.

TL;DR

Векторная БД — это система, которая хранит embeddings и быстро находит ближайшие по сходству векторы, часто вместе с объектами и метаданными.

Vector database, или векторная база данных, — это система для хранения и быстрого поиска высокоразмерных векторов. На практике она нужна, когда вы превращаете текст, изображения или другие объекты в embedding-векторы и хотите находить самые похожие элементы без полного перебора.

Английский термин: vector database. Также встречается: векторная база данных, векторная БД. Не путайте её с самим embedding: embedding — это векторное представление объекта, а vector database — система, которая эти векторы хранит, индексирует и возвращает по запросу.

Простыми словами

Грубо говоря, векторную БД можно представить как картотеку, где записи ищутся не по точному слову, а по близости «координат смысла». Если два текста после преобразования в векторы оказываются рядом, система считает их похожими и может вернуть один по запросу к другому.

Поэтому векторная БД особенно полезна там, где пользователь формулирует вопрос своими словами, а нужный ответ лежит в документе с другой формулировкой. Для RAG это типичный сценарий: сначала находите релевантные фрагменты, потом уже передаёте их модели.

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

Официальные документы Qdrant, Weaviate и Milvus сходятся в главном: речь идёт о хранении и поиске по векторам, а не просто о ещё одной таблице с числами. Weaviate отдельно подчёркивает, что может хранить объекты данных и их vector embeddings, а его поиск включает vector similarity search, hybrid search, фильтры, RAG и reranking.

  1. Вы берёте объект: абзац документа, карточку товара, вопрос-ответ или изображение.
  2. Модель преобразует этот объект в embedding-вектор.
  3. Вектор и связанные данные сохраняются в системе. В Weaviate это описано как хранение объектов и их embeddings.
  4. Для быстрого поиска строится индекс. Во многих системах используются approximate nearest neighbor-подходы; один из самых известных — графовый HNSW из одноимённой статьи.
  5. Когда приходит новый запрос, он тоже превращается в вектор.
  6. База ищет ближайшие векторы, а затем может применить фильтры, hybrid search и reranking, если это поддерживается выбранной системой.
  7. Полученные фрагменты уходят в приложение, поиск или 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 по внутренней документации

  1. Разбейте документы на фрагменты.
  2. Для каждого фрагмента создайте embedding.
  3. Сохраните в vector database сам фрагмент, его вектор и метаданные: например, источник, раздел, дату обновления.
  4. Когда пользователь задаёт вопрос, создайте embedding уже для этого вопроса.
  5. Запустите vector similarity search. Если нужно, добавьте фильтр по типу документа или используйте hybrid search.
  6. Отберите несколько лучших результатов и при необходимости примените reranking.
  7. Передайте найденные фрагменты в 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.

Источники

Вопросы и ответы

Векторная БД и embedding — это одно и то же?

Нет. Embedding — это векторное представление объекта. Векторная БД — система, которая хранит такие векторы, индексирует их и ищет ближайшие по сходству.

Нужна ли векторная БД для RAG?

Не всегда, но очень часто. Если у вас есть retrieval-шаг с embeddings и вы хотите быстро искать похожие фрагменты, vector database обычно становится центральным компонентом такого пайплайна.

pgvector — это полноценная векторная БД?

Зависит от классификации. По источникам это extension для PostgreSQL с vector similarity search. Поэтому его часто рассматривают как векторный поиск внутри Postgres, а не как отдельную standalone-систему.

Чем vector database лучше обычного поиска по словам?

Не «лучше» всегда, а решает другую задачу. Полнотекстовый поиск ищет совпадения по словам, а vector search ищет близость векторов. На практике их нередко комбинируют через hybrid search.

Источники

SOURCES

Вопросы и ответы

FAQ
Векторная БД и embedding — это одно и то же?

Нет. Embedding — это векторное представление объекта. Векторная БД — система, которая хранит такие векторы, индексирует их и ищет ближайшие по сходству.

Нужна ли векторная БД для RAG?

Не всегда, но очень часто. Если у вас есть retrieval-шаг с embeddings и вы хотите быстро искать похожие фрагменты, vector database обычно становится центральным компонентом такого пайплайна.

pgvector — это полноценная векторная БД?

Зависит от классификации. По источникам это extension для PostgreSQL с vector similarity search. Поэтому его часто рассматривают как векторный поиск внутри Postgres, а не как отдельную standalone-систему.

Чем vector database лучше обычного поиска по словам?

Не «лучше» всегда, а решает другую задачу. Полнотекстовый поиск ищет совпадения по словам, а vector search ищет близость векторов. На практике их нередко комбинируют через hybrid search.

Читайте также

LINKS