1. 670次问答先别急着谈准确率先把这个数字拆开看先说结论670次问答、108个差评好评率约83.9%差评率约16.1%。如果这是一个普通客服机器人这个数字勉强可以接受。但在工控知识库POC里这个数字是绝对拿不出手的。为什么因为工控场景里一次错误回答的代价不是“用户不满意”而是维修工照着一个错误参数调设备结果把变频器烧了或者产线停机多停了两个小时。差评背后不只是体验问题是真实的生产风险。这个项目是这样的某制造企业为了提升一线维修工的设备故障排查效率计划部署一套基于大模型的工控知识库。我在项目交付方负责POC阶段的技术验证和落地。知识源来自过去三年积累的设备手册、报警代码表、维修工单、工艺参数文档大约四千多页非结构化资料全部部署在客户内网。试运行两周业务侧拉了一个二十多人的维修班组实际使用累计670次问答交互其中108次被用户标记为“不满意”或回访时明确反馈“没用”。这个POC的原始目标很朴素让维修工用自然语言提问系统给出设备故障排查建议、报警代码解释、维修步骤和参考参数。比如“三号产线变频器报F0020过流是什么原因”“轴承温度偏高到75度正常吗”“换刀机械臂卡住了怎么复位”。这些事原本要翻手册、查工单、问老师傅POC想把这件事变得像问同事一样简单。但670次问答真实跑下来问题暴露得很彻底。108个差评不是均匀分布的也不是一个单一原因造成的。我花了将近一周时间把每一条差评的问答记录、检索命中文档、模型生成内容全部拉出来做归因才把问题分成清晰的几类。下面这张表是我当时整理的差评分类先放出来后面所有分析都围绕它展开。差评类型数量条占比典型表现答非所问没抓住真实意图3633.3%问“机台报警”答了一堆报警代码定义没对应到这个机台数据、型号、参数错误3229.6%推荐了错误的传感器量程把A型号扭矩参数答到B型号上步骤缺失或顺序颠倒2422.2%复位流程漏了“先断电确认”步骤拆装顺序写反答完没有出处用户不敢信1614.8%回答看起来完整但没有引用来源维修工不敢照着做这108条差评是POC最有价值的资产比那562次“看起来还凑合”的成功回答值钱得多。因为每一个差评背后都对应一个具体的链路缺陷而且这些缺陷不是模型能力问题是工程问题。2. 108个差评背后的四层根因从知识源到生成链路逐层排查当时排查的第一步是建立追问机制。光看差评本身看不出原因必须把每一条差评对应的“用户问题、检索召回的文档片段、最终生成文本”全部拉出来对齐。我把这108个样本做了完整的链路回放发现根因高度集中在四个层面知识源数据质量、检索召回策略、生成约束缺失、评估与交互设计。四层问题逐层传导最终表现为用户看到的“乱回答”。2.1 知识端四千页资料进库之前根本没做过“入库前处理”工控文档是知识库里最难处理的文本类型没有之一。既有正式的设备操作手册又有老师傅手写的维修工单还有二十年历史的扫描版图纸和技术通知。这个POC最初建库用了最省事的方案把所有PDF批量转文本、按固定字数切片、灌进向量库。听起来没什么毛病结果埋了三个大雷。第一个雷是扫描版PDF的OCR质量。早期设备手册很多是扫描件部分页面歪斜、字迹模糊转出来的文本大量乱码和错字。报警代码表这种关键文档被OCR识别错误后“F0020过流故障”变成了“F0020过流故障”机率有多高实测错几个字母向量检索就基本召不回了。检索召回是“近似匹配”一字之差语义空间里跑偏很远。第二个雷是技术文档的版式被粗暴切碎。工控手册里大量内容是“表格说明文字”混合结构比如报警代码总表一个表格几十行每行是“代码-故障描述-可能原因-处理措施”。固定字数切块极容易把一行完整记录拦腰切断前半块只有代码和描述后半块只剩原因和措施。检索时召回了前半块模型拿到的是残缺信息生成时只能靠“猜”猜的结果就是数据错误和答非所问。第三个雷是版本混存。过去三年现场换过两次设备批次同一个型号在不同批次里参数有差异。资料库里新旧手册混放没有版本标记。向量检索没有时间概念新旧版本都能搜出来模型如果同时拿到两个版本的矛盾参数生成时往往选择更靠前的那段用户拿到的就是过时甚至错误的参数。很多关于参数错误的差评根子在知识端而不是模型端。2.2 检索端纯向量方案在工控场景下的召回失真问题知识端的问题解决之前检索端做得再好也没有意义。但解决了一部分数据问题后我开始重新审视检索策略发现纯向量检索在工控领域有几个先天短板。第一维修工的表达习惯和手册的官方表述之间存在巨大的语义鸿沟。用户问“机台老是报警怎么弄”维修工单里写的是“精雕机X轴经常性报警”设备手册里写的是“X轴伺服驱动器ALM报警”。在文档里找“伺服驱动器报警”很容易但要用向量检索把“机台老是报警”和“伺服驱动器ALM报警”关联起来难度很大。维修场景大量使用俗称、缩写和口语化描述而手册是书面语这种词汇错位让向量检索的命中率直线下降。第二工控文档里的关键信息高度依赖精确匹配。设备型号“S7-1500”和“S7-1200”只有几位之差但硬件完全不同报警代码“F0020”和“F0021”在向量空间里的距离非常近语义上也确实相关但维修处置方式完全不同。纯向量检索对这种“形式相似、含义迥异”的核心标识符几乎束手无策因为向量模型会把它们编码成相近的向量。第三top_k和相似度阈值设置不合理。这个POC初始采用的方案是top_k5、相似度阈值0.7实际运行中频繁出现两种情况真正有用的文档片段相似度低于0.7被滤掉模型只能用弱相关的片段硬答或者模型为了凑够5个片段把相似度很低、其实跟问题无关的碎片强行拼进来。工控文档里大量参数表格结构相近检索经常把不同型号的参数表混在一起返回模型再聪明也分不清哪个参数属于哪个设备。2.3 生成端模型在“照着念”和“编造”之间缺一个刹闸机制知识端和检索端的问题解决了大半之后我重新测试了差评样本发现仍然有不少回答看起来“有模有样”但细看是错的。这部分差评指向生成层的约束问题。当时用的开源大模型默认提示词只是简单写了一句“请根据提供的资料回答用户问题”。这个提示词太太太天真了。模型拿到检索片段后没有任何机制约束它“只能用资料里的内容作答”也没有引导它“资料来源冲突时怎么办”更没有要求它“找不到答案时必须直接说不知道”。于是模型在信息不足时会调动自己的内部知识“脑补”。最典型的场景是问一个具体设备的扭矩参数检索返回的片段里只有设备名称没有参数表。模型没有直接说“资料中未找到”而是根据训练知识中“类似设备的常见扭矩范围”给了一个看似合理的数字。维修工并不知道这个数字是从大模型知识里“编”出来的可能就照着做了。这是工控领域最危险的错误类型因为它是“自信地犯错”用户几乎无法辨别。另一个生成端的细节是温度参数。POC初始采用通用聊天场景的默认配置导致模型回答的随机性偏高同一问题换一种问法措辞和重点就完全不同。而工控场景恰恰需要高度稳定、可预期的输出。同一个报警代码上午问和下午问处理步骤不能两样。这个配置缺陷加剧了用户的不信任感也直接导致部分“步骤缺失或顺序不一致”的差评。2.4 评估与交互端POC从头到尾缺一个可量化的评测闭环前面三层都是技术链路的问题第四层则是项目管理的问题。复盘时我承认整个POC最大的锅是没有在第一天就建立评测集和反馈闭环。初期我们只有一个“好像效果还行”的模糊印象靠的是开发团队自己拿几个常见问题试了试。但开发人员不是维修工不会用一线那种充满口语和噪音的方式提问。真实用户在试运行阶段问出的问题大量是“这个咋回事”“它转不动了”“电压低会不会是这个原因”和开发团队自测时的规范问法完全不同。等到点踩数据出来才发现研发自测的自我感觉良好和真实业务场景差距极大。更关键的是反馈数据没有形成闭环。用户在问答页面点了“没用”之后系统自动记录了一条差评数据但后续没有任何人跟进这条数据到底为什么被点踩。如果当时把差评样本实时回流到标注团队边跑边修两周时间至少可以解决掉一半问题。实际执行是差评堆积到最后统一处理白白浪费了两周的真实流量。还有个容易被忽略的点回答没有展示参考来源。POC阶段的问答界面只是纯文本对话框回答末尾没有“参考文档”链接也没有出处片段。工业场景里一线维修工对AI的回答天然不信任如果所有回答都看不到来源他们更倾向于直接点“差评”而不是“冒着风险照着做”。这一点不是技术问题但对差评率的影响非常直接。3. 优化方向把差评库变成下一轮迭代的路线图根因分析做完之后优化方向其实是被差评推着走出来的。108个差评样本重新梳理后形成一个明确闭环治理知识源检索改混合策略生成层加约束和兜底最后把评价体系做成常态化运营机制。3.1 知识源治理把70%的时间用在20%的高频文档上第一个要做的决定是砍范围。不是所有四千页资料都值得入库。我拉出了维修工单和报警代码的访问频率数据发现大约80%的查询集中在报警代码、故障复位、参数设置这几类问题上而这几类内容对应的核心文档其实只有二十多份。POC阶段应该做深这二十多份而不是平均用力。选定了核心文档后逐份做结构化处理。设备手册拆成“型号信息、技术参数、操作步骤、报警说明、维护保养”等结构化段落报警代码表单独抽出来转成关系型结构一行代码对应一条完整记录工单文本按“故障现象-处理过程-结果”做字段抽取。这个过程很枯燥但它是收益最大的一步。结构化后的数据再入库检索和生成的准确率直接上了一个台阶。版本混存问题必须立规矩。所有文档入库前必须标注适用设备批次和生效日期对同一型号不同批次的参数差异建立“参数变更记录表”。检索时如果命中多条版本记录要么通过元数据过滤掉过期版本要么把版本差异显式写进回答让用户自己确认。不要指望模型自己分辨新旧版本这个要求对模型来说太超纲了。OCR文件全部重新过一遍关键内容报警代码、型号、参数值人工核对。不能用“OCR之后再通读一遍”这种粗放方式要针对关键字段做专项校验报警代码的字母数字组合、参数值的小数点和单位、设备型号的连字符写法。工控文档里一个字符的错误就是一次事故。3.2 检索链路混合检索加一个轻量重排效果立竿见影知识源处理完之后我把检索方案从“纯向量”改成了“向量BM25混合检索”。思路很简单向量负责语义召回BM25负责精确关键词匹配。工控场景里“F0020”“S7-1500”这类硬编码标识符精确匹配是保底手段向量匹配做不到万无一失。混合结果的融合我采用的方案是经典的RRFReciprocal Rank Fusion方法。给每条候选文档在两个检索结果里分别计算排名倒数最后对两个分数求和排序。这样避免了两个不同量纲的相似度分数直接相加的问题实现简单效果稳定。重排环节加了一个轻量级的cross-encoder模型对RRF融合后的前20个候选做精细化排序最终只取前3到5个送入生成模块。加了重排之后Top1命中的准确率提升非常明显因为重排模型能更准确地判断“这段和用户问题到底有多相关”。阈值策略也做了调整。原来的固定阈值0.7我把语义检索的阈值提高到0.82宁可漏召回不可错召回。如果最终结果集中没有一条相似度超过阈值系统不再继续生成而是直接输出兜底话术“资料库中没有找到与该问题匹配的内容建议联系设备厂家支持”。这个改动看起来会增加“拒答率”但对比实测发现大部分被拒的问题本来就该被拒硬答出来只会贡献差评。另一个细节是切块策略。固定512字符切块改成了按标题层级和表格结构切块块长缩短到256字符左右overlap设为50字符。看起来是个小改动但对工控文档来说影响很大因为报警代码、故障原因、处理措施经常在表格里挨着一个块最好包含一条完整记录而不是从中间切断。3.3 生成策略给模型划出“可以说的”和“不能说的”边界生成层的优化核心是我重新设计了一套提示词约束。这次明确了三点只能使用检索到的文档内容回答资料中没有的信息直接回答不知道涉及安全事项时必须提示“务必确认断电后再操作”。提示词模板大致长这样你是设备维护知识问答助手。回答用户问题时必须遵循以下规则 1. 只能依据参考资料内容进行回答不得使用模型内部知识补充技术参数。 2. 如果参考资料无法回答用户问题直接回复“资料库中未找到相关信息建议联系设备厂家或查阅纸质手册确认。” 3. 回答必须包含参考编号格式为[1][2]对应末尾的“参考文档”列表。 4. 如果参考资料中有多个不同数值或版本差异请在回答中并列给出并说明资料来源不要自行选择一个。 5. 涉及设备拆装、电气操作、参数修改的内容必须在回答末尾增加提示“操作前请确认设备已断电并参照对应的现场安全操作规程执行。”这套提示词的作用等于给模型画了一个边界不是让它变得更聪明而是让它学会在不确定的时候闭嘴。实测下明确说“不知道”的回答差评率反而低于那些硬答编造的回答因为用户至少知道系统没有骗他。温度参数从默认值改成了0.1保证同一问题多次回答的输出结果基本一致。工业场景不需要“有创造力的回答”需要的是“每次都一样的标准答案”。3.4 评估与运营闭环差评库是资产不是垃圾优化做完后最重要的一步是把评估从“人拍脑袋”变成“数据驱动”。我把之前670次问答里的所有记录整理成了第一批评测集562条好评样本作为回归测试集108条差评样本单独作为问题集。每一次检索策略调整、提示词修改都用这670条数据全量回归一遍观察差评集上的通过率而不是只看好评集有没有变差。同时建立了反馈标注流程。用户在问答界面点“差评”后系统自动记录当时的用户问题、检索候选、模型输出文本并由业务侧标注员补充一句简要的“原因归类”是答非所问、参数错误还是缺来源。每周固定时间拉一次差评明细对照评测集找出仍在发生的同类问题进入下一轮迭代。还有一个立竿见影的做法是在问答界面显示参考来源。把检索命中的文档片段以“参考文档”形式展示在回答末尾维修工可以点击查看原文。来源可见之后即使某个回答不完全准确用户也能快速判断问题出在哪可以自己按图索骥找答案。这个改动直接把“无法确认来源不敢信”这一类差评几乎清零。4. 常见问题排查速查表下次遇到同类POC直接对照定位这类项目的坑有很强的共性我把这次POC踩过的坑整理成一张速查表方便遇到类似场景时快速定位。症状根因排查方法对应解法差评集中在“参数错误”参数表被切碎或版本混存查看命中文档的原始位置确认切片是否完整参数表按行structure入库版本加元数据过滤差评集中在“答非所问”词汇鸿沟导致召不回相关文档抽查差评样本的检索命中Top5看是否偏离增加BM25混合检索补充同义词别名表用户反馈“不敢照着做”回答没有来源信任感缺失查看问答界面是否有引文展示回答末尾列出参考文档编号和片段同一问题答案不稳定模型温度参数过高相同问题连续问10次比对输出温度调低到0.1-0.2加强提示词约束模型经常编造手册外的参数提示词没有禁止脑补查看输出是否包含检索片段之外的内容在提示词中强制“只用参考资料”缺资料时拒答差评一条条看整体没感觉缺少评测集和归因标注建立差评库给每条差评打原因标签按原因标签统计根因分布驱动、迭代优先级这张表不是什么高深的方法论但它确实是从108条差评里一个一个填出来的。做知识库项目的人应该有体会最大的成本不是模型选型不是prompt调试而是“定位问题在哪一层”。这张表能把定位时间从几天压缩到几小时。4.1 实操心得差评率是技术问题更是流程问题整个POC复盘下来我最大的心得是在工控场景里知识库的差评不能当成“模型不行”来处理。670次问答里有108个差评如果只看最后的结果数字很容易得出“这个模型效果不达标”的结论然后换模型、加大算力问题却依然存在。实际上拆开108个差评看纯模型能力导致的错误占比很小大部分差评源于知识源没治理、检索策略不适应领域特性、生成环节没有约束、评估机制缺位。如果你现在正准备做一个垂直领域的知识库POC我建议从第一天就做几件事搭一个二十条的评测集覆盖这个领域最高频的提问方式先把基线打出来知识源选最核心的二十份文档做精细化结构化不要贪多检索策略直接用“向量加关键词混合检索加轻量重排”的组合不要裸用纯向量生成提示词里明确写上“没找到就直说”不要给模型发挥空间问答界面必须展示参考来源。这几件事不需要多少成本但它们决定POC能不能从“演示看着不错”变成“真让人敢用”。最后说一个数据层面的教训670次问答、108个差评表面上是一个失败的结果但真正失败的是如果这670次问答跑完我们没有从108个差评里学到东西。差评率不是用来向领导汇报的KPI它是系统最诚实的能力评估报告。能定位到每一层根因这108个差评就相当于108次免费的专家咨询。也正是把这些差评逐条拆解、逐层归因之后这个工控知识库才从一个“大模型Demo”变成了真正可交付、可上线、可长期运营的工程系统。
