本文將提供從客戶問題到最終部署的應用程序的清晰路線圖，旨在簡化開發滿足人們需求的高級RAG框架的復雜過程。

引言

當今，大多數的公司主要依靠文檔開發運營工作。這或許是近年來檢索增強生成系統如此流行的原因之一。這個想法很簡單：通過向系統提示和用戶查詢提供附加信息，克服LLM當前的局限性——例如幻覺和知識截止。

于是，人們可以快速構建和部署第一個RAG應用程序原型。但是，當用戶真正與這套首個RAG系統交互時，缺陷開始顯現。RAG系統給出的答案顯得膚淺，重要的上下文信息被遺漏，檢索悄然失敗。而且，系統的性能還隨著文檔數量的增加而下降。

不過，我們最終還是可以通過制定計劃來構建、部署和增強先進的RAG應用程序，從而避免這種情況。

本文將提供從最初的客戶問題到最終部署的應用程序的清晰路線圖，從而簡化了開發滿足人們需求的高級RAG框架的復雜過程。

本文將上述整個過程劃分為10個具體步驟，從而有利于方便指導每一個RAG項目實現從構思到生產的全流程。

1. 需要解決的問題

在進行任何編程之前，我們必須問自己：實際問題是什么？我們對情況了解得越深入，就越容易找到解決方案。

這個問題理解過程的一個重要部分是確定用戶的理想或“夢想”結果是什么樣的。

明確定義問題和期望結果標志著我們路線圖的開始和結束。

解決該問題的一個可能方案是檢索增強生成（RAG）系統，該系統能夠利用外部知識增強大型語言模型。這有助于克服信息過時或領域專業知識淺薄等局限性。

然而，RAG系統引入了額外的復雜性。現在，需要開發和維護兩個獨立的組件：索引部分和生成部分。

因此，我們首先應該問：這個問題有沒有更簡單的解決方案？也許一個基本的關鍵詞搜索、一個基于規則的系統或一個常見問題解答頁面就足夠了——這些都不需要LLM。

RAG的替代方案是緩存增強生成，它將整個上下文加載到模型的內存中，從而無需完全檢索。

解決問題的方法有很多，RAG只是其中之一。不要落入“工具法則”（又稱“馬斯洛錘”）的陷阱。該法則描述的是一種認知偏差，即過度依賴熟悉的工具，即使它并非最合適的解決方案。

一位留著胡子、戴著帽子的卡通男子在一輛爆胎的汽車旁邊彈吉他唱歌，旁邊有一個對話框說：“?我的方向盤掉了，但我的精神很高?”。

此圖展示了馬斯洛錘子理論的一個幽默例子：一位音樂家坐在車旁，拿著吉他唱歌。真正的問題是爆胎了；但是，他沒有去換，而是開始寫一首關于爆胎的歌，因為寫歌是他應對任何問題的工具。

2. 為問題提供的數據

最終的RAG系統的質量取決于你輸入的文檔。

首先，我們必須確保手頭有合適的文件來解答最常見情況的問題。如果沒有足夠且最新的文件，LLM通常會給出“我不知道”的答案，或者在最糟糕的情況下，給出一個不切實際的答案。

收集完所有必需的文檔后，我們來檢查一下數據的格式和質量。它是純文本、PDF、HTML頁面、圖像，還是各種格式的混合？

從文檔中提取信息是任何RAG流程中不可避免的一步，而你的LLM答案的質量很大程度上取決于你從來源中提取內容的效率。

換句話說：輸入的是垃圾，輸出的也是垃圾。

垃圾進，垃圾出（【引文1】）

此圖展示的這幅火柴人漫畫幽默地解釋了機器學習：一個人將“數據”倒入標有“線性代數”的一堆數據中，在另一邊收集“答案”，如果答案是錯誤的，他們只需“攪拌這堆數據，直到看起來正確為止”。

結構化數據（例如數據庫或CSV文件）非常適合處理。這些格式更易于查詢，并更易于線性化為文本。

相反，非結構化數據則需要更多的處理步驟，因為信息并非以易于使用的形式提供。非結構化文檔處理流程可能包含多個步驟，具體取決于所使用的工具。我最喜歡的PDF處理工具是：

