Векторне сховище 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 та навчимо команду. Векторна база даних дає загальне розуміння технології, але ми додамо конкретні рішення під вашу задачу. Якщо ви хочете обговорити деталі, зв'яжіться з нами.

Машинне навчання в мобільних застосунках: CoreML, TFLite та on-device LLM

Ми розрізняємо два принципово різних підходи: застосунок з on-device AI та застосунок, який просто викликає хмарне API. Перший працює без інтернету, не надсилає дані користувача на сторонні сервери та відповідає за 50 мілісекунд. Другий залежить від затримки мережі та тарифного плану. Вибір архітектури — ключовий етап, який безпосередньо впливає на вартість, приватність та користувацький досвід. Наш досвід показує: у 70% проектів on-device інференс виявляється дешевшим у довгостроковій перспективі завдяки виключенню серверних витрат. Економія може сягати 40% щомісячних витрат — отримайте консультацію, ми порахуємо для вашого кейсу.

Як вибрати між CoreML та TFLite для on-device інференсу?

CoreML — нативний фреймворк Apple для запуску ML-моделей на пристрої, описаний у документації Apple. Підтримує Neural Engine (A11 Bionic та новіші), GPU та CPU як fallback. Моделі конвертуються у формат .mlmodel через coremltools з PyTorch, ONNX або TensorFlow. Конвертація — не завжди тривіальна: кастомні шари вимагають реалізації MLCustomLayer, а квантизація до INT8 іноді помітно знижує точність на специфічних даних. Ми гарантуємо, що підсумкова модель проходить валідацію на реальних даних до та після конвертації.

TensorFlow Lite — крос-платформна альтернатива для Android та Flutter відповідно до специфікації Google. На Android використовує NNAPI (Neural Networks API) для апаратного прискорення — з Android 10+ NNAPI стабільніший, до цього краще явно використовувати GPU delegate через GpuDelegate. Типова помилка: модель навчена на нормалізованих даних у діапазоні [0,1], а в застосунку на вхід подається [0,255] — інференс працює, але з безглуздими результатами без помилки. Ми включаємо модуль автоматичної валідації вхідних даних у SDK.

Для задач класифікації зображень, детекції об'єктів та сегментації доступні готові оптимізовані моделі. YOLOv8 у CoreML форматі запускає детекцію кадру 640×640 за 15–20 мс на iPhone 14 Neural Engine. MobileNetV3 на TFLite з GPU delegate — близько 8 мс на Pixel 7 при класифікації.

Що робити, якщо потрібна генерація тексту на пристрої?

Запуск невеликих мовних моделей на пристрої став реальністю за останні роки. Apple Intelligence використовує власні моделі через Private Cloud Compute, але для сторонніх розробників доступні інші шляхи.

llama.cpp з Metal backend на iOS — робочий підхід для phi-3-mini (3.8B параметрів, 4-bit квантизація, ~2.3 ГБ). Інференс: 15–25 токенів/секунду на iPhone 15 Pro. Для інтеграції в Swift використовуємо Swift Package llama.swift або обгортку через C-інтерфейс llama.h. Бінарник до застосунку не додаємо — модель завантажується при першому запуску та зберігається в Application Support. Наші сертифіковані розробники налаштовують інкрементальне завантаження, щоб не блокувати перший запуск.

На Android аналог — Google AI Edge (колишній MediaPipe LLM Inference API) з підтримкою Gemma-2B. Працює через GPU delegate, на Tensor G3 чіпі Pixel 8 Pro — близько 20 токенів/секунду.

Інтеграція OpenAI API та інших хмарних моделей

Для сценаріїв, де cloud inference допустимий, інтеграція OpenAI, Anthropic або Google Gemini — це HTTP клієнт + streaming SSE. У Swift зручно через AsyncThrowingStream для стрімінгових відповідей. У Kotlin — через Flow.

Критично важливо: API-ключі ніколи не зберігаються в бандлі застосунку. Навіть обфускований ключ витягується з IPA за 10 хвилин через strings або frida. Правильна архітектура: мобільний застосунок → власний backend → OpenAI API. Backend контролює rate limiting, логує запити, захищає ключ.

Що входить у роботу (результати)

• Навчена та квантизована модель під цільовий пристрій (документація за метриками)
• SDK для інтеграції (Swift/Kotlin/Flutter) з прикладами виклику
• Тести продуктивності на 3–5 реальних пристроях
• Інструкція з оновлення моделі OTA
• Підтримка при проходженні модерації App Store / Google Play (перевірка відповідності Guidelines 4.2, 5.1)
• 2 тижні технічної підтримки після релізу

Типовий пайплайн проекту

1. Аналіз завдання — вимірюємо latency, privacy, size, підтримувані пристрої.
2. Прототипування моделі — в Python, оцінка accuracy на цільових даних.
3. Конвертація та квантизація — під CoreML/TFLite з валідацією.
4. Інтеграція в застосунок — модель обгортається в сервісний шар (легко замінювати CoreML → TFLite → хмара).
5. Тестування — на реальних пристроях, вимір FPS, RAM, батареї.
6. Деплой — через TestFlight / Firebase App Distribution, моніторинг метрик.

Терміни: інтеграція готової CoreML/TFLite моделі — 1–2 тижні, розробка кастомної моделі з мобільною оптимізацією — від 6 тижнів, on-device LLM чат з персоналізацією — 4–8 тижнів.

Чому ми беремося за складні кейси?

10+ років досвіду в мобільній розробці, 50+ впроваджених AI/ML рішень, гарантія сумісності з актуальними версіями iOS та Android. Всі проекти проходять code review та навантажувальне тестування. У вартість вже входить підготовка документації для модерації та навчання вашої команди.

Зв'яжіться з нами — ми допоможемо вибрати архітектуру та впровадити ML у ваш застосунок під ключ. Замовте аудит наявного рішення — безкоштовно оцінимо потенціал економії серверних витрат. Отримайте консультацію експерта — напишіть нам сьогодні.