Rozwiązania · Usługi finansowe
W organizacji finansowej użyteczny agent nie doradza i niczego nie zatwierdza: czyta dokumenty i transakcje, klasyfikuje je do kategorii z ustalonego zestawu, mówi, jak bardzo jest pewny, i może odpowiedzieć „nie wiem”. Reszta — decyzja, zatwierdzenie, polityka — pozostaje po stronie ludzi.
Oferta, z warunkamiNie piszemy „dostarczone”, ponieważ nie mamy takiego agenta wdrożonego produkcyjnie u klienta z sektora finansowego. To, co mamy i pokazujemy dokładnie jako takie, to własny pipeline ingestii działający na naszych danych: pięć modułów Python, 1.526 linii, które czytają powiadomienia bankowe z e-maili i wyciągów PDF, klasyfikują każdą transakcję za pomocą narzędzi i zapisują ją do PostgreSQL z deduplikacją, plus cztery przepływy automatyzacji dla webhooków od trzech procesorów płatności. Rzeczywisty stan, powiedziany w tym samym zdaniu: repozytorium nie jest pod git, katalogi `tests/` i `webhook-server/` są puste, a przybliżone dopasowanie nazw kontrahentów korzysta z heurystyki n-gramów oznaczonej w kodzie jako „do zastąpienia usługą osadzania przed produkcją”. Część platformy finansowej w produkcji — przepływ wniosku, kontrakt, wykres płatności, audyt — jest osobną pracą, z własnymi dowodami, i tam piszemy „dostarczone”.
Wnioski o agentów AI w usługach finansowych prawie zawsze przychodzą w formie „żeby odpowiadał klientom na pytania o nasze produkty”. To uzasadnione żądanie, ale nie tam oszczędza się czas. Czas traci się gdzie indziej: ktoś codziennie otwiera dziesiątki powiadomień bankowych i wyciągów, patrzy na opis typu ciąg wielkich liter z kodem i decyduje, czy to wpływ od klienta, wynagrodzenie, podatek, rata do wierzyciela czy koszt operacyjny. Ta praca jest powtarzalna, nudna i właśnie dlatego pełna błędów.
Model językowy nadaje się do tego, pod jednym warunkiem: nie wolno prosić go o pisanie odpowiedzi w wolnym tekście. Jeśli poprosisz o zdanie, to Ty je sparsujesz, a parsowanie zrobisz źle. W naszym przepływie model nie pisze: dostaje siedem narzędzi i musi wywołać dokładnie jedno — wpływ od klienta, wynagrodzenie, podatek, płatność do wierzyciela, koszt operacyjny, opłatę bankową albo nieznane. Każde narzędzie wymaga, oprócz nazwy kontrahenta lub kategorii, wskaźnika pewności między 0 a 1. „Nieznane” wymaga zapisanego powodu. Wynik jest strukturą, a nie opinią.
Druga zasada jest taka, że nic nie wchodzi dwa razy. Każda transakcja wyodrębniona z powiadomienia albo z wyciągu dostaje zewnętrzny identyfikator obliczony jako 16-znakowy prefiks z odcisku SHA-256 nad jej polami, kolumna jest unikalna w tabeli, a wstawianie odbywa się przez `ON CONFLICT (external_id) DO NOTHING`. Praktyczna konsekwencja: skrzynka pocztowa może być odczytana ponownie tyle razy, ile chcesz, a saldo się nie podwaja. Bez tej reguły każdy finansowy przepływ ingestii w trzecim tygodniu zaczyna produkować duplikaty, które ktoś czyści ręcznie.
Czego taki agent nie robi i dlaczego ważne jest, żeby napisać to na stronie: nie zatwierdza płatności, nie podejmuje decyzji kredytowej, nie daje rekomendacji inwestycyjnych i nie odpowiada klientowi w imieniu instytucji. Wskaźnik pewności, który zwraca, to ocena modelu o samym modelu, a nie pomiar dokładności wykonany przez nas — ta różnica to różnica między narzędziem a iluzją kontroli.
Co obejmuje
Powiadomienia są odczytywane ze skrzynki pocztowej przez IMAP, wyciągi z PDF. Każda transakcja dostaje zewnętrzny identyfikator z odcisku SHA-256 nad jej polami, kolumna `external_id` jest `NOT NULL UNIQUE` w tabeli, a wstawianie odbywa się przez `ON CONFLICT (external_id) DO NOTHING`, z osobnym logiem dla wiersza wstawionego i dla tego pominiętego jako duplikat. Ponowne odczytanie tej samej skrzynki nie tworzy żadnego duplikatu.
Siedem narzędzi, bez wolnego tekstu: wpływ od klienta, wynagrodzenie, podatek, płatność do wierzyciela, koszt operacyjny, opłata bankowa, nieznane. Model musi wywołać tylko jedno. Pierwsze sześć wymaga obowiązkowo, oprócz nazwy lub kategorii, wskaźnika pewności między 0,0 a 1,0, zadeklarowanego w schemacie narzędzia; siódme wymaga powodu. Używany model jest zadeklarowany w kodzie, nie ukryty w konfiguracji.
Klasyfikator, który nie może powiedzieć „nie wiem”, zakwalifikuje błędnie, z dużą pewnością, właśnie nietypowe transakcje — czyli te, które mają znaczenie. Dlatego narzędzie nieznane jest dostępne tak samo jak pozostałe i wymaga zapisanego powodu, który trafia do wiersza. Wiersze nieznane są listą roboczą człowieka, a nie porażką systemu.
Ta sama firma pojawia się w wyciągach w trzech pisowniach. Nad klasyfikacją istnieje dopasowanie po podobieństwie cosinusowym między wektorami. Mówimy dziś dokładnie, czym są te wektory: to heurystyka n-gramów znakowych, napisana w kodzie z komentarzem, że do produkcji trzeba ją zastąpić prawdziwym wywołaniem usługi embeddingowej. Działa dla wariantów zapisu; nie jest dopasowaniem semantycznym.
Cztery przepływy automatyzacji, po jednym dla trzech procesorów płatności i jeden do codziennej rekonsyliacji, z 7 do 10 węzłów każdy. Idea architektury jest taka, że różne źródła — e-mail, PDF, webhook — nie produkują trzech tabel, które potem trzeba uzgadniać, tylko wiersze w tej samej tabeli, z tą samą regułą deduplikacji.
Wywołania przechodzą przez własny gateway pod `api.megapromoting.com/v1`, z 44 skonfigurowanymi modelami, każdy z kosztem na token i limitem kontekstu. Klucz projektu ma białą listę modeli, budżet i okres, można go rotować z zachowaniem historii, a zużycie jest konsolidowane codziennie na użytkownik × klucz × model. Szczegół, który zaskakuje wszystkich: modele rozumowania generują wewnętrzne kroki, których system śledzenia nie widzi, ale dostawca je nalicza — więc brutto budżet na klucz ustawia się poniżej pożądanego limitu.
Do kroków, które nie wymagają dużego modelu — wyodrębniania pól ze znanego formatu, dopasowywania nazw, sprawdzeń spójności — nie jest potrzebny żaden zewnętrzny dostawca; to zwykły kod. Model wywołuje się tylko dla kroku klasyfikacji. Gdy twoja polityka zabrania wynoszenia danych, pytanie brzmi, co dokładnie trafia do modelu, a nie czy używa się AI: można wysłać opis transakcji bez identyfikatorów kont.
Nie zatwierdza płatności i nie wykonuje przelewu. Nie podejmuje decyzji kredytowej — zasady, progi i zatwierdzenie są polityką instytucji. Nie daje rekomendacji inwestycyjnych i nie odpowiada klientowi w twoim imieniu bez oddzielnego procesu zatwierdzania. I nie gwarantuje ci dokładności: wynik zaufania to wyjście modelu o samym sobie, a nie niezależny pomiar.
Traseul
Pierwsze dostarczenie to nie agent, lecz lista: kategorie, do których może klasyfikować, jakie obowiązkowe pola wymaga każda z nich, i co oznacza u ciebie „nieznane”. Jeśli tej listy nie da się zapisać na jednej stronie, zadanie nie nadaje się na agenta — i lepiej dowiedzieć się tego teraz.
Odczyt z e-maila, PDF lub webhooka, wyodrębnianie pól, obliczanie identyfikatora zewnętrznego i zapis do bazy wykonuje się i weryfikuje bez żadnego wywołania modelu. Dostarczamy potok, który poprawnie ingestuje i nie duplikuje. Jeśli ten krok nie jest solidny, model nad nim tylko produkuje bardziej przekonujące błędy.
Na wierzchu działającego potoku kładziemy narzędzia klasyfikacji i uruchamiamy je na zestawie twoich rzeczywistych transakcji, z poprawnym wynikiem ustalonym przez osobę, która dziś wykonuje tę pracę. Dostarczamy tabelę zgodności i niezgodności, a nie stwierdzenie o dokładności. Próg, od którego wiersz trafia do człowieka, wybiera się z tej tabeli.
Klucz projektu z białą listą modeli i budżetem, codzienna konsolidacja zużycia, dziennik z wywołanym narzędziem i wynikiem oraz bramka, która przekazuje do człowieka wszystko, co jest poniżej progu lub nieznane. Dostarczamy dostępy, dokument uruchomieniowy i pisemną listę tego, co agent robi samodzielnie, a czego nie.
Dane
Zasady różnią się w zależności od branży. To są te, które obowiązują w usługach finansowych.
Przykład
Sytuacja
Powiadomienia bankowe i miesięczne wyciągi trafiały do skrzynki pocztowej i były czytane przez osobę, która klasyfikowała je według kategorii. Pierwsza oczywista wersja — skrypt, który czyta skrzynkę i zapisuje do bazy — ma problem, który wychodzi na jaw dopiero w trzecim tygodniu: przy każdym ponownym uruchomieniu albo ponownym odczycie te same transakcje trafiają ponownie.
Co zbudowaliśmy
Napisaliśmy pięć modułów, 1.526 linii Pythona: dwa analizatory powiadomień przez IMAP, ekstraktor wyciągów PDF, klasyfikator oparty na narzędziach i zapis do PostgreSQL. Główną zasadą jest identyfikator zewnętrzny — 16-znakowy prefiks z odcisku SHA-256 nad polami transakcji — z unikalną kolumną w tabeli i wstawianiem `ON CONFLICT DO NOTHING`. Klasyfikacja nie zwraca tekstu: model wywołuje jedno z siedmiu narzędzi, z obowiązkowym wynikiem zaufania, a „nieznane” wymaga podania powodu.
Co z tego wyszło
Skrzynka pocztowa może być odczytana ponownie w dowolnym momencie, a wiersze już przetworzone są pomijane i oznaczane jako duplikat w dzienniku. Transakcje, których model nie potrafi zaklasyfikować, pojawiają się jako lista robocza, z podanym obok powodem, zamiast być wpychane do kategorii tylko po to, żeby wyglądało, że wszystko się udało.
Czego nie mówi ten przypadek
To wewnętrzny potok, a nie system dostarczony klientowi finansowemu: nie jest pod git, katalogi testowe są puste, a przybliżone dopasowanie nazw korzysta z heurystyki n-gramów, którą kod wyraźnie oznacza jako tymczasową. Opisałam to tutaj, bo pokazuje metodę, a nie dlatego, że jest to produkt.
Pytania
Nie, i nie jest to ograniczenie techniczne, które pokonamy w następnej wersji. Zatwierdzanie jest decyzją o skutkach prawnych, która należy do upoważnionej osoby w instytucji. Agent przygotowuje: klasyfikuje, uzupełnia, sygnalizuje, co nie pasuje. System, który sam zatwierdza, powinien umieć odpowiedzieć przed kontrolerem, a wynik zaufania nie jest odpowiedzią.
Nie z wyniku zaufania — to jest ocena modelu samego siebie, a nie pomiar. Wiadomo to z porównania z decyzjami osoby, która dziś wykonuje tę pracę, na zbiorze rzeczywistych transakcji, przygotowanym przed uruchomieniem czegokolwiek w trybie automatycznym. Wynik tego porównania to tabela, którą dostarczamy, w tym wiersze, w których agent się pomylił.
Wywołaj narzędzie „nieznane” i wpisz powód. Wiersz trafia na listę roboczą osoby, a nie do wybranej losowo kategorii tylko po to, by system wyglądał na działający. Klasyfikator bez wyjścia „nie wiem” myli się dokładnie tam, gdzie błąd kosztuje: przy nietypowych transakcjach.
Nie. Każda transakcja ma zewnętrzny identyfikator obliczony jako odcisk na podstawie jej pól, kolumna jest unikalna, a wstawianie używa `ON CONFLICT (external_id) DO NOTHING`. Pominięty wiersz jest odnotowany w dzienniku jako duplikat, więc widać, że został odczytany ponownie.
Na etapie klasyfikacji tak: opis transakcji i kwota trafiają do wybranego modelu przez nasz gateway, z kluczem projektu, listą dozwolonych modeli i budżetem. Pozostałe etapy — odczyt, ekstrakcja, deduplikacja, dopasowanie nazw — to zwykły kod i nigdzie nie wychodzą. To, co dokładnie może wyjść, ustala się na piśmie wcześniej, a nie odkrywa z logów później.
Tak, to jeden z modułów potoku. Trzeba wiedzieć, że wyciąg PDF to format kruchy: odczytuje się go według struktury generowanej przez dany bank, a gdy bank zmienia szablon, moduł trzeba dostosować. Dlatego pisze się go z kontrolami, które wyraźnie się wywracają, a nie zgadują.
Ponieważ nasza zasada wymaga co najmniej dwóch własnych wdrożeń, aby napisać „dostarczone”, a opisana tutaj potok działa na naszych danych, a nie w produkcji u klienta z sektora finansowego. Ma też braki, które nazywamy: nie jest pod git, nie ma testów, a dopasowanie nazw używa heurystyki oznaczonej w kodzie jako tymczasowa. Gdy będziemy mogły powołać się na dwa wdrożenia u klientek i klientów, zmienimy to słowo.
Trzech rzeczy: zamkniętej listy kategorii, do których wolno klasyfikować, zestawu rzeczywistych transakcji z poprawną odpowiedzią podaną przez osobę, która dziś wykonuje tę pracę, oraz pisemnej decyzji, jakie pola mogą wychodzić z waszej sieci. Bez trzeciego punktu nie zaczynamy, bo to jedyny, którego nie da się naprawić później.
Opowiedz nam o swoim procesie. Wspólnie ustalimy, co warto zbudować, co da się połączyć i jak sprawdzimy wynik.