Blog Post

Power BI Community Blog
6 MIN READ

AI is Only as Smart as Your Model

sharvu's avatar
sharvu
Icon for Microsoft Employee rankMicrosoft Employee
4 months ago

A semantic layer translates technical data structures into business terms. It sits between the data storage platform and the analytics tools, letting consumers ask questions in natural language and, in turn, enabling conversational analytics. Last week, bhpat_msft and I discussed the importance of the Semantic Layer and how to build an AI-ready schema within Power BI semantic models at Power BI Days, hosted by the Power BI DC User Group.

 

The need for a semantic layer is not new. As data teams build and maintain ETL processes and develop the reports and dashboards that track business performance through trends and KPIs, they keep running into a familiar problem: the same metric with different definitions across the enterprise. A seemingly simple KPI can be calculated several ways from one business unit to the next. For the Operations function, Quantity may be the total quantity ordered. For Finance, Quantity may aggregate only fulfilled orders.

 

Quantity = SUM('Products'[Quantity])

Quantity = CALCULATE(SUM('Products'[Quantity]), FILTER('Orders', 'Orders'[FulfillmentStatus] = "Fulfilled"))

 

Within a single business function, this isn’t a problem. Operations and Finance may have their own reports and analytical products, and each monitors performance on its own terms. At the enterprise level, where consumers from both functions draw on the same content, it quickly becomes a problem that breeds confusion and distrust.

 

The problem gets worse when AI agents enter the picture, because the LLM behind an agent is grounded only in the context available to it through the semantic model. To avoid building and maintaining two separate models, teams may reach for a quick fix inside one model:

 

Quantity = SUM('Products'[Quantity])

Finance Quantity = CALCULATE(SUM('Products'[Quantity]), FILTER('Orders', 'Orders'[FulfillmentStatus] = "Fulfilled"))

 

But once a consumer turns to Copilot for Power BI or a Data Agent and asks a question in natural language, that quick fix can produce inconsistent answers.

 

Consumers carry implicit institutional knowledge that they rarely spell out. A Finance user might ask Copilot, “What is the Quantity for this month?” without specifying Finance Quantity, because to them it goes without saying that their definition is the one that applies. When the LLM scans the model, though, it returns the plain Quantity metric, which is the KPI Operations defined. To the Finance consumer, the answer looks wrong, and confusion and distrust follow.

 

A human analyst who has worked with the organization’s data absorbs that business logic through experience. When a Quantity number looks off, they can usually sense it and dig into why. The LLM behind an AI agent has none of that institutional memory, because the knowledge was never made explicit in the first place.

 

The real fix is to make that institutional knowledge explicit by embedding it in the semantic layer. Doing so produces more consistent, more accurate responses from AI experiences, and it builds the consumer trust that drives adoption.

Within Microsoft Fabric, the semantic layer is Fabric IQ, which has two components: semantic models and Ontologies.

The Semantic Foundation

A good semantic foundation matters even without AI, but with an LLM in the loop it matters more than ever. None of these practices are AI-specific, yet each carries more weight once consumers use AI experiences to query the model.

 

  • Data quality -  Poor data quality hurts performance and leads to inconsistent results. Common failures include missing keys in a dimension table, which cause referential integrity issues, and mismatched data types, which produce inaccurate results.
  • Model design - Power BI reports work best on a well-defined schema. Star and snowflake schemas with clearly defined fact and dimension tables perform best and make for a better consumer experience. Avoid many-to-many relationships and bi-directional filtering wherever you can, since both introduce ambiguity into the model.
  • DAX expressions - Complicated DAX hurts performance. Simplify your expressions and push complex transformations back to the source.
  • Security and access - Design with security in mind. Configure appropriate roles and filter expressions, and map user access on least privilege. Implement the right row-level and object/column-level security in the model, and test it for both performance and user experience.

Semantic Model Best Practices

