「RAG 已死？」這句話前陣子引發一波討論風潮。RAG (Retrieval-Augmented Generation，檢索增強生成) 讓大型語言模型 (LLM) 能夠存取外部知識，看似解決了模型「胡說八道」和知識侷限性的問題。打造一個 RAG 應用程式 Demo 非常簡單，但許多團隊在將其推向生產環境時，卻發現系統的穩定性與回答品質遠不如預期。
Chroma 的創辦人兼執行長 Jeff Huber 在訪談中則提供更具洞見的觀點：RAG 並沒有死亡，但我們對 RAG 的理解與實踐，已經到了必須「升級」的時刻。他認為，業界需要從單純談論 RAG，演進到一個更全面、更嚴謹的方式：「情境工程 (Context Engineering)」。影片中的訪談還有許多精彩對話，有興趣的讀者請務必去觀看！
https://www.youtube.com/watch?v=pIbIZ_Bxl_g這家公司是誰？Chroma 的核心理念與產品
從「煉金術」到「工程學」：Chroma 的創立初衷
Jeff Huber 創立 Chroma 的核心動機，源於他多年在應用機器學習領域的經驗。他發現打造一個引人注目的 AI Demo 相對容易，但要將其變成一個穩定、可靠、可維護的生產級系統，過程卻充滿了不確定性，感覺更像是「煉金術 (alchemy)」而非「工程學 (engineering)」。開發者們不斷地調整參數、更換模型、修改提示詞，卻缺乏一套系統性的方法論來衡量與改進系統效能。
Chroma 的使命，就是要填補這個從 Demo 到 Production 之間的巨大鴻溝。他們希望提供一套工具與基礎設施，讓開發 AI 應用程式的過程，能回歸到嚴謹的工程學方法，讓每一步的優化都有跡可循。
不只是向量資料庫：打造為 AI 而生的現代搜尋基礎設施
當人們問起 Chroma 是做什麼的，Jeff 的回答是：「為 AI 應用程式打造的檢索引擎 (retrieval engine)」，或是「為 AI 設計的現代搜尋基礎設施」。這兩個描述都比「向量資料庫」來得更精準。Jeff 解釋，「現代」體現在兩個層面：
- 現代化的分散式系統架構：Chroma 的底層架構採用了近 5-10 年才成熟的系統設計原則，例如讀寫分離、儲存與運算分離。它以 Rust 語言編寫，具備多租戶能力，並利用物件儲存作為核心的持久層。
- 為 AI 設計的搜尋典範：傳統搜尋系統的最終使用者是「人類」。人類一次大概只能消化 10 個藍色連結。但 AI 應用的搜尋使用者是「大型語言模型」。LLM 可以一次消化數百甚至數千份文件，這徹底改變了搜尋系統需要處理的工作負載 (workload) 和回傳結果的形式。
Chroma 的設計從一開始就考慮到這些為 AI 服務的根本性差異，這也是它與許多傳統系統「附加」向量搜尋功能的產品，最核心的不同之處。
從 RAG 到情境工程：AI 應用開發的思維升級
Jeff Huber 的核心論點並非要拋棄 RAG，而是指出「RAG」這個詞彙已經被過度簡化，成為一種阻礙我們深入思考的標籤。我們需要將其解構，並融入一個更廣闊的工程框架。
「脈絡腐化」：為什麼更大的 Context Window 無法拯救簡單的 RAG？
近年來，各大模型廠商不斷推出擁有超長上下文視窗的模型。市場上普遍存在一種迷思：只要視窗夠大，把所有相關資料都丟進去，LLM 就能夠完美地理解與回答。
然而，Chroma 的研究團隊發表了一份名為「Context Rot (脈絡腐化)」的技術報告：隨著上下文視窗中 Token 數量的增加，LLM 的表現會顯著下降。 模型會開始忽略指令、無法專注於關鍵資訊，推理能力也會變弱。這就像讓一個人在充滿數千本書的房間裡找一句話，過多的資訊噪音反而會讓他迷失方向。
重新定義任務：什麼是「情境工程 (Context Engineering)」？
基於「脈絡腐化」的觀察，Jeff 提出個人對於「情境工程」定義：
情境工程是一門專業，其核心任務是決定在任何一次 LLM 生成步驟中，應該在上下文視窗中放入哪些資訊。
這份工作包含兩個循環：
- 內循環 (Inner Loop)：針對當前的單次查詢，如何即時地篩選、組合出最相關的資訊片段。
- 外循環 (Outer Loop)：如何根據系統的長期表現，持續優化篩選資訊的策略，讓系統隨時間變得越來越聰明。
RAG 其實只是實踐情境工程的一種手段。問題在於 RAG 這個詞彙可能導致「檢索 (Retrieval)」、「增強 (Augmented)」、「生成 (Generation)」三個獨立的工程問題混為一談。「情境工程」則將焦點放回最關鍵的步驟——如何為 LLM 精心準備一份完美的「簡報資料」，而這份準備工作，遠比一次簡單的向量搜尋要複雜得多。
實踐情境工程：將 RAG 的「R」做到極致
那麼，具體的情境工程該如何實踐？這代表我們需要將 RAG 中的「R (Retrieval)」拆解成更精細的步驟。Jeff 分享在頂尖團隊中逐漸成為主流的「兩階段檢索」策略：
- 第一階段：大規模粗篩 (First-stage Retrieval)這個階段的目標是從海量的候選資料中，快速、低成本地篩選出一個相對較小的候選集。這裡會綜合使用多種工具，例如：向量搜尋 (Vector Search)、全文檢索 (Full-text Search)、元資料過濾 (Metadata Filtering)。透過這個階段將候選文件從數百萬份，縮小到數百份。
- 第二階段：LLM 重排 (Reranking)。利用一個 LLM（可以是專門的 Reranker 模型，也可以是通用的 LLM）作為「重排器」，對第一階段篩選出的數百份文件進行二次排序與篩選，挑選出最終最相關的 20-30 份。
TN科技筆記的觀點
所謂的 RAG 爭議，其核心並非技術的生死，而是思考方式的升級。過去我們談論 RAG，常將其視為一個「向量檢索 -> 餵給 LLM」的簡單工具。而「情境工程」則將其提升為一門嚴謹的工程學科。這意味著我們不再是被動地期望 LLM 碰巧找到好答案，而是主動地、系統性地設計整個資訊供應鏈，從源頭就確保 LLM 能在最理想的「情境」下進行思考與生成。
「情境工程」的核心理念，是將品質控制點大幅前移到「生成之前」。透過多階段檢索、精排 (Reranking) 等手段，我們能在資訊進入 LLM 的上下文視窗前就進行過濾與優化，這是一種更有效、更具確定性的品質保障方式。例如近期主流大廠 AI 應用，都離不開對使用者歷史與偏好的「記憶」，其技術本質就是一套高效的「情境工程」系統。它能夠在每一次互動中，精準地從歷史對話、使用者檔案中檢索出最相關的片段，為 LLM 營造出個人化情境。由此可知未來「如何為大型語言模型提供關鍵且完整的上下文」已成為 LLM 回答品質最重要的控管手段之一。影片中的訪談還有許多精彩對話，有興趣的讀者請務必去觀看！
支持TN科技筆記，與科技共同前行
我是TN科技筆記，如果喜歡這篇文章，歡迎留言、點選愛心、轉發給我支持鼓勵～～～也歡迎每個月請我喝杯咖啡，鼓勵我撰寫更多科技文章，一起跟著科技浪潮前進！！>>>>> 請我喝一杯咖啡
在此也感謝每個月持續請我喝杯咖啡的讀者們，讓我更加有動力為各位帶來科技新知！
