Kategoryzacja dochodów/wydatków wyciągu bankowego (model LLM)

Budżet: 25000 UAH Termin: 10 dni

Doświadczenie w opracowywaniu modułów do integracji zewnętrznych modeli i API, w tym z konfiguracją lokalnych rozwiązań ML/LLM, pozwala efektywnie zbudować Twój system kategoryzacji. Biorąc pod uwagę wymagania dotyczące szybkości (do 2 sek na 100 transakcji) i surowości odpowiedzi — zalecam wdrożenie warstwy cache i przetwarzanie zapytań w partiach.

Mogę pomóc w organizacji przetwarzania przychodzącego JSON i formować wyjście z kategoriami według podanej listy. Dla lokalnego LLM można używać lekkich modeli z optymalizacją pod Twoje zadanie, lub podłączyć zewnętrzne usługi z wyraźną kontrolą kosztów.

Biorąc pod uwagę, że projekt jest w Pythonie, mogę dostarczyć API (na przykład REST) z PHP lub Laravel do przyjmowania i zwracania danych, jeśli będzie to potrzebne do dalszej integracji. Moje doświadczenie obejmuje pracę z REST API, Dockerem do izolacji środowiska, Git, MySQL/PostgreSQL, co pomoże w skalowaniu i wsparciu projektu.

Mogę również pomóc w konfiguracji szybkiego rozpoznawania i adaptacji dla nowych banków poprzez budowę systemu szablonów reguł i parsowania, które uzupełnią kategoryzację.

Jestem gotów przystąpić do technicznej dyskusji szczegółów, aby dokładnie zrealizować wymagania dotyczące szybkości, dokładności i skalowalności.

Budżet: 2000 UAH Termin: 14 dni

Zrobiłem sobie takie rozwiązanie - analiza danych finansowych miesięcznie. Mogę zrealizować to dla Ciebie zgodnie z Twoim zapytaniem i wymaganiami.

Budżet: 7497 UAH Termin: 7 dni

Cześć! Przejrzałem output.json — ważne punkty:
Blok heurystyczny ze status: ok, changes_count: 0 — już masz działającą warstwę opartą na regułach, która zgadza się z kategorią. Zadanie polega na dodaniu LLM-fallback dla przypadków niejednoznacznych.

W description_raw wbudowane są kody MCC (5411, 5814, 5541, 5912) — 70-80% transakcji klasyfikowanych jest przez ISO 18245 bez LLM. Ale MCC = sygnał, nie prawda: ABTS BARTOLILLOS ma MCC 5422 (mięso/rzeźnik), a u was Entertainment — potrzebna jest weryfikacja po nazwie sprzedawcy.

Rzeczywista lista — 16+ kategorii, nie 12. Restauracje ≠ Żywność, P2P self, Subskrypcje, Wypłata gotówki.
Architektura: MCC → heurystyka → LLM tylko dla niskiej pewności → cache. $0.001/100tx przy 85% pokryciu bez LLM. Jestem nowy na Freelancehunt, codziennie piszę z LLM w produkcji (StratBase.ai).

Budżet: 3000 UAH Termin: 4 dni

Cześć, z niecierpliwością czekam na możliwość realizacji projektu kategoryzacji przychodów i wydatków z wyciągu bankowego za pomocą modelu dużego modelu językowego (LLM). Jestem pewny swojej zdolności do wykonania tego zadania, ponieważ mam doświadczenie w pracy nad podobnymi projektami i wiem, jak stworzyć efektywny system kategoryzacji. Do realizacji tego projektu wykorzystam techniczne narzędzia przetwarzania języka naturalnego, takie jak biblioteki TensorFlow lub PyTorch, aby opracować i wytrenować model LLM na dostępnych danych, zapewniając wysoki poziom dokładności kategoryzacji. Ponadto zwrócę szczególną uwagę na etapy wstępnego przetwarzania danych, na przykład normalizację danych tekstowych, aby poprawić jakość wynikowego modelu.

Budżet: 11000 UAH Termin: 7 dni

Dzień dobry.
Jestem gotów podjąć się realizacji Państwa projektu.
Mogę opracować dla Państwa automatyzację do kategoryzacji wyciągów za pomocą n8n.
Proszę pisać na prywatne wiadomości, omówimy wszystkie szczegóły i będziemy mogli przystąpić do realizacji.

Budżet: 1000 UAH Termin: 1 dzień

