編者按： 向量嵌入技術真的能像宣傳的那樣精確地幫助檢索和理解信息嗎？檢索增強生成（RAG）技術的可靠性真的像我們想象的那么高嗎？

本文揭示了 RAG 技術中最為致命的技術短板 —— 向量嵌入技術的語義匹配可靠性。作者并非停留在批評，而是提供了一個務實的解決方案：將向量嵌入作為搜索結果的優化工具，與傳統的同義詞搜索等方法配合使用，而非唯一檢索依據。

本文系原作者觀點，Baihai IDP 僅編譯轉載。

作者 | Michael Wood

編譯 | 岳揚

在 RAG 系統中，其核心任務是找出那些與查詢內容相似度最高的存儲信息。然而，向量相似度搜索并不能實現這一點，這也是 RAG 在實際應用中遭遇挫折的原因。

01 選錯了工具

RAG 在生產環境中的失敗，歸咎于使用了向量嵌入來衡量信息的相似度，這顯然不是一個恰當的選擇。 我們可以通過一個簡單的例子來說明這一點。假設有三個詞匯：

• King（國王）
• Queen（王后）
• Ruler（統治者）

“國王”和“統治者”可能指的是同一人（因此它們可以被視為同義詞），但“國王”和“王后”則明顯指的是不同的人。按照相似度的百分比來衡量，“國王/統治者”應該有較高的相似度得分，而“國王/王后”的得分則應該是零。

換句話說，如果查詢的內容是關于“國王”的，那么包含“王后”信息的文本片段應該是不相關的；而包含“統治者”信息的文本片段則可能相關。但是，向量嵌入卻認為“王后”與“國王”的關聯度高于“統治者”。以下是在使用 OpenAI 的 ADA-002 嵌入模型時，“王后”和“統治者”與“國王”的向量相似度得分：

• King（國王）
• Queen（王后）：92%
• Ruler（統治者）：83%

這意味著，當搜索關于“國王”的信息時，系統會優先展示關于“王后”的文本片段，而不是關于“統治者”的，盡管后者在內容上可能更為相關，而關于“王后”的信息則完全不相關。

02 向量嵌入在處理“誰、什么、何時、何地、如何”這類問題時并不適用

向量嵌入的問題不僅出現在涉及人物的詞匯（如國王）上，也出現在涉及其他事物的詞匯上。

設想一個關于貓的特性的查詢。理論上，提到狗的文本在相似度上應該是零，而關于貓科動物的文本則應該有極高的相似度得分。但是，向量嵌入又一次給出了錯誤的結果：

• 貓（Cat）
• 狗（Dog）：86%
• 貓科動物（Feline）：85%

盡管兩者分數只差 1 %，但這仍然意味著討論狗的文本會優先于討論貓科動物的文本；這顯然不合理，因為討論狗的文本與查詢毫不相關，而討論貓科動物的文本則極為相關。

絕對同義詞指的是意義完全相同的詞匯。然而，即便是在處理絕對同義詞時，向量嵌入也會錯誤地優先考慮那些根本不是同義詞的詞匯 —— 下面的例子就進一步證明了這一點。

“The Big Apple”是紐約市的別稱。假設蘇珊是一位新澤西州的居民，她在博客中記錄了自己在家鄉的餐館、博物館和其他地點的體驗。但在一篇帖子中，蘇珊提到她在“The Big Apple”舉行的婚禮。當一位訪客在蘇珊的網站上詢問 Chatbot：“蘇珊去過紐約嗎？”時，問題出現了。

非常遺憾，關于新澤西的大量內容會排在蘇珊提及結婚的那篇帖子之前。原因何在？從向量嵌入的角度來看，“新澤西”在語義上比“The Big Apple”更接近“紐約”：

• 紐約（New York）
• 新澤西（New Jersey）：90%
• The Big Apple：89%

根據涉及“新澤西”的帖子數量，對“The Big Apple”的提及有可能在 Chatbot 檢索到的數百個候選內容中都被忽略。這表明，向量嵌入在處理地點信息（如紐約（New York））時同樣可能出錯，正如它在處理人物（如國王（Kings））、其他食物（如貓（cat））時的表現一樣。

實際上，向量嵌入在處理行為操作時也存在問題。

• bake a cake
• bake a pie: 93%
• make a chocolate cake: 92%

以“烘焙蛋糕（bake a cake）”為例，討論“烘焙派（bake a pie）”（得分93%）的文本可能會優先于“制作巧克力蛋糕（make a chocolate cake）”（得分92%）的內容；盡管前者與查詢完全無關，而后者則直接相關。

