Data agent ve Fabricu: kdy už Copilot nestačí

Ve 3. dílu jsem procházel Copilota v Power BI: čtyři místa, kde ho potkáte, a kdo za něj platí. Všechna mají jedno společné. Copilot odpovídá nad reportem nebo semantic modelem, který máte otevřený nebo který si sám najde. Microsoft 365 Copilot umí report propojit i s vašimi soubory a e-maily. Dokud se ptáte nad jedním modelem, Copilot stačí.

Jenže co když chcete jednu sdílenou položku, která spojí čísla z modelu s pravidly z firemní směrnice? A kterou zavoláte z Copilot Studia, z Foundry nebo z vlastní aplikace? Tady Copilot končí a začíná data agent. Článek patří do seriálu o mapě AI nástrojů kolem datové platformy. Nejedná se o žádný Deep dive, spíš o to, kdy po data agentovi sáhnout, jak ho nastavit, aby odpovídal správně, a co od něj čekat.

Co data agent je

Data agent je samostatná položka ve workspace. Sestavíte ho, otestujete a publikujete, podobně jako report. Dáte do něj až pět zdrojů v libovolné kombinaci: lakehouse, warehouse, KQL databázi, semantic model, ontologii nebo index v Azure AI Search.

V jádru jde o natural language to SQL/DAX/KQL podle zdroje. Na otázku agent vybere vhodný zdroj a vygeneruje k ní dotaz: pro lakehouse a warehouse v SQL, pro semantic model v DAX, pro KQL databázi v KQL. Dotaz ověří a spustí. Generuje jen čtecí dotazy, takže nic nezmění ani nesmaže. Odpoví vám, kolik se prodalo a kde. Otázka „proč klesla produktivita“ zůstane bez odpovědi, kauzální analýzu agent nedělá.

Kam zapadá

Jednotlivé úrovně na sebe navazují takhle:

• Prep data for AI (2. díl) – příprava semantic modelu, ze které čerpá Copilot i data agent.
• Copilot v Power BI (3. díl) – otázky analytika nad jedním reportem nebo modelem, přímo v Power BI.
• Data agent (tenhle díl) – odpovědi nad víc zdroji, zabalené do položky, kterou lze sdílet a volat zvenku.
• Foundry a Microsoft 365 Copilot (další díly) – data agent jako jeden z nástrojů jiného agenta.

Microsoft data agenta řadí pod Fabric IQ, vedle ontologie, semantic modelů a Graphu, k tomu názvu se ještě krátce vrátím. V praxi to znamená: data agent leží mezi daty ve Fabricu a nástroji, které se na ně ptají, třeba Copilot Studiem, Foundry nebo Microsoft 365 Copilotem.

Kdy po něm sáhnout

Podle mě se data agent vyplatí ve třech situacích:

• Odpověď potřebuje víc zdrojů. Například čísla ze semantic modelu plus pravidla z dokumentů v Azure AI Search.
• Agenta má volat jiný nástroj. Copilot Studio, Foundry nebo vlastní aplikace přes MCP, případně Microsoft 365 Copilot jako hotový agent pro uživatele.
• Chcete jednu sdílenou definici „jak se ptát“. Instrukce, výběr zdrojů a popis se nastaví jednou a používají je všichni. Výpočetní pravidla ale dál patří do modelu, k tomu níže.

Pokud se ptáte nad jedním dobře připraveným modelem a odpověď vám stačí v Power BI, zůstal bych u Copilota. Data agent je další položka, kterou je potřeba udržovat, testovat a platit.

Kam patří pravidla pro výpočty

U lakehouse nebo warehouse funguje všechno, co v agentovi najdete: instrukce agenta, instrukce ke zdroji i example queries. U semantic modelu z toho zbude málo: instrukce ke zdroji ani example queries nastavit nejdou a podle dokumentace se ani instrukce agenta nepředávají té části agenta, která píše DAX dotaz.

Ta část vychází z metadat modelu a hlavně z Prep data for AI – nastavení uloženého přímo na semantic modelu. Má tři části:

• AI data schema – které tabulky, sloupce a measures má AI vidět.
• Verified answers – ověřené odpovědi navázané na trigger otázky.
• AI instructions – pokyny pro AI v běžné řeči.

Prep data for AI dnes vyžaduje zapnuté Q&A, se kterým Microsoft do budoucna nepočítá.

Výpočetní pravidla („vlajková prodejna je formát Mega Store“, „marže se počítá bez divize X“) proto patří do Prep data for AI, na jedno místo. Čerpá z něj data agent i Copilot. V mých testech agent pravidlo z Prep data for AI dodržel a Copilot v reportu vrátil verified answer. Do instrukcí agenta dejte jen to, co platí napříč zdroji: formát odpovědí, kdy jít do kterého zdroje, zkratky a tón.

Kdo se k čemu dostane a kolik to stojí

Agent se ptá pod identitou uživatele, takže platí jeho oprávnění včetně RLS a CLS. Nad semantic modelem stačí oprávnění Read. Sdílením agenta ale k datům nikoho nepustíte – kdo k modelu přístup nemá, dostane chybu nebo prázdný výsledek.

Opačný případ: kdo k modelu Read má, může se na něj ptát přes AI, dokud to na modelu nevypnete. Rozhoduje nastavení přímo na modelu Allow any person with only read permissions to use AI. Není to tenant setting, ve výchozím stavu je zapnuté a platí pro Copilota, data agenta i MCP nástroje Microsoftu. U citlivých modelů ho tedy projděte model po modelu. Když to nastavení vypnete, model zmizí z vyhledávání v Copilotovi všem uživatelům. I ti s Build nebo Write ho pak musí otevřít přímým odkazem nebo připojit ručně.

Agent potřebuje kapacitu F2 a výš nebo Premium P1 a výš. Spotřeba se počítá z tokenů a do nich patří i instrukce a historie konverzace, takže dlouhé instrukce zaplatíte u každé otázky. Dotaz, který agent spustí, se účtuje zvlášť na položce, která ho vykoná.

Co jsem zjistil v testech

Zkoušel jsem ve svém tenantu na kapacitě F2 nad svým obvyklým demo modelem Current Performance: anonymizovaná data z retailu s elektronikou, jeden obchodní den (13. 3. 2017) s tržbami, marží a cíli po divizích, prodejnách, kanálech a hodinách. Nad ním jsem postavil dva agenty. První měl jen tento model:

Druhý měl navíc index v Azure AI Search s fiktivními firemními dokumenty – směrnicí s pravidly pro marže, eskalace a bonusy a glosářem metrik:

1. Kam zadávat instrukce. Pravidlo uložené v Prep data for AI agent v mých pokusech dodržel, jen se projevilo až chvíli po uložení. Pravidlo jen v instrukcích agenta v jednom pokusu zafungovalo taky, i když by podle dokumentace nemělo. Na tom bych nestavěl. Problém nastal, když jsem stejné pravidlo napsal na obě místa a každé jinak. Agent pak na stejnou otázku ve dvou pokusech odpověděl pokaždé jinak a jednou vrátil popisek podle jednoho pravidla a číslo podle druhého, aniž na rozpor upozornil. Proto pravidla pro výpočty patří na jedno místo, do Prep data for AI.

2. Jak kombinuje data s dokumenty. Spojit číslo z modelu s pravidlem ze směrnice agent umí, jen ne vždycky správně. Z 15 testovacích otázek, z nichž většina potřebovala číslo i pravidlo ze směrnice, zodpověděl správně 6. Chyby přitom vypadají věrohodně. Započítal divizi, kterou měl podle směrnice vyloučit, a vymyslel si příznak „Below Margin Alarm Threshold“. Na první pohled nic nepoznáte. Agenta proto testujte stejně jako nové measures – proti číslům, která znáte.

