Proizvodnja od kraja do kraja: verifikacija, praćenje i etika

Dobici:

Može dizajnirati end-to-end arhitekturu koja preuzima LLM značajku od ideje do proizvodnje
Uspostavlja nivoe provođenja verifikacije, ljudskog odobrenja i praćenja (zapisivanje/metrika)
Granice prevode etiku i principe privatnosti u proizvodne odluke

U prethodnih deset cjelina naučili smo dijelove jedan po jedan: strukturu zahtjeva, ekonomiju tokena, tok, sistemski prompt, odabir modela, keš memoriju, skup, upravljanje greškama, siguran ključ i automatizaciju. U ovoj posljednjoj cjelini kombiniramo dijelove i uspostavljamo holističku arhitekturu koja nosi karakteristiku LLM-a od ideje do proizvodnje. Proizvodnja se razlikuje od „demonstracije rada“: verifikacija je obavezna, izlaz se mora pratiti, granice i etički principi moraju biti ugrađeni u odluke. Ova jedinica je noseći stupac modula; Ovdje se okupljaju svi prethodni.

Slojevi proizvodne arhitekture

Čvrsta LLM kvalifikacija sastoji se od otprilike pet slojeva:

Ulazni sloj: Prikupite podatke, očistite ih, maskirajte osjetljiva područja, prenesite samo ono što je potrebno.
Sloj modela: Odaberite ispravan model (jedinica 5), postavite sistemski prompt i parametre (jedinica 4), keš (jedinica 6).
Validacijski sloj: Provjerite izlaz u odnosu na shemu/pravilo, izvor i ljudsko odobrenje ako je potrebno.
Akcioni sloj: Izvedite radnju sa validiranim izlazom; Snimite radnje sa velikim uticajem.
Sloj za praćenje: Snimite i izmjerite svaki poziv, cijenu, grešku i kvalitet.

Ovi slojevi su cevovod; svaki provjerava izlaz prethodnog.

Zašto je potrebna verifikacija?

LLM mogu proizvesti tečan, ali ponekad netačan rezultat. To se zove halucinacija: model može izmisliti informacije koje izgledaju istinite, ali nisu. U igrici za ćaskanje ovo je podnošljivo; ne može se tolerisati u proizvodnom sistemu (faktura, zdravstveni, pravni, finansijski). Tako se ispostavilo, slijepo nepouzdano; je potvrđeno.

Slojevi verifikacije (povećavaju se uticajem):

Validacija formata/šeme: Da li je izlaz u skladu sa očekivanom JSON šemom? (Strukturirani izlaz u velikoj mjeri to garantuje.)
Provjera pravila/logike: Jesu li vrijednosti razumne? (Da li je iznos negativan, da li je datum u budućnosti, da li je kategorija važeća?)
Provjera izvora: Da li se tvrdnja zasniva na dostavljenoj dokumentaciji? Da li model kaže nešto što nije u dokumentu?
Ljudsko odobrenje: Stručnjak razmatra odluke koje imaju veliki uticaj ili dvosmislene.

Oprez: "Model je tako dobar, nije potrebna dodatna provjera" je najopasnija proizvodna zabluda. Bez obzira na to koliko je model dobar, sloj za verifikaciju je sigurnosna mreža u odlukama sa velikim uticajem. Čak i jedna pogrešna automatska odluka može oduzeti svo ušteđeno vrijeme.

Čovjek-u-petlji

Ne mora svaka odluka biti potpuno automatska. U pristupu čovjeka u petlji, model ubrzava rad i čovjek ga odobrava. Prava ravnoteža zavisi od uticaja odluke i pouzdanosti modela na taj zadatak.

Uticaj odluke

Pristup

Nisko (prijedlog etikete, nacrt)

Potpuna automatizacija; greška je jeftina i reverzibilna

Srednji (usmjeravanje, određivanje prioriteta)

Automatizacija + kontrola uzorkovanja

Visoka (novac, ugovor, zdravlje, brisanje)

