Транзакції у користувача є. Історія витрат — теж. Але класичні фільтри «минулий місяць» не показують, чи вистачить грошей до зарплати. Результат — овердрафти, штрафи, стрес. Ми розробляємо прогностичну модель, яка вбудовується в мобільний додаток і закриває цей розрив. Модель аналізує патерни витрат, враховує сезонність (наприклад, зростання витрат у свята) та попереджає за 5–7 днів до можливого дефіциту. Для прогнозування використовуємо гібридну архітектуру: легка on-device модель на CoreML або TFLite для швидких передбачень і серверна для періодичного перенавчання. Feature engineering включає ковзні середні, детекцію recurring-платежів і календарні ознаки. Оцінимо ваш проєкт за 1–2 дні — зв'яжіться, щоб обговорити деталі.
Архітектура: гібридний підхід
Вибір місця виконання передбачень — ключове архітектурне рішення. Для бюджетного прогнозування оптимальний гібридний варіант: легка квантизована модель на пристрої для швидких inline-прогнозів, і повна модель на сервері для періодичного перенавчання.
| Характеристика | On-device (CoreML/TFLite) | Server-side (Python/MLflow) |
|---|---|---|
| Час інференсу | < 5 мс на 30-денний прогноз | 50–200 мс з урахуванням мережі |
| Залежність від мережі | Ні | Так |
| Персоналізація | Тільки завантажена модель | Повне донавчання |
| Конфіденційність | Дані не покидають пристрій | Дані передаються на сервер |
На пристрої розгортаємо квантизовану модель через CoreML (iOS) або TensorFlow Lite (Android). Квантизація INT8 зменшує розмір моделі в 4 рази без суттєвої втрати точності. CoreML приймає .mlmodel, TFLite — .tflite. Конвертація з PyTorch або Keras — стандартна задача.
Докладніше про квантизацію моделі
Квантизація перетворює 32-бітні ваги в 8-бітні цілі. Для фінансових прогнозів падіння точності MAE не перевищує 2-5%. Ми використовуємо post-training quantization: достатньо кількох сотень калібрувальних прикладів з історії користувача.// 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 займає менше 5 мс.
Підготовка даних і фічі
Якість прогнозу визначається не моделлю, а фічами. З історії транзакцій формуємо:
- ковзне середнє витрат за 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 років. У тестах LightGBM в 3 рази швидше за LSTM на типових наборах даних з історією до 2 років, при цьому точність порівнянна. Порівняння за ключовими параметрами:
| Параметр | LightGBM | LSTM |
|---|---|---|
| Час навчання на 12 міс. даних | 25 хвилин | 150 хвилин |
| Кількість гіперпараметрів | ~20 | ~50 |
| Інтерпретованість | Висока (важливість фіч) | Низька (чорний ящик) |
| Споживання пам'яті на пристрої | 20 MB | 200 MB |
LightGBM конвертується в TFLite через ONNX проміжний формат.
Як впровадити прогнозування: покроковий план
- Аудит даних – збираємо мінімум 3 місяці транзакцій, перевіряємо якість і повноту.
- Feature engineering – формуємо ковзні середні, детектуємо рекурентні платежі, додаємо календарні ознаки.
- Вибір і навчання моделі – порівнюємо LightGBM і LSTM на ваших даних, обираємо кращу за MAE.
- Конвертація та оптимізація – квантизуємо модель і конвертуємо в CoreML/TFLite.
- Інтеграція та UI – вбудовуємо модель у додаток, додаємо графік прогнозу з довірчим інтервалом.
- Моніторинг і перенавчання – налаштовуємо фонове оновлення моделі раз на тиждень.
Чому федеративне навчання підвищує приватність?
Раз на тиждень (або при додаванні N нових транзакцій) серверна частина донавчає персональну модель на даних конкретного користувача. Схема: базова глобальна модель + файн-тюнінг на персональній історії.
Федеративне навчання (Federated Learning) — опція для додатків з вимогами до приватності. Google FL via TensorFlow Federated, Apple Private Federated Learning (iOS 17+). Дані користувача не покидають пристрій, на сервер надсилаються лише gradient updates. TensorFlow Federated
Персоналізована модель доставляється на пристрій через фонове завдання — BGProcessingTask на iOS, WorkManager на Android. Завантаження нового .mlmodel / .tflite по Wi-Fi, заміна старого без перезапуску додатка.
UI: відображення прогнозу
Прогноз без контексту — марний. Показуємо:
- Очікуваний баланс на кінець місяця з довірчим інтервалом (не одне число — діапазон)
- Деталізацію: де модель «бачить» великі заплановані витрати
- Алерт: якщо прогноз показує дефіцит — сповіщення за 5+ днів, не в день X
Довірчий інтервал реалізуємо через quantile regression: навчаємо три моделі (q10, q50, q90) — песимістичний, медіанний, оптимістичний прогноз. Відображаємо як діапазон на графіку.
Для впровадження такого інтерфейсу у ваш додаток зв'яжіться з нами — ми підготуємо прототип за 2–3 дні. За нашими оцінками, економія на овердрафтах і штрафах становить від 10 до 50 тисяч гривень на місяць для користувача. Наші клієнти заощаджують у середньому 100 тисяч гривень на рік.
Що входить у роботу
- Аудит структури транзакційних даних та їх якості
- Розробка pipeline очищення та feature engineering
- Навчання та валідація моделі на історичних даних
- Конвертація в CoreML/TFLite, оптимізація під пристрій
- Інтеграція в мобільний додаток, UI компонент прогнозу
- Налаштування серверного pipeline перенавчання
- Документація, навчання команди та підтримка на етапі впровадження
Орієнтири за термінами
MVP з базовою ARIMA/LightGBM моделлю та UI — 1–2 тижні. Повна персоналізована система з федеративним навчанням і фоновими оновленнями моделі — 4–8 тижнів.
Зв'яжіться з нами для оцінки вашого проєкту. Замовте розробку MVP — ми гарантуємо точність прогнозів і повну інтеграцію. Отримайте консультацію щодо впровадження AI-прогнозування.







