Lõpp-lõpuni tootmine: kontrollimine, jälgimine ja eetika

Kasu:

• Oskab kujundada terviklikku arhitektuuri, mis võtab LLM-i funktsiooni ideest tootmiseni
• Loob kinnituse jõustamise, inimeste heakskiidu ja jälgimise (logimine/mõõdikud) tasandid
• Piirid muudavad eetika ja privaatsuspõhimõtted tootmisotsusteks

Eelmises kümnes üksuses õppisime osi ükshaaval: päringu struktuur, märgi ökonoomika, voog, süsteemiviip, mudeli valik, vahemälu, partii, veahaldus, turvaline võti ja automatiseerimine. Selles viimases üksuses ühendame osad ja loome tervikliku arhitektuuri, mis kannab LLM-i funktsiooni ideest tootmiseni. Tootmine erineb “töötavast demost”: kontrollimine on kohustuslik, väljundit tuleb jälgida, piirid ja eetilised põhimõtted peavad olema otsustesse põimitud. See seade on mooduli kandeveerg; Kõik eelnevad tulevad siia kokku.

Tootmisarhitektuuri kihid

Kindel LLM-i kvalifikatsioon koosneb ligikaudu viiest kihist:

1. Sisendkiht: koguge andmeid, puhastage need, maskeerige tundlikud alad, edastage ainult vajalik.
2. Mudelikiht: valige õige mudel (üksus 5), määrake süsteemiviip ja parameetrid (üksus 4), vahemälu (üksus 6).
3. Valideerimiskiht: vajadusel kontrollige väljundit skeemi/reegli, allika ja inimese heakskiiduga.
4. Tegevuskiht: sooritage toiming kinnitatud väljundiga; Jäädvustage suure mõjuga toiminguid.
5. Järelevalvekiht: salvestage ja mõõtke iga kõne, maksumust, viga ja kvaliteeti.

Need kihid on torujuhe; igaüks kontrollib eelmise väljundit.

Miks on kinnitamine nõutav?

LLM-id võivad anda sujuvat, kuid mõnikord ebatäpset väljundit. Seda nimetatakse hallutsinatsiooniks: mudel võib koostada teavet, mis näib olevat tõsi, kuid mitte. Jutumängus on see talutav; ei saa taluda tootmissüsteemis (arve, tervishoid, juriidiline, finants). Nii selgus, pimesi ebausaldusväärne; on kinnitatud.

Kinnituskihid (suurenevad mõju tõttu):

• Vormingu/skeemi valideerimine: kas väljund vastab eeldatavale JSON-skeemile? (Struktureeritud väljund tagab selle suures osas.)
• Reegli/loogika kontrollimine: kas väärtused on mõistlikud? (Kas summa on negatiivne, kas kuupäev on tulevikus, kas kategooria kehtib?)
• Allika kinnitus: kas nõue põhineb esitatud dokumentidel? Kas mudel ütleb midagi, mida dokumendis pole?
• Inimese heakskiit: ekspert vaatab läbi suure mõjuga või mitmetähenduslikud otsused.

Ettevaatust: "Mudel on nii hea, et täiendavat kontrolli pole vaja" on kõige ohtlikum tootmisviga. Olenemata sellest, kui hea mudel on, on kontrollikiht suure mõjuga otsuste tegemisel turvavõrk. Isegi üks vale automaatne otsus võib ära võtta kogu säästetud aja.

Inimene silmuses

Iga otsus ei pea olema täisautomaatne. Inimene silmuses lähenemise puhul kiirendab modell tööd ja inimene kiidab selle heaks. Õige tasakaal sõltub otsuse mõjust ja mudeli usaldusväärsusest sellele ülesandele.

Otsuse mõju

Lähenemine

Madal (sildi soovitus, mustand)

Täielik automatiseerimine; viga on odav ja pöörduv

Keskmine (marsruutimine, prioritiseerimine)

Automatiseerimine + proovivõtu juhtimine

Kõrge (raha, leping, tervis, kustutamine)

Inimese nõusolek on kohustuslik; mudel ainult soovitab

Järelevalve: te ei saa hallata seda, mida te ei näe

