Pinecone, Weaviate, Milvus, Qdrant чи Chroma: як обрати векторну базу даних

Усі векторні бази даних обіцяють швидкість, масштаб і розумний пошук, а рекламні тексти вендорів рясніють схожими фразами. Абстрактного переможця тут немає. Правильний вибір залежить від обсягу даних вашої команди, від того, скільки інфраструктури ви готові доглядати, і від того, що має вміти ваш пошук. Нижче розібрано Pinecone, Weaviate, Milvus, Qdrant і Chroma: кожен маркетинговий термін перекладено простою мовою, і для кожної бази зазначено, де вона справді виправдовує себе.

Pinecone: нічого не треба адмініструвати

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

Керований і serverless. Не треба орендувати й налаштовувати віртуальні машини, не треба думати про шарди, репліки, налаштування пам'яті чи кількість вузлів у міру зростання даних. Ви створюєте акаунт, берете API-ключ і починаєте надсилати дані. Це цінно, бо векторний пошук жадібно їсть CPU і пам'ять, а самостійно підтримувати таку систему, як відомо, дуже клопітно. Serverless означає, що оплата йде за реально використане сховище й запити, а Pinecone сам масштабує бекенд угору й униз.

Нативний гібридний пошук. Тут поєднано два зовсім різні підходи:

• Щільний пошук — семантичний. Моделі перетворюють текст на ембеддинги, які вловлюють поняття, тому запит «котячі» знаходить документи зі словом «кіт».
• Розріджений пошук — це зіставлення ключових слів у традиції BM25. Він шукає точні рядки: серійні номери, коди помилок або ідентифікатори товарів на кшталт SKU-8492X.

У кожного є сліпа пляма. Щільний пошук розуміє намір, але безнадійний у точності. Він може вважати SKU-8492X близьким сусідом SKU-8492Y, і точний пошук зламається. Розріджений пошук безпомилково знаходить точні токени, але нічого не знає про контекст. Pinecone зберігає обидва типи векторів в одному індексі й автоматично об'єднує їхні оцінки.

Чому важливі нульові накладні витрати. Якщо ви розробник, який випускає ШІ-функцію, вам краще займатися логікою застосунку та користувацьким досвідом, ніж гратися в адміністратора бази, крутити параметри чи прокидатися о третій ночі, бо в бази закінчилася RAM.

Підступ. Прив'язка до вендора й вартість на екстремальних обсягах. Pinecone — закритий і лише керований сервіс, розгорнути його в себе не можна. За мільярдів запитів із високим навантаженням рахунок за SaaS може перевищити вартість самостійного запуску open-source системи.

Weaviate: ембеддинги й гібридний пошук в одній коробці

Обирайте її, якщо потрібен пошук за ключовими словами й семантичний пошук в одній системі.

Вбудована векторизація. Weaviate бере ембеддинги на себе. Вам не потрібно писати код, який надсилає текст до OpenAI, Cohere чи Hugging Face, збирає вектори й зберігає їх самостійно. Ви передаєте сирий текст, а модулі на кшталт text2vec-openai або text2vec-transformers створюють і оновлюють вектори за лаштунками. Один раз налаштуйте схему з потрібним провайдером моделей, і конвеєр ембеддингів працюватиме під час завантаження даних і знову під час запиту, що помітно спрощує архітектуру.

BM25 плюс вектори, нативно. Рушій одночасно виконує точний алгоритм пошуку за ключовими словами й семантичний пошук в одному шарі зберігання, а потім зводить усе в єдиний ранжований список.

• Під час пошуку за ключовими словами артикул ABC-123 не переплутається з ABC-124, бо BM25 зіставляє точні токени.
• Під час векторного пошуку запит «проблеми зі сном» знаходить документи про безсоння, бо зміст розуміється.

Для кожного об'єкта будуються інвертований індекс для ключових слів і векторний індекс для змісту. Параметр alpha, наприклад alpha: 0.5, зсуває баланс між буквальними ключовими словами й абстрактним змістом.

