实习日志 / 中文 / 分流与欺诈提醒 / 不判断谁在骗保：报案分流和欺诈提醒怎么设计

不判断谁在骗保：报案分流和欺诈提醒怎么设计

题目对报案受理环节提了两个要求。一是把每一单报案分成快速、常规、复杂三类，并由理赔人员盲审分类结果；二是标记欺诈信号，但不做欺诈认定，而且在测试集里不能出现一次误报。

9 月 30 日我去核对代码时，后端两样都没有。代码里有一个"严重程度"字段，但没有任何地方给它赋值；"欺诈信号"字段只有员工能手动改，系统自己从来不会产生它。于是我写了一份设计，给两件事各定了一套规则。写之前先定了一个基调：两套规则都不是判决。分流只说明这单接下来需要多少人工，欺诈提醒只说明有件事值得员工看一眼。

分流分的是什么

分流判断的是：报案提交以后，这一单能直接往下走，还是需要常规跟进，还是需要有经验的人来看。它不判断事故本身有多严重。

这个区分很重要。真正严重的情况，比如有人受伤、现场还有危险，客户一般不会在 agent 上花时间，系统本来也会直接转人工，代码里已经有这条紧急通道。这类报案如果最后形成了理赔单，分流结果直接就是复杂。

用测试样例说明三类的区别：

倒车撞到停车场的柱子，保险杠凹了，照片和报价都齐，没有别人牵涉。这一单可以直接往下走，是快速。
楼上水管爆裂，厨房天花板泡坏了，但报价单只传了第一页。事情不复杂，可总得有人去追第二页，是常规。
有人受伤，或者对方车主不认责任，或者客户对免赔额有异议。这类需要有经验的人判断，是复杂。

按顺序问三个问题

第一，有没有需要专业判断的情况？ 下面任何一条成立，就是复杂：

有人受伤，或现场有危险，或已经转了紧急人工；
牵涉其他当事人，而且责任还没确认或者有争议。责任记在一个新增的登记字段里，取值是对方认责、我方认责、双方都有责、有争议、不清楚，有争议或不清楚就是复杂；
保不保说不清：保单查询的结果本身带着不确定的标记（比如保单没写这类事故保不保），或者 Agent 明确记下了"这次损失可能不在保障范围内"；
客户对免赔额或保障范围表示不认同；
房子没法住，或者还有持续的损坏风险，比如还在漏水；
欺诈提醒到了"需复核"这一级。

第二，如果不复杂，有没有需要人跟进的事？ 下面任何一条成立，就是常规：

有必需的材料没交、看不清、缺页，或者暂时拿不到，比如警方报告还没出；
有必需的问题客户还没回答，或者回答"不知道"；
客户前后说法不一致，或者材料和陈述对不上，而且还没澄清；
保单查不到（查不到不等于没问题）；
车不能开、需要拖车，或者需要派定损员；
牵涉其他当事人，但责任已经明确。要找对方或者对方的保险公司追偿，总得有人跟进；
损失金额超过 5,000 新西兰元，或者完全不知道金额；
欺诈提醒只到了"提示"这一级；
可能是重复报案。

第三，以上都没有，才是快速。

三类之间取最高的那一类，但所有命中的原因都要记下来，让理赔员知道为什么这样分。

边界要往保守的一边倒

几条边界规则决定了这套规则会不会出事：

拿不准的一律不给快速。 任何该有的信息缺失、未知或者查不到，结果最多是常规。
金额取所有来源里最大的那个。 来源是新增的"估计损失金额"字段，客户自己估的，或者报价单、定损单上含 GST 的总额；财产险则把各项物品的金额加起来。正好 5,000 算快速，超过才算常规。
5,000 这条线是怎么来的。 业界的分流门槛由保险公司按理赔员的处理能力自己定，没有统一的数字。DataRobot 的理赔分流文档举的例子，正是"预测损失低于 5,000 美元的走直通处理"。所以我们把它做成可配置的数，默认 5,000 新西兰元，展示时说"可配置的业务门槛，默认值参照业界示例"，不说成新西兰的行业标准。
和业界对直通处理的说法对得上。 只有玻璃损坏、责任清楚的单车小事故、有限的水损或风损、没有人受伤的单方事件最适合直通；有欺诈迹象、责任不清、多车多方、有人受伤、事实有争议的，一般不走直通。
材料晚到也算常规。 比如警方报告还没出，分流上算常规，因为总得有人跟进。这和"一次报案不需要后续补充"那个指标是两回事，互不影响。
算一次，有变化就重算。 报案提交、形成理赔单时算一次；之后只要有新信息进来，比如补了材料、澄清了事实、员工处理了某条提醒，就重新算。
没有形成理赔单的报案不分流，比如中途就转了紧急人工的。
分类和原因只给员工看，客户那边看不到。

