1. 特征的概念
1.1 特征&变量&指标
在以往专家规则系统时代，更多的是用
“变量”
一词来表示规则模型的入参，随着技术的发展，机器学习领域采用“特征”一词来表示算法模型所需要的入参。随着机器学习领域的广泛普及及专家规则的算法化趋势，
“特征”
一词成了更多人使用的入参统称(本文将统一用“特征”一词)。
指标
一词具备浓郁的业务含义，比如血压指标、信贷指标，具备明确的业务含义。当前，在技术领域，指标平台被普遍认为是更高阶段的BI产品，因为BI的发展基本走完了以报表为核心的固定看书阶段、以宽表为核心的自主分析阶段，进入了以指标为核心的智能用数时代。
1.2 特征之于风控体系
银行风控是银行业务管理的核心部分，主要通过一系列策略、流程和技术手段，对银行业务中可能产生的各类风险进行预防、识别、评估和控制，通常用在
全
流程
信贷(贷前、贷中、贷后)、反欺诈、安全运营等业务。
可以说特征是支撑风控模型的数据表现，是风控体系成效凸显的重要一环，银行内部的特征可以简单概括为以下几类：
1.3 实时特征工程的痛点
首先就是
特征开发难度高、部署难度大
的问题。比如存在特征穿越、离线/在线逻辑不一致的问题、存在python代码与SQL相互翻译以进行生产投产的难题。此外，还存在监控不健全、分享复用难度大等难点。
另外就是
离线回溯
的问题。内部特征的回溯需要进行稳定性和成本的平衡，比较理想的肯定是通过离线回溯系统，实现业务系统数据定期备份到这里用。但因为考虑到部署成本，实际在离线回溯时，一些数据还是直接去调业务接口，但会进行一些限速，并且做比较严格的监控，最终实现在模型回溯效果与实用成本之间实现平衡。
2. 如何建设一套易用的特征体系
2.1 特征平台定位及供需关系
笔者认为，特征平台的定位与应用目的非常清晰，即
加工特征并向风控系统及机器学习平台提供特征数据
。特征平台向风控系统提供特征数据的方式可以概括为以下三种方式：
A方式：
基本是一种大家不会采用的方式，因为提前获取了模型实例所需的外部数据、征信数据，带来了
较高的运营成本
。
B、C方式：
是通过
将模型按照数据成本进行拆分
，能够大幅度降低运营成本，其中B方式美中不足的地方在于风控系统压力较大。但，这里笔者强烈不建议用户无缘由的在B方式与C方式之间切换，因为这样的技术方案的变化还要带动模型的重构与测试，影响范围甚广，且收益甚小。
(备注：B方式的蓝色虚线，涵盖了
API访问和直接读取数据
两种方式，不再展开来说)
2.2 特征平台的场景支撑力
2.2.1 业务及功能定位
特征平台必然要包括征信特征、三方外部数据、企业内数据、图数据，并尽可能提供拖拉拽、低代码、DSL(动态脚本语言)等对敏捷迭代友好型特征加工方式的平台化产品。
2.2.2 丰富加工能力的诉求
业务系统在调用反欺诈模型时候通常会设置逃生机制。同样的道理，在计算特征过程中获取外部数据的时候，也会面临类似的问题。根据特征的应用场景，可以概括为下面三种：
支撑实时决策场景。
决策模型及数据特征考虑简单高效的思路，采用性能优先的原则。可以
容忍
特征调用所需数据计算
失败
，甚至如果决策超时会有兜底的降级策略。
支撑准实时决策场景。
一般是异步化结果响应，保障准确率优先。在数据调用失败时会重试，甚至有些关键数据接口失败要开启授信熔断并等待恢复，这些都是
保障准确率
的有效手段。
支撑离线决策场景。
特征不但支持实时决策场景，同时可以结合实时场景获得的数据，用于实现贷中、贷后等批量决策场景，用于额度管理、催收、逾期管理等业务。
2.3 计算特征的几种方式
实时计算特征。
是一种最基础的特征加工方式，就是在决策引擎调用特征引擎时，特征引擎从数据源拉取数据、完成计算并返回结果，它是一种读时计算
(类似的概念有：
读时建模
)
