Dobici:
- Sposobnost uspostavljanja slojeva provjere valjanosti izlaza temeljenih na shemi i pravilima
- Sposobnost da se smisleno zahtijeva sudjelovanje čovjeka u procesu donošenja odluka s velikim utjecajem
- Sposobnost dizajniranja provjere i usmjeravanja temeljenog na pragu povjerenja s drugim modelom
Jezični model proizvodi fluidan, uvjerljiv i često točan - ali "uvjerljiv" nije isto što i "ispravan". Model može tiho uklopiti iznos, datum ili JSON polje; To se zove halucinacija (model pouzdano proizvodi informacije koje ne postoje u stvarnosti). U poslovnom sustavu, ako taj izlaz teče u sljedeći korak - plaćanje, e-pošta, pisanje baze podataka - pogreška se prelijeva u stvarni svijet. U ovoj jedinici naučit ćemo filtrirati izlaz slojevima provjere prije nego uđe u sustav i zahtijevati sudjelovanje čovjeka u petlji u odlukama s velikim utjecajem.
Zašto je potrebna provjera valjanosti izlaza?
Izlaz modela može biti oštećen na dva primarna načina: format (nije u skladu s očekivanom JSON shemom, polje nedostaje/višak) i sadržaj (format je točan, ali vrijednost je pogrešna — nepostojeći kod proizvoda, nelogičan datum). Postoji treća dimenzija u smislu sigurnosti: zlonamjerni izlaz (zlonamjerna naredba nastala kao rezultat ubacivanja ili curenja). Čvrsti sustav svu trojicu zaustavlja na vratima.
Oprez: "Model općenito točan" nije proizvodni kriterij. U sustavu bez verifikacije čak i jedna greška u tisuću znači 100 pogrešnih transakcija dnevno u 100.000 zahtjeva dnevno.
Slojevi autentifikacije: korak po korak
- Provjera valjanosti sheme. Provjerite sa strojem je li izlaz u skladu s očekivanom strukturom: jesu li polja prisutna, jesu li njihovi tipovi ispravni, jesu li obavezna polja ispunjena?
- Validacija pravila/poslovne logike. Odgovaraju li vrijednosti poslovnim pravilima? (Iznos > 0, datum nije u budućnosti, šifra proizvoda pripada katalogu.)
- Kontrola referenci/izvora. Ako model proizvede tvrdnju, može li se ona povezati s izvorom? (Je li RAG citat stvarno u dokumentu?)
- Validacija s drugim modelom (LLM-as-judge). Neovisni model ocjenjuje rezultat kao "točan/nepotpun/rizičan".
- Prag povjerenja i orijentacija. Ako model ili validator prijavi nisku pouzdanost, izlaz ne prolazi automatski; je usmjeren na ljude.
- Ljudska kontrola. Ishod visoke potencije ili niske sigurnosti ovisi o odobrenju stručnjaka.
Četiri predloška za kopiranje
Shema + "izmisli ako ne znaš" zajedno:
Vratite odgovor SAMO u sljedećoj JSON shemi: Napišite "low". NIKADA ne pišite procjenu kao da je točna.
Provjera s drugim modelom (upit za suca):
Vi ste neovisni validator. Ispod je <source> tekst i <claim>. Provjerite pojavljuju li se SVAKI broj i datum u zahtjevu doslovno u izvoru. Za svaki recite: "provjereno | nije u izvoru | proturječi izvoru." Ako je čak i jedan od njih 'odsutan/konfliktan', označite rezultat kao "ZAHTJEVAN LJUDSKI PREGLED".<source>{{ text }}</source><claim>{{ model_output }}</claim>
Pravilo usmjeravanja praga povjerenja:
Pravilo usmjeravanja:- emin_misin = "visoko" I iznos < 10.000 TL -> automatska obrada- emin_misin = "srednje" ILI iznos 10.000-100.000 TL -> druga provjera modela- emin_misin = "nisko" ILI iznos > 100.000 TL -> potrebno ljudsko odobrenje
Kartica sažetka ljudske revizije (ubrzava pregled):
Kada osobi predstavljate odluku, predočite ovu karticu: - Što se predlaže? (jedna rečenica)- Na kojem se izvoru temelji? (referenca na članak/dokument)- Koje su 2 najslabije pretpostavke?- Ako budu odobrene, mogu li se poništiti? (da/ne)
Slab upit / Jak upit
loš pristup
Snažan pristup
"Oduzmi iznos od fakture" (slobodan tekst)
Stroga JSON shema + null + polje povjerenja
Pisanje izlaza izravno u sustav plaćanja
Shema → pravilo → ljudsko odobrenje (ako je potrebno)
Samo govorim modelu "budi siguran"
Validacija broja/datuma s drugim modelom
Obrada svakog izlaza s jednakim povjerenjem
Usmjeravanje na temelju utjecaja i povjerenja
Snažan pristup ne nada se da je model točan; Stvara vrata koja će vas uhvatiti kada ste u krivu.
Tri mini kućišta
Slučaj 1 — Shema sama po sebi nije bila dovoljna. Računovodstvena automatizacija izvlačila je iznos iz faktura kao JSON. Shema je bila točna, ali je model proizveo "125.000" umjesto "1.250,00" na fakturi (decimalni pomak). Shema to nije uspjela uhvatiti; provjera pravila ("iznos mora biti u skladu s ukupnim brojem stavki fakture za ±1%") je uhvaćena i spriječeno je netočno bilježenje 112.500 TL.
Slučaj 2 — Drugi model je uhvatio halucinaciju. "30 dana obavijesti o raskidu", rekao je pomoćnik pravne podrške u sažetku ugovora; Međutim, u ugovoru je bilo 90 dana. Kad je neovisni sudac označio model kao "u sukobu s izvorom", rezultat je proslijeđen čovjeku i ispravljen. Da je automatski, kupac bi obavijestio o otkazivanju na temelju pogrešnog datuma.
Slučaj 3 — Usmjeravanje je smanjilo opterećenje za 70%. Sustav potraživanja osiguranja automatski je odobrio zahtjeve s malim iznosima i zahtjevima s visokim stupnjem sigurnosti i poslao stručnjaku samo one iznad praga/nisko sigurne. Od 3200 dnevnih potreba, samo 950 otpada na ljude; stručnjaci su svoje vrijeme posvetili doista rizičnih 30%, pri čemu je prosječno vrijeme transakcije palo s 4 sata na 40 minuta.
Savjet: nemojte postavljati ljudsku kontrolu tako da "ljudi mogu sve vidjeti" — to će ih umoriti i odobravanje će postati guma. Umjesto toga, samo usmjerite izlaze visokog utjecaja i niske pouzdanosti na čovjeka; Ovo usmjerava pozornost na ono što je stvarno važno.
Učiniti ljudsku kontrolu smislenom
Human-in-the-loop nije stavljanje potvrdnog okvira na papir. Recenzent mora imati (1) kontekst za razumijevanje odluke, (2) pristup izvoru i (3) ovlast reći "ne". Inače, kontrola ostaje kozmetička. Kartica s pregledom (četvrti predložak iznad) trebala bi pružiti upravo taj kontekst.
Uobičajene greške
- Samo provodim provjeru valjanosti sheme i preskačem pogreške sadržaja/vrijednosti.
- Misleći da govoreći modelu "uvjeri se" radite stvarnu provjeru.
- Automatski provodite visoko utjecajne, nepovratne odluke.
- Stavljanje ljudske kontrole na svaki rezultat i pretvaranje odobrenja u besmisleni gumeni pečat.
- Govor recenzentu "odobri" bez navođenja izvora i konteksta.
- Obrada svih izlaza s istim rizikom bez uspostavljanja praga pouzdanosti i usmjeravanja.
Ukratko
- Izlaz je oštećen na tri načina: oblik, sadržaj i zlonamjerna namjera; čvrsti sustav sve troje zaustavlja na vratima.
- Slojevi: provjera valjanosti sheme, pravilo/poslovna logika, kontrola izvora, drugi model (LLM-as-judge) i usmjeravanje praga povjerenja.
- Čovjek u petlji trebao bi biti obavezan za izlaze s velikim utjecajem i niskom sigurnošću.
- Ljudski pregled mora biti smislen: recenzent mora imati kontekst, pristup resursima i ovlasti reći "ne".
- I sigurnost i učinkovitost postižu se usmjeravanjem samo rizičnih na ljude, a ne svakog izlaza.
Zadatak aplikacije
Uzmite primjer iz vlastite umjetne inteligencije. Najprije definirajte JSON shemu i prisilite izlaz na nju. Zatim napišite najmanje dva poslovna pravila (na primjer, "iznos odgovara ukupnom broju stavki"). Na kraju, postavite tablicu usmjeravanja: koja kombinacija povjerenja/utjecaja ide automatski, koja ide drugom modelu, koja ide čovjeku? Generirajte neispravan uzorak i promatrajte gdje ga svaki sloj hvata.
popis za provjeru
- [ ] Definiram strogu shemu za izlaz i provjeravam je sa strojem.
- [ ] Dodao sam najmanje jednu provjeru valjanosti poslovanja/pravila (logika vrijednosti).
- [ ] Mogu povezati tvrdnje s izvorom i provjeriti ih.
- [ ] Drugi model ili ljudska validacija dostupna za ishode velikog utjecaja/niske sigurnosti.
- [ ] Pravilo usmjeravanja definirano na temelju povjerenja i utjecaja.
- [ ] Recenzent ima kontekst, izvor i ovlast za odbijanje.