RAG на ChromaDB: від прототипу до продакшену

Поширена ситуація: модель відповідає не за контекстом, а latency p99 перевищує 5 секунд. Причини — невідфільтровані ембедінги, перемішані чанки та непідготовлена векторна база. Ми стикалися з цим десятки разів і знаємо, як налаштувати <cite>[RAG](https://en.wikipedia.org/wiki/Retrieval-augmented_gen

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

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

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

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

Поширена ситуація: модель відповідає не за контекстом, а latency p99 перевищує 5 секунд. Причини — невідфільтровані ембедінги, перемішані чанки та непідготовлена векторна база. Ми стикалися з цим десятки разів і знаємо, як налаштувати RAG на ChromaDB під ваші дані.

Чому ChromaDB — хороший старт для RAG?

ChromaDB — це embedded векторна база даних, яка не потребує окремого сервера для локальної розробки. Вона підтримує in-memory та persistent режими, а також HTTP-режим для продакшену. Це дозволяє швидко ітерувати: написали код — запустили — перевірили. Для прототипування RAG-систем і невеликих продакшен-деплоїв (до кількох мільйонів документів) ChromaDB — стандартний вибір.

Які проблеми ми вирішуємо?

  • Галюцинації LLM: RAG знижує їх за рахунок подачі релевантного контексту. Але якщо пошук повертає не ті чанки — галюцинації залишаються. Ми налаштовуємо embedding-модель, розмір чанка та метрику схожості так, щоб precision@k була >0.8. Це знижує latency з 5с до 50 мс і економить до 70% обчислювальних ресурсів.
  • Повільний пошук: при 100k+ чанків latency може перевищити 1 секунду. Оптимізація HNSW-графа (ef_construction, ef_search) та шардування за метаданими скорочують час до 50 мс.
  • Складність масштабування: ChromaDB легко масштабується горизонтально через HTTP-сервер та реплікацію. Ми покажемо, як налаштувати кластер для мільйонів запитів на день.

Як ми це робимо: стек та конфігурації

Використовуємо перевірений стек: Python 3.11, ChromaDB 0.5.x, OpenAI text-embedding-3-small (1536-dim), GPT-4o-mini для генерації. Для складних сценаріїв — LangChain або LlamaIndex. Додатково застосовуємо fine-tuning ембедінгів під доменну специфіку та MLOps-практики для відстеження експериментів.

Запуск та підключення

import chromadb from chromadb.utils import embedding_functions # In-memory (для розробки та тестів) client = chromadb.EphemeralClient() # Persistent (файлове сховище) client = chromadb.PersistentClient(path="./chroma_db") # HTTP-сервер (production) client = chromadb.HttpClient(host="localhost", port=8000) 

Створення колекції та індексація

from chromadb.utils.embedding_functions import OpenAIEmbeddingFunction embedding_fn = OpenAIEmbeddingFunction( api_key="...", model_name="text-embedding-3-small" ) collection = client.get_or_create_collection( name="knowledge_base", embedding_function=embedding_fn, metadata={"hnsw:space": "cosine"} # Метрика схожості ) # Додавання документів collection.add( documents=["Текст чанка 1", "Текст чанка 2", ...], metadatas=[ {"source": "contract.pdf", "page": 1, "doc_type": "contract"}, {"source": "faq.md", "page": 0, "doc_type": "faq"}, ], ids=["chunk_001", "chunk_002", ...] ) 

RAG-запит

from openai import OpenAI openai_client = OpenAI() def rag_answer(question: str, n_results: int = 4) -> str: # Пошук релевантних чанків results = collection.query( query_texts=[question], n_results=n_results, where={"doc_type": {"$in": ["contract", "regulation"]}}, # Фільтр ) context = "\n\n".join(results["documents"][0]) # Генерація відповіді response = openai_client.chat.completions.create( model="gpt-4o-mini", messages=[ {"role": "system", "content": "Відповідай лише на основі контексту."}, {"role": "user", "content": f"Контекст:\n{context}\n\nПитання: {question}"} ], temperature=0, ) return response.choices[0].message.content answer = rag_answer("Який термін дії договору?") 

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

Етап Результат
Аналіз даних Інвентаризація документів, вибір стратегії чанкування (recursive split, semantic chunking)
Проектування Архітектура RAG, вибір моделі ембедінгів, налаштування HNSW-параметрів
Реалізація Інтеграція ChromaDB, написання пайплайну індексації та запитів, unit-тести
Тестування A/B-тест проти baseline, замір precision@k, recall@k, latency p99
Деплой Docker-контейнеризація, CI/CD, моніторинг (Prometheus + Grafana)
Приклад конфігурації HNSW для високої точності
collection = client.create_collection( name="high_accuracy", metadata={ "hnsw:space": "cosine", "hnsw:construction_ef": 200, "hnsw:search_ef": 100, "hnsw:M": 32 } ) 

Ми передаємо документацію по архітектурі, доступ до репозиторію, інструкцію з експлуатації та проводимо навчання команди.

Чому ChromaDB краща за інші embedded векторні бази?

Порівняємо ChromaDB з основними альтернативами для прототипування:

Критерій ChromaDB FAISS Qdrant (embedded)
Встановлення pip install chromadb pip install faiss-cpu pip install qdrant-client
In-memory Так Так Ні (тільки persistent)
Persistent Так Ні (вручну) Так
Метадані Так (фільтрація) Ні Так
HTTP-сервер Вбудований Ні Окремий сервер

ChromaDB виграє за рахунок вбудованої підтримки метаданих та HTTP-режиму з коробки. Для прототипу це знижує час до першого RAG-запиту до годин.

Як забезпечити точність відповідей у RAG?

Ключ — якість індексації. Використовуємо:

  • Розмір чанка: 256–512 токенів для питально-відповідних сценаріїв, 1024+ для сумаризації.
  • Перекриття чанків: 10–20% для збереження контекстної зв'язності.
  • Фільтри: Чанки з метаданими (джерело, тип документа) дозволяють точково обмежувати пошук.
  • Кількість чанків у контексті: 3–5 зазвичай достатньо, але для складних питань — до 10.

Процес роботи з нами

  1. Аналітика: Ви надсилаєте датасет документів — ми оцінюємо обсяг, структуру, мову.
  2. Проектування: Вибираємо embedding-модель, метрику схожості, стратегію індексації.
  3. Реалізація: Пишемо пайплайн індексації та RAG-запит. Використовуємо ваш API-ключ до LLM.
  4. Тестування: Порівнюємо baseline (простий пошук) з фінальною версією. Метрики — точність, повнота, час відповіді.
  5. Деплой: Запускаємо у вашому середовищі (K8s, Docker, bare metal). Налаштовуємо моніторинг.

Терміни та вартість

  • Прототип: 2–5 днів. Ідеально для оцінки feasibility.
  • Продакшен-версія: 2–3 тижні. Включає моніторинг, CI/CD, навантажувальне тестування.

Вартість розраховується індивідуально під ваш обсяг даних та вимоги до latency. Оцінимо проект за 1 день. Економія на інфраструктурі сягає 40% за рахунок оптимізованого індексування. Зв'яжіться з нами — обговоримо деталі.

Наш досвід — 5+ років в AI/ML, 20+ впроваджених RAG-проектів. Сертифіковані спеціалісти з OpenAI, Hugging Face, Kubernetes. Гарантуємо якість: прописуємо SLA по точності та latency. Замовте RAG з ChromaDB під ключ — отримайте працюючу систему з нуля до продакшену.