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

引言

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

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

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

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

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

1. 需要解決的問題

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

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

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

解決該問題的一個可能方案是檢索增強生成（RAG）系統(tǒng)，該系統(tǒng)能夠利用外部知識增強大型語言模型。這有助于克服信息過時或領(lǐng)域?qū)I(yè)知識淺薄等局限性。

然而，RAG系統(tǒng)引入了額外的復雜性。現(xiàn)在，需要開發(fā)和維護兩個獨立的組件：索引部分和生成部分。

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

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

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

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

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

2. 為問題提供的數(shù)據(jù)

最終的RAG系統(tǒng)的質(zhì)量取決于你輸入的文檔。

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

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

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

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

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

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

結(jié)構(gòu)化數(shù)據(jù)（例如數(shù)據(jù)庫或CSV文件）非常適合處理。這些格式更易于查詢，并更易于線性化為文本。

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

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

3.數(shù)據(jù)預處理

收集所需數(shù)據(jù)并選擇適當?shù)男畔⑻崛》椒ê?，可以設(shè)計預處理流程。

這一步至關(guān)重要，因為數(shù)據(jù)的切片和注釋方式直接影響檢索器為LLM找到的內(nèi)容。

在數(shù)據(jù)預處理的設(shè)計過程中，應考慮以下幾點：

（1）分塊策略

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

• 分塊大?。ɡ?28個標記）提供詳細、細粒度的信息，但由于上下文丟失，可能會丟失不可或缺的內(nèi)容。?
• 較大的塊大?。ɡ?12個或更多標記）可確保保留全面的信息，但可能會降低系統(tǒng)速度。此外，在單個提示中組合多個長塊可能會導致上下文過長。這會使模型感到困惑——這種現(xiàn)象通常被稱為“迷失在中間”。
  不幸的是，沒有通用的規(guī)則來確定最佳的塊大小或策略。這些選擇很大程度上取決于數(shù)據(jù)的結(jié)構(gòu)和性質(zhì)。

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

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

（2）元數(shù)據(jù)提取

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

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

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

（3）搜索方法

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

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

（4）索引和存儲

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

此表總結(jié)了主流向量數(shù)據(jù)庫（包括Meta FAISS、Pinecone、Weaviate、Milvus、ChromaDB、Qdrant和Neo4j）的主要特性。表中列出了每個數(shù)據(jù)庫的常規(guī)信息、開源狀態(tài)、開發(fā)語言、算法、混合搜索、距離度量、優(yōu)勢和局限性。

這里展示了當前業(yè)界領(lǐng)先的向量數(shù)據(jù)庫的功能比較，突出它們的優(yōu)勢、支持的算法以及高效相似性搜索和人工智能應用的關(guān)鍵限制。

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

4.原型設(shè)計

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

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

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

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

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

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

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

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

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

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

5. 增強檢索過程

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

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

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

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

許多向量數(shù)據(jù)庫使用HNSW（分層可導航小世界圖）或其他近似最近鄰（ANN）算法。你通?？梢哉{(diào)整它們的參數(shù)，以在速度和準確性之間取得更好的平衡。

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

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

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

選擇不同的相似度度量

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

集成混合搜索方法

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

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

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

添加業(yè)務(wù)邏輯

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

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

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

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

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

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

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

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

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

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

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

除了設(shè)計和維護實際的RAG框架之外，還必須部署、監(jiān)控和持續(xù)更新這些模型。

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

6. LLM答案生成

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

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

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

7.評估

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

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

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

構(gòu)建這樣的數(shù)據(jù)集本身就是一種挑戰(zhàn)，并且極大地受益于領(lǐng)域?qū)＜液妥罱K用戶之間的對話。

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

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

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

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

8.改進和實驗

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

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

以下是一些值得嘗試的領(lǐng)域：

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

RAPTOR樹展示：分層分塊逐層聚類和匯總文本塊，構(gòu)建結(jié)構(gòu)化樹，以實現(xiàn)高效的文檔理解和檢索（【引文12】）

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

9. RAG框架的部署

到目前為止，我們大多數(shù)人只在本地完成了開發(fā)?，F(xiàn)在，到了一個重要的步驟：在生產(chǎn)基礎(chǔ)設(shè)施中部署RAG系統(tǒng)。

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

這通常需要：

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

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

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

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

10.持續(xù)改進的反饋循環(huán)

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

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

這使得RAG與許多軟件應用程序一樣，不再是一個靜態(tài)產(chǎn)品，而是一個不斷發(fā)展的服務(wù)。

總結(jié)

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

通過遵循本文概述的10個步驟，在開發(fā)RAG應用時，人們可以從基本原型轉(zhuǎn)變?yōu)榭梢酝度肷a(chǎn)的服務(wù)，從而以可靠、可擴展和智能的方式真正幫助終端用戶。

參考文獻

【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】人類系統(tǒng)提示， 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社區(qū)編輯，51CTO專家博客、講師，濰坊一所高校計算機教師，自由編程界老兵一枚。

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