Категоризація доходів/розходів банківської виписки (LLM модель)

Бюджет: 25000 UAH Термін: 10 днів

Досвід роботи з розробкою модулів для інтеграції зовнішніх моделей і API, у тому числі з налаштуванням локальних ML/LLM рішень, дозволяє ефективно побудувати вашу систему категоризації. Із врахуванням вимог по швидкості (до 2 сек на 100 транзакцій) і суворості відповідей — рекомендую реалізувати шар кешування і обробляти запити батчами.

Можу допомогти організувати обробку вхідного JSON і формувати вихід із категоріями за заданим списком. Для локальної LLM можна використовувати легкі моделі з оптимізацією під вашу задачу, або підключити зовнішні сервіси з чітким контролем вартості.

Враховуючи, що проєкт на Python, можу надати API (наприклад REST) з PHP або Laravel для прийому і віддачі даних, якщо це знадобиться для подальшої інтеграції. Мій досвід включає роботу з REST API, Docker для ізоляції середовища, Git, MySQL/PostgreSQL, що допоможе в масштабуванні і підтримці проекту.

Також можу допомогти із налаштуванням швидкого розпізнавання та адаптації для нових банків за рахунок побудови системи шаблонів правил та парсингу, які доповнюватимуть категоризацію.

Готовий приступити до технічного обговорення деталей, щоб точно реалізувати вимоги по швидкості, точності і масштабованості.

Бюджет: 2000 UAH Термін: 14 днів

Зробив собі таке рішення - аналіз фінансових даних помісячно. Можу реалізувати для вас під ваш запит і вимоги.

Бюджет: 7497 UAH Термін: 7 днів

Вітаю! Подивився output.json — важливі моменти: Блок heuristic зі status: ok, changes_count: 0 — у вас вже є робочий rule-based layer, який сходиться з category. Задача не будувати класифікатор з нуля, а додати LLM-fallback для ambiguous cases.

У description_raw вбудовані MCC-коди (5411, 5814, 5541, 5912) — 70-80% транзакцій класифікуються через ISO 18245 без LLM. Але MCC = сигнал, не істина: ABTS BARTOLILLOS має MCC 5422 (meat/butcher), а у вас Entertainment — потрібна перевірка по merchant name.

Реальний список — 16+ категорій, не 12. Restaurants ≠ Food, P2P self, Subscriptions, Cash withdrawal. Архітектура: MCC → heuristic → LLM тільки для low-confidence → cache. $0.001/100tx при 85% coverage без LLM. Я новий на Freelancehunt, щоденно пишу з LLM у проді (StratBase.ai).

Бюджет: 3000 UAH Термін: 4 дні

Привіт, я з нетерпінням чекаю можливості реалізувати проєкт категоризації доходів та расходів банківської виписки за допомогою моделі великого мовиового моделю (LLM). Я впевнений у своїй здатності виконати це завдання, оскільки маю досвід роботи з подібними проєктами й знаю, як створити ефективну систему категоризації. Для реалізації цього проєкту я використаю технічні засоби обробки природної мови, такі як бібліотеки TensorFlow або PyTorch, щоб розробити й навчити модель LLM на наявних даних, забезпечивши високий рівень точності категоризації. Крім того, я зверну особливу увагу на етапи передобробки даних, наприклад, нормалізацію текстових даних, щоб підвищити якість результуючої моделі.

Бюджет: 11000 UAH Термін: 7 днів

Добрий день.
Готовий взяти Ваш проект у роботу.
Зможу розробити для Вас таку автоматизацію для категоризації виписок за допомогою n8n.
Пишіть в особисті, обговоримо всі нюанси і зможемо приступити до реалізації.

Бюджет: 1000 UAH Термін: 1 день

