RAGFlow · 第 3 章：第一节 RAGFlow 配置参数全景图与实验结论
系列导航
- 第 0 章 前言：为什么企业 AI 工程师必须掌握 RAGFlow
- 第 1 章：安装部署与基础配置**——从零跑通第一个 RAG Pipeline
- 第 2 章：RAGFlow RAGFlow 代码介绍
- 第 3 章：攻克企业复杂文档——理解 DeepDoc、Naive、MinerU 与 Docling 的区别
- 第一节 RAGFlow 配置参数全景图与实验结论（本文）
- 第二节 实验Chunk Method (解析方法与布局识别)
- 第三节 实验Chunk Token Num & Overlap (切片与重叠)
- 第四节 实验Similarity Threshold (相似度阈值)
- 第五节 实验Vector/Keyword Weight (混合搜索权重)
- 第六节 MinuerBridge安装配置与运行使用
- 第 4 章：理解 Agentic RAG 核心——定义与低代码实现
- 第 5 章：工作流编排——构建基于图（Graph）的 RAG
- 第 6 章：Deep Research 模板应用——部署自动拆解子问题的深度研究智能体
- 第 7 章：企业级扩展——API 接入与外部工具集成（MCP）
- 第 8 章：评估与复盘——从"玄学"到量化 RAG 性能指标评测
本章内容介绍
第一节 列举RAGFlow配置参数和优先级; 前置了通过实验获得的关键参数的综合配置
第二节 - 第五节 分别是四个关键参数的实验记录.
第六节 鉴于MinerU在企业文档识别任务中具有较好的实际效果, 专门提供MinerU的具体使用方法.
RAGFlow 配置参数全景图
这份文档记录了 RAGFlow 界面中大部分RAG关键配置参数的定义、作用域以及在后端代码中的对应处理逻辑。
1. 知识库配置 (Dataset & Parsing)
作用域：影响文件的解析、切片(Chunking)和索引质量。
| 参数名称 | 界面标题 (UI Name) | 核心作用 (Effect) | 核心代码位置 (Code Trace) | 影响阶段 |
|---|---|---|---|---|
parser_id | 解析方法 (Chunk Method) | 决定文件如何拆分（General, Naive, Laws等）。 | rag/nlp/(各种 chunker 逻辑) | Indexing |
chunk_token_num | 最大 Token 数 | 控制每个 Chunk 的语义颗粒度。 | rag/nlp/ | Indexing |
overlapped_percent | 重叠比例 | 块与块之间的重复信息，用于保持上下文。 | rag/nlp/ | Indexing |
layout_recognize | 布局识别 | 是否识别 PDF/图片中的表格、标题等结构。 | deepdoc/ | Indexing |
embd_id | 嵌入模型 | 用于向量化的模型。 | rag/llm/embedding_model.py | Indexing |
auto_keywords | 自动关键词 | 提取 Chunk 的关键词，增强混合搜索。 | rag/nlp/ | Indexing |
raptor | 递归摘要树 (RAPTOR) | 是否开启递归层级摘要，适合处理全局性问题。 | rag/nlp/raptor.py | Indexing |
2. 检索与召回 (Retrieval & Rerank)
作用域：影响查询时的结果相关性与准确度。
| 参数名称 | 界面标题 (UI Name) | 核心作用 (Effect) | 核心代码位置 (Code Trace) | 影响阶段 |
|---|---|---|---|---|
similarity_threshold | 相似度阈值 | 低于该分数的召回块将被过滤。 | rag/nlp/search.py | Retrieval |
vector_similarity_weight | 向量权重 | 混合检索中向量 (Dense) 的比重（0~1）。 | rag/nlp/search.py | Retrieval |
top_n | 召回数量 (Top N) | 最终喂给大模型的上下文片段数量。 | rag/nlp/search.py | Retrieval |
rerank_id | 重排模型 | 使用二阶段精选模型重新给候选块打分。 | rag/llm/reranker_model.py | Retrieval |
use_kg | 启用知识图谱 | 是否引入 GraphRAG 提取的实体关系进行检索。 | rag/nlp/search.py | Retrieval |
3. 对话设置 (Chat & Assistant)
作用域：影响 LLM 的生成风格和用户交互体验。
| 参数名称 | 界面标题 (UI Name) | 核心作用 (Effect) | 核心代码位置 (Code Trace) | 影响阶段 |
|---|---|---|---|---|
system | 系统提示词 (System Prompt) | 决定 AI 的角色设定和回答准则。 | api/apps/chat_app.py | Generation |
temperature | 采样温度 | 控制回答的确定性 vs 随机性。 | rag/llm/chat_model.py | Generation |
refine_multiturn | 多轮对话优化 | 是否将历史对话融合进新的查询意图。 | rag/llm/chat_model.py | Generation |
quote | 引用开关 | 回答中是否标注来源片段的具体出处。 | web/src/pages/chat/... | Generation/UI |
empty_response | 没找到时的回答 | 当检索不到任何内容时的自定义兜底策略。 | api/apps/chat_app.py | Generation |
下面是把四个参数统一到Indexing（入库/建索引）和Retrieval（检索/召回）两个业务环节后的完整总结。可以直接作为 blog 的“实验总结与参数选择建议”。
关键参数实验的结论和建议
RAGFlow 的知识库效果，本质上由两个环节共同决定：
- Indexing 阶段：决定“文档被如何切分、解析、入库”
- 主要参数：解析方法、Chunk Size、Overlap
- 目标：让知识块结构清晰、语义完整、粒度合适
- Retrieval 阶段：决定“用户问题来了以后，系统如何召回内容”
- 主要参数：Similarity Threshold、Vector / Keyword Weight
- 目标：在“召回足够多”和“过滤无关内容”之间取得平衡
Indexing 决定知识库的底子，Retrieval 决定问答时怎么取内容。
前者偏“文档加工”，后者偏“搜索策略”。- Indexing 阶段：决定“文档被如何切分、解析、入库”
主要参数说明
- 解析方法决定文档结构能不能被正确保留下来；
- Chunk Size 和 Overlap决定知识块是否完整、是否容易命中；
- Similarity Threshold决定召回内容的“水线”高低；
- Vector / Keyword Weight决定系统更相信“语义相似”还是“关键词匹配”。
对于大多数企业文档知识库，可以先用下面这组配置作为起点：
Parsing Method = General + MinerU Chunk Size = 512 Overlap = 10% Similarity Threshold = 0.30 Vector Weight = 0.3 - 0.4 Keyword Weight = 0.7 - 0.6根据手头侧使用企业文档， 此配置适合大多数 制度、方案、说明书、运行规程、检修规程、项目文档 的初始测试。
表 1：Indexing 阶段参数选择建议
| 企业文档类型 | 推荐解析方法 | 推荐 Chunk Size | 推荐 Overlap | 适用原因 |
|---|---|---|---|---|
| 普通制度、方案、说明书、操作手册 | General + MinerU | 512 | 10% | 适合作为默认方案，兼顾段落完整性和检索粒度 |
| 长篇规范、标准、技术白皮书、项目方案书 | General / Paper + MinerU | 1024+ | 10% | 文档上下文较长，过小切片容易割裂完整逻辑 |
| FAQ、知识问答、客服问答、故障问答库 | General / Naive | 200 - 500 | 15% | 问答内容通常短而独立，适合小切片精准命中 |
| 检修规程、运行规程、安全制度 | General + MinerU | 512 - 800 | 10% - 15% | 需要保留步骤、条件、措施之间的上下文关系 |
| 运行记录、缺陷记录、检修记录 | General / Table | 300 - 600 | 10% | 单条记录通常较短，重点是保留设备、时间、现象、处理结果 |
| Excel、CSV、台账、结构化表格 | Table | 按行/表格结构切分 | 低 overlap | 表格字段关系比自然段更重要，应优先保持表格结构 |
| 学术论文、技术论文、研究报告 | Paper | 800 - 1200 | 10% | 需要识别摘要、章节、图表、参考结构，避免普通切分破坏逻辑 |
| 代码库、接口文档、配置文件 | Naive / Code 类解析方式 | 800+ | 10% - 20% | 函数体、类、配置块不宜被切断，切片应尽量保持代码单元完整 |
对于企业知识库，最稳妥的策略不是一开始追求“最高级参数”，而是：
先用中等切片 + 中等阈值 + 混合检索作为基线，
再根据真实问题逐步微调。
表 2：Retrieval 阶段参数选择建议
| 使用场景 | Similarity Threshold 建议 | Vector Weight 建议 | Keyword Weight 建议 | 调参逻辑 |
|---|---|---|---|---|
| 常规企业文档问答 | 0.20 - 0.30 | 0.4 | 0.6 | 作为大多数知识库的起点，兼顾语义理解和关键词匹配 |
| 运行规程、检修规程、安全制度、企业运行记录、检修记录、缺陷闭环 | 0.40 - 0.50 | 0.3 | 0.7 | 需要一定语义能力，但不能放任无关内容混入 |
| 高风险专业知识库，例如安全、规程、API、法规 | 0.50 | 0.3 | 0.7 | 宁可少召回，也要减少无关内容进入回答上下文 |
| 口语化问答、故障现象解释 | 0.20 - 0.30 | 0.5 - 0.7 | 0.5 - 0.3 | 用户表达可能不等于文档原文，需要提高语义检索权重 |
| 测点编号、设备编码、缺陷单号、工单号查询、文档管理、编号搜索、标题搜索、精确查找 | 0.5 | 0.1 - 0.2 | 0.9 - 0.8 | 依赖精确匹配，关键词权重应占主导，不应过度依赖向量语义 |
尤其是专业企业文档，不建议盲目追求高语义权重。
如果文档中存在大量设备编码、部件名称、故障现象、标准条款、检修步骤、缺陷单号，关键词检索仍然非常重要。
最终可以把调参原则总结为一句话：
文档越结构化、编号越多、术语越固定，就越应该提高 Keyword Weight；问题越口语化、表达越不固定，就越应该提高 Vector Weight；业务越不能接受误答，就越应该适当提高 Similarity Threshold。