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

Векторный поиск — это механика, а векторная база данных — инфраструктура вокруг неё: где лежат эмбеддинги, метаданные и исходный текст, как это масштабируется и почему обычная SQL-база тут не помощник. На собеседовании по AI-инфраструктуре важно уметь выбрать правильный тип хранилища под задачу, а не тащить Pinecone в каждый проект.

Интуиция

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

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

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

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

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

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

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

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

• Реляционная (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 (сжатие памяти). Их механику разбирает тема векторный поиск; здесь важно лишь, что тип индекса — это ручка компромисса recall / скорость / память / время постройки.

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

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