📚 课程目录第4章决策链路总览

4. 决策链路总览：从数据接入到决策输出的完整链路架构图

信用评分 KS 流式决策并非单一模型或单一规则，而是一条从原始数据流入到最终决策结果输出的完整工程链路。本章以架构图为核心，拆解链路中的 6 个关键阶段，帮助学员建立全局视角，理解数据如何在毫秒级时间内完成清洗、特征计算、模型评分、规则拦截与决策输出。

完整的 KS 流式决策链路可抽象为以下 6 个阶段，每个阶段承担明确的职责，且前后依赖关系严格：

阶段编号	阶段名称	核心职责	典型组件/技术
1	数据接入	接收上游系统推送的实时事件或批量数据	Kafka、HTTP API、文件监听
2	数据清洗与标准化	去重、格式校验、缺失值填充、字段映射	Flink/Spark Streaming、规则引擎
3	特征工程	实时计算衍生变量、时间窗口聚合、外部数据拼接	特征存储（Redis）、CEP、滑动窗口
4	模型评分	加载 KS 模型，对特征向量进行概率预测	PMML/ONNX 模型、模型服务（TF Serving）
5	规则决策	基于评分结果与业务规则进行综合判断	决策表、决策树、规则引擎（Drools）
6	决策输出	将最终决策结果返回给上游系统，并记录日志	API 响应、消息队列、审计数据库

架构要点： 第 3 阶段（特征工程）和第 4 阶段（模型评分）是 KS 流式决策的性能瓶颈所在。特征计算需要平衡实时性与复杂度，模型评分需要保证低延迟（通常要求 < 50ms）。

下图展示了从数据接入到决策输出的完整流水线架构，包含 6 个核心阶段及其之间的数据流向：

在流式决策链路中，数据流并非简单的“请求-响应”模式，而是包含多个异步环节与状态缓存。以下表格对比了各阶段的数据形态与存储方式：

阶段	输入数据形态	输出数据形态	状态存储
数据接入	JSON / Avro / Protobuf	标准化事件对象	无状态
数据清洗	原始事件	清洗后事件	无状态
特征工程	清洗后事件	特征向量（Key-Value）	Redis / 本地状态
模型评分	特征向量	评分结果（概率值）	模型参数（只读）
规则决策	评分结果 + 原始特征	决策码 + 拒绝原因	规则配置（只读）
决策输出	决策结果	响应报文 + 审计日志	数据库 / 消息队列

  实战经验： 特征工程阶段的状态管理是链路中最容易出问题的环节。建议使用 Redis 集群存储用户级特征，并设置合理的 TTL（如 7 天），避免状态无限膨胀导致内存溢出。

在完整链路中，并非所有请求都会走完全部 6 个阶段。以下 3 个关键决策点可以提前终止流程，提升系统吞吐量：

决策点 A（数据清洗后）： 如果请求数据格式严重错误或缺失关键字段，直接返回“数据异常”决策，不再进入特征计算。
决策点 B（特征工程后）： 如果命中硬性拒绝规则（如黑名单、多头借贷超限），直接返回“拒绝”决策，跳过模型评分。
决策点 C（模型评分后）： 如果评分结果低于业务设定的 KS 阈值下限，直接返回“拒绝”；如果高于阈值上限，直接返回“通过”；中间区间进入规则引擎做精细判断。

为了保障 KS 流式决策的实时性，链路各阶段需要满足以下性能指标（以单次请求为例）：

阶段	目标延迟	吞吐量要求	容错机制
数据接入	< 5ms	10,000 TPS	消息队列重试
数据清洗	< 10ms	10,000 TPS	失败跳过 + 告警
特征工程	< 30ms	5,000 TPS	降级（使用默认特征）
模型评分	< 20ms	5,000 TPS	降级（使用备用模型）
规则决策	< 10ms	5,000 TPS	降级（使用默认决策）
决策输出	< 5ms	10,000 TPS	异步写入 + 重试

注意： 以上指标为单机单链路参考值。实际生产环境中，需要根据数据量级、模型复杂度、硬件配置进行压测调优。特征工程和模型评分阶段通常需要水平扩展以应对流量高峰。

完整的决策链路必须配备监控体系，以便快速定位瓶颈与异常。建议在每个阶段埋入以下监控指标：