Model optimization matters whether you’re using Copilot, a Data Agent, or neither. It keeps query execution efficient, which improves the experience for your consumers. With Copilot or a Data Agent in the mix, a well-optimized model produces better responses. Here are some best practices that can be used to optimize your semantic models:

 

  • Remove tables and columns you don’t use -  Too often, an entire tables are imported when only a handful of its columns are actively used within the semantic model. Dropping unused objects keeps the model lighter and faster.
  • Filter unnecessary rows - Keep only the data each table needs for reporting, and avoid retaining history “just in case.” Use techniques like incremental refresh to keep models lean and efficient.
  • Avoid redundancy -  When the same value lives in two places, such as a dimension attribute denormalized into the fact table, the model pays in memory and the LLM pays with a second field to disambiguate. Keep one canonical version, usually in the dimension, and let the relationship surface it elsewhere.
  • Disable Auto Date/Time and use your own date table - Power BI auto-generates a hidden date table for every date field, and those hidden tables consume storage that gets expensive across many dates or wide ranges. Build one central Date table and use it as your dimension.
  • Split date and time into separate columns -  First ask whether you need the time at all, because most of the time you don’t. If you do, split it into two columns so cardinality spreads across two narrower dictionaries instead of one wide one.
  • Reduce decimal precision in numeric fields -  Model size is driven by column cardinality, and decimals balloon unique values fast. Rounding can shrink a column dramatically when you have a lot of rows.
  • Use integer types, not text, for numeric fields - A billing document number stored as text takes more space than the same value as an integer, though the savings shrink as cardinality rises.
  • Group and aggregate detail your reports don’t surface -  Aggregate where you can, and be honest about columns that add detail without contributing to a report. Document line items and codes are the usual suspects.
  • Define calculations in measures -  Define your calculations explicitly in measures, which are computed at runtime and take up no storage. Leave them implicit and you let Power BI’s engine, or the LLM, decide which aggregation to apply based on context, and a SUM is not the same as an AVERAGE.
  • Document your semantic objects -  Use the Description field on tables, columns, and measures. Descriptions give the LLM more semantic context about what each object is and how to use it, and Copilot can generate a first draft for you.

Preparing your data for AI

Once the foundation is built, you can ground and curate the model so AI can generate accurate, trustworthy answers. Designing an AI-ready schema involves embedding institutional knowledge into the model itself, and you do that with the Prep for AI capabilities. They’re available in both Power BI Desktop and Fabric, so they fit cloud-native development as well.

 

  • Define the schema for Copilot. Decide which columns, tables, and measures Copilot can and can’t use. Tag and organize your fields, exclude noise or sensitive data, and keep results accurate, consistent, and business-relevant. This is how you control scope and make sure Copilot only uses trusted data.
  • Add verified answers. Set approved, model-grounded responses for the questions people ask repeatedly. Verified answers act as grounding references, so Copilot learns the correct way to respond to specific business questions.
  • Add context with AI instructions. Define business terms, synonyms, metrics, and KPIs, and give guidance on how the LLM should navigate your data and curate the right answers. You can even specify the persona or role you want the model to adopt with consumers. This helps Copilot interpret intent more accurately and improves the relevance of insights for end users.

None of this is glamorous work. But it’s the work that improves the performance of your semantic models and the accuracy of your AI-enabled analytics experiences, and ultimately leads to positive user experiences for your Consumers. 

Updated 3 months ago
Version 2.0

5 Comments

  • Great article! The connection between data quality, semantic models, and AI success is very important. Building a strong data foundation is the key to creating reliable AI-powered analytics experiences. Excited to keep learning more about Microsoft Fabric and AI.

  • Sejal56's avatar
    Sejal56
    Frequent Visitor

    Thank you for sharing this insightful article. I learned how an effective semantic layer improves AI-powered analytics by providing consistent business definitions. The best practices around semantic model optimization, data quality, and the "Prep for AI" features such as Verified Answers and AI Instructions were especially valuable. This article helped me better understand how to build trustworthy and AI-ready Power BI semantic models.