Než pustíte Copilot k datům, připravte sémantický model

Otázka „jaká byla minulý měsíc marže v jednotlivých regionech?“ zní jednoduše. Microsoft Copilot i Fabric data agent ale musejí před zodpovězením otázky udělat několik rozhodnutí. Vybrat správný zdroj. Určit, kterou z několika metrik marže použít. Rozpoznat období a nastavit filtry. Pokud pro tato rozhodnutí model nenabízí jednoznačná pravidla, vznikne technicky správný dotaz se špatným výsledkem. A pokud číslo vypadá věrohodně, nikdo si chyby nevšimne. Spolehlivost odpovědí proto není jen vlastností samotného nástroje. Je důsledkem toho, jak dobře je navržená a popsaná datová vrstva pod ním.

AI jako nový kolega v týmu

Představte si nového kolegu v analytickém týmu. Dostane model s tabulkami F_SLS nebo CALC_01, bez popisů a s několika podobně nazvanými metrikami. Význam bude odhadovat. Někdy se trefí, jindy sáhne po špatném sloupci nebo metrice.

AI je ve stejné situaci. Neví, že „tržby“ v jednom reportu znamenají fakturované výnosy a v jiném prodejní objednávky bez storna. Platí jednoduché pravidlo: pokud model rychle nepochopí nový kolega, nebude mu spolehlivě rozumět ani AI.

Problém je, že řada modelů vznikla jen jako podpora jednoho reportu. Obchodní logika je schovaná v dynamických metrikách a správný význam zajišťuje výchozí nastavení filtrů a přepínačů v reportu. Jenže konverzační nástroj report neovládá jako uživatel. Copilot nad otevřeným reportem sice jeho obsah vidí, ale přepínače za autora nenastaví. A Fabric data agent report nevidí vůbec, pracuje jen s modelem. Model připravený pro AI proto musí obstát sám o sobě. To znamená jasně pojmenované objekty, popisy, explicitně definované metriky a žádné téměř shodné varianty klíčových KPI.

Každý nástroj řeší něco jiného

Microsoft nabízí dvě cesty, jak se ptát přirozeným jazykem. Copilot v Power BI pracuje nad sémantickým modelem a reportem. Fabric data agent umožňuje kombinaci více zdrojů dat a integraci do další nástrojů. Umí vybírat mezi lakehousem, warehousem, sémantickými modely a KQL databázemi (nově také ontologiemi Fabric IQ a Microsoft Graphem) a podle typu zdroje generuje SQL, DAX nebo KQL. Vždy jen pro čtení a vždy s oprávněními konkrétního uživatele.

Pro návrh řešení je důležité vědět, co se kde dá ovlivnit. Pro sémantický model instrukce v datovém agentovi řeší jediné: na který zdroj poslat otázku. Když pak agent dotazuje sémantický model, staví DAX dotaz jen z metadat modelu a z konfigurace Prep data for AI. Tu lze nastavit pomocí tří nástrojů:

• AI data schema vymezí, které tabulky, sloupce a metriky má AI používat.
• AI instructions doplní firemní pojmy a pomůže v rozhodování při nejasnostech. Třeba že „aktivní zákazník“ má alespoň jednu dokončenou objednávku za posledních dvanáct měsíců.
• Verified answers vrátí u vybraných otázek předem schválenou odpověď místo nedeterministické generované.

Bez testů se neobejdete

Generativní AI je nedeterministická a stejný vstup ve stejném kontextu může vytvořit odlišný výstup. Uživatel se může na tutéž věc zeptat více způsoby, jazykový model se může časem změnit. Úspěšné demo tedy nic nedokazuje. Odpověď, která dnes vyšla správně, může zítra vyjít jinak.

Jediná obrana je testovací sada otázek a očekávaných správných odpovědí. Vezměte skutečné otázky z provozu a ke každé si zapište očekávaný zdroj, metriku, filtry, období a výsledek. Nekontrolujte jen výsledné číslo. Ověřte i cestu k němu, protože stejné číslo může vzniknout špatnou metrikou. Testy spouštějte po každé změně modelu, instrukcí i agentu. Důležité otázky opakovaně.

U českých nasazení otestujte i jazyk. Technologie má dnes oficiální podporu jen pro angličtinu. S českými dotazy a názvy sice funguje výborně, ale nesmíte to brát jako samozřejmost.

Co z toho plyne pro IT management

Konverzační AI přináší byznysu nové možnosti. Uživatel se k informacím dostane sám a hned, bez čekání na kolegu nebo na vyřízení požadavku na IT. Podmínkou správných odpovědí je ale model připravený na nového konzumenta. Doporučuji dva kroky před nasazením a dva za provozu:

• Úsilí směřovat primárně do sémantického modelu. Tam leží nejvíce možností k optimalizaci. Špatně navržený model nelze opravit instrukcemi v agentu.
• Přípravu modelu pro AI a testovací sadu zařadit do vývojového procesu. Konfigurace Prep data for AI a testy s očekávanými výsledky by měly být stejně samozřejmé jako code review.
• Sledovat, na co se uživatelé skutečně ptají. Reálné otázky odhalí slabiny modelu a průběžně doplňují testovací sadu.
• Naučit uživatele se správně ptát a poskytnuté odpovědi kriticky ověřovat. AI podává správnou i špatnou odpověď se stejnou sebejistotou.

Práce na kvalitě modelu se nakonec vrátí dvakrát. Jednou v podobě spolehlivějších odpovědí AI, podruhé v self-service analytice. Nad srozumitelným modelem zvládnou i netechničtí uživatelé připravit vlastní report a analýzu dat.

Autor: Martin Záruba, senior architect, Microsoft Fabric, Adastra