Päästä päähän -tuotanto: todentaminen, valvonta ja etiikka

Voitot:

• Pystyy suunnittelemaan kokonaisvaltaisen arkkitehtuurin, joka vie LLM-ominaisuuden ideasta tuotantoon
• Perustaa vahvistuksen täytäntöönpanon, ihmisen hyväksynnän ja seurannan (lokikirjaus/mittarit)
• Rajat muuttavat etiikan ja yksityisyyden periaatteet tuotantopäätöksiksi

Edellisillä kymmenellä jaksolla opimme osat yksitellen: pyyntörakenne, tokenin taloustiede, kulku, järjestelmäkehote, mallin valinta, välimuisti, erä, virheenhallinta, suojattu avain ja automaatio. Tässä viimeisessä yksikössä yhdistämme osat ja luomme kokonaisvaltaisen arkkitehtuurin, joka kantaa LLM-ominaisuuden ideasta tuotantoon. Tuotanto eroaa "toimivasta demosta": todentaminen on pakollista, tuotantoa on valvottava, rajat ja eettiset periaatteet on upotettava päätöksiin. Tämä yksikkö on moduulin kantajapylväs; Kaikki edelliset yhdistyvät tähän.

Tuotantoarkkitehtuurin kerrokset

Kiinteä LLM-tutkinto koostuu noin viidestä tasosta:

1. Syöttökerros: Kerää tietoa, puhdista se, peitä herkät alueet, lähetä vain tarpeellista.
2. Mallikerros: Valitse oikea malli (yksikkö 5), aseta järjestelmäkehote ja parametrit (yksikkö 4), välimuisti (yksikkö 6).
3. Validointikerros: Tarkista tuloste skeeman/säännön, lähteen ja ihmisen hyväksynnän suhteen tarvittaessa.
4. Toimintokerros: Suorita toiminto validoidulla lähdöllä; Tallenna voimakkaita toimintoja.
5. Valvontakerros: Tallenna ja mittaa jokainen puhelu, hinta, virhe ja laatu.

Nämä kerrokset ovat putki; jokainen tarkistaa edellisen tulosteen.

Miksi vahvistus vaaditaan?

LLM:t voivat tuottaa sujuvaa, mutta joskus epätarkkoja tuloksia. Tätä kutsutaan hallusinaatioksi: malli saattaa tuottaa tietoa, joka näyttää olevan totta, mutta ei sitä ole. Chat-pelissä tämä on siedettävää; ei voida hyväksyä tuotantojärjestelmässä (lasku, terveys, laki, rahoitus). Joten kävi ilmi, sokeasti epäluotettava; vahvistetaan.

Varmistuskerrokset (lisääntyvät iskun mukaan):

• Muoto/skeeman vahvistus: Onko tulos odotetun JSON-skeeman mukainen? (Strukturoitu tuotos suurelta osin takaa tämän.)
• Säännön/logiikan tarkistus: Ovatko arvot järkeviä? (Onko summa negatiivinen, onko päivämäärä tulevaisuudessa, onko luokka voimassa?)
• Lähteen vahvistus: Perustuuko vaatimus toimitettuihin asiakirjoihin? Sanouko malli jotain, mitä ei ole asiakirjassa?
• Ihmisten hyväksyntä: Asiantuntija arvioi vaikuttavat tai epäselvät päätökset.

Varoitus: "Malli on niin hyvä, ettei lisävarmennusta tarvita" on vaarallisin tuotantovirhe. Riippumatta siitä, kuinka hyvä malli on, varmistuskerros on turvaverkko vaikuttavissa päätöksissä. Jopa yksi väärä automaattinen päätös voi viedä kaiken säästetyn ajan.

Ihminen silmukassa

Jokaisen päätöksen ei tarvitse olla täysin automaattista. Ihminen silmukassa -mallissa malli nopeuttaa työtä ja ihminen hyväksyy sen. Oikea tasapaino riippuu päätöksen vaikutuksesta ja mallin luotettavuudesta kyseiseen tehtävään.

