#从 Demo 到生产：保险 AI 系统真正的分水岭，是可解释、可追溯、可交付

王胜利在学习
0 阅读7分钟

这不是一篇“AI 能做什么”的畅想文，而是一篇“AI 怎么上线并长期可用”的落地复盘。

这两年做保险 AI，我有个很强的体感：

很多团队都能在两周内做出“看起来很聪明”的 Demo，但 3 个月后真正跑在业务里的系统并不多。

原因并不神秘：

  • Demo 追求“答得像人”；
  • 生产系统需要“错了能解释、结论能回放、流程能审计”。

尤其在保险这种强监管、重信任行业里，模型能力只是门槛，治理能力和交付能力才是分水岭。

这篇结合我们项目（脱敏）讲三件事：

  1. 为什么“可解释 + 可追溯”是硬需求；
  2. 我们怎么把这两个能力做进系统，不靠口头承诺；
  3. 一套可复用的 90 天落地路径。

1. 先看现实：为什么 Demo 经常过，生产经常卡

保险销售场景天然复杂：

  • 语音脏数据：方言、噪音、口语、省略表达；
  • 语义高风险：一句话可能同时涉及合规、销售、情绪；
  • 组织协同长链路：坐席、主管、质检、法务、运营都要看同一份结论。

这会导致一个经典问题：

模型给了结论，但团队无法“确认这个结论是否可信”。

具体表现通常是：

  • 一线顾问：不知道系统为什么这样判断；
  • 主管：不知道这个判断能不能指导跟进优先级；
  • 合规：不知道结论是否有证据可复核；
  • 技术：线上 drift 了，定位成本很高。

所以真正难点从来不是“做一个模型输出”，而是“构建一条可复核的决策链”。

2. 我们的目标不是“更聪明”，而是“更可被信任”

我们内部把系统目标拆成三个层次：

  • 可解释：每个关键结论都能回答“为什么”；
  • 可追溯：每个关键字段都能回溯到原始证据；
  • 可交付：能稳定上线、可观测、可验收、可复制。

听起来像方法论，但必须体现在具体设计里。

下面讲我们怎么做。

3. 架构设计：用“证据优先”替代“结果优先”

3.1 端到端处理链路（简化）

通话音频
  -> ASR 转写
  -> 说话人分离 + 时间戳
  -> KYC 信息抽取（字段/证据/置信度）
  -> 意向评分（规则 + 模型）
  -> 推荐引擎（约束过滤 + 候选解释）
  -> 人审与反馈回写
  -> 数据闭环（训练/评估/策略更新）

这条链路里我们最强调的是：

所有中间结论都必须带 evidence，而不是只留最终分数。

3.2 关键数据结构（建议）

以 KYC 字段为例，不直接存“值”，而是存“值 + 证据 + 置信度 + 来源”。

{
  "field": "retirement_income_range",
  "value": "5000-10000",
  "confidence": 0.82,
  "evidence": {
    "conversation_id": "conv_20260303_001",
    "speaker": "customer",
    "start_ms": 421000,
    "end_ms": 429800,
    "text": "我一个月退休金大概八千多"
  },
  "extracted_by": "llm_v3+rule_kyc_12",
  "updated_at": "2026-03-03T10:28:11+08:00"
}

这件事很“工程”，但价值巨大：

  • 质检可复核；
  • 客服可复述；
  • 法务可审计；
  • 算法可回放。

4. 决策引擎：规则与大模型不是二选一，而是分层协作

在保险场景，纯规则容易僵，纯模型风险高。我们最后走的是混合架构：

4.1 分层职责

  • 规则层：兜底硬约束（合规红线、流程完整性、禁用表达）；
  • 模型层：处理上下文语义（意向、风险提示是否真正理解、推荐理由生成）；
  • 检索层（RAG）：注入最新条款、内部规则、产品约束。

4.2 一个简化决策流程

def decide_next_action(context):
    hard_flags = rules_engine.check(context)
    if hard_flags.blocked:
        return {
            "action": "halt_and_review",
            "reason": hard_flags.reason,
            "trace": hard_flags.trace_id
        }

    llm_result = llm_infer(context, with_rag=True)
    score = blend(hard_flags.score, llm_result.intent_score)

    if score >= 0.8:
        return {"action": "priority_follow_up", "why": llm_result.why}
    if score >= 0.5:
        return {"action": "nurture_and_collect", "why": llm_result.gap}
    return {"action": "low_frequency_touch", "why": "low_intent"}

