Gevinster:
- Mulighed for at etablere skema- og regelbaserede outputvalideringslag
- Evne til meningsfuldt at kræve menneske-i-løkken i beslutninger med stor indflydelse
- Evne til at designe verifikation og tillidstærskelbaseret routing med den anden model
En sprogmodel producerer flydende, overbevisende og ofte nøjagtig - men "overbevisende" er ikke det samme som "korrekt." Modellen kan lydløst passe til et beløb, en dato eller et JSON-felt; Dette kaldes hallucination (modellen producerer trygt information, der ikke eksisterer i virkeligheden). I et virksomhedssystem, hvis dette output flyder til næste trin - en betaling, en e-mail, en databaseskrivning - smitter fejlen over i den virkelige verden. I denne enhed lærer vi at filtrere outputtet med verifikationslag, før det kommer ind i systemet, og at kræve menneske-in-the-loop i beslutninger med stor effekt.
Hvorfor er outputvalidering påkrævet?
Modeloutput kan beskadiges på to primære måder: format (overensstemmer ikke med det forventede JSON-skema, feltet mangler/overskydende) og indhold (formatet er korrekt, men værdien er forkert - en ikke-eksisterende produktkode, en ulogisk dato). Der er en tredje dimension med hensyn til sikkerhed: ondsindet output (en ondsindet kommando produceret som følge af injektion eller lækage). Et solidt system stopper alle tre ved døren.
Forsigtig: "Model generelt nøjagtig" er ikke et produktionskriterium. I et system uden verifikation betyder selv en fejl ud af tusind 100 fejlagtige transaktioner om dagen i 100.000 anmodninger om dagen.
Lag af autentificering: Trin for trin
- Skema validering. Kontroller med maskinen, at outputtet er i overensstemmelse med den forventede struktur: er felterne til stede, er deres typer korrekte, er de obligatoriske felter udfyldt?
- Validering af regel/forretningslogik. Passer værdierne til forretningsreglerne? (Beløb > 0, dato er ikke i fremtiden, produktkode hører til kataloget.)
- Reference/kildekontrol. Hvis modellen frembringer en påstand, kan den så linkes til kilden? (Er RAG-citatet faktisk i dokumentet?)
- Validering med den anden model (LLM-as-judge). En uafhængig model vurderer outputtet som "korrekt/ufuldstændigt/risikofyldt".
- Tillidstærskel og orientering. Hvis modellen eller validatoren rapporterer lav konfidens, passerer outputtet ikke automatisk; er rettet mod mennesker.
- Menneskelig kontrol. Et resultat med høj styrke eller lavt sikkert resultat afhænger af en eksperts godkendelse.
Fire kopierbare skabeloner
Skema + "find det op, hvis du ikke ved det" sammen:
Returner KUN svaret i følgende JSON-skema: Skriv "low". Skriv ALDRIG et skøn, som om det var nøjagtigt.
Verifikation med anden model (dommerprompt):
Du er en uafhængig validator. Nedenfor er en <kilde>-tekst og en <krav>. Tjek, om HVER tal og dato i påstanden forekommer ordret i kilden. Sig for hver enkelt: "verificeret | ikke i kilden | modsiger kilden." Hvis selv en af dem er 'fraværende/modstridende', skal du markere resultatet som "MENNESKELIG GENNEMGANG PÅKRÆVET".<source>{{ text }}</source><claim>{{ model_output }}</claim>
Ruteregel for tillidstærskel:
Ruteregel:- emin_misin = "høj" OG beløb < 10.000 TL -> automatisk behandling- emin_misin = "medium" ELLER beløb 10.000-100.000 TL -> anden modelbekræftelse- emin_misin = "lav" ELLER beløb > 100.000 TL påkrævet -> menneskelig godkendelse
Kort over menneskelig revision (fremskynder gennemgangen):
Når du præsenterer beslutningen for en person, skal du fremvise dette kort: - Hvad bliver foreslået? (én sætning)- Hvilken kilde er den baseret på? (artikel/dokumentreference)- Hvad er de 2 svageste antagelser?- Kan de, hvis de godkendes, omgøres? (ja/nej)
Svag prompt / stærk prompt
dårlig tilgang
Stærk tilgang
"Træk beløb fra faktura" (fritekst)
Strengt JSON-skema + null + tillidsfelt
Skrivning af output direkte til betalingssystemet
Skema → regel → menneskelig godkendelse (hvis nødvendigt)
Sig bare til modellen "vær sikker"
Nummer/dato validering med anden model
Behandler hvert output med lige stor selvtillid
Routing baseret på indflydelse og tillid
Den stærke tilgang håber ikke, at modellen er korrekt; Det skaber en dør, der fanger dig, når du tager fejl.
Tre mini etuier
Sag 1 — Ordningen alene var ikke nok. En regnskabsautomatisering var ved at udtrække beløbet fra fakturaerne som JSON. Ordningen var korrekt, men modellen producerede "125.000" i stedet for "1.250,00" på en faktura (decimalforskydning). Ordningen formåede ikke at fange dette; regelbekræftelse ("beløbet skal være i overensstemmelse med det samlede antal fakturaposter med ±1 %) blev fanget, og forkert registrering af 112.500 TL blev forhindret.
Case 2 - Den anden model fangede hallucinationen. "30 dages varsel om opsigelse," sagde en juridisk supportassistent i kontraktresuméet; I kontrakten var det dog 90 dage. Da den uafhængige dommer markerede modellen som "konfliktende med kilden", blev outputtet videresendt til mennesket og rettet. Hvis det var automatisk, ville kunden meddele annulleringen baseret på den forkerte dato.
Tilfælde 3 — Routing reducerede belastningen med 70 %. Et forsikringsskadesystem godkendte automatisk skader med lavt beløb og høj sikkerhed og sendte kun de over tærskel/lavsikre skader til eksperten. Af de 3.200 daglige krav faldt kun 950 til mennesker; eksperter viede deres tid til de virkelig risikable 30 %, hvor den gennemsnitlige transaktionstid faldt fra 4 timer til 40 minutter.
Tip: Indstil ikke menneskelig kontrol, så "folk kan se alt" - dette vil trætte folk ud, og godkendelse bliver et gummistempel. Send i stedet kun output med høj effekt og lav tillid til mennesket; Dette fokuserer opmærksomheden på det, der virkelig betyder noget.
Gør menneskelig kontrol meningsfuld
Menneske-i-løkken handler ikke om at sætte et afkrydsningsfelt på papir. Anmelderen skal have (1) konteksten til at forstå beslutningen, (2) adgang til kilden og (3) autoritet til at sige "nej". Ellers forbliver kontrollen kosmetisk. Gennemgangskortet (fjerde skabelon ovenfor) er beregnet til at give netop den kontekst.
Almindelige fejl
- Bare laver skemavalidering og springer indhold/værdifejl over.
- Tænker, at ved at fortælle modellen "sørg for", at du laver en reel verifikation.
- Implementer automatisk irreversible beslutninger med stor effekt.
- At sætte menneskelig kontrol på hvert output og forvandle godkendelse til et meningsløst gummistempel.
- At sige "godkend" til anmelderen uden at give kilde og sammenhæng.
- Behandling af alle output med samme risiko uden at etablere en tillidstærskel og routing.
Sammenfattende
- Outputtet er beskadiget på tre måder: form, indhold og ondsindet hensigt; et solidt system stopper alle tre ved døren.
- Lag: skemavalidering, regel/forretningslogik, kildekontrol, anden model (LLM-as-judge) og routing af tillidsgrænser.
- Human-in-the-loop bør være obligatorisk for output med høj effekt og lav sikkerhed.
- Menneskelig gennemgang skal være meningsfuld: anmelderen skal have kontekst, ressourceadgang og autoritet til at sige "nej."
- Både sikkerhed og effektivitet opnås ved kun at lede de risikable til mennesker, ikke alle output.
Ansøgningsopgave
Tag et eksempel fra din egen AI-output. Definer først et JSON-skema og tving output til det. Skriv derefter mindst to forretningsregler (f.eks. "beløb matcher alt af varer"). Til sidst opstil en routingtabel: hvilken tillid/påvirkningskombination går automatisk, hvilken går til den anden model, hvilken går til mennesket? Generer en defekt prøve og observer, hvor hvert lag fanger den.
tjekliste
- [ ] Jeg definerer et strengt skema for outputtet og verificerer det med maskinen.
- [ ] Jeg tilføjede mindst én virksomheds-/regelvalidering (værdilogik).
- [ ] Jeg kan knytte påstandene til kilden og kontrollere dem.
- [ ] Anden model eller menneskelig validering tilgængelig for høj effekt/lave sikkerhedsresultater.
- [ ] Routingregel defineret baseret på tillid og indflydelse.
- [ ] Anmelderen er forsynet med kontekst, kilde og autoritet til at afvise.