上个月我们在审一份为期三十天的可靠性摸底试验报告会开了不到半小时就卡住了故障次数对不上。有人从试验记录里数出37次故障有人数出33次还有人说其中至少两条根本不算故障。别小看这几次的差别故障次数一改平均故障间隔时间跟着变最后的可靠性结论甚至可能从“不达标”翻成“达标”。也是从那次会议之后我们搭起了一套用AI做报告文档审核的内部工具代号IACheck专职做故障次数精准核验顺带把整个可靠性检测与评估体系的数据口径重新捋了一遍。这篇就聊聊这套东西解决的是什么问题、具体怎么落地以及运行过程中踩过的那些真实边界。1. 故障次数核验可靠性评估里最容易被忽视的地基1.1 同一个故障三种写法描述差异如何让计数失真如果把可靠性检测与评估体系比作一栋楼故障次数就是地基里的钢筋。这个比喻一点都不夸张。平均故障间隔时间的分子是累计试验时间分母是故障次数故障率、可靠度函数、维修性指标的计算几乎都要从这个数字出发。可恰恰是这个最基础的数字在实际操作中最容易出问题。最常见的情况是同一个故障在不同人的笔下有完全不同的写法。有一次我在复核时发现同一个电源模块过压保护动作试验日志里写的是“电源模块输出异常”维修记录里写的是“电源保护重启后正常”质量系统的缺陷单上又变成“输出电压超上限”。如果不是恰好三份文档的样机编号和发生时间都能对上这三个条目会被当成三次独立故障故障次数直接虚增两倍。而反向的风险同样存在有些记录把故障描述得非常隐晦比如“整机运行不太稳定”没有经验的人根本看不出来这是一条故障还是操作人员的抱怨。这个问题在行业里并不少见。故障记录的填写质量完全取决于当时值班工程师的习惯同一个团队里有人喜欢写现象有人喜欢写判读结论有人惜字如金只写一个“偶发”。当这些记录汇总到一份可靠性评估报告里时每一处描述差异都会变成统计口径的偏差。最让人头疼的是这种偏差不是你仔细看一遍就能发现的它藏在几百条记录的措辞缝隙里。1.2 口径之争故障记录与故障判据之间的鸿沟除了描述差异更麻烦的是故障记录与故障判据之间的鸿沟。一份试验记录里有大量信息是按时间顺序写的事件并不等于故障。比如“试验箱温度达到设定值样机功耗上升”这很可能只是正常的温升现象“更换备件后复测通过”这描述的是处理动作而不是故障本身。到底哪些条目算故障需要结合试验条件、指标限值、是否属于外部原因来综合判断。这个判断在很多人看来是“常识”但真要把常识写成可执行的规则时才会发现里面有太多隐性条件。比如某设备在电压跌落试验中发生复位到底算不算故障取决于该设备的规格书是否允许复位。不同产品、不同批次判据都不一样。人工审核时这个判断靠经验审核任务一多、人员一换口径就不稳定了。这也是为什么只靠增加人手解决不了问题——人少了看不过来人多了口径更乱。可靠性评估最怕的不是结论不好而是同样的输入数据换个人统计就得出完全不同的结论。判定口径无法固化后面所有基于故障次数的分析都等于建立在流沙上。1.3 人工核验为什么救不了场我见过很多团队用最原始的方式处理这类问题把报告打出来拿尺子对着表格一行一行数再做记号。这样做的结果通常是一次鉴定会前几个工程师连续加班两天数出来的数字还不一样。原因倒也不是谁粗心而是每个人对“这条算不算故障”“这两条是不是同一个故障”的判断标准都不一样。更麻烦的是人工审核的过程没有留痕。最后汇报时评审专家问一句“这个数字是怎么来的”我们往往只能回答“我们人工核过的”。这个回答在追溯性要求越来越高的今天已经很难让人信服。故障次数直接关系到产品能不能定型、可靠性指标能不能达标如果连这个数字的来源都说不清楚整套评估体系的可信度都会被打问号。所以我在那次故障次数对不上的会议之后下决心要做一个能自动读报告、自动归一描述、自动给出核验意见并留下完整证据链的工具也就是后来的IACheck。2. IACheck怎么读懂故障记录一次解析、两次归一的处理链路IACheck的总体思路不是简单地把报告丢给某个大模型让它输出一个数字而是把核验过程拆成可追溯的几步先把非结构化文档变成结构化字段再把故障描述归一成标准故障模式最后用规则引擎完成计数。每一层都可以独立检查、独立修正。2.1 先把非结构化文档变成结构化字段第一步是把非结构化文档变成结构化字段。可靠性报告的来源很杂质量管理系统导出的PDF、试验台软件生成的日志、手写扫描件都有。IACheck先用OCR把图片和扫描件转成文字再做版面解析把每一段文字归到正确的表格行列里。这一步看起来简单实际最容易翻车。尤其是跨页表格第二页没有表头程序很难判断这列到底是“故障现象”还是“处理措施”。我们在工程上做了个折中不仅要做版面还原还要对关键字段做类型校验。比如“累计工作时间”这个字段必须是一个数字加一个时间单位如果识别结果里出现明显异常就自动标记为疑似错误并在界面里把原图区域框出来让复核的人一眼看到原始凭证。AI的判读结果本身不能直接作为最终结论原始证据必须随时可查。标准化之后每条记录至少包含这些字段样机编号试验阶段累计工作时间故障发生时刻故障现象故障部件处理措施备注有了这组字段后面的归一化和计数才有稳定的操作对象。2.2 故障描述归一的三个层次第二步是故障描述归一。归一化分三个层次。第一层是部件名称的归一。同一块电路板在不同报告里可能被写成“电源板”“电源模块”“电源组件”甚至“PSU板”这些都必须映射到唯一的部件编码。第二层是故障模式的归一。比如“偶发重启”“黑屏后自动恢复”“异常断电后自行恢复”语言表达差别很大但在可靠性分析里它们属于同一个故障模式异常重启。第三层是语义级别的归一。这一步依赖语言模型把整句话转成向量再和故障模式库里的标准描述做相似度匹配。相似度超过设定阈值的自动归类低于阈值的转到人工。为什么必须做这个三层结构因为直接问模型“这条记录属于哪个故障模式”虽然方便但模型可能给出两个不同结果而给不出一个稳定的说法条款多了之后很难排查。分层的最大好处是每一层出问题都可以单独修正词典错了就改词典模型错了就补样本不会牵一发动全身。2.3 用规则把“次数”判准去重、合并与剔除逻辑归一化解决的是“是不是同一个故障”的判断前序问题最终计数还得靠规则引擎因为计数必须确定不能这次跑出37次、下次跑出33次。IACheck的规则层专门处理三件事合并、剔除、追溯。合并的逻辑是同一样机出现同一部件同一故障模式且发生时间间隔在设定窗口内判定为同一故障的重复表现合并计数。比如某样机在48小时试验循环里出现三次显示黑屏但自动恢复且中间没有更换部件按可靠性判据通常应作为一次可报告故障处理。合并时系统会生成一条证据链哪几条原始记录、为什么合并、隶属哪个样机哪个部件。剔除的逻辑是试验条件超差、外部电网异常、人工误操作等原因导致的异常不属于产品可靠性故障。系统把这类原因单独归为“非可报告”并记录剔除理由。追溯则是把合并、剔除、保留操作全部反写到原始记录上最终输出一份核验差异说明表。下面是一条约束处理后的记录示例{ record_id: T-2025-0512-014, device_sn: S0102-003, fault_part: P202-PSU, fault_mode: M301-异常重启, fault_time: 2025-05-12 09:41:22, working_hours: 215.5, suggest: merge, merge_with: [T-2025-0511-023], confidence: 0.93, reason: 同一样机同一部件同一故障模式且发生时间间隔小于36小时 }3. 落地IACheck的实操要点从历史数据标定到验收闭环3.1 历史报告标定故障词典与故障码体系的建设说句实在话IACheck这类工具不是装上就能用的它需要先吃够一定量的历史报告。我们在起步阶段做的最重要的一件事是整理故障词典和故障码体系。流程大概是从历史报告里挑出两百到五百条有代表性的记录逐条标注出部件名、故障现象、处理措施并且明确标出哪些记录最终被判定为可报告故障、哪些被合并、哪些被剔除。这些标注数据同时干三件事一是用来写同义表达词典比如“黑屏”“显示无输出”“屏幕不亮”归到一类二是用来归纳每个产品线的两级故障码先按部件编码再按故障模式编码三是用来训练和评估语义模型。没有这个步骤就急着上线后面一定会在准确率上栽跟头。我自己见过太多项目跳过标定直接调模型最后模型在测试集上表现不错一到真实报告就频繁出错因为真实报告里的表达方式远比测试集丰富。提示故障词典不是一次性建完的至少要留出两轮迭代的余量。第一轮覆盖规范写法第二轮专门吸收口语化、缺主语、带错别字的写法。3.2 模型与规则的分工配置第二个要点是把握模型与规则的配置度。我的建议是重规则、轻模型。凡是能用词典、正则、字段映射解决的事情坚决不交给模型。模型只负责一件事开放文本的语义归一也就是处理词典覆盖不到的语言变化。最后计数必须由规则引擎完成。原因很简单模型的预测天生带有不确定性同一句话换一种问法可能给出不同结果但故障次数是要写进报告、要对外解释的数据必须稳定、可复现。如果第一版不想投入太多资源可以不接大模型而是先微调一个轻量的序列标注模型来抽取实体再用文本向量相似度做归一。这样做的好处是出错好定位、算力要求低坏处是面对特别口语化的描述时泛化能力弱。实测下来只要词典覆盖到位轻量模型加规则的组合已经能覆盖大部分规范试验记录。3.3 输出设计与人工复核闭环第三个要点是输出设计和人工复核闭环。IACheck的输出不是简简单单给一个数字而是给一个可以审查的过程。每条原始记录都会得到一个处理意见保留、合并、剔除、人工复核附带置信度和理由。置信度高的记录可以自动通过置信度中等的记录进入一个快速勾选界面人工只需要看系统高亮的关键字段做确定或推翻置信度低的记录必须逐条点开原文对照原报告截图核验。在验收上我们用一段已由资深工程师人工判定过故障次数的历史数据做盲测计算IACheck的核验结果与人工判定结果的一致率。第一版的目标我建议设在90%以上再放量使用达不到就继续补词典、补规则、补样本。另外还有一个非常实用的设计把每次人工推翻AI判定的案例都记录下来定期归因这比任何测试指标都能说明问题。4. 实测中的坑AI核验在真实报告前暴露的边界问题4.1 扫描件OCR错字与表格串列第一个坑是OCR错字和表格串列。我们有一批比较老旧的历史报告是扫描出来的清晰度本来就不高。OCR把“电机”识别成“电枢”把型号字母里的O识别成数字0部件编码完全对不上。更麻烦的是表格跨页后表头丢失程序把第二页第一列的数据当作故障现象实际那列是处理措施统计结果自然全错。后来我们加了两道保险第一字段类型校验比如累计工作时间必须匹配数字加单位的模式如果识别结果不满足就标记为疑似误识别第二所有进入人工复核界面的记录都保留原图区域截图人可以点开看原始证据。这套机制虽然让自动化率打折但至少保证了不会把错误结果一路传到故障库里。宁可在核验环节多花一点人工时间也不要在后续评估分析里反复返工。4.2 “同一故障”的时空窗如何定义第二个坑是“同一故障”的时间窗定义。这个坑严格来说不是技术坑而是定义坑但技术实现绕不开它。如果把时间窗设成固定的小时数比如48小时同一故障只是没有在修复后完整跑过一个验证周期再次出现时就会被拆成多次故障如果时间窗设得过长两个没有因果关系的独立故障又会被糊里糊涂地合并成一次。我们最后采用的做法是按验证周期而不是按小时数判断样机更换部件后重新完整运行了一个验证周期没有再出同类问题之后再次出现同类问题视为新的故障如果没有经过完整验证就又出现视为同一故障未修复。但这个定义在不同产品线里并不一样所以规则里的时间窗参数必须做成可配置项。同时我强烈建议在每次评审会之前把时间窗的取值和试验工程师、设计师对齐一遍否则AI的合并结果很可能会在评审会上被挑战。4.3 置信度阈值的取舍第三个坑是置信度阈值的取舍。最开始我们把自动判定阈值设得很高基本0.9以上才自动处理结果大量记录都进了人工池系统并没有给审核人员省多少事。后来我们把阈值下调到0.6自动化率上去了但业务方很快发现有些明显该人工确认的记录被自动放行了。最后我们改成两级阈值0.85以上自动判定0.6到0.85之间进入快速勾选界面0.6以下强制人工逐条核验。这个调整之后系统的自动化率大概能回到百分之六十多同时误判率可以接受。经验就是阈值不是一个参数而是一组参数而且一定要基于实际业务的容错能力来调。可靠性报告这种场景我对自动判定的要求是宁可少判不可错判。因为少判还有人工兜底错判直接污染数据。4.4 历史数据的格式多样性第四个坑来自历史数据的格式多样性。这几年我们手里的存档报告来源五花八门有纸质的、有试验台软件直接导出的、有自己整理到Excel里的字段命名完全不一致。刚开始我们想让IACheck把所有历史数据一次全部清洗完结果陷在格式适配的泥潭里。最后调整了策略按报告批处理先把结构规范的最新报告跑通形成基准把结构较老、表述较乱的报告作为后续批次一边处理一边补充标注作为模型和词典的增量训练数据。这种分阶段推进的方式比一开始求全实用得多。后来我还发现IACheck上线三个月之后由它核验过的报告格式开始反过来影响试验团队的填写习惯大家知道最终会有AI来审填写规范了很多模板层面甚至在源头减少了模糊描述。这个正反馈是我当初没有预料到的。5. 故障次数核准后可靠性评估体系被重塑的部分5.1 MTBF从拍脑袋变成可追溯故障次数一旦被精准核验第一个明显变化是MTBF这类指标终于从拍脑袋变成了可追溯。我们有一个项目原统计的故障次数是18次IACheck核验后确认的可报告故障是14次。别看只差4次在那个累计试验时长下MTBF从约500小时变成了约640小时直接影响了这个项目“是否达到规定的最低可接受值”的结论。项目人工原统计IACheck核验差异原因故障记录总数2323无可报告故障18143次合并、1次剔除计算用试验时长9000小时9000小时不变修正后MTBF500小时642小时故障次数差异同时我也要说明这绝不意味着系统在放松判据帮产品过关恰恰相反因为每一条合并、剔除都有证据链评审专家反而更愿意接受结论。过去人工数出来的数字大家心里都有疑问只是碍于没有更好的方案才勉强接受现在数字背后有逐条解释可靠性结论的置信度完全不一样。5.2 故障模式分布终于能支撑Pareto决策第二个变化是故障模式分布终于能支撑决策了。过去我们想画一张故障模式频次排序表一共十来个故障模式“其他”类却能占到将近三分之一因为人工归类时抓不住那么多细节很多表述模棱两可的记录都被丢进了“其他”。IACheck做了语义归一之后“其他”类占比大幅下降真正的TOP故障模式浮现出来。比如某个项目里异常重启、传感器无输出、通讯时断三类问题占了七成故障次数这个排序直接指导了下一轮设计改进和维修策略的制定。如果没有精准的故障分类这些资源投入方向很可能就是拍脑袋。可靠性评估的价值并不只是算出几个指标交差而是把有限的设计改进资源投向真正值得投入的地方。故障次数核验这一步做扎实了后面所有的分析才有根基。5.3 从我的角度看这套体系的局限与经验最后说说我自己的体会。用IACheck做故障次数精准核验最核心的价值不在于替代人而在于把“判定过程”本身变成可解释、可被复查的对象。我也提醒自己不要把AI的能力神化故障判据的源头仍然是工程定义AI只是把定义翻译成了规则和模型。如果我们内部对于某类故障到底算不算可报告故障本身就说不清楚那AI只能放大这种混乱而不是解决它。从分工上看我的建议是让AI负责把模糊海量的记录变成结构化的候选结论让人负责处理那些低置信度、真真假假的疑难条目。这样做一个月之后我发现团队审核报告的时间不仅没有增加反而明显变少而且每个人对“故障次数为什么是这个数”的解释能力都强了很多。现在我再拿到一份可靠性报告先看IACheck输出的核验差异表再决定要不要翻原始记录效率比从前翻纸质报告高得多。这套方法目前还在继续打磨尤其是针对更复杂的多故障交织场景还有不少空间可以扩展。