Dobici:
- Sposobnost uspostavljanja slojeva validacije izlaza zasnovanih na šemi i pravilima
- Sposobnost da smisleno zahtijevaju čovjeka u petlji u odlukama s velikim utjecajem
- Mogućnost dizajniranja verifikacije i rutiranja zasnovanog na pragu poverenja sa drugim modelom
Jezički model proizvodi fluidan, uvjerljiv i često tačan - ali "uvjerljiv" nije isto što i "tačan". 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 sistemu, ako taj izlaz teče u sljedeći korak — plaćanje, e-mail, upis u bazu podataka — greška se prelijeva u stvarni svijet. U ovoj jedinici naučićemo da filtriramo izlaz sa slojevima verifikacije pre nego što uđe u sistem i da zahtevamo čoveka u petlji u odlukama sa velikim uticajem.
Zašto je potrebna validacija izlaza?
Izlaz modela može biti oštećen na dva primarna načina: format (ne odgovara očekivanoj JSON šemi, polje nedostaje/višak) i sadržaj (format je ispravan, ali je vrijednost pogrešna — nepostojeći kod proizvoda, nelogičan datum). Postoji treća dimenzija u smislu sigurnosti: zlonamjerni izlaz (zlonamjerna naredba proizvedena kao rezultat injekcije ili curenja). Čvrst sistem zaustavlja sve troje na vratima.
Oprez: "Model općenito tačan" nije proizvodni kriterij. U sistemu bez verifikacije, čak i jedna greška na hiljadu znači 100 pogrešnih transakcija dnevno na 100.000 zahteva dnevno.
Slojevi provjere autentičnosti: korak po korak
- Validacija šeme. Proverite sa mašinom da li je izlaz u skladu sa očekivanom strukturom: da li su polja prisutna, da li su njihovi tipovi tačni, da li su popunjena obavezna polja?
- Validacija pravila/poslovne logike. Poklapaju li se vrijednosti s poslovnim pravilima? (Količina > 0, datum nije u budućnosti, šifra proizvoda pripada katalogu.)
- Referentna/izvorna kontrola. Ako model proizvede tvrdnju, može li se povezati s izvorom? (Da li je citat RAG-a zapravo u dokumentu?)
- Validacija sa drugim modelom (LLM-kao sudija). Nezavisni model procjenjuje rezultat kao "tačan/nepotpun/rizičan".
- Prag povjerenja i orijentacija. Ako model ili validator prijavi nisku pouzdanost, izlaz neće automatski proći; je usmjeren na ljude.
- Ljudska kontrola. Ishod visoke potencije ili niske sigurnosti ovisi o odobrenju stručnjaka.
Četiri predloška koji se mogu kopirati
Šema + "izmislite ako ne znate" zajedno:
Vratite odgovor SAMO u sljedećoj JSON šemi: Napišite "low". NIKADA ne pišite procjenu kao da je tačna.
Verifikacija sa drugim modelom (prompt sudije):
Vi ste nezavisni validator. Ispod je <izvor> tekst i <zahtjev>. Provjerite da li se SVAKI broj i datum u zahtjevu pojavljuju doslovno u izvoru. Za svaki recite: "provjereno | nije u izvoru | kontradiktorno izvoru." Ako je čak jedan od njih 'odsutan/konfliktan', označite rezultat kao "POTREBAN LJUDSKI PREGLED".<izvor>{{ text }}</source><claim>{{ model_output }}</claim>
Pravilo usmjeravanja praga povjerenja:
Pravilo usmjeravanja:- emin_misin = "visoki" I iznos < 10.000 TL -> automatska obrada- emin_misin = "srednji" ILI iznos 10.000-100.000 TL -> provjera drugog modela- emin_misin = "nizak" ILI iznos > 100.000 TL -> potreban ljudski zahtjev
Kartica sažetka ljudske revizije (ubrzava pregled):
Prilikom predstavljanja odluke osobi, predočite ovu karticu: - Šta se predlaže? (jedna rečenica)- Na kom se izvoru zasniva? (referenca na članak/dokument)- Koje su 2 najslabije pretpostavke?- Ako se odobre, mogu li se poništiti? (da/ne)
Slaba prompt / jaka prompt
loš pristup
Snažan pristup
"Oduzmi iznos od fakture" (besplatan tekst)
Stroga JSON shema + null + polje povjerenja
Pisanje izlaza direktno u platni sistem
Shema → pravilo → ljudsko odobrenje (ako je potrebno)
Samo kažem modelu "budi siguran"
Potvrda broja/datuma sa drugim modelom
Obrada svakog rezultata sa jednakim povjerenjem
Usmjeravanje zasnovano na utjecaju i povjerenju
Snažan pristup se ne nada da je model ispravan; To stvara vrata koja će vas uhvatiti kada pogriješite.
Tri mini futrole
Slučaj 1 — Sama šema nije bila dovoljna. Računovodstvena automatizacija je izdvajala iznos iz faktura kao JSON. Šema je bila ispravna, ali model je proizveo "125.000" umjesto "1.250.00" na fakturi (decimalni pomak). Šema to nije uspjela uhvatiti; uhvaćena je provjera pravila ("iznos mora biti u skladu sa ukupnim stavcima fakture za ±1%") i spriječeno je pogrešno evidentiranje 112.500 TL.
Slučaj 2 — Drugi model je uhvatio halucinaciju. „30 dana obaveštenja o raskidu“, rekao je pomoćnik za pravnu podršku u sažetku ugovora; Međutim, u ugovoru je to bilo 90 dana. Kada je nezavisni sudija označio model kao "konflikt sa izvorom", rezultat je prosleđen čoveku i ispravljen. Da je automatski, kupac bi obavijestio o otkazivanju na osnovu pogrešnog datuma.
Slučaj 3 — Usmjeravanje je smanjilo opterećenje za 70%. Sistem za odštetne zahtjeve u osiguranju automatski je odobravao zahtjeve s niskim iznosom i visokim osiguranjem i šalje stručnjaku samo one iznad praga/nisko sigurnih. Od 3.200 dnevnih potreba, samo 950 pada na ljude; stručnjaci su svoje vrijeme posvetili zaista rizičnih 30%, pri čemu je prosječno vrijeme transakcije palo sa 4 sata na 40 minuta.
Savjet: Ne postavljajte ljudsku kontrolu tako da "ljudi mogu vidjeti sve" - to će umoriti ljude i odobravanje će postati pečat. Umjesto toga, usmjerite samo rezultate s velikim utjecajem i niskim povjerenjem do čovjeka; Ovo usmjerava pažnju na ono što je zaista važno.
Osmišljavanje ljudske kontrole
Čovjek u petlji ne znači stavljanje polja za potvrdu na papir. Recenzent mora imati (1) kontekst da razumije odluku, (2) pristup izvoru i (3) ovlaštenje da kaže „ne“. U suprotnom, kontrola ostaje kozmetička. Kartica za pregled (četvrti predložak iznad) treba da pruži upravo taj kontekst.
Uobičajene greške
- Samo radim provjeru valjanosti sheme i preskače greške sadržaja/vrijednosti.
- Razmišljajući da govoreći modelu "uvjeri se" radite pravu verifikaciju.
- Automatski implementirajte nepovratne odluke velikog utjecaja.
- Stavljanje ljudske kontrole na svaki izlaz i pretvaranje odobrenja u besmisleni gumeni pečat.
- Recenzentu kažete "odobri" bez navođenja izvora i konteksta.
- Obrada svih izlaza s istim rizikom bez uspostavljanja praga povjerenja i usmjeravanja.
Ukratko
- Izlaz je oštećen na tri načina: oblik, sadržaj i zlonamjerna namjera; čvrst sistem zaustavlja sve troje na vratima.
- Slojevi: validacija šeme, pravilo/poslovna logika, kontrola izvora, drugi model (LLM-kao sudija) i usmjeravanje praga povjerenja.
- Čovjek u petlji trebao bi biti obavezan za izlaze s visokim utjecajem i niskom sigurnošću.
- Ljudski pregled mora biti smislen: recenzent mora imati kontekst, pristup resursima i ovlaštenje da kaže „ne“.
- I sigurnost i efikasnost se postižu usmjeravanjem samo onih rizičnih na ljude, a ne svakog rezultata.
Zadatak aplikacije
Uzmite primjer iz vlastitog AI izlaza. Prvo definirajte JSON shemu i prisilite izlaz na nju. Zatim napišite najmanje dva poslovna pravila (na primjer, “iznos odgovara ukupnom broju stavki”). Konačno, postavite tabelu rutiranja: koja kombinacija povjerenja/utjecaja ide automatski, koja ide na drugi model, a koja na čovjeka? Generirajte neispravan uzorak i promatrajte gdje ga svaki sloj hvata.
kontrolna lista
- [ ] Definiram strogu šemu za izlaz i provjeravam je sa mašinom.
- [ ] Dodao sam barem jednu validaciju poslovanja/pravila (logika vrijednosti).
- [ ] Mogu povezati tvrdnje sa izvorom i provjeriti ih.
- [ ] Dostupan je drugi model ili ljudska validacija za velike rezultate/niske sigurnosne rezultate.
- [ ] Pravilo rutiranja definirano na osnovu povjerenja i utjecaja.
- [ ] Recenzent ima kontekst, izvor i ovlaštenje da odbije.