注意这里不是追求“算法最优”，而是追求：

  • 决策边界清晰；
  • 错误可控；
  • 结果可解释。

5. 三个模块怎么落地

我们项目核心是三个模块：KYC 提取、意向评分、产品推荐。下面说具体实现侧重点。

5.1 KYC 自动提取：先解决“信息碎片化”

典型问题不是“信息不存在”，而是“信息散落在对话里，无法组织复用”。

落地策略：

  • 字段级 schema 先定死（避免自由提取导致污染）；
  • 低置信字段不自动入主档；
  • 每个字段绑定证据片段；
  • 缺失字段自动生成“下次沟通提问建议”。

核心收益：从“顾问记忆”变成“组织记忆”。

5.2 意向评分：先把排序做对

很多团队一上来优化话术，其实最该先做的是“跟进顺序”。

我们把输出从“神秘分数”改成“可执行队列”：

  • A：本周重点跟进；
  • B：继续培育，补关键字段；
  • C：低频触达，等待窗口。

并强制输出解释字段：

{
  "bucket": "A",
  "top_reasons": [
    "近2次沟通均出现明确养老规划诉求",
    "主动询问家属参与方案讨论",
    "活动参与频次上升"
  ],
  "next_action": "48小时内安排二次沟通，优先确认家庭决策角色"
}

5.3 产品推荐：先给边界，再给答案

推荐模块最容易被误解成“自动卖货”，我们实际做法是：

  1. 先做约束过滤（年龄/需求/风险偏好/合规限制）；
  2. 再给候选方案；
  3. 每个候选都给“适配原因 + 缺失信息 + 不推荐条件”。

这样前线会更愿意采纳，因为系统给的是“判断支持”，不是“替你拍板”。

6. 上线后的关键指标（不是越多越好）

我们把指标控制在一组“业务 + 质量 + 风险”组合里，避免 KPI 噪声。

6.1 业务指标

  • 跟进命中率（优先队列转化）
  • AHT 变化
  • 新人上手周期

6.2 质量指标

  • KYC 字段完整度
  • 字段证据覆盖率
  • 推荐采纳率

6.3 风险指标

  • 高风险表达拦截率
  • 误报/漏报比
  • 无证据结论占比（目标趋近 0）

如果你只能先看一个指标，我建议看：

“无证据关键结论占比”。

这个指标长期居高，后面所有“智能化提升”都会变得不稳。

7. 我们踩过的 4 个坑

坑 1：过早追求端到端全自动

结果是上线慢、反馈慢、风险高。后来改成“关键节点人审 + 自动建议”，推进速度明显提升。

坑 2：评分复杂，解释太弱

模型可能更准，但前线不采纳。最后我们把复杂度让给后端，把解释透明给前端。

坑 3：只存结果，不存证据

出错后很难定位，跨团队沟通成本极高。补了证据链后，问题定位效率提升非常明显。

坑 4：忽略银发客群沟通语境

技术上“判对了”，业务上“讲不通”。后面我们把输出语言改成更通俗、更可确认，采纳率才提升。

8. 给工程团队的 90 天落地模板

如果你也在做保险 AI，可以按这个节奏跑：

第 1-30 天：把证据链跑通

  • 定义 KYC schema；
  • 字段抽取 + 证据绑定；
  • 建立最小可回放链路。

交付物：字段准确率、证据覆盖率、回放报告。

第 31-60 天：把决策链跑通

  • 上规则引擎兜底；
  • 意向评分从“分数”改“队列 + 解释”；
  • 推荐模块加入边界约束。

交付物：优先队列命中率、采纳率、误报率。

第 61-90 天：把治理链跑通

  • 日志、权限、版本、审计流程补齐；
  • 关键模型建立灰度发布与回滚机制；
  • 形成可复用 SOP。

交付物：上线验收包（技术 + 合规 + 业务）。

9. 结语

我现在越来越确定：

保险 AI 的竞争，不是“谁先把模型接上”，而是“谁先把模型变成组织能力”。

而组织能力的最小单元，就是这三件事：

  • 结论能解释；
  • 过程能追溯；
  • 系统能交付。

如果这三件事做对了，模型迭代会越来越轻松； 如果这三件事没做对，再强的模型也会卡在 Demo 阶段。

参考资料（公开信息）

avatar
文章
阅读
粉丝