Päätöksen vaikutus

Lähestymistapa

Matala (etikettiehdotus, luonnos)

Täysi automaatio; virhe on halpa ja korjattavissa

Keskitaso (reititys, priorisointi)

Automaatio + näytteenottoohjaus

Korkea (raha, sopimus, terveys, poisto)

Ihmisen suostumus on pakollinen; malli vain ehdottaa

Valvonta: Et voi hallita sitä, mitä et näe

Tuotannossa sinun on valvottava jokaista puhelua. Ilman valvontaa et voi parantaa kustannuksia, laatua tai havaita ongelmaa ajoissa. Tärkeimmät tallennettavat tiedot:

• Käyttö/kustannus: Pyyntöä kohti ja tunnukset yhteensä, mallin jakelu, päiväkulutus.
• Latenssi: Keskimääräinen ja pahimman tapauksen vasteaika.
• Virheprosentti: 429/500, uudelleenyritykset, hylkäämiset.
• Laatu: Hylätty tulostusnopeus varmistuskerroksessa, korjausnopeus ihmisen hyväksynnällä, käyttäjien palaute.

Vihje: Älä kirjoita arkaluonteisia tietoja (henkilökohtaisia ​​tietoja, avaimia) valvontalokiin. Harkitse lokeja luottamuksellisuuden piirissä; tallenna tarvittaessa maskaamalla (yksikkö 9).

Etiikka ja rajat

Eettinen vastuu on yhtä paljon tuotantopäätöstä kuin tekninen tarkkuus:

• Läpinäkyvyys: Käyttäjän tulee tietää, puhuuko hän tekoälylle vai ihmiselle.
• Oikeudenmukaisuus ja harha: Mallissa voi olla harhaa tiedoista, joiden perusteella se on koulutettu; Seuraa syrjiviä seurauksia vaikuttavissa päätöksissä (vuokraus, luotto).
• Vastuu: Jos automaattinen päätös aiheuttaa vahinkoa, olet vastuussa; "Malli sanoi niin" ei ole puolustus.
• Rajojen hyväksyminen: Malli ei pysty suorittamaan joitakin tehtäviä luotettavasti; Niiden automatisoimatta jättäminen on myös suunnittelupäätös.

Kopioitavat mallit

# Validoinnin tarkistuslista (tulosten luomisen jälkeen)1) Onko skeema kelvollinen? (strukturoidun tuotoksen validointi)2) Onko arvoilla järkeä? (säännön tarkistus: väli, päivämäärä, enum)3) Perustuuko väite lähteeseen? (hylkää jos ei ole asiakirjassa)4) Onko vaikutus suuri? → lähetä ihmisen hyväksyttäväksi5) Jos kaikki on hyväksytty → salli toiminto, tallenna

# Järjestelmäkehote, joka pakottaa luottamaan lähteeseen Luota vain toimitetun asiakirjan tietoihin. Älä lisää mitään, mitä ei ole asiakirjassa. Jos asiakirjassa ei ole tietoja, kirjoita "Ei löydy asiakirjasta". Älä koskaan arvaa tai keksi asioita.

# Ihmisen hyväksyntäkynnys (päätössääntö) IF päätöksen_tyyppi [raha, sopimus, poisto, terveys] → ihmisen hyväksyntä pakollinenJOS malli_luottamus < kynnys TAI validointi "epävarma" → lähetä ihmisen hyväksynnälle OTHER → automaattinen käyttö + näytteenoton valvonta

# Jäljityslokimalli (kirjoitetaan arkaluontoisia tietoja){ "time":"...", "malli":"...", "input_token":..., "output_token":..., "delay_ms":..., "stop_reason":"...", "todennus":"hyväksytty|hylätty|ihminen", "kustannus_} / NE" ovat kirjoitettuja tietoja:...

