Vinster:
- Möjlighet att upprätta schema- och regelbaserade utdatavalideringslager
- Förmåga att på ett meningsfullt sätt kräva människa-i-slingan i beslut med stor genomslagskraft
- Möjlighet att designa verifiering och förtroendetröskelbaserad routing med den andra modellen
En språkmodell producerar flytande, övertygande och ofta korrekt – men "övertygande" är inte detsamma som "korrekt". Modellen kan tyst passa ett belopp, ett datum eller ett JSON-fält; Detta kallas hallucination (modellen producerar med säkerhet information som inte finns i verkligheten). I ett företagssystem, om den utmatningen går till nästa steg - en betalning, ett e-postmeddelande, en databasskrivning - sprider felet över till den verkliga världen. I den här enheten kommer vi att lära oss att filtrera utdata med verifieringslager innan det kommer in i systemet och att kräva människa-i-slingan i beslut med stor effekt.
Varför krävs utdatavalidering?
Modellutdata kan förstöras på två primära sätt: format (överensstämmer inte med det förväntade JSON-schemat, fält saknas/överskott) och innehåll (formatet är korrekt men värdet är fel — en icke-existerande produktkod, ett ologiskt datum). Det finns en tredje dimension när det gäller säkerhet: skadlig utdata (ett skadligt kommando som skapas som ett resultat av injektion eller läcka). Ett solidt system stoppar alla tre vid dörren.
Varning: "Modell generellt korrekt" är inte ett produktionskriterium. I ett system utan verifiering innebär även ett fel på tusen 100 felaktiga transaktioner per dag i 100 000 förfrågningar per dag.
Lager av autentisering: Steg för steg
- Schemavalidering. Kontrollera med maskinen att utdata överensstämmer med den förväntade strukturen: finns fälten närvarande, är deras typer korrekta, är de obligatoriska fälten ifyllda?
- Regel/affärslogikvalidering. Matchar värderingarna affärsreglerna? (Belopp > 0, datum är inte i framtiden, produktkoden tillhör katalogen.)
- Referens/källa kontroll. Om modellen producerar ett påstående, kan det kopplas till källan? (Finns RAG-citatet verkligen i dokumentet?)
- Validering med den andra modellen (LLM-as-judge). En oberoende modell utvärderar resultatet som "korrekt/ofullständig/risk".
- Förtroendetröskel och orientering. Om modellen eller validatorn rapporterar lågt förtroende, passerar inte utdata automatiskt; är riktad till människor.
- Mänsklig kontroll. Ett högpotens eller lågt säkert resultat beror på en experts godkännande.
Fyra kopieringsbara mallar
Schema + "finn på om du inte vet" tillsammans:
Returnera ENDAST svaret i följande JSON-schema: Skriv "låg". Skriv ALDRIG en uppskattning som om den vore exakt.
Verifiering med andra modellen (domaruppmaning):
Du är en oberoende validator. Nedan finns en <källa>-text och en <claim>. Kontrollera om VARJE siffra och datum i påståendet står ordagrant i källan. För varje, säg: "verifierad | inte i källan | motsäger källan." Om ens en av dem är "frånvarande/konfliktiga", markera resultatet som "HUMAN GRANSKNING KRÄVS".<källa>{{ text }}</source><claim>{{ model_output }}</claim>
Routningsregel för förtroendetröskel:
Routningsregel:- emin_misin = "hög" OCH belopp < 10 000 TL -> automatisk bearbetning- emin_misin = "medium" ELLER belopp 10 000-100 000 TL -> andra modellverifiering- emin_misin = "lågt" ELLER belopp > 100 000 TL krävs -> mänskligt godkännande
Sammanfattningskort för mänsklig revision (påskyndar granskningen):
När du presenterar beslutet för en person, visa detta kort: - Vad föreslås? (en mening)- Vilken källa är den baserad på? (artikel/dokumentreferens)- Vilka är de två svagaste antagandena?- Om de godkänns, kan de vändas? (ja/nej)
Svag prompt / Stark prompt
dåligt tillvägagångssätt
Starkt förhållningssätt
"Ta bort belopp från faktura" (fritext)
Strikt JSON-schema + null + förtroendefält
Skriva utdata direkt till betalningssystemet
Schema → regel → mänskligt godkännande (om nödvändigt)
Säg bara till modellen "var säker"
Antal/datum validering med andra modellen
Bearbetar varje utdata med lika självförtroende
Routing baserad på inflytande och förtroende
Det starka förhållningssättet hoppas inte att modellen är korrekt; Det skapar en dörr som fångar dig när du har fel.
Tre minifodral
Fall 1 — Systemet i sig var inte tillräckligt. En bokföringsautomatisering extraherade beloppet från fakturorna som JSON. Schemat var korrekt, men modellen gav "125 000" istället för "1 250,00" på en faktura (decimalskifte). Schemat lyckades inte fånga detta; regelverifiering ("beloppet måste överensstämma med summan av fakturaposter med ±1 %) fångades och felaktig registrering av 112 500 TL förhindrades.
Fall 2 — Den andra modellen fångade hallucinationen. "30 dagars varsel om uppsägning," sa en juridisk supportassistent i kontraktssammanfattningen; I kontraktet var det dock 90 dagar. När den oberoende domaren flaggade modellen som "konflikt med källan", skickades utdata till människan och korrigerades. Om det var automatiskt skulle kunden meddela avbokningen baserat på fel datum.
Fall 3 — Dirigering minskade belastningen med 70 %. Ett försäkringsskadesystem godkände automatiskt fordringar med lågt belopp och hög säkerhet och skickade endast de över tröskelvärdena/lågsäkra fordringarna till experten. Av de 3 200 dagliga kraven föll endast 950 till människor; experter ägnade sin tid åt de verkligt riskabla 30 %, med den genomsnittliga transaktionstiden som sjönk från 4 timmar till 40 minuter.
Tips: Ställ inte in mänsklig kontroll så att "människor kan se allt" - detta kommer att trötta ut folk och godkännande kommer att bli en gummistämpel. Istället dirigera endast utdata med hög effekt och lågt förtroende till människan; Detta fokuserar uppmärksamheten på det som verkligen betyder något.
Gör mänsklig kontroll meningsfull
Human-in-the-loop handlar inte om att sätta en kryssruta på papper. Granskaren måste ha (1) sammanhanget för att förstå beslutet, (2) tillgång till källan och (3) behörighet att säga "nej". Annars förblir kontrollen kosmetisk. Granskningskortet (fjärde mallen ovan) är tänkt att ge just det sammanhanget.
Vanliga misstag
- Gör bara schemavalidering och hoppar över innehåll/värdefel.
- Tänker att genom att säga till modellen "se till att" du gör riktig verifiering.
- Implementera automatiskt oåterkalleliga beslut med stor genomslagskraft.
- Att sätta mänsklig kontroll på varje produktion och förvandla godkännande till en meningslös gummistämpel.
- Att säga "godkänna" till granskaren utan att ange källa och sammanhang.
- Bearbetar alla utdata med samma risk utan att etablera en förtroendetröskel och routing.
Sammanfattningsvis
- Utdata skadas på tre sätt: form, innehåll och skadlig avsikt; ett solidt system stoppar alla tre vid dörren.
- Lager: schemavalidering, regel/affärslogik, källkontroll, andra modell (LLM-as-judge) och routing för förtroendetröskel.
- Människan-i-slingan bör vara obligatorisk för utdata med hög effekt och låg säkerhet.
- Mänsklig granskning måste vara meningsfull: granskaren måste ha sammanhang, tillgång till resurser och befogenhet att säga "nej".
- Både säkerhet och effektivitet uppnås genom att bara rikta de riskabla till människor, inte alla resultat.
Applikationsuppgift
Ta ett exempel från din egen AI-utgång. Definiera först ett JSON-schema och tvinga utdata till det. Skriv sedan minst två affärsregler (till exempel "beloppet matchar totalt antal artiklar"). Slutligen, sätt upp en routingtabell: vilken förtroende/inflytande-kombination går automatiskt, vilken går till den andra modellen, vilken går till människan? Generera ett felaktigt prov och observera var varje lager fångar det.
checklista
- [ ] Jag definierar ett strikt schema för utdata och verifierar det med maskinen.
- [ ] Jag har lagt till minst en verksamhets-/regelvalidering (värdelogik).
- [ ] Jag kan länka påståendena till källan och kontrollera dem.
- [ ] Andra modellen eller mänsklig validering tillgänglig för hög effekt/låga säkerhetsresultat.
- [ ] Routingregel definierad utifrån förtroende och inflytande.
- [ ] Granskaren förses med sammanhang, källa och behörighet att avvisa.