• Mistral OCR：用于快速將文檔轉換為MarkDown格式的文件。?
• Docling：一個將文檔轉換為MarkDown格式并提供額外布局信息的開源解決方案。?
• Vision LLM：你可以在其中傳遞頁面的屏幕截圖以及提取所有文本并以MarkDown格式返回的指令。半結構化數據包括部分有組織的格式，例如JSON文件或網頁——網頁尤其成為信息提取的常見來源。在這種情況下，必須首先刪除樣板內容，包括導航菜單和廣告等不相關的元素。
  你可以使用常見的網絡抓取工具（如BeautifulSoup和Scrapy）來實現此目標。
  這凸顯了一個重要的觀點：RAG并非魔法。LLM只能利用事先提供的信息。因此，擁有正確、機器可讀且清晰的格式對最終表現有著巨大的影響。

3.數據預處理

收集所需數據并選擇適當的信息提取方法后，可以設計預處理流程。

這一步至關重要，因為數據的切片和注釋方式直接影響檢索器為LLM找到的內容。

在數據預處理的設計過程中，應考慮以下幾點：

（1）分塊策略

分塊策略定義了在索引之前如何將文檔拆分成多個部分。這是必要的，因為嵌入模型和LLM都有輸入標記的限制。此外，所選的塊大小對整體系統性能有巨大的影響。

• 分塊大小（例如128個標記）提供詳細、細粒度的信息，但由于上下文丟失，可能會丟失不可或缺的內容。?
• 較大的塊大小（例如512個或更多標記）可確保保留全面的信息，但可能會降低系統速度。此外，在單個提示中組合多個長塊可能會導致上下文過長。這會使模型感到困惑——這種現象通常被稱為“迷失在中間”。
  不幸的是，沒有通用的規則來確定最佳的塊大小或策略。這些選擇很大程度上取決于數據的結構和性質。

GPT-3.5-Turbo-0613在答案位于20個文檔上下文（約4000個標記）的開頭或結尾時，準確率最高，中間部分則急劇下降，呈現出U形的位置偏差。其中的虛線表示閉卷準確率（56.1%）（【引文2】）。

此折線圖展示了準確率與包含答案的文檔在總共20篇檢索到的文檔中的位置的關系。隨著答案從第一位移動到后面的位置，準確率急劇下降，在中間位置觸底，并在接近第20位時再次上升。紅色虛線標記了閉卷考試的準確率，以便進行比較。圖例顯示了“GPT-3.5-Turbo-0613”和“GPT-3.5-Turbo-0613（閉卷）”的結果。

（2）元數據提取

每個塊可以攜帶元數據（屬性），這些元數據提供上下文信息，但不出現在正文中。例如，元數據可以包括文檔標題、作者、日期、章節名稱、來源URL等。

這些元數據對于篩選或提升最終檢索過程非常有用。它還支持訪問控制機制，允許系統確定哪些人可以訪問某些信息。

元數據可以手動提供，也可以自動派生，例如，使用命名實體識別（NER）來標記提到的產品或人員，或者對每個塊的主題進行分類。

（3）搜索方法

RAG并非只要求向量搜索。任何搜索方法都可以用來檢索相關的文本塊。常用方法包括向量搜索、關鍵字搜索和混合搜索。

• 向量搜索會嵌入查詢，并根據語義相似度找到最近的嵌入向量。它非常適合概念匹配，但在處理罕見的、特定領域的術語時可能會表現不佳。?
• 關鍵詞（詞匯）搜索通過倒排索引（例如BM25）將查詢詞與文本匹配。這種方法擅長檢索特定的技術術語或不常用的術語。?
• 混合搜索并行運行向量和關鍵字搜索，并使用倒數秩融合或線性融合等方法對結果進行重新排序以合并分數。

（4）索引和存儲

隨著RAG應用的日益普及，提供向量存儲功能的公司數量也顯著增加。由于選項眾多，我在下表中總結了其中最突出的幾個，以便你做出更好的決策。

此表總結了主流向量數據庫（包括Meta FAISS、Pinecone、Weaviate、Milvus、ChromaDB、Qdrant和Neo4j）的主要特性。表中列出了每個數據庫的常規信息、開源狀態、開發語言、算法、混合搜索、距離度量、優勢和局限性。

