AIxiv專欄是機器之心釋出學術、技術內容的欄目。過去數年，機器之心AIxiv專欄接收報導了2000多篇內容，覆蓋全球各大高校與企業的頂級實驗室，有效促進了學術交流與傳播。如果您有優秀的工作想要分享，歡迎投稿或者聯絡報導。投稿郵箱：liyazhou@jiqizhixin.com；zhaoyunfeng@jiqizhixin.com
本文作者為張穎峰，英飛流 InfiniFlow 創始人 CEO，連續創業者，先後負責 7 年搜尋引擎研發，5 年資料庫核心研發，10 年雲端計算基礎架構和大資料架構研發，10 年人工智慧核心演算法研發，包括廣告推薦引擎，計算機視覺和自然語言處理。先後主導並參與三家大型企業數字化轉型，支撐過日活千萬，日均兩億動態搜尋請求的網際網路電商業務。
搜尋技術是電腦科學中最難的技術挑戰之一，迄今只有很少一部分商業化產品可以把這個問題解決得很好。大多數商品並不需要很強的搜尋，因為這和使用者體驗並沒有直接關係。然而，隨著 LLM 的爆炸性增長，每家使用 LLM 的公司都需要內建一個強大的檢索系統，才能使得 LLM 可以真正為企業用起來，這就是 RAG （基於檢索增強的內容生成）—— 透過搜尋內部資訊給 LLM 提供與使用者提問最相關的內容，來幫助 LLM 做最終的答案生成。
想象一下，LLM 正在針對使用者提問回答，如果沒有 RAG，那麼 LLM 不得不根據自己在訓練過程中學到的知識來回憶內容，而有了 RAG 之後，這種問題回答就如同開卷考試，到教科書中去尋找包含答案的段落，因此回答問題變得容易很多。隨著 LLM 的演進，新的 LLM 具有更長的上下文視窗，可以處理更大的使用者輸入，如果可以直接在上下文視窗中載入整個教科書，為什麼還需要去教科書中翻答案呢？實際上，對於大多數應用而言，即使 LLM 可以包含上百萬乃至上千萬 Token 的上下文視窗，搜尋依然必不可少：
企業通常包含多個版本的類似文件，將它們全部傳給 LLM 會導致相互衝突的資訊。
大多數企業內部場景都需要對傳給上下文視窗的內容做訪問許可權控制。
LLM 更容易受到跟問題語義相關但卻跟答案無關內容的干擾，從而分心。
即使 LLM 能力很強大，也沒有必要浪費多很多的成本和延遲來處理跟使用者提問不相關的數百萬個 Token 。
RAG 從出現到流行只花了很短的時間，這得益於各種 LLMOps 工具迅速將如下的元件串接起來使得整個系統得以運轉。
以上這種基於語義相似度的方法已經工作了很多年：首先，將資料分塊（例如根據段落），然後透過 Embedding 模型把每個塊轉成向量儲存到向量資料庫。在檢索過程中，把提問也轉成向量，接著透過向量資料庫檢索到最接近該向量的資料塊，這些資料塊理論上包含跟查詢語義最相似的資料。
在整個鏈路中，LLMOps 工具可以操作的事情有：
解析和切分文件。通常採用固定大小來把解析好的文字切成資料塊。
編排任務，包括資料寫入和查詢時，負責把資料塊發到 Embedding 模型（既包含私有化也包含 SaaS API）；返回的向量連同資料塊共同發給向量資料庫；根據提示詞模板拼接向量資料庫返回的內容。
業務邏輯組裝。例如使用者對話內容的生成和返回，對話跟業務系統（如客服系統）的連線，等等。
這個流程的建立很簡單，但搜尋效果卻很一般，因為這套樸素的基於語義相似度的搜尋系統包含若干侷限：
Embedding 是針對整塊文字的處理，對於一個特定的問題，它無法區分文字中特定的實體 / 關係 / 事件等權重明顯需要提高的 Token，這樣導致 Embedding 的有效資訊密度有限，整體召回精度不高。
Embedding 無法實現精確檢索。例如如果使用者詢問 “2024 年 3 月我們公司財務計劃包含哪些組合”，那麼很可能得到的結果是其他時間段的資料，或者得到運營計劃，營銷管理等其他型別的資料。
對 Embedding 模型很敏感，針對通用領域訓練的 Embedding 模型在垂直場景可能表現不佳。
對如何資料分塊很敏感，輸入資料的解析、分塊和轉換方式不同，導致的搜尋返回結果也會大不同。而依託於 LLMOps 工具的體系，對於資料分塊的邏輯往往簡單粗暴，忽視了資料本身的語義和組織。
缺乏使用者意圖識別。使用者的提問可能並沒有明確的意圖，因此即便解決了前述的召回精度問題，在意圖不明的情況下，也沒有辦法用相似度來找到答案。
無法針對複雜提問進行回答，例如多跳問答（就是需要從多個來源收集資訊並進行多步推理才能得出綜合答案的問題。
因此可以把這類以 LLMOps 為核心的 RAG 看作 1.0 版本，它的主要特點在於重編排而輕效果，重生態而輕核心。因此，從面世一開始就迅速普及，普通開發者可以藉助於這些工具快速搭建起原型系統，但在深入企業級場景時，卻很難滿足要求，並且經常處於無計可施的狀態。隨著 LLM 快速向更多場景滲透，RAG 也需要快速進化，畢竟搜尋系統的核心是找到答案，而不是找到最相似的結果。基於這些，我們認為未來的 RAG 2.0 可能是這樣工作的：
其主要特點為：
1.RAG 2.0 是以搜尋為中心的端到端系統，它將整個 RAG 按照搜尋的典型流程劃分為若干階段：包含資料的資訊抽取、文件預處理、構建索引以及檢索。RAG 2.0 是典型的 AI Infra，區別於以現代資料棧為代表的 Data Infra，它無法用類似的 LLMOps 工具來編排。因為以上環節之間相互耦合，介面遠沒有到統一 API 和資料格式的地步，並且環節之間還存在迴圈依賴。例如對問題進行查詢重寫，是解決多跳問答、引入使用者意圖識別必不可少的環節。查詢重寫和獲得答案，是一個反覆檢索和重寫的過程，編排在這裡不僅不重要，甚至會干擾搜尋和排序的調優。近期知名的 AI 編排框架 LangChain 遭到吐槽，就是同樣的道理。
2. 需要一個更全面和強大的資料庫，來提供更多的召回手段，這是由於為解決 RAG 1.0 中召回精度不高的痛點，需要採用多種方法混合搜尋。除了向量搜尋之外，還應該包含關鍵詞全文搜尋、稀疏向量搜尋，乃至支援類似 ColBERT 這樣 Late Interaction 機制的張量搜尋。
近期 OpenAI 收購了資料倉儲公司 Rockset，這背後的邏輯，其實並不在於資料倉儲本身對於 RAG 有多麼大的價值，而是相比其他資料倉儲，Rockset 更是一個索引資料庫，它對錶的每列資料都建立了倒排索引，因此可以提供類比於 Elasticsearch 的關鍵詞全文搜尋能力，再配套以向量搜尋，原生具備這 2 類混合搜尋能力的資料庫，在當前階段，就已經沒有多少選擇了，再加上 Rockset 還採用了雲原生架構，2 點結合，是 OpenAI 做出選擇的主要原因。這些考慮，也是我們在另外開發 AI 原生資料庫 Infinity 的主要原因，我們期望它能原生地包含前述的所有能力，從而可以更好地支撐 RAG 2.0。
3. 資料庫只能涵蓋 RAG 2.0 中的資料檢索和召回環節，還需要站在整個 RAG 的鏈路上，針對各環節進行最佳化，這包括：
這些階段，可以說每個環節都是圍繞模型來工作的。它們聯合資料庫一起，共同保證最終問答的效果。
因此，RAG 2.0 相比 RAG 1.0 會複雜很多，其核心是資料庫和各種模型，需要依託一個平臺來不斷迭代和最佳化，這就是我們開發並開源 RAGFlow 的原因。它沒有采用已有的 RAG 1.0 元件，而是從整個鏈路出發來根本性地解決 LLM 搜尋系統的問題。當前，RAGFlow 仍處於初級階段，系統的每個環節，都還在不斷地進化中。由於使用了正確的方式解決正確的問題，因此自開源以來 RAGFlow 只用了不到 3 個月就獲得了 Github 萬星。當然，這只是新的起點。
RAG 2.0 將會對 LLM 在企業中如何應用產生巨大影響，我們對它作為產品推動力的發展感到振奮，如果你也對此感興趣，歡迎關注和了解我們的工作：https://github.com/infiniflow/ragflow