Mit jelent a megoldásarchitektúra
A megoldásarchitektúra (solution architecture) az a terv, amely megmondja, milyen részekből áll az éles rendszer, hogyan kapcsolódnak egymáshoz, hol futnak, és ki fér hozzájuk. Egy LLM megoldás a demóban gyakran egyetlen modellhívásnak látszik. Élesben szinte soha nem az. A valóságban több komponens áll össze egy rendszerré, és a minőség, a késleltetés, a költség és a biztonság ennek az egésznek a tulajdonsága, nem egyetlen modellé. Az FDE dolga, hogy ezt a rendszert ne egy általános referenciából másolja át, hanem az adott ügyfél adataira, rendszereire és korlátaira szabja.
Ez a szemlélet a szerep magjából következik. Az FDE egy ügyfélre koncentrál sok képességgel, ezért az architektúra nem egy termék általános vázlata, hanem egy konkrét szervezet konkrét munkafolyamatára formált megoldás. A tervezés így mindig két kérdésre felel egyszerre. Az egyik, hogy technikailag mi a helyes felépítés. A másik, hogy ez a felépítés elfér-e az ügyfél valós környezetében, a rendszerei, a szabályai és a jogosultsági határai között.
A fő komponensek
Egy tipikus éles LLM megoldás néhány jól elkülönülő rétegből áll. Az első az adatforrások réteg, vagyis azok az adatbázisok, fájlok és API-k, amelyekben az üzletileg kritikus tudás él. A második a visszakeresés (retrieval), amely a kérdéshez tartozó releváns tartalmat emeli ki a nagy adathalmazból, hogy az a modell elé kerülhessen. A harmadik maga az LLM hívás, ahol a modell a kontextus alapján választ, elemez vagy döntést készít elő. A negyedik az orkesztráció és az ügynökök (agents) rétege, amely több lépést, több hívást és külső eszközök meghívását fűzi össze egy folyamattá. Az ötödik az alkalmazás vagy felület, ahol a végfelhasználó ténylegesen találkozik a megoldással.
Ezeken keresztülfekszik egy hatodik réteg, a hitelesítés és jogosultság (auth). Ez nem a folyamat egy állomása, hanem minden réteget átfog. Meghatározza, hogy egy adott felhasználó vagy szolgáltatás pontosan mihez férhet hozzá, és hogy a rendszer sosem lát vagy ad ki olyan adatot, amelyhez a hívó félnek nincs joga. Éles vállalati környezetben ez a réteg dönti el, hogy a megoldás egyáltalán bevezethető-e.
Az ügyfél infrastruktúráján, az ügyfél eszközeivel
A hagyományos Solutions Architect jellemzően offline, anonimizált adaton épít proof of conceptet, majd átadja a megvalósítást. Az FDE ezzel szemben közvetlenül az ügyfél infrastruktúráján, az ügyfél eszközeivel ír kódot. Ez nem apró különbség, hanem az architektúra minden rétegét érinti. A bevezetési topológia (deployment topology) azt írja le, hol fut valójában az egyes komponens. Az adat sokszor nem hagyhatja el az ügyfél saját felhőkörnyezetét vagy adatközpontját, ezért a visszakeresés és az orkesztráció is oda kerül, a modellhívás pedig egy jóváhagyott, elszigetelt csatornán megy.
Ebből a helyzetből fakad a szerep egyik nehézsége. A mérnök nem a saját, jól ismert fejlesztői környezetében dolgozik, hanem az ügyfélében, annak eszközlánca, jogosultsági rendszere és korlátai mellett. Ami a demóban egy vonalnyi kód volt, az élesben egy integrációs feladat, amelyet az ügyfél rendszereinek határai szabnak meg. Az architektúra ezért nemcsak azt írja le, mi a helyes felépítés elvben, hanem azt is, mi valósítható meg ebben a konkrét környezetben.
Biztonság és jogosultság
Vállalati és különösen szabályozott iparágakban (regulated industries), például a pénzügyben, az egészségügyben, a jogban és a közigazgatásban, a biztonság nem utólag ráhúzott réteg, hanem az architektúra kiindulópontja. Több elv fut itt párhuzamosan. Az adatlokáció (data residency) azt szabja meg, földrajzilag és jogilag hol tárolható és dolgozható fel az adat. A hozzáférés vezérlés (access control) azt írja le, ki és mi léphet be az egyes komponensekbe. A legkisebb jogosultság elve (least privilege) pedig azt mondja ki, hogy minden felhasználó és minden szolgáltatás pontosan annyi jogot kapjon, amennyi a feladatához feltétlenül kell, se többet.
Ezek az elvek közvetlenül alakítják a tervet. A visszakeresésnek tiszteletben kell tartania a forrásrendszer jogosultságait, hogy a modell elé sose kerüljön olyan tartalom, amelyet a felhasználó amúgy nem láthatna. Az ügynökök eszközhasználatát szűk, ellenőrzött körre kell zárni. A naplózásnak követhetővé kell tennie, ki mit kérdezett és milyen adat alapján született a válasz. Aki ezeket a döntéseket az építés végére hagyja, az rendszerint újratervezésre kényszerül, mert a biztonsági korlát az egész topológiát átrendezheti.
Naiv architektúra
- Egyetlen modellhívás köré húzott vékony felület
- A jogosultság csak a felületen, nem az adat szintjén
- Az adat kimásolva, az ügyfél környezetén kívül
- Nincs napló, nincs nyomon követhető döntés
- A minőség egyetlen prompton múlik
Robusztus architektúra
- Elkülönült adat, visszakeresés, modell és orkesztráció
- A jogosultság a forrásadat szintjén érvényesül
- Az adat az ügyfél infrastruktúráján marad
- Teljes naplózás és követhető döntési út
- A minőséget evalok és visszakeresés együtt tartja
A fő kompromisszumok
Az architektúra jó része tudatos kompromisszum, nem egyetlen helyes válasz. Az első nagy döntés, hogy a platform beépített primitíveit használjuk, vagy saját komponenst építünk. A platform primitívjei gyorsabban visznek éles működésig és kevesebb karbantartást igényelnek, a saját építés viszont több kontrollt ad a különleges igényekre. A jó FDE alapból a platform képességeire támaszkodik, és csak ott épít sajátot, ahol az ügyfél valós igénye ezt indokolja.
A második a késleltetés és a minőség viszonya. Több visszakeresési lépés, több modellhívás vagy egy ügynöki lánc jobb választ adhat, de lassabb és drágább. A harmadik a költség, amely az egész rendszer mérete, a hívások száma és a választott modell függvénye. Ezek a szempontok összefüggenek. Egy erősebb modell javíthatja a minőséget, de növeli a késleltetést és a költséget, egy szűkített visszakeresés csökkenti a költséget, de ronthatja a pontosságot. Az architektúra épp ezeknek a szempontoknak a tudatos súlyozása az ügyfél tényleges prioritásai szerint.
Az FDE mint az architektúra kapcsolattartója
Az architektúra nem születhet meg zárt ajtók mögött. Az FDE az account elsődleges technikai kapcsolattartója, aki az architektúra kérdéseket kezeli az ügyfél mérnöki és szakmai csapataival, a technikai szereplőktől a vezetőkig. Ő fordítja le az ügyfél biztonsági és üzemeltetési elvárásait konkrét tervvé, és ő magyarázza el, miért így épül fel a rendszer. Amikor egy éles hiba felmerül, szintén ő debugolja, és ő igazítja a konfigurációt a valós teljesítményigényhez.
Ebből fakad, hogy a jó architektúra egyszerre technikai és kapcsolati termék. A terv akkor áll meg, ha az ügyfél csapata érti és elfogadja, mert nekik kell vele együtt élniük az éles működésben. A következő leckében arra a rétegre nézünk közelebbről, amely nélkül ez az egész felépítés üres marad, az adatintegrációra és a pipeline-okra az ügyfélnél.
Hat réteg, egy rendszer. Az adatforrások, a visszakeresés, az LLM hívás, az orkesztráció, az alkalmazás és az auth együtt adja az eredményt. A minőség, a késleltetés, a költség és a biztonság mind az egész rendszer tulajdonsága, ezért az FDE mindig a teljes architektúrában gondolkodik, nem egyetlen komponensben.
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 →