今年3月有个做工业设备的客户来找我，说他们花8万块搭了个客服Agent，接的大模型也不差，但上线之后天天答非所问。客户问减速机型号选型，它回答润滑油更换周期；客户问保修政策，它报了个不存在的产品编号。他们的研发总监张工折腾了一个多月，换了三个大模型，从通义千问换到文心一言再换到DeepSeek，结果都一样烂。
张工当时快崩溃了，觉得是大模型能力不行。我让他把知识库的数据处理流程发给我看了一眼，问题立刻就清楚了。他们的知识库里有大量产品参数表、技术规格书和售后政策文档，全部用的是500字固定长度切片。这个切片方式把一张完整的减速机参数表从中间切成了两半，型号在第一个切片里，对应的技术参数在第二个切片里。Agent检索的时候只抓到了半个表，回答当然驴唇不对马嘴。
这个问题的本质不是大模型不行，是喂给大模型的原料出了问题。你把一份完整的文档切成碎片，碎片之间丢失了上下文关系，大模型再聪明也拼不回来。今天我就把知识库切片策略这个事情讲透，搞Agent的企业一定能用上。
知识库切片是Agent开发里最容易被忽视、但影响最大的环节。很多人以为接个大模型就完事了，其实大模型只是大脑，知识库切片才是喂给大脑的信息。信息喂错了，大脑再好使也没用。下面我从几个具体问题说起。
固定长度切片最大的问题，是把一张完整的表切成了两半
固定长度切片是最常见的做法，也是最坑的做法。它的逻辑很简单：把文档按固定字数切成一段一段的，每段300字或者500字，存到向量数据库里。听起来没毛病，但实际操作中问题大了去了。张工他们的产品参数表是这样的：一张表有20行，每行包含型号、功率、转速、重量、价格5个字段。500字一刀切下去，前12行在第一个切片里，后8行在第二个切片里。客户问第15行的产品参数，Agent检索到第二个切片，但第二个切片里没有表头，大模型根本不知道那些数字代表什么含义。
这还不是最惨的。有些参数表一行就有200多字，500字的切片刚好把一行的内容从中间截断。比如某型号的参数描述是”该型号适用于重载工况环境，额定功率15kW，输出转速1450rpm，建议配套使用XL系列联轴器”。切片恰好从”输出转速”后面切断了，后半句”建议配套使用XL系列联轴器”跑到下一个切片里去了。客户问这个型号需要配什么联轴器，Agent在当前切片里找不到答案，就瞎编了一个。这就是答非所问的根源。
正确的做法是什么？对于表格类内容，绝对不能用固定长度切片。你要按照表格的自然结构来切，一行一个切片或者一张表一个切片，确保每个切片里的信息是完整的。现在主流的文档解析工具都支持按表格结构切分，比如把Markdown表格整张提取出来作为一个切片，或者按行拆分但每行都带上表头信息。这样Agent检索到任何一行都能知道每个字段的含义，回答就准确了。
张工他们的参数表改用按行切片之后，每个切片包含完整的表头加一行数据，大概100到150字。Agent检索的时候能准确命中具体型号，回答的参数完全正确。就这一个改动，准确率从40%直接跳到65%。
语义切片听起来高级，但没有边界标记照样乱
有些企业知道固定切片不好，就改用了语义切片。语义切片的原理是用算法判断文本的语义边界，在语义自然断开的地方切分。理论上比固定切片高级很多，但实际用起来也有坑。最大的问题是语义切片算法对文档格式有要求，你的文档格式不规范，语义切片照样切错。
张工他们的技术规格书是Word文档转的纯文本，格式信息全丢了。章节之间没有明确分隔符，段落之间混在一起。语义切片算法在这种文本上表现很差，因为它找不到清晰的语义边界。切出来的切片有时候包含两个章节的内容，有时候把一个段落切成了两半，比固定切片好不到哪去。
解决这个问题的办法是在文档预处理阶段就做好结构化标记。你把Word文档转成Markdown格式，用井号标注章节层级，用分隔线标注章节边界，用表格语法标注表格结构。然后语义切片算法就能识别这些标记，在正确的位置切分。我帮张工团队写了一个文档预处理脚本，把他们的200多份Word文档批量转成结构化Markdown，语义切片的效果立刻好了很多。
还有一个技巧是在每个切片的开头加上上下文摘要。比如一个切片是从第三章”售后政策”里切出来的，你在切片内容前面加一句”以下内容来自第三章售后政策”。这样大模型在生成回答的时候就知道这段信息的上下文背景，回答会更准确。这个技巧看起来简单，但效果非常显著，我测试过加上下文摘要之后准确率能提升10到15个百分点。
想让Agent答得准，切片的时候必须带上元数据
元数据是知识库切片里最容易被忽略的东西。很多人只存了文本内容，没存任何元数据信息。结果就是Agent检索到一段文字，但不知道这段文字来自哪个文档、属于哪个章节、是什么时间发布的。张工他们的知识库就是纯文本切片，没有元数据。客户问最新的保修政策，Agent可能检索到三年前的旧政策来回答，因为旧政策和新政策在向量空间里很接近。
元数据应该包含哪些信息？我给张工团队定的标准是这样的：每个切片必须带上文档标题、章节路径、文档类型（产品手册/售后政策/技术规格）、发布日期、有效状态（有效/已废止）。这些元数据存在向量数据库的metadata字段里，检索的时候可以作为过滤条件。客户问保修政策，Agent在检索的时候先过滤”文档类型=售后政策”且”有效状态=有效”的切片，从结果里再找最相关的。这样就不会检索到过期的旧文档了。
元数据还有一个重要作用是提升检索精度。向量检索是基于语义相似度的，有时候两个完全不同的话题在向量空间里距离很近，导致误检索。加上元数据过滤之后，你可以缩小检索范围，减少误命中的概率。张工团队加上元数据过滤之后，误检索率从30%降到了8%左右。这个提升非常明显，客户感受最深的就是Agent不再胡说八道了。
给切片加元数据的工作量取决于你的文档管理规范程度。如果你的文档本身有良好的命名规范和目录结构，写个脚本批量提取元数据并不难。但如果文档乱七八糟堆在一起，你就得先做文档治理再建知识库。这也是为什么我说Agent开发最大的坑不是代码，是数据准备。你数据没整理好，再好的大模型和检索算法都救不回来。
从40%到92%准确率，我帮客户调整切片策略的完整过程
我帮张工团队做的完整调整分四步。第一步是文档预处理，把200多份Word文档全部转成结构化Markdown，补全章节标记和表格语法。这一步花了一周时间，主要是写转换脚本和人工校验。第二步是改切片策略，表格类内容按行切分带表头，段落类内容用语义切分加章节边界标记，每个切片前面加上下文摘要。这一步花了三天调试。第三步是加元数据，给每个切片标注文档类型、发布日期和有效状态，在检索时做metadata过滤。这一步两天搞定。第四步是测试调优，准备了200个真实客户问题做测试集，跑了三轮测试调整切片大小和检索参数。
最终的测试结果是这样的：200个测试问题里，184个回答准确，准确率92%。跟之前的40%比提升了52个百分点。张工看到这个数据的时候整个人都松弛了，说折腾了一个多月终于搞定了。而且关键是什么？这个提升跟大模型一点关系都没有，我们最后用的还是最初那个通义千问。全部的改进都来自知识库切片策略的优化。
我后来复盘了一下这个项目，最大的教训是企业在做Agent的时候，把90%的精力花在了选大模型和写prompt上，只留10%的精力给数据处理。这个比例完全反了。正确的比例应该是70%的精力花在数据准备和切片策略上，20%花在检索调优上，10%花在大模型选择和prompt工程上。你的知识库切片做不好，用GPT-4o也是垃圾进垃圾出。切片做好了，用便宜的小模型照样能跑出好效果。
如果你正在做或者准备做企业Agent，我建议你在动手写代码之前先花一周时间把知识库的数据结构理清楚。你的文档是什么格式、有哪些类型、表格和段落各占多少比例、需要哪些元数据字段。把这些想清楚了再选切片策略，能少走很多弯路。张工团队就是吃了这个亏，先上线再发现问题，返工的成本比从头来过还高。
需要相关服务？联系我们免费咨询
九五星球企服提供公司注册、代理记账、商标注册、财税咨询、高新申报、网站开发等一站式企业服务。可以先免费咨询看看，觉得合适再合作，不推销。
免费小工具推荐：
联系方式：
- 电话/微信：18910232032
- 扫码添加专业经营合规顾问，免费咨询 ↓
