我至今還記得 RAG（檢索增強生成）這個詞剛火起來時的情景。那感覺，就像是哥倫布發現了新大陸。一夜之間，所有人都成了 RAG 的信徒。它簡單、直接，承諾了一個美好的未來：只要把你的私有數據“喂”給大模型，它就能無所不知、無所不曉。AI 應用開發的門檻，仿佛瞬間被夷為平地。

那時候，大家都在談論 RAG，會議室里、技術論壇上，到處都是它的身影。它像一個萬能公式，簡單到只需要兩個步驟：檢索（Retrieval），然后生成（Generation）。聽起來無懈可擊。我們都沉浸在這種“靈丹妙藥”式的興奮中，以為抓住了通往 AGI 的捷徑。初創公司們拿著 RAG 的故事，輕松就能拿到融資；開發者們用著 LangChain 或者 LlamaIndex，幾行代碼就能搭出一個看起來很酷的 Demo。

那是一個充滿希望的“淘金熱”時代，而 RAG，就是我們手里最時髦的鐵鍬。

但正如所有被過度神化的概念一樣，當我們真正拿著這把鐵鍬深入挖掘時，才發現事情遠沒有那么簡單。Chroma 的創始人 Jeff Huber 在那次 Latent Space 的采訪中，用了一個詞來形容 RAG——“糟糕”（awful）。這個詞像一盆冷水，澆醒了許多沉浸在狂熱中的人，也包括我。

他說，RAG 是個糟糕的抽象，因為它把檢索、生成、結合這三個完全不同的概念硬生生地捆綁在一起，結果讓所有人都感到困惑。更糟糕的是，市場把 RAG 簡化成了一個極其膚淺的操作：“用 Embedding 做一次向量搜索”。

這番話讓我醍醐灌頂。我們確實被這個時髦的縮寫綁架了。我們開始忽略構建一個真正可靠系統背后那些最關鍵、最困難的問題。Jeff 形容當時的狀態像是在玩“煉金術”。他描繪了一個生動的畫面：一個人站在一堆冒著熱氣的垃圾前，當被問及這是否就是他的數據系統時，他回答“是”。再問他怎么知道這系統好不好，怎么讓它更好？他只會說，“你就隨便攪一攪，然后看看會不會變好。”

這不就是我們當時很多人的真實寫照嗎？我們把所有的文檔切塊、做 Embedding，然后一股腦地扔進向量數據庫。當用戶提問時，我們進行一次相似度搜索，把最靠前的幾個片段塞給大模型，然后祈禱它能給出一個靠譜的答案。當效果不好時，我們就開始“玄學調參”：調整 chunk size，換個 Embedding 模型，或者修改一下 Prompt。我們確實在“隨便攪一攪”，期待奇跡發生。

我們忽略了，從一個看起來能跑的 Demo 到一個真正穩健的生產級應用之間，橫亙著一條巨大的鴻溝。而 RAG 這個過于簡化的概念，恰恰掩蓋了這條鴻溝的深度和寬度。

就在我們對 RAG 的“煉金術”感到迷茫時，Jeff 提出了一個更精確、也更具工程思維的詞：上下文工程（Context Engineering）。

這個詞瞬間擊中了我。它不再是一個含糊的打包方案，而是一門嚴謹的學科。Jeff 給它的定義清晰而深刻：“上下文工程的任務，就是在每一步生成時，決定上下文窗口里應該放什么。”

這才是問題的核心。大語言模型就像一個記憶力超群但注意力有限的天才，它能處理的信息量是驚人的，但你不能把全世界的圖書館都塞到它面前，指望它瞬間找到你想要的那句話。你必須像一個圖書管理員一樣，精準地把最相關的那幾本書、那幾頁紙遞給它。這個“遞書”的過程，就是上下文工程。

Jeff 進一步把它拆解為兩個循環：

?內循環：在單次生成中，如何從海量信息中，精準地挑選出最關鍵的內容放進當前的上下文窗口。

?外循環：隨著時間的推移和與用戶的交互，系統如何學習，如何變得越來越擅長挑選信息，從而不斷優化內循環的效果。

這個概念的提出，標志著我們開始從一種“黑箱思維”轉向一種“白箱思維”。我們不再把希望寄托于“攪一攪”，而是開始像真正的工程師一樣，去設計、度量和優化那個至關重要的“上下文”。

我立刻想起了那些業界頂尖的 AI 應用，無論是 Perplexity AI 的精準回答，還是 Cursor 的智能代碼補全。它們之所以體驗出色，本質上不就是因為它們在上下文工程上做到了極致嗎？它們總能在最恰當的時機，把最準確的信息——無論是網絡搜索結果、代碼庫片段，還是歷史對話——喂給模型。

