Teljes körű gyártás: ellenőrzés, felügyelet és etika

Nyereség:

• Meg tudja tervezni a végpontok közötti architektúrát, amely az LLM-funkciókat az ötlettől a gyártásig viszi át
• Létrehozza az ellenőrzés végrehajtását, az emberi jóváhagyást és a követést (naplózás/metrikák)
• A határok az etikát és az adatvédelmi elveket termelési döntésekké alakítják át

Az előző tíz egységben egyenként tanultuk meg a részeket: kérésstruktúra, token gazdaságosság, áramlás, rendszerprompt, modellválasztás, gyorsítótár, köteg, hibakezelés, biztonságos kulcs és automatizálás. Ebben az utolsó egységben egyesítjük az alkatrészeket, és létrehozzuk azt a holisztikus architektúrát, amely egy LLM jellemzőt hordoz az ötlettől a gyártásig. A gyártás különbözik a „működő demótól”: az ellenőrzés kötelező, a kimenetet figyelni kell, a határokat és az etikai elveket be kell ágyazni a döntésekbe. Ez az egység a modul hordozóoszlopa; Az összes előző itt összejön.

A termelési architektúra rétegei

A szilárd LLM képesítés nagyjából öt szintből áll:

1. Beviteli réteg: Adatgyűjtés, tisztítás, érzékeny területek maszkolása, csak a szükséges továbbítás.
2. Modellréteg: Válassza ki a megfelelő modellt (5. egység), állítsa be a rendszerpromptot és a paramétereket (4. egység), a gyorsítótárat (6. egység).
3. Ellenőrzési réteg: Ellenőrizze a kimenetet a séma/szabály, a forrás és az emberi jóváhagyás alapján, ha szükséges.
4. Műveleti réteg: Művelet végrehajtása ellenőrzött kimenettel; Rögzítse a nagy hatású műveleteket.
5. Felügyeleti réteg: Minden hívást, költséget, hibát és minőséget rögzít és mér.

Ezek a rétegek egy csővezeték; mindegyik ellenőrzi az előző kimenetét.

Miért szükséges az ellenőrzés?

Az LLM-ek folyékony, de néha pontatlan kimenetet produkálhatnak. Ezt nevezik hallucinációnak: a modell olyan információkat állíthat elő, amelyek igaznak tűnnek, de nem az. Egy chatjátékban ez elviselhető; termelési rendszerben (számla, egészségügyi, jogi, pénzügyi) nem tolerálható. Így derült ki, vakon megbízhatatlan; megerősítést nyer.

Ellenőrző rétegek (hatástól függően):

• Formátum/séma ellenőrzése: A kimenet megfelel a várt JSON-sémának? (A strukturált kimenet nagyrészt ezt garantálja.)
• Szabály/logikai ellenőrzés: ésszerűek az értékek? (Negatív az összeg, jövőre esik a dátum, érvényes a kategória?)
• Forrás ellenőrzése: A követelés a benyújtott dokumentáción alapul? Mond valamit a modell, ami nincs benne a dokumentumban?
• Emberi jóváhagyás: A szakértő felülvizsgálja a nagy hatású vagy kétértelmű döntéseket.

Figyelem: "A modell olyan jó, nincs szükség további ellenőrzésre" a legveszélyesebb gyártási tévedés. Bármilyen jó is a modell, az ellenőrző réteg biztonsági háló a nagy hatású döntéseknél. Még egy rossz automatikus döntés is elveszi az összes megspórolt időt.

Human-in-the-Loop

Nem kell minden döntésnek teljesen automatikusnak lennie. A humán-in-the-loop megközelítésben a modell felgyorsítja a munkát, az ember pedig jóváhagyja azt. A helyes egyensúly a döntés hatásától és a modell megbízhatóságától függ az adott feladatra.

A döntés hatása

Megközelítés

Alacsony (címkejavaslat, piszkozat)

Teljes automatizálás; a hiba olcsó és visszafordítható

Közepes (útválasztás, prioritás)

Automatizálás + mintavételezés

Magas (pénz, szerződés, egészség, törlés)

Az emberi hozzájárulás kötelező; a modell csak azt sugallja

Monitoring: Amit nem látsz, azt nem tudod kezelni

