十步構(gòu)建智能應(yīng)用：RAG從原型到生產(chǎn)的全鏈路解析

作者：朱先忠 2025-07-07 08:27:22

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

譯者 | 朱先忠

審校 | 重樓

摘要：本文將提供從客戶問(wèn)題到最終部署的應(yīng)用程序的清晰路線圖，旨在簡(jiǎn)化開(kāi)發(fā)滿足人們需求的高級(jí)RAG框架的復(fù)雜過(guò)程。

引言

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

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

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

本文將提供從最初的客戶問(wèn)題到最終部署的應(yīng)用程序的清晰路線圖，從而簡(jiǎn)化了開(kāi)發(fā)滿足人們需求的高級(jí)RAG框架的復(fù)雜過(guò)程。

1. 需要解決的問(wèn)題

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

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

明確定義問(wèn)題和期望結(jié)果標(biāo)志著我們路線圖的開(kāi)始和結(jié)束。

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

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

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

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

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

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

此圖展示了馬斯洛錘子理論的一個(gè)幽默例子：一位音樂(lè)家坐在車旁，拿著吉他唱歌。真正的問(wèn)題是爆胎了；但是，他沒(méi)有去換，而是開(kāi)始寫一首關(guān)于爆胎的歌，因?yàn)閷懜枋撬麘?yīng)對(duì)任何問(wèn)題的工具。

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

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

首先，我們必須確保手頭有合適的文件來(lái)解答最常見(jiàn)情況的問(wèn)題。如果沒(méi)有足夠且最新的文件，LLM通常會(huì)給出“我不知道”的答案，或者在最糟糕的情況下，給出一個(gè)不切實(shí)際的答案。

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

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

換句話說(shuō)：輸入的是垃圾，輸出的也是垃圾。

垃圾進(jìn)，垃圾出（【引文1】）

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

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

相反，非結(jié)構(gòu)化數(shù)據(jù)則需要更多的處理步驟，因?yàn)樾畔⒉⒎且砸子谑褂玫男问教峁?。非結(jié)構(gòu)化文檔處理流程可能包含多個(gè)步驟，具體取決于所使用的工具。我最喜歡的PDF處理工具是：

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

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

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

這一步至關(guān)重要，因?yàn)閿?shù)據(jù)的切片和注釋方式直接影響檢索器為L(zhǎng)LM找到的內(nèi)容。

在數(shù)據(jù)預(yù)處理的設(shè)計(jì)過(guò)程中，應(yīng)考慮以下幾點(diǎn)：

（1）分塊策略

分塊策略定義了在索引之前如何將文檔拆分成多個(gè)部分。這是必要的，因?yàn)榍度肽Ｐ秃蚅LM都有輸入標(biāo)記的限制。此外，所選的塊大小對(duì)整體系統(tǒng)性能有巨大的影響。

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

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

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

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

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

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

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

（3）搜索方法

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

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

（4）索引和存儲(chǔ)

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

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

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

我個(gè)人最喜歡的是Qdrant，因?yàn)樗峁┝烁呒?jí)搜索功能，讓你可以創(chuàng)造性地設(shè)計(jì)檢索過(guò)程。

4.原型設(shè)計(jì)

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

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

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

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

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

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

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

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

設(shè)置初始索引原型后，你可以開(kāi)始首次手動(dòng)實(shí)驗(yàn)，并根據(jù)用戶查詢檢索相關(guān)塊。請(qǐng)考慮以下幾點(diǎn)來(lái)手動(dòng)評(píng)估結(jié)果：

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

5. 增強(qiáng)檢索過(guò)程

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

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

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

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

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

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

HNSW（分層可導(dǎo)航小世界圖，見(jiàn)【引文3】）

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

選擇不同的相似度度量

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

集成混合搜索方法

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

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

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

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

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

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

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

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

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

交叉編碼器通常能更準(zhǔn)確地進(jìn)行排名，因?yàn)樗鼈兡懿蹲讲樵兒臀臋n之間的微妙關(guān)系。然而，由于必須對(duì)每個(gè)文檔進(jìn)行單獨(dú)評(píng)估，因此速度較慢。

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

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

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

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

順便說(shuō)一句，如果你決定使用自定義或開(kāi)源模型進(jìn)行嵌入、重新排序，甚至將其作為L(zhǎng)LM而不是完全托管的服務(wù)，歡迎來(lái)到MLOps的世界！

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

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

6. LLM答案生成

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

LLM類型繁多，各有優(yōu)缺點(diǎn)。申請(qǐng)LLM類型時(shí)，應(yīng)考慮以下幾點(diǎn)：

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

7.評(píng)估

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

在其他軟件項(xiàng)目中，單元測(cè)試通常在這一階段編寫。然而，對(duì)于RAG開(kāi)發(fā)來(lái)說(shuō)，事情有點(diǎn)棘手。

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

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

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

RAG框架的整體評(píng)估是不同指標(biāo)和工具的混合。

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

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

8.改進(jìn)和實(shí)驗(yàn)

基于評(píng)估過(guò)程中獲得的洞察，RAG框架可以得到進(jìn)一步增強(qiáng)。此階段遵循一個(gè)迭代循環(huán)：實(shí)驗(yàn)→評(píng)估→改進(jìn)→重復(fù)。

這一步不是要增加隨機(jī)的復(fù)雜性，而是要進(jìn)行明智的實(shí)驗(yàn)。

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

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

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

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

9. RAG框架的部署

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

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

這通常需要：

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

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

如果你不知道從哪里開(kāi)始，那么在Hugging Face Spaces上部署和分享你的第一批成果將會(huì)給你帶來(lái)一個(gè)快速的勝利體驗(yàn)，并允許你收集初步反饋。

下一步，Google Firebase可能會(huì)成為你的一個(gè)不錯(cuò)的選擇，因?yàn)樗梢詾槟阕詣?dòng)處理后端。

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

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

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

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

總結(jié)

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

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

參考文獻(xiàn)

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

【2】迷失在中間：語(yǔ)言模型如何使用長(zhǎng)上下文，https://arxiv.org/abs/2307.03172

【3】Pinecone分層可導(dǎo)航小世界（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：大型語(yǔ)言模型可以通過(guò)工具交互批評(píng)進(jìn)行自我糾正，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：語(yǔ)言模型的不確定性量化，https://cvs-health.github.io/uqlm/latest/index.html

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

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