Ljudski pristanak je obavezan; model samo sugerira

Nadgledanje: Ne možete upravljati onim što ne vidite

U proizvodnji morate pratiti svaki poziv. Bez praćenja, ne možete poboljšati troškove, kvalitet ili rano uočiti problem. Ključni pokazatelji za snimanje:

Upotreba/cijena: Po zahtjevu i ukupni tokeni, distribucija modela, dnevna potrošnja.
Latencija: prosječno i vrijeme odgovora u najgorem slučaju.
Stopa greške: 429/500 stopa, ponovni pokušaji, napuštanja.
Kvalitet: odbijena izlazna stopa na sloju verifikacije, stopa korekcije na ljudskom odobrenju, povratne informacije korisnika.

Savjet: Nemojte upisivati osjetljive podatke (lične informacije, ključeve) u evidencije nadzora. Razmotrite dnevnike u okviru povjerljivosti; snimanje maskiranjem ako je potrebno (jedinica 9).

Etika i granice

Etička odgovornost je jednako dio proizvodne odluke koliko i tehnička preciznost:

Transparentnost: korisnik treba da zna da li razgovara sa veštačkom inteligencijom ili sa čovekom.
Pravednost i pristrasnost: model može imati pristrasnost iz podataka na kojima je obučen; Nadgledati diskriminatorne posljedice u odlukama s velikim utjecajem (zapošljavanje, kredit).
Odgovornost: Ako automatizovana odluka prouzrokuje štetu, vi ste odgovorni; “Manekenka je tako rekla” nije odbrana.
Prihvatanje ograničenja: Model ne može pouzdano obavljati neke zadatke; ne automatizirati ih je također odluka dizajna.

Copiable Templates

# Kontrolna lista za validaciju (nakon generisanja izlaza)1) Da li je šema važeća? (provjera strukturiranog izlaza)2) Da li vrijednosti imaju smisla? (provera pravila: opseg, datum, enum)3) Da li je tvrdnja zasnovana na izvoru? (odbaciti ako nije u dokumentu)4) Da li je uticaj visok? → pošalji na ljudsko odobrenje5) Ako je sve prošlo → dozvoli radnju, sačuvaj

# Sistemski prompt koji prisiljava oslanjanje na izvor Oslonite se samo na informacije u datom dokumentu. Nemojte dodavati ništa što nije u dokumentu. Ako informacija nije u dokumentu, napišite "Nije pronađeno u dokumentu". Nikad ne pogađaj i ne izmišljaj stvari.

# Prag ljudskog odobrenja (pravilo odluke)IF tip_odluke u [novac, ugovor, brisanje, zdravlje] → ljudsko odobrenje obaveznoIF model_trust < prag ILI validacija "neizvjesno" → predati ljudskom odobrenju OTHER → automatska primjena + kontrola uzorkovanja

# Predložak dnevnika praćenja (pisanje osjetljivih podataka){ "time":"...", "model":"...", "input_token":..., "output_token":..., "delay_ms":..., "stop_reason":"...", "authentication":"prošlo|odbijeno|ljudski", "cost_usd" NISU upisani podaci

Slaba brza / Jaka brza (pouzdanost proizvodnje)

# SLABO (bez provjere, bez izvora, primjenjuje se automatski) Procijenite ovaj zahtjev, donesite odluku o povratu novca i prijavite se.

# JAKO (bazirano na izvoru, generira preporuku, prepušta ljudskom odobrenju) Procijenite ovaj zahtjev za povrat samo na osnovu dokumenta o politici povrata. Preporučite odluku sa obrazloženjem, ali ne implementirajte: {"recommendation":"approve|reject","reason":"...","policy_clause":"..."}.Ako nema jasne osnove u dokumentu o politici, navedite "nejasno". Predstavnik će odobriti konačnu odluku.

Moćna verzija; Odluku pripisuje izvoru, pozicionira model kao “sugeratora” a ne kao “činitelja” i stavlja korak s velikim utjecajem iza ljudskog odobravanja. Ovo je suština pouzdanosti proizvodnje.

