Yunit 3 / 11

Pagpapatunay ng Output at Pagsusuri ng Tao

Mga nadagdag:

  • Kakayahang magtatag ng schema at mga layer ng pagpapatunay ng output na nakabatay sa panuntunan
  • Kakayahang makabuluhang mangailangan ng human-in-the-loop sa mga desisyong may mataas na epekto
  • Kakayahang magdisenyo ng pag-verify at pagtitiwala sa pagruruta batay sa threshold sa pangalawang modelo

Ang isang modelo ng wika ay gumagawa ng tuluy-tuloy, mapanghikayat, at kadalasang tumpak—ngunit ang "mapanghikayat" ay hindi katulad ng "tama." Maaaring tahimik na magkasya ang modelo sa isang halaga, petsa, o isang field ng JSON; Ito ay tinatawag na guni-guni (ang modelo ay may kumpiyansa na gumagawa ng impormasyon na hindi umiiral sa katotohanan). Sa isang enterprise system, kung ang output na iyon ay dumadaloy sa susunod na hakbang — isang pagbabayad, isang email, isang database write — ang error ay dumaloy sa totoong mundo. Sa unit na ito, matututuhan nating i-filter ang output gamit ang mga layer ng pag-verify bago ito pumasok sa system at humiling ng human-in-the-loop sa mga desisyong may mataas na epekto.

Bakit Kinakailangan ang Output Validation?

Maaaring masira ang output ng modelo sa dalawang pangunahing paraan: format (hindi umaayon sa inaasahang JSON schema, kulang/labis ang field) at content (tama ang format ngunit mali ang value — isang hindi umiiral na code ng produkto, isang hindi makatwirang petsa). Mayroong ikatlong dimensyon sa mga tuntunin ng seguridad: malisyosong output (isang malisyosong utos na ginawa bilang resulta ng pag-iniksyon o pagtagas). Isang solidong sistema ang huminto sa tatlo sa pintuan.

Babala: Ang "modelo sa pangkalahatan ay tumpak" ay hindi isang pamantayan sa produksyon. Sa isang system na walang pag-verify, kahit isang error sa isang libo ay nangangahulugang 100 maling transaksyon bawat araw sa 100,000 kahilingan bawat araw.

Mga Layer ng Authentication: Hakbang sa Hakbang

  1. Pagpapatunay ng schema. Suriin sa makina kung ang output ay umaayon sa inaasahang istraktura: naroroon ba ang mga patlang, tama ba ang kanilang mga uri, napunan ba ang mga kinakailangang patlang?
  2. Pagpapatunay ng lohika ng panuntunan/negosyo. Ang mga halaga ba ay tumutugma sa mga patakaran ng negosyo? (Halaga > 0, ang petsa ay wala sa hinaharap, ang code ng produkto ay kabilang sa catalogue.)
  3. Kontrol ng sanggunian/pinagmulan. Kung ang modelo ay gumagawa ng isang assertion, maaari ba itong maiugnay sa pinagmulan? (Nasa dokumento ba talaga ang RAG quote?)
  4. Pagpapatunay gamit ang pangalawang modelo (LLM-bilang-hukom). Sinusuri ng isang independiyenteng modelo ang output bilang "tama/hindi kumpleto/mapanganib".
  5. Trust threshold at oryentasyon. Kung ang modelo o validator ay nag-ulat ng mababang kumpiyansa, ang output ay hindi awtomatikong pumasa; ay nakadirekta sa mga tao.
  6. Kontrol ng tao. Ang isang mataas na potensyal o mababang-ligtas na kinalabasan ay nakasalalay sa pag-apruba ng isang eksperto.

Apat na Nakokopyang Template

Scheme + "gumawa kung hindi mo alam" nang magkasama:

Ibalik ang tugon sa sumusunod na JSON schema LAMANG: Isulat ang "mababa". HUWAG sumulat ng isang pagtatantya na parang ito ay eksakto.

