端到端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系統，充分利用即時知識的全部力量，而無需承受持續重新訓練模型的負擔。