Вітаю! Ми — команда NovaCore Solutions. Маємо значний досвід у розробці фінтех-рішень та систем обробки банківських транзакцій. Ми спеціалізуємося на створенні високопродуктивних модулів для структурування фінансових даних та їх категоризації за допомогою LLM. Для вашого запиту ми можемо запропонувати оптимізоване рішення на базі локальних моделей (наприклад, архітектури Llama або BERT-подібних моделей, донавчених під класифікацію), що забезпечить необхідну швидкість (до 2 сек на 100 транзакцій), жорстку валідацію відповідей та мінімальну собівартість. Оскільки ми вже реалізовували масштабні CRM-системи з фінансовими модулями, ми розуміємо специфіку роботи з різними банківськими форматами та можемо побудувати універсальний парсер для швидкого додавання нових банків. Готові обговорити технічні деталі та архітектуру модуля.

Бюджет: 15000 UAH Термін: 8 днів

Костянтин подивився example.json — 232 транзакції з Banamex, іспанські merchant-рядки (OXXO, DIDI, FARMACIA SIMI), RFC-коди в description_raw, поле category вже заповнене ("Medical" у першому записі). Задача не просто виклик LLM — стабільний модуль під 4 constraints: валідна структура виходу, 50 tx/сек, $0.005/100 tx, 30+ банків.

Маю робочий код на Ollama з витягом структурованих даних через JSON schema — механіка під вашу задачу близька.

Під 7 ваших пунктів:

