直接回答
FAQ 按「一问一答」成对切分，政策条款按条款切分并把条款号回填进分块元数据，而且这两类不能进同一个索引——前者靠问题相似度检索，后者靠条款精确匹配，混在一起会互相干扰。
切分决定检索质量
切分不是技术细节，是知识库能不能用准的第一道关口。同一个模型、同一批文档，切分方式不同，答案的对错可能截然相反。很多「模型不行」的抱怨，根子都在这。
FAQ 和政策，必须分开切
- FAQ 类：按「一问一答」成对切分，一个问答就是一个块。用户问什么就直接命中那个答案，不会被旁边的问题干扰。
- 政策 / 条款类：按条款切分，并把条款号回填进分块元数据。检索时能带着条款号回答，用户也能回到原文核对。
这两类不能进同一个索引。原因是它们的检索语义差别很大：FAQ 看的是问题相似度，政策看的是条款精确匹配。混在一起，检索结果会互相稀释，该命中的条款被一堆相似问题挤掉。
fallback 不要退回定长切分
定长切分最省事，也最容易把答案腰斩。如果按语义切分失败，宁可报错，也不要退回定长切分——检索出来的是半句话，模型只能靠猜，猜错了还看不出错在哪。报错至少能让你当场发现切分器有问题，而不是等上线后从客户的抱怨里发现。
分块分桶怎么落地
把内容按类型分桶，每桶用对应的切分器，落到独立索引。检索时先判断问题属于哪一桶，再进对应索引取内容。
| 内容类型 | 切分方式 | 元数据 |
|---|---|---|
| FAQ | 一问一答成对 | 问题、分类 |
| 政策条款 | 按条款切 | 条款号、生效日期 |
切完之后怎么验证
切分做完不能凭感觉。回头跑一遍评测集，重点看 recall@k：想找的内容有没有被召回。如果 recall@k 低，八成还是切分的问题，而不是模型的问题。这套做法看着麻烦，但它决定了后面评测能不能通过。
关键数据
| FAQ 切分 | 按一问一答成对切分，一块即一问一答 |
| 政策切分 | 按条款切分，条款号回填进分块元数据 |
| 索引规则 | FAQ 与政策条款不能进同一个索引 |
| fallback | 宁可报错，也不退回定长切分 |
| 根本原因 | FAQ 靠问题相似度，政策靠条款精确匹配，混索引会互相干扰 |
依据来源
- RAGFlow 官方文档
- 我方 2026 年交付实测
常见追问
为什么不能用定长切分图省事？
定长切分会把一条完整答案从中间截断，检索回来的是半句话，模型无法据此给出准确回答。
条款号回填到元数据有什么用？
让回答能带上出处，用户可回原文核对；同时在检索时支持按条款号精确命中，比纯语义匹配更稳。
一个索引里放多类内容会怎样？
不同检索语义会互相干扰，召回结果被稀释，准确率下降。按内容类型分桶、分索引更可靠。
本页由 合尘猫 SavantCat 发布 · 原文 https://savantcat.cn/answers/enterprise-knowledge-base/how-to-chunk.html · 引用或转载请注明出处。