A gyártás során minden hívást figyelnie kell. Felügyelet nélkül nem lehet javítani a költségeken, a minőségen, és nem lehet korán felismerni a problémát. A rögzítendő legfontosabb mutatók:

• Használat/költség: kérésenként és teljes tokenenként, modelleloszlás, napi költés.
• Késési idő: Átlagos és legrosszabb válaszidő.
• Hibaarány: 429/500 arány, újrapróbálkozások, elhagyások.
• Minőség: Elutasított kimeneti sebesség az ellenőrzési rétegnél, korrekciós arány emberi jóváhagyáskor, felhasználói visszajelzés.

Tipp: Ne írjon érzékeny adatokat (személyes adatokat, kulcsokat) a megfigyelési naplókba. Vegye figyelembe a naplókat a titoktartási körön belül; szükség esetén maszkolással rögzítse (9. egység).

Etika és határok

Az etikai felelősség ugyanúgy része a gyártási döntésnek, mint a műszaki pontosság:

• Átláthatóság: A felhasználónak tudnia kell, hogy mesterséges intelligenciával vagy emberrel beszél.
• Méltányosság és torzítás: A modell torzítást hordozhat a betanított adatokból; Figyelemmel kíséri a diszkriminatív következményeket a nagy hatású döntéseknél (felvétel, hitel).
• Felelősség: Ha egy automatizált döntés kárt okoz, Ön a felelős; „A modell mondta” nem védekezés.
• Korlátok elfogadása: A modell nem tud megbízhatóan végrehajtani bizonyos feladatokat; ezek automatizálása szintén tervezési döntés.

Másolható sablonok

# Érvényesítési ellenőrző lista (kimenet generálása után)1) Érvényes a séma? (strukturált kimenet érvényesítése)2) Van értelme az értékeknek? (szabály ellenőrzése: tartomány, dátum, enum)3) Az állítás a forráson alapul? (elutasítás, ha nincs a dokumentumban)4) Magas a hatás? → küldje el emberi jóváhagyásra5) Ha minden megfelelt → engedélyezze a műveletet, mentse

# Rendszerkérdés, amely arra kényszeríti a forrásra támaszkodni, hogy csak a megadott dokumentumban található információkra támaszkodjon. Ne adjon hozzá semmit, ami nem szerepel a dokumentumban. Ha egy információ nem szerepel a dokumentumban, írja be, hogy "Nem található a dokumentumban". Soha ne találgass vagy találj ki dolgokat.

# Emberi jóváhagyási küszöb (döntési szabály) IF döntés_típusa [pénz, szerződés, törlés, egészség] → emberi jóváhagyás kötelező IF model_trust < küszöb VAGY érvényesítés "bizonytalan" → beküldés emberi jóváhagyásra OTHER → automatikus alkalmazás + mintavételezés

# Nyomkövetési naplósablon (érzékeny adatok írása){ "time":"...", "modell":"...", "input_token":..., "output_token":..., "delay_ms":..., "stop_reason":"...", "hitelesítés":"passed|rejected|human", "cost_usd":... VER és } / NE adatok vannak írva

Gyenge felszólítás / Erős felszólítás (gyártási megbízhatóság)

# GYENGE (nincs ellenőrzés, nincs forrás, automatikusan érvényesül) Értékelje ezt a kérést, hozzon döntést a visszatérítésről és jelentkezzen.

# ERŐS (forrásalapú, ajánlást generál, emberi jóváhagyásra hagyja) Ezt a visszaküldési kérelmet csak a visszaküldési szabályzat dokumentuma alapján értékelje. Javasolja a döntést indoklással, de ne hajtsa végre: {"recommendation":"prove|reject","reason":"...","policy_clause":"..."}.Ha az irányelv dokumentumban nincs egyértelmű alap, adja meg a "unclear" szót. A végső döntést egy képviselő hagyja jóvá.

Erőteljes változat; A döntést a forrásnak tulajdonítja, a modellt „suggesztióként” pozicionálja, nem pedig „cselekvőként”, és a nagy hatású lépést az emberi jóváhagyás mögé helyezi. Ez a termelési megbízhatóság lényege.

Három mini tok