這里展示了當前業界領先的向量數據庫的功能比較，突出它們的優勢、支持的算法以及高效相似性搜索和人工智能應用的關鍵限制。

我個人最喜歡的是Qdrant，因為它提供了高級搜索功能，讓你可以創造性地設計檢索過程。

4.原型設計

基于“快速失敗”的原則，原型設計在RAG系統的設計過程中起著至關重要的作用。如果沒有豐富的經驗，我們很可能不知道什么可行，什么行不通。

找出答案的最佳方法是快速構建第一個原型——從Jupyter筆記本中的基本RAG應用程序開始，不斷增加復雜性以更接近所需的輸出。

這樣，我們就獲得了關注，獲得了實踐經驗，并確保如果最初的想法表現不佳或沒有滿足用戶的要求，后續的工作不會導致時間的浪費。

這些實驗可以涵蓋多個方面，具體取決于最終目標和數據源。然而，向量存儲的性能和相關性很大程度上取決于所使用的嵌入模型。

選擇合適模型的一個很好的起點是參考HuggingFase嵌入排行榜，它根據不同的指標能夠比較各種語言的文本和圖像嵌入模型。

下面給出了嵌入排行榜界面截圖，展示了多語言模型的性能。圖表繪制了任務平均得分與參數數量的關系，各種模型以綠色氣泡表示，左側為基準類型的過濾器。

HuggingFase嵌入排行榜通過性能、大小和標記容量比較了1,000多種語言和131個任務的多語言嵌入模型。

關于向量存儲，我會在原型設計階段選擇FAISS、ChromaDB或Qdrant，因為這三個數據庫都提供了方便的本地實現，使得它們非常適合在Jupyter筆記本中進行實驗。

設置初始索引原型后，你可以開始首次手動實驗，并根據用戶查詢檢索相關塊。請考慮以下幾點來手動評估結果：

• 這些塊真的與查詢相關嗎？?
• 塊大小看起來合適嗎？?
• 這些區塊的排序合理嗎？你會按照類似的順序排列它們嗎？?
• 這些塊是否提供了足夠的上下文來自信地回答查詢？?
• 頂部結果中是否存在不相關或冗余的塊？?
• 檢索到的塊在多大程度上代表了查詢中的觀點或子主題的多樣性？?
• 是否存在語義漂移的跡象，即內容與實際查詢含義略有偏差？?
• 塊中的語言是否足夠清晰且易于理解，以便進行下游處理？這種手動評估有助于在進行自動基準測試或與下游LLM集成之前改進分塊、索引和檢索策略。

5. 增強檢索過程

如果原型階段尚未完成，現在是時候根據從原型中獲得的見解來提升檢索過程了。即使是設計最精良、組織最完善的向量存儲，如果沒有能夠有效利用其豐富結構的檢索策略，也是毫無價值的。

與數據處理管道一樣，鏈條的強度取決于其最薄弱的環節——并且在許多RAG應用程序中，該薄弱環節通常是檢索過程。

如果你不確定如何進一步改進檢索過程，以下給出三個基礎型建議：

選擇不同的相似性搜索算法

許多向量數據庫使用HNSW（分層可導航小世界圖）或其他近似最近鄰（ANN）算法。你通常可以調整它們的參數，以在速度和準確性之間取得更好的平衡。

從我的角度來看，Pinecone在解釋和可視化HNSW算法方面做得非常出色，如下圖所示：

HNSW（分層可導航小世界圖，見【引文3】）

該圖展示了由箭頭連接的三層節點，展示了HNSW（分層可導航小世界）圖搜索過程。藍色“入口點”從頂層開始，向下遍歷各層，到達底層的黃色“查詢向量”及其最近鄰。

選擇不同的相似度度量

余弦相似度很常用，但并非唯一選擇。其他度量包括內積、歐氏距離和曼哈頓距離。根據你的數據和任務的不同情形，其中一種度量可能比其他度量表現更好。

集成混合搜索方法

混合搜索允許你將基于關鍵字（稀疏）的搜索與密集向量搜索相結合。許多向量數據庫（例如Qdrant）支持混合搜索，并允許你配置復雜的組合，例如其博客文章圖片中所示的組合。

