AI 原生开放教材

外观

Easy-Vibe（Datawhale：从零做出真实产品）课时教程·中英混排原文 ↗原件 ↓仓库 ↗

8. 檢索增強與知識層（Retrieval & Knowledge） ​

在前面的視覺與理解層中，模型主要依賴“自身參數裡學到的知識”來理解和生成內容。但在真實業務裡，很多問題並不能只靠“記憶”解決：企業內部制度每天在變、法規和行業標準持續更新、某個客戶的歷史記錄只存在於內部數據庫。這時，僅靠模型“背過”的知識遠遠不夠，更關鍵的是能否在 外部知識庫、結構化數據和圖譜上進行高效檢索與推理 。

可以把這一層理解為：在模型能力之上，再加一層“會查資料、會用數據庫的外腦”。當用戶提出問題時，系統不再直接生成答案，而是先去合適的數據源裡“翻資料”：文檔庫、數據庫、搜索引擎、知識圖譜、日誌與業務系統……然後再讓模型基於真實檢索到的內容來給出回答與決策。這樣不僅能顯著提升準確性和時效性，還能在很大程度上提升可解釋性和合規性（例如可引用出處、保留執行 SQL 記錄等）。

圍繞這一層，常見能力大致可以分為兩個方向：一是 檢索增強生成（RAG） ，主要面向“自然語言問答 + 文檔/知識庫檢索”；二是 結構化數據與知識圖譜（Structured Data & KG） ，負責對數據庫、圖數據庫和領域知識中臺進行更精準、可控的訪問與推理。下面分別展開。

8.1 檢索增強生成（RAG） ​

RAG（Retrieval‑Augmented Generation）可以看作是“會查資料的 LLM”。與純粹依賴模型內部參數不同，RAG 在回答每一個問題前，都會先去外部知識庫做檢索，把與問題最相關的若干段文檔片段（chunk）找出來，然後再把這些檢索到的內容作為“上下文”餵給 LLM，讓它在“看過資料”的基礎上生成答案。對於企業知識庫問答、行業報告搜索、法律/醫療/金融專業問答、內部文檔搜索機器人等場景，RAG 已經成為默認範式。

在系統架構上，典型 RAG 可以拆解為三層： 索引構建層、檢索層、生成層 。前兩層主要是“查得準”，後一層則負責“說得清”。下面從這三層來展開，並在二級小節中進一步細化核心設計與實踐。

  • 場景
    • 企業內部知識問答：員工用自然語言提問制度流程、技術文檔、項目資料，系統基於內部文檔與 Wiki 檢索相關內容後，由 LLM 生成清晰回答並附帶引用。
    • 行業報告與研究搜索：在大量 PDF、報告和論文中檢索某個行業問題的相關內容（如“新能源車補貼政策變化”），並自動總結、對比和列出處。
    • 法律 / 醫療 / 金融領域問答：基於法規條文、判決文書、臨床指南、產品說明書等權威材料進行檢索增強，降低“胡編亂造”的風險。
    • 內部文檔 / 工單搜索機器人：幫助運營、客服、研發快速在知識庫、工單和變更記錄中定位答案，並以自然語言總結結果。
  • 原理 RAG 的核心思想是把“知識存貯在外部，推理交給模型”：
    • 將非結構化文檔（PDF、網頁、Word、技術文檔等）拆成適合檢索的文檔塊（chunk），用 Embedding 模型將其映射到向量空間，並構建向量索引（如 FAISS、Milvus、PGVector 等）。
    • 在用戶查詢時，同時利用語義向量檢索與關鍵詞檢索（Hybrid Search），找到與問題最相關的若干文檔塊，並根據相關性和覆蓋度做重排序（Re‑ranking）。
    • 將檢索到的上下文、用戶提問、以及必要的系統指令/格式約束一起輸入 LLM，由模型在“可見證據”的約束下進行回答，並在輸出中引用出處（source citation），以提升可解釋性和可審計性。
  • 模型 典型 RAG 系統往往是一個 模型組合架構 ：
    • Embedding 模型：用於將查詢和文檔塊編碼到同一個語義空間，是向量檢索效果的關鍵（包括通用 Embedding 和領域定製 Embedding）。
    • 檢索與重排模型：Hybrid Search（如 BM25 + Vector）負責第一輪召回，Cross‑Encoder Re‑ranker 或 LLM 本身用於對召回結果做更精細的重排序。
    • 生成模型：LLM 在給定檢索上下文的前提下進行回答；在更復雜的 RAG / HyDE / ReAct + RAG 中，LLM 還會參與“偽文檔生成”“多輪工具調用”“思考 + 檢索交替”等過程，以提高召回、減少遺忘和增強推理能力。

8.1.1 索引構建與知識資產整理 ​

