Pilnīga ražošana: pārbaude, uzraudzība un ētika — API, izmaksas un integrācija

Ieguvumi:

Var izstrādāt visaptverošu arhitektūru, kas izmanto LLM funkciju no idejas līdz ražošanai
Izveido verifikācijas izpildes, cilvēku apstiprinājuma un izsekošanas līmeņus (reģistrēšana/metrika)
Robežas pārvērš ētikas un privātuma principus ražošanas lēmumos

Iepriekšējās desmit vienībās mēs apguvām daļas pa vienam: pieprasījuma struktūra, marķiera ekonomika, plūsma, sistēmas uzvedne, modeļa izvēle, kešatmiņa, partija, kļūdu pārvaldība, droša atslēga un automatizācija. Šajā pēdējā vienībā mēs apvienojam daļas un izveidojam holistisko arhitektūru, kas ietver LLM funkciju no idejas līdz ražošanai. Ražošana atšķiras no “darba demonstrācijas”: pārbaude ir obligāta, produkcija ir jāuzrauga, robežas un ētikas principi ir jāiekļauj lēmumos. Šī vienība ir moduļa nesēja kolonna; Šeit saplūst visi iepriekšējie.

Ražošanas arhitektūras slāņi

Cieta LLM kvalifikācija sastāv no aptuveni pieciem slāņiem:

Ievades slānis: apkopojiet datus, notīriet tos, maskējiet jutīgās zonas, pārsūtiet tikai nepieciešamo.
Modeļa slānis: atlasiet pareizo modeli (5. vienība), iestatiet sistēmas uzvedni un parametrus (4. vienība), kešatmiņu (6. vienība).
Validācijas slānis: ja nepieciešams, pārbaudiet izvadi pēc shēmas/noteikuma, avota un cilvēka apstiprinājuma.
Darbības slānis: veiciet darbību ar apstiprinātu izvadi; Uzņemiet spēcīgas ietekmes darbības.
Uzraudzības slānis: ierakstiet un novērtējiet katru zvanu, izmaksas, kļūdu un kvalitāti.

Šie slāņi ir cauruļvads; katrs pārbauda iepriekšējās izvadi.

Kāpēc ir nepieciešama pārbaude?

LLM var nodrošināt tekošu, bet dažreiz neprecīzu izvadi. To sauc par halucinācijām: modelis var izdomāt informāciju, kas šķiet patiesa, bet tā nav. Tērzēšanas spēlē tas ir pieļaujams; nevar pieļaut ražošanas sistēmā (rēķins, veselība, juridiskā, finanses). Tā izrādījās, akli neuzticams; ir apstiprināts.

Verifikācijas slāņi (palielinās pēc ietekmes):

Formāta/shēmas validācija: vai izvade atbilst paredzētajai JSON shēmai? (Strukturētā produkcija to lielā mērā garantē.)
Noteikumu/loģikas pārbaude: vai vērtības ir pamatotas? (Vai summa ir negatīva, vai datums ir nākotnē, vai kategorija ir derīga?)
Avota pārbaude: vai prasība ir balstīta uz iesniegto dokumentāciju? Vai modelī ir rakstīts kaut kas tāds, kas nav dokumentā?
Cilvēka apstiprinājums: eksperts pārskata ļoti ietekmīgus vai neskaidrus lēmumus.

Uzmanību: "Modelis ir tik labs, nav nepieciešama turpmāka pārbaude" ir visbīstamākā ražošanas kļūda. Neatkarīgi no tā, cik labs ir modelis, verifikācijas slānis ir drošības tīkls, pieņemot lēmumus ar lielu ietekmi. Pat viens nepareizs automātisks lēmums var atņemt visu ietaupīto laiku.

Cilvēks cilpā

Ne katram lēmumam ir jābūt pilnībā automātiskam. Cilvēks cilpā pieejā modelis paātrina darbu, un cilvēks to apstiprina. Pareizais līdzsvars ir atkarīgs no lēmuma ietekmes un modeļa uzticamības uz šo uzdevumu.

