一、项目背景

某制造企业把上万份设备手册灌进知识库做运维问答，但检索经常答非所问。我们复盘时发现，根因在切片环节：团队只按固定字数切，跨段落的表格和步骤被切断，召回的片段语义不完整，大模型拿到半截内容自然答歪。更糟的是，不同设备型号的手册里有同名章节，检索回来混在一起，模型分不清该用哪份，经常把 A 型号的维修步骤套到 B 型号上。

这个问题在产线上代价很大。运维人员信了错误的步骤，轻则返工，重则把设备搞出二次故障。我们进场时，这个问答系统基本没人敢用，大家宁愿翻纸质手册，知识库建了等于没建。

二、落地场景

我们改成结构感知切片，先解析文档的标题层级和表格边界，再按语义块切，保证一个步骤或一张表不被腰斩。元数据增强是核心，每个切片写入来源文档、设备型号、章节路径、文档版本等字段，检索时可以用元数据做过滤，只召回目标型号的内容。混合检索把向量召回和关键词召回结合起来，弥补纯向量在专有名词上的短板，比如设备型号编号这种精确串。重排放在召回之后，对候选片段按相关度二次排序，并把引用来源一并返回，方便运维人员核对，也方便我们追溯答错时到底召回了什么。

案例片段（已脱敏）： 结构感知切片与元数据过滤配置片段（示意）：chunk:  mode: structure_aware  max_tokens: 512  keep_table: true  metadata: [doc_id, model, chapter, version] retrieve:  hybrid: true  filter: "model == 'A3' AND version >= '2.0'"  rerank_top: 5切换结构感知切片后，针对某型号 A3 的问答准确率从约 68% 提到约 89%，无效检索占比从约两成降到约 4%，运维人员反馈答非所问的情况明显少了。

三、关键技术挑战与解决思路

第一个坑是表格处理。设备手册里大量参数是表格，按字数切会把一行拆成两半。我们做了表格整体保留策略，表格作为一个不可拆单元，超长时整体前移或单独成块。这一步立竿见影，参数类问题的准确率直接上一个台阶，因为模型终于能看到完整的参数行。

第二个难点是同名章节的消歧。不同型号都有安装章节，纯向量检索分不清。元数据过滤在这里是关键，检索时带上型号条件，召回范围瞬间收窄到正确文档。这比靠模型自己判断靠谱得多，也让我们意识到，很多 RAG 答错不是模型不行，是检索把错的喂给它了。

第三个点是重排的成本。重排模型每次多一层推理，会加延迟。我们只对 top20 候选做重排，控制开销，剩下的直接丢弃，性价比最高。这里有个权衡，重排窗口太小会漏掉靠后的好片段，太大又拖延迟，20 是我们压测下来体验和效果的平衡点。

四、效果数据

上线后问答准确率从约 68% 提到约 89%，召回命中率约 0.91，无效检索占比从约 20% 降到约 4%，人工纠错率下降约六成。运维同事愿意真的用这个问答，而不只是摆设，知识库的使用率从几乎为零涨到日均数百次查询。我们后来把这套切片和元数据规范沉淀成了内部建库标准。（数据均为脱敏示意值）

落到工程细节，我们给每个切片打的元数据不止型号和版本，还带了文档生效日期和适用区域，检索时这些条件可以组合过滤，召回精度比单靠型号又高了一截。建库流程我们也做了自动化，手册一更新就触发重新切片和索引更新，不用人工搬。上线一段时间后我们复盘，发现运维最常问的是参数类和故障排查类，这两类在结构感知切片下准确率最高，反而是开放的闲聊类问题模型答得一般，于是我们把问答入口的定位从通用助手收窄到手册助手，反而口碑更好。这个收窄的动作说明，RAG 场景把边界划清楚，比盲目追求全覆盖更有用。

我们把这套结构感知切片的经验整理成了一份建库规范，明确规定了哪些元素必须作为不可拆单元保留，哪些可以按语义块切。规范落地后，新接入一份手册时工程师照着做就不会再犯腰斩表格的低级错误。我们也顺手做了一个切片质量的自检工具，建库完成后自动抽样检查片段完整性，发现问题立即告警。这个工具上线后，人工巡检切片的时间基本省掉了，建库效率又提升了一截，规范加工具双管齐下才真正把质量锁住。

五、可复用经验总结

RAG 的召回上限在切片这一步就决定了，只按字数硬切永远救不回被切断的表格，结构感知才是正路。元数据看着不起眼，却是同名消歧和精准过滤的杀手锏，建库时就把字段规划好。混合检索别省，专有名词场景纯向量会翻车。重排要克制，只对 top 候选做，成本才压得住。我后来觉得，RAG 项目八成精力该花在检索侧，而不是盲目换更大的模型。很多团队反过来，模型换了一圈，召回还是烂，根子在切片。