一位開發者對構建「上下文引擎」的詳細分析突顯了生產環境RAG團隊一直在悄悄解決的問題：檢索有效，但管理真正進入LLM上下文視窗的內容無效。該系統用純Python實作，具有可測量的基準，明確控制記憶體、壓縮、重排序和token預算——解決了原始檢索和提示構建之間的差距，這正是大多數RAG實作失敗的地方。

這直接對應了我在4月份報導的Karpathy放棄RAG轉向LLM原生知識管理時所涉及的內容。根本問題不是檢索精度——而是架構問題。RAG教學止步於「檢索文件，塞進提示」，但生產系統需要對資訊流做出深思熟慮的決策。當檢索的上下文有6000個字元但你的預算只有1800個token，當近似重複的文件排擠掉有用的文件，當第一輪對話歷史在二十輪後仍佔據空間——這就是基礎RAG失效的地方。

更廣泛的社群正從不同角度聚焦於這個相同問題。擁有27000星標的RAG Techniques儲存庫強調五層架構，按順序處理失效模式。其他開發者正在實作混合BM25+向量搜尋配合交叉編碼器重排序，或完全放棄RAG轉向LLM維護的markdown知識庫。連接這些方法的是對上下文組成的明確控制，而不是寄希望於檢索+提示在規模化時能奇蹟般地工作。

對於運行多輪聊天機器人或擁有大型知識庫的RAG系統的團隊來說，這不是理論問題。上下文管理在最初幾輪對話內就成為瓶頸。選擇是有意識地構建這一層，或者眼看著系統隨著上下文累積而退化——這解釋了為什麼生產團隊正在投入工程時間解決理論上應該透過更好的提示來解決的問題。