1. eset – Az ellenőrző réteg mentésének napja. Egy fintech azt kérte a modellel, hogy osztályozza a tranzakcióleírásokat és hozzon létre automatikus könyvelési rekordokat. Hozzáadták a szabály érvényesítését: miután a modell hibásan adta ki az összeget (a dokumentumban szereplő 1250 helyett 12 500), az "összeg nem egyezik a bizonylattal" szabály elutasította a kimenetet, és a rekord az emberre esett. Ha nem lenne ellenőrzés, a helytelen rekord csendben bekerülne a rendszerbe.

2. eset – A szökevényt a megfigyelés fogta el. Egy SaaS csapat felállított egy felügyeleti panelt; Egy reggel a napi költség megháromszorozódott. A naplókból kiderült, hogy egy kliens belépett egy hurokba, és ugyanazt a kérést több ezer alkalommal küldte el. Hozzáadták a kvótát és a duplikáció megszüntetését; A probléma órákon belül megoldódott. Nyomon követés nélkül a számla meglepetés lenne a hónap végén.

3. eset – A korlát elfogadása. Egy egészségügyi startup azt tervezte, hogy teljesen automatikusan elkészíti a diagnózist, és megmutatja a páciensnek. Egy etikai és felelősségi felülvizsgálat során úgy döntöttek, hogy ez nem megengedett: a modell csak összegzést és lehetséges pontokat ad az orvosnak, az orvos állítja fel a diagnózist. A munka nem automatizálása szintén kiforrott tervezési döntés.

Gyakori hibák

• Érvényesítés átugrása: A kimenet vakon történő alkalmazása, mondván: "Jó a modell".
• Nagy hatású döntések automatizálása: Az emberi jóváhagyás elengedhetetlen a pénzben/egészségügyben/jogban.
• Nem figyelik: A költség- és minőségi problémákat későn fedezik fel.
• Érzékeny adatok írása naplókba: Adatvédelem megsértése; Mentse el maszkolással.
• Nem próbál a forrásra hagyatkozni: A modell azt alkothatja, ami nem szerepel a dokumentumban.
• Korlátok figyelmen kívül hagyása: Egyes feladatok nem automatizálása a helyes döntés; Az átláthatóság és a felelősség a tiéd.

Mélyebb: kiadáskezelés, visszagörgetés és növekményes üzembe helyezés

Egy LLM-funkció gyártásba vétele nem azt jelenti, hogy beállítjuk és elfelejtjük; az élő rendszer biztonságos módosítása idővel. Három pillére van.

Verziószámítás. A rendszerkérdések, a modellválasztás és az ellenőrzési szabályok idővel változnak. Verzió minden jelentős változást, és rögzítse, hogy melyik verzió él. Ha egy napon a minőség romlik, "min változtattunk?" Perceken belül válaszolnia kell a kérdésre. Egy verzió nélküli rendszerben a regresszió kiváltó okának megtalálása napokig tart.

Visszagörgetés. Ha egy új prompt vagy modell a vártnál rosszabbul viselkedik élőben, akkor gyorsan vissza kell tudni térni az előző, jól ismert verzióhoz. A visszavonási terv nélküli változtatás vakon vállalja az élő kockázatot. „Változtattam valamit, elromlott, nem tudok visszamenni” – ez a legdrágább gyártási forgatókönyv.

Fokozatos bevezetés. Ahelyett, hogy az összes forgalomra egyszerre alkalmazná a módosítást, először kis százalékra (pl. 5%) tegye közzé, és figyelje a mutatókat (minőség, költség, hibák). Ha jó, növeli a százalékot; Ha rossz, akkor csak egy kis részt érintve kapja vissza. Ez nagymértékben korlátozza a kockázatot.

Ez a három gyakorlat ötvözi az összes korábbi egység technikáját: az eval (5. egység) előre méri a változást, a monitorozás (ez az egység) korai figyelmeztetést ad a terjedés során, az ellenőrző réteg elkapja a hibás kimeneteket, mielőtt azok végrehajthatóvá válnának. A gyártás nem egyetlen helyes beállítás; Ez egy folyamatos fegyelem, amely mér, figyel és magabiztosan változtathat. Az egész modul az Ön számára való ennek a tudományágnak a kialakítására.

Összefoglalva