Witaj! Jesteśmy zespołem NovaCore Solutions. Mamy znaczące doświadczenie w opracowywaniu rozwiązań fintech oraz systemów przetwarzania transakcji bankowych. Specjalizujemy się w tworzeniu wysokowydajnych modułów do strukturyzacji danych finansowych oraz ich kategoryzacji za pomocą LLM. Dla Twojego zapytania możemy zaproponować zoptymalizowane rozwiązanie oparte na lokalnych modelach (na przykład architekturze Llama lub modelach podobnych do BERT, dostosowanych do klasyfikacji), które zapewni wymaganą szybkość (do 2 sekund na 100 transakcji), rygorystyczną walidację odpowiedzi oraz minimalny koszt. Ponieważ już realizowaliśmy rozbudowane systemy CRM z modułami finansowymi, rozumiemy specyfikę pracy z różnymi formatami bankowymi i możemy zbudować uniwersalny parser do szybkiego dodawania nowych banków. Jesteśmy gotowi omówić szczegóły techniczne oraz architekturę modułu.

Budżet: 15000 UAH Termin: 8 dni

Kostjantyn spojrzał na example.json — 232 transakcje z Banamex, hiszpańskie linie handlowe (OXXO, DIDI, FARMACIA SIMI), kody RFC w description_raw, pole category już wypełnione ("Medical" w pierwszym wpisie). Zadanie to nie tylko wyzwanie LLM — stabilny moduł pod 4 ograniczeniami: ważna struktura wyjścia, 50 tx/sek, $0.005/100 tx, 30+ banków.

Mam działający kod na Ollama z wyciągiem danych strukturalnych przez JSON schema — mechanika pod twoje zadanie jest bliska.

Pod 7 twoich punktów:

