Prodhimi nga fundi në fund: Verifikimi, Monitorimi dhe Etika — API, Kostoja dhe Integrimi

Fitimet:

Mund të dizajnojë arkitekturën nga fundi në fund që merr një veçori LLM nga ideja në prodhim
Vendos shtresa të zbatimit të verifikimit, miratimit njerëzor dhe gjurmimit (logimi/metrika)
Kufijtë përkthejnë etikën dhe parimet e privatësisë në vendime prodhimi

Në dhjetë njësitë e mëparshme, ne mësuam pjesët një nga një: strukturën e kërkesës, ekonominë e tokenit, rrjedhën, kërkesat e sistemit, zgjedhjen e modelit, cache, grupin, menaxhimin e gabimeve, çelësin e sigurt dhe automatizimin. Në këtë njësi të fundit, ne kombinojmë pjesët dhe vendosim arkitekturën holistike që mbart një veçori LLM nga ideja në prodhim. Prodhimi është i ndryshëm nga një "demo pune": verifikimi është i detyrueshëm, rezultati duhet të monitorohet, kufijtë dhe parimet etike duhet të përfshihen në vendime. Kjo njësi është kolona bartëse e modulit; Të gjitha të mëparshmet bashkohen këtu.

Shtresat e Arkitekturës së Prodhimit

Një kualifikim solid LLM përbëhet nga afërsisht pesë shtresa:

Shtresa hyrëse: Mblidhni të dhëna, pastroni ato, maskoni zonat e ndjeshme, transmetoni vetëm atë që është e nevojshme.
Shtresa e modelit: Zgjidhni modelin e duhur (njësia 5), vendosni kërkesën dhe parametrat e sistemit (njësia 4), cache (njësia 6).
Shtresa e verifikimit: Kontrolloni rezultatin kundrejt skemës/rregullave, burimit dhe miratimit njerëzor nëse është e nevojshme.
Shtresa e veprimit: Kryeni veprim me dalje të vërtetuar; Kapni veprime me ndikim të lartë.
Shtresa e monitorimit: Regjistroni dhe matni çdo telefonatë, kosto, gabim dhe cilësi.

Këto shtresa janë një tubacion; secila kontrollon daljen e të mëparshmes.

Pse kërkohet verifikimi?

LLM-të mund të prodhojnë rezultate të rrjedhshme, por ndonjëherë të pasakta. Ky quhet halucinacion: modeli mund të fabrikojë informacion që duket të jetë i vërtetë, por nuk është. Në një lojë chat kjo është e tolerueshme; nuk mund të tolerohet në një sistem prodhimi (faturë, shëndetësi, ligjor, financë). Kështu doli, verbërisht jo e besueshme; është konfirmuar.

Shtresat e verifikimit (duke u rritur nga ndikimi):

Vlefshmëria e formatit/skemës: A përputhet dalja me skemën e pritur JSON? (Prodhimi i strukturuar e garanton kryesisht këtë.)
Verifikimi i rregullës/logjikës: A janë vlerat të arsyeshme? (A është shuma negative, a është data në të ardhmen, a është kategoria e vlefshme?)
Verifikimi i burimit: A bazohet pretendimi në dokumentacionin e ofruar? A thotë modeli diçka që nuk është në dokument?
Miratimi njerëzor: Një ekspert shqyrton vendimet me ndikim të lartë ose të paqarta.

Kujdes: "Modeli është aq i mirë, nuk ka nevojë për verifikim të mëtejshëm" është gabimi më i rrezikshëm i prodhimit. Pavarësisht se sa i mirë është modeli, shtresa e verifikimit është një rrjet sigurie në vendimet me ndikim të lartë. Edhe një vendim i gabuar automatik mund të heqë gjithë kohën e kursyer.

Njeriu-in-the-Loop

Jo çdo vendim duhet të jetë plotësisht automatik. Në qasjen njeriu në lak, modeli e përshpejton punën dhe njeriu e miraton atë. Balanca e duhur varet nga ndikimi i vendimit dhe besueshmëria e modelit në atë detyrë.

