Visapusiška gamyba: tikrinimas, stebėjimas ir etika — API, kaina ir integravimas

Pelnas:

Gali sukurti visapusišką architektūrą, kuri perima LLM funkciją nuo idėjos iki gamybos
Nustato patvirtinimo vykdymo, žmogaus patvirtinimo ir stebėjimo lygius (registravimas / metrika)
Ribos paverčia etikos ir privatumo principus gamybos sprendimais

Ankstesniuose dešimtyje dalių mokėmės po vieną: užklausos struktūra, žetonų ekonomika, srautas, sistemos eilutė, modelio pasirinkimas, talpykla, paketas, klaidų valdymas, saugus raktas ir automatizavimas. Šiame paskutiniame padalinyje sujungiame dalis ir sukuriame holistinę architektūrą, kuri perteikia LLM bruožą nuo idėjos iki gamybos. Gamyba skiriasi nuo „darbinės demonstracinės versijos“: patikrinimas yra privalomas, produkcija turi būti stebima, ribos ir etikos principai turi būti įtvirtinti sprendimuose. Šis blokas yra modulio nešiklio kolona; Čia susijungia visi ankstesni.

Gamybos architektūros sluoksniai

Tvirta LLM kvalifikacija susideda iš maždaug penkių sluoksnių:

Įvesties sluoksnis: rinkti duomenis, juos išvalyti, užmaskuoti jautrias vietas, perduoti tik tai, kas būtina.
Modelio sluoksnis: pasirinkite tinkamą modelį (5 blokas), nustatykite sistemos eilutę ir parametrus (4 blokas), talpyklą (6 blokas).
Patvirtinimo sluoksnis: jei reikia, patikrinkite išvestį pagal schemą / taisyklę, šaltinį ir žmogaus patvirtinimą.
Veiksmo sluoksnis: atlikite veiksmą su patvirtinta išvestimi; Užfiksuokite didelio poveikio veiksmus.
Stebėjimo sluoksnis: įrašykite ir išmatuokite kiekvieną skambutį, kainą, klaidą ir kokybę.

Šie sluoksniai yra dujotiekis; kiekvienas tikrina ankstesnio išvestį.

Kodėl reikalingas patvirtinimas?

LLM gali sklandžiai, bet kartais netiksliai pateikti rezultatus. Tai vadinama haliucinacijomis: modelis gali sukurti informaciją, kuri atrodo teisinga, bet ne. Pokalbių žaidime tai toleruotina; negali būti toleruojamas gamybos sistemoje (sąskaitos faktūros, sveikatos, teisinės, finansinės). Taip pasirodė, aklai nepatikimas; yra patvirtinta.

Tikrinimo sluoksniai (didėja dėl poveikio):

Formato / schemos patvirtinimas: ar išvestis atitinka numatomą JSON schemą? (Struktūrizuota produkcija iš esmės tai garantuoja.)
Taisyklės / logikos patikrinimas: ar vertės yra pagrįstos? (Ar suma neigiama, ar data ateityje, ar kategorija galioja?)
Šaltinio patikrinimas: ar pretenzija grindžiama pateiktais dokumentais? Ar modelis sako tai, ko nėra dokumente?
Žmogaus pritarimas: ekspertas peržiūri didelio poveikio ar dviprasmiškus sprendimus.

Atsargiai: „Modelis toks geras, nereikia tolesnio tikrinimo“ yra pavojingiausia gamybos klaida. Kad ir koks geras modelis būtų, patikros sluoksnis yra apsauginis tinklas priimant didelio poveikio sprendimus. Net vienas neteisingas automatinis sprendimas gali atimti visą sutaupytą laiką.

Žmogus kilpoje

Ne kiekvienas sprendimas turi būti visiškai automatinis. Taikant „žmogaus kilpoje“ metodą, modelis pagreitina darbą, o žmogus jam pritaria. Tinkama pusiausvyra priklauso nuo sprendimo poveikio ir modelio patikimumo tai užduočiai.

Sprendimo poveikis

Prieiga

Žemas (etiketės pasiūlymas, juodraštis)

Pilna automatika; klaida yra pigi ir grįžtama

Vidutinė (maršruto parinkimas, prioritetų nustatymas)

Automatika + mėginių ėmimo kontrolė

Didelis (pinigai, sutartis, sveikata, ištrynimas)

Žmogaus sutikimas yra privalomas; modelis tik siūlo

Stebėjimas: jūs negalite valdyti to, ko nematote

