# 特征变量平台方案介绍

> 面向风控场景的特征（变量）平台：讲清楚它是干什么的、应该具备哪些能力、业内有哪些技术路线、各自适合谁，以及落地时最容易踩的坑。本文只做方案介绍与选型说明，不涉及代码实现。

## 一、先明确它解决什么问题

### 1.1 风控语境下的「变量」是什么

风控里通常把特征叫作「变量」。一条变量由五要素构成：**实体**（客户 / 账户 / 设备 / 商户 / 银行卡）+ **指标**（次数、金额、比率、去重数）+ **时间窗**（近 1 小时 / 7 天 / 90 天 / 历史累计）+ **过滤条件**（仅成功交易、仅本人设备）+ **加工方式**（计数、求和、最大、均值、趋势、最近一次）。

按变化速度可以分三类：

| 类型 | 例子 | 更新频率 | 典型来源 |
| --- | --- | --- | --- |
| 静态变量 | 性别、年龄、地域、职业、学历 | 月/季 | 申请资料、三方数据 |
| 动态变量 | 近 7 天申请次数、近 1 小时登录失败数、近 30 天最大逾期天数 | 秒/分/时/天 | 业务库、埋点、征信 |
| 派生变量 | 负债收入比、多头共债指数、关系网络中心度、行为序列趋势 | 随上游变化 | 前两类运算而来 |

### 1.2 没有平台时的典型困境

| 困境 | 具体表现 | 后果 |
| --- | --- | --- |
| 需求排队 | 策略同学提变量，数据同学排期写 SQL | 一个变量 1—2 周，策略迭代被拖死 |
| 口径漂移 | 同名变量不同人算，过滤条件、时间窗、去重口径各写各的 | 模型线上线下表现不一致，复盘扯皮 |
| 特征穿越 | 训练集用「最新分区」拼历史样本 | 离线 AUC 虚高，上线直接崩 |
| 在线离线不一致 | 离线 Spark 算一遍、线上 Java 再写一遍 | 同一客户两个分数，投诉无法解释 |
| 上线人肉 | 脚本+手工导数+手工同步 Redis | 变更不可追溯，出问题回滚不了 |
| 重复建设 | 三个团队各自维护「近 7 天申请次数」 | 存储与算力浪费，口径三份 |

### 1.3 平台化的四个目标

- **快**：新变量从「周」降到「小时/天」，实时变量可配置上线。
- **准**：口径唯一、可回溯、训练与服务同源，样本不穿越。
- **稳**：在线查询延迟可控（风控决策总预算通常 100—300ms，变量查询占其中几十毫秒），有降级兜底。
- **可管**：血缘、权限、审计、成本、生命周期都能说清楚。

## 二、功能全景：一个完整平台该有什么

把能力按「接入 → 研发 → 加工 → 存储 → 服务 → 治理 → 运营」七层拆开，任何一套方案都是这七层的不同取舍。

| 能力域 | 关键能力 | 主要产出物 |
| --- | --- | --- |
| 数据接入 | 多源接入、CDC、实体识别与 ID 归一、事件/维度建模 | 明细事件表、实体主数据 |
| 特征研发 | 定义、调试、试算、评审、版本 | 特征定义、特征文档 |
| 特征加工 | 批处理、流处理、实时点算、回填补数 | 特征值、特征快照 |
| 特征存储 | 离线、在线、近线、快照四态 | 宽表、KV、OLAP 表、快照分区 |
| 特征服务 | 实时点查、批量查询、训练集拼装、SDK/网关 | 在线接口、训练样本集 |
| 特征治理 | 元数据、血缘、口径、版本、权限、审计 | 特征目录、变更记录 |
| 特征运营 | 监控、质量、成本、价值评估、下线 | 监控大盘、质量报告、成本账单 |

### 2.1 数据接入与实体建模

