Sok csapat, amely visszakeresésre épülő generálási (RAG) rendszereket épít magas kockázatú osztályozási feladatokra, ugyanazt a megközelítést választja: minden bizonytalan esetet azonnal a nagy nyelvi modellhez (LLM) irányítanak, és bíznak benne, hogy a lekért kontextus megoldja a kérdést. Demo környezetben ez jól működik, de összeomlik, amikor egy rendszernek meg kell állnia egy audit, szabályozó vagy megfelelésért felelős vizsgálata előtt, különösen hat hónappal a döntés után.
Vineet Vijay, aki vezető AI és gépi tanulás mérnök, egy éve épít RAG alapú osztályozó rendszereket szabályozott vállalati környezetben. Ilyen környezetben a téves válasz költsége nem egy kínos chatbot‑reakció: a döntésnek hosszú távon is helyt kell állnia ellenőrzéskor. Ez más tervezési filozófiát követel meg, mint amit a legtöbb AI‑engineering anyag feltételez.
Mi a probléma az „összesen LLM” csővezetéssel?
Három fő hiányosság emelhető ki:
- Auditálhatóság: a „a modell a lekért kontextus alapján döntött” nem elfogadható magyarázat. Szükség van olyan döntési útra, amely ember által rekonstruálható anélkül, hogy újra lefuttatnánk az inferenciát és reménykednénk az azonos kimenetben.
- Költség nagy volument kezelve: ha napi több tízezer eset kerül feldolgozásra és mindegyik LLM‑hívást kap több lekért dokumentummal, az inferencia számlája és a válaszidő a forgalommal együtt nő, míg a szabályalapú logika ilyen skálázódást nem produkál.
- Modelldrift az egyszerű eseteken: az LLM‑ek jól kezelik a finom, ítéleti jellegű döntéseket, ugyanakkor kiszámíthatatlanok lehetnek olyan esetekben, amelyek determinisztikus, világos szabály alapján eldönthetők. Egy strukturált, pontos egyezésnek nem szabadna a modell „hangulatától” függenie.
A kaszkád megoldása
A javaslat: hagyjuk abba az LLM frontvonalként történő használatát, és tegyük meg az eszkalációs útnak. A gyakorlatban ez háromlépcsős csővezetéket jelent:
-
Determinisztikus első szint: pontos egyezések, strukturált mezők összehasonlítása és bármi, ami egyértelmű szabály alatt megoldható — itt nincs modellhívás. Ez a réteg nagyrészt kiszűri a forgalmat (sok esetben a többséget, a konkrét arány az adatminőségtől függ), és minden döntés teljesen magyarázható, mert lekérdezésen alapul, nem inferencián.
-
Lekérdezés alapú második szint: azok az esetek, amelyeket az első réteg nem oldott fel, itt kapnak célzott kontextust: korábbi ellenőrzők döntései hasonló ügyekben, háttérdokumentumok, vagy történeti precedensek, amelyek tisztázzák az éles helyzeteket. Itt a retrieval lépés számít többet mint a generálás: ha rossz kontextust hívsz le, a legjobb LLM is magabiztos, de téves választ ad.
-
LLM eszkaláció harmadik szint: az LLM csak azokat az eseteket látja, amelyeket az első két réteg nem tudott eldönteni. Egy valós projektben, amelyen a szerző dolgozott, csak az igazán bizonytalan 10–15% irányítása az LLM‑hez mintegy 6×‑os inferencia költségcsökkenést eredményezett egy teljesen LLM‑alapú alapon mérve, miközben a determinisztikus többség következetessége gyakorlatilag tökéletesre javult.
Promptolás aszimmetrikus kockázat mellett
Ha egy ügy eléri az LLM szintet, sok csapat semleges promptot használ („Döntsd el, jóváhagyandó vagy jelölendő az eset”). Ez a megközelítés nem megfelelő magas kockázatú osztályozásnál, mert a két hibatípus költségei nem szimmetrikusak: ami kimarad és valóban figyelmet igényelt, komoly downstream kárt okozhat; ami tévesen jelölve lett, legtöbbször csak idő‑ és erőforrásveszteség.
Aszimmetrikus kockázati promptban a tradeoff expliciten benne van. Gyakorlatilag ez azt jelenti, hogy a modellt arra utasítjuk, hogy a bizonytalanságot eszkalációs okként kezelje inkább mint automatikus megoldást, példákat adunk mindkét hibajellegre és következményeikre, és a bináris döntés mellé kérünk egy konfidenciaszámot. Ezt a konfidenciaszintet második kaszkádpontként használjuk: minden, ami egy küszöb alá esik, emberi felülvizsgálatra kerül, függetlenül a modell osztályozásától.
Bár ez elsőre csak prompt‑finomításnak tűnik, a gyakorlatban ez különbség a ténylegesen csökkentett felülvizsgálói terhelés és egy kockázatot csendben növelő, álcázottan jól működő rendszer között.
Rendszeres értékelés és metrikák
A standard RAG metrikák nem erre a használati esetre készültek; adaptálás nélkül félrevezető biztonságérzetet adhatnak. Néhány fontos korrekció:
- A retrieval minőségét külön kell mérni a végső osztályozási pontosságtól. Jó lekérdezési rangsor mellett is rossz döntés születhet, ha a generáló lépés rosszul súlyozza a bizonyítékokat.
- Az értékelő készletet szándékosan túl kell reprezentálni azokkal az esetekkel, amelyek a harmadik szintre jutnak, mert itt van a tényleges ítélőképesség próbája. Ha az eval készlet tükrözi a termelési eloszlást, az dominálni fogják a determinisztikus esetek, és vakok maradunk a valódi hibákra.
- Az „LLM mint bíró” módszer használható, de a bíró promptjának ugyanazt az aszimmetrikus kockázati keretet kell követnie, mint a termelésben használt promptnak. Ha a bíró szimmetrikusan kezeli a hibákat, akkor rendszerszinten rossz tradeoff felé tolhatjuk a finomhangolást.
- Építsünk visszacsatolási kört a megerősített kimenetekből a retrieval korpuszba: ha egy emberi felülvizsgáló megváltoztat egy modell döntését, az eset és a helyes lezárás legyen később lekérdezhető kontextus. Enélkül a rendszer soha nem javul a bizonytalan esetek kezelésében, csak ismétli ugyanazokat a hibákat.
Általános tanulság
A kísértés, hogy a legképesebb modellt használjuk minden döntésnél, érthető. Azonban olyan területeken, ahol a téves válaszoknak valódi következményei vannak, értékesebb mérnöki munka eldönteni, mi az, ami soha nem kerülhet a modellre. A kaszkád architektúra nem csupán a LLM‑korlátok körüli kerülőút: ez az érett RAG‑rendszer kialakulása, amikor valóban meg kell tudni védeni egy döntést olyan szereplők előtt, akik célja a logika hibáinak feltárása.
Ha szabályozott vagy magas kockázatú területre építesz AI‑rendszert, a helyes kérdés az első prompt megírása előtt nem az, hogy „Hogyan készítem fel a modellt?”, hanem: „A döntés mely részei soha ne legyenek a modell feladata?”
Vineet Vijay, Lead AI and machine learning engineer.
