長上下文是如何失效的

yan
0 評論 1249 瀏覽 0 收藏 13 分鐘

長上下文能力曾被視為大模型的“質(zhì)變突破”,但它真的如我們想象中那樣有效嗎?本篇文章將從技術(shù)原理、產(chǎn)品實踐與用戶體驗三個維度,拆解長上下文的失效機制,揭示其在真實場景中的邊界與誤區(qū),并提出更具現(xiàn)實感的產(chǎn)品思考路徑。

隨著前沿模型的上下文窗口不斷擴大,長上下文支持多達100萬個標記,我看到許多令人興奮的討論,探討長上下文窗口將如何解鎖我們夢寐以求的智能體。畢竟,有了足夠大的窗口,你只需將所有可能需要的東西——工具、文檔、指令等等——都放入提示中,然后讓模型處理其余的事情。

長上下文激發(fā)了RAG的熱情(當你可以把所有內(nèi)容都放在提示符中時,不需要找到最好的文檔!),啟用了MCP炒作(連接到每個工具和模型都可以做任何工作?。?,并激發(fā)了對代理的熱情。

但實際上,更長的上下文并不一定能生成更好的響應(yīng)。上下文過載可能會導(dǎo)致你的智能體和應(yīng)用程序以意想不到的方式出現(xiàn)故障。上下文可能會被污染、分散注意力、造成混淆或產(chǎn)生沖突。這對依賴上下文來收集信息、綜合研究結(jié)果和協(xié)調(diào)行動的智能體來說尤其成問題。

讓我們梳理一下上下文可能失控的情況,然后回顧減輕或完全避免上下文失敗的方法。

上下文失敗的幾種可能:

  • 上下文中毒:當幻覺進入上下文時
  • 上下文干擾:當上下文淹沒訓(xùn)練時
  • 上下文混淆:當多余的上下文影響響應(yīng)時
  • 上下文沖突:當上下文的部分內(nèi)容不一致時

上下文中毒

上下文中毒是指幻覺或其他錯誤進入上下文,并在其中被反復(fù)引用的情況。

Deep Mind團隊在《Gemini 2.5技術(shù)報告》中指出了上下文中毒的問題,我們上周已經(jīng)對此進行了剖析。在玩《寶可夢》時,Gemini智能體偶爾會在游戲過程中產(chǎn)生幻覺,從而污染其上下文:

這種問題的一種特別嚴重的形式可能會在“上下文中毒”中出現(xiàn)——即上下文中的許多部分(目標、摘要)被有關(guān)游戲狀態(tài)的虛假信息“污染”,而消除這些虛假信息往往需要很長時間。結(jié)果,模型可能會執(zhí)著于實現(xiàn)不可能或不相關(guān)的目標。

如果其上下文的“目標”部分被污染,智能體就會制定出毫無意義的策略,并重復(fù)行為以追求一個無法實現(xiàn)的目標。

上下文干擾

上下文干擾是指當上下文變得過長時,模型會過度關(guān)注上下文,而忽略了它在訓(xùn)練過程中所學(xué)的內(nèi)容。

在自主工作流程中,隨著上下文的不斷增加(即模型收集更多信息并積累歷史),這種積累的上下文可能會變得分散注意力,而不是有所幫助。玩寶可夢的雙子座智能體清楚地展示了這個問題:

雖然Gemini 2.5 Pro支持100萬個以上的token上下文,但如何讓智能體有效利用這一特性,是一個新的研究前沿。在這個智能體設(shè)置中,觀察發(fā)現(xiàn),當上下文顯著超過10萬個token時,智能體傾向于從其龐大的歷史記錄中重復(fù)行動,而不是生成新的計劃。這一現(xiàn)象雖然只是個例,但凸顯了用于檢索的長上下文和用于多步驟生成推理的長上下文之間的重要區(qū)別。

該智能體沒有利用其訓(xùn)練來制定新策略,而是執(zhí)著于重復(fù)其廣泛上下文歷史中的過往行動。

對于較小的模型,分心上限要低得多。Databricks的一項研究發(fā)現(xiàn),Llama 3.1 405b的模型正確性在約32k時開始下降,而較小模型的下降時間更早。

如果模型在上下文窗口填滿之前很久就開始表現(xiàn)失常,那么超大上下文窗口的意義何在?簡而言之:總結(jié)長上下文為何失敗事實檢索。如果你不做這兩件事,就要警惕所選模型的分心上限。

上下文混淆

上下文混淆是指模型使用上下文中多余的內(nèi)容來生成低質(zhì)量的響應(yīng)。

有那么一會兒,感覺真的就像每個人都要推出一個多模態(tài)計算平臺(MCP)。一個強大的模型,連接到所有你的服務(wù)和各種東西,完成所有瑣碎任務(wù)的夢想似乎觸手可及。只需把所有工具描述都放進提示詞里,然后點擊執(zhí)行??藙诘拢–laude)的系統(tǒng)提示詞為我們指明了方向,因為它主要是工具定義或使用工具的說明。

但即便整合與競爭不會減緩MCP的發(fā)展,上下文混淆也會。事實證明,工具太多也會有問題。

