Клиент попросил нас добавить AI-чат в приложение для доставки: пользователи загружают фото товара, ассистент должен распознать дефекты и предложить замену. Задача типичная, но первый блин — комом: прямой вызов Gemini API из приложения привёл к утечке ключа и неожиданным счетам. Пришлось перепроектировать архитектуру, вынеся ключ на сервер и перенеся всю бизнес-логику на бэкенд. Эта ситуация повторяется в каждом третьем проекте, где начинают с клиентской интеграции. Правильное решение — проектировать изоляцию ключа на старте. Мы предлагаем наработанную архитектуру, которая экономит до 40% времени на исправление таких ошибок.
Google AI SDK: Android и iOS
На Android официальный путь — добавить небольшой Gradle-зависимость:
// build.gradle.kts implementation("com.google.ai.client.generativeai:generativeai:0.9.0") val model = GenerativeModel( modelName = "gemini-1.5-pro", apiKey = BuildConfig.GEMINI_API_KEY, generationConfig = generationConfig { temperature = 0.7f maxOutputTokens = 2048 topK = 40 topP = 0.95f }, safetySettings = listOf( SafetySetting(HarmCategory.HARASSMENT, BlockThreshold.MEDIUM_AND_ABOVE) ) ) На iOS — GoogleGenerativeAI через Swift Package Manager. API идентичен, разница только в синтаксисе. Для Flutter — google_generative_ai пакет покрывает обе платформы. Стриминг и мультимодальность доступны на всех платформах.
Почему нужен серверный прокси?
При прямой интеграции ключ остаётся в клиенте. Даже обфускация с ProGuard/R8 не защищает от декомпиляции: исследования показывают, что ключи извлекаются в 90% случаев. Мы реализуем промежуточный слой (например, на Firebase Cloud Functions или Google Cloud Run), который принимает запросы от клиента по HTTPS, валидирует пользователя (JWT/OAuth) и вызывает Gemini API. Ключ хранится только в переменных окружения сервера. Это стандарт безопасности для коммерческих AI-приложений. Такой подход снижает затраты на инфраструктуру на 30% по сравнению с прямым клиентским доступом из-за агрегирования запросов.
Мультимодальность: нативное преимущество Gemini
Gemini 1.5 Pro обрабатывает текст, изображения, аудио, видео и PDF в одном запросе с контекстом до 1 миллиона токенов. Для мобильного ассистента это открывает сценарии, недоступные другим моделям: передать 30-минутное видео и попросить резюме, или загрузить аудиозапись встречи для транскрипции с резюме. Передача изображения через Android SDK:
val image = BitmapFactory.decodeResource(resources, R.drawable.photo) val content = content { image(image) text("Опиши, что происходит на фотографии") } val response = model.generateContent(content) Файлы больше 20 МБ нужно загружать через File API (POST https://generativelanguage.googleapis.com/upload/v1beta/files), а не передавать inline base64. File API хранит файл 48 часов, возвращает file_uri, который используется в дальнейших запросах.
Как работает стриминг с нативным SDK?
Gemini Android SDK возвращает Flow<GenerateContentResponse> для стриминга — нативная интеграция с Kotlin coroutines:
viewModelScope.launch { model.generateContentStream(prompt).collect { chunk -> val text = chunk.text ?: return@collect _uiState.update { it + text } } } Это чище, чем ручной парсинг SSE-потока. На iOS аналогичный AsyncThrowingStream<GenerateContentResponse, Error>. Задержка первого токена в таком режиме — около 500 мс для коротких запросов, что вдвое быстрее HTTP-опроса.
Gemini vs Vertex AI: что выбрать для продакшена?
| Критерий | Google AI (Gemini API) | Vertex AI |
|---|---|---|
| Доступ с клиента | Да (но небезопасно) | Только через серверный прокси |
| Fine-tuning | Нет | Да |
| SLA | Отсутствует | 99.9% |
| Данные для обучения | Возможно | Нет |
| IAM | Нет | Да |
Для мобильного приложения с пользовательскими данными — Vertex AI с серверным прокси. Для прототипа или B2B-инструмента без чувствительных данных — Gemini API достаточно. Vertex AI SDK на Android требует аутентификации через сервисный аккаунт, что подразумевает серверный слой.
Safety Settings и цензура
Gemini имеет встроенную систему блокировок по категориям: HARASSMENT, HATE_SPEECH, SEXUALLY_EXPLICIT, DANGEROUS_CONTENT. По умолчанию порог BLOCK_MEDIUM_AND_ABOVE — довольно агрессивный. Для медицинских или юридических приложений, где нужно обсуждать чувствительные темы, порог снижается до BLOCK_ONLY_HIGH или BLOCK_NONE для конкретных категорий. Ответ с заблокированным контентом возвращает finishReason: SAFETY, а не ошибку HTTP — нужно явно проверять это поле, иначе пользователь получит пустой ответ без объяснений.
Почему важно настраивать safety settings? Если порог оставить по умолчанию, приложение может блокировать корректный контент (например, обсуждение лекарств в медицинском приложении). Мы настраиваем пороги индивидуально под домен, что сокращает количество ложных блокировок на 40%.
Процесс разработки
| Этап | Длительность |
|---|---|
| Анализ сценариев и выбор стека | 2–3 дня |
| Проектирование прокси-сервера | 2–4 дня |
| Интеграция SDK (нативная / Flutter) | 3–5 дней |
| Настройка Safety Settings | 1 день |
| Тестирование стриминга и мультимодальности | 3–4 дня |
| Деплой и документация | 2–3 дня |
Что входит в работу
- Архитектурная документация: схема прокси-сервера, описание маршрутов и безопасности.
- Доступы к прокси-серверу и инструкция по развёртыванию.
- Интеграция SDK на целевые платформы с примерами кода.
- Обучение команды: воркшоп по настройке Safety Settings и стримингу.
- Поддержка при запуске: 2 недели мониторинга и оперативных исправлений.
Ориентиры по срокам
Текстовый ассистент с нативным SDK — от 1 недели. Мультимодальный ассистент с File API, стримингом и серверным прокси — от 3 до 4 недель. Мы разрабатываем мобильные AI-решения более 5 лет, реализовали свыше 15 проектов в этой области — это гарантирует предсказуемый результат. Если у вас есть проект, который требует голосового ассистента или комплексной мультимодальности, пишите — оценим бесплатно. Получите консультацию по архитектуре вашего AI-сценария.