在任何 RAG 系統中，索引構建都是基礎。沒有高質量的索引，後續再強大的 LLM 也只是“巧婦難為無米之炊”。索引構建的目標，是把雜亂無章的文檔資源轉化為“可檢索、可維護、可擴展的知識資產”。

從流程上看，典型索引構建包括以下幾個關鍵步驟：

  1. 文檔分塊與預處理 文檔往往是長篇 PDF、PPT、Word 或網頁，如果直接對整篇文檔做向量化，既容易造成“稀釋”（一篇文檔包含多個主題），也不利於高效檢索。因此需要：
    1. 按段落、標題、頁碼、章節結構進行分塊，平衡“語義完整度”和“塊大小”；
    2. 處理格式問題（表格、公式、圖片中的文字 OCR）、去噪（頁眉頁腳、目錄、版權信息等）；
    3. 為每個塊生成“上下文標籤”（如所屬文檔、章節標題、頁碼），為後續解釋與引用做好準備。
  2. Embedding 與向量索引 在分塊基礎上，對每個文檔塊生成語義向量：
    1. 選擇合適的 Embedding 模型（如通用語義 Embedding、領域微調模型），確保對目標語言和領域術語有良好表達能力；
    2. 使用 FAISS、Milvus、PGVector 等構建高維向量索引，支持大規模數據下的近似最近鄰檢索；
    3. 處理多版本與增量更新：當文檔更新時，需要支持增量重建索引、版本記錄和舊版本清理策略。
  3. 元信息索引與過濾 單純的語義向量並不足以應對複雜過濾需求，通常還需要構建 元信息索引 ：
    1. 為每個文檔塊補充時間、作者、來源、文檔類型、業務線、敏感級別等元數據；
    2. 支持在檢索時基於元信息進行預過濾（如時間範圍、部門、權限等級），減少無關結果；
    3. 為權限控制與審計打下基礎，避免 RAG 在回答中洩露用戶無權訪問的內容。

8.1.2 檢索與重排序：從“召回相關”到“找到最合適的證據” ​

在索引構建完成後，當用戶發起查詢，就進入檢索與重排序階段。這裡的關鍵不只是“找一些相關文檔”，而是要儘可能找到 既相關又覆蓋充分、且支持推理的證據組合 。

  1. Hybrid 檢索：向量 + 關鍵詞的互補 純向量檢索擅長捕捉語義相似度，但對於精確術語、代號、表格字段等，關鍵詞檢索（如 BM25）往往更穩健。因此工程實踐中普遍採用 Hybrid Search：
    1. 首先對查詢分別進行向量檢索和關鍵詞檢索，得到兩組候選文檔塊；
    2. 使用加權打分或學習到的融合策略，將兩路候選合併；
    3. 在一些場景中，可根據查詢類型（FAQ 問答 vs. 法條定位）動態調節向量與關鍵詞檢索的權重。
  2. 重排序（Re‑ranking）：更精細地挑選“證據集” 初始檢索結果往往包含不少“邊緣相關”或“冗餘”文檔塊，需要重排序來提升最終 Top‑K 的質量：
    1. 使用 Cross‑Encoder（交叉編碼器）對“查詢–文檔塊”對進行雙向編碼和相關性打分，相比雙塔 Embedding 模型精度更高，但開銷較大，適合作為二階段重排；
    2. 在性能允許時，引入 LLM 進行輕量級重排，讓模型基於更豐富的語義和上下文信息來判斷哪些塊真正“有用”；
    3. 同時考慮覆蓋度與多樣性，避免所有檢索塊都集中在同一文檔或同一段落，從而導致回答視野過窄。
  3. 檢索–生成閉環優化 更高級的實踐中，檢索和生成不再是單向流程，而是形成閉環：
    1. 利用 LLM 對檢索結果的“使用情況”進行分析（哪些塊被引用、哪些塊總是被忽略），反向指導索引和分塊策略的優化；
    2. 利用對話日誌中的“追問/糾錯”信號，對召回失敗、誤召回的樣本進行標註和再訓練，提高系統對模糊查詢、長尾問題的魯棒性。

8.1.3 生成與引用：在“證據約束下”回答問題 ​