Ndikimi i vendimit

Qasje

E ulët (sugjerim etiketë, draft)

Automatizimi i plotë; gabimi është i lirë dhe i kthyeshëm

E mesme (drejtimi, prioritizimi)

Automatizimi + kontrolli i kampionimit

E lartë (para, kontratë, shëndet, fshirje)

Pëlqimi i njeriut është i detyrueshëm; modeli vetëm sugjeron

Monitorimi: Ju nuk mund të menaxhoni atë që nuk shihni

Në prodhim, duhet të monitoroni çdo thirrje. Pa monitorim, nuk mund të përmirësoni koston, cilësinë ose ta kapni një problem herët. Metrikat kryesore për të regjistruar:

Përdorimi/kostoja: Për kërkesë dhe argumente totale, shpërndarja e modelit, shpenzimet ditore.
Vonesa: Koha mesatare dhe në rastin më të keq të përgjigjes.
Shkalla e gabimit: normat 429/500, riprovimet, braktisjet.
Cilësia: Shkalla e prodhimit të refuzuar në shtresën e verifikimit, shkalla e korrigjimit me miratimin njerëzor, reagimet e përdoruesit.

Këshillë: Mos shkruani të dhëna të ndjeshme (të dhëna personale, çelësa) në regjistrat e monitorimit. Konsideroni regjistrat brenda fushës së konfidencialitetit; regjistroni duke maskuar nëse është e nevojshme (njësia 9).

Etika dhe Kufijtë

Përgjegjësia etike është po aq pjesë e vendimit të prodhimit sa edhe saktësia teknike:

Transparenca: Përdoruesi duhet të dijë nëse po flet me një inteligjencë artificiale apo me një njeri.
Drejtësia dhe paragjykimi: Modeli mund të ketë paragjykime nga të dhënat mbi të cilat është trajnuar; Monitoroni pasojat diskriminuese në vendimet me ndikim të lartë (punësimi, kreditimi).
Përgjegjësia: Nëse një vendim i automatizuar shkakton dëm, ju jeni përgjegjës; "Modeli tha kështu" nuk është një mbrojtje.
Pranimi i kufijve: Modeli nuk mund të kryejë disa detyra në mënyrë të besueshme; mos automatizimi i tyre është gjithashtu një vendim projektimi.

Modele të kopjueshme

# Lista kontrolluese e verifikimit (pas gjenerimit të prodhimit)1) A është skema e vlefshme? (vlefshmëria e prodhimit të strukturuar) 2) A kanë kuptim vlerat? (kontrolli i rregullave: diapazoni, data, numri) 3) A bazohet pretendimi në burim? (refuzo nëse jo në dokument)4) A është ndikimi i lartë? → dërgo për miratim njerëzor5) Nëse të gjitha kalohen → lejo veprimin, ruaje

# Njoftim i sistemit që detyron të mbështetet në burim Mbështetuni vetëm në informacionin në dokumentin e dhënë. Mos shtoni asgjë që nuk është në dokument. Nëse një informacion nuk është në dokument, shkruani "Nuk u gjet në dokument". Asnjëherë mos i hamendësoni apo shpikni gjërat.

# Pragu i miratimit njerëzor (rregulli i vendimit) IF lloji_vendimi në [para, kontratë, fshirje, shëndet] → miratimi njerëzor i detyrueshëmIF model_besimi < pragu OSE vërtetimi "i pasigurt" → dorëzoji miratimit njerëzor TJERA → aplikim automatik + kontroll kampionimi

# Trace log shabllon (shkrimi i të dhënave sensitive){ "time":"...", "model":"...", "input_token":..., "output_token":..., "delay_ms":..., "stop_arsye":"...", "authentication":"kaluar|refuzuar|njerëzore dhe të dhënat janë të shkruara...