Tootmises peate jälgima iga kõnet. Ilma jälgimiseta ei saa te kulusid, kvaliteeti parandada ega probleemi varakult tabada. Peamised salvestatavad mõõdikud:

• Kasutus/kulu: päringu ja žetoonide kogusumma, mudelijaotus, päevakulu.
• Latentsus: keskmine ja halvimal juhul reageerimise aeg.
• Veamäär: 429/500 määrad, korduskatsed, loobumised.
• Kvaliteet: tagasilükatud väljundkiirus kontrollkihil, parandusmäär inimese heakskiidul, kasutaja tagasiside.

Näpunäide: ärge kirjutage jälgimislogidesse tundlikke andmeid (isiklik teave, võtmed). Kaaluge logisid konfidentsiaalsuse piires; salvestage vajadusel maskeerides (ühik 9).

Eetika ja piirid

Eetiline vastutus on samamoodi tootmisotsuse osa kui tehniline täpsus:

• Läbipaistvus: kasutaja peaks teadma, kas ta räägib tehisintellekti või inimesega.
• Õiglus ja kallutatus: mudelil võivad olla kallutatud andmed, mille põhjal seda koolitatakse; Jälgige diskrimineerivaid tagajärgi suure mõjuga otsuste puhul (värbamine, krediit).
• Vastutus: kui automatiseeritud otsus põhjustab kahju, vastutate teie; "Modell ütles nii" ei ole kaitse.
• Limiitide aktsepteerimine: Mudel ei suuda mõnda ülesannet usaldusväärselt täita; nende automatiseerimata jätmine on samuti disainiotsus.

Kopeeritavad mallid

# Valideerimise kontrollnimekiri (pärast väljundi genereerimist)1) Kas skeem on kehtiv? (struktureeritud väljundi valideerimine)2) Kas väärtustel on mõtet? (reeglikontroll: vahemik, kuupäev, loend)3) Kas väide põhineb allikal? (lükake tagasi, kui seda pole dokumendis märgitud)4) Kas mõju on suur? → saada inimese heakskiitmiseks5) Kui kõik on läbitud → luba toiming, salvesta

# Süsteemi viip, mis sunnib tuginema allikale. Toetuge ainult esitatud dokumendis olevale teabele. Ärge lisage midagi, mida dokumendis pole. Kui teavet dokumendis ei ole, kirjutage "Dokumendist ei leitud". Ärge kunagi arvake ega mõtle välja asju.

# Inimese heakskiidu lävi (otsustusreegel) IF otsuse_tüüp [raha, leping, kustutamine, tervis] → inimese heakskiit kohustuslik,IF model_trust < lävi VÕI valideerimine "ebakindel" → esita inimese heakskiidule OTHER → automaatne rakendamine + proovivõtu kontroll

# Jälgimislogi mall (kirjutab tundlikke andmeid){ "time":"...", "modell":"...", "input_token":..., "output_token":..., "delay_ms":..., "stop_reason":"...", "autentimine":"läbi lükatud|tagasi lükatud|inimene", "cost_usd" / NE on kirjutatud VER ja personaalne võti / võti:...

Nõrk viip / Tugev viip (tootmiskindlus)

# NÕRK (kinnitust pole, allikat pole, rakendub automaatselt) Hinnake seda taotlust, tehke tagasimakseotsus ja taotlege.

# TUGEV (allikapõhine, genereerib soovituse, jätab inimese heakskiidu) Hinda seda tagastustaotlust ainult tagastuspoliitika dokumendi põhjal. Soovitage otsust koos põhjendusega, kuid ärge rakendage: {"recommendation":"prove|reject","reason":"...","policy_clause":"..."}.Kui poliitikadokumendis puudub selge alus, märkige "unclear". Lõpliku otsuse kinnitab esindaja.

Võimas versioon; See omistab otsuse allikale, positsioneerib mudeli pigem "soovitajaks" kui "tegijaks" ja asetab suure mõjuga sammu inimeste heakskiidu taha. See on tootmise usaldusväärsuse olemus.

Kolm miniümbrist

