Det din rapport inte berättar för AI: så förbereder du din semantiska modell i Power BI

De flesta semantiska modeller i Power BI är byggda för att stödja rapporter som människor läser. Modellen innehåller mått och relationer, och allt annat överlåts till rapporten och personen som använder den.

Det har fungerat bra, eftersom människor själva fyller i luckorna. Men Copilot, MCP (Model Context Protocol), Fabric Apps och andra agenter tittar inte på rapporten. De ställer frågor direkt till modellen, och allt som tidigare fanns i rapportens layout och i analytikerns huvud saknas.

Om en analytiker måste förklara rapporten är modellen inte redo för AI

En välbyggd Power BI-rapport bär på mycket information som inte finns i modellen alls. Sidrubriken anger att siffrorna exkluderar koncerninterna försäljningar. Ett filter på sidnivå tar bort testkunder. En kommentar under ett visuellt objekt förklarar att innevarande månad uppdateras efter bokslutet. Layouten styr dig att först titta på försäljningen och sedan på antalet enheter.

Allt detta är affärslogik. Den hamnade i rapportlagret helt enkelt för att rapporten var det enda stället där någon använde datan.

Sedan finns logiken som alltid funnits i människors huvuden. Analytikern vet att måttet ”Sales v2” inte längre används, att kreditnotor bokförs i en annan månad än den ursprungliga fakturan och att en affärsenhets siffror kommer in en vecka sent. Inget av detta finns nedskrivet någonstans, eftersom ingen hittills har behövt det.

Rapportlager, semantiskt lager och semantisk modell – vad är skillnaden?

Rapportlagret är den del av dataarkitekturen som användarna ser: rapporter, dashboards och visualiseringar som byggs på datan.

Det semantiska lagret ligger mellan datan och rapporterna och innehåller affärslogiken. Det definierar vad datan betyder, hur mått beräknas och hur dataset hänger ihop, så att alla utgår från samma definitioner.

Den semantiska modellen är hur det semantiska lagret faktiskt implementeras. Den samlar tabeller, relationer, mått, beräkningar och hierarkier, och rapporterna byggs ovanpå den. I Power BI är den semantiska modellen det som tidigare kallades dataset.

Vad AI kan se – och vad den inte kan se

En AI-agent ser tabellerna, kolumnerna, måtten och relationerna i modellen, tillsammans med deras namn. Om du har fyllt i beskrivningar ser den även dem. Det är allt.

Den kan inte se sidfilter, rubriker, textrutor eller layout. Den vet inte vilket av dina fem försäljningsmått som är det rätta. Den vet inte att värdet 3 i ”Status_cd” betyder en annullerad order.

Det som händer sedan är förutsägbart. Agenten väljer ett mått utifrån namnet, räknar korrekt och levererar ett självsäkert svar som är fel för verksamheten. En människa hade reagerat, eftersom siffran hade sett konstig ut. Agenten har ingen känsla för vad som ser konstigt ut.

Det här är det verkliga skiftet. En rapport var utformad för någon som vet hur den ska läsas. För en agent är modellen den enda sanningskällan, så modellen måste uttrycka allt explicit.

Sju förändringar som gör din semantiska modell i Power BI AI-redo

1. Beskriv varje tabell, kolumn och mått

   Power BI har haft ett beskrivningsfält i flera år, men i de flesta modeller är det tomt. För en agent är beskrivningar den mest värdefulla information du kan ge. En bra beskrivning anger vad måttet beräknar, vad det utelämnar och när det ska användas.

   Till exempel: ”Nettoförsäljning exklusive koncernintern försäljning och kreditnotor. Använd när någon frågar om försäljning utan att specificera närmare.” → I praktiken: spara modellen i .pbip-format, använd ett Tabular Editor-skript för att lista alla mått som saknar beskrivning och låt AI skriva utkast till beskrivningar i TMDL-filerna, som en expert granskar före publicering.

2. Flytta rapportlogik till modellen

   Varje filter på sid- eller visualiseringsnivå som bär affärsmässig betydelse hör hemma i ett mått eller i själva modellen. Om testkunder alltid ska exkluderas bygger du in den regeln i modellen i stället för att upprepa den på varje rapportsida.

   → I praktiken: gå igenom rapportdefinitionerna i ditt .pbip-projekt, hitta filtren på sid- och visualiseringsnivå och flytta de permanenta undantagen till det semantiska lagret.

