GigaChat AI-ассистент для мобильных приложений: интеграция под РФ

Разработка AI-ассистента в мобильном приложении на базе GigaChat (Сбер)

Мобильные приложения для финансового и медицинского секторов обязаны хранить данные в РФ. GigaChat — единственная крупная языковая модель с серверами в российском контуре. Мы интегрировали её в 15+ проектов: от банковских чат-ботов до аналитики документов. Процесс от подписания до деплоя занимает от двух до четырёх недель. Оцените свой сценарий — свяжитесь с нами для предварительного аудита.

Проблемы, которые решаем

1. Юридическая изоляция данных. GigaChat размещается на серверах Сбера в РФ. Это единственный вариант для приложений, где 152-ФЗ требует локального хранения. YandexGPT тоже работает в РФ, но GigaChat имеет более гибкую B2B-адаптацию с корпоративными тарифами и выделенными ресурсами. Например, клиенты с большим объёмом запросов получают dedicated endpoint с гарантированной пропускной способностью.

2. OAuth 2.0 с короткоживущими токенами. Access_token GigaChat живёт 30 минут. Прямое получение на мобильном устройстве небезопасно — client_id и client_secret должны оставаться только на сервере. Мы проектируем серверный прокси, который берёт на себя авторизацию и выдаёт токен клиенту. Это снижает риск утечки учётных данных.

3. Нестандартные корневые сертификаты. Сбер использует собственные CA из реестра Минцифры. В production нужно явно добавить эти сертификаты в доверенные — иначе HTTPS-соединение упадёт. Мы уже настроили это под iOS (через ATS), Android (Network Security Config) и серверные платформы. Потери производительности нет — время установки соединения увеличивается не более чем на 5%.

Как авторизоваться в GigaChat API?

Протокол OAuth 2.0 с типом client_credentials. Запрос:

POST https://ngw.devices.sberbank.ru:9443/api/v2/oauth
Authorization: Basic {base64(client_id:client_secret)}
Content-Type: application/x-www-form-urlencoded

scope=GIGACHAT_API_CORP

Токен возвращается в JSON с полями access_token и expires_at. На мобильном клиенте мы не храним секреты — все запросы идут через наш серверный прокси, который получает токен и передаёт его клиенту по защищённому каналу. Пример серверного кода (Python):

# Серверная сторона (Python) — получение токена
import httpx, base64, time

class GigaChatAuth:
    def __init__(self, client_id: str, client_secret: str):
        self._credentials = base64.b64encode(
            f"{client_id}:{client_secret}".encode()
        ).decode()
        self._token = None
        self._expires_at = 0

    async def get_token(self) -> str:
        if time.time() < self._expires_at - 60:
            return self._token
        async with httpx.AsyncClient(verify=False) as client:
            resp = await client.post(
                "https://ngw.devices.sberbank.ru:9443/api/v2/oauth",
                headers={"Authorization": f"Basic {self._credentials}"},
                data={"scope": "GIGACHAT_API_CORP"}
            )
        data = resp.json()
        self._token = data["access_token"]
        self._expires_at = data["expires_at"] / 1000
        return self._token

Ссылка: GigaChat API Specification (текущая версия). Важно: verify=False допустим только для тестирования. В production подключайте сертификаты Минцифры (например, через файл cacert.pem).

Почему серверный прокси обязателен?

Прямое использование GigaChat API с мобильного устройства — грубейшая ошибка безопасности. client_secret — это ключ к вашему аккаунту. Если он скомпрометирован, злоумышленник может генерировать токены за ваш счёт. Прокси решает эту проблему: он хранит секрет, а мобильное приложение получает только временный токен. Дополнительно прокси позволяет:

• Кэшировать токены и уменьшать число запросов к GigaChat (экономия до 40% на лимитах).
• Логировать все запросы для аудита.
• Добавить собственную бизнес-логику (например, модерацию контента или A/B-тестирование).

Какая модель GigaChat подходит для вашего приложения?

GigaChat-Pro в 2-3 раза точнее базовой модели на задачах извлечения данных и финансового анализа. Если ваш ассистент должен работать с отчётами и графиками, выбирайте Pro. В наших проектах точность извлечения данных из отчётов достигает 95%.

Как Function Calling упрощает интеграцию с бэкендом?

GigaChat поддерживает вызов функций через параметр functions. Синтаксис отличается от OpenAI: поле называется functions (не tools), а вызов приходит в function_call (не tool_calls). Это первое, что ломается при миграции. Пример запроса:

{
  "functions": [{
    "name": "get_account_balance",
    "description": "Получить баланс счёта клиента",
    "parameters": {
      "type": "object",
      "properties": {
        "account_id": {"type": "string"}
      },
      "required": ["account_id"]
    }
  }],
  "function_call": "auto"
}

Мы реализовали такой паттерн в нескольких проектах — ассистент сам решает, когда вызвать функцию, и возвращает структурированные данные. Это позволяет интегрироваться с любым REST API без ручного парсинга.

Работа с изображениями

GigaChat Pro позволяет загружать изображения через файловый API. Шаги:

1. Загрузить файл POST /api/v1/files с purpose: general. Максимальный размер — 20 МБ.
2. Получить file_id.
3. Передать его в сообщении как image_url: https://gigachat.ru/files/{file_id}/content.

Файл удаляется через 24 часа — это важно учитывать при проектировании. Для критичных данных рекомендуем выгружать сразу.

Что входит в работу

• Серверный прокси с OAuth 2.0 (Python/Go/Node.js).
• Мобильный SDK для iOS/Android/Flutter с обработкой токенов и стриминга (SSE).
• Настройка российских корневых сертификатов для production.
• Реализация function calling под вашу бизнес-логику.
• Интеграция с файловым API (если нужны изображения).
• Документация по развёртыванию и поддержке.

Процесс работы

Для настройки сертификатов: на iOS используем ATS, на Android — Network Security Config. На сервере обновляем CA bundle. Мы подготовили пошаговые инструкции для каждой платформы.

Сроки ориентировочно

• Базовый текстовый ассистент (прокси + чат-интерфейс): от 1,5 до 2 недель.
• С function calling и изображениями: от 3 до 4 недель.

Стоимость рассчитывается индивидуально. Для точной оценки свяжитесь с нами — мы подготовим предложение под ваш проект.

AI и ML в мобильных приложениях: CoreML, TFLite и on-device модели

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

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

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

TensorFlow Lite — кросс-платформенная альтернатива для Android и Flutter. На 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 токенов/секунду.

Ограничения реальны: модели больше 4B параметров на мобильных устройствах по-прежнему медленны. Для сложных задач рассуждения on-device LLM уступает GPT-4o в качестве. Гибридный подход — on-device для коротких задач и приватных данных, облако для сложных запросов — часто оптимален. Оценим ваш кейс и предложим баланс производительности и приватности — пишите.

Интеграция 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, логирует запросы, защищает ключ.

Что входит в работу (deliverables)

• Обученная и квантизированная модель под целевое устройство (документация по метрикам)
• 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 в ваше приложение под ключ. Закажите аудит существующего решения — бесплатно оценим потенциал экономии серверных затрат (в некоторых проектах экономия достигает $10k в месяц).