Juhtum 1 – päev, mil kontrollkiht salvestas. Fintech lasi mudelil tehingukirjeldusi klassifitseerida ja automaatseid raamatupidamiskirjeid luua. Nad lisasid reegli valideerimise: kui mudel väljastas summa valesti (dokumendis oleva 1250 asemel 12 500), lükkas reegel "summa ei vasta dokumendile" väljundi ja rekord langes inimesele. Kui kinnitust ei tehtud, siseneks vale kirje vaikselt süsteemi.

Juhtum 2 – jälitustegevusega tabatud põgenik. SaaS-i meeskond oli loonud seirepaneeli; Ühel hommikul päevakulu kolmekordistus. Logidest oli näha, et klient sisenes tsüklisse ja saatis sama päringu tuhandeid kordi. Nad lisasid kvoodid ja dubleerimise; Probleem lahenes tundide jooksul. Ilma jälgimiseta oleks arve kuu lõpus üllatus.

Juhtum 3 – limiidiga nõustumine. Tervishoiuteenust pakkuv ettevõte kavatses teha diagnoosisoovituse täielikult automaatselt ja näidata seda patsiendile. Eetika ja vastutuse ülevaates otsustasid nad, et see on piirideta: mudel annab arstile ainult kokkuvõtte ja võimalikud punktid, arst paneb diagnoosi. Töö mitte automatiseerimine on samuti küps disainiotsus.

Levinud vead

• Valideerimise vahelejätmine: väljundi pimesi rakendamine, öeldes "mudel on hea".
• Suure mõjuga otsuste automatiseerimine: inimeste heakskiit on raha/tervise/õiguse vallas hädavajalik.
• Ei jälgita: kulu- ja kvaliteediprobleemid avastatakse hilja.
• Tundlike andmete logidesse kirjutamine: Privaatsuse rikkumine; Salvestage see maskeerides.
• Ei püüa allikale tugineda: mudel võib moodustada selle, mida dokumendis pole.
• Piirangute eiramine: mõne ülesande mitte automatiseerimine on õige otsus; Läbipaistvus ja vastutus on teie.

Sügavam: väljalaskehaldus, tagasivõtmine ja järkjärguline juurutamine

LLM-i funktsiooni tootmisse võtmine ei tähenda selle seadistamist ja selle unustamist; on reaalajas süsteemi aja jooksul ohutult muuta. Sellel on kolm sammast.

Versioonide koostamine. Teie süsteemiviip, mudeli valik ja kinnitusreeglid muutuvad aja jooksul. Versiooni iga oluline muudatus ja registreerige, milline versioon on aktiivne. Kui ühel päeval kvaliteet langeb, siis "mida me muutsime?" Peaksite vastama küsimusele mõne minuti jooksul. Versioonideta süsteemis võtab regressiooni algpõhjuse leidmine päevi.

Tagasipööramine. Kui uus viip või mudel käitub reaalajas oodatust halvemini, peaksite saama kiiresti naasta eelmisele tuntud versioonile. Muudatus ilma tagasipööramisplaanita on reaalse riski pimesi aktsepteerimine. "Ma muutsin midagi, läks halvasti, ma ei saa tagasi minna" on kõige kallim tootmise stsenaarium.

Järkjärguline levitamine. Selle asemel, et rakendada muudatust kogu liiklusele korraga, tutvustate seda esmalt väikesele protsendile (nt 5%) ja jälgite mõõdikuid (kvaliteet, maksumus, vead). Kui see on hea, suurendate protsenti; Kui see on halb, saate selle tagasi, mõjutades ainult väikest osa. See piirab riski oluliselt.

Need kolm praktikat ühendavad kõigi eelmiste üksuste tehnikaid: hindamine (üksus 5) mõõdab muutusi ette, jälgimine (see üksus) annab levimise ajal varajase hoiatuse, kontrollikiht püüab vigased väljundid kinni enne, kui need muutuvad rakendatavaks. Tootmine ei ole üks õige seadistus; See on pidev distsipliin, mis mõõdab, jälgib ja võib enesekindlalt muutuda. Kogu moodul on teie jaoks selle distsipliini kehtestamiseks.

Kokkuvõttes

