zisky:
- Schopnost vytvořit výstupní validační vrstvy založené na schématu a pravidlech
- Schopnost smysluplně vyžadovat člověka ve smyčce při rozhodování s velkým dopadem
- Schopnost navrhnout směrování založené na ověřování a prahu důvěry s druhým modelem
Jazykový model vytváří plynulé, přesvědčivé a často přesné – ale „přesvědčivý“ není totéž jako „správný“. Model může tiše přizpůsobit částku, datum nebo pole JSON; Tomu se říká halucinace (model sebevědomě produkuje informace, které ve skutečnosti neexistují). Pokud v podnikovém systému tento výstup přejde do dalšího kroku – platba, e-mail, zápis do databáze – chyba se přelije do skutečného světa. V této jednotce se naučíme filtrovat výstup pomocí ověřovacích vrstev předtím, než vstoupí do systému, a vyžadovat zapojení člověka ve smyčce při rozhodování s velkým dopadem.
Proč je vyžadováno ověření výstupu?
Výstup modelu může být poškozen dvěma primárními způsoby: formát (neodpovídá očekávanému schématu JSON, pole chybí/přebývá) a obsah (formát je správný, ale hodnota je špatná — neexistující kód produktu, nelogické datum). Pokud jde o bezpečnost, existuje třetí rozměr: škodlivý výstup (škodlivý příkaz vytvořený v důsledku injekce nebo úniku). Pevný systém zastaví všechny tři u dveří.
Upozornění: "Model obecně přesný" není výrobním kritériem. V systému bez ověřování i jedna chyba z tisíce znamená 100 chybných transakcí za den ve 100 000 žádostech za den.
Vrstvy autentizace: Krok za krokem
- Validace schématu. Zkontrolujte pomocí stroje, že výstup odpovídá očekávané struktuře: jsou přítomna pole, jsou jejich typy správné, jsou povinná pole vyplněna?
- Ověření pravidel/obchodní logiky. Odpovídají hodnoty obchodním pravidlům? (Částka > 0, datum není v budoucnosti, kód produktu patří do katalogu.)
- Ovládání reference/zdroje. Pokud model vytváří tvrzení, lze jej propojit se zdrojem? (Je citát RAG skutečně v dokumentu?)
- Validace s druhým modelem (LLM-as-judge). Nezávislý model hodnotí výstup jako „správný/neúplný/rizikový“.
- Práh důvěry a orientace. Pokud model nebo validátor hlásí nízkou spolehlivost, výstup automaticky neprojde; je zaměřena na lidi.
- Lidská kontrola. Vysoce účinný nebo málo bezpečný výsledek závisí na schválení odborníkem.
Čtyři kopírovatelné šablony
Schéma + „vymysli si, když to nevíš“:
Vraťte odpověď POUZE v následujícím schématu JSON: Napište „nízká“. NIKDY nepište odhad, jako by byl přesný.
Ověření s druhým modelem (výzva rozhodčího):
Jste nezávislým validátorem. Níže je <zdrojový> text a <nárok>. Zkontrolujte, zda se KAŽDÉ číslo a datum v nároku vyskytují doslovně ve zdroji. U každého řekněte: "ověřeno | není ve zdroji | odporuje zdroji." Pokud je byť jen jeden z nich 'nepřítomný/v konfliktu', označte výsledek jako "VYŽADOVÁNA KONTROLA ČLOVĚKEM".<zdroj>{{ text }}</source><claim>{{ model_output }}</claim>
Pravidlo směrování prahu důvěry:
Směrovací pravidlo:- emin_misin = "vysoké" A množství < 10 000 TL -> automatické zpracování- emin_misin = "střední" NEBO množství 10 000-100 000 TL -> ověření druhého modelu- emin_misin = "nízké" NEBO množství > 100 -> 000 TL požadované lidské schválení
Karta shrnutí lidského auditu (urychluje kontrolu):
Při předkládání rozhodnutí osobě předložte tuto kartu: Co se navrhuje? (jedna věta)- Z jakého zdroje to vychází? (odkaz na článek/dokument)- Jaké jsou 2 nejslabší předpoklady?- Pokud budou schváleny, lze je zvrátit? (ano/ne)
Slabá výzva / Silná výzva
špatný přístup
Silný přístup
"Odečíst částku z faktury" (volný text)
Přísné schéma JSON + null + pole důvěryhodnosti
Zápis výstupu přímo do platebního systému
Schéma → pravidlo → schválení člověkem (v případě potřeby)
Jen říkám modelu "buď si jistý"
Číslo/datum ověření u druhého modelu
Zpracování každého výstupu se stejnou důvěrou
Směrování založené na vlivu a důvěře
Silný přístup nedoufá, že model je správný; Vytváří dveře, které vás zachytí, když se zmýlíte.
Tři mini pouzdra
Případ 1 – Samotný režim nestačil. Účetní automatizace extrahovala částku z faktur jako JSON. Schéma bylo správné, ale model produkoval „125 000“ místo „1 250,00“ na faktuře (desetinný posun). Toto schéma nedokázalo zachytit; ověření pravidla („částka musí odpovídat součtu položek faktury o ±1 %“) a bylo zabráněno nesprávnému zaúčtování 112 500 TL.
Případ 2 — Druhý model zachytil halucinaci. „30denní výpovědní lhůta,“ uvedl asistent právní podpory ve shrnutí smlouvy; Ve smlouvě však bylo 90 dní. Když nezávislý soudce označil model za „v konfliktu se zdrojem“, výstup byl předán člověku a opraven. Pokud by to bylo automatické, zákazník by oznámil zrušení na základě špatného data.
Případ 3 – Směrování snížilo zatížení o 70 %. Systém pojistných událostí automaticky schvaloval nízko a vysoce zabezpečené pojistné události a znalci zasílal pouze ty nadlimitní/nízkozabezpečené. Z 3200 denních požadavků připadlo jen 950 na lidi; odborníci věnovali svůj čas skutečně rizikovým 30 %, přičemž průměrná doba transakce klesla ze 4 hodin na 40 minut.
Tip: Nenastavujte lidskou kontrolu tak, aby „lidé všechno viděli“ — to lidi unaví a schválení se stane razítkem. Místo toho směřujte k člověku pouze vysoce účinné a málo spolehlivé výstupy; Tím se soustředí pozornost na to, na čem skutečně záleží.
Aby měla lidská kontrola smysl
Human-in-the-loop není o umístění zaškrtávacího políčka na papír. Recenzent musí mít (1) kontext, aby porozuměl rozhodnutí, (2) přístup ke zdroji a (3) oprávnění říci „ne“. Jinak ovládání zůstává kosmetické. Karta s přehledem (čtvrtá šablona výše) má poskytnout právě tento kontext.
Časté chyby
- Provádím pouze ověřování schématu a přeskakování chyb obsahu/hodnoty.
- Myslet si, že když modelu řeknete „ujistěte se“, děláte skutečné ověření.
- Automaticky implementujte vysoce účinná a nevratná rozhodnutí.
- Zavedení lidské kontroly nad každým výstupem a proměna souhlasu v nesmyslné razítko.
- Říci „schválit“ recenzentovi bez uvedení zdroje a kontextu.
- Zpracování všech výstupů se stejným rizikem bez stanovení prahu důvěryhodnosti a směrování.
V souhrnu
- Výstup je poškozen třemi způsoby: formou, obsahem a zlým úmyslem; pevný systém zastaví všechny tři u dveří.
- Vrstvy: ověření schématu, pravidlo/obchodní logika, řízení zdroje, druhý model (LLM-as-judge) a směrování prahu důvěryhodnosti.
- U výstupů s vysokým dopadem a nízkou bezpečností by měla být funkce Human in the Loop povinná.
- Lidská recenze musí být smysluplná: recenzent musí mít kontext, přístup ke zdrojům a pravomoc říci „ne“.
- Bezpečnost i účinnost se získá tím, že se na člověka směřují pouze ty rizikové, ne každý výstup.
Aplikační úkol
Vezměte si příklad z vlastního výstupu AI. Nejprve definujte schéma JSON a vynucení výstupu do něj. Poté napište alespoň dvě obchodní pravidla (například „množství odpovídá celkovému počtu položek“). Nakonec nastavte směrovací tabulku: která kombinace důvěry/vlivu jde automaticky, která jde do druhého modelu, která jde do člověka? Vygenerujte vadný vzorek a sledujte, kde jej jednotlivé vrstvy zachycují.
kontrolní seznam
- [ ] Definuji striktní schéma pro výstup a ověřuji ho na stroji.
- [ ] Přidal jsem alespoň jedno ověření podnikání/pravidel (logika hodnot).
- [ ] Mohu propojit tvrzení se zdrojem a zkontrolovat je.
- [ ] Druhý model nebo lidské ověření k dispozici pro výsledky s vysokým dopadem/nízkou bezpečností.
- [ ] Směrovací pravidlo definované na základě důvěry a vlivu.
- [ ] Recenzent má k dispozici kontext, zdroj a oprávnění odmítnout.