保险理赔的报案环节,一直是客户体验的痛点——表单字段多、术语晦涩、凌晨出事故找不到人协助。Travelers 最近在全美范围上线了基于 OpenAI 的 Claim Assistant,把传统表单流程改成了对话式引导,同时实现了 7×24 小时服务和高峰期的弹性扩容。这件事值得做技术拆解,因为它不只是"接个 ChatGPT",而是把 LLM 嵌进了业务流程的关键节点。
从表单到对话:理赔报案的核心改造
传统理赔报案流程是这样的:客户打开网页,面对一个长表单——事故时间、地点、涉及车辆、人员伤亡、财产损失类型……每个字段都有业务含义,但客户未必理解"third-party liability"和"collision coverage"的区别。结果就是:填错、漏填、反复修改,客服电话量居高不下。
Travelers 的 Claim Assistant 把这个流程翻转了——客户用自然语言描述事故,AI 逐步提取关键信息并确认,最终生成结构化的理赔申请。这背后的技术架构至少要解决三个问题:
- 信息提取与校验:从自由文本中准确提取理赔所需的字段,并判断是否完整。
- 流程控制:不是一次性问完所有问题,而是根据事故类型动态调整询问顺序和内容。
- 高峰弹性:暴风雪、洪灾期间报案量可能飙升数倍,AI 服务必须能自动扩容。
架构拆解:对话引擎 + 业务规则 + 弹性部署
一个生产级的 Claim Assistant,架构上通常包含这几层:
- 对话管理层:管理多轮对话状态,追踪哪些信息已收集、哪些还缺失。这不是纯 LLM 能胜任的——LLM 会"忘事",需要外部状态管理。
- LLM 调用层:用 OpenAI 的模型做自然语言理解和生成,但 prompt 必须被业务规则约束,防止模型自由发挥到业务之外。
- 规则校验层:提取出的字段要经过业务规则校验——比如保单是否覆盖该类损失、报案是否在时效内。
- 弹性基础设施:容器化部署 + 自动扩缩容,确保高峰期响应时间不退化。
关键设计决策在于:LLM 不是系统的主控,而是被调用的能力单元。主控逻辑是确定性代码,LLM 只在需要理解自然语言或生成友好回复时介入。这种"确定性骨架 + LLM 肌肉"的模式,是金融保险类场景的稳妥选择。
动手实践:一个最小化理赔对话引擎
下面用一个可运行的 Python 示例,演示 Claim Assistant 的核心逻辑——多轮对话状态追踪 + LLM 信息提取。你需要先安装依赖并准备 OpenAI API Key:
pip install openai pydantic
export OPENAI_API_KEY="sk-你的key"
import json
from openai import OpenAI
from pydantic import BaseModel, Field
from typing import Optional
client = OpenAI()
# ---- 理赔所需的结构化字段 ----
class ClaimData(BaseModel):
incident_date: Optional[str] = Field(None, description="事故发生日期,格式 YYYY-MM-DD")
incident_location: Optional[str] = Field(None, description="事故地点")
loss_type: Optional[str] = Field(None, description="损失类型:collision/theft/fire/water_damage/other")
description: Optional[str] = Field(None, description="事故简要描述")
involved_parties: Optional[str] = Field(None, description="涉及的其他方信息")
estimated_damage: Optional[str] = Field(None, description="预估损失金额")
# ---- 多轮对话状态管理 ----
class ClaimAssistant:
def __init__(self):
self.collected = ClaimData()
self.conversation_history = []
self.required_fields = ["incident_date", "incident_location", "loss_type", "description"]
def missing_fields(self) -> list[str]:
"""返回尚未收集的必填字段"""
return [f for f in self.required_fields if getattr(self.collected, f) is None]
def extract_info(self, user_input: str) -> dict:
"""调用 LLM 从用户输入中提取结构化字段"""
schema = ClaimData.model_json_schema()
prompt = f"""你是保险理赔信息提取助手。从用户的陈述中提取以下字段信息。
如果某字段在用户陈述中找不到,对应值设为 null。
字段定义:
{json.dumps(schema['properties'], ensure_ascii=False)}
用户陈述:{user_input}
请以 JSON 格式返回提取结果,只返回 JSON,不要其他内容。"""
response = client.chat.completions.create(
model="gpt-4o-mini",
messages=[{"role": "system", "content": prompt}],
temperature=0.1, # 低温度保证提取稳定性
)
try:
return json.loads(response.choices[0].message.content)
except json.JSONDecodeError:
return {}
def generate_question(self, missing_field: str) -> str:
"""针对缺失字段生成自然语言追问"""
field_descriptions = {
"incident_date": "事故是哪天发生的?请提供具体日期。",
"incident_location": "事故发生在哪里?请提供地址或区域。",
"loss_type": "这次事故的主要损失类型是什么?比如碰撞、盗窃、火灾、水损等。",
"description": "请简要描述事故经过。",
}
return field_descriptions.get(missing_field, f"请提供{missing_field}的信息。")
def process_message(self, user_input: str) -> str:
# 1. 记录对话历史
self.conversation_history.append({"role": "user", "content": user_input})
# 2. 从用户输入提取信息并更新状态
extracted = self.extract_info(user_input)
for field, value in extracted.items():
if value is not None and hasattr(self.collected, field):
setattr(self.collected, field, value)
# 3. 检查缺失字段,生成追问或确认完成
missing = self.missing_fields()
if missing:
return self.generate_question(missing[0])
else:
return (
f"理赔信息已收集完整,确认如下:\n"
f"- 日期:{self.collected.incident_date}\n"
f"- 地点:{self.collected.incident_location}\n"
f"- 类型:{self.collected.loss_type}\n"
f"- 描述:{self.collected.description}\n\n"
f"确认无误后,我们将正式提交理赔申请。"
)
# ---- 运行示例 ----
assistant = ClaimAssistant()
# 模拟客户多轮对话
messages = [
"昨天下午我在停车场被别人撞了,车头受损",
"2024-12-15,地点是朝阳区大望路SOHO停车场",
"碰撞,对方车撞了我的车头,对方车牌号京A88xxx",
]
for msg in messages:
reply = assistant.process_message(msg)
print(f"客户:{msg}")
print(f"助手:{reply}\n")
print("--- 最终收集数据 ---")
print(assistant.collected.model_dump_json(indent=2))
运行后你会看到助手逐步追问缺失字段,最终汇总确认。这个示例虽然简化,但展示了两个关键设计:
- Pydantic 模型做字段定义:既是提取的 schema,也是状态追踪的数据结构,类型安全且可校验。
- 确定性逻辑控制流程:
missing_fields()决定下一步问什么,LLM 只负责"听懂客户说的话"和"把话说得自然",不负责流程决策。
生产部署的几个硬约束
Travelers 能全美范围上线,意味着这几个问题必须解决:
合规与审计。保险理赔是强监管领域,每一轮对话、每一次字段提取结果都必须可追溯。实践中需要对每条 LLM 调用做日志记录,包括输入 prompt、模型版本、输出结果和提取置信度。建议在 extract_info 之外加一层人工复核触发——当提取结果存在歧义或置信度低时,自动转人工。
高峰弹性。暴风雪期间报案量可能从日均几百飙升到几千。容器化部署(Kubernetes + HPA)是基本要求,但更关键的是 LLM 调用的限流与排队策略。OpenAI API 有 RPM/TPM 限制,高峰期需要做请求队列 + 优先级排序——比如涉及人员伤亡的报案优先处理。
幻觉防控。LLM 可能"编造"客户没说的信息。上面的代码用 temperature=0.1 和严格的 JSON schema 约束来降低风险,但生产环境还需要做提取结果的交叉校验——比如客户说"昨天",提取出的日期要和当前日期比对;客户说"停车场",地点字段不能填成"高速公路"。
上线前的检查清单
如果你的团队也在做类似的理赔/报案助手,上线前逐项确认:
- ☐ 对话状态是否由确定性代码管理,而非完全依赖 LLM 上下文记忆?
- ☐ 结构化提取是否有 schema 约束 + 低温度设定?
- ☐ 提取结果是否经过业务规则校验(保单覆盖范围、报案时效等)?
- ☐ 是否有置信度评估机制,低置信度时自动转人工?
- ☐ 是否有完整的对话日志和字段提取审计记录?
- ☐ 高峰期 LLM API 调用是否有排队、限流和优先级策略?
- ☐ 是否做了幻觉测试——用故意模糊或矛盾的输入验证提取准确性?
- ☐ 是否有 fallback 通道——AI 服务不可用时客户仍能通过传统渠道报案?
Travelers 的全美部署说明:LLM 在保险理赔场景已经过了从实验到生产的门槛。但门槛不是"模型够聪明",而是"系统够可控"。把 LLM 放在确定性框架里当能力单元用,而不是让它当主角——这是这条路线能走通的根本原因。