Gamyboje turite stebėti kiekvieną skambutį. Be stebėjimo negalite pagerinti sąnaudų, kokybės ar anksti pastebėti problemos. Pagrindinė metrika, kurią reikia įrašyti:

Naudojimas / kaina: už užklausą ir bendrą žetonų skaičių, modelio paskirstymą, dienos išlaidas.
Vėlavimas: vidutinis ir blogiausio atvejo atsako laikas.
Klaidų dažnis: 429/500 rodikliai, pakartotiniai bandymai, atsisakymai.
Kokybė: atmestas išvesties dažnis tikrinimo lygyje, pataisos greitis, kai žmogus patvirtina, naudotojų atsiliepimai.

Patarimas: nerašykite jautrių duomenų (asmeninės informacijos, raktų) į stebėjimo žurnalus. Atsižvelgti į žurnalų konfidencialumo sritį; įrašyti, jei reikia, užmaskuojant (9 blokas).

Etika ir ribos

Etinė atsakomybė yra tokia pat gamybos sprendimo dalis, kaip ir techninis tikslumas:

Skaidrumas: vartotojas turėtų žinoti, ar kalbasi su dirbtiniu intelektu, ar su žmogumi.
Sąžiningumas ir šališkumas: modelis gali turėti šališkumo dėl duomenų, kuriais remiantis jis yra parengtas; Stebėkite diskriminacines pasekmes priimant didelio poveikio sprendimus (įdarbinimą, kreditą).
Atsakomybė: jei automatizuotas sprendimas sukelia žalą, esate atsakingas; „Modelis taip pasakė“ nėra gynyba.
Ribų priėmimas: modelis negali patikimai atlikti kai kurių užduočių; jų neautomatizavimas taip pat yra dizaino sprendimas.

Kopijuojami šablonai

# Patvirtinimo kontrolinis sąrašas (po išvesties generavimo)1) Ar schema galioja? (struktūrinės išvesties patvirtinimas) 2) Ar reikšmės turi prasmę? (taisyklės patikrinimas: intervalas, data, eilė)3) Ar teiginys pagrįstas šaltiniu? (atmesti, jei dokumente nėra)4) Ar poveikis didelis? → siųsti žmogaus patvirtinimui5) Jei viskas atlikta → leisti veikti, išsaugoti

# Sistemos raginimas, kuris verčia pasikliauti šaltiniu Pasikliaukite tik pateiktame dokumente pateikta informacija. Nepridėkite nieko, ko nėra dokumente. Jei dokumente informacijos nėra, parašykite „Dokumente nerasta“. Niekada nespėk ir negalvok dalykų.

# Žmogaus patvirtinimo slenkstis (sprendimo taisyklė) IF sprendimo_tipas [pinigai, sutartis, ištrynimas, sveikata] → žmogaus patvirtinimas privalomasIF model_trust < slenkstis ARBA patvirtinimas „neaiškus“ → pateikti žmogaus patvirtinimui OTHER → automatinis pritaikymas + mėginių ėmimo kontrolė

# Trace log šablonas (rašomi neskelbtini duomenys){ "time":"...", "model":"...", "input_token":..., "output_token":..., "delay_ms":..., "stop_reason":"...", "autentifikavimas":"passed|rejected|man", "asmeninis_usd": VER ir raktas / NE yra parašyti

Silpna raginimas / Stiprus raginimas (gamybos patikimumas)

# SILPNAS (be patvirtinimo, nėra šaltinio, taikoma automatiškai) Įvertinkite šį prašymą, priimkite sprendimą dėl pinigų grąžinimo ir kreipkitės.

# STIPRUS (pagal šaltinį, generuoja rekomendaciją, palieka žmogaus patvirtinimui) Įvertinkite šią grąžinimo užklausą remdamiesi tik grąžinimo politikos dokumentu. Rekomenduokite sprendimą su pagrindimu, bet neįgyvendinkite: {"recommendation":"prove|reject","reason":"...","policy_clause":"..."}.Jei politikos dokumente nėra aiškaus pagrindo, nurodykite "neaišku". Galutinį sprendimą patvirtins atstovas.

Galinga versija; Sprendimas priskiriamas šaltiniui, modelis nurodomas kaip „pasiūlytojas“, o ne „darytojas“, o didelio poveikio žingsnis yra už žmogaus pritarimo. Tai yra gamybos patikimumo esmė.

Trys mini dėklai