此流程圖展示了兩種混合搜索流程：一種使用維度不斷增加的Matryoshka嵌入，并在每個階段重新排序；另一種使用密集、全密集和稀疏向量，在最終重新排序步驟（稱為“后期交互”）之前融合它們的結果，以選擇前10個匹配項。

在此圖展示的Qdrant混合搜索流程的示例中，該流程將密集和稀疏向量檢索與多階段重排序相結合，以獲得最佳搜索結果（【引文4】）。

添加業務邏輯

這是一個廣泛的概念，指的是定制檢索以更好地適合你的領域或用戶的期望。

例如，你可能會提升某些類型的內容：如果你知道官方政策文件比Slack消息更值得信賴，那么你可以為來自“政策”文檔的任何塊分配更高的分數。

此外，許多向量數據庫允許你按元數據（例如創建時間或其他上下文）進行篩選。這允許你將新近度和特定領域的篩選納入檢索過程。

用于重新排序的交叉編碼器

交叉編碼器將查詢和單個文檔一起作為輸入，并直接輸出相關性分數。

交叉編碼器通常能更準確地進行排名，因為它們能捕捉查詢和文檔之間的微妙關系。然而，由于必須對每個文檔進行單獨評估，因此速度較慢。

下面的示意流程鏈接了一個圖片和網頁，完美地概括了雙編碼器和交叉編碼器之間的區別。

雙編碼器與交叉編碼器的比較（【引文5】）

這張圖比較了雙編碼器和交叉編碼器。雙編碼器通過BERT和池化分別處理兩個句子，然后測量相似度；交叉編碼器通過BERT和分類器同時處理兩個句子，以獲得相關性分數。

然而，面對所有這些可能性，人們很容易過度設計。在這種情況下，我始終牢記一個原則：保持簡單，簡潔（KISS）。整個框架應該盡可能簡單——并且只在必要時才考慮復雜性。

順便說一句，如果你決定使用自定義或開源模型進行嵌入、重新排序，甚至將其作為LLM而不是完全托管的服務，歡迎來到MLOps的世界！

除了設計和維護實際的RAG框架之外，還必須部署、監控和持續更新這些模型。

如果你希望避免這些額外的運營開銷，不妨從托管服務入手，快速實現創新。最終，這始終還是要在控制力和便捷性之間進行權衡。

6. LLM答案生成

從數據源檢索到最相關的文檔后，我們將重點轉移到RAG的生成部分。這一步驟旨在設計LLM如何使用檢索到的信息來生成有用、正確且安全的響應。

LLM類型繁多，各有優缺點。申請LLM類型時，應考慮以下幾點：

• 開放式或封閉式模型?
• 自行部署（本地）或基于API的訪問?
• 推理延遲（生成響應的速度）?
• 推理成本（例如，計算要求或API定價）?
• 上下文窗口大小（模型一次可以處理多少信息）?
• 多模式功能（文本、圖像、音頻等）?
• 與你的領域相關的基準模型性能?
• 安全、隱私和數據駐留合規性?
• 許可條款（商業用途與研究用途）?選擇合適的LLM與選擇合適的提示設計同樣重要，尤其是系統提示，它定義了模型的預期行為。一個好的系統提示遠不止為LLM賦予一個角色，例如“你是……方面的專家”。已發布的Claude系統提示就證明了這一點，它涵蓋了超過24,000個詞條（【引文6】）。
  因此，非常值得投入時間和精力進行提示工程，并根據你所在領域的特定挑戰定制提示（及其示例）。?
  此外，一些應用程序可能需要實施“護欄”——檢查和約束LLM的輸出以防止不良行為。?
  這些“護欄”可以通過簡單的基于提示的指令來實現，例如：“你不得生成有關以下主題的答案......”。?
  對于更高級的“護欄”，可能需要額外的工具，例如：?
• Guardrails AI
• Rebuff
• NeMo Guardrails
• LMQL（語言模型查詢語言）?與護欄密切相關的另一個問題是幻覺，即LLM生成不正確或虛構的內容（與護欄情況下的不適當內容相反）。
  不幸的是，RAG框架并不能完全消除幻覺，但可以通過以下策略來緩解：?