Prompt i dobët / Prompt i fortë (besueshmëria e prodhimit)

# I DOBËT (pa verifikim, pa burim, zbatohet automatikisht) Vlerësoni këtë kërkesë, merrni një vendim për rimbursimin dhe aplikoni.

# FORTË (bazuar në burim, gjeneron rekomandime, lë në miratimin njerëzor) Vlerësoni këtë kërkesë kthimi bazuar vetëm në dokumentin e politikës së kthimit. Rekomandoni vendimin me arsyetim por mos zbatoni: {"rekomandim":"mirato|refuzo", "arsye":"...","klauzolë_policy":"..."}.Nëse nuk ka bazë të qartë në dokumentin e politikave, jepni "të paqartë". Një përfaqësues do të miratojë vendimin përfundimtar.

Version i fuqishëm; Ai ia atribuon vendimin burimit, e pozicionon modelin si një "sugjerues" dhe jo një "bërës" dhe e vendos hapin me ndikim të lartë pas miratimit njerëzor. Ky është thelbi i besueshmërisë së prodhimit.

Tre Mini Rastet

Rasti 1 - Dita kur u ruajt shtresa e verifikimit. Një fintech po kërkonte modelin të klasifikonte përshkrimet e transaksioneve dhe të krijonte regjistrime automatike të kontabilitetit. Ata shtuan vërtetimin e rregullave: sapo modeli e nxirrte shumën gabimisht (12,500 në vend të 1,250 në dokument), rregulli "shuma nuk përputhet me dokumentin" e refuzoi rezultatin dhe rekordi ra tek njeriu. Nëse nuk do të kishte verifikim, regjistrimi i pasaktë do të hynte në heshtje në sistem.

Rasti 2 — I arratisur i kapur nga vëzhgimi. Një ekip MSA kishte ngritur një panel monitorimi; Një mëngjes kostoja ditore u trefishua. Nga regjistrat u pa se një klient hyri në një lak dhe dërgoi të njëjtën kërkesë mijëra herë. Ata shtuan kuotën dhe dedulikimin; Problemi u zgjidh brenda disa orësh. Pa gjurmim, fatura do të ishte një surprizë në fund të muajit.

Rasti 3 - Pranimi i kufirit. Një startup i kujdesit shëndetësor po planifikonte të bënte një rekomandim diagnostikimi plotësisht automatikisht dhe t'ia tregonte atë pacientit. Në një rishikim të etikës dhe përgjegjësisë, ata vendosën se kjo ishte jashtë kufijve: modeli ofron vetëm një përmbledhje dhe pika të mundshme për një mjek, mjeku bën diagnozën. Mos automatizimi i një pune është gjithashtu një vendim i pjekur i projektimit.

Gabimet e zakonshme

Anashkalimi i vërtetimit: Zbatoni verbërisht rezultatin, duke thënë "modeli është i mirë".
Automatizimi i vendimit me ndikim të lartë: Miratimi njerëzor është thelbësor në para/shëndet/ligj.
Mos monitorimi: Problemet e kostos dhe cilësisë zbulohen vonë.
Shkrimi i të dhënave të ndjeshme në regjistra: Shkelje e privatësisë; Ruajeni duke e maskuar.
Duke mos u përpjekur të mbështeteni te burimi: Modeli mund të përbëjë atë që nuk është në dokument.
Injorimi i kufijve: Mosautomatizimi i disa detyrave është vendimi i duhur; Transparenca dhe përgjegjësia janë tuajat.

Më i thellë: Menaxhimi i lëshimit, Rikthimi dhe vendosja në rritje

Marrja e një veçorie LLM në prodhim nuk ka të bëjë me vendosjen dhe harrimin e tij; është të modifikoni në mënyrë të sigurt një sistem të drejtpërdrejtë me kalimin e kohës. Ajo ka tre shtylla.