A gyártás több, mint egy működő demó: beviteli, modellezési, ellenőrzési, műveleti és megfigyelési rétegekből álló folyamat. A kimenet ellenőrzés nélkül megbízhatatlan; a nagy hatású döntések emberi jóváhagyáshoz kötöttek; Minden hívást ellenőriznek a költségek, a hibák és a minőség szempontjából. Az etika, az átláthatóság, az elfogultság ellenőrzése, az elszámoltathatóság és a korlátok elfogadása a technikai döntések szerves részét képezik. Minden, ebben a modulban tanult darab ebben a holisztikus kialakításban egyesül.

Pályázati feladat

Tervezzen teljes körű LLM-funkciót. (1) Töltse ki az öt réteget (bemenet, modell, ellenőrzés, művelet, megfigyelés) az adott feladathoz. (2) Jelölje meg hatás szerint, hogy mely döntésekhez van szükség emberi jóváhagyásra. (3) Írjon legalább három érvényesítési ellenőrzést (séma, szabály, forrás). (4) Határozza meg azokat a kulcsfontosságú mutatókat, amelyeket követni fog, és melyeket nem naplóz. (5) Írjon egy korlátot és egy etikai elvet, amelyet elfogad ebben a funkcióban.

ellenőrző lista

• [ ] A gyártócső öt rétegét tudom megtervezni.
• [ ] Érvényesíthetem a kimenetet séma, szabály és forrás alapján.
• [ ] A döntés hatása alapján beállíthatok emberi jóváhagyási küszöböt.
• [ ] Figyelem a költségeket, a hibákat és a minőséget, és gyakorolom, hogy ne írjak érzékeny adatokat a naplókba.
• [ ] Az etikát, a felelősséget és a határokat termelési döntésekké tudom alakítani.

Modul vizsga

1. Mit csinál a „rendszer” szerepkör egy LLM chat API-ban?

• A) Állandó utasításokat és viselkedési szabályokat ad a modellnek, amelyek a teljes beszélgetés során érvényesek ✔
• B) Megtartja a felhasználó által írt utolsó kérdést
• C) Tárolja a modell által generált választ
• D) Titkosítja az API kulcsot

Leírás: A rendszerszerep a modellnek állandó utasításokat, személyiséget és szabályokat ad, amelyek a teljes beszélgetés során érvényesek; Ez egy magas szintű átirányítás, különálló a felhasználói üzenetektől.

2. Miért küldik el újra a beszélgetési előzményeket (korábbi üzeneteket) minden API-kérésben?

• A) Szükség van biztonsági mentésre, mivel a szerver törli az előzményeket
• B) az API-hívások állapot nélküliek; ✔ A rendszer minden kérésnél újraküldi a kontextust, mert a modell nem emlékszik az előzményekre
• C) Csak számlázáshoz szükséges, nincs hatással a modellre
• D) Az előzmények küldése kötelező, nehogy lelassuljon a válasz

Magyarázat: Az LLM API hívások állapot nélküliek; A modell nem emlékszik az előző körökre, így minden releváns előzményt visszaküld minden kérésre a kontextus megőrzése érdekében.

3. Mit jelent a „token” az LLM árképzésben?

• A) Az API-ba való bejelentkezéshez használt egyszeri jelszó
• B) Minden egyes kérelemre fizetett fix díj
• C) A legkisebb egység, amelyben a modell feldolgozza a szöveget; általában a ✔ szórésznek felel meg
• D) Olyan mértékegység, amely csak a kimenet hosszát méri

Leírás: A token a legkisebb egység, amelyben a modell szöveget dolgoz fel; Általában egy szó töredékének felel meg, és mind a bemeneti, mind a kimeneti díj a tokenek száma alapján történik.

4. Miért drágábbak a kimeneti tokenek, mint a bemeneti tokenek a legtöbb LLM szolgáltatónál?

• A) A kimeneti tokenek mindig hosszabbak, mint a bemeneti tokenek
• B) A bemeneti tokenek ingyenesek
• C) A kimeneti tokeneket kétszer küldik el az interneten keresztül
• D) Az egységköltség magasabb, mert a kimenet generálása további számításokat igényel minden token esetében ✔

Leírás: Mindegyik kimeneti token megköveteli a modelltől, hogy lépésről lépésre generáljon (számítást); Ez a termelési költség magasabb, mint az input egyszerre történő feldolgozása, így a kibocsátási egységár általában magasabb.