Tootmine on midagi enamat kui töötav demo: see on sisend-, mudeli-, kontrolli-, tegevus- ja jälgimiskihtide konveier. Väljund on ilma kontrollimiseta ebausaldusväärne; suure mõjuga otsused on seotud inimeste heakskiiduga; Iga kõnet jälgitakse kulude, vigade ja kvaliteedi osas. Eetika, läbipaistvus, eelarvamuste kontroll, vastutus ja piirangutega nõustumine on tehniliste otsuste lahutamatud osad. Iga selles moodulis õpitud tükk on selle tervikliku kujundusega kokku pandud.

Rakenduse ülesanne

Kujundage LLM-i funktsioon otsast lõpuni. (1) Täitke oma konkreetse ülesande jaoks viis kihti (sisend, mudel, kontrollimine, tegevus, jälgimine). (2) Märgistage mõju järgi, millised otsused nõuavad inimese heakskiitu. (3) Kirjutage vähemalt kolm valideerimiskontrolli (skeem, reegel, allikas). (4) Määrake kindlaks peamised mõõdikud, mida jälgite ja mida te ei logi. (5) Kirjutage piir ja eetiline põhimõte, millega selle funktsiooni puhul nõustute.

kontrollnimekiri

• [ ] Oskan kujundada viis kihti tootmistorustikku.
• [ ] Saan kontrollida väljundit skeemi, reegli ja allika suhtes.
• [ ] Saan määrata inimese heakskiidu läve, lähtudes otsuse mõjust.
• [ ] Jälgin kulusid, vigu ja kvaliteeti ning harjutan mitte kirjutama logidesse tundlikke andmeid.
• [ ] Oskan muuta eetika, vastutuse ja piirid tootmisotsusteks.

Mooduli eksam

1. Mida teeb süsteemiroll LLM-i vestluse API-s?

• A) Annab mudelile püsivaid juhiseid ja käitumisreegleid, mis kehtivad kogu vestluse vältel ✔
• B) jätab alles kasutaja kirjutatud viimase küsimuse
• C) Salvestab mudeli loodud vastuse
• D) Krüpteerib API võtme

Kirjeldus. Süsteemi roll annab mudelile püsivad juhised, isikupära ja reeglid, mis kehtivad kogu vestluse vältel; See on kõrgetasemeline ümbersuunamine, mis on kasutajate sõnumitest eraldiseisev.

2. Miks saadetakse API päringus iga kord uuesti vestluste ajalugu (eelmised sõnumid)?

• A) On vaja varundada, kuna server kustutab ajaloo
• B) API-kutsed on olekuta; ✔ Iga päringu korral saadetakse kontekst uuesti, kuna mudel ei mäleta ajalugu
• C) Nõutav ainult arveldamiseks, mudelit ei mõjuta
• D) Ajaloo saatmine on kohustuslik, et vältida reageerimise aeglustumist

Selgitus: LLM API kutsed on olekuta; Mudel ei mäleta eelmisi ringe, seega saadetakse iga konteksti säilitamise taotluse korral kogu asjakohane ajalugu uuesti.

3. Mis on LLM-i hinnakujunduses "märk"?

• A) API-sse sisselogimiseks kasutatav ühekordne parool
• B) Iga taotluse eest makstav fikseeritud tasu
• C) Väikseim ühik, milles mudel teksti töötleb; vastab tavaliselt sõna osale ✔
• D) Ühik, mis mõõdab ainult väljundi pikkust

Kirjeldus: Token on väikseim ühik, milles mudel teksti töötleb; Tavaliselt vastab see sõna fragmendile ja nii sisend kui ka väljund võetakse tasu märkide arvu alusel.

4. Miks on enamiku LLM-i pakkujate väljundmärgid kallimad kui sisendmärgid?

• A) Väljundmärgid on alati sisendist pikemad
• B) Sisendmärgid on tasuta
• C) Väljundmärgid saadetakse kaks korda Interneti kaudu
• D) Ühiku maksumus on kõrgem, kuna väljundi genereerimine nõuab iga märgi jaoks täiendavaid arvutusi ✔

Kirjeldus: iga väljundmärk nõuab, et mudel teostaks samm-sammult genereerimise (arvutamise); See tootmiskulu on suurem kui sisendi korraga töötlemine, seega on toodanguühiku hind tavaliselt kõrgem.