Versionimi. Kërkesat e sistemit, përzgjedhja e modelit dhe rregullat e verifikimit ndryshojnë me kalimin e kohës. Version çdo ndryshim të rëndësishëm dhe regjistroni se cili version është i drejtpërdrejtë. Nëse një ditë bie cilësia, "çfarë kemi ndryshuar?" Ju duhet të jeni në gjendje t'i përgjigjeni pyetjes brenda disa minutave. Në një sistem pa version, gjetja e shkakut rrënjësor të një regresioni kërkon ditë.

Rikthim. Nëse një kërkesë ose model i ri sillet më keq nga sa pritej në live, duhet të jeni në gjendje të ktheheni shpejt në versionin e mëparshëm, të mirënjohur. Një ndryshim pa një plan rikthimi është të pranosh verbërisht një rrezik të drejtpërdrejtë. “Ndryshova diçka, u bë keq, nuk kthehem dot”, është skenari më i shtrenjtë i prodhimit.

Shfaqja graduale. Në vend që të aplikoni një ndryshim në të gjithë trafikun menjëherë, ju e shpërndani atë në një përqindje të vogël (p.sh. 5%) së pari dhe monitoroni metrikat (cilësia, kostoja, gabimet). Nëse është mirë, ju rritni përqindjen; Nëse është e keqe, do ta ktheni atë me vetëm një pjesë të vogël të prekur. Kjo kufizon shumë rrezikun.

Këto tre praktika kombinojnë teknikat nga të gjitha njësitë e mëparshme: vlerësimi (njësia 5) mat ndryshon paraprakisht, monitorimi (kjo njësi) jep paralajmërim të hershëm gjatë përhapjes, shtresa e verifikimit kap rezultate të gabuara përpara se ato të bëhen të zbatueshme. Prodhimi nuk është një strukturë e vetme e saktë; Është një disiplinë e vazhdueshme që mat, monitoron dhe mund të ndryshojë me besim. I gjithë moduli është që ju të vendosni këtë disiplinë.

Në përmbledhje

Prodhimi është më shumë se një demonstrim funksional: është një tubacion i shtresave të dhënash, modeli, verifikimi, veprimi dhe monitorimi. Prodhimi nuk është i besueshëm pa verifikim; vendimet me ndikim të lartë janë të lidhura me miratimin njerëzor; Çdo telefonatë monitorohet për kosto, gabime dhe cilësi. Etika, transparenca, kontrolli i paragjykimeve, llogaridhënia dhe pranimi i kufijve janë pjesë përbërëse e vendimeve teknike. Çdo pjesë e mësuar në këtë modul bashkohet në këtë dizajn holistik.

Detyra e aplikimit

Dizenjoni një veçori LLM nga fundi në fund. (1) Plotësoni pesë shtresat (hyrje, model, verifikim, veprim, monitorim) për detyrën tuaj specifike. (2) Shënoni sipas ndikimit se cilat vendime do të kërkojnë miratimin njerëzor. (3) Shkruani të paktën tre kontrolle të vërtetimit (skema, rregulli, burimi). (4) Përcaktoni metrikat kryesore që do të gjurmoni dhe çfarë nuk do të regjistroni. (5) Shkruani një kufi dhe një parim etik që pranoni në këtë veçori.

listë kontrolli

[ ] Unë mund të dizajnoj pesë shtresa të tubacionit të prodhimit.
[ ] Mund të vërtetoj daljen kundrejt skemës, rregullit dhe burimit.
[ ] Unë mund të vendos një prag miratimi njerëzor bazuar në ndikimin e vendimit.
[ ] Unë monitoroj koston, gabimet dhe cilësinë dhe praktikoj të mos shkruaj të dhëna të ndjeshme në regjistra.
[ ] Unë mund të transformoj etikën, përgjegjësinë dhe kufijtë në vendime prodhimi.

Provimi i Modulit

1. Çfarë bën roli 'sistemi' në një API të bisedës LLM?

