给制造业设计一个设备手册问答系统，讲完整方案

先把 PDF 解析成文本，按标题层级切块，用 embedding 建向量索引，检索时做向量加 BM25 的混合检索，再加一个重排。生成时把检索到的片段拼进 prompt，要求它基于给定内容回答、找不到就说找不到，并给出引用。前端做成移动端方便现场用。后面可以再加多模态处理图纸。

技术选型没错，但它是一个通用文档问答方案，换成法律、医疗一个字都不用改——也就是说，它没有回应这个场景的任何特殊性。而且没有基线、没有代价、没有评测。

① 先问四个问题：手册多少本、什么形态（原生 PDF 还是扫描件）、多久更新一次？用户是现场工程师还是客服坐席——现场的容忍度低、要移动端、可能没网？答错的代价是什么——是多打一个电话，还是按错步骤导致停机？现在他们怎么查——这条最值钱，现状就是我的基线。

假设：400 本手册、混合形态、季度更新、现场工程师为主、答错可能导致误操作、现在靠翻 PDF 和打电话问老师傅。

② 基线：解析 + 按标题层级切块 + 向量与 BM25 混合检索 + 重排 + 「找不到就说找不到」 + 强制引用到手册页码。这套东西在这类场景一般能到七成左右的可用率，剩下三成集中在三个地方：表格里的参数、图纸和爆炸图、以及跨型号的混淆。先把这个基线摆出来，是为了让后面每一样加挂都有参照物。

③ 加挂，每样都说代价：

• 脏文档处理（这个场景的第一大坑）。扫描件要 OCR，表格要单独抽成结构化再回填成自然语言描述，图纸要做图文关联。解决什么：把不可检索的内容变成可检索。代价是什么：解析流水线本身成为一个要长期维护的系统，且 OCR 错误会静默传播——一个小数点识别错，答案就是错的且看不出来。什么时候不该用：如果八成的高频问题都落在少数几本原生 PDF 上，先只处理那几本，别一上来做全量解析。
• 精确匹配通道。报警码、型号、参数编号这类查询天生不适合向量检索——它们是标识符不是语义。做法是把报警码抽成结构化字段，走精确查询直接命中，检索层只做兜底。代价：要维护抽取规则；不该用：手册里编码体系不统一时，强抽会引入错误映射。
• 版本与型号隔离（这个场景的第一大风险）。同一个报警码在不同型号、不同固件版本含义可能完全不同。做法是把型号和版本做成必填的检索过滤条件，用户没说型号就先反问，而不是猜。代价：多一次交互，体验变差；但这个代价必须付——在这个场景里，答错型号比答不出来危险得多。
• 引用溯源。每条答案必须给出手册名 + 版本 + 页码，让工程师能去核对。代价：约束了生成自由度、拒答率会上升；收益：它同时是信任机制和排障入口。
• 私有化部署（如果数据不能出网或现场没网）。代价：这笔账要按并发算，不是按调用量算——自建的成本是固定的，只有在调用量足够大或合规强制时才划算。不该用：调用量小又没有合规要求时，自建纯亏。

④ 评测：从真实工单里抽 100 条起步的评测集，按类型分层（报警码 / 操作步骤 / 参数查询 / 故障排查），因为不同类型的失败原因完全不同。三条线：离线集决定能不能发；线上采样看有没有变坏；业务指标看平均处理时长和转人工率。报警码这类有标准答案，可以做精确评测，不需要 judge；操作步骤这类才用 judge，且 judge 自己要有校准集。零成本信号里最有用的是重问率（问完又换个说法再问一遍）和引用点击率。要注意统计关：n=100、基线 80% 的时候，95% 置信区间大约 ±7.8 个百分点，涨三个点说明不了任何事。

⑤ 演进：给触发信号而不是排期。出现「一个问题要跨三四本手册才能答」才考虑图结构；出现「查询需要多轮试探才能定位」才考虑 Agentic 检索；图纸相关提问占比超过一定比例，才上多模态检索。退路也要说：如果解析流水线的维护成本超过它带来的收益，就退回到「只覆盖高频那 30 本 + 其余引导到人工」。