Векторная база данных — хранилище числовых представлений с поиском по близости и фильтрацией по метаданным. Отвечает за то, чтобы найти ближайшие векторы быстро и не перебирая весь индекс.
Нужна ли отдельная
Главный вопрос, который стоит задать до выбора продукта. На объёмах до нескольких сотен тысяч фрагментов расширения к обычной базе — pgvector к PostgreSQL — обычно достаточно.
Аргумент в пользу такого решения не технический, а эксплуатационный: одна база вместо двух. Один бэкап, одна репликация, одна точка отказа, транзакции вместе с прикладными данными. Для небольшой команды это перевешивает разницу в скорости поиска.
Отдельное специализированное решение оправдано, когда фрагментов миллионы, нужна сложная фильтрация по метаданным на скорости, требуется горизонтальное масштабирование или гибридный поиск из коробки.
Типы индексов: плоский, IVF, HNSW
Плоский (перебор). Расстояние считается до каждого вектора — результат точный, скорость падает линейно с ростом базы. На десятках–сотнях тысяч векторов это всё ещё миллисекунды; типичное применение — эталонные наборы и проверка, сколько теряют приближённые индексы.
IVF (кластеры). Векторы заранее группируются, поиск идёт только по ближайшим к запросу группам. Индекс строится быстро и требует меньше памяти, чем граф; плата — пропуск части релевантных векторов в «чужих» кластерах и чувствительность к числу групп: их заметно больше или меньше оптимального — точность падает.
HNSW (граф). Векторы связываются в многослойный граф, поиск идёт по переходам от coarse к точному. Даёт лучшее соотношение скорость/полнота на больших базах и хорошо переносит добавление векторов; плата — память на граф связей и медленное построение на десятках миллионов векторов.
Параметры этих индексов и компромисс полнота/скорость — тема статьи про векторный поиск; здесь важно, что тип индекса выбирается под объём и режим обновлений, а не «по умолчанию HNSW».
Квантование векторов в базе
Зачем. Основной потребитель памяти — сами векторы, и база умеет хранить их сжато. Скалярное квантование до одного байта на компоненту сжимает вектор вчетверо при потере полноты в единицы процентных пунктов на типовых задачах; продукционное кодирование (PQ) сжимает в 16–32 раза, но теряет заметнее и требует обучения кодовой книги на ваших данных.
Когда включать. Обычно — когда индекс не помещается в оперативную память или стоимость этой памяти становится существенной. На сотнях тысяч фрагментов выигрыш не окупает потерю точности; на десятках миллионов — наоборот.
Не путать с квантованием модели: там сжимаются веса нейросети, здесь — хранимые векторы. Это независимые механизмы, и применяются они по разным основаниям.
Память и масштаб
Счёт памяти простой. Вектор из 1024 компонент занимает около 4 КБ, миллион фрагментов — порядка 4 ГБ только на векторы; граф HNSW добавляет ещё 50–100% сверху. Отсюда быстрый тест реализуемости: размерность модели эмбеддингов умножается на число фрагментов — и видно, помещается ли индекс в оперативную память сервера.
Порог, где всё усложняется. Пока индекс лежит в памяти одной машины, эксплуатация проста. Дальше начинается шардинг — разбиение индекса по узлам с маршрутизацией запросов, — репликация под нагрузку чтения и согласованность метаданных с кусками. Это основные затраты специализированных решений, и появляются они на миллионах векторов.
Диск против памяти. Часть решений умеет держать индекс на диске и подкачивать при поиске — экономия памяти ценой роста задержки в разы. Для интерактивных сценариев это обычно неприемлемо, для фоновой обработки — приемлемо.
Миграции
Переезд с сохранением векторов. Если модель эмбеддингов и метрика не меняются, векторы переносятся выгрузкой и загрузкой вместе с метаданными; проверка — сравнение полноты поиска на контрольном наборе запросов до и после. Стандартного языка запросов между продуктами нет, поэтому слой обращения к базе лучше изолировать в коде с самого начала.
Смена модели эмбеддингов — не миграция, а переиндексация. Векторы разных моделей несравнимы: между старым и новым индексом нет соответствия, корпус пересчитывается целиком. Планировать смену модели надо как проект с полной переиндексацией и повторным замером качества, а не как «обновление базы».
Практическое правило. Источник истины — исходные документы, индекс — производное. Пока это так, любая миграция сводится к повторной индексации, и потерять данные переходом между продуктами невозможно.
На что смотреть при выборе
Фильтрация вместе с поиском. Ключевой практический критерий. Разграничение доступа и отсечение устаревших редакций — не опция, и важно, чтобы фильтр применялся во время поиска, а не после. Иначе после фильтрации может не остаться ничего.
Обновление и удаление. Насколько дёшево изменить или удалить фрагменты. Некоторые структуры индекса плохо переносят удаление и требуют перестройки.
Гибридный поиск. Есть ли встроенный словесный поиск или придётся держать второй индекс отдельно.
Где размещается. Локально или в облаке — с учётом того, что в векторах хранятся ваши документы, а восстановить из вектора исходный текст частично возможно.
Эксплуатация. Резервное копирование, мониторинг, обновление версий. Про это вспоминают последним, а болит оно первым.
Чего векторная база не делает
Не заменяет обычную базу: агрегаты, соединения, отчёты остаются задачей реляционной СУБД.
Не отвечает за качество поиска — оно определяется моделью эмбеддингов и нарезкой документов. Смена базы меняет скорость и удобство, но не то, находится ли нужное.
Не хранит исходный текст «бесплатно»: обычно рядом всё равно нужно держать оригиналы, чтобы показать источник.
Частые вопросы
Можно ли обойтись PostgreSQL с pgvector?
На объёмах до нескольких сотен тысяч фрагментов — как правило да, и это чаще всего правильный выбор. Выигрывает эксплуатация: одна база, один бэкап, одна точка отказа, транзакции вместе с прикладными данными.
Когда нужна специализированная база?
Когда фрагментов миллионы, требуется сложная фильтрация по метаданным на скорости, нужно горизонтальное масштабирование или встроенный гибридный поиск. До этих порогов отдельное решение добавляет работы больше, чем даёт выигрыша.
Влияет ли выбор базы на качество ответов?
Почти нет. Качество определяется нарезкой документов и моделью эмбеддингов; база отвечает за скорость поиска и удобство фильтрации. Менять базу в надежде, что система станет точнее, — потраченное время.
Безопасно ли хранить векторы в облаке?
Вектор — не шифр: по нему частично восстановим исходный текст. Если документы содержат персональные данные или коммерческую тайну, размещение индекса во внешнем сервисе нужно оценивать так же, как размещение самих документов.
Сколько памяти займёт индекс?
Считается напрямую: размерность эмбеддинга × 4 байта × число фрагментов, плюс 50–100% на граф HNSW и служебные структуры. Для типовой размерности 1024 это около 4 КБ на фрагмент, то есть миллион фрагментов — порядка 8 ГБ с накладными расходами. Квантование снижает оценку в 4–32 раза ценой полноты.
Как перенести индекс в другую базу?
Если модель эмбеддингов та же — выгрузкой векторов с метаданными и контрольной проверкой полноты на наборе запросов. Если модель меняется — только полной переиндексацией из исходных документов. Держать исходники как источник истины — обязательное условие безболезненного переезда.
Чем квантование в базе отличается от квантования модели?
Квантование модели сжимает её веса ради дешёвого инференса и применяется на стороне вычисления эмбеддингов. Квантование в базе сжимает уже вычисленные векторы ради памяти. Решения независимы: можно применять оба, ни один или один из них, и качество системы проверяется замером полноты поиска, а не по документации продукта.