3. Co to stojí. V jednom měření (10 otázek) mě otázka na druhého agenta na F2 stála v průměru kolem 1 900 CU sekund, zhruba pětkrát víc než příklad v dokumentaci. Do denního rozpočtu F2 by se tak vešlo asi 91 otázek, pokud by kapacita nedělala nic jiného. Azure AI Search v tom čísle není, ten se platí zvlášť v Azure podle tarifu služby. Kolik CU spotřebuje váš agent, záleží hlavně na tom, kolik textu zpracuje: délka instrukcí a historie konverzace se počítají u každé otázky.

4. Jak je na tom s češtinou. Data agent oficiálně podporuje jen angličtinu. V praxi na českou otázku odpovídá česky. Nad modelem Current Performance vrátil na českou otázku na tržby podle divizí správná čísla. Zbytek jsem zkoušel na malém vlastním lakehouse s potravinami a nápoji, protože jsem potřeboval stejná data česky i anglicky. České otázky nad českými daty dopadly stejně jako anglické nad anglickými a součty bez filtru na textovou hodnotu fungovaly vždy. Drhne to jinde: když se zeptáte na „kávu“ a v datech je „Coffee“, agent vrátí nulu a nic neřekne. Pomůže slovníček hodnot v instrukcích agenta (káva = Coffee). Se slovníčkem dopadly české otázky nad anglickými daty nejlépe ze všech kombinací, které jsem zkoušel.

Vzorek byl malý, takže rozdíly mezi variantami berte orientačně. V 1. dílu jsem psal, že česky funguje podobně jako anglicky. To platí, dokud jsou česká i data, nebo agent dostane slovníček hodnot.

Pár dalších limitů, na které se vyplatí myslet předem: odpověď v chatu má k listopadu 2026 nejvýš 25 řádků a 25 sloupců a zdroj musí ležet na kapacitě ve stejném regionu jako agent. Data agent je na konverzační otázky, ne na export celých datasetů.

Integrace s okolním světem

Publikací vznikne sdílená verze agenta, pracovní zůstává vedle. Publikovanou verzi pak můžete zapojit takto:

• Microsoft 365 Copilot – při publikaci zvolíte Agent Store a uživatelé agenta osloví přes @, i z Teams.
• Copilot Studio – agent se přidá jako tool. Pozor na režim autentizace Maker: všichni pak vidí data přes přístup tvůrce.
• Foundry – přes nástroj Fabric IQ.
• MCP – publikovaný agent je MCP server s jedním nástrojem, jehož popis je popis agenta.

Popis při publikaci proto pište konkrétně. Nadřazený agent nebo Copilot se podle něj rozhoduje, kdy data agenta zavolat. A jedna věc pro ty, kdo řeší compliance: odpovědi mohou v těchto službách opustit compliance boundary Fabricu a zpracovává je cílová služba podle svých podmínek.

Fabric IQ v kostce

Kolem data agenta narazíte na název Fabric IQ. Je to zastřešení pro ontologii, semantic modely, Graph, Planning a data agenty. Stejný název ale nese i přepínač v Copilot pane a nástroj ve Foundry, takže se v tom snadno zamotáte. Jedna zkušenost z testu: se zapnutým přepínačem Fabric IQ mi Copilot verified answers nevracel, s vypnutým ano. Co všechna „IQ“ od Microsoftu znamenají, rozeberu v samostatném článku.

Závěr

Dnešní článek vám měl ukázat, kde končí Copilot a kde začíná data agent. Copilot je pro otázky nad jedním modelem v Power BI. Data agent pro odpovědi, které potřebují víc zdrojů nebo mají žít mimo Power BI. Základ je ale v obou případech stejný: připravený model a výpočetní pravidla v Prep data for AI, na jednom místě. A odpovědi agenta kontrolujte proti číslům, která znáte, dokud mu nebudete mít důvod věřit. Příště se podívám, co se změní, když data agenta pustíte do Foundry.

Oficiální dokumentace pro další studium: Fabric data agent concepts, Semantic model best practices for data agent, Add and configure data sources, Fabric data agent sharing and permission management, Data agent in Fabric consumption, What is Fabric IQ?