Microsoft Fabric 中的資料代理是一項一般可用的功能，讓你能透過生成式人工智慧建立屬於自己的對話式問答系統。Fabric 資料代理讓組織內的每個人都能取得更易取得且可執行的資料洞察。 透過使用 Fabric 資料代理，您的團隊可以用簡單的英文問題與組織在 Fabric OneLake 中儲存的資料進行對話，並獲得相關答案。 如此一來，即使是沒有 AI 技術專長或不熟悉資料結構的人，也可以獲得精確且內容豐富的答案。 在 Microsoft Fabric 更廣泛的代理式應用程式架構中，資料代理作為對話式分析元件，透過湖屋、倉庫、語意模型及多代理解決方案中的 KQL 資料庫，連接 OneLake 中的受管控資料。
您也可以加入針對組織的指示、範例與指引，以微調 Fabric 資料代理。 此方法確保回應符合組織的需求與目標，讓每個人都能更有效地參與數據。 Fabric Data Agent 培養了以數據為基礎的決策文化，因為它降低了洞察可及性的障礙，促進協作，並協助您的組織從數據中提取更多價值。
先決條件
- 付費的 F2 或更高級別的 Fabric 容量，或啟用 Microsoft Fabric 的 Power BI Premium（P1 或更高級別）容量。
- 根據 Fabric 資料代理租戶設定中說明的需求，啟用 AI 的跨地理處理與跨地理儲存功能。
- 至少有一個資料來源，包含資料：倉庫、湖屋、Power BI 語意模型、KQL 資料庫、鏡像資料庫或本體。 你必須有讀取權限存取資料來源。
治理前提條件
如果您的租戶或工作空間受 Microsoft Purview 政策管理，代理程式必須在這些政策內運作。 以下 Purview 政策可根據敏感度與政策配置限制代理存取及代理回傳的結果：
- Purview DLP 政策在 Fabric Data Warehouse（現已全面提供）：DLP 政策可以偵測並限制代理在查詢倉庫資產時對敏感資料的存取。
- 存取限制政策（預覽）針對 Fabric KQL 資料庫、Fabric SQL 資料庫及 Fabric Data Warehouse：這些政策可防止代理存取或回傳被歸類為敏感資產的結果。
Fabric 資料代理的運作方式
Fabric 資料代理使用大型語言模型（LLM）幫助使用者自然地與其資料互動。 Fabric 資料代理套用 Azure OpenAI 助理 API，行為類似代理。 它處理使用者問題，決定最相關的資料來源（Lakehouse、Warehouse、Power BI 資料集、KQL 資料庫、本體論或 Microsoft Graph），並呼叫適當的工具來產生、驗證及執行查詢。 使用者可以用淺顯語言提問，並獲得結構化且易讀的答案。 此方法免除撰寫複雜查詢的需求，確保資料存取準確且安全。
以下是其運作方式：
問題解析與驗證：Fabric資料代理將 OpenAI 助理 API 應用於底層代理Azure處理使用者問題。 此方法可確保問題符合安全性通訊協定、負責任的 AI (RAI) 原則和使用者權限。 Fabric 資料代理程式也遵守 Microsoft Purview 對底層 Fabric 資料來源的治理控制，包括資料遺失防護（DLP）及存取限制政策。 政策執行可能會阻止某些查詢執行，或特定資料無法在回應中被顯示。 Fabric 資料代理嚴格執行唯讀存取，維持所有資料來源的唯讀連線。
Enforcement 機制：Fabric資料代理在處理過程中會加以多層保護。 它利用請求使用者的憑證與權限來強制執行最低權限存取，確保每次互動僅存取使用者被授權查看的資料。 代理程式會在執行任何動作前，根據租戶與工作空間的政策設定評估請求。 保護欄限制工具呼叫及輸出至有範圍的資料來源，防止查詢到達設定範圍外的資源。 你可以選擇整合 Azure AI Content Safety 來套用內容風險控管，幫助減少有害或違反政策的回應。
資料來源識別：Fabric資料代理使用使用者的憑證來存取資料來源的結構。 此方法確保系統取得使用者有權限查看的資料結構資訊。 代理人接著會根據所有可用資料來源評估使用者的問題，包括關聯式資料庫（Lakehouse 和 Warehouse）、Power BI 資料集（語意模型）、KQL 資料庫、本體論以及 Microsoft Graph。 它也可能會參考使用者提供的資料代理程式指示，以判斷最相關的資料來源。 對於 Power BI 語意模型，代理程式利用使用者對模型的讀取權限來取得結構與中繼資料以產生查詢;代理驅動查詢不需要建置權限。
工具調用與查詢產生：一旦識別出正確的資料來源或來源，Fabric資料代理會重新表述問題以求清晰與結構化，然後呼叫相應工具產生結構化查詢：
- 關聯式資料庫 (Lakehouse/Warehouse) 的自然語言轉為 SQL (NL2SQL)。
- 自然語言轉 DAX（NL2DAX）用於 Power BI 資料集（語意模型）。
- 將自然語言轉換為 KQL (NL2KQL) 用於 KQL 資料庫。 NL2KQL 可以在所選資料庫中使用 KQL 使用者定義函式（UDF）。
- 透過 Microsoft Graph 查詢組織資料，並使其可存取。
所選工具會根據所提供的結構、元資料和上下文產生查詢，而 Fabric 資料代理底層的代理會再傳遞這些內容。
查詢驗證：工具執行驗證以確保查詢正確形成，並遵守自身的安全協定與 RAI 政策。
查詢執行與回應：驗證後，Fabric資料代理會針對所選資料來源執行查詢。 結果會格式化為人類可讀取的回應，其中可能包含結構化資料，例如資料表、摘要或重要見解。
透過這種方式，使用者可以用自然語言與他們的資料互動。 Fabric 資料代理負責查詢產生、驗證與執行的複雜性。 使用者不需要自己寫 SQL、DAX 或 KQL。
Microsoft Purview 的安全與治理
Microsoft Purview 為 Fabric 資料代理提供治理與風險控管。 這些功能目前處於預覽階段，幫助組織在使用代理存取 Fabric 資料時維持合規性。 主要功能包括：
- 風險發現與稽核：Fabric資料客服的提示與回應可納入 Purview 風險發現與稽核，讓資安團隊能掌握客服人員如何與組織資料互動。
- DSPM 資料風險評估：資料安全態勢管理（DSPM）資料風險評估能揭露客服人員使用資料來源中的敏感資料風險，協助您識別並處理潛在風險。
- 內部風險管理：Purview 內部風險管理能偵測涉及客服人員的高風險 AI 使用模式，如異常查詢量或敏感資料存取。
- 稽核、電子發現與保留：Purview 稽核、電子發現與保留政策適用於支援Fabric工作負載中的客服人員互動與輸出。 不合規的使用偵測也可能標記違反組織政策的代理行為。
欲了解更多關於 Microsoft Purview 如何與 Fabric 整合的資訊，請參見 使用 Microsoft Purview 來治理 Microsoft Fabric。
Fabric 資料代理設定
設定 Fabric 資料代理類似於建立 Power BI 報告——你先設計並精煉它，確保符合需求，然後發布並與同事分享，讓他們能與資料互動。 建立 Fabric 資料代理程式包括：
選擇資料來源：Fabric資料代理可支援最多五個資料來源，可任意組合，包括湖屋、倉庫、KQL 資料庫、Power BI語意模型、本體論及Microsoft Graph。 例如，一個已設定的 Fabric 資料代理可以包含五個 Power BI 語意模型。 它可以包含兩個 Power BI 語意模型、一個 lakehouse 和一個 KQL 資料庫的混合。 您有許多可用的選項。
選擇相關資料表：選擇資料來源後，逐一新增，並定義Fabric資料代理所使用的每個來源的具體資料表。 此步驟確保 Fabric 資料代理僅聚焦於相關資料，取得準確結果。 對於湖屋來說，這一步就是選擇湖屋資料表（而不是單一的湖屋檔案）。 如果你的資料一開始是以檔案形式（例如 CSV 或 JSON），請將其匯入資料表或以其他方式透過資料表讓代理程式能夠存取。
Adding Context：為提升Fabric資料代理的準確度，請透過Fabric資料代理指令與範例查詢提供更多上下文。 作為 Fabric 資料代理的底層代理，這個上下文幫助 Azure OpenAI 助理 API 做出更明智的決策，如何處理使用者問題，並判斷哪個資料來源最適合回答這些問題。
Data agent instructions：新增指令，指導Fabric資料代理的代理人，決定最適合回答特定問題的資料來源。 您也可以提供自訂規則或定義，以釐清組織術語或特定需求。 這些指示可以提供更多內容或喜好設定，以影響代理程式選取和查詢資料來源的方式。 例如，將有關財務指標的問題直接指向 Power BI 語意模型，將涉及原始資料探索的查詢指派到資料湖屋，並將需要日誌分析的問題導向 KQL 資料庫。
範例查詢：加入範例問題-查詢對，說明Fabric資料代理人應如何回應常見查詢。 這些範例可作為代理程式的指南，可協助其瞭解如何解譯類似問題並產生精確的回應。
備註
目前 Power BI 語意模型資料來源尚不支援新增範例查詢/問題配對。
透過結合清晰的 AI 指示與相關範例查詢，您可以更好地將 Fabric 資料代理與組織的資料需求對齊，確保回應更準確且具情境感知。
這很重要
開發者提供的資料代理指令與範例查詢必須在組織與角色基礎的限制內運作。 若指令或提示與政策衝突（例如嘗試繞過唯讀行為或存取超出範圍的來源），代理程式會依照下節描述的優先順序模型拒絕或重新導向該請求。
治理層與意圖層
當你設定 Fabric 資料代理時，多層意圖會影響代理的行為。 這些層級依序由高到低排列，定義代理人可做的事：
- 組織意圖：由您組織管理員設定的租戶整體政策與合規要求。 這些約束佔據最高優先權，且無法被其他層覆蓋。
- 基於角色的意圖：適用於特定角色或群組的工作區治理設定與權限邊界。 這些設定會強制執行存取控制和資料範圍限制。
- 開發者意圖：在建置資料代理時，提供自訂指令、範例查詢及資料來源設定。
- 使用者意圖：終端使用者在與客服人員對話時提交的問題與提示。
當層級間發生衝突時，較高優先權層會覆蓋較低層級。 例如，組織政策與工作區治理設定總是覆蓋開發者指示與使用者提示。 此優先順序模型確保代理系統在核准範圍內運行，無論設定或提示是如何。
Fabric 資料代理與副駕駛之間的差異
雖然 Fabric 資料代理與 Fabric 副駕駛皆使用生成式 AI 來處理與推理資料，但它們在功能與使用情境上存在關鍵差異：
Configuration flexibility：你可以高度配置Fabric資料代理程式。 您可以提供自訂指示和範例，以針對特定案例量身打造其行為。 另一方面，Fabric 副駕駛是預先設定的，沒有這種程度的客製化。
範圍與使用案例：Fabric copilot 協助 Microsoft Fabric 內的任務，例如產生筆記本程式碼或倉儲查詢。 相較之下，Fabric 資料代理是獨立且可配置的產物，能跨 OneLake 及語意模型查詢資料。 Fabric 資料代理也能整合 Microsoft 365 Copilot，直接在 Microsoft 365 應用程式中呈現自然語言洞見。 當代理透過 Microsoft 365 Copilot 存取時，Microsoft Purview 治理政策仍適用於底層資料來源。 此外，Fabric 資料代理還能連接外部系統，如 Microsoft Copilot Studio、Azure AI Foundry、Microsoft Teams 或其他 Fabric 以外的工具。 外部編排器與多代理執行時可調用 Fabric 資料代理程式以支援端對端代理式工作流程，而資料代理則專注於唯讀、受控的資料存取。
Fabric 資料代理程式的評估
產品團隊嚴格評估了 Fabric 資料代理回應的品質與安全性：
Benchmark Testing：產品團隊在多種公開與私人資料集中測試Fabric資料代理，以確保回應品質與準確性。
增強傷害緩解：產品團隊實施防護措施，確保Fabric資料代理的輸出聚焦於特定資料來源的情境，降低無關或誤導性答案的風險。
治理和安全性
Microsoft Purview 整合為 Fabric 資料代理提供治理控制。 當你設定資料代理時，Purview 治理政策會套用到代理可存取的底層資料來源。 此整合有助於確保透過代理人員的資料存取遵循與直接存取相同的合規與分類規則。
Microsoft Purview 政策：代理查詢的資料來源會使用資料存取控制與敏感性標籤等 Purview 政策。 若 Purview 政策限制對湖屋或倉庫的存取，代理在處理使用者查詢時會遵守此限制。
出站存取保護：Fabric 資料代理在工作區出站存取保護範圍內運作。 工作區管理員可透過工作區設定管理允許的出站連線，以控制資料代理可連接的外部端點。
Microsoft 365 Copilot 整合：當Fabric資料代理透過Microsoft 365 Copilot出現時，Purview 治理政策仍持續適用。 使用者只能存取其憑證與 Purview 政策允許的資料，無論入口點為何。
資料代理的 ALM 與 DevOps
Fabric 資料代理支援應用程式生命週期管理（ALM）功能，協助您管理跨開發、測試及生產環境的代理配置。
診斷：利用內建診斷監控代理行為、識別查詢產生問題，並排解回應品質。 診斷功能提供代理如何處理問題及選擇資料來源的可視化。
Git 整合：你可以用 Git 整合來控制代理設定。 將您的 Fabric 工作空間連接到 Git 儲存庫，追蹤代理指令、範例查詢及資料來源選擇隨時間的變更。
部署管線：利用Fabric部署管線在工作區間推廣資料代理（例如從開發到生產環境）。 這項支援讓你能在將變更開放給終端使用者之前，先在暫存環境中測試。
營運監督
為了維持持續的品質與政策一致性，請考慮以下 Fabric 資料代理的營運實務：
- 日誌與稽核：透過現有的日誌與稽核功能監控客服人員互動。 檢視查詢模式與回應品質，有助於你及早發現意外行為。
- 人機協同升級管理：為敏感或高影響力請求建立升級處理程序。 對於自動回答不足的情況，請定義流程將問題導向合格的審查者。
- 定期檢視：定期檢視資料代理的指示與範例查詢，確保其與當前組織政策及資料結構保持一致。 隨著資料來源或業務需求變化，請相應更新代理設定。
局限性
- Fabric 資料代理程式僅產生 SQL、DAX 和 KQL 的「讀取」查詢。 它不會產生 SQL、DAX 或 KQL 查詢來建立、更新或刪除資料。
- Fabric資料代理不支援非結構化資料，如 .pdf、.docx或 .txt 檔案。 你不能用 Fabric 資料代理來存取非結構化資料資源。
- 對於湖屋資料來源，Fabric 資料代理程式會利用你選擇的湖屋資料表來回答問題。 除非將 Lakehouse 檔案匯入或以資料表形式公開，否則不會直接讀取獨立的 lakehouse 檔案（例如 CSV 或 JSON 檔案）。
- Fabric 資料代理目前不支援非英語語言。 為了達到最佳表現，請以英文提供問題、指示和範例查詢。
- 你無法更改 Fabric 資料代理所使用的大型語言模型。
- Fabric 資料代理中的對話歷史紀錄可能不一定能持續保存。 在某些情況下，例如後端基礎設施變更、服務更新或模型升級，過去的對話紀錄可能會被重置或遺失。
- 當資料來源的工作區容量與資料代理的工作區容量位於不同區域時，Fabric 資料代理無法執行查詢。 例如，一個位於北歐的資料湖屋，若資料代理程式的容量能力位於法國中部，則會失敗。
- 使用者可在資料代理程式中為每個資料來源提供最多 100 個範例查詢。
- Fabric Data Agents 目前設計用於提供對話式分析，而非回傳完整的資料集。 為確保回應簡潔且具效能，聊天輸出會自動限制和/或總結回傳的資料。 目前，回應最多限制為25列25欄。 請注意，過去的聊天紀錄可能會影響後續的回覆。 例如，如果你要求「顯示今年所有行數」，代理人仍會回傳最多 25 行。 接著，在這有限的背景下可能會回答後續問題，這可能會影響結果。 在這種情況下，建議重新開始聊天會話。
- 若底層資料來源適用 Microsoft Purview DLP 或存取限制政策，代理回應可能會被截斷或阻擋。 具體行為取決於你組織的政策配置。
- Purview 政策標示為敏感的資產可能無法被代理存取，導致回答不完整或無法查詢某些資料來源。
- 代理人員的互動可能會被記錄並可透過 Microsoft Purview Audit 和 eDiscovery 發現。 組織在部署代理處理敏感工作負載時，應考慮這些治理控制措施。
- 透過資料代理存取 Power BI 語意模型，是透過模型的讀取權限來管理，且不需要工作區層級的存取權限。 列層級安全性（RLS）和欄層級安全性（CLS）仍然適用。