zisky:
- Schopnosť vytvoriť vrstvy overovania výstupov na základe schém a pravidiel
- Schopnosť zmysluplne vyžadovať „človek v slučke“ pri rozhodnutiach s vysokým dopadom
- Schopnosť navrhnúť overenie a smerovanie založené na prahu dôvery s druhým modelom
Jazykový model vytvára plynulý, presvedčivý a často presný – ale „presvedčivý“ nie je to isté ako „správny“. Model môže ticho prispôsobiť množstvo, dátum alebo pole JSON; Toto sa nazýva halucinácia (model s istotou produkuje informácie, ktoré v skutočnosti neexistujú). Ak v podnikovom systéme tento výstup prejde do ďalšieho kroku – platba, e-mail, zápis do databázy – chyba sa prenesie do skutočného sveta. V tejto jednotke sa naučíme filtrovať výstup s overovacími vrstvami predtým, ako vstúpi do systému, a pri rozhodovaní s vysokým dopadom vyžadovať „človek v slučke“.
Prečo je potrebná validácia výstupu?
Výstup modelu môže byť poškodený dvoma hlavnými spôsobmi: formát (nezodpovedá očakávanej schéme JSON, pole chýba/prebytok) a obsah (formát je správny, ale hodnota je nesprávna – neexistujúci kód produktu, nelogický dátum). Pokiaľ ide o bezpečnosť, existuje tretí rozmer: škodlivý výstup (škodlivý príkaz vytvorený ako výsledok injekcie alebo úniku). Pevný systém zastaví všetkých troch pri dverách.
Upozornenie: „Model vo všeobecnosti presný“ nie je výrobným kritériom. V systéme bez overenia aj jedna chyba z tisíc znamená 100 chybných transakcií denne v 100 000 požiadavkách denne.
Vrstvy autentifikácie: Krok za krokom
- Overenie schémy. Skontrolujte pomocou stroja, či výstup zodpovedá očakávanej štruktúre: sú polia prítomné, sú ich typy správne, sú vyplnené povinné polia?
- Overenie pravidiel/obchodnej logiky. Zhodujú sa hodnoty s obchodnými pravidlami? (Čiastka > 0, dátum nie je v budúcnosti, kód produktu patrí do katalógu.)
- Ovládanie referencie/zdroja. Ak model vytvára tvrdenie, môže byť prepojené so zdrojom? (Je citát RAG skutočne v dokumente?)
- Validácia s druhým modelom (LLM-as-judge). Nezávislý model hodnotí výstup ako „správny/neúplný/rizikový“.
- Prah dôvery a orientácia. Ak model alebo validátor hlási nízku spoľahlivosť, výstup automaticky neprejde; je zameraná na ľudí.
- Ľudská kontrola. Vysoko účinný alebo nízko bezpečný výsledok závisí od súhlasu odborníka.
Štyri kopírovateľné šablóny
Schéma + „vymyslite si, ak neviete“:
Vráťte odpoveď LEN v nasledujúcej schéme JSON: Napíšte „nízka“. NIKDY nepíšte odhad, ako keby bol presný.
Overenie s druhým modelom (výzva sudcu):
Ste nezávislý overovateľ. Nižšie je uvedený <zdrojový> text a <nárok>. Skontrolujte, či sa KAŽDÉ číslo a dátum v nároku vyskytujú doslovne v zdroji. Pre každý povedzte: "overené | nie je v zdroji | odporuje zdroju." Ak čo i len jeden z nich „chýba/je v konflikte“, označte výsledok ako „VYŽADUJE SA ĽUDSKÉ POSÚDENIE“.<zdroj>{{ text }}</source><claim>{{ model_output }}</claim>
Pravidlo smerovania prahu dôvery:
Pravidlo smerovania:- emin_misin = "vysoké" A množstvo < 10 000 TL -> automatické spracovanie - emin_misin = "stredné" ALEBO množstvo 10 000 - 100 000 TL -> overenie druhého modelu - emin_misin = "nízke" ALEBO množstvo > 100 -> 000 TL požadované od človeka
Súhrnná karta auditu človeka (urýchľuje kontrolu):
Pri predkladaní rozhodnutia osobe predložte túto kartu: Čo sa navrhuje? (jedna veta)- Z akého zdroja vychádza? (odkaz na článok/dokument)- Aké sú 2 najslabšie predpoklady?- Ak budú schválené, možno ich zvrátiť? (áno/nie)
Slabá výzva / silná výzva
zlý prístup
Silný prístup
"Odpočítať sumu z faktúry" (voľný text)
Prísna schéma JSON + null + pole dôveryhodnosti
Zapísanie výstupu priamo do platobného systému
Schéma → pravidlo → schválenie človekom (ak je to potrebné)
Stačí povedať modelke „buď si istý“
Overenie čísla/dátumu s druhým modelom
Spracovanie každého výstupu s rovnakou istotou
Smerovanie založené na vplyve a dôvere
Silný prístup nedúfa, že model je správny; Vytvára dvere, ktoré vás zachytia, keď sa pomýlite.
Tri mini puzdrá
Prípad 1 – Samotná schéma nestačila. Účtovná automatizácia extrahovala sumu z faktúr ako JSON. Schéma bola správna, ale model vyrobil na faktúre „125 000“ namiesto „1 250,00“ (desatinný posun). Schéma to nedokázalo zachytiť; bolo zachytené overenie pravidla („suma musí byť v súlade so súčtom položiek faktúry o ±1 %“) a bolo zabránené nesprávnemu zaúčtovaniu 112 500 TL.
Prípad 2 — Druhý model zachytil halucináciu. „30-dňová výpovedná lehota,“ uviedol asistent právnej podpory v súhrne zmluvy; V zmluve to však bolo 90 dní. Keď nezávislý sudca označil model za „konfliktný so zdrojom“, výstup bol postúpený človeku a opravený. Ak by to bolo automatické, zákazník by oznámil zrušenie na základe nesprávneho dátumu.
Prípad 3 – Smerovanie znížilo zaťaženie o 70 %. Systém poistných škôd automaticky schvaľoval nízko a vysoko bezpečnostné nároky a znalcovi posielal len tie nadlimitné/nízkozabezpečené. Z 3200 denných požiadaviek len 950 pripadlo na ľudí; odborníci venovali svoj čas skutočne rizikovým 30 %, pričom priemerný čas transakcie klesol zo 4 hodín na 40 minút.
Tip: Nenastavujte ľudskú kontrolu tak, aby „ľudia všetko videli“ — to ľudí unavuje a súhlas sa stane pečiatkou. Namiesto toho smerujte k človeku len výstupy s vysokým dopadom a nízkou spoľahlivosťou; To sústreďuje pozornosť na to, na čom skutočne záleží.
Aby mala ľudská kontrola zmysel
Human-in-the-loop nie je o umiestnení začiarkavacieho políčka na papier. Recenzent musí mať (1) kontext na pochopenie rozhodnutia, (2) prístup k zdroju a (3) právomoc povedať „nie“. V opačnom prípade zostáva ovládanie kozmetické. Revízna karta (štvrtá šablóna vyššie) má poskytnúť práve tento kontext.
Časté chyby
- Robím len overenie schémy a preskakovanie chýb obsahu/hodnoty.
- Mysliac si, že tým, že poviete modelu „uisti sa“, robíte skutočné overenie.
- Automaticky implementujte nezvratné rozhodnutia s vysokým dopadom.
- Zavedenie ľudskej kontroly nad každým výstupom a premena schválenia na nezmyselnú gumičku.
- Povedať recenzentovi „schváliť“ bez uvedenia zdroja a kontextu.
- Spracovanie všetkých výstupov s rovnakým rizikom bez stanovenia prahu dôveryhodnosti a smerovania.
V súhrne
- Výstup je poškodený tromi spôsobmi: formou, obsahom a zlým úmyslom; pevný systém zastaví všetkých troch pri dverách.
- Vrstvy: validácia schémy, pravidlo/obchodná logika, riadenie zdroja, druhý model (LLM-as-judge) a smerovanie prahu dôvery.
- Pre výstupy s vysokým dopadom a nízkou bezpečnosťou by mala byť prítomnosť človeka v slučke povinná.
- Ľudská kontrola musí byť zmysluplná: recenzent musí mať kontext, prístup k zdrojom a právomoc povedať „nie“.
- Bezpečnosť aj účinnosť sa získavajú tým, že sa na človeka nasmerujú len tie rizikové, nie každý výstup.
Aplikačná úloha
Vezmite si príklad z vlastného výstupu AI. Najprv definujte schému JSON a vynútite jej výstup. Potom napíšte aspoň dve obchodné pravidlá (napríklad „množstvo zodpovedá súčtu položiek“). Nakoniec nastavte smerovaciu tabuľku: ktorá kombinácia dôvery/vplyvu ide automaticky, ktorá ide do druhého modelu, ktorá ide na človeka? Vytvorte chybnú vzorku a sledujte, kde ju každá vrstva zachytáva.
kontrolný zoznam
- [ ] Definujem prísnu schému pre výstup a overím ju na stroji.
- [ ] Pridal som aspoň jedno overenie podnikania/pravidiel (logika hodnôt).
- [ ] Môžem prepojiť tvrdenia so zdrojom a skontrolovať ich.
- [ ] K dispozícii je druhý model alebo ľudské overenie pre výsledky s vysokým dopadom/nízkou bezpečnosťou.
- [ ] Smerovacie pravidlo definované na základe dôvery a vplyvu.
- [ ] Recenzent má k dispozícii kontext, zdroj a oprávnenie odmietnuť.