Сравнительный анализ пяти встроенных хранилищ векторов: FAISS, Chroma, LanceDB, VectLite

Большинство сравнений «лучших баз данных векторов» выглядят как перефразированные версии собственных страниц-презентаций производителей: Pinecone — быстрый, Qdrant — надежный, Chroma — простой, все выигрывают. Этот обзор основан на более узкой задаче. Нет кластеров, нет Docker, нет открытых портов, нет управляемых тарифов. Только встроенный хранилище векторов, представляющее собой один локальный файл, команду pip install и три строки кода на Python. Вот домашний тест пяти движков для именно такого использования.

Цифры

Набор данных содержал 5 000 векторов размером 384 измерения; было совершено 50 запросов с использованием косинусного сходства. Все тесты проводились на macOS (x86_64) с Python 3.12.8 с использованием стандартных настроек каждого движка.

Через десять секунд: FAISS — самый быстрый инструмент, хотя его едва можно назвать базой данных. Chroma — наиболее простой вариант для начала работы, но его стандартный показатель восстановления данных в 84% является проблемой, которую многие игнорируют. VectLite достигает показателя восстановления 96,6% в встроенном режиме без какой-либо настройки, что стало сюрпризом. LanceDB стремится к идеальному показателю восстановления, но за это платит задержкой. NumPy выступает в роли арбитра, а не конкурента.

Почему показатель «самый быстрый» — неверный критерий оценки

