我为什么研究RAGFlow：RuyiBookCourse遇到复杂文档解析后必须想清楚的事
OK，OK，大家好，欢迎大家来到大鹏 AI 教育，我是张大鹏。
这篇文章讲RAGFlow。
但我不是为了追热点才研究它。
我研究 RAGFlow，是因为RuyiBookCourse正好走到了一个非常现实的位置：
电子书解析不是把文字拿出来就完了。如果我要把电子书变成课程，真正难的不是“抽取文本”这四个字。
真正难的是：目录、章节、表格、代码、图片说明、页眉页脚、参考资料，这些结构能不能被理解，能不能被保留下来，能不能在后续问答和课程生成里继续发挥作用。
这就是 RAGFlow 对我有参考价值的地方。
RAGFlow到底是什么
RAGFlow 官方把它定位为基于深度文档理解的开源 RAG 引擎。
这个定位里最关键的不是“RAG”，而是“深度文档理解”。
普通 RAG 系统最容易犯的错误，是把文档直接切成很多文本块，然后丢进向量库。
这对简单文章可以用。
但对复杂文档不够。
比如：
- 教材 PDF
- 技术手册
- 财报
- 表格很多的资料
- 论文
- 版式复杂的扫描文档
这些资料的问题不是“有没有文字”，而是“文字之间的关系有没有被理解”。
RAGFlow 强调的正是这件事。
它不是只做聊天页面，而是更关注文档进入知识库之前，解析、切分、结构理解这一步能不能做好。
这给RuyiBookCourse什么启发
RuyiBookCourse的目标是电子书转课程。
这件事听起来像内容处理，其实很像文档理解。
一本技术书里，章节标题、代码块、表格、图示、练习、总结、参考资料，都不是普通文本。
如果解析阶段把这些结构打碎了，后面再强的模型也只能在混乱材料上工作。
所以我看 RAGFlow，不是因为我要马上把它接进项目。
我更关心它背后的产品判断：
RAG 的质量，首先取决于文档进入系统时的质量。这句话对RuyiBookCourse很重要。
我现在做src\parse，本质上就是在为后面的 RAG 和课程生成打地基。
如果解析层不稳定，后面写再多 prompt 都是在补洞。
RAGFlow强在哪里
我的理解里，RAGFlow 的强点主要有三个。
第一，它把文档理解放在前面。
官方文档和仓库都在强调复杂格式数据、deep document understanding、well-founded citations。
这说明它不是只把 RAG 当成“向量搜索 + 聊天”。
第二，它重视可引用。
对课程生产来说，引用很重要。
我不能只要 AI 说“应该先学 scales”，我还要知道这个判断来自哪本书、哪一章、哪一段。
第三，它适合处理复杂资料。
RAGFlow 的 DeepDoc 相关资料里提到版面识别、表格结构识别等能力。
这对电子书、教材、技术 PDF 都很关键。
我为什么没有立刻接入RAGFlow
这点我想说清楚。
我研究 RAGFlow，不等于我现在就要把它部署进RuyiBookCourse。
我的项目当前还在打底层链路。
我现在更需要确认：
- 本地 EPUB/PDF 解析是否稳定
- 章节 Markdown 是否干净
- 输出目录是否统一
- RAG chunk 规则是否适合课程生产
- CLI 能否先跑通最小闭环
如果这些基础还没稳定，就先上一个完整平台，反而会让问题变复杂。
所以我的策略是：
先学习 RAGFlow 的设计思想，再决定是否接入它。这个顺序很重要。
什么时候我会考虑接入RAGFlow
如果后面RuyiBookCourse遇到这些情况，我会认真考虑接入 RAGFlow：
- PDF 版式越来越复杂
- 表格和图片说明越来越多
- 自己维护解析器成本明显变高
- 需要可视化管理知识库
- 需要更完整的文档问答后台
- 需要多人协作处理资料
这时候 RAGFlow 可能会成为一个合适的外部能力。
但在当前阶段，我更倾向于先把项目自己的解析和课程化链路跑通。
我的结论
RAGFlow 对我最大的价值，不是告诉我“换一个知识库平台”。
它提醒我一件更底层的事：
电子书转课程，第一关是文档理解，不是聊天。如果我把这个判断落实到RuyiBookCourse，那接下来就应该继续优化src\parse，继续让章节 Markdown 更干净、更可追溯、更适合 RAG。
平台可以以后再接。
但文档理解这件事，现在就要做好。
参考资料
- RAGFlow 官方文档：https://ragflow.io/docs/
- RAGFlow GitHub：https://github.com/infiniflow/ragflow
- RAGFlow DeepDoc：https://github.com/infiniflow/ragflow/blob/main/deepdoc/README.md