Векторные базы данных стали «рабочей лошадкой» современного семантического поиска и систем с дополненной генерацией. Они хранят и индексируют эмбеддинги — плотные векторы, в которых расстояние отражает смысловую близость объектов. На этих примитивах строятся контуры поиска фактов, рекомендации, дедупликация, кластеризация и, главное, retrieval для RAG-пайплайнов. Краткие основы см. в термине «Векторная база данных» и материале про эмбеддинги; здесь — технический обзор: какие индексы использовать, как их настраивать под объём/затраты/SLA, как строить гибридный поиск и эксплуатацию в проде.
Целевая аудитория — инженеры поиска и платформенных решений, которые отвечают за качество извлечения (Recall/NDCG), задержки (P95), экономику ($/1k запросов) и устойчивость индекса при росте коллекций.
Зачем отдельная векторная БД и где её место в архитектуре
Векторная БД решает задачу приближённого поиска ближайших соседей (ANN) по большим коллекциям. «Лобовой» перебор по L2/косинусу даёт точные ответы, но масштабируется плохо: O(N·d). Специализированные индексы сокращают сложность и память ценой небольшой аппроксимации. В архитектуре RAG векторная БД живёт между подсистемой индексации и сборкой контекста, принимая на вход запрос-вектор и возвращая top-k кандидатов с метаданными (источник, язык, ACL, даты). Подробную «сцену действий» см. в RAG-pipeline.
Пара важных причин выделять отдельный слой:
- Метаданные и фильтры: поиск не только по вектору, но и по языку/дате/разделу/ролям.
- Эксплуатация: инкрементальные вставки, soft-delete, TTL, реплика/шардирование, бэкапы и аудит кандидатов.
- Наблюдаемость: Recall@k/NDCG@k, P50/P95, цена/1k запросов — на постоянном мониторинге.
Модель данных: (vector, id, metadata) и договорённости
Минимальный артефакт — тройка (vector, id, metadata).
- vector: L2-нормированный массив чисел длины *d* (часто 384–1024).
- id: стабильный идентификатор фрагмента (чанка).
- metadata: язык (lang), раздел (section), источник (source_id), временные метки (ts, version), права (acl), тип контента.
Договорённости, которые экономят месяцы:
- Версионирование: хранить embedding_model, index_version и «дату сборки».
- Нормализация: L2-норма = 1 для стабильного косинуса/dot.
- Размер чанка: 500–1000 токенов + 10–20% overlap — хороший старт для извлечения фактов.
- Единая модель эмбеддингов для индекса и запроса.
Метрики расстояния: косинус, L2 и dot-product
Метрика влияет на совместимость с индексами и стабильность ранжирования:
| Метрика | Плюсы | Минусы | Где уместна |
| Косинусная близость | Устойчива к масштабу, хорошо работает с L2-нормой | Требует нормализации | Текстовые эмбеддинги, поиск по смыслу |
| L2 (евклид) | Геометрически интерпретируема | Чувствительна к масштабу | Кластеризация, индексы с L2 |
| Скалярное произведение (dot) | Быстро для MIPS | Зависит от нормы | Приемлемо с нормализацией |
Практика: нормируйте векторы и используйте косинус или dot (с нормой) — так легче переносить профили индексов.
Индексы ANN: как выбрать под объём и SLA
Главный дизайн-выбор — структура индекса. Ниже — «шпаргалка» по профилям.
| Индекс | Идея | Плюсы | Минусы | Рекомендуемое применение |
| HNSW (граф «малых миров») | Навигация по многоуровневому графу | Высокий Recall при малых задержках; инкрементальные вставки | Память ↑, требуется тюнинг M/ef | Кластеры до десятков млн векторов, акцент на качество |
| IVF (coarse quantizer) | Разбиение на кластеры, поиск в nprobe | Скорость на больших N; память ↓ | Зависимость от nlist/nprobe | Крупные индексы с равномерным распределением |
| PQ / IVF-PQ | Квантование компонент вектора | Сжатие ×10–16 и I/O ↓ | Потеря точности, калибровка | Огромные коллекции при жёстком бюджете RAM |
| Flat (brute-force) | Полный перебор (CPU/SIMD, GPU) | Точная метрика, дебаг | Медленно при N≫ | Малые коллекции, контроль и A/B |
| Disk-ориентированные (DiskANN/Hybrid) | Данные/индекс частично на диске | Масштаб «за пределы RAM» | Сложность I/O | Связка с дешёвым сториджем, холодные шард-пулы |
Практический маршрут миграции: Стартуйте с HNSW (быстрый сильный baseline). С ростом объёма/ограничений памяти переходите на IVF-PQ для кратного снижения RAM при умеренной потере точности. Для сверхкрупных архивов добавляйте диск-ориентированные профили.
Параметры индексов: от чего зависит качество и P95
| Параметр | Что делает | Типовые ориентиры | Комментарии |
| Размерность *d* | Сколько признаков в векторе | 256–1024 | Слишком большие *d* ухудшают память/шум |
| efConstruction (HNSW) | Глубина построения графа | 100–400 | Больше — лучше Recall, дороже по RAM/времени |
| M (HNSW) | Степень вершин | 16–48 | Баланс ширины графа и памяти |
| nlist (IVF) | Число кластеров | 4k–32k | Пропорционально объёму данных |
| nprobe (IVF) | Сколько кластеров сканить | 8–64 | Больше — точнее, но дороже |
| Кодбуки PQ | Глубина/кол-во подпространств | 8×8, 16×8 | Тюнинг под вашу *d* и бюджет |
Всегда держите baseline кривые Recall@k ↔ P95 ↔ цена/1k запросов на своём корпусе.
Гибридный поиск: keyword + вектор + rerank
Векторный поиск устойчив к перефразировкам, но проигрывает на редких терминах и артикулах. Поэтому прод-стек строится как гибрид:
- Pre-filter keyword/BM25 и метаданные — чтобы отсечь очевидно нерелевантные разделы.
- ANN-кандидаты — 50–200 документов по вектору.
- Fusion списков (весовое объединение).
- Rerank компактной моделью или LLM-судьёй до top-k = 3–8 для подачи в генератор.
Гибрид повышает стабильность и объяснимость; производственные аспекты покрыты в RAG-pipeline.
Метаданные и фильтры: половина успеха в проде
Хорошая схема metadata — такой же «индекс качества», как и ANN.
- Язык, раздел, свежесть — фильтруйте *до* или *во время* ANN, а не после.
- ACL — фильтрация прав доступа в индексе, иначе есть риск утечек.
- Версии и источники — облегчает аудит и регрессионные тесты.
- Типы фрагментов — текст/таблица/код для профилированного rerank и сборки контекста.
Многоязычные и мультимодальные индексы
Лучший приём — шардирование: отдельные профили для языков и модальностей. Для мультимодальных моделей храните векторы в общем пространстве (текст↔картинка). Если пространства разные — делайте объединение на уровне fusion.
Стоимость и производительность: где живут узкие места
Главные бюджеты: память, I/O и вычисления. Инженерные рычаги:
- Размерность и нормализация векторов — контролируют RAM и стабильность.
- Квантование весов/векторов/кэшей — даёт ×2–4 экономию памяти/трафика; детали в «Квантовании».
- Batch-запросы и SIMD/GPU для Flat и rerank.
- Кэш кандидатов и результатов top-k.
- Сетевые задержки — держите индекс ближе к генератору; P95 часто «съедается» сетью.
Масштабирование и отказоустойчивость
- Шардирование по доменам/языкам/версиям; маршрутизация запроса к профилю.
- Репликация чтения для трафика и экспериментов.
- UPSERT/soft-delete/TTL — операции жизненного цикла фрагментов.
- Миграции эмбеддингов — период двойного индекса (старый+новый) и атомарное переключение.
- Бэкапы — снимки индексов и payload; проверка восстановления в регламенте.
- Наблюдаемость — трассировки, логи кандидатов, версии конфигов.
Качество поиска: офлайн и онлайн-оценка
| Этап | Метрики | Цель/примечания |
| ANN (кандидаты) | Recall@k, MRR | Найти «правильные» фрагменты без rerank |
| Ранжирование | NDCG@k | Порядок кандидатов по полезности |
| Сквозной RAG | Faithfulness, Citation@k | Верность источникам в ответах |
| Производство | P50/P95, цена/1k запросов | SLA и экономика |
Держите golden-наборы из реального трафика и A/B-тесты на сквозном сценарии. Чисто офлайн-метрики легко «перетюнить».
Профили выбора индекса: экспресс-решения под объём
| Объём коллекции | RAM | SLA | Индекс | Комментарии |
| ≤ 1 млн векторов | Не ограничена | Ригорозный Recall | HNSW | Простой тюнинг, быстрый rollout |
| 1–50 млн | Средняя | Баланс | IVF / IVF-HNSW | Тонкая настройка nlist/nprobe |
| 50 млн+ | Жёсткие лимиты | «Приемлемый» Recall | IVF-PQ | ×10–16 экономия памяти |
| 100 млн+ и архив | Ограничена | Высокий P95 | Диск-ориентированные | Профили с I/O и кэшем |
Таблица: эффекты параметров и практические ориентиры
| Рычаг | Влияние на Recall | Влияние на P95 | Цена |
| ef (HNSW, запрос) ↑ | ↑ | ↑ | ↑ CPU/RAM |
| nprobe (IVF) ↑ | ↑ | ↑ | ↑ сканируемых кластеров |
| PQ: кодбуки глубже | ↑ | ≈ | ↑ память кодбуков |
| d (размерность) ↓ | ↓/≈ | ↓ | ↓ RAM/IO |
| Квантование векторов | ↓ умеренно | ↓ | ↓ RAM/IO значительно |
Ориентируйтесь на собственные кривые компромисса — они сильно зависят от корпуса и задач.
Инженерные паттерны и анти-паттерны
Делайте так
- Гибрид первым делом: pre-filter keyword+метаданные → ANN → fusion → rerank.
- Отдельные шарды на языки/домены; общий API маршрутизации.
- Версионирование эмбеддингов и индексов, журналы кандидатов.
- Малое top-k (3–8) для сквозного RAG; сжатие выдержек вместо «простыней».
- Нормализация векторов и фиксированная модель эмбеддингов для индекса и запроса.
Избегайте
- «Вектор — и точка»: без keyword/метаданных редкие термины теряются.
- Гигантских чанков: падает точность извлечения.
- Единых глобальных шкал для квантования: используйте per-channel/group-wise (см. квантование).
- Отсутствия трассировок: без логов кандидатов невозможно разбирать инциденты.
Чек-лист запуска векторной БД
- Определите сценарий: семантический поиск, RAG, рекомендации.
- Согласуйте метрики: Recall@k, NDCG@k, P95, цена/1k запросов.
- Выберите модель эмбеддингов и *d*; включите L2-норму.
- Настройте индекс (HNSW/IVF/IVF-PQ) и baseline-кривые.
- Включите гибрид (keyword/метаданные/fusion) и rerank.
- Введите наблюдаемость и версии: trace-id, журналы кандидатов, конфиги.
- Продумайте миграции эмбеддингов: двойной индекс, атомарное переключение.
- Оптимизируйте стоимость: кэш, батч, квантование векторов и кэшей.
- Задокументируйте инциденты и откаты.
Часто задаваемые вопросы (FAQ)
Можно ли обойтись без HNSW и сразу идти в IVF-PQ? Да, если у вас сразу большой объём и жёсткие ограничения по памяти. Но без baseline на HNSW сложнее понимать «цену» компромисса.
Нужен ли GPU для векторной БД? Не всегда. CPU+SIMD закрывают много профилей. GPU полезен для Flat/переранжирования или когда вы делаете много параллельных запросов. Главный лимит — память и сеть.
Сколько внутренних ссылок/цитат отдавать в RAG? Обычно 3–8 фрагментов (top-k), но сжатых до фактов. Большие списки увеличивают стоимость и ухудшают ответ.
Что выбрать: косинус или L2? При L2-норме косинус стабилен и хорошо переносится между реализациями. L2 удобен для некоторых индексов и кластеризации.
Как понять, что индекс «устал»? Растут P95 и падает Recall@k/NDCG@k без изменения корпуса. Проверьте размеры шарда, кэш/сеть, обновите параметры ef/nprobe, пересоберите индекс.
Как квантование векторов влияет на качество? INT8-представления обычно дают умеренную потерю Recall@k; выигрыш в памяти/IO часто окупает компромисс. Подробности — в статье о квантовании.
Словарь терминов
- ANN (Approximate Nearest Neighbors) — приближённый поиск ближайших соседей.
- HNSW/IVF/PQ — семейства индексов и квантования для ускорения и сжатия.
- Recall@k/NDCG@k — полнота извлечения и качество ранжирования.
- Fusion — слияние списков результатов keyword и ANN.
- Rerank — доранжирование компактной моделью/LLM.
- ACL — контроль доступа на уровне индекса.
- Chunking — разбиение документов на фрагменты.
- P50/P95 — медиана/95-й перцентиль задержки.
- IVF-PQ — инвертированный файл с квантованием по подпространствам.