Категоризация доходов/расходов банковской выписки (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 со статусом: ok, changes_count: 0 — у вас уже есть рабочий rule-based layer, который совпадает с category. Задача не строить классификатор с нуля, а добавить LLM-fallback для неоднозначных случаев.

В description_raw встроены MCC-коды (5411, 5814, 5541, 5912) — 70-80% транзакций классифицируются через ISO 18245 без LLM. Но MCC = сигнал, не истина: ABTS BARTOLILLOS имеет MCC 5422 (мясо/мясник), а у вас Entertainment — нужна проверка по названию торговца.

Реальный список — 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. Так что для чистого локального развертывания с вашей скоростью нужен GPU-сервер с vLLM, или regex закрывает 95%+ трафика и LLM обрабатывает лишь 1-5 tx/100 — тогда локально нормально.
4. Стабильность выхода — JSON schema через Instructor или Outlines + temperature=0. Это дает валидный формат и очень низкую вариативность. 100% детерминизм невозможен ни у одного LLM-провайдера (GPU reduction order, известная проблема Ollama #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 (Speed & Privacy): Для соблюдения тайминга < 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 и постпродакшн-сопровождение
✅ Договор c компанией, гарантированный результат!
🔥 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-модуля:

Интеллектуальный Pre-processing: Перед отправкой в 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:
- Инференс ~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 со строгими категориями без лишнего «мусора». Архитектуру сделаю на базе абстрактных парсеров: это позволит быстро подключать новые банки, просто описывая маппинг полей, не переписывая логику классификатора. На связи буду и после сдачи, если понадобится дотюнить точность на специфических транзакциях.