• CRITIC：大型語言模型可通過工具交互批評進行自我糾正（【引文7】）?
• 基于文檔信息來源頁面的視覺基礎，例如使用Docling（【引文8】）?
• 亞馬遜的Bedrock幻覺檢查語境基礎（【引文9】）?
• Uqlm：語言模型的不確定性量化（【引文10】）此外，請為LLM調用實現超時和回退機制。沒有什么比你的應用因為模型運行時間過長而掛起更糟糕的了。如果遇到超時或錯誤，你可以向用戶返回一條友好的消息（“抱歉，我現在遇到問題，請重試”），而不是崩潰。

7.評估

目前為止，我們僅對中間步驟和結果進行了人工檢查。然而，為了獲得更深入的洞察，我們需要進行更全面、更準確的評估。

在其他軟件項目中，單元測試通常在這一階段編寫。然而，對于RAG開發來說，事情有點棘手。

評估步驟從組裝“黃金數據集”開始，其中包括你的系統應該能夠處理的一組示例問題及其正確答案。

構建這樣的數據集本身就是一種挑戰，并且極大地受益于領域專家和最終用戶之間的對話。

最后，每個問題都與一個基本事實信息源相關聯。例如，如果可能的話，問題X應該由文檔Y第2部分來回答。

RAG框架的整體評估是不同指標和工具的混合。

例如，信息檢索（IR）指標衡量檢索器獲取相關信息的效果。這一過程常見指標包括：

• Recall@K，是指正確答案塊位于檢索到的前K個答案塊中的查詢的百分比。?
• MRR（平均倒數排名），查看每個查詢的第一個相關結果的排名（MRR越高意味著相關文檔平均出現的位置越高）。?另一方面，生成評估是一項更為艱巨的任務，因為評估自由格式文本的質量具有主觀性。有一種方法是人工評估，它被認為是黃金標準，但可擴展性較差。
  一個自動化的替代方案是LLM-as-a-judge。該技術使用大型語言模型對答案進行評分，有效地將評估工作外包給了人工智能（見【引文11】）。?
  有一個非常方便的用于增強生成評估的開源工具包是RAGAS，我建議你好好熟悉一下這個工具。這個工具還使用底層的LLM來評估以下標準：?
• 忠誠度：答案是否忠實于來源？?
• 相關性：答案是否解答了問題？?
• 上下文精度：檢索到的信息中有多少部分被實際使用？因此，RAGAS可以被視為RAG應用程序的一種單元測試框架。

8.改進和實驗

基于評估過程中獲得的洞察，RAG框架可以得到進一步增強。此階段遵循一個迭代循環：實驗→評估→改進→重復。

這一步不是要增加隨機的復雜性，而是要進行明智的實驗。

以下是一些值得嘗試的領域：

• 分塊策略：過去，人們探索了許多分塊策略，例如基于大小的分塊、語義分塊、混合分塊、重疊分塊或分層分塊。后者對于需要理解文檔語料庫中更廣泛背景的答案生成任務特別有用。
  在分層分塊中，文檔被拆分成多個粒度的塊，以反映內容的自然結構（例如章節、段落和句子），而不是僅僅依賴于固定大小的標記窗口。如果文檔已轉換為MarkDown格式，則此方法效果最佳。
  然而，原始文本也可以進行分層分塊，正如RAPTOR所展示的那樣，它使用自下而上的方法構建了更高級別摘要的樹。
  下圖展示了RAPTOR樹的分層分塊方法。文檔被聚類到葉節點，由更高級別的LLM進行匯總，每個節點存儲其索引、子節點、摘要文本和嵌入。

RAPTOR樹展示：分層分塊逐層聚類和匯總文本塊，構建結構化樹，以實現高效的文檔理解和檢索（【引文12】）

• 提示結構：測試不同的提示公式、少量示例或單獨的檢索和推理步驟（又名ReAct提示）。?
• 檢索參數：調整top_k、重新排序閾值或元數據過濾器。?
• 嵌入模型：將嵌入模型替換為針對你的領域或語言優化的模型。如果沒有特定領域的嵌入模型，你可能需要自行微調。不過，在執行此操作之前，請考慮使用混合搜索來完成特定領域的任務，因為它可以更好地處理特定領域的關鍵詞。在實驗和調整流水線的各個部分時，很容易迷失方向并失去對性能的關注。此時，Git等版本控制系統便會展現出其真正的優勢；如果一開始沒有使用這樣的系統的話，那么應該好好使用。這些實驗最好在單獨的分支中進行管理，理想情況下每個版本都有一個專用的分支。
  在這個階段，由于存在大量的可能性，人們很容易盲目地進行優化。
  明確的假設和預先定義的可衡量結果有助于集中精力于應用程序想要解決的實際目標。