Tri mini futrole

Slučaj 1 — Dan kada je sloj za verifikaciju sačuvan. Fintech je imao model da klasifikuje opise transakcija i kreira automatske računovodstvene zapise. Dodali su validaciju pravila: kada je model pogrešno izbacio iznos (12.500 umjesto 1.250 u dokumentu), pravilo "iznos ne odgovara dokumentu" je odbilo izlaz i zapis je pao na čovjeka. Da nije bilo verifikacije, netačan zapis bi tiho ušao u sistem.

Slučaj 2 — Begunac uhvaćen nadzorom. SaaS tim je postavio nadzorni panel; Jednog jutra dnevni trošak se utrostručio. Iz evidencije se vidjelo da je klijent ušao u petlju i poslao isti zahtjev hiljadama puta. Dodali su kvotu i deduplikaciju; Problem je riješen u roku od nekoliko sati. Bez praćenja, račun bi bio iznenađenje na kraju mjeseca.

Slučaj 3 — Prihvatanje ograničenja. Jedan zdravstveni startup planirao je potpuno automatski napraviti preporuku za dijagnozu i pokazati je pacijentu. U pregledu etike i odgovornosti, odlučili su da je ovo zabranjeno: model pruža samo sažetak i moguće poene za liječnika, ljekar postavlja dijagnozu. Neautomatizacija posla je također zrela dizajnerska odluka.

Uobičajene greške

Preskakanje validacije: slijepa primjena rezultata, govoreći "model je dobar".
Automatizacija odluka sa velikim uticajem: Ljudsko odobrenje je neophodno u novcu/zdravlju/zakonu.
Nepraćenje: Problemi sa troškovima i kvalitetom se otkrivaju kasno.
Upisivanje osjetljivih podataka u dnevnike: Kršenje privatnosti; Sačuvajte ga maskiranjem.
Ne pokušavam se osloniti na izvor: model može sastaviti ono što nije u dokumentu.
Ignoriranje ograničenja: Neautomatizacija nekih zadataka je prava odluka; Transparentnost i odgovornost su na vama.

Dublje: Upravljanje izdanjima, vraćanje unatrag i inkrementalna implementacija

Uvođenje LLM funkcije u produkciju ne znači postavljanje i zaboravljanje; je bezbedno modifikovanje živog sistema tokom vremena. Ima tri stuba.

Versioniranje. Vaš sistemski prompt, izbor modela i pravila verifikacije se menjaju tokom vremena. Verzija svake značajne promjene i zabilježite koja je verzija aktivna. Ako jednog dana kvaliteta padne, "šta smo promijenili?" Trebali biste biti u mogućnosti da odgovorite na pitanje u roku od nekoliko minuta. U sistemu bez verzije, pronalaženje glavnog uzroka regresije traje danima.

Rollback. Ako se novi upit ili model ponaša lošije nego što se očekivalo uživo, trebali biste se moći brzo vratiti na prethodnu, dobro poznatu verziju. Promjena bez plana vraćanja je slijepo prihvatanje živog rizika. „Nešto sam promenio, pokvarilo se, ne mogu da se vratim“ najskuplji je scenario proizvodnje.

Postepeno uvođenje. Umjesto da primjenjujete promjenu na sav promet odjednom, prvo je uvodite na mali postotak (npr. 5%) i pratite metriku (kvalitet, cijena, greške). Ako je dobro, povećavate procenat; Ako je loš, vratit ćete ga samo sa malim dijelom pogođenim. Ovo uvelike ograničava rizik.

Ove tri prakse kombinuju tehnike iz svih prethodnih jedinica: evaluacija (jedinica 5) mjeri promjenu unaprijed, praćenje (ova jedinica) daje rano upozorenje tokom širenja, sloj za verifikaciju hvata pogrešne izlaze prije nego što postanu djelotvorni. Proizvodnja nije jedna ispravna postavka; To je kontinuirana disciplina koja mjeri, prati i može se mijenjati s povjerenjem. Cijeli modul je za vas da uspostavite ovu disciplinu.

