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 兩步合起來的，有可能前面兩步就錯了，也有可能單獨看還好，但只看頭尾問題 + 答案就覺得不對勁
而且由於「聊天」的特性，第一項搜尋的挑戰更為嚴峻：拿到自然語言、長句的問題，要從索引找出相關的片段資料，有時不是光靠 embedding 就能解決的
向量資料庫？ #
向量資料庫 (Vector DB) 並不是 RAG 的專利！傳統搜尋也能用，更精確地說是利用 embedding，把使用者的關鍵字找最相似的資料，而不一定單純用關鍵字匹配
另一方面，RAG 不見得一定要用 Vector DB；就字面上來說，也可以用網頁搜尋的結果去生成（只不過歷史脈絡並不是這樣），例如像 Perplexity
如果對 RAG 有興趣，我有一系列跟 RAG 有關的文章: https://ywctech.net/tags/rag/ ，包括 LlamaIndex 的實作，以及 LangChain 與 LlamaIndex 的比較唷