Досвід створення RAG-систем на базі Milvus

Досвід створення RAG-систем на базі Milvus

Напрямки AI-розробки

Часті запитання

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1440
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1301
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    997
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1264
  • image_logo-advance_0.webp
    Розробка логотипу компанії B2B Advance
    712
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    1002

Досвід створення RAG-систем на базі Milvus

Коли розробка RAG з Milvus стає необхідністю

Реляційні бази з косинусною відстанню пасують при обсягах > 100K векторів. Ми зіткнулися з цим у фінтех-проекті: 2.5M чанків документації, 6 мов, вимога latency P99 < 500 мс. Вибір припав на Milvus — open-source векторну БД з HNSW-індексами та GPU-прискоренням. Розкажемо, як ми налаштовували гібридний пошук (dense + sparse) у production.

Типова проблема — «фантомні» релевантні результати: модель повертає схожі за змістом, але не за контекстом. Ми вирішили це через hybrid search з RRF-ранжуванням (Reciprocal Rank Fusion). Наш досвід показує, що правильна конфігурація індексів знижує latency на 40%.

Налаштування RAG Milvus для production

Масштаб: 2.5M чанків — не межа. Milvus легко масштабується горизонтально: ми розгортали кластери до 10 нод з підтримкою мільярдів векторів. Важливо правильно вибрати індекс: для нашого клієнта використовували HNSW (M=32, efConstruction=400) для dense i SPARSE_INVERTED_INDEX для sparse. HNSW забезпечує пошук у 1.5 рази швидше, ніж IVF_SQ8 при тому ж recall.

Гібридний пошук: dense vs sparse. Dense-вектори добре ловлять семантику, але пропускають точні збіги за ключовими словами. Ми об'єднали обидва підходи через RRF-ранжування. У результаті релевантність зросла на 25%.

Мультитенантність без головного болю. Партиціонування дозволяє ізолювати дані різних клієнтів без створення окремих колекцій. Ми реалізували схему з динамічними партиціями — легко і безпечно.

Чому Milvus — найкращий вибір для корпоративного RAG?

Milvus outperforms інші векторні БД за швидкістю та вартістю при високих навантаженнях. Порівняємо індекси:

Індекс Speed (QPS) Recall@10 Пам'ять/вектор
HNSW 900 98% 2-4 MB
IVF_FLAT 600 95% 0.5-1 MB
IVF_SQ8 800 92% 0.2-0.5 MB
DISKANN 400 90% ~0 MB (на диску)

Ми використовуємо HNSW як універсальний вибір для production, а DISKANN — для архівних даних на SSD.

Чому Milvus краще Pinecone для високих навантажень?

Milvus дешевший на обсягах > 1M векторів, оскільки не вимагає плати за кожен запит. Для типового кластера на 10M векторів Milvus коштує близько $500/міс на обладнанні, тоді як Pinecone — $2000/міс (у 4 рази дорожче). Порівняємо:

Характеристика Milvus (self-hosted) Pinecone (managed)
Вартість Обладнання + підтримка $0.10/1000 векторів/день
GPU-прискорення Так (NVIDIA CUDA) Ні
Гібридний пошук Вбудований Через плагіни
Контроль Повний Обмежений

Як налаштувати HNSW-індекси для мінімального latency?

Ключові параметри: M (16-64) та efConstruction (200-500). Більше efConstruction — вища точність, але повільніше побудова. У production ми використовуємо M=32, efConstruction=400, а для пошуку ef=100-200. Це дає latency P99 < 400 мс на 2.5M чанків.

Як ми налаштували гібридний пошук для високої релевантності?

Ось код, який ми застосували для нашого клієнта (фінтех, 2.5M чанків):

from pymilvus import connections, Collection, FieldSchema, CollectionSchema, DataType, utility # Підключення до Milvus connections.connect( alias="default", host="localhost", port="19530" ) # Або через URI (Milvus Lite для локальної розробки) from pymilvus import MilvusClient client = MilvusClient("./milvus_local.db") # SQLite-подібний файл 
fields = [ FieldSchema(name="id", dtype=DataType.INT64, is_primary=True, auto_id=True), FieldSchema(name="text", dtype=DataType.VARCHAR, max_length=4096), FieldSchema(name="source", dtype=DataType.VARCHAR, max_length=512), FieldSchema(name="doc_type", dtype=DataType.VARCHAR, max_length=64), FieldSchema(name="page", dtype=DataType.INT32), FieldSchema( name="dense_vector", dtype=DataType.FLOAT_VECTOR, dim=1536 # text-embedding-3-small ), FieldSchema( name="sparse_vector", dtype=DataType.SPARSE_FLOAT_VECTOR # BM25 ), ] schema = CollectionSchema(fields=fields, description="Corporate Knowledge Base") collection = Collection(name="knowledge_base", schema=schema) # Індекси для векторних полів collection.create_index( field_name="dense_vector", index_params={"metric_type": "COSINE", "index_type": "HNSW", "params": {"M": 16, "efConstruction": 200}} ) collection.create_index( field_name="sparse_vector", index_params={"metric_type": "IP", "index_type": "SPARSE_INVERTED_INDEX"} ) collection.load() 
from pymilvus import AnnSearchRequest, RRFRanker def milvus_hybrid_search(query: str, top_k: int = 5) -> list: # Dense вектор dense_vec = dense_embedder.embed_query(query) # Sparse вектор (через вбудований BM25Encoder) sparse_vec = sparse_encoder.encode_queries([query]) # Два запити для RRF dense_req = AnnSearchRequest( data=[dense_vec], anns_field="dense_vector", param={"metric_type": "COSINE", "params": {"ef": 100}}, limit=30, ) sparse_req = AnnSearchRequest( data=sparse_vec, anns_field="sparse_vector", param={"metric_type": "IP"}, limit=30, ) # RRF fusion results = collection.hybrid_search( reqs=[dense_req, sparse_req], rerank=RRFRanker(k=60), limit=top_k, output_fields=["text", "source", "doc_type"], ) return results 

Результат: 850 QPS при latency P99 < 400мс на кластері з 3 вузлів (8 vCPU, 32GB RAM кожен).

Що входить в роботу

  • Аудит даних і проектування схеми колекцій
  • Розгортання Milvus кластера (Kubernetes / bare-metal) з GPU-прискоренням
  • Налаштування індексів і параметрів (efConstruction, M, ef) під навантаження
  • Ingestion pipeline (PySpark / Kafka / direct)
  • RAG-пайплайн з LangChain або LlamaIndex
  • Документація та навчання команди
  • Підтримка 2 тижні після запуску

Процес роботи

  1. Аналітика: збираємо вимоги, оцінюємо обсяг і частоту запитів.
  2. Проектування: вибираємо схему, індекси, топологію кластера.
  3. Реалізація: розгортаємо Milvus, пишемо пайплайни, інтегруємо з LLM.
  4. Тест: навантажувальне тестування, tweak параметрів.
  5. Деплой: CI/CD, моніторинг (Prometheus + Grafana).

Терміни

  • Налаштування Milvus кластера + схема: 3–5 днів
  • Ingestion pipeline з hybrid indexing: 5–10 днів
  • RAG-пайплайн і оцінка: 1–2 тижні
  • Разом: 3–5 тижнів

Метрики компанії

Понад 7 років працюємо з vector databases (7+ років досвіду), 30+ розгортань Milvus у production (30+ успішних проектів). Гарантуємо uptime 99.9% на кластері та експертну підтримку. Оцінимо ваш проект за 2 дні — напишіть нам. Отримайте консультацію з архітектури RAG: розрахуємо вартість і терміни під ваш об'єм даних.