Câștiguri:
- Abilitatea de a stabili straturi de validare a rezultatelor bazate pe scheme și reguli
- Capacitatea de a solicita în mod semnificativ un om în buclă în decizii cu impact ridicat
- Abilitatea de a proiecta verificarea și rutarea bazată pe pragul de încredere cu cel de-al doilea model
Un model de limbaj produce fluid, persuasiv și adesea precis, dar „persuasiv” nu este același lucru cu „corect”. Modelul poate încadra în tăcere o sumă, o dată sau un câmp JSON; Aceasta se numește halucinație (modelul produce cu încredere informații care nu există în realitate). Într-un sistem de întreprindere, dacă acea ieșire trece la pasul următor - o plată, un e-mail, o scriere de bază de date - eroarea se revarsă în lumea reală. În această unitate, vom învăța să filtram ieșirea cu straturi de verificare înainte de a intra în sistem și să solicităm un om în buclă în deciziile cu impact ridicat.
De ce este necesară validarea ieșirii?
Ieșirea modelului poate fi coruptă în două moduri principale: format (nu este conform cu schema JSON așteptată, câmpul lipsește/exces) și conținut (formatul este corect, dar valoarea este greșită - un cod de produs inexistent, o dată ilogică). Există o a treia dimensiune în ceea ce privește securitatea: ieșirea rău intenționată (o comandă rău intenționată produsă ca urmare a injectării sau scurgerii). Un sistem solid îi oprește pe toți trei la ușă.
Atenție: „Modelul în general precis” nu este un criteriu de producție. Într-un sistem fără verificare, chiar și o eroare la o mie înseamnă 100 de tranzacții eronate pe zi în 100.000 de solicitări pe zi.
Straturi de autentificare: pas cu pas
- Validarea schemei. Verificați cu mașina dacă rezultatul este conform cu structura așteptată: sunt câmpurile prezente, tipurile lor sunt corecte, câmpurile obligatorii sunt completate?
- Validarea regulilor/logicii de afaceri. Se potrivesc valorile cu regulile de afaceri? (Suma > 0, data nu este în viitor, codul produsului aparține catalogului.)
- Controlul referințelor/sursei. Dacă modelul produce o aserțiune, poate fi legat de sursă? (Citatul RAG este de fapt în document?)
- Validare cu al doilea model (LLM-as-judge). Un model independent evaluează rezultatul drept „corec/incomplet/risc”.
- Pragul de încredere și orientare. Dacă modelul sau validatorul raportează o încredere scăzută, rezultatul nu trece automat; este îndreptată către oameni.
- Controlul uman. Un rezultat cu potență ridicată sau cu siguranță scăzută depinde de aprobarea unui expert.
Patru șabloane copiabile
Schema + „inventează-te dacă nu știi” împreună:
Returnați răspunsul NUMAI în următoarea schemă JSON: scrieți „low”. NU scrie NICIODATĂ o estimare ca și cum ar fi exactă.
Verificare cu al doilea model (promptul judecătorului):
Sunteți un validator independent. Mai jos este un text <sursă> și o <revendicare>. Verificați pentru a vedea dacă FIECARE număr și dată din revendicare apar literal în sursă. Pentru fiecare, spuneți: „verificat | nu în sursă | contrazice sursa”. Dacă chiar și unul dintre ele este „absent/in conflict”, marcați rezultatul ca „NECESARĂ REVIZIE UMANĂ”.<source>{{ text }}</source><claim>{{ model_output }}</claim>
Regula de rutare a pragului de încredere:
Regula de rutare:- emin_misin = „mare” ȘI cantitate < 10.000 TL -> procesare automată- emin_misin = „medie” SAU cantitate 10.000-100.000 TL -> al doilea model de verificare- emin_misin = „scăzut” SAU cantitate > 100.000 TL necesară -> este necesară aprobarea umană
Card rezumat al auditului uman (accelerează revizuirea):
Când prezentați decizia unei persoane, prezentați acest card: - Ce se propune? (o propoziție)- Pe ce sursă se bazează? (referință articol/document)- Care sunt cele mai slabe 2 ipoteze?- Dacă sunt aprobate, pot fi inversate? (da/nu)
Solicitare slabă / Solicitare puternică
abordare slabă
Abordare puternică
„Scădeți suma din factură” (text liber)
Schemă JSON strictă + câmp nul + de încredere
Scrierea rezultatului direct în sistemul de plată
Schemă → regulă → aprobare umană (dacă este necesar)
Doar spune modelului „fii sigur”
Validare număr/data cu al doilea model
Procesarea fiecărei rezultate cu aceeași încredere
Dirijare bazată pe influență și încredere
Abordarea puternică nu speră că modelul este corect; Creează o ușă care te va prinde atunci când greșești.
Trei mini carcase
Cazul 1 — Schema în sine nu a fost suficientă. O automatizare contabilă extragea suma din facturi ca JSON. Schema a fost corectă, dar modelul a produs „125.000” în loc de „1.250,00” pe o factură (schift zecimal). Schema nu a reușit să surprindă acest lucru; verificarea regulilor („suma trebuie să fie în concordanță cu totalul articolelor din factură cu ±1%”) a fost prinsă și a fost împiedicată înregistrarea incorectă a 112.500 TL.
Cazul 2 — Al doilea model a surprins halucinația. „Aviz de 30 de zile de reziliere”, a spus un asistent de asistență juridică în rezumatul contractului; Totuși, în contract era de 90 de zile. Când judecătorul independent a semnalat modelul ca „în conflict cu sursa”, rezultatul a fost transmis omului și corectat. Dacă ar fi automat, clientul ar notifica anularea pe baza unei date greșite.
Cazul 3 — Rutarea a redus sarcina cu 70%. Un sistem de daune de asigurare a aprobat automat daunele cu sumă mică și de înaltă securitate și le-a trimis expertului doar pe cele de peste prag/securitate scăzută. Din cele 3.200 de cereri zilnice, doar 950 au căzut în sarcina oamenilor; experții și-au dedicat timpul celor 30% cu adevărat riscante, timpul mediu de tranzacție scăzând de la 4 ore la 40 de minute.
Sfat: nu configurați controlul uman astfel încât „oamenii să poată vedea totul” – acest lucru îi va obosi pe oameni, iar aprobarea va deveni o ștampilă de cauciuc. În schimb, direcționați doar rezultate cu impact ridicat și cu încredere scăzută către om; Acest lucru concentrează atenția asupra a ceea ce contează cu adevărat.
A face controlul uman semnificativ
Human-in-the-loop nu este despre a pune o casetă de selectare pe hârtie. Revizorul trebuie să aibă (1) contextul pentru a înțelege decizia, (2) acces la sursă și (3) autoritatea de a spune „nu”. În caz contrar, controlul rămâne cosmetic. Cardul de recenzie (al patrulea șablon de mai sus) este menit să ofere tocmai acel context.
Greșeli comune
- Facem doar validarea schemei și omit erorile de conținut/valoare.
- Gândindu-mă că spunându-i modelului „asigură-te” că faci o verificare reală.
- Implementați automat decizii ireversibile cu impact ridicat.
- Pune control uman asupra fiecărei rezultate și transformă aprobarea într-o ștampilă de cauciuc fără sens.
- Spunând „aprobă” recenzentului fără a oferi sursa și contextul.
- Procesarea tuturor rezultatelor cu același risc fără a stabili un prag de încredere și o rutare.
Pe scurt
- Ieșirea este coruptă în trei moduri: formă, conținut și intenție rău intenționată; un sistem solid îi oprește pe toți trei la ușă.
- Straturi: validarea schemei, regulă/logica de afaceri, controlul sursei, al doilea model (LLM-as-judge) și rutarea pragului de încredere.
- Human-in-the-loop ar trebui să fie obligatoriu pentru rezultate cu impact ridicat și cu siguranță scăzută.
- Evaluarea umană trebuie să fie semnificativă: examinatorul trebuie să aibă context, acces la resurse și autoritatea de a spune „nu”.
- Atât siguranța, cât și eficiența sunt câștigate prin direcționarea doar a celor riscante către oameni, nu către fiecare rezultat.
Sarcina de aplicare
Luați un exemplu din propria dvs. ieșire AI. Mai întâi definiți o schemă JSON și forțați ieșirea la aceasta. Apoi scrieți cel puțin două reguli de afaceri (de exemplu, „suma se potrivește cu totalul articolelor”). În cele din urmă, configurați un tabel de rutare: care combinație de încredere/influență merge automat, care merge la al doilea model, care merge la uman? Generați un eșantion defect și observați unde îl captează fiecare strat.
lista de verificare
- [ ] Definesc o schemă strictă pentru ieșire și o verific cu mașina.
- [ ] Am adăugat cel puțin o validare de afaceri/reguli (logica valorii).
- [ ] Pot lega afirmațiile la sursă și le pot verifica.
- [ ] Al doilea model sau validare umană disponibilă pentru rezultate cu impact ridicat/siguranță scăzută.
- [ ] Regula de rutare definită pe baza încrederii și influenței.
- [ ] Revizorului i se oferă contextul, sursa și autoritatea de respingere.