4 tanulság az AI Functions használatához a Microsoft Fabric Data Warehouse-ban

Egy egyeztetési eltérést (break) lezárnak, az elemző pedig beírja a megjegyzés mezőbe: „agent fee diff, átkönyvelve, ld. ticket 4471". Havi néhány száz ilyen sor, néhány év alatt, és a warehouse-ban ott ül a pontos története annak, miért csúsznak el az elszámolási költségek, csak épp olyan nyelven, amit egyetlen SQL-lekérdezés sem ért. A Microsoft friss preview-ja a Fabric Data Warehouse-ban pontosan ezt célozza: beépített AI-függvények, amelyek közvetlenül T-SQL-ből végeznek kinyerést, osztályozást és szövegtranszformációt, plusz egy általános függvény saját promptokhoz.

A függvények újak. Az viszont egyáltalán nem új, hogyan tud félremenni a modell-kimenet egy warehouse-ban, és az alábbi tanulságok zöme ebből a második kategóriából jön: abból, amit LLM-ek ETL-be kötése közben tanultam egy Fabric lakehouse körül, rávetítve arra, ami ebben a preview-ban ténylegesen megjelent.

Mi érkezett, egy menetben

A bejelentés szerint a preview a következőket adja:

• ai_extract(text, topics…) a megadott témákat azonosítja a szabad szövegben, és JSON property-ként adja vissza, kontextuális értelmezésre építve, nem regexekre.
• ai_analyze_sentiment(text) pozitív, negatív, semleges vagy vegyes címkét ad a szövegre.
• ai_classify(text, classes…) a megadott címkék közül a szöveghez kontextuálisan legközelebbit választja.
• ai_summarize, ai_fix_grammar, ai_translate a klasszikus transzformációkat fedik le, amiket eddig az alkalmazásrétegben csináltál.
• ai_generate_response(instructions, text) saját promptot fogad mindarra, amit a beépítettek nem fednek le.

Minden közönséges T-SQL-lekérdezésből fut, és valójában ez a lényeg: táblaszintű szövegfeldolgozás külső szolgáltatás, orchestration-réteg és export-lépés nélkül.

Pénzügyi szövegre a megfeleltetés elég közvetlen:

1. tanulság: a beépített függvények több pénzügyi szöveget fednek le, mint várnád

Aki egyszer már kötött LLM-et pipeline-ba, annak az a reflexe, hogy azonnal a saját prompthoz nyúl. Itt érdemes megfordítani a sorrendet: előbb az ai_extract és az ai_classify, mert ezek rákényszerítenek, hogy pontosan kimondd, mit akarsz (témalista, címkekészlet), és kiszámítható formát adnak vissza. A bejelentés saját példái orvosi feljegyzésekből való kinyerés és alkalmazáslogok osztályozása; cseréld ki a főneveket, és máris AP-kérdések irányításánál vagy break-kommentek kódolásánál tartasz.

Amikor a Morgan Stanley-nél havi 600+ számla (PDF és Excel) feldolgozását automatizáltam, a nehéz részt a szabad szöveges leírássorok jelentették; az összegek és dátumok parse-olhatók, de hogy mi volt valójában a tétel, azt próza mondja el, és az allokációs logika pont ebben a prózában lakik. Egy függvény, ami ezt a prózát a warehouse-on belül kötött címkekészletté alakítja, a törékeny parsoló kód egy egész kategóriáját teszi feleslegessé.

A sentiment-elemzést viszont nyugodt szívvel kihagynám. A pénzügyi műveletekben senkinek nem kell modell ahhoz, hogy megállapítsa egy fizetési felszólítás hangulatát.

2. tanulság: betöltéskor címkézz, ne riportkészítéskor

A bejelentés leghasznosabb mintája egyben a legkisebb: az ai_classify lakehouse-fájlokból OPENROWSET()-tel beolvasott sorokon fut, és az eredmény-kategória plusz oszlopként kerül a céltáblába. A címke egyszer számolódik ki, amikor a sor megérkezik, és minden downstream felhasználó ugyanazt az értéket örökli.

