Векторные базы данных: как работает поиск по смыслу

Обычная база данных находит записи по точному совпадению: ID равен 42, имя содержит «Иванов», дата больше 1 января. Векторная база данных находит записи по смыслу: «документы, похожие на этот запрос», «изображения, визуально близкие к загруженному». Это фундаментальная инфраструктура для RAG-систем, рекомендаций, семантического поиска и работы с неструктурированными данными.

Эмбеддинги: текст как точка в пространстве

Чтобы искать «по смыслу», нужно превратить смысл в числа. Модели эмбеддингов (embedding models) преобразуют текст, изображения или аудио в числовые векторы фиксированной длины — обычно от 384 до 3072 измерений.

Ключевое свойство: семантически близкие тексты получают близкие векторы. «Как добраться до аэропорта?» и «Маршрут в аэропорт» будут рядом в векторном пространстве, хотя не имеют общих значимых слов.

Расстояние между векторами измеряется через:

• Косинусное сходство — наиболее популярная метрика. Измеряет угол между векторами, игнорируя длину. Значение 1 — идентичны, 0 — не связаны, -1 — противоположны.
• Евклидово расстояние (L2) — прямая линия между точками в пространстве. Чувствительно к масштабу.
• Скалярное произведение — когда длина вектора несёт информацию (например, о «важности» документа).

Проблема поиска в высоком измерении

Точный поиск ближайшего соседа (exact nearest neighbor) в пространстве 1536 измерений среди миллионов векторов — вычислительно дорогая операция. Сравнение запроса с каждым вектором в базе занимает O(n) — линейно растёт с размером базы. Для миллиарда векторов это секунды, а не миллисекунды.

Поэтому векторные базы используют приближённый поиск (Approximate Nearest Neighbor, ANN). Идея: построить индекс, который отсекает 99% векторов, не являющихся ближайшими, и проверяет только оставшийся 1%. Точность — 95–99%, скорость — в тысячи раз выше.

Алгоритмы индексации

HNSW (Hierarchical Navigable Small World)

Самый популярный алгоритм для векторного поиска. Строит многоуровневый граф, где каждый уровень — сеть с разной плотностью связей. Верхние уровни — крупные «прыжки» для быстрой навигации. Нижние — мелкие шаги для точного поиска.

Поиск начинается на верхнем уровне и «спускается» к нижнему, на каждом уровне переходя к ближайшему соседу. Это похоже на поиск слова в словаре: сначала открываете примерно нужную страницу, затем уточняете.

Преимущества: высокая точность (recall 95–99%), быстрый поиск (миллисекунды на миллионах векторов). Недостаток: индекс занимает много памяти — весь граф должен быть в RAM.

IVF (Inverted File Index)

Разделяет векторное пространство на кластеры (обычно через k-means). При поиске запрос сравнивается с центрами кластеров, выбираются ближайшие кластеры, и поиск идёт только внутри них.

Менее точен, чем HNSW, но более экономичен по памяти. Подходит для больших наборов данных с ограниченной RAM.

PQ (Product Quantization)

Сжимает векторы для хранения на диске. Вектор из 1536 float32 (6 КБ) сжимается до 48–192 байт. Комбинируется с IVF или HNSW для баланса скорости, точности и потребления памяти.

Сравнение баз данных

Pinecone

Полностью управляемый облачный сервис. Не нужно администрировать инфраструктуру — загрузил векторы, получил API для поиска.

• Масштабируется до миллиардов векторов
• Поддерживает фильтрацию по метаданным
• Serverless-тариф с оплатой за запросы
• Минус: закрытый код, vendor lock-in, данные на серверах Pinecone

Weaviate

Open-source база данных с гибридным поиском — векторный (ANN) и полнотекстовый (BM25) в одном запросе. Встроенные модели для автоматической генерации эмбеддингов — можно загружать текст напрямую, без предварительной векторизации.

import weaviate

client = weaviate.connect_to_local()

# Поиск похожих документов
result = client.collections.get("Article").query.near_text(
    query="производительность языковых моделей",
    limit=5
)

Qdrant

Open-source, написан на Rust. Выделяется производительностью и эффективным использованием памяти. Поддерживает фильтрацию по payload (метаданным) одновременно с векторным поиском — без потери скорости.

