Управление контекстом AI-диалога в мобильном приложении

Разговорный AI-ассистент в мобильном приложении быстро теряет контекст, если не управлять историей диалога. Каждый запрос пользователя и ответ модели добавляют токены — при активном использовании лимит окна исчерпывается за 10–15 сообщений, а затраты на API растут экспоненциально. Мы интегрируем контекстное окно и управление историей диалога AI в мобильные приложения под ключ. На основе нашего опыта (10+ лет в мобильной разработке и 50+ AI-проектов) мы гарантируем эффективное использование контекста. Правильная стратегия управления контекстом сокращает расходы на API до 30%.

Почему растёт история диалога и как это влияет на стоимость?

Каждый обмен добавляет токены: запрос пользователя + ответ модели. При среднем сообщении 50–100 токенов и 20 парах — уже 2000–4000 токенов только на историю, плюс системный промпт. При gpt-4o с ценой $5 за 1M input токенов — мелочь, но при 1000 активных пользователей с 50 сообщениями в день затраты превышают $250 в день только на историю. Экономия на эффективном управлении может достигать 30% от стоимости API-запросов.

Вторая проблема: разные модели имеют разные лимиты (GPT-4o — 128K, Claude — 200K, YandexGPT — 8K). Приложение, оптимизированное под одну модель, может давать сбои при переключении на другую.

Как управлять контекстом при смене AI-модели?

Для универсальности рекомендуется реализовать абстракцию над управлением контекстом: задать максимальное количество токенов для текущей модели и динамически подстраивать стратегию (скользящее окно с порогом, оставляющим запас). Например, для YandexGPT с 8K лимитом стоит использовать скользящее окно с менее чем 7K токенов, оставляя место под ответ. Для GPT-4o с 128K можно применять гибридную память без ограничений. Такой подход позволяет переключать модели без изменения логики.

Три стратегии управления историей диалога AI

func buildMessages(history: [Message], systemPrompt: String, maxTokens: Int = 3000) -> [Message] {
    var result: [Message] = []
    var tokenCount = countTokens(systemPrompt)
    for message in history.reversed() {
        let msgTokens = countTokens(message.content)
        if tokenCount + msgTokens > maxTokens { break }
        result.insert(message, at: 0)
        tokenCount += msgTokens
    }
    return result
}

Сравнение стратегий

Получите консультацию по архитектуре контекстного окна — мы поможем выбрать оптимальную стратегию для вашего проекта.

Как реализовать гибридную память: пошаговое руководство

1. Определите типы фактов. Какие данные нужно запоминать? Например, для медицинского ассистента: аллергии, текущие лекарства, хронические заболевания.
2. Создайте схему долгосрочной памяти. Используйте SQLite или in-memory словарь. Каждый факт — ключ-значение с тегом времени.
3. При каждом ответе модели извлекайте факты. Отправляйте последние 10–15 сообщений + все актуальные факты в промпт.
4. После получения ответа обновляйте факты. Дополнительный вызов модели (меньшей) извлекает новые факты из диалога.
5. Периодически чистите устаревшие факты. Удаляйте факты, не подтверждённые более недели.

Детали реализации

Долгосрочная память может храниться в виде графа знаний или простых пар ключ-значение. Для извлечения фактов используйте structured output моделей, например, JSON-формат. Это упрощает парсинг и обновление. Важно проверять корректность извлечённых фактов и не допускать зацикливания.

Как выбрать стратегию для вашего мобильного приложения?

Если приложение требует запоминания ключевых фактов (аллергии, предпочтения), гибридная память — единственный рабочий вариант. Суммаризация без явного сохранения фактов может привести к юридическим рискам в медицинских или финансовых ассистентах. Мы рекомендуем проводить аудит требований перед выбором. Свяжитесь с нами для консультации — поможем определиться.

Технические аспекты: хранение, подсчёт токенов и UI

Хранение истории на мобиле

SQLite — стандарт. Структура:

CREATE TABLE conversations (
    id TEXT PRIMARY KEY,
    created_at INTEGER,
    title TEXT,
    model TEXT,
    summary TEXT
);
CREATE TABLE messages (
    id TEXT PRIMARY KEY,
    conversation_id TEXT REFERENCES conversations(id),
    role TEXT CHECK(role IN ('user', 'assistant', 'system')),
    content TEXT,
    token_count INTEGER,
    created_at INTEGER
);
CREATE INDEX idx_messages_conversation ON messages(conversation_id, created_at);

token_count считается при сохранении — не при каждой загрузке.

Подсчёт токенов на мобиле

Точный подсчёт требует токенизатора для конкретной модели. Согласно Wikipedia, токенизация — процесс разбиения текста на токены. На сервере — tiktoken для OpenAI, tokenizers от HuggingFace. На мобиле используем эвристику: английский ~4 символа = 1 токен, русский ~2–2.5 символа = 1 токен, код ~3 символа = 1 токен. Для ответственного подсчёта (тарификация, лимиты) — серверная валидация.

UI: отображение истории

Список сообщений — UITableView с обратным порядком (новые снизу) или LazyColumn в Compose с reverseLayout = true. При стриминге последнее сообщение обновляется на месте без перескакивания скролла. Индикация контекстного окна (визуальная полоска или счётчик токенов) снижает жалобы на забывчивость ассистента.

Что мы предлагаем и сроки

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

• Документация по архитектуре управления историей
• Исходный код модуля контекстного окна с тестами
• Интеграция с выбранной моделью AI (GPT, Claude, YandexGPT)
• Настройка подсчёта токенов и мониторинга расходов
• Обучение команды работе с системой

Ориентиры по срокам

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

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 в месяц).