Fabric ontology és data agentek: hol lakjon az üzleti jelentés?

„Mely vevőink vannak késedelemben?” Ennél egyszerűbb kérdést aligha írhat be egy kintlévőség-kezelő egy data agentnek. Most képzelj el egy tipikus középvállalati felállást: a lakehouse-ban van egy fizetési határidő oszlop, a szemantikus modellben egy késedelmes kintlévőség measure, amely kihagyja a vitatott számlákat, a behajtási csapat pedig olyan türelmi idővel dolgozik, amelyet soha senki nem írt le. Az ágensnek még az első SQL-sor előtt el kell döntenie, melyik „késedelem” értelmezést választja, és a táblaséma ebben semmit nem segít.

A Microsoft FabCon Europe körüli Fabric IQ-újdonságainak nagy része erre az értelmezési pillanatra céloz. Az ontology elem újraírt szerkesztőfelületet kapott, a data agentek mostantól ontologyt is felvehetnek kontextusforrásnak, és új helyek jöttek létre az utasításoknak. Pénzügyi vagy BI-vezetőként az a hasznos kérdés, hogy melyik definíciónak hol a helye.

Mit csinál egy data agent a kérdéssel

A Fabric data agent általánosan elérhető (GA) elem, amely természetes nyelvű kérdésekre válaszol a OneLake-ben lévő adatok alapján. A dokumentáció szerint kötött sorrendben dolgozik: a kérdést összeveti a biztonsági és responsible AI szabályokkal, a kérdező felhasználó hitelesítő adataival beolvassa a beállított források sémáját, eldönti, melyik forrás illik a kérdéshez, majd meghívja a megfelelő eszközt, amely lekérdezést generál. Ez lakehouse és warehouse esetén SQL-t, szemantikus modellnél DAX-ot, KQL adatbázisnál KQL-t jelent. A lekérdezés validálás után lefut, az eredményből pedig válasz lesz.

Két tervezési döntést érdemes ismerni, mielőtt az újdonságokra térnénk. Az ágens szigorúan csak olvas, és a kérdező jogosultságaival fut, tehát a sor- és oszlopszintű biztonság érvényben marad. Egy ágenshez legfeljebb öt adatforrás adható tetszőleges kombinációban, a szerző pedig utasításokkal és kérdés–lekérdezés példapárokkal terelgeti.

Az egész folyamat azon a lépésen múlik, ahol az ágens az üzleti szavakat táblákra és oszlopokra fordítja. Ehhez eddig csak a séma állt rendelkezésére, meg az, amit a szerző egy utasításmezőbe begépelt.

Mit tesz hozzá az ontology

Erre válaszol a még preview állapotú ontology elem: a vállalkozás közös, géppel is értelmezhető leírása. Entitástípusokat tartalmaz (Vevő, Számla, Költséghely), ezek tulajdonságait, a köztük lévő kapcsolatokat, metrikákat, természetes nyelvű szabályokat és adatkötéseket (data binding), amelyek megmondják, mit melyik forrás szolgáltat. A dokumentáció egy ponton nagyon óvatosan fogalmaz, és ez a keynote-ok nyelvezetében könnyen elsikkad: az ontology definíciókat és kötéseket tárol, nem általános célú lekérdezőmotor. Az adat abban a rendszerben marad, amelyik a gazdája, és az ontologyt fogyasztó felület a bekötött forráson futtatja a lekérdezéseit.

Az új „ontology as context source” preview-val a data agent felhasználhatja az ontology entitásait, kapcsolatait, definícióit, megfeleltetéseit, szinonimáit és forráskötéseit, amikor SQL-t, KQL-t vagy DAX-ot generál. Ebben az első kiadásban az ontology csak olvasható kontextusforrás, a Microsoft szerint pedig a szerzők tisztábban látják a kapcsolódó adatforrásokat, a futási lépéseket és a generált lekérdezéseket. Ez utóbbi legalább annyit ér, mint a pontosságra tett ígéret, mert azt a lekérdezést lehet ellenőrizni, amelyet el is lehet olvasni.

A szerkesztési oldalon néhány régi ellenérv is megszűnt. Az entitástípusoknak már nem kell egyedi kulcs a forrásban, kapcsolat külön kapcsolótábla nélkül is megadható, a kötések pedig szemantikus modellekre, lakehouse-okra, eventhouse-okra, warehouse-okra, SQL adatbázisokra és tükrözött adatbázisokra is kiterjednek. Az ontologyból épített gráf opcionális lett: a sémagráf nem tölt be példányadatot, csak akkor, ha ezt kifejezetten kéred olyan kérdésekhez, ahol éppen az entitások közötti útvonal a lényeg.

A measure-ök maradnak a helyükön

Egy meglévő Power BI-környezet szempontjából az a legfontosabb, hogy ontology szemantikus modellből is generálható. A táblák és kapcsolatok adják a kiinduló szerkezetet, a DAX measure-ök pedig metrikaként jelennek meg az ontologyban, a megfelelő entitásokhoz rendelve. A DAX-kifejezés gazdája továbbra is a szemantikus modell. Az ontology a metrika forrását és üzleti kontextusát őrzi meg, így az ágens felismeri és használja a szervezet saját számítását, ahelyett hogy újat rakna össze.

Aki éveket töltött azzal, hogy egy árrés- vagy allokációs measure-t mindenkivel elfogadtasson, annak ez megnyugtató kialakítás. A Morgan Stanley-nél Power BI-ban és DAX-ban épített aktivitásalapú költségallokációmnak az adta az értékét, hogy minden régió és üzletág ugyanazt a számot olvasta ugyanabból a definícióból. Visszalépés lett volna egy második szemantikus réteg, amelyben újra le kell írni ezeket a képleteket. Az ontology megközelítése a modellt tekinti a számítás hiteles forrásának, és azt teszi hozzá, amit egy modell nehezen fejez ki: milyen dolgok léteznek, hogyan kapcsolódnak össze forrásokon átívelően, és mit jelentenek a szavak.