- **多源接入**：业务库 CDC（Binlog）、日志与埋点、消息队列、三方 API/文件（征信、运营商、工商、司法）、名单库。
- **实体与主键**：客户号、证件号、手机号、设备指纹、银行卡、商户号。难点是**同一实体多 ID 归一**（一个人两台设备、三个手机号、两张卡），需要实体解析与 ID-Mapping 表。
- **时间语义**：必须区分**事件时间**（业务发生）与**处理时间**（数据到达）。风控几乎所有窗口都按事件时间算，否则补数、乱序时结果不可复现。
- **数据质量前置**：空值、重复、乱序、单位（元/分）、时区、脱敏字段的可用性。

### 2.2 特征研发（变量工厂的门面）

- **定义方式四选**：SQL（最通用）、算子化 DSL（窗口/聚合/过滤/join 组合）、Python UDF（复杂逻辑）、可视化配置（给策略同学用）。
- **在线调试**：单实体试算（输入一个客户号看所有变量值）、抽样回放（取一批历史样本跑一遍）、与旧口径对比（差异清单）。
- **版本与评审**：草稿 → 测试 → 灰度 → 上线 → 下线，每一步留痕。
- **特征文档**：业务含义、口径伪代码、取值分布、空值率、负责人、SLA。文档不是附属品，是平台能不能被复用的关键。

### 2.3 特征加工

| 加工形态 | 引擎 | 时效 | 适合 |
| --- | --- | --- | --- |
| 批处理 | Spark / Hive / 数仓 SQL | T+1 或小时级 | 慢变量、历史累计、回溯重算 |
| 流处理 | Flink / Spark Structured Streaming | 秒—分钟 | 交易监控、申请频次、实时反欺诈 |
| 实时点算 | 服务端聚合（如查询最近 N 条明细现算） | 毫秒级 | 与本次请求强相关的变量（距上次申请间隔） |
| 回填补数 | 重放 + 幂等写 | 按需 | 口径变更、历史修正、故障恢复 |

### 2.4 特征存储：四态并存

- **离线存储**：Hive / Iceberg / Hudi / Paimon / Parquet，负责历史全量与训练样本。
- **在线存储**：Redis / Tair / HBase / TiKV / 云 KV，负责「实体 → 特征向量」的毫秒级点查。
- **近线 / OLAP**：ClickHouse / Doris / StarRocks，负责明细回溯、临时分析、批量取数，也能承担中低并发的点查。
- **快照**：按日或按批物化的特征快照表，是训练集拼装和「当时值」复盘的唯一可靠来源。

### 2.5 特征服务

- **实时点查**：一次请求取一个实体的一批变量，通常用批量接口（一次网络往返拿 50—200 个变量）。
- **批量查询**：批量评分、离线回溯、策略回测。
- **训练集拼装**：按标签时间做 Point-in-Time Join，产出不穿越的样本。
- **SDK 与网关**：多语言客户端、鉴权、限流、超时预算、降级兜底（返回默认值并打标）。

### 2.6 特征治理

- 元数据与**字段级血缘**：变量 ← 中间表 ← 源表 ← 上游系统。
- **口径唯一**：同名必须同义，同义必须同名，命名规范先行。
- **权限**：按业务域、按特征、按环境（生产/测试）隔离；敏感字段脱敏；所有查询留审计日志。
- **变更管理**：影响面分析（谁在用这条变量）、双跑验证、可回滚。
- **成本**：存储、计算、QPS 配额到团队/应用维度。

### 2.7 特征运营

- **可用性**：成功率、P99 延迟、QPS、超时率、降级率。
- **质量**：覆盖率、空值率、异常值率、分布漂移（PSI/KS）、Top 值突变。
- **价值**：变量在模型中的重要性、单变量区分度（IV）、命中率、策略引用次数。
- **生命周期**：冷变量识别、僵尸变量下线、口径升级。

## 三、技术方案谱系：七种典型做法

### 3.1 离线宽表型（T+1 批）

**做法**：数仓里按实体聚合成一张或几张宽表，天级调度算好，再整体同步到在线 KV；查询就是按主键取一整行。