Heikko kehote / Vahva kehote (tuotannon luotettavuus)

# HEIKKO (ei vahvistusta, ei lähdettä, sovelletaan automaattisesti) Arvioi tämä pyyntö, tee hyvityspäätös ja hae.

# VAHVA (lähdepohjainen, tuottaa suosituksen, jättää ihmisen hyväksynnän) Arvioi tämä palautuspyyntö vain palautuskäytäntöasiakirjan perusteella. Suosittele päätöstä perusteluineen, mutta älä toteuta: {"recommendation":"approve|reject","reason":"...","policy_clause":"..."}.Jos käytäntöasiakirjassa ei ole selkeää perustetta, kirjoita "epäselvä". Edustaja hyväksyy lopullisen päätöksen.

Tehokas versio; Se asettaa päätöksen lähteen ansioksi, asettaa mallin "ehdottajaksi" eikä "tekijäksi" ja asettaa suuren vaikutuksen ihmisen hyväksynnän taakse. Tämä on tuotannon luotettavuuden ydin.

Kolme minikoteloa

Tapaus 1 – Päivä, jolloin vahvistuskerros tallensi. Fintechin malli luokitteli tapahtumakuvauksia ja luo automaattisia kirjanpitotietueita. He lisäsivät säännön vahvistuksen: kun malli tulosti summan väärin (12 500 asiakirjan 1 250 sijaan), "summa ei vastaa asiakirjaa" -sääntö hylkäsi tulosteen ja tietue putosi ihmiselle. Jos varmennusta ei tehdä, väärä tietue saapuisi hiljaa järjestelmään.

Tapaus 2 – Valvonnan saanut karannut. SaaS-tiimi oli perustanut valvontapaneelin; Eräänä aamuna päivähinta kolminkertaistui. Lokeista nähtiin, että asiakas meni silmukkaan ja lähetti saman pyynnön tuhansia kertoja. He lisäsivät kiintiöitä ja päällekkäisyyden poistamista; Ongelma ratkesi muutamassa tunnissa. Ilman seurantaa lasku olisi yllätys kuun lopussa.

Tapaus 3 – Rajan hyväksyminen. Terveydenhuollon startup aikoi tehdä diagnoosisuosituksen täysin automaattisesti ja näyttää sen potilaalle. Etiikka- ja vastuukatselmuksessa he päättivät, että tämä oli rajatonta: malli antaa vain yhteenvedon ja mahdolliset pisteet lääkärille, lääkäri tekee diagnoosin. Työn automatisoimatta jättäminen on myös kypsä suunnittelupäätös.

Yleisiä virheitä

• Validoinnin ohittaminen: Tulosteen soveltaminen sokeasti sanoen "malli on hyvä".
• Vaikuttavan päätöksen automatisointi: Ihmisten hyväksyntä on olennaista rahassa/terveydessä/lainsäädännössä.
• Ei valvontaa: Kustannus- ja laatuongelmat havaitaan myöhässä.
• Arkaluonteisten tietojen kirjoittaminen lokeihin: Yksityisyyden loukkaus; Tallenna se peittämällä se.
• Ei yritä luottaa lähteeseen: Malli voi muodostaa sen, mitä asiakirjassa ei ole.
• Rajojen huomioimatta jättäminen: joidenkin tehtävien automatisoimatta jättäminen on oikea päätös; Avoimuus ja vastuu ovat sinun.

Deeper: Julkaisun hallinta, palautus ja asteittainen käyttöönotto

LLM-ominaisuuden ottaminen tuotantoon ei tarkoita sen määrittämistä ja sen unohtamista; on muuttaa elävää järjestelmää turvallisesti ajan myötä. Siinä on kolme pilaria.