Lēmuma ietekme

Pieeja

Zems (iezīmes ieteikums, melnraksts)

Pilna automatizācija; kļūda ir lēta un atgriezeniska

Vidēja (maršrutēšana, prioritāšu noteikšana)

Automatizācija + paraugu ņemšanas kontrole

Augsts (nauda, līgums, veselība, dzēšana)

Cilvēka piekrišana ir obligāta; modelis tikai iesaka

Uzraudzība: jūs nevarat pārvaldīt to, ko neredzat

Ražošanā jums ir jāuzrauga katrs zvans. Bez uzraudzības jūs nevarat uzlabot izmaksas, kvalitāti vai savlaicīgi novērst problēmu. Galvenie ierakstāmie rādītāji:

Lietojums/izmaksas: pēc pieprasījuma un kopējie marķieri, modeļu izplatīšana, ikdienas izdevumi.
Latentums: vidējais un sliktākā gadījuma reakcijas laiks.
Kļūdu biežums: 429/500, atkārtojumi, pamešanas gadījumi.
Kvalitāte: noraidīts izvades ātrums pārbaudes slānī, korekcijas ātrums pēc cilvēka apstiprinājuma, lietotāju atsauksmes.

Padoms. Nerakstiet sensitīvus datus (personisko informāciju, atslēgas) uzraudzības žurnālos. Apsveriet žurnālus konfidencialitātes ietvaros; ierakstīt, ja nepieciešams, maskējot (9. vienība).

Ētika un robežas

Ētiskā atbildība ir tikpat liela ražošanas lēmuma sastāvdaļa kā tehniskā precizitāte:

Pārredzamība: lietotājam ir jāzina, vai viņš runā ar mākslīgo intelektu vai cilvēku.
Taisnīgums un neobjektivitāte: modelī var būt novirzes no datiem, uz kuriem tas ir apmācīts; Pārraugiet diskriminējošās sekas, pieņemot lēmumus ar lielu ietekmi (nomāšana darbā, kredīts).
Atbildība: ja automatizēts lēmums rada kaitējumu, jūs esat atbildīgs; “Modele tā teica” nav aizstāvība.
Ierobežojumu pieņemšana: modelis nevar uzticami veikt dažus uzdevumus; to neautomatizācija ir arī dizaina lēmums.

Kopējamas veidnes

# Validācijas kontrolsaraksts (pēc izvades ģenerēšanas)1) Vai shēma ir derīga? (strukturētās produkcijas apstiprināšana) 2) Vai vērtībām ir jēga? (noteikumu pārbaude: diapazons, datums, saraksts)3) Vai pretenzija ir balstīta uz avotu? (noraidīt, ja tas nav dokumentā)4) Vai ietekme ir liela? → nosūtīt cilvēka apstiprināšanai5) Ja viss ir izturēts → atļaut darbību, saglabāt

# Sistēmas uzvedne, kas liek paļauties uz avotu Paļauties tikai uz sniegtajā dokumentā esošo informāciju. Nepievienojiet neko, kas nav dokumentā. Ja dokumentā informācijas nav, ierakstiet "Dokumentā nav atrasts". Nekad neuzmini un neizdomā lietas.

# Cilvēka apstiprinājuma slieksnis (lēmuma noteikums) IF lēmuma_veids [nauda, līgums, dzēšana, veselība] → cilvēka apstiprinājums obligāts IF model_trust < slieksnis VAI validācija "nenoteikta" → iesniegt cilvēka apstiprināšanai OTHER → automātiska pielietošana + izlases kontrole

# Izsekošanas žurnāla veidne (sensitīvu datu rakstīšana){ "time":"...", "modelis":"...", "input_token":..., "output_token":..., "delay_ms":..., "stop_reason":"...", "autentifikācija":"passed|rejected|cilvēks", "cost_}/NE" ir rakstīti dati: VER un atslēgas } /usd":...

