RAGFlow概述：用文档理解做稳知识库问答

RAGFlow 是一个开源 RAG 引擎。它最值得关注的地方，不是“能不能把资料接到大模型上”，而是它把重点放在了真实文档的处理上。

很多 RAG Demo 用的是干净 Markdown 或几段纯文本。真实项目里，资料往往是 PDF、扫描件、Excel、Word、网页、图片和表格。资料一复杂，普通切分就容易把上下文切坏。RAGFlow 的价值就在这里：先尽量理解文档结构，再把它变成更适合检索的知识块。

RAGFlow 适合解决什么问题

一个简单知识库可以这样做：

把文档转成纯文本 -> 切块 -> 向量化 -> 检索 -> 生成答案

这个流程适合干净文档。遇到复杂资料时，问题会变多。

例如一份采购合同里，付款条件在表格里，违约条款在正文里，补充说明在页脚里。如果系统只按固定字数切块，可能把一条规则切成三段。用户问“提前解约赔多少”，检索只命中了金额，没有命中适用条件，答案就会误导。

RAGFlow 的定位更像“面向文档型知识库的 RAG 工作台”。它把上传、解析、分块、检索测试、聊天和引用溯源放到一套流程里。

flowchart TD
  A["上传文档"] --> B["文档解析"]
  B --> C["模板化分块"]
  C --> D["索引和检索"]
  D --> E["聊天助手"]
  E --> F["答案和引用"]

Deep document understanding 是什么

Deep document understanding 可以理解为对文档版面和内容结构的理解。

普通文本抽取只关心“字有哪些”。文档理解还要关心“这些字在哪里、属于什么结构、和周围内容是什么关系”。

例如一份 PDF 报告：

标题表示章节主题
表格表示结构化数据
图片说明解释图表含义
页眉页脚可能是重复噪声
脚注可能影响条款解释

如果系统把页眉页脚反复切进知识库，检索时就会出现大量无关片段。如果系统把表格按行乱序抽出，用户问“现金流同比变化”，模型可能拿不到完整数据。

RAGFlow 强调文档理解，目的就是让进入知识库的内容更接近人读文档时看到的结构。

模板化分块

Chunk 是检索时能被单独找回的一小段知识。RAGFlow 强调 template-based chunking，也就是不同文档类型用不同切法。

FAQ 表格适合“一行问答一个 chunk”。

Q：如何重置密码？
A：进入账号设置，点击安全中心，选择重置密码。

论文适合按摘要、章节、实验、结论切。

Abstract
Introduction
Method
Experiment
Conclusion

产品手册适合按标题层级保留步骤。

3.2 设备初始化
步骤 1：接通电源
步骤 2：长按启动键
步骤 3：等待指示灯变蓝

如果把这三种文档都按固定 500 字切，效果通常不会好。FAQ 会把问答拆散，论文会丢章节语义，手册会把步骤切断。

混合检索

RAGFlow 的检索思路包含关键词匹配和向量相似度。选择 rerank 后，还会引入重排分数。

关键词匹配适合精确实体。

例如：

E42 故障码
ISO 27001 A.5
订单号 ORD-918273

这些词不能只靠语义相似度。E42 就是 E42，错一个字符都可能是另一个含义。

向量相似度适合语义近义。

例如用户问：

设备启动不了怎么办？

文档里写的是：

开机失败时请检查电源、保险丝和启动键状态。

两句话不完全相同，但语义接近。向量检索能把它们连起来。

flowchart LR
  Q["用户问题"] --> K["关键词匹配"]
  Q --> V["向量相似度"]
  K --> M["混合评分"]
  V --> M
  M --> R["可选 Rerank"]
  R --> N["Top N Chunks"]
  N --> L["LLM 生成回答"]

Rerank 的取舍

Rerank 是把第一轮检索结果重新排序。它通常更准，也通常更慢。

例如用户问：

已拆封耳机还能退货吗？

第一轮检索可能找出很多“退款”相关片段。Rerank 会更细地判断哪些片段真正回答“已拆封”“耳机”“能否退货”这三个条件。

如果是内部客服知识库，慢一点换更准通常值得。
如果是实时搜索建议，延迟可能比精排更重要。

RAGFlow 的发布说明里也提到过内置 rerank 模型对检索时间的影响。这说明 RAG 系统不是“功能越多越好”，而是要看准确率和延迟的平衡。

引用溯源

RAGFlow 强调 grounded citations，也就是让答案能回到资料来源。

例如用户问：

这台设备质保多久？

一个更可用的答案不是只说“质保 12 个月”，而是带上出处：

设备质保期为 12 个月。依据是《售后服务条款》第 2.1 节。

引用的价值有两个。

第一，用户能核对。
第二，开发者能调试。

如果答案错了，看引用就能判断问题出在哪里：是检索错了，还是模型没读懂，还是原文就有歧义。

不过引用不是绝对保证。模型可能引用了相关段落，但结论超过了段落支持范围。所以关键业务场景仍然要做人工复核或规则校验。

多语言、图片和 Agent 能力

真实知识库经常是多语言混杂的。

例如中文用户问：

退货政策是什么？

知识库里可能只有英文文档：

Return policy applies within 7 days for eligible products.

跨语言搜索可以把中文问题和英文资料对齐。对跨国团队、英文产品文档、中文客服场景都很有用。

图片也是类似问题。产品手册里很多信息在图旁边的说明里。RAGFlow 支持在 Chat/Search 中显示图片，可以让答案和原始视觉资料更接近。

Agent 能力则把知识库问答往工作流推进。

例如一个售后助手可以先检索故障说明，再根据故障类型调用工单创建流程。代码组件还能做简单脚本处理，比如把检索到的销售表格清洗后再生成报告。

初学者怎么上手

可以从一个很小的例子开始。

准备三份资料：

产品 FAQ
售后政策
设备手册

然后做四件事：

上传资料
检查 chunk 是否合理
用检索测试问几个真实问题
创建聊天助手并检查引用

一个测试问题可以是：

设备开机后指示灯一直闪怎么办？

如果检索命中了设备手册里的故障处理章节，并且答案引用了正确位置，说明知识库初步可用。

另一个测试问题可以是：

拆封商品还能退吗？

如果系统检索到了售后政策中的例外条款，而不是只找到普通退货规则，说明检索质量更接近真实业务要求。

RAGFlow 和普通 RAG Demo 的区别

普通 RAG Demo 常见链路是：

文本 -> 切块 -> 向量库 -> 问答

RAGFlow 更像：

复杂文档 -> 文档理解 -> 模板化分块 -> 混合检索 -> 引用溯源 -> 聊天或 Agent

差别不在概念，而在工程细节。真实应用里，文档解析、分块策略、检索测试、引用校验往往比“调用哪个模型”更影响效果。

资料校验

RAGFlow 的定位、Deep document understanding、template-based chunking、grounded citations、多源数据支持等信息来自官方 GitHub README。关于检索组件中关键词相似度、向量相似度、rerank score、Top N 等概念，参考了 RAGFlow retrieval component 文档。关于 rerank 延迟、多语言搜索、图片显示和引用改进，参考了 RAGFlow release notes。