Выбор векторной базы данных для RAG: сравнение восьми вариантов

Выбор векторной базы данных для технологии RAG сводится к нескольким важным вопросам: размер данных, возможности фильтрации, способы хранения и объем операций, которые может обработать ваша команда. Вот краткий обзор перед вступлением в детали. Chroma и pgvector подходят для небольших проектов. Qdrant и Milvus — стандартный выбор для самостоятельной развертки в производственных условиях. Pinecone представляет собой полностью управляемый вариант. Если в вашей инфраструктуре уже используется Postgres, pgvector не требует дополнительных затрат, а если вам нужна локальная установка, готовая к работе за несколько минут, Chroma можно установить с помощью одной команды pip.

Системы с открытым исходным кодом, такие как Qdrant, Milvus и Weaviate, соперничают с платными платформами по показателям воспроизведения данных и задержки, причем каждая из них предлагает бесплатный вариант самостоятельной развертки наряду с опцией платных облачных решений. Ещё один важный показатель: сочетание технологии плотного поиска векторов с разреженным поиском по ключевым словам с алгоритмом BM25 позволило повысить показатель Recall@10 с примерно 78% до примерно 91% в реальных тестах, поэтому гибридный поиск присутствует во многих из перечисленных ниже вариантов.

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

Что на самом деле делает векторная база данных

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

Есть один недостаток. Поиск k ближайших соседей с точностью требует O(N·d) вычислений на каждый запрос, что становится неэффективным при количестве векторов, превышающем несколько сотен тысяч. Базы данных векторов преодолевают эту проблему, идя на небольшую потерю в точности возврата результатов в обмен на приблизительные индексы ближайших соседей, которые отвечают примерно за логарифмическое время.

Что измерять перед выбором

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

Качество поиска и задержка. Показатель Recall@K показывает, с какой частотой система находит действительно лучшие результаты среди своих топ-K результатов. Высокий уровень воспроизведения означает, что модель получает наилучшую доступную информацию. Задержка, измеряемая в миллисекундах, также имеет большое значение; инженеры обращают внимание на показатели p95 или p99, поскольку они отражают худшие сценарии работы системы для пользователей.

Фильтрация метаданных. Часто необходимо сузить диапазон поиска с помощью структурированных атрибутов. Поиск по запросу «корпоративная политика» может требовать отбора только документов, созданных после определенной даты или относящихся к определенному отделу. Эффективная фильтрация помогает исключить из результатов нерелевантные или несанкционированные записи. Базы данных с предварительной фильтрацией, как правило, лучше, поскольку они удаляют нежелательные записи до начала векторного поиска, тем самым обеспечивая большую точность результатов.

Соответствие экосистеме. База данных становится более полезной, когда хорошо взаимодействует с остальными компонентами стека ИИ. Коннекторы для LangChain и LlamaIndex сокращают время на создание рабочей пайплайны RAG. Клиентские библиотеки на нескольких языках и поддержка AWS, GCP и других облачных платформ определяют степень гладкой интеграции существующего корпоративного программного обеспечения.

Готовность к эксплуатации. Этот аспект касается способности системы функционировать в сложных производственных условиях:

• Масштабируемость, то есть возможность обработки миллиардов векторов и высокой нагрузки запросов.
• Изоляция пользователей в приложениях с множественными арендаторами.
• Соответствие стандартам, таким как SOC 2, HIPAA и GDPR.
• Возможность мониторинга, что позволяет отслеживать производительность поиска и использование ресурсов.

Бесплатные и open-source варианты

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

Chroma

Chroma — это база данных для встраивания, созданная для ускорения работы разработчиков. Это самый короткий путь от пустого репозитория до рабочего прототипа RAG, и многие используют её в качестве своего первого векторного хранилища. Она подходит для хакатонов, локальной разработки и быстрых экспериментов, где важнее простота, чем распределённая масштабируемость.

Что она предлагает: небольшой Python-API, который позволяет переходить от временных локальных тестов к постоянному клиент-серверному режиму, локальное хранилище на основе SQLite, что исключает необходимость настройки отдельного сервера базы данных, а также встроенные функции встраивания, преобразующие необработанный текст в векторы при вставке с использованием стандартных параметров, таких как all-MiniLM-L6-v2. Она поддерживает интеграцию с LangChain, LlamaIndex, OpenAI и Hugging Face.

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