- 优点：实现最简单、成本最低、回溯天然成立（每天一份快照）。
- 缺点：时效只有 T+1；宽表字段数一多就爆炸（几百列后变更和重算都痛苦）；新增一个变量要动整张表。
- 适合：贷前申请评分、慢变量为主、团队小、实时要求不高的场景。

### 3.2 Lambda 架构（批流分离）

**做法**：批层负责历史与回溯，流层负责当天实时，查询时合并。

- 优点：实时性达标，历史可重算，是过去十年最主流的工程折中。
- 缺点：**两套代码、两套口径**，靠人保证一致；流层出了问题只能等批层修复；开发与运维成本翻倍。
- 适合：已有成熟离线数仓、有独立实时团队、实时变量占比中等的机构。

### 3.3 Kappa / 流批一体

**做法**：只保留一条流式链路，批处理视为「有界流」，用同一套 SQL/算子同时跑实时与回溯（Flink SQL、湖仓一体、OpenMLDB 这类时序数据库）。

- 优点：**口径唯一**，回溯就是重放；开发效率高；运维只有一套。
- 缺点：对引擎能力要求高；长窗口（90 天、历史累计）状态成本大；冷启动与补数要专门设计；SQL 覆盖不了的复杂逻辑仍需 UDF。
- 适合：实时变量占比高、对一致性要求苛刻、有实时平台能力的团队。

### 3.4 特征存储型（Feature Store 范式）

**做法**：以「特征」为中心组织：特征注册中心 + 离线/在线双写 + Point-in-Time Join + 训练与推理共用一个定义。开源代表 Feast、Feathr、Hopsworks，商业代表 Tecton。

- 优点：复用率最高，天然带治理；模型团队与策略团队共用一套特征；训练样本生产标准化。
- 缺点：**重**，需要专门平台团队；对已有数仓体系有侵入；国内三方数据与离线生态适配要额外投入；推行不当会变成「又一个元数据系统」。
- 适合：多模型、多业务线、特征被反复消费的中大型机构。

### 3.5 实时计算型（流式 + 规则/指标引擎）

**做法**：Flink 侧做窗口聚合与状态计算，配合规则引擎或指标中台直接产出变量，写回 KV 供决策引擎调用。

- 优点：秒级甚至亚秒级，天然适合交易反欺诈、盗刷、营销薅羊毛。
- 缺点：状态管理复杂（大状态、TTL、扩缩容）；乱序与补数难；逻辑写在流任务里，策略同学改不动。
- 适合：实时风控是主战场的场景（支付、消费金融的申请反欺诈）。

### 3.6 搜索 / OLAP 点查型

**做法**：ClickHouse / Doris / StarRocks 存明细与预聚合，按主键点查，顺带承担分析与回溯。

- 优点：一栈多用（点查 + 分析 + 取数 + 回溯），SQL 友好，运维比自建 KV 简单。
- 缺点：**高并发点查不是强项**，需要预聚合、分区分桶、物化视图；QPS 上万后成本与稳定性要仔细验证；单点查延迟通常在几毫秒到几十毫秒，不如纯 KV 稳。
- 适合：中等 QPS、同时需要分析与回溯、想减少组件数量的团队。

### 3.7 KV 型（在线存储底座）

**做法**：Redis / Tair / HBase / TiKV 存「实体 ID → 特征向量」，由上游批/流任务写入。

- 优点：延迟最低、吞吐最高、技术成熟。
- 缺点：无 SQL、无聚合能力，只能点查；容量成本高；批量回溯要另存一份；数据模型变更不灵活。
- 适合：作为**在线服务层**，与离线/近线组合使用，几乎不会单独存在。

### 3.8 专项型：图 / 序列 / 向量

- **图特征**：关系网络（设备共享、担保圈、团伙聚集、二度联系人风险传导），依托图数据库或图计算引擎。
- **序列特征**：行为序列、账单序列、登录序列，作为序列模型（RNN/Transformer）的输入，需要「按实体按时间有序」的存储形态。
- **向量特征**：文本、图像、行为 embedding，用于相似人群、地址文本匹配、材料识别，是近年新增的一类。