A) I jep modelit udhëzime të përhershme dhe rregulla sjelljeje që zbatohen gjatë gjithë bisedës ✔
B) Mban pyetjen e fundit të shkruar nga përdoruesi
C) Ruan përgjigjen e prodhuar nga modeli
D) Enkripton çelësin API

Përshkrimi: Roli i sistemit i jep modelit udhëzime të vazhdueshme, personalitet dhe rregulla që zbatohen gjatë gjithë bisedës; Është një ridrejtim i nivelit të lartë, i ndarë nga mesazhet e përdoruesve.

2. Pse historiku i bisedave (mesazhet e mëparshme) dërgohet përsëri çdo herë në një kërkesë API?

A) Është e nevojshme të bëni kopje rezervë pasi serveri fshin historinë
B) Thirrjet API janë pa shtetësi; ✔ Konteksti dërgohet sërish për çdo kërkesë sepse modeli nuk e mban mend historinë
C) Kërkohet vetëm për faturim, nuk ka efekt në model
D) Dërgimi i historisë është i detyrueshëm për të shmangur ngadalësimin e përgjigjes

Shpjegim: Thirrjet LLM API janë pa shtetësi; Modeli nuk i mban mend raundet e mëparshme, kështu që i gjithë historia përkatëse dërgohet përsëri në çdo kërkesë për të ruajtur kontekstin.

3. Çfarë është një 'token' në çmimin e LLM?

A) Fjalëkalimi një herë i përdorur për të hyrë në API
B) Një tarifë fikse e paguar për çdo kërkesë
C) Njësia më e vogël në të cilën modeli përpunon tekstin; zakonisht korrespondon me pjesën e fjalës ✔
D) Një njësi që mat vetëm gjatësinë e daljes

Përshkrimi: Token është njësia më e vogël në të cilën modeli përpunon tekstin; Zakonisht korrespondon me një fragment të një fjale dhe si hyrja ashtu edhe dalja ngarkohen në bazë të numrit të shenjave.

4. Pse shenjat e daljes janë më të shtrenjta se shenjat hyrëse në shumicën e ofruesve të LLM?

A) Shenjat e daljes janë gjithmonë më të gjata se hyrjet
B) Shenjat hyrëse janë falas
C) Shenjat e daljes dërgohen dy herë në internet
D) Kostoja e njësisë është më e lartë sepse gjenerimi i prodhimit kërkon llogaritje shtesë për çdo shenjë ✔

Përshkrimi: Secili prej shenjave të daljes kërkon që modeli të kryejë gjenerimin hap pas hapi (llogaritjen); Kjo kosto prodhimi është më e lartë se përpunimi i të dhënave përnjëherë, kështu që çmimi i njësisë së prodhimit është zakonisht më i lartë.

5. Në cilën situatë është më e dobishme përdorimi i transmetimit?

A) Në përgjigje të gjata; Redukton vonesën e perceptuar dhe parandalon afatin ✔
B) Vetëm me përgjigje shumë të shkurtra, me një fjalë
C) Për të ulur koston në zero
D) Për të fshehur çelësin API

Përshkrimi: Në përgjigjet e gjata, transmetimi redukton vonesën e perceptuar duke i bërë fjalët e para të shfaqen menjëherë dhe parandalon afatet e HTTP në vlerat e mëdha max_tokens.

6. Çfarë ndikon në përgjithësi rritja e parametrit 'fort' në modelet moderne?

A) Gjithmonë shkurtojeni përgjigjen
B) Rrotullon automatikisht tastin API
C) Redukton vetëm çmimin e tokenit të hyrjes
D) Rrit thellësinë e të menduarit dhe shpenzimet simbolike; Mund të përmirësojë cilësinë, por gjithashtu rrit vonesën dhe koston ✔

Përshkrimi: Parametri i përpjekjes rregullon sa thellë modeli do të mendojë për një detyrë dhe sa argumente do të shpenzojë; Përmirësimi mund të përmirësojë cilësinë, por gjithashtu rrit vonesën dhe koston. Për detyra të thjeshta, mjafton përpjekje e ulët.

