Векторные базы данных: какую выбрать и нужна ли вообще

Короткий ответ: скорее всего, отдельная векторная база вам не нужна. До сотни тысяч фрагментов — а это тысячи страниц текста — задачу решает расширение к той базе, которая у вас уже стоит. Отдельное хранилище окупается на миллионах.

И вторая половина, которая важнее выбора: качество поиска определяется не базой. База отвечает на вопрос «какие векторы ближе», и делает это примерно одинаково у всех.

Что она вообще делает

Хранит векторы и быстро находит ближайшие к заданному. Всё.

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

Отсюда первое практическое следствие: на малых объёмах приближение не нужно. Десять тысяч фрагментов перебираются за миллисекунды честно, без индекса и без отдельной системы.

По каким признакам выбирать, если всё же нужна

По убыванию того, как часто это решает.

Гибридный поиск из коробки. Векторный поиск теряет артикулы, коды ошибок и названия функций — их ловит обычный полнотекстовый. Если база умеет и то, и другое вместе, вы не будете склеивать две выдачи руками.

Фильтрация по метаданным вместе с поиском. «Найди похожее, но только в актуальных документах отдела продаж». Если фильтр применяется после поиска, вы получите пустую выдачу там, где должны были получить ответ.

Обновление без пересборки. База знаний меняется ежедневно. Индекс, который приходится перестраивать целиком, превращает это в ночную задачу.

Работа на вашей стороне. Для персональных данных вопрос не в удобстве: обработка должна оставаться там, где положено — что нельзя отдавать наружу.

Чего в списке нет: скорости на миллисекундах и рейтингов по бенчмаркам. На реальных объёмах разница между приличными решениями теряется в шуме на фоне вызова модели, который занимает секунды.

Что решает не база

Это главное, ради чего стоит дочитать.

Качество ответа определяется нарезкой — я измерял: при фиксированной нарезке 95% смысловых разделов оказываются разрезаны между кусками, и никакая база этого не исправит. Метрики поиска без магии — там числа.

Дальше по влиянию идут гибридный поиск, реранкер и только потом модель эмбеддингов. Векторное хранилище в этом списке вообще не появляется: оно не улучшает и не ухудшает, оно хранит.

Поэтому порядок работ такой: сначала нарезка и разметка, потом качество выдачи, и лишь когда всё это настроено — вопрос, где хранить.

Условие несогласия

Если у вас изначально миллионы фрагментов — каталог товаров, архив переписки, лог событий, — выбор хранилища перестаёт быть отложенным решением: перебор не сработает, а перенос данных потом стоит дороже, чем выбор сейчас.

Признак: если объём известен и он большой, выбирайте сразу. Если объём неизвестен, начинайте с расширения к существующей базе — переход потом дешевле, чем кажется, потому что переносятся не векторы, а исходные тексты.

Чего я делать не стал бы

Не стал бы заводить отдельную систему ради демонстрации на сотне документов. Это лишняя зависимость, лишний контейнер и лишний повод для отказа в проде.

Не стал бы хранить векторы без исходных текстов рядом. Смена модели эмбеддингов требует пересчёта всего, и без исходников это отдельный проект.

Не стал бы выбирать по бенчмаркам скорости. Узкое место в таком контуре — не поиск, а генерация; выигрыш в миллисекундах не виден за секундами ответа модели.

Открытый вопрос

Порог «сотня тысяч» я называю по опыту, а не по замеру: он зависит от размерности векторов, железа и того, что считать приемлемой задержкой.

Померить его на своём материале несложно — сгенерировать нужное число векторов и засечь перебор, — но я этого не делал, и честно говорю, что цифра здесь ориентир, а не результат. Если у вас объём близок к порогу, полчаса замера дадут ответ точнее любой статьи.