Każda liczba ma pokrycie w Twoich danych
Model językowy potrafi sformułować przekonujące zdanie z wartością, która nie ma pokrycia w danych — to najlepiej udokumentowana słabość generatywnej AI w zastosowaniach finansowych. Poniżej: na czym ten problem polega, jak rozwiązaliśmy go na poziomie architektury i co z tego wynika dla wiarygodności liczb, na których podejmujesz decyzje.
Każda liczba pokazywana w systemie przechodzi wieloetapową weryfikację względem Twoich dokumentów źródłowych, co ogranicza ryzyko halucynacji modelu do minimum. Nie sprowadza go jednak do zera — żadne narzędzie oparte na generatywnej AI nie jest w pełni nieomylne, dlatego wyniki weryfikuj również po swojej stronie. Poniżej pokazujemy, na czym ta weryfikacja polega i jak każdą wartość prześledzisz do dokumentów źródłowych.
Problem: właściwości generatywnych modeli językowych
Duży model językowy (LLM) generuje tekst probabilistycznie: przewiduje kolejne fragmenty wypowiedzi tak, aby całość była spójna językowo — a nie tak, aby była zgodna z danymi źródłowymi. W zastosowaniach finansowych ta właściwość ma cztery konsekwencje, z których każda dyskwalifikuje model jako samodzielne źródło wartości liczbowych.
- Konfabulacja (halucynacja). Model potrafi wygenerować kwotę, procent lub datę, które nie występują w żadnym dokumencie źródłowym — zachowując przy tym rzeczowy, pewny ton wypowiedzi. Błąd nie sygnalizuje się stylistycznie i jest nieodróżnialny od poprawnego wyniku bez niezależnej kontroli.
- Zawodna arytmetyka. Model nie wykonuje obliczeń — odtwarza ich wzorce statystyczne. Sumowanie pozycji, wyliczanie procentów i różnic między okresami obarczone są błędem, którego skala nie jest przewidywalna.
- Brak kalibracji pewności. Model formułuje wnioski słabo uzasadnione danymi z taką samą stanowczością jak wnioski dobrze udokumentowane. Deklarowana pewność wypowiedzi nie koreluje z jej poprawnością.
- Niedeterminizm. To samo pytanie zadane dwukrotnie może zwrócić różne odpowiedzi. Proces, którego wyniku nie można powtórzyć, nie spełnia wymogów stawianych sprawozdawczości finansowej.
Rozwiązanie: rozdzielenie warstwy obliczeniowej od językowej
Wymienione ryzyka eliminujemy na poziomie konstrukcji systemu, a nie deklaracji. Wszystkie wartości liczbowe wylicza deterministyczny silnik bezpośrednio z dokumentów źródłowych — ten sam zestaw danych zawsze daje ten sam wynik. Model językowy otrzymuje wyłącznie gotowe, policzone fakty; jego rolą jest uporządkowanie i opis, nie obliczenia. Kontrola składniowa odrzuca każdy tekst modelu zawierający wartość liczbową bez pokrycia w policzonym fakcie — taka treść jest zastępowana opisem generowanym deterministycznie.
Zdanie wygenerowane przez AI z kwotą powiązaną linią z fakturą źródłową i znacznikiem weryfikacji
weryfikacja-zrodlo.webp — Ilustracja koncepcyjna 16:9, ciemny motyw aplikacji finansowej (tło #0a0a0b, subtelna siatka). Po lewej karta z tekstem po polsku: „W marcu koszty energii wzrosły o 1 840 zł" — kwota „1 840 zł" wyróżniona niebieskim (#3b82f6) i podkreślona. Od kwoty biegnie cienka niebieska linia do miniatury faktury po prawej (dokument z pozycjami i sumą), na fakturze zielony znacznik weryfikacji (#22c55e). Minimalistyczny styl wektorowy, cienkie linie, bez postaci ludzkich, bez logotypów.
Konsekwencje dla Twojej firmy
Decyzje finansowe podejmujesz na wartościach, które system potrafi odtworzyć i udokumentować: każda kwota ma ścieżkę do dokumentów źródłowych, klasę pewności i wynik weryfikacji. Ryzyko charakterystyczne dla narzędzi opartych wyłącznie na modelu językowym — przekonująca narracja zbudowana wokół błędnej liczby — zostaje ograniczone konstrukcyjnie: wartość, która nie przejdzie weryfikacji, nie jest publikowana.
Weryfikacja każdej wartości przed publikacją
Przed publikacją każda wartość jest przeliczana ponownie — niezależnym zapytaniem do danych źródłowych. Wartość, której nie można odtworzyć w granicach przyjętej tolerancji (±1% względnie), zostaje odrzucona wraz z całą obserwacją, w której występuje — zasada fail-closed, „wszystko albo nic". Negatywny wynik weryfikacji nie degraduje wartości do „przybliżonej": obserwacja nie jest publikowana w ogóle. Priorytetem jest precyzja publikowanych danych, nie ich liczba.
Diagram przepływu weryfikacji: dane źródłowe, wyliczenie, ponowne przeliczenie w tolerancji ±1%, publikacja lub odrzucenie
weryfikacja-warstwy.webp — Poziomy diagram przepływu 16:9, 4 etapy połączone strzałkami, ciemny motyw (tło #0a0a0b, subtelna siatka), minimalistyczny styl wektorowy, cienkie linie. Etap 1: ikona dokumentów, podpis „Dane źródłowe". Etap 2: ikona silnika/kalkulatora, podpis „Wyliczenie wartości". Etap 3: ikona lupy nad liczbą, podpis „Ponowne przeliczenie (tolerancja ±1%)". Etap 4: bramka rozdzielająca dwie ścieżki — zielona (#22c55e) z podpisem „Publikacja" oraz czerwona/wygaszona (#ef4444) z przekreślonym okiem i podpisem „Odrzucenie". Akcent niebieski #3b82f6, podpisy po polsku, bez postaci ludzkich.
Ścieżka audytu: od kwoty do dokumentu źródłowego
Każda opublikowana kwota zachowuje powiązanie z fakturami, z których została wyliczona. Z poziomu obserwacji lub rekomendacji dostępna jest lista dokumentów źródłowych — z datami, kontrahentami i kwotami składowymi. Ta sama ścieżka służy do weryfikacji zewnętrznej: wynik można przedstawić księgowości, bankowi lub wspólnikowi razem z dokumentacją.
Rekomendacja w aplikacji bilans.ai z otwartą listą faktur źródłowych
weryfikacja-cytowanie.png — Realistyczny mockup 16:10 ciemnego interfejsu aplikacji finansowej SaaS (tło #0a0a0b, karty #101014, obramowania #26262b, akcent #3b82f6, typografia sans-serif). Karta rekomendacji oszczędności z polskim tytułem i kwotą miesięczną; nad nią otwarte okno modalne „Faktury źródłowe" z tabelą 4–5 wierszy: kolumny Data, Kontrahent, Numer, Kwota (realistyczne polskie dane, kwoty 300–6 000 zł). Suma pozycji spójna z kwotą na karcie. Bez postaci ludzkich. (Alternatywnie: realny zrzut z trasy /rekomendacje → „Pokaż faktury".)
Trzy klasy pewności i przedziały prognoz
Każdej wartości przypisujemy klasę pewności. Wartość potwierdzona pochodzi bezpośrednio z danych i przeszła weryfikację. Szacunek opiera się na przyjętych założeniach i jest prezentowany jako przedział (np. 800–1200 zł/mies.), nie jako wartość punktowa. Hipoteza oznacza zależność wymagającą potwierdzenia w danych. Prognozy publikujemy z przedziałem niepewności i prawdopodobieństwem przekroczenia progu — nie jako pojedynczą trajektorię. Jeżeli wolumen danych nie pozwala na statystycznie istotne wnioskowanie, system raportuje niewystarczającą podstawę danych zamiast publikować ekstrapolację o niskiej wiarygodności.
Karty w aplikacji ze znacznikami klas pewności i prognozą prezentowaną jako przedział niepewności
weryfikacja-zaufanie.png — Mockup 16:10 ciemnego interfejsu aplikacji finansowej (tło #0a0a0b, karty #101014, akcent #3b82f6, typografia sans-serif). Trzy karty obserwacji ze znacznikami klas pewności: zielona etykieta „Potwierdzone" z kwotą punktową, żółta „Szacunek" z przedziałem „ok. 800–1 200 zł/mies.", szara „Hipoteza" bez kwoty. Obok wykres prognozy typu fan chart: linia historyczna i rozszerzający się przedział niepewności, oś w tys. zł. Jedna karta w stanie „Niewystarczająca podstawa danych" (wygaszona). Podpisy po polsku, bez postaci ludzkich. (Alternatywnie: realne zrzuty z /rekomendacje i /run-rate.)
Zasady operacyjne
Cztery reguły stosowane bez wyjątków — niezależnie od modułu, klienta i skali danych.
Pomiar zamiast deklaracji
Zrealizowane oszczędności są wyliczane z faktur zaksięgowanych po wdrożeniu rekomendacji, z konserwatywnym ograniczeniem kwot. Model językowy nie ma technicznej możliwości zapisania kwoty zrealizowanej. Status realizacji zatwierdza użytkownik.
Priorytetyzacja według istotności i pewności
Obserwacje są szeregowane według wpływu finansowego i klasy pewności. Pozycje o niskiej pewności trafiają do osobnej sekcji przeglądowej, a sygnały poniżej progu istotności są tłumione — kontrola odsetka fałszywych alarmów jest parametrem systemu, nie skutkiem ubocznym.
Tryb testowy nowych detektorów
Nowy mechanizm detekcji pracuje początkowo w trybie równoległym (shadow): jego wyniki są rejestrowane i audytowane, ale nie są publikowane, dopóki precyzja nie zostanie potwierdzona na danych rzeczywistych.
Deterministyczna procedura weryfikacji
Jednolity próg tolerancji i zasada „wszystko albo nic": negatywny wynik weryfikacji pojedynczego faktu odrzuca całą obserwację. Procedura wykonuje się automatycznie, bez ręcznych wyjątków i nadpisań.
Granice metody
Opisana weryfikacja obejmuje warstwę liczbową: wartość, której nie można odtworzyć w tolerancji ±1%, nie jest publikowana. Warstwa interpretacyjna — dobór akcentów, hipotezy przyczynowe, priorytetyzacja opisu — pozostaje wynikiem pracy modelu generatywnego i, jak każda technologia tej klasy, nie osiąga stuprocentowej niezawodności. Z tego względu żaden wniosek w bilans.ai nie wymaga zaufania do modelu: każdy ma klasę pewności, wynik weryfikacji i ścieżkę do dokumentów źródłowych, a pozycje oznaczone jako szacunek lub hipoteza należy traktować jako punkt wyjścia do własnej oceny, nie jako rozstrzygnięcie.
Zasada nadrzędna
W finansach błędna wartość jest gorsza niż brak wartości — bo staje się podstawą decyzji. Stąd reguła nadrzędna systemu: to, czego nie można potwierdzić, nie jest publikowane. Tam, gdzie inne narzędzia ekstrapolują, bilans.ai domyślnie wstrzymuje publikację.