1 atvejis – diena, kai patvirtinimo sluoksnis išsaugojo. „Fintech“ modelis turėjo klasifikuoti operacijų aprašymus ir kurti automatinius apskaitos įrašus. Jie pridėjo taisyklės patvirtinimą: kai modelis neteisingai išvedė sumą (12 500 vietoj 1 250 dokumente), taisyklė „suma neatitinka dokumento“ atmetė išvestį ir įrašas atiteko žmogui. Jei patikrinimo nebūtų, neteisingas įrašas tyliai patektų į sistemą.

2 atvejis – bėglys sučiuptas stebėjimo. SaaS komanda sukūrė stebėjimo grupę; Vieną rytą dienos kaina išaugo tris kartus. Iš žurnalų buvo matyti, kad klientas pateko į kilpą ir tūkstančius kartų išsiuntė tą pačią užklausą. Jie pridėjo kvotą ir dubliavimo panaikinimą; Problema buvo išspręsta per kelias valandas. Be stebėjimo sąskaita mėnesio pabaigoje būtų staigmena.

3 atvejis. Priimama riba. Sveikatos priežiūros įmonė planavo visiškai automatiškai pateikti diagnozės rekomendaciją ir parodyti ją pacientui. Etikos ir atsakomybės apžvalgoje jie nusprendė, kad tai neribojama: modelis pateikia tik santrauką ir galimus taškus gydytojui, gydytojas nustato diagnozę. Darbo neautomatizavimas taip pat yra brandus dizaino sprendimas.

Dažnos klaidos

Patvirtinimo praleidimas: aklas išvesties taikymas sakydamas „modelis geras“.
Didelio poveikio sprendimų automatizavimas: žmogaus pritarimas yra būtinas pinigų / sveikatos / teisės srityje.
Nestebėjimas: išlaidų ir kokybės problemos aptinkamos pavėluotai.
Jautrių duomenų įrašymas į žurnalus: Privatumo pažeidimas; Išsaugokite jį užmaskuodami.
Nesistengiama pasikliauti šaltiniu: modelis gali sudaryti tai, ko nėra dokumente.
Ribų nepaisymas: kai kurių užduočių neautomatizavimas yra teisingas sprendimas; Skaidrumas ir atsakomybė yra jūsų.

Deeper: leidimų valdymas, atšaukimas ir laipsniškas diegimas

LLM funkcijos įtraukimas į gamybą nereiškia, kad ją reikia nustatyti ir pamiršti; yra saugiai modifikuoti veikiančią sistemą laikui bėgant. Jame yra trys stulpai.

Versijų kūrimas. Sistemos raginimas, modelio pasirinkimas ir patvirtinimo taisyklės laikui bėgant keičiasi. Išverskite kiekvieną reikšmingą pakeitimą ir įrašykite, kuri versija veikia. Jei vieną dieną kokybė sumažės, "ką mes pakeitėme?" Į klausimą turėtumėte atsakyti per kelias minutes. Versijų neturinčioje sistemoje pagrindinės regresijos priežasties paieška trunka kelias dienas.

Atšaukimas. Jei naujas raginimas ar modelis veikia blogiau, nei tikėtasi, turėtumėte greitai grįžti prie ankstesnės, gerai žinomos versijos. Pakeitimas be atšaukimo plano yra aklas rizikos prisiėmimas. „Kažką pakeičiau, pasidarė blogai, negaliu grįžti“ – brangiausias gamybos scenarijus.

Laipsniškas išleidimas. Užuot taikę pakeitimą visam srautui iš karto, pirmiausia išleidžiate jį nedideliam procentui (pvz., 5 %) ir stebite metriką (kokybę, kainą, klaidas). Jei tai gerai, padidinkite procentą; Jei jis blogas, susigrąžinsite jį su tik maža dalimi. Tai labai apriboja riziką.

Šios trys praktikos sujungia visų ankstesnių vienetų metodus: eval (5 skyrius) iš anksto įvertina pokyčius, stebėjimas (šis vienetas) iš anksto įspėja sklidimo metu, tikrinimo sluoksnis užfiksuoja klaidingus rezultatus, kol jie tampa tinkami. Gamyba nėra viena teisinga sąranka; Tai nuolatinė disciplina, kuri matuoja, stebi ir gali drąsiai keistis. Visas modulis skirtas jums nustatyti šią discipliną.

Apibendrinant

