帶過工業(yè)級Agent的朋友都知道真正的難點往往不是把大模型接進業(yè)務(wù)流程而是搞清楚“用戶這句話到底想讓我干什么”。Agent的意圖識別和傳統(tǒng)ChatBot完全不是一回事——用戶可能在一次會話里連續(xù)切換三四個目標(biāo)可能把“幫我查一下昨天的訂單”說成“那個單子到哪了”甚至可能在對話中段突然從查詢意圖跳到投訴意圖。單純的分類模型處理不了這種動態(tài)、碎片、多義的輸入拿大模型硬做分類又面臨延遲、成本和置信度不可信的問題。我在這類項目里反復(fù)踩坑后最終沉淀下來一套方案把意圖識別拆成“召回—分類—置信—仲裁”四個層級每一層只負責(zé)一件事層層收斂最終只把高置信度的結(jié)果交給Agent執(zhí)行。這套分層漏斗思路已經(jīng)在我們多個線上項目中穩(wěn)定運行今天把完整設(shè)計和實踐細節(jié)寫出來給正在做Agent底層能力的朋友一個可復(fù)用的參考。文章適合算法工程師、Agent平臺開發(fā)者和技術(shù)負責(zé)人閱讀也適合準(zhǔn)備自建Agent意圖識別體系但還沒理清架構(gòu)的團隊。1. 為什么工業(yè)級Agent需要“分層漏斗”而不是一個模型1.1 單模型意圖識別在真實場景里的三個致命短板很多團隊一開始都會用最直接的辦法把所有用戶輸入丟給一個微調(diào)過的分類模型或者干脆讓LLM做zero-shot分類。在小流量Demo里這個方案看起來一切正常但一旦放到生產(chǎn)環(huán)境三個問題會立刻暴露。第一個是召回不全。用戶的表達方式極其多樣同一個意圖可能有幾十種說法還夾雜著口語、錯別字、行業(yè)黑話。單模型依賴訓(xùn)練時見過的表達模式對沒見過的變體幾乎必然漏召回。尤其當(dāng)意圖類別超過幾十個時分類模型在類別間容易產(chǎn)生混淆長尾意圖的召回率會急劇下降。第二個是置信度不可信。分類模型輸出的softmax概率和LLM的logits都不能直接當(dāng)作真實置信度使用。模型對某條輸入可能特別自信但實際上完全分錯也可能對明顯的高頻意圖給出50%左右的概率導(dǎo)致無法決策。我見過太多團隊把softmax概率當(dāng)閾值用上線后誤判率比想象中高一倍。第三個是無法兜底。單模型方案是一個封閉的黑盒分錯了沒有中間層去攔截也沒有機會通過交互澄清。用戶一句話被錯誤歸類后Agent會直接執(zhí)行一個錯誤動作這種體驗在工業(yè)場景里是致命的。比如用戶說“我不要這個方案了”如果Agent把它識別成“確認(rèn)下單”后果非常嚴(yán)重。1.2 漏斗思想從哪里來搜索引擎的分層架構(gòu)遷移分層漏斗的思路其實很樸素就是借鑒搜索引擎經(jīng)典的“召回—粗排—精排”架構(gòu)。搜索引擎面對的是海量網(wǎng)頁不可能讓精排模型處理所有候選而是先用廉價的召回通道把候選集縮小再用更精細的模型排序。意圖識別面對的輸入空間同樣巨大——用戶說什么都行但Agent真正能執(zhí)行的意圖是有限的、收斂的。因此我們需要做的就是設(shè)計一個漏斗最上層用最便宜、最快的方式把和任何已知意圖相關(guān)的輸入撈出來中間層做精細分類再往上一層專門判斷“這個分類結(jié)果可不可信”最后一層根據(jù)可信度決定是直接執(zhí)行、繼續(xù)追問還是轉(zhuǎn)人工。每層只做一個任務(wù)這帶來了單模型方案完全沒有的工程優(yōu)勢每一層可以獨立測試、獨立回滾、獨立優(yōu)化。召回率低了只調(diào)召回層精度低了只調(diào)分類層閾值策略不對只調(diào)仲裁層。出了問題生產(chǎn)鏈路自帶有日志定位不用像單模型那樣一換就全局風(fēng)險。1.3 分層漏斗的整體架構(gòu)一覽我把整套漏斗設(shè)計成四個層級下面用表格把每層的職責(zé)、輸入輸出和典型技術(shù)選型列清楚層級核心任務(wù)輸入輸出典型實現(xiàn)L1 語義召回層從原始輸入中快速撈回候選意圖用戶raw query候選意圖列表TopN關(guān)鍵詞規(guī)則、BM25、向量檢索多路召回L2 意圖分類層對候選意圖做精細區(qū)分候選意圖列表 query判別式意圖 類別分?jǐn)?shù)微調(diào)分類模型 / LLM few-shotL3 置信度評估層判斷分類結(jié)果是否可信分類結(jié)果 query特征置信度分?jǐn)?shù) 決策標(biāo)志熵計算、多次采樣一致性、校準(zhǔn)器L4 路由仲裁層決定如何執(zhí)行、是否澄清、是否降級置信度分?jǐn)?shù) 業(yè)務(wù)上下文路由指令執(zhí)行/澄清/轉(zhuǎn)人工規(guī)則策略 Agent編排系統(tǒng)聯(lián)動這個架構(gòu)可以理解為“漏斗閘門”前三層不斷收窄候選并評估質(zhì)量第四層是最終閘門決定輸出流向。下面我把每一層怎么設(shè)計和落地的細節(jié)展開寫這些才是整個方案的真正干貨。2. 四個層級的設(shè)計要點與實操細節(jié)2.1 第一層語義召回層先別急著分類先撈回來很多人做意圖識別會跳過分層直接進入分類這個步驟其實是漏斗里性價比最高的一環(huán)。召回層的目標(biāo)不是精準(zhǔn)識別意圖而是“寧多勿漏”——把可能相關(guān)的意圖全部撈出來寧可撈出一堆無關(guān)候選也不能把真正意圖漏掉。召回層我建議做成多路召回而不是單一通道。至少需要三路規(guī)則召回、關(guān)鍵詞召回、向量語義召回。規(guī)則召回用來處理確定性極強的場景比如正則匹配訂單號、手機號、純數(shù)字ID。這一路延遲最低5ms準(zhǔn)確率100%是漏斗里最穩(wěn)定的底座。關(guān)鍵詞召回靠維護一個“意圖詞表”每個意圖對應(yīng)一組同義詞和關(guān)鍵詞。比如“查訂單”意圖可能對應(yīng)“訂單”“物流”“到哪了”“發(fā)貨沒”等詞。關(guān)鍵詞召回的優(yōu)點是可控性強缺點是擴展性弱需要持續(xù)維護。向量語義召回是核心。先選一個合適的embedding模型把用戶query編碼成向量然后和預(yù)置的“意圖種子向量”做余弦相似度檢索。這里的操作要點是不要用單個向量代表一個意圖而要用一個意圖的多個表達向量共同表示。操作上可以給每個意圖準(zhǔn)備至少20-50條種子表達把這些表達向量聚集成2-5個類心檢索時分別比對這些類心。召回層有一個容易踩的坑向量檢索的相似度閾值不能定太高否則漏召回。我經(jīng)驗上是先定一個偏低的閾值比如0.55-0.65取決于embedding模型確保召回率在95%以上寧可把后層負擔(dān)加重也不能在這一層丟掉真實意圖。召回層的TopN建議設(shè)定在5-10個左右太少容易漏太多會讓分類層壓力過大。2.2 第二層意圖分類層核心是意圖體系設(shè)計召回層把候選意圖列表送進來之后分類層要做精細區(qū)分。這一層的效果好壞80%取決于前期的意圖體系設(shè)計而不是模型選型。意圖體系設(shè)計有兩個關(guān)鍵原則一是層級化二是互斥性。層級化是指把意圖拆成“粗意圖細意圖”兩個級別。粗意圖可以理解為業(yè)務(wù)模塊比如“訂單管理”“客戶服務(wù)”“系統(tǒng)設(shè)置”細意圖才是真正執(zhí)行的動作比如“查詢物流”“修改收貨地址”“投訴快遞員”。分類層先判斷屬于哪個粗意圖模塊再在模塊內(nèi)部做細分類。這么做的好處是每個細分類只需要在幾十個同類之間做區(qū)分難度遠低于在幾百個不相關(guān)意圖之間做區(qū)分。互斥性要求每個意圖定義必須彼此獨立不能有重疊。我見過很多失敗案例比如同時定義了“取消訂單”和“訂單退款”用戶說“我不要了”時兩個意圖概率都高分類器就糊涂了。正確的做法是定義“訂單售后”這個粗意圖細意圖分別是“取消訂單”“退款申請”“退貨申請”讓它們之間的邊界清晰可判。模型選型上我的經(jīng)驗是“微調(diào)小模型為主、LLM為輔”。當(dāng)意圖數(shù)量在50個以內(nèi)、每條意圖的訓(xùn)練樣本超過200條時微調(diào)一個百億參數(shù)以下的小模型比如基于BERT系列的分類模型或7B級別的對話模型效果都不錯延遲可控。如果意圖數(shù)量特別多幾百個或者標(biāo)注數(shù)據(jù)不足再用LLM few-shot兜底。LLM分類的prompt一定要給示例并且要求輸出JSON格式方便后鏈路解析{ intent_group: order_management, intent: query_logistics, confidence: 0.78 }分類層的輸出不能只有一個預(yù)測結(jié)果必須把候選列表里每個候選意圖的分?jǐn)?shù)都保留下來因為下一層置信度評估需要拿到整體分布信息而不僅僅是Top1。2.3 第三層置信度評估層別信模型自帶的概率這一層是整個漏斗里最有價值、也最容易被忽略的部分。工業(yè)級Agent能不能讓人放心就看這層閘門是否可靠。分類模型輸出的softmax概率在真實場景中通常是過度自信的。一個訓(xùn)練得不錯的分類器對錯誤樣本也可能給出0.9以上的概率。所以我不直接使用模型的原始概率而是重新做一個“置信度評估”。置信度的來源我常用三個內(nèi)部熵、多次采樣一致性、語義相似度。內(nèi)部熵是指對分類結(jié)果的所有類目概率求信息熵。熵越低表示模型在類別間越確定熵越高表示模型在猶豫。把熵值作為一個負向特征高熵樣本轉(zhuǎn)入人工或澄清流程。多次采樣一致性針對LLM分類用相同prompt、不同temperature比如0.2和0.7各采一次看兩次結(jié)果是否一致。一致度越高置信度越高。這個方案對LLM特別有效因為它可以檢測模型的隨機性——真實置信的意圖不容易被溫度擾動改變瞎猜的意圖很容易翻車。語義相似度是指把query和意圖種子表達做向量相似度校驗。如果query和“預(yù)測意圖”的種子向量相似度都不高說明分類結(jié)果很可能有問題。比如用戶說“你們客服電話是多少”分類器可能把它分到“投訴建議”但query和“投訴建議”的種子表達在向量空間其實沒那么接近這時相似度校驗就會給低分。拿到多個置信度信號后還需要做置信度校準(zhǔn)。校準(zhǔn)的目標(biāo)是讓分?jǐn)?shù)真實反映準(zhǔn)確率。我常用的是保序回歸Isotonic Regression把“模型分?jǐn)?shù)-是否預(yù)測正確”作為訓(xùn)練對擬合一個校準(zhǔn)函數(shù)。校準(zhǔn)后的分?jǐn)?shù)可以直接作為決策依據(jù)比如0.8分意味著大約80%的概率預(yù)測正確。閾值設(shè)定方面我建議引入業(yè)務(wù)代價矩陣。不同意圖的錯誤識別代價差異很大誤把“取消訂單”識別成“確認(rèn)收貨”的代價極高誤把“閑聊”識別成“查詢天氣”則無所謂。因此不能全局一個閾值要對高代價意圖設(shè)定更高的閾值比如0.9對低代價意圖設(shè)低閾值比如0.7。這就是漏斗比單模型靈活的關(guān)鍵——每個意圖有自己的閘門。2.4 第四層路由仲裁層把決策變成可執(zhí)行的策略最后一層不涉及模型推理而是策略引擎。它接收置信度分?jǐn)?shù)和業(yè)務(wù)上下文輸出Agent執(zhí)行指令。我把路由策略設(shè)計成三檔高置信區(qū)間比如校準(zhǔn)置信度≥0.85直接執(zhí)行。這一檔的意圖不需要向用戶二次確認(rèn)Agent直接調(diào)用對應(yīng)的工具或流程。中置信區(qū)間0.60-0.85進入澄清會話。Agent不是直接執(zhí)行而是反問用戶確認(rèn)比如“您是想查詢物流狀態(tài)還是修改收貨地址”這比錯誤執(zhí)行要好得多也增加了用戶參與的感知。低置信區(qū)間0.60降級處理包括轉(zhuǎn)人工客服或者返回通用兜底話術(shù)。路由層必須和Agent編排系統(tǒng)做好聯(lián)動。我在項目里的做法是路由層輸出一個標(biāo)準(zhǔn)的意圖事件包含意圖編碼、置信度、是否需要澄清等字段Agent編排系統(tǒng)統(tǒng)一消費這個事件。仲裁結(jié)果同時也記錄到日志作為后續(xù)優(yōu)化漏斗的數(shù)據(jù)回流。這一層的工程要點是策略可配置化。不要讓策略硬編碼在代碼里而是通過配置中心下發(fā)這樣線上的閾值調(diào)整不用發(fā)版算法團隊可以直接通過管理后臺調(diào)整每個意圖的置信度閾值。我見過太多團隊在路由策略上寫死參數(shù)導(dǎo)致每次調(diào)整代價極高。3. 實操過程從零搭建一個可上線的分層漏斗3.1 第一步梳理業(yè)務(wù)意圖清單建立意圖編號體系任何漏斗都不能在意圖清單不清晰的情況下動工。梳理意圖清單的正確順序是先收集產(chǎn)品功能列表再收集客服對話日志最后做聚類整合。產(chǎn)品功能列表告訴你系統(tǒng)希望用戶做的事情有哪些客服日志則能暴露用戶真實問法。實際操作時我們拉取了近3個月的用戶會話日志過濾掉無效噪音如純語氣詞、空白信息做一次聚類統(tǒng)計把高頻片段提取出來再映射到產(chǎn)品功能上。這樣得到的意圖清單既有業(yè)務(wù)邏輯支撐又有真實數(shù)據(jù)依據(jù)。意圖編號體系是從工程角度必須做好的事。建議格式[模塊]-[動作]-[序號]比如order-query-01、order-cancel-02。等級編號的好處是后鏈路可以拿編號做權(quán)限控制、統(tǒng)計分析和錯誤歸因。我見過直接用中文描述當(dāng)意圖ID的項目最后在代碼里到處都是魔法字符串排查問題時無從下手。3.2 第二步構(gòu)建評測集與三層指標(biāo)體評測集是整個漏斗能否持續(xù)優(yōu)化的基礎(chǔ)。我建議按三個來源構(gòu)建真實線上日志占比60%以上、人工構(gòu)造困難樣本20%、公開領(lǐng)域相關(guān)數(shù)據(jù)集20%。其中人工構(gòu)造的困難樣本尤其重要包括同義改寫、錯別字、歧義表達、多意圖混合等。每個意圖至少準(zhǔn)備50-100條評測樣本整體評測集規(guī)模建議在2000條以上。評測指標(biāo)不能只看最終準(zhǔn)確率要分各層獨立看。召回層看召回率真實意圖是否在候選列表中分類層看分類精度候選排序后Top1是否正確置信度層看校準(zhǔn)誤差ECEExpected Calibration Error和AUC-ROC路由層看最終決策的正確率和澄清率。每層指標(biāo)獨立監(jiān)控才能快速定位漏斗的瓶頸層。這里有一個實操技巧把評測集構(gòu)建成帶“意圖分層標(biāo)簽”的格式。每條數(shù)據(jù)除了標(biāo)注最終意圖還要標(biāo)注是否屬于長尾表達、是否包含歧義、是否需要澄清。這樣無論在做模型調(diào)優(yōu)還是路由策略時都能針對特定樣本子集觀察效果。3.3 第三步確定各層閾值與參數(shù)先跑通再優(yōu)化閾值和參數(shù)在冷啟動階段很難一步到位我的方式是“初始保守一周內(nèi)校準(zhǔn)”。初始參數(shù)可以參考這個表格參數(shù)初始值說明向量召回相似度閾值0.60寧低勿高保召回召回TopN8留住長尾候選分類模型溫度0.3降低隨機性LLM采樣一致性閾值2/2一致兩次采樣必須一致高置信執(zhí)行閾值0.85初始偏高中置信澄清區(qū)間0.60-0.85留足澄清空間低置信轉(zhuǎn)人工閾值0.60低于此值不執(zhí)行上線后一周內(nèi)通過日志統(tǒng)計實際分布每個意圖的置信度分布、漏斗各層漏出率、澄清率、人工轉(zhuǎn)接率。然后根據(jù)數(shù)據(jù)反向調(diào)整閾值。注意閾值調(diào)整每次只動一個參數(shù)而且要看業(yè)務(wù)指標(biāo)如下單成功率、投訴率聯(lián)動變化不要只看模型指標(biāo)。3.4 第四步灰度發(fā)布與線上監(jiān)控漏斗模型改造要經(jīng)過灰度發(fā)布不能一把梭全量切換。我的經(jīng)驗是分三個階段內(nèi)部環(huán)境驗證2-3天→ 5%流量灰度3-5天→ 50%流量灰度3天→ 全量?；叶绕陂g重點監(jiān)控三類指標(biāo)漏斗各層延遲確保P99在500ms以內(nèi)、決策分布高/中/低置信的比例、業(yè)務(wù)側(cè)轉(zhuǎn)化率比如Agent執(zhí)行成功率、用戶滿意度。這里的對比邏輯很重要要把新漏斗的結(jié)果和舊方案同時輸出對比而不是直接切換后只看新指標(biāo)。我踩過這個坑切換后忘記做對比結(jié)果效果好不好全靠感覺。4. 常見問題與排查技巧實錄4.1 問題一漏斗整體漏出率過高用戶請求大量落到低置信這是上線初期最常碰到的情況。排查路徑是逐層看日志先看召回層命中了沒有。如果召回層就沒把真實意圖撈入候選說明向量閾值太高或意圖種子表達不足再看分類層是否把候選排錯這通常是意圖體系邊界不清或訓(xùn)練樣本不足最后看置信度層分?jǐn)?shù)是否普遍偏低這可能是校準(zhǔn)器沒有訓(xùn)練好或者是query本身在意圖體系中確實邊界模糊。一個典型的案例某電商場景上線時用戶說“這衣服我能退嗎”被歸到低置信轉(zhuǎn)人工。日志顯示分類層正確分到“退貨申請”但置信度層因為query里帶有“嗎”這個疑問語氣詞語義相似度打分偏低。這個問題的本質(zhì)是置信度評估特征不夠豐富后來我們把“是否包含確認(rèn)性問句”作為附加特征加入校準(zhǔn)器問題解決。這種case如果不逐層查日志根本定位不到原因。4.2 問題二用戶的意圖在會話中漂移工業(yè)級Agent的意圖識別必須跟蹤多輪會話中的意圖轉(zhuǎn)變。用戶第一句說“查一下訂單”中間可能插一句“你們發(fā)的是什么快遞”然后又回到訂單主題。如果漏斗只看單輪query會把每個query獨立判斷導(dǎo)致Agent“失憶”。我的解決方案是引入會話級狀態(tài)管理維護一個“當(dāng)前活躍意圖?！泵慨?dāng)新的高置信意圖出現(xiàn)時判斷它和當(dāng)前意圖的關(guān)系——如果是子意圖比如從“查訂單”變?yōu)椤安槲锪鞴尽眲t采用子意圖如果是完全無關(guān)的新意圖從“查訂單”變?yōu)椤巴对V”則切換意圖棧如果置信度不夠高優(yōu)先在當(dāng)前意圖上下文中理解而非獨立判斷。這個策略在工程上需要Agent狀態(tài)層配合給漏斗傳入會話上下文。實際操作里我們做了一個輕量級的上下文注入把最近3輪的用戶輸入和Agent動作拼成一段摘要文本附加到分類層的輸入中。這樣做的好處是分類層能感知上下文壞處是輸入變長延遲和成本會上升所以要控制摘要的長度和結(jié)構(gòu)。4.3 問題三中置信區(qū)間樣本太多澄清話術(shù)讓用戶厭煩澄清機制是雙刃劍。如果系統(tǒng)整天問“您是想A還是B”用戶很快就會失去耐心。我在實踐中發(fā)現(xiàn)中置信區(qū)間過大的根本原因往往是意圖體系粒度不當(dāng)而不是澄清策略本身的問題。解決思路有兩個方向。第一個方向是壓縮中置信區(qū)間通過增加訓(xùn)練樣本、細化種子表達把原本模糊的樣本提升到高置信區(qū)。第二個方向是改進澄清方式不要每次都把選項全部拋給用戶而是用更自然的確認(rèn)話術(shù)比如“您是要查這個訂單的物流對嗎”這樣用戶回答“嗯”就能確認(rèn)成本比“您是選A還是B還是C”低得多。另外路由層要能做“基于背景的澄清跳過”。如果當(dāng)前是投訴場景用戶又說了一遍訂單號這時哪怕置信度不高也不要再澄清訂單相關(guān)意圖直接在當(dāng)前意圖上下文里執(zhí)行。這個規(guī)則不復(fù)雜但能把澄清率降低不少。4.4 問題四冷啟動階段沒有標(biāo)注數(shù)據(jù)漏斗跑不起來很多團隊拿到新業(yè)務(wù)時面臨真實數(shù)據(jù)不足的困境。我的做法是“用偽標(biāo)注啟動漏斗”。從歷史客服對話日志中用LLM批量打標(biāo)一批數(shù)據(jù)然后人工抽檢修正形成初期種子集。這種方法的有趣之處在于LLM打標(biāo)的數(shù)據(jù)有噪音但噪音分布相對均勻用來做初始召回層和意圖體系的驗證完全夠用。另外一個冷啟動技巧是“復(fù)用通用意圖庫”。很多場景的意圖是通用的比如“轉(zhuǎn)人工”“投訴”“咨詢幫助”“再見”這四類在任何業(yè)務(wù)里都存在。這些通用意圖可以先固定進漏斗讓漏斗在業(yè)務(wù)意圖還沒豐富起來時也能正常工作業(yè)務(wù)意圖再隨著數(shù)據(jù)積累逐步加入。冷啟動階段還需要特別注意評測集的建設(shè)邏輯評測集應(yīng)該和訓(xùn)練集分開不能用同樣的偽標(biāo)注數(shù)據(jù)評測。我建議冷啟動評測集用人工標(biāo)注數(shù)量不用太多每個意圖30條左右但務(wù)必是人工確認(rèn)過的否則評測指標(biāo)會虛高。5. 分層漏斗的擴展思考與個人經(jīng)驗分層漏斗的價值不只是提高準(zhǔn)確率還在于它讓Agent底層決策變得可解釋、可觀測、可治理。每一條用戶輸入在漏斗中的流轉(zhuǎn)軌跡都會被記錄出問題時可以回溯到具體層級。這在Agent需要審計或合規(guī)的工業(yè)場景里非常重要——你必須能說清楚“為什么Agent做了這個動作”?；谶@套方案后續(xù)還可以向幾個方向擴展。一是把漏斗輸出和Agent記憶模塊打通讓歷史交互沉淀為更精細的意圖先驗降低重復(fù)識別成本。二是引入主動學(xué)習(xí)機制把中置信和人工處理的樣本自動回流到標(biāo)注平臺每周形成一次“難例集”持續(xù)迭代分類層。三是針對具體行業(yè)構(gòu)建垂直意圖模板庫比如金融、醫(yī)療、電商各自有一套召回種子表達和意圖層級減少跨場景重復(fù)建設(shè)的工作量。我個人的經(jīng)驗是不要讓漏斗一開始就追求全覆蓋。先覆蓋業(yè)務(wù)最核心、最頻繁、代價最高的20個意圖把漏斗跑順暢再逐步擴張到長尾意圖。每擴張一批意圖都要重新評估閾值和評測集因為意圖體系變大后類別間的混淆會重新抬頭。這個過程需要耐心但走穩(wěn)每一步后你的Agent意圖識別能力會非常扎實。最后再說一句實操感受分層漏斗最值錢的不是某一層模型多強而是這種“層層設(shè)防、閘門決策”的工程結(jié)構(gòu)讓你在模型不夠完美時也能保證線上不出大事故。