Как думать про distributed vector search
Команда говорит, что переходит от single-node vector search к distributed vector retrieval system. Какие вопросы и trade-off стоит обсудить?
Короткий ответ
Нужно обсудить объем индекса, latency SLA, recall, sharding, replication, routing, обновления индекса, hardware profile и компромисс между точностью ANN и скоростью.
Полный разбор
Переход к distributed vector search обычно нужен, когда single-node индекс перестает помещаться по памяти, не выдерживает QPS или не дает нужный latency. Начать стоит с требований: размер корпуса, размер embedding, QPS, p95/p99 latency, freshness, recall target и стоимость.
Архитектурно нужно решить sharding и replication. Sharding уменьшает нагрузку на узел, но усложняет global top-k merge. Replication помогает читать быстрее и повышает reliability, но дороже по памяти. Routing может быть простым fan-out по шардам или более умным через partitioning/cluster assignment.
Отдельный блок — ANN index: HNSW, IVF/PQ, ScaNN/FAISS-подходы, quantization, CPU/GPU, batch search. Для production важны online updates, rebuild strategy, consistency, monitoring recall/latency и деградация при росте каталога.
Теория
Vector search в RecSys, ads и search — это candidate generation. Главный компромисс: recall и freshness против latency, памяти и стоимости.
Типичные ошибки
- Сразу выбирать конкретную библиотеку без требований.
- Не обсудить global top-k после sharding.
- Забыть про обновления индекса и monitoring recall.
Как отвечать на собеседовании
- Начни с требований: corpus size, QPS, latency, recall, freshness.
- Потом разложи sharding, replication, ANN index и merge top-k.