1. 為什么需要意圖識別分層漏斗1.1 Agent開發(fā)中“最貴”的環(huán)節(jié)往往不是模型而是理解用戶這兩年Agent開發(fā)火到什么程度隨便打開一個技術(shù)社區(qū)十條動態(tài)里至少有三條在聊LangChain、Dify、CrewAI的對比或者“用XX框架三天搭了一個Agent”。但真上手做過生產(chǎn)級Agent的人會告訴你真正勸退你的通常不是模型能力不夠不是框架選錯而是你搞不定用戶到底想干什么。我見過不少團(tuán)隊把最多的精力花在工具調(diào)用、Agent記憶和編排上結(jié)果上線第一天就被真實的用戶輸入打回原形。用戶說的話和你在評測集里精心構(gòu)造的Prompt完全是兩個物種他們會說“那個東西我不要了”、會說“幫我看看這是啥情況”、會發(fā)來一條只有表情包的語音轉(zhuǎn)寫文本甚至?xí)谕粋€句子里塞進(jìn)三個意圖——“順便把上個月那個訂單退了還有發(fā)票開一下對了你們怎么還不發(fā)貨”。這些輸入如果直接丟給Agent要么被誤解要么觸發(fā)錯誤的工具鏈要么就是一堆無意義的模型Token消耗。這也是“工業(yè)級Agent意圖識別分層漏斗”這個方案出現(xiàn)的原因。它解決的核心問題不是“要不要用意圖識別”而是“在真實流量、真實成本、真實延遲約束下意圖識別怎么做才穩(wěn)”。所謂分層漏斗本質(zhì)就是一組由粗到細(xì)的過濾器串聯(lián)起來讓每一層只做一件事低成本的把明顯的情況處理掉高成本的留給真正需要它的復(fù)雜場景。1.2 單一模型方案在真實流量下為什么站不住腳很多剛接觸Agent的人第一反應(yīng)是意圖識別不是很簡單嗎把用戶的話發(fā)給大模型讓它返回一個JSON寫上意圖類型不就行了理論上確實行得通我自己早期也是這樣做的。但隨著流量上來問題就變得非常具體。首先是不可控。同一個Prompt模型今天的輸出格式可能和昨天略有差異換一個Prompt版本某些意圖的判定就飄了。你當(dāng)然可以用結(jié)構(gòu)化輸出約束它但一旦約束復(fù)雜了模型的推理效果又會打折。更別提那些模型“自信滿滿給錯答案”的時刻——它在返回的confidence字段里寫了個0.95但意圖是錯的。其次是成本。工業(yè)級流量不是幾十條評測樣本而是每天幾十萬條真實請求。如果每一條都走大模型推理每月的模型賬單會直接把項目的ROI打穿。然后是延遲。用戶可不會等你三秒鐘才回一句“我想退款”。大模型推理在大多數(shù)場景下都有幾百毫秒到一兩秒的時延這對交互型Agent來說是致命的。最后是排查。單模型方案的邏輯是個黑盒這條請求為什么被識別成“退款”而不是“投訴”沒有中間過程沒有可解釋的依據(jù)出了問題只能改Prompt碰運(yùn)氣。這些痛點疊加在一起就迫使你從“讓模型解決一切”的思路轉(zhuǎn)向“把問題拆開用最便宜的工具解決每一小塊”。1.3 漏斗到底在“漏”什么一句話概括這個方案讓簡單的輸入在淺層被快速命中讓復(fù)雜的輸入進(jìn)入深層被精細(xì)處理讓無法判斷的輸入明確地走向“轉(zhuǎn)人工”或“繼續(xù)追問”而不是讓系統(tǒng)硬猜。我用一個生活化的例子說明。假設(shè)你開了一家線下面館門口站著一位接待員。絕大多數(shù)客人走進(jìn)來說“一碗牛肉面”接待員直接記單就行不需要問任何多余的問題。少數(shù)客人說“你們有沒有不辣的拌面”這時候接待員才需要動一下腦子把客人分類到“咨詢”還是“點單”。只有極少數(shù)客人站在門口半天不說話最后來一句“你們這行嗎”這種輸入連接待員也搞不定才會喊老板出來。意圖識別分層漏斗做的事情就是把接待員這個角色標(biāo)準(zhǔn)化先靠本能規(guī)則和輕量模型處理大量普通情況再動用高級技能大模型處理少數(shù)復(fù)雜情況最后明確承認(rèn)自己的能力邊界不讓用戶被一個錯誤答案誤導(dǎo)。2. 漏斗的整體架構(gòu)設(shè)計與分層邏輯2.1 四個層級的職責(zé)劃分我在實際項目中用的方案是四層結(jié)構(gòu)每一層都有自己的核心指標(biāo)和代價上限。整體長這樣第一層是輸入清洗層。它的任務(wù)是把原始文本變成干凈的、可預(yù)測的、標(biāo)準(zhǔn)化的內(nèi)容。第二層是粗篩層用輕量模型在毫秒級把明顯的高頻意圖識別出來。第三層是精排層針對粗篩層拿不準(zhǔn)的樣本用更重的模型加規(guī)則做精確判斷。第四層是大模型兜底層處理真正的長尾和復(fù)雜場景最后附上置信度和解釋。這里有一個關(guān)鍵點不是所有請求都會走完四層。每一層都有“高置信直接返回”和“低置信放行到下一層”兩條路徑。用得最多的流量應(yīng)該在第一二層就被處理掉只有少數(shù)請求需要走到第四層——這也是分層能同時控制成本、延遲和準(zhǔn)確率的核心原因。我在項目里實際統(tǒng)計過一組數(shù)據(jù)大約七成的輸入在第一層和第二層就被高置信命中直接在100毫秒內(nèi)返回剩余三成進(jìn)入精排層后又有一半能被規(guī)則和NER模型處理掉最終真正需要調(diào)用大模型的請求占比不超過15%。這個比例直接決定了每月的模型賬單和整體服務(wù)的響應(yīng)速度。2.2 每一層設(shè)計的核心目標(biāo)在設(shè)計每一層時我習(xí)慣用一個“三問法”來約束自己這一層要擋掉什么、要放過什么、放過的代價是什么。這三個問題想清楚層與層之間的邊界自然就清晰了。第一問用于確定層的核心能力第二問用于避免過度設(shè)計第三問用于控制事故半徑。舉個例子清洗層要擋掉的是亂碼、空語句和無意義符號但它必須放過那些口語化的長句因為后面還有模型能處理清洗層不需要在這里追求全對。粗篩層要擋掉的是高頻、單一、特征明顯的意圖但它必須放過那些邊界模糊的樣本——如果粗篩層強(qiáng)行給出答案代價就是誤判后的錯誤工具調(diào)用。在具體落地時我還會給每個層設(shè)計一個獨立的小型評測集。這個評測集不追求覆蓋所有場景只覆蓋該層“應(yīng)該管”的場景。這樣做的好處是每次調(diào)整某一層的邏輯可以立刻看到效果是變好還是變壞而不是被整個系統(tǒng)的指標(biāo)波動攪成一團(tuán)漿糊。層與層之間傳遞的不僅是文本本身還有上游留下的元信息。比如清洗層可以標(biāo)記出“這句話包含訂單號”“這句話包含情緒強(qiáng)烈的詞匯”粗篩層可以附上“這是高置信結(jié)果可直接使用”或“這是低置信結(jié)果建議走精排”。這些元信息讓每一層都清楚地知道自己只是整個流程的組成部分而不是最終裁判。2.3 分層設(shè)計的一個容易忽略的收益故障隔離分層不僅是為了性能和成本還有一個容易被忽略的好處——故障隔離。如果整個系統(tǒng)只有一個大模型在撐一旦模型服務(wù)抖動或Prompt誤改全線崩潰你連回滾的目標(biāo)都不明確。分層之后每一層的依賴是不一樣的粗篩層依賴的是本地推理服務(wù)精排層依賴的是NER模型和規(guī)則庫只有兜底層依賴外部大模型API。這樣即使大模型API掛了你的系統(tǒng)還能靠前兩層支撐大部分高頻場景用戶體驗不會斷崖式下跌。我在生產(chǎn)環(huán)境里專門做過一次演練停掉大模型服務(wù)系統(tǒng)仍然能處理接近70%的請求雖然覆蓋率變差但至少不會出現(xiàn)大面積錯誤。對于一套面向客戶的系統(tǒng)來說這種“降級但不崩潰”的能力往往比某些指標(biāo)上的極致提升更重要。3. 各層的技術(shù)選型與實現(xiàn)要點3.1 清洗層低成本消除輸入的“臟東西”清洗層的地位被很多人低估。實際上輸入質(zhì)量直接決定了后面所有層的表現(xiàn)你喂給模型一堆亂碼就別指望它能輸出什么好東西。清洗層的處理項大致包括文本歸一化全角轉(zhuǎn)半角、繁體轉(zhuǎn)簡體、URL和郵箱提取、Emoji移除或保留標(biāo)記、多余空白壓縮、明顯的廣告和無意義內(nèi)容過濾、以及一些領(lǐng)域?qū)俚那逑匆?guī)則。這里有一個很多人踩過的坑清洗要克制不是清洗得越狠越好。比如你不要把用戶說的“不要了”里“不”字清洗掉否則后面所有否定意圖全部識別失敗。清洗的邊界應(yīng)該是“去除與意圖無關(guān)的噪聲”而不是“替判斷層做決策”。一個實用建議把所有清洗規(guī)則做成可獨立開關(guān)的模塊每一條規(guī)則都配上對應(yīng)的輸入輸出示例。這樣如果某條規(guī)則誤傷了正常輸入你可以在線上快速單獨禁用這一條而不用把整套清洗邏輯回滾。3.2 粗篩層輕量模型的高頻意圖速判粗篩層我推薦用fastText或TextCNN這類輕量模型起步而不是一上來就用BERT。原因很實在粗篩層處理的是七成左右的流量每個請求都要過它對推理時延和吞吐的要求極高。fastText在一臺中等配置的CPU機(jī)器上能達(dá)到每毫秒處理幾條文本的吞吐而BERT即使是tiny版本CPU推理也要幾十毫秒起。粗篩層的分類類別不需要覆蓋全部分支只覆蓋Top 5到Top 10的高頻意圖就夠了剩下的統(tǒng)一歸為“其他”。實際項目中這個層用幾千條標(biāo)注樣本就能訓(xùn)出一個不錯的baseline分類準(zhǔn)確率通常在85%以上——對粗篩來說已經(jīng)足夠了因為拿不準(zhǔn)的它會放給精排層。這里需要特別聊一下閾值設(shè)計。粗篩層輸出的每個類別都有一個概率分?jǐn)?shù)你不能只看最大概率值來判斷。我的習(xí)慣是給每個意圖類別設(shè)獨立閾值高頻意圖的閾值設(shè)在0.6左右因為它的樣本量多、模型學(xué)得扎實低頻意圖的閾值設(shè)在0.8以上寧可漏到下一層也不要輕易給出低置信度的判定。這種設(shè)計很樸素但效果比用一個全局閾值好很多。3.3 精排層規(guī)則與NER模型配合做精細(xì)化判定到了精排層你要處理的是粗篩層認(rèn)為“模棱兩可”的輸入。這層我通常用“NER模型抽取關(guān)鍵實體 規(guī)則引擎做邏輯判斷”的組合。NER負(fù)責(zé)從文本中抽出結(jié)構(gòu)化信息訂單號、商品名、地址、金額、時間等。這些實體本身就是意圖判斷的關(guān)鍵依據(jù)。比如用戶說“我不想要那個藍(lán)色的大衣”如果你的NER能識別出“藍(lán)色大衣”是商品“不想要”是否定情緒規(guī)則引擎就能高置信地判斷這是“退貨”意圖。規(guī)則引擎的價值在精排層體現(xiàn)得最明顯。它能實現(xiàn)很多模型做起來很費勁的邏輯否定詞檢測、雙重否定處理、同義短語映射、時態(tài)判斷等。比如“我之前說要退但現(xiàn)在已經(jīng)收到了”——這句話的意圖是“取消了退貨需求”純模型容易判斷錯但規(guī)則引擎看到“但”字轉(zhuǎn)折再加上“已經(jīng)收到”就能識別出意圖反轉(zhuǎn)。規(guī)則引擎的維護(hù)是一個長期工作。我的做法是每周固定一天review線上誤判樣本把高頻誤判場景抽象成規(guī)則補(bǔ)充進(jìn)去。規(guī)則不是越寫越多越好每新增一條規(guī)則都需要用回歸集跑一遍確保沒有把已有的正確判斷改壞。3.4 大模型兜底層最后一公里的精細(xì)理解與安全控制走到這一層的輸入基本是前兩層搞不定的長尾場景。這一層要開放給大模型但絕不是直接把文本扔給大模型然后等結(jié)果。首先Prompt必須強(qiáng)制模型輸出結(jié)構(gòu)化JSON包含意圖標(biāo)簽、置信度、關(guān)鍵依據(jù)字段和一句話解釋。其次要明確告訴模型“不確定時必須輸出低置信度并建議冒泡到人工處理”而不是逼著模型硬選一個答案。我見過最經(jīng)典的大模型兜底翻車案例是用戶輸入“你們這些操作流程是違法的吧”某些模型在沒有上下文的情況下會把這一句判斷為“法律咨詢”意圖然后Agent真的去找法務(wù)工具了。為了避免這種情況我在兜底層加了兩條硬規(guī)則第一條涉及安全、法律、醫(yī)療、金融的敏感詞無論模型輸出什么系統(tǒng)都強(qiáng)制走人工審核第二條大模型輸出任何意圖之前必須先給出支持該判斷的文本依據(jù)系統(tǒng)會檢查這個依據(jù)是否真的是用戶原話中的內(nèi)容防止模型憑空造依據(jù)。大模型層的成本控制也很關(guān)鍵。我會用“意圖ID緩存”和“語義相似度緩存”來復(fù)用歷史結(jié)果如果用戶輸入的語義和某個歷史請求相似度超過0.95就直接返回歷史意圖不再調(diào)用大模型。實測下來這個簡單策略能省下20%到30%的大模型調(diào)用量。4. 實操落地一個客服工單Agent的完整案例4.1 場景定義與數(shù)據(jù)集準(zhǔn)備為了把上面的設(shè)計落成可復(fù)現(xiàn)的步驟我用一個實際的“客服工單自動分派Agent”來演示。這個Agent的輸入是用戶提交的工單文本輸出是意圖標(biāo)簽工單系統(tǒng)根據(jù)意圖自動分派給對應(yīng)處理組。意圖類別設(shè)計為六個退款、換貨、物流查詢、發(fā)票問題、投訴建議、其他。前五個是高頻意圖最后一個“其他”用于兜底長尾。數(shù)據(jù)集方面我準(zhǔn)備了兩套主訓(xùn)練集是人工標(biāo)注的5000條樣本類別分布大致是退款25%、物流查詢20%、換貨15%、發(fā)票10%、投訴建議10%、其他20%評測集是單獨留出的1000條樣本用于各層的效果驗證。這里有個實操經(jīng)驗標(biāo)注數(shù)據(jù)不要全讓標(biāo)注團(tuán)隊標(biāo)。我建議先用大模型批量加標(biāo)注也就是讓大模型對每一條樣本給出意圖和理由然后人工只審核置信度低的那部分。這樣5000條樣本的標(biāo)注量人工實際需要看的大概只有1500條左右。4.2 粗篩層和精排層的實現(xiàn)示例粗篩層用fastText訓(xùn)練核心代碼很簡單import fasttext # 訓(xùn)練粗篩分類模型 model fasttext.train_supervised( inputtrain_clean.txt, lr0.5, epoch25, wordNgrams2, dim100, minCount1, losssoftmax ) # 保存模型 model.save_model(intent_l1.bin) # 預(yù)測時返回概率 labels, probabilities model.predict(我不想要這個訂單了, k3) print(labels, probabilities)訓(xùn)練數(shù)據(jù)格式是fasttext的標(biāo)準(zhǔn)格式__label__退款 我不想要這個訂單了。樣本量不大十幾秒就訓(xùn)完了。實測在評測集上這個簡單模型對六個類別的加權(quán)準(zhǔn)確率能到86%左右對退款的單獨召回率更是超過90%。精排層我用了輕量NER加規(guī)則判斷。NER負(fù)責(zé)抽取訂單號、金額、商品關(guān)鍵詞和否定詞規(guī)則引擎根據(jù)這些抽取值做組合判斷。比如一個典型的規(guī)則IF 包含否定詞 AND 包含訂單號 AND 含商品提及 THEN 意圖退款 IF 包含“發(fā)票” OR “開票” THEN 意圖發(fā)票問題優(yōu)先級高于退款 IF 包含物流詞發(fā)貨/到哪/快遞 AND NOT 包含否定詞 THEN 意圖物流查詢每條規(guī)則都帶條件的優(yōu)先級。發(fā)票、投訴這類邊界明確的詞規(guī)則優(yōu)先級要高于NER組合判斷這樣能減少誤判。4.3 LLM兜底層的Prompt設(shè)計送入兜底層的Prompt我經(jīng)過多次迭代后固定成了下面這個模板你是工單意圖識別系統(tǒng)的一部分。請判斷用戶輸入的意圖并返回JSON。 意圖選項退款、換貨、物流查詢、發(fā)票問題、投訴建議、其他。 要求 1. 必須返回合法JSON格式為{intent: , confidence: 0-1, evidence: 支持判斷的關(guān)鍵句子, uncertain: true/false} 2. confidence要求嚴(yán)格評估不確定時不能超過0.6 3. uncertain為true時代表你判斷不了系統(tǒng)將轉(zhuǎn)人工處理 4. 只根據(jù)用戶輸入原文判斷不要推理輸入之外的信息 5. 如果輸入涉及違法、安全、人身傷害等內(nèi)容直接設(shè)置intent為“其他”uncertain為true 用戶輸入{user_input}這里有三個細(xì)節(jié)值得說明。第一uncertain字段是非常重要的安全網(wǎng)。模型寫得越自由越容易在邊界輸入上犯錯讓它主動承認(rèn)不確定比讓它硬猜更可靠。第二明確要求模型只根據(jù)原文判斷能減少幻覺式的推理。第三安全相關(guān)指令寫在Prompt里但要記得Prompt只是軟約束真正硬性的攔截要靠系統(tǒng)層的敏感詞列表和人工審核流程。4.4 閾值調(diào)參與整體效果評估整個漏斗串起來之后需要重點調(diào)的是各層的閾值。我的調(diào)參流程有固定套路先在評測集上跑一遍統(tǒng)計每層的預(yù)測分?jǐn)?shù)分布畫出“分?jǐn)?shù)閾值-準(zhǔn)確率/召回率”曲線然后從業(yè)務(wù)角度選擇閾值。選擇的邏輯是優(yōu)先消滅“高置信但是錯的”樣本。具體操作是把準(zhǔn)確率曲線上“最后一段接近1.0但仍然有錯”的位置選為閾值點寧可在那個區(qū)間漏掉一些對的結(jié)果也不要把錯的放進(jìn)高置信通道。我最終的參數(shù)配置是粗篩層高頻類別閾值0.6、低頻類別閾值0.8精排層規(guī)則命中即返回單規(guī)則匹配數(shù)不低于2個才允許高置信大模型層的置信度門檻是0.9confidence低于0.9的全部轉(zhuǎn)人工。跑完整個流程后的評測數(shù)據(jù)是全量準(zhǔn)確率96.2%單條請求P99延遲480毫秒大模型調(diào)用占比11.7%。對比原來“全量走大模型”的方案準(zhǔn)確率基本持平延遲從平均1.8秒降到了平均180毫秒每百萬條請求的模型成本下降了約78%。這個結(jié)果讓我確信分層漏斗不是犧牲質(zhì)量換成本而是在幾乎不損失質(zhì)量的前提下大幅優(yōu)化了成本和體驗。5. 常見問題與排查技巧實錄5.1 相似意圖混淆怎么辦運(yùn)營一個真實系統(tǒng)之后最高頻的誤判場景集中在“退款”和“換貨”、“物流查詢”和“投訴”這幾組相似意圖上。比如用戶說“我要把換回來的東西退了”——這句話里同時包含換貨和退款兩個信號很多人會把意圖誤判成換貨。這類問題我的排查順序是先看清洗層有沒有把關(guān)鍵詞弄丟再看粗篩層的概率分布如果兩個類別的概率非常接近說明特征本身就混淆就可以用精排層的規(guī)則硬性定優(yōu)先級。在這個例子里“退”出現(xiàn)在“換”之后語義上更接近取消行為規(guī)則可以定為“退貨關(guān)鍵詞優(yōu)先于換貨關(guān)鍵詞觸發(fā)”。相似意圖還有一個排查方向看看是不是上下文缺失導(dǎo)致的。很多工單文本只是用戶對話中的一句話缺少前文。這時候單靠當(dāng)前文本確實判斷不了正確做法是讓系統(tǒng)返回“需要澄清”而不是硬分派一個意圖。為此我在漏斗出口設(shè)計了一個“澄清請求”通道當(dāng)最終置信度仍不足時Agent會先向用戶問一句“您是想退款還是換貨”這比猜一個意圖然后走錯流程要省太多事。5.2 冷啟動階段沒有標(biāo)注數(shù)據(jù)如果你剛接手一個全新場景的Agent手頭沒有任何標(biāo)注數(shù)據(jù)怎么搭漏斗我的經(jīng)驗是先用大模型蒸餾一批偽標(biāo)注數(shù)據(jù)。把你從日志里找到的一萬條真實輸入用大模型打上意圖標(biāo)簽和理由然后人工抽檢500條如果抽檢一致率達(dá)到90%以上就用這批偽標(biāo)注數(shù)據(jù)去訓(xùn)粗篩模型。粗篩模型訓(xùn)出來后再反哺一批“模型認(rèn)為低置信的樣本”讓人工集中標(biāo)注這部分形成循環(huán)迭代。這個思路的本質(zhì)是讓最貴的模型去做標(biāo)注讓便宜的模型去承接流量人只需要做最后的質(zhì)量把關(guān)而不是從頭純?nèi)斯?biāo)注。我實際用下來第一周就能讓粗篩層達(dá)到75%以上的準(zhǔn)確率三周后穩(wěn)定在85%以上。5.3 延遲和性能瓶頸排查分層漏斗上線后如果發(fā)現(xiàn)P99延遲飆高優(yōu)先排查的不是模型服務(wù)而是你的調(diào)用鏈路有沒有串行化的浪費。最常見的問題是每一層都等上一層的最終結(jié)果才開始明明粗篩層已經(jīng)高置信了后面還是象征性地把請求發(fā)到了下一層做驗證。我給粗篩層加了“短路開關(guān)”高置信請求直接返回低置信請求才繼續(xù)向下轉(zhuǎn)發(fā)。這個改動在很多情況下能讓P99延遲直接砍半。另一個性能坑是規(guī)則引擎的正則太復(fù)雜。有些正則表達(dá)式在最壞情況下會回溯很久一條請求卡個幾百毫秒也不奇怪。建議把所有正則加上超時保護(hù)并定期用數(shù)據(jù)集基準(zhǔn)測試來發(fā)現(xiàn)哪些正則拖慢了整體速度。5.4 安全層面的邊界約束做意圖識別漏斗必然要考慮安全邊界。因為意圖識別通常位于Agent技術(shù)棧的最前端如果這里被繞過后面所有工具調(diào)用和記憶系統(tǒng)都會面臨風(fēng)險。我把安全措施也做成了漏斗形態(tài)清洗層移除可疑注入模式粗篩層識別“越權(quán)指令”意圖精排層檢測敏感實體兜底層強(qiáng)制走人工。整個過程里有一條硬性規(guī)則——涉及安全、法律、醫(yī)療等高風(fēng)險領(lǐng)域的內(nèi)容不設(shè)“自動高置信通道”一律人工審核。這條規(guī)則沒有任何例外。另外就是日志脫敏。意圖識別系統(tǒng)的日志中往往會包含用戶的原話如果不做脫敏一旦日志泄露最壞情況是用戶隱私批量暴露。我的做法是日志落盤前對文本中的手機(jī)號、身份證號、家庭住址、銀行卡號做正則脫敏替換保留實體類型但不保留原文。這樣雖然損失了部分可回溯性但安全性提升明顯。6. 一些踩坑后的個人體會做完這個項目之后再回看我最想對外分享的一句話是工業(yè)級Agent不是用更好的模型堆出來的而是用更清楚的邊界堆出來的。邊界體現(xiàn)在很多層面。層與層之間的邊界決定了每層能做什么、不能做什么閾值與置信度之間的邊界決定了系統(tǒng)敢不敢返回結(jié)果自動處理與人工審核的邊界決定了事故能不能被攔在最后一米。我踩過最貴的一個坑是早期把規(guī)則引擎寫得太激進(jìn)。有一段時間線上突然出現(xiàn)了大量“退款”意圖排查了很久才發(fā)現(xiàn)是新上的一條規(guī)則“只要出現(xiàn)‘退’字就判定為退款”誤傷了所有包含“退貨運(yùn)費”的物流查詢。教訓(xùn)很深刻規(guī)則一定要寫條件組合單一關(guān)鍵詞永遠(yuǎn)不要作為意圖級別的判定依據(jù)。第二個印象深刻的教訓(xùn)是評測集要定期更新。最初的評測集用久了模型和規(guī)則都已經(jīng)過擬合到那1000條樣本上了每次改動都看著漲點上線后卻頻頻翻車。后來我把評測集改成月度滾動機(jī)制每個月淘汰一批舊的、加入一批新采集的真實誤判樣本效果才恢復(fù)穩(wěn)定。最后分享一個小技巧無論你的漏斗設(shè)計得有多完整上線初期一定要保留一個“真實流量回放”的離線環(huán)境。把當(dāng)天線上的請求原樣記錄下來隨后跑一遍當(dāng)天的漏斗版本和最新版本對比兩者的輸出差異。這個習(xí)慣幫我發(fā)現(xiàn)過好幾輪Prompt冷熱切換導(dǎo)致的行為漂移成本幾乎為零但這一個動作就能避免好多次線上事故。意圖識別分層漏斗不是什么花哨的技術(shù)它就是一套樸素的工程化思維把復(fù)雜問題拆開每一層都做自己有把握的事把不確定的部分明確暴露出來。如果你的Agent正在被“用戶說不清話”折磨不妨先從兩層漏斗跑起來——清洗加粗篩跑通之后再往上疊精排和LLM兜底。很多時候完成比完美重要跑起來比討論架構(gòu)重要。