Векторная база данных (Vector Database): индексы ANN, гибридный поиск, метаданные и продакшн-паттерны

Зачем векторная БД (Vector Database) и когда она уместна

• Семантический поиск: пользователи формулируют запросы свободно, а система находит подходящие фрагменты даже без точных совпадений слов.
• RAG и ассистенты: перед генерацией ответа подтягиваются релевантные выдержки из корпуса, снижая «догадки» модели (RAG).
• Рекомендации и «похоже на это»: статьи, товары, видео, PR в коде.
• Дедупликация/near-duplicate: поиск «почти одинаковых» документов и медиаматериалов.
• Кластеризация/таксономии: группировка коллекций и авто-разметка.
• Антиспам/антифрод/анализ логов: аномалии в смыслах, а не только в ключевых словах.

Если домен стабилен и «жёстко» формализован, бывает достаточно реляционной БД + keyword. Но там, где важна семантика и устойчивость к перефразировкам, векторная БД становится ядром поиска.

Архитектура и модель данных

Векторная БД хранит тройку: (vector, id, metadata).

• vector — массив чисел фиксированной длины *d* (например, 384/768/1024); как правило, L2-нормированный.
• id — уникальный идентификатор фрагмента (чанка документа, записи, изображения).
• metadata (payload) — минимально достаточные поля фильтрации: источник, язык, раздел, дата/версия, права доступа.

Типичный поток:

• Ингест: получение сырого контента, очистка, нормализация форматов.
• Разбиение (chunking) документов на фрагменты удобного размера.
• Подсчёт эмбеддингов для чанков одной и той же моделью эмбеддингов.
• Индексация: запись (vector, id, metadata) и построение индекса ANN.
• Поиск: запрос → эмбеддинг → ANN-кандидаты → гибрид с keyword → фильтры/переранжирование → top-k.
• Интеграция с приложением: например, подстановка фрагментов в контур RAG или в ранжирование выдачи.

На физическом уровне БД предоставляет индексы ANN, фильтры по метаданным, API для batch-операций, репликацию/шардирование и наблюдаемость.

Метрики близости и нормализация

Выбор метрики влияет на совместимость с индексом и стабильность выдачи:

• Косинусная близость — угол между векторами, устойчив к масштабу; обычно требует L2-нормализации (||v||=1).
• Dot-product — удобен для MIPS; с нормализацией ведёт себя похоже на косинус.
• L2 (евклид) — ближе к «геометрической» дистанции; применяется в кластеризации и некоторых ANN-индексах.

Инженерные правила:

• Нормируйте векторы (L2), если используете косинус/dot; это стабилизирует ранжирование.
• Не гонитесь за высокой размерностью: 256–1024 чаще достаточно; чем больше *d*, тем выше память/IO и риск «шума».

Индексы ANN: профили и компромиссы

Поиск ближайших соседей в векторном пространстве «в лоб» (brute-force) дорог: O(N·d). Поэтому используют Approximate Nearest Neighbors (ANN). Ниже — таблица «что выбрать и когда».

Практический путь: начните с HNSW (получить сильный baseline), далее при росте данных переходите к IVF-PQ (существенно экономит память при умеренной деградации).

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

Векторный поиск устойчив к перефразировкам, но уязвим к редким терминам и именам собственным. Keyword-слой (BM25/фильтры) даёт точность на номенклатуре, артикулах, кодах. Производственная стратегия:

• Fusion: объединение результат-листов (keyword и ANN) с последующим переранжированием.
• Переранжирование (rerank): компактная модель или LLM-судья улучшает точность top-k.
• Фильтры по метаданным: язык, раздел, дата «свежести», допустимость по ролям.

Итог: система стабильно отвечает на и «научные формулировки», и на запросы «по артикулам».

Метаданные и фильтры: половина успеха

Метаданные минимально-необходимые, но качественные. Рекомендации:

• Источник, раздел, язык, дата/версия — для фильтров и «time-aware» поиска.
• Права доступа — ACL/ролевая фильтрация на уровне индекса.
• Семантические тэги — когда корпус велик и неоднороден.
• Сводки/заголовки — краткие описания повысят кликабельность результатов.

Фильтры должны применяться до или во время ANN-поиска (а не после) — иначе в топ попадут нерелевантные кандидаты.

Качество: как измерять и не обмануться

Офлайн и онлайн-метрики:

Практика:

• Golden-наборы: пары «запрос → правильный фрагмент» из реального трафика.
• Срезы: язык, раздел, свежесть; где падает качество и почему.
• Разводите офлайн и A/B: без онлайна легко «перетюнить» под тест.

Производительность и стоимость

Где прячутся ресурсы:

• Память: ~4 байта × *d* на float (или 2 байта при FP16/квантовании) + overhead индекса. Для d=768 это десятки МБ на 100k векторов.
• Квантование и сжатие: уменьшает память/IO и цену инференса — см. Квантование.
• Batch и SIMD/GPU: батчируйте вычисления и используйте аппаратные инструкции; GPU ускоряет Flat и переранжирование.
• Кэширование: результаты top-k и «горячие» запросы; KV-кэш на стороне генератора — уже в стеке инференса (Инференс).
• Ограничения: max-k, ограничение длины чанка/цитаты, таймауты запросов.

Цель — удержать P95 в бюджет і цену/1k запросов в лимите продукта.

Масштабирование, шардирование, отказоустойчивость

