2. 业务背景：催收业务流程简介，触达渠道及数据流
2.1 催收业务核心流程
催收业务是贷后管理的关键环节，其目标是在合规前提下，通过多触达渠道与逾期客户建立联系，引导其完成还款。一个标准的催收流程通常遵循“由浅入深、由低到高”的策略，按逾期天数划分为不同阶段：
| 阶段 | 逾期天数 (DPD) | 主要策略 | 触达强度 |
|---|---|---|---|
| M1 早期 | 1 – 7 天 | 智能提醒、短信、AI 外呼 | 低 |
| M1 中后期 | 8 – 30 天 | 人工电话、IVR 催缴、短信组合 | 中 |
| M2 | 31 – 60 天 | 人工电话 + 信函、施压话术 | 高 |
| M3+ | 61 天以上 | 委外催收、法务介入 | 极高 |
Drift 监控切入点： 不同阶段的触达策略切换点（如 M1→M2）是 Drift 的高发区域，策略切换时的数据流衔接错误或渠道切换延迟，常导致客户触达中断。
2.2 四大触达渠道详解
催收系统通过以下四个主要渠道与客户建立联系，每个渠道的技术实现和数据流特征各不相同：
- 电话（人工外呼）：坐席通过预测式或预览式外呼拨号，通话录音实时上传。数据流包含：拨号记录、通话时长、接通状态、坐席工号。
- 短信：通过短信网关（如 AWS SNS、阿里云短信）发送催收通知。数据流包含：发送时间、送达状态、回执码、退订标记。
- IVR（交互式语音应答）：客户接听后按键交互，完成身份验证或还款承诺。数据流包含：按键轨迹、挂机原因、IVR 菜单路径。
- AI 外呼：基于 NLP 的机器人外呼，模拟人工对话。数据流包含：ASR 转写文本、意图识别结果、对话轮次、挂机原因。
数据流共性： 所有渠道的触达事件最终都会汇聚到催收数据总线（Kafka / Pulsar），形成统一的
touch_event 主题，供 Drift 监控系统消费。
2.3 触达数据流架构
下图展示了催收触达系统的数据流架构，从策略引擎下发任务到各渠道执行，再到结果回传的全链路：
2.4 触达事件数据模型
Drift 监控系统消费的 touch_event 消息体包含以下核心字段，用于判断触达是否成功、是否存在漂移：
{
"event_id": "uuid", // 事件唯一 ID
"case_id": "CASE20250301001", // 催收案件 ID
"customer_id": "CUST10086", // 客户 ID
"channel": "phone|sms|ivr|ai", // 触达渠道
"touch_time": "2025-03-01T10:30:00Z", // 触达发起时间
"status": "delivered|failed|no_answer|busy|blocked", // 触达结果
"duration_sec": 120, // 通话时长（仅电话/AI）
"ivr_path": "1-2-3", // IVR 按键路径
"ai_intent": "promise_pay", // AI 意图识别结果
"source_system": "dialer|gateway" // 来源系统
}
常见 Drift 场景： 当
touch_time 与策略引擎下发的计划触达时间偏差超过阈值（如 > 30 分钟），或同一案件在短时间内被多个渠道重复触达（如电话和 AI 外呼同时拨打），即构成触达漂移事件。
2.5 渠道选择与 Drift 关系
不同渠道的触达成功率与 Drift 风险存在显著差异，监控系统需针对各渠道设置不同的漂移容忍度：
- 电话：实时性最高，但受限于坐席资源，易出现“排队漂移”（任务等待时间过长）。
- 短信：异步送达，延迟通常在秒级，但运营商网关故障会导致批量漂移。
- IVR：交互性强，但客户按键超时或挂机过早会导致“半触达漂移”。
- AI 外呼：并发高，但 ASR 识别错误或意图匹配失败会造成“无效触达漂移”。
理解上述业务背景和数据流，是后续构建 Drift 监控规则、设计告警阈值、定位漂移根因的基础。下一节将深入讲解 Drift 监控的核心指标体系。