Gamyba yra daugiau nei veikianti demonstracinė versija: tai įvesties, modelio, tikrinimo, veiksmų ir stebėjimo sluoksnių rinkinys. Išvestis yra nepatikima be patikrinimo; didelio poveikio sprendimai yra susieti su žmogaus pritarimu; Kiekvienas skambutis yra stebimas dėl kainos, klaidų ir kokybės. Etika, skaidrumas, šališkumo kontrolė, atskaitomybė ir apribojimų priėmimas yra neatsiejami nuo techninių sprendimų. Kiekvienas šiame modulyje išmoktas kūrinys susijungia į šį holistinį dizainą.

Taikymo užduotis

Sukurkite LLM funkciją nuo galo iki galo. (1) Užpildykite penkis sluoksnius (įvestis, modelis, patikrinimas, veiksmas, stebėjimas) savo konkrečiai užduočiai. (2) Pažymėkite pagal poveikį, kuriems sprendimams reikės žmogaus pritarimo. (3) Parašykite bent tris patvirtinimo patikras (schema, taisyklė, šaltinis). (4) Nustatykite pagrindines metrikas, kurias stebėsite ir kurių neregistruosite. (5) Parašykite ribą ir etinį principą, kurį sutinkate su šia funkcija.

kontrolinis sąrašas

[ ] Galiu suprojektuoti penkis gamybos vamzdyno sluoksnius.
[ ] Galiu patikrinti išvestį pagal schemą, taisyklę ir šaltinį.
[ ] Galiu nustatyti žmogaus patvirtinimo slenkstį, atsižvelgdamas į sprendimo poveikį.
[ ] Stebiu išlaidas, klaidas ir kokybę bei praktikuojuosi nerašyti slaptų duomenų į žurnalus.
[ ] Galiu etiką, atsakomybę ir ribas paversti gamybos sprendimais.

Modulio egzaminas

1. Ką „sistemos“ vaidmuo atlieka LLM pokalbių API?

A) Suteikia modeliui nuolatinius nurodymus ir elgesio taisykles, kurios galioja viso pokalbio metu ✔
B) Išsaugo paskutinį vartotojo parašytą klausimą
C) Išsaugo modelio sukurtą atsakymą
D) Šifruoja API raktą

Aprašymas: sistemos vaidmuo suteikia modeliui nuolatines instrukcijas, asmenybę ir taisykles, kurios galioja viso pokalbio metu; Tai aukšto lygio peradresavimas, atskirtas nuo vartotojo pranešimų.

2. Kodėl pokalbių istorija (ankstesni pranešimai) siunčiama iš naujo kiekvieną kartą API užklausoje?

A) Būtina sukurti atsarginę kopiją, nes serveris ištrina istoriją
B) API iškvietimai yra be būsenos; ✔ Kontekstas iš naujo siunčiamas kiekvienai užklausai, nes modelis neprisimena istorijos
C) Reikalingas tik sąskaitoms faktūroms išrašyti, modeliui įtakos neturi
D) Siuntimo istorija yra privaloma, kad nesulėtėtų atsakymas

Paaiškinimas: LLM API iškvietimai yra be būsenos; Modelis neprisimena ankstesnių raundų, todėl visa susijusi istorija persiunčiama kiekvienu prašymu išsaugoti kontekstą.

3. Kas yra „žetonas“ LLM kainodaroje?

A) Vienkartinis slaptažodis, naudojamas prisijungiant prie API
B) Už kiekvieną prašymą mokamas fiksuotas mokestis
C) Mažiausias vienetas, kuriame modelis apdoroja tekstą; dažniausiai atitinka žodžio dalį ✔
D) Vienetas, matuojantis tik išvesties ilgį

Aprašymas: Žetonas yra mažiausias vienetas, kuriame modelis apdoroja tekstą; Paprastai tai atitinka žodžio fragmentą, o tiek įvestis, tiek išvestis apmokestinami pagal žetonų skaičių.

4. Kodėl daugelyje LLM tiekėjų išvesties žetonai yra brangesni nei įvesties žetonai?

A) Išvesties žetonai visada yra ilgesni nei įvesties
B) Įvesties žetonai yra nemokami
C) Išvesties žetonai du kartus siunčiami internetu
D) Vieneto kaina yra didesnė, nes produkcijos generavimui reikia atlikti papildomus kiekvieno žetono skaičiavimus ✔