• Шардирование: разделяйте корпусы по языкам/домейнам/версиям; отдельные профили индексов под разные нагрузки.
• Репликация: чтение-реплики для трафика; чёткий SLA на ребилд индекса.
• Консистентность: чаще eventual; для критичных сценариев — журналы/версии и «двойной индекс» при миграциях.
• Бэкапы и катастрофоустойчивость: резерв индексов и *payload*; RPO/RTO регламентирован.
• Наблюдаемость: метрики поиска, журнал кандидатов, конфиги индексов — пригодится при инцидентах.

Аппаратная платформа зависит от профиля нагрузки; если задействуются ускорители, учитывайте базовые принципы из Hardware GPU 101.

Интеграция с RAG и ассистентами

Векторная БД — это «скелет» retrieval в RAG: запрос → top-k фрагментов → модель. Практика:

• Chunking 500–1000 токенов с 10–20% перекрытием — хороший старт.
• k=3–8: больше редко помогает, но увеличивает стоимость и «замусоривает» контекст.
• Гибрид и rerank поднимают «ядровые» выдержки, пригодные для цитирования.
• Сжатие фрагментов перед подстановкой — экономит контекст и снижает P95.

Общий обзор решений и профилей поисковых движков — см. Обзор векторных БД.

Обновления, удаление и версионирование

• UPSERT: заменяйте существующие записи по id, храните версию документа в метаданных.
• Soft-delete/TTL: помечайте устаревшие фрагменты; ребилд по расписанию.
• Миграции эмбеддингов: при смене модели держите двойной индекс на период перехода, затем атомарно переключайтесь.
• Дедупликация: контроль хэшей исходного контента и векторов (near-duplicate).
• Аудит: логи операций, чтобы воспроизвести состояние индекса на момент инцидента.

Риски и безопасность

• Конфиденциальность: вектора могут «утекать» информацию о первичных данных; фильтруйте PII до индексации, разделяйте индексы по зонам доступа.
• Poisoning: вредоносные документы в индексе уводят поиск; валидируйте источники, белые списки для RAG.
• Prompt-injection из документов: отделяйте данные от инструкций; в подсказках запрещайте выполнять команды, пришедшие из источников.
• Предвзятость: перекосы корпуса проявляются в выдаче; анализируйте срезы и корректируйте.
• Надёжность: таймауты, backoff-ретраи, предельные объёмы ответов и защита от «штормов» запросов.

Чек-лист внедрения векторной БД

• Сформулируйте сценарий: семантический поиск, RAG, рекомендации.
• Оцените корпус: источники, права, языки, обновляемость.
• Выберите модель эмбеддингов и размерность; решите вопрос нормализации.
• Настройте chunking и метаданные: язык/раздел/дата/версия/ACL.
• Постройте индекс ANN (старт — HNSW), зафиксируйте baseline по Recall@k/NDCG@k.
• Подключите гибрид (keyword+вектор), затем rerank там, где это окупается.
• Введите наблюдаемость: P50/P95, hit-rate кэша, цена/1k запросов, срезы качества.
• Планируйте миграции эмбеддингов: двойной индекс и обратимая конфигурация.
• Оптимизируйте стоимость: квантование, сжатие, батч, кэш.
• Задокументируйте инциденты и процедуры отката; настройте бэкапы и реплики.

Таблица: быстрые ориентиры по выбору индекса

Таблица: параметры качества и SLA (ориентиры)

FAQ

В чём отличие векторной БД от «просто библиотеки ANN»? Векторная БД — это не только индекс, но и жизненный цикл данных: метаданные, фильтры, доступы, репликация, шардирование, наблюдаемость и миграции.

Можно ли обойтись без keyword-поиска? Технически да, но гибрид почти всегда стабильнее: редкие термины и имена собственные лучше ловятся BM25/фильтрами.

Как выбрать размер чанка? Старт: 500–1000 токенов и перекрытие 10–20%. Затем подстраивайтесь по Recall@k и A/B-результатам в вашем корпусе.

Что делать при смене модели эмбеддингов? Держать двойной индекс (старый+новый), собирать сравнимую статистику, затем атомарно переключаться; не забывать об обратимости конфигурации.

Когда стоит квантовать вектора/индексы? Когда упираетесь в память/IO или цену. Смотрите падение Recall/NDCG на своих задачах; компромисс часто выгоден (Квантование).

Нужны ли GPU? Не всегда. CPU + SIMD закрывают многие профили. GPU полезны для Flat/переранжирования или когда у вас большой поток однотипных запросов.

Как защититься от «ядовитых» документов? Санкционированные источники, проверка PII, белые списки для RAG, логи и аудит извлечённых фрагментов.

Словарь терминов

• Эмбеддинг — плотный числовой вектор, представляющий объект.
• ANN (Approximate Nearest Neighbors) — приближённый поиск ближайших соседей.
• HNSW/IVF/PQ — семейства индексов и квантования для ускорения и сжатия.
• Recall@k / NDCG@k — метрики полноты и качества ранжирования.
• Rerank — доранжирование кандидатов более мощной моделью.
• Fusion — объединение списков результатов keyword и векторного поиска.
• Шардирование/репликация — распределение и отказоустойчивость хранения/поиска.
• ACL — управление доступом к данным на уровне индекса.
• Chunking — разбиение документов на фрагменты перед индексацией.
• Payload (metadata) — сопутствующие поля для фильтрации/аудита.

См. также

• Большие языковые модели (LLM)
• Машинное обучение (ML)
• Искусственный интеллект (AI)
• RAG-pipeline: архитектура и паттерны
• AI-стек: слои и роли
• Аппаратная база: GPU 101