5. Millises olukorras on voogesituse kasutamine kõige kasulikum?

• A) pikkades vastustes; Vähendab tajutavat viivitust ja hoiab ära ajalõpu ✔
• B) Ainult väga lühikeste, ühesõnaliste vastustega
• C) vähendada kulusid nullini
• D) API võtme peitmiseks

Kirjeldus: pikkade vastuste korral vähendab voogesitus tajutavat latentsust, pannes esimesed sõnad kohe ilmuma ja hoiab ära HTTP ajalõpu suurte max_tokens väärtuste korral.

6. Mida mõjutab parameetri „pingutuse” suurendamine tänapäevastes mudelites üldiselt?

• A) Lühendage alati vastust
• B) Pöörab automaatselt API-võtit
• C) See vähendab ainult sisendmärgi hinda
• D) Suurendab mõtlemissügavust ja märgikulutusi; See võib parandada kvaliteeti, kuid suurendab ka latentsust ja kulusid ✔

Kirjeldus: jõupingutuse parameeter reguleerib, kui sügavalt mudel ülesande üle mõtleb ja kui palju märke kulutab; Uuendamine võib parandada kvaliteeti, kuid suurendab ka latentsust ja kulusid. Lihtsate ülesannete jaoks piisab vähesest pingutusest.

7. Milline on üldiselt kõige kulutõhusam lähenemine lihtsale ja mahukale klassifitseerimisülesandele?

• A) Kasutage alati kõige kallimat ja võimsamat mudelit
• B) Kõigile mudelitele korraga helistamine iga päringu korral
• C) ülesande täitmiseks kõige kergema/odavama mudeli valimine, kontrollides seda väikese evaliga ✔
• D) max_tokens väärtuse tarbetult liiga kõrge hoidmine

Selgitus: Kui ülesanne pole keeruline, vähendab kulu oluliselt kiirema ja odavama mudeli valimine, mis ülesandega hõlpsalt toime tuleb (nt Haiku klass), selle asemel et kasutada kõige kallimat ja võimsamat mudelit.

8. Millise stsenaariumi korral vähendab kiire vahemällu salvestamine kulusid kõige rohkem?

• A) Kui suurt ja fikseeritud konteksti kasutatakse korduvalt paljudes taotlustes ✔
• B) Kui iga päringuga saadetakse täiesti erinev tekst
• C) Kui esitatakse ainult üks taotlus
• D) Väljundmärkide vähendamiseks

Kirjeldus: Vahemällu salvestamine on eesliite vaste; Juhtudel, kui suurt muutumatut konteksti (süsteemiviip, dokumendid) kasutatakse paljude päringute jaoks uuesti, moodustab vahemälust lugemine väikese osa (~0,1x) täishinnast.

9. Kuidas peaksin viipa muutma, et viipa vahemälu tabaks?

• A) Muutuva sisu panemine algusesse ja fikseeritud sisu lõppu
• B) Manustage iga päringu jaoks süsteemiviipale praegune kuupäev ja kellaaeg
• C) Fikseeritud sisu (süsteemiviip, dokumendid) algusesse ja muutuva sisu lõppu panemine ✔
• D) Tööriistade loendi järjekorra muutmine iga päringu korral

Selgitus: kuna vahemälu on eesliite vaste, lähtestatakse fikseeritud/muutumatu sisu (süsteemiviip, dokumendid); muutuv sisu (kuupäev, kasutaja küsimus, päringu ID) pannakse lõppu. Isegi üks alguses muudetud bait muudab vahemälu kehtetuks.

10. Millise töökoormuse jaoks sobib kõige paremini paketttöötlus?

• A) Reaalajas vestlus, kus kasutaja ootab ekraanil kohest vastust
• B) Ainult üks lühike küsimus
• C) API võtme genereerimine
• D) Tööd, mis on viivitust taluvad, mahukad ja ei nõua kohest tulemust ✔

Kirjeldus: Paketttöötlus sobib suurte tööde jaoks, mis ei vaja kohest reageerimist ja taluvad viivitusi; tulemused edastatakse mõne aja pärast, kuid ühiku maksumus on tavaliselt madalam.