Aprašymas: Kiekvienas išvesties prieigos raktas reikalauja, kad modelis atliktų žingsnis po žingsnio generavimą (apskaičiavimą); Šios gamybos sąnaudos yra didesnės nei visų sąnaudų perdirbimas vienu metu, todėl produkcijos vieneto kaina paprastai yra didesnė.

5. Kokioje situacijoje srautinis perdavimas yra naudingiausias?

A) Ilguose atsakymuose; Sumažina suvokiamą vėlavimą ir apsaugo nuo skirtojo laiko ✔
B) Tik labai trumpais, vieno žodžio atsakymais
C) sumažinti išlaidas iki nulio
D) Norėdami paslėpti API raktą

Aprašymas: esant ilgiems atsakymams, srautinis perdavimas sumažina suvokiamą delsą, nes pirmieji žodžiai pasirodo iš karto ir neleidžia HTTP skirtajam laikui esant didelėms max_tokens reikšmėms.

6. Ką apskritai veikia „pastangos“ parametro padidinimas šiuolaikiniuose modeliuose?

A) Visada sutrumpinkite atsakymą
B) Automatiškai pasuka API raktą
C) Tai tik sumažina įvesties žetono kainą
D) Didina mąstymo gylį ir žetonų išlaidas; Tai gali pagerinti kokybę, bet taip pat padidina delsą ir kainą ✔

Aprašymas: pastangų parametras koreguoja, kaip giliai modelis mąstys apie užduotį ir kiek žetonų išleis; Atnaujinimas gali pagerinti kokybę, bet taip pat padidina delsą ir išlaidas. Paprastoms užduotims atlikti pakanka mažų pastangų.

7. Koks paprastai yra ekonomiškiausias būdas atlikti paprastą, didelės apimties klasifikavimo užduotį?

A) Visada naudokite brangiausią ir galingiausią modelį
B) Skambinkite visiems modeliams vienu metu dėl kiekvienos užklausos
C) Lengviausio/pigiausio modelio, kuris atlieka užduotį, pasirinkimas, patikrinant jį šiek tiek eval ✔
D) išlaikyti be reikalo per didelę max_tokens reikšmę

Paaiškinimas: jei užduotis nesudėtinga, pasirinkus greitesnį ir pigesnį modelį, kuris lengvai atlieka užduotį (pvz., Haiku klasė), užuot naudojęs brangiausią ir galingiausią modelį, žymiai sumažės kaina.

8. Kuriuo atveju greitas talpyklos kaupimas sumažina išlaidas labiausiai?

A) Kai daug užklausų pakartotinai naudojamas didelis ir fiksuotas kontekstas ✔
B) Kai su kiekviena užklausa siunčiamas visiškai skirtingas tekstas
C) Kai pateikiamas tik vienas prašymas
D) Sumažinti išvesties žetonus

Aprašymas: talpyklos kaupimas yra priešdėlio atitiktis; Tais atvejais, kai daug užklausų pakartotinai naudojamas didelis, nekintantis kontekstas (sistemos raginimas, dokumentai), nuskaitymas iš talpyklos sudaro mažą visos kainos dalelę (~0,1 karto).

9. Kaip turėčiau redaguoti raginimą, kad raginimo talpykla būtų pasiekta?

A) Įdėkite kintamą turinį į pradžią ir fiksuotą turinį pabaigoje
B) Įterpkite dabartinę datą ir laiką kiekvienos užklausos sistemos eilutėje
C) Fiksuoto turinio (sistemos raginimo, dokumentų) išdėstymas pradžioje ir kintamo turinio įdėjimas į pabaigą ✔
D) Keisti įrankių sąrašo tvarką su kiekviena užklausa

Paaiškinimas: kadangi talpykla yra priešdėlio atitiktis, inicijuojamas fiksuotas / nekintantis turinys (sistemos raginimas, dokumentai); kintamasis turinys (data, vartotojo klausimas, užklausos ID) dedamas pabaigoje. Net vienas pradžioje pakeistas baitas panaikins talpyklą.

10. Kokiam darbo krūviui geriausiai tinka paketinis apdorojimas?

A) Tiesioginis pokalbis, kai vartotojas tikisi momentinio atsakymo ekrane
B) Tik vienas trumpas klausimas
C) API rakto generavimas
D) Darbai, kurie yra atsparūs vėlavimui, didelės apimties ir nereikalauja greitų rezultatų ✔

Aprašymas: Paketinis apdorojimas tinka didelės apimties darbams, kuriems nereikia nedelsiant reaguoti ir kurie yra tolerantiški vėlavimui; rezultatai pateikiami po tam tikro laiko, tačiau vieneto kaina paprastai yra mažesnė.

