Proizvodnja od kraja do kraja: provjera, praćenje i etika — API, cijena i integracija

Dobici:

Može dizajnirati end-to-end arhitekturu koja vodi značajku LLM-a od ideje do proizvodnje
Uspostavlja slojeve provedbe verifikacije, ljudskog odobrenja i praćenja (bilježenje/metrika)
Granice pretvaraju načela etike i privatnosti u proizvodne odluke

U prethodnih deset jedinica učili smo dijelove jedan po jedan: strukturu zahtjeva, ekonomiju tokena, tok, odzivnik sustava, odabir modela, predmemoriju, seriju, upravljanje pogreškama, sigurni ključ i automatizaciju. U ovoj posljednjoj jedinici kombiniramo dijelove i uspostavljamo holističku arhitekturu koja nosi značajku LLM-a od ideje do proizvodnje. Proizvodnja se razlikuje od "radne demonstracije": provjera je obavezna, izlaz se mora pratiti, granice i etička načela moraju biti ugrađeni u odluke. Ova jedinica je nosivi stup modula; Ovdje se spajaju svi prethodni.

Slojevi proizvodne arhitekture

Solidna LLM kvalifikacija sastoji se od otprilike pet razina:

Ulazni sloj: Prikupite podatke, očistite ih, maskirajte osjetljiva područja, prenesite samo ono što je neophodno.
Sloj modela: Odaberite ispravan model (jedinica 5), postavite upit i parametre sustava (jedinica 4), predmemoriju (jedinica 6).
Sloj provjere valjanosti: provjerite izlaz prema shemi/pravilu, izvoru i ljudskom odobrenju ako je potrebno.
Sloj akcije: Izvršite radnju s potvrđenim izlazom; Snimite radnje visokog učinka.
Sloj nadzora: Snimite i izmjerite svaki poziv, cijenu, grešku i kvalitetu.

Ovi slojevi su cjevovod; svaki provjerava izlaz prethodnog.

Zašto je provjera potrebna?

LLM-ovi mogu proizvesti tečne, ali ponekad i netočne rezultate. To se zove halucinacija: model može izmisliti informacije koje se čine istinitima, ali nisu. U igri chata to je podnošljivo; ne može se tolerirati u proizvodnom sustavu (faktura, zdravstvo, pravo, financije). Tako je ispalo, slijepo nepouzdano; je potvrđeno.

Verifikacijski slojevi (povećavaju se utjecajem):

Validacija formata/sheme: Je li izlaz u skladu s očekivanom JSON shemom? (Strukturirani izlaz to uvelike jamči.)
Provjera pravila/logike: Jesu li vrijednosti razumne? (Je li iznos negativan, je li datum u budućnosti, je li kategorija važeća?)
Provjera izvora: temelji li se tvrdnja na dostavljenoj dokumentaciji? Govori li model nešto čega nema u dokumentu?
Ljudsko odobrenje: Stručnjak pregledava vrlo utjecajne ili dvosmislene odluke.

Oprez: "Model je toliko dobar da nije potrebna daljnja provjera" je najopasnija proizvodna zabluda. Bez obzira na to koliko je model dobar, verifikacijski sloj je sigurnosna mreža u odlukama s velikim utjecajem. Č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, a čovjek ga odobrava. Prava ravnoteža ovisi o utjecaju odluke i pouzdanosti modela na taj zadatak.

Utjecaj odluke

pristup

Nisko (prijedlog oznake, nacrt)

Potpuna automatizacija; greška je jeftina i reverzibilna

Srednje (usmjeravanje, određivanje prioriteta)

Automatizacija + kontrola uzorkovanja

Visoko (novac, ugovor, zdravlje, brisanje)

Ljudski pristanak je obavezan; model samo sugerira

Praćenje: Ne možete upravljati onim što ne vidite

U proizvodnji morate pratiti svaki poziv. Bez praćenja ne možete poboljšati troškove, kvalitetu niti rano uočiti problem. Ključne metrike koje treba zabilježiti:

Upotreba/cijena: po zahtjevu i ukupni tokeni, distribucija modela, dnevna potrošnja.
Latencija: prosječno i najgore vrijeme odgovora.
Stopa pogrešaka: stope 429/500, ponovni pokušaji, odustajanja.
Kvaliteta: Stopa odbijenog izlaza na sloju provjere, stopa ispravka nakon ljudskog odobrenja, povratne informacije korisnika.

Savjet: Nemojte pisati osjetljive podatke (osobne podatke, ključeve) u zapisnike nadzora. Razmotrite zapisnike u okviru povjerljivosti; snimanje maskiranjem ako je potrebno (cjelina 9).

Etika i granice

Etička odgovornost jednako je dio proizvodne odluke kao i tehnička točnost:

Transparentnost: Korisnik bi trebao znati razgovara li s umjetnom inteligencijom ili s čovjekom.
Pravednost i pristranost: Model može nositi pristranost iz podataka na kojima je obučen; Pratite diskriminatorne posljedice u odlukama s velikim utjecajem (zapošljavanje, kredit).
Odgovornost: ako automatizirana odluka uzrokuje štetu, vi ste odgovorni; "Manekenka je tako rekla" nije obrana.
Prihvaćanje ograničenja: Model ne može pouzdano obavljati neke zadatke; ne automatizirati ih također je dizajnerska odluka.

Predlošci koji se mogu kopirati

# Popis za provjeru valjanosti (nakon generiranja izlaza)1) Je li shema važeća? (provjera strukturirane izlazne vrijednosti) 2) Imaju li vrijednosti smisla? (provjera pravila: raspon, datum, enum)3) Temelji li se tvrdnja na izvoru? (odbaciti ako nije u dokumentu) 4) Je li utjecaj velik? → pošalji na ljudsko odobrenje5) Ako je sve prošlo → dopusti akciju, spremi

# Sustavski prompt koji prisiljava na oslanjanje na izvor. Oslonite se samo na informacije u dostavljenom dokumentu. Nemojte dodavati ništa što nije u dokumentu. Ako informacije nema u dokumentu, napišite "Nije pronađeno u dokumentu". Nikad ne pogađajte i ne izmišljajte stvari.

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

# Predložak dnevnika praćenja (zapisivanje osjetljivih podataka){ "vrijeme":"...", "model":"...", "input_token":..., "output_token":..., "delay_ms":..., "stop_reason":"...", "authentication":"passed|rejected|human", "cost_usd":... } // osobni podaci i ključ NIKADA se ne zapisuju

Slab prompt / Jak prompt (pouzdanost proizvodnje)

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

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

Snažna verzija; Odluku pripisuje izvoru, pozicionira model kao "predlagača", a ne kao "izvršitelja", i stavlja korak velikog utjecaja iza ljudskog odobrenja. Ovo je bit pouzdanosti proizvodnje.

Tri mini kućišta

Slučaj 1 — Dan kada je verifikacijski sloj spremljen. Fintech je model klasificirao opise transakcija i stvorio automatsku računovodstvenu evidenciju. Dodali su provjeru valjanosti pravila: nakon što model ispiše netočan iznos (12.500 umjesto 1.250 u dokumentu), pravilo "iznos ne odgovara dokumentu" odbacilo je izlaz i rekord je pao na čovjeka. Ako nije bilo provjere, netočan bi zapis tiho ušao u sustav.

Slučaj 2 — Bjegunac uhvaćen nadzorom. SaaS tim je postavio nadzornu ploču; Jedno jutro dnevni trošak se utrostručio. Iz zapisa se vidjelo da je klijent ušao u petlju i poslao isti zahtjev tisuće 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 — Prihvaćanje ograničenja. Startup u zdravstvu planirao je napraviti preporuku za dijagnozu potpuno automatski i pokazati je pacijentu. U reviziji etike i odgovornosti odlučili su da je to zabranjeno: model daje samo sažetak i moguće bodove liječniku, liječnik postavlja dijagnozu. Neautomatiziranje posla također je zrela dizajnerska odluka.

Uobičajene greške