Vesd össze azzal, ahogy a szabad szöveg kategorizálása a pénzügyi csapatokban általában történik. Minden elemző a saját Power Query-lépésében vagy Excel-lookupjában rakja kupacokba ugyanazokat a kommenteket, a kupacok szétcsúsznak, és hó végére két riport nem ért egyet abban, hány ügy volt „timing" és hány „data error". A betöltéskor hozzárendelt kategória ugyanolyan származtatott oszlop, mint bármelyik másik: egyszer számolt, perzisztált, lekérdezhető, és load-timestampig visszakövethető. Ráadásul ad valamit, amit az e-mailes-Excel-es munkamódszer sosem adott meg: egy helyet, ahol mérhető, hogy a címkék egyáltalán jók-e. Ennek az érvnek semmi köze az AI-hoz; az AI csak lehetővé teszi a származtatást olyan szövegre, ami eddig ellenállt neki.

3. tanulság: a prompt mostantól adatbázis-objektum, kezeld is úgy

Amikor a beépített függvények kevésnek bizonyulnak, az ai_generate_response szabad instrukciókat fogad, és a bejelentés kimondott best practice-e, hogy a promptot T-SQL függvénybe vagy eljárásba csomagold, és külön modulként hívd. Ez a tanács többet érdemel egy záró lábjegyzetnél, mert megváltoztatja, hogy mi is egy prompt. CREATE OR ALTER FUNCTION-be csomagolva a prompt verziózható, reviewolható, deployolható objektum lesz: ugyanaz a CI/CD pipeline szállíthatja, amelyik a view-kat és a tárolt eljárásokat. A BI-asset-ek CI/CD-je a Syngentánál a napi munkám része, és a chat-ablakokban meg notebook-cellákban élő promptok pontosan az a fajta asset, amiért ez a fegyelem létezik.

A bejelentés incidens-elemző példájából átdolgozva, pénzügyes ízesítéssel:

-- A prompt egy helyen él, verziókezelés alatt,
-- és minden hívó ugyanazokat a szabályokat kapja.
CREATE OR ALTER FUNCTION dbo.classify_break_comment (@comment VARCHAR(8000))
RETURNS VARCHAR(8000)
AS
BEGIN
    RETURN ai_generate_response(
        'Olvasd el ezt az egyeztetési break-kommentet, és adj vissza tömör JSON-t:
         break_cause (fee_mismatch, timing, missing_instruction, data_error, other),
         recurring_candidate (true/false),
         follow_up_team.
         Ne idézd az eredeti kommentet. Komment: ',
        @comment
    );
END;

Így becsomagolva a címke-taxonómia módosítása pull requesten keresztül megy, nem egy Slack-üzenetben.

4. tanulság: a modell válasza vélemény, tárold is úgy

Ezeknek a függvényeknek a kimenete kontextuális ítélet, nem determinisztikus számítás, és a warehouse-nak így is kell rögzítenie. Az eredeti szövegoszlop maradjon érintetlenül minden AI-származtatott érték mellett. A származtatott oszlopokat nevezd el úgy, hogy senki ne nézze forrásadatnak (break_cause_ai, ne break_cause). Mintavételezz kézzel címkézett halmazon, mielőtt bármelyik riport rájuk épülne, ugyanúgy, ahogy egy fuzzy-matching szabályt validálnál egy egyeztetésben. És egyelőre tartsd őket távol a kontroll-kritikus utaktól: ha egy kategória rossz queue-ba irányít egy ticketet, az percekbe kerül; ha könyvelési tételt vagy sign-offot táplál, az audit findingba torkollik. A preview-státusz is számít: a szintaxis és a viselkedés a general availability előtt még változhat, ami eggyel több ok arra, hogy minden hívás a 3. tanulság wrapper-függvényein menjen át, így egy breaking change egyetlen ALTER-rel javítható.

Hova illeszkedik

Először olyan szövegen érdemes próbálni, ami tényleg beragadt: break-kommentek, zárási issue-logok, ticket-leírások, az AP-mailbox. Válassz egyet, címkézz fel kézzel egy mintát, futtasd rá az ai_classify-t, és mérj, mielőtt megbízol benne. A teljes preview-leírás az orvosi feljegyzéses, log-osztályozós és ticket-transzformációs példákkal a Microsoft Fabric blogon olvasható: Working with unstructured text in Fabric Data Warehouse with built-in AI functions, a teljes függvényreferenciát pedig az onnan linkelt dokumentáció adja. A szabad szöveg sokáig az az adattípus volt, amit a pénzügyi warehouse-ok közös megegyezéssel ignoráltak; ezzel a preview-val az ignorálás kényszer helyett már csak döntés.