Dobički:
- Sposobnost vzpostavitve plasti preverjanja izhoda na podlagi sheme in pravil
- Sposobnost smiselnega zahtevanja človeka v zanki pri odločitvah z velikim vplivom
- Zmožnost oblikovanja usmerjanja na podlagi preverjanja in praga zaupanja z drugim modelom
Jezikovni model je tekoč, prepričljiv in pogosto natančen, vendar "prepričljiv" ni isto kot "pravilen". Model se lahko tiho prilega znesku, datumu ali polju JSON; To se imenuje halucinacija (model samozavestno proizvaja informacije, ki v resnici ne obstajajo). Če v podjetniškem sistemu ta izhod preide v naslednji korak - plačilo, e-pošta, zapis v bazo podatkov - se napaka prelije v resnični svet. V tej enoti se bomo naučili filtrirati izhod s sloji za preverjanje, preden vstopi v sistem, in zahtevati sodelovanje človeka v zanki pri odločitvah z velikim vplivom.
Zakaj je potrebna validacija izhoda?
Izhodni podatki modela so lahko poškodovani na dva glavna načina: oblika (ni v skladu s pričakovano shemo JSON, polje manjka/odvečno) in vsebina (forma je pravilna, vendar je vrednost napačna — neobstoječa koda izdelka, nelogičen datum). Obstaja še tretja dimenzija glede varnosti: zlonamerni izhod (zlonamerni ukaz, ki nastane kot posledica vbrizgavanja ali uhajanja). Trden sistem vse tri ustavi na vratih.
Pozor: "Model na splošno natančen" ni proizvodni kriterij. V sistemu brez verifikacije že ena napaka na tisoč pomeni 100 napačnih transakcij na dan v 100.000 zahtevah na dan.
Plasti avtentikacije: korak za korakom
- Preverjanje sheme. Z napravo preverite, ali je izhod v skladu s pričakovano strukturo: ali so polja prisotna, ali so njihove vrste pravilne, ali so zahtevana polja izpolnjena?
- Validacija pravil/poslovne logike. Ali se vrednosti ujemajo s poslovnimi pravili? (Znesek > 0, datum ni v prihodnosti, koda izdelka spada v katalog.)
- Nadzor sklicevanja/vira. Če model ustvari trditev, ali jo je mogoče povezati z virom? (Ali je citat RAG dejansko v dokumentu?)
- Validacija z drugim modelom (LLM-as-judge). Neodvisni model oceni rezultat kot "pravilen/nepopoln/tvegan".
- Prag zaupanja in usmeritev. Če model ali validator poroča o nizki stopnji zaupanja, izhod ne bo samodejno prestal; je namenjeno ljudem.
- Človeški nadzor. Visoko učinkovit ali nizko varen rezultat je odvisen od odobritve strokovnjaka.
Štiri kopirane predloge
Shema + "izmisli si, če ne veš" skupaj:
Odgovor vrni SAMO v naslednji shemi JSON: Napišite "low". NIKOLI ne napišite ocene, kot da bi bila natančna.
Preverjanje z drugim modelom (poziv sodnika):
Ste neodvisni validator. Spodaj je besedilo <source> in <claim>. Preverite, ali se VSAKA številka in datum v zahtevku pojavlja dobesedno v viru. Za vsako recite: "preverjeno | ni v viru | nasprotuje viru." Če je vsaj eden od njih 'odsoten/v nasprotju', označite rezultat kot "ZAHTEVAN JE LJUDSKI PREGLED".<source>{{ text }}</source><claim>{{ model_output }}</claim>
Pravilo usmerjanja praga zaupanja:
Pravilo usmerjanja:- emin_misin = "visoko" IN znesek < 10.000 TL -> samodejna obdelava- emin_misin = "srednje" ALI znesek 10.000-100.000 TL -> drugo preverjanje modela- emin_misin = "nizek" ALI znesek > 100.000 TL -> potrebna je odobritev človeka
Kartica s povzetkom človeške revizije (pospeši pregled):
Ko osebi predstavite odločitev, dajte to kartico: - Kaj je predlagano? (en stavek)- Na katerem viru temelji? (referenca na članek/dokument) – Kateri sta 2 najšibkejši predpostavki? – Če sta odobreni, ju je mogoče razveljaviti? (da/ne)
Šibek poziv / močan poziv
slab pristop
Močan pristop
"Odštej znesek od računa" (prosto besedilo)
Stroga shema JSON + null + polje zaupanja
Pisanje izhoda neposredno v plačilni sistem
Shema → pravilo → človeška odobritev (če je potrebno)
Modelu samo rečem "bodi prepričan"
Preverjanje številke/datuma z drugim modelom
Obdelava vsakega izhoda z enakim zaupanjem
Usmerjanje na podlagi vpliva in zaupanja
Močan pristop ne upa, da je model pravilen; Ustvari vrata, ki vas bodo ujela, ko se boste zmotili.
Trije mini kovčki
Primer 1 – Shema sama ni bila dovolj. Računovodska avtomatizacija je izvlekla znesek iz računov kot JSON. Shema je bila pravilna, vendar je model proizvedel "125.000" namesto "1.250,00" na računu (decimalni premik). Shema tega ni uspela zajeti; preverjanje pravila (»znesek mora biti v skladu s skupno postavko na računu za ±1 %«) je bilo ulovljeno in preprečeno je bilo napačno beleženje 112.500 TL.
Primer 2 — Drugi model je ujel halucinacije. »30-dnevno obvestilo o odpovedi,« je v povzetku pogodbe dejal pomočnik pravne podpore; Vendar je bilo v pogodbi 90 dni. Ko je neodvisni sodnik označil model kot "v nasprotju z virom", je bil rezultat posredovan človeku in popravljen. Če bi bilo samodejno, bi stranka obvestila o odpovedi na podlagi napačnega datuma.
Primer 3 – Usmerjanje je zmanjšalo obremenitev za 70 %. Sistem zavarovalnih zahtevkov je samodejno odobril zahtevke z nizkimi zneski in zahtevke z visoko varnostjo ter strokovnjaku poslal samo tiste, ki so nad pragom/nizko varovani. Od 3200 dnevnih potreb jih je le 950 padlo na ljudi; strokovnjaki so svoj čas posvetili resnično tveganim 30 %, pri čemer se je povprečni čas transakcije zmanjšal s 4 ur na 40 minut.
Namig: Človeškega nadzora ne nastavite tako, da "lahko ljudje vidijo vse" - to bo ljudi utrudilo in odobravanje bo postalo gumijasti pečat. Namesto tega na človeka usmerite samo rezultate z velikim vplivom in nizko stopnjo zaupanja; To usmeri pozornost na tisto, kar je resnično pomembno.
Človeški nadzor postane pomenljiv
Human-in-the-loop ne pomeni, da potrditveno polje postavite na papir. Pregledovalec mora imeti (1) kontekst za razumevanje odločitve, (2) dostop do vira in (3) pooblastilo, da reče "ne". V nasprotnem primeru nadzor ostaja kozmetičen. Pregledna kartica (četrta predloga zgoraj) naj bi zagotovila ravno ta kontekst.
Pogoste napake
- Samo preverjanje sheme in preskakovanje napak vsebine/vrednosti.
- Mislite, da s tem, ko modelu rečete "prepričajte se", izvajate resnično preverjanje.
- Samodejno izvajajte zelo vplivne, nepreklicne odločitve.
- Človeški nadzor nad vsakim rezultatom in spreminjanje odobritve v nesmiselno gumijasto žigosanje.
- Recenzentu reči »odobri«, ne da bi navedli vir in kontekst.
- Obdelava vseh izhodov z enakim tveganjem brez vzpostavitve praga zaupanja in usmerjanja.
Če povzamem
- Izhod je pokvarjen na tri načine: oblika, vsebina in zlonamerni namen; trden sistem ustavi vse tri na vratih.
- Plasti: preverjanje sheme, pravilo/poslovna logika, nadzor vira, drugi model (LLM-as-judge) in usmerjanje praga zaupanja.
- Človek v zanki bi moral biti obvezen za rezultate z velikim vplivom in nizko varnostjo.
- Človeški pregled mora biti smiseln: pregledovalec mora imeti kontekst, dostop do virov in pooblastilo, da reče "ne".
- Varnost in učinkovitost dosežemo z usmerjanjem samo tveganih na ljudi, ne pa vseh rezultatov.
Aplikacijska naloga
Vzemite primer iz lastnega rezultata AI. Najprej definirajte shemo JSON in ji vsilite izhod. Nato napišite vsaj dve poslovni pravili (na primer »znesek se ujema s skupnim številom postavk«). Končno nastavite usmerjevalno tabelo: katera kombinacija zaupanja/vpliva gre samodejno, katera k drugemu modelu, katera k človeku? Ustvarite napačen vzorec in opazujte, kje ga posamezna plast zajame.
kontrolni seznam
- [ ] Definiram strogo shemo za izhod in jo preverim s strojem.
- [ ] Dodal sem vsaj eno potrditev poslovanja/pravil (logika vrednosti).
- [ ] Trditve znam povezati z virom in jih preveriti.
- [ ] Drugi model ali človeška validacija je na voljo za rezultate z velikim vplivom/nizko varnostjo.
- [ ] Pravilo usmerjanja, opredeljeno na podlagi zaupanja in vpliva.
- [ ] Pregledovalcu so na voljo kontekst, vir in pooblastilo za zavrnitev.