RAGFlow 使用指南：構建可靠 RAG 應用的實用指南
更新於 2025年9月19日
8 分鐘
如何使用 RAGFlow：構建可靠 RAG 應用程式的實用指南
如果您嘗試構建檢索增強生成 (RAG) 系統，您可能已經遇到了典型的痛點：幻覺、不穩定的檢索、緩慢的管道和混亂的文件預處理。RAGFlow 是一個端到端的工作流程工具，可幫助您協調文件導入、分塊、向量化、檢索和生成，並提供更多控制和可觀察性。
本指南採用實用且以解決方案為導向的方法。我們將逐步完成一個乾淨的設定，向您展示如何將 RAGFlow 用於真實文件，並分享實際減少幻覺並提高答案品質的模式。
什麼是 RAGFlow？以及為何要使用它？
RAGFlow 是一個用於構建檢索增強生成管道的系統。在典型的 RAG 設定中，您會：
- 導入文件（PDF、網頁、簡報、程式碼等）
- 將內容分塊為可檢索的單元
- 將塊嵌入向量中以進行語義搜索
- 在提問時檢索前 top‑k 個相關塊
- 生成使用 LLM 的有根據的答案
RAGFlow 添加了明確的預設值、工作流程塊和護欄，因此您可以更快地迭代並交付更可靠的應用程式。如果您想要以下內容，它特別有用：
- 一致的分塊和元數據：更好的檢索始於更好的塊。
- 可插拔的嵌入和 LLM：交換 OpenAI、本地模型或企業端點。
- 評估和護欄：衡量檢索品質並減少幻覺。
- 可部署的管道：以更少的重寫次數從筆記本電腦轉移到生產環境。
快速入門：從零到可用的 RAGFlow 管道
以下是一個最小的端到端工作流程，您可以進行調整。即使您的環境不同，該順序和護欄也是可移植的。
1) 準備您的環境
- 創建一個包含您的金鑰的
.env：
OPENAI_API_KEY（或其他 LLM 提供者）
EMBEDDINGS_API_KEY（如果使用單獨的提供者）
VECTOR_DB_URL（例如，Pinecone、Weaviate、Qdrant 或本地）
- 設定一個項目目錄，例如
ragflow-project/，其中包含以下資料夾：
data/raw/（原始檔案）
data/processed/（已清理的塊）
configs/（用於管道設定的 YAML/JSON）
eval/（數據集和報告）
2) 導入具有乾淨元數據的文件
良好的元數據 = 更好的檢索。規範化標題、作者、日期和來源。
- 使用強大的解析器將 PDF 和簡報轉換為文本
- 保留結構：標題、列表、程式碼塊和表格
- 將元數據附加到每個塊：
source、section、page、timestamp、version
提示：保留
doc_id 和 chunk_id 以支援引用和重新導入。3) 選擇適合您內容的分塊策略
分塊會嚴重影響檢索品質和延遲。
- 對於敘述性文檔：語義分塊（按標題/段落分割）
- 對於技術文檔：使用 混合分塊（語義 + 固定視窗）
- 對於程式碼：按 function/class 分塊，並帶有一個小的滑動視窗
建議的起始設定：
chunk_size：600–1,000 個 tokens
chunk_overlap：50–100 個 tokens
max_depth：將巢狀部分限制為 2–3 層，以避免碎片化
4) 選擇嵌入和向量儲存
- 從一個強大的通用嵌入模型開始（例如，text‑embedding‑3‑large 或一個現代本地模型）。如果隱私是關鍵，請考慮自託管嵌入。
- 使用支援以下功能的向量 DB：
- 混合搜索（密集 + 關鍵字）
- 篩選器（元數據約束）
- 批次 upserts 和 索引指標
要測試的索引設定：
top_k = 5–10用於初始檢索
similarity_metric = cosine（或某些模型的點積）
- 啟用 最大邊緣相關性 (MMR) 以減少冗餘
5) 檢索協調
實施一個兩階段檢索器：
- 快速候選召回
- 混合搜索 (BM25 + 密集)
- 大的
top_k（例如，30–50）
- 重新排序
- 交叉編碼器重新排序器或基於 LLM 的評分
- 減少到最終的
top_k（例如，5–8）
添加元數據篩選器：
source:"handbook" AND section:"benefits" AND version:"v2" 以將答案限制為受信任的文檔。6) 具有結構的有根據的生成
您的提示應強制執行引用，並在證據不足時拒絕回答。
範例系統提示：
您是一位仔細的助手。僅使用提供的上下文中支持的資訊回答。- 以 [doc_id:chunk_id] 的形式內嵌引用來源。- 如果上下文不夠充分，請說“提供的文件中沒有足夠的資訊。”- 不要捏造事實。使用者提示範本：
問題：{query}上下文：{top_chunks}指示：- 首先提供簡潔的答案，然後提供詳細資訊。- 在每個事實性聲明後包含引用。7) 添加護欄以減少幻覺
- 可回答性檢查：在生成之前，詢問一個小型模型：“檢索到的塊中是否有直接證據？”如果沒有，則返回一個澄清問題。
- 引用或沉默策略：阻止缺少引用的輸出。
- 用於企業內容的 毒性/PII 篩選器。
8) 評估和持續改進
創建一個
eval/ 集，其中包含：- 50–200 個真實使用者問題
- 基本事實答案（或受信任的參考文獻）
- 適用的預期來源（文檔 ID）
衡量：
- 檢索命中率（黃金來源是否出現在 top‑k 中？）
- 答案忠實度（引用支援的陳述）
- 延遲（p95 端到端）
- 成本（每 100 個查詢）
迭代：
- 塊大小和重疊
- 嵌入模型選擇
- 重新排序器與更高的 top‑k
- 提示結構和約束
完整的 RAGFlow 管道：範例配置
以下是一個概念配置，您可以根據您的工具鏈進行調整。根據需要替換提供者名稱。
project: product-handbook-ragio:input_path: data/raw/output_index: product-handbook-indexparsing:pdf:strategy: autokeep_layout: trueextract_tables: truemarkdown:preserve_headings: truechunking:method: semantic_hybridtarget_tokens: 800overlap_tokens: 80windowing: 2metadata:fields: [doc_id, title, section, page, version, source]embeddings:provider: openaimodel: text-embedding-3-largevectorstore:<a23>type: qdrant</a24>url: ${VECTOR_DB_URL}similarity: cosineretrieval:hybrid: truelexical_weight: 0.35semantic_weight: 0.65candidate_top_k: 40rerank:enabled: truemodel: bge-reranker-largefinal_top_k: 7generation:llm: gpt-4otemperature: 0.2cite_or_silence: trueguardrails:answerability_check: truepii_filter: truetoxicity_filter: moderatemonitoring:log_traces: truelatency_budget_ms: 3500cost_budget_per_100: 1.25如何將 RAGFlow 用於不同的內容類型
產品手冊和指南
- 首選具有清晰章節邊界的語義分塊
- 附加版本和生效日期以防止過時的答案
- 使用嚴格的篩選器：始終要求
version = latest
知識庫和常見問題解答
- 使用較小的塊（400–600 個 tokens）以獲得精確的答案
- 增加候選池並依靠重新排序來找到確切的程式碼片段
- 自動生成規範的問/答對，以透過詞彙搜索提高召回率
工程文檔和程式碼
- 按函數/模組分塊，並在元數據中包含導入圖
- 啟用父子檢索：返回函數 + 其 docstring 上下文
- 使用程式碼感知重新排序器來優先處理相關符號
法律和合規
- 要求段落級別的引用
- 為不完整的上下文添加拒絕邏輯
- 在單獨的索引中保留一套監管機構批准的黃金來源
實際有效的提示模式
- 先回答後引用：頂部是簡短的答案；每次聲明後內嵌引用
- 檢索鏈：首先要求模型總結每個塊，然後進行綜合
- 查詢重寫：在檢索之前，使用同義詞和領域術語擴展使用者查詢
- 對比提示：“根據上下文解釋為什麼選項 A 比 B 更好。”這會強制使用證據
範例查詢重寫步驟：
原始：“我們的 PTO 結轉政策是什麼？”重寫：“帶薪休假結轉政策；休假展期；最多小時數；最新政策版本”可觀察性和回饋迴路
- 記錄使用了哪些塊、它們的分數以及哪些被忽略
- 捕獲帶有簡短理由的贊/踩；將其回饋到檢索器調整中
- 在部署任何模型更改之前，每週在您的評估集上運行迴歸測試
效能調整秘笈
- 如果答案感覺很通用：增加
candidate_top_k並添加更強大的重新排序器
- 如果答案遺漏了細節：減少塊大小；稍微提高詞彙權重
- 如果引用重複相同的塊：啟用 MMR 並提高多樣性
- 如果延遲很高：緩存嵌入，預先計算查詢重寫，使用較小的重新排序器
- 如果成本飆升：降低生成溫度，縮短提示，嘗試使用較小的 LLM 進行第一遍
安全和治理要點
- 加密儲存的向量並編輯元數據中的敏感欄位
- 使用按索引存取控制；按團隊或數據敏感度進行分段
- 維護數據沿襲記錄：文檔來源 URL、校驗和和導入時間戳
案例研究快照：從混亂的 PDF 到受信任的答案
一個支援團隊導入了 1,200 頁的 PDF。最初的檢索不一致；代理不信任該機器人。在切換到語義混合分塊（800 個 tokens，80 個重疊），啟用交叉編碼器重新排序並強制執行引用或沉默後，top‑k 命中率從 62% 提高到 89%，並且代理採用率翻了一番。關鍵不是更大的 LLM，而是更乾淨的塊和更嚴格的檢索。
工具提示：使用 AI 側邊欄進行快速迭代
值得注意的是：如果您正在跨多個文檔試驗提示和檢索程式碼片段，那麼一個允許您直接從瀏覽器透過 PDF、網頁和程式碼聊天的 AI 助手可以加速迭代。順便說一句，Sider.AI（https://sider.ai/）提供了一個 AI 側邊欄，可讓您從您所在的頁面中提取上下文、總結並快速改進提示。它對於在您正式化管道之前原型化 RAG 提示和測試塊品質非常方便。
RAGFlow 疑難排解：快速修復
- “模型很自信但錯誤。”
- 啟用可回答性檢查；降低溫度；要求引用
- “搜索返回近乎重複的內容。”
- 開啟 MMR；添加重新排序器；減少塊重疊
- “延遲在峰值時飆升。”
- 批次嵌入；緩存查詢重寫；使用流式生成
- “舊政策不斷出現。”
- 篩選
version = latest；棄用或封存過時的文檔
後續步驟：使您的 RAGFlow 在生產環境中可靠
- 從一個小的、受信任的語料庫開始；首先完善分塊和篩選器
- 在升級 LLM 之前添加重新排序器
- 建立一個包含 100 個問題的評估集，並每週追蹤命中率
- 連接使用者回饋以持續調整檢索
主要要點：
- 對於 RAG 而言，檢索品質勝過模型大小
- 分塊、元數據和重新排序是您的核心槓桿
- 像引用或沉默這樣的護欄可以極大地提高信任度
- 儘早投資於可觀察性和評估
透過這些實踐，RAGFlow 成為有根據的答案的可靠後盾，無論您是為幫助機器人、開發人員副駕駛還是內部知識助手提供支援。
常見問題解答
Q1: 什麼是 RAGFlow？我該如何將它用於文檔 QA？
RAGFlow 是一個用於構建檢索增強生成管道的框架。您可以透過引用導入、分塊、嵌入、檢索和生成答案，以減少幻覺並提高準確性。
Q2: 我應該如何在 RAGFlow 中對文檔進行分塊？
使用語義或混合分塊，塊大小為 600–1,000 個 token，重疊為 50–100 個 token。對於程式碼，按函數或類別分塊，並包含周圍的上下文。
Q3: 哪個向量數據庫最適合 RAGFlow？
選擇一個支援混合搜索、元數據篩選器和重新排序的儲存庫 — Qdrant、Weaviate、Pinecone 或本地選項都是常見的選擇。
Q4: 如何防止 RAGFlow 應用程式中出現幻覺？
強制執行引用或沉默策略，在生成之前新增可回答性檢查，並保持提示嚴格，僅使用檢索到的上下文。
Q5: 我應該追蹤哪些指標來評估 RAGFlow？
監控檢索命中率、答案忠實度、延遲和每 100 個查詢的成本，並維護一個小型但具有代表性的評估集。
