跳至主要內容
7.565 分鐘閱讀

我們造了神諭機,卻需要圖書館員——為什麼 RAG 的「R」比 Google 搜尋還難

搜尋從 Yahoo! 時代就在了,對多數人來說感覺像「已經解決」。打幾個字、按 Enter,就會出一份「夠用」的清單。

  • rags
  • agent memory
  • llm
我們造了神諭機,卻需要圖書館員——為什麼 RAG 的「R」比 Google 搜尋還難

我們造了神諭機,卻需要圖書館員——為什麼 RAG 的「R」比 Google 搜尋還難

「已解決」的錯覺

搜尋從 Yahoo! 時代就在了,對多數人來說感覺像「已經解決」。打幾個字、按 Enter,就會出一份「夠用」的清單。久而久之,我們養成習慣:搜尋、掃過、點進去、再排序。所以我懂為什麼大家覺得搜尋不是問題。

但那只是錯覺。兩個小故事。

我有個朋友,叫他 Frank 吧。他在多家跨國科技公司當過 CTO。我們聊到 RAG,他的看法基本上是:「搜尋早就解決了,接 BM25 或 embedding 就好。」我說行不通,舉了 query-document mismatch、跨 session 綜合等問題。他不聽,說我顧慮太理論、太學術。結果我是對的。

另一個朋友叫 Tom,前阿里巴巴 P8 工程師,Elasticsearch 專家。Tom 知道我在做 RAG,反應是:「還有什麼好做的?超 low-tech 的啊。」這次我不用爭。我只建議他自己往下鑽。畢竟,搜尋專家理應更清楚才對。

錯覺是真的。

這篇文章我會說明,RAG 裡的 retrieval 不是 網頁搜尋——而且在很多方面更難。我們會看網頁搜尋為什麼能 work、RAG 實際面對什麼、以及為什麼「圖書館員」比「神諭機」更重要。

網頁搜尋的黃金時代

大多數資料都是垃圾。

根據 Ahrefs 2023 年的資料,整個網路只有 3.45% 能從 Google 拿到流量。這不只是今天的事;三十年前就是這樣。正因如此,Larry Page 和 Sergey Brin 發明了 PageRank,在垃圾堆裡找金子。那個演算法標誌著網頁搜尋黃金時代的開始。

但 PageRank 只是第一步。它告訴你哪些網站品質高,不代表一定是你想要的。於是後來有了關鍵字匹配(TF−IDF)、語意理解(neural embeddings)、實體辨識(Knowledge Graph),超越單純字串比對。Google 等人用這些技術更好理解使用者意圖,盡量帶回最相關的資料。效果我們都親眼見過。

今天的 RAG 系統會向搜尋引擎這些 前輩 借幾招。sparse 和 dense 文字編碼到處都是。Zep、Mem0 這類 agent memory 函式庫有自己的 knowledge graph 實作。HippoRAG 這類方案甚至借 PageRank 的想法在知識庫裡排序文件。

這就引出一個問題:如果 RAG 在向大師學習,為什麼常常感覺這麼脆弱?為什麼 Google 搜尋這麼穩,RAG 卻可以天真到讓人抓狂?

大分流:當地圖消失

網頁搜尋本質上比較簡單,因為網路就是,嗯,一張 。它有內建結構,一張由數百萬想被找到的人維護的地圖。

這張地圖有明確方向。網站有目的和主題。頁面用 HTML 結構、sitemap、robots.txt 引導爬蟲。最重要的是,backlink 形成全球引用網路,告訴你哪些頁面、哪些站相關。

地圖也有隱含訊號,來自幾十年的人類互動。Google 能取得海量使用者行為——數十億次點擊、查詢修正、停留時間——不斷強化地圖上哪些路徑通到寶藏。它理解 domain authority、新鮮度等時間訊號,還有無數其他線索,讓地圖豐富又可靠。

網路是訊號豐富的環境。

換到 RAG,我們在地獄模式。沒有地圖,只有垃圾場。

資料彼此不連。可能是密密麻麻的合約,也可能是亂成一團的 Slack 紀錄。運氣好時沒 context,運氣不好時 context 還錯。更糟的是,我們常把垃圾砸成更小的「chunk」,進一步剝掉本來就少的 context。

這又回到神諭機和圖書館員。LLM 是神諭機——像會烤神秘餅乾的慈祥阿嬤,看起來什麼都知道,即使其實不知道。我們做 RAG,是給這位聰明但不可靠的神諭機配一位一絲不苟的圖書館員,讓它 grounded 在事實上。

但我們把圖書館員丟進垃圾場,還指望他光榮地完成工作?

歡迎來到垃圾場

RAG 垃圾場的問題很特別。在 query 端,使用者行為完全不同:

  1. 使用者是在聊天,不是在搜尋。 他們跟 LLM 講話像跟人講話,query 往往很長、很口語、沒有清楚關鍵字。
  2. context 是假設的,不是給的。 使用者預期 LLM 記得過去對話或擁有普世知識。他們會說:「我上週跟你說的那件重要的事是什麼?」祝你好運能檢索到。

系統端,挑戰同樣嚇人:

  1. Context Rot。 就算你付得起檢索幾十份文件以確保找到正確事實(本身就很貴),又會遇到新問題:塞太多 context 會淹沒正確答案、拖累推理。
  2. 矛盾到處都是。 從不同文件拉出不相連的 chunk,常常看起來互相矛盾。沒有原始結構,LLM 只能猜哪個事實才對。

這是 RAG 開發者每天都在打的仗。「R」難,不是因為缺演算法,而是演算法離不開它最愛的夥伴:資料結構。我們倒進 RAG 的檔案和文字,缺乏網頁那種 metadata、階層和連結。

未來是策展,不只是搜尋

面對這堆垃圾場問題,業界慢慢明白:不能只發明更好的 retrieval 演算法,還得成為更好的資料策展人。

就像任何垃圾場,場地本身無辜;亂的是缺乏整理。我們現在看到「Context Engineering」成為一門專門學科。Databricks 這類公司整個生意都圍繞資料處理、治理、血緣。AGI 快要到了,我們才終於理解「Big Data」是個神話。

豐富、高品質、結構良好的資料才是王。

搜尋的演算法面可能是成熟領域。資料結構這面才剛開始。


原文發表於 Medium