Vāja uzvedne / spēcīga uzvedne (ražošanas uzticamība)

# VĀJS (nav verifikācijas, nav avota, tiek lietots automātiski) Novērtējiet šo pieprasījumu, pieņemiet lēmumu par atmaksu un piesakieties.

# STRONG (pamatojoties uz avotu, ģenerē ieteikumu, atstāj cilvēka apstiprinājumu) Novērtējiet šo atgriešanas pieprasījumu, pamatojoties tikai uz atgriešanas politikas dokumentu. Ieteikt lēmumu ar pamatojumu, bet neīstenot: {"recommendation":"approve|reject","reason":"...","policy_clause":"..."}.Ja politikas dokumentā nav skaidra pamata, ievadiet "neskaidrs". Pārstāvis apstiprinās galīgo lēmumu.

Jaudīga versija; Tas attiecina lēmumu uz avotu, pozicionē modeli kā “ieteicēju”, nevis kā “darītāju”, un spēcīgo soli atstāj aiz cilvēka apstiprinājuma. Tā ir ražošanas uzticamības būtība.

Trīs mini futrāļi

1. gadījums — diena, kurā tika saglabāts verifikācijas slānis. Fintech lika modelim klasificēt darījumu aprakstus un izveidot automātiskus grāmatvedības ierakstus. Viņi pievienoja kārtulas validāciju: kad modelis nepareizi izvadīja summu (12 500, nevis 1250 dokumentā), noteikums “summa neatbilst dokumentam” noraidīja izvadi, un ieraksts tika reģistrēts cilvēkam. Ja verifikācija nenotiktu, nepareizais ieraksts klusībā nonāktu sistēmā.

2. gadījums — novērošana notverts bēglis. SaaS komanda bija izveidojusi uzraudzības paneli; Kādu rītu dienas izmaksas trīskāršojās. No žurnāliem bija redzams, ka klients iekļuva cilpā un nosūtīja vienu un to pašu pieprasījumu tūkstošiem reižu. Viņi pievienoja kvotu un atcēla dublēšanos; Problēma tika atrisināta stundu laikā. Bez izsekošanas rēķins būtu pārsteigums mēneša beigās.

3. gadījums — limita pieņemšana. Veselības aprūpes jaunuzņēmums plānoja pilnībā automātiski veikt diagnozes ieteikumu un parādīt to pacientam. Ētikas un atbildības pārskatā viņi nolēma, ka tas ir ārpus ierobežojumiem: modelis sniedz tikai kopsavilkumu un iespējamos punktus ārstam, ārsts veic diagnozi. Darba neautomatizācija ir arī nobriedis dizaina lēmums.

Biežas kļūdas

Validācijas izlaišana: akli pielietojiet rezultātu, sakot "modelis ir labs".
Spēcīgu lēmumu automatizācija: Cilvēka apstiprinājums ir būtisks naudas/veselības/tiesību jomā.
Neuzraudzība: izmaksu un kvalitātes problēmas tiek atklātas vēlu.
Sensitīvu datu ierakstīšana žurnālos: Privātuma pārkāpums; Saglabājiet to, maskējot to.
Nemēģina paļauties uz avotu: modelis var veidot to, kas nav dokumentā.
Ierobežojumu ignorēšana: dažu uzdevumu neautomatizācija ir pareizs lēmums; Pārredzamība un atbildība ir jūsu.

Deeper: laidienu pārvaldība, atcelšana un pakāpeniska izvietošana

LLM funkcijas ieviešana ražošanā nenozīmē tās iestatīšanu un aizmirstību; ir droši modificēt dzīvu sistēmu laika gaitā. Tam ir trīs pīlāri.