上述例子表明，向量相似度并不是衡量內容相同度的可靠方法。它不僅不適用于人物（如國王）、事物（如貓）和地點（如紐約），也不適用于行為操作（如烘焙蛋糕）。換言之，向量嵌入在回答關于人物、事物、地點以及行為操作等問題的相似度百分比時，并不具備可靠性。 換句話說，向量嵌入在處理人們可能提出的幾乎所有類型的問題上都有其固有的缺陷。

03 RAG 愛好者未曾透露的真相

你可能會懷疑上述例子是否經過了篩選，或者百分比分數是否真的重要。讓我們對比一下 RAG 的誤導性描述與其實際運作方式。

• RAG 的誤導性描述是這樣的：將數以百萬計的文本片段的向量嵌入存儲在向量數據庫中。獲取用戶查詢的向量嵌入，然后通過余弦相似度算法，找出與之最匹配的前三個片段，并將這些片段連同用戶查詢一起發送給大語言模型（LLM）。這被標榜為一種“快速、精確且可擴展”的解決方案（引自一位知名 AI 作者，其公司已培訓超過 40 萬人——詳見下文）。
• 然而，最先進的 RAG 實際操作是這樣的：將數千份文檔的向量加載到向量數據庫中，檢索出近 50,000 個字符的文本片段，與用戶查詢一起發送給 LLM，結果卻是一個可靠性不高的 Chatbot（例如，F1 score 低于50）。

以 2024 年 9 月 3 日發布的 OP-RAG[1] 為例。

OP-RAG 是 Nvidia 三位研究者的研究成果，因此這項研究來自聲譽卓著的研究人員。

再來看上述圖表所示的結果，這些是基于 ??EN.QA?? 數據集的評估數據。數據集中的前兩個問題是：

• 《行尸走肉》第八季的最后一集何時播出？
• 希臘神話中的春之女神是誰？

這些問題的答案都很簡短，不需要復雜的解釋。而且，這個數據集僅占整個維基百科語料庫的3.8%。

盡管 Nvidia 擁有豐富的資源，數據集的大小適中，答案也相對簡短，但研究者們還是通過一種新的 RAG 方法，發送 48K 的文本片段并連同用戶查詢一起，打破了之前的最先進水平，實現了 47.25 的 F1 score（如果發送的內容更少，F1 score 會更低）。

這些 Nvidia 的研究者難道沒有意識到，他們本應該能夠存儲超過現在 25 倍的向量，并且始終能在前三個匹配內容中找到相關答案嗎？當然不是。實際上，RAG 在現實世界中的運作并非如此。同樣，Nvidia 在 2024 年 11 月 1 日發布的 LongRAG[2] 也是一個絕佳的例證。

04 更大型的 LLMs 也救不了場

看看 2024 年 10 月 Databricks[3] 發布的研究成果。

要想正確率超過 80 %，RAG 得向 OpenAI 的 o1 模型發送 64K 字符的文本片段。其他模型，包括 GPT-4o、GPT-4 Turbo 和 Claude-3.5 Sonnet，無一達到這一標準。但 o1 模型的結果問題重重。

首先，其產生信息的幻覺率居高不下。

其次，即便處理的是簡短內容，o1 的速度也慢得讓人無法忍受。處理 64 K的文本簡直慢到讓人難以接受。

再者，運行 o1 的成本也是一筆不小的開銷。

更有甚者，業界傳言稱即將推出的一批新模型在性能上并未帶來明顯提升 —— Anthropic 甚至無限期推遲了新模型的發布。

即便大模型能夠解決問題，它們也會變得更慢、更貴。換句話說，對于實際應用來說，它們未免太慢也太貴了。企業會愿意為一個 Chatbot 支付比真人更高的費用嗎？尤其是這個機器人每給出一個不可靠的答案都需要花費近一分鐘的時間。

這就是 RAG 的現狀。這就是依賴向量嵌入帶來的后果。

05 別責怪自己，問題出在它們身上

我之所以撰寫此文，是因為我發現論壇上有許多數據科學家和程序員在自我懷疑，認為自己操作不當。通常情況下，總有人會熱心地提出一系列解決方案：比如重排序、改寫查詢語句、使用 BM25 算法、構建知識圖譜等等，希望能撞大運找到解決之道。

但問題在于，成千上萬的人所學到的東西根本就是錯誤的。以下內容摘自一本 2024 年 10 月更新的書籍，作者是一家培訓過 40 萬人的公司的聯合創始人：

RAG 最適合處理那些數據量龐大、無法一次性裝入 LLM 上下文窗口，且需要快速響應和低延遲的場景。…

