為什麼您的編碼代理不再需要 Rag 來自 Cline 的 Nik Pash 解釋了為什麼他不再推薦 RAG 用於自主編碼代理，他的觀點比我預期的要強烈。 應用層正在縮小。隨著模型的改進，我們圍繞 LLM 構建的所有巧妙工程都不斷過時。 RAG 發生了什麼： 上下文視窗大幅擴展，無需嵌入搜尋 編碼代理在直接檔案存取方面比區塊內嵌效果更好 當您將溫度設置為 0 時，幻覺甚至不是問題 內嵌儲存體的安全問題很重要 像 Klein 這樣的現代編碼代理不是 RAG，而是使用 Nik 所說的“敘事完整性”。讓代理透過 grep 等工具有機地探索程式碼，完整讀取文件，並遵循自己的思路。這模仿了高級工程師的實際工作方式。 就連 Cloud Code 的 Boris 也承認他們嘗試過 RAG 並放棄了它。模式很清楚。 當 RAG 仍然有意義時： 預算限制 （內嵌搜尋使用較少的權杖） 海量非結構化資料湖 一些非編碼用例 但對於嚴肅的工程團隊來說呢？停止使用嵌入搜索分散您的編碼代理的注意力。讓他們直接閱讀程式碼，自然地建立理解，並專注地執行。 真正的問題不在於 Rag 是否已經消亡，而是當更簡單的方法現在效果更好時，您是否仍然堅持過時的解決方案。