Fabric IQ 讓 AI 讀懂公司指標：問營收之前，先確認大家算的是同一件事
Fabric IQ 接上 Power BI 的指標與資料關係。從營收問題，理解企業 AI 為何需要共同定義、權限與更新時間。
會議中有人問這個月營收多少，財務、業務與營運可能各自打開一張表。數字不同，未必有人算錯：一個算已收款，一個算已簽約，另一個扣除退貨。把三張表交給 AI，模型可以很快寫出答案，但它需要先知道這次提問所指的營收是哪一種。
Microsoft 在 2026 年 9 月的資料產品發布中，宣佈 Fabric IQ 在 Copilot Chat 與 Cowork 正式推出。官方說明，這項整合讓 AI 使用 Power BI 語意模型中的指標、資料關係與業務定義。Microsoft 資料主管在 X 的相關貼文查核時有超過兩萬次瀏覽，討論重點是把模型和公司脈絡接在一起。
我的判斷是：Fabric IQ 的價值，要從「公司是否已有可信的共同指標」評估。它提供把既有定義帶進 AI 工作的方向，資料整理與責任分工仍需要人完成。如果每個部門連營收怎麼算都沒有共識，讓 AI 更容易取得資料，只會更快遇到同一個爭議。
語意模型，保存數字背後的業務意思
語意模型可以理解成資料的共同說明書。它描述有哪些資料、如何關聯，以及某個指標應怎麼計算。Power BI 是 Microsoft 的商業分析工具，團隊常用它建立報表。語意模型中的定義，讓不同報表能使用同一套計算方式，減少各自重新解讀原始欄位的情況。
例如訂單表記錄成交金額，退款表記錄退款，商品表記錄產品分類。計算某個品類的淨營收，需要知道表與表怎麼連接，也需要決定是否扣除退款。若只看到一個叫做金額的欄位，AI 無法由名稱得知完整規則。共同模型把這些關係與計算先保存下來。
這對問答很重要，因為自然語言容易省略條件。使用者說本季業績，可能沒有說日期依成交、出貨還是收款。系統若能使用公司的標準定義，回答會更有一致的基礎。但若公司允許多種口徑，就應讓回答顯示採用哪一種，而不是默默把其中一種當成唯一答案。
共同說明書也需要維護者。業務規則改了，舊定義就可能失準。可以指定每個關鍵指標的負責人，保留生效日期與修改原因。這樣 AI 回答和既有報表出現差異時，團隊才知道應檢查資料、定義，還是更新時間，避免所有問題都被歸因於模型。
這次正式推出的是哪些整合？
Microsoft 官方發布把 Fabric IQ 的 Copilot Chat 與 Cowork 整合列為正式推出，並說明會保留既有資料存取與治理方式。依發布內容，這項能力對 Fabric 與 Power BI 客戶預設開啟。實際看到的功能與可存取範圍，仍要以組織帳號和管理設定確認。
同一篇發布也提到其他資料產品，但階段並不相同。例如跨組織脈絡分享屬於預覽，其他開發整合仍有後續安排。讀產品新聞時，應把每一項功能的狀態分開，避免把一個已正式推出的整合，延伸成所有新能力都已可以立即使用。
本文聚焦的是 AI 如何取得一致業務定義，沒有實際登入企業租戶或量測回答正確率。官方說明能證明產品提供的整合方向，無法代替某家公司自己的導入結果。若既有模型完整，試做起點可能較好，但是否減少錯誤，仍需對照實際問題與報表。
在規劃導入時，可以先盤點目前哪些報表已有共用模型，哪些仍由個人試算表維護。兩者的準備工作不同。前者可先檢查定義是否清楚，後者可能需要先整合欄位與計算規則。產品入口能否開啟，和資料是否適合拿來回答，是兩個要分別確認的項目。
用營收問題檢查定義是否完整
假設一家公司想讓同事詢問上月營收變化。第一步應先寫出營收的標準口徑，包括是否含稅、是否扣退款、幣別如何處理，以及日期依哪個事件計算。這是本文的示範情境，沒有對應某個客戶的實測成果。條件愈清楚，後續回答愈容易和報表對照。
接著檢查月份。公司若使用會計期間，可能和曆月不同。月底訂單跨時區，也可能被分到不同日期。這些因素會讓看似簡單的上月兩字變得模糊。對一般同事，回答最好附上實際涵蓋期間，讓讀者知道比較的是哪些交易。
品類與客戶範圍也需要明確。產品重新分類、公司合併客戶帳號，都可能讓同一個問題在不同時間得到不同結果。若要比較前後變化，應知道分類採用當時狀態，還是目前重新整理後的狀態。這種選擇會影響結論，不能只由 AI 自行猜測。
最後，資料缺口要有標記。如果部分地區尚未更新，報表應顯示涵蓋範圍。回答沒有找到資料，和營收真的為零，是完全不同的情況。讓系統保留缺少與未更新狀態，能避免一句流暢的摘要把問題遮住，讓讀者誤以為數字已完整。
一致定義，也要搭配正確權限
某個指標已在公司內定義好，不代表每個人都能讀取所有底層資料。業務可能能看自己的區域，主管能看整個部門。AI 問答應延續這種分工，才不會因為換成聊天介面，就讓原本無法取得的細節出現在回答中。
官方強調保留存取與治理方式，導入驗證仍應使用不同角色的測試帳號。確認每個角色能取得預期資料，也確認無權限的範圍是否被排除。不要只用管理員帳號試問一次，因為管理員的成功回答，不能代表一般同事看到的結果。
權限還有解釋問題。使用者拿到較小範圍的數字，可能不知道自己只能看其中一區。回答可以在不揭露額外資料的前提下，說明目前可用範圍。若不同角色比較回答，也應先確認範圍一致，避免把合理的權限差異當成模型回答不穩定。
跨組織分享則需要另外評估。合作夥伴可能需要共同指標，但未必需要每筆明細。先決定分享內容、目的與接收角色，再研究對應能力。這個問題和內部問答不同，不能因為資料模型已建立，就直接沿用相同開放範圍。
資料更新時間，會改變回答的用途
一致的指標，仍可能使用不同時間更新的資料。昨天完成更新的報表，無法反映今天剛發生的退款。AI 回答若沒有顯示資料日期，使用者可能把歷史狀態當成即時狀態。對營收、庫存與交付進度，這項差異會直接影響下一個決定。
可以把更新時間當成回答的一部分。先說明數字依據的資料截至何時，再解釋趨勢。若資料延遲，應保留延遲標記，而不是用模型推估補滿。資料管線故障時，流暢回答反而更容易造成誤會，因為看起來完整的文字不會自然暴露更新問題。
變化分析也應使用一致時間窗口。比較完整上月和本月前幾天，通常需要說明差異。若想判斷成長，應先決定是比較相同天數，還是使用完整結算期間。這是分析設計上的選擇，應由問題目的決定，而非讓系統為了快速回覆挑一個方便的數字。
團隊可以為常見問題整理一份回答規格。營收問題附口徑與期間，庫存問題附更新時間，客戶分佈問題附範圍。規格不必很長，但要保留會改變讀者理解的條件。這能讓 AI 產物更容易覆核，也讓不同同事的提問有共同的品質標準。
驗證回答，要回到可重算的資料
試做時，可以先選一組有確定答案的問題，讓 AI 與既有報表分別回答。比較不只看最終數字，還應看計算條件、資料期間與涵蓋範圍。兩個數字剛好相同，仍可能使用不同方法，下一次資料改變時就會出現差異。
對變化原因尤其要小心。資料能顯示某品類下降，不一定能證明下降由某次活動造成。AI 可以提出值得調查的方向，但結論應區分觀察到的現象與尚未驗證的解釋。保留這個區分，能避免簡短摘要把相關性寫成因果。
出現差異時，先建立問題紀錄，附原問題、回答、參考報表與日期。再判斷是定義缺少、權限不同、資料延遲，還是系統解讀錯誤。這種分類能讓負責人針對原因改善，不必每次都重寫提問，期待某一種措辭偶然得到正確答案。
調整後，只需重查受影響問題與必要的共同指標。若修改的是退款定義，相關營收問題需要重驗，其他完全無關的數字未必需要全量重做。明確的依賴關係能降低維護負擔，也讓團隊在更新規則後，知道哪些回答需要重新確認。
驗證也應包含問題的不同說法。同事可能問銷售額、業績或營收，這些詞在公司內未必完全相同。如果系統把所有詞都對應到同一個指標，應確認這是團隊接受的規則。若需要追問，應讓追問具體說明差別，例如要看已簽約金額還是已收款金額，幫助使用者做選擇。
另一類重要測試是無法回答的問題。使用者可能詢問尚未收集的資料，或需要沒有權限的明細。可靠流程應指出缺口，並說明可提供的替代範圍。若每個問題都有一段完整回答，反而要確認系統是否用不相干數字湊出結論。能清楚表示資料不足，是企業問答品質的一部分。
團隊還可以保留幾個容易混淆的問題作為固定檢查。每次更新模型或資料定義後，重新查看這些問題，就能較早發現解讀變化。這份小型檢查集應包含真實業務差異，避免只留下字面上很清楚的題目，讓測試成績與日常使用脫節。
常見問題
公司一定要重新整理所有資料嗎？
可以從已有共用語意模型的一個流程開始。先確認關鍵指標定義、負責人與更新方式，再做問答比較。沒有共同定義的資料，通常需要更多準備。導入範圍應由資料成熟度決定，無須第一輪就涵蓋全公司。
AI 回答和報表一樣，是否就可以直接使用？
應再確認期間、範圍與計算口徑。數字相同只是第一步，回答對變化原因的解釋也需要證據。對重要決策，保留可回查資料與負責人，能讓讀者知道結論如何形成，以及哪些部分仍需調查。
所有發布的新功能都已正式推出嗎？
各項狀態不同。Fabric IQ 在 Copilot Chat 與 Cowork 的整合列為正式推出，同篇發布的其他能力包含預覽與後續安排。採用前應確認自己需要的那項功能，避免把整場發布視為同一個可用階段。
讓 AI 回答之前，先建立共同的數字語言
Fabric IQ 的新聞，反映企業 AI 正走向更深的資料脈絡。模型要答對公司的問題，需要知道欄位如何關聯，也需要知道公司如何解釋指標。這些定義若已被整理成共同資產，AI 問答就有更清楚的起點。
下一步可以挑一個每週都會被問到的指標，寫出定義、資料日期與可看角色，再準備幾個有確定答案的問題。用這些問題對照既有報表與 AI 回答。當差異能被解釋與修正，才有理由把問答範圍逐步擴大。
