在實(shí)際的大語(yǔ)言模型對(duì)話應(yīng)用中用戶很少會(huì)像考試題一樣把完整需求一次性說(shuō)清楚。更常見(jiàn)的情況是先說(shuō)要做什么再補(bǔ)一個(gè)條件中途又換了一個(gè)方向最后還可能說(shuō)“還是按最開始那個(gè)方案來(lái)”。這種需求不斷變化的過(guò)程就是用戶意圖的演變。很多開發(fā)者在調(diào)試對(duì)話應(yīng)用時(shí)遇到過(guò)類似現(xiàn)象模型在單輪問(wèn)答里表現(xiàn)得很好但用戶連續(xù)聊幾輪之后系統(tǒng)就開始答非所問(wèn)——要么死守最初的理解要么被最后一句帶跑。這個(gè)問(wèn)題有一個(gè)貼近研究語(yǔ)境的描述LLMs Get Lost in Evolving User Intent也就是語(yǔ)言模型在處理持續(xù)演變的用戶意圖時(shí)會(huì)“迷失”。這篇文章會(huì)按這樣的順序展開先界定什么是演變的用戶意圖再?gòu)?Transformer 的注意力機(jī)制和工程實(shí)現(xiàn)方式分析模型為什么會(huì)迷失接著用最小實(shí)驗(yàn)讓現(xiàn)象可復(fù)現(xiàn)然后給出四種工程化緩解策略并落地一個(gè)意圖狀態(tài)管理模塊。最后補(bǔ)充生產(chǎn)環(huán)境中的參數(shù)選擇、常見(jiàn)坑、評(píng)估方法和上線檢查清單。內(nèi)容適合正在做對(duì)話系統(tǒng)、Agent、客服機(jī)器人、智能推薦等方向的開發(fā)者和算法工程師也適合剛接觸 LLM 應(yīng)用開發(fā)、想理解“為什么模型聊多了就跑偏”的讀者。1. 先理解“演變中的用戶意圖”到底難在哪里1.1 靜態(tài)意圖與動(dòng)態(tài)意圖的區(qū)別在傳統(tǒng) NLP 里意圖識(shí)別通常被建模成一個(gè)分類問(wèn)題給一句話判斷它是查詢天氣、訂機(jī)票還是閑聊。這種做法把每個(gè)用戶輸入當(dāng)成獨(dú)立樣本處理意圖是靜態(tài)的。但在真實(shí)多輪對(duì)話中用戶意圖很少是靜態(tài)的。用戶可能在第一輪表達(dá)核心目標(biāo)第二輪補(bǔ)充限制條件第三輪因?yàn)樾滦畔⒍{(diào)整目標(biāo)第四輪又推翻之前的決定。這種動(dòng)態(tài)變化要求系統(tǒng)不僅理解“當(dāng)前這句話在說(shuō)什么”還要理解“這句話相對(duì)之前的意圖做了什么修改”。兩者最大的區(qū)別在于靜態(tài)意圖看重“當(dāng)前輸入的獨(dú)立語(yǔ)義”。動(dòng)態(tài)意圖看重“當(dāng)前輸入與歷史決策之間的增量關(guān)系”。比如同一句話“還是便宜的更好”如果前文在對(duì)比兩臺(tái)筆記本它表示選擇低價(jià)機(jī)型如果前文在討論顯卡品牌它表示降低顯卡預(yù)算。脫離歷史這句話的意圖就是模糊的。LLM 雖然在單句理解上很強(qiáng)但把它放進(jìn)不斷變化的上下文里它并沒(méi)有天然的機(jī)制去維護(hù)一個(gè)可查詢、可更新、可回滾的“意圖狀態(tài)”。1.2 意圖演變的四種典型模式觀察真實(shí)用戶行為后可以把意圖演變歸納成四類模式。每種模式對(duì)系統(tǒng)的要求都不一樣。演變模式用戶表現(xiàn)LLM 容易出現(xiàn)的錯(cuò)誤系統(tǒng)需要做什么細(xì)化逐步補(bǔ)充限制條件把補(bǔ)充條件當(dāng)成新話題追加約束保留已有信息切換明確表示換了目標(biāo)仍然沿用舊需求生成結(jié)果識(shí)別切換重建狀態(tài)回退說(shuō)“還是按原來(lái)的來(lái)”當(dāng)成全新需求丟失原約束保存歷史快照支持恢復(fù)模糊化需求越說(shuō)越含糊直接丟棄早期信息標(biāo)記待澄清主動(dòng)反問(wèn)以“細(xì)化”為例用戶說(shuō)“我想買臺(tái)筆記本”然后說(shuō)“屏幕要好一點(diǎn)”再補(bǔ)一句“主要用來(lái)剪視頻”。這三句話合在一起才構(gòu)成完整意圖。如果把每句話獨(dú)立處理第二次是在追加屏幕要求第三次是在追加用途要求而不是在換話題。很多系統(tǒng)出錯(cuò)是因?yàn)槟Ｐ桶押笱a(bǔ)充的信息誤判成了替代關(guān)系?！扒袚Q”模式則是另一類難題。用戶說(shuō)“算了筆記本先不看幫我看看臺(tái)式機(jī)”這是一次明確的話題切換。系統(tǒng)一邊要保留用戶對(duì)“視頻剪輯”和“預(yù)算”這類跨話題仍然有效的偏好一邊要把設(shè)備類型從筆記本換成臺(tái)式機(jī)。如果直接清空所有狀態(tài)用戶就得重新說(shuō)一遍需求如果完全不清空模型又會(huì)把臺(tái)式機(jī)推薦當(dāng)成筆記本推薦。1.3 為什么多輪場(chǎng)景比單輪問(wèn)答難單輪問(wèn)答可以看作一個(gè)“給定問(wèn)題生成答案”的映射。模型的輸入是完整可見(jiàn)的答案只需要對(duì)齊這一句話。多輪場(chǎng)景引入了幾個(gè)額外的變量時(shí)間順序哪句話先出現(xiàn)哪句話后出現(xiàn)直接影響意圖的覆蓋關(guān)系。指代關(guān)系用戶說(shuō)“那個(gè)”“這個(gè)”“還是剛才說(shuō)的”都需要回到歷史中解析。更新語(yǔ)義用戶是在追加信息、替換信息還是撤銷信息單靠文本相似度無(wú)法判斷。信息權(quán)重不是所有歷史信息都同等重要。預(yù)算和核心目標(biāo)通常比語(yǔ)氣詞重要得多。LLM 本身沒(méi)有“狀態(tài)”概念。它只是一個(gè)基于上下文的概率生成器。把多輪消息直接拼進(jìn) prompt本質(zhì)上是在賭模型能從純文本中隱式推斷出狀態(tài)。對(duì)話變短時(shí)問(wèn)題不大對(duì)話變長(zhǎng)、意圖變化次數(shù)變多后模型就會(huì)在文本海洋里丟失關(guān)鍵信號(hào)。2. 從模型機(jī)制看 LLM 為什么會(huì)在意圖演變中迷失2.1 近因偏差后說(shuō)的話往往贏得更多注意力Transformer 的注意力機(jī)制會(huì)計(jì)算每個(gè) token 與上下文中其他 token 的相關(guān)度但實(shí)際應(yīng)用中靠近 prompt 末尾的 token 往往對(duì)輸出影響更大。這是因?yàn)樯蓵r(shí)模型需要把“最近讀到的信息”作為續(xù)寫依據(jù)位置編碼也會(huì)顯著影響相關(guān)性計(jì)算。放在對(duì)話場(chǎng)景里這個(gè)機(jī)制會(huì)造成一種典型錯(cuò)誤用戶前幾輪明確說(shuō)了預(yù)算不能超過(guò) 8000最后一輪隨口問(wèn)“那 4080 顯卡的機(jī)器怎么樣”模型可能直接忽略預(yù)算約束推薦一臺(tái) 1 萬(wàn)多的設(shè)備。原因不是模型“不聽話”而是它在計(jì)算概率時(shí)最后那句關(guān)于顯卡的提問(wèn)把注意力拉走了。離模型最近的文本天然擁有更高權(quán)重。緩解辦法不是給模型加提示說(shuō)“請(qǐng)記住預(yù)算”而是要在輸入層面把關(guān)鍵約束放到足夠顯眼的位置最好獨(dú)立于對(duì)話流水單獨(dú)固定在 prompt 的安全區(qū)域。這一點(diǎn)后面會(huì)展開。2.2 早期關(guān)鍵信息被上下文稀釋當(dāng)對(duì)話輪次不斷增多時(shí)早期信息會(huì)被不斷壓縮、折疊、混合。即使模型有 128K 的上下文窗口它也不會(huì)像數(shù)據(jù)庫(kù)一樣精確記住“第三輪用戶說(shuō)過(guò)預(yù)算 8000”。上下文窗口只是“能容納”不等于“能精確保留語(yǔ)義”。從信息論角度看每輪新增的消息都會(huì)改變整個(gè)序列的概率分布。后加入的內(nèi)容會(huì)與已有內(nèi)容產(chǎn)生注意力交互早期 token 的特征向量經(jīng)過(guò)多層編碼后會(huì)被大量后續(xù)信息覆蓋。用戶最初的訴求是“剪輯 4K 視頻”聊了二十輪后這個(gè)信息在向量空間里可能已經(jīng)變得非常微弱。這也是為什么建議不要把全部歷史消息直接塞給模型。原始材料的價(jià)值密度會(huì)隨著輪次增長(zhǎng)而下降真正需要保留的是從歷史中抽取出來(lái)的結(jié)構(gòu)化意圖狀態(tài)而不是逐字逐句的聊天記錄。2.3 對(duì)話狀態(tài)缺乏顯式維護(hù)機(jī)制LLM 應(yīng)用最常見(jiàn)的做法是把messages數(shù)組不斷追加用戶說(shuō)一句往列表里加一條然后整體發(fā)給模型。這種方式本身沒(méi)有錯(cuò)誤錯(cuò)誤在于把“消息歷史”當(dāng)成了“對(duì)話狀態(tài)”。對(duì)話狀態(tài)應(yīng)該是可查詢的當(dāng)前用戶的最終目標(biāo)是什么、已經(jīng)確認(rèn)的條件有哪些、哪些條件還沖突、上一輪意圖與當(dāng)前意圖是什么關(guān)系。但消息歷史只是原始事件流它不區(qū)分事實(shí)和情緒不區(qū)分已確認(rèn)和待確認(rèn)也不區(qū)分舊信息和新信息。意圖一旦演變?cè)嘉谋臼恰把葑兦暗膬?nèi)容”和“演變后的內(nèi)容”的混合物模型必須自己推斷哪一個(gè)覆蓋哪一個(gè)。比如用戶說(shuō)“預(yù)算 8000”三分鐘后說(shuō)“預(yù)算可以放寬到 10000”。從消息歷史看這兩句話是兩條獨(dú)立消息模型需要自己判斷后一句覆蓋前一句。文本里沒(méi)有顯式標(biāo)記“這是一次 REPLACE 操作”模型只能靠語(yǔ)義做概率推斷出錯(cuò)是正常的。2.4 指令沖突與自我漂移另一種迷失來(lái)自系統(tǒng)指令的沖突。很多應(yīng)用會(huì)在系統(tǒng)提示里寫“請(qǐng)優(yōu)先按照用戶最新要求執(zhí)行”同時(shí)又要求“記住用戶的初始目標(biāo)”。當(dāng)用戶最新一句話是在初始目標(biāo)基礎(chǔ)上做細(xì)化時(shí)這兩條指令沒(méi)有沖突但用戶最新一句話是在否定初始目標(biāo)時(shí)模型就會(huì)出現(xiàn)兩難。例如系統(tǒng)要求原則一記住用戶最開始的目標(biāo)。原則二用戶最新意圖優(yōu)先。當(dāng)用戶說(shuō)“還是算了不買筆記本了幫我看看顯示器”模型可能既能生成筆記本相關(guān)的推薦也能生成顯示器推薦具體結(jié)果取決于哪條原則在注意力分布中更占優(yōu)勢(shì)。這種搖擺就是“自我漂移”。要解決這個(gè)問(wèn)題必須把“更新還是覆蓋”的判斷從模型隱式推斷中剝離出來(lái)交給顯式的狀態(tài)操作。用戶明確說(shuō)“算了換成別的”這是一次 SWITCH用戶說(shuō)“再加一個(gè)條件”這是一次 ADD用戶說(shuō)“還是按最早那個(gè)方案”這是一次 ROLLBACK。只有把這些操作建模清楚模型才不需要猜測(cè)。3. 用最小實(shí)驗(yàn)讓“迷失”現(xiàn)象可復(fù)現(xiàn)3.1 實(shí)驗(yàn)場(chǎng)景設(shè)計(jì)為了不依賴具體模型也能觀察問(wèn)題可以先做一個(gè)純文本實(shí)驗(yàn)?zāi)M一段意圖持續(xù)演變的對(duì)話然后用兩種方式構(gòu)造輸入對(duì)比哪種方式更能保留關(guān)鍵信息。第一種方式是“直接截取最近幾輪”模擬很多人使用messages[-5:]的做法。第二種方式是“先抽取結(jié)構(gòu)化意圖狀態(tài)再根據(jù)狀態(tài)生成壓縮摘要”。這個(gè)實(shí)驗(yàn)不調(diào)用任何大模型 API只對(duì)比信息保留結(jié)果用來(lái)說(shuō)明消息歷史與意圖狀態(tài)之間的鴻溝。對(duì)話劇本設(shè)計(jì)如下用戶我想買一臺(tái)剪輯 4K 視頻的筆記本。用戶預(yù)算控制在 8000 以內(nèi)。用戶平時(shí)主要用達(dá)芬奇調(diào)色。用戶算了還是看看臺(tái)式機(jī)。用戶你覺(jué)得哪種處理器更適合我這個(gè)劇本里存在兩次重要演變從筆記本切到臺(tái)式機(jī)從具體機(jī)型咨詢變成處理器對(duì)比。真正跨輪次始終有效的約束是“剪輯 4K 視頻”和“預(yù)算 8000 以內(nèi)”真正被替換掉的是設(shè)備類型。3.2 示例代碼# 模擬一段會(huì)演變的對(duì)話 turns [ 我想買一臺(tái)剪輯4K視頻的筆記本, 預(yù)算控制在8000以內(nèi), 平時(shí)主要用達(dá)芬奇調(diào)色, 算了還是看看臺(tái)式機(jī), 你覺(jué)得哪種處理器更適合我, ] # 方案一只保留最近 N 輪原文 def recent_context(messages, keep2): return messages[-keep:] # 方案二抽取結(jié)構(gòu)化意圖狀態(tài) def extract_state(messages): state { device: , purpose: , budget: , software: , confirmed: [], } for text in messages: if 筆記本 in text: state[device] 筆記本 if 臺(tái)式機(jī) in text: state[device] 臺(tái)式機(jī) if 4K in text or 調(diào)色 in text: state[purpose] 視頻剪輯/調(diào)色 if 8000 in text: state[budget] 8000以內(nèi) if 達(dá)芬奇 in text: state[software] 達(dá)芬奇 return state print(方案一最后兩條原文) for item in recent_context(turns, 2): print( -, item) print(\n方案二結(jié)構(gòu)化狀態(tài)) state extract_state(turns) for key, value in state.items(): print(f - {key}: {value if value else 未確認(rèn)})輸出結(jié)果是方案一最后兩條原文 - 算了還是看看臺(tái)式機(jī) - 你覺(jué)得哪種處理器更適合我 方案二結(jié)構(gòu)化狀態(tài) - device: 臺(tái)式機(jī) - purpose: 視頻剪輯/調(diào)色 - budget: 8000以內(nèi) - software: 達(dá)芬奇 - confirmed: []從這個(gè)例子可以清晰看到問(wèn)題如果只保留最近兩條原始消息系統(tǒng)完全丟失了“剪輯 4K 視頻”和“預(yù)算 8000 以內(nèi)”這兩個(gè)關(guān)鍵約束。模型看到最后兩條消息只會(huì)知道用戶在問(wèn)臺(tái)式機(jī)處理器無(wú)法知道用戶需要高性價(jià)比、適合 4K 剪輯的臺(tái)式機(jī)。結(jié)構(gòu)化方案也存在問(wèn)題它把所有信息都當(dāng)成“追加”不知道“筆記本”被“臺(tái)式機(jī)”覆蓋了。說(shuō)明只抽取不更新同樣不夠還需要一套明確的狀態(tài)變更規(guī)則。3.3 實(shí)驗(yàn)結(jié)果觀察這個(gè)最小實(shí)驗(yàn)揭示了兩個(gè)工程結(jié)論截?cái)鄽v史可以控制 prompt 長(zhǎng)度但絕不能代替狀態(tài)管理。截?cái)嘀粫?huì)讓模型看到更少的證據(jù)它原本就隱式推斷不足的問(wèn)題會(huì)被進(jìn)一步放大。單純抽取字段也不等于理解意圖演變。必須區(qū)分 ADD、REPLACE、SWITCH、ROLLBACK 四種操作否則抽取出來(lái)的狀態(tài)可能是自相矛盾的。用真實(shí) LLM 做同樣測(cè)試時(shí)現(xiàn)象會(huì)更明顯。保持同樣對(duì)話第一問(wèn)讓模型用“最近兩條消息”作答第二問(wèn)讓模型用“結(jié)構(gòu)化狀態(tài)”作答。前者很可能推薦一個(gè)高價(jià)臺(tái)式機(jī)配置后者則更有可能給出符合 4K 剪輯和 8000 預(yù)算的方案。這就是“迷失”在業(yè)務(wù)結(jié)果上的體現(xiàn)。4. 緩解迷失的四種工程化策略4.1 顯式對(duì)話狀態(tài)跟蹤第一步是改變思路不再把“消息歷史”當(dāng)作系統(tǒng)記憶而是單獨(dú)維護(hù)一份經(jīng)過(guò)結(jié)構(gòu)化處理的對(duì)話狀態(tài)。對(duì)話狀態(tài)至少需要包含topic當(dāng)前主話題。task用戶當(dāng)前的核心任務(wù)。constraints已經(jīng)確認(rèn)的約束條件。status當(dāng)前狀態(tài)是進(jìn)行中、待澄清還是已切換。version意圖版本的編號(hào)用于支持回退。每次用戶輸入進(jìn)來(lái)先通過(guò)一個(gè)分類模塊判斷這次輸入屬于 ADD、REPLACE、SWITCH 還是 ROLLBACK再?zèng)Q定如何修改狀態(tài)。只有狀態(tài)確認(rèn)后才根據(jù)狀態(tài)構(gòu)造發(fā)給模型的 prompt。模型生成時(shí)不再直接面對(duì)一大段歷史流水賬而是面對(duì)一份已經(jīng)整理好的需求清單。4.2 關(guān)鍵信息錨定與上下文壓縮即使不用完整狀態(tài)管理也可以采用一種輕量級(jí)優(yōu)化把關(guān)鍵約束從歷史中提取出來(lái)放到 prompt 的固定區(qū)域。假設(shè)系統(tǒng)提示原本是你是一個(gè)購(gòu)機(jī)助手請(qǐng)根據(jù)用戶消息給出建議。改進(jìn)后可以變成system_prompt f 你是購(gòu)機(jī)助手。用戶當(dāng)前需求如下 - 主話題{state[device]} - 核心任務(wù){(diào)state[purpose]} - 預(yù)算約束{state[budget] or 未指定} - 軟件要求{state[software] or 未指定} 如果用戶提供的條件與上述狀態(tài)沖突以用戶最新明確要求為準(zhǔn)。 如果用戶只是補(bǔ)充信息不要替換原有約束。 這樣做有三個(gè)好處關(guān)鍵約束在 prompt 開頭重復(fù)出現(xiàn)注意力更容易覆蓋。壓縮掉無(wú)關(guān)歷史降低早期信息被稀釋的風(fēng)險(xiǎn)。通過(guò)顯式文本告訴模型當(dāng)前狀態(tài)與用戶最新輸入的關(guān)系減少自我漂移。上下文壓縮可以結(jié)合摘要實(shí)現(xiàn)。每幾輪對(duì)話就用一個(gè)獨(dú)立模型把舊消息壓縮成結(jié)構(gòu)化狀態(tài)或簡(jiǎn)短紀(jì)要而不是直接截?cái)?。重點(diǎn)是從“保留最后幾句”變成“保留最重要的語(yǔ)義”。4.3 意圖變化檢測(cè)與澄清確認(rèn)意圖變化檢測(cè)是這類系統(tǒng)的核心模塊。它不需要非常復(fù)雜關(guān)鍵是定義清楚“什么算變化”。推薦的做法是維護(hù)一個(gè)輕量分類器輸入是上一輪狀態(tài)加上當(dāng)前用戶消息輸出是四類操作之一ADD新增約束或補(bǔ)充細(xì)節(jié)已有狀態(tài)不變。REPLACE某個(gè)字段被新值覆蓋。SWITCH主話題或目標(biāo)任務(wù)發(fā)生切換。ROLLBACK用戶要求回到之前某個(gè)版本。對(duì)于 SWITCH 和 ROLLBACK系統(tǒng)不應(yīng)該直接執(zhí)行。更好的方式是先向用戶確認(rèn)“你是想徹底切換話題還是在當(dāng)前話題下補(bǔ)充條件”這一步能明顯減少誤殺。例如用戶說(shuō)“還是看看臺(tái)式機(jī)”這可能是 SWITCH也可能是補(bǔ)充信息。如果系統(tǒng)自動(dòng)判斷為 SWITCH原有預(yù)算約束仍然應(yīng)該保留但設(shè)備類型字段要覆蓋。如果用戶說(shuō)“算了剛才說(shuō)的都不算”這才是完整的 ROLLBACK。4.4 用結(jié)構(gòu)化協(xié)議約束意圖更新為了讓意圖狀態(tài)可維護(hù)、可回滾可以把狀態(tài)變更建模成事件流而不是直接修改一個(gè)可變對(duì)象。每個(gè)變更事件記錄變更類型。變更字段。變更前值。變更后值。觸發(fā)該變更的用戶消息。時(shí)間戳。這樣即使?fàn)顟B(tài)被改錯(cuò)了也能從事件流中恢復(fù)。這在用戶反復(fù)調(diào)整需求時(shí)尤其有用。用戶先說(shuō)要 A然后說(shuō)改成 B最后說(shuō)“剛才 B 不合適還是用 A 吧”。如果沒(méi)有事件流系統(tǒng)只能重新問(wèn)一遍原始需求有了事件流就可以直接回滾到 A 版本。5. 實(shí)現(xiàn)一個(gè)意圖演變感知的會(huì)話模塊5.1 需求與數(shù)據(jù)設(shè)計(jì)為了演示真實(shí)的工程化方案下面實(shí)現(xiàn)一個(gè)最小可運(yùn)行的意圖狀態(tài)管理器。它不依賴具體 LLM只負(fù)責(zé)維護(hù)意圖狀態(tài)供上層調(diào)用。核心數(shù)據(jù)結(jié)構(gòu)from dataclasses import dataclass, field from typing import Optional dataclass class IntentState: topic: str task: str constraints: dict field(default_factorydict) version: int 0 last_action: str dataclass class IntentDelta: action: str # ADD / REPLACE / SWITCH / ROLLBACK field_name: Optional[str] None value: Optional[object] None snapshot_id: Optional[int] None dataclass class StateSnapshot: version: int state_copy: IntentState source_text: str每個(gè)IntentState代表一個(gè)版本的意圖狀態(tài)。版本號(hào)遞增每次變更都會(huì)生成快照以便回退。5.2 核心實(shí)現(xiàn)class IntentStateManager: def __init__(self): self.state IntentState() self.snapshots [] self.operations [] def _save_snapshot(self, source_text: str): snapshot StateSnapshot( versionself.state.version, state_copyIntentState( topicself.state.topic, taskself.state.task, constraintsself.state.constraints.copy(), versionself.state.version, last_actionself.state.last_action, ), source_textsource_text, ) self.snapshots.append(snapshot) self.operations.append(source_text) def _next_version(self, action: str): self.state.version 1 self.state.last_action action def apply_delta(self, delta: IntentDelta, source_text: str): self._save_snapshot(source_text) if delta.action ADD: self._apply_add(delta) elif delta.action REPLACE: self._apply_replace(delta) elif delta.action SWITCH: self._apply_switch(delta) elif delta.action ROLLBACK: self._apply_rollback(delta) else: raise ValueError(funknown action: {delta.action}) self._next_version(delta.action) return self.state def _apply_add(self, delta: IntentDelta): if delta.field_name constraints: for key, value in delta.value.items(): self.state.constraints[key] value else: setattr(self.state, delta.field_name, delta.value) def _apply_replace(self, delta: IntentDelta): if delta.field_name constraints: self.state.constraints[delta.value[0]] delta.value[1] else: setattr(self.state, delta.field_name, delta.value) def _apply_switch(self, delta: IntentDelta): # 切換話題時(shí)保留跨話題有效的全局約束重置 topic/task self.state.topic delta.value.get(topic, self.state.topic) self.state.task delta.value.get(task, ) # 預(yù)算等全局約束不清理 def _apply_rollback(self, delta: IntentDelta): target_version delta.snapshot_id or 0 if target_version len(self.snapshots): return target self.snapshots[target_version].state_copy self.state IntentState( topictarget.topic, tasktarget.task, constraintstarget.constraints.copy(), versionself.state.version, last_actionROLLBACK, )這段代碼的核心思想是所有狀態(tài)變更都通過(guò)IntentDelta描述所有變更前狀態(tài)都保存為快照。SWITCH只重置話題和任務(wù)不清理預(yù)算這類跨話題約束。ROLLBACK可以直接恢復(fù)到任意歷史版本。5.3 運(yùn)行驗(yàn)證用之前那段對(duì)話劇本驗(yàn)證manager IntentStateManager() manager.apply_delta(IntentDelta(ADD, value{device: 筆記本}), 我想買一臺(tái)筆記本) manager.apply_delta(IntentDelta(ADD, value{purpose: 剪輯4K視頻}), 剪輯4K視頻用) manager.apply_delta(IntentDelta(ADD, constraints, {budget: 8000以內(nèi)}), 預(yù)算8000以內(nèi)) # 用戶切換話題 manager.apply_delta( IntentDelta(SWITCH, value{topic: 臺(tái)式機(jī), task: 選購(gòu)設(shè)備}), 算了還是看看臺(tái)式機(jī), ) # 用戶回退到最初版本 manager.apply_delta( IntentDelta(ROLLBACK, snapshot_id0), 還是按最開始那個(gè)方案來(lái), ) print(當(dāng)前狀態(tài), manager.state)運(yùn)行后可以觀察到第一次 SWITCH 后topic變成“臺(tái)式機(jī)”但constraints[budget]仍然是“8000以內(nèi)”。ROLLBACK 到版本 0 后topic恢復(fù)為“筆記本”約束也恢復(fù)為當(dāng)時(shí)的狀態(tài)。這個(gè)模塊解決了最核心的“意圖演變可管理”問(wèn)題。真實(shí)項(xiàng)目中IntentDelta的生成可以交給 LLM讓模型輸出 JSON 形式的狀態(tài)變更指令再由IntentStateManager執(zhí)行而不是讓模型直接修改消息歷史。這樣既利用了 LLM 的語(yǔ)義理解能力又保證了狀態(tài)變更的確定性。6. 配置、調(diào)參與生產(chǎn)落地6.1 關(guān)鍵參數(shù)與調(diào)參建議下表列出意圖狀態(tài)管理模塊落地時(shí)最常調(diào)整的參數(shù)及其影響參數(shù)含義常見(jiàn)值調(diào)小影響調(diào)大影響意圖變化閾值判斷 SWITCH 的置信度閾值0.6 ~ 0.8容易誤判切換頻繁重置狀態(tài)容易漏掉真實(shí)切換沿用舊狀態(tài)快照保存條數(shù)保留多少個(gè)歷史版本5 ~ 20回退范圍變小內(nèi)存和存儲(chǔ)成本上升澄清觸發(fā)次數(shù)同一處歧義最多追問(wèn)幾次1 ~ 2用戶可能不耐煩可能忽略真實(shí)意圖變化狀態(tài)摘要觸發(fā)輪數(shù)多少輪后壓縮舊消息5 ~ 10過(guò)早壓縮丟失細(xì)節(jié)太晚壓縮導(dǎo)致上下文超限關(guān)鍵約束最大數(shù)最多維護(hù)多少條約束8 ~ 12重要約束可能被丟棄模型注意力被稀釋“變化檢測(cè)閾值”最值得關(guān)注。如果閾值太低用戶說(shuō)“我想再看看另一款”就會(huì)被識(shí)別成 SWITCH系統(tǒng)立刻重置狀態(tài)如果閾值太高就算用戶明確說(shuō)“換個(gè)方向”系統(tǒng)仍然沿用舊狀態(tài)。生產(chǎn)環(huán)境中建議先取 0.7再根據(jù)誤判率調(diào)。6.2 學(xué)習(xí)環(huán)境與生產(chǎn)環(huán)境的差異學(xué)習(xí)環(huán)境里一個(gè)messages數(shù)組加一個(gè) prompt 就能跑通對(duì)話。但進(jìn)入生產(chǎn)環(huán)境至少要補(bǔ)齊以下幾塊狀態(tài)存儲(chǔ)把IntentState持久化到 Redis 或數(shù)據(jù)庫(kù)中而不是只存在內(nèi)存里。否則服務(wù)重啟或負(fù)載均衡切換后用戶狀態(tài)直接丟失。操作審計(jì)每條IntentDelta都要記錄用戶 ID、會(huì)話 ID、來(lái)源消息、操作時(shí)間。方便排查“用戶為什么被推薦了一個(gè)錯(cuò)誤結(jié)果”。權(quán)限與隔離不同用戶、不同業(yè)務(wù)域的意圖狀態(tài)要隔離避免互相污染。監(jiān)控告警監(jiān)控狀態(tài)變更頻率。如果單個(gè)會(huì)話在短時(shí)間內(nèi)出現(xiàn)大量 SWITCH 或 ROLLBACK說(shuō)明用戶可能困惑或者檢測(cè)模塊在抖動(dòng)?；貪L方案新版本狀態(tài)管理邏輯上線后要能快速切回舊版本。狀態(tài)結(jié)構(gòu)變更時(shí)需要兼容舊數(shù)據(jù)。生產(chǎn)環(huán)境的另一個(gè)關(guān)鍵點(diǎn)是 API 延遲。如果每輪用戶輸入都要先做意圖分類、再壓縮上下文、再構(gòu)造 prompt最后調(diào)用 LLM整體延遲會(huì)明顯上升。建議把不必要的串行步驟改成異步或并行比如上下文壓縮可以放到后臺(tái)不阻塞主鏈路。6.3 三個(gè)最容易踩的坑坑一把補(bǔ)充信息當(dāng)成切換用戶說(shuō)“屏幕也要好一點(diǎn)”這通常是對(duì)筆記本需求的補(bǔ)充。但變化檢測(cè)模塊如果只看到“屏幕”和前面的“筆記本”不一致就可能判斷為 SWITCH導(dǎo)致系統(tǒng)重新問(wèn)“您是想買筆記本還是顯示器”。原因是沒(méi)有把更新語(yǔ)義區(qū)分開。補(bǔ)充信息屬于 ADD通常不會(huì)改變主話題。解決方式是在分類 prompt 里明確說(shuō)明只有出現(xiàn)“算了”“換個(gè)”“不看了”等切換信號(hào)或新輸入的核心名詞與當(dāng)前 topic 完全不同且意圖明確時(shí)才允許判定為 SWITCH?？佣顟B(tài)只維護(hù)不清理越積越多有些實(shí)現(xiàn)會(huì)把所有約束不斷追加導(dǎo)致狀態(tài)里的約束相互矛盾。用戶說(shuō)“預(yù)算 8000”后又“預(yù)算 10000”。如果用 ADD 方式追加狀態(tài)里同時(shí)存在兩條預(yù)算模型不知道該用哪條。這就是典型的“維護(hù)了狀態(tài)但沒(méi)維護(hù)更新語(yǔ)義”。正確做法是對(duì)單值約束使用 REPLACE對(duì)多值約束才使用 ADD。預(yù)算、人數(shù)、時(shí)間這類字段是單值的新值應(yīng)該覆蓋舊值標(biāo)簽、偏好、待辦清單這類字段是多值的可以追加。坑三快照只存了對(duì)象引用沒(méi)有深拷貝內(nèi)存態(tài)演示代碼里如果沒(méi)有深拷貝快照后續(xù)修改狀態(tài)會(huì)同時(shí)修改所有歷史快照導(dǎo)致 ROLLBACK 全部失效。上面示例中通過(guò)IntentState(...)顯式創(chuàng)建新對(duì)象就是為了避免這個(gè)問(wèn)題。生產(chǎn)環(huán)境使用對(duì)象序列化時(shí)要尤其注意不要把同一個(gè)引用塞進(jìn)快照。注意回滾功能是否可靠直接決定用戶說(shuō)“還是按原來(lái)的來(lái)”時(shí)系統(tǒng)表現(xiàn)如何。上線前必須用專門測(cè)試用例驗(yàn)證回滾后狀態(tài)完全恢復(fù)而不只是主話題恢復(fù)。7. 效果怎么評(píng)估怎么判斷系統(tǒng)不再迷失7.1 意圖演變?cè)u(píng)測(cè)集怎么建判斷“迷失”是否被緩解不能只看最終回答是否讓用戶滿意因?yàn)闈M意度受太多因素影響。更可靠的方式是建立一套面向意圖演變的評(píng)測(cè)集。每個(gè)測(cè)試用例包含四部分多輪對(duì)話劇本。劇本中每一步的真實(shí)意圖狀態(tài)。期望的狀態(tài)操作類型。關(guān)鍵約束最終是否保留。例如{ conversation: [ 我想買一臺(tái)剪輯4K視頻的筆記本, 預(yù)算8000以內(nèi), 算了還是看看臺(tái)式機(jī), 你推薦一個(gè)更適合我的處理器 ], expected_state: { topic: 臺(tái)式機(jī), purpose: 視頻剪輯/調(diào)色, budget: 8000以內(nèi) }, expected_operations: [ADD, ADD, SWITCH, ADD], key_constraints_kept: [purpose, budget] }評(píng)測(cè)時(shí)把對(duì)話逐條送入系統(tǒng)每一步后對(duì)比當(dāng)前實(shí)際狀態(tài)與期望狀態(tài)。統(tǒng)計(jì)三個(gè)指標(biāo)狀態(tài)一致率每一步狀態(tài)完全正確的比例。操作準(zhǔn)確率ADD、SWITCH、ROLLBACK 四種操作分類正確的比例。關(guān)鍵約束保留率最終狀態(tài)中仍保留核心約束的比例。這三個(gè)指標(biāo)比“回答正確率”更可控、更穩(wěn)定。即使模型生成結(jié)果換了種說(shuō)法只要狀態(tài)正確系統(tǒng)整體就是健康的。7.2 發(fā)布前檢查清單把意圖演變感知模塊上線前建議過(guò)一遍以下清單狀態(tài)管理模塊是否有完整的單元測(cè)試覆蓋 ADD、REPLACE、SWITCH、ROLLBACK 四種操作。是否有專門測(cè)試“用戶說(shuō)了算了后預(yù)算仍然保留”的用例?？煺帐欠裆羁截惢貪L后原狀態(tài)是否完全恢復(fù)。變化檢測(cè)閾值是否經(jīng)過(guò)一批真實(shí)歷史對(duì)話調(diào)優(yōu)。長(zhǎng)對(duì)話超過(guò)上下文窗口時(shí)壓縮策略是否優(yōu)先保留核心約束。狀態(tài)持久化是否具備服務(wù)重啟后能否恢復(fù)。是否記錄操作審計(jì)日志能否回答“用戶為什么被推薦這個(gè)結(jié)果”?；貪L上線方案是否存在狀態(tài)結(jié)構(gòu)變更是否兼容舊數(shù)據(jù)。是否監(jiān)控單會(huì)話內(nèi)高頻 SWITCH 和 ROLLBACK 異常。7.3 擴(kuò)展方向意圖演變管理不是一個(gè)一次性功能而是 LLM 應(yīng)用對(duì)話層的基礎(chǔ)設(shè)施。下一步可以沿著這些方向擴(kuò)展把IntentStateManager與多 Agent 編排結(jié)合每個(gè) Agent 都讀取同一份意圖狀態(tài)避免不同 Agent 對(duì)用戶需求理解不一致。加入基于用戶反饋的自動(dòng)修正。當(dāng)用戶對(duì)推薦結(jié)果表示不滿時(shí)自動(dòng)分析當(dāng)前狀態(tài)中哪個(gè)約束可能錯(cuò)了觸發(fā)澄清或回退。把支持 ROLLBACK 的意圖事件流與用戶畫像打通。長(zhǎng)期維護(hù)用戶在不同業(yè)務(wù)場(chǎng)景中的偏好演變曲線讓推薦更個(gè)性化。針對(duì)不同語(yǔ)言和業(yè)務(wù)領(lǐng)域做狀態(tài)字段的抽象。比如電商、醫(yī)療、教育、法律咨詢的約束字段完全不同但 ADD/REPLACE/SWITCH/ROLLBACK 這套操作語(yǔ)義是通用的?；氐阶铋_始的問(wèn)題LLM 為什么會(huì)在演變中的用戶意圖里迷失根本原因是模型只能從文本中隱式猜測(cè)狀態(tài)而工程上也沒(méi)給它維護(hù)狀態(tài)的機(jī)會(huì)。只要把“當(dāng)前用戶要什么”從消息歷史中顯式抽離出來(lái)用結(jié)構(gòu)化狀態(tài)加操作事件流管理每一步變化再通過(guò)評(píng)測(cè)集驗(yàn)證關(guān)鍵約束是否保留這個(gè)問(wèn)題就能被系統(tǒng)性地緩解。對(duì)開發(fā)者來(lái)說(shuō)最重要的轉(zhuǎn)變不是換更強(qiáng)的模型而是先承認(rèn)意圖管理是一種工程能力不能完全交給模型免費(fèi)獲得。