把 MES 设备手册做成 RAG 友好语料——长文档切片的工程实践

在 MES（制造执行系统）实施项目里，现场工程师最常提的一类需求是："这台设备的换型参数在哪份手册里""某个工单的报工逻辑为什么和 SOP 对不上"。他们希望直接把问题抛给内部的检索/问答系统，而不是在几十页 PDF 里翻。但现实是：设备手册、BOM 清单、工单模板、SOP 文档动辄上百页，直接整篇向量化后再检索，召回结果要么太碎、要么把表格从中间切断，答案质量很差。这篇文章分享我们在制造业知识库项目里沉淀的长文档切片方法，以及踩过的几个坑。

一、为什么"按固定字数一刀切"不行

很多团队第一次做 RAG，直接把文档按 500 字一个窗口滑动切分。在 MES 场景这会立刻出问题：

• chunk 太大（比如 2000 字）：一个块里混了多台设备、多个工序的描述，向量表示被"平均"掉，用户问"XX-200 型号的换型步骤"会召回一堆无关段落。
• chunk 太小（比如 200 字）：把一张"参数对照表"从中间劈成两半，检索回来半张表，LLM 根本拼不出完整答案。
• 丢失结构上下文：脱离"第 3 章 设备维护 → 3.2 换型操作"这样的标题路径后，单独一句"拧松 4 颗 M8 螺栓"失去了归属，模型不知道它属于哪台设备。

二、基于结构层级的递归切片

我们的核心思路是：不按字数切，而是按文档原有的标题层级（H1/H2/H3）+ 列表 + 表格边界递归切分，每个 chunk 保留"祖先标题链"作为上下文元数据。流程如下：

flowchart TD
    A[原始文档 PDF/Markdown] --> B[结构解析：识别标题层级/列表/表格]
    B --> C[按 H2 分块]
    C --> D{单块超阈值?}
    D -- 是 --> E[按 H3 再拆]
    E --> F{仍超阈值?}
    F -- 是 --> G[按段落二分 + 10% 重叠]
    D -- 否 --> H[表格整体成块/保留表头]
    F -- 否 --> H
    G --> I[注入 frontmatter 元数据]
    H --> I
    I --> J[向量化 + 带元数据入库]

下面是递归切分的示意实现（基于 Markdown 标题，生产环境可换成 PDF 解析器的段落树）：

三、三个踩过的坑（实践视角）

1. 表格被劈成两半：最早我们允许表格参与字数二分，结果一张"扭矩对照表"断了，召回回来只有半截列名。后来强制"表格整体作为一个 chunk"，用 | 分隔符保留结构，问题消失。
2. 重叠窗口设成 0：跨段语义断裂，比如"步骤 3 接步骤 2"被切到两个块，模型拼不出连续动作。设 10% overlap（约 120 字）后，跨段指代明显好转。
3. 丢失设备型号元数据：检索时只能靠全文匹配，区分不了"XX-200"和"XX-500"。后来每个 chunk 注入 frontmatter（设备型号 / 工序 / 文档版本），检索时用元数据过滤，精确率提升明显。

四、检索侧怎么配合

切片只是前半段。检索时务必把 ancestors 标题链拼到 chunk 文本前面再向量化，这样"3.2 换型操作"的上下文会进入向量；同时保留 meta 供结果过滤（如只查某型号）。我们实测，同样的问题，带标题链+元数据的召回命中率比纯正文高出一个量级。

五、FAQ

Q1：chunk 定多大合适？

没有银弹。技术手册类建议 800–1500 字，表格/代码整体保留；对话类短文可更小。先用 1200 字跑一版评测再调。

Q2：表格到底怎么处理最稳？

整体作为一个 chunk，表头必须保留在块内，不要参与字数二分。超长宽表可转成"字段名:值"的列表再切。

Q3：元数据（ancestors）有什么用？

两件事：向量化时拼到文本前补上下文；检索后按设备/版本过滤，避免跨型号串味。

Q4：重叠窗口会不会让存储和成本翻倍？

10% overlap 增加约 10% 向量数，换来跨段连贯性，性价比高；超过 20% 收益递减。

Q5：手册版本更新了怎么办？

用文档版本号做 meta，更新时整批按版本重建对应 chunk，旧版本保留历史供追溯，不要原地覆盖。

作者：默然｜数智化转型网