RAG 跟傳統搜尋不一樣的地方
目錄
傳統搜尋跟檢索增強生成 (RAG, Retrieval Augmented Generation) 最大的不同
搜尋 | RAG |
---|---|
目的: 找到個體 | 目的: 得到答案 |
索引內的每筆資料:通常是一整個個體(一頁網頁、一則新聞、一個商品…) | 索引內的每筆資料:有可能是個體的片段 |
索引內的資料:有「很多」個體 | 索引內的資料:可能是從「一篇」超長的文件檔案所分段 |
索引匹配出來的:是直接給使用者看的結果 | 索引匹配出來的:是給 LLM 看的(可以零碎讓人類不太懂) |
輸出是資料個體本身 | 輸出是 LLM 從片段去生成的文字 |
用不用向量資料庫、用不用 embedding 並不是相異之處!
傳統搜尋 #
傳統搜尋是以「關鍵字」起家(例如 Google 找網頁, 電商找產品…),找出所有包含這個關鍵字的個體
所以傳統搜尋的挑戰之一是「關鍵字」匹配,例如
- 錯字:使用者查 strawbarry 找不到個體 strawberry
- 同義詞:查口紅,找不到唇膏
- 語意:查圓桌,但找到圓桌武士
- 匹配到不同部分:查香水,但找到 「香」氛「水」氧機
這些挑戰也已經有不同的解法(包括 embedding! ),然而…
傳統搜尋最大的挑戰是「非自然語言的提問」與「沒給出答案」
非自然語言的提問 #
平常你跟人聊天,問的是「第一次約會推薦去哪裡吃晚餐?」、「老婆生日了,要送什麼禮物比較好?」
但是做 Google 搜尋,大概很多人被訓練著以單詞的方式,查詢像「約會 晚餐」或「生日禮物」
因為是用字串比對,其他贅字並沒有幫助甚至有害。然而,從自然提問濃縮到單詞,有些資訊就漏掉了
沒給出答案 #
「不是找到相符的網頁或文件了嗎?為什麼說沒給答案?」 – 因為你還是要讀完那些網頁,自己研究消化
如果「個體」是一個超長網頁或文件,對,你知道這個文件跟你想查詢的有關,但是他有 100 頁,就算你在文件內 ctrl-f 找到你的關鍵字,你還是要讀過不少文字才能獲得答案
… 相關的文件給你了,但答案要自己找尋
RAG #
RAG (Retrieval Augmented Generation) 則是由於近年生成式 AI 的進步,模型不但能文字接龍,甚至能多輪對話。 所以使用者不再需要把問題變成關鍵字;使用者可以直接用白話提問
然而,語言模型是靠訓練時的資料獲取知識。很多 LLM 無法上網獲得新知,也沒有便宜的方法去進修補充知識
於是有了 RAG 這個方法論:
- 對於使用者的問題,額外寫程式搜尋到相關資料
- 把相關資料,連同使用者問題,給 LLM 讓他思考聊天,給出答案
以前是「你」要消化看懂文件,現在是「LLM」看懂文件直接給出答案
而且只需要拿重要的「片段」給 LLM ,不需要給個體、一整篇文件,LLM 就能拿來利用,融合模型內部的知識 (parametric memory),以文字對話的方式給出答案
雖然傳統搜尋也可以只把片段給人類看,不過傳統搜尋大部分的心態是「導流量到個體」;顯示片段只是為了吸引使用者閱讀去融合自己的知識
RAG 的挑戰 #
因此,雖然 RAG 整體看似更厲害,但本質上的挑戰跟你做傳統搜尋一樣 – 或許還更多。RAG 的挑戰有
- 搜尋 recall/precision/relevancy:仍然要把問題相關的資料搜尋出來,是否所有相關的都有搜出來?搜出來的都相關?沒相關的不搜出來?
- 生成幻想:LLM 拿到搜尋結果以後,生成的答案是否跟「搜尋結果」有關?
- 整體滿意度:LLM 生成的答案是否跟最初的「問題」有關?答案是由 1 2 兩步合起來的,有可能前面兩步就錯了,也有可能單獨看還好,但只看頭尾問題 + 答案就覺得不對勁
![Different metrics for different phases in RAG](./rag-metrics.webp)
而且由於「聊天」的特性,第一項搜尋的挑戰更為嚴峻:拿到自然語言、長句的問題,要從索引找出相關的片段資料,有時不是光靠 embedding 就能解決的
向量資料庫? #
向量資料庫 (Vector DB) 並不是 RAG 的專利!傳統搜尋也能用,更精確地說是利用 embedding,把使用者的關鍵字找最相似的資料,而不一定單純用關鍵字匹配
另一方面,RAG 不見得一定要用 Vector DB;就字面上來說,也可以用網頁搜尋的結果去生成(只不過歷史脈絡並不是這樣),例如像 Perplexity
如果對 RAG 有興趣,我有一系列跟 RAG 有關的文章: https://ywctech.net/tags/rag/ ,包括 LlamaIndex 的實作,以及 LangChain 與 LlamaIndex 的比較唷