現在，RAG 系統已經有了一套標準的架構，這一架構已經在眾多流行框架中得到應用，開發者無需再從頭開始。…

數據轉換成向量嵌入后，向量數據庫就能迅速找到相似項，因為相似項在向量空間中以相近的向量形式存在，我們稱之為 vector store（即 storing vectors）。語義搜索在 vector stores 中進行，它通過比較用戶查詢的嵌入向量與存儲數據的嵌入向量來理解用戶查詢的意義。這樣，無論用戶查詢中使用了哪些關鍵詞，或是搜索的數據類型如何，都能確保搜索結果的相關性和準確性。

數學原理告訴我們，向量嵌入技術并不是通過比較相似度的百分比來定位信息。它們無法理解用戶查詢的真實意圖。即便是面對最簡單的用戶查詢，它們也無法保證搜索結果的相關性，更別提“無論用戶查詢中使用了哪些關鍵詞，或是搜索的數據類型如何”。

正如 OP-RAG 研究論文所示，即便通過向量搜索能夠檢索到 400 個數據塊，大語言模型（LLM）在最基礎的測試中也有超過一半的概率找不到相關信息。盡管如此，教科書上卻告訴數據科學家：“在實際操作中，我們可以將整個網站或課程內容上傳到 Deep Lake [向量數據庫]中，以便在成千上萬的文檔中進行搜索…… 為了生成回答，我們會提取與用戶問題最匹配的前 k 個（比如前 3 個）數據塊，整理成提示詞，然后以 temperature 參數為 0 的模式發送給模型。”

教科書普遍向學生灌輸，向量嵌入技術強大到可以存儲“數百萬份文檔”，并且能夠從前 3 個最相關的數據塊中找到用戶查詢的答案。但是，根據數學原理和引用的研究結果，這種說法顯然是不準確的。

06 通往百分百精確回答的道路

解決問題的關鍵在于不再單純依賴向量嵌入技術。

但這并不意味著向量嵌入就毫無價值了。絕非如此！ 它們在自然語言處理（NLP）領域扮演著至關重要的角色。

例如，向量嵌入是處理多義詞的有力工具。以“glasses”這個詞為例，它既可以指代日常飲用的玻璃杯，也可以是指戴在臉上的眼鏡。

假設有人提問：朱莉婭·羅伯茨（Julia Roberts）佩戴的是哪種眼鏡？通過向量嵌入技術，我們可以確保與眼鏡相關的信息位于飲酒玻璃杯相關的信息之上，這正是其語義處理能力的體現。

ChatGPT 的問世，在數據科學界引發了一種不太樂觀的變化。像 synonyms、hyponyms、hypernyms、 holonyms 等 NLP 的重要工具，被邊緣化，轉而更多地關注 Chatbot 的查詢。

無疑，大語言模型（LLMs）確實簡化了 NLP 的某些方面。但目前，我們似乎把有價值的技術也一同舍棄了。

LLMs 和向量嵌入技術是 NLP 的關鍵技術，但它們并非完整的解決方案。

舉個例子，許多公司發現，當 Chatbot 無法展示訪客所需的產品清單時，訪客往往會選擇離開。為此，這些公司嘗試用基于同義詞的搜索來替代傳統的關鍵字搜索。

基于同義詞的搜索確實能夠找到關鍵字搜索遺漏的產品，但這是有代價的。由于一詞多義的存在，常常會有不相關的信息覆蓋了訪客真正想要的內容。比如，一個想買飲酒玻璃杯的訪客，可能會看到一大堆眼鏡的清單。

面對這種情況，我們不必全盤否定，向量嵌入技術恰好可以發揮作用。我們不應完全依賴向量嵌入，而應將其作為搜索結果的優化工具。在基于同義詞的搜索基礎上，利用向量嵌入將最相關的結果推至前列。

Thanks for reading!

Hope you have enjoyed and learned new things from this blog!

About the authors

Michael Wood

AI Engineer and Full-Stack Developer.

Personal site: ??https://michaelcalvinwood.net??.

END

本期互動內容 ??

?如果不完全依賴向量嵌入，你認為RAG系統還有哪些可行的信息檢索優化路徑？歡迎分享你的技術構想。

??文中鏈接??

[1]??https://arxiv.org/html/2409.01666v1??

[2]??https://arxiv.org/html/2410.18050v2??

[3]??https://www.databricks.com/blog/long-context-rag-capabilities-openai-o1-and-google-gemini??

原文鏈接：

??https://blog.cubed.run/the-insanity-of-relying-on-vector-embeddings-why-rag-fails-be73554490b2??