單輪問答相對簡單：用戶提出問題，人工智慧回答。多輪對話更加困難：用戶詢問引用先前答案的後續內容，而人工智慧必須保持跨輪對話的上下文。這就是有用的 BI 助手與華麗的搜尋引擎的區別。
上下文視窗問題
大型語言模型有一個上下文視窗——它們可以一次處理的文字量。在多輪對話中，先前的每個輪次都會消耗此視窗的一部分。 5-10 輪後，模型開始「忘記」之前的上下文。解決方案：在模型外部維護結構化對話狀態，並為每個新回合僅注入相關上下文。
參考解析度
當用戶說「現在按月顯示」時，人工智慧必須將「that」解析為先前查詢的主題（例如「按地區劃分的收入」）。這需要追蹤對話的實體圖：已經討論了哪些指標、維度和篩選器，以及哪些在當前回合中處於活動狀態。
上下文視窗管理策略
有效的上下文管理：（1）將每輪對話的查詢、結果和元數據存儲在對話狀態對象中。（2）對於每一輪新對話，生成簡潔的上下文摘要——而非完整歷史記錄。（3）在相關時保留關鍵實體引用，以便後續問題可以引用之前的結果而無需重新計算。（4）實施滑動窗口策略，保留最近的N輪對話的完整上下文，同時為較早的對話維護壓縮摘要。這種方法在保持對話連貫性的同時，限制了token使用量和延遲。
何時重置上下文
並非所有轉彎都屬於同一分析線程。如果用戶從“收入分析”切換到“人數趨勢”，人工智慧應該會偵測主題轉移並重置分析上下文，同時在用戶返回到上一個主題時保持對話歷史記錄可用。
重點
- 上下文視窗問題
- 參考解析度
- 上下文視窗管理策略
- 何時重置上下文
結論
並非所有轉彎都屬於同一分析線程。如果用戶從“收入分析”切換到“人數趨勢”，人工智慧應該檢測主題轉移並重置分析上下文——同時保持…
在 蜂啟諮詢，我們幫助企業建立資料基礎、語意層和人工智慧代理生態系統，將資料轉化為決策。我們的 MCP 支援平台可連接 50 多個數據來源，在 2 週內完成部署，並直接在您的團隊已使用的 IM 工具中提供見解。 預約免費演示 了解我們如何幫助您的組織。