Proizvodnja od konca do konca: preverjanje, spremljanje in etika — API, stroški in integracija

Dobički:

Lahko oblikuje arhitekturo od konca do konca, ki funkcijo LLM popelje od ideje do proizvodnje
Vzpostavi plasti uveljavljanja preverjanja, človeške odobritve in sledenja (beleženje/metrike)
Meje prevajajo načela etike in zasebnosti v proizvodne odločitve

V prejšnjih desetih enotah smo se učili enega za drugim: struktura zahteve, ekonomika žetona, tok, sistemski poziv, izbira modela, predpomnilnik, paket, upravljanje napak, varni ključ in avtomatizacija. V tej zadnji enoti združimo dele in vzpostavimo celostno arhitekturo, ki prenaša LLM funkcijo od ideje do proizvodnje. Proizvodnja se razlikuje od »delujoče predstavitve«: preverjanje je obvezno, rezultate je treba spremljati, meje in etična načela morajo biti vgrajena v odločitve. Ta enota je nosilni stolpec modula; Tukaj se združijo vsi prejšnji.

Plasti proizvodne arhitekture

Trdna kvalifikacija LLM je sestavljena iz približno petih ravni:

Vhodna plast: Zberite podatke, očistite jih, maskirajte občutljiva področja, posredujte samo tisto, kar je nujno.
Sloj modela: izberite pravi model (enota 5), nastavite sistemski poziv in parametre (enota 4), predpomnilnik (enota 6).
Plast preverjanja: preverite izhod glede na shemo/pravilo, vir in po potrebi človeško odobritev.
Sloj dejanj: Izvedite dejanje s potrjenim izhodom; Zajemite dejanja z velikim vplivom.
Plast spremljanja: Zabeležite in izmerite vsak klic, stroške, napake in kakovost.

Ti sloji so cevovod; vsak preveri rezultat prejšnjega.

Zakaj je potrebno preverjanje?

LLM-ji lahko proizvedejo tekoče, a včasih netočne rezultate. To se imenuje halucinacija: model si lahko izmisli informacije, ki se zdijo resnične, vendar niso. V klepetalnici je to dopustno; v proizvodnem sistemu (račun, zdravje, pravo, finance) ni mogoče tolerirati. Tako se je izkazalo, slepo nezanesljivo; je potrjeno.

Verifikacijski sloji (naraščajo z vplivom):

Preverjanje formata/sheme: Ali je rezultat v skladu s pričakovano shemo JSON? (Strukturiran izhod to v veliki meri zagotavlja.)
Preverjanje pravila/logike: Ali so vrednosti razumne? (Ali je znesek negativen, ali je datum v prihodnosti, ali je kategorija veljavna?)
Preverjanje vira: ali trditev temelji na predloženi dokumentaciji? Ali model pove nekaj, česar ni v dokumentu?
Človeška odobritev: Strokovnjak pregleda zelo vplivne ali dvoumne odločitve.

Pozor: »Model je tako dober, da nadaljnje preverjanje ni potrebno« je najnevarnejša proizvodna napaka. Ne glede na to, kako dober je model, je sloj preverjanja varnostna mreža pri odločitvah z velikim vplivom. Že ena napačna avtomatska odločitev lahko odvzame ves prihranjeni čas.

Človek v zanki

Vsaka odločitev ni nujno popolnoma samodejna. Pri pristopu človek v zanki model pospeši delo in človek to odobri. Pravo ravnotežje je odvisno od vpliva odločitve in zanesljivosti modela na to nalogo.

Vpliv odločitve

Pristop

Nizka (predlog oznake, osnutek)

Popolna avtomatizacija; napaka je poceni in reverzibilna

Srednje (usmerjanje, prioriteta)

Avtomatizacija + kontrola vzorčenja

Visoko (denar, pogodba, zdravje, brisanje)

Privolitev človeka je obvezna; model samo nakazuje

Spremljanje: ne morete upravljati s tem, česar ne vidite

