保险定损Harness实战：从影像质检到规则引擎的自动化理赔管线

先说实话我一开始听人聊“保险理赔 Agent”脑子里浮现的也是一套“大模型看照片、直接出定损单”的神奇系统。真到自己动手才发现重点根本不在模型有多聪明而在怎么把影像识别、定价规则、配件库、人工审核这些零散能力装进一个可靠的工作流里。这个装法就是我们说的 Harness。这篇文章想聊的就是我从零搭一套自动化定损 Harness 的完整思路为什么先拆业务流程、管线怎么分层、定价环节有哪些坑、防欺诈为什么不能依赖模型、上线前数据口径和灰度策略怎么定。不堆理论都是实际跑通过、也踩过坑的经验。给正在做理赔系统改造、或者打算用大模型做业务自动化的团队做个参照。1. 定损业务的真实堵点为什么人工流程会把理赔时效拖垮1.1 传统定损的五个环节和各自的时间黑洞定损在保险业务里很少单独存在。一次车险理赔从客户报案到赔款到账通常要走报案登记、资料收集、损失核定、维修方案确认、复核支付这几个环节。定损这个动作卡在资料收集和维修方案确认的中间是整条链路里最耗时、也最依赖老师傅经验的一环。我见过太多理赔员的日常早晨打开系统发现昨天夜里涌进十几个案件每个案件挂着十几张现场照片有的是手机拍的有的是行车记录仪截的甚至还有模糊的监控截图。他需要一张一张看先判断受损部位再对照保单确认哪些属于赔付范围然后凭经验估一个维修金额再写一段结论文案。这套流程跑下来一个熟练理赔员一天能处理的案件量非常有限而那些刚入职不久的新人常常连“这个保险杠该修还是该换”都拿不准。时间黑洞主要集中在三处照片整理和筛选。现场照片没有固定规范角度、亮度、拍摄距离千奇百怪人工要先理解“拍的是什么”才能判断“坏成什么样”。维修方案的判断。定损不是简单的“坏了赔钱”要区分剐蹭、凹陷、开裂、碎裂要判断损伤是否涉及结构件还要考虑原厂件和副厂件的差别。金额校验。系统里虽然有配件价格库但实际定损时很容易出现工时费虚高、重复报价、超范围维修等问题复核人员得逐条核对。1.2 Agent 真正值得介入的三个切入口很多人把 Agent 想得很玄其实落到业务上它就是一段“能自己调用多种能力的自动化决策流程”。对定损来说最值得做的不是让模型直接输出“赔多少钱”而是把上面三个人工环节拆成机器擅长的事第一个切入口是影像的规范化整理。让视觉模型先做质量过滤、场景分类、损伤区域定位把几十张混乱的照片变成一组“部位损伤类型置信度”的结构化信息。第二个切入口是标准化损失描述。把视觉模型的输出交给语言模型生成统一的报案摘要和损失说明理赔员不用再从头看一遍照片。第三个切入口是规则化校验。把定价和审核规则变成可配置的流程节点Agent 自动对照保单条款、配件价格库和维修标准发现异常直接弹给人工。我当时的判断是这三个环节一旦打通理赔员就能从“看图写作文”里解放出来只处理模型不敢拍板的高风险案件。响应时效、审核一致性、人力成本三个指标都会同步改善。1.3 为什么叫 Harness 而不叫“模型”这里我要强调一个容易混淆的概念。我们搭的是定损 Harness不是简单部署一个视觉模型或语言模型。Harness 的本意是“装配架”放在软件工程里就是一套把模型、规则、数据源、人工审批串起来的执行框架。模型负责感知和生成规则负责约束和校验工作流负责调度和兜底审计日志负责留痕。缺少任何一层系统都很难真正落地。我也见过团队直接拿开源大模型接图片输入让模型自由发挥写定损意见结果输出格式千奇百怪、金额张冠李戴这样的系统根本没法进生产环境。所以下面我讲的整个方案都围绕“如何搭一个让模型在规则边界内高效工作的 Harness”展开。2. Harness 的管线设计从“一堆照片”到“结构化损失清单”2.1 整体流程分六段节点间只用结构化数据传递我习惯把定损管线拆成六段影像采集与质检、车辆信息识别、损伤检测、方案生成、价格计算、审核输出。每段可以单独替换算法也可以独立开关。管线跑起来以后节点之间传递的不是自然语言而是一份统一的 JSON 结构。打个比方影像检测节点之后输出的不是一句“前保险杠有损伤”而是{ panel: front_bumper, damage_type: crack, severity: medium, bbox: [152, 310, 480, 420], confidence: 0.92, image_id: claim_20250110_A002_03 }这个设计的核心原因只有一个可控。自然语言的自由度太高下游的价格计算和规则引擎无法稳定依赖。先让模型吐出结构化字段再由语言模型基于字段生成人类可读的报告这样无论模型怎么换定价模块的输入格式永远稳定。2.2 影像质检这一步很多人会忽略它的重要性定损系统的准确性一半取决于模型能力另一半取决于输入质量。照片本身就是歪的、糊的、反光的后面的流程做得再好也是白搭。所以我在 Harness 的第一段专门放了一个影像质检节点做以下几件事清晰度检测。低于阈值的图片直接退回并自动通知客户重新拍摄。场景有效性判断。区分“事故现场照”“车身局部照”“行驶证证件照”避免把无关图片误送入损伤检测。敏感信息剥离。移除图片上的 GPS 坐标、人脸、车牌等隐私信息只保留业务需要的视觉特征。这里要特别提醒很多隐私问题不是模型造成的而是原始数据本身带进来的。多角度覆盖检查。结合车辆识别结果判断上传图片里是否包含了前、后、左、右等多个角度缺角度时自动提示补拍。这些逻辑不复杂但能显著降低后续模型出错率。我做过一个统计加入自动质检后损伤检测的误报率下降了大约三成主要就是滤掉了反光、失焦和无关背景。2.3 损伤检测节点边界框、分割蒙版和分类标签缺一不可损伤检测节点是整条管线的感知核心。只输出一个“车坏了”的结论没有任何价值我们要的是结构化位置和程度。具体做法是让视觉模型同时完成三件事目标检测。用边界框示意损伤在图片中的位置。语义分割。细化到“保险杠左侧”“翼子板下部”这类区域级粒度方便后续匹配配件编码。分类标签。区分剐蹭、凹陷、开裂、碎片脱落等损伤类别以及轻度、中度、重度的程度分级。分类标签要跟业务端对齐不能拍脑袋写。比如“开裂”在维修语境里通常意味着更换而“剐蹭”大多走修复。如果模型把开裂识别成剐蹭后面生成的定损金额就会差出一大截。检测节点跑完就会生成一份损失清单的“毛坯版”包含所有被识别出来的部位和损伤属性。还没到定金额的程度但理赔员看起来脑子里已经对“这是个什么案子”有画面了。2.4 语言模型在这里的角色不是裁判是文书管线里我安排了一个语言模型节点但它承担的并不是定损决策而是把结构化字段转译成标准报告。比如输入是上面那个 JSON输出可能是经检测本案车辆前保险杠中部存在一处中度开裂损伤建议维修方案为更换前保险杠面罩需同步确认是否存在内部支架变形。这步的意义在于理赔员和客户看到的报告是自然语言但机器关心的字段一个不少。语言模型还能帮客户写报案摘要、自动回答“下一步需要做什么”的说明文案这也是提升体验很直接的一环。不过要强调语言模型的输出必须基于上游结构化字段生成不允许它自行编造损伤部位或金额数字。在 Lite 引导词里写死“只允许描述输入 JSON 中已有的信息”生产环境里很管用。3. 定损估价维修方案和金额怎么算各方才会认3.1 “修还是换”是估价的第一道选择题定损金额的大头往往不是工时而是配件费用。所以估价的第一步是判断配件走“维修”还是“更换”。这个判断依赖下面几个输入判断因子数据来源可信度说明损伤类型视觉模型分类标签开裂、碎裂对应更换剐蹭、浅凹陷对应修复损伤面积与位置分割蒙版计算超过所在面板面积的阈值时倾向更换是否涉及结构件车型配件库关联纵梁、A柱等结构件损伤必须人工复核配件市场可得性配件库价格与库存状态缺件时即使受损不重也可能走换件这三个前端输入交叉分析后定损 Harness 会生成一个“建议方案”但这里不能直接拍板。我见过最坑的情况是模型看到保险杠开裂就建议换总成但实际上原保险杠壳体可以单独更换且成本远低于总成。这就要求规则引擎里必须配置配件层级映射细分“总成、面罩、骨架、支架”等子件而不是把所有情况都推到总成。3.2 金额计算的本质是把人工定价逻辑程序化定了修还是换下一步才是金额测算。这部分的核心逻辑并不神秘就是把理赔员的经验变成规则配件费以本地化配件库的价格为准原厂件、品牌件、副厂件分档录入。拆装工时按车型维修手册的标准工时乘以实时单价。喷漆费用喷漆面积结合漆面类型和颜色覆盖率计算。旧件残值更换件在部分险种下需要扣除残值。这些计算如果直接让模型完成数字很容易飘。实际做法是设置一个专门的定价引擎由规则驱动所有价格数据从库里查询。Agent 只负责传递配件编码、工时用量、喷漆面积这些键值对不直接参与乘除。这里分享一个教训初期我图省事让语言模型直接输出最终金额结果模型把“某车型前门喷漆工时费”和“某车型前门总成价格”混在一起生成了一份离谱的报价单。后来改成下图这种规则引擎算价、模型只做校验解释的结构再没出过类似问题。我这里说的“下图”其实没有图就是一条铁律数字计算永远交给程序不交给概率。3.3 自动放行阈值把低风险案件交给机器高风险留给人工即使规则引擎可靠我也不会让系统对所有案件自动定损。成本上不划算风险上也不可控。通常我按金额和风险把案件分成三类自动通过金额低于设定阈值、损伤类型简单、维修方案明确。比如轻微剐蹭单面喷漆系统直接出单并通知理赔员复核。人工审核涉及结构件、涉及更换总成、金额超阈值、或者图片质检不过关的自动分配给人伤定损员。自动退回明显超出保单责任范围、或涉嫌篡改图片的直接退回并触发预警。这个分而治之的思路比追求“完全自动化”现实得多。我见过好几个团队非要让系统处理所有案件结果复杂案件的坏口碑拖累了简单案件的好体验。把 70% 的简单案件自动化剩下的 30% 沉淀给人工精耕反而整体效率提升最明显。4. 规则闸门与反欺诈Agent 身边必须有一道“紧箍咒”4.1 反欺诈不是模型的活是规则引擎的活不少人在打磨视觉模型上花了很多功夫却忽略了定损环节最常见的欺诈风险根本不是靠看图片能发现的。举个很常见的例子同一辆车在短时间内反复出险每次事故的照片虽然不同角度但细节高度相似或者理赔人上传的事故照片和信息填报时间前后矛盾。这些问题从单张图片看不出毛病必须在跨案件数据里找关联。我在 Harness 里设置了一组规则闸门跑在所有环节之后、审核之前报案频率检查。同一投保人、同一车牌在过去一段时间的出险次数超限时自动标记。照片重复度检查。计算当前案件照片与历史案件照片的感知哈希相似度异常相似直接进入人工排查。损失部位一致性检查。比如上一案修的是左后门这次报案又说左后门受损且相隔时间很近就需要关注是否重复索赔。图像元数据异常。删除 GPS 之后仍然记录拍摄时间时间与报案时间段严重不符的进入风控队列。这些规则没有任何一条依赖大模型的“推理能力”全部是确定性逻辑。但它们能挡掉的案件量非常可观因为很多时候欺诈者的手法并不精妙只是在量大时不被注意到。4.2 合规兜底让每条决策都可以回放保险作为强监管行业尤其重视决策可解释性和数据完整性。我在设计 Harness 时把“过程留痕”当做一个硬需求而不是事后补加的日志。具体来说每个案件会生成一份完整的决策档案内容包括输入的原始照片和清洗后的照片每个模型节点的输出结果和置信度定价引擎使用的配件编码、工时单价、计算过程命中哪些规则、被哪个规则拦截人工审核人的操作记录和修改理由。这种设计在争议处理时特别好用。客户质疑赔偿金额不合理我们不需要重新找人看照片直接把整条决策链调出来对应到是哪个环节、哪条规则、哪个数据导致的最终结果。对内部来说也很容易复盘 Agent 到底在哪一步开始跑偏。4.3 人工介入点要“早设”而不是“后补”很多做自动化的团队有个惯性系统先跑跑完了再让人看结果。这个反馈链路太长了。我现在的做法是在管线里早早埋下人工介入点。比如损伤检测节点发现图像不清或视角不足直接挂起等补拍规则闸门命中高风险标记案件直接跳过价格计算的等待队列优先派给审核人。也就是说机器先做粗筛人类在处理疑难时只看到机器已经整理好的半成品不需要从零看一遍证据。这样安排人工审核的负担能减轻很多。而且对理赔员来说系统不是“抢饭碗”而是帮他们把脏活累活先干完了这种协作模式比单纯让模型全自动更容易获得业务部门的配合。5. 上线前必须解决的三件小事数据口径、灰度路径、效果度量5.1 标注口径不统一模型训练多少次都是原地打转定损模型的微调效果很大程度上不取决于训练轮次而取决于标注数据的一致性。我踩过最深的坑就是同一个损伤在不同标注员手里被打上了不同的标签。有人把“需要钣金修复的凹陷”标成“中度剐蹭”有人把“保险杠面罩轻微碎裂”标成“保险杠总成损坏”模型学到的全是噪音。所以项目一开始就要建立一本标注规范里面至少要写明损伤类别的最小像素面积和边界低于多少不算损伤。同区域多重损伤时如何切分是合并一个框还是拆成多个类别。哪些边缘情况必须标注“待人工确认”禁止硬猜。上传图片的拍摄角度、距离、光线要求标注数据应与线上真实数据分布一致。这个规范最好邀请有经验的定损员一起制定而不是纯算法团队自己写。定损员知道什么是“轻微、中度、重度”的真实业务边界算法团队如果闭门造车标出来的数据再漂亮也没法用。5.2 先跑影子模式再灰度放量最后才谈自动支付再好的实验室指标也不能代替线上复杂场景的考验。我把上线路径拆成三个阶段第一个阶段是影子模式。系统只跑分析不对外输出也不影响真实理赔流程。唯一的任务是积累一批“机器定损结果 vs 人工定损结果”的对照样本。这一步能暴露出大量问题比如某些车型的配件库里根本没有对应编码某些区域照片始终无法触发损伤检测。第二个阶段是人工建议模式。系统把定损报告作为建议推送给理赔员理赔员可以一键采纳也可以全部推翻。这个阶段开始收集采纳率同时让人工反馈“为什么否决”。我通常会每周拉一次否决原因清单把高频问题直接提到迭代会上。第三个阶段才是部分自动放行。限制金额上限限制损伤类型只处理最简单的那部分案件。同时保留随机抽检比例防止模型在无人注意的时候悄悄漂移。5.3 效果度量别只盯着“准确率”一个数字衡量定损 Harness 的效果我一般用五个维度同时看人工审核率多少案件完全不需要人工介入。建议采纳率人工审核模式下理赔员采纳系统建议的比例。定损时效从照片上传到结果输出的端到端时间。金额偏离率机器结果和人工复核后最终赔付金额的差距。争议率客户或维修厂对定损结果提出异议的案件比例。只盯着准确率是很危险的。准确率高可能只是因为系统只处理了最简单的案件实际业务价值的提升被掩盖。更合理的做法是在灰度期间按案件类型分别统计这几个指标每个类型单独决策是放量还是收紧。5.4 一个容易被忽略的细节给客户的文案要有人味最后说一个很容易被忽略的细节。Agent 算完账之后如果不经过包装就把“您的前保险杠开裂建议更换金额 3200 元”这样冷冰冰的文本发给客户体验会非常糟糕。我会在整条流水线的最末端加一个“话术生成”环节同样是语言模型但它只负责根据结构化结果生成温和、清晰的告知文案包含下一步操作指引和人工客服联系方式。必要时还会主动附上一句“该结果由系统辅助生成已同步理赔专员复核”既满足告知义务也减少不必要的对质。这个细节看起来小却直接决定了用户面对自动化的第一印象。系统越智能越要在对外沟通时保留必要的温度。做这套 Harness 的整个过程让我最深的体会是定损自动化的难点不在“让机器像人一样判断”而在于把判断过程拆成机器能稳定执行的动作再配一套兜住意外的规则和流程。模型会迭代、数据会变化、业务口径也会调整但分层清晰的管线、明确的数据口径和稳妥的灰度路径才是这套系统能走远的地基。如果让我给正准备启动类似项目的团队一个建议那就是别急着追求全自动先把影子模式跑透把人工和机器的边界画清楚后面的事会顺很多。