### 3.9 方案对比

| 方案 | 时效 | 回溯能力 | 在线离线一致性 | 开发效率 | 成本与复杂度 | 典型适用 |
| --- | --- | --- | --- | --- | --- | --- |
| 离线宽表 | T+1 | 强 | 好（只有一份） | 低（改表难） | 低 | 贷前评分、慢变量 |
| Lambda 批流分离 | 秒—天 | 强 | 靠人保证 | 中 | 中高（两套） | 已有数仓 + 实时团队 |
| Kappa / 流批一体 | 秒 | 强（重放） | 最好 | 高 | 中高（引擎要求高） | 实时占比高 |
| 特征存储 | 取决于底座 | 强（PIT） | 好 | 最高（复用） | 高（平台团队） | 多模型多业务线 |
| 流式实时计算 | 亚秒—秒 | 弱（需重放设计） | 中 | 低（逻辑在流任务） | 高（状态运维） | 支付反欺诈 |
| OLAP 点查 | 分钟—天 | 强 | 中 | 高（SQL） | 中 | 中等 QPS + 分析需求 |
| KV 在线层 | 毫秒 | 不适用 | 取决于上游 | — | 中 | 在线服务层 |

**结论**：现实中几乎不存在「单选」。常见组合是：**离线批处理 + 流处理补实时 + KV 做在线 + OLAP 做回溯分析**，差别只在「批流是否同一套定义」以及「有没有特征注册与治理层」。

## 四、决定成败的几个设计点

### 4.1 特征定义的抽象层级

| 层级 | 使用者 | 灵活度 | 可治理性 | 说明 |
| --- | --- | --- | --- | --- |
| 可视化配置 | 策略/运营 | 低 | 高 | 只覆盖常见窗口聚合，适合标准化变量 |
| 算子化 DSL | 数据 + 策略 | 中 | 高 | 窗口/过滤/聚合/关联组合，最推荐的中间层 |
| SQL | 数据开发 | 高 | 中 | 表达力强，但口径容易被写歪，需要模板与评审 |
| Python UDF | 算法 | 最高 | 低 | 复杂逻辑兜底，必须版本化与沙箱隔离 |

建议以「算子化为主、SQL 兜底、UDF 例外」的三层结构，而不是让所有人都写 SQL。

### 4.2 Point-in-Time 正确性（最容易翻车的地方）

训练样本的每条特征，必须是**标签发生时点之前**已知的值。常见错误是拿「最新分区」的特征表去拼两年前的样本，等于把未来信息泄露给模型。

正确做法：

1. 特征按事件时间分区，保留**每日快照**或可追溯的变更日志；
2. 拼样本时按「标签时间 → 取该时间之前最近一份快照」做 as-of join；
3. 窗口类变量的边界必须统一（含头不含尾 / 含头含尾），并在文档里写死；
4. 上线前做一次「离线重放校验」：随机抽 N 个历史时点，用平台重算，与当时线上值比对。

### 4.3 在线离线一致性

- **同源**：同一份明细、同一套算子，避免「离线 Spark、线上 Java」各写一遍。
- **双跑比对**：每天抽样若干实体，离线重算 vs 在线实查，差异超阈值就告警。
- **时间对齐**：明确「T 日跑 T-1 数据」还是「T 日跑 T 日截止到某时刻」，跨时区、跨系统时钟要统一。
- **空值与默认值**：离线写 null、线上返回 0，是最隐蔽的不一致来源。

### 4.4 实时链路的工程细节

| 问题 | 处理方式 |
| --- | --- |
| 乱序 | 事件时间 + 水位线，允许迟到窗口，超时进侧输出补算 |
| 状态膨胀 | 按窗口 TTL 清理，RocksDB + 增量 checkpoint，大状态单独扩容 |
| 重复消费 | 消息 ID 去重 + 幂等写（按「实体+时间窗」覆盖写） |
| 补数 | 重放 Kafka 到指定时间点，或直接用批任务回填后覆盖 |
| 堆积降级 | 监控消费延迟，超阈值切 T+1 兜底值并打标 |
| 变更发布 | Savepoint + 双跑 + 灰度，禁止直接改线上算子 |

