2. 拒绝原因数据来源：人工审核记录、规则引擎日志、第三方数据源、历史拒绝样本库
拒绝原因变量衍生的基础是高质量、多维度的原始数据。在实际风控场景中，拒绝原因数据并非集中存储于单一系统，而是分散在多个异构数据源中。理解这些数据源的结构、采集方式与质量特征，是后续进行变量衍生与分箱的前提。
2.1 四大核心数据源概览
拒绝原因数据主要来源于以下四个渠道，每个渠道在数据格式、实时性、结构化程度上存在显著差异：
| 数据源 | 数据形式 | 结构化程度 | 实时性 | 典型字段 |
|---|---|---|---|---|
| 人工审核记录 | 文本备注、勾选项、审核结论 | 半结构化/非结构化 | T+1 ~ T+3 | 审核员ID、拒绝代码、审核备注、通话录音转写 |
| 规则引擎日志 | JSON/键值对、事件流 | 高度结构化 | 实时/准实时 | 规则ID、命中规则列表、规则得分、触发时间戳 |
| 第三方数据源 | API响应报文、报告PDF/XML | 结构化/半结构化 | 实时/定时 | 征信报告字段、黑名单匹配结果、多头借贷数据 |
| 历史拒绝样本库 | 数据库表、离线Hive/Parquet | 结构化 | 离线（T+1） | 申请ID、拒绝时间、拒绝阶段、关联拒绝原因码 |
关键认知： 拒绝原因数据源的质量直接决定衍生变量的有效性。规则引擎日志通常是最干净、最可追溯的数据源；人工审核记录虽然信息丰富，但需要大量清洗与标准化工作。
2.2 数据源详解与采集要点
2.2.1 人工审核记录
人工审核记录是风控专家在审核过程中留下的判断痕迹，包含显性拒绝原因（如勾选的拒绝代码）和隐性拒绝原因（如审核备注中的自由文本）。
- 采集方式： 从审核系统数据库导出审核日志表，或通过API拉取审核工单数据。
- 常见字段：
reviewer_id,decision_code,decision_reason,review_comment,review_timestamp。 - 质量风险： 审核员主观性差异、拒绝代码使用不规范、备注文本中存在大量口语化表达。
- 处理建议： 建立标准拒绝代码映射表；对备注文本进行NLP实体抽取（如“收入证明不清晰” → 收入证明类拒绝）。
2.2.2 规则引擎日志
规则引擎日志是自动化决策过程中最精确的拒绝原因来源。每条日志记录了申请单触发了哪些规则、每条规则的权重与得分。
- 采集方式： 从规则引擎的事件总线（Kafka/Flume）实时消费，或从日志存储系统（Elasticsearch/HDFS）批量拉取。
- 常见字段：
rule_id,rule_name,rule_version,triggered,rule_score,threshold,hit_detail。 - 质量风险： 日志丢失、时间戳不同步、规则版本迭代导致历史日志不可比。
- 处理建议： 建立规则版本快照表；对日志进行去重与时间对齐；将多行日志按申请ID聚合为规则命中向量。
2.2.3 第三方数据源
第三方数据源提供外部征信与验证信息，其拒绝原因通常以特定字段或状态码形式返回。
- 采集方式： 通过API网关调用第三方接口，记录请求与响应报文。
- 常见字段：
third_party_code,response_status,error_message,data_quality_flag,query_result。 - 质量风险： 接口超时、数据更新延迟、第三方返回格式变更、部分字段缺失。
- 处理建议： 缓存第三方返回的原始JSON/XML；对返回码进行标准化映射；记录调用耗时与异常状态作为衍生特征。
2.2.4 历史拒绝样本库
历史拒绝样本库是离线存储的、已决拒绝申请的全量数据，通常用于模型训练与回溯分析。
- 采集方式： 从数据仓库（Hive/ClickHouse）按时间分区抽取，或从OLTP数据库归档。
- 常见字段：
application_id,reject_timestamp,reject_stage,primary_reason_code,secondary_reason_code,associated_rule_ids。 - 质量风险： 数据口径不一致（不同时期的拒绝原因定义不同）、样本选择偏差（仅保留最终拒绝样本，缺少中途拒绝记录）。
- 处理建议： 建立统一的拒绝原因码字典；保留拒绝全链路日志而非仅最终结果；对历史样本进行时间切片验证。
2.3 数据源融合架构
在实际工程中，拒绝原因数据需要从多个源汇聚到统一的数据湖或特征平台。下图展示了典型的数据源融合架构：
工程建议： 在搭建数据管道时，优先保证规则引擎日志的完整性与实时性。人工审核记录建议增加标准化拒绝代码字段（下拉选择），减少自由文本依赖。第三方数据源需设计重试与降级策略，避免因接口异常导致特征缺失。
2.4 数据质量评估矩阵
在开始变量衍生前，需对每个数据源进行质量评估。以下矩阵可作为评估参考：
| 评估维度 | 人工审核记录 | 规则引擎日志 | 第三方数据源 | 历史拒绝样本库 |
|---|---|---|---|---|
| 完整性 | 中（备注字段缺失率高） | 高（自动化采集） | 中（受接口稳定性影响） | 高（离线批量存储） |
| 一致性 | 低（审核员主观差异） | 高（规则定义明确） | 中（第三方版本变更） | 中（历史口径变化） |
| 时效性 | 低（T+1 ~ T+3） | 高（实时/准实时） | 高（实时查询） | 低（离线T+1） |
| 可解释性 | 高（含人工判断逻辑） | 高（规则逻辑透明） | 中（黑盒评分） | 高（可回溯全链路） |
常见陷阱： 不要直接使用原始拒绝原因码进行建模。不同数据源的拒绝原因码可能存在冲突（如规则引擎的“R01”与人工审核的“A01”均表示“收入不足”），必须先进行统一编码映射。建议建立全局拒绝原因码字典，并保留原始码作为溯源字段。
2.5 数据源接入清单示例
以下是一个实际项目中拒绝原因数据源接入的配置清单模板，供参考：
# 拒绝原因数据源接入配置（YAML 示例）
data_sources:
manual_review:
type: mysql
table: review_decision_log
partition_key: review_date
fields: [application_id, reviewer_id, decision_code, review_comment]
schedule: daily 02:00
rule_engine:
type: kafka
topic: rule_engine_events
consumer_group: reject_feature_pipeline
fields: [application_id, rule_id, rule_name, triggered, score, timestamp]
watermark: 10s
third_party:
type: api
endpoint: https://api.creditagency.com/v2/query
fields: [query_id, response_code, risk_level, data_quality_flag]
retry: 3
timeout: 5s
historical_reject:
type: hive
table: dwd_reject_sample_di
partition_key: dt
fields: [application_id, reject_stage, primary_reason, secondary_reason]
schedule: daily 03:00
在实际接入时，建议为每个数据源增加数据质量监控任务，包括记录数波动检测、字段缺失率统计、拒绝原因码分布漂移监控等，确保衍生变量的输入稳定可靠。