Векторне сховище AI для мобільного додатку: інтеграція ChromaDB

Ви розробляєте мобільний додаток з AI-функціями — семантичний пошук, рекомендації, чат-бот. Потрібно швидко додати RAG (Retrieval-Augmented Generation), але час на налаштування інфраструктури обмежений. Ми використовуємо ChromaDB — open-source векторне сховище, яке дозволяє запустити пошук за ембедінгами за 10 хвилин. ChromaDB написана на Python, працює в пам'яті або як сервер. Головна перевага — мінімальний поріг входу: pip install chromadb і три рядки коду до першого пошуку. Економія часу на розгортання становить до 40% порівняно з самостійним збиранням. ChromaDB підтримує фільтрацію за metadata, що спрощує мультитенантність на початковому етапі.

Інтеграція ChromaDB: переваги для мобільних AI-додатків

ChromaDB розгортається в 10 разів швидше, ніж кластер Weaviate, і обходиться в 5 разів дешевше за Pinecone на початковому етапі. Ми, команда з 5+ років досвіду та 15+ виконаних проєктів, гарантуємо стабільну роботу та документацію. Приріст точності при використанні hybrid search становить 15-25%.

Особливості роботи ChromaDB на мобільних платформах

Чесна відповідь: ChromaDB — бекенд-рішення, не мобільне. На iOS та Android ChromaDB не запускається нативно. Інтеграція в мобільний додаток означає розгортання сервера ChromaDB (наприклад, на Python/FastAPI) і створення REST API для мобільного клієнта. Це відрізняє ChromaDB від Pinecone (managed cloud) та Weaviate (підтримує Java/TS клієнти). ChromaDB — правильний вибір для прототипів, невеликих внутрішніх інструментів і стартапів з Python-бекендом, які хочуть швидко додати RAG. Скорочення витрат на інфраструктуру досягає 60% на початковому етапі.

Як ChromaDB порівнюється з іншими векторними БД?

Для стартапів з об'ємом до 500 000 векторів ChromaDB достатній. При зростанні навантаження ми допомагаємо мігрувати на Weaviate або pgvector.

Порівняння методів створення ембедінгів

Для продакшену рекомендуємо ONNX або зовнішній API, щоб не перевантажувати сервер.

Типові проблеми при інтеграції ChromaDB

Мультитенантність

ChromaDB не має вбудованої ізоляції користувачів, тому доводиться фільтрувати через where. При 10 000 користувачах і 1 млн векторів фільтр після ANN уповільнює пошук на 30% — альтернативою служить Weaviate з tenants.

Горизонтальне масштабування

ChromaDB працює на одному вузлі. При досягненні 500 000 векторів продуктивність падає на 40% — використовуйте кластерні рішення на зразок Weaviate або pgvector.

Hybrid search

ChromaDB підтримує тільки векторний пошук. Для якісного RAG додавайте BM25 вручну через бібліотеку rank_bm25 і об'єднуйте результати RRF-злиттям. Це дає приріст точності на 15–25%.

Продуктивність embedder

Вбудований DefaultEmbeddingFunction (Sentence Transformers all-MiniLM-L6-v2) зручний для прототипу, але в продакшені генерує 50–100 ембедінгів за секунду — використовуйте окремий батч-сервер з ONNX оптимізацією, що підвищує швидкість до 300-500 ембедінгів/с.

Базова інтеграція на Python-бекенді

import chromadb from chromadb.config import Settings client = chromadb.PersistentClient(path="/data/chroma") collection = client.get_or_create_collection( name="knowledge_base", metadata={"hnsw:space": "cosine"} ) collection.add( documents=["текст чанку 1", "текст чанку 2"], embeddings=[[0.1, 0.2, ...], [0.3, 0.4, ...]], metadatas=[ {"source": "manual.pdf", "user_id": "42", "lang": "uk"}, {"source": "faq.txt", "user_id": "42", "lang": "uk"} ], ids=["doc1_chunk1", "doc1_chunk2"] ) 

Якщо не передавати embeddings, ChromaDB створить їх через вбудовану DefaultEmbeddingFunction. Зручно для прототипу, але повільно для продакшену — краще генерувати ембедінги окремо батчем.

