Forward Deploy Engineer · Lecke 06

Adatintegráció és pipeline-ok az ügyfélnél

Egy LLM megoldás minősége ritkán múlik a modellen, sokkal inkább az adaton, amelyet elé teszünk. Az adatintegráció ezért az FDE munkájának legnehezebb és legértékesebb része. Ez a lecke végigveszi, hogyan áll össze egy pipeline az ügyfél heterogén rendszereiből, hogyan kezeljük a valós adat hiányosságait, és hogyan tartja tiszteletben a lánc a jogosultsági határokat.

Vissza a tananyaghoz


Az adat a valódi munka

Egy demóban a modell okosnak látszik, mert gondosan előkészített bemenetet kap. Élesben a bemenet az ügyfél valós adatából jön, és itt derül ki, hogy a megoldás értéke nagyrészt az adat elérésén és minőségén áll. Az FDE ezért nem a modellt hangolja először, hanem az adathoz vezető utat építi ki. Ez a szerep egyik megkülönböztető vonása. A mérnök nem laborban tisztított, anonimizált mintán dolgozik, hanem közvetlenül az ügyfél rendszerein és valós adatán, ezért szembesül azzal, ami egy tiszta bemutatóban rejtve marad.

Ebből következik, hogy az adatintegráció nem előkészítő teher, hanem az érték forrása. Ahol a szükséges tudás jó minőségben, jogtisztán és frissen eljut a modellhez, ott a megoldás megbízható. Ahol nem, ott a legjobb modell is téved vagy kitalál. A pipeline dolga pontosan ez. Rendezetten, ismételhetően és követhetően eljuttatni a helyes adatot a helyes formában a rendszer többi rétegéhez.


Az ügyfél heterogén adatvilága

A vállalati adat ritkán él egyetlen tiszta helyen. Jellemzően relációs adatbázisokban, dokumentumtárakban, fájlrendszereken, e-mailekben, üzenetküldőkben és belső API-k mögött szóródik szét, gyakran évek alatt lerakódott rétegekben. Ezek a források eltérő formátumot, eltérő azonosítókat és eltérő jogosultsági rendszert használnak. Az FDE első feladata feltérképezni, hol él a use case-hez szükséges tudás, milyen formában, és milyen csatornán érhető el jogtisztán.

Ez a feltérképezés összeér az előző leckék munkájával. A felfedezésben megrajzolt folyamattérkép megmutatja, melyik lépéshez milyen adat kell, a megoldásarchitektúra pedig eldönti, hol futhat a feldolgozás. Az adatintegráció a kettő közé feszül. Az a mérnöki munka, amely a szétszórt, egyenetlen forrásokból egy megbízható, a modell számára használható adatfolyamot csinál, anélkül hogy az adat elhagyná az ügyfél környezetét, ahol annak maradnia kell.


EGY ADATPIPELINE LÁNCA Kinyerés DB, fájl, API Tisztítás hiány, duplikátum Transzformáció darabolás chunking Indexelés embedding index Visszakeresés a modell elé Jogosultság és eredetkövetés (lineage) végig a láncon Minden lépés az ügyfél környezetében fut, ismételhetően és követhetően.
A pipeline a nyers forrásokból lépésről lépésre készít a modell számára használható, kereshető adatot. A jogosultság és az eredetkövetés nem külön állomás, hanem az egész láncot átfogja.

A lánc lépései

Egy tipikus pipeline néhány jól elkülönülő lépésből áll. A kinyerés (extraction) a forrásrendszerekből olvassa ki a nyers adatot, tiszteletben tartva azok terhelhetőségét és hozzáférési szabályait. A tisztítás (cleaning) kezeli a hiányzó mezőket, a duplikátumokat és az ellentmondó rekordokat, és eldönti, mit tekintünk érvényesnek. A transzformáció alakítja használható formára az adatot, ide tartozik a szöveges tartalom értelmes egységekre darabolása (chunking), mert a modell nem egy egész dokumentumtárat kap, hanem a kérdéshez tartozó releváns részleteket.

Az indexelés teszi kereshetővé az adatot. A szöveges tartalomból numerikus reprezentáció, beágyazás (embedding) készül, amely egy indexbe kerül, hogy hasonlóság alapján gyorsan visszakereshető legyen. Végül a visszakeresés (retrieval) emeli ki a kérdéshez tartozó legrelevánsabb részeket, és ezek kerülnek a modell kontextusába. Ez a lánc az, amelyre a megoldásarchitektúrában látott visszakeresési réteg valójában épül. A minőség itt dől el, mert amit a visszakeresés nem hoz elő, azt a modell nem látja.


