微軟 Fabric 這一年多在產(chǎn)品定位上的變化我剛開(kāi)始是持保留態(tài)度的——又是一個(gè)想搶占企業(yè)數(shù)據(jù)入口的云服務(wù)而已。但真把幾個(gè)智能體項(xiàng)目跑下來(lái)之后我發(fā)現(xiàn)自己之前低估了它。智能體或者說(shuō) AI Agent 這幾年最大的瓶頸根本不是模型能力不夠而是它“不懂業(yè)務(wù)”。你讓一個(gè)大模型分析銷售下滑它連你們公司“有效銷售額”到底怎么定義都不清楚怎么可能給出靠譜判斷微軟 Fabric 被越來(lái)越多團(tuán)隊(duì)當(dāng)成智能體學(xué)習(xí)業(yè)務(wù)運(yùn)作的平臺(tái)核心就是它把一個(gè)企業(yè)里散落的數(shù)據(jù)、口徑、實(shí)時(shí)事件整理成了一套智能體可以查詢、理解、持續(xù)修正的“業(yè)務(wù)事實(shí)層”。這篇文章我不打算泛泛介紹功能而是結(jié)合我實(shí)際搭建的經(jīng)驗(yàn)聊清楚這么幾件事智能體為什么需要平臺(tái)級(jí)的業(yè)務(wù)語(yǔ)義Fabric 里哪些能力真正派上了用場(chǎng)我是怎么一步步把一個(gè)“會(huì)讀數(shù)據(jù)、懂業(yè)務(wù)規(guī)則”的智能體跑起來(lái)的以及這個(gè)過(guò)程中踩過(guò)卻很少被寫進(jìn)文檔的坑。如果你正在企業(yè)里做數(shù)據(jù)平臺(tái)或者要給智能體項(xiàng)目找一個(gè)不會(huì)把口徑搞亂的數(shù)據(jù)基座這篇應(yīng)該能給你省不少試錯(cuò)時(shí)間。1. 智能體為什么需要“業(yè)務(wù)運(yùn)作學(xué)習(xí)”Fabric 恰好干了這件事1.1 只靠 Prompt 調(diào)優(yōu)的智能體根本學(xué)不會(huì)業(yè)務(wù)過(guò)去一年我觀察到的智能體項(xiàng)目凡是做到一半卡住的問(wèn)題幾乎都不在大模型本身而在“模型對(duì)業(yè)務(wù)的理解太淺”。你可以把提示詞寫得再花哨把工具定義得再詳細(xì)但模型始終缺少一個(gè)東西一套和企業(yè)真實(shí)運(yùn)作完全對(duì)齊的數(shù)據(jù)事實(shí)。舉個(gè)例子。一個(gè)零售客戶想讓我做“門店經(jīng)營(yíng)診斷智能體”我一開(kāi)始拿到的問(wèn)題清單是這樣的門店毛利為什么比上周低了庫(kù)存周轉(zhuǎn)突然惡化是哪幾個(gè) SKU 導(dǎo)致的哪些門店退貨率異常這些問(wèn)題的答案全部藏在底層數(shù)據(jù)里分布在訂單系統(tǒng)、庫(kù)存系統(tǒng)、門店主數(shù)據(jù)里。更麻煩的是每個(gè)系統(tǒng)的字段命名、更新節(jié)奏、統(tǒng)計(jì)口徑都不一樣“訂單金額”在 CRM 里和在財(cái)務(wù)系統(tǒng)里的含義就不同。反過(guò)來(lái)想一個(gè)合格的業(yè)務(wù)分析師是怎么回答這些問(wèn)題的他會(huì)先打開(kāi)報(bào)表看一眼指標(biāo)定義再下鉆到明細(xì)最后結(jié)合自己對(duì)業(yè)務(wù)的理解給出分析。分析師之所以能做這件事是因?yàn)樗X中有“業(yè)務(wù)語(yǔ)義”和“數(shù)據(jù)模型”。智能體如果只拿到一個(gè)數(shù)據(jù)庫(kù)連接串沒(méi)有一個(gè)語(yǔ)義模型它就像被蒙著眼睛派進(jìn)一個(gè)巨大的倉(cāng)庫(kù)讓它找一件它連長(zhǎng)相都不知道的東西。所以我越來(lái)越傾向于把“業(yè)務(wù)運(yùn)作學(xué)習(xí)”這四個(gè)字拆成這樣學(xué)習(xí) 數(shù)據(jù)事實(shí) 語(yǔ)義口徑 實(shí)時(shí)狀態(tài) 反饋修正。缺任何一個(gè)環(huán)節(jié)智能體都只是接了一個(gè)數(shù)據(jù)源的“高級(jí)聊天框”。1.2 Fabric 把數(shù)據(jù)湖、語(yǔ)義層、事件流拼成了業(yè)務(wù)學(xué)習(xí)底座微軟 Fabric 的定位恰好是覆蓋了這四個(gè)環(huán)節(jié)。它不是一個(gè)單純的數(shù)據(jù)倉(cāng)庫(kù)或者 BI 工具而是一個(gè)把存儲(chǔ)、加工、分析、實(shí)時(shí)事件、治理收攏在同一套管理體系里的 SaaS 平臺(tái)。我給它總結(jié)了三層能力對(duì)應(yīng)智能體學(xué)習(xí)的三個(gè)需求統(tǒng)一的事實(shí)存儲(chǔ)層OneLake 把結(jié)構(gòu)化表格、半結(jié)構(gòu)化日志、非結(jié)構(gòu)化文檔放進(jìn)同一個(gè)湖里形成智能體的“記憶體”可計(jì)算的語(yǔ)義層指標(biāo)口徑、維度層級(jí)、業(yè)務(wù)關(guān)系在語(yǔ)義模型里定義清楚智能體查詢時(shí)拿到的是“有效銷售額”這樣有業(yè)務(wù)含義的結(jié)果而不是讓模型自己拼字段實(shí)時(shí)事件通道通過(guò)實(shí)時(shí)智能模塊接入訂單、庫(kù)存、設(shè)備事件讓智能體能感知“當(dāng)下正在發(fā)生什么”而不只是事后翻舊賬。在這個(gè)結(jié)構(gòu)里智能體不再是一個(gè)直接連庫(kù)的“裸查詢器”而是一個(gè)站在業(yè)務(wù)語(yǔ)義之上的推理者。你問(wèn)它“為什么華東區(qū)周轉(zhuǎn)天數(shù)上升了”它不是先去猜哪張表里有什么字段而是先定位到“庫(kù)存周轉(zhuǎn)天數(shù)”這個(gè)指標(biāo)的定義再按模型下鉆到區(qū)域、品類最后結(jié)合實(shí)時(shí)補(bǔ)貨事件給出解釋。我實(shí)際做完一個(gè)項(xiàng)目之后的體會(huì)是Fabric 并不能讓模型一夜之間變聰明但它給了模型一個(gè)不扭曲業(yè)務(wù)真相的“參考系”。智能體給出的結(jié)論一旦有異議你可以回溯到它查詢的指標(biāo)、數(shù)據(jù)源、時(shí)間范圍整個(gè)判斷過(guò)程是可驗(yàn)證的。這一點(diǎn)對(duì)于要上生產(chǎn)環(huán)境的智能體來(lái)說(shuō)價(jià)值甚至比準(zhǔn)確率還重要。2. 我實(shí)際用到的 Fabric 核心組件與選擇邏輯2.1 OneLake 湖倉(cāng)一體讓散落的業(yè)務(wù)數(shù)據(jù)先住進(jìn)同一個(gè)倉(cāng)庫(kù)智能體學(xué)業(yè)務(wù)的第一步是先解決“數(shù)據(jù)在哪”的問(wèn)題。我在項(xiàng)目里最常見(jiàn)的數(shù)據(jù)環(huán)境是銷售在 SQL Server庫(kù)存在一個(gè)老舊的 ERP 系統(tǒng)客戶主數(shù)據(jù)又在另一套 CRM偶爾還有手工維護(hù)的 Excel 表。過(guò)去我們做數(shù)倉(cāng)第一步就是寫一堆 ETL 把數(shù)據(jù)“抽”到統(tǒng)一存儲(chǔ)。Fabric 里的 OneLake 給了我一個(gè)更省事的答案它依托云對(duì)象存儲(chǔ)但對(duì)外暴露的是一個(gè)邏輯數(shù)據(jù)湖。這意味著你既可以物理搬數(shù)據(jù)進(jìn)來(lái)也可以用快捷方式指向外部存儲(chǔ)讓數(shù)據(jù)看起來(lái)都住在同一個(gè)湖里實(shí)際上沒(méi)有產(chǎn)生冗余拷貝。我自己最常用的做法有這么幾個(gè)用 Data Factory 管道把 SQL Server 的業(yè)務(wù)表按增量策略復(fù)制為 Delta 表CSV 和 Excel 這種小數(shù)據(jù)源直接扔到 Notebook 里清洗后寫回湖里對(duì)于已經(jīng)存在其他數(shù)據(jù)湖的歷史數(shù)據(jù)用快捷方式直接掛載避免重復(fù)遷移在 Data Hub 里做好表登記和描述讓智能體工具能“看到”有哪些表可用。有一個(gè)實(shí)際體驗(yàn)值得單獨(dú)拎出來(lái)說(shuō)OneLake 里的每張表都會(huì)自動(dòng)暴露一個(gè) SQL 分析端點(diǎn)這意味著智能體可以用標(biāo)準(zhǔn) SQL 直接查詢湖里的數(shù)據(jù)不需要你再去封裝一套 HTTP API。我項(xiàng)目里給智能體配查詢工具時(shí)幾乎沒(méi)寫后端接口客戶端就是對(duì)著分析端點(diǎn)跑 SQL。這讓整個(gè)鏈路清爽了一個(gè)量級(jí)。2.2 語(yǔ)義模型與指標(biāo)庫(kù)把“口徑”變成智能體能直接復(fù)用的資產(chǎn)數(shù)據(jù)進(jìn)了湖下一道坎是口徑。這一步是智能體能不能“說(shuō)人話”的分水嶺。什么叫口徑問(wèn)題我舉一個(gè)具體例子。業(yè)務(wù)那邊說(shuō)“門店毛利”聽(tīng)起來(lái)簡(jiǎn)單。但實(shí)際算起來(lái)要不要扣掉后臺(tái)分?jǐn)偝杀咀饨鸷腿斯な撬阍诳偛窟€是算在門店退款訂單的毛利是紅沖還是忽略促銷贈(zèng)品的成本算不算進(jìn)去如果這些口徑不統(tǒng)一你問(wèn)智能體“華東和華南哪個(gè)毛利高”它可能因?yàn)殡p方的算法不同給出一份完全錯(cuò)誤的對(duì)比。Fabric 里的語(yǔ)義模型本質(zhì)上就是把這類口徑問(wèn)題固化下來(lái)變成可復(fù)用、可審計(jì)的指標(biāo)資產(chǎn)。我通常在模型里做這樣幾件事用計(jì)算列和度量值把有效銷售額、毛利、庫(kù)存周轉(zhuǎn)天數(shù)等核心指標(biāo)定義好建好維度層級(jí)比如大區(qū)→城市→門店→柜臺(tái)讓智能體可以逐層下鉆把指標(biāo)描述寫清楚在語(yǔ)義模型的描述字段里說(shuō)明“適用于什么場(chǎng)景、排除哪些數(shù)據(jù)”相當(dāng)于給智能體一本指標(biāo)說(shuō)明書。這里有個(gè)細(xì)節(jié)我特別想提醒語(yǔ)義模型的描述文本質(zhì)量直接決定智能體能否正確選指標(biāo)。模型會(huì)讀這些描述來(lái)判斷“當(dāng)前問(wèn)題該用哪個(gè)指標(biāo)”。如果你只在度量值里寫一行公式?jīng)]有任何業(yè)務(wù)說(shuō)明智能體很可能把“現(xiàn)金流量”和“營(yíng)業(yè)收入”混著用。我在項(xiàng)目上花了大量時(shí)間打磨描述文本收益比繼續(xù)調(diào) Prompt 大得多。2.3 實(shí)時(shí)智能與事件通道讓智能體感知“正在發(fā)生的業(yè)務(wù)”大部分企業(yè)的分析場(chǎng)景是 T1 的昨天的數(shù)據(jù)今天看這沒(méi)有錯(cuò)。但智能體要做的很多事并不適合等一天。比如庫(kù)存預(yù)警、門店客流異常、訂單積壓告警這些都是分鐘級(jí)的問(wèn)題等到第二天再發(fā)現(xiàn)損失已經(jīng)造成了。Fabric 的實(shí)時(shí)智能模塊本質(zhì)是一個(gè)托管式的 Kusto 分析環(huán)境。我可以把訂單事件流、庫(kù)存變動(dòng)流、門店打卡流接進(jìn)去再讓智能體通過(guò) KQL 查詢實(shí)時(shí)表。我自己實(shí)驗(yàn)時(shí)接了兩路模擬事件流一路是訂單創(chuàng)建一路是退換貨然后給智能體加了一個(gè)工具“查詢最近 15 分鐘退貨率超過(guò) 10% 的門店”。效果很直觀智能體給出的答案不再是延遲半天的舊數(shù)據(jù)而是剛剛發(fā)生的事實(shí)。但我要坦白一句實(shí)時(shí)事件流是要花錢的吞吐量越大成本越高。所以我的建議不是“所有數(shù)據(jù)都上實(shí)時(shí)”而是按需分層。普通經(jīng)營(yíng)分析繼續(xù)走 T1運(yùn)營(yíng)監(jiān)控走準(zhǔn)實(shí)時(shí)只有真正需要秒級(jí)響應(yīng)的風(fēng)控、告警才上事件流。智能體在工具描述里標(biāo)明數(shù)據(jù)延遲讓模型自己判斷該查哪一層這是我在項(xiàng)目里用起來(lái)最順的折衷方案。2.4 Copilot 與開(kāi)發(fā)鏈降門檻可以別指望全自動(dòng)Fabric 平臺(tái)內(nèi)置的 Copilot在 Notebook 和 SQL 編輯場(chǎng)景里確實(shí)能幫忙。比如我寫管道清洗邏輯時(shí)讓它先生成一段 Dataflow 表達(dá)式或者在一個(gè)長(zhǎng) SQL 里讓它補(bǔ)全一段 Window 函數(shù)的寫法這些場(chǎng)景它發(fā)揮得不錯(cuò)能省掉不少查文檔的時(shí)間。不過(guò)我基本不指望 Copilot 直接幫我把整個(gè)智能體鏈路搭好。原因很簡(jiǎn)單智能體項(xiàng)目最大的復(fù)雜度不在“寫代碼”而在“理解業(yè)務(wù)”。業(yè)務(wù)口徑、權(quán)限邊界、事件路由這些問(wèn)題Copilot 看不到也猜不出來(lái)它們需要的是人去梳理和定義。所以我的定位是Copilot 當(dāng)副駕駛用主干工程還是自己來(lái)。把助手當(dāng)主力容易在項(xiàng)目收尾時(shí)發(fā)現(xiàn)一堆隱性問(wèn)題。3. 搭建“業(yè)務(wù)學(xué)習(xí)智能體”的完整實(shí)操鏈路零售門店診斷場(chǎng)景3.1 選場(chǎng)景先找一個(gè)邊界清晰、容易見(jiàn)效的業(yè)務(wù)問(wèn)題智能體學(xué)業(yè)務(wù)我不建議一上來(lái)就做一個(gè)“全知全能”的超級(jí)智能體。邊界越寬不可控因素越多最后往往連及格都很難。我做第一個(gè)驗(yàn)證項(xiàng)目時(shí)刻意選了一個(gè)邊界很窄的場(chǎng)景零售連鎖門店的經(jīng)營(yíng)異常診斷。選擇它有三個(gè)原因。第一數(shù)據(jù)邊界清楚門店銷售、庫(kù)存、客流事件都是相對(duì)標(biāo)準(zhǔn)的數(shù)據(jù)不需要跨十幾個(gè)系統(tǒng)。第二判斷規(guī)則可以明確定義比如毛利波動(dòng)、庫(kù)存周轉(zhuǎn)、退貨率這些指標(biāo)都能預(yù)先設(shè)置閾值。第三動(dòng)作可審計(jì)智能體輸出的結(jié)論只是“建議”最終由門店運(yùn)營(yíng)人員確認(rèn)不會(huì)造成不可逆的后果。如果你也想復(fù)制這條路我建議用這四個(gè)標(biāo)準(zhǔn)篩選場(chǎng)景數(shù)據(jù)可得且穩(wěn)定、業(yè)務(wù)規(guī)則可以描述、判斷結(jié)果可以驗(yàn)證、失敗不會(huì)造成大損失。滿足這四個(gè)條件就能作為第一個(gè)智能體項(xiàng)目落地。3.2 數(shù)據(jù)管道落地從 SQL Server 和 CSV 匯入 OneLake我的數(shù)據(jù)源主力是一套 SQL Server 業(yè)務(wù)庫(kù)外帶幾張手工維護(hù)的 CSV。整個(gè)匯數(shù)過(guò)程分四步在 Fabric 里建好工作區(qū)按業(yè)務(wù)域拆出銷售域、庫(kù)存域、門店域三個(gè)子域用 Data Factory 管道把 SQL Server 的訂單表、退貨表、產(chǎn)品表、門店表復(fù)制到 OneLake格式選 Delta并設(shè)置增量刷新手工 CSV 在 Notebook 里讀取做字段標(biāo)準(zhǔn)化、去重后寫出到湖里并在 Data Hub 登記歷史數(shù)據(jù)本來(lái)有一部分在外部數(shù)據(jù)湖里我直接建快捷方式掛載沒(méi)有重復(fù)搬遷。這個(gè)環(huán)節(jié)最常見(jiàn)的坑有三個(gè)我逐個(gè)說(shuō)。第一個(gè)坑是時(shí)間字段時(shí)區(qū)混亂。門店分布在多個(gè)時(shí)區(qū)時(shí)如果統(tǒng)一用本地時(shí)間存做跨區(qū)域匯總就會(huì)亂。我的處理方式是清洗層統(tǒng)一存 UTC展示時(shí)再按門店時(shí)區(qū)轉(zhuǎn)換。智能體查詢時(shí)時(shí)間篩選條件一律用 UTC安全性會(huì)高很多。第二個(gè)坑是增量同步的機(jī)制。訂單表一旦量大每天全量復(fù)制既慢又費(fèi)錢。我后來(lái)在源表加了水印字段管道按“大于上次最大水印值”增量拉取才算把這個(gè)坑填平。第三個(gè)坑是臟數(shù)據(jù)攔截。比如訂單金額為負(fù)數(shù)、日期早于門店開(kāi)業(yè)日期這類問(wèn)題如果不在一開(kāi)始攔截后面會(huì)污染所有指標(biāo)。我在管道出湖前加了數(shù)據(jù)質(zhì)量斷言不符合規(guī)則的行直接進(jìn)異常表方便后續(xù)處理。3.3 定義語(yǔ)義模型讓智能體知道毛利到底怎么算數(shù)據(jù)進(jìn)湖之后我花了一天時(shí)間建語(yǔ)義模型這是整個(gè)項(xiàng)目里性價(jià)比最高的一天。我建了一張“門店經(jīng)營(yíng)指標(biāo)”語(yǔ)義模型核心指標(biāo)大概是這樣的指標(biāo)計(jì)算口徑使用說(shuō)明有效銷售額訂單金額 - 退款金額 - 贈(zèng)品金額所有銷售額分析的基礎(chǔ)排除測(cè)試訂單門店毛利有效銷售額 - 已售商品成本 - 門店分?jǐn)傋饨鸺叭斯H用于含分?jǐn)偝杀镜慕?jīng)營(yíng)分析庫(kù)存周轉(zhuǎn)天數(shù)平均庫(kù)存 / 日銷售成本按 30 天滾動(dòng)窗口計(jì)算門店退貨率退貨訂單數(shù) / 有效訂單數(shù)退貨率分析統(tǒng)一用此口徑這個(gè)表的價(jià)值不在于公式本身而在于它成了智能體和業(yè)務(wù)之間唯一的“契約”。業(yè)務(wù)人員說(shuō)“毛利下降”智能體第一時(shí)間就通過(guò)語(yǔ)義模型知道這個(gè)毛利是扣了分?jǐn)偝杀镜牟皇且粋€(gè)簡(jiǎn)單的賬面數(shù)字。這樣雙方討論的才是同一件事。在語(yǔ)義模型描述里我還標(biāo)注了指標(biāo)適用的邊界條件比如“新店開(kāi)業(yè)前三個(gè)月不參與同比分析”。這個(gè)細(xì)節(jié)在后來(lái)的反饋環(huán)節(jié)起了很大作用它是“學(xué)習(xí)”的起點(diǎn)。3.4 接智能體工具調(diào)用 SQL 端點(diǎn) 結(jié)果解讀有了數(shù)據(jù)有了語(yǔ)義接下來(lái)就是把智能體接上。我采用的是目前最主流的 LLM 工具調(diào)用方案整體結(jié)構(gòu)是這樣的給智能體配一個(gè)工具函數(shù)名query_sql_endpoint參數(shù)是標(biāo)準(zhǔn) SQL 查詢語(yǔ)句System Prompt 里寫清楚業(yè)務(wù)摘要、指標(biāo)定義、常用維度層級(jí)用戶提問(wèn)進(jìn)來(lái)后模型自己判斷該查哪些指標(biāo)、生成什么 SQL、調(diào)用工具、拿到結(jié)果、再結(jié)合規(guī)則輸出結(jié)論。我給智能體的提示詞里有一段類似下面這樣的定義簡(jiǎn)化后你是門店經(jīng)營(yíng)診斷助手?？刹樵冎笜?biāo)包括 - effective_sales有效銷售額訂單金額-退款-贈(zèng)品排除測(cè)試訂單 - store_gross_margin門店毛利扣除貨品成本、門店分?jǐn)傋饨鸺叭斯?- inventory_turnover_days庫(kù)存周轉(zhuǎn)天數(shù)平均庫(kù)存/日銷售成本30天滾動(dòng) - return_rate門店退貨率退貨訂單數(shù)/有效訂單數(shù) 規(guī)則新店開(kāi)業(yè)前3個(gè)月不參與同比分析所有結(jié)論必須標(biāo)注數(shù)據(jù)來(lái)源時(shí)間窗口如果查詢結(jié)果為空回答“暫無(wú)足夠數(shù)據(jù)”。這個(gè)設(shè)計(jì)有個(gè)關(guān)鍵點(diǎn)我想強(qiáng)調(diào)三遍查詢要拆碎不要寫大而全的 SQL。我一開(kāi)始也試過(guò)讓模型一次把“各地區(qū)銷售、毛利、周轉(zhuǎn)率”全查出來(lái)結(jié)果它經(jīng)常寫出一大段 JOIN不是性能差就是結(jié)果錯(cuò)。后來(lái)改成一次只查一張明細(xì)或一個(gè)指標(biāo)模型分析錯(cuò)誤率明顯下降速度也快很多。工具層我做了兩個(gè)保護(hù)一是查詢限定到指定 schema 視圖不允許它掃整表二是單次查詢最多返回 200 行避免結(jié)果集過(guò)大。這兩個(gè)限制看起來(lái)簡(jiǎn)單但能擋掉大多數(shù)性能事故。3.5 反饋閉環(huán)把人的糾正“喂”回語(yǔ)義層這節(jié)我想聊“學(xué)習(xí)”這個(gè)詞因?yàn)檫@是最容易被忽視的一步。智能體上線兩星期后我發(fā)現(xiàn)它對(duì)“新店”這個(gè)場(chǎng)景還是會(huì)誤判。新店沒(méi)有歷史銷量但模型不知道這一點(diǎn)經(jīng)常會(huì)拿新店和成熟店做同比得出“異常下滑”的結(jié)論。這其實(shí)不是模型笨而是我漏掉了重要的業(yè)務(wù)知識(shí)。后來(lái)我在語(yǔ)義模型里加上“是否新店”標(biāo)記并在提示詞里寫明“新店前 3 個(gè)月不參與同比分析”問(wèn)題就明顯緩解了。這件事讓我意識(shí)到智能體的“業(yè)務(wù)學(xué)習(xí)”不是模型自己長(zhǎng)出來(lái)的而是要有一個(gè)反饋機(jī)制把人的糾正持續(xù)灌回語(yǔ)義層和規(guī)則層。我的做法是在業(yè)務(wù)端加了一個(gè)簡(jiǎn)單入口運(yùn)營(yíng)人員可以對(duì)智能體回答點(diǎn)“有用”“沒(méi)用”“口徑不對(duì)”。這些動(dòng)作記錄會(huì)寫回 OneLake每周做一次復(fù)盤把高頻錯(cuò)誤轉(zhuǎn)化為語(yǔ)義模型或規(guī)則調(diào)整。跑了一個(gè)多月之后智能體在常見(jiàn)問(wèn)題上的表現(xiàn)肉眼可見(jiàn)地變好。沒(méi)有反饋閉環(huán)的智能體本質(zhì)上只是一個(gè)查詢工具有了它才談得上“學(xué)習(xí)業(yè)務(wù)運(yùn)作”。4. 智能體學(xué)業(yè)務(wù)時(shí)最容易踩的四個(gè)坑4.1 權(quán)限邊界智能體只準(zhǔn)看它該看的很多團(tuán)隊(duì)在給智能體配數(shù)據(jù)權(quán)限時(shí)圖省事直接給一個(gè)高權(quán)限賬號(hào)。這在我這里是要堅(jiān)決攔住的做法。智能體的查詢路徑是可被攻擊的你給了它全局讀取權(quán)限就等于讓任何能調(diào)用它的人都越權(quán)讀數(shù)據(jù)。Fabric 這塊我推薦的做法是三步走。第一調(diào)用的數(shù)據(jù)連接統(tǒng)一走固定身份啟用行級(jí)安全性第二語(yǔ)義模型按組織架構(gòu)配置 RLS 規(guī)則數(shù)據(jù)行自動(dòng)帶區(qū)域標(biāo)簽第三在智能體工具層做二次過(guò)濾只暴露預(yù)先定義好的視圖讓模型沒(méi)有機(jī)會(huì)去查模型之外的內(nèi)容。另外一個(gè)容易被忽略的地方是審計(jì)。智能體的每一次查詢、每一個(gè)建議最好都落日志。我在 Fabric 里開(kāi)了操作審計(jì)把智能體的查詢 SQL、返回結(jié)果、時(shí)間點(diǎn)都記錄下來(lái)。做到這一步權(quán)限和追溯才算閉環(huán)。4.2 新鮮度分層實(shí)時(shí)數(shù)據(jù)不是免費(fèi)的實(shí)時(shí)很好但每個(gè)實(shí)時(shí)事件流都有成本而且不是所有問(wèn)題都需要秒級(jí)響應(yīng)。我?guī)蜆I(yè)務(wù)把數(shù)據(jù)分成三層T1 的離線層用于月度趨勢(shì)和戰(zhàn)略分析5 到 15 分鐘的準(zhǔn)實(shí)時(shí)層用于運(yùn)營(yíng)監(jiān)控和異常預(yù)警秒級(jí)實(shí)時(shí)層用于訂單風(fēng)控和設(shè)備告警。這個(gè)分層的核心是讓智能體在回答問(wèn)題時(shí)能根據(jù)問(wèn)題性質(zhì)選擇正確的數(shù)據(jù)源。具體到落地我會(huì)在工具描述里寫明“本工具數(shù)據(jù)延遲約 X 分鐘”讓模型自己判斷。比如“本月華東區(qū)銷售趨勢(shì)”就沒(méi)必要查實(shí)時(shí)流離線層足夠而“現(xiàn)在哪些門店排隊(duì)異?！北仨氉邔?shí)時(shí)層。模型讀工具描述做選擇比人在代碼里寫死路由要靈活也更不容易出錯(cuò)。4.3 幻覺(jué)治理讓結(jié)論帶著來(lái)源說(shuō)話LLM 的幻覺(jué)問(wèn)題在智能體里會(huì)被放大因?yàn)槟Ｐ蜁?huì)用非常自信的口吻給你一個(gè)不存在的數(shù)字。我在項(xiàng)目里實(shí)測(cè)最有效的四條辦法如下強(qiáng)制結(jié)論標(biāo)注來(lái)源智能體每次回答都必須寫“數(shù)據(jù)來(lái)源XX分析端點(diǎn)時(shí)間窗口XX”沒(méi)有來(lái)源的結(jié)論視為無(wú)效空結(jié)果回退查詢結(jié)果為空或行數(shù)過(guò)少時(shí)明確讓模型回答“暫無(wú)足夠數(shù)據(jù)”禁止它腦補(bǔ)規(guī)則優(yōu)先明確的業(yè)務(wù)規(guī)則放到提示詞或校驗(yàn)函數(shù)里模型只做判定不做規(guī)則發(fā)明人工復(fù)核標(biāo)記當(dāng)某指標(biāo)波動(dòng)超過(guò)預(yù)設(shè)閾值系統(tǒng)自動(dòng)給結(jié)論打上“需人工復(fù)核”標(biāo)簽。第四點(diǎn)是我最想分享的。它的思路是既然模型的不確定性沒(méi)法完全消除那就把不確定性顯式地變成產(chǎn)品的一部分。當(dāng)智能體說(shuō)“華東區(qū)毛利率異常下降需人工復(fù)核”的時(shí)候業(yè)務(wù)人員知道這個(gè)時(shí)候要謹(jǐn)慎而不是無(wú)條件信任。這個(gè)設(shè)計(jì)比反復(fù)調(diào)試提示詞有用得多。4.4 別把智能體當(dāng)決策者先讓它做有腦子的分析師最后一個(gè)坑也是最常見(jiàn)的坑項(xiàng)目做一半就想著讓智能體自動(dòng)做決策自動(dòng)下采購(gòu)單、自動(dòng)改價(jià)。我的態(tài)度很明確有腦子的分析師是當(dāng)前最務(wù)實(shí)、最安全的階段。智能體真正自主決策需要極其嚴(yán)苛的校驗(yàn)、回退和審計(jì)機(jī)制而大多數(shù)企業(yè)的數(shù)據(jù)質(zhì)量和系統(tǒng)連接根本撐不起這個(gè)目標(biāo)。與其在一開(kāi)始就追求“無(wú)人化”不如先實(shí)現(xiàn)“人機(jī)協(xié)同”智能體負(fù)責(zé)發(fā)現(xiàn)問(wèn)題、給出建議、生成方案人負(fù)責(zé)確認(rèn)和拍板。這個(gè)階段的價(jià)值一點(diǎn)不少而且風(fēng)險(xiǎn)小、容錯(cuò)高。等你積累一段時(shí)間的數(shù)據(jù)反饋和信任再逐步擴(kuò)大智能體的自主范圍這條路才走得通。5. 實(shí)測(cè)感受、局限和后續(xù)可以擴(kuò)展的方向5.1 一周跑完鏈路后的真實(shí)體感從數(shù)據(jù)導(dǎo)入到智能體上線我差不多花了一周。給我最大工作量的不是智能體框架而是數(shù)據(jù)整理和口徑定義這個(gè)結(jié)論我說(shuō)過(guò)好幾次但每次項(xiàng)目都會(huì)再驗(yàn)證一次。跑完整個(gè)鏈路我最滿意的部分是“語(yǔ)義模型 SQL 端點(diǎn)”的組合。它讓智能體回答問(wèn)題時(shí)基于的是企業(yè)真實(shí)指標(biāo)而不是模型的內(nèi)部記憶。相比我之前做的純文檔 RAG這種結(jié)構(gòu)化語(yǔ)義檢索的方式在數(shù)字、比例、時(shí)間窗口這些容易出錯(cuò)的點(diǎn)上準(zhǔn)確率要好不少。當(dāng)然它也遠(yuǎn)沒(méi)到完美。比如有幾個(gè)情況它依然處理得不夠好一個(gè)模糊的問(wèn)題里同時(shí)涉及多個(gè)指標(biāo)和多個(gè)維度的復(fù)雜下鉆模型生成 SQL 的成功率會(huì)下降首次出現(xiàn)的新業(yè)務(wù)場(chǎng)景它依然會(huì)因?yàn)槿鄙僦R(shí)而給出比較泛的結(jié)論。這些都需要靠持續(xù)的反饋積累來(lái)改善急不來(lái)。5.2 從“讀數(shù)據(jù)”到“做動(dòng)作”的延伸思路如果后續(xù)想進(jìn)一步有幾個(gè)方向我覺(jué)得值得關(guān)注。一是 Fabric 工作流和自動(dòng)化的聯(lián)動(dòng)。如果智能體判斷某門店需要補(bǔ)貨它可以觸發(fā)一個(gè) Data Factory 管道把補(bǔ)貨明細(xì)清單生成好再由業(yè)務(wù)人員在系統(tǒng)里確認(rèn)。這相當(dāng)于給智能體接上了執(zhí)行的手腳但每一步依舊可以審計(jì)。二是多智能體協(xié)同。等數(shù)據(jù)域足夠規(guī)范可以拆出銷售智能體、庫(kù)存智能體、客服智能體各管一攤再由一個(gè)主智能體做匯總決策。這個(gè)方向很誘人但它對(duì) Fabric 各域之間的血緣關(guān)系和指標(biāo)一致性要求極高一旦兩個(gè)域?qū)ν恢笜?biāo)口徑不一致智能體之間的對(duì)話就會(huì)變成雞同鴨講。三是和 Copilot 的融合。平臺(tái)本身也在持續(xù)強(qiáng)化自然語(yǔ)言能力比較理想化的前景是業(yè)務(wù)人員直接說(shuō)“把華東退貨異常門店列出來(lái)”平臺(tái)自動(dòng)完成取數(shù)、摘要、推送建議的全流程。這個(gè)體驗(yàn)如果能做好智能體學(xué)習(xí)業(yè)務(wù)運(yùn)作的成本會(huì)被進(jìn)一步壓到極低。5.3 關(guān)于這類項(xiàng)目我最后想說(shuō)的建議如果讓我給一個(gè)還沒(méi)開(kāi)始做智能體數(shù)據(jù)平臺(tái)的人一句話我會(huì)說(shuō)把“審計(jì)”放在“智能”前面。智能體每做一次查詢、每給一個(gè)建議都要留下完整日志。將來(lái)你糾錯(cuò)、復(fù)盤、優(yōu)化提示詞靠的全是這些日志。我見(jiàn)過(guò)太多團(tuán)隊(duì)興致勃勃做智能體結(jié)果數(shù)據(jù)鏈路混亂、口徑?jīng)]有收斂、日志丟失最后整個(gè)項(xiàng)目變成一個(gè)黑盒——誰(shuí)都不知道智能體為什么這么回答那才是真正的災(zāi)難。微軟 Fabric 在這里承擔(dān)的不只是數(shù)據(jù)存儲(chǔ)或者報(bào)表平臺(tái)的角色。它更像是一張可以持續(xù)生長(zhǎng)的“業(yè)務(wù)事實(shí)網(wǎng)絡(luò)”而智能體只是在這張網(wǎng)上爬行、推理、學(xué)習(xí)的乘客。把網(wǎng)織好比換一個(gè)更聰明的乘客更重要。