《伯克利函數(shù)調(diào)用排行榜》是一個工具使用基準,評估模型有效使用工具響應(yīng)提示的能力?,F(xiàn)在已經(jīng)是第三個版本了,排行榜顯示,當提供多個工具時,每個模型的表現(xiàn)都更差長上下文是如何失敗的此外,伯克利團隊“設(shè)計了提供的函數(shù)都不相關(guān)的場景……我們期望模型的輸出是沒有函數(shù)調(diào)用的。”然而,所有模型偶爾都會調(diào)用不相關(guān)的工具。

瀏覽函數(shù)調(diào)用排行榜時,你會發(fā)現(xiàn)隨著模型變小,問題變得更嚴重:

上下文混淆的一個顯著例子可見于最近的一篇論文,該論文評估了小模型在GeoEngine基準測試中的性能,這是一項包含46種不同工具的試驗。當團隊向量化(壓縮)的Llama 3.1 8b模型提供包含所有46種工具的查詢時,它失敗了,盡管上下文完全在16k的上下文窗口內(nèi)。但當他們只給模型19種工具時,它成功了。

問題在于:如果你把某些內(nèi)容置于上下文中,模型就必須關(guān)注它。這可能是無關(guān)信息或不必要的工具定義,但模型會將其考慮在內(nèi)。大型模型,尤其是推理模型,在忽略或舍棄多余上下文方面越來越出色,但我們?nèi)圆粩嗫吹綗o用信息讓智能體犯錯。更長的上下文讓我們能塞進更多信息,但這種能力也有弊端。

上下文沖突

上下文沖突是指在你的上下文中積累了與上下文中其他信息相沖突的新信息和工具。

這是_上下文混淆_的一個更具問題的版本:這里的錯誤上下文并非無關(guān)緊要,而是直接與提示中的其他信息相沖突。

微軟和Salesforce的一個團隊在最近的一篇論文中出色地記錄了這一點。該團隊從多個基準測試中提取提示,并將信息 “分片” 到多個提示中。可以這樣理解:有時,你可能會坐下來,在按下回車鍵之前,先在ChatGPT或Claude中輸入段落,仔細考慮每一個必要的細節(jié)。其他時候,你可能先輸入一個簡單的提示,然后在聊天機器人的回答不令人滿意時再添加更多細節(jié)。微軟/Salesforce團隊對基準測試提示進行了修改,使其看起來像這些多步驟的交流:

左側(cè)提示中的所有信息都包含在右側(cè)的多條消息中,這些消息將在多輪聊天中依次呈現(xiàn)。

分片提示產(chǎn)生的結(jié)果明顯更差,平均下降了39%。該團隊測試了一系列模型——OpenAI備受贊譽的o3的得分從98.1降至64.1。

發(fā)生了什么?為什么分階段收集信息時模型的表現(xiàn)比一次性收集時更差?

答案是“上下文混淆”:包含整個聊天交流內(nèi)容的組合上下文,包含了模型在“尚未掌握所有信息”時對挑戰(zhàn)的早期回答嘗試。這些錯誤答案仍然存在于上下文中,并在模型生成最終答案時對其產(chǎn)生影響。團隊寫道:

我們發(fā)現(xiàn),大語言模型(LLMs)常常在對話早期就做出假設(shè),并過早地嘗試生成最終解決方案,且過度依賴這些方案。簡單來說,我們發(fā)現(xiàn)當大語言模型在對話中走錯方向時,它們就會迷失方向,無法恢復(fù)。

這對智能體構(gòu)建者來說可不是個好兆頭。智能體從文檔、工具調(diào)用以及處理子問題的其他模型中收集上下文。所有這些從不同來源收集的上下文,都有可能相互矛盾。此外,當你連接到非自己創(chuàng)建的MCP工具時,這些工具的描述和說明與你其他提示內(nèi)容發(fā)生沖突的可能性更大。

百萬令牌上下文窗口的出現(xiàn),感覺具有變革性。將智能體可能需要的一切都納入提示的能力,激發(fā)了人們對超級智能助手的想象,這些助手可以訪問任何文檔、連接到所有工具,并保持完美的記憶。

但正如我們所看到的,更大的上下文會產(chǎn)生新的失敗模式。上下文污染會嵌入隨著時間推移而累積的錯誤。上下文干擾會導(dǎo)致智能體過度依賴其上下文,重復(fù)過去的行動而不是向前推進。上下文混淆會導(dǎo)致使用不相關(guān)的工具或文檔。上下文沖突會造成內(nèi)部矛盾,從而破壞推理過程。

這些失敗對智能體的影響最為嚴重,因為智能體恰恰是在上下文急劇膨脹的場景中運行的:從多個來源收集信息、進行順序性的工具調(diào)用、參與多輪推理,以及積累大量的歷史記錄。

幸運的是,有解決辦法!在即將發(fā)布的文章中,我們將介紹減輕或避免這些問題的技術(shù),從動態(tài)加載工具的方法到啟動上下文隔離區(qū)。

閱讀后續(xù)文章“如何修復(fù)你的上下文”

文章來源:https://www.dbreunig.com/2025/06/22/how-contexts-fail-and-how-to-fix-them.html#fnref:live

本文由 @yan 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)作者許可,禁止轉(zhuǎn)載

題圖來自Unsplash,基于CC0協(xié)議

該文觀點僅代表作者本人,人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務(wù)

更多精彩內(nèi)容,請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發(fā)揮!