Основная база данных доступна бесплатно по лицензии Apache 2.0, а также существует версия в облаке для масштабирования в производственных условиях.

Milvus

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

Его архитектура разделяет узлы данных, узлы запросов и узлы индексов. Он поддерживает множество типов индексов, включая HNSW, IVF и DiskANN, что позволяет настраивать работу под конкретное оборудование; кроме того, он обеспечивает мощную индексацию и поиск с использованием ускорения GPU. Узлы можно добавлять или удалять в реальном времени без простоев.

Преимущества: наборы данных в миллиарды записей работают предсказуемо без резких скачков задержки p99; строгая изоляция узлов позволяет направлять вычисления именно туда, где это необходимо для выполнения задач; к тому же существует крупное сообщество разработчиков с обширной документацией и плагинами. Недостатки: развертывание, настройка и эксплуатация системы на базе Kubernetes требуют значительных инженерных усилий, а для простого приложения типа RAG дополнительные компоненты, такие как etcd и Kafka, представляют собой ненужную нагрузку.

Этот движок распространяется бесплатно по лицензии Apache 2.0. Компания Zilliz, создавшая его, предлагает услуги управляемого хостинга по цене от 155 долларов в месяц.

Qdrant

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

В основе лежит движок хранения на Rust под названием Gridstore, оптимизированный для работы с векторными данными. Благодаря модульной архитектуре поиска один запрос может включать плотные векторы, разреженные векторы и фильтры метаданных. Фильтрация применяется непосредственно во время обхода графа с использованием алгоритма HNSW, что позволяет избежать снижения точности результатов, возникающего при фильтрации после поиска. Также существует Qdrant Edge — легковесная встроенная версия для мобильных устройств и робототехники.

Типичная задержка p50 составляет примерно 4–5 мс, фильтрация остается точной даже при строгих ограничениях, а лицензия (Apache 2.0) является лицензией с открытыми условиями. Недостатки: участие в разработке ядра Rust подразумевает более крутой кривой обучения, а для достижения оптимальной работы алгоритма HNSW требуется тщательная настройка памяти и индексов.

Распространение под лицензией с открытым исходным кодом бесплатно. Qdrant Cloud предлагает бесплатный управляемый уровень с 1 ГБ хранилища, а также платные кластеры, работающие по модели оплаты за использование.

Weaviate

Weaviate — это open-source база данных, ориентированная на ИИ и построенная на основе графообразных объектов; она объединяет несколько стилей поиска и типов данных в единый интерфейс запросов. Она подходит, когда требуется зрелый гибридный поиск, сложные связи между объектами и встроенный в базу данных ИИ-процесс.

Он нативно сочетает в себе методы высокой степени сходства и ранжирования ключевых слов по алгоритму BM25. Модули векторизации подключаются к сервисам OpenAI, Cohere и Hugging Face для автоматического преобразования текста в векторы. Данные хранятся в схеме, основанной на классах и ориентированной на отображение взаимосвязей, причем предусмотрена изоляция данных для нескольких пользователей и их репликация.

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

Программное обеспечение предоставляется бесплатно по лицензии BSD-3. Weaviate Cloud предлагает облачные планы без необходимости управления серверами по цене от 45 долларов в месяц.

pgvector для PostgreSQL

Расширение pgvector превращает PostgreSQL в мощный хранилище векторов, позволяя хранить эмбеддинги рядом с обычными транзакционными данными. Это идеальный выбор для команд, уже использующих Postgres, которые не хотят создавать дополнительную базу данных.

Оно добавляет встроенный тип столбца для векторов в стандартные схемы SQL, поддерживает косинусное сходство, расстояние L2 и скалярный произведение, создает индексы HNSW и IVFFlat, а также выполняет запросы на поиск сходства в рамках стандартных транзакций ACID.

Огромное преимущество заключается в отсутствии операционных затрат, проверок безопасности и необходимости обслуживания отдельной системы. Существующие инструменты мониторинга, резервного копирования и репликации Postgres остаются в силе, а фильтрация метаданных представляет собой просто знакомое условие WHERE вместе с функцией расстояния. Недостатки — более высокое потребление памяти и худшая масштабируемость по сравнению с движками, разработанными исключительно для векторов, а также заметное увеличение задержек после достижения примерно 50 миллионов векторов, если не использовать такие инструменты, как pgvectorscale.