3. Behåll ett kanoniskt mått per begrepp

   Om modellen innehåller Sales, Sales v2, Sales (new) och Sales_FIN får agenten gissa. Ta bort dubbletterna, dölj hjälpmått och se till att varje affärsbegrepp har exakt ett tydligt mått.

   → I praktiken: hitta oanvända och överlappande mått med Measure Killer eller Best Practice Analyzer i Tabular Editor, och flytta dem till en dold mapp ”Deprecated” innan du raderar dem permanent.

4. Använd verksamhetens egna begrepp

   ”Fact_SalesLines” och ”Status_cd” är systemspråk. En agent klarar sig bättre med ”Försäljningsrader” och ”Orderstatus”, och kodvärden bör skrivas ut i klartext. Dölj tekniska nyckelkolumner som användarna inte behöver se.

   → I praktiken: byt namn på kolumner till affärsspråk i det semantiska lagret och översätt kodvärden med en underhållen mappningstabell, så att samma terminologi används i alla modeller.

5. Skriv ner de oskrivna reglerna

   Tyst kunskap måste dokumenteras: schemat för månadsbokslut, räkenskapsårets rytm, fördröjningar i datakällor och undantag från reglerna. Power BI erbjuder funktioner för att förbereda data för AI, som instruktioner till agenten och verifierade svar, men de är bara behållare. Först måste ni komma överens om reglerna med verksamheten.

   → I praktiken: lägg in reglerna i AI-instruktionerna i vyn ”Prep data for AI” i Power BI och versionshantera samma text bredvid modellen, så att ändringar granskas som kod. Du kan också dokumentera tyst kunskap i AI-instruktioner eller kontextfiler.

6. Bygg fokuserade modeller med ett tydligt syfte

   En jättemodell med 400 mått som täcker hela företaget är svår för en agent att arbeta med. En mindre modell med fokus på ett ämnesområde ger mer träffsäkra svar. Behandla varje modell som en produkt med en tydlig målgrupp och ett tydligt syfte.

   → I praktiken: bygg en separat semantisk modell för varje ämnesområde, till exempel försäljning eller ekonomi, och använd dataschemat i vyn ”Prep data for AI” för att bara exponera de tabeller och mått som områdets frågor kräver.

7. Hoppa inte över testfrågor och säkerhet

   Skriv 20 typiska affärsfrågor med rätt svar och kör dem genom agenten efter varje ändring i modellen. Då ser du direkt om något slutar fungera. Kontrollera samtidigt att säkerheten på rad- och objektnivå är i ordning. I en rapport såg användarna bara det som placerats på sidan. En agent kan fråga modellen om vad som helst.

   → I praktiken: validera datakvaliteten med tester, spara testfrågorna och de korrekta svaren som verifierade svar och kontrollera säkerheten på radnivå med ”View as” i Power BI Desktop.

Tekniskt enkelt, organisatoriskt svårt

Att skriva beskrivningar och städa upp bland måtten är tekniskt okomplicerat. Det svåra är att avgöra vilken definition som är rätt.

När en BI-utvecklare skriver ”nettoförsäljning exklusive kreditnotor” i en beskrivning fattar hen ett affärsbeslut. Om ekonomi och försäljning räknar marginal på olika sätt löser beskrivningen inte oenigheten. Den blottlägger den bara.

Därför bör varje centralt mått ha en affärsägare som godkänner definitionen. BI-teamet ansvarar för implementering och kvalitet, men definitionen tillhör den som ansvarar för den delen av verksamheten.

I den meningen är agenterna ett test för organisationen. De tvingar er att skriva ner det ni i åratal har avgjort i korridorsamtal.

Var ska du börja?

Du behöver inte åtgärda hela modellbiblioteket på en gång. Fyra steg räcker för att komma igång:

• Välj en modell som används brett och vars siffror är viktiga för ledningen.
• Dokumentera logiken i dess viktigaste rapporter: sidfilter, rubriker och textrutor.
• Avsätt en timme för att intervjua analytikern: vilka undantag har hen i huvudet när modellen används?
• Skriv 20 testfrågor, kör dem genom agenten och se var den snubblar.

Resultaten visar snabbt hur långt din modell är från att vara AI-redo. Ofta visar de också hur mycket ert datadrivna beslutsfattande har vilat på vad enskilda personer kommer ihåg.

Frågan är alltså inte om er analysplattform har stöd för Copilot, MCP eller Fabric Apps. Den är om er semantiska modell kan berätta för en agent det som er analytiker redan vet.