Versiointi. Järjestelmäkehote, mallin valinta ja vahvistussäännöt muuttuvat ajan myötä. Versio jokainen merkittävä muutos ja kirjaa, mikä versio on käytössä. Jos laatu laskee eräänä päivänä, "mitä muutimme?" Sinun pitäisi pystyä vastaamaan kysymykseen muutamassa minuutissa. Versiottomassa järjestelmässä regression perimmäisen syyn löytäminen kestää päiviä.

Palautus. Jos uusi kehote tai malli käyttäytyy livenä odotettua huonommin, sinun pitäisi pystyä nopeasti palaamaan edelliseen, tunnettuun versioon. Muutos ilman peruutussuunnitelmaa on sokeasti elävän riskin hyväksyminen. "Muutin jotain, se meni huonoon, en voi palata" on kallein tuotantoskenaario.

Asteittainen käyttöönotto. Sen sijaan, että soveltaisit muutosta kaikkeen liikenteeseen kerralla, otat sen käyttöön ensin pienelle prosenttiosuudelle (esim. 5 %) ja seuraat mittareita (laatu, hinta, virheet). Jos se on hyvä, lisäät prosenttiosuutta; Jos se on huono, saat sen takaisin, mutta vain pieni osa vaikuttaa. Tämä rajoittaa riskiä suuresti.

Nämä kolme käytäntöä yhdistävät kaikkien aiempien yksiköiden tekniikat: eval (yksikkö 5) mittaa muutoksen etukäteen, seuranta (tämä yksikkö) antaa varhaisen varoituksen leviämisen aikana, varmistuskerros havaitsee virheelliset tuotokset ennen kuin niistä tulee toimintakelpoisia. Tuotanto ei ole yksittäinen oikea kokoonpano; Se on jatkuva kurinalaisuus, joka mittaa, valvoo ja voi muuttua luottavaisesti. Koko moduuli on sinun perustaaksesi tämän kurinalaisuuden.

Yhteenvetona

Tuotanto on enemmän kuin toimiva esittely: se on syöttö-, malli-, varmistus-, toiminta- ja valvontatasojen putki. Tulos on epäluotettava ilman varmennusta; suuret päätökset on sidottu ihmisten hyväksyntään; Jokaisesta puhelusta seurataan kustannuksia, virheitä ja laatua. Etiikka, avoimuus, puolueellisuus, vastuullisuus ja rajojen hyväksyminen ovat olennaisia ​​teknisiä päätöksiä. Jokainen tässä moduulissa opittu pala yhdistyy tähän kokonaisvaltaiseen suunnitteluun.

Sovellustehtävä

Suunnittele LLM-ominaisuus päästä päähän. (1) Täytä viisi tasoa (syöttö, malli, vahvistus, toiminta, valvonta) erityistä tehtävääsi varten. (2) Merkitse vaikutuksen mukaan, mitkä päätökset vaativat ihmisen hyväksynnän. (3) Kirjoita vähintään kolme validointitarkistusta (kaavio, sääntö, lähde). (4) Määritä tärkeimmät tiedot, joita seuraat ja mitä et kirjaa. (5) Kirjoita raja ja eettinen periaate, jonka hyväksyt tässä ominaisuudessa.

tarkistuslista

• [ ] Osaan suunnitella viisi kerrosta tuotantoputkea.
• [ ] Pystyn validoimaan tulosteen skeemaa, sääntöä ja lähdettä vastaan.
• [ ] Voin asettaa ihmisen hyväksymisrajan päätöksen vaikutuksen perusteella.
• [ ] Tarkkailen kustannuksia, virheitä ja laatua ja harjoittelen sitä, etten kirjoita arkaluonteisia tietoja lokeihin.
• [ ] Pystyn muuttamaan etiikan, vastuullisuuden ja rajat tuotantopäätöksiksi.

Moduulin tentti

1. Mitä "järjestelmän" rooli tekee LLM-chat API:ssa?

• A) Antaa mallille pysyviä ohjeita ja käyttäytymissääntöjä, jotka pätevät koko keskustelun ajan ✔
• B) Säilyttää käyttäjän kirjoittaman viimeisen kysymyksen
• C) Tallentaa mallin tuottaman vastauksen
• D) Salaa API-avaimen

