Merk
Tilgang til denne siden krever autorisasjon. Du kan prøve å logge på eller endre kataloger.
Tilgang til denne siden krever autorisasjon. Du kan prøve å endre kataloger.
Gjelder for:✅ Power Bi-tjeneste
En godt forberedt semantisk modell gir Copilot et sterkere grunnlag for å svare på forretningsspørsmål nøyaktig i Power BI. Før du introduserer Copilot for brukere, må du evaluere modellen og løse problemer som kan påvirke svarkvaliteten. Start med målene, relasjonene og forretningsdefinisjonene som allerede er brukt i rapportene. Løs modelleringsproblemer i den semantiske modellen fordi flere instruksjoner ikke kan rette unøyaktige relasjoner eller upassende aggregasjoner. Deretter optimaliserer du modellen for Copilot og etablerer en konsekvent gjennomgangsprosess.
Denne artikkelen er ment for semantiske modellforfattere, rapporteiere og team som introduserer Copilot for brukere. Det utfyller Still Copilot spørsmål om dataene dine, som beskriver hvordan brukere kan stille spørsmål og bekrefte resultatene. Denne artikkelen forklarer hvordan du klargjør semantisk modell og evaluerer svarene Copilot .
Merk
Vær oppmerksom på følgende krav:
- Administratoren må aktivere Copilot i Microsoft Fabric.
- Stoffkapasiteten må være i et av områdene som er oppført i denne artikkelen, fabric-områdetilgjengelighet. Hvis den ikke er det, kan du ikke bruke Copilot.
- Administratoren må aktivere leierbryteren før du begynner å bruke Copilot. Se leierinnstillingeneCopilot for mer informasjon.
- Hvis leieren eller kapasiteten er utenfor datagrensen for USA eller EU, Copilot deaktiveres som standard. Det eneste unntaket er hvis Fabric-leieradministratoren aktiverer at dataene som sendes til Azure OpenAI, kan behandles utenfor leierens geografiske område, samsvarsgrense eller leierinnstilling for nasjonal skyforekomst. Du finner denne innstillingen i administrasjonsportalen for infrastruktur.
- Copilot i Microsoft Fabric støttes ikke på prøveversjon av SKU-er. Bare betalte SKU-er støttes.
- Hvis du vil se den frittstående Copilot opplevelsen i Power BI, må leieradministratoren aktivere leierbryteren.
Merk
I den Power Bi-tjeneste nettmodelleringsopplevelsenCopilot kan du gjøre mer enn å evaluere modellen. Den kan også foreslå og bruke endringer direkte, for eksempel gi nytt navn til tabeller og kolonner, opprette relasjoner og generere DAX-mål. Optimaliseringsveiledningen i denne artikkelen støtter direkte bedre resultater fra denne analysen: En godt strukturert, tydelig navngitt modell bidrar til å Copilot gi mer nøyaktige og nyttige forslag.
Start med fokuserte forretningsspørsmål
Velg et fokusert forretningsscenario og identifiser spørsmålene brukerne ofte stiller. For hvert spørsmål definerer du forventet måling, gruppering, datobasis, filtre og validert resultat.
Inkluder spørsmål som viser tvetydighet. Hvordan fungerer for eksempel salg? Kan det referere til omsetning, ordrevolum, vekst eller margin. Definer en standard tolkning, eller be om Copilot en avklaring.
Start med spørsmål om totaler, sammenligninger, rangeringer og trender som den semantiske modellen støtter. Legg til mer komplekse spørsmål etter Copilot svar på det første settet konsekvent.
Se gjennom og forbedre den semantiske modellen
Bruk anbefalingene i tabellene nedenfor til å Copilot tolke den semantiske modellen og forbedre svarkvaliteten.
Modellstruktur
| Element | Vurdering | Bekrivelse | Hvor du skal søke | Eksempel |
|---|---|---|---|---|
| Kobling av tabell | Definer klare relasjoner | Du kan tydelig definere alle relasjoner mellom tabeller og kontrollere at de er logiske. Angi hvilke relasjoner som er én-til-mange, mange-til-en eller mange-til-mange. | Velg Behandle relasjoner i modellvisning | Opprett en én-til-mange-relasjon fra Date[DateID] til Sales[DateID] , og kontroller at relasjonen er aktiv. |
| Faktatabeller | Fjern formål og detaljnivå | Identifiser faktatabeller tydelig, og definer hva hver rad representerer. Sørg for at beregninger bruker aggregasjoner som passer for dette detaljnivået. | I tabellegenskaper og modellstrukturen | Faktatabeller for navn tydelig, for eksempel FactSales, og beskriv detaljnivået, for eksempel én rad per ordrelinje. |
| Dimensjonstabeller | Støttende beskrivende data | Opprett dimensjonstabeller som inneholder beskrivende attributter relatert til kvantitative mål i faktatabeller. | I tabellegenskaper og datamodellstruktur | Opprett dimensjonstabeller som DimProduct med attributter (ProductName, Category, Brand) og DimCustomer med attributter (CustomerName, City, Segment). |
| Hierarkier | Logiske grupperinger | Opprett klare hierarkier i dataene, spesielt for dimensjonstabeller som støtter neddrilling i rapporter. | Velg Nytt hierarki i hurtigmenyen for tabellen | Opprett et hierarki i Date tabellen:Year>Quarter>Month>Day . I Geography tabellen:Country/Region>State>City . |
| Relasjonstyper | Tydelig spesifisert | Hvis du vil sikre nøyaktig rapportgenerering, må du tydelig angi relasjonstypen (aktiv eller inaktiv) og kardinaliteten. | I dialogboksen for relasjonsegenskaper | Sett Date til Sales som Mange-til-én (aktiv), Product til Sales Mange-til-én (aktiv), og merk rollespillrelasjoner som inaktive når det er aktuelt. |
Mål og KPI-er
Copilot kan opprette ad hoc-beregninger, men legge til ofte brukte eller forretningskritiske beregninger i den semantiske modellen som gjennomgåtte mål. Denne tilnærmingen gir rapportforfattere og Copilot konsekvente forretningsdefinisjoner å bruke.
| Element | Vurdering | Bekrivelse | Hvor du skal søke | Eksempel |
|---|---|---|---|---|
| Tiltak | Standardisert beregningslogikk | Gi mål standardisert, klar beregningslogikk som er enkel å forklare og forstå. | Egenskapen Definisjon og beskrivelse av mål | Mål DAX: Total Sales = SUM(Sales[SaleAmount]) og legg til beskrivelsen: «Summen av alle salgsbeløp». |
| Tiltak | Navnekonvensjoner | Gi målnavn som tydelig gjenspeiler beregningen og formålet. | I feltet Målnavn når du oppretter mål | Bruk beskrivende navn: Average Customer Rating i stedet for forkortet: AvgRating. |
| Tiltak | Forhåndsdefinerte og gjennomgåtte mål | Opprett gjenbrukbare mål for vanlige forespørsler og forretningskritiske beregninger. Se gjennom logikken slik at rapportforfattere og Copilot bruke konsekvente forretningsdefinisjoner. | I måldefinisjonen og beskrivelsesegenskapen | Definer [Net Sales] med godkjent behandling av returer, rabatter og kansellerte ordrer. Inkluder ofte forespurte mål som hittil i år salg og måned-over-måned vekst. |
| Tiltak | Forholdstall | Definer forhold med riktig virkemåte for teller, nevner og aggregasjon. | I måldefinisjonen | Definer [Gross Margin %] ved å dele det godkjente bruttofortjenestemålet med det godkjente nettosalgsmålet i stedet for gjennomsnittlige prosenter på radnivå. |
| Tiltak | Antall | Opprett separate mål når antall rader og antall forretningshendelser representerer ulike resultater. | I måldefinisjonen | Definer [Order Count] separat fra [Order Line Count]. |
| Tiltak | Punkt-i-tid-saldoer | Bruk mål som aggregerer øyeblikksbilder på riktig måte på tvers av produkter, plasseringer og datoer. | I måldefinisjonen | Definer et mål for sluttlager i stedet for å summere daglige øyeblikksbilder av lager på tvers av datoer. |
| Tiltak | Visningsformater | Bruk formater som gjør enheten og skalaen for hvert mål klart. | I målformategenskapen | Formater pengemål som valuta, forhold som prosenter og teller som heltall. |
| KPI-er (Key Performance Indicators) | Forhåndsdefinert og relevant | Opprett et sett med KPI-er som er relevante for forretningskonteksten og vises ofte i rapporter. | Opprette mål for ofte sporede KPI-er | Definer mål som ROI = DIVIDE([Profit], [Investment]), CAC = DIVIDE([Marketing Spend], [New Customers]), LTV = [Avg Order Value] * [Purchase Frequency] * [Customer Lifespan]. |
Kolonner og datakvalitet
| Element | Vurdering | Bekrivelse | Hvor du skal søke | Eksempel |
|---|---|---|---|---|
| Kolonnenavn | Entydige etiketter | Gjør kolonnenavn entydige og selvforklarende. Behold nyttige forretningsidentifikatorer, men unngå ID-er eller koder som krever ytterligere oppslag uten kontekst. | Gi nytt navn til kolonner i Power Query-redigering eller modellvisning | Gi nytt navn til kolonne fra ProdID til Product ID eller Product Name, og fra CustNo til Customer Number. |
| Kolonnedatatyper | Riktig og konsekvent | Bruk riktige og konsekvente datatyper for kolonner på tvers av alle tabeller for å sikre at målene beregnes riktig, og for å aktivere riktig sortering og filtrering. | Angi datatype i kolonneegenskaper | Sørg for Sales[SaleAmount] at desimaltall (ikke tekst), Date[Date] er dato (ikke tekst), Product[ProductID] er heltall. |
| Datakonsekvens | Standardiserte verdier | Vedlikehold standardiserte verdier i kolonner for å sikre konsekvens i filtre og rapportering. | Bruke Søk og erstatt eller Power Query-transformasjoner | I Status kolonnen må du sørge for at alle verdier bruker konsistente store og små bokstaver: Open, Closed, Pending (ikke store og små bokstaver som open, CLOSED). |
| Datokolonner | Fjern forretningsmessig betydning | Skille datoer med ulike forretningsmenyer. Dokumenter om perioder bruker et regnskapsår eller kalenderår, inkludert når regnskapsåret starter. Bruk datokolonner og -relasjoner i stedet for bare å stole på tekstetiketter. | I datotabeller, relasjoner og beskrivelsesegenskaper | Bruk distinkte Order Date kolonner og Shipment Date kolonner. Definer kolonner for regnskapsperioder i stedet for bare å stole på etiketter som Q1. |
| Viktige kolonner | Fullstendige og unike verdier | Adressen mangler eller dupliserte nøkler slik at relasjoner og beregninger gir nøyaktige resultater. | I Power Query transformasjoner og kildedata | Kontroller at hver rad i en kundedimensjon har en unik, ikke-tom kundenøkkel. |
Oppdatering, sikkerhet og metadata
| Element | Vurdering | Bekrivelse | Hvor du skal søke | Eksempel |
|---|---|---|---|---|
| Tidsplaner for oppdatering | Gjennomsiktig og planlagt | Kommuniser tydelig oppdateringsplanene for dataene for å sikre at brukerne forstår aktualiteten til dataene de analyserer. | I datasettinnstillinger og dokumentasjon | Legg til en tekstboks eller beskrivelse som sier: «Data oppdateres daglig kl. 06:00 UTC» eller «Sanntidsdata med 15-minutters trinnvis oppdatering». |
| Sikkerhet | Definisjoner på rollenivå | Definer sikkerhetsroller for ulike nivåer av datatilgang hvis det finnes sensitive elementer som ikke alle brukere skal se. | Velg Behandle roller i modellvisning | Opprett rolle "Salgsteam" med filter: Sales[Region] = USERNAME() og rolle "HR" med filter på ansattdatatabeller. |
| Metadata | Dokumentasjon av struktur | Som referanse kan du dokumentere strukturen til datamodellen, inkludert tabeller, kolonner, relasjoner og mål. | Bruk beskrivelsesegenskaper og ekstern dokumentasjon | Legg til beskrivelser i tabeller og kolonner. Opprett et eget dokument med modelldiagram, dataordbok og målkatalog. |
Vurderinger for DAX-spørring
Tabellen nedenfor viser andre vilkår som kan hjelpe deg med å opprette nøyaktige DAX-spørringer (Data Analysis Expressions) med Copilot. Disse anbefalingene kan hjelpe deg med å generere nøyaktige DAX-spørringer.
| Element | Vurdering | Bekrivelse | Hvor du skal søke | Eksempel |
|---|---|---|---|---|
| Mål, tabeller og kolonner | Beskrivelser | I beskrivelsesegenskapen definerer du hvert element og hvordan du har tenkt å bruke det. Begynn med forretningsmessig betydning, enhet og viktige utelukkelser. Copilot bruker bare de første 200 tegnene. | I Egenskaper-ruten, Beskrivelse-feltet for mål, tabeller og kolonner | For mål [YOY Sales]legger du til beskrivelse: "Forskjell fra år til år (YOY) i ordrer. Bruk den med «Dato»[År]-kolonnen for å vise etter andre år enn det siste året. Delår kan sammenlignes med samme periode året før.» |
| Beregningsgrupper | Beskrivelser | Modellmetadataene inneholder ikke beregningselementer. Bruk beskrivelsen av beregningsgruppekolonnen til å vise og forklare hvordan du bruker beregningselementene. Copilot bruker bare de første 200 tegnene. | I Egenskaper-ruten for kolonnen for beregningsgruppen | For kolonnen Eksempelberegningsgruppe for tidsintelligens legger du til beskrivelse: "Bruk med mål og datotabell for Gjeldende: gjeldende verdi, MTD: hittil i måned og QTD: hittil i kvartal, hittil i år, hittil i år, PY: forrige år, PY MTD, PY QTD, YOY: endring fra år til år, YOY%: YOY som en %." For en måltabell legger du til: «Mål brukes til å aggregere data. Disse målene kan vises som år over år ved hjelp av denne syntaksen CALCULATE([Measure Name], Time intelligence[Time calculation] = YOY)." |
Feilsøke testresultater
Se gjennom den genererte spørringen og resultatene for å identifisere kilden til et problem før du oppdaterer ai-instruksjonene.
| Problem | Hva du bør kontrollere |
|---|---|
| Feil forretningsmetrikk | Se gjennom målnavn, beskrivelser, ai-dataskjemavalg og instruksjoner som definerer standard måledata. |
| Uventet total- eller tidsperiode | Sammenlign filterkonteksten og datogrunnlaget med det forventede resultatet. Deretter kan du se gjennom relasjonsvirkemåte og aggregasjonslogikk. |
| Manglende kategorier eller ingen resultater | Kontroller kildedataene, oppdateringsstatusen, kategoriverdiene, forespurt periode og forbrukerens tillatelser. Ikke tolke noe resultat som null. |
| Rette data med en villedende presentasjon | Se gjennom enheter, formatering, sortering og om forklaringen sier mer enn dataene støtter. |
| Treg eller mislykket respons | Undersøk den genererte spørringen og semantiske modellytelsen. Sammenlign spørringen med en validert referansespørring før du endrer forretningsveiledning. |
| Forberedelse av data for ai-endringer gjenspeiles ikke | Bekreft at du har endret riktig semantisk modell og gi tid til at endringene trer i kraft. Lukk og åpne ruten på Copilot nytt, og kontroller eventuelle krav til distribusjon og oppdatering. |
Hvis du vil ha informasjon om testing, distribusjon og oppdateringskrav, kan du Copilot se Teste verktøyendringer og vurderinger og begrensninger.