V proizvodnji morate spremljati vsak klic. Brez spremljanja ne morete izboljšati stroškov, kakovosti ali zgodaj odkriti težave. Ključne meritve za beleženje:

Uporaba/strošek: na zahtevo in skupni žetoni, porazdelitev modela, dnevna poraba.
Zakasnitev: povprečni in najslabši odzivni čas.
Stopnja napak: stopnje 429/500, ponovni poskusi, opustitve.
Kakovost: Stopnja zavrnjenega izpisa na ravni preverjanja, stopnja popravka po odobritvi človeka, povratne informacije uporabnikov.

Namig: Ne zapisujte občutljivih podatkov (osebnih podatkov, ključev) v dnevnike spremljanja. Upoštevajte dnevnike v okviru zaupnosti; snemanje z maskiranjem, če je potrebno (enota 9).

Etika in meje

Etična odgovornost je prav tako del proizvodne odločitve kot tehnična natančnost:

Preglednost: uporabnik mora vedeti, ali se pogovarja z umetno inteligenco ali človekom.
Poštenost in pristranskost: model lahko nosi pristranskost iz podatkov, na podlagi katerih je učen; Spremljajte diskriminatorne posledice pri odločitvah z velikim vplivom (zaposlovanje, kredit).
Odgovornost: Če avtomatizirana odločitev povzroči škodo, ste odgovorni vi; "Manekenka je tako rekla" ni obramba.
Sprejemanje omejitev: model nekaterih nalog ne more opravljati zanesljivo; njihova neavtomatizacija je prav tako oblikovalska odločitev.

Predloge, ki jih je mogoče kopirati

# Kontrolni seznam za preverjanje veljavnosti (po ustvarjanju izhodnih podatkov) 1) Ali je shema veljavna? (strukturirano preverjanje izhoda) 2) Ali so vrednosti smiselne? (preverjanje pravil: obseg, datum, enum)3) Ali trditev temelji na viru? (zavrnite, če ni v dokumentu) 4) Ali je vpliv velik? → pošlji v človeško odobritev5) Če je vse uspešno → dovoli dejanje, shrani

# Sistemski poziv, ki prisili k zanašanju na izvor. Zanašajte se samo na informacije v predloženem dokumentu. Ne dodajajte ničesar, kar ni v dokumentu. Če informacije ni v dokumentu, napišite "Ni najdena v dokumentu". Nikoli ne ugibajte in ne izmišljujte stvari.

# Prag človeške odobritve (pravilo odločitve) ČE tip_odločitve v [denar, pogodba, brisanje, zdravje] → obvezna človeška odobritev IF model_trust < prag ALI potrditev "negotovo" → predloži odobritvi človeka DRUGO → samodejna uporaba + nadzor vzorčenja

# Predloga dnevnika sledenja (zapisovanje občutljivih podatkov){ "time":"...", "model":"...", "input_token":..., "output_token":..., "delay_ms":..., "stop_reason":"...", "authentication":"passed|rejected|human", "cost_usd":... } // osebni podatki in ključ niso NIKOLI zapisani

Šibek poziv/močan poziv (zanesljivost proizvodnje)

# ŠIBKO (brez preverjanja, brez vira, velja samodejno) Ocenite to zahtevo, se odločite za vračilo in se prijavite.

# MOČNO (na podlagi vira, ustvari priporočilo, prepusti odobritvi ljudi) Ocenite to zahtevo za vračilo samo na podlagi dokumenta o politiki vračila. Priporočite odločitev z utemeljitvijo, vendar je ne izvajajte: {"recommendation":"approve|reject","reason":"...","policy_clause":"..."}. Če v dokumentu o politiki ni jasne podlage, navedite "nejasno". Predstavnik bo potrdil končno odločitev.

Zmogljiva različica; Odločitev pripiše viru, model postavi kot »predlagatelja« in ne kot »izvajalca«, korak z velikim učinkom pa postavi za človeško odobritev. To je bistvo zanesljivosti proizvodnje.

Trije mini kovčki

