# Векторные базы данных и их типы

> Векторные БД: managed vs self-hosted, метаданные и фильтры, когда хватит pgvector — выбор хранилища на AI-собеседовании.

Раздел: [RAG: поиск + генерация](https://ml-book.com/s/rag/) · Страница темы: https://ml-book.com/t/vector-databases/ · Обновлено: 2026-09-16 · Источник: ml-book.com, учебник делается сообществом

## Интуиция

Представь три разных вопроса к системе. «Дай пользователя с email = ivan@mail.ru» — это точное совпадение по значению. «Дай заказ по его id = 8842» — это выборка по ключу. А «найди документы, похожие по *смыслу* на этот абзац» — это уже поиск по геометрической близости в многомерном пространстве. Первые два вопроса идеально решает обычная СУБД. Третий она не умеет: у неё нет понятия «похоже по смыслу», только «равно/больше/меньше» и совпадение подстрок.

Векторная база данных (vector database) — это хранилище, специализированное под третий вопрос. Она хранит не строки таблиц, а [эмбеддинги](https://ml-book.com/t/embeddings/) — числовые векторы размерности 384–3072 — вместе с прикреплёнными к ним данными, и умеет за миллисекунды находить ближайших соседей среди миллионов таких векторов через [ANN-индекс](https://ml-book.com/t/vector-search/).

## Что именно хранит векторная БД

Одна запись в векторной БД — это тройка:

- **Вектор (embedding)** — то, по чему ищут. Массив чисел, полученный из модели эмбеддингов.
- **Метаданные (payload / metadata)** — структурированные поля: автор, дата, отдел, язык, тип документа. По ним фильтруют выдачу.
- **Полезная нагрузка** — сам исходный текст чанка или ссылка на него. Именно её отдают LLM в промпт после поиска.

Обычная реляционная база тоже умеет хранить массив чисел в колонке. Но она не умеет по нему *эффективно* искать близость: чтобы найти ближайшие векторы, ей пришлось бы посчитать расстояние до каждой строки — полный перебор O(N × d) на запрос. Векторная БД строит специальный индекс (HNSW-граф, IVF-ячейки), который превращает этот перебор в навигацию по структуре и даёт ответ на порядки быстрее.

> **💡 Ключевая мысль**
>
> Три парадигмы БД отвечают на три разных вопроса: реляционная — «что *равно* значению» (точный поиск, JOIN, транзакции), ключ-значение — «что лежит по *ключу*», векторная — «что *похоже по смыслу*». Выбор базы = выбор вопроса, на который она отвечает хорошо.

> 🎛 Интерактивная визуализация — на странице темы: https://ml-book.com/t/vector-databases/

## Три парадигмы хранения

Чтобы выбрать базу, полезно держать в голове их сильные стороны:

- **Реляционная (SQL: PostgreSQL, MySQL)** — данные в таблицах «строки × столбцы». Сильна в точных запросах по значению, соединениях таблиц (JOIN) и транзакциях с гарантиями ACID. Ищет «равно / больше / меньше», а не «похоже по смыслу».
- **Документная / ключ-значение (NoSQL: MongoDB, Redis, DynamoDB)** — хранит документы или пары «ключ → значение», легко масштабируется горизонтально. Идеальна для выборки по ключу и гибких схем, но плохо ищет по произвольным полям без индекса.
- **Векторная** — хранит эмбеддинги и ищет по семантической близости через ANN-индекс. Это единственная из трёх, кто отвечает на «найди похожее по смыслу».

## Типы решений на рынке

«Векторная БД» — это не один продукт, а три уровня зрелости инфраструктуры:

- **Специализированные БД** (Pinecone, Qdrant, Weaviate, Milvus) — отдельный сервис только под векторы: масштабирование, репликация, фильтр-осведомлённый поиск, обновления «на живую». Нужны, когда векторов миллионы и требования к нагрузке серьёзные.
- **Расширения к существующим БД** (pgvector для PostgreSQL, векторный поиск в Redis, Elasticsearch, OpenSearch) — добавляют вектор-колонку и ANN-индекс в базу, которая у вас уже есть. Одна система, привычные бэкапы и транзакции — обычно лучший старт.
- **Библиотеки-индексы без сервера** (FAISS, hnswlib) — вы держите индекс сами, в памяти процесса. Максимум контроля и скорости, но персистентность, репликация и фильтры — целиком ваша забота.

Индексы внутри почти одинаковы у всех: точный **Flat** (100% recall, медленно), **IVF** (кластеры), **HNSW** (граф, дефолт), **PQ** (сжатие памяти). Их механику разбирает тема [векторный поиск](https://ml-book.com/t/vector-search/); здесь важно лишь, что тип индекса — это ручка компромисса recall / скорость / память / время постройки.

## Фильтрация и когда БД не нужна

Реальные запросы почти всегда с фильтром: «похожие документы, но только за 2024 год и только отдела продаж». Тут возникает конфликт с ANN. **Пост-фильтрация (post-filtering)** — сначала найти топ-k по близости, потом отсеять по метаданным — рискует оставить два результата из десяти, если фильтр строгий. **Пре-фильтрация (pre-filtering)** — сначала сузить по метаданным, потом искать близость — точнее, но дороже для строгого индекса. Зрелые движки делают фильтрацию *внутри* обхода индекса, добирая кандидатов.

> **⚠️ Подводный камень**
>
> Не поднимай выделенную векторную БД ради 5000 чанков. На тысячах–десятках тысяч документов честный перебор в numpy или FAISS в памяти отвечает за миллисекунды, а операционная сложность отдельного сервиса реальна уже сегодня. Специализированная БД оправдана масштабом и требованиями к нагрузке, а не модой.

> **🎤 На собеседовании**
>
> - «Чем векторная БД отличается от реляционной?» — реляционная ищет точное совпадение по значению (равно/больше) и делает JOIN с ACID; векторная ищет семантическую близость через ANN-индекс. Разные вопросы — разные структуры данных.
> - «Нужна ли отдельная векторная БД или хватит pgvector?» — если Postgres уже в стеке и векторов до ~1 млн, pgvector проще в эксплуатации: одна база, транзакции, бэкапы. Выделенный сервис — когда масштаб и нагрузка этого требуют.
> - «Pre-filtering или post-filtering?» — пост-фильтр может выбить почти все результаты при строгом условии; пре-фильтр точнее, но дороже. В идеале — фильтрация внутри обхода индекса (filter-aware search).
> - «Когда векторная БД вообще не нужна?» — на тысячах документов: numpy/FAISS в памяти, без отдельного сервиса.

## Связанные темы

- [Векторный поиск и ANN-индексы](https://ml-book.com/t/vector-search/)
- [Что такое RAG и зачем он нужен](https://ml-book.com/t/rag-basics/)
- [Чанкинг и подготовка данных](https://ml-book.com/t/chunking/)
- [Эмбеддинг-модели: как их обучают](https://ml-book.com/t/embedding-models/)

---

Интерактив, тест из 12 вопросов и карточки терминов — на странице темы: https://ml-book.com/t/vector-databases/
Весь учебник в markdown: https://ml-book.com/llms-full.txt · Оглавление для агентов: https://ml-book.com/llms.txt