最後一環是生成層，它直接決定了用戶體驗。這裡的目標不是讓模型“隨心所欲”地發揮，而是讓它在 檢索證據的約束下，給出清晰、有邊界、有引用的回答 。

  1. 基於檢索上下文的受控生成 在 RAG 架構中，LLM 接收到的不只是用戶問題，還包括多段檢索到的文檔塊以及系統指令。系統通常會：
    1. 通過 Prompt 約束模型“只根據給定文檔回答”“如果文檔中找不到答案就明確說明缺失”；
    2. 對檢索上下文進行結構化組織（分段、編號、標註來源），方便模型理解與引用；
    3. 控制輸出格式（列表、表格、分點說明等），適配下游系統或前端展示。
  2. 引用與可解釋性（Source Citation） 為了便於審計與追溯，尤其在法律、醫療、金融、企業內部制度等高風險領域，回答中往往需要附帶明確引用：
    1. 在輸出中標註引用來源，如“[文檔 A，第 3 章，第 2 節]”“[法規 X 第 12 條]”；
    2. 在前端界面中支持一鍵跳轉到原文位置，便於用戶核查和進一步閱讀；
    3. 在後臺保存“問題–檢索結果–引用塊–最終回答”的完整鏈路日誌，為後續風控和模型改進提供數據。
  3. 先進 RAG 變體：HyDE / ReAct + RAG 等 為進一步提升難題場景下的效果，實踐中還會使用更復雜的 RAG 變體：
    1. HyDE：由 LLM 先根據問題生成一個“假想答案文檔”，再用該文檔向量去檢索真實文檔，從而提高召回質量；
    2. ReAct + RAG：LLM 以“思考（Reasoning）+ 行動（Action）”的方式，在推理中多次調用檢索工具，逐步細化問題、補充證據，類似“邊思考邊查資料”；
    3. 多輪 RAG：在對話過程中，保留歷史檢索結果和回答，形成上下文感知的長期知識會話，而不僅是“單問單檢索”。

8.2 結構化數據與知識圖譜（Structured Data & KG） ​

如果說 RAG 主要解決“如何在大規模非結構化文檔中查資料”，那麼結構化數據與知識圖譜這一層，則更多面向“如何優雅地用好數據庫、報表系統和圖數據庫中的結構化知識”。

在企業環境中，真正關鍵的業務數據——訂單、客戶、合同、庫存、行為日誌——往往以關係數據庫、數據倉庫、OLAP 引擎或圖數據庫的形式存在。這些系統在查詢能力、計算效率和審計方面已經非常成熟，但對於業務人員而言，直接寫 SQL / DSL 仍然門檻較高。Text‑to‑SQL / Text‑to‑DSL 與 知識圖譜問答與推理 ，就是要讓 LLM 在不破壞這些系統穩定性的前提下，作為“自然語言界面”和“推理協作夥伴”插入進來。

  • 場景
    • BI 智能問答與自助分析：業務人員用自然語言發問（如“幫我看看最近 3 個月華東地區新客的復購率趨勢”），系統自動生成 SQL，查詢數據倉庫，然後用自然語言和可視化圖表返回結果。
    • 運營 / 銷售分析助手：運營同學可以用對話的方式探索數據（“這個活動轉化率為什麼下降”“哪些渠道貢獻了最多高價值用戶”），在多輪對話中逐步細化條件和維度。
    • 領域知識中臺：將實體、概念、規則和案例組織為知識圖譜，支持圍繞某個實體進行上下游關係探索和合規性檢查。
    • 圖數據庫問答與推理系統：在風險控制、反洗錢、供應鏈分析等場景中，通過圖數據庫與 LLM 聯合，對“關係鏈條”和“多跳推理”類問題進行回答與解釋。
  • 原理 這一層的核心，是把 LLM 從“直接給答案的人”變成“會調用數據庫與圖數據庫的助手”：
    • 在數據庫問答中，模型需要理解用戶的自然語言意圖，結合數據庫 schema（表結構、字段含義、約束等），生成正確的 SQL / GraphQL / 內部 DSL，再對執行結果進行解釋與可視化。
    • 在知識圖譜場景中，系統需要先從文檔和日誌中抽取實體和關係，構建結構化圖譜；然後在問答時由 LLM 負責把自然語言問題轉譯為圖查詢（如 Cypher），並基於查詢結果進行多跳推理和解釋。
    • 與 RAG 不同，這裡強調的是 對結構化數據與圖結構的精確訪問 ，一方面要保證語義正確、語法嚴謹，另一方面要控制側寫攻擊、敏感數據暴露和高成本查詢。
  • 模型 典型方案通常是“LLM + 專用組件”的多模塊架構：
    • Text‑to‑SQL 模型：在大規模 SQL 語料上預訓練或微調的模型（如 PICARD、DIN‑SQL 等），側重語法正確性與 schema 對齊，有時會搭配執行反饋進行自我修正。
    • 信息抽取與圖譜構建 pipeline：通過實體識別（NER）、關係抽取、事件抽取等模塊，從文本和日誌中構建和更新知識圖譜；LLM 可以參與難例抽取、邊界模糊關係的輔助判斷。
    • LLM + 圖數據庫聯合問答：LLM 負責問題解析、查詢生成與結果解釋，圖數據庫（如 Neo4j 等）負責高效執行與多跳關係搜索，兩者通過工具調用協議或中間 DSL 對接。

8.2.1 數據庫問答（Text‑to‑SQL / DSL）實踐 ​