Preskakanje provjere valjanosti: slijepa primjena izlaza, govoreći "model je dobar".
Automatiziranje odluka s velikim utjecajem: Ljudsko odobrenje bitno je u novcu/zdravlju/zakonu.
Ne prati se: Problemi s troškovima i kvalitetom otkrivaju se kasno.
Zapisivanje osjetljivih podataka u zapisnike: Povreda privatnosti; Spasite ga maskiranjem.
Ne oslanjanje na izvor: Model može izmisliti ono što nije u dokumentu.
Ignoriranje ograničenja: neautomatizacija nekih zadataka je prava odluka; Transparentnost i odgovornost su vaše.

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

Stavljanje LLM značajke u proizvodnju ne znači da je postavite i zaboravite na nju; je sigurno mijenjati živi sustav tijekom vremena. Ima tri stupa.

Verzija. Upit vašeg sustava, odabir modela i pravila provjere mijenjaju se tijekom vremena. Verzirajte svaku značajnu promjenu i zabilježite koja je verzija aktivna. Ako jednog dana kvaliteta padne, "što smo promijenili?" Trebali biste moći odgovoriti na pitanje u roku od nekoliko minuta. U sustavu bez verzije, pronalaženje temeljnog uzroka regresije traje danima.

Povratak. Ako se novi upit ili model ponašaju lošije od očekivanog uživo, trebali biste se moći brzo vratiti na prethodnu, dobro poznatu verziju. Promjena bez plana vraćanja je slijepo prihvaćanje živog rizika. “Nešto sam promijenio, postalo je loše, ne mogu nazad” najskuplji je produkcijski scenarij.

Postupno uvođenje. Umjesto primjene promjene na sav promet odjednom, prvo je uvedete na mali postotak (npr. 5%) i pratite metriku (kvaliteta, cijena, pogreške). Ako je dobro, povećavate postotak; Ako je loš, dobit ćete ga natrag sa samo malim dijelom zahvaćenim. To uvelike ograničava rizik.

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

Ukratko

Produkcija je više od radne demonstracije: to je cjevovod slojeva unosa, modela, verifikacije, akcije i nadzora. Izlaz je nepouzdan bez provjere; odluke s visokim učinkom vezane su uz ljudsko odobrenje; Svaki poziv prati se na trošak, pogreške i kvalitetu. Etika, transparentnost, kontrola pristranosti, odgovornost i prihvaćanje ograničenja sastavni su dio tehničkih odluka. Svaki dio koji se nauči u ovom modulu spaja se u ovaj holistički dizajn.

Zadatak aplikacije

Dizajnirajte značajku LLM-a od kraja do kraja. (1) Ispunite pet slojeva (unos, model, provjera, radnja, praćenje) za svoj specifični zadatak. (2) Označite utjecajem koje će odluke zahtijevati ljudsko odobrenje. (3) Napišite najmanje tri provjere valjanosti (shema, pravilo, izvor). (4) Odredite ključne metrike koje ćete pratiti, a koje nećete bilježiti. (5) Napišite ograničenje i etičko načelo koje prihvaćate u ovoj značajci.

popis za provjeru

[ ] Mogu dizajnirati pet slojeva proizvodnog cjevovoda.
[ ] Mogu potvrditi izlaz prema shemi, pravilu i izvoru.
[ ] Mogu postaviti prag ljudskog odobrenja na temelju utjecaja odluke.
[ ] Pratim troškove, pogreške i kvalitetu i prakticiram ne zapisivati osjetljive podatke u zapisnike.
[ ] Mogu transformirati etiku, odgovornost i granice u proizvodne odluke.

Modul ispit

1. Što uloga 'sustava' radi u API-ju za LLM chat?

A) Daje modelu stalne upute i pravila ponašanja koja vrijede tijekom cijelog razgovora ✔
B) Zadržava zadnje pitanje koje je korisnik napisao
C) Pohranjuje odgovor koji proizvodi model
D) Šifrira API ključ