Szabályok köznyelven

Az ontology szerzői mostantól természetes nyelvű szabályokat rendelhetnek entitástípusokhoz, kapcsolatokhoz és tulajdonságokhoz. A Microsoft példái a kiskereskedelemből jönnek, például hogy egy bolt készletpozíciója akkor „veszélyeztetett”, ha a várható készlet a következő ütemezett szállítás előtt a biztonsági készlet alá esik. Pénzügyi megfelelője lehetne ez: „Egy számla akkor késedelmes, ha a fizetési határidő után is kifizetetlen, és nincs vitatottként megjelölve”, vagy „Egy eltérés akkor lényeges, ha meghaladja a számlacsoportjára beállított küszöböt”.

Minden leírt szabály mellé odakívánkozik egy megjegyzés. A dokumentáció a szabályokat olyan kontextusként írja le, amelyet a támogatott fogyasztók az érvelésük során felhasználhatnak. Ez útmutatás az ágensnek, ami más, mint egy platform által kikényszerített megkötés. A szabály megmondja az ágensnek, mit jelent a „késedelmes”, de nem garantálja, hogy a generált lekérdezés alkalmazta is. Ezért a látható futási lépések és lekérdezések jelentik a valódi kontrollt, és ezért kellenek továbbra is ismert válaszú tesztkérdések.

Négy hely egy definíciónak

A Topics a másik újdonság ebben a táblázatban. Támogatott adatforrásonként akár egymillió karakternyi, szakaszokra bontott útmutatást fogad be, az ágens pedig csak a kérdéshez illő szakaszokat keresi ki és adja át az SQL-generátornak. Az adatforrás-utasítások ezzel szemben minden alkalommal elmennek, amikor a forrás használatba kerül, ezért a Microsoft a kivétel nélküli szabályokhoz ajánlja őket.

A csapda az, ha az alsó sorokba kerül az, ami a felsőkbe való. Az egyik ágens utasításai közé begépelt definíció csak annak az egy ágensnek segít. Ugyanez a definíció az ontologyban minden ágens, dashboard és eszköz számára elérhető, amely olvassa, ráadásul verziótörténete van: a szerzők névvel ellátott verziókat hozhatnak létre, és vissza tudnak állni egy korábbira.

Ugyanaz a kontextus a Fabricen kívülről

A publikált data agent egyetlen eszközt kínáló MCP-szerverként is fogyasztható, és ez a szerver már támogatja az MCP Taskst, így egy hosszan futó kérdés nem azon múlik, hogy a kapcsolat végig nyitva marad-e. A Fabric IQ MCP-szerver általánosan elérhetővé vált Power BI-riportokra és szemantikus modellekre, beleértve a DAX futtatását azokon a modelleken, amelyekhez a felhasználónak joga van; a Microsoft szerint az ontologyk és a data agentek következnek. Az ontologynak saját MCP-eszközei is vannak a definíciók kezelésére és a lekérdezésre.

A hozzáférés-szabályozás az adatot követi. Az ontology szerkesztése és lekérdezése tiszteletben tartja a OneLake securityt, valamint a forrás által érvényesített sor-, objektum- és oszlopszintű biztonságot. Power BI-oldalon a szemantikus modellek szerkesztői új beállítást kaptak, amellyel a csak olvasási joggal rendelkező felhasználók elől elzárható a modell a Copiloton, a data agenteken és a Microsoft MCP-szerverein keresztül. A beállítás alapból engedélyezve van, hogy a meglévő működés ne változzon, vagyis az AI-hozzáférés szűkítése modellenként külön, tudatos döntés.

Mit érdemes ellenőrizni, mielőtt építesz rá

Preview állapotú az ontology elem, az ontology mint kontextusforrás és a Topics is. Néhány dokumentált korlát alapvetően meghatározza a pilotot. A data agentek jelenleg nem támogatnak az angolon kívül más nyelvet, sem a kérdésekben, sem az utasításokban. A normál runtime legfeljebb 25 sort ad vissza, a preview runtime-on ez legfeljebb 1000. Az ágens nem tud olyan forrást lekérdezni, amelynek a kapacitása más régióban van, mint a sajátja. Ha pedig a korábbi felületen építettél ontologyt, azt át kell másolni az újba, a szabályokat újra létre kell hozni, a ráépülő fogyasztókat újra be kell kötni; a régi felület 2027. január 31-én megszűnik.

A mostani Fabric lakehouse-munkámban a governance-ráfordítás a row-level securitybe és az adatminőségi szabványokba megy, jóval azelőtt, hogy bárki kérdést tenne fel egy AI-nak. Az ontology ezt a munkát nem rövidíti le. Helyet ad az eredményének, ahonnan az ágensek ki tudják olvasni.

Az angol nyelvi korlát magyar csapatoknál külön mérlegelendő: a definíciókat és szabályokat angolul kell megírni, és a felhasználóknak is angolul érdemes kérdezniük.

Egy értelmes pilot szűkre szabott: generálj ontologyt egyetlen, jól karbantartott szemantikus modellből, tarts meg egy maroknyi entitást, írd le azt a három definíciót, amelyről a legtöbb vita folyik, és futtasd le ugyanazt a húsz kérdést az ontologyval és nélküle. A Microsoft bejelentése, a Trusted AI starts with Microsoft Fabric, Real-Time Intelligence, and IQ felsorolja az ontology összes változását, a korlátok részletei pedig a Microsoft Learn ontology-áttekintőjében és a data agent koncepcióoldalán találhatók.