Vector Databases: Pinecone, Weaviate, pgvector, Qdrant, ChromaDB

Цели урока

• Понять зачем нужна vector database и чем ANN лучше brute-force
• Разобраться в алгоритмах HNSW и IVF - как работают, когда применять
• Сравнить pgvector, Pinecone, Qdrant, ChromaDB - выбрать для своего проекта
• Написать интеграцию с pgvector (TypeORM) и Qdrant (SDK) на TypeScript
• Реализовать metadata filtering и hybrid search

HNSW-индекс находит ближайший вектор из 100 миллионов за 3 мс. Brute-force на тех же данных - 40 секунд. Разрыв в 13 000 раз. PostgreSQL хранит числа, строки, JSON - но спросить 'что похоже на это?' за 10 мс на миллионе векторов не может. Для этого построили отдельный класс баз данных.

• Spotify использует vector search для рекомендации подкастов - 500M+ embeddings в Vespa (аналог vector DB)
• Notion AI хранит embeddings всех страниц пользователя в Pinecone - поиск по рабочему пространству за 200ms
• GitHub Copilot индексирует репозиторий через embeddings + Qdrant для контекстных подсказок на уровне всей кодовой базы
• Supabase добавил pgvector как стандартное расширение - vector search доступен каждому PostgreSQL-проекту

Как появились vector databases

**2017**: Facebook AI Research выпускает Faiss - первую open-source библиотеку для миллиардного ANN-поиска. Это библиотека, не база данных: нет персистентности, нет API, нет фильтрации. **2021**: Pinecone - первая fully managed vector DB с REST API. Привлекает `100M USD` инвестиций за год. **2022**: Qdrant (Rust, open-source) и Weaviate (Go, GraphQL) выходят на рынок как ответ на взрыв LLM-приложений после ChatGPT. **2023**: pgvector 0.5 добавляет HNSW-индекс - PostgreSQL становится полноценным вариантом для production. За 6 лет сегмент вырос с нуля до `1.5B USD` рынка.

Предварительные знания

• Embeddings: Turning Text into Vectors for Search and Comparison

Зачем нужна отдельная vector database

PostgreSQL хранит числа, строки, JSON. Умеет индексировать по полям, делать JOIN, отвечать за миллисекунды. Но спросить 'что похоже на это?' - на миллионе векторов, за 10 мс - не может. Для этого построили отдельный класс баз данных.

Причина в математике. Brute-force поиск ближайшего вектора - это O(n × d): каждый из n векторов, каждое из d измерений. Один миллион 1536-мерных векторов - **1.5 миллиарда операций** на каждый запрос.

Vector database решает задачу через **Approximate Nearest Neighbors (ANN)** - алгоритмы, которые находят не идеально ближайшие, а **достаточно близкие** векторы за O(log n) вместо O(n). Точность 95-99% при ускорении в 100-1000 раз. Для RAG-поиска 97% - лучше, чем достаточно.

Помимо скорости, vector database берёт на себя ещё несколько задач, которые иначе пришлось бы решать вручную:

• **Персистентность** - данные сохраняются на диск, не теряются при перезапуске
• **Индексация** - специальные структуры данных для быстрого ANN-поиска
• **Metadata filtering** - фильтрация результатов по полям (дата, категория, автор) вместе с vector search
• **Масштабирование** - шардирование и репликация для миллиардов векторов
• **CRUD-операции** - добавление, обновление, удаление отдельных векторов без перестройки индекса
• **Hybrid search** - комбинация vector search + keyword search (BM25)

**Аналогия:** обычная база данных - как книга с оглавлением (B-tree index). Vector database - как библиотекарь, который знает, что книга 'про космос' стоит рядом с книгой 'про ракеты', потому что понимает тематическую близость. Разные задачи - разные структуры данных. PostgreSQL никуда не уходит - vector DB работает рядом, не вместо.

ANN-алгоритмы: HNSW и IVF

HNSW-индекс находит ближайший вектор из 100 миллионов за 3 мс. Brute-force на тех же данных - 40 секунд. Разрыв в 13 000 раз. За счёт чего? Два главных алгоритма приближённого поиска дают ответ.

HNSW (Hierarchical Navigable Small World)

HNSW строит многослойный граф связей между векторами. Верхний слой - грубая карта (мало узлов, длинные прыжки). Нижний - детальная (все узлы, короткие связи). Поиск начинается сверху и спускается вниз, каждый раз приближаясь к цели - как навигатор, который сначала видит страну, потом город, потом улицу.

IVF (Inverted File Index)

IVF делит пространство на **кластеры** (ячейки Вороного). При поиске сначала определяется, к каким кластерам ближе query, а затем перебираются только векторы в этих кластерах. Вместо 1 000 000 - только 10 000 сравнений. Цена - нужно периодически перестраивать кластеры при добавлении данных.

**Правило выбора:** для большинства backend-задач (до 10M векторов) - HNSW. Проще в настройке, не требует перестройки при добавлении данных, высокая точность из коробки. IVF выгоден при экономии памяти и объёмах 100M+ векторов.

Сравнение vector databases: pgvector, Pinecone, Qdrant, ChromaDB

2017 - Facebook AI выпускает Faiss: первая open-source библиотека для миллиардного ANN-поиска. 2021 - Pinecone: первая fully managed vector DB. 2022 - Qdrant и Weaviate: ответ на взрыв LLM-приложений после ChatGPT. За 5 лет рынок заполнился решениями на любой вкус и бюджет.