1. primer – dan, ko je bila shranjena verifikacijska plast. Fintech je zahteval, da model razvrsti opise transakcij in ustvari avtomatske računovodske evidence. Dodali so preverjanje pravil: ko je model izpisal nepravilen znesek (12.500 namesto 1.250 v dokumentu), je pravilo "znesek ne ustreza dokumentu" zavrnilo izhod in zapis je padel na človeka. Če preverjanja ni bilo, bi napačen zapis tiho vstopil v sistem.

Primer 2 – Ubežnik, ujet zaradi nadzora. Ekipa SaaS je vzpostavila nadzorno ploščo; Nekega jutra so se dnevni stroški potrojili. Iz dnevnikov je bilo razvidno, da je stranka vstopila v zanko in tisočkrat poslala isto zahtevo. Dodali so kvoto in deduplikacijo; Težava je bila odpravljena v nekaj urah. Brez sledenja bi bil račun ob koncu meseca presenečenje.

Primer 3 — Sprejemanje omejitve. Zagon zdravstvenega varstva je načrtoval, da bo priporočilo za diagnozo pripravil popolnoma samodejno in ga prikazal pacientu. Pri pregledu etike in odgovornosti so se odločili, da je to prepovedano: model zdravniku ponudi le povzetek in možne točke, zdravnik pa postavi diagnozo. Tudi neavtomatizacija dela je zrela oblikovalska odločitev.

Pogoste napake

Preskok preverjanja: slepo uporabo izhoda, češ da je "model dober".
Avtomatizacija zelo vplivnih odločitev: človeška odobritev je bistvena pri denarju/zdravju/pravu.
Brez spremljanja: težave s stroški in kakovostjo so odkrite pozno.
Pisanje občutljivih podatkov v dnevnike: kršitev zasebnosti; Shranite ga tako, da ga zakrijete.
Ne poskušajte se zanašati na vir: model lahko ustvari tisto, česar ni v dokumentu.
Ignoriranje omejitev: neavtomatizacija nekaterih opravil je prava odločitev; Transparentnost in odgovornost sta vaši.

Deeper: upravljanje izdaj, povrnitev nazaj in postopno uvajanje

Uvedba funkcije LLM v proizvodnjo ne pomeni, da jo nastavite in pozabite nanjo; je varno spreminjanje živega sistema skozi čas. Ima tri stebre.

Versioning. Vaš sistemski poziv, izbira modela in pravila preverjanja se sčasoma spreminjajo. Različite vsako pomembno spremembo in zabeležite, katera različica je v živo. Če nekega dne kakovost pade, "kaj smo spremenili?" Na vprašanje bi morali biti sposobni odgovoriti v nekaj minutah. V sistemu brez različic iskanje temeljnega vzroka za nazadovanje traja nekaj dni.

Povratek nazaj. Če se novi poziv ali model v živo obnaša slabše od pričakovanega, bi morali imeti možnost, da se hitro vrnete na prejšnjo, dobro znano različico. Sprememba brez načrta za povrnitev je slepo sprejemanje tveganja v živo. "Nekaj sem spremenil, postalo je slabo, ne morem nazaj" je najdražji produkcijski scenarij.

Postopno uvajanje. Namesto da bi spremembo uporabili za ves promet hkrati, jo najprej uvedete na majhen odstotek (npr. 5 %) in spremljate meritve (kakovost, stroški, napake). Če je dobro, povečaš odstotek; Če je slab, ga boste dobili nazaj, pri čemer bo prizadet le majhen del. To močno omeji tveganje.

Te tri prakse združujejo tehnike iz vseh prejšnjih enot: eval (enota 5) meri spremembe vnaprej, spremljanje (ta enota) daje zgodnje opozorilo med širjenjem, plast preverjanja ujame napačne izhode, preden začnejo ukrepati. Proizvodnja ni ena sama pravilna postavitev; Je stalna disciplina, ki meri, spremlja in lahko z zaupanjem spreminja. Celoten modul je namenjen vam, da vzpostavite to disciplino.

Če povzamem

