RAGFlow 装好了还在什么都用 General 切？这份 11 种切片方法选择表值得存

你有没有见过这样的场景：PDF、Word、Excel 一股脑拖进 RAGFlow，切片方法全程默认，结果一问问题——表格散了架、手册章节串了台、扫描页直接变天书。

这时候多数人的第一反应是换模型、调提示词，甚至怀疑 RAGFlow 不过如此。但看看知乎、B站、小红书上这半年的讨论，会发现真正的共识恰恰相反：RAGFlow 能在 8 万多 Star 的开源 RAG 赛道里站住脚，靠的就是深度文档理解，而这个能力藏在创建知识库时那个不起眼的「切片方法」下拉框里。哔哩哔哩知乎选不对方法，等于核心卖点没用上，拿它当了个普通切分器。

这篇不聊安装部署（最近聊得太多了），也不做问答质量排查，只解决一件事：什么文档配什么切片方法，社区里踩过的坑有哪些，一次讲清楚，建议先收藏再对照操作。

先花 30 秒搞懂：切片方法到底在切什么

RAGFlow 默认不是按固定长度硬切文本。它的 DeepDoc 模块会先「看」一遍文档：做版面识别（标题、段落、图表位置）、表格结构识别、扫描件 OCR，然后再按结构下刀。小红书这也是它处理复杂 PDF 时口碑明显好于很多同类工具的原因。知乎

而「切片方法」（Chunk Method），就是你给 RAGFlow 选的切分模板——告诉它「这是一份什么文档」，它就用对应的策略去组织切片。截至 0.26 版本，官方内置 11 种常用方法，外加知识图谱这类进阶选项。小红书哔哩哔哩大多数人的问题不是方法不够多，而是从头到尾只用了默认的 General。

一张表：什么文档配什么方法

这个对应关系不是我拍脑袋：RAGFlow 官方文档和社区的参数配置实践里，基本都是按「文件格式 + 文档体裁」两个维度来匹配方法的，比如有工程实践帖直接给出「Word 用 General、Excel 用 Table」的组合模板。知乎

高频方法细说：哪些真有用，哪些是摆设

General：默认，但别当唯一。 它是覆盖面最广的方法，普通文本类文档用它没毛病。但它的定位是「不知道选什么的时候选它」，而不是「选它总没错」。手册、表格、FAQ 这类结构特征明显的文档，换成专用方法提升是肉眼可见的。

Manual：被低估的一个。 各种设备手册、运维手册、员工手册往往是企业知识库的大头，这类文档层级深、编号多，General 切完经常章节错位。Manual 就是为这种场景做的，做制造业、运维类知识库的值得优先试。

Table：表格救星，但有个坑。 Excel、CSV 用它切，每一行数据会被组织成结构化切片，问「某型号参数是多少」这类精确查询时命中率明显更高。但社区有人吐槽：表格按 Table 方式切完非常规整、一共 113 个块，结果在聊天里调用本地模型回答时却没能完全发挥作用。小红书表格类问答还受模型上下文和检索条数影响，别指望切对了就一劳永逸。

Q&A：格式不对别硬用。 这个方法要求文档本身就是「问题-答案」成对的结构，适合现成的 FAQ 文档。社区吐槽点在于：通过 API 往 Q&A 模式的知识库添加解析块时，字段设计和 Dify 那套问答对逻辑不一样，习惯 Dify 的用户迁移过来容易懵。小红书文档不是现成问答格式的，老老实实用 General。

One：短文档的隐藏神器。 整份文档作为一个切片，听起来很蠢，但对制度文件、通知公告这类「必须整体理解」的短文档反而是最优解——避免关键信息被切断在两个切片里。长文档千万别用。

Resume 和 Tag：两个场景专用项。 Resume 是给 HR 场景准备的，把各种格式的简历解析成结构化字段，不做招聘基本用不上，但真建简历库时它就是最专业的。Tag 则低调得多：它把文档解析成「标签库」，其他知识库可以引用这个标签库给自己的切片自动打标——做多库分类体系时，这个能省不少手工整理的工夫。

知识图谱：藏在配置页的进阶开关。 严格说它不在切片方法下拉框里，而是知识库配置页上的「提取知识图谱」开关。知乎开启后解析时会同步抽取实体和关系，实体类型还能自定义，答「A 和 B 什么关系」这类多跳问题时有奇效。知乎代价是解析速度远慢于普通切片，只建议对确实有复杂关系查询需求的核心文档开启，别全库打开。

社区踩坑清单：这几条能省你一晚上

1. 解析慢，大概率不是玄学。 RAGFlow 解析慢是知乎上的高频提问，瓶颈主要在 DeepDoc 的版面识别。能上 GPU 就上 GPU；纯 CPU 环境可以调大任务执行器数量（`–workers`）；另外解析速度跟具体方法、配置有关，要求不高的纯文本库，可以评估关掉重量级的版面识别。知乎

2. 扫描件先自查 OCR 效果。 扫描版 PDF 入库前，先点开解析结果看看文字层对不对。OCR 识别错了，后面换什么模型都救不回来——垃圾进垃圾出，在 RAG 里体现得特别直接。

3. 换方法 = 重新解析。 切片方法是知识库级别的设置，改了方法要重新上传解析。所以建议一开始就按文档类型分库：手册一个库、表格一个库、FAQ 一个库，既方便选方法，也方便后面分别调检索参数。

4. 别把参数调优当第一步。 切片 token 大小、分隔符这些参数当然能调，但优先级永远排在「方法选对」之后。方法错了，参数是在错误的切法上做微调。

往前看：解析这件事，RAGFlow 还在加码

如果你最近关注了 8 月 20 日 InfiniFlow 官方发布的 v0.27.0，可能会担心新版本会不会折腾解析这块。知乎梳理一下公开信息，给还在观望的你三个判断：

第一，0.27 是最后一个以 Python 为后端的大版本，下个版本起迁移到 Go。知乎对普通用户，部署方式（Docker 一键起）不会有体感变化；但对准备做二次开发的团队，现在基于 Python 后端做的定制代码，要开始评估迁移成本了。

第二，0.27 的重头戏是「知识编译引擎」。 官方给出的方向是把文档解析、知识加工从「问答时处理」进一步变成「提前编译好」的资产，配合升级的 Agentic Retrieval，让 RAGFlow 从问答工具往「服务各类 Agent 框架的数据基座」转。知乎说白了，官方也认为解析和知识加工是整条链路里最值得砸资源的地方——这跟你现在把切片方法选对的收益，是同一个方向。

第三，老知识库不用急着推翻重来。 从 0.21 的 Ingestion Pipeline 到 0.26 的解析持续改进，官方对存量数据的升级路径一直是重点维护项，之前还专门发过无缝升级指引。知乎知乎按文档类型分库的习惯，在版本迭代时会让你从容很多。

总结

RAGFlow 的上限由文档解析决定，而解析的上限很大程度取决于你选的那个切片方法。记住三句话：结构明显的文档别用 General 硬切；按文档类型分库；方法选对之前别急着调参数。

如果你正在搭或者已经搭了 RAGFlow 知识库，不妨现在就打开知识库设置看一眼：你的每一份文档，真的配对了方法吗？