Pag-verify gamit ang pangalawang modelo (judge prompt):

Isa kang independent validator. Nasa ibaba ang isang <source> text at isang <claim>. Suriin upang makita kung ang BAWAT numero at petsa sa claim ay nangyayari sa verbatim sa pinagmulan. Para sa bawat isa, sabihing: "na-verify | wala sa source | contradicts source." Kung kahit isa sa mga ito ay 'absent/conflicting', markahan ang resulta bilang "HUMAN REVIEW KINAKAILANGAN".<source>{{ text }}</source><claim>{{ model_output }}</claim>

Panuntunan sa pagruruta ng threshold ng tiwala:

Panuntunan sa pagruruta:- emin_misin = "mataas" AT halaga < 10,000 TL -> awtomatikong pagpoproseso- emin_misin = "medium" O halagang 10,000-100,000 TL -> pangalawang pag-verify ng modelo- emin_misin = "mababa" O halaga > 100,000 TL -> kailangan ng pag-apruba ng tao

Card ng buod ng pag-audit ng tao (nagpapabilis ng pagsusuri):

Kapag iniharap ang desisyon sa isang tao, ipakita ang card na ito:- Ano ang iminumungkahi? (isang pangungusap)- Saang pinagmulan ito batay? (sanggunian sa artikulo/dokumento)- Ano ang 2 pinakamahinang pagpapalagay?- Kung naaprubahan, maaari bang baligtarin ang mga ito? (oo/hindi)

Mahina Prompt / Malakas na Prompt

mahinang diskarte

Malakas na diskarte

"Magbawas ng halaga sa invoice" (libreng text)

Mahigpit na JSON schema + null + trust field

Pagsusulat ng output nang direkta sa sistema ng pagbabayad

Schema → panuntunan → pag-apruba ng tao (kung kinakailangan)

Sinasabi lang sa modelo na "siguraduhin mo"

Pagpapatunay ng numero/petsa kasama ang pangalawang modelo

Pinoproseso ang bawat output nang may pantay na kumpiyansa

Pagruruta batay sa impluwensya at tiwala

Ang malakas na diskarte ay hindi umaasa na ang modelo ay tama; Lumilikha ito ng pinto na sasaluhin ka kapag mali ka.

Tatlong Mini Case

Kaso 1 — Ang pamamaraan lamang ay hindi sapat. Kinukuha ng automation ng accounting ang halaga mula sa mga invoice bilang JSON. Ang scheme ay tama, ngunit ang modelo ay gumawa ng "125,000" sa halip na "1,250.00" sa isang invoice (decimal shift). Nabigo ang scheme na makuha ito; ang pag-verify ng panuntunan ("ang halaga ay dapat na naaayon sa kabuuan ng mga item ng invoice nang ±1%)") ay nahuli at napigilan ang maling pag-record ng 112,500 TL.

Case 2 — Nakuha ng pangalawang modelo ang hallucination. "30 araw na paunawa ng pagwawakas," sabi ng isang katulong sa suportang legal sa buod ng kontrata; Gayunpaman, sa kontrata ito ay 90 araw. Nang i-flag ng independiyenteng hukom ang modelo bilang "sumasalungat sa pinagmulan", ang output ay ipinasa sa tao at naitama. Kung awtomatiko ito, aabisuhan ng customer ang pagkansela batay sa maling petsa.

Kaso 3 — Binawasan ng pagruruta ang load ng 70%. Awtomatikong inaprubahan ng isang system ng insurance claims ang mababang halaga at mataas na seguridad na mga claim at ipinadala lamang ang nasa itaas ng threshold/mababa ang secure na mga claim sa eksperto. Sa 3,200 araw-araw na pangangailangan, 950 lamang ang nahulog sa mga tao; Inilaan ng mga eksperto ang kanilang oras sa tunay na peligrosong 30%, na may average na oras ng transaksyon na bumababa mula 4 na oras hanggang 40 minuto.