Ukratko

Proizvodnja je više od radne demonstracije: to je cevovod slojeva unosa, modela, verifikacije, akcije i praćenja. Izlaz je nepouzdan bez verifikacije; odluke sa velikim uticajem vezane su za ljudsko odobravanje; Svaki poziv se prati zbog troškova, grešaka i kvaliteta. Etika, transparentnost, kontrola pristrasnosti, odgovornost i prihvatanje ograničenja su sastavni dio tehničkih odluka. Svaki dio naučen u ovom modulu spaja se u ovaj holistički dizajn.

Zadatak aplikacije

Dizajnirajte LLM funkciju od kraja do kraja. (1) Popunite pet slojeva (unos, model, verifikacija, radnja, praćenje) za svoj specifični zadatak. (2) Označite po uticaju koje će odluke zahtijevati ljudsko odobrenje. (3) Napišite najmanje tri provjere valjanosti (šema, pravilo, izvor). (4) Odredite ključne metrike koje ćete pratiti, a šta nećete evidentirati. (5) Napišite ograničenje i etičko načelo koje prihvatate u ovoj osobini.

kontrolna lista

[ ] Mogu dizajnirati pet slojeva proizvodnog cjevovoda.
[ ] Mogu potvrditi izlaz u odnosu na šemu, pravilo i izvor.
[ ] Mogu postaviti ljudski prag odobrenja na osnovu uticaja odluke.
[ ] Pratim troškove, greške i kvalitet i praktikujem da ne upisujem osjetljive podatke u dnevnike.
[ ] Mogu da transformišem etiku, odgovornost i granice u proizvodne odluke.

Modul Exam

1. Šta radi 'sistemska' uloga u LLM chat API-ju?

A) Daje modelu trajna uputstva i pravila ponašanja koja se primjenjuju tokom cijelog razgovora ✔
B) Zadržava posljednje pitanje koje je napisao korisnik
C) Pohranjuje odgovor proizveden od strane modela
D) Šifruje API ključ

Opis: Sistemska uloga daje modelu stalna uputstva, ličnost i pravila koja se primenjuju tokom čitavog razgovora; To je preusmjeravanje na visokom nivou, odvojeno od korisničkih poruka.

2. Zašto se historija razgovora (prethodne poruke) svaki put ponovo šalje u API zahtjevu?

A) Potrebno je napraviti rezervnu kopiju jer server briše historiju
B) API pozivi su bez državljanstva; ✔ Kontekst se zamjenjuje na svaki zahtjev jer model ne pamti istoriju
C) Potreban samo za fakturisanje, nema uticaja na model
D) Slanje istorije je obavezno kako bi se izbjeglo usporavanje odgovora

Objašnjenje: LLM API pozivi su bez stanja; Model ne pamti prethodne runde, pa se sva relevantna historija zamjera na svaki zahtjev za očuvanjem konteksta.

3. Šta je 'token' u LLM cijenama?

A) Jednokratna lozinka koja se koristi za prijavu na API
B) Fiksna naknada koja se plaća na svaki zahtjev
C) Najmanja jedinica u kojoj model obrađuje tekst; obično odgovara dijelu riječi ✔
D) Jedinica koja mjeri samo dužinu izlaza

Opis: Token je najmanja jedinica u kojoj model obrađuje tekst; Obično odgovara fragmentu riječi, a i ulaz i izlaz se naplaćuju na osnovu broja tokena.

4. Zašto su izlazni tokeni skuplji od ulaznih tokena kod većine LLM provajdera?

A) Izlazni tokeni su uvijek duži od ulaznih
B) Ulazni tokeni su besplatni
C) Izlazni tokeni se šalju dva puta preko interneta
D) Jedinični trošak je veći jer generiranje izlaza zahtijeva dodatne proračune za svaki token ✔

Opis: Svaki od izlaznih tokena zahtijeva od modela da izvrši generiranje korak po korak (računanje); Ovaj proizvodni trošak je veći od obrade inputa odjednom, tako da je jedinična cijena izlaza obično viša.

