Реализация AI-прогнозирования бюджета пользователя в мобильном приложении
Транзакции у пользователя есть. История трат — тоже. Проблема в том, что классические фильтры «прошлый месяц» не говорят, хватит ли денег до зарплаты. Прогностическая модель, встроенная в мобильное приложение, закрывает этот gap: смотрит на паттерны, учитывает сезонность, предупреждает до того, как баланс уйдёт в минус.
Архитектура: на устройстве или сервер
Первый вопрос — где считать. Для бюджетного прогнозирования ответ почти всегда «гибридно»: лёгкая модель на устройстве для быстрого inline-прогноза, тяжёлая на сервере для переобучения и персонализации.
На устройстве разворачиваем квантизованную модель через CoreML (iOS) или TensorFlow Lite (Android). CoreML принимает .mlmodel формат, TFLite — .tflite. Обе можно получить конвертацией из PyTorch или Keras.
// iOS: загрузка CoreML модели и предсказание
import CoreML
class BudgetForecaster {
private let model: BudgetForecastModel
init() throws {
let config = MLModelConfiguration()
config.computeUnits = .cpuAndNeuralEngine
model = try BudgetForecastModel(configuration: config)
}
func predictBalance(features: BudgetForecastModelInput) throws -> Double {
let output = try model.prediction(input: features)
return output.predictedBalance
}
}
computeUnits = .cpuAndNeuralEngine — модель использует Neural Engine на A12+ чипах. Инференс 30-дневного прогноза на iPhone 14 занимает < 5ms.
Подготовка данных и фичи
Качество прогноза определяется не моделью, а фичами. Из истории транзакций формируем:
- скользящее среднее расходов за 7/30/90 дней по категориям
- день недели и день месяца (сезонность внутри месяца — реальная: расходы 25-го числа системно отличаются от 10-го)
- флаг «recurring»: платежи с регулярным интервалом (Netflix, аренда, кредит)
- отклонение текущего периода от среднего — z-score трат
Recurring-платежи — особый случай. Их нужно детектировать отдельно: кластеризация по amount ± 5% + периодичность. Хорошо работает простой алгоритм: группируем транзакции одного merchant, считаем медиану интервала между ними, если StdDev < 3 дня — это recurring.
Модели: что использовать
Для временных рядов финансовых данных с объёмом истории 3–24 месяца хорошо работают три подхода:
| Модель | Когда подходит | Сложность реализации |
|---|---|---|
| ARIMA / SARIMA | Мало данных, нет нелинейности | Низкая |
| LightGBM / XGBoost | Смешанные фичи, таблицы | Средняя |
| LSTM / Transformer | Сложные паттерны, много истории | Высокая |
На практике для большинства приложений LightGBM выигрывает у LSTM при объёме истории < 2 лет. Меньше данных — проще модель. LSTM переобучается на коротких рядах. LightGBM конвертируется в TFLite через tf.lite.TFLiteConverter + ONNX промежуточный формат.
Серверная часть: переобучение и персонализация
Раз в неделю (или при добавлении N новых транзакций) серверная часть дообучает персональную модель на данных конкретного пользователя. Схема: базовая глобальная модель + файн-тюнинг на персональной истории.
Федеративное обучение (Federated Learning) — опция для приложений с требованиями к приватности. Google FL via TensorFlow Federated, Apple Private Federated Learning (iOS 17+). Данные пользователя не покидают устройство, на сервер отправляются только gradient updates.
Персонализированная модель доставляется на устройство через фоновую задачу — BGProcessingTask на iOS, WorkManager на Android. Загрузка нового .mlmodel / .tflite по Wi-Fi, замена старого без перезапуска приложения.
UI: отображение прогноза
Прогноз без контекста — бесполезен. Показываем:
- Ожидаемый баланс к концу месяца с доверительным интервалом (не одно число — диапазон)
- Детализация: где модель «видит» крупные запланированные траты
- Алерт: если прогноз показывает дефицит — уведомление за 5+ дней, не в день X
Доверительный интервал реализуем через quantile regression: обучаем три модели (q10, q50, q90) — пессимистичный, медианный, оптимистичный прогноз. Отображаем как диапазон на графике.
Процесс работы
Аудит структуры транзакционных данных и их качества. Разработка pipeline очистки и feature engineering. Обучение и валидация модели на исторических данных. Конвертация в CoreML/TFLite, оптимизация под устройство. Интеграция в мобильное приложение, UI компонент прогноза. Настройка серверного pipeline переобучения.
Ориентиры по срокам
MVP с базовой ARIMA/LightGBM моделью и UI — 1–2 недели. Полная персонализированная система с федеративным обучением и фоновыми обновлениями модели — 4–8 недель.