A vállalati AI-alkalmazások eddig nagyrészt a kontextusépítésre épülnek: csatlakoztatják a vállalati rendszereket, feldolgozzák a dokumentumokat, létrehozzák a chunk-okat és embeddingeket, felépítik a retrieválási csővezetékeket, majd ezekből állítják össze az egyes asszisztensek vagy agentek futásidejű kontextusát. Ez a megközelítés jól működik elszigetelt asszisztensek és copilotok esetén, de alapvetően alkalmazás-specifikus kontextusként kezeli a vállalati tudást ahelyett, hogy azt megosztott vállalati vagyonként menedzselné.
Ahogy egy szervezet több AI-alkalmazást és agentet telepít, ez a modell működésképtelenné válik. Különböző csapatok ugyanazokat a dokumentumokat dolgozzák fel, külön embeddingeket és indexeket tartanak fenn, és következetlen reprezentációkat hoznak létre ugyanazon üzleti tudásról. A probléma így nem csupán az, hogy kontextust biztosítsunk az AI rendszereknek — hanem maga a vállalati tudás kezelése válik a központi kérdéssé.
Miért nem elég pusztán kontextust építeni?
A jelenlegi gyakorlat lényege, hogy minden alkalmazás saját kontextusát állítja elő és tartja karban. Ez három oka miatt válik hosszabb távon problémássá:
- Következetlenség: a vállalati tudás több, egymástól független rendszerben él különböző sémákkal, definíciókkal és frissítési ciklusokkal. Ugyanaz a termék, ügyfél vagy folyamat különböző módon, vagy akár egymásnak ellentmondóan is megjelenhet dokumentumokban, Jira ticketekben, forráskódban, CRM-ben és metaadatokban. Ha ezeket az eltéréseket alkalmazás-specifikus kontextusba ágyazzuk, a következetlenség nem oldódik meg — csak áttevődik az AI alkalmazásra.
- Változások terjesztésének nehézsége: a vállalati tudás folyamatosan változik, de minden alkalmazás saját kontextuscsatornát tart fenn. Amikor dokumentumok, kód vagy üzleti definíciók módosulnak, a downstream chunk-ok, embeddingek és indexek függetlenül frissülnek, így az egyes AI alkalmazások különböző verziókon működhetnek.
- Ismétlődő csapatmunka és költségek: különböző csapatok ugyanazt a tudást dolgozzák fel, hasonló embeddingeket és indexeket hoznak létre, és átfedő kontextusokat építenek különböző alkalmazásokhoz. Ez duplikált mérnöki munkát, fölösleges infrastruktúra-költséget és fragmentált tudást eredményez.
Ezek a problémák nem pusztán kontextusépítési kérdések — tudásmenedzsment-problémák. A strukturált adatoknál az enterprise data platformok egyszer már megoldották, hogy az adatokat egyszer kezeljék és megosszák alkalmazások között. A vállalati AI-nak ugyanezt az architekturális fegyelmet kell követnie: egy megosztott enterprise knowledge platformra van szükség, amely egyszer kezeli a tudást és újrahasználható reprezentációkat publikál minden AI alkalmazás számára.
Rétegezett adat- és tudáskezelés
Egy enterprise knowledge platform a strukturált adatokat kezelő vállalati adatplatformok megfelelője a vállalati tudás számára. Ahelyett, hogy a dokumentumokat, forráskódot, Jira-ticketeket, email-eket és API-kat külön alkalmazási bemenetekként kezelné, ez a platform megőrzi, rendszerezi, integrálja, szabályozza és publikálja a tudást egy közös architektúrán keresztül, így minden AI alkalmazás ugyanazt a megbízható tudásalapot fogyaszthatja.
A platform négy elkülönített rétegre bontja a tudáskezelést, melyek külön felelősségeket kapnak: a forrásmegőrzés, a normalizálás, a kapcsolódás és a közzététel. Ez lehetővé teszi, hogy az egyes lépcsők függetlenül fejlődjenek, miközben következetes alapot biztosítanak minden downstream alkalmazásnak.
A négy réteg: Raw → Refined → Integrated → Serving
- Raw (nyers): megőrzi az eredeti forrásokat.
- Refined (finomított): heterogén forrásokat alakít át kezelt tudásobjektumokká.
- Integrated (integrált): összekapcsolja a tudást rendszerek között egy egységes vállalati tudásmodellbe.
- Serving (szolgáltató): újrahasználható és agent-specifikus reprezentációkat publikál AI alkalmazások számára.
Raw réteg — a forrás megőrzése
A raw réteg begyűjti az információt a vállalati rendszerekből úgy, hogy megőrzi az eredeti formát és forrásazonosítót: adatbázis-rekordok és change eventek, PDF-ek és más dokumentumok, Confluence oldalak, Jira ticketek, forráskód, API-válaszok, emailek, képek és eseményfolyamok. A cél nem azonnal agentre készé tenni az információt, hanem biztosítani a megbízható forrást, ahonnan a platform később újrafeldolgozhatja a tudást.
Refined réteg — a vállalati tudás normalizálása
A refined réteg a heterogén forrásokat kezelhető tudásobjektumokká alakítja. Minden forrás konzisztens reprezentációt kap, miközben megőrzi az identitást, metaadatokat, jogosultságokat, verziókat, lineage-t és hivatkozásokat az eredeti tartalomra. Például egy termékkövetelmény-dokumentum átalakulhat egy strukturált objektummá, amely tartalmaz dokumentumazonosítót, termékazonosítót, címet, forrásrendszert, szerzőt, verziót, jogosultságokat, tageket, létrehozási és módosítási időt, valamint a kapcsolódó tartalmat.
Ebben a lépésben nem cél a különböző üzleti domének összekapcsolása; ehelyett egy újrahasználható és kormányzott reprezentáció jön létre minden vállalati tudásforráshoz. Amint minden forrás strukturált vagy félig strukturált tudásobjektummá válik, az integrált réteg összekötésre képes.
Integrated réteg — a vállalati tudásmodell felépítése
Az integrated réteg független tudásobjektumokat egyesít egy egységes vállalati tudásmodellbe. Két fő szerepe van: a rendszerek és üzleti domének közötti kapcsolatok létrehozása, valamint az AI számára szükséges üzleti kapcsolatok modellezése a következtetéshez.
A tudást közös üzleti azonosítók (például termék- vagy ügyfélazonosítók), explicit rendszerek közötti hivatkozások (például Jira és Git linkek) vagy AI-alapú entitásfeloldás segítségével kötik össze, ha nincs közvetlen kapcsolat. Például egy „Bulk Invoice Upload” követelménydokumentum, egy „Implement Invoice Upload API” Jira story és egy ugyanazt a funkciót bemutató release note ugyanarra a képességre utalhatnak, még ha expliciten nem is kapcsolódnak.
Az integrált réteg az üzleti logikán alapuló kapcsolatok modelljét készíti el (implemented_by, contains, belongs_to, affects, depends_on stb.), amelyek a működésmódot, függőségeket, tulajdonlást és üzleti hatást írják le — nem csupán az adatbázisok primer/idegen kulcs viszonyait. Ez lehetővé teszi az AI számára, hogy mérnökség, termék, ügyféltámogatás, pénzügy és más domének között nyomon kövesse a tudást egy közös vállalati szemlélet mentén.
Serving réteg — tudás publikálása AI számára
A serving réteg hasonló a sok vállalati AI-alkalmazásnál használt kontextusréteghez, de egy kezelt vállalati tudásalapra épül. Átalakítja az enterprise knowledge modelt olyan reprezentációkká, amelyek különböző AI munkaterhelésekre optimalizáltak. Két kategóriába sorolhatók:
- Megosztott vállalati reprezentációk: közös tudásalapot biztosítanak minden AI alkalmazás számára — például SQL nézetek, keresési indexek, chunk-ok, embeddingek, gráfmodellek és API-k, amelyeket egyszer hoznak létre és újrahasználnak.
- Agent-specifikus reprezentációk: a platform dinamikusan állít össze feladatspecifikus kontextust az integrált tudásmodellből az egyes agentek igényei szerint. Egy Product Agent, Revenue Agent és Customer Support Agent ugyanazt a tudásalapot fogyaszthatja, miközben más-más, szerepkörre szabott kontextust kap.
Ez a réteg támogatja az újrahasználhatóságot, csökkenti a duplikált feldolgozást és biztosítja, hogy minden alkalmazás ugyanazon menedzselt tudáson alapuljon.
A menedzselt tudásplatform előnyei
A jelenlegi vállalati tudásrendszerek elsősorban emberek számára készültek: Confluence oldalak, dokumentumok, Jira, metaadat-rendszerek segítik a munkát és az értelmezést. A nagyméretű nyelvi modellek azonban alapvetően megváltoztatták, hogyan fogyasztja a tudást a gép: a modellek mostantól képesek természetes nyelvet értelmezni, következtetni és dokumentumokon át rezonálni. Ez az átalakulás új, AI-kompatibilis adatalapokat igényel.
A kezelt enterprise knowledge platform átalakítja a humánorientált rendszereket AI-ready infrastruktúrává: a tudást konzisztens, újrahasználható és szabályozott adattá teszi. Ennek konkrét képességei:
- Tudás életciklus-kezelés: inkrementális betöltés, változások propagálása, verziókezelés és történeti következtetés anélkül, hogy minden kontextuscsatornát újra kellene építeni.
- Kormányzás és bizalom: teljes end-to-end lineage, traceability, jogosultságok, ownership, minőségellenőrzés és magyarázható AI-válaszok, amelyek visszavezethetők az eredeti forrásokra.
- Újrahasználható tudásszolgáltatások: közös keresési indexek, embeddingek, gráfmodellek, SQL nézetek, API-k és dinamikus kontextus-összeállítás.
- Folyamatos fejlődés: a tárolás, keresés, embedding modellek és AI alkalmazások független evolúciója, miközben az agent visszajelzés folyamatosan javítja a vállalati tudást.
A platform emellett támogatja a human-in-the-loop és reinforcement learning munkafolyamatokat: az agentek visszajelzései visszaforgathatók a platformba, ellenőrizhetők, szabályozhatók és integrálhatók az enterprise knowledge modellbe, mielőtt azt közzétennék a downstream alkalmazásoknak. Ez zárt visszacsatolási köröket hoz létre a folyamatos javításhoz.
A következő versenyelőny – a tudásalap
A ChatGPT 3 2022 végi megjelenése óta az iparág hatalmas erőforrásokat fordított foundation modellekre, RAG-architektúrákra, vektoradatbázisokra, embeddingekre, MCP-re és multi-agent frameworks-re. Ezek a technológiák javították az AI-alkalmazások építését és bevezetését, és ma a stack gyorsan érlelődik.
A következő szűk keresztmetszet már nem a modell vagy az agent framework lesz, hanem az őket tápláló vállalati adatalap. Az AI agentek annyira jók, mint az az adat és tudás, amit fogyasztanak. Jobb modellek nem kompenzálják a fragmentált dokumentumokat, következetlen üzleti definíciókat, összekapcsolatlan rendszereket vagy gyengén kezelt tudást: mint minden adatvezérelt rendszernél, itt is érvényes a Garbage in, garbage out elv.
Ezért a legfontosabb befektetés ma már nem az agentek számának növelése, hanem az a vállalati tudásplatform kiépítése, amely minden agentet támogat. Amely szervezetek a vállalati tudást megosztott infrastruktúraként kezelik, nem alkalmazás-specifikus kontextusként, megbízhatóbb AI-t építenek, gyorsabban fejlesztenek új alkalmazásokat, és skálázzák az AI-t anélkül, hogy újra és újra újból felépítenék ugyanazt az alapot.
A következő versenyelőnyt tehát nem több agent építése hozza, hanem az a tudás- és adatalap, amelyre minden agent támaszkodik.
Shuhua Xu, Lead Data Engineer
