Вибір векторної бази даних для 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.
• Можливість моніторингу, щоб контролювати продуктивність пошуку та використання ресурсів.

Безкоштовні та відкриті варіанти

Безкоштовні двигуни дозволяють вам керувати власною інфраструктурою та уникати постійних платежів за підписку. Наведені нижче двигуни відсортовані приблизно від найлегших до найважчих.

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 — це база даних з відкритим кодом, створена спеціально для ШІ, яка організована навколо об’єктів у форматі графів та поєднує кілька стилів пошуку та типів даних у єдиний інтерфейс запитів. Вона ідеально підходить, коли потрібен розвинений гібридний пошук, складні зв’язки між об’єктами та робочий процес ШІ, вбудований у базу даних.

Він природним чином поєднує в собі високу ступінь схожості та ранжування ключових слів за алгоритмом 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

PingCAP TiDB Vector Search поєднує розподілену 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. Структура витрат. Для ситуацій із інтенсивним використанням ресурсів кількома користувачами, коли більшість з них не активні, економія від 10 до 100 разів від Turbopuffer є реальною, хоча час виконання запитів із низькою активністю становить близько 500 мс. Для систем, чутливих до витрат, із понад 50 мільйонами векторів та прогнозованим навантаженням підходить поєднання pgvector та pgvectorscale.
3. Вимоги до логіки обробки. Для запитів із кількома етапами обробки, потреби у пояснюваності або наявності відносних структур слід додати граф знань, такий як Neo4j, Memgraph чи FalkorDB, та використовувати Graph RAG разом із векторами, а не замість них.

Поширені запитання

Як створити базу даних векторів для RAG? Розділіть документи на частини, створіть ембеддинги за допомогою моделі, такої як OpenAI чи BGE, а потім збережіть та індексуйте ці вектори у сервісах на кшталт Qdrant, Milvus чи pgvector. Для повністю локальної налаштування можна використовувати Chroma чи FAISS, які працюють на одному пристрої без участі хмари.

Яку роль вона відіграє? Це двигун пошуку, який знаходиться між вашими документами та моделлю LLM. Він зберігає ембеддинги, а під час запиту повертає найбільш релевантні частини документів, щоб модель могла відповідати, спираючись на конкретний контекст, а не лише на пам’ять.

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

Як вектори використовуються в цьому процесі? Модель ембеддингів перетворює фрагменти тексту на високорозмірні вектори. База даних зберігає їх, і коли надходить запит, вона знаходить найближчі вектори до запитуваного вектора за допомогою пошуку ANN та передає ці фрагменти у запрошення до моделі.

Чи завжди потрібна база даних векторів? Ні, хоча вона залишається стандартом у галузі. Системи без векторів, такі як PageIndex, повністю уникають ембеддингів. Вони перетворюють документи на ієрархічні дерева та дозволяють ШІ аналізувати зміст за допомогою змістового огляду для пошуку відповідей. Багато корпоративних команд також використовують графові бази даних для GraphRAG, отримуючи контекст через прямі зв’язки замість просторової схожості.

Які існують сім типів RAG? Naive RAG (просте отримання даних, потім генерація), retrieve-and-rerank (стандартний підхід у продакшені), hybrid RAG (одночасний щільний та розріджений пошук), multimodal RAG (текст, зображення та аудіо в одному потоці обробки), Graph RAG (перебір знань у графі для реляційних запитів), agentic RAG (агент LLM обирає найкращу стратегію пошуку для кожного запиту) та HyDE RAG (модель спочатку складає гіпотетичну відповідь, а потім шукає інформацію на її основі).