Чому важлива одна система. Доки нативна гібридна підтримка не дозріла, команди тримали Elasticsearch для ключових слів поруч з окремим векторним сховищем, синхронізували дані між ними й писали власний код для об'єднання оцінок. Weaviate знімає це операційне навантаження, бо є обома рушіями одночасно.

Чим відрізняється від Pinecone. Розгортанням. Pinecone — лише закритий SaaS. Weaviate — open source і cloud-native: її можна використовувати як керований сервіс (Weaviate Cloud Services), усередині власного VPC в AWS чи GCP або повністю on-premises із Docker чи Kubernetes. Такий контроль над тим, де живуть дані, важить дуже багато для корпоративної безпеки й відповідності вимогам.

Milvus: створений для величезного масштабу

Обирайте його, якщо будуєте платформи корпоративного рівня з мільярдами векторів. Якщо Pinecone — про простоту, а Weaviate — про зручність розробника, то Milvus — про грубий інфраструктурний масштаб і чисту продуктивність.

Розподілений і горизонтально масштабований. Це не один моноліт, а набір мікросервісів без стану, поділених на шари:

• Вузли запитів читають і шукають
• Вузли даних записують і приймають дані
• Вузли індексів будують пошукові графи

Така архітектура дає дві переваги. Ви масштабуєтеся вшир, додаючи дешевші машини, а не переходячи на одну велику й дорогу. І частини масштабуються незалежно, тож продукт з акцентом на читання, наприклад рекомендаційний рушій із мільйонами користувачів, може додати лише вузли запитів і не чіпати потужності завантаження, зберігаючи розумні витрати.

Прискорення на GPU. Обчислення відстаней між мільярдами багатовимірних векторів виснажує CPU. Milvus під'єднує бібліотеки прискорення (NVIDIA RAPIDS, FAISS-GPU і графові індекси на кшталт CAGRA), щоб передати цю роботу GPU, які виконують тисячі матричних операцій паралельно. У результаті затримка лишається нижчою за мілісекунду на наборах із десятків мільярдів ембеддингів, а вузьке місце зміщується зі швидкості обчислень на пропускну здатність пам'яті.

Чому вся справа в масштабі. Аматорському проєкту з кількома тисячами документів це ні до чого. Milvus орієнтований на платформи, що керують мільярдами векторів і терабайтами даних. За такого обсягу менші бази задихаються, намагаючись тримати все в RAM. Milvus використовує багаторівневе зберігання: гарячі дані лежать у RAM або на SSD, холодні — в об'єктному сховищі на кшталт S3 чи MinIO. Він також застосовує квантизацію векторів, наприклад 1-бітне стиснення RaBitQ, щоб скоротити потребу в пам'яті до 70%. Крім того, ви отримуєте глибокий контроль над стратегіями індексації (HNSW, IVF-Flat, DiskANN), і інфраструктурні команди можуть налаштовувати компроміс між швидкістю та повнотою.

Підступ. Складність. Це сильно розподілена система на Kubernetes, що залежить від Etcd, S3 і Pulsar або Kafka, тож розгортання, моніторинг і супровід вимагають серйозних зусиль DevOps.

Qdrant: контроль над точністю й швидкістю

Обирайте його, коли важливий контроль над ранжуванням і затримкою. Він помітно закріпився в продакшені завдяки акценту на ефективності й точному контролі, тоді як Pinecone робить ставку на простоту, Weaviate — на зручність, а Milvus — на величезні кластери.

Написаний на Rust. Qdrant створено з нуля системною мовою, відомою безпечною роботою з пам'яттю, швидкістю й відсутністю збирача сміття. Це важливо, бо бази на Java чи Go періодично зупиняються, щоб звільнити пам'ять, і під високим навантаженням ці паузи перетворюються на раптові сплески затримки — сумнозвісну проблему p99. Без збирача Qdrant дає стабільний, передбачуваний час відповіді в субмілісекундному діапазоні навіть за великого конкурентного навантаження і часто витрачає менше RAM і CPU, ніж конкуренти.