1. Wejście — twój JSON bez zmian struktury.
2. Moduł — categorize(transactions) -> list[dict] Python z type hints, wbudowuje się w istniejący projekt bez ciężkich zależności.
3. LLM — hybryda: warstwa regex zamyka oczywiste znaczniki (NOMINA → Salary, SPEI → P2P, OXXO → Food itd.), LLM przetwarza niejednoznaczne przypadki. Według publicznego cennika na 17.04.2026: Gemini 2.5 Flash ~$0.002/100 tx, GPT-4o-mini ~$0.003/100 tx — obie w ramach twojego limitu $0.005. Batch API (50% zniżki) — jeśli można przetwarzać paczkami z opóźnieniem do 24 godzin, w przeciwnym razie stawki sync są wyższe. Lokalna Llama 3.1 8B przez Ollama — opcja, ale na konsumenckich Macach naprawdę osiąga 1-3 tx/sek, nie 50. Więc dla czystego lokalnego wdrożenia z twoją prędkością potrzebny jest serwer GPU z vLLM, lub regex zamyka 95%+ ruchu, a LLM przetwarza tylko 1-5 tx/100 — wtedy lokalnie jest w porządku.
4. Stabilność wyjścia — JSON schema przez Instructor lub Outlines + temperature=0. To daje ważny format i bardzo niską zmienność. 100% deterministyczność jest niemożliwa u żadnego dostawcy LLM (GPU reduction order, znany problem Ollama #5321), dlatego dodam raport oceny ze stabilnością powtórnych uruchomień na twoich danych.
5. Prędkość 100 tx / 2 sek — osiągana przez 20-50 równoległych wywołań async do Gemini Flash / GPT-4o-mini. Lokalnie bez GPU — przez architekturę regex-first.
6. Wyjście — twój JSON, pole category jest nadpisywane wartością z listy + dodaję confidence per tx + raport oceny na uruchomieniu po całym pliku.
7. 30 banków — bank-agnostic prompt po description_normalized + config merchant→category (YAML/JSON). Dodanie nowego banku — linie w config, bez zmian w kodzie. Twój JSON jest już ujednolicony — nie ma potrzeby dużych przeróbek.

Jedno doprecyzowanie: czy chcesz poprawić istniejącą kategoryzację (w przykładzie już jest "Medical"), czy przerobić od zera? To zmienia priorytety — przy poprawie trzeba porównać z baseline'em i nie zepsuć istniejącego. Rozwiń

Budżet: 12000 UAH Termin: 5 dni

Witaj
Przykład mojej realizacji interfejsu AI:
https://217-154-170-186.nip.io/
moje rozwiązanie techniczne dla projektu:
Lokalny LLM (Szybkość i Prywatność): Aby spełnić wymaganie czasowe < 2 sekundy, proponuję użyć lokalnego modelu Phi-3-mini lub Llama-3-8B, wdrożonego przez vLLM lub Ollama. To zapewni zerowy koszt transakcji i natychmiastowe przetwarzanie wsadowe.

Ścisły format (JSON Guard): Aby model nie "fantazjował", używam biblioteki Instructor lub Outlines. To gwarantuje, że na wyjściu będzie tylko ważny JSON i tylko kategorie z twojej listy (Enum).

Optymalizacja kosztów: Jeśli wybierzemy zewnętrzne API, to GPT-4o-mini będzie kosztować około $0.0007 za 100 transakcji, co jest 7 razy tańsze niż twój limit ($0.005).

Uniwersalność dla 30+ banków: LLM działa z semantyką tekstu (opis), dlatego nie musimy pisać wyrażeń regularnych dla każdego banku. Wystarczy podać oczyszczone pole opisu i kod MCC.
GIT: https://github.com/onyx144 Rozwiń

Budżet: 10000 UAH Termin: 1 dzień

✋ Witaj! Jesteśmy firmą IT dZENcode.

Możemy opracować dla Ciebie moduł kategoryzacji transakcji do tego zadania.

Czy masz przykłady transakcji i potrzebnych kategorii do nauki?
Czy należy od razu uwzględnić konfigurację dla nowych banków?

Szczegółowe informacje o naszych usługach i stawkach znajdziesz na stronie: Freelancehunt
Zobacz – potem omówimy szczegóły pracy, pisz, gdy będziesz gotowy.

Ostateczny koszt ustalany jest dopiero po wyjaśnieniu zakresu i wymagań.

___________________
Z poważaniem,
Menadżer dZENcode

Nasze mocne strony:
💎 10+ lat świadczymy usługi IT: Outsourcing, Outstaffing
🔥 90+ pracowników na etacie
🚀 Projekty „od zera” i wsparcie
⚙️ SLA i wsparcie po produkcji
✅ Umowa z firmą, gwarantowany wynik!
🔥 250+ publicznych opinii od 2015 roku. Rozwiń

Budżet: 8000 UAH Termin: 7 dni

Cześć, pracowałem z parserami plików, więc mam już gotowy skrypt. Proponuję nie wszystko robić przez llm, ponieważ może ona halucynować i wydawać błędne odpowiedzi. Zgłaszajcie się na prywatne wiadomości, wykonam wszystko jakościowo, szybko i w ramach waszego budżetu.

Budżet: 11000 UAH Termin: 6 dni

Witam.

Przejrzałem twój JSON i widzę, że potrzebny jest tutaj nie tylko wywołanie LLM, ale stabilny hybrydowy moduł kategoryzacji. W danych jest dużo szumów: 232 transakcje, 217 unikalnych opisów raw, hiszpańskie linie merchant, RFC, kody techniczne, różne banki i silne przesunięcie w kategoriach. Dlatego czysta generacja bez warstwy pośredniej będzie niestabilna.

Dla tego przypadku zebrałbym rozwiązanie w ten sposób:
- najpierw normalizacja description_raw i mapowanie specyficzne dla banków pól
- następnie warstwa reguł dla oczywistych wzorców i powtarzających się merchantów
- główna kategoryzacja przez fastText jako deterministyczny szybki klasyfikator
- Qwen/Qwen2.5-3B-Instruct jako fallback dla kontrowersyjnych lub niskokonfidenckich transakcji
- wyjście tylko w sztywnym JSON z listą dozwolonych kategorii

Takie podejście daje potrzebną szybkość, ponieważ fastText dobrze działa na zwykłym CPU i nadaje się do przetwarzania wsadowego. Dla 100 transakcji do 2 sekund to bardziej realistyczna droga niż robienie wszystkiego przez czystą LLM. Qwen2.5-3B-Instruct używałbym tylko tam, gdzie reguły i klasyfikator nie dają pewnego wyniku, aby zachować stabilność i kontrolę nad kategoriami.

Przed rozpoczęciem pracy muszę wyjaśnić:
- przykład wejściowego JSON w pełnym formacie
- ostateczną listę kategorii
- czy istnieje oznaczony zestaw transakcji do weryfikacji jakości
- które banki są krytyczne dla pierwszej kolejności

W prywatnych odpowiedziach odpowiem na wszystkie pytania, mogę zrobić PoC na twoim JSON i pokazać dokładność, szybkość oraz stabilność hybrydowego schematu do pełnej realizacji. Rozwiń

Budżet: 2000 UAH Termin: 2 dni

Dzień dobry, w ogóle to takie coś można zrobić i bez LLM, można też łączyć - kod + LLM.

Budżet: 10000 UAH Termin: 1 dzień

Witam! Mogę to zrealizować. Proszę napisać na prywatną wiadomość, aby omówić wszystkie szczegóły. Będę zadowolony ze współpracy!

Budżet: 10000 UAH Termin: 5 dni

Dzień dobry
sądząc po załączonym json, trzeba będzie albo zrobić fine-tuning modelu, albo szkolić swój od zera, ponieważ w wielu wypisach przeznaczenie płatności jest niejasne.
Do klasyfikacji lepiej w tym przypadku wybrać nie llm, a bert lub embedding mgdel.

Budżet: 14000 UAH Termin: 5 dni

Witam, Konstantynie! Jestem Nina, menedżer inżyniera Walentyna.

Szczegółowo przeanalizowaliśmy Twój przykład JSON z transakcjami banku Banamex. Widzę specyfikę danych: hiszpańskie opisy sprzedawców (OXXO, DIDI, SIMI), obecność identyfikatorów podatkowych (RFC) oraz konieczność mapowania na Twój ścisły wykaz kategorii.

Nasze rozwiązanie dla Twojego modułu Python:

Inteligentne wstępne przetwarzanie: Przed wysłaniem do LLM moduł automatycznie oczyści description_raw z kodów technicznych i RFC. To jest krytyczne dla zmieszczenia się w budżecie < $0.005, ponieważ zmniejsza objętość tokenów trzykrotnie.

Semantyczna pamięć podręczna (L1/L2): Wdrożymy bazę wiedzy na temat Twoich transakcji. Jeśli "DIDI FOOD" już wystąpił, kategoria zostanie przypisana w 5 ms bez odwoływania się do AI. To gwarantuje prędkość 100 transakcji / < 1 sek.

Deterministyczność przez Pydantic: Model będzie działał w trybie Structured Output. Sztywno ograniczymy go Twoim wykazem (Wynagrodzenie, Telekom, Auto itd.). Opcji „własnych” nie będzie fizycznie.

Batch API: Dla nowych transakcji użyjemy przetwarzania wsadowego, co mieści się w limicie $0.001 za 100 wierszy.

Termin: 5–7 dni.
Budżet: 14 000 zł.

Konstantynie, już przygotowaliśmy prototyp parsera dla Twojego formatu. Jesteśmy gotowi zaprezentować dokładność na rozszerzonym zbiorze danych.

Z poważaniem, Nina. Rozwiń

Budżet: 18000 UAH Termin: 14 dni

Cześć! Pracowałem z podobnymi zadaniami — w szczególności wdrażałem system wykrywania transakcji fraudowych, co jest znacznie bardziej skomplikowanym zadaniem niż kategoryzacja. Dlatego od razu widzę tutaj kilka pułapek.
LLM w produkcji nie zadziała stabilnie w ramach waszych wymagań — latencja jest nieprzewidywalna, a koszt trudno kontrolować przy skalowaniu.

Zbudowałbym to inaczej:

Podstawa — wytrenowany klasyfikator FastText, a nie LLM:
- Wnioskowanie ~0.1 sek na 100 transakcji (20 razy szybciej niż wasze wymaganie)
- Koszt po treningu: 0 $
Dane treningowe — oznaczamy 3–5k transakcji przez GPT-4o-mini Batch API (~0.10 $ jednorazowo), trenujemy model, potem działa autonomicznie.
LLM pozostaje tylko jako fallback dla transakcji z niską pewnością — tam, gdzie klasyfikator nie jest pewny.
Wsparcie dla 30+ banków — przez pliki konfiguracyjne per-bank do mapowania pól. Nowy bank podłącza się bez zmiany logiki klasyfikatora.
Proponuję omówić szczegóły współpracy w wiadomościach prywatnych. Rozwiń

Budżet: 12000 UAH Termin: 10 dni

Witam! Proponuję zrealizować moduł klasyfikacji oparty na zespole modeli LightGBM, XGBoost i CatBoost. Takie rozwiązanie lepiej nadaje się do tego zadania, ponieważ zapewnia wysoką szybkość przetwarzania nawet na zwykłym CPU oraz stabilne, przewidywalne wyniki.

Mam 4-letnie doświadczenie w programowaniu w Pythonie i tworzeniu systemów analizy danych, dlatego będę w stanie zbudować elastyczną architekturę z możliwością szybkiego skalowania i dodawania nowych banków. Moduł będzie działał całkowicie lokalnie i ściśle przestrzegał określonych kategorii oraz formatu JSON.

Proponuję omówić szczegóły zadania technicznego, będę zadowolony ze współpracy!

Budżet: 18500 UAH Termin: 9 dni

Cześć.

Zapoznałem się z przykładem pliku. Format zadania jest jasny: potrzebny jest nie tylko wywołanie LLM, ale staranny moduł Pythona, który stabilnie przyjmuje bankowy JSON, normalizuje transakcje i zwraca ściśle ważny JSON z kategoryzacją w ramach określonej listy.

Z przykładu widać, że ważne jest zachowanie przewidywalności wyniku, sztywnej struktury odpowiedzi, wysokiej prędkości przetwarzania oraz możliwości skalowania rozwiązania pod różne banki bez przerabiania całej logiki.

Zrealizowałbym to jako niezawodny moduł z kilkoma poziomami przetwarzania:
— przyjęcie i walidacja wejściowego JSON
— normalizacja opisów transakcji
— kategoryzacja do ustalonych kategorii
— ścisły JSON na wyjściu
— logika, którą można szybko dostosować do nowych banków
— optymalizacja pod kątem prędkości i kosztów przetwarzania

W takich zadaniach kładę nacisk nie na “swobodną odpowiedź modelu”, ale na kontrolowany i praktycznie użyteczny wynik, który można wbudować w produkt bez niespodzianek.

Jestem gotów zapoznać się z ostatecznymi wymaganiami dotyczącymi formatu wejściowego i od razu zaproponować optymalną architekturę realizacji. Rozwiń

Budżet: 15000 UAH Termin: 7 dni

Witaj! Jestem założycielem agencji inżynieryjnej Vaysed.
Budujemy ekosystemy, w których sztuczna inteligencja działa pod ścisłą kontrolą deterministycznych algorytmów. Przeanalizowałem dostarczony plik, w którym znajdują się transakcje banku Banamex, pole description_raw oraz typowi sprzedawcy tacy jak OXXO czy DIDI FOOD. Zadanie idealnie pasuje do naszego profilu.

Przetwarzanie 100 transakcji przez LLM w 2 sekundy "na żywo" przy budżecie < 0,005 USD — to wyzwanie inżynieryjne, które nie rozwiązuje się prostym napisaniem promptu. Oto jak gwarantujemy zadeklarowaną prędkość i sztywny format wyjścia:
Semantyczna pamięć zamiast LLM: Większość transakcji użytkowników regularnie się powtarza. Wprowadzamy pośrednią warstwę bazy danych (Redis + PostgreSQL). Jeśli system już zna sprzedawcę, kategoria jest przypisywana natychmiast (w ciągu 5-10 milisekund) w ogóle bez odwołania do sieci neuronowej. To obniża koszt przetwarzania 80% zbioru do zera.
Batching i deterministyczne parsowanie: Dla nowych transakcji (np. nieznanych przelewów P2P) nasz moduł Python będzie formował zapytania wsadowe (batches). Aby zapewnić absolutną sztywność odpowiedzi (wymóg nr 4), zastosujemy biblioteki strukturalnego wyjścia (Outlines lub Instructor). Model na poziomie generacji tokenów będzie ograniczony do twojej listy (Wynagrodzenie, Telekomunikacja itp.) i fizycznie nie będzie mógł wydać halucynacji ani odejścia od formatu.
Uniwersalny adapter: Moduł znormalizuje wejściowy zbiór niezależnie od struktury banku, przekaże oczyszczone dane do silnika kategoryzacji i zwróci finalny JSON.

Jako model możemy wdrożyć lokalną zoptymalizowaną wersję (opartą na vLLM dla super szybkiego wnioskowania) lub użyć gpt-4o-mini w trybie wsadowym, co z zapasem mieści się w twoim limicie finansowym.

Tworzymy niezawodne architektury danych i mikrousługi na poziomie korporacyjnym. Nasze podejście inżynieryjne oraz zrealizowane przypadki można ocenić w portfolio: https://vaysed.me/

Napisz do mnie, a uzgodnimy architekturę modułu i terminy wdrożenia! Rozwiń

Budżet: 10000 UAH Termin: 14 dni

Do takiego zadania najlepiej nadaje się mały lokalny model, taki jak Llama 3 lub Mistral, uruchomiony przez vLLM lub Ollama — to jedyny sposób, aby zmieścić się w Twoim budżecie i uzyskać wynik szybciej niż w 2 sekundy. Zrealizuję moduł z wykorzystaniem Structured Output (przez Instructor lub Outlines), aby na wyjściu zawsze był ważny JSON z rygorystycznymi kategoriami bez zbędnego „śmiecia”. Architektura będzie oparta na abstrakcyjnych parserach: to pozwoli szybko podłączać nowe banki, po prostu opisując mapowanie pól, bez przepisywania logiki klasyfikatora. Będę dostępny także po oddaniu projektu, jeśli zajdzie potrzeba dostrojenia dokładności w specyficznych transakcjach.