5. Milyen helyzetben a legelőnyösebb a streaming használata?

• A) Hosszú válaszokban; Csökkenti az észlelt késést és megakadályozza az időtúllépést ✔
• B) Csak nagyon rövid, egyszavas válaszokban
• C) A költségek nullára csökkentése
• D) Az API kulcs elrejtése

Leírás: Hosszú válaszok esetén a streamelés csökkenti az észlelt késleltetést azáltal, hogy azonnal megjelennek az első szavak, és megakadályozza a HTTP időtúllépést nagy max_tokens értékeknél.

6. Mit befolyásol általában az „erõfeszítés” paraméter növelése a modern modellekben?

• A) Mindig rövidítse le a választ
• B) Automatikusan elforgatja az API kulcsot
• C) Csak a bemeneti token árát csökkenti
• D) Növeli a gondolkodási mélységet és a jelképes kiadásokat; Javíthatja a minőséget, de növeli a késleltetést és a költségeket is ✔

Leírás: Az erőfeszítés paraméter beállítja, hogy a modell milyen mélyen gondolkodjon egy feladaton, és hány tokent költ el; A frissítés javíthatja a minőséget, de növeli a késleltetést és a költségeket is. Egyszerű feladatokhoz kis erőfeszítés is elegendő.

7. Általában mi a legköltséghatékonyabb módja egy egyszerű, nagy volumenű osztályozási feladatnak?

• A) Mindig a legdrágább és legerősebb modellt használja
• B) Az összes modell egyidejű hívása minden kérés esetén
• C) A feladatot teljesítő legkönnyebb/legolcsóbb modell kiválasztása egy kis eval ellenőrzéssel ✔
• D) a max_tokens értéket szükségtelenül túl magasan tartani

Magyarázat: Ha a feladat nem bonyolult, akkor a legdrágább és legerősebb modell helyett egy gyorsabb és olcsóbb, a feladatot könnyen teljesítő modell kiválasztása (pl. Haiku osztály) jelentősen csökkenti a költségeket.

8. Melyik forgatókönyv szerint csökkenti leginkább a költségeket az azonnali gyorsítótárazás?

• A) Ha egy nagy és rögzített kontextust ismételten használnak sok kérés során ✔
• B) Amikor minden kéréssel teljesen más szöveget küldenek
• C) Ha csak egyetlen kérés érkezik
• D) A kimeneti tokenek csökkentése

Leírás: A gyorsítótárazás egy előtagegyezés; Azokban az esetekben, amikor egy nagy, változtathatatlan kontextus (rendszerprompt, dokumentumok) sok kérésben újrafelhasználásra kerül, a gyorsítótárból történő olvasás a teljes ár kis töredéke (~0,1x).

9. Hogyan szerkeszthetem a promptot, hogy a gyorsítótár elérje?

• A) Változó tartalom elhelyezése az elejére és rögzített tartalom a végére
• B) Minden kérésnél ágyazza be az aktuális dátumot és időt a rendszerpromptba
• C) Rögzített tartalom (rendszerprompt, dokumentumok) elejére és változó tartalom a végére ✔
• D) Az eszközlista sorrendjének módosítása minden kéréssel

Magyarázat: Mivel a gyorsítótár egy előtagegyezés, a rögzített/változatlan tartalom (rendszerprompt, dokumentumok) inicializálásra kerül; változó tartalom (dátum, felhasználói kérdés, kérésazonosító) a végére kerül. Még az elején megváltoztatott egyetlen bájt is érvényteleníti a gyorsítótárat.

10. Milyen típusú munkaterhelésre a legalkalmasabb a kötegelt feldolgozás?

• A) Élő csevegés, ahol a felhasználó azonnali választ vár a képernyőn
• B) Csak egy rövid kérdés
• C) API kulcs generálása
• D) Késéstűrő, nagy volumenű és azonnali eredményt nem igénylő munkák ✔

Leírás: A kötegelt feldolgozás alkalmas nagy mennyiségű munkára, amely nem igényel azonnali választ és tűri a késést; az eredményeket bizonyos idő elteltével szállítják, de az egységköltség általában alacsonyabb.

