Информационный поиск
Vector Databases
ChatGPT с RAG, Spotify рекомендации, Pinterest visual search, Notion AI semantic search - все работают через vector databases. Без них LLM не 'помнит' пользовательские документы, рекомендательная система не находит похожие треки. Это инфраструктура семантического интернета: Google хранит эмбеддинги для триллионов веб-страниц, Meta - для 2 миллиардов фотографий. Vector DB - новый тип базы данных на котором строится AI-era.
- **Notion AI** - semantic search по всем заметкам пользователя; Pinecone для embeddings; при вопросе 'где я записал про встречу в апреле?' находит релевантные заметки через cosine similarity
- **Spotify 'Fans Also Like'** - embeddings для 100M треков; Annoy (FAISS-like) для ANN; 'artists similar to X' через song embedding proximity
- **Shopify AI Search** - hybrid search (BM25 + dense embeddings); запрос 'синяя джинсовая куртка для зимы' находит по цвету (dense) и точным словам (sparse)
FAISS: Facebook AI Similarity Search
Meta хранит embeddings для 2 миллиардов фотографий (поиск дублей, рекомендации). Brute-force поиск ближайших соседей: O(N*d) = 2B * 512 float = невозможно за разумное время. FAISS (2019, Meta) - библиотека ANN (Approximate Nearest Neighbor) которую используют Meta, LinkedIn, Airbnb, Pinterest.
**FAISS** - C++ библиотека с Python биндингами. Три ключевых индекса: **IndexFlatL2** (точный brute-force, baseline), **IndexIVFFlat** (inverted file index, случайные centroid'ы разбивают пространство), **IndexIVFPQ** (+ Product Quantization: сжатие векторов в коды, 8-64 bytes vs 2048 bytes для float512). GPU-версия: FAISS-GPU ускоряет в 10-100x.
Что такое nprobe в FAISS IVF индексе и как его значение влияет на качество поиска?
Milvus: Production Vector Database
FAISS - библиотека, не база данных. Нет persistence, нет REST API, нет горизонтального масштабирования. **Milvus** (open-source, 2019) - production-ready vector database: Kubernetes-native, sharding, replication, filtering по metadata, REST и gRPC API. Используется в Walmart, eBay, Roblox.
Milvus архитектура: **Storage** (MinIO/S3 для segments), **Coordinator** (metadata), **Query Node** (поиск), **Data Node** (ingestion). Поддерживает: HNSW, IVF_FLAT, IVF_PQ, RNSG индексы. **Hybrid search**: ANN + scalar filtering (WHERE category='news' AND date > '2024-01-01').
Почему production системы используют Milvus вместо FAISS напрямую?
Pinecone: Managed Vector Database
Стартап строит RAG-систему и не хочет управлять Kubernetes кластером для Milvus. **Pinecone** - managed cloud vector database (SaaS): нет инфраструктуры, REST API, автоматическое масштабирование. Используется в Notion AI, Shopify, Gong.
Pinecone: **serverless** (pay per query, автоскейл) и **pod-based** (фиксированные ресурсы, предсказуемая latency). Поддерживает: namespace (партиционирование данных), metadata filtering, sparse-dense hybrid search (BM25 + embeddings). Ограничения: vendor lock-in, дороже self-hosted при масштабе.
Что такое sparse-dense hybrid search в Pinecone?
HNSW vs IVF: алгоритмы ANN
За всеми vector databases стоят два основных алгоритма ANN: **HNSW** (Hierarchical Navigable Small World) и **IVF** (Inverted File Index). Выбор алгоритма определяет latency, recall, память и скорость добавления векторов.
**HNSW** (2016, Malkov & Yashunin): граф навигации с несколькими слоями. Поиск начинается с верхнего (разреженного) слоя и спускается к нижнему (плотному). Recall@10 = 98-99% при разумной latency. Медленный build O(N*log(N)), быстрый поиск. **IVF**: Voronoi клетки через k-means + инвертированный файл. Быстрый build, настраиваемый trade-off через nprobe.
Vector database заменяет обычную реляционную БД для хранения данных с embeddings
Vector database хранит только embeddings и metadata для поиска. Основные данные (полные тексты, изображения, пользователи) хранятся в PostgreSQL/S3/Elasticsearch. Vector DB - специализированный индекс поверх основного хранилища.
Попытка хранить всё в Pinecone/Milvus: нет транзакций, нет JOIN, нет complex queries, нет backup/restore как в PostgreSQL. Типичная архитектура RAG: PostgreSQL (chunk texts) + Milvus (embeddings) + Redis (кеш). ID из Milvus используется для lookup полного текста в PostgreSQL.
Поисковая система требует recall@10 = 99% и latency p99 < 10ms при 1B векторов. Какой алгоритм и почему?
Ключевые идеи
- **FAISS** - Meta open-source библиотека; IVF+PQ: 32x сжатие, recall 85-92%; IndexFlatL2 точный baseline; GPU версия 10-100x быстрее
- **Milvus** - open-source production DB; Kubernetes-native, sharding, replication, hybrid search; self-hosted, бесплатно при масштабе
- **Pinecone** - managed SaaS; serverless автоскейл; vendor lock-in; sparse-dense hybrid search; лучше для стартапов без DevOps
- **HNSW vs IVF**: HNSW = recall@10 99%, медленный build; IVF+PQ = recall 85-92%, быстрый build, в 30x меньше памяти
Связанные темы
Vector databases - инфраструктура для semantic search и RAG:
- Query Understanding — Query expansion и intent detection улучшают качество query vector для ANN поиска
- Vision-Language Models — CLIP embeddings из VLM - стандартный вектор для visual search в FAISS/Milvus
Вопросы для размышления
- Notion AI хранит embeddings всех заметок пользователя. Пользователь удалил заметку. Как гарантировать что вектор удалён из Milvus и не появляется в поисковой выдаче - какие архитектурные паттерны используются?
- HNSW строит граф навигации. Добавление нового вектора требует пересчёта связей - это медленно при высоком ingestion rate (10,000 векторов/сек). Как Milvus решает эту проблему через streaming + batch segment merge?
- Hybrid search: 70% dense + 30% sparse. Как выбрать оптимальный alpha для конкретной задачи (e-commerce поиск товаров vs поиск по научным статьям) и какие метрики использовать для оценки?