Ez egy folyamatban lévő sorozat része: lásd az első bejegyzést itt .
AI II. alapelv: Az üzenetek biztonságos betöltése (ha valóban muszáj)
Szeretné, hogy a chatbotja Taylor Swift dalszövegeiről kezdjen beszélni ahelyett, hogy technikai támogatást nyújtana? Ezt tette a chatbotunk, amikor megszegtük a fenti elvet. Ha szeretné de-Swift alkalmazását és biztonságosabbá tenni mesterséges intelligencia architektúráját, olvassa tovább. (Elnézést Taylor rajongóktól!)
Hol tárolja az utasításokat
Tárolja az utasításokat a kód többi részével? Vagy töltsd be őket más forrásból? Esetleg a kettő kombinációja? Az alábbiakban bemutatjuk a döntés kereteit.
A lehetőség – Üzenetek tárolása a Gitben
Az első kérdés, amelyet fel kell tennie: Van-e azonnali oka annak, hogy a promptokat a kódtól elkülönítve tárolja? Ha nem, hagyja az utasításokat a Gitben a kódbázis többi részével, ahová tartoznak. Ez messze a legegyszerűbb és legbiztonságosabb karbantartás. Ez az alapértelmezett beállítás.
Visszatérve az 1. alapelvhez: A promptok kódok . A kódbázis részeinek Git-en kívüli tárolása lehetséges és néha szükséges is, de nem triviális. Ne vedd könnyedén a költözésre vonatkozó döntést.
B lehetőség – Prompts betöltése a verzió által vezérelt platformról
Mi van, ha néhány promptot nem mérnököknek kell szerkeszteniük? Ez akkor fordulhat elő, ha egy adott területen mély tartományi szakértelemre van szükség. Vagy ha egy prompt nagyon gyakran kell módosítani, és nem tud várni a mérnöki osztályon.
Ebben az esetben a promptot futás közben kell betöltenie egy verzióvezérelt forrásból. Láttam, hogy a Confluence és a Google Docs sikeresen használható erre a célra. Számos más verzióvezérelt, API-hoz elérhető platform is elérhető.
Az azonnali betöltési logika tervezésekor ne becsülje alá az integráció hozzáadásával járó erőfeszítést. Számos hibaállapotot és forgatókönyvet kell kezelnie ahhoz, hogy megbízhasson az alkalmazásában. A hozzáférési jogosultságokat konfigurálni és karbantartani kell, az automatizált tesztelést és a további felügyeletet pedig ki kell terjeszteni a hibák mielőbbi észlelése érdekében.
Íme néhány forgatókönyv, amelyekre terveznie kell:
- Az alkalmazás nem tudja betölteni a promptokat futás közben. Megölöd a bevetést? Vált a prompt biztonsági másolatára?
- A felszólítás szintaxisa a módosítás után érvénytelenné válik, és használhatatlan adatstruktúrákat ad vissza. Az automatikus tesztek nem tudták észlelni a problémát, mert a tesztvégrehajtás során nem töltötték be a promptokat. Milyen további tesztelési infrastruktúrát és felügyeletet kell hozzáadni ennek észleléséhez és az ügyfelekre gyakorolt hatás minimalizálásához?
- A promptot sürgősen vissza kell görgetni. Ehhez új kód telepítése szükséges? Vagy épít egy külön felhasználói felületet az azonnali telepítéshez?
- Az olyan platformok, mint a Confluence, által a dokumentumhoz hozzáadott szintaxis beszivároghat a futásidejű promptba, ami negatívan befolyásolja annak teljesítményét. Ügyeljen arra, hogy szűrje ki a szennyeződést olyan eszközökkel, mint a Beautiful Soup.
Mindezek a problémák 100%-ban megoldhatók. De könnyen beleeshetünk abba a gondolkodásmódba, hogy a prompt betöltése egy Google-dokumentumból triviális művelet, amely nem befolyásolja mélyen az alkalmazás architektúráját. Amint fentebb bemutattam, a külső prompt betöltése komoly feladat, és a nagy megbízhatóságú alkalmazásokhoz óvatosan kell hozzáállni.
C lehetőség – Prompts betöltése nem verzió-vezérelt platformról
Ez egy rossz ötlet, és meg fogod bánni. A promptok igazságforrásának verzió-vezéreltnek kell lennie, megfelelő API-val és hozzáférés-vezérléssel kell rendelkeznie. Ez nem egy olyan terület, ahol le kell vágni.
D lehetőség – Hibrid megközelítés
A hibrid megközelítés egyesíti, hogy egyes promptokat közvetlenül a kódbázisban tárol, míg másokat külső, verzióvezérelt forrásokból tölt be. Noha az összes felszólítás egységes helyének fenntartása gyakran egyszerűbb és megbízhatóbb, vannak olyan forgatókönyvek, amikor a hibrid stratégia előnyöket kínálhat.
Fontolja meg a hibrid megközelítés alkalmazását az alábbi feltételek mellett:
- Vegyes használat : Egyes promptok gyakori frissítéseket igényelnek a nem kódoló tartomány szakértőitől, ami praktikussá teszi a külső betöltést, míg másokat csak a mérnökök módosítanak.
- Kockázatkezelés : A kritikus üzeneteknek (pl. védőkorlátoknak) a fő adattárban kell lenniük a maximális megbízhatóság érdekében. A kevésbé kritikus felszólítások, különösen azok, amelyek gyakran kiigazításon esnek át, biztonságosan élhetnek kívülről.
- Kiértékelési rugalmasság : Az ML-stílusú kiértékelésre szánt promptok külsőleg kezelhetők, hogy egyszerűsítsék az értékelési keretrendszerbe való integrációjukat.
Védőkorlátok
A Guardrail promptok (más néven cenzor promptok) arra specializálódtak, hogy még azelőtt kiszűrjék a válaszokat, hogy azok eljutnának a felhasználókhoz, biztosítva a megfelelő, biztonságos és megfelelő kimeneteket. A védőkorlátok védőmechanizmusként szolgálnak, különösen olyan alkalmazásokban, ahol a felhasználói interakciók jelentős jogi vagy etikai kockázatokkal járnak. Egy második védelmi vonalat biztosítanak, elkapják a nem megfelelő kimeneteket, amelyek átcsúsznak.
Ne töltsön be külső doksiktól származó védőkorlát-utasításokat – ez jelentős, szükségtelen kockázatot jelent. Vagy tartsa meg őket a Gitben a kódjával együtt, vagy használjon harmadik féltől származó eszközt, például a Fiddle Guardrails-t . A védőkorlát logikája nem változik túl gyakran, így ez a megközelítés nem lassítja le annyira.
A védőkorlátok használata saját elv, amelyet egy későbbi bejegyzésben részletesebben tárgyalunk. Ez egy nagyszerű minta, amely javítja az alkalmazás biztonságát, és segít jobban aludni éjszaka. Csak ne töltse be őket a Google Dokumentumokból.
Felszólítások betöltése a könnyebb kiértékelés érdekében
A csapatok gyakran külsőleg töltenek be promptokat, hogy integrálják azokat kiértékelő motorokkal, például az ML Flow-val . E gyakorlat mögött meghúzódó feltételezés az, hogy a promptok hasonlóak az ML modellekhez, és külön, statisztikai értékelést igényelnek. Csatlakoztat egy promptot, megméri az F1 pontszámot a kimeneten (vagy bármilyen más mérőszámot szeretne), és ismételget.
Ez a megközelítés néha érvényes – például az ML-modellként való viselkedésre tervezett besorolási promptoknál. De a legtöbb felszólítás alapvetően különbözik: amint azt az 1. alapelv vázolja: Az LLM-kérések kódok . A tipikus promptok jobban hasonlítanak az alkalmazáslogikához, mint az ML modellekhez. Alkalmasabbak Pass-Fail típusú kiértékelésre a környező kóddal együtt, nem pedig statisztikai értékelési megközelítésre.
A külső értékelő motorok nem segítenek a legtöbb felszólításban. Ehelyett automatizált AI-vezérelt teszteket kell használnia, hasonlóan a hagyományos egységtesztekhez. Ezek lesznek a következő bejegyzések középpontjában.
Fontolja meg a következő gyakorlatokat:
- Csak azokat a promptokat szabad külsőleg értékelni, amelyek funkcionalitása kifejezetten utánozza a gépi tanulási modelleket (pl. osztályozási vagy pontozási feladatok).
- Az üzleti logikai utasítások többségét a fő kódbázison belül tartsa fenn, az ML-ellenőrzési technikák helyett az egységteszthez hasonló hagyományos automatizált tesztelési módszereket alkalmazva.
- Ahol a külső értékelés indokolt, lehetőség szerint csak azokat a felszólításokat különítse el.
Esettanulmány
A betöltési promptok központi problémája a rendelkezésre állás – mi a teendő, ha a prompt nem töltődik be a várt időpontban.
Ez történt velünk a Taylor Swift példában. A Confluence hitelesítési adatokkal kapcsolatos probléma eredményeként betöltött műszaki támogatási alkalmazás egyik felszólítása sem, beleértve a védőkorlátot sem. Ez valahogy nem váltott ki futásidejű hibákat, és a bot minden utasítás vagy bevitel nélkül kezdett válaszolni (mivel a bemeneti formázási karakterlánc a prompt része volt). És mivel akar beszélni az OpenAI LLM-je a bemenet hiányában? Kiderült, hogy a Queen „I Want to Break Free” dalszövege és különböző Taylor Swift-dalok. Szerencsére ezt szinte azonnal elkapták és kijavították, a felhasználók pedig élvezték a zenei beszélgetést – legalábbis ezt mondom magamnak.
Miért történt ez az eset? Két hiba történt:
- A promptok sikeres betöltését nem ellenőrizték. Egy hibaüzenetnek kellett volna megjelennie azonnali betöltési időben, mivel az alkalmazás nem tud működni a betöltés nélkül.
- A védőkorlát-prompt kívülről be lett töltve a többi felszólítással. Ez az egyik prompt, amelyet nem szabad ilyen módon betölteni. A Gitben kellett volna tartani, mint az utolsó védelmi vonalat.
Az incidens után a védőkorlát promptot újra áttelepítették a Gitbe, és kivételi logikát adtak hozzá, hogy megakadályozzák a telepítést, ha egy prompt nem tölthető be vagy érvénytelen volt. Ha proaktívan követi ezeket az ajánlásokat, megkímélheti magát egy halálozás után.
Következtetés
Ebben a bejegyzésben megvizsgáltam az AI-alkalmazásokon belüli gyors tárolás és betöltés legfontosabb szempontjait. Az alapértelmezett gyakorlat az, hogy a promptokat a kód mellett verzióvezérelt tárolókban tárolja. Csak akkor térjen el ettől, ha annak nyomós oka van, mint például a nem mérnökök általi gyakori szerkesztés vagy speciális értékelési követelmények.
Ha a promptokat külsőleg kell betölteni, válasszon megbízható és szigorúan verzió-vezérelt forrásokat, és adjon hozzá tesztelést és figyelést a rugalmasság érdekében. Az alkalmazásbiztonságban betöltött kritikus szerepük miatt a Guardrail promptoknak a kódbázisban kell maradniuk a súlyos megbízhatósági kockázatok elkerülése érdekében.
A legtöbb prompt természetében közelebb áll a kódhoz, mint az ML-modellekhez, ezért csak ott használjon ML stílusú eszközöket, ahol szüksége van rájuk. Ne tárolja az összes felszólítását kívülről, csak azért, hogy leegyszerűsítse az integrációt néhány kiértékelő eszközzel.
Ha tetszett ez a bejegyzés, kövesd a sorozatot további információkért.