### 4.5 容量与性能估算

在线存储容量可用一个粗略公式估算：**实体数 × 特征数 × 单值字节 × 副本数 × 冗余系数（约 1.3）**。例如一千万实体、200 个特征、单值平均 8 字节、双副本，量级在数十 GB 到百 GB，属于单机群可承载的范围；真正吃资源的是**特征数膨胀**与**历史快照**，而不是实体数本身。

查询性能主要看三件事：单次请求的变量个数、是否批量接口、是否命中本地缓存。实践中把「一次决策需要的 100—200 个变量」做成一次批量点查，比拆成 20 次调用稳定得多。

### 4.6 服务层设计

- **超时预算**：决策总预算 100—300ms 时，变量查询一般给 30—50ms，超时立即降级，不能拖垮整条决策流。
- **多级缓存**：进程内缓存（热点实体）+ 分布式缓存 + 存储回源。
- **兜底**：降级返回默认值与「降级标记」，下游模型按标记走保守策略。
- **熔断与限流**：按应用维度配额，防止一个批量任务打垮在线。

### 4.7 版本、灰度与回滚

特征要有**语义版本**：口径变更必须升版本，旧版本保留一段时间双写。上线流程建议「影子流量（新老并行只记录不决策）→ 小流量灰度 → 全量」，任何一步都能在分钟级回滚。

### 4.8 复用与「特征市场」

平台价值的一大半来自复用。需要：可搜索的特征目录、按业务域/实体/主题分类、热门与相似特征推荐、复用率指标（同一特征被多少个策略/模型引用）。没有复用指标，平台会退化成「一个人用的脚本仓库」。

### 4.9 可解释性与合规

风控是强监管场景，变量不仅要算得对，还要**解释得清**：

- 每条变量必须有业务含义（不能是黑盒 embedding 直接进拒绝理由）；
- 拒绝原因可回溯到具体变量与阈值；
- 数据分级分类、最小必要、脱敏、访问审计；
- 三方数据要有授权与使用范围记录；
- 模型侧配合 SHAP / 评分卡，保证「为什么拒」可向客户与监管说明。

### 4.10 成本控制

- 冷热分层：近期数据热存、历史归档；
- TTL：行为类变量设合理保留期；
- 预聚合代替明细扫描；
- 用批处理补历史，而不是把长窗口都放流里；
- 按业务价值下线低价值变量（长期无人引用、区分度接近 0）。

## 五、风控业务视角：变量在各环节怎么用

| 环节 | 典型决策 | 主要变量族 | 时效要求 |
| --- | --- | --- | --- |
| 贷前申请 | 准入、额度、定价 | 身份、征信、负债、多头、设备、行为 | 秒级 |
| 反欺诈 | 拦截、转人工、加强核验 | 设备指纹、关系网络、申请频次、资料一致性 | 亚秒—秒 |
| 贷中管理 | 预警、调额、冻结 | 交易行为、还款行为、额度使用率、外部风险信号 | 分钟—天 |
| 贷后催收 | 分案、触达策略 | 逾期天数、还款能力、联系活跃度 | 天 |
| 名单与团伙 | 黑名单命中、团伙识别 | 名单库、图特征、共享设备/联系人 | 秒—天 |

常见变量族清单：

| 变量族 | 举例 | 加工要点 |
| --- | --- | --- |
| 身份类 | 年龄、户籍、职业稳定性 | 静态为主，注意三方数据时效 |
| 设备类 | 设备指纹、装机数、Root/越狱、模拟器 | 需要设备图谱与 ID-Mapping |
| 行为类 | 近 1 小时登录失败数、页面停留、申请间隔 | 流式窗口，注意乱序 |
| 交易类 | 近 30 天交易笔数/金额、夜间交易占比 | 批流结合，金额单位统一 |
| 负债类 | 多头借贷、共债机构数、负债收入比 | 依赖征信与三方，注意口径 |
| 名单类 | 黑/灰/白名单、司法涉诉 | 命中即用，需版本与来源审计 |
| 关系类 | 二度联系人逾期率、设备共享数、担保圈 | 图计算，注意隐私边界 |
| 时序类 | 账单序列、行为序列、还款序列 | 序列存储 + 序列模型 |