Versionēšana. Jūsu sistēmas uzvedne, modeļa izvēle un verifikācijas noteikumi laika gaitā mainās. Versija katru būtisku izmaiņu un ierakstiet, kura versija ir pieejama. Ja kādu dienu kvalitāte pazeminās, "ko mēs mainījām?" Jums vajadzētu būt iespējai atbildēt uz jautājumu dažu minūšu laikā. Sistēmā bez versijām regresijas pamatcēloņa atrašana aizņem vairākas dienas.

Atcelšana. Ja jauna uzvedne vai modelis tiešraidē darbojas sliktāk, nekā paredzēts, jums vajadzētu būt iespējai ātri atgriezties pie iepriekšējās, labi zināmās versijas. Izmaiņas bez atcelšanas plāna ir akla riska pieņemšana. "Es kaut ko mainīju, tas kļuva slikti, es nevaru atgriezties" ir visdārgākais ražošanas scenārijs.

Pakāpeniska izlaišana. Tā vietā, lai uzreiz piemērotu izmaiņas visai datplūsmai, vispirms tās jāievieš nelielai daļai (piem., 5%) un jāuzrauga metrika (kvalitāte, izmaksas, kļūdas). Ja tas ir labi, jūs palielināt procentus; Ja tas ir slikts, jūs to atgūsit, skarot tikai nelielu daļu. Tas ievērojami ierobežo risku.

Šajās trīs praksēs ir apvienoti visu iepriekšējo vienību paņēmieni: eval (5. vienība) mēra izmaiņas iepriekš, uzraudzība (šī vienība) sniedz agrīnu brīdinājumu izplatīšanas laikā, verifikācijas slānis uztver kļūdainos rezultātus, pirms tie kļūst izmantojami. Ražošana nav viena pareiza iestatīšana; Tā ir nepārtraukta disciplīna, kas mēra, uzrauga un var droši mainīties. Viss modulis ir paredzēts jums, lai izveidotu šo disciplīnu.

Rezumējot

Ražošana ir vairāk nekā darba demonstrācija: tas ir ievades, modeļa, verifikācijas, darbības un uzraudzības slāņu konveijera. Izvade nav uzticama bez pārbaudes; lielas ietekmes lēmumi ir saistīti ar cilvēka apstiprinājumu; Katrs zvans tiek pārraudzīts attiecībā uz izmaksām, kļūdām un kvalitāti. Ētika, caurspīdīgums, aizspriedumu kontrole, atbildība un ierobežojumu pieņemšana ir neatņemama tehnisko lēmumu sastāvdaļa. Katrs šajā modulī apgūtais gabals tiek apvienots šajā holistiskajā dizainā.

Lietojumprogrammas uzdevums

Izstrādājiet LLM funkciju no gala līdz galam. (1) Aizpildiet piecus slāņus (ievade, modelis, pārbaude, darbība, uzraudzība) savam konkrētajam uzdevumam. (2) Atzīmējiet pēc ietekmes, kuriem lēmumiem būs nepieciešams cilvēka apstiprinājums. (3) Uzrakstiet vismaz trīs validācijas pārbaudes (shēma, noteikums, avots). (4) Nosakiet galvenos rādītājus, kurus izsekosit un kurus nereģistrēsit. (5) Uzrakstiet ierobežojumu un ētikas principu, ko piekrītat šai funkcijai.

kontrolsaraksts

[ ] Varu noformēt piecus ražošanas cauruļvada slāņus.
[ ] Es varu pārbaudīt izvadi pēc shēmas, kārtulas un avota.
[ ] Es varu iestatīt cilvēka apstiprinājuma slieksni, pamatojoties uz lēmuma ietekmi.
[ ] Es uzraugu izmaksas, kļūdas un kvalitāti un praktizēju neierakstīt sensitīvus datus žurnālos.
[ ] Es varu pārveidot ētiku, atbildību un robežas ražošanas lēmumos.

Moduļa eksāmens

1. Ko “sistēmas” loma veic LLM tērzēšanas API?