Produkcija je več kot delujoča predstavitev: je niz vhodnih, modelnih, verifikacijskih, akcijskih in nadzornih slojev. Izhod je nezanesljiv brez preverjanja; odločitve z velikim vplivom so povezane s človeško odobritvijo; Vsak klic se spremlja glede stroškov, napak in kakovosti. Etika, preglednost, nadzor pristranskosti, odgovornost in sprejemanje omejitev so sestavni del tehničnih odločitev. Vsak kos, ki se ga naučite v tem modulu, je združen v to celostno zasnovo.

Aplikacijska naloga

Oblikujte funkcijo LLM od konca do konca. (1) Izpolnite pet plasti (vnos, model, preverjanje, dejanje, spremljanje) za vašo specifično nalogo. (2) Z vplivom označite, katere odločitve bodo zahtevale človeško odobritev. (3) Napišite vsaj tri potrditvena preverjanja (shema, pravilo, vir). (4) Določite ključne meritve, ki jim boste sledili, in česa ne boste beležili. (5) Napišite omejitev in etično načelo, ki ga sprejemate v tej funkciji.

kontrolni seznam

[ ] Znam oblikovati pet plasti proizvodnega cevovoda.
[ ] Izhod lahko preverim glede na shemo, pravilo in vir.
[ ] Na podlagi vpliva odločitve lahko nastavim prag odobritve.
[ ] Spremljam stroške, napake in kakovost ter ne zapisujem občutljivih podatkov v dnevnike.
[ ] Etiko, odgovornost in meje lahko spremenim v proizvodne odločitve.

Modulni izpit

1. Kaj počne vloga 'sistema' v API-ju za klepet LLM?

A) Modelu daje stalna navodila in pravila obnašanja, ki veljajo skozi celoten pogovor ✔
B) Ohrani zadnje vprašanje, ki ga je napisal uporabnik
C) Shrani odziv, ki ga ustvari model
D) Šifrira ključ API

Opis: sistemska vloga daje modelu vztrajna navodila, osebnost in pravila, ki veljajo skozi celoten pogovor; Gre za preusmeritev na visoki ravni, ločeno od uporabniških sporočil.

2. Zakaj se zgodovina pogovorov (prejšnja sporočila) vsakič znova pošlje v zahtevi API?

A) Potrebno je narediti varnostno kopijo, saj strežnik izbriše zgodovino
B) klici API so brez stanja; ✔ Kontekst se ponovno pošlje ob vsaki zahtevi, ker si model ne zapomni zgodovine
C) Potreben le za izdajanje računov, nima vpliva na model
D) Pošiljanje zgodovine je obvezno, da preprečite upočasnitev odziva

Pojasnilo: klici LLM API so brez stanja; Model si ne zapomni prejšnjih krogov, zato se vsa ustrezna zgodovina znova pošlje ob vsaki zahtevi, da se ohrani kontekst.

3. Kaj je 'žeton' pri določanju cen LLM?

A) Enkratno geslo za prijavo v API
B) Fiksna pristojbina, plačana za vsako zahtevo
C) Najmanjša enota, v kateri model obdeluje besedilo; običajno ustreza besednemu delu ✔
D) Enota, ki meri samo dolžino izhoda

Opis: Žeton je najmanjša enota, v kateri model obdeluje besedilo; Običajno ustreza delčku besede, tako vnos kot izhod pa se zaračunava glede na število žetonov.

4. Zakaj so izhodni žetoni pri večini ponudnikov LLM dražji od vhodnih?

A) Izhodni žetoni so vedno daljši od vhodnih
B) Vhodni žetoni so brezplačni
C) Izhodni žetoni se dvakrat pošljejo po internetu
D) Stroški na enoto so višji, ker ustvarjanje rezultatov zahteva dodatne izračune za vsak žeton ✔

Opis: vsak od izhodnih žetonov zahteva, da model izvaja generiranje po korakih (izračun); Ta proizvodni strošek je višji kot obdelava vložka naenkrat, zato je izhodna cena na enoto običajno višja.

5. V kakšni situaciji je uporaba pretakanja najbolj koristna?