Щільні, розріджені вектори й метадані разом. Підтримка кількох векторів вбудована. Кожна збережена точка може містити:

• Щільний вектор для семантичного контексту
• Розріджений вектор для точних ключових слів
• Структурований JSON-payload із метаданими, наприклад userId, creationDate або status

Багато векторних баз фільтрують за метаданими (скажімо, лише документи, де status == active) або після векторного пошуку, що спотворює результати, або до нього, що сповільнює запит. Qdrant будує структурні індекси безпосередньо за payload, тож зіставлення ключових слів, семантична оцінка й фільтрація відбуваються одночасно під час обходу векторного графа.

Важелі, які інші системи ховають. Вирізняються три:

• Власна оцінка з нативним Reciprocal Rank Fusion (RRF), щоб ви самі вирішували, як саме поєднуються оцінки ключових слів і векторів.
• Налаштування квантизації: налаштуйте Scalar Quantization (SQ) або Product Quantization (PQ), щоб пожертвувати невеликою точністю заради приблизно вчетверо меншої витрати RAM і швидших запитів.
• Де він працює: як один невеликий бінарник, як розподілений кластер або як хмарний сервіс.

Chroma: найшвидший шлях до прототипу

Обирайте її для локальних RAG-прототипів і експериментів. Якщо Milvus і Pinecone орієнтовані на мільярди об'єктів у хмарі, то Chroma повністю зосереджена на досвіді розробника без тертя.

Вбудовувана. Вона працює в тому самому процесі, тож це не важкий фоновий сервіс на кшталт MySQL чи Docker-контейнера. Вона живе всередині вашого Python-скрипта або Jupyter-ноутбука. Отже, жодних рядків підключення, користувачів бази, файрволів чи хмарних інстансів. Почати справді настільки просто:

import chromadb
# Start a local, persistent database on your hard drive
client = chromadb.PersistentClient(path="./my_local_db")
collection = client.get_or_create_collection("my_docs")
# Add raw text - Chroma handles the embedding automatically
collection.add(
    documents=[
        "Retrieval-Augmented Generation relies on good context.",
        "Chroma runs in-process."
    ],
    ids=["id1", "id2"]
)

Запускайте її в ефемерному режимі, повністю в RAM, коли дані зникають після завершення скрипта, або вкажіть теку, щоб зберігати дані на диск.

Чому вона підходить для прототипів. З двох причин. По-перше, у ній є вбудовані функції ембеддингів, за замовчуванням — легка локальна модель all-MiniLM-L6-v2. Зазвичай ви викликаєте API ембеддингів, чекаєте на вектори й зіставляєте їх самі, а тут ви віддаєте сирий текст, і Chroma робить решту. По-друге, чудова підтримка інструментами. Відкрийте майже будь-який туторіал з LangChain чи LlamaIndex, і сховищем там виявиться Chroma, тож скопійований приклад RAG-конвеєра, найімовірніше, уже її використовує.

Вона подорослішала. Chroma більше не просто інструмент для прототипів. Тепер у ній є мультимодальний пошук, гібридний пошук (щільний плюс BM25) і клієнт-серверний режим (chroma run) для більших багатокористувацьких сценаріїв.

Її межа. Масштаб і висока доступність. Для критичної для бізнесу системи з мільярдами векторів, жорсткими цілями щодо затримки на 99-му перцентилі й автоматичним перемиканням між регіонами локальна файлова архітектура не підійде. Якщо ж мета — перевірити RAG-ідею на кількох тисячах чи мільйонах документів на власній машині, швидше стартувати не вийде.

Вердикт

Найкращої бази даних узагалі не існує, є найкраща для вашого поточного етапу. Поширений шлях — прототип на Chroma і перехід на Qdrant, Weaviate, Milvus або Pinecone, коли знадобиться надійність продакшен-рівня.