夜雨聆风你一定经历过这种时刻：把一份几十页的产品手册 PDF 丢进公司的知识库，问它一个手册里明明写着的问题，它却答得驴唇不对马嘴。你的第一反应往往是——模型不够聪明，换个更大的。
但如果你打开后台看一眼喂给模型的内容，可能会发现真正的问题：那份排版整齐的手册，在进入模型之前，已经被按字数硬切成了一段段。标题和正文被切断，一张三列表格被劈成三瓣，跨页的一段说明从中间断开。模型不是不会答，它拿到的本来就是碎片。
这篇文章要拆的开源项目叫 RAGFlow，它要解决的正是这个问题：在问题到达大模型之前，先把文档读懂、切对。 我们跟着一份带标题和表格的 PDF 手册，走一遍从上传到回答的全过程，看它具体做了什么、代价是什么、什么时候值得用。
假设手册里有这样一个表格，写着不同套餐的价格和权限：
如果用最简单的"每凑够 500 字就切一刀"，这张表很可能从中间断开：上一个片段只拿到"专业版 299 元"，下一个片段拿到"10 企业版 洽谈 不限"。当有人问"专业版多少钱"，检索到的可能是那半张残缺的表，模型只能猜。
RAGFlow 的做法不同。它在切之前，会先识别出"这一块是表格"，然后把整张表作为一个完整单元保留下来，还原成有行有列的结构。这样无论问题落到哪一行，检索拿到的都是完整的一张表，而不是半句残文。
这个差别听起来朴素，但它决定了知识库回答的上限。下面我们拆开看它是怎么做到的。
RAGFlow 里负责看文档的部分叫 DeepDoc。当一份 PDF 进来，它不是急着抽文字，而是先把每一页渲染成图像，然后做三件事。
第一件是文字识别。对能直接取出文字层的 PDF，它优先用文字层；对扫描件或者文字层是乱码的情况（有些 PDF 用了特殊字体编码，复制出来全是奇怪符号），它会回退到 OCR，也就是把图片里的字认出来。OCR 由两个小模型配合：一个负责框出每一行文字在哪里，一个负责认出框里是什么字。
第二件是版面识别。它会判断页面上每一块分别是什么——是标题、正文、表格、图片，还是页眉页脚。这一步很关键，因为知道了"这是标题"，后面切片时才能让标题跟它下面的正文待在一起，而不是孤零零地被切到上一段末尾。
第三件是表格结构识别。它不光知道"这里有个表格"，还能认出有几行几列、谁是表头、哪些格子合并了，然后把表格重建成结构化的样子。前面那张套餐表能完整保留，靠的就是这一步。
这三件事用的都是本地运行的视觉模型，不需要把你的文档发给外部服务。它们随项目一起分发，第一次运行时会自动下载。换句话说，"读懂版面"这件事发生在你自己的机器上。
打个比方：硬切就像撕报纸，不管文章到哪儿，撕到哪算哪；DeepDoc 更像一个真人先通读版面，用荧光笔标出标题、正文和表格，再沿着它们本来的边界裁剪。这个比喻也有不完全成立的地方——真人靠理解语义，而 DeepDoc 靠的是视觉模型识别版面结构，它并不真的"读懂"文章在讲什么，它认得的是长什么样。
读懂版面之后才进入切片。RAGFlow 为不同种类的文档准备了不同的切法，在代码里可以看到一长串：通用、论文、书籍、法律、手册、简历、问答、表格、演示文稿、图片等等。
为什么要分这么细？因为不同文档的"完整语义单元"不一样。法律条款要按"条"来切，不能把同一条拦腰斩断；书籍和论文要顺着标题层级，让一节内容尽量待在一起；简历本身就是结构化信息，可以按字段抽取；问答类文档则适合一问一答成对保存。
对最常见的通用文档，它用一个相对简单但靠谱的规则：顺着段落往下累加，字数或 token 数达到一个阈值（默认约 512 个 token，你可以把 token 粗略理解成"字或词的片段"，512 个 token 对中文大致相当于三四百字）就另起一块，同时在相邻块之间留一点重叠，避免一句话正好在边界被切断。表格因为前面已经被识别出来，会单独成块、不被文字阈值切散。每个切下来的块还会记着自己来自第几页、在页面上的什么坐标位置。
这里有个值得注意的事实：切片这一步并不调用大模型。它靠的是版面识别的结果加上 token 计数和分隔规则，速度快、成本低、结果稳定。大模型在 RAGFlow 里主要用在更后面的"生成回答"，以及一些可选的增强环节（比如自动给片段生成可能被问到的问题、对长文档做层次化摘要），但这些都不是默认切片的必经之路。
这也解释了一个常见误解：有人以为"智能切片"就是让大模型读完文档自己决定怎么切。RAGFlow 选择的是更工程化的路线——用专门的视觉模型处理结构化的版面问题，把大模型留给真正需要语言理解的地方。
文档被切成块、存进检索引擎之后，就到了提问环节。当你问"专业版多少钱"，RAGFlow 会同时从两条路找答案。
一条是语义检索：用一个"向量模型"把你的问题转成一串数字（这串数字叫向量，可以理解成这段话语义的坐标），再去库里找坐标最接近的片段，即使字面不一样也能匹配，比如你问"多少钱"能匹配到写着"月费 299 元"的块。另一条是关键词检索：按词的匹配和权重找，专有名词、产品名、数字这种"字面对得上很重要"的内容更依赖它。两条路的结果会按一个比例加权合并，默认语义占三成、关键词占七成——这个比例可以调，文档越依赖专有名词，关键词那一头就越重要。
找回来一批候选之后，还可以选择加一道重排。重排是用一个专门的模型，把"问题"和"每个候选片段"成对过一遍，重新判断谁真的相关、谁只是沾边，然后重新排序。它能显著提升命中率，但也多一次模型调用的延迟和成本，所以默认是关闭的，需要你手动选一个重排模型（比如开源的 bge-reranker）才开启。
最后，最相关的几块被拼进提示词，交给大模型生成回答。RAGFlow 还会做一件很多人看重的事：让答案带上出处。它会让模型在每句话末尾标一个来源编号，编号对应到具体的片段，而每个片段都记着来自哪个文档、第几页。前端据此可以做到点一下编号就跳回原文那一页，对应位置还能高亮。这在企业场景里很重要——回答对不对，使用者能自己核实，而不是只能选择相信。
上面这条"解析—切片—混合检索—重排—带出处回答"是默认就走的主链路。除此之外，RAGFlow 还提供了一些需要你主动开启的高级能力，了解一下边界有助于判断它能走多远。
一个是把检索、分类、调用不同模型、调用外部工具这些步骤，用一张可视化的画布连成流程图（类似一张有向图，数据沿着节点之间的连线流动），用来做比"一问一答"更复杂的企业流程，比如先判断问题类型、再决定查哪个库、最后调不同的模型。另一个是把长文档递归地逐层总结成一棵"摘要树"，提问时能同时利用细节和高层概括，适合手册、论文这种篇幅很长的资料。它还支持把文档里的实体和关系抽成知识图谱，以及对外提供 MCP 服务（一种让 AI 工具能标准化调用外部能力的协议）。
需要强调的是，这些都不是默认路径，也不是每次都该开：它们各自带来额外的模型调用成本和复杂度。对大多数知识库来说，先把"切对、找对、标好来源"这条主链路跑通，收益最大；只有当主链路确实满足不了，才值得逐个评估这些增强。
理解了主链路，适用边界就比较清楚了。
RAGFlow 最能发挥价值的场景，是你的资料里有大量复杂文档：PDF 尤其是扫描件、表格、合同、论文、产品手册、财报，而且你需要答案能溯源到具体出处，或者需要在自己的服务器上私有部署。它还提供一个可视化的画布，可以把"检索—分类—调用模型—调用工具"连成流程，适合做比简单问答更复杂的企业应用。
但它不是一个轻量选择。它是一整套平台，依赖数据库、缓存、对象存储和检索引擎（可以选 Elasticsearch 或它自家的 Infinity），部署和运维都有成本。大模型和向量模型也需要你自己准备，要么接 API，要么自己部署。
如果你的资料主要是 Markdown 和纯文本、量也不大、没有复杂表格，那用一个向量库加一小段切分代码可能就够了，犯不上扛起整个平台。工具的价值和它的重量是绑在一起的。
回到开头那个问题：知识库答错，先别怪模型。沿着这条链路你会发现，大量错误其实发生在更前面——文件被切碎了、表格被劈断了、召回的片段不对。RAGFlow 给出的答案是：在内容进入模型之前，先用专门的文档理解能力把它切对，再用混合检索找对，最后用来源标注让人能核实。
想上手的话，可以从它的 Docker 部署开始，先拿一份你自己工作里最头疼的 PDF 试，重点看两件事：表格有没有被完整保留，回答的来源能不能对上原文。这两点过了，再考虑要不要把它接进正式系统。
毕竟，让大模型回答得好的前提，是先给它看得懂的材料。
