Пошук ембедингів легкий при 10K векторів. При 100M векторів із затримкою P99 менше 100 мс це проблема інфраструктури — і саме її вирішує цей шаблон.
Ваш RAG-конвеєр або система рекомендацій чудово працює в розробці з кількома тисячами векторів. Тепер у вас 50 мільйонів ембедингів, запити потребують затримки менше 100 мс, індекс постійно зростає, і ви споживаєте занадто багато пам'яті. Вам потрібна архітектура векторної бази даних, яка масштабується горизонтально, ефективно управляє пам'яттю (не все має знаходитися в RAM), обробляє паралельні записи під час індексації без погіршення продуктивності запитів і не коштує 10 тисяч доларів на місяць в інфраструктурі для того, що по суті є пошуковим індексом.
Explore more design patterns and system architectures
Наші архітектори можуть допомогти вам проектувати та будувати системи, використовуючи цей шаблон для ваших конкретних вимог.
Зв'яжіться з нами
Архітектура масштабованої векторної бази даних вирішує проблеми роботи векторного пошуку в промисловому масштабі: партиціонування індексу між вузлами (sharding), багаторівневе сховище (гарячі сегменти в пам'яті, теплі на SSD, холодні на S3), маршрутизація запитів із балансуванням навантаження та автомасштабування на основі навантаження запитів та розміру індексу. Шаблон охоплює топологію розгортання, планування потужності, ізоляцію запису/читання та оптимізацію витрат. Це інфраструктурний шар, який робить RAG-системи та системи рекомендацій життєздатними у великому масштабі.
Архітектура розгортає вузли векторної бази даних у кластерній топології з розділенням між вузлами запитів (шлях читання) та вузлами даних (шлях запису). Конвеєр індексації/завантаження обробляє генерацію ембедингів та пакетні upserts з буферизацією запису, щоб уникнути впливу на затримку запитів. Маршрутизатор запитів розподіляє пошуки між репліками для читання з паралелізмом на рівні шардів. Багаторівневе сховище переміщує рідкодоступні сегменти з пам'яті на SSD, а потім на S3, із прозорим завантаженням під час запиту. Автомасштабування регулює кількість реплік на основі QPS запитів та затримки P99.
| Рівень | Технології |
|---|---|
| Векторна база даних | Milvus (розподілена), Qdrant (однонодова/малий кластер), Pinecone (керована) |
| Бекенд сховища | MinIO / S3 (зберігання сегментів), SSD (теплий рівень), RAM (гарячий рівень) |
| Координація | etcd (метадані Milvus), Pulsar/Kafka (журнал попереднього запису) |
| Моделі ембедингів | OpenAI text-embedding-3-large, Cohere embed-v4, BGE-M3, E5-large-v2 |
| Інфраструктура | Kubernetes (EKS/GKE) з вузлами GPU для ембедингів, вузли, оптимізовані для пам'яті, для запитів |
| Моніторинг | Grafana + Milvus metrics exporter, кастомні дашборди P99/recall |
| Використовувати, коли | Уникати, коли |
|---|---|
| Кількість векторів перевищує 5 мільйонів і зростає, вимагаючи горизонтального масштабування | У вас менше 1 мільйона векторів — pgvector на вашому існуючому PostgreSQL достатньо |
| Затримка запиту P99 менше 100 мс є жорсткою вимогою | Затримка запиту 500 мс+ є прийнятною — працюють простіші варіанти |
| Кілька додатків/орендарів спільно використовують векторну інфраструктуру | Один додаток з однією колекцією — використовуйте керований сервіс |
| Оптимізація витрат вимагає багаторівневого сховища (не все в RAM) | Бюджет дозволяє повністю керовані сервіси, а цінова політика постачальника підходить для вашого масштабу |
MW розробляє інфраструктуру векторних баз даних з підходом "правильний розмір з першого дня, масштабування за мірою". Ми починаємо з планування потужності на основі кількості векторів, розмірності, типу індексу та цільової затримки — не припущення. Наші розгортання Milvus на Kubernetes включають дашборди Grafana, що відстежують кількість сегментів, використання пам'яті, перцентилі затримки запитів та оцінки точності пошуку. Ми впровадили автомасштабовані кластери Milvus, які обробляють 10-кратні піки трафіку в робочі години та зменшують масштаб вночі, зменшуючи витрати на інфраструктуру на 40-60% порівняно зі статичним виділенням ресурсів.
Надайте вашому LLM доступ до ваших даних без налаштування. RAG заповнює розрив між універсальними мовними моделями та знаннями, специфічними для домену.
MicrocosmWorks зазвичай рекомендує pgvector для проєктів з менш ніж 5-10 мільйонами векторів, де команда вже використовує PostgreSQL, оскільки це дозволяє уникнути впровадження нового компонента інфраструктури та підтримує гібридні SQL-плюс-векторні запити нативно. Понад 10 мільйонів векторів або коли потрібна p99 latency менше 50 мс при високій паралельності, спеціалізована векторна база даних, така як Qdrant, Weaviate або Milvus, забезпечує значно кращу продуктивність завдяки оптимізованим алгоритмам індексування та пошуку з прискоренням GPU. Ми допомагаємо клієнтам прийняти це рішення під час архітектурного огляду шляхом бенчмаркінгу їхніх фактичних шаблонів запитів та прогнозів зростання.
MicrocosmWorks розробляє кластери векторних баз даних зі стратегіями шардингу на основі хешування або метаданих, які розподіляють вектори між вузлами, зберігаючи семантично пов'язані дані спільно розміщеними для ефективного пошуку. Ми реалізуємо рівні маршрутизації запитів, які розподіляють пошукові запити на відповідні шарди та об'єднують результати за допомогою глобальної агрегації top-K, підтримуючи затримку менше 100 мс навіть по десятках шардів. Наші моніторингові дашборди відстежують баланс шардів, розподіл запитів та затримку реплікації, щоб запобігти гарячим точкам (hotspots) у міру масштабування вашого набору даних.
MicrocosmWorks застосовує скалярне квантування (зменшення float32 до int8) та продуктове квантування для стиснення векторного сховища в 4-8 разів зі типовим зниженням recall менше ніж на 2%, що ми перевіряємо за допомогою A/B тестування на вашому фактичному query workload перед розгортанням у production. Ми також впроваджуємо двохетапний підхід до retrieval, де quantized vectors слугують для початкового candidate retrieval, а full-precision vectors використовуються лише для фінального re-ranking найкращих результатів. Ця hybrid strategy дозволяє клієнтам зберігати сотні мільйонів векторів за незначну частину вартості, зберігаючи search quality, невідмінну від uncompressed operation.
MicrocosmWorks розгортає векторні бази даних у конфігураціях з множинними репліками із синхронною реплікацією для стійкості запису та репліками для читання, розподіленими по зонах доступності для відмовостійкості та балансування навантаження. Ми налаштовуємо автоматичне перемикання після відмови (failover) із вибором лідера, що ґрунтується на перевірках стану (health-check-driven leader election), щоб збій вузла призводив до менш ніж 10 секунд недоступності для читання та нульової втрати даних. Наші шаблони infrastructure-as-code включають попередньо налаштовані графіки резервного копіювання, відновлення до заданого моменту часу (point-in-time recovery) та посібники з аварійного відновлення (disaster recovery runbooks), адаптовані для кожного рушія векторної бази даних.
MicrocosmWorks розробляє архітектуру розгортань векторних баз даних з кількома колекціями, де кожен застосунок або модель вбудовування отримує власну ізольовану колекцію з відповідними конфігураціями індексів, одночасно спільно використовуючи базову інфраструктуру кластера для ефективності витрат. Ми впроваджуємо уніфікований шлюз запитів, який маршрутизує запити до правильної колекції на основі контексту застосунку та застосовує попереднє оброблення для конкретної колекції, як-от вбудовування запитів за допомогою відповідної моделі. Цей підхід багатоорендної векторної бази даних зазвичай зменшує витрати на інфраструктуру на 40-60% порівняно з використанням окремих кластерів для кожного застосунку.