Kasu:
- Võimalus luua skeemi- ja reeglipõhiseid väljundi valideerimiskihte
- Võime nõuda suure mõjuga otsuste tegemisel mõttekalt silmapaistvat inimest
- Võime kujundada kontrolli ja usaldusläve põhist marsruutimist teise mudeliga
Keelemudel on sujuv, veenev ja sageli täpne, kuid "veenv" ei ole sama, mis "õige". Mudel mahutab vaikselt summa, kuupäeva või JSON-välja; Seda nimetatakse hallutsinatsiooniks (mudel toodab enesekindlalt teavet, mida tegelikkuses ei eksisteeri). Ettevõttesüsteemis, kui see väljund liigub järgmisse etappi - makse, meilisõnum, andmebaasi kirjutamine -, kandub viga reaalsesse maailma. Selles üksuses õpime filtreerima väljundit verifitseerimiskihtidega enne selle sisenemist süsteemi ja nõudma in-the-loop'i inimest suure mõjuga otsuste tegemisel.
Miks on väljundi kinnitamine nõutav?
Mudeli väljundit saab rikkuda kahel peamisel viisil: vormingus (ei vasta eeldatavale JSON-skeemile, väli puudub/liigne) ja sisu (vorming on õige, aga väärtus vale – tootekood puudub, kuupäev on ebaloogiline). Turvalisuse osas on kolmas mõõde: pahatahtlik väljund (süstimise või lekke tulemusena tekkinud pahatahtlik käsk). Tugev süsteem peatab kõik kolm ukse juures.
Ettevaatust: "Mudel üldiselt täpne" ei ole tootmise kriteerium. Verifitseerimata süsteemis tähendab isegi üks viga tuhandest 100 vigast tehingut päevas 100 000 päringu kohta päevas.
Autentimise kihid: samm-sammult
- Skeemi valideerimine. Kontrollige masinaga, kas väljund vastab eeldatavale struktuurile: kas väljad on olemas, kas nende tüübid on õiged, kas vajalikud väljad on täidetud?
- Reegli/äriloogika valideerimine. Kas väärtused vastavad ärireeglitele? (Summa > 0, kuupäev ei ole tulevikus, tootekood kuulub kataloogi.)
- Viite/allika juhtimine. Kui mudel esitab väite, kas seda saab allikaga siduda? (Kas RAG-i tsitaat on tegelikult dokumendis?)
- Valideerimine teise mudeliga (LLM-as-judge). Sõltumatu mudel hindab väljundit "õigeks/puudulikuks/riskantseks".
- Usalduslävi ja orientatsioon. Kui mudel või valideerija teatab madalast usaldusväärsusest, ei lähe väljund automaatselt läbi; on suunatud inimestele.
- Inimese kontroll. Suure potentsiaaliga või madala turvalisuse tulemus sõltub eksperdi heakskiidust.
Neli kopeeritavat malli
Skeem + "mõelge välja, kui ei tea" koos:
Tagasta vastus AINULT järgmises JSON-skeemis: kirjutage "madal". ÄRGE KUNAGI kirjutage hinnangut nii, nagu see oleks täpne.
Kontrollimine teise mudeliga (kohtuniku viip):
Olete sõltumatu valideerija. Allpool on tekst <allikas> ja <nõue>. Kontrollige, kas nõude IGA number ja kuupäev esinevad allikas sõna-sõnalt. Öelge iga kohta: "kinnitatud | pole allikas | on vastuolus allikaga." Kui kasvõi üks neist on "puudub/konfliktne", märkige tulemuseks "INIMÜLEVAADE VAJALIK".<source>{{ text }}</source><claim>{{ model_output }}</claim>
Usaldusläve marsruutimise reegel:
Marsruutimisreegel:- emin_misin = "kõrge" JA summa < 10 000 TL -> automaatne töötlemine - emin_misin = "keskmine" VÕI summa 10 000-100 000 TL -> teise mudeli kontrollimine- emin_misin = "madal" VÕI summa > 100 000 TL nõutav
Inimese auditi kokkuvõtte kaart (kiirendab ülevaatamist):
Otsust inimesele esitades esitage järgmine kaart: - Mida tehakse? (üks lause)- Mis allikal see põhineb? (artikli/dokumendi viide)- Millised on 2 kõige nõrgemat eeldust?- Kas heakskiitmise korral saab need ümber pöörata? (jah/ei)
Nõrk viip / Tugev viip
halb lähenemine
Tugev lähenemine
"Arvest summa lahutamine" (vaba tekst)
Range JSON-skeem + null + usaldusväli
Väljundi kirjutamine otse maksesüsteemi
Skeem → reegel → inimese heakskiit (vajadusel)
Lihtsalt öeldes modellile "ole kindel"
Numbri/kuupäeva kinnitamine teise mudeliga
Iga väljundi töötlemine võrdse enesekindlusega
Mõjul ja usaldusel põhinev marsruutimine
Tugev lähenemine ei looda, et mudel on õige; See loob ukse, mis püüab sind kinni, kui eksid.
Kolm miniümbrist
Juhtum 1 – skeemist üksi ei piisanud. Raamatupidamise automatiseerimine eraldas arvetelt summa JSON-vormingus. Skeem oli õige, kuid mudel andis arvel "1250,00" asemel "125 000" (kümnendkoha nihe). Skeem ei suutnud seda tabada; tabati reeglite kontrollimine ("summa peab olema kooskõlas arvekirjete kogusummaga ±1%") ja hoiti ära 112 500 TL vale kajastamine.
Juhtum 2 – teine mudel jäädvustas hallutsinatsiooni. "30 päeva etteteatamisega lõpetamisest," ütles õigusabi assistent lepingu kokkuvõttes; Lepingus oli see aga kirjas 90 päeva. Kui sõltumatu kohtunik märkis mudeli kui "allikaga vastuolus olevat", edastati väljund inimesele ja parandati. Kui see oleks automaatne, teavitaks klient tühistamisest vale kuupäeva alusel.
Juhtum 3 – marsruutimine vähendas koormust 70%. Kindlustusnõuete süsteem kiitis automaatselt heaks madalasummalised ja kõrge tagatisega kahjunõuded ning saatis eksperdile ainult need, mis ületasid piirmäära/madala turvalisuse. 3200 päevasest nõudest langes inimestele vaid 950; eksperdid pühendasid oma aega tõeliselt riskantsele 30%-le, kusjuures keskmine tehinguaeg langes 4 tunnilt 40 minutile.
Näpunäide: ärge seadistage inimlikku kontrolli nii, et "inimesed näevad kõike" – see väsitab inimesi ja heakskiit muutub kummitempliks. Selle asemel suunake inimesele ainult suure mõjuga ja madala usaldusväärsusega väljundid; See koondab tähelepanu sellele, mis on tõeliselt oluline.
Inimkontrolli muutmine tähendusrikkaks
Human-in-the-loop ei tähenda märkeruudu paberile panemist. Arvustajal peab olema (1) kontekst, et otsust mõista, (2) juurdepääs allikale ja (3) volitused öelda „ei”. Vastasel juhul jääb kontroll kosmeetiliseks. Ülevaatekaart (neljas mall ülal) on mõeldud just selle konteksti pakkumiseks.
Levinud vead
- Lihtsalt skeemi valideerimine ja sisu/väärtuse vigade vahelejätmine.
- Mõeldes, et öeldes mudelile "veendu", teete tõelist kontrolli.
- Rakendage automaatselt suure mõjuga ja pöördumatud otsused.
- Pannes iga väljundi inimliku kontrolli ja muutes heakskiidu mõttetuks kummitempliks.
- Öelge arvustajale "kinnita" ilma allikat ja konteksti avaldamata.
- Kõigi sama riskiga väljundite töötlemine ilma usaldusläve ja marsruutimiseta.
Kokkuvõttes
- Väljund on rikutud kolmel viisil: vorm, sisu ja pahatahtlikud kavatsused; kindel süsteem peatab kõik kolm ukse juures.
- Kihid: skeemi valideerimine, reegli/äriloogika, allika juhtimine, teine mudel (LLM-as-judge) ja usaldusläve marsruutimine.
- Inimene-in-the-loop peaks olema kohustuslik suure mõjuga ja madala turvalisusega väljundite jaoks.
- Inimülevaatus peab olema sisukas: ülevaatajal peab olema kontekst, juurdepääs ressurssidele ja õigus öelda "ei".
- Nii ohutus kui ka tõhusus saavutatakse, kui suunata inimestele ainult riskantsed, mitte iga väljund.
Rakenduse ülesanne
Võtke näide oma AI väljundist. Esmalt määratlege JSON-skeem ja sundige sellele väljund. Seejärel kirjutage vähemalt kaks ärireeglit (näiteks "summa vastab kaupade kogusummale"). Lõpuks koosta marsruutimistabel: milline usaldus/mõju kombinatsioon läheb automaatselt, milline teisele mudelile, milline inimesele? Looge vigane proov ja jälgige, kus iga kiht selle hõivab.
kontrollnimekiri
- [ ] Määran väljundi jaoks range skeemi ja kontrollin seda masinaga.
- [ ] Lisasin vähemalt ühe äri/reeglite valideerimise (väärtusloogika).
- [ ] Saan väited allikaga siduda ja neid kontrollida.
- [ ] Suure mõju/madala ohutuse jaoks on saadaval teine mudel või inimese kinnitus.
- [ ] Usalduse ja mõju põhjal määratletud marsruutimisreegel.
- [ ] Arvustajale antakse tagasilükkamiseks kontekst, allikas ja õigus.