Когда я решил автоматизировать категоризацию трат в Drebedengi.ru, начал с простого: обучил локальную ML-модель на своей истории расходов и отдал ей всю работу. Но со временем проект прошёл три крупных этапа — и каждый оказался отдельным приключением, с погружением в алгоритмы, реверс-инжиниринг API и тем самым вайбкодингом, когда пишешь ночью «на ощущениях», а потом неделю всё шлифуешь.
Этап 1. Чистый ML
Выгрузил бэкап данных из Drebedengi, очистил и нормализовал комментарии, выделил временные признаки (день недели, час, месяц), добавил сумму и категориальные признаки, векторизовал текст с TF-IDF. Обучил пару классических моделей, выбрал лучшую по F1-метрике.
Результат был рабочим, но не идеальным: новые магазины или редкие формулировки снижали точность, а без регулярного дообучения качество быстро падало.
Этап 2. ML + ручная категоризация
Чтобы снизить количество ошибок, сделал Telegram-бота с интерактивным выбором. Модель предсказывала топ-3 категорий, бот показывал кнопки, и я мог быстро выбрать правильную. Выбранная категория отправлялась обратно в Drebedengi.
Пришлось погрузиться в их API.
Много логики родилось в режиме вайбкодинга: сначала быстро «накидать, чтобы работало», потом отлаживать до стабильности.
Этап 3. ML + LLM + ручная категоризация
Дальше я подключил Google Gemini. Теперь процесс такой:
ML предсказывает топ-3 категорий.
LLM получает список расходов и возвращает свои топ-3.
Списки объединяются, дубликаты убираются, в Telegram я вижу до 8 кнопок (6 от моделей + служебные Удалить + Пропустить).
Если уверенность ML выше заданного порога, система сама меняет категорию в Drebedengi, удаляя старую запись и создавая новую с пометкой [Категоризировано ботом: ...].
Если уверенность низкая — получаю уведомление и выбираю сам.
Оставлен и резервный вариант: если ML недоступна или даёт сбой, подключается упрощённый keyword-классификатор по словарю.
Сложности
Исследование API Drebedengi
Вайбкодинг
Многие фичи, вроде автокатегоризации по расписанию или объединения прогнозов ML и LLM, появились после ночных сессий, когда архитектура ещё не была окончательной, а хотелось «чтобы завтра работало».
Баланс уверенности ML
Слишком низкий порог — и много ошибок, слишком высокий — почти всё уходит на ручную проверку.
|