這才是它們真正的護城河。Jeff 一針見血地指出：“現在所有你能想到的，做得比較好的 AI 初創公司，他們真正擅長、最核心的一件事就是上下文工程。”

要理解上下文工程為什么如此重要，就必須先理解一個殘酷的現實：上下文腐爛（Context Rot）。

在很長一段時間里，各大模型廠商都在宣傳它們超長的上下文窗口，從幾千個 Token 一路卷到上百萬，甚至上千萬。它們發布的那些“大海撈針”測試圖表，幾乎都是一條完美的直線，仿佛在告訴我們：別擔心，把所有東西都扔進來吧，我的模型能搞定一切。

但現實是，這是一個美麗的謊言。Chroma 發布的那份關于 Context 的技術報告，無情地揭示了真相：隨著上下文窗口中 Token 數量的增加，LLM 的性能會顯著下降。模型會變得“注意力不集中”，推理能力會變弱，甚至會直接忽略掉你明確給出的指令。

這就好比在一個嘈雜的派對上，你試圖和一個朋友進行深度對話。當周圍只有三五個人時，你們交流順暢；但當房間里擠滿了一百個人，每個人都在大聲說話時，即使你的朋友聽力再好，也很難捕捉到你話語里的所有細節和深意。

“上下文腐含”就是大模型的“派對噪音問題”。當上下文窗口被無關或低相關度的信息填滿時，那些真正關鍵的“信號”就被淹沒在了“噪音”之中。模型的性能不是線性提升，反而在某個臨界點之后開始腐爛。

這也就解釋了，為什么簡單粗暴地把所有東西都塞進上下文窗口的做法，往往效果很差。這不僅是成本和效率的問題，更是質量的問題。緩存（Caching）可以解決一部分效率問題，但它無法解決上下文腐爛帶來的質量下降。

因此，上下文工程的核心挑戰，變成了一個經典的優化問題：如果你有一萬個候選信息片段，但上下文窗口里只有二十個空位，你如何能確保放進去的是最精華、最相關的那二十個？

那么，這門新興的“手藝”具體是怎么做的呢？它不是單一的技術，而是一個工具箱，一種組合拳。

Jeff 在訪談中提到了一個非常普遍且有效的模式：多階段檢索（Multi-stage Retrieval）。

這就像我們自己找資料的過程。比如，我想寫一篇關于“文藝復興時期佛羅倫薩的藝術”的文章。我不會直接去讀完整個圖書館的所有書。

第一步，我會進行粗篩。我會先用一些快速的方法，把候選范圍縮小。我可能會用圖書館的檢索系統，搜索“文藝復興”、“佛羅倫薩”、“藝術”這幾個關鍵詞（類似全文搜索）；或者，我也會找找那些帶有“藝術史”標簽的書架（類似元數據過濾）；我還可能憑感覺，找那些看起來最相關的書籍（類似向量搜索的語義相似度匹配）。通過這一步，我可能從幾萬本書里，圈定了三百本候選書。

第二步，我會進行精排。現在，我需要在這三百本書里，找出最核心的二三十本。我會快速翻閱這三百本書的目錄、前言和索引，判斷它們和我主題的真正相關性。這個過程，就像是讓一個更強大的“模型”（我自己的大腦）對候選集進行重新打分和排序（Re-ranking）。

AI 應用中的上下文工程，也是同樣的道理。第一階段，用向量搜索、全文搜索、元數據過濾等高效的手段，從海量數據中快速召回幾百個候選片段。第二階段，再調用一個大模型（甚至可以是專門的 re-rank 小模型），對這幾百個候選片段進行更精細的打分和排序，最終選出最精華的部分，喂給負責最終生成的那個核心模型。

我看到很多頂尖團隊都在實踐這種思想。他們甚至會用 Prompt 來讓大模型本身充當一個出色的“重排器”。Jeff 預測，隨著大模型變得越來越便宜，這種“暴力美學”式的重排會成為主流。專門的 re-rank 模型或許不會消失，但會像 ASIC 或 FPGA 一樣，只在那些對成本和性能要求極致的場景下才會使用。

更重要的是，上下文工程的工具箱里，不只有這些時髦的新工具。Jeff 提到，像**正則表達式（Regex）**這種“老古董”，在代碼搜索這類特定場景下依然極其有效。谷歌和 GitHub 的代碼搜索，主力就是正則。

這給了我很大的啟發：真正的工程思維，不是盲目追新，而是深刻理解每一種工具的邊界和適用場景，然后像一個匠人一樣，把它們巧妙地組合在一起，去解決實際問題。Embedding 擅長處理語義的模糊性，而正則則能提供無與倫比的精確性。它們不是替代關系，而是互補關系。

這次訪談最讓我著迷的，是 Jeff 對未來的思考。他認為，我們今天的做法，在五到十年后回頭看，可能會顯得“非常粗糙，甚至有點好笑”。