7. Cila është përgjithësisht qasja më kosto-efektive për një detyrë të thjeshtë klasifikimi me volum të lartë?

A) Përdorni gjithmonë modelin më të shtrenjtë dhe më të fuqishëm
B) Thirrja e të gjitha modeleve në të njëjtën kohë për çdo kërkesë
C) Zgjedhja e modelit më të lehtë/më të lirë që realizon detyrën duke e verifikuar me pak eval ✔
D) mbajtja e vlerës max_tokens në mënyrë të panevojshme shumë të lartë

Shpjegim: Nëse detyra nuk është komplekse, zgjedhja e një modeli më të shpejtë dhe më të lirë që e kryen lehtësisht detyrën (p.sh. klasa Haiku) në vend të përdorimit të modelit më të shtrenjtë dhe më të fuqishëm do të ulë ndjeshëm koston.

8. Në cilin skenar e redukton më shumë koston memoria e shpejtë?

A) Kur një kontekst i madh dhe fiks përdoret në mënyrë të përsëritur në shumë kërkesa ✔
B) Kur me çdo kërkesë dërgohet një tekst krejtësisht i ndryshëm
C) Kur bëhet vetëm një kërkesë e vetme
D) Për të reduktuar shenjat e daljes

Përshkrimi: Caching është një përputhje prefiksi; Në rastet kur një kontekst i madh, i pandryshueshëm (prompt sistemi, dokumente) ripërdoret në shumë kërkesa, leximi nga cache është një pjesë e vogël (~0.1x) e çmimit të plotë.

9. Si duhet ta modifikoj promptin në mënyrë që cache e shpejtë të godasë?

A) Vendosja e përmbajtjes së ndryshueshme në fillim dhe e përmbajtjes fikse në fund
B) Vendosni datën dhe orën aktuale në kërkesën e sistemit për secilën kërkesë
C) Vendosja e përmbajtjes fikse (promptja e sistemit, dokumentet) në fillim dhe e ndryshueshme në fund ✔
D) Ndryshimi i renditjes së listës së mjeteve me çdo kërkesë

Shpjegim: Meqenëse cache është një përputhje me prefiks, përmbajtja fikse/e pandryshueshme (prompt sistemi, dokumentet) inicializohet; Përmbajtja e ndryshueshme (data, pyetja e përdoruesit, ID-ja e kërkesës) vendoset në fund. Edhe një bajt i vetëm i ndryshuar në fillim do ta zhvlerësojë cache-in.

10. Për cilin lloj ngarkese pune është më i përshtatshmi përpunimi i grupeve?

A) Bisedë live ku përdoruesi pret një përgjigje të menjëhershme në ekran
B) Vetëm një pyetje e shkurtër
C) Gjenerimi i çelësit API
D) Punë që janë tolerante ndaj vonesave, volum të madh dhe nuk kërkojnë rezultate të menjëhershme ✔

Përshkrimi: Përpunimi në grup është i përshtatshëm për vëllime të mëdha punësh që nuk kërkojnë përgjigje të menjëhershme dhe janë tolerante ndaj vonesave; rezultatet jepen pas njëfarë kohe, por kostoja për njësi është zakonisht më e ulët.

11. Çfarë përdoret për të përputhur me siguri se cilës kërkesë i përkasin rezultatet në një grup?

A) Urdhri (pozicioni) i dërgimit të kërkesave
B) Gjatësia e përgjigjeve
C) 4 shifrat e fundit të çelësit API
D) Një custom_id unike e dhënë për çdo kërkesë ✔

Vërejtje: Rezultatet me shumicë mund të kthehen në një mënyrë të ndryshme nga urdhri i dorëzimit; kështu që është e nevojshme të përputhen rezultatet sipas ID-së, jo vendndodhjes, me një custom_id unike të dhënë për çdo kërkesë.

12. Cila është sjellja e rekomanduar kur merrni një gabim 429 (kufiri i normës) nga API?