Kuvaus: Järjestelmärooli antaa mallille pysyviä ohjeita, persoonallisuutta ja sääntöjä, jotka pätevät koko keskustelun ajan; Se on korkean tason uudelleenohjaus, erillään käyttäjien viesteistä.

2. Miksi keskusteluhistoria (aiemmat viestit) lähetetään uudelleen joka kerta API-pyynnössä?

• A) Varmuuskopiointi on välttämätöntä, koska palvelin poistaa historian
• B) API-kutsut ovat tilattomia; ✔ Konteksti lähetetään uudelleen jokaisesta pyynnöstä, koska malli ei muista historiaa
• C) Vaaditaan vain laskutukseen, ei vaikuta malliin
• D) Historian lähettäminen on pakollista, jotta vastaus ei hidastu

Selitys: LLM API -kutsut ovat tilattomia; Malli ei muista edellisiä kierroksia, joten kaikki asiaankuuluvat historiat lähetetään uudelleen jokaisessa kontekstin säilyttämispyynnössä.

3. Mikä on "tunnus" LLM-hinnoittelussa?

• A) Kertaluonteinen salasana, jota käytetään API:hen kirjautumiseen
• B) Kiinteä maksu jokaisesta pyynnöstä
• C) Pienin yksikkö, jossa malli käsittelee tekstiä; vastaa yleensä sanaosaa ✔
• D) Yksikkö, joka mittaa vain lähdön pituuden

Kuvaus: Token on pienin yksikkö, jossa malli käsittelee tekstiä; Se vastaa yleensä sanan fragmenttia, ja sekä syöttö että lähtö veloitetaan merkkien lukumäärän perusteella.

4. Miksi useimpien LLM-palveluntarjoajien tulostokenit ovat kalliimpia kuin syöttötunnukset?

• A) Lähtötunnukset ovat aina pidempiä kuin syöte
• B) Syöttötunnukset ovat ilmaisia
• C) Tulostustunnukset lähetetään kahdesti Internetin kautta
• D) Yksikköhinta on korkeampi, koska tuotannon luominen vaatii lisälaskelmia jokaiselle tunnukselle ✔

Kuvaus: Jokainen tuloste vaatii mallin suorittamaan vaiheittaisen luonnin (laskennan); Tämä tuotantokustannus on korkeampi kuin panoksen käsittely kerralla, joten tuotoksen yksikköhinta on yleensä korkeampi.

5. Missä tilanteessa suoratoiston käyttäminen on hyödyllisintä?

• A) pitkissä vastauksissa; Vähentää havaittua viivettä ja estää aikakatkaisun ✔
• B) Vain hyvin lyhyissä, yhden sanan vastauksissa
• C) Kustannusten vähentäminen nollaan
• D) API-avaimen piilottaminen

Kuvaus: Pitkissä vastauksissa suoratoisto vähentää havaittua latenssia saamalla ensimmäiset sanat näkyviin välittömästi ja estää HTTP-aikakatkaisut suurilla max_tokens-arvoilla.

6. Mihin 'ponnistus'-parametrin lisääminen nykyaikaisissa malleissa yleensä vaikuttaa?

• A) Lyhennä aina vastausta
• B) Kääntää automaattisesti API-avainta
• C) Se vain alentaa syöttötunnuksen hintaa
• D) Lisää ajattelun syvyyttä ja rahankulutusta; Se voi parantaa laatua, mutta se myös lisää viivettä ja kustannuksia ✔

Kuvaus: Työparametri säätää, kuinka syvästi malli ajattelee tehtävää ja kuinka monta merkkiä se käyttää; Päivitys voi parantaa laatua, mutta se myös lisää viivettä ja kustannuksia. Yksinkertaisiin tehtäviin pieni vaiva riittää.

