Mi az LLMOps és miben más
Az LLMOps a nyelvi modellre épülő rendszerek üzemeltetésének fegyelme, a klasszikus DevOps és MLOps gondolkodás nyelvi modellre szabott folytatása. Ugyanazok az alapelvek érvényesek, tehát a reprodukálhatóság, a verziózás, az automatizált bevezetés és a folyamatos megfigyelés, de a nyelvi modell néhány ponton új problémát ad hozzájuk. Az első, hogy a rendszer nem determinista, így egy változtatás hatása nem jelezhető előre biztosan, csak méréssel. A második, hogy a viselkedést nem csak a kód határozza meg, hanem a prompt, a visszakeresési index és maga a modell is, amelyek külön életet élnek. A harmadik, hogy a modellt gyakran egy külső szolgáltató üzemelteti, tehát alattad is változhat anélkül, hogy hozzányúlnál. Az LLMOps ezekre a sajátosságokra ad rendszerezett választ, hogy a rendszer idővel ne lassan romoljon, hanem mérhetően, kézben tartva fejlődjön.
Az életciklus egy zárt hurok
A rendszer élete nem egyenes vonal, hanem ismétlődő hurok. Fejlesztéssel kezdődik, ahol a promptot, a RAG-ot és a logikát alakítod. Ezt követi a kiértékelés, ahol a hatodik leckében tárgyalt evalokkal ellenőrzöd, hogy a változás valóban javított. Ha átment, jön a bevezetés, ám nem egy lépésben, hanem fokozatosan. Élesben a megfigyelés következik, ahol a valós forgalmat méred, gyűjtöd a jelzéseket és a hibás eseteket. A megfigyelésből származó tanulság visszatáplálódik a fejlesztésbe, és a hurok újraindul. Ennek a huroknak az a lényege, hogy soha nincs kész állapot. Minden éles rendszer folyamatos karbantartást kíván, mert körülötte a világ, a felhasználói igény, az adat és a modell is változik. Az LLMOps ezt a hurkot teszi rendszeressé, mérhetővé és biztonságossá, ahelyett hogy ad hoc javítgatás lenne.
Verziózni kell mindent, nemcsak a kódot
A klasszikus szoftvernél a kód verziózása elég a reprodukálhatósághoz. Egy LLM rendszernél ez kevés, mert a viselkedést négy külön dolog együtt határozza meg, és bármelyik változása megváltoztatja a kimenetet. Verziózni kell a promptot, mert egyetlen szó módosítása is elmozdíthatja a viselkedést. Verziózni kell a modellt, tehát pontosan rögzíteni, melyik modell melyik változatát hívod. Verziózni kell a visszakeresési adatot és az indexet, mert a RAG kimenete attól is függ, mi van benne és hogyan van feldarabolva. Végül verziózni kell magát a kiértékelő készletet, különben nem tudod összevetni a régi és az új eredményt azonos alapon. A cél a reprodukálhatóság, tehát hogy egy éles viselkedést vissza tudj fejteni arra a pontos kombinációra, amely előállította. E nélkül minden hibakeresés találgatás, mert nem tudod, melyik összetevő melyik állapotában futott a rendszer.
Fokozatos bevezetés és visszagörgetés
Mivel a változás hatása nem jelezhető előre biztosan, éles rendszerbe soha nem egy lépésben vezetünk be. Több bevált fokozat van. Az árnyékbevezetésnél (shadow deployment) az új változat a valós forgalmon fut, de a válasza nem jut el a felhasználóhoz, csak összeveted a régivel, így kockázat nélkül mérsz éles bemeneten. A kanárikiadásnál (canary release) az új változatot előbb csak a forgalom kis részének adod, figyeled a mérőszámokat, és csak fokozatosan növeled az arányt. Az A/B teszt két változatot futtat párhuzamosan, hogy a valós hatásukat összevesd. Mindezek közös feltétele a visszagörgetés (rollback) lehetősége. Egy prompt vagy modellcsere ugyanolyan bevezetés, mint egy kódmódosítás, tehát reverzibilisnek kell lennie, az előző változatnak készen kell állnia, hogy baj esetén másodpercek alatt visszaállíthasd. Az a mérnöki fegyelem, hogy minden éles változtatáshoz eleve hozzátartozik a visszaút terve, választja el a stabil rendszert a törékenytől.
- ÁrnyékbevezetésAz új változat éles forgalmon fut, de a válasza nem jut a felhasználóhoz, csak mérsz.
- KanárikiadásElőbb a forgalom kis részének adod, majd a mérőszámok alapján fokozatosan növeled.
- Teljes bevezetésHa a jelzések stabilak, a teljes forgalomra kiterjeszted.
- Visszagörgetés készenAz előző változat elérhető marad, hogy baj esetén azonnal visszaállíthasd.
Monitoring, sodródás és a modell csendes változása
Az éles megfigyelés két rétegből áll. Az egyik a rendszeroldali mérőszámok folyamatos figyelése, tehát a késleltetés, a költség, a hibaarány és a modell által megtagadott válaszok aránya. A másik, nehezebb réteg a minőség figyelése, amelyhez a hatodik leckében tárgyalt online eval, a felhasználói visszajelzés és a rögzített nyomvonalak adják az alapot. Két lassú veszélyre kell külön figyelni. Az egyik a sodródás (drift), amikor a valós forgalom eloszlása fokozatosan eltér attól, amire a rendszert hangoltad, például új témák, új nyelvhasználat vagy megváltozott felhasználói szokások miatt, és a minőség lassan, észrevétlenül romlik. A másik, az LLM rendszerekre jellemző veszély, hogy a modell alattad változik. Ha egy külső szolgáltató frissíti a modellt, a viselkedés megváltozhat anélkül, hogy egy sort is módosítanál. A védekezés, hogy ahol lehet, rögzített modellváltozatra kötsz, és minden modellfrissítésnél újrafuttatod a teljes kiértékelő készletet, mielőtt átengeded élesbe. Így a csendes változás sem tud észrevétlenül rontani a rendszereden.
A kiértékelés mint bevezetési kapu
Az eddigi elemek egyetlen gyakorlatban állnak össze, amely az egész LLMOps gerincét adja. A kiértékelő készletet be kell építeni a bevezetési folyamatba mint kaput, amelyen egyetlen változtatás sem jut túl automatikus, sikeres eval nélkül. Ez ugyanaz a gondolat, mint a hagyományos szoftver folyamatos integrációjában a tesztek futtatása, csak itt az eval a teszt. Egy promptmódosítás vagy egy modellcsere így nem érzésre kerül élesbe, hanem csak akkor, ha a mérés igazolta, hogy nem rontott. A visszatáplált éles hibák pedig új eseteket adnak a készlethez, ami idővel egyre erősebb védőhálót épít. Ettől lesz a rendszer fejlődése kumulatív, mert minden megoldott hiba tartósan bekerül a védelembe, és a régi bajok nem térnek vissza csendben egy későbbi módosítással.
Két állítás, amit érdemes megjegyezni. Az első, hogy egy LLM rendszernél a prompt, a modell, az index és az eval mind verziózandó műtermék, nem csak a kód, különben nincs reprodukálhatóság. A második, hogy a modell alattad is változhat, ezért rögzített változatra köss, és minden frissítésnél futtasd újra a teljes kiértékelő készletet, mielőtt élesbe engeded.
Workshop
AI Transformation Day
Egésznapos, vezetőknek szóló program. Feltérképezzük, hol tart a szervezet, mi az első reális lépés, és milyen belső feltételek szükségesek a sikerhez. A nap végén konkrét, prioritizált cselekvési lista.
Érdekel a program →