Порівняли 4 vector DB для RAG-пайплайну: latency, ціна, точність retrieval

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Побудова RAG-пайплайну практично завжди починається з питання про модель і промпти, а закінчується питанням, яке спочатку здається другорядним: «Яку векторну базу обрати?». За останній рік я встиг попрацювати з чотирма популярними рішеннями — Pinecone, Weaviate, Qdrant і Milvus, і в кожному випадку виявлялося, що маркетингові порівняння на сайтах постачальників мають дуже мало спільного з тим, що насправді відбувається на реальному навантаженні. Пройшовши такий досвід, я з впевненістю можу сказати: вибір векторної бази — це не технічне питання, а питання пріоритетів команди, і з цієї причини універсальної відповіді «яка база найкраща» не існує в принципі.

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

З Weaviate в мене склалися неоднозначні стосунки. Гібридний пошук, що поєднує vector search і BM25, дійсно рятує на специфічних запитах, де семантичний пошук губиться в термінології. Але я вважаю, що ця гнучкість має ціну — вона потребує людини, яка розуміється на тонкощах налаштування, а не просто «підключив і працює». Якщо в команді немає окремого спеціаліста, готового постійно тюнити ці параметри, гнучкість перетворюється на джерело прихованих проблем, а не перевагу.

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

Milvus — це, мабуть, найбільший урок про те, як легко переоцінити майбутній масштаб проєкту. Архітектура, розрахована на мільйони й десятки мільйонів векторів, з розподіленими компонентами на кшталт etcd і Pulsar, виглядає солідно на папері, але для середнього проєкту вона перетворюється на операційний тягар без відповідної вигоди. Я багато разів бачив, як команди обирають рішення «на виріст», ще не маючи навіть близько того обсягу даних, який виправдав би таку складність, і потім роками платять інженерним часом за рішення, прийняте під впливом амбіцій, а не реальних потреб.

Головний висновок стосується не технологій, а мислення команди. Managed-рішення на кшталт Pinecone підходять тим, хто цінує швидкість запуску і готовий платити за спокій. Гнучкі рішення на кшталт Weaviate виправдані лише там, де є ресурс постійно їх підтримувати. Qdrant особисто мені здається найбалансованішим варіантом для більшості проєктів середнього масштабу. А Milvus варто розглядати лише тоді, коли масштаб даних — це не мрія про майбутнє, а вже наявна реальність.