A) Detyrimi duke dërguar shumë më tepër kërkesa në të njëjtën kohë
B) Përpjekja përsëri me prapavijë eksponenciale, duke ndjekur titullin riprovim pas ✔
C) Anuloni plotësisht kërkesën dhe shfaqni gabimin si një përplasje tek përdoruesi
D) Ndryshimi i çelësit API

Shpjegim: 429 është një gabim i riprovueshëm; Qasja e saktë është të provoni përsëri me prapambetje eksponenciale, duke respektuar titullin e riprovës pas. Shumica e SDK-ve zyrtare e bëjnë këtë automatikisht.

13. Cili nga kodet e mëposhtëm të gabimit HTTP konsiderohen përgjithësisht të riprovueshëm?

A) 400 (kërkesë e pavlefshme)
B) 401 (gabim vërtetimi)
C) 529 (serveri i mbingarkuar) ✔
D) 404 (nuk u gjet)

Shpjegim: 429 (kufizimi i shpejtësisë), 500 (gabim serveri) dhe 529 (mbingarkesa) janë gabime të përkohshme dhe mund të riprovohen duke u tërhequr. Gabimet si 400 dhe 401 janë çështje kërkese/identiteti; Përpjekja përsëri nuk do ta zgjidhë atë.

14. Cila nga mënyrat e mëposhtme është mënyra e sigurt për të menaxhuar çelësat API?

A) Ruajtja në variablin e mjedisit/menaxheri i fshehur, duke mos e futur në kod dhe duke e rrotulluar rregullisht ✔
B) Shkruani çelësin direkt në kodin burimor dhe dërgojeni atë në depo
C) Vendosja e çelësit në anën e klientit (shfletuesi) JavaScript
D) Ndarja e një çelësi të vetëm me të gjithë ekipin përmes emailit

Përshkrimi: Çelësat nuk shkruhen kurrë në kodin burimor ose në depo; Ai ruhet në një variabël mjedisor ose mjet të fshehur menaxhimi, i dhënë me privilegje minimale dhe rrotullohet rregullisht.

15. Cila është qasja më e mirë për integrimin e LLM me një mjet automatizimi (n8n, Zapier, Make) për sa i përket privatësisë?

A) Dërgimi i të gjitha të dhënave të papërpunuara në model, edhe nëse nuk është e nevojshme
B) Shkrimi i çelësit API në tekst të thjeshtë brenda hapit të rrjedhës
C) Minimizimi dhe maskimi i të dhënave të ndjeshme dhe ruajtja e çelësit si kredenciale sekrete ✔
D) Mbajtja e përhershme e të dhënave personale në historikun e rrjedhës

Përshkrimi: Ndërsa të dhënat që futen në automatizimin kalojnë nëpër sisteme dhe model të palëve të treta, të dhënat e ndjeshme/personale duhet të minimizohen, të maskohen dhe të dërgohen vetëm fushat e kërkuara; Çelësi API ruhet gjithashtu si kredenciale sekrete brenda mjetit.

16. Pse është i detyrueshëm vërtetimi i prodhimit në një veçori prodhimi të bazuar në LLM?

A) Kërkohet vetëm formatimi sepse modeli nuk gabon kurrë
B) Sepse modeli mund të prodhojë në mënyrë të rrjedhshme, por ndonjëherë në mënyrë të gabuar; Skema/rregulli duhet të auditohet me burime dhe miratim njerëzor ✔
C) Validimi duhet shmangur sepse vetëm rrit koston
D) Verifikimi është vetëm për të zvogëluar numrin e argumenteve

Përshkrimi: LLM-të mund të prodhojnë rezultate të rrjedhshme, por ndonjëherë të pasakta (halucinative); kështu doli në vendime me ndikim të lartë; Duhet të auditohet nga kontrolli i skemës/rregullave, vërtetimi i burimit dhe miratimi njerëzor kur është e nevojshme.