“ RAG召回時最好進行多次過濾，這樣才能大大提升召回文檔的質量。”

關于RAG數據召回技術，大家都都知道現在普遍使用的是相似度(語義)召回方式；但對沒有真正實際操作過的人來說，可能會認為RAG只能進行相似度召回；但在真正的業務場景中，標量召回的效果可能會比相似度召回更好。

原因在于，RAG的目的是為了更準確的召回與問題相關的內容，但并沒有限制具體的召回方式，不論是傳統的字符匹配，分詞技術(如es)，還是現在爆火的相似度計算都可以作為數據召回的手段，而且可以根據不同的場景選擇合適的召回方式。

標量召回和相似度召回

標量召回就是基于傳統的字段匹配的方式，而相似度召回是基于向量計算的方式；其分別對應傳統的關系型數據庫和現在的向量數據庫。

向量數據庫作為一個相對比較新的中間件，可能部分剛開始學習向量數據庫的人并不了解其運作機制，可能會有人認為其只支持向量計算。

但事實是，向量數據庫和傳統的數據庫并沒有什么特別本質的區別，其更像是在傳統數據庫的基礎之上，增加了向量計算，以及單獨的向量字段，因此向量數據庫同樣支持傳統的字符匹配模式。

我們都知道在RAG中有一個非常重要的組件——Embedding嵌入模型，其作用是把自然語言轉換成向量形式。

而向量數據庫的運作原理就是，在文檔處理階段，通過對文檔進行拆分，然后再通過embedding模型把拆分之后的文檔轉換成向量模式，之后保存到向量數據庫中的向量字段中。

然后在用戶提問時，通過同樣的方式把用戶問題轉換成向量模式，之后再通過某種計算方式對用戶問題和拆分的文檔進行向量匹配，如歐式距離，余弦相似度計算等方式，來計算用戶問題和具體文檔之間的相似度，相似度越高，其語義相關性越大；這就是相似度召回的基本原理。

但是呢，相似度計算畢竟不是很準確，特別是在語義不明確的情況下；其召回的數據質量真的無法保證，因此這時就需要使用標量召回配合相似度召回來提升文檔的召回質量。

舉例來說，針對不同的用戶可能存在不同的特性，然后可以把這些特性作為文檔的屬性進行數據隔離；如有些文檔屬于部門專有文檔，有些文檔屬于用戶文檔，有些文檔又屬于企業內部文檔；而部門名稱，用戶文檔，企業文檔等都屬于數據特征。

因此，不同用戶提出的問題，可以先根據用戶所在的部門，或者屬于消費者和管理者的角色，先篩選出對于角色的文檔；然后再次基礎之后，在進行相似度召回，這樣就能大大提升文檔召回的準確率。

本文轉載自???AI探索時代??? 作者：DFires