端到端RAG工作流：檢索增強生成的工作原理

檢索增強生成（Retrieval Augmented Generation，RAG）是一種人工智能架構模式，它在推理時將大語言模型與外部知識源連接起來，使模型能夠生成超越其靜態訓練數據的準確、上下文感知的響應。RAG系統不是依賴預訓練期間編碼的知識，而是針對每個用户查詢從外部數據庫中檢索相關文檔，並將這些內容注入到生成前的LLM提示中。結果是生成式AI系統能夠基於經過驗證的來源產生準確、特定領域的答案，而無需在底層知識發生變化時重新訓練整個模型。

LLM常常因知識截止日期而提供過時的答案，並且無法訪問專有的內部文檔或實時的外部數據源。RAG直接解決了這一限制。超過60%的組織正在積極開發基於AI的檢索工具，這反映了從僅依賴模型記憶到動態連接AI與包含內部文檔、產品文檔和當前數據的實時知識庫的根本轉變。

本指南將介紹完整的RAG工作流——從架構組件和數據攝入到混合檢索、提示設計、評估和部署——併為構建生產級RAG管道的團隊提供實用指導。

RAG架構的關鍵組件

RAG系統包含四個主要組件：存儲外部知識的知識庫、為每個查詢找到相關文檔的信息檢索組件（檢索器）、將檢索到的上下文組裝成LLM提示的集成層，以及生成最終響應的生成器（LLM）。每個組件都可以獨立優化，整個管道的質量受限於最薄弱的環節——高質量的LLM無法彌補持續檢索不相關文檔的檢索器。

檢索器和向量數據庫

檢索器接收用户查詢，將其轉換為可比較的表示形式，並從知識庫返回最相關的文檔。檢索器質量是RAG輸出質量的單一最大決定因素。向量數據庫存儲文檔塊的數值表示——稱為嵌入——從而支持大規模快速相似性搜索。與基於精確值匹配的關係數據庫不同，向量數據庫使用餘弦相似度等距離度量來查找語義上與查詢最接近的文檔。

生成器和編排層

生成器是接收增強後提示（用户原始問題與檢索上下文相結合）並生成最終響應的大語言模型。編排層將所有組件連接成一個連貫的RAG管道，處理提示組裝、對話歷史和錯誤處理。LangChain和LlamaIndex等框架提供了常見的編排原語，而Databricks等平台則為全棧提供託管基礎設施。

數據源和外部知識

RAG系統的有效數據源範圍很廣：關係表中的結構化數據、PDF和Markdown文件中的非結構化文本、內部文檔（如工程手冊和HR政策）、產品文檔以及外部知識庫。領域特定數據——即直接與用户可能提出的問題相關的內容——應首先攝入並最仔細維護。內部數據，包括專有研究和內部文檔，在RAG實現中能產生最具防禦性的優勢，因為這些知識是任何公共LLM都未曾訓練過的。

選擇數據源時的實際問題在於相關性密度：索引文檔中實際能在響應真實查詢時被檢索到的比例。高相關性源能證明嵌入和索引的計算和財務成本是合理的；低相關性源則會增加檢索器必須過濾的噪聲，從而降低檢索質量。

多個數據源可以合併到一個RAG系統中——例如，將產品文檔庫與實時客户數據庫配對——只要攝入管道將每個源歸一化為一致的文本格式。團隊應記錄每個索引源的數據血緣，以便任何檢索文檔的起源都能追溯到其權威來源，從而在受監管行業中實現審計和合規工作流。

嵌入模型和向量存儲

選擇嵌入模型

嵌入模型是一種專門的語言模型，它將文本轉換為數值表示——高維向量，這些向量編碼語義含義。當用户提交查詢時，相同的嵌入模型將該用户輸入轉換為可比較的向量，從而能夠在查詢與所有存儲的文檔嵌入之間進行數學比較。攝入時使用的嵌入模型必須與查詢時使用的完全相同。

模型選擇涉及表示質量、向量維度、推理延遲和財務成本之間的權衡。通用模型如bge-large-en生成1024維向量，可在多種領域使用。針對技術文本微調的領域特定嵌入模型通常在狹窄的檢索任務中優於通用模型。嵌入模型將原始文本轉換為使向量相似性搜索成為可能的數值表示。

嵌入模型還可以根據其處理與待檢索文檔措辭不同的查詢的能力進行評估——這種屬性稱為跨語言或釋義魯棒性。在企業環境中，用户以對話方式提問而文檔以正式方式撰寫時，這種語義橋樑至關重要。在提交生產索引運行之前，使用代表性樣本的真實用户查詢測試嵌入模型，可以防止後續對整個語料庫進行代價高昂的重新嵌入。