## 六、落地路线：三个阶段

| 阶段 | 目标 | 推荐架构 | 关键动作 | 主要风险 |
| --- | --- | --- | --- | --- |
| 起步（0—6 个月） | 需求从周降到天，口径统一 | 离线宽表 + KV 在线 + 统一命名与文档 | 先做 30—50 个高频变量；建口径文档；接通在线点查 | 直接上大平台，投入大、见效慢 |
| 成长（6—18 个月） | 实时变量可用，治理成型 | 批流分离或流批一体 + 特征注册 + PIT + 监控 | 引入特征元数据、血缘、双跑校验；实时变量占 20%—30% | 批流两套口径漂移；监控缺失导致线上事故 |
| 成熟（18 个月以上） | 复用率高、可运营 | 统一特征存储 + 图/序列/向量 + 价值运营 | 特征市场、复用率考核、成本分摊、下线机制 | 平台化过度，变成流程负担 |

落地顺序建议：**先把口径和回溯做对，再追求实时**。回溯错了，实时只会让错误更快发生。

## 七、常见坑与反模式

| # | 反模式 | 后果 | 规避 |
| --- | --- | --- | --- |
| 1 | 用最新分区拼历史样本 | 特征穿越，离线虚高 | PIT Join + 快照表 |
| 2 | 离线 Spark、线上 Java 各写一遍 | 同人不同分 | 同源算子 + 双跑比对 |
| 3 | 变量直接查业务库 | 拖垮核心系统 | 只读从库/数仓，禁止直连生产 |
| 4 | 宽表无限加列 | 变更困难、重算代价大 | 按主题拆表 + 特征注册 |
| 5 | 只做离线不做快照 | 无法回溯、无法复盘 | 每日快照保留 |
| 6 | 变量无业务含义（纯 embedding 进拒绝） | 拒绝不可解释 | 关键决策用可解释变量 |
| 7 | 没有 owner | 出问题无人认领 | 每条变量有负责人 |
| 8 | 口径靠口头约定 | 三份实现 | 命名规范 + 文档 + 评审 |
| 9 | 在线接口无超时降级 | 一个慢查询拖垮决策 | 超时预算 + 兜底值 |
| 10 | 特征数量只增不减 | 成本失控、模型过拟合 | 生命周期与价值评估 |
| 11 | 流任务频繁直接改线上 | 状态不兼容、结果错乱 | Savepoint + 双跑 + 灰度 |
| 12 | 平台先行、需求在后 | 建了没人用 | 从 3—5 个真实决策场景切入 |

## 八、选型决策清单

| 你的情况 | 建议路线 |
| --- | --- |
| 团队 < 5 人、变量 < 100、只做贷前 | 离线宽表 + Redis，别上平台 |
| 有实时反欺诈诉求、已有 Flink 能力 | 批流一体（同源算子），KV 做在线 |
| 已有成熟数仓、实时团队独立 | Lambda 先跑，逐步收敛到同源定义 |
| 多业务线共用、模型团队多 | 特征存储范式 + 特征注册 + PIT |
| 分析需求与点查需求并重 | OLAP（CK/Doris）承载点查与回溯 |
| 团伙/关联风险突出 | 增加图特征专项，独立图存储 |
| 强监管、需逐条解释 | 变量以可解释指标为主，黑盒特征只做辅助 |

## 九、演进趋势