7. Mikä on yleensä kustannustehokkain lähestymistapa yksinkertaiseen, suureen luokitustehtävään?

• A) Käytä aina kalleinta ja tehokkainta mallia
• B) Soittaa kaikkiin malleihin samanaikaisesti jokaisesta pyynnöstä
• C) Valitse kevyin/halvin malli, joka suorittaa tehtävän tarkistamalla se pienellä evalilla ✔
• D) max_tokens-arvon pitäminen tarpeettoman liian korkeana

Selitys: Jos tehtävä ei ole monimutkainen, nopeamman ja halvemman mallin valitseminen, joka suorittaa tehtävän helposti (esim. Haiku-luokka) kalleimman ja tehokkaimman mallin sijaan, vähentää kustannuksia merkittävästi.

8. Missä skenaariossa nopea välimuisti alentaa kustannuksia eniten?

• A) Kun suurta ja kiinteää kontekstia käytetään toistuvasti monissa pyynnöissä ✔
• B) Kun jokaisen pyynnön yhteydessä lähetetään täysin erilainen teksti
• C) Kun tehdään vain yksi pyyntö
• D) Tulostusmerkkien vähentäminen

Kuvaus: Välimuisti on etuliiteosuma; Tapauksissa, joissa suurta, muuttumatonta kontekstia (järjestelmäkehote, asiakirjat) käytetään uudelleen useissa pyynnöissä, välimuistista lukeminen on pieni murto-osa (~0,1x) täydestä hinnasta.

9. Miten kehotetta tulee muokata niin, että kehotteen välimuisti osuu?

• A) Muuttuvan sisällön lisääminen alkuun ja kiinteän sisällön sijoittaminen loppuun
• B) Upota kunkin pyynnön järjestelmäkehotteeseen nykyinen päivämäärä ja aika
• C) Kiinteän sisällön (järjestelmäkehote, asiakirjat) sijoittaminen alkuun ja muuttuvan sisällön sijoittaminen loppuun ✔
• D) Työkalulistan järjestyksen muuttaminen jokaisen pyynnön yhteydessä

Selitys: Koska välimuisti vastaa etuliitettä, kiinteä/muuttumaton sisältö (järjestelmäkehote, asiakirjat) alustetaan. muuttuva sisältö (päivämäärä, käyttäjän kysymys, pyyntötunnus) laitetaan loppuun. Jopa yksikin alussa muutettu tavu mitätöi välimuistin.

10. Minkä tyyppiseen työmäärään eräkäsittely sopii parhaiten?

• A) Live-chat, jossa käyttäjä odottaa välitöntä vastausta näytöllä
• B) Vain yksi lyhyt kysymys
• C) API-avaimen luominen
• D) Työt, jotka kestävät viivettä, ovat suuria eivätkä vaadi välittömiä tuloksia ✔

Kuvaus: Eräkäsittely soveltuu suuriin töihin, jotka eivät vaadi välitöntä vastausta ja jotka sietävät viivettä; tulokset toimitetaan jonkin ajan kuluttua, mutta yksikkökustannukset ovat yleensä alhaisemmat.

11. Mitä käytetään täsmäämään luotettavasti mihin pyyntöön tulokset kuuluvat erässä?

• A) Pyyntöjen lähetysjärjestys (sijainti).
• B) Vastausten pituus
• C) API-avaimen 4 viimeistä numeroa
• D) Jokaiselle pyynnölle annettu yksilöllinen custom_id ✔

Huomautus: Joukkotulokset voidaan palauttaa eri järjestyksessä kuin lähetysjärjestyksessä; joten tulokset on yhdistettävä tunnuksen, ei sijainnin, perusteella kullekin pyynnölle annetulla yksilöllisellä custom_id-tunnisteella.

12. Mikä on suositeltava toimintatapa, kun saat 429 (nopeusrajoitus) -virheen API:lta?

