• AI automatizáció
  • Adatcsövek
  • Pénzügyi BI
  • n8n

Megbízható AI a pénzügyi adatcsövekben: kontroll-playbook a hallucinációk ellen

A hallucináló LLM-lépés csendben hibázik. RAG-alapozás, kimeneti sémák és lépésenkénti validáció a pénzügy jól ismert kontrolljaira fordítva.

6 perces olvasás

Tartalom6 szakasz
  1. Miért csúszik át a hallucináció a szokásos monitoringon
  2. Az öt hibamód, pénzügyi nyelvre fordítva
  3. Ez a kontrollkeretrendszer már megvan a pénzügyben
  4. Kényszerítsd ki a struktúrát, aztán ellenőrizd az értékeket
  5. A rétegzett architektúra
  6. A validációs büdzsét oda költsd, ahol materiális a tét

Egy elromlott ütemezett job hírt ad magáról: a futás pirosra vált, a logban ott a kivétel. Az az LLM-lépés viszont, amelyik kitalál egy számot, egyiket sem teszi. Gördülékeny, formailag hibátlan kimenetet ad vissza, és simán átmegy a downstream validáción; a téves szám aztán pontosan úgy érkezik meg a vezetői riportba, mintha helyes lenne. Az n8n blogja nemrég részletes rendszerezést közölt ezekről a csendes hibákról és az őket megfogó architektúráról, és ha az ember kontrollerszemmel olvassa, nem mérnökként, egyetlen következtetésre jut: ez belső kontroll-probléma, a pénzügy pedig nagyon régóta old meg ilyeneket.

Miért csúszik át a hallucináció a szokásos monitoringon

A pipeline-monitoring hangos hibák elkapására épül: timeoutra, kivételre. A hallucináló modell egyiket sem produkálja. Minden tokent statisztikai valószínűség alapján választ, nem tényellenőrzés alapján, így amikor a tanítóadat ritkás vagy ellentmondásos, hihetően hangzó választ ad, belső jelzés nélkül arról, hogy valami nem stimmel. A rossz válasz ugyanakkora magabiztossággal érkezik, mint a jó, és pontosan ezért nem gyógyítja meg önmagában semmilyen prompt-finomhangolás.

A kiváltó okokat érdemes szétszálazni, mert mindegyik más orvosságra mutat. A tudás-cutoff miatt a modell nem tudhat a múlt heti szállító-onboardingról; ezt a rést a retrieval zárja be, a prompt csiszolgatása nem. A szennyezett tanítóadat miatt a pontosság a cutoffon belül sem egyenletes. Alapozás híján a modell a parametrikus memóriájára támaszkodik, ami a tanítóforrások tömörített keveréke, és a számokat csak közelíti. A túlszabályozott prompt arra kényszeríti a modellt, hogy a megkövetelt forma kedvéért tartalmat találjon ki, ezért a praktikus tanács: a kérdést húzd szorosra, a formátumot engedd lazábbra. A kreatív íráshoz hangolt mintavételezési beállításoknak pedig semmi keresnivalójuk extrakciós vagy klasszifikációs lépésben: ott alacsony temperature kell, és ahol a platform engedi, rögzített seed.

Az öt hibamód, pénzügyi nyelvre fordítva

Ha a hallucinációt egyetlen, differenciálatlan kockázatként kezeljük, nehezebb elkapni. A gyakorlatban öt minta tér vissza, mindegyik más lenyomattal. Az ismert esetek szépen ráilleszthetők: 2024-ben egy kanadai vitarendezési testület arra kötelezte az Air Canadát, hogy térítse meg a kegyeleti tarifát, miután az ügyfélszolgálati chatbotja téves szabályzati információt adott egy utasnak, 2023-ban pedig egy New York-i ügyvédet szankcionáltak, mert hat, a ChatGPT által kitalált hivatkozásra épülő beadványt nyújtott be.

A pénzügyi pipeline-okban ugyanez halkabban zajlik:

HibamódÍgy néz ki egy pénzügyi pipeline-banDetektív kontroll
TénykitalációA zárási kommentár olyan szállítói jóváírást említ, amit sosem könyveltekMinden szám a lekért dokumentummal vagy a főkönyvvel egyeztetendő
Hivatkozás-hallucinációAz összefoglaló olyan számlaszámra hivatkozik, ami sehová sem vezetMinden hivatkozásnak létező dokumentum-azonosítóra kell mutatnia
Forrás-összemosásAz A szállító fizetési feltételei a B szállítónál landolnak az AP-triázsbanMinden állítás egyetlen lekért chunkra vezessen vissza, ne keverékre
Következtetési hibaA tételek jók, a kiszámolt végösszeg mégis tévesMinden aritmetika kódban számolódik újra; a modell összegét nem fogadjuk el
Utasítás-sodródásA főkönyvi kódoló ágens prózát ad vissza a megengedett kódok egyike helyettMinden kimenet sémával validálandó, nem átolvasással

Ezek egyike sem dob kivételt, és mindegyik túlél egy felületes átolvasást.

Ez a kontrollkeretrendszer már megvan a pénzügyben

Ha lehántjuk róla a gépi tanulásos szókincset, a megelőzési lista úgy olvasható, mint egy belső kontroll-kézikönyv. Minden válasz lehorgonyzása lekért dokumentumokban: ez az alátámasztó bizonylat követelménye, amit minden auditor számon kér. Az AI-lépések determinisztikus ellenőrzésekbe csomagolása (összeg újraszámolása, dátum validálása, szállító kikeresése a törzsadatból) a független ellenőrzés. Az ágens-lépések közé iktatott ellenőrzőpontok, ahonnan az alacsony konfidenciájú kimenet emberi sorba kerül: ez a négy szem elve. A pipeline futtatása ground-truth adathalmazon minden változtatás után pedig az időszakos kontrolltesztelés.