A) V dolgih odgovorih; Zmanjša zaznano zakasnitev in prepreči časovno omejitev ✔
B) Samo v zelo kratkih, enobesednih odgovorih
C) Zmanjšati stroške na nič
D) Če želite skriti ključ API

Opis: pri dolgih odzivih pretakanje zmanjša zaznano zakasnitev tako, da se prve besede prikažejo takoj, in prepreči časovne omejitve HTTP pri velikih vrednostih max_tokens.

6. Na kaj na splošno vpliva povečanje parametra 'napora' pri sodobnih modelih?

A) Odgovor vedno skrajšaj
B) Samodejno zavrti ključ API
C) Zniža le ceno vhodnega žetona
D) Poveča globino razmišljanja in simbolično porabo; Morda izboljša kakovost, vendar tudi poveča zakasnitev in stroške ✔

Opis: parameter napora prilagaja, kako globoko bo model razmišljal o nalogi in koliko žetonov bo porabil; Nadgradnja lahko izboljša kakovost, vendar tudi poveča zakasnitev in stroške. Za preprosta opravila zadostuje majhen napor.

7. Kateri je na splošno stroškovno najučinkovitejši pristop k enostavni, obsežni nalogi klasifikacije?

A) Vedno uporabljajte najdražji in najmočnejši model
B) Klicanje vseh modelov hkrati za vsako zahtevo
C) Izbira najlažjega/najcenejšega modela, ki opravi nalogo, tako da ga preverite z majhno oceno ✔
D) ohranjanje vrednosti max_tokens po nepotrebnem previsoke

Pojasnilo: Če naloga ni zapletena, bo izbira hitrejšega in cenejšega modela, ki z lahkoto opravi nalogo (npr. Haiku razred), namesto uporabe najdražjega in zmogljivega modela znatno znižala stroške.

8. V katerem scenariju hitro predpomnjenje najbolj zmanjša stroške?

A) Ko se velik in fiksen kontekst večkrat uporablja v številnih zahtevah ✔
B) Ko je ob vsaki zahtevi poslano popolnoma drugačno besedilo
C) Ko je vložena samo ena zahteva
D) Za zmanjšanje izhodnih žetonov

Opis: predpomnjenje je ujemanje predpone; V primerih, ko se velik, nespremenljiv kontekst (sistemski poziv, dokumenti) ponovno uporabi v številnih zahtevah, je branje iz predpomnilnika majhen del (~0,1x) polne cene.

9. Kako naj uredim poziv, da bo predpomnilnik pozivov zadel?

A) Postavljanje spremenljive vsebine na začetek in fiksne vsebine na konec
B) Vdelajte trenutni datum in uro v sistemski poziv za vsako zahtevo
C) Postavitev fiksne vsebine (sistemski poziv, dokumenti) na začetek in spremenljive vsebine na konec ✔
D) Spreminjanje vrstnega reda seznama orodij z vsako zahtevo

Pojasnilo: Ker je predpomnilnik ujemanje predpone, se inicializira fiksna/nespremenljiva vsebina (sistemski poziv, dokumenti); spremenljiva vsebina (datum, vprašanje uporabnika, ID zahteve) je postavljena na koncu. Celo en bajt, spremenjen na začetku, razveljavi predpomnilnik.

10. Za kakšno vrsto delovne obremenitve je paketna obdelava najprimernejša?

A) Klepet v živo, kjer uporabnik pričakuje takojšen odgovor na zaslonu
B) Samo eno kratko vprašanje
C) Ustvarjanje ključa API
D) Dela, ki so tolerantna na zamude, imajo velik obseg in ne zahtevajo takojšnjih rezultatov ✔

Opis: Paketna obdelava je primerna za velike količine opravil, ki ne zahtevajo takojšnjega odziva in so tolerantna do zamud; rezultati so dostavljeni čez nekaj časa, vendar je cena na enoto običajno nižja.

11. Kaj se uporablja za zanesljivo ujemanje, kateri zahtevi pripadajo rezultati v paketu?