A) Sniedz modelim pastāvīgus norādījumus un uzvedības noteikumus, kas attiecas uz visu sarunu ✔
B) Saglabā pēdējo lietotāja uzrakstīto jautājumu
C) Saglabā modeļa radīto atbildi
D) Šifrē API atslēgu

Apraksts: Sistēmas loma sniedz modelim pastāvīgus norādījumus, personību un noteikumus, kas ir spēkā visas sarunas laikā; Tā ir augsta līmeņa novirzīšana, kas ir atsevišķa no lietotāja ziņojumiem.

2. Kāpēc sarunu vēsture (iepriekšējie ziņojumi) tiek nosūtīta atkārtoti katru reizi API pieprasījumā?

A) Ir nepieciešams izveidot dublējumu, jo serveris dzēš vēsturi
B) API izsaukumi ir bezvalsts; ✔ Konteksts tiek nosūtīts atkārtoti pēc katra pieprasījuma, jo modelis neatceras vēsturi
C) Nepieciešams tikai rēķinu izrakstīšanai, neietekmē modeli
D) Vēstures nosūtīšana ir obligāta, lai izvairītos no atbildes palēnināšanas

Paskaidrojums: LLM API izsaukumi ir bezvalsts; Modelis neatceras iepriekšējās kārtas, tāpēc visa attiecīgā vēsture tiek pārsūtīta uz katru pieprasījumu, lai saglabātu kontekstu.

3. Kas ir “žetons” LLM cenā?

A) Vienreizēja parole, ko izmanto, lai pieteiktos API
B) Fiksēta maksa, ko maksā par katru pieprasījumu
C) mazākā vienība, kurā modelis apstrādā tekstu; parasti atbilst vārda daļai ✔
D) vienība, kas mēra tikai izvades garumu

Apraksts: Token ir mazākā vienība, kurā modelis apstrādā tekstu; Tas parasti atbilst vārda fragmentam, un gan ievade, gan izvade tiek iekasēta, pamatojoties uz marķieru skaitu.

4. Kāpēc lielākajā daļā LLM nodrošinātāju izvades marķieri ir dārgāki nekā ievades marķieri?

A) Izvades marķieri vienmēr ir garāki par ievadi
B) Ievades marķieri ir bezmaksas
C) Izvades marķieri tiek nosūtīti divreiz internetā
D) Vienības izmaksas ir augstākas, jo produkcijas ģenerēšanai ir nepieciešami papildu aprēķini katram marķierim ✔

Apraksts: katram no izvades marķieriem ir nepieciešams, lai modelis veiktu soli pa solim ģenerēšanu (aprēķinu); Šīs ražošanas izmaksas ir augstākas nekā visu izejvielu pārstrāde uzreiz, tāpēc produkcijas vienības cena parasti ir augstāka.

5. Kādā situācijā straumēšanas izmantošana ir visizdevīgākā?

A) Garās atbildēs; Samazina uztverto kavēšanos un novērš taimautu ✔
B) Tikai ļoti īsās, viena vārda atbildēs
C) Samazināt izmaksas līdz nullei
D) Lai paslēptu API atslēgu

Apraksts: garās atbildēs straumēšana samazina uztverto latentumu, liekot pirmajiem vārdiem parādīties nekavējoties, un novērš HTTP taimautu pie lielām max_tokens vērtībām.

6. Ko vispār ietekmē parametra “piepūle” palielināšana mūsdienu modeļos?

A) Vienmēr saīsiniet atbildi
B) Automātiski pagriež API atslēgu
C) Tas tikai samazina ievades marķiera cenu
D) Palielina domāšanas dziļumu un žetonu tēriņus; Tas var uzlabot kvalitāti, bet arī palielina latentumu un izmaksas ✔

Apraksts: piepūles parametrs pielāgo, cik dziļi modelis domās par uzdevumu un cik marķieru tas iztērēs; Jaunināšana var uzlabot kvalitāti, taču tā arī palielina latentumu un izmaksas. Vienkāršu uzdevumu veikšanai pietiek ar nelielu piepūli.

