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