A validált szelettől az éles rendszerig
Az előző szakaszban a mérnök egy szűk szeletet validált evalokkal, valós ügyféladaton. Ez a szelet a lehető legkisebb egység volt, amely mégis teljes, végponttól végpontig működő megoldás. Fontos látni, hogy ez a kész prototípus a bevezetés kiindulópontja, nem a végállomása. Az FDE feladata épp az, hogy a demóból élő, működő éles rendszert csináljon. A kettő között nagy a távolság. A prototípus egyetlen jól előkészített eseten megbízhatóan fut, az éles rendszernek viszont sok felhasználó sokféle, előre nem látott bemenetén, hosszú időn át, felügyelet mellett kell helytállnia.
Ezért a bevezetést nem egy nagy kapcsolóként kezeljük, amelyet egyszer felkattintunk. Szakaszokra bontjuk, és minden szakaszban tanulunk, mielőtt kiszélesítjük a kört. A cél az, hogy a kockázatot kicsi, kezelhető adagokban vegyük fel, ne az egész szervezetre egyszerre.
Deployability, mint tervezési szempont
A Palantir a szerep felelősségei között kifejezetten kiemeli az engineering review-t, a code review-t, a deployability optimalizálását, valamint az éles rendszerek karbantartását és monitorozását. Ez nem véletlen. Egy megoldás akkor telepíthető jól, ha nem egyetlen mérnök fejében él, hanem reprodukálhatóan feláll. A konfiguráció el van választva a kódtól, a titkok nem a forrásban ülnek, a telepítés ismételhető, és a rendszer az első perctől kezdve megfigyelhető. Ha ezt a bevezetés végére hagyjuk, a skálázás fájdalmas lesz.
Az AI megoldásoknál a megfigyelhetőség (observability) nem korlátozódik a szokásos infrastruktúra metrikákra. Látni akarjuk, milyen bemenetek érkeznek, milyen promptok mennek a modellhez, mennyi tokent használunk, mekkora a késleltetés, és hol romlik a minőség. Enélkül egy éles hibát nem lehet reprodukálni, márpedig az account elsődleges technikai kapcsolattartójaként az FDE-nek épp az éles hibák debugolása a dolga.
- Pilot indításaSzűk, együttműködő felhasználói kör, szoros felügyelet, gyors javítási hurok a valós használat alapján.
- Mérés és tanulásA pilot alatt gyűjtött hibák és eval eredmények visszafolynak a megoldásba, mielőtt bárkinek kiszélesítenénk.
- KiszélesítésA kör tágabb csapatokra nyílik, itt derül ki, mennyire terhelhető a rendszer és hogyan viselkedik idegen bemeneteken.
- Teljes rolloutA teljes felhasználói kör átáll, a súlypont a folyamatos monitorozásra és a stabil üzemre helyeződik.
- FenntartásKarbantartás, riasztások, rendszeres felülvizsgálat, hogy a megoldás a valós használatban is megbízható maradjon.
Megbízhatóság, késleltetés és költség a skálán
Ami egyetlen pilot felhasználónál elfogadható, az száz felhasználónál könnyen elromlik. Három tengelyen kell egyszerre gondolkodni. Az első a megbízhatóság. Az Anthropic magas biztonsági és megbízhatósági (safety and reliability) elvárásokat támaszt az éles alkalmazásokkal szemben, és ez az elvárás a skálázással csak szigorodik. A modell néha rossz vagy hiányos választ ad, a külső rendszerek időnként nem válaszolnak, ezért a megoldásnak hibatűrőnek kell lennie. Kellenek újrapróbálkozások, tartalék útvonalak (fallback), és olyan viselkedés, amely hiba esetén sem omlik össze, hanem kontrollált módon degradálódik.
A második tengely a késleltetés. Egy demóban a néhány másodperces válaszidő nem zavaró, éles munkafolyamatban viszont az egész bevezetést megbuktathatja. A harmadik a költség. Minden hívásnak ára van, és ami egy felhasználónál elhanyagolható, az a teljes szervezetnél komoly tétel. Itt lép be az a feladat, amelyet az OpenAI is kiemel, a modell konfigurációjának a valós teljesítményigényekhez igazítása. A megfelelő modellméret megválasztása, a felesleges hívások kiszűrése és a bemenetek okos kezelése együtt dönti el, hogy a megoldás skálán is fenntartható marad-e.
Az alábbi ábra sematikus. Nem mért adatot mutat, hanem azt az elvi mintát, ahogyan az éles adoptáció szakaszról szakaszra épül fel.
Változáskezelés, nem csak technikai kérdés
A skálázás legkeményebb része sokszor nem a kód. Az éles adoptáció (production adoption) azt jelenti, hogy a felhasználók tényleg beépítik a megoldást a napi munkájukba, és ehhez meg kell változtatniuk a megszokott folyamataikat. Ez a változáskezelés (change management) terepe. Ha a mérnök figyelmen kívül hagyja, a rendszer technikailag működhet, mégsem használja senki. Ezért a bevezetés részét képezi a betanítás, a világos dokumentáció, és a korai felhasználók bevonása, akik hitelesen tudják közvetíteni a többiek felé, mire jó az eszköz.
Ehhez kapcsolódik a hatás mérése. A siker mércéje ebben a szerepben nem az, hogy elkészült-e a rendszer, hanem az éles adoptáció és a mérhető munkafolyamat hatás. Ezt előre definiált sikerkritériumokhoz kötjük, és a bevezetés alatt folyamatosan visszamérjük. Ha a mért hatás elmarad a várttól, az nem kudarc, hanem jelzés, hogy a megoldáson vagy a folyamaton még igazítani kell.
Három tengely a skálán. A megbízhatóság, a késleltetés és a költség együtt mozog. Egy dimenzió javítása gyakran a másik kettő rovására megy, ezért a skálázás mindig kompromisszumok tudatos meghozása, nem egyetlen szám optimalizálása.
Hosszú távú felelősség és átadás
Az éles rendszer nem a bevezetés végén ér véget, hanem ott kezdi az életét. A Palantir modelljében a mérnök felel az éles rendszerek karbantartásáért és monitorozásáért, ami folyamatos jelenlétet feltételez. A gyakorlatban két végállapot felé haladhat a megbízás. Az egyikben a mérnök hosszabb távon is birtokolja a rendszert, figyeli a metrikákat, kezeli a riasztásokat, és a valós használat alapján fejleszti tovább. A másikban a felelősség átadásra kerül az ügyfél saját csapatának, dokumentációval, üzemeltetési leírásokkal (runbook) és betanítással megtámogatva.
Bármelyik felé haladunk, az átadhatóságot már a tervezéskor beépítjük. Egy megoldás, amelyet csak az eredeti mérnök ért, éles környezetben kockázat. Ezért a jó FDE úgy dolgozik, hogy a rendszer túléli a saját jelenlétét. Ez a szemlélet vezet át a következő leckéhez, ahol azt nézzük meg, hogyan kommunikál a mérnök a szervezet minden szintjével, a technikai csapatoktól a vezetőkig, hogy a bevezetés ne csak technikailag, hanem emberileg is sikerüljön.
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 →