7. Kāda parasti ir visrentablākā pieeja vienkāršam, liela apjoma klasifikācijas uzdevumam?

A) Vienmēr izmantojiet visdārgāko un jaudīgāko modeli
B) Zvanīt visiem modeļiem vienlaikus katram pieprasījumam
C) Izvēlēties vieglāko/lētāko modeli, kas izpilda uzdevumu, pārbaudot to ar nelielu eval ✔
D) saglabājot max_tokens vērtību nevajadzīgi pārāk augstu

Paskaidrojums: Ja uzdevums nav sarežģīts, izmaksas ievērojami samazināsies, izvēloties ātrāku un lētāku modeli, kas viegli izpilda uzdevumu (piem., Haiku klase), nevis izmantojot visdārgāko un jaudīgāko modeli.

8. Kādā gadījumā tūlītēja saglabāšana kešatmiņā visvairāk samazina izmaksas?

A) Ja liels un fiksēts konteksts tiek atkārtoti izmantots daudzos pieprasījumos ✔
B) Kad ar katru pieprasījumu tiek nosūtīts pavisam cits teksts
C) Ja tiek veikts tikai viens pieprasījums
D) Lai samazinātu izvades marķierus

Apraksts: Kešatmiņa ir prefiksa atbilstība; Gadījumos, kad liels, nemainīgs konteksts (sistēmas uzvedne, dokumenti) tiek atkārtoti izmantots daudziem pieprasījumiem, lasīšana no kešatmiņas ir neliela daļa (~0,1 x) no pilnās cenas.

9. Kā rediģēt uzvedni, lai tiktu parādīta uzvedne kešatmiņā?

A) Mainīga satura ievietošana sākumā un fiksēta satura ievietošana beigās
B) Katra pieprasījuma sistēmas uzvednē ieguliet pašreizējo datumu un laiku
C) Fiksēta satura (sistēmas uzvednes, dokumentu) ievietošana sākumā un mainīga satura ievietošana beigās ✔
D) Rīku saraksta secības maiņa ar katru pieprasījumu

Paskaidrojums. Tā kā kešatmiņa ir prefiksa atbilstība, tiek inicializēts fiksēts/nemainīgs saturs (sistēmas uzvedne, dokumenti); mainīgais saturs (datums, lietotāja jautājums, pieprasījuma ID) tiek ievietots beigās. Pat viens sākumā mainīts baits padarīs kešatmiņu nederīgu.

10. Kādam darba apjomam pakešu apstrāde ir vispiemērotākā?

A) Tiešraides tērzēšana, kurā lietotājs sagaida tūlītēju atbildi ekrānā
B) Tikai viens īss jautājums
C) API atslēgas ģenerēšana
D) Darbi, kas ir izturīgi pret kavēšanos, liela apjoma un neprasa tūlītējus rezultātus ✔

Apraksts: Pakešu apstrāde ir piemērota liela apjoma darbiem, kuriem nav nepieciešama tūlītēja reakcija un kuri ir izturīgi pret kavēšanos; rezultāti tiek piegādāti pēc kāda laika, bet vienības izmaksas parasti ir zemākas.

11. Kas tiek izmantots, lai pārliecinoši saskaņotu, kuram pieprasījumam rezultāti pieder partijai?

A) Pieprasījumu nosūtīšanas secība (pozīcija).
B) Atbilžu garums
C) API atslēgas pēdējie 4 cipari
D) Katram pieprasījumam piešķirts unikāls custom_id ✔

Piezīme: lielapjoma rezultātus var atgriezt citā secībā nekā iesniegšanas secībā; tāpēc ir nepieciešams saskaņot rezultātus pēc ID, nevis atrašanās vietas, ar unikālu custom_id, kas tiek piešķirts katram pieprasījumam.