• A) Pakottaen lähettämällä useita pyyntöjä samanaikaisesti
• B) Yritetään uudelleen eksponentiaalisella perääntymisellä seuraamalla uudelleenyritys-jälkeen otsikkoa ✔
• C) Peruuta pyyntö kokonaan ja näytä virhe käyttäjälle kaatumisena
• D) API-avaimen vaihtaminen

Selitys: 429 on uudelleenyritettävä virhe; Oikea tapa on yrittää uudelleen eksponentiaalisella perääntymisellä uudelleenyritystä jälkeen -otsikkoa noudattaen. Useimmat viralliset SDK:t tekevät tämän automaattisesti.

13. Mitä seuraavista HTTP-virhekoodeista pidetään yleensä uudelleen yritettävänä?

• A) 400 (virheellinen pyyntö)
• B) 401 (todennusvirhe)
• C) 529 (palvelin ylikuormitettu) ✔
• D) 404 (ei löydy)

Selitys: 429 (nopeusrajoitus), 500 (palvelinvirhe) ja 529 (ylikuormitus) ovat tilapäisiä virheitä, ja niitä voidaan yrittää uudelleen peruuttamalla. Virheet, kuten 400 ja 401, ovat pyyntö-/identiteettiongelmia; Uudelleen yrittäminen ei ratkaise asiaa.

14. Mikä seuraavista on turvallinen tapa hallita API-avaimia?

• A) Ympäristömuuttujan/piilotetun hallinnan tallentaminen, ei upottaa sitä koodiin ja pyörii säännöllisesti ✔
• B) Kirjoita avain suoraan lähdekoodiin ja lähetä se arkistoon
• C) Avaimen asettaminen asiakaspuolen (selaimen) JavaScriptiin
• D) Yhden avaimen jakaminen koko tiimin kanssa sähköpostitse

Kuvaus: Avaimia ei koskaan kirjoiteta lähdekoodiin tai arkistoon; Se on tallennettu ympäristömuuttujaan tai piilotettuun hallintatyökaluun, joka myönnetään minimaalisilla oikeuksilla ja jota pyöritetään säännöllisesti.

15. Mikä on paras lähestymistapa LLM-integraatioon automaatiotyökalulla (n8n, Zapier, Make) yksityisyyden kannalta?

• A) Kaikkien raakatietojen lähettäminen malliin, vaikka se ei olisi välttämätöntä
• B) API-avaimen kirjoittaminen pelkkänä tekstinä kulkuvaiheen sisällä
• C) Arkaluontoisten tietojen minimoiminen ja peittäminen ja avaimen tallentaminen salaisiksi tunnistetiedoiksi ✔
• D) Henkilötietojen säilyttäminen pysyvästi kulkuhistoriassa

Kuvaus: Kun automaatiota syöttävät tiedot kulkevat kolmannen osapuolen järjestelmien ja mallin kautta, arkaluontoiset/henkilökohtaiset tiedot on minimoitava, peitettava ja lähetettävä vain pakolliset kentät. API-avain tallennetaan myös työkalun salaisiksi tunnistetiedoiksi.

16. Miksi tulosten validointi on pakollista LLM-pohjaisessa tuotantoominaisuudesta?

• A) Vain muotoilu vaaditaan, koska malli ei koskaan tee virheitä
• B) Koska malli voi tuottaa sujuvasti, mutta joskus virheellisesti; Kaavio/sääntö on auditoitava resurssien ja ihmisten hyväksynnällä ✔
• C) Validointia tulee välttää, koska se vain lisää kustannuksia
• D) Todentaminen on vain merkkien määrän vähentämistä

Kuvaus: LLM:t voivat tuottaa sujuvaa, mutta joskus epätarkkoja (hallusinatorisia) tuloksia; joten se tuli ulos suurivaikutteisia päätöksiä; Se tulee tarkastaa skeeman/sääntöjen tarkistuksella, lähteen validoinnilla ja tarvittaessa ihmisen hyväksynnällä.