Tip: Huwag mag-set up ng kontrol ng tao para "makita ng mga tao ang lahat" — mapapagod nito ang mga tao at magiging rubber stamp ang pag-apruba. Sa halip, ruta lamang ang mataas na epekto at mababang kumpiyansa na mga output sa tao; Nakatuon ito ng pansin sa kung ano talaga ang mahalaga.

Gawing Makahulugan ang Kontrol ng Tao

Ang Human-in-the-loop ay hindi tungkol sa paglalagay ng checkbox sa papel. Ang tagasuri ay dapat magkaroon ng (1) konteksto upang maunawaan ang desisyon, (2) access sa pinagmulan, at (3) awtoridad na magsabi ng “hindi.” Kung hindi, ang kontrol ay nananatiling kosmetiko. Ang review card (ikaapat na template sa itaas) ay nilalayong magbigay ng kontekstong iyon lamang.

Mga karaniwang pagkakamali

  • Ginagawa lang ang pagpapatunay ng schema at paglaktaw ng mga error sa nilalaman/halaga.
  • Iniisip na sa pamamagitan ng pagsasabi sa modelo na "siguraduhin" na ginagawa mo ang tunay na pag-verify.
  • Awtomatikong ipatupad ang mga desisyong may mataas na epekto at hindi maibabalik.
  • Paglalagay ng kontrol ng tao sa bawat output at ginagawang walang kabuluhan ang pag-apruba.
  • Pagsasabi ng "apruba" sa reviewer nang hindi ibinibigay ang pinagmulan at konteksto.
  • Pinoproseso ang lahat ng mga output na may parehong panganib nang hindi nagtatatag ng trust threshold at pagruruta.

Sa buod

  • Ang output ay nasira sa tatlong paraan: anyo, nilalaman, at malisyosong layunin; isang solidong sistema ang huminto sa tatlo sa pintuan.
  • Mga layer: pagpapatunay ng schema, lohika ng panuntunan/negosyo, kontrol sa pinagmulan, pangalawang modelo (LLM-bilang-hukom), at pagruruta ng threshold ng tiwala.
  • Dapat na mandatory ang Human-in-the-loop para sa mga output na may mataas na epekto at mababang kaligtasan.
  • Ang pagsusuri ng tao ay dapat na makabuluhan: ang tagasuri ay dapat magkaroon ng konteksto, pag-access sa mapagkukunan, at awtoridad na magsabi ng "hindi."
  • Parehong kaligtasan at kahusayan ay nakukuha sa pamamagitan ng pagdidirekta lamang sa mga peligroso sa mga tao, hindi sa bawat output.

Gawain ng aplikasyon

Kumuha ng isang halimbawa mula sa iyong sariling output ng AI. Una, tukuyin ang isang JSON schema at pilitin ang output dito. Pagkatapos ay sumulat ng hindi bababa sa dalawang panuntunan sa negosyo (halimbawa, "halagang tumutugma sa kabuuan ng mga item"). Panghuli, mag-set up ng routing table: aling kumbinasyon ng tiwala/impluwensya ang awtomatikong napupunta, na napupunta sa pangalawang modelo, na napupunta sa tao? Bumuo ng isang may sira na sample at obserbahan kung saan ito kinukuha ng bawat layer.

checklist

  • [ ] Tinukoy ko ang isang mahigpit na schema para sa output at i-verify ito sa makina.
  • [ ] Nagdagdag ako ng kahit isang business/rules validation (value logic).
  • [ ] Maaari kong iugnay ang mga pahayag sa pinagmulan at suriin ang mga ito.
  • [ ] Ang pangalawang modelo o pagpapatunay ng tao ay magagamit para sa mataas na epekto/mababang mga resulta ng kaligtasan.
  • [ ] Tinukoy ang panuntunan sa pagruruta batay sa tiwala at impluwensya.
  • [ ] Ang tagasuri ay binibigyan ng konteksto, pinagmulan, at awtoridad na tanggihan.