5. U kojoj situaciji je korištenje streaminga najkorisnije?

A) U dugim odgovorima; Smanjuje uočeno kašnjenje i sprečava timeout ✔
B) Samo u vrlo kratkim odgovorima od jedne riječi
C) Smanjenje troškova na nulu
D) Sakriti API ključ

Opis: U dugim odgovorima, striming smanjuje uočeno kašnjenje tako što se prve riječi pojavljuju odmah i sprječava HTTP timeout pri velikim vrijednostima max_tokensa.

6. Na šta općenito utiče povećanje parametra 'napor' u modernim modelima?

A) Uvijek skratite odgovor
B) Automatski rotira API ključ
C) To samo smanjuje cijenu ulaznog tokena
D) Povećava dubinu razmišljanja i trošenje simbola; Može poboljšati kvalitetu, ali također povećava kašnjenje i troškove ✔

Opis: Parametar napora prilagođava koliko će model duboko razmišljati o zadatku i koliko će tokena potrošiti; Nadogradnja može poboljšati kvalitet, ali također povećava kašnjenje i troškove. Za jednostavne zadatke dovoljan je mali napor.

7. Koji je općenito najisplativiji pristup jednostavnom zadatku klasifikacije velikog obima?

A) Uvijek koristite najskuplji i najmoćniji model
B) Pozivanje svih modela u isto vrijeme za svaki zahtjev
C) Odabir najlakšeg/najjeftinijeg modela koji ispunjava zadatak tako što ga provjeravamo malom procjenom ✔
D) zadržavanje vrijednosti max_tokensa nepotrebno previsokom

Objašnjenje: Ako zadatak nije složen, odabir bržeg i jeftinijeg modela koji lako izvršava zadatak (npr. haiku klasa) umjesto korištenja najskupljeg i najmoćnijeg modela značajno će smanjiti troškove.

8. U kojem scenariju promptno keširanje najviše smanjuje troškove?

A) Kada se veliki i fiksni kontekst više puta koristi u mnogim zahtjevima ✔
B) Kada se uz svaki zahtjev šalje potpuno drugačiji tekst
C) Kada se podnese samo jedan zahtjev
D) Za smanjenje izlaznih tokena

Opis: Keširanje je podudaranje prefiksa; U slučajevima kada se veliki, nepromjenjivi kontekst (sistemski prompt, dokumenti) ponovo koristi u mnogim zahtjevima, čitanje iz keša je mali dio (~0,1x) pune cijene.

9. Kako da uredim prompt tako da se keš prompt pojavi?

A) Stavljanje promjenjivog sadržaja na početak i fiksnog sadržaja na kraju
B) Ugradite trenutni datum i vrijeme u sistemski prompt za svaki zahtjev
C) Stavljanje fiksnog sadržaja (sistemski prompt, dokumenti) na početak i varijabilnog sadržaja na kraju ✔
D) Promena redosleda liste alata sa svakim zahtevom

Objašnjenje: Budući da je predmemorija podudaranje prefiksa, fiksni/nepromjenjivi sadržaj (sistemska prompt, dokumenti) se inicijalizira; promenljivi sadržaj (datum, korisničko pitanje, ID zahteva) stavlja se na kraj. Čak i jedan bajt promijenjen na početku će poništiti keš memoriju.

10. Za koji tip posla je grupna obrada najprikladnija?

A) Live chat gdje korisnik očekuje trenutni odgovor na ekranu
B) Samo jedno kratko pitanje
C) Generisanje API ključa
D) Poslovi koji su tolerantni na kašnjenje, veliki obim i ne zahtijevaju trenutne rezultate ✔

Opis: Batch obrada je pogodna za velike količine poslova koji ne zahtijevaju trenutni odgovor i tolerantni su na kašnjenje; rezultati se isporučuju nakon nekog vremena, ali je jedinična cijena obično niža.