分塊策略和索引

大型文檔在嵌入前必須分割成較小的塊，因為嵌入模型的上下文窗口有限，且較小的塊能提供更精確的檢索。塊大小直接影響輸出質量：塊太小會丟失周圍上下文，塊太大會稀釋與用户問題最相關的特定段落。常見策略包括按令牌數量進行固定大小分割，以及帶有重疊邊界的句子邊界分割，以減少關鍵上下文落在邊界上的風險。

嵌入後，向量被存儲並在向量存儲中建立索引。使用HNSW等算法的向量索引對嵌入進行組織，以實現大規模近似最近鄰搜索，將檢索從對所有嵌入的線性掃描減少到亞毫秒級查找。

信息檢索與混合搜索

語義搜索——大多數RAG系統的支柱——找到與用户查詢含義最接近的文檔，自然處理改述和同義詞。Databricks AI Search實現了語義向量搜索，並自動從Delta表同步，使知識庫無需手動重新索引即可反映新數據。

純語義搜索在精確匹配查詢方面存在已知弱點：特定錯誤代碼、版本號或命名實體。混合搜索通過結合語義向量搜索和BM25關鍵詞搜索（一種在精確和罕見詞匹配方面表現出色的概率詞頻模型）來解決此問題。並行運行兩個搜索路徑，並使用倒數排名融合合併結果，可在更廣泛的查詢分佈上提高檢索效率。

一個重排序步驟可以進一步改善結果：使用交叉編碼器模型根據查詢對每個檢索到的文檔進行評分，並重新排序結果，使最相關的文檔排在前面。諸如重排序之類的檢索方法能顯著提高精度，並且在LLM上下文窗口限制可傳遞給生成器的文檔數量時尤為有價值。

相似性閾值增加了最終質量門控：相關性分數低於最低截止值的文檔應被完全過濾掉，而不是作為低質量上下文傳遞給生成器。傳遞不相關的上下文比不傳遞上下文更糟糕——它會消耗上下文窗口，並增加LLM在生成響應中將正確與錯誤信息混合的風險。設置保守閾值並隨時間監控過濾率是一種無需架構更改即可維持檢索質量的直接方法。

RAG如何工作：從攝入到生成

RAG工作流遵循五個連續階段，將用户的問題轉化為基於事實的準確響應。

階段1：攝入並歸一化外部數據

RAG管道從數據攝入開始。原始文檔被加載到ETL管道中，該管道清理和歸一化文本——刪除樣板文件、標準化空白、從表格和代碼中提取結構化內容。數據湖倉架構在統一治理下集中攝入結構化和非結構化內容，使其成為RAG知識庫的自然基礎。

階段2：分塊、嵌入和索引

清理後的文檔被分割成塊，每個塊通過嵌入模型生成向量，結果嵌入連同原始文本和元數據（文檔標題、日期、來源URL）寫入向量存儲。元數據支持過濾檢索——限定結果僅包含特定日期範圍內或特定用户角色可訪問的文檔。RAG需要持續更新以保持數據相關性；生產系統需要自動化管道，檢測更新後的源文檔並按計劃或事件驅動觸發重新嵌入。

階段3：檢索相關文檔

當用户提交查詢時，RAG系統使用相同的嵌入模型將用户輸入轉換為向量表示，並查詢向量存儲，執行相似性搜索，返回最相關的top-k個文檔塊。k值——檢索多少個塊——需要在檢索覆蓋率和上下文窗口消耗之間權衡，並且必須針對目標LLM進行調優。

階段4：增強LLM提示

檢索到的文檔被組裝成增強後的提示。典型結構首先放置系統指令（“僅根據提供的上下文回答用户問題。如果在上下文中找不到答案，請説出來。”），然後是檢索到的文本塊，最後是用户的原始問題。將最相關的文檔放在前面有助於提高注意力，特別是對於容易受到“中間迷失”現象影響的模型，該現象中靠近開頭和結尾的上下文比中間內容獲得更多關注。

階段5：生成最終響應

生成器接收增強後的提示併產生最終響應。後處理可以進一步優化輸出，例如格式化或添加引用。一個生產級RAG系統還必須包含反饋循環，收集用户對響應的評價以持續改進檢索和生成質量。

通過遵循這個端到端工作流，組織可以構建不僅準確而且可解釋、可信且易於更新的AI系統，充分利用實時知識的全部力量，而無需承受持續重新訓練模型的負擔。