Az orchestration réteg és a saját framework csapdája

Mi az orchestration réteg

A modern AI alkalmazások ritkán állnak egyetlen modellhívásból. Egy tipikus kérdés megválaszolásához több lépés kell. Előbb értelmezni kell a felhasználó kérését, utána le kell kérdezni hozzá a releváns adatot a vektoradatbázisból, esetleg meg kell hívni egy külső API-t vagy egy segédeszközt, majd mindebből a modellnek választ kell generálnia, és lehet, hogy az egészet több körben. Valakinek el kell döntenie, mi legyen a következő lépés, milyen sorrendben fussanak a hívások, pontosan mit adunk át a modellnek, és mikor állunk meg. Ez a döntéslogika az orchestration réteg.

Fontos látni, hogy ez egy önálló réteg, nem maga a modell és nem az adatbázis. A modell szöveget generál, a vektoradatbázis adatot ad vissza, az eszközök egy-egy műveletet végeznek el. Az orchestration réteg az, amely ezeket a darabokat a helyes sorrendbe fűzi, átadja egymásnak az eredményeket, és eldönti, mikor kész a válasz. Ha egy zenekarhoz hasonlítjuk, akkor a modell és az eszközök a hangszerek, az orchestration réteg pedig a karmester. Nem játszik egyetlen hangszeren sem, mégis rajta múlik, hogy a darab összeáll-e.

A LangChain mint keretrendszer

A LangChain a legismertebb orchestration keretrendszer. Kész építőelemek gyűjteményét adja. Vannak láncok (chains), amelyekkel több lépést fűzhetünk egymás után, eszközök (tools), amelyeket a modell meghívhat, memória a beszélgetés állapotának megőrzésére, ügynök (agent) absztrakciók, amelyek maguk döntik el a lépések sorrendjét, és rengeteg kész integráció adatforrásokhoz és külső szolgáltatásokhoz. Az ígéret vonzó. Nem kell nulláról megírni a gyakori mintázatokat, elég összerakni a meglévő darabokból. Egy prototípus így valóban gyorsan összeáll, és szinte minden feladatra van a dokumentációban kész recept. Ez a kényelem teszi a LangChain-t népszerű kiindulóponttá, különösen amikor gyorsan kell egy működő demót mutatni.

Az őszinte kép

Az őszinte kép azonban árnyaltabb, és érdemes vezetőként is ismerni. Sok csapat tapasztalata, hogy ami prototípusban kényelmes, az élesben teherré válik. A keretrendszer egy vastag absztrakciós réteget húz a modellhívás és a saját kódunk közé. Amíg minden a keret elképzelése szerint halad, ez a réteg segít. Amint valami egyedit szeretnénk, vagy egy hibát kell megérteni, ugyanez a réteg útban van.

A gyakori panaszok visszatérők. A hibakeresés nehéz, mert a ténylegesen elküldött promptot és a hívási láncot több absztrakció fedi el, és nem mindig látszik, pontosan mi ment a modellhez. A verziók gyorsan változnak, és egy frissítés csendben átírhatja a viselkedést. A sok kész elem miatt könnyű olyan függőségeket behúzni, amelyekre nincs is szükség. Ezek nem elvi hibák, hanem annak az ára, hogy sok döntést a keret hoz meg helyettünk.

Sok csapat ezért ugyanazt az utat járja be. A kezdeti lelkesedés után fokozatosan kiváltják a keretet egy saját, jóval vékonyabb réteggel, amely csak azt tartalmazza, amire tényleg szükségük van. Nem azért, mert a keret rossz, hanem mert egy ponton a kontroll fontosabbá válik, mint a gyors összerakhatóság. Az alábbi összevetés a két megközelítés jellemzőit állítja egymás mellé.

A saját framework csapdája

Itt jön a képbe az, amit a saját framework csapdájának nevezünk. Amikor egy csapat leváltja a keretet, gyakran büszkén jelenti be, hogy megírta a saját frameworkjét. A valóság az, hogy ez legtöbbször nem egy framework, hanem néhány jól átlátható függvény. Egy hívás a modellhez, egy segédfüggvény, amely összeállítja a promptot, egy egyszerű ciklus, amely az eszközhívásokat kezeli, és egy réteg, amely naplózza, mi történt. Ez a néhány függvény átlátható, tesztelhető, és pontosan annyit tud, amennyire szükség van. Semmi varázslat nincs benne, és éppen ez az erőssége.