Рынок векторных баз данных — это сфера маркетинговых сражений. Каждый поставщик публикует результаты тестов, в которых ему удается победить, СМИ повторяют эти цифры без контекста, а все сосредотачиваются на задержке. Одна лишь задержка вводит в заблуждение. Ответить за полмиллисекунды, но с неверными данными, хуже, чем потребоваться 5 мс для получения правильных результатов. Именно это измеряет показатель воспроизводимости, и поэтому серьезные инструменты, такие как ANN-Benchmarks (https://ann-benchmarks.com/), отображают его в сочетании с пропускной способностью.

Поэтому в этих тестах одновременно измеряются оба показателя: с одной стороны — задержки p50, p95 и p99, а также количество запросов в секунду, а с другой — показатель воспроизводимости@10 по сравнению с точным поиском с использованием NumPy.

Что тестировалось, а что нет

Проект представляет собой небольшой пакет на Python под названием vectlite-benchmark-lab. Каждый движок реализует общий интерфейс VectorStore, и запускающий скрипт вызывает их по очереди. Он охватывает следующее:

• Пакетную загрузку данных
• Поиск k-NN с измерением точности восстановления
• Фильтрацию метаданных по точному совпадению на основе tenant_id
• Время запуска при первом использовании
• Резервное копирование и портабельность
• Экспорт в форматы CSV, JSON и графики с использованием Matplotlib

А что исключено — сказано сразу: нет распределенных или многокластерных конфигураций, в текущей версии не более 5 000 векторов, отсутствует настройка индексов, а также нет поддержки Qdrant или pgvector, поскольку они требуют работающего сервера, тогда как целью была чисто локальная обработка. Этот последний выбор сделан намеренно. Первый важный вопрос не в том, кто победит после двух недель настройки, а в том, как будет вести себя движок сразу после установки без каких-либо изменений.

Метод

«Истинная ценность» — это поиск по косинусу с использованием метода brute-force в NumPy. Показатель воспроизводимости движка представляет собой долю истинных соседей, которые оно возвращает, в среднем по всем запросам. Настройки запуска:

vectlite      : 0.10.0
vectors       : 5,000 (synthetic, normalized)
dimensions    : 384
queries       : 50
top_k         : 10
metric        : cosine
filter        : tenant_id (exact-match)
warmup        : 5 queries discarded
hardware      : macOS x86_64, Python 3.12.8

Чтобы воспроизвести его на вашем компьютере, выполните полную команду:

PYTHONPATH=src python -m vectlite_benchmark_lab run \
  --stores vectlite,faiss,chroma,lancedb,numpy_exact \
  --vectors 5000 --dimensions 384 --queries 50 \
  --top-k 10 --batch-size 500 \
  --output-dir results/vectlite-0.10.0 \
  --data-dir data/vectlite-0.10.0

Затем сравните свои результаты с этими и обратите внимание на различия.

FAISS: предел скорости

FAISS лидирует во всех показателях задержки: 0,65 мс при p95 и идеальном уровне воспроизведения данных, что соответствует ожиданиям от библиотеки на C++, оптимизированной именно для этой цели в течение десяти лет. Однако это не база данных — у неё нет встроенной фильтрации метаданных, функций постоянного хранения данных и возможности создания портабельных резервных копий. Её можно обернуть слоем, добавляющим эти функции, и так и делают, но в чистом виде она больше похожа на математическую библиотеку, чем на инструмент, который можно предоставить клиентам. Сравнивать её с Chroma — всё равно что сравнивать двигатель F1 с Toyota: один быстрее на трассе, другой доставляет продукты домой. Этот пример приводится лишь в качестве справки. Если вам нужен исключительно простой поиск векторов, это очевидный выбор.

Chroma: простота начала работы, но следите за уровнем воспроизведения данных

Chroma является стандартным выбором для прототипов RAG, и это обусловлено удобством работы разработчика. Установите chromadb, напишите пять строк — и документы уже индексируются.

Проблема заключается в точности восстановления данных. При работе с этими данными без применения фильтров Chroma находит лишь 84% релевантных результатов, что означает, что примерно один из шести ожидаемых результатов так и не появляется. Для прототипа это нормально. Однако в производственной среде RAG, где качество поиска влияет на ответ модели, это скрытое снижение релевантности, которое API не выявляет. При настройке параметров HNSW можно восполнить большую часть этого разрыва, если вы знаете о необходимости таких изменений. С использованием фильтров точность восстановления достигает 100%, но задержка p95 возрастает до 18,76 мс, что значительно медленнее, чем у остальных методов при выполнении одной и той же задачи. Вердикт: отлично с первого дня и всё ещё хорошо через тридцать дней, при условии настройки перед внедрением в производство.

VectLite: сюрприз

Версия 0.10.0 достигает уровня воспроизведения 96,6% при стандартных настройках, что является самым высоким показателем среди всех встроенных движков. Время выполнения простого поиска по p95 составляет 5,71 мс, что находится на среднем уровне (Chroma 3,14, LanceDB 12,20). При фильтрации время выполнения по p95 составляет 10,28 мс, тогда как у Chroma — 18,76 мс, то есть здесь скорость примерно в два раза выше.

Виден прогресс с момента первых версий. По сравнению с v0,1.x скорость обработки данных выросла с 47 до 154 векторов в секунду (примерно в 3,3 раза быстрее), уровень воспроизведения увеличился с 0,948 до 0,966, а время выполнения по фильтру по p95 сократилось с 18,6 мс до 10,3 мс, что на 45% меньше.

Скорость обработки данных является слабым местом. 154 вектора в секунду — это медленно по сравнению с 2000 и более у Chroma, а также очень медленно по сравнению с LanceDB. Для нескольких тысяч документов, индексируемых один раз, это не имеет значения. Но для миллиона векторов это означает долгое ожидание, поэтому это, вероятно, следующая проблема, которую необходимо решить. Тем не менее, это был единственный движок в группе, чьи показатели не требовали оправданий.

LanceDB: полная точность, медленный поиск

LanceDB обеспечивает 100% точность и обрабатывает 20 120 векторов в секунду, что на бумаге выглядит впечатляюще. Однако цена этого — задержка поиска: 12,20 мс (p95), что является самым высоким показателем среди пяти рассмотренных инструментов. Для пакетной обработки тысяч запросов за ночь это не имеет значения. Но для интерактивного инструмента, где человек ожидает ответа у клавиатуры, это становится значимым недостатком. Подходит для пакетной обработки и аналитики, но слишком медлен для интерактивного использования.

NumPy: арбитр

Поиск по косинусу с использованием brute-force на всей матрице по определению обеспечивает полную точность, при этом задержка остается приемлемой до нескольких десятков тысяч векторов, после чего резко возрастает. Это не готовый продукт, а инструмент, по которому оцениваются все остальные движки.

Какой выбрать

Бенчмарк не выявляет победителя — он показывает существующие компромиссы. Примерное соответствие по сценариям использования:

• Быстрый прототип RAG: Chroma — благодаря двухминутной настройке и большой экосистеме
• Встроенная память ИИ: VectLite — для наилучшего по умолчанию воспроизведения данных и портативного формата файла
• Локальная пакетная обработка: LanceDB — для идеального воспроизведения данных и быстрого их ввода
• Чистая сетевая нейронная сеть без фильтрации: FAISS — для безупречной задержки обработки
• Распределенная эксплуатация: Qdrant или Milvus — отдельная категория, которая здесь не тестировалась

Начало работы и резервное копирование

Два показателя, которые часто игнорируются в тестах. Время запуска — время воссоздания базы данных после перезагрузки: FAISS занимает 0,001 мс, LanceDB — 2 мс, Chroma — 5 мс, а VectLite — 3 059 мс. VectLite сильно теряет в скорости при повторном открытии. Это не имеет значения для процессов, работающих длительное время, но для безсерверных функций или инструментов командной строки, запускаемых по требованию, трехсекундное время запуска является серьезным недостатком и, скорее всего, первым элементом, который необходимо устранить.

Резервное копирование: VectLite генерирует портативный файл размером 19 МБ за 54 мс. Копирование, версионирование и развертывание — это просто обработка файлов. Именно это свойство, называемое «встраиваемым», позволяет решать практические задачи, и оно же помогло SQLite существовать в течение двух десятилетий.

Ограничения данного теста

Каждый тест-процесс требует учета определенных факторов. Здесь их пять:

1. Количество векторов в 5 000 считается небольшим; поведение системы меняется при количестве 100 000 и более.
2. Использовались только стандартные настройки; вероятно, параметры Chroma и VectLite можно настроить еще лучше.
3. В тесте не участвовали никакие серверные движки: Qdrant, Milvus, Weaviate и pgvector исключены.
4. Это один экземпляр теста без интервалов доверия и повторений.
5. Тест выполнялся на одном компьютере, поэтому другое оборудование может дать другие результаты.

Код является открытым, а результаты воспроизводимы, поэтому любая выявленная ошибка или предвзятость заслуживают отдельного рассмотрения.

Следующие шаги и выводы

Этот тест является лишь отправной точкой, а не окончательным вердиктом. Краткий список для следующего этапа: вектор длиной 100 тыс., тест в 768 измерениях для всех движков; тест в стиле RAG с использованием корпусов данных в формате Markdown и PDF, где запросы формулируют люди; настройка показателя воспроизведения, чтобы движки соревновались при сопоставимой точности; ускоренный запуск для VectLite; а также повторные тесты с интервалами доверия.

Поиск «лучшей базы данных векторов» не приводит к универсальному ответу, поскольку он зависит от того, как вы сбалансируете показатели воспроизведения данных, задержку, процесс вставки информации и время запуска. Особого внимания заслуживает не какой-то явный лидер, а то, что у каждого инструмента своя специфика. FAISS — это инструмент для высокой скорости, выдающий себя за базу данных. Chroma — это удобный инструмент для начинающих, требующий настройки перед использованием в производственных условиях. LanceDB — это перфекционист, который не против медленной работы. NumPy — беспристрастный судья, не способный к масштабированию. VectLite — это инструмент, который тихо достигает целевого уровня воспроизведения данных без каких-либо компромиссов.

Для локальных решений, инструментов командной строки или систем RAG, работающих офлайн на ноутбуке, VectLite представляет собой весомую альтернативу: SQLite сделал локальные реляционные базы данных скучными и неудобными в использовании, а VectLite стремится выполнять ту же функцию, но с использованием искусственного интеллекта. Это означает файл размером 19 МБ, который отвечает на запросы примерно за 6 мс.

Ссылки для справки: ANN-Benchmarks по адресу https://ann-benchmarks.com/, информация о тестах производительности Qdrant на https://qdrant.tech/benchmarks/, FAISS по адресу https://github.com/facebookresearch/faiss, документация Chroma по адресу https://docs.trychroma.com/ и LanceDB по адресу https://lancedb.github.io/lancedb/.