Ieguvumi:
- Spēja izveidot shēmas un uz kārtulām balstītus izvades validācijas slāņus
- Spēja jēgpilni pieprasīt cilvēku lokā, pieņemot spēcīgus lēmumus
- Spēja izstrādāt verifikāciju un uzticamības slieksni balstītu maršrutēšanu ar otro modeli
Valodas modelis rada plūstošu, pārliecinošu un bieži vien precīzu, taču “pārliecinošs” nav tas pats, kas “pareizs”. Modelis var klusi ievietot summu, datumu vai JSON lauku; To sauc par halucinācijām (modelis pārliecinoši rada informāciju, kas patiesībā neeksistē). Ja uzņēmuma sistēmā šī izvade pāriet uz nākamo soli - maksājumu, e-pastu, datubāzes rakstīšanu -, kļūda tiek izplatīta reālajā pasaulē. Šajā nodaļā mēs iemācīsimies filtrēt izvadi ar verifikācijas slāņiem, pirms tā nonāk sistēmā, un pieprasīt cilvēku cilpā, pieņemot spēcīgus lēmumus.
Kāpēc ir nepieciešama izvades apstiprināšana?
Modeļa izvadi var sabojāt divos primārajos veidos: formātā (neatbilst paredzētajai JSON shēmai, trūkst/pārmērīgs lauks) un saturs (formāts ir pareizs, bet vērtība ir nepareiza — neesošs produkta kods, neloģisks datums). Ir trešā drošības dimensija: ļaunprātīga izvade (ļaunprātīga komanda, kas rodas injekcijas vai noplūdes rezultātā). Cietā sistēma visus trīs apstādina pie durvīm.
Uzmanību: "Modelis kopumā ir precīzs" nav ražošanas kritērijs. Sistēmā bez verifikācijas pat viena kļūda no tūkstoša nozīmē 100 kļūdainus darījumus dienā 100 000 pieprasījumu dienā.
Autentifikācijas slāņi: soli pa solim
- Shēmas validācija. Pārbaudiet ar iekārtu, vai izvade atbilst paredzamajai struktūrai: vai ir lauki, vai to veidi ir pareizi, vai nepieciešamie lauki ir aizpildīti?
- Noteikumu/biznesa loģikas validācija. Vai vērtības atbilst biznesa noteikumiem? (Summa > 0, datums nav nākotnē, preces kods pieder katalogam.)
- Atsauces/avota vadība. Ja modelis rada apgalvojumu, vai to var saistīt ar avotu? (Vai RAG citāts patiešām ir dokumentā?)
- Validācija ar otro modeli (LLM-as-judge). Neatkarīgs modelis novērtē rezultātu kā "pareizu/nepilnīgu/riskantu".
- Uzticības slieksnis un orientācija. Ja modelis vai validators ziņo par zemu ticamību, izvade netiek automātiski nodota; ir vērsta uz cilvēkiem.
- Cilvēka kontrole. Augstas iedarbības vai zemas drošības rezultāts ir atkarīgs no eksperta apstiprinājuma.
Četras kopējamas veidnes
Shēma + "izdomā, ja nezināt" kopā:
Atgrieziet atbildi šādā TIKAI JSON shēmā: ierakstiet “zems”. NEKAD nerakstiet tāmi tā, it kā tā būtu precīza.
Verifikācija ar otro modeli (tiesneša uzvedne):
Jūs esat neatkarīgs pārbaudītājs. Zemāk ir <avota> teksts un <pretenzija>. Pārbaudiet, vai KATRS pretenzijas numurs un datums avotā ir norādīts burtiski. Par katru sakiet: "pārbaudīts | nav avotā | ir pretrunā ar avotu." Ja kaut viens no tiem ir “nav klāt/konfliktē”, atzīmējiet rezultātu kā “NEPIECIEŠAMA PĀRSKATĪŠANA CILVĒKĀ”.<source>{{ text }}</source><claim>{{ model_output }}</claim>
Uzticamības sliekšņa maršrutēšanas noteikums:
Maršrutēšanas noteikums:- emin_misin = "augsta" UN summa < 10 000 TL -> automātiska apstrāde- emin_misin = "vidēja" VAI summa 10 000-100 000 TL -> otrā modeļa pārbaude - emin_misin = "zema" VAI summa > 100 000 TL
Cilvēka audita kopsavilkuma karte (paātrina pārskatīšanu):
Iesniedzot personai lēmumu, uzrādiet šo karti:- Kas tiek piedāvāts? (viens teikums)- Uz kādu avotu tas balstās? (raksta/dokumenta atsauce)- Kādi ir 2 vājākie pieņēmumi?- Ja tie tiek apstiprināti, vai tos var mainīt? (jā/nē)
Vāja uzvedne / spēcīga uzvedne
slikta pieeja
Spēcīga pieeja
"Atņemt summu no rēķina" (brīvs teksts)
Stingra JSON shēma + null + uzticamības lauks
Izvades ierakstīšana tieši maksājumu sistēmā
Shēma → noteikums → cilvēka apstiprinājums (ja nepieciešams)
Vienkārši pasaku modelim "pārliecinies"
Numura/datuma apstiprināšana ar otro modeli
Ar vienādu pārliecību tiek apstrādāta katra produkcija
Maršrutēšana, pamatojoties uz ietekmi un uzticību
Spēcīgā pieeja necer, ka modelis ir pareizs; Tas rada durvis, kas jūs aizķers, kad jūs kļūdāties.
Trīs mini futrāļi
1. gadījums — ar shēmu vien nepietika. Grāmatvedības automatizācija izvilka summu no rēķiniem kā JSON. Shēma bija pareiza, taču modelis rēķinā uzrādīja "125 000", nevis "1 250,00" (decimālā maiņa). Shēmai to neizdevās uztvert; noteikumu pārbaude ("summai jāatbilst rēķina preču kopsummai par ±1%") tika pieķerta un novērsta nepareiza 112 500 TL ierakstīšana.
2. gadījums — otrais modelis iemūžināja halucinācijas. “30 dienas paziņojums par izbeigšanu,” līguma kopsavilkumā teica juridiskā atbalsta palīgs; Tomēr līgumā tas bija 90 dienas. Kad neatkarīgais tiesnesis modeli atzīmēja kā “konfliktējošu ar avotu”, izvade tika pārsūtīta cilvēkam un labota. Ja tas būtu automātiski, klients paziņotu par atcelšanu, pamatojoties uz nepareizu datumu.
3. gadījums — maršrutēšana samazināja slodzi par 70%. Apdrošināšanas atlīdzību sistēma automātiski apstiprināja mazas summas un augstas drošības prasības un nosūtīja ekspertam tikai tos, kas pārsniedz slieksni/zemu drošumu. No 3200 ikdienas prasībām tikai 950 krita uz cilvēkiem; eksperti veltīja savu laiku patiesi riskantajiem 30%, vidējam darījuma laikam samazinoties no 4 stundām līdz 40 minūtēm.
Padoms. Neiestatiet cilvēka kontroli tā, lai "cilvēki varētu redzēt visu" — tas cilvēkus nogurdinās un apstiprinājums kļūs par gumijas zīmogu. Tā vietā nosūtiet cilvēkam tikai augstas ietekmes un zemas ticamības rezultātus; Tas pievērš uzmanību tam, kas patiešām ir svarīgs.
Cilvēka kontroles padarīšana jēgpilnu
Human-in-the-loop nav izvēles rūtiņas ievietošana uz papīra. Recenzentam ir jābūt (1) kontekstam, lai saprastu lēmumu, (2) piekļuvei avotam un (3) pilnvarām pateikt “nē”. Pretējā gadījumā kontrole paliek kosmētiska. Pārskata kartīte (ceturtā veidne iepriekš) ir paredzēta, lai sniegtu tieši šo kontekstu.
Biežas kļūdas
- Vienkārši veicam shēmas validāciju un izlaižam satura/vērtības kļūdas.
- Domājot, ka, pasakot modelim "pārliecinieties", jūs veicat īstu pārbaudi.
- Automātiski ieviesiet spēcīgus, neatgriezeniskus lēmumus.
- Cilvēka kontrole pār katru rezultātu un apstiprinājuma pārvēršana bezjēdzīgā gumijas zīmogā.
- Sakot recenzentam “apstiprināt”, nenorādot avotu un kontekstu.
- Visu izvadu apstrāde ar tādu pašu risku, nenosakot uzticamības slieksni un maršrutēšanu.
Rezumējot
- Izvade tiek bojāta trīs veidos: forma, saturs un ļaunprātīgs nolūks; cieta sistēma aptur visus trīs pie durvīm.
- Slāņi: shēmas validācija, noteikumu/biznesa loģika, avota kontrole, otrais modelis (LLM-as-Judge) un uzticamības sliekšņa maršrutēšana.
- Cilvēkam cilpā jābūt obligātai augstas ietekmes un zemas drošības izvadēm.
- Cilvēka veiktajai pārskatīšanai ir jābūt jēgpilnai: recenzentam ir jābūt kontekstam, piekļuvei resursiem un pilnvarām pateikt “nē”.
- Gan drošība, gan efektivitāte tiek iegūta, novirzot tikai riskantos cilvēkus, nevis katru produkciju.
Lietojumprogrammas uzdevums
Ņemiet piemēru no savas AI izvades. Vispirms definējiet JSON shēmu un piespiediet tai izvadīt. Pēc tam uzrakstiet vismaz divus uzņēmējdarbības noteikumus (piemēram, “summa atbilst preču kopsummai”). Visbeidzot, izveidojiet maršrutēšanas tabulu: kura uzticēšanās/ietekmes kombinācija pāriet automātiski, kura uz otro modeli, kura uz cilvēku? Izveidojiet kļūdainu paraugu un novērojiet, kur katrs slānis to uztver.
kontrolsaraksts
- [ ] Es definēju stingru izvades shēmu un pārbaudu to ar mašīnu.
- [ ] Es pievienoju vismaz vienu uzņēmuma/noteikumu validāciju (vērtību loģiku).
- [ ] Es varu saistīt apgalvojumus ar avotu un pārbaudīt tos.
- [ ] Ir pieejams otrs modelis vai cilvēka apstiprinājums lielai ietekmei/zemiem drošības rezultātiem.
- [ ] Maršrutēšanas noteikums, kas noteikts, pamatojoties uz uzticēšanos un ietekmi.
- [ ] Recenzentam tiek sniegts konteksts, avots un tiesības noraidīt.