11. Mit használnak annak megbízható párosítására, hogy az eredmények egy kötegben melyik kéréshez tartoznak?

• A) A kérések küldési sorrendje (pozíciója).
• B) A válaszok hossza
• C) Az API kulcs utolsó 4 számjegye
• D) Minden kéréshez egyedi custom_id ✔

Megjegyzés: A tömeges eredmények a benyújtási sorrendtől eltérő sorrendben küldhetők vissza; ezért az eredményeket ID, nem pedig hely alapján kell egyeztetni az egyes kérésekhez adott egyedi custom_id-vel.

12. Mi a javasolt viselkedés, ha 429-es (sebességkorlát) hibaüzenetet kap az API-tól?

• A) Kényszerítés sok több kérés egyidejű elküldésével
• B) Újrapróbálkozás exponenciális visszalépéssel, a ✔ újrapróbálkozás után címsort követve
• C) Törölje a kérést teljesen, és mutassa meg a hibát összeomlásként a felhasználónak
• D) Az API kulcs megváltoztatása

Magyarázat: A 429 újrapróbálható hiba; A helyes megközelítés az, ha újra próbálkozunk exponenciális visszalépéssel, az újrapróbálkozás utáni fejléc tiszteletben tartása mellett. A legtöbb hivatalos SDK ezt automatikusan megteszi.

13. Az alábbi HTTP-hibakódok közül melyik tekinthető újrapróbálhatónak?

• A) 400 (érvénytelen kérelem)
• B) 401 (hitelesítési hiba)
• C) 529 (a szerver túlterhelt) ✔
• D) 404 (nem található)

Magyarázat: A 429 (sebességkorlátozás), az 500 (szerverhiba) és az 529 (túlterhelés) átmeneti hibák, és visszalépéssel újra megpróbálhatók. Az olyan hibák, mint a 400-as és 401-es, kérés/identitásproblémák; Újbóli próbálkozás nem oldja meg.

14. Az alábbiak közül melyik a biztonságos módja az API-kulcsok kezelésének?

• A) Környezeti változó/rejtett kezelő tárolása, kódba nem ágyazása és rendszeres forgatása ✔
• B) Írja be a kulcsot közvetlenül a forráskódba, és küldje el a tárolóba
• C) A kulcs elhelyezése a kliens oldali (böngésző) JavaScriptben
• D) Egyetlen kulcs megosztása az egész csapattal e-mailben

Leírás: A kulcsok soha nem íródnak a forráskódba vagy a tárolóba; Környezeti változóban vagy rejtett kezelőeszközben tárolják, minimális jogosultságokkal, és rendszeresen forgatják.

15. Mi a legjobb megközelítés az LLM-integrációhoz automatizálási eszközzel (n8n, Zapier, Make) az adatvédelem szempontjából?

• A) Minden nyers adat elküldése a modellnek, még akkor is, ha nem szükséges
• B) Az API-kulcs beírása egyszerű szöveggel a folyamatlépésben
• C) Az érzékeny adatok minimalizálása és maszkolása, valamint a kulcs titkos hitelesítő adatokként való tárolása ✔
• D) A személyes adatok állandó megőrzése az áramlási előzményekben

Leírás: Mivel az automatizálásba belépő adatok harmadik féltől származó rendszereken és modelleken haladnak át, az érzékeny/személyes adatokat minimalizálni kell, el kell takarni, és csak a kötelező mezőket kell elküldeni; Az API-kulcs titkos hitelesítő adatokként is tárolódik az eszközben.

16. Miért kötelező a kimenet érvényesítése egy LLM alapú termelési szolgáltatásban?

• A) Csak formázásra van szükség, mert a modell soha nem hibázik
• B) Mert a modell folyékonyan, de néha hibásan tud produkálni; A sémát/szabályt erőforrás- és emberi jóváhagyással kell auditálni ✔
• C) Az érvényesítést kerülni kell, mert az csak növeli a költségeket
• D) Az ellenőrzés csak a tokenek számának csökkentésére szolgál

Leírás: Az LLM-ek folyékony, de néha pontatlan (hallucinációs) kimenetet produkálhatnak; tehát nagy hatású döntésekben jelent meg; Sémák/szabályok ellenőrzésével, forrásellenőrzésével és szükség esetén emberi jóváhagyással kell auditálni.