- **流批一体**成为默认选项：Flink SQL、湖仓一体（Iceberg/Hudi/Paimon）、时序特征数据库让「一次定义、两处执行」变得可行。
- **特征平台与模型平台融合**：特征、样本、训练、推理打通，模型上线不再单独导特征。
- **实时决策闭环**：变量 → 规则/模型 → 决策 → 反馈数据自动回流，形成分钟级迭代。
- **图与序列成为标配**：团伙识别、行为序列模型从加分项变成基础能力。
- **向量与多模态特征**：文本、图像、语音 embedding 进入风控（资料识别、地址校验、客服质检）。
- **隐私计算**：联邦学习、可信执行环境用于跨机构特征合作，解决「数据不出域」。
- **LLM 辅助特征工程**：自然语言描述生成候选变量、自动补口径文档，但可解释与合规仍是硬约束。

## 十、竞品与选型参考

| 产品 / 厂商 | 类型 | 优点 | 局限 |
| --- | --- | --- | --- |
| OpenMLDB（第四范式开源） | 开源实时特征数据库 | 离线与实时同源 SQL、时序窗口能力强、国内社区活跃 | 需自运维，生态较新，复杂逻辑要写 UDF |
| Feast | 开源 Feature Store | 轻量、特征注册与在线/离线统一、多云中立 | 偏「注册与读取」，实时计算弱，生产化组件需自建 |
| Tecton | 商业 Feature Store | 端到端能力强、PIT 与监控完善、接入快 | 闭源、价格高，国内部署与数据合规受限 |
| 阿里云 PAI 特征平台 / 华为云数据使能 | 云托管 | 与训练推理打通、运维托管、弹性 | 厂商绑定，离线实时能力与本地数仓适配成本高 |
| 商业风控变量平台（同盾、邦盛等） | 行业方案 | 风控变量库现成、开箱即用、实施快 | 黑盒、定制受限，二次开发与迁移成本高 |

> 选型要看三件事：能否做到离线实时同源、能否做 PIT 回溯、治理（血缘/版本/权限）是否开箱可用，而不是先比组件数量。

> **资料来源与时效**：厂商官网与公开产品文档、开源项目文档/仓库、公开技术文章与行业报告，以及行业常见实践；信息整理截至 **2026-10**，未逐一与厂商核实。产品能力、定价与版本会随迭代变化，选型前请核对官方最新资料并做 POC 验证；本节不构成选型推荐，也不含厂商商务信息。

## 十一、与其他风险系统的关系

| 系统 | 关系 | 交互内容 |
| --- | --- | --- |
| 数据接入与数据服务 | 上游 | 明细事件与三方字段，作为变量原料 |
| 规则引擎 | 下游 | 通过变量服务点查/批量取数，供决策流使用 |
| 模型平台 | 双向 | 提供 PIT 样本；模型分数可回流为衍生变量 |
| 名单服务 | 并行 | 名单命中可作为变量来源之一，但口径需独立 |
| 贷中监控 | 下游 | 行为与外部信号变量 |
| 决策留痕 | 下游 | 变量快照随决策落库，支持回溯 |
| 策略分析 | 下游 | 变量分布、漂移与区分度分析 |

## 十二、术语表

| 术语 | 含义 |
| --- | --- |
| 特征 / 变量 | 描述实体某一属性的数值或类别，风控里多称变量 |
| 实体 | 被描述的对象：客户、账户、设备、商户 |
| Point-in-Time Join | 按标签时间取当时特征值，防止特征穿越 |
| 特征穿越 | 训练时用到了预测时点之后才有的信息 |
| 在线存储 | 支撑毫秒级点查的 KV/缓存 |
| 特征快照 | 某个时点全量特征值的物化副本 |
| 特征注册中心 | 特征定义、元数据、血缘、版本的统一登记处 |
| PSI | 群体稳定性指标，衡量分布漂移 |
| IV | 变量区分度指标 |
| 双跑 | 新旧逻辑并行计算并比对差异 |
| Savepoint | 流任务状态快照，用于升级与回滚 |

---

> 本文是方案说明，不含实现细节。具体落地时，建议先定口径与回溯规则，再选引擎与存储；平台的价值不在组件多少，而在「同一条变量只存在一种正确算法」。