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+. Inference 30-денного прогнозу на iPhone 14 займає < 5ms.
Підготовка даних та ознаки
Якість прогнозу визначається не моделлю, а ознаками. З історії транзакцій формуємо:
- скользящее середнє видатків за 7/30/90 днів по категоріях
- день тижня та день місяця (сезонність всередині місяця—реальна: видатки 25-го числа системно відрізняються від 10-го)
- флаг "recurring": платежі з регулярним інтервалом (Netflix, аренда, кредит)
- відхилення поточного періоду від середнього—z-score трат
Recurring-платежі—спеціальний випадок. Детектуйте окремо: кластеризація за amount ± 5% + періодичність. Хорошо працює простий алгоритм: групуємо трансакції одного мерчанта, рахуємо медіану інтервалу, якщо StdDev < 3 дні—це recurring.
Моделі: що використовувати
Для часових рядів фінансових даних з об'ємом історії 3–24 місяці добре працюють три підходи:
| Модель | Коли підходить | Складність реалізації |
|---|---|---|
| ARIMA / SARIMA | Мало даних, без нелінійності | Низька |
| LightGBM / XGBoost | Змішані ознаки, таблиці | Середня |
| LSTM / Transformer | Складні паттерни, багато історії | Висока |
На практиці для більшості додатків LightGBM перевищує LSTM при об'ємі історії < 2 років. Менше даних—простіша модель. LSTM переобучується на коротких рядах. LightGBM конвертується в TFLite через tf.lite.TFLiteConverter + ONNX проміжний формат.
Серверна частина: переобучення та персоналізація
Раз на тиждень (або при додаванні N нових транзакцій) серверна частина дообучає персональну модель на даних конкретного користувача. Схема: базова глобальна модель + fine-tuning на персональній історії.
Федеративне обучение (Federated Learning)—опція для додатків з вимогами до приватності. Google FL через 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 тижнів.