Это расширение бесплатное и имеет открытый исходный код. Расходы зависят от способа хостинга Postgres.

Платные и управляемые варианты

Управляемые базы данных обеспечивают минимальные затраты на обслуживание, позволяя команде сосредоточиться на приложении, а не на серверах.

Pinecone

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

Он работает исключительно в формате облачного SaaS, разделяет слои чтения, записи и хранения, что позволяет каждому из них масштабироваться независимо, предоставляет возможность запуска моделей для встраивания и переранжирования через Pinecone Inference, а также поддерживает плотные и разреженные векторы, а также эффективную фильтрацию метаданных. Взамен пользователь не сталкивается с проблемами инфраструктуры, не нуждается в установке обновлений или пересоздании индексов, имеет широкую совместимость с различными фреймворками и облачными сервисами, а также высокую доступность с предсказуемой производительностью при высокой нагрузке.

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

Цены как указано: бесплатный уровень Starter (2 ГБ, 1 млн операций чтения, только AWS us-east-1); уровень Standard с минимальной ежемесячной оплатой в $50 по цене $0,33 за ГБ в месяц, плюс примерно $4–$4,50 за миллион операций записи и $16–$18 за миллион операций чтения; уровень Enterprise с минимальной ежемесячной оплатой в $500; а также дополнение HIPAA по цене $190 в месяц.

Turbopuffer

Turbopuffer — это безсерверный поисковый движок, созданный непосредственно на облачном хранилище объектов, причем ключевой особенностью является экономичность. Он является лучшим вариантом для многоклиентских SaaS-решений и продуктов ИИ с огромным количеством пространств имен, где необходимо контролировать расходы.

Он обходит традиционные диски и выполняет поиск непосредственно в системах хранения объектов, обрабатывает миллиарды векторов без ограничений по пространствам имён, использует индекс SPFresh, отрегулированный для поиска, и позволяет сразу видеть результаты записей. Расходы на хранение и запросы существенно ниже, чем у более старых управляемых сервисов; избегаются ценовые ловушки, связанные с оплатой за каждый под, которые наказывают архитектуры с несколькими арендаторами, а стандартные планы включают соответствие стандартам SOC 2 и HIPAA.

С другой стороны, это закрытый исходный код с меньшим опытом использования по сравнению с устоявшимися конкурентами, а его экосистема плагинов и интеграций менее развита. Оплата осуществляется исключительно в зависимости от объёма использования, при этом на стандартных планах установлен минимальный платеж в 64 доллара в месяц, а для крупных пространств имён предусмотрены скидки за большой объём запросов.

TiDB Vector Search

Система векторного поиска TiDB от PingCAP сочетает в себе распределенную SQL-базу данных с собственным движком эмбеддингов, что позволяет обрабатывать крупные транзакционные нагрузки и выполнять семантический поиск в одной системе с возможностью масштабирования. Это особенно удобно, когда требуется высокий горизонтальный масштаб наряду с сложной фильтрацией по SQL-запросам и векторным поиском в одних и тех же данных.

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

Для легкой системы RAG, основанной исключительно на векторах, это чрезмерно, а полная настройка производительности требует глубокого понимания распределенных SQL-запросов.

В пакете TiDB Cloud Starter бесплатный тариф является самым щедрым в своей категории: 5 ГБ для хранения строк, 5 ГБ для хранения столбцов и 50 млн единиц запросов на кластер, причем организация может иметь до 5 кластеров. В сумме это даёт 25 ГБ для хранения строк, 25 ГБ для хранения столбцов и 250 млн единиц запросов в месяц бесплатно. При превышении этих лимитов стоимость составляет 0,10 доллара за миллион единиц запросов и 0,20 доллара за ГБ-месяц для хранения строк в регионе us-east.

Где векторные системы RAG уступают

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

• Потеря контекста. Стандартные векторные системы RAG разбивают документы на небольшие фрагменты, чтобы они вмещались в окна контекста. Этот механический процесс уничтожает структуру сложных документов, и небольшой фрагмент легко теряет связь с заголовками или разделами, которые придавали ему смысл.
• Неточность. Поиск основан на близости в векторном пространстве, поэтому похожие термины или названия продуктов с схожей формулировкой путаются. В запрос попадают неверные факты, что приводит к галлюцинациям.
• Дорогостоящие обновления. Переход на более совершенную модель вкладки означает необходимость повторной обработки всего корпуса данных и создания крупных индексов с нуля, что увеличивает расходы на вычисления и другие затраты.