Opis: uloga sustava daje modelu trajne upute, osobnost i pravila koja se primjenjuju tijekom cijelog razgovora; To je preusmjeravanje visoke razine, odvojeno od korisničkih poruka.

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

A) Potrebno je napraviti sigurnosnu kopiju jer poslužitelj briše povijest
B) API pozivi su bez stanja; ✔ Kontekst se ponovno šalje na svaki zahtjev jer model ne pamti povijest
C) Potrebno samo za fakturiranje, nema utjecaja na model
D) Slanje povijesti je obavezno kako bi se izbjeglo usporavanje odgovora

Objašnjenje: LLM API pozivi su bez stanja; Model ne pamti prethodne runde, tako da se sva relevantna povijest ponovno šalje na svaki zahtjev radi očuvanja konteksta.

3. Što je 'token' u cijenama LLM-a?

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 duljinu izlaza

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

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

A) Izlazni žetoni su uvijek duži od ulaznih
B) Ulazni tokeni su besplatni
C) Izlazni tokeni šalju se dva puta putem interneta
D) Jedinični trošak je viši jer stvaranje izlaza zahtijeva dodatne izračune za svaki token ✔

Opis: svaki od izlaznih tokena zahtijeva da model izvede generiranje korak po korak (izračun); Ovaj proizvodni trošak je veći od obrade inputa odjednom, tako da je izlazna jedinična cijena obično viša.

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

A) U dugim odgovorima; Smanjuje percipirano kašnjenje i sprječava vremensko ograničenje ✔
B) Samo u vrlo kratkim odgovorima od jedne riječi
C) Svesti troškove na nulu
D) Za skrivanje API ključa

Opis: u dugim odgovorima, strujanje smanjuje percipiranu latenciju tako što se prve riječi pojavljuju odmah i sprječava HTTP timeout pri velikim vrijednostima max_tokens.

6. Na što općenito utječe povećanje parametra 'napora' kod modernih modela?

A) Uvijek skratite odgovor
B) Automatski rotira API ključ
C) Samo smanjuje ulaznu cijenu tokena
D) Povećava dubinu razmišljanja i simboličnu potrošnju; Može poboljšati kvalitetu, ali također povećava kašnjenje i troškove ✔

Opis: Parametar napora prilagođava koliko će duboko model razmišljati o zadatku i koliko će žetona potrošiti; Nadogradnja može poboljšati kvalitetu, 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, opsežnom zadatku klasifikacije?

A) Uvijek koristite najskuplji i najjači model
B) Pozivanje svih modela u isto vrijeme za svaki zahtjev
C) Odabir najlakšeg/najjeftinijeg modela koji ispunjava zadatak provjerom s malom procjenom ✔
D) održavanje nepotrebno previsoke vrijednosti max_tokens

Objašnjenje: Ako zadatak nije složen, odabirom bržeg i jeftinijeg modela koji lako ispunjava zadatak (npr. Haiku sat) umjesto korištenja najskupljeg i najsnažnijeg modela značajno će se smanjiti trošak.

8. U kojem scenariju brzo predmemoriranje 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) Smanjiti izlazne žetone

Opis: predmemoriranje je podudaranje prefiksa; U slučajevima kada se veliki, nepromjenjivi kontekst (sistemski odzivnik, dokumenti) ponovno koristi u mnogim zahtjevima, čitanje iz predmemorije mali je dio (~0,1x) pune cijene.

9. Kako bih trebao urediti prompt tako da se predmemorija upita pogađa?

A) Stavljanje varijabilnog sadržaja na početak, a fiksnog sadržaja na kraj
B) Ugradite trenutni datum i vrijeme u upit sustava za svaki zahtjev
C) Stavljanje fiksnog sadržaja (sustavski odzivnik, dokumenti) na početak i promjenjivog sadržaja na kraj ✔
D) Promjena redoslijeda popisa alata sa svakim zahtjevom

Objašnjenje: Budući da je predmemorija podudaranje prefiksa, fiksni/nepromjenjivi sadržaj (sistemski prompt, dokumenti) se inicijalizira; varijabilni sadržaj (datum, pitanje korisnika, ID zahtjeva) stavlja se na kraju. Čak će i jedan bajt promijenjen na početku poništiti predmemoriju.