员工能不能改分类，我前后想法变过一次。最初的方案是理赔员可以改，改过以后系统不再覆盖，只在旁边显示"按现在的规则会分成什么"供参考。第二天我改了主意：员工不能改分类，工作台上只显示分类和理由。

怎么检验分流

题目要求理赔人员盲审。做法是挑 10 到 15 个案例，只给摘要、不给系统的结论，请没参与设计的人独立分类，再和系统的结果对比。

这里有一件需要说清楚的事：受控测试集的标准答案也是按这套规则标的，所以系统在受控集上答对，只能说明代码照着规则做了；规则本身合不合理，要看盲审的结果。这两个数字必须分开报告。

欺诈提醒：做什么，不做什么

系统不判断谁在骗保。它只做一件事：发现能拿证据说清楚的不对劲，就在员工那边提醒一下。员工看过以后，可以确认需要调查，也可以直接驳回。

这和我们调研时总结的行业做法一致。新西兰的保险公司在理赔时会核查身份、保单、事故、所有权和历史记录，发现不一致就交给人复核，但从不因为一个地方对不上就认定欺诈。

几条底线：

客户完全看不到提醒。 需要澄清时，比如收据日期对不上，Agent 就像处理任何普通的前后不一致那样，平常地请客户再确认一下，不提"可疑"两个字。
不使用任何个人属性，年龄、民族、语言、住址、职业一律不用。
不引入第三方的风险评分。 现有代码对接外部数据时，本来就有意把对方给的欺诈标签和风险分丢掉，这个做法保持不变。
系统查不了的，就记作"没查"，不当作"查过了，没问题"。

看哪些不对劲

强的异常：单据日期和事故日期矛盾，而且矛盾就写在纸面上。有两种：

证明所有权或购买的单据，日期晚于出事日期。比如客户说笔记本 9 月 24 日被偷，交上来的收据却写着 9 月 26 日购买；
维修报价或定损报告，日期早于出事日期，等于出事之前就已经有了这份损坏的报价。

弱的异常：单独看，都可能只是运气不好。

过去一年里，同一个人已经提交过两次或更多理赔；
保单生效不到 30 天就出事。这一条要知道保单第一次生效的日期。保单查询结果里的起始日是本期保单的起始日，每年续保都会变，拿它来算，刚续保的老客户也会被当成"刚投保"。所以只有拿到首次生效日才做，拿不到就不做。

另外单列一种：可能是重复报案。同一个人、同一类险种，另有一张已经提交的理赔单，事故日期相差三天以内。这只提醒员工"可能重复"，不算欺诈，多半是客户手滑报了两次。

怎么分级

只有一个弱的异常：给员工一个小提示，不改变理赔单的欺诈状态，也不算"标记"；
有一个强的异常，或者两个弱的异常同时出现：才把欺诈状态改成"需复核"，这才算"标记"；
"调查中"这一级只能由员工设置，系统永远不会自动升到这一级。

这么保守，是因为题目要求测试集里不能冤枉一个人，所以宁可少标，也不能标错。

防止冤枉人

保守的分级之外，还有一组规定专门用来防误报：

日期按新西兰时间的自然日比较。同一天买、同一天出事，不算矛盾，至少要差一天；
客户只知道一个时间段，比如"白天上班时被偷"，就按对客户最有利的那一端算。查收据是否晚于出事，用时间段的最后一天；查报价是否早于出事，用时间段的第一天；
补打印的收据上往往有两个日期，只看购买日期，不看打印日期；分不清哪个是购买日期的，这张单据不参与判断；
只有收据、购买凭证、所有权证明参与"晚于出事"的检查，只有维修报价和定损报告参与"早于出事"的检查，其他单据的日期一概不看；
出事日期不知道，或者单据上的日期看不清、页面缺了，就记作"没查"；
客户主动做了解释，比如"这是后来换新的收据"，提醒照样发出，解释附在提醒上一起交给员工，系统不判断解释是否成立；
查重复和查次数，只看已经提交的理赔单，不看本单，也不看没提交的草稿，所以客户重开一次对话不会被当成重复；
查历史时系统出错，重复和次数两项都记作"没查"；
被判为同一件事的重复报案，不重复计入一年内的次数；
同一张理赔单上，同一种异常只提醒一次，重新计算时不重复发；
员工驳回的提醒不再参与分级；之后出现新的证据，比如又交了一张有问题的单据，会产生一条新的提醒。

