构建企业知识库时如何处理文档分块?

企业知识库检索不准，很多时候不是模型不行，而是文档分块一开始就切错了。客服明明问的是一个完整问题，系统却只捞出半句定义；答案确实在库里，但上下文被切散了，最后看起来就像“知识库没有这条内容”。我做这类 RAG 知识库时，最先检查的通常不是向量库，而是分块方式。

先按语义切，不要只按字数切

分块不是拿剪刀平均裁纸。产品手册里的一个小节、FAQ里的一组问答、制度文件中的一条规则，往往都应该尽量保持完整。标题、适用条件、操作步骤和例外说明如果被拆到不同片段里，检索即使找到了关键词，模型也可能缺少真正能回答问题的依据。

当然，块也不能无限大。切得太碎，命中会更精准，但上下文容易丢；切得太大，信息虽然完整，噪声也会跟着增加。原文中提到的 200—800 字可以作为初始试验范围，但别把它当成死规定。FAQ可能适合更小的完整问答，复杂流程则需要保留更多前后关系，关键是让一个片段尽可能独立表达一个知识点。

我会重点保留三类信息

第一是标题和层级。片段脱离原文后，最好还能看出它属于哪个产品、流程或制度。第二是条件和限制，比如“什么情况下适用”“谁负责处理”“有哪些例外”。第三是指向关系，像“见下一步”“按照上文定义”这类表述，单独拿出来通常很难使用。

表格、PDF和图片尤其容易踩坑。直接把文件扔进系统，文本顺序可能已经乱了。我之前就遇到过这种情况：看起来文档成功入库，检索结果却完全不对路。更稳妥的做法是先处理 OCR 和结构化字段，再进行分块；必要时把表格内容改成能够独立阅读的文本。

别凭感觉决定方案

同一批文档可以尝试不同切法，拿真实客服问题做对比。重点看两件事：相关片段能不能被召回，以及召回后是否保留了回答所需的上下文。若短块命中率不错但回答经常缺条件，就需要适当合并；若长块总是夹带大量无关内容，就继续按语义边界拆分。

我最建议的节奏是先挑客服或销售中的一个小场景，收集检索错误样本，再针对“切碎、切大、标题丢失、条件分离”这些问题逐个调整。分块没有万能模板，真正好用的标准只有一个：片段被单独拿出来时，既能被准确找到，也足以支撑一次可靠回答。