pgvector - если уже есть PostgreSQL

Главное преимущество pgvector - **нулевые инфраструктурные изменения**. Расширение устанавливается в существующую PostgreSQL, векторы хранятся рядом с остальными данными. JOIN-ы, транзакции, ACID - всё работает. Supabase сделал pgvector стандартным расширением - миллионы PostgreSQL-проектов получили vector search одной командой.

Pinecone - managed без DevOps

Pinecone - fully managed vector database. Нет серверов, нет настройки индексов, нет масштабирования вручную. Платишь за хранение и запросы. Notion AI хранит embeddings всех страниц пользователя в Pinecone - поиск по рабочему пространству за 200ms. Идеально для стартапов без DevOps-команды.

Qdrant - производительность и гибкость

Qdrant написан на Rust - показывает лучшую производительность среди open-source решений. Поддерживает rich filtering, payload indexing, multi-vector search. GitHub Copilot использует Qdrant для индексации репозиториев - контекстные подсказки на основе всего кодовой базы. Запускается как Docker-контейнер или Qdrant Cloud.

Практика: pgvector + TypeORM и Qdrant SDK

Два наиболее практичных решения для NestJS-бекенда: pgvector через TypeORM - расширение к существующей базе, и Qdrant через official SDK - выделенный vector store. Оба в 10-20 строк кода на запрос.

pgvector + TypeORM

Qdrant SDK

**Docker для локальной разработки:** Qdrant запускается одной командой: `docker run -p 6333:6333 qdrant/qdrant`. Для pgvector - добавить расширение в существующий PostgreSQL: `CREATE EXTENSION vector;` (доступно в официальном Docker-образе `pgvector/pgvector:pg16`).

Metadata filtering и Hybrid Search

Чистый vector search возвращает семантически близкие результаты - но игнорирует **структурированные ограничения**: 'только документы за последний месяц', 'только из категории billing', 'только на английском'. **Metadata filtering** соединяет vector search с обычными фильтрами - без потери скорости ANN.

Hybrid Search: vector + keyword

Hybrid search комбинирует **семантический поиск** (embeddings) с **лексическим поиском** (BM25/full-text). Vector search находит 'по смыслу' - keyword search ловит точные термины, аббревиатуры, коды ошибок. Perplexity.ai строит поиск именно на этой комбинации: семантика + точное совпадение ключевых слов.

Поддержка hybrid search в разных vector databases:

**Когда hybrid search критичен:** поиск по технической документации (точные API-имена, коды ошибок), юридические тексты (номера статей, даты), медицинские данные (названия препаратов, коды МКБ). Везде, где точные идентификаторы соседствуют со свободным текстом.

Vector database заменяет PostgreSQL - переносим все данные туда

Vector DB дополняет реляционную базу, а не заменяет. Metadata, пользователи, бизнес-данные живут в PostgreSQL; embeddings - в vector DB

Vector database оптимизирована для одного: ANN-поиска по плотным векторам. Транзакции, сложные JOIN-ы, агрегации, foreign keys - всё это остаётся в PostgreSQL. Типичная архитектура: документ с metadata в PostgreSQL + его embedding в Qdrant, связанные по id. При pgvector оба слоя - в одной базе.

Ключевые выводы

• HNSW из 100M векторов - 3 мс. Brute-force - 40 секунд. 13 000x - не магия, а правильные структуры данных
• ANN (approximate nearest neighbor) - 95-99% точность при 100-1000x ускорении: достаточно для RAG
• pgvector - лучший выбор при существующем PostgreSQL (до 5-10M векторов, нативные JOIN-ы, ACID)
• Qdrant - лучший open-source для выделенного vector store (Rust, высокая производительность)
• Pinecone - managed решение без DevOps (70/мес+), платишь за хранение и запросы
• Hybrid search (vector + keyword/BM25) критичен для данных с точными идентификаторами
• Vector DB дополняет PostgreSQL, не заменяет - metadata и бизнес-данные остаются в реляционной БД

Вопросы для размышления

• PostgreSQL не умеет спросить 'что похоже на это?' за 10 мс на миллионе векторов. Почему именно эта операция требует отдельного класса баз данных?
• HNSW vs IVF: когда жертва точностью ради памяти оправдана? При каком объёме данных и каком use case?
• Hybrid search объединяет semantic + keyword поиск. Для какого типа данных в реальном проекте это было бы критично?

Что дальше

Vector database готова принимать embeddings и отвечать на запросы. Но откуда берутся тексты для embeddings? Реальные данные - это PDF-отчёты, DOCX-контракты, HTML-страницы. Их нужно распарсить, почистить и подготовить.

• Document Processing — Извлечение текста из PDF, DOCX, HTML перед генерацией embeddings
• RAG Fundamentals — Собираем всё вместе: embeddings + vector DB + LLM = RAG pipeline

Связанные уроки

• aie-09-embeddings — Векторная БД хранит эмбеддинги, которые вы генерируете
• aie-12-rag-fundamentals — Векторный поиск это шаг retrieval в RAG
• db-30-vector — pgvector добавляет векторное индексирование в реляционную БД
• alg-10-binary-search — ANN-индексы меняют точность на сублинейный поиск
• ds-09-trees-intro — HNSW это навигируемый графовый индекс по векторам
• db-09-indexes-btree