數據庫問答的目標，是讓業務人員“用自然語言問數據”，而系統在背後自動完成查詢語句生成、執行與解釋。要把這件事做好，關鍵在於兼顧 語義準確性、語法正確性和執行安全性 。

  1. 自然語言到 SQL / DSL 的轉換 在最基礎的鏈路中，系統需要：
    1. 解析用戶意圖：識別出查詢對象（如“華東地區新客”）、過濾條件（時間、地區、渠道）、聚合方式（總數、平均值、同比/環比）和展示需求（趨勢、排行、Top‑N）；
    2. 結合數據庫 schema：理解哪些表與字段可以表達上述概念，如何進行關聯（join）、分組（group by）和排序；
    3. 生成可執行的 SQL / GraphQL / 內部 DSL，並通過語法校驗器或專門的 Text2SQL 模型（PICARD、DIN‑SQL 等）確保結構合法。
  2. 執行結果的自然語言解釋與可視化 查詢執行後，系統還需把“冷冰冰的結果集”變成“可理解的洞察”：
    1. 對簡單結果進行文本解釋，如“過去 3 個月華東地區新客的復購率整體呈上升趨勢，從 15% 提升到 21%”；
    2. 對複雜結果選擇合適的可視化形式（折線圖、柱狀圖、餅圖、分佈圖等），並給出簡要分析；
    3. 支持用戶基於當前結果繼續追問（如“這波增長主要來自哪些渠道？”），自動在歷史 SQL 和上下文的基礎上構造新的查詢。
  3. 安全與控制：防止“亂查”和“越權” 由於 LLM 生成的 SQL 具有高度靈活性，必須有一層安全與治理機制：
    1. 基於用戶角色與權限，對可查詢的庫、表、字段和時間範圍做嚴格限制；
    2. 為模型生成的 SQL 配備靜態/動態審查規則，過濾危險操作（如大範圍掃描、高成本 join、跨租戶查詢等）；
    3. 將“自然語言問題–生成 SQL–執行結果–最終回答”完整記錄，用於審計與異常分析。

8.2.2 知識圖譜構建與查詢 ​

知識圖譜試圖把散落在文本、表格、日誌中的知識，組織成“實體–關係–屬性–事件”的結構化網絡，從而更好地支持 關係探索、多跳推理和複雜問答 。在這一方向上，LLM 與傳統信息抽取、圖數據庫形成了良好的互補。

  1. 從文檔中抽取實體和關係構建圖譜 構建知識圖譜通常採用多階段 pipeline：
    1. 信息抽取：利用 NER、關係抽取、事件抽取等模型，從文本中識別實體（人、機構、產品、地名、概念等）、它們之間的關係（隸屬、合作、依賴、因果）以及關鍵事件（交易、風險、變更）；
    2. 規範化與對齊：將同一實體的不同表述（簡稱、別名、拼寫變體）進行歸一，對齊到統一 ID；
    3. 圖譜更新與版本管理：支持增量更新、衝突解決和錯誤糾正，確保圖譜在長期演化中保持質量與一致性。LLM 可以在歧義消解、關係類型細化、規則歸納等環節輔助傳統算法。
  2. LLM + 圖數據庫（Neo4j 等）的查詢與推理 當圖譜構建完畢，圖數據庫負責高效存儲和檢索，而 LLM 則可以扮演“自然語言入口 + 推理控制器”的角色：
    1. 問題解析與圖查詢生成：將自然語言問題轉譯為圖查詢語句（如 Neo4j 的 Cypher），包括確定起點實體、關係類型、路徑長度與過濾條件；
    2. 多跳推理：通過圖查詢得到的路徑和局部子圖，再由 LLM 進行解釋與歸納，如“客戶 A 與高風險實體 B 之間通過三家公司間接相連”；
    3. 結果可視化與可解釋性：將圖查詢結果以可視化網絡形式呈現，同時由 LLM 給出口頭說明，幫助用戶理解複雜關係結構。
  3. 領域知識中臺與統一服務 在更大規模的企業或行業級應用中，知識圖譜往往作為“領域知識中臺”存在：
    1. 為上層業務系統（風控、合規、客戶 360 視圖、供應鏈分析等）提供統一的實體和關係視角；
    2. 與 RAG、數據庫問答共同構成統一的知識服務層，由統一的 LLM 編排邏輯決定當前問題該訪問文檔索引、關係數據庫還是圖數據庫；
    3. 在安全和合規要求下，通過圖譜層面的訪問控制和脫敏策略，進一步降低敏感信息洩露的風險。

這一層的共同目標，是把“模型會說話”升級為“模型既會說話，又真正接上了企業的真實數據與知識資產”。當 RAG、Text‑to‑SQL、知識圖譜與傳統數據基礎設施有效結合之後，AI 系統才能在複雜業務環境中既保持智能和靈活性，又具備可控性、可解釋性和長期演化能力。