11. Mida kasutatakse enesekindlaks vastavusse viimiseks, millisele päringule tulemused partiis kuuluvad?

• A) Päringute saatmise järjekord (positsioon).
• B) Vastuste pikkus
• C) API võtme 4 viimast numbrit
• D) Igale päringule antud kordumatu custom_id ✔

Märkus: hulgitulemused võidakse tagastada esitamisjärjekorrast erinevas järjekorras; seega on vaja tulemusi sobitada ID, mitte asukoha järgi, igale päringule antud kordumatu custom_id-ga.

12. Milline on soovituslik käitumine, kui saate API-lt veateate 429 (määrapiirang)?

• A) Sundimine, saates korraga palju rohkem taotlusi
• B) Proovige uuesti eksponentsiaalse tagasilöögiga, järgides pealkirja ✔ uuesti proovige pärast
• C) Tühistage taotlus täielikult ja näidake kasutajale viga kui krahhi
• D) API võtme muutmine

Selgitus: 429 on uuesti proovitav viga; Õige lähenemisviis on proovida uuesti eksponentsiaalse tagasilöögiga, järgides uuesti proovimise päist. Enamik ametlikke SDK-sid teeb seda automaatselt.

13. Milliseid järgmisi HTTP veakoode peetakse üldiselt uuesti proovitavateks?

• A) 400 (kehtetu taotlus)
• B) 401 (autentimisviga)
• C) 529 (server on ülekoormatud) ✔
• D) 404 (ei leitud)

Selgitus: 429 (kiiruspiirang), 500 (serveri tõrge) ja 529 (ülekoormus) on ajutised vead ja neid saab uuesti proovida tagasilülitamisega. Vead nagu 400 ja 401 on päringu/identiteedi probleemid; Uuesti proovimine ei lahenda seda.

14. Milline järgmistest on turvaline viis API-võtmete haldamiseks?

• A) Keskkonnamuutuja/peidetud halduri salvestamine, koodi mitte manustamine ja korrapärane pöörlemine ✔
• B) Kirjutage võti otse lähtekoodi ja saatke see hoidlasse
• C) Võtme panemine kliendipoolsesse (brauseri) JavaScripti
• D) Ühe võtme jagamine kogu meeskonnaga e-posti teel

Kirjeldus: võtmeid ei kirjutata kunagi lähtekoodi ega hoidlasse; See salvestatakse keskkonnamuutujas või peidetud haldustööriistas, millele antakse minimaalsed õigused ja mida pööratakse regulaarselt.

15. Milline on privaatsuse seisukohalt parim lähenemine LLM-i integreerimisele automatiseerimistööriistaga (n8n, Zapier, Make)?

• A) Kõigi algandmete saatmine mudelile, isegi kui see pole vajalik
• B) API võtme kirjutamine lihttekstina voosammu sees
• C) Tundlike andmete minimeerimine ja maskeerimine ning võtme salvestamine salajaste mandaatidena ✔
• D) Isikuandmete pidev hoidmine voo ajaloos

Kirjeldus: Kuna automatiseerimisse sisestatavad andmed läbivad kolmandate osapoolte süsteeme ja mudeleid, tuleb tundlikud/isikuandmed minimeerida, maskeerida ja saata ainult kohustuslikud väljad; API võti salvestatakse ka tööriistas salajaste mandaatidena.

16. Miks on LLM-põhise tootmisfunktsiooni puhul väljundi valideerimine kohustuslik?

• A) Vaja on ainult vormindamist, sest mudel ei tee kunagi vigu
• B) Kuna mudel võib toota sujuvalt, kuid mõnikord valesti; Skeemi/reeglit tuleb auditeerida ressursside ja inimeste heakskiidul ✔
• C) Valideerimist tuleks vältida, kuna see ainult suurendab kulusid
• D) Kontrollimine on mõeldud ainult žetoonide arvu vähendamiseks

Kirjeldus: LLM-id võivad anda sujuvat, kuid mõnikord ebatäpset (hallutsinatoorset) väljundit; nii et see tuli välja suure mõjuga otsustes; Seda tuleks vajadusel auditeerida skeemi/reeglite kontrollimise, allika valideerimise ja inimese heakskiiduga.