4. 特征工程与特征存储：在线特征计算、特征平台设计、特征一致性保障
在额度定价的流式决策场景中，模型推理依赖的特征必须满足毫秒级延迟、高一致性和持续更新三个核心要求。本章聚焦于在线特征计算架构、特征平台（Feast / Tecton）的设计模式，以及保障训练-推理特征一致性的工程方法。
4.1 在线特征计算的挑战与架构
额度定价模型通常需要三类特征：
- 静态特征：用户画像、信用评级等，变化频率低，可从离线数仓直接加载。
- 实时聚合特征：近1小时/24小时交易次数、金额均值等，需在流式引擎中滑动窗口计算。
- 时序衍生特征：环比、同比、移动平均等，依赖历史状态存储。
关键约束：在线特征计算必须在请求到达后 10ms 内完成，否则会阻塞模型推理，导致定价响应超时。
下图展示了额度定价场景中在线特征计算的典型架构，包含实时流处理、特征存储和模型 serving 三层：
4.2 特征平台设计：Feast 与 Tecton 模式
特征平台的核心职责是统一管理特征定义、在线/离线存储和特征服务。业界主流方案对比：
| 维度 | Feast（开源） | Tecton（商业） |
|---|---|---|
| 特征注册 | YAML 定义 + Python SDK | Python SDK + 自动血统追踪 |
| 在线存储 | Redis / DynamoDB / Firestore | 自研高性能 KV 存储 |
| 离线存储 | BigQuery / Redshift / Snowflake | Snowflake / Databricks |
| 实时特征 | 需自建流处理管道 | 内置 Stream Feature View |
| 一致性保障 | 手动校验 + point-in-time join | 自动时间旅行 + 监控告警 |
| 适用场景 | 中小团队、预算有限 | 大型金融机构、高 SLA 要求 |
实践建议：对于额度定价场景，推荐使用 Feast + Redis 作为在线特征存储，配合 Flink 做实时聚合。当特征数量超过 500 个且需要严格一致性时，可评估 Tecton。
4.3 特征一致性保障
训练时使用的特征分布与在线推理时不一致，是导致模型效果衰减的首要原因。保障一致性的三个关键措施：
- Point-in-Time 正确性：训练样本必须使用特征在事件发生时刻的快照值，而非最新值。Feast 通过
historical_retrieval自动实现时间旅行。 - 特征编码对齐：类别特征的 LabelEncoder、数值特征的标准化参数，必须在训练和在线推理时使用同一份序列化文件。
- 监控与告警：实时对比在线特征与离线特征的统计分布（均值、方差、空值率），偏差超过阈值时触发告警。
常见陷阱：在线特征存储中遗漏了某个特征，导致模型推理时使用默认值填充，但训练时该特征正常。这种“静默缺失”会严重扭曲定价结果，且难以排查。
下图展示了特征一致性保障的完整校验链路：
4.4 特征平台部署清单
在额度定价系统中落地特征平台，建议按以下步骤推进：
| 阶段 | 任务 | 产出物 |
|---|---|---|
| 1. 特征盘点 | 梳理所有定价模型依赖的特征，区分静态/实时/时序 | 特征字典（含来源、类型、更新频率） |
| 2. 平台选型 | 根据团队规模和 SLA 选择 Feast 或 Tecton | 技术选型报告 |
| 3. 在线存储部署 | 搭建 Redis 集群，配置 TTL 和持久化策略 | 存储压测报告（QPS > 10k, P99 < 5ms） |
| 4. 流处理管道 | Flink 作业实现滑动窗口聚合，写入特征存储 | 实时特征延迟 < 2s |
| 5. 一致性校验 | 部署离线-在线特征对比监控 | 告警规则 + 仪表盘 |
| 6. 模型联调 | 使用 Feast SDK 替换原有特征获取逻辑 | 端到端延迟 < 50ms |
关键指标：特征平台上线后，模型推理的特征获取延迟应控制在 5ms 以内，特征一致性校验通过率 > 99.5%，否则需要优化存储索引或增加缓存层。