A) Vrstni red (pozicija) pošiljanja zahtev
B) Dolžina odgovorov
C) Zadnje 4 številke ključa API
D) Enolični custom_id, dodeljen vsaki zahtevi ✔

Opomba: Množični rezultati so lahko vrnjeni v drugačnem vrstnem redu kot vrstni red oddaje; zato je treba rezultate ujemati po ID-ju, ne po lokaciji, z edinstvenim custom_id, ki se dodeli vsaki zahtevi.

12. Kakšno je priporočeno vedenje, ko od API-ja prejmete napako 429 (omejitev hitrosti)?

A) Vsiljevanje s pošiljanjem več zahtevkov hkrati
B) Ponovni poskus z eksponentnim odmikom, ki sledi naslovu ✔ Ponovni poskus
C) V celoti prekličite zahtevo in uporabniku prikažite napako kot zrušitev
D) Spreminjanje ključa API

Pojasnilo: 429 je napaka, ki jo je mogoče znova poskusiti; Pravilen pristop je, da poskusite znova z eksponentnim odmikom, pri čemer upoštevate glavo ponovnega poskusa. Večina uradnih SDK-jev to naredi samodejno.

13. Katere od naslednjih kod napak HTTP na splošno veljajo za ponovne poskuse?

A) 400 (neveljavna zahteva)
B) 401 (napaka pri preverjanju pristnosti)
C) 529 (strežnik preobremenjen) ✔
D) 404 (ni najden)

Pojasnilo: 429 (omejitev hitrosti), 500 (napaka strežnika) in 529 (preobremenitev) so začasne napake in jih je mogoče znova poskusiti z umikom. Napake, kot sta 400 in 401, so težave z zahtevo/identiteto; Ponovni poskus ne bo rešil.

14. Kaj od naslednjega je varen način za upravljanje ključev API?

A) Shranjevanje v spremenljivki okolja/skritem upravitelju, brez vdelave v kodo in redno menjavanje ✔
B) Zapišite ključ neposredno v izvorno kodo in ga pošljite v repozitorij
C) Namestitev ključa v JavaScript na strani odjemalca (brskalnik).
D) Skupna raba enega ključa s celotno ekipo po e-pošti

Opis: ključi se nikoli ne zapišejo v izvorno kodo ali repozitorij; Shranjen je v spremenljivki okolja ali skritem orodju za upravljanje, dodeljen z minimalnimi privilegiji in se redno izmenjuje.

15. Kateri je najboljši pristop k integraciji LLM z orodjem za avtomatizacijo (n8n, Zapier, Make) z vidika zasebnosti?

A) Pošiljanje vseh neobdelanih podatkov v model, tudi če to ni potrebno
B) Pisanje ključa API v navadnem besedilu znotraj koraka toka
C) Minimiziranje in maskiranje občutljivih podatkov ter shranjevanje ključa kot skrivnih poverilnic ✔
D) Trajno shranjevanje osebnih podatkov v zgodovini pretoka

Opis: Ker avtomatizacija vnosa podatkov poteka skozi sisteme in model tretjih oseb, je treba občutljive/osebne podatke minimizirati, maskirati in poslati samo obvezna polja; Ključ API je tudi shranjen kot skrivne poverilnice znotraj orodja.

16. Zakaj je preverjanje izhoda obvezno v produkcijski funkciji, ki temelji na LLM?

A) Potrebno je samo oblikovanje, ker model nikoli ne dela napak
B) Ker lahko model proizvaja tekoče, vendar včasih nepravilno; Shemo/pravilo je treba pregledati z odobritvijo virov in ljudi ✔
C) Validaciji se je treba izogibati, ker le poveča stroške
D) Preverjanje je samo za zmanjšanje števila žetonov

Opis: LLM lahko proizvedejo tekoče, a včasih netočne (halucinatorne) rezultate; tako se je izkazalo pri odločitvah z velikim vplivom; Revidirati ga je treba s preverjanjem sheme/pravil, potrjevanjem vira in po potrebi s človeško odobritvijo.