Graph RAG — один из вариантов. Он представляет точки данных в виде узлов, а связи — в виде рёбер, причём инструменты вроде Writer Knowledge Graph поддерживают явные связи между документами. Это обеспечивает многократное рассуждение, снижает вероятность галлюцинаций и позволяет команде обновлять один факт, не переобрабатывая всё заново.

Практический способ принятия решения

Начните с того, что уже используется. В Postgres с примерно 10 млн векторов pgvector справляется с задачей без дополнительных зависимостей, а pgvectorscale расширяет его возможности до 50 млн и более. В MongoDB используйте Atlas Vector Search. В Elastic или OpenSearch можно оставаться на прежнем решении, поскольку OpenSearch 3.0 уже устранил большинство недостатков. В Redis используйте встроенную поддержку векторов в Redis 8 с параметром FT.HYBRID.

Если начинать с нуля, учитывайте три фактора:

1. Масштабируемость и производительность. Создание прототипов с менее чем 1 миллионом векторных точек подходит для Chroma. Самостоятельная развертка в производственных условиях с высокой производительностью фильтрации предпочтительна с использованием Qdrant. Работа с миллиардами данных или с использованием ускорения GPU подходит для Milvus. Управляемые решения для производственных задач с требованиями к соответствию стандартам лучше всего реализовываются с помощью Pinecone или Weaviate Cloud.
2. Структура затрат. При интенсивном использовании ресурсов несколькими арендаторами, когда большинство из них находятся в неактивном состоянии, Turbopuffer позволяет сократить затраты в 10–100 раз, хотя выполнение запросов к «холодным» данным занимает около 500 мс. Для систем, чувствительных к затратам, с более чем 50 миллионами векторов и предсказуемой нагрузкой подходит комбинация pgvector и pgvectorscale.
3. Требования к логике обработки. При задачах с несколькими этапами обработки, требующих объяснимости результатов или наличия реляционной структуры, необходимо использовать графовую сеть знаний, такую как Neo4j, Memgraph или FalkorDB, и применять технологию Graph RAG вместе с векторами, а не вместо них.

Часто задаваемые вопросы

Как создать векторную базу данных для RAG? Разделите документы на фрагменты, сгенерируйте эмбеддинги с помощью такой модели, как OpenAI или BGE, затем сохраните и индексируйте эти векторы в таких системах, как Qdrant, Milvus или pgvector. Для полностью локальной настройки можно использовать Chroma или FAISS, запущенные на одном компьютере без участия облака.

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

Какую базу данных следует использовать? Это зависит от масштаба и технологической стека. Chroma и pgvector — лучшие бесплатные варианты для небольших и средних проектов; Qdrant и Milvus предпочтительны для самостоятельно развернутых производственных систем; Pinecone — лучший вариант с обслуживанием, если не хочется заниматься техническим управлением.

Как используются векторы в этой системе? Модель эмбеддингов преобразует фрагменты текста в высокомерные векторы. База данных хранит их, и при поступлении вопроса она находит векторы, наиболее близкие к вектору запроса, с помощью поиска по аннотированной сети, и передает эти фрагменты в запрос.

Необходима ли всегда векторная база данных? Нет, хотя она по-прежнему является стандартом в индустрии. Системы без векторов, такие как PageIndex, полностью игнорируют эмбеддинги. Они преобразуют документы в иерархические деревья и позволяют большим языковым моделям анализировать структуру содержания для поиска ответов. Многие корпоративные команды также используют графовые базы данных для технологии GraphRAG, получая контекст через явные связи вместо пространственного сходства.

Каковы семь типов RAG? Наивный RAG (простое извлечение данных затем генерация текста), извлечение и переранжирование (стандартный подход в производстве), гибридный RAG (одновременное использование плотного и разреженного поиска), мультимодальный RAG (текст, изображения и аудио в одной обработке), Graph RAG (проход по графу знаний для реляционных запросов), агентный RAG (агент на основе LLM выбирает наилучшую стратегию извлечения данных для каждого запроса) и HyDE RAG (модель сначала составляет гипотетический ответ, затем ищет соответствующие данные на его основе).