试用期答辩
个人经历总结
时间轴
- 6月6日入职
- 6月18号-7月3号完成意外险责任新增
- 7月4号-8月26号，意外险分润发布
- 7月29号-Present，案例分析
意外险分润
立项背景
我的职责
核心问题
业务相对复杂
1. 沟通成本高
分润计收费1月份的时候业务已经提出诉求，之间反复变动过方案，加上产品中途换人，导致一个问题: PRD 并不清楚，很多细节在做的过程中需要一点“摸索”，更需要及时发现再和各方确认
2. 本身逻辑复杂
以风控签约关联产品组为例：
- 校验产品是否允许关联
- 校验产品组是否可以关联
- 校验产品与产品组是否同保司、同险种
- 校验产品是否已经关联
- 校验产品签约时间是否在产品组生效时间内
- 如果都可以，启动事务
- 无效之前的产品组版本，以及产品组与产品列表关系
- 创建新产品组版本
- 关联新产品组版本到新的产品列表
- 关闭事务
以计费下发时收集需要的产品组为例：
- 获取距离结算超过三个月的产品组
- 计算每个产品组计费窗口
- 获取每个产品组中每个产品的每个签约窗口
- 考虑窗口的交集情况，需要非常小心窗口的开闭情况，比如对于风控签约来说，其结束时间是闭区间
- 选择符合条件的产品进行审批
资损风险高
这是计收费工程链路固有的复杂性
- 签约的时候需要处理并发与事务
- 计提计费充分考虑幂等
- 下发失败重试的设计
- 计费因子的处理尤其要小心
关键解法
事前
- 防御性编程
- 单元测试(参数化)
事中
- T0
- 灰度
事后
- T1
项目成果
案例分析
立项背景
风控策略同学在分析案件寻找新的风险特征时，简单案件完整排查需要2h+，疑难案件需要1D+。而通过LLM 的能力，在已有的投保人、被保人健康数据、财务数据、保单行为数据等基础上，可以自动、快速完成对个案的风险判断，以至于未来可以覆盖全量理赔案件。
我的职责
核心问题
关键解法
多学多问
主动买了《健康险核保与理赔》学习
积极关注论文与前沿进展
克服“不可能”
比如周末做🤖demo时 默认的 flask 接口只接受 dict 入参，大模型不认识 dict，一度觉得不能调用 tool。突发奇想觉得应该能 hack 默认的接口，所以利用 Flask有的 blueprint 机制重新注册了Http 接口, 并转换入参 json 格式变成 kv 绕过了接口默认的 dict 转换，从而在🤖侧实现了LLM 对于案件分析的调用。