A Morgan Stanley-nél általam épített reconciliation platform napi 500K+ settlementet egyeztetett ügynöki és CSD-számlákkal, és a teljes koncepció arra épült, hogy egyetlen költség sem terhelhető tovább ügyfélre trade-szintű bizonyíték nélkül. A generált kimenet ugyanezt a hozzáállást érdemli. A modell által előállított szám: állítás, az állításokat pedig forrásdokumentummal egyeztetjük, mielőtt továbbmennének, függetlenül attól, hogy ember vagy modell írta-e le őket.

Kényszerítsd ki a struktúrát, aztán ellenőrizd az értékeket

A szabad szöveg adja a modellnek a legtöbb teret a sodródásra; egy séma ennek a felületnek a nagyját elveszi. Egy hipotetikus AP-extrakciós lépésnél a kimeneti kontraktus így nézhet ki:

JSON
{
  "type": "object",
  "required": ["vendor_id", "gross_amount", "currency", "gl_code", "source_document_id"],
  "properties": {
    "vendor_id":          { "type": "string", "pattern": "^V[0-9]{6}$" },
    "gross_amount":       { "type": "number" },
    "currency":           { "type": "string", "enum": ["EUR", "USD", "HUF"] },
    "gl_code":            { "type": "string", "enum": ["6010", "6020", "6090"] },
    "source_document_id": { "type": "string" }
  },
  "additionalProperties": false
}

Az enumok megszüntetik az utasítás-sodródást: a modell nem adhat vissza négyszavas leírást oda, ahová főkönyvi kód való. A kötelező source_document_id kikényszeríti a visszakövethetőséget. Amit a séma nem tud: jótállni az értékekért. Egy formailag tökéletes objektum is hordozhat kitalált összeget, ezért a struktúrát nem szabad összekeverni az igazsággal. Ezt a rést fedi le a determinisztikus réteg. Amit kód tud ellenőrizni, azt kód ellenőrizze: a végösszegek újraszámolódnak, a törzsadat-lookup pedig megerősíti, hogy a szállító valóban létezik. A korlát fordítva is igaz: a programozott ellenőrzés a verifikálható állításokra való, a hangnemhez és az összefoglalók minőségéhez továbbra is ember vagy bíráló modell kell.

A rétegzett architektúra

Az n8n által leírt felépítés öt réteget pakol egymásra, és mindegyik látható workflow-lépés, amelyet külön lehet vizsgálni és tesztelni. A context engineering a generálás előtt rendezi a memóriát és a few-shot példákat. A tudás-alapozás vektortárból emel be bizonyítékot, hogy a modell összefoglaljon, ne emlékezetből dolgozzon. A kimeneti kényszerek strukturált output parsert párosítanak automatikus javító parserrel és kód-ellenőrzésekkel. Az ágens-validáció IF-csomópontos ellenőrzőpontokat tesz a lépések közé, amelyek az alacsony konfidenciájú kimenetet felülvizsgálatra terelik, az ágens mozgásterét pedig guardrailek korlátozzák. A folyamatos kiértékelés minden változtatásnál ground-truth adathalmazon futtatja a teljes pipeline-t, és az eredmény irányítja a javítást: a tényszerűségi regresszió a retrievalre mutat, a következtetési regresszió ellenőrzőpontot követel.

Mivel a Morgan Stanley-nél részt vettem egy cégszintű, pénzügyi dokumentumokra épülő RAG-megoldás tervezésében és tesztelésében, külön aláhúznám az alapozó réteget. A retrieval minősége dönti el, hogy a modell egyáltalán miben lehet pontos: a hibrid keresés olyan találatokat fog meg, amelyeket bármelyik módszer önmagában elejtene, az újrarangsorolás a jelölteket valódi relevancia szerint szűri, és mindehhez ott az állandó kitétel, hogy a kurált forrás fölötti retrieval csak akkor segít, ha a forrás tényleg kurált. A teljes, rétegről rétegre haladó leírás a konkrét node-okkal együtt az n8n hallucinációkról szóló útmutatójában olvasható.

A validációs büdzsét oda költsd, ahol materiális a tét

Az ellenőrzőpontoknak ára van késleltetésben és számítási kapacitásban, és az útmutató őszintén kimondja ezt a trade-offot: a lépésenkénti validáció oda való, ahol a rossz válasz sokba kerül. Erre a pénzügynek évtizedek óta saját szava van: materialitás.

A belső meeting-összefoglalókat gyártó pipeline futhat lazábban. Amelyik viszont a zárást táplálja vagy külsőleg riportolt adathoz nyúl, annál minden réteg bekapcsolva marad. Ugyanez a logika érvényes az inputra is: a megbízható belső adat egy erős modellel kevesebb guardrailt igényel, mint a felhasználói szöveg vagy egy külső katalógus, vagyis a kontroll-intenzitás kövesse a kockázatot, pontosan úgy, ahogy egy kontroller ma is scope-olja a tesztelést.

A hallucináció nem javításra váró bug, hanem strukturális tulajdonsága annak, ahogyan ezek a modellek szöveget generálnak, vagyis a megbízhatósági munka a modell körüli architektúrában lakik, nem a promptban. Egy kontrollernek ez furcsa módon megnyugtató. Esendő folyamatok köré kontrollkeretet építeni: mindig is ez volt a munka, most csak egy újabb folyamat került alá.