9. RAG框架的部署

到目前為止，我們大多數人只在本地完成了開發。現在，到了一個重要的步驟：在生產基礎設施中部署RAG系統。

這一步涉及軟件工程和DevOps，以確保你的管道在現實世界中穩定、可擴展且可維護。

這通常需要：

• 檢索管道和LLM交互的后端托管（例如，Flask、FastAPI或LangChain Server）。?
• 前端集成，如果用戶將通過網絡應用程序或聊天機器人界面進行交互。?
• 模型服務基礎設施，尤其是通過Docker、TorchServe或推理端點使用本地或微調模型時。?
• 你的向量數據庫（例如Qdrant、Pinecone或Weaviate）以及任何文檔提取管道的持久存儲。?
• 可觀察性和日志記錄，用于跟蹤查詢負載、錯誤、延遲和系統健康狀況。該領域的常用工具包括Prometheus和Grafana。?

所有上述這些觀點其實都只是觸及了AI應用程序部署的表面，這至少與RAG框架本身的開發一樣是一個廣泛的話題，因此值得專門寫一篇文章來探討。

如果你不知道從哪里開始，那么在Hugging Face Spaces上部署和分享你的第一批成果將會給你帶來一個快速的勝利體驗，并允許你收集初步反饋。

下一步，Google Firebase可能會成為你的一個不錯的選擇，因為它可以為你自動處理后端。

10.持續改進的反饋循環

然而，在應用程序開發、測試和部署之后，RAG框架并不完整。

在收集初步用戶反饋后——無論上一步選擇了哪種部署方法——都必須不斷整合這些反饋，以便更好地滿足用戶的需求。

這使得RAG與許多軟件應用程序一樣，不再是一個靜態產品，而是一個不斷發展的服務。

總結

本文描述的10個步驟強調了構建高級RAG應用程序不僅僅是檢索幾個相關的上下文塊的問題。這是一項必須根據特定領域及其獨特要求進行定制的服務——強調沒有一刀切的解決方案。這是因為文檔類型多樣，并且每個領域都有不同的特定需求。

通過遵循本文概述的10個步驟，在開發RAG應用時，人們可以從基本原型轉變為可以投入生產的服務，從而以可靠、可擴展和智能的方式真正幫助終端用戶。

參考文獻

【1】9GAG，??https://9gag.com/gag/apGYd0E??

【2】迷失在中間：語言模型如何使用長上下文，??https://arxiv.org/abs/2307.03172??

【3】Pinecone分層可導航小世界（HNSW），??https://www.pinecone.io/learn/series/faiss/hnsw/??

【4】混合搜索改版，??https://qdrant.tech/articles/hybrid-search/??

【5】交叉編碼器與雙編碼器， https://sbert.net/examples/cross_encoder/applications/README.html

【6】人類系統提示， https://docs.anthropic.com/en/release-notes/system-prompts#may-22th-2025

【7】CRITIC：大型語言模型可以通過工具交互批評進行自我糾正，??https://arxiv.org/abs/2305.11738??

【8】docling， https://docling-project.github.io/docling/examples/visual_grounding/#rag

【9】亞馬遜Bedrock， https://aws.amazon.com/de/blogs/aws/guardrails-for-amazon-bedrock-can-now-detect-hallucinations-and-safeguard-apps-built-using-custom-or-third-party-fms/

【10】uqlm：語言模型的不確定性量化，??https://cvs-health.github.io/uqlm/latest/index.html??

【11】使用MT-Bench和Chatbot Arena評LLM（LLM-as-a-Judge），??https://arxiv.org/abs/2306.05685??

【12】RAPTOR：面向樹狀檢索的遞歸抽象處理，??https://arxiv.org/html/2401.18059v1??

譯者介紹

朱先忠，51CTO社區編輯，51CTO專家博客、講師，濰坊一所高校計算機教師，自由編程界老兵一枚。

原文標題：??From Prototype to Production: A 10-Step Guide to Building Advanced RAG Applications??，作者：Felix Pappe