12. Kāda ir ieteicama rīcība, saņemot 429 (likmju ierobežojuma) kļūdu no API?

A) Piespiešana, nosūtot daudz vairāk pieprasījumu vienlaikus
B) Mēģiniet vēlreiz ar eksponenciālu atkāpšanos, ievērojot virsrakstu ✔
C) pilnībā atceliet pieprasījumu un parādiet lietotājam kļūdu kā avāriju
D) API atslēgas maiņa

Paskaidrojums: 429 ir atkārtoti izmēģināma kļūda; Pareizā pieeja ir mēģināt vēlreiz ar eksponenciālu atkāpšanos, ievērojot galveni vēlreiz mēģināt pēc. Lielākā daļa oficiālo SDK to dara automātiski.

13. Kuri no tālāk norādītajiem HTTP kļūdu kodiem parasti tiek uzskatīti par atkārtoti izmēģināmiem?

A) 400 (nederīgs pieprasījums)
B) 401 (autentifikācijas kļūda)
C) 529 (serveris ir pārslogots) ✔
D) 404 (nav atrasts)

Paskaidrojums: 429 (ātruma ierobežojums), 500 (servera kļūda) un 529 (pārslodze) ir īslaicīgas kļūdas, un tās var mēģināt vēlreiz, atkāpjoties. Kļūdas, piemēram, 400 un 401, ir pieprasījuma/identitātes problēmas; Mēģinot vēlreiz, tas netiks atrisināts.

14. Kurš no šiem ir drošais API atslēgu pārvaldības veids?

A) Vides mainīgā/slēptā pārvaldnieka saglabāšana, neiegulšana kodā un regulāra rotācija ✔
B) Ierakstiet atslēgu tieši avota kodā un nosūtiet to uz repozitoriju
C) Atslēgas ievietošana klienta puses (pārlūka) JavaScript
D) Vienas atslēgas koplietošana ar visu komandu pa e-pastu

Apraksts: atslēgas nekad netiek ierakstītas avota kodā vai repozitorijā; Tas tiek glabāts vides mainīgajā vai slēptā pārvaldības rīkā, piešķirts ar minimālām privilēģijām un regulāri rotēts.

15. Kāda ir labākā pieeja LLM integrācijai ar automatizācijas rīku (n8n, Zapier, Make) privātuma ziņā?

A) Visu neapstrādāto datu nosūtīšana modelim, pat ja tas nav nepieciešams
B) API atslēgas rakstīšana vienkāršā tekstā plūsmas solī
C) Sensitīvu datu samazināšana un maskēšana un atslēgas saglabāšana kā slepenie akreditācijas dati ✔
D) Personas datu pastāvīga glabāšana plūsmas vēsturē

Apraksts: Tā kā dati tiek ievadīti automatizācijā, iet caur trešo pušu sistēmām un modeli, sensitīvie/personiskie dati ir jāsamazina, jāmaskē un jānosūta tikai obligātie lauki; API atslēga tiek saglabāta arī kā slepenie akreditācijas dati rīkā.

16. Kāpēc produkcijas validācija ir obligāta uz LLM balstītā ražošanas līdzeklī?

A) Nepieciešams tikai formatējums, jo modelis nekad nepieļauj kļūdas
B) jo modelis var ražot plūstoši, bet dažreiz nepareizi; Shēma/noteikums ir jāauditē ar resursu un cilvēku apstiprinājumu ✔
C) Jāizvairās no apstiprināšanas, jo tā tikai palielina izmaksas
D) Pārbaude ir paredzēta tikai marķieru skaita samazināšanai

Apraksts: LLM var radīt tekošu, bet dažkārt neprecīzu (halucinācijas) rezultātu; tāpēc tas izpaudās lēmumos ar lielu ietekmi; To vajadzētu pārbaudīt, pārbaudot shēmu/noteikumus, apstiprinot avotu un, ja nepieciešams, apstiprinot cilvēku.