11. Kas naudojama norint patikimai suderinti, kuriai užklausai rezultatai priklauso partijoje?

A) Prašymų siuntimo tvarka (pozicija).
B) Atsakymų trukmė
C) 4 paskutiniai API rakto skaitmenys
D) Kiekvienai užklausai suteiktas unikalus custom_id ✔

Pastaba: masiniai rezultatai gali būti grąžinami kita tvarka nei pateikimo tvarka; todėl būtina suderinti rezultatus pagal ID, o ne vietą, su unikaliu custom_id, pateiktu kiekvienai užklausai.

12. Koks yra rekomenduojamas elgesys, kai iš API gaunate 429 (normos limito) klaidą?

A) Priversti siunčiant daug daugiau užklausų vienu metu
B) Bandymas dar kartą su eksponentiniu atsitraukimu, vadovaudamasis antrašte ✔ bandyti iš naujo
C) Visiškai atšaukite užklausą ir vartotojui parodykite klaidą kaip strigtį
D) API rakto keitimas

Paaiškinimas: 429 yra pakartotinai bandoma klaida; Teisingas būdas yra bandyti dar kartą su eksponentiniu atsitraukimu, atsižvelgiant į pakartotinio bandymo antraštę. Dauguma oficialių SDK tai daro automatiškai.

13. Kuriuos iš šių HTTP klaidų kodų paprastai galima bandyti pakartoti?

A) 400 (netinkama užklausa)
B) 401 (autentifikavimo klaida)
C) 529 (serveris perkrautas) ✔
D) 404 (nerasta)

Paaiškinimas: 429 (greičio apribojimas), 500 (serverio klaida) ir 529 (perkrova) yra laikinos klaidos ir jas galima bandyti dar kartą atsitraukiant. Tokios klaidos kaip 400 ir 401 yra užklausos / tapatybės problemos; Bandymas dar kartą to neišspręs.

14. Kuris iš šių būdų yra saugus API raktų tvarkymo būdas?

A) Saugoti aplinkos kintamąjį / paslėptą tvarkyklę, neįterpti į kodą ir reguliariai suktis ✔
B) Įrašykite raktą tiesiai į šaltinio kodą ir nusiųskite jį į saugyklą
C) Rakto įdėjimas į kliento pusės (naršyklės) JavaScript
D) Vieno rakto bendrinimas su visa komanda el. paštu

Aprašymas: raktai niekada neįrašomi į šaltinio kodą ar saugyklą; Jis saugomas aplinkos kintamajame arba paslėptame valdymo įrankyje, suteikiamas minimaliomis privilegijomis ir reguliariai keičiamas.

15. Koks yra geriausias požiūris į LLM integravimą su automatizavimo įrankiu (n8n, Zapier, Make) privatumo požiūriu?

A) Visų neapdorotų duomenų siuntimas į modelį, net jei tai nėra būtina
B) API rakto rašymas paprastu tekstu srauto veiksme
C) Sumažinti ir užmaskuoti neskelbtinus duomenis ir saugoti raktą kaip slaptus kredencialus ✔
D) Asmens duomenų nuolatinis saugojimas srauto istorijoje

Aprašymas: Kadangi duomenys įvedami į automatiką pereina per trečiųjų šalių sistemas ir modelį, jautrūs / asmeniniai duomenys turi būti minimizuojami, užmaskuoti ir siųsti tik privalomus laukus; API raktas taip pat saugomas kaip slapti kredencialai įrankyje.

16. Kodėl LLM pagrįstoje gamybos savybėje produkcijos patvirtinimas yra privalomas?

A) Reikalingas tik formatavimas, nes modelis niekada nedaro klaidų
B) Kadangi modelis gali gaminti sklandžiai, bet kartais neteisingai; Schema/taisyklė turi būti patikrinta gavus išteklių ir žmogaus sutikimą ✔
C) Reikėtų vengti patvirtinimo, nes tai tik padidina išlaidas
D) Tikrinimas skirtas tik žetonų skaičiui sumažinti

Aprašymas: LLM gali sklandžiai, bet kartais netaikliai (haliucinacines) išvestis; taigi, tai išėjo į didelio poveikio sprendimus; Jis turėtų būti tikrinamas tikrinant schemą / taisykles, patvirtinant šaltinį ir prireikus žmogaus patvirtinimu.