• HNSW-индексы с сегментацией для эффективного обновления
• Квантизация векторов для экономии памяти
• Мультивекторный поиск (несколько векторов на одну точку)
• gRPC API для высоконагруженных сценариев

pgvector

Расширение для PostgreSQL. Не отдельная база данных, а новый тип данных в существующем PostgreSQL.

-- Создание таблицы с вектором
CREATE TABLE documents (
    id SERIAL PRIMARY KEY,
    content TEXT,
    embedding vector(1536)
);

-- Поиск ближайших
SELECT content
FROM documents
ORDER BY embedding <=> '[0.1, 0.2, ...]'
LIMIT 5;

Преимущество: если вы уже используете PostgreSQL, не нужна отдельная инфраструктура. Транзакции, бэкапы, масштабирование — всё стандартное для PostgreSQL. Недостаток: медленнее специализированных решений на больших объёмах (миллионы+ векторов).

Chroma

Встраиваемая база данных для прототипов и небольших проектов. Работает как Python-библиотека — без серверного процесса.

import chromadb

client = chromadb.Client()
collection = client.create_collection("docs")

# Добавление документов (эмбеддинги генерируются автоматически)
collection.add(
    documents=["Текст первого документа", "Текст второго"],
    ids=["doc1", "doc2"]
)

# Поиск
results = collection.query(query_texts=["мой запрос"], n_results=3)

Идеальна для разработки и тестирования RAG-пайплайнов. Для продакшена с большими объёмами — переходите на Qdrant, Weaviate или Pinecone.

Какую базу выбрать

Прототип, до 100 000 документов: Chroma. Минимальная настройка, работает из коробки.

Уже используете PostgreSQL: pgvector. Меньше инфраструктуры, проще ops.

Продакшен, нужна производительность: Qdrant или Weaviate. Оба open-source, оба зрелые.

Максимальный масштаб без ops: Pinecone. Платите деньгами, экономите время инженеров.

Ключевой совет: для RAG качество эмбеддингов важнее выбора базы данных. Разница между Qdrant и Pinecone — проценты производительности. Разница между хорошей и плохой моделью эмбеддингов — качество результатов поиска.

Векторные базы данных: зачем они нужны в эпоху LLM

Взрывной рост RAG-систем (Retrieval-Augmented Generation) сделал векторные базы данных одним из ключевых компонентов ИИ-стека. Задача: хранить эмбеддинги (числовые представления смысла) и быстро находить семантически похожие документы по запросу. Без векторной БД RAG невозможен.

Сравнение векторных баз данных 2025

Алгоритмы поиска: HNSW vs IVF vs Flat

Flat (точный поиск) — перебирает все векторы, 100% recall. Подходит для <100K векторов. При большем объёме становится медленным.

IVF (Inverted File Index) — кластеризует векторы, ищет в ближайших кластерах. Быстрее Flat, небольшая потеря recall. Хорош для 100K–10M векторов.

HNSW (Hierarchical Navigable Small World) — граф близости, поиск за O(log n). Лучший баланс скорости и качества. Стандарт для production при любом объёме.

Когда достаточно pgvector

Если у вас уже есть PostgreSQL и объём данных <1M документов — pgvector часто достаточен. Преимущества: единая инфраструктура, ACID-транзакции, знакомый SQL, JOINS с реляционными данными. Недостатки: при HNSW индексе возможен приблизительный recall, нет встроенного hybrid search. Для стартапов и внутренних инструментов pgvector — первый выбор. Миграция на выделенную векторную БД при росте — тривиальна.

Выбор для production RAG

Быстрый старт, managed → Pinecone (serverless, от $0)
Self-hosted, production-ready → Qdrant (Rust, быстрый, Docker)
Hybrid search критичен → Weaviate (BM25 + вектор out of the box)
Уже на PostgreSQL → pgvector (до 1M документов)
Enterprise масштаб → Milvus / Zilliz Cloud

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

• RAG: как подключить документы к языковой модели
• Как встроить ИИ-поиск с эмбеддингами
• LangChain vs LlamaIndex: фреймворки для RAG