A valós adat minősége

A terepen szinte mindig kiderül, hogy az adat nem olyan, mint a leírása. Mezők hiányoznak, ugyanaz az entitás több néven szerepel, régi és új rekordok ellentmondanak egymásnak, és a felhasználók kézi kerülőutakat építettek a rendszer korlátai köré. Ezek nem kivételek, hanem a normál állapot. A pipeline egyik feladata, hogy ezt a valóságot ne elrejtse, hanem kezelje. A hiányt jelölni kell, nem kitalálni, az ellentmondást szabály szerint feloldani, a peremeseteket pedig tudatosan kezelni vagy tudatosan kizárni.

Ez a munka azért kritikus, mert az LLM a rossz adatot is magabiztosan dolgozza fel. Ha a visszakeresés elavult vagy hibás részletet ad át, a modell arra fog helyes hangzású, de téves választ építeni. Az adatminőség tehát nem esztétikai kérdés, hanem a megbízhatóság alapja. A jó FDE ezért az adat állapotát külön megvizsgálja, és a pipeline-ba beépíti azokat az ellenőrzéseket, amelyek a leggyakoribb hibákat még a modell elé kerülés előtt kiszűrik.


Adat elérése és jogtiszta kinyerésealapfeltétel
Tisztítás és inkonzisztencia kezelésegyakran a fő munka
Darabolás és indexelés minőségea visszakeresést dönti el
Frissesség és ismételhetőségéles működéshez kell

Jogosultság és eredetkövetés a pipeline-ban

Az adatintegráció ott találkozik a biztonsággal, ahol a legkönnyebb hibázni. A visszakeresésnek tiszteletben kell tartania a forrásrendszer jogosultságait, hogy a modell elé sose kerüljön olyan tartalom, amelyet az adott felhasználó egyébként nem láthatna. Ez nem elég a felület szintjén, mert ha az index a jogosultságtól függetlenül mindent tartalmaz, a visszakeresés kiszivárogtathat védett adatot. A jogosultságot ezért az adat szintjén kell érvényesíteni, végig a láncon, nem csak a végén.

Ehhez társul az eredetkövetés (data lineage). Éles rendszerben tudni kell, hogy egy adott válasz melyik forrásból, melyik rekordból és melyik feldolgozási lépésen át született. Ez teszi a megoldást auditálhatóvá, és ez segít a hibák visszafejtésében is. Ha egy válasz rossz, az eredetkövetés megmutatja, a lánc melyik pontján romlott el az adat. A pipeline így nemcsak adatot mozgat, hanem bizalmat is épít, mert követhetővé és ellenőrizhetővé teszi, mire alapoz a rendszer.


Batch, frissítés és ismételhetőség

Egy prototípusban elég egyszer betölteni az adatot. Élesben a forrás változik, ezért a pipeline-nak frissülnie kell. A döntés, hogy ez időzített kötegekben (batch) történjen, vagy közel valós időben, az ügyfél igényétől függ. Ahol a friss adat kritikus, ott gyakoribb vagy folyamatos frissítés kell, ahol nem, ott a ritkább köteg egyszerűbb és olcsóbb. A jó pipeline emellett inkrementális, vagyis nem építi újra minden alkalommal a teljes indexet, csak a változást dolgozza fel.

A közös követelmény az ismételhetőség. Egy éles pipeline-nak determinisztikusan, ugyanabból a bemenetből ugyanazt a kimenetet kell adnia, és hibánál újrafuttathatónak kell lennie anélkül, hogy adatot rontana vagy duplikálna. Ez viszi át az adatintegrációt a kézi, egyszeri megoldásból az üzemeltethető rendszer szintjére. Innen vezet az út a következő kérdéshez. Ha az adat rendben eljut a modellhez, honnan tudjuk, hogy a válasz valóban jó. Erre felelnek az evalok, amelyekről a következő lecke szól.


80/20

A munka nagy része az adaton van. Egy éles LLM megoldásban ritkán a modell a szűk keresztmetszet. Sokkal gyakrabban az adat elérése, tisztítása, jogtiszta visszakeresése és frissen tartása dönti el, hogy a rendszer megbízható lesz-e. Az FDE ezért az adatpipeline-t kezeli a megoldás gerinceként.


← Előző lecke Következő lecke →

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 →