Vector index — векторный индекс для семантического поиска и RAG (как выбрать и настроить)

Базовая идея Vector index (векторного индекса)

1) Текст → эмбеддинг x ∈ ℝᵈ. 2) Индекс хранит эмбеддинги документов {v_i} с метаданными. 3) Запрос кодируется в вектор q, после чего индекс возвращает k ближайших v_i по метрике близости. 4) (Опционально) переранжирование кросс-энкодером и пост-обработка (MMR, дедуп, правила).

Метрики близости

• Cosine similarity: cos(q,v)=⟨q,v⟩/(||q||·||v||) — инвариант к масштабу.
• L2 (евклид): хорошо для нормированных векторов.
• Inner Product (IP/MIPS): максимизация скалярного произведения. Трюк: для MIPS нормируйте/расширяйте вектора (добавочный компонент), чтобы свести к L2.

Типы векторных индексов (короткий обзор)

На практике применяют гибриды: HNSW для «горячего» RAM-слоя, IVF-PQ/SSD для «холодного».

Тюнинг качества и скорости

Ключевые ручки:

• HNSW: M (связность графа) и ef_search (ширина луча при поиске), ef_construction (качество графа).
• IVF: nlist (число кластеров), nprobe (сколько центров сканировать на запрос).
• PQ: число подпространств m и размер кодбука (бит на подпространство).
• Top-k: сколько кандидатов вернуть на первом этапе, прежде чем переранжировать.

Метрики для контроля

• Recall@k (какая доля «истинных» соседей найдена) и Precision@k.
• Latency p50/p95/p99 — стабильность важнее средних.
• Cost: память индекса, размер на диске, время построения/апдейта.

Рецепты:

• Начните с HNSW: M≈16/32, ef_search≈64…256, добейтесь Recall@10 ≥ 0.9, затем оптимизируйте p95.
• Для 10M+ векторов рассмотрите IVF: nlist≈√N, на запрос nprobe=1…8 (увеличивайте до достижения recall).
• При дефиците RAM — PQ/OPQ (8–16 подпространств) с переранжированием по точным векторам для топ-кандидатов.

Чанкование, мультивекторы и переранжирование

• Размер чанка: 400–1 200 токенов с перекрытием 50–150 — хорошая отправная точка; меньше «воды» — лучше recall.
• Мультивекторные ретриверы (ColBERT-подход): несколько векторов на документ (по токенам/фразам) ↑recall на мелких фактах.
• MMR (Maximal Marginal Relevance): уменьшает дубли — балансирует «сходство с запросом» и разнообразие контента.
• Переранжирование кросс-энкодером: берите топ-L кандидатов из индекса (например, 50–200), далее короткая модель (bi-encoder → cross-encoder) возвращает топ-k финальных чанков.

Гибридный поиск: вектор + ключевые слова

Чистый семантический поиск пропускает точные атрибуты (даты, коды, тикеры). Гибрид решает это:

• BM25/keyword → даёт точные совпадения;
• Vector → покрывает перефразирования и «смысл».

Схемы объединения: RRF (Reciprocal Rank Fusion), взвешенная сумма нормированных скорингов, двухступенчатый пайплайн (keyword-фильтр → ANN).

Фильтры по метаданным

• Pre-filter (до поиска): быстрый битсет/инвертированный индекс сокращает кандидатов (например, language=ru, source=docs).
• Post-filter: отбрасывает/переразвешивает результаты после ANN.
• Индексация полей: даты, типы документов, доступы. Держите отдельные индексы/микро-сегменты, чтобы фильтры не «ломали» latency.

Эксплуатация и жизненный цикл

• Upsert/удаления: HNSW хорошо поддерживает онлайновые вставки; IVF зачастую требует переобучения центров для больших сдвигов.
• Томбстоуны и компакция: логическое удаление → периодическая пересборка/мердж.
• Версионирование эмбеддингов: смена модели эмбеддинга == новый индекс (простое «доваривание» ломает качество).
• Мультишард: держите независимые индексы по доменам/разделам, объединяйте результаты на уровне агрегации.
• Дедупликация: не храните одинаковые/почти одинаковые чанки — теряется разнообразие, падает MMR.

Оценка памяти и стоимости

Память на вектор (без квантования): d × sizeof(dtype) (например, 1024 × 4B ≈ 4 KiB). Накладные расходы:

• HNSW: ~M × 8–16 B на ребро + служебные структуры; полная память может быть 2–3× от «сырых» векторов.
• IVF: центры (nlist × d), списки кандидатов, возможный кеш кодов.
• PQ: вектора → компактные коды (например, 8 бит × m), 10–20× компрессия; часть качества теряется, поэтому делайте recheck топ-кандидатов по исходным векторам.

Качество данных и «дрейф» эмбеддингов

• Эмбеддинги зависят от модели и её версии: при апдейте — переиндексация.
• Нормализация (L2-norm) нужна для cosine; следите, чтобы и база, и запрос были нормированы одинаково.
• Языки/домены: лучше отдельные индексы или поля-фильтры по языку/разделу.
• Обогащение метаданными: автор, дата, тип документа — помогают фильтрации и гибридным схемам.

Анти-паттерны

• «Один гигантский индекс на всё» — хуже управляемость и фильтры; дробите по коллекциям/неймспейсам.
• «Кодируем любой мусор» — дубликаты и «вода» ухудшают recall и переранжирование.
• «Стараться 100% recall на ANN» — даст взрыв latency/памяти; закладывайте двухступенчатый пайплайн с rerank.
• «Сменили эмбеддинг и доиндексировали в старый» — смесь распределений ломает топологию; строите новый индекс.

Мини-плейбук внедрения

1. Выберите модель эмбеддингов (ru/en, домен), зафиксируйте размерность d.
2. Решите схему чанкования и метаданные.
3. Начните с HNSW (RAM); измерьте Recall@k / p95 на золотом наборе (см. Evals).
4. Добавьте MMR и переранжирование кросс-энкодером.
5. При росте N → переход к IVF-PQ/SSD с recheck топ-L по точным векторам.
6. Введите мониторинг: recall, p95, размер индекса, долю дублей, «дрейф» качества при апдейтах.
7. Регламентируйте переиндексацию (версия эмбеддинга → версия индекса).

Мини-глоссарий

• ANN — approximate nearest neighbors, приближённый поиск соседей.
• HNSW — графовый индекс с многоуровневой навигацией.
• IVF — разбиение пространства на кластеры и поиск в их списках.
• PQ/OPQ — (оптимизированное) продукт-квантование для компрессии.
• MMR — отбор результатов с максимальной релевантностью и разнообразием.
• Recall@k — доля «истинных» соседей среди найденных k.

См. также

• RAG: извлечение и дополнение
• Evals
• Контекстное окно
• Fine-tuning