他暢想了未來檢索系統的幾個可能性：

第一，停留在潛在空間（Latent Space）。現在我們把文本轉成向量（Embedding），檢索完之后，再把結果轉回文本給大模型。這個“來回翻譯”的過程，既損耗信息又效率低下。為什么不能讓模型直接在那個充滿豐富語義的向量空間里工作呢？這就像我們不需要把腦海中的想法一字一句說出來再給自己聽一遍，才能進行下一步思考一樣。

第二，持續檢索（Continuous Retrieval）。今天的模式是“一次檢索，一次生成”。我們先搜集好所有資料，然后一口氣寫完文章。但更自然的方式，難道不應該是“邊寫邊查”嗎？當模型生成到某個節點，發現信息不足時，它應該能主動地、實時地去檢索新的信息來補充上下文。最近已經有一些相關的研究，比如教模型在內部推理時自己決定何時去檢索。這讓模型從一個被動的“信息消費者”，變成一個主動的“信息探索者”。

這些想法讓我意識到，我們目前對大模型的利用方式，還處在非常初級的階段。我們把它當成一個黑箱，從外部給它喂數據。而未來的方向，一定是把檢索、記憶這些能力，更深度地內化到模型自身的結構和工作流中去。

這也引出了他對“記憶”的看法。Jeff 認為，“記憶”這個詞很好，因為它通俗易懂，但它的本質，依然是上下文工程。所謂的長期記憶、短期記憶，最終都要落實到“在恰當的時機，把合適的信息放入上下文窗口”這個問題上。我們不必被各種花哨的記憶類型、信息圖譜所迷惑。

他提到了一個更樸素也更有力的概念：壓縮（Compression）。這就像我們電腦的磁盤碎片整理，或者數據庫的索引重建。系統可以在后臺，通過離線的計算和推理，不斷地對已有的信息進行整理、合并、提煉、總結，從而讓未來的檢索更高效、更精準。這聽起來沒有“人工夢境”或者“睡眠周期”那么性感，但它是一個真正經過時間檢驗的、來自計算機科學的工程智慧。

訪談的最后，話題從技術轉向了創業哲學和個人信仰。這部分內容，讓我對 Jeff 和 Chroma 這家公司有了更深的理解。

他說，創業有兩種流派。一種是精益創業，不斷追逐用戶的反饋，哪里有需求就去哪里。但這種方式的風險是，你最終可能會做出一款“給初中生用的約會軟件”，因為它迎合的是最底層、最直接的需求。

而他選擇了第二種流，派：堅持一個非常堅定的、甚至是逆勢的觀點，然后瘋狂地專注去做。

Chroma 的發展路徑完美地詮釋了這一點。在向量數據庫賽道最火熱、所有人都急著融資、搶占市場的時候，他們卻選擇放慢腳步，花了很長時間去打磨他們的云產品 Chroma Cloud。因為他們不想為了速度，而犧牲掉他們最看重的“卓越的開發者體驗”。

Jeff 說：“你做一件事的方式，其實就是你做所有事的方式。” 這句話深深地打動了我。從 Chroma 簡潔的 API（??pip install chromadb??），到他們設計精美的網站和文檔，再到他們高信息密度的技術報告，處處都體現出一種對細節、對品質、對工藝水準（Craftsmanship）的極致追求。

這種追求，源于創始人自身的品味和堅持。他認為，創始人必須是公司的“品味把關人”，確保公司的文化、產品和品牌擁有一致的靈魂。

最后，他談到了人生。他說人生短暫，如風中煙霧，所以應該只去做自己真正熱愛的事，只和自己喜歡的人共事，只服務自己真心想服務的客戶。他談到了人類的繁榮，談到了那些需要幾個世紀才能完成的工程，比如巴塞羅那的圣家堂。

那一刻我明白了，他們之所以如此在意上下文工程的細節，之所以愿意花巨大的精力去打磨一個看似簡單的數據庫，并不僅僅是為了商業上的成功。在這一切背后，有一種更宏大的愿景在驅動著他們：把 AI 應用的開發，從充滿不確定性的“煉金術”，變成一門嚴謹、可靠、甚至優雅的“工程學”。

他們想種下的，是一棵自己或許無法完全看到它枝繁葉茂的大樹。

回望 RAG 的興衰，再到上下文工程的崛起，我看到的不僅僅是技術概念的迭代，更是一種思想的進化。我們正在告別那個充滿泡沫和炒作的“淘金熱”時代，走向一個更成熟、更理性的“大航海”時代。前路依然充滿未知，但我們手中的羅盤，已經變得前所未有的清晰。

本文轉載自??芝士AI吃魚??，作者：芝士AI吃魚