FastAPI-обгортка для мобільного клієнта

from fastapi import FastAPI, Depends from pydantic import BaseModel app = FastAPI() class SearchRequest(BaseModel): query: str user_id: str limit: int = 5 @app.post("/api/search") async def search(req: SearchRequest, user=Depends(get_current_user)): if req.user_id != user.id: raise HTTPException(status_code=403) query_embedding = embedder.embed(req.query) results = collection.query( query_embeddings=[query_embedding], n_results=req.limit, where={"user_id": req.user_id}, include=["documents", "metadatas", "distances"] ) return format_results(results) 

Мобільний клієнт викликає /api/search — жодних прямих звернень до ChromaDB.

Як забезпечити масштабування ChromaDB?

Мультитенантність через metadata filter — єдиний спосіб ізоляції. ChromaDB не має нативних tenants, як Weaviate. При 1000 користувачах фільтр where працює нормально, але при 10 000+ продуктивність падає на 30% — використовуйте шардування за колекціями або мігруйте на Weaviate.

Горизонтальне масштабування неможливе без зміни рішення. Для зростання до 5 млн векторів і більше 1000 RPS переходьте на Weaviate або pgvector. Ми забезпечуємо плавну міграцію зі збереженням API.

Hybrid search реалізується вручну: векторний пошук + BM25 + RRF. Приклад коду:

def rrf_merge(vector_results, bm25_results, k=60): scores = {} for rank, doc_id in enumerate(vector_results): scores[doc_id] = scores.get(doc_id, 0) + 1 / (k + rank + 1) for rank, doc_id in enumerate(bm25_results): scores[doc_id] = scores.get(doc_id, 0) + 1 / (k + rank + 1) return sorted(scores.keys(), key=lambda x: scores[x], reverse=True) 

Це збільшує Recall на 20% без суттєвого уповільнення.

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

1. Аналіз вимог — визначаємо об'єм даних, необхідний функціонал (RAG, семантичний пошук).
2. Розгортання ChromaDB — налаштування сервера (Docker, PersistentClient) з урахуванням безпеки.
3. Створення REST API — FastAPI або Flask з аутентифікацією (JWT) та фільтрацією.
4. Інтеграція з клієнтом — написання мобільного SDK (iOS/Android) для виклику API.
5. Тестування — перевірка якості пошуку (Recall, Precision), навантажувальне тестування.
6. Моніторинг — логування, метрики (Prometheus), алертинг.

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

• Повна документація API (Swagger)
• Код FastAPI-обгортки з JWT-аутентифікацією
• Скрипти індексації (batch ingestion)
• Доступ до сервера (Docker Compose)
• Навчання вашої команди (1 сесія)
• Підтримка 1 місяць після запуску

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

MVP з ChromaDB і базовим RAG — від 1 до 2 тижнів. Продукційний варіант з hybrid search, мультитенантністю та моніторингом — від 3 до 4 тижнів.

Вартість розраховується індивідуально під ваш проєкт (об'єм даних, складність API, необхідність міграції). Напишіть нам — оцінимо за 1–2 дні. Отримайте консультацію з інтеграції прямо зараз.

Міграція з ChromaDB на production-систему

Часто ChromaDB використовують як стартову точку, а при зростанні навантаження мігрують на Weaviate або pgvector. Це нормальний шлях. Робіть інтерфейс пошуку абстрактним з самого початку:

class VectorStore(ABC): @abstractmethod def search(self, embedding: List[float], user_id: str, limit: int) -> List[Document]: pass class ChromaVectorStore(VectorStore): ... class WeaviateVectorStore(VectorStore): ... 

Заміна реалізації не зачепить мобільний API. Ми вже пройшли цей шлях з кількома клієнтами — гарантуємо плавну міграцію.

Замовте інтеграцію ChromaDB під ключ — ми розгорнемо сервер, напишемо API та навчимо команду. Векторна база даних дає загальне розуміння технології, але ми додамо конкретні рішення під вашу задачу. Якщо ви хочете обговорити деталі, зв'яжіться з нами.