第 2.3.1 节：先判断知识内容应该如何分块
进入实现之前，先围绕“先判断知识内容应该如何分块”划清适用场景、不做范围和判断条件。完成本节后，你应该能够写出知识内容应该如何分块的适用场景、不适用场景、前置条件和进入工程实现的判断标准。
本章要解决什么问题
做 RAG（检索增强生成）项目时，新手最常遇到的挫败不是“模型不会说话”，而是：资料明明在知识库里，Agent（智能体）却没有找到；或者找到了错误资料，模型还把错误资料说得很像真的。
在企业客服知识库与工单 Agent 工作台里，这个问题非常具体。客户问“签收 7 天内设备故障能不能换货”，资料库里确实有售后政策；客户问“企业版账号席位怎么增加”，产品手册里也有说明；客户问“投诉物流延误需要准备什么材料”，客服 SOP（标准作业流程）里写得很清楚。但如果系统检索出来的是旧版政策、相邻产品线资料、只有标题没有处理条件的片段，最终回答仍然会错。
这类错误通常不是生成模型单独造成的，而是检索链路共同造成的。RAG 的效果至少由这些决策决定：
- 文档如何清洗、识别标题、表格、问答对和附件。
- 文档怎么分块，条件和结论是否被切开。
- 每个分块是否带有产品线、版本、部门、权限、有效期等元数据。
- Embedding（嵌入向量）模型是否适合当前语言、行业和资料类型。
- 向量索引如何兼顾召回率、速度、成本和更新频率。
- 查询是否需要改写、扩展或拆成多个子问题。
- 召回结果是否经过权限过滤、版本过滤和业务过滤。
- Reranker（重排序器）是否把真正相关的片段排到前面。
- 最终回答是否带有可追溯的引用片段，而不是只给一段看似流畅的总结。
- 是否有评估样例证明优化真的提升了命中质量。
本章带你把“RAG 效果不好”拆成可以排查、可以设计、可以验收的工程问题。
学习目标
学完本章后，读者应该能做到：
- 用人话解释文档分块、Embedding（嵌入向量）、索引、召回和重排分别解决什么问题。
- 说明为什么这些环节共同决定 RAG 效果，而不是只靠换一个大模型解决。
- 为客服知识库设计一套基础分块策略，避免把问题条件、处理结论、适用范围和引用来源切散。
- 为知识片段设计元数据字段，包括来源、版本、产品线、权限、有效期、所属部门和引用位置。
- 区分召回、过滤、重排和构造上下文的职责边界。
- 设计引用片段，让回答能回到具体文档、章节、段落或表格。
- 设计权限过滤，避免客服 Agent 把内部资料、跨客户资料或未发布资料暴露给不该看到的人。
- 准备检索评估样例，用样例证明系统是否命中了正确片段。
- 面试时把 RAG 检索链路讲成工程方案，而不是只背“向量数据库”和“Embedding（嵌入向量）”两个词。
贯穿业务场景
本章继续使用贯穿项目：企业客服知识库与工单 Agent 工作台。
这个工作台面向客服主管、一线客服、售后专员和内部运营人员。它要接入企业资料库，让 Agent 能够回答客户问题、引用依据、判断是否需要查订单或创建工单。知识库里会有这些资料：
| 资料类型 | 例子 | 检索难点 |
|---|---|---|
| 售后政策 | 退换货、维修、退款、质保规则 | 条件多，版本更新频繁，容易命中旧政策。 |
| 产品手册 | 功能说明、使用限制、套餐差异 | 产品线相似，问题容易跨产品误命中。 |
| 客服 SOP（标准作业流程） | 投诉处理、工单分派、升级规则 | 内部资料多，不一定能展示给客户。 |
| FAQ（常见问题） | 常见问答、标准话术 | 问法变化多，需要语义召回。 |
| 表格资料 | 价格表、服务等级、材料清单 | 表格如果被切碎，答案会缺列或缺条件。 |
| 历史工单总结 | 已解决案例、问题复盘 | 涉及客户隐私，必须做权限过滤。 |
我们先看一个典型问题：
客户：我买的企业版设备签收 6 天后发现无法开机，可以直接换货吗？
理想处理流程不是让模型凭常识回答，而是：
- 判断这是售后政策问题，优先走 RAG 检索。
- 根据“企业版设备”“签收 6 天”“无法开机”“换货”形成检索查询。
- 在知识库中只检索当前租户、当前产品线、已发布且仍有效的售后政策。
- 召回相关候选片段。
- 用重排序把包含“签收 7 天内”“硬件故障”“换货条件”“检测材料”的片段排到前面。
- 构造上下文，保留引用片段和来源。
- 让 Agent 回答：可以申请检测换货，但是否直接换货取决于检测结果，并列出需要准备的材料。
- 如果需要进一步处理，再进入工具调用或工单创建流程。
这个例子说明：RAG 不是“把文档塞进向量库”这么简单。检索链路里任何一个环节做错，最后都会表现为“Agent 乱答”。
新手为什么会卡住
新手做知识库问答时，常常会卡在这些地方：
| 卡点 | 表面现象 | 真正原因 | 正确处理 |
|---|---|---|---|
| 只调大 top_k（召回数量） | 召回更多片段但答案仍然不准 | 召回数量增加了，噪声也增加了 | 先看命中的片段是否正确，再决定召回数量和重排策略。 |
| 以为 Embedding（嵌入向量）能理解所有规则 | 语义相近但规则不同的资料被混在一起 | 向量相似不等于业务适用 | 用元数据过滤版本、产品线、权限和有效期。 |
| 固定长度切文档 | 条件和结论分到不同片段 | 分块没有尊重文档结构 | 按标题、段落、表格、问答对和规则条款切分。 |
| 不保留引用来源 | 用户不信答案，客服无法复盘 | 分块缺少来源和位置 | 保存 source_id（来源编号）、heading_path（标题路径）、page_number（页码）和 quote_span（引用范围）。 |
| 不做权限过滤 | 内部 SOP（标准作业流程）被展示给客户 | 只做语义检索，没做访问控制 | 检索前和检索后都要检查权限。 |
| 不做评估样例 | 改了参数不知道有没有变好 | 没有可重复验证的测试集 | 准备问题、期望命中片段、不应命中片段和验收标准。 |
| 把错误都怪模型 | 模型回答看起来错 | 进入模型上下文的资料已经错了 | 先查检索日志，再判断是检索问题还是生成问题。 |
本章的核心目标，就是让读者从“调参碰运气”转向“用工程链路定位问题”。