1. Вхід — ваш JSON без змін структури.
2. Модуль — categorize(transactions) -> list[dict] Python з type hints, вбудовується в наявний проект без важких залежностей.
3. LLM — гібрид: regex-шар закриває очевидні маркери (NOMINA → Salary, SPEI → P2P, OXXO → Food тощо), LLM обробляє неоднозначні випадки. За публічним прайсом на 17.04.2026: Gemini 2.5 Flash ~$0.002/100 tx, GPT-4o-mini ~$0.003/100 tx — обидві в рамках вашого ліміту $0.005. Batch API (50% знижка) — якщо можна обробляти пакетами з лагом до 24 годин, інакше sync-тарифи вище. Локальна Llama 3.1 8B через Ollama — опція, але на споживчих Mac вона реально тягне 1-3 tx/сек, не 50. Тож для чистого локал-deploy з вашою швидкістю потрібен GPU-сервер з vLLM, або regex закриває 95%+ трафіку і LLM обробляє лише 1-5 tx/100 — тоді локально норм.
4. Стабільність виходу — JSON schema через Instructor або Outlines + temperature=0. Це дає валідний формат і дуже низьку варіативність. 100% детермінізм неможливий у жодного LLM-провайдера (GPU reduction order, відомий Ollama issue #5321), тому додам evaluation-звіт зі стабільністю повторних прогонів на ваших даних.
5. Швидкість 100 tx / 2 сек — досягається через 20-50 паралельних async-викликів до Gemini Flash / GPT-4o-mini. Локально без GPU — через regex-first архітектуру.
6. Вихід — ваш JSON, поле category перезаписується значенням зі списку + додаю confidence per tx + evaluation-звіт на прогоні по всьому файлу.
7. 30 банків — bank-agnostic промпт по description_normalized + config merchant→category (YAML/JSON). Додавання нового банку — рядки в config, без змін коду. Ваш JSON вже уніфікований — великих перепрошивок не треба.

Одне уточнення: ви хочете покращити наявну категоризацію (у прикладі вже є "Medical") чи переробити з нуля? Це змінює пріоритети — при покращенні треба порівняти з baseline-ом і не зіпсувати існуюче. Розгорнути

Бюджет: 12000 UAH Термін: 5 днів

Здравствуйте
Приклад моєї реалізації AI-інтерфейсу:
https://217-154-170-186.nip.io/
моє технічне рішення для проєкту:
Локальна LLM (Швидкість і Конфіденційність): Для дотримання таймінгу < 2 сек я пропоную використовувати локальну модель Phi-3-mini або Llama-3-8B, розгорнуту через vLLM або Ollama. Це дасть нульову вартість транзакції та миттєву обробку батчами.

Суворий формат (JSON Guard): Щоб модель не «фантазувала», я використовую бібліотеку Instructor або Outlines. Це гарантує, що на виході буде тільки валідний JSON і тільки категорії з вашого списку (Enum).

Оптимізація вартості: Якщо виберемо зовнішнє API, то GPT-4o-mini обійдеться приблизно в $0.0007 за 100 транзакцій, що в 7 разів дешевше вашого ліміту ($0.005).

Універсальність для 30+ банків: LLM працює з семантикою тексту (description), тому нам не потрібно писати регулярні вирази під кожен банк. Достатньо подавати очищене поле опису та MCC-код.
ГІТ: https://github.com/onyx144 Розгорнути

Бюджет: 10000 UAH Термін: 1 день

✋ Доброго дня! Ми IT-компанія dZENcode.

Ми можемо розробити для вас модуль категоризації транзакцій під цю задачу.

Чи є у вас приклади транзакцій та потрібних категорій для навчання?
Чи потрібно одразу закладати налаштування під нові банки?

Докладну інформацію про наші послуги та ставки ви знайдете на сайті: Freelancehunt
Подивіться – далі обговоримо деталі роботи, пишіть, коли будете готові.

Фінальна вартість формується тільки після уточнення обсягу та вимог.

___________________
З повагою,
Менеджер dZENcode

Наші сильні сторони:
💎 10+ років надаємо IT-послуги: Аутсорс, Аутстаф
🔥 90+ штатних спеціалістів
🚀 Проекти «з нуля» та на підтримку
⚙️ SLA та постпродакшн-супровід
✅ Договір з компанією, гарантований результат!
🔥 250+ публічних відгуків з 2015 року. Розгорнути

Бюджет: 8000 UAH Термін: 7 днів

Привіт, працював з парсерами файлами, рахуйте вже є готовий скрипт. Пропоную не все робити через ллм, т.я. вона може галюцинувати і видавати хибні відповіді. Звертайтесь в особисті, виконаю все якісно, швидко та по вашому бюджету '.

Бюджет: 11000 UAH Термін: 6 днів

Вітаю.

Переглянув ваш JSON і бачу, що тут потрібен не просто LLM-виклик, а стабільний гібридний модуль категоризації. У даних багато шуму: 232 транзакції, 217 унікальних raw-описів, іспанські merchant-рядки, RFC, технічні коди, різні банки та сильний перекіс по категоріях. Тому чиста генерація без проміжного шару буде нестабільною.

Для цього кейсу я б збирав рішення так:
- спочатку нормалізація description_raw і bank-specific mapping полів
- далі rule layer для очевидних патернів і повторюваних мерчантів
- основна категоризація через fastText як детермінований швидкий класифікатор
- Qwen/Qwen2.5-3B-Instruct як fallback для спірних або низькоконфідентних транзакцій
- вихід тільки у жорсткий JSON зі списком дозволених категорій

Такий підхід дає потрібну швидкість, бо fastText добре працює на звичайному CPU і підходить для batch-обробки. Для 100 транзакцій до 2 секунд це реалістичніший шлях, ніж робити все через чисту LLM. Qwen2.5-3B-Instruct я б використовував лише там, де правила і класифікатор не дають впевненого результату, щоб зберегти стабільність і контроль по категоріях.

Перед початком роботи маю уточнити:
- приклад вхідного JSON у повному форматі
- фінальний список категорій
- чи є розмічений набір транзакцій для перевірки якості
- які банки критичні для першої черги

В особистих відповім на всі питання, можу зробити PoC на вашому JSON і показати точність, швидкість та стабільність гібридної схеми до повної реалізації. Розгорнути

Бюджет: 2000 UAH Термін: 2 дні

Доброго дня, взагалі-то таке можна зробити і без LLM, також можна комбінувати - код+LLM.

Бюджет: 10000 UAH Термін: 1 день

Вітаю! Зможу реалізувати. Відпишіть в приват щоб обговорити всі деталі. Буду рад співпраці!

Бюджет: 10000 UAH Термін: 5 днів

Доброго дня
судячи з прикладеного json, потрібно буде або робити файн-тюнінг моделі, або навчати свою з нуля, оскільки у багатьох виписках призначення платежу незрозуміле.
Для класифікації краще в цьому випадку вибрати не llm, а bert або ембеддинг модель.

Бюджет: 14000 UAH Термін: 5 днів

Вітаю, Константине! Я Ніна, менеджер інженера Валентина.

Ми детально проаналізували ваш приклад JSON з транзакціями банку Banamex. Ми бачимо специфіку даних: іспанські описи мерчантів (OXXO, DIDI, SIMI), наявність податкових ідентифікаторів (RFC) та необхідність мапінгу на ваш строгий список категорій.

Наше рішення для вашого Python-модуля:

Інтелектуальне попереднє оброблення: Перед відправкою в LLM модуль буде автоматично очищати description_raw від технічних кодів та RFC. Це критично для потрапляння в бюджет < $0.005, оскільки скорочує обсяг токенів в 3 рази.

Семантичний кеш (L1/L2): Ми впровадимо базу знань по ваших транзакціях. Якщо "DIDI FOOD" вже зустрічався, категорія буде присвоєна за 5 мс без звернення до ІІ. Це гарантує швидкість 100 транз / < 1 сек.

Детермінізм через Pydantic: Модель буде працювати в режимі Structured Output. Ми жорстко обмежимо її вашим списком (Зарплата, Телеком, Авто тощо). Варіантів «від себе» не буде фізично.

Batch API: Для нових транзакцій використовуємо пакетну обробку, що вписується в ліміт $0.001 за 100 рядків.

Термін: 5–7 днів.
Бюджет: 14 000 грн.

Константине, ми вже підготували прототип парсера для вашого формату. Готові продемонструвати точність на розширеному наборі даних.

З повагою, Ніна. Розгорнути

Бюджет: 18000 UAH Термін: 14 днів

Привіт! Працював з подібними задачами — зокрема реалізовував систему виявлення фродових транзакцій, що є значно складнішою задачею, ніж категоризація. Тому одразу бачу тут кілька підводних каменів.
LLM у продакшені не спрацює стабільно в межах ваших вимог — латентність непередбачувана, а вартість важко контролювати при масштабуванні.

Я б побудував інакше:

Основа — навчений FastText-класифікатор, а не LLM:
- Inference ~0.1 сек на 100 транзакцій (у 20 разів швидше за вашу вимогу)
- Вартість після навчання: $0
Навчальні дані — розмічаємо 3–5k транзакцій через GPT-4o-mini Batch API (~$0.10 одноразово), тренуємо модель, далі вона працює автономно.
LLM залишається тільки як fallback для транзакцій з низькою впевненістю — там де класифікатор не впевнений.
Підтримка 30+ банків — через конфіг-файли per-банк для маппінгу полів. Новий банк підключається без зміни логіки класифікатора.
Пропоную обговорити деталі співпраці в особистих повідомленнях Розгорнути

Бюджет: 12000 UAH Термін: 10 днів

Вітаю! Пропоную реалізувати модуль класифікації на базі ансамблю моделей LightGBM, XGBoost та CatBoost. Таке рішення краще підходить для цієї задачі, оскільки забезпечує високу швидкість обробки навіть на звичайному CPU та стабільні, передбачувані результати.

Маю 4 роки досвіду розробки на Python і створення систем аналізу даних, тому зможу побудувати гнучку архітектуру з можливістю швидкого масштабування та додавання нових банків. Модуль працюватиме повністю локально та чітко дотримуватиметься заданих категорій і формату JSON.

Пропоную обговорити деталі технічного завдання, буду радий співпраці!

Бюджет: 18500 UAH Термін: 9 днів

Доброго дня.

Ознайомився з прикладом файлу. Формат завдання зрозумілий: тут потрібен не просто виклик LLM, а акуратний Python-модуль, який стабільно приймає банківський JSON, нормалізує транзакції і повертає строго валідний JSON з категоризацією в рамках заданого списку.

За прикладом видно, що важливо зберегти передбачуваність результату, жорстку структуру відповіді, високу швидкість обробки і можливість масштабувати рішення під різні банки без переробки всієї логіки.

Я б реалізував це як надійний модуль з кількома рівнями обробки:
— прийом і валідація вхідного JSON
— нормалізація описів транзакцій
— категоризація у фіксовані категорії
— строгий JSON на виході
— логіка, яку можна швидко адаптувати під нові банки
— оптимізація під швидкість і вартість обробки

В таких завданнях я роблю акцент не на “вільній відповіді моделі”, а на контрольованому і практично застосовному результаті, який можна вбудувати в продукт без сюрпризів.

Готовий подивитися фінальні вимоги до вхідного формату і одразу запропонувати оптимальну архітектуру реалізації. Розгорнути

Бюджет: 15000 UAH Термін: 7 днів

Вітаю! Я засновник інженерного агентства Vaysed.
Ми будуємо екосистеми, де штучний інтелект працює під суворим контролем детермінованих алгоритмів. Я проаналізував наданий файл, де фігурують транзакції банку Banamex, поле description_raw та типові мерчанти на кшталт OXXO чи DIDI FOOD. Завдання ідеально лягає під наш профіль.

Обробляти 100 транзакцій через LLM за 2 секунди "в лоб" при бюджеті < $0.005 — це інженерний виклик, який не вирішується простим написанням промпту. Ось як ми гарантуємо заявлену швидкість та жорсткий формат виводу:
Семантичний кеш замість LLM: Більшість транзакцій користувачів регулярно повторюються. Ми імплементуємо проміжний шар бази даних (Redis + PostgreSQL). Якщо система вже знає мерчанта, категорія присвоюється миттєво (за 5-10 мілісекунд) взагалі без звернення до нейромережі. Це зводить вартість обробки 80% масиву до нуля.
Батчинг та детермінований парсинг: Для нових транзакцій (наприклад, невідомих P2P-переказів) наш Python-модуль формуватиме пакетні запити (batches). Щоб гарантувати абсолютну жорсткість відповідей (вимога №4), ми застосуємо бібліотеки структурного виводу (Outlines або Instructor). Модель на рівні генерації токенів буде обмежена вашим списком (Salary, Telecom тощо) і фізично не зможе видати галюцинацію чи відхилення від формату.
Універсальний адаптер: Модуль нормалізуватиме вхідний масив незалежно від структури банку, передаватиме очищені дані в рушій категоризації та повертатиме фінальний JSON.

У якості моделі ми можемо розгорнути локальну оптимізовану версію (на базі vLLM для надшвидкого інференсу) або використати gpt-4o-mini у пакетному режимі, що з запасом вписується у ваш фінансовий ліміт.

Ми створюємо надійні data-архітектури та мікросервіси корпоративного рівня. Оцінити наш інженерний підхід та реалізовані кейси можна в портфоліо: https://vaysed.me/

Напишіть мені, і ми узгодимо архітектуру модуля та терміни розгортання! Розгорнути

Бюджет: 10000 UAH Термін: 14 днів

Для такої задачі найкраще підійде невелика локальна модель на кшталт Llama 3 або Mistral, прогнана через vLLM або Ollama — це єдиний спосіб вписатися у ваш ліміт по бюджету і видати результат швидше 2 секунд. Я реалізую модуль з використанням Structured Output (через Instructor або Outlines), щоб на виході завжди був валідний JSON зі строгими категоріями без зайвого «сміття». Архітектуру зроблю на базі абстрактних парсерів: це дозволить швидко підключати нові банки, просто описуючи маппінг полів, не переписуючи логіку класифікатора. На зв'язку буду і після здачі, якщо знадобиться дотюнити точність на специфічних транзакціях.