10. Za koju vrstu radnog opterećenja je skupna obrada najprikladnija?

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

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

11. Što se koristi za pouzdano podudaranje kojem zahtjevu rezultati pripadaju u skupu?

A) Slanje redoslijeda (pozicija) zahtjeva
B) Duljina odgovora
C) Zadnje 4 znamenke API ključa
D) Jedinstveni custom_id dan svakom zahtjevu ✔

Napomena: Skupni rezultati mogu biti vraćeni drugačijim redoslijedom od redoslijeda podnošenja; stoga je potrebno uskladiti rezultate prema ID-u, a ne prema lokaciji, s jedinstvenim custom_id-om koji se daje svakom zahtjevu.

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

A) Forsiranje slanjem mnogo više zahtjeva u isto vrijeme
B) Ponovni pokušaj s eksponencijalnim odmakom, nakon naslova ponovno pokušaj nakon ✔
C) Otkažite zahtjev u potpunosti i pogrešku pokažite korisniku kao pad
D) Promjena API ključa

Objašnjenje: 429 je greška koja se može ponoviti; Ispravan pristup je pokušati ponovno s eksponencijalnim odmakom, poštujući zaglavlje ponovnog pokušaja. Većina službenih SDK-ova to radi automatski.

13. Koji se od sljedećih HTTP kodova pogrešaka općenito smatra mogućim za ponovni pokušaj?

A) 400 (nevažeći zahtjev)
B) 401 (pogreška provjere autentičnosti)
C) 529 (poslužitelj preopterećen) ✔
D) 404 (nije pronađeno)

Objašnjenje: 429 (ograničenje brzine), 500 (pogreška poslužitelja) i 529 (preopterećenje) su privremene pogreške i mogu se ponovno pokušati povući. Pogreške poput 400 i 401 su problemi sa zahtjevima/identitetom; Ponovni pokušaj neće riješiti problem.

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

A) Pohranjivanje u varijablu okruženja/skriveni upravitelj, neugrađivanje u kod i redovito rotiranje ✔
B) Zapišite ključ izravno u izvorni kod i pošaljite ga u repozitorij
C) Stavljanje ključa u JavaScript na strani klijenta (preglednik).
D) Dijeljenje jednog ključa s cijelim timom putem e-pošte

Opis: Ključevi se nikada ne zapisuju u izvorni kod ili repozitorij; Pohranjuje se u varijablu okruženja ili skriveni alat za upravljanje, dodijeljen s minimalnim privilegijama i redovito se mijenja.

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

A) Slanje svih neobrađenih podataka u model, čak i ako to nije potrebno
B) Pisanje API ključa u običnom tekstu unutar koraka toka
C) Minimiziranje i maskiranje osjetljivih podataka i pohranjivanje ključa kao tajnih vjerodajnica ✔
D) Trajno čuvanje osobnih podataka u povijesti toka

Opis: Kako automatizirani unos podataka prolazi kroz sustave i model trećih strana, osjetljive/osobne podatke potrebno je minimizirati, maskirati i poslati samo obavezna polja; API ključ je također pohranjen kao tajna vjerodajnica unutar alata.

16. Zašto je provjera valjanosti izlaza obavezna u značajci proizvodnje koja se temelji na LLM-u?

A) Potrebno je samo formatiranje jer model nikada ne griješi
B) Zato što model može proizvoditi fluidno, ali ponekad netočno; Shema/pravilo se mora revidirati uz odobrenje resursa i ljudi ✔
C) Validaciju treba izbjegavati jer samo povećava troškove
D) Provjera služi samo za smanjenje broja tokena

Opis: LLM mogu proizvesti tečne, ali ponekad netočne (halucinatorne) rezultate; tako da je došlo do odluka koje su imale veliki utjecaj; Treba ga revidirati provjerom sheme/pravila, provjerom valjanosti izvora i ljudskim odobrenjem kada je potrebno.