调研里还看到，有的新西兰保险公司在报案时要求客户确认"所答属实，并知晓理赔信息可能被登记和共享"，而我们的最终确认页没有这一步。所以方案里在最终确认页加了这句如实声明，并记下客户确认的时间。它不参与任何判断，作用是提醒客户如实回答，同时留下记录。

怎么检验欺诈提醒

先把几个词定清楚。"标记"指系统把欺诈状态改成了"需复核"。测试包的标准答案，意思是"这一单该不该有人看一眼"，和"这是不是欺诈"无关，所以收据晚于出事的包一律算该标，哪怕故事里有一个无辜的解释：该看的就要看，看了再由员工判断。"误报"是指不该标的包被标了，目标是零。另外要报告该标的包里标出了多少，并写明总数；"提示"级和"没查"的数量也单独报告，不能藏起来。

这套规则能抓到的，是单据和记录层面能核对的矛盾，抓不到一个编得很圆的故事。所以展示时的说法应当是"在受理阶段就把可核对的异常交给人"，不能说"识别欺诈"。

落到代码里

实现上尽量复用现有的机制：

分流写成一个独立的纯函数，输入是理赔单的事实、材料状态、保障状态和当前有效的提醒，输出分类和全部原因，立案时调用，之后信息变化时重算；
欺诈提醒复用现成的"员工复核信号"。它在代码里的注释本来就写着"只给员工看的复核证据，永远不是自动结论"，工作台已经能列出这些信号，员工也已经能确认或驳回，只需要新写一个产生信号的规则文件；
新增三个登记字段，和其他字段一样由模型提出、客户确认：客户对免赔额或保障是否不认同、责任（只在牵涉其他当事人时问）、估计损失金额（客户说了或者单据上有才记，不强制追问）；
需要一组可见性测试，确认客户能看到的任何页面、Agent 的任何回复里，都不出现分类、原因和提醒。

核对代码时还发现了两个坑。一个是"保不保说不清"的判定来源。不能直接用保障状态等于"需复核"来判断，因为运行时只要查到保单，就一律把保障状态设成"需复核"，照它判，每一个查到保单的报案都会是复杂。正确的来源是保单查询记录上的不确定标记，加上 Agent 记下的"可能不在保障内"。另一个是上传文件的类型：客户在聊天里上传，图片一律记成事故照片，PDF 一律记成"其他文件"，只有从详情页补交某项要求的材料时才会带上"维修报价""收据"这类类型。不解决这个，所有报价和收据都算"没交"，分流最低是常规，日期检查也找不到该查的单据。所以聊天上传需要一种定类型的方式，比如由模型读文件时给出类型。

整个方案里最没把握的一环，是从收据、报价单、定损报告里读出购买日期或开票日期。这一环做不完，就没有强的异常，欺诈提醒基本只能靠"两个弱的同时出现"，能标出来的会很少，展示时如实说明就好。

优先顺序也按这个排：分流和它的可见性测试最先做，它是题目的硬要求；测试开关和上传类型紧随其后，没有它们，受控测试集里没有一个包能分到快速；然后是重复报案和报案次数，它们只用自己数据库里的数据；再然后是异议字段和如实声明；最后是读单据日期。

对测试集的要求

最后，这份设计也给测试集提了要求。分流的标准答案按规则标，并写出预期命中的原因，方便逐条对账；欺诈的标准答案按"该不该有人看一眼"标，并写出预期会出现哪些异常、哪些项应当是"没查"。

30 个测试包里，该标的放 5 个：收据晚于出事的 2 个（其中一个的出事时间是一个时间段），报价早于出事的 1 个，"一年内多次理赔"加"保单刚生效"同时出现的 2 个。看起来可疑、其实无辜的对照放 4 个：补打印的收据上同时有购买日期和打印日期；同一天买、同一天被偷；过去一年只有一次理赔；一处和日期无关的普通前后不一致。另外至少放 2 个历史查询出错的包，检查"没查"不会被当成"没问题"。

对照组是这份要求里我最在意的部分。一套欺诈规则好不好，不只看它抓到了几个，更要看它在那些"看起来像、其实不是"的案子面前，能不能忍住不标。