Информационный поиск

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 поиск по научным статьям) и какие метрики использовать для оценки?

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

  • la-15-svd
Vector Databases

0

1

Войти