2、特征工程基础：特征定义、特征类型（连续/离散/时序）、特征存储选型（Redis/Feast）

在额度定价决策链路中，特征工程是将原始业务数据转化为模型可理解、可学习的数值化表示的过程。特征的质量直接决定了定价模型的精度上限与泛化能力。本节将系统梳理特征的定义、分类体系以及生产环境下的存储选型策略。

2.1 特征定义与核心要素

特征是用于描述业务实体（如用户、订单、设备）某一可测量维度的数值或类别化表示。一个完整的特征定义包含以下四个核心要素：

2.2 特征类型：连续 / 离散 / 时序

根据数据取值空间与业务含义，特征可分为三大类型。不同类型的特征在预处理、编码方式与模型适配性上存在显著差异。

2.2.1 连续特征

取值在实数域内连续变化，具有可比较的大小关系。常见于额度定价中的收入、负债率、信用分等指标。

• 典型处理：标准化（Z-score）、归一化（Min-Max）、分箱（Bucketization）
• 模型适配：线性模型需标准化，树模型对尺度不敏感
• 注意：长尾分布特征建议做对数变换或分位数分箱

2.2.2 离散特征

取值来自有限集合，无自然顺序或顺序无实际意义。例如职业类型、学历等级、所在城市等级。

• 典型处理：独热编码（One-Hot）、标签编码（Label Encoding）、目标编码（Target Encoding）
• 模型适配：线性模型需独热编码；树模型可直接处理标签编码
• 注意：高基数离散特征（如城市代码 > 1000 类）建议使用 Embedding 或哈希编码

2.2.3 时序特征

带有时间戳维度的特征，反映实体行为在时间轴上的变化模式。在额度定价中，时序特征对捕捉用户信用波动至关重要。

• 典型处理：滑动窗口聚合（均值/最大值/趋势）、时间衰减加权、差分特征
• 模型适配：时序特征常作为静态特征输入，或使用时序模型（LSTM/Transformer）
• 注意：需严格避免数据泄露——训练时只能使用历史时间窗口内的数据

2.3 特征存储选型：Redis vs. Feast

特征存储是特征工程与模型推理之间的桥梁。在额度定价的实时决策场景中，特征存储需要满足低延迟读取、高并发、一致性与可回溯四大核心要求。当前业界主流方案分为两类：轻量级键值存储（Redis）与专用特征平台（Feast）。

2.3.1 Redis：高性能在线特征缓存

Redis 作为内存数据库，在额度定价场景中通常用作在线特征缓存层，存储实时计算或预计算的特征值。

• 优势：微秒级读取延迟、支持多种数据结构（Hash/Sorted Set）、天然支持 TTL 过期
• 劣势：无原生特征版本管理、不支持时间点回溯、数据一致性依赖外部保障
• 典型用法：用户实时画像特征（如当前负债率、近 5 分钟交易次数）

# Redis 特征存储示例：用户实时特征
# 特征键命名规范：feature:<entity_type>:<entity_id>:<feature_name>
SET feature:user:u1001:current_debt_ratio "0.45"
SET feature:user:u1001:recent_5min_tx_count "3"
EXPIRE feature:user:u1001:current_debt_ratio 300   # 5分钟过期
EXPIRE feature:user:u1001:recent_5min_tx_count 300

2.3.2 Feast：企业级特征平台

Feast 是开源的特征存储平台，提供从特征定义、离线批量计算到在线低延迟服务的完整链路。

• 优势：特征注册中心、时间点回溯（Point-in-Time Join）、离线/在线一致性校验、与 Spark/Flink 原生集成
• 劣势：部署运维成本较高、小规模场景下引入过多依赖
• 典型用法：需要特征版本管理与模型回放验证的成熟团队

# Feast 特征定义示例（Python SDK）
from feast import Entity, FeatureView, Field, ValueType
from feast.types import Float32, Int64

# 定义实体
user = Entity(name="user_id", value_type=ValueType.INT64, description="用户ID")

# 定义特征视图
user_credit_features = FeatureView(
    name="user_credit_features",
    entities=["user_id"],
    ttl="1d",
    schema=[
        Field(name="credit_score", dtype=Float32),
        Field(name="annual_income", dtype=Float32),
        Field(name="overdue_count_30d", dtype=Int64),
    ],
    online=True,
    source="user_credit_batch_source",
)

2.3.3 选型对比与决策矩阵

2.4 特征存储选型决策流程

在实际项目中，特征存储选型并非二选一，而是根据业务阶段与规模进行分层组合。以下决策流程可供参考：

1. 评估特征规模：特征数量 < 200 且无版本管理需求 → 优先 Redis
2. 评估回溯需求：需要频繁进行模型回放验证 → 引入 Feast 离线存储
3. 评估团队能力：有专职数据平台团队 → 部署 Feast 全链路；否则保持 Redis + 离线表
4. 渐进式演进：先以 Redis 上线，待特征治理痛点出现后再平滑迁移至 Feast