A csapda két irányba nyílik. Az egyik oldalon az áll, aki túl sokáig ragaszkodik a nehéz kerethez akkor is, amikor már csak a kontrollt szeretné, és a keret inkább lassítja. A másik oldalon az, aki a saját néhány függvényét külön termékként kezdi kezelni, folyamatosan új képességekkel bővíti, míg a vékony rétegből lassan újabb nehéz keret lesz, csak most a sajátja, a saját hibáival és karbantartási terhével. A cél nem az, hogy mindenki írja meg a sajátját, hanem hogy a réteg pontosan akkora legyen, amekkorára a feladatnak szüksége van.

Egy fiktív céges példa

Nézzük ezt egy fiktív példán. A Duna Retail Zrt. ügyfélszolgálati asszisztenst épít, amely a webshop kérdéseit válaszolja meg, a rendelés státuszától a visszaküldési feltételekig. Az első verzió LangChain-nel készül, a demó egy hétvége alatt működik, és a vezetőség elégedett. Ahogy a rendszer élesbe kerül, sorra jönnek a valós igények, amelyek a demóban fel sem merültek.

A jogi csapat pontosan látni akarja, milyen szöveg megy a modellhez, mert felelősséget vállalnak a válaszokért. Az ügyfélszolgálat vezetője azt kéri, hogy panaszos vagy bizonytalan esetekben mindig ember vegye át a szót. Egy rossz válasz kivizsgálásakor a fejlesztők fél napot töltenek azzal, hogy a keret rétegein átrágva megtalálják, hol dőlt el a hiba. Egyik igény sem rendkívüli, de mind a kontrollról és az átláthatóságról szól, éppen arról, amit a vastag absztrakció elfed.

A csapat végül vegyes megoldás mellett dönt. A gyakori, kritikus úton, ahol az ügyfelek nagy része megfordul, kiváltják a keretet néhány saját függvényre, hogy minden lépés látható és tesztelhető legyen. A ritka, sokféle külső rendszert érintő feladatoknál viszont maradnak a kész keretnél, mert ott a sok integráció valódi értéket ad. A döntés nem elvi, hanem gyakorlati. Ott adnak fel absztrakciót, ahol a kontroll a legfontosabb, és ott tartják meg, ahol a kényelem többet ér.

Mikor a keret, mikor a saját vékony réteg

A döntés ritkán fekete vagy fehér, és nem is egyszer kell meghozni. A keretrendszer akkor a jó választás, amikor gyorsan kell prototípust mutatni, amikor sokféle külső rendszert kell összekötni, és amikor a csapat szívesen épít mások kész, karbantartott megoldásaira. A saját vékony réteg akkor éri meg, amikor a kiszámíthatóság, az átláthatóság és a kontroll a legfontosabb, amikor a hívási út egyszerű és jól ismert, és amikor a hibákra gyorsan kell reagálni.

A kettő ráadásul nem zárja ki egymást. A legtöbb érett rendszer vegyesen használja őket, ahogy a fiktív példában is láttuk. A stabil, kritikus úton saját, vékony kód fut, a ritkább, sokféle integrációt igénylő feladatoknál pedig a kész keret. A jó mérnöki döntés nem az, hogy melyik tábor mellé állunk, hanem hogy feladatonként a megfelelőt választjuk.

Vezetői tanulság

A vezetői tanulság egyszerű. Az orchestration nem varázslat. Nincs benne semmi, amit ne lehetne megérteni, és a legtöbb rendszer néhány jól elnevezett lépésre bontható. Amikor egy csapat azt mondja, hogy a keret vagy éppen a saját megoldás miatt lassú a fejlesztés, a kérdés mögött szinte mindig ugyanaz a döntés áll.

A keretrendszer választása valójában arról szól, mennyi absztrakciót fogadunk el a saját kontrollunk rovására. Több absztrakció gyorsabb kezdést jelent, de kevesebb rálátást és nehezebb hibakeresést. Kevesebb absztrakció több kezdeti munkát jelent, de tisztább rálátást és teljes kontrollt. Egyik sem eleve jobb a másiknál. A helyes kérdés nem az, hogy melyik eszköz a divatos, hanem hogy ennél a konkrét feladatnál a gyorsaság vagy a kontroll fontosabb. Ha a csapat ezt tudatosan felteszi, ritkán esik bele akár a nehéz keret, akár a felfújt saját réteg csapdájába.