單輪問答相對簡單：使用者提出問題，人工智慧返回答案。多輪對話則困難得多——使用者會提出引用前文結果的追問，比如“那按華東區再細分呢”“把它改成環比”，系統必須跨輪次保持上下文，才能給出連續、一致的分析。這正是有用的商業智慧（BI）助手與華麗搜尋引擎之間的分水嶺。
什麼是上下文窗口問題？
大語言模型有固定的上下文視窗，即單次能夠處理的最大文本量。在多輪對話中，每一輪的提問、回答與圖表說明都會佔用視窗空間，輪次一多，早期資訊就會被逐漸擠出。實踐中，5至10輪之後模型就開始“忘記”最初的查詢條件，出現答非所問或口徑漂移，使用者不得不反覆重述需求。
把完整歷史全部塞進視窗並不現實，成本與延遲都會隨輪次線性增長，企業級場景尤其承受不起。更合理的方案是在模型之外維護結構化的對話狀態——誰問了什麼、基於哪個資料集、應用了哪些篩選條件——並在每一輪只注入與當前問題相關的上下文片段。上下文管理的關鍵不再是“記住多少”，而是“挑對多少”。
AI如何解析代詞與省略指代？
使用者說“現在按月度顯示”，人工智慧必須把“現在”解析為上一輪討論的主題，例如“按地區劃分的收入”。這類指代消解要求系統維護一張對話實體圖：本輪已經提到哪些指標、維度與過濾條件，哪些仍然處於啟用狀態，哪些已經被使用者主動放棄。
參考解析的難點在於歧義。當使用者上一輪同時討論過“華東區收入”與“華北區銷量”時，“改成趨勢圖”究竟指哪一個？優秀的系統會結合最近提及、當前焦點與使用者的明確用詞綜合判斷，並在不確定時主動向用戶確認，而不是默默猜測導致口徑錯誤——一次靜默的錯誤換算，可能讓使用者對整個系統的信任歸零。
上下文窗口應該如何管理？
成熟的上下文管理通常遵循三步策略。第一步，把每一輪的查詢、結果與後設資料寫入對話狀態物件；第二步，在開啟新一輪之前，把歷史壓縮成一份緊湊的上下文摘要，只保留關鍵指標、維度與結論；第三步，將摘要、當前問題以及被引用的具體實體一起送入模型，讓模型把精力集中在真正相關的內容上。
這一策略的核心收益是可擴充套件性：無論對話進行到第幾輪，送入模型的文本量都保持近似恆定，回答延遲與成本不會隨輪次失控。對於企業級的BI場景，這還意味著每一次回答都可以回溯到確定的資料口徑，為審計與合規留下清晰痕跡，也讓使用者能夠放心地展開長程探索式分析。
摘要的生成質量直接決定多輪體驗的成敗。一份好的摘要應當回答四個問題：使用者在分析什麼主題、已經確認了哪些口徑、得到了什麼結論、還有哪些待辦追問。把摘要做得太短會丟失關鍵資訊，做得太長又擠佔上下文視窗，成熟系統通常會用結構化欄位（主題、指標、維度、篩選條件、結論）而不是自由文本儲存狀態，既便於機器檢索，也便於隨時向用戶確認。
好的多輪對話體驗應該如何衡量？
衡量標準不應只看單輪迴答正確率。真正有用的指標包括：指代消解成功率——使用者使用“它”“那個”“上面”等詞時系統是否正確理解；上下文延續率——追問後結果是否保持同一資料口徑；以及任務完成率——使用者能否在不重新描述全部條件的情況下得到最終答案。
行業實踐中，把指代消解成功率提升20個百分點，通常能讓使用者的平均會話輪數從3輪左右提高到8輪以上，而每輪追問節省的時間可達數分鐘。更重要的是，多輪能力直接決定業務使用者能否獨立完成探索式分析——這正是對話式BI替代傳統報表的價值所在，也是蜂啟諮詢在評估BI助手時最看重的維度。
測試方法上，企業可以用一組標準化的多輪場景做基準測試：例如連續追問五個問題、中途切換主題再切回、使用口語化指代等，觀察系統的口徑保持能力與響應質量。這類測試應當由業務使用者參與設計，因為只有他們才清楚哪些追問真正發生在日常工作中，測試場景貼近真實，結論纔有參考價值。
什麼時候該重置上下文？
並非所有輪次都屬於同一分析執行緒。當使用者從“收入分析”切換到“人員編制趨勢”時，人工智慧應當檢測到主題轉移，重置當前的分析上下文，避免把舊指標帶入新問題；同時保留完整的會話歷史，讓使用者隨時可以回到上一個主題繼續追問，而不必從頭再來。
好的系統還會區分“軟切換”與“硬切換”：軟切換時保留常用的篩選條件，例如組織範圍與時間範圍；硬切換則清空全部口徑。明確這兩類切換規則，可以在靈活性與準確性之間取得平衡，也避免使用者在不同主題間來回切換時反覆輸入相同條件，把寶貴的時間浪費在重複描述上。
此外，企業還應該為對話狀態設定合理的保留策略：短期會話資料在對話結束後即可歸檔，涉及敏感業務資料的會話則按合規要求留存並做脫敏處理。上下文管理不只是技術問題，也是資料治理問題，二者在設計之初就應統一考慮，避免系統上線後再回頭補合規的課。
本文的核心要點是什麼？
- 在模型之外維護結構化對話狀態，而非依賴上下文視窗硬記。
- 用緊湊摘要代替完整歷史，控制成本與延遲。
- 用對話實體圖解決指代消解，必要時主動向用戶確認。
- 檢測主題轉移，區分軟切換與硬切換。
設計多輪對話的下一步是什麼？
多輪對話能力決定了一款BI工具究竟是被動應答的查詢器，還是能夠陪伴業務使用者完成完整分析旅程的智慧助手。上下文視窗管理、指代消解與主題切換並非錦上添花，而是對話式分析可用性的地基，任何一環節缺失，都會讓體驗停留在“能用”而非“好用”。
對準備引入對話式BI的企業，建議在選型時用真實的五輪以上業務追問進行壓力測試，觀察系統在口徑一致性與響應質量上的表現。蜂啟諮詢可以幫助企業搭建這類評估場景，並基於語義層把多輪上下文管理與企業指標口徑統一起來，讓每一次追問都建立在可信的資料基礎之上。
對話狀態應該如何建模？
把記憶外部化是正確的方向，但臨時拼湊的狀態物件往往不斷新增欄位，最後沒人確定哪一個纔是權威來源。更乾淨的做法，是把對話狀態視為一個小而帶型別的結構，包含四個槽位，每個槽位在新的一輪到來時都有明確的優先順序規則。
- 主題——當前討論的指標或度量：營收、毛利、員工人數、出貨量。新的一輪若明確說出指標就替換主題；若沒有，則維持不變。
- 維度與篩選條件——地區、渠道、產品、時間區間，以及任何明確的限制。這是狀態中最常被修改的部分，也正是「按月」或「只要上海」實際改變的內容。
- 操作——比較、排序、趨勢、分解或閾值檢查。這是多數狀態模型遺漏的部分；正因缺少它，能處理好「跟去年同期比」的助理，卻會在「哪些地區表現最差？」上失敗。
- 結果指標——指向先前結果集的引用，使「在這些當中，哪些成長最快？」無需重跑原始查詢即可求解。
優先順序規則比結構更重要。當使用者說「現在按渠道拆分，但只看前三大地區」，三個槽位同時改變，一個維持不變。以定義好的順序逐槽求解的系統——先篩選條件、再維度、最後主題——行為可預測；而每次都從最新一句重新推導整個狀態的系統，則會出現使用者所說「助理斷線了」的反覆無常行為。
實務上多輪對話會在哪些地方出問題？
除了上下文窗口耗盡之外， 生產環境的部署中有四類問題反覆出現，每一類都有對應的解法。
數字指涉的歧義。「那去年呢？」可能指去年同期、上一個完整年度，或在當前粒度下做年增比較。與其猜測，更好的做法是解析最可能的解讀，在答案中明確說明（「去年同期，一月到三月」），並提供其他選項。說明解讀只需一句話，卻能消除大部分靜默的誤解。
下鑽鏈超過schema範圍。使用者依序要求按地區、城市、門市、產品拆分，而第四層在該粒度下並不存在。正確的回應不是報錯，也不是幻化出一張圖表，而是優雅地說明邊界：目前可用的最細粒度是什麼，以及是否願意用近似方式呈現。妥善處理schema的邊界，是讓助理顯得專業的重要部分。
單一對話中的主題漂移。一段關於毛利的對話滑向員工人數，之後又繞回來。因此主題偵測應是軟性而非二元的：維護一個分析上下文堆疊而非單一上下文，回到先前主題時就能恢復其狀態，而不是重新開始。
跨輪次的權限洩漏。隨著對話狀態累積篩選條件與實體，它可能同時累積了使用者不應看到的數據訪問權——某個在一個上下文中合法的篩選條件，會暴露出在另一個上下文中不被允許的聚合結果。每一個求解出的查詢，都必須針對完整累積的狀態重新授權，而不是隻針對最新一輪。
如何測試多輪對話助理？
單輪評估會漏掉大部分出問題的地方。測試單位必須是「對話」而非「問題」，實用的做法是建立腳本化的對話測試集：二十到五十段多輪對話腳本，涵蓋使用者實際會產生的模式——細化、下鑽、比較、切換主題、返回、修正——每段都帶有已知正確的最終狀態與預期答案。
執行這套測試集可以得到三項指標。狀態準確率：在第N輪之後，求解出的查詢規格是否與預期一致？深度上的答案準確率：分別在第一輪、第五輪、第十五輪衡量準確率，因為這套架構的重點正是準確率不應隨深度下降——若下降，說明外部化狀態沒有發揮作用。恢復率：當使用者修正助理時（「不，我是指按季」），下一輪能做對的比例有多高？
再補一個成本低但診斷價值高的生產訊號：使用者放棄當前對話並另開新對話的比例。在第三、四輪之後出現高放棄率，是上下文處理失敗最清晰的指標，而且無需任何標註就能在日誌中看見。
多輪BI中是什麼破壞了上下文，又該如何修復？
多輪分析會在系統遺忘已說內容時失敗。常見的罪魁是 Treating 每個問題為孤立請求的無狀態處理；是"上季度"在各輪中含義不同的隱性假設變更；也是因前一輪被丟棄而失去錨點的丟失引用——比如"把它和北美區域對比"無處著落。用戶的感受是不得不重複自己，或者更糟，收到一個對錯誤問題的自信回答。
修復之道是把上下文當作一等公民的狀態來管理。維護一個顯式的會話對象，記錄前幾輪已解析的實體、過濾器、時間範圍和指標定義，並將其帶入每一個新查詢，使後續追問建立在既定基礎之上。當引用含糊時，依據該狀態來解析而非猜測，並在確實不清時向用戶確認。對長會話定期摘要為緊湊的上下文快照，使模型不會隨對話變長而丟失主線。當狀態被刻意對待，一場十輪的探查就會像與一位全程在場的分析師協作一般。