11. Šta se koristi za pouzdano podudaranje kojem zahtjevu pripadaju rezultati u grupi?

A) Slanje redoslijeda (pozicije) zahtjeva
B) Dužina odgovora
C) Zadnje 4 cifre API ključa
D) Jedinstveni custom_id dat svakom zahtjevu ✔

Napomena: Grupni rezultati mogu biti vraćeni drugačijim redosledom od naloga za podnošenje; tako da je potrebno uskladiti rezultate prema ID-u, a ne lokaciji, sa jedinstvenim custom_id-om dati svakom zahtjevu.

12. Koje je preporučeno ponašanje kada dobijete grešku 429 (ograničenje brzine) od API-ja?

A) Forsiranje slanjem više zahtjeva u isto vrijeme
B) Pokušaj ponovo sa eksponencijalnim odustajanjem, nakon naslova ponovnog pokušaja ✔
C) Otkažite zahtjev u potpunosti i prikažite grešku kao rušenje korisniku
D) Promjena API ključa

Objašnjenje: 429 je greška koja se može ponoviti; Ispravan pristup je pokušati ponovo sa eksponencijalnim povlačenjem, poštujući zaglavlje ponovnog pokušaja. Većina zvaničnih SDK-ova to radi automatski.

13. Koji od sljedećih HTTP kodova grešaka se općenito smatraju ponovnim pokušajem?

A) 400 (nevažeći zahtjev)
B) 401 (greška u autentifikaciji)
C) 529 (server preopterećen) ✔
D) 404 (nije pronađeno)

Objašnjenje: 429 (ograničenje brzine), 500 (greška servera) i 529 (preopterećenje) su privremene greške i mogu se ponovo pokušati povlačenjem. Greške poput 400 i 401 su pitanja zahtjeva/identiteta; Ponovni pokušaj to neće riješiti.

14. Što je od sljedećeg siguran način upravljanja API ključevima?

A) Pohranjivanje varijable okruženja/skrivenog menadžera, ne ugrađivanje u kod i redovno rotiranje ✔
B) Upišite ključ direktno u izvorni kod i pošaljite ga u spremište
C) Stavljanje ključa u JavaScript na strani klijenta (pretraživača).
D) Dijeljenje jednog ključa sa cijelim timom putem e-pošte

Opis: Ključevi se nikada ne pišu u izvorni kod ili spremište; Pohranjuje se u promjenljivu okolinu ili skriveni alat za upravljanje, dodjeljuje se s minimalnim privilegijama i redovno se rotira.

15. Koji je najbolji pristup LLM integraciji sa alatom za automatizaciju (n8n, Zapier, Make) u smislu privatnosti?

A) Slanje svih neobrađenih podataka u model, čak i ako to nije neophodno
B) Pisanje API ključa u običnom tekstu unutar koraka toka
C) Minimiziranje i maskiranje osjetljivih podataka i pohranjivanje ključa kao tajne vjerodajnice ✔
D) Trajno čuvanje ličnih podataka u istoriji toka

Opis: Kako automatizacija unosa podataka prolazi kroz sisteme i modele trećih strana, osjetljivi/lični podaci moraju biti minimizirani, maskirani i poslati samo obavezna polja; API ključ se također pohranjuje kao tajni vjerodajnici unutar alata.

16. Zašto je validacija rezultata obavezna u proizvodnoj funkciji zasnovanoj na LLM?

A) Potrebno je samo formatiranje jer model nikada ne pravi greške
B) Zato što model može proizvoditi fluidno, ali ponekad pogrešno; Šema/pravilo mora biti revidirano uz odobrenje resursa i ljudi ✔
C) Validaciju treba izbjegavati jer samo povećava troškove
D) Verifikacija je samo za smanjenje broja tokena

Opis: LLM mogu proizvesti tečan, ali ponekad netačan (halucinantni) izlaz; tako da je izašao u odlukama velikog uticaja; Trebalo bi da se revidira provjerom šeme/pravila, validacijom izvora i ljudskim odobrenjem kada je to potrebno.