Gevinster:
- Evne til å etablere skjema- og regelbaserte utdatavalideringslag
- Evne til meningsfullt å kreve menneske-i-løkken i beslutninger med stor effekt
- Evne til å designe verifikasjon og tillitsterskelbasert ruting med den andre modellen
En språkmodell produserer flytende, overbevisende og ofte nøyaktig - men "overbevisende" er ikke det samme som "korrekt." Modellen kan stille inn et beløp, en dato eller et JSON-felt; Dette kalles hallusinasjon (modellen produserer trygt informasjon som ikke eksisterer i virkeligheten). I et bedriftssystem, hvis utdataene går til neste trinn - en betaling, en e-post, en databaseskriving - smitter feilen over i den virkelige verden. I denne enheten vil vi lære å filtrere utdataene med verifiseringslag før det kommer inn i systemet og å kreve menneske-i-løkken i beslutninger med stor effekt.
Hvorfor kreves utdatavalidering?
Modellutdata kan bli ødelagt på to primære måter: format (samsvarer ikke med det forventede JSON-skjemaet, feltet mangler/overflødig) og innhold (formatet er riktig, men verdien er feil - en ikke-eksisterende produktkode, en ulogisk dato). Det er en tredje dimensjon når det gjelder sikkerhet: ondsinnet utgang (en ondsinnet kommando produsert som et resultat av injeksjon eller lekkasje). Et solid system stopper alle tre ved døren.
Advarsel: "Modellen er generelt nøyaktig" er ikke et produksjonskriterium. I et system uten verifisering betyr selv én feil av tusen 100 feiltransaksjoner per dag i 100 000 forespørsler per dag.
Lag med autentisering: trinn for trinn
- Skjemavalidering. Sjekk med maskinen at utgangen samsvarer med den forventede strukturen: finnes feltene, er typene riktige, er de obligatoriske feltene fylt ut?
- Regel/forretningslogikkvalidering. Stemmer verdiene med forretningsreglene? (Beløp > 0, dato er ikke i fremtiden, produktkode tilhører katalogen.)
- Referanse/kildekontroll. Hvis modellen produserer en påstand, kan den knyttes til kilden? (Er RAG-sitatet faktisk i dokumentet?)
- Validering med den andre modellen (LLM-as-judge). En uavhengig modell vurderer resultatet som "riktig/ufullstendig/risikofylt".
- Tillitsterskel og orientering. Hvis modellen eller validatoren rapporterer lav konfidens, passerer ikke utdata automatisk; er rettet mot mennesker.
- Menneskelig kontroll. Et utfall med høy styrke eller lite trygt avhenger av en eksperts godkjenning.
Fire kopierbare maler
Opplegg + "finn på hvis du ikke vet" sammen:
Returner responsen KUN i følgende JSON-skjema: Skriv "lav". ALDRI skriv et anslag som om det var nøyaktig.
Verifikasjon med andre modell (dommermelding):
Du er en uavhengig validator. Nedenfor er en <kilde>-tekst og en <krav>. Sjekk om HVER tall og dato i påstanden står ordrett i kilden. For hver, si: "verifisert | ikke i kilden | motsier kilden." Hvis til og med en av dem er "fraværende/motstridende", merk resultatet som "MENNESKELIG GJENNOMGANG KREVES".<kilde>{{ tekst }}</source><claim>{{ model_output }}</claim>
Rutingregel for tillitsterskel:
Rutingregel:- emin_misin = "høy" OG beløp < 10 000 TL -> automatisk behandling- emin_misin = "middels" ELLER beløp 10 000-100 000 TL -> andre modellverifisering- emin_misin = "lav" ELLER beløp > 100 000 TL nødvendig -> menneskelig godkjenning
Sammendragskort for menneskelig revisjon (fremskynder gjennomgangen):
Når du presenterer avgjørelsen for en person, legg frem dette kortet: - Hva blir foreslått? (én setning)- Hvilken kilde er den basert på? (artikkel/dokumentreferanse)- Hva er de 2 svakeste forutsetningene?- Kan de reverseres hvis de blir godkjent? (ja/nei)
Svak forespørsel / sterk forespørsel
dårlig tilnærming
Sterk tilnærming
"Trekk beløp fra faktura" (fritekst)
Strengt JSON-skjema + null + tillitsfelt
Skrive utdata direkte til betalingssystemet
Skjema → regel → menneskelig godkjenning (om nødvendig)
Bare si til modellen "vær sikker"
Antall/dato validering med andre modell
Behandler hver utgang med samme selvtillit
Ruting basert på innflytelse og tillit
Den sterke tilnærmingen håper ikke at modellen er riktig; Det skaper en dør som vil fange deg når du tar feil.
Tre minivesker
Sak 1 — Ordningen alene var ikke nok. En regnskapsautomatisering hentet beløpet fra fakturaene som JSON. Ordningen var riktig, men modellen produserte "125 000" i stedet for "1 250,00" på en faktura (desimalforskyvning). Opplegget klarte ikke å fange opp dette; regelverifisering ("beløpet må være i tråd med totalen av fakturaposter med ±1 %) ble fanget og feil registrering av 112 500 TL ble forhindret.
Tilfelle 2 - Den andre modellen fanget hallusinasjonen. "30 dagers varsel om oppsigelse," sa en juridisk støtteassistent i kontraktssammendraget; I kontrakten var det imidlertid 90 dager. Da den uavhengige dommeren flagget modellen som "konflikt med kilden", ble utdataene videresendt til mennesket og korrigert. Hvis det var automatisk, ville kunden varslet kanselleringen basert på feil dato.
Tilfelle 3 — Ruting reduserte belastningen med 70 %. Et forsikringsskadesystem godkjente automatisk lavbeløps- og høysikkerhetskrav og sendte kun de over terskel/lavsikrede til eksperten. Av de 3200 daglige kravene falt bare 950 til mennesker; eksperter viet tiden sin til de virkelig risikable 30 %, med gjennomsnittlig transaksjonstid som sank fra 4 timer til 40 minutter.
Tips: Ikke sett opp menneskelig kontroll slik at «folk kan se alt» – dette vil slite ut folk og godkjenning blir et gummistempel. I stedet skal du bare sende utganger med høy effekt og lav selvtillit til mennesket; Dette fokuserer oppmerksomheten på det som virkelig betyr noe.
Gjør menneskelig kontroll meningsfull
Human-in-the-loop handler ikke om å sette en avkrysningsboks på papir. Anmelderen må ha (1) konteksten for å forstå avgjørelsen, (2) tilgang til kilden og (3) myndighet til å si «nei». Ellers forblir kontrollen kosmetisk. Gjennomgangskortet (fjerde mal ovenfor) er ment å gi akkurat den konteksten.
Vanlige feil
- Bare gjør skjemavalidering og hopper over innhold/verdifeil.
- Tenker at ved å fortelle modellen "sørg for at" du gjør ekte verifisering.
- Implementer automatisk irreversible beslutninger med stor effekt.
- Å sette menneskelig kontroll på hver utgang og gjøre godkjenning til et meningsløst gummistempel.
- Å si "godkjenne" til anmelderen uten å oppgi kilde og kontekst.
- Behandler alle utdata med samme risiko uten å etablere en tillitsterskel og ruting.
Oppsummert
- Utdataene blir ødelagt på tre måter: form, innhold og ondsinnet hensikt; et solid system stopper alle tre ved døren.
- Lag: skjemavalidering, regel/forretningslogikk, kildekontroll, andre modell (LLM-as-judge) og ruting av tillitsterskel.
- Human-in-the-loop bør være obligatorisk for utganger med høy effekt og lav sikkerhet.
- Menneskelig vurdering må være meningsfull: anmelderen må ha kontekst, ressurstilgang og autoritet til å si «nei».
- Både sikkerhet og effektivitet oppnås ved å rette bare de risikofylte til mennesker, ikke alle utdata.
Søknadsoppgave
Ta et eksempel fra din egen AI-utgang. Definer først et JSON-skjema og tving utdataene til det. Skriv deretter minst to forretningsregler (for eksempel "beløpet samsvarer med totalt antall varer"). Til slutt, sett opp en rutetabell: hvilken tillit/innflytelse-kombinasjon går automatisk, hvilken går til den andre modellen, hvilken går til mennesket? Generer en defekt prøve og observer hvor hvert lag fanger den.
sjekkliste
- [ ] Jeg definerer et strengt skjema for utdataene og verifiserer det med maskinen.
- [ ] Jeg la til minst én virksomhet/regelvalidering (verdilogikk).
- [ ] Jeg kan koble påstandene til kilden og sjekke dem.
- [ ] Andre modell eller menneskelig validering tilgjengelig for høy effekt/lavt sikkerhetsresultat.
- [ ] Rutingregel definert basert på tillit og innflytelse.
- [ ] Anmelderen er utstyrt med kontekst, kilde og autoritet til å avvise.