Feature Stores / Real-Time ML：Feast、Michelangelo 与实时决策
Feature Store 的本质不是“给模型读取特征的缓存”，而是把模型需要的业务事实做成可定义、可版本化、可回放、可服务、可监控、可审计的数据产品。
Feature Stores / Real-Time ML 解读
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| Feast docs | https://docs.feast.dev/ | 理解开源 feature store 的 entity、feature view、offline/online serving（在维护的活文档，访问日期: 2026-07-01） |
| Feast GitHub | https://github.com/feast-dev/feast | 理解工程边界、注册表、provider 和 serving 模式（活跃仓库，访问日期: 2026-07-01） |
| Uber Michelangelo | https://www.uber.com/blog/michelangelo-machine-learning-platform/ | 理解大规模 ML 平台、特征、训练、部署和监控（博客 2017-09，经典案例） |
| Metaflow docs | https://docs.metaflow.org/ | 理解 ML/data workflow、版本化、实验和生产流水线（在维护的活文档，访问日期: 2026-07-01） |
| NIST AI RMF | https://www.nist.gov/itl/ai-risk-management-framework | 把实时 ML 纳入治理、测量、监控和风险管理（AI RMF 1.0 发布 2023-01） |
核心导读
Feature Store 的本质不是“给模型读取特征的缓存”，而是把模型需要的业务事实做成可定义、可版本化、可回放、可服务、可监控、可审计的数据产品。
实时 AI 决策失败往往不是因为模型结构落后，而是因为训练和服务看到的特征口径不同、时间点错误、实时特征过期、实体映射不一致、默认值掩盖缺失、审计无法还原当时输入。Feature Store 要解决的是 AI 决策的事实层一致性。
从系统学习角度看，Feature Store 位于数据平台、模型平台和决策引擎之间的契约层。它不替代数据仓库、流处理或模型注册表，而是把“可用于决策的事实”定义成有 owner、SLO、用途边界和证据链的资产；评估它也不能只看查询延迟，还要看 point-in-time correctness、offline/online parity、freshness breach 对下游决策的影响。
它的治理边界也要明确：特征平台可以阻止过期、越权或未批准用途的特征进入模型，但不能替代信贷政策、欺诈策略、模型验证或人工复核。模型是否可靠、决策是否允许、客户影响是否可接受，仍需要模型风险、policy engine、decision service 和 workflow 共同承担。
问题定义
实时 ML 决策需要回答一个看似简单但极难保证的问题:
At decision time T,
what facts about entity E were actually available,
under which definitions, permissions, versions, and freshness guarantees?
没有这个能力，系统会出现:
- 训练集使用了未来才知道的信息，离线效果虚高。
- 线上服务用另一套代码计算特征，造成 training-serving skew。
- 多个团队重复计算“过去 30 天交易次数”，但窗口、过滤条件和时区不同。
- 支付欺诈模型读取 stale velocity feature，错误放行或误拒。
- 信贷预审批无法证明某次客户决策使用了哪些特征值。
- Agent 工具风险判断缺少实时上下文，只能依赖模型直觉。
Feature Store 解决的是特征生命周期，而不是单次特征查询。
核心原理
Feature 是带语义的业务事实，不是裸字段。一个合格特征至少需要定义:
| 维度 | 含义 |
|---|---|
| Entity | customer、account、device、merchant、case、agent session |
| Definition | 业务口径和计算逻辑 |
| Source | 原始系统、表、topic、owner |
| Timestamp semantics | event time、processing time、available time |
| Freshness SLO | 最大可接受延迟 |
| Null/default policy | 缺失、异常和默认值如何处理 |
| Allowed use | 训练、服务、监控、分析、人工辅助 |
| Prohibited use | 禁止用于某些自动决策或客户分群 |
| Privacy class | PII、sensitive、consent required、retention |
| Quality checks | range、distribution、missing、drift、schema |
| Consumers | 模型、规则、决策服务、Agent、dashboard |
| Version | 特征定义、数据源和转换逻辑版本 |
Feature Store 的核心结构通常包括 offline store 与 online store:
| 层 | 作用 | 典型能力 |
|---|---|---|
| Offline store | 历史训练、回放、验证、审计 | point-in-time join、backtesting、数据血缘 |
| Online store | 低延迟线上服务 | key-value lookup、materialization、freshness control |
| Registry | 特征定义、owner、schema、版本 | feature view、entity、依赖关系 |
| Materialization | 把批处理或流式结果推到 online store | schedule、streaming、backfill |
| Feature service | 对模型和决策服务提供特征向量 | 权限、默认值、SLO、trace |
Point-in-time correctness 是最关键的机制:
entity_id + decision_event_time
-> join only feature values available before that time
-> enforce event time, processing time, and available time rules
如果 6 月 1 日做信贷预审批，训练样本不能使用 6 月 5 日才出现的逾期结果。否则模型学到的是未来信息，不是当时可用事实。
系统/架构模型
实时 AI 决策应拆成事实层、预测层、策略层和行动层:
Data sources
-> batch transforms / streaming transforms
-> feature registry
-> offline feature store
-> online feature store
Request / Event
-> identity and entity resolution
-> feature service
-> online lookup
-> real-time computation
-> freshness and default checks
-> model service
-> rule / policy service
-> decision service
-> workflow / action
-> trace log
-> feedback and label capture
-> offline replay and retraining
模型服务输出 score，决策服务输出 action。两者不能混在一起:
| 层 | 输出 | 责任 |
|---|---|---|
| Feature service | feature vector | 事实口径、时效、权限、质量 |
| Model service | score、probability、embedding | 预测质量和模型版本 |
| Policy service | allow、deny、review、mask、constraint | 合规、风险和业务规则 |
| Decision service | approve、decline、step-up、recommend、escalate | 决策编排和责任边界 |
| Workflow service | case、task、notice、approval | 人机流程和副作用管理 |
Feature Store 和模型注册表需要绑定。模型版本必须声明依赖哪些 feature view 版本，否则线上模型变更和特征变更会互相破坏。
关键机制与取舍
| 机制 | 价值 | 取舍 |
|---|---|---|
| Offline/online parity | 降低训练和服务口径差异 | 需要统一定义和自动化验证 |
| Point-in-time join | 防止未来信息泄露 | 增加数据建模和回放复杂度 |
| Streaming features | 捕捉实时行为和风险 | pipeline lag、成本、乱序和迟到数据更难管理 |
| Freshness SLO | 明确特征可用性承诺 | stale 时必须有降级或阻断策略 |
| Entity registry | 统一客户、账户、设备、商户映射 | 身份解析错误会系统性污染特征 |
| Feature reuse | 减少重复计算和口径分裂 | 需要 owner 承担稳定性和变更治理 |
| Purpose limitation | 防止特征被滥用到不合适决策 | 会限制快速实验，需要审批流程 |
| Default policy | 线上缺失时可控降级 | 默认值可能掩盖数据事故，必须可监控 |
Freshness 不是统一标准。支付拦截可能要求秒级，KYC routing 可以分钟级，长期客户画像可以日级。关键是每个特征的时效承诺与决策风险匹配:
| Feature tier | Freshness | 常见场景 | stale 策略 |
|---|---|---|---|
| Critical real-time | seconds | 支付欺诈、account takeover | 拒绝自动放行、step-up 或人工复核 |
| Operational real-time | under 1 minute | KYC routing、Agent tool gating | 降级到保守规则 |
| Near real-time | minutes | 推荐、next-best-action | 使用 batch fallback 并标记低置信 |
| Batch | daily/weekly | 长期画像、策略分析 | 不用于毫秒级高风险动作 |
证据与控制
Feature Store 的证据不是一张特征列表，而是能回放某次决策:
decision_id
-> entity ids
-> event time / processing time / available time
-> feature values and feature versions
-> model version
-> policy version
-> decision output
-> action and feedback
发布门禁应包含:
| 控制 | 检查 |
|---|---|
| Feature contract | critical features 有定义、owner、SLO、用途边界 |
| Leakage check | 训练集通过 point-in-time 和 label cutoff 检查 |
| Parity test | offline 与 online 抽样对比，口径差异可解释 |
| Freshness monitoring | lag、stale rate、missing rate 有报警和降级 |
| Schema and quality checks | 类型、范围、分布、entity coverage、异常值 |
| Version binding | 模型版本绑定 feature view 和 transformation 版本 |
| Purpose and privacy review | 敏感特征有使用目的、权限和保留期限 |
| Incident replay | 可重现 stale feature、缺失特征或错误默认值导致的决策 |
监控指标应覆盖 freshness lag、missing rate、distribution drift、schema drift、online/offline parity、entity coverage、fallback rate、default value rate 和 downstream decision impact。
金融零售场景映射
支付欺诈:
transaction event
-> card/account/device/merchant velocity features
-> fraud model
-> policy rules
-> approve / step-up / decline / manual review
-> dispute and feedback loop
这里 velocity 特征的 freshness 比模型类型更关键。过去 5 秒同设备失败次数、同商户异常交易、同卡跨境尝试如果延迟，模型分数会失真。
信贷预审批:
- 区分营销资格、正式审批和人工复核。
- Bureau、收入、余额、关系深度和还款行为特征需要时间语义。
- 训练集必须按当时可见信息回放。
- reason code 和 adverse action 边界不能由特征平台替代，但特征平台必须提供证据。
KYC onboarding:
- 文档上传次数、OCR 失败次数、设备/IP 异常、补件历史可作为 routing 特征。
- 文档充分性和最终 onboarding 决策仍要进入规则、政策和人工例外处理。
Agent 工具风险:
agent wants to call tool
-> user role + customer context + action risk + recent behavior features
-> policy/model decision
-> allow / require approval / block
-> audit trace
Agent 场景的特征包括会话状态、最近失败工具调用、policy violation count、客户同意状态和当前 workflow state。
反模式
- 把 Feature Store 做成线上缓存表，没有特征定义、owner、SLO 和版本。
- 训练 SQL 与线上代码分离维护，导致隐性 skew。
- 训练数据没有 event time、available time，只按最新快照 join。
- stale critical feature 仍然返回成功，模型也不知道输入已过期。
- 缺失值默认填 0，但没有记录 default rate 和业务含义。
- 特征复用只追求效率，不管理用途限制、隐私分类和客户影响。
- 模型上线时不绑定 feature view 版本，特征变更变成隐性模型变更。
- 审计只能看到模型分数，看不到当时特征向量和特征定义。
最终心智模型
Feature Store 是 AI 决策系统的事实控制面。它回答“当时系统知道什么、按什么口径知道、能否用于这个目的、是否足够新鲜、能否被回放”。
实时 AI 的可靠性不是模型服务单独提供的。事实层保证输入可信，模型层负责预测，策略层定义边界，决策层承担行动责任，日志层保存证据。
SOTA 检查 (2026-07-01)
- Feast 仍是开源 feature store 的事实标准（2026-07 确认）：现为 Linux Foundation 项目，Red Hat 持续投入并将其纳入其 AI 平台叙事；2026 年社区基准显示 Java gRPC feature server + Redis online store 组合可在大规模数据集与高 QPS 下稳定达到亚毫秒级 p99 延迟。本篇以 Feast 作为开源锚点仍然成立。
- 商业格局已重排：Tecton 于 2025-08（2025-08-22 公告）被 Databricks 收购，官方定位从独立 feature store 转为「为个性化 AI agent 提供实时数据」。独立商业 feature store 赛道正收敛为大数据平台的内置能力，选型时"独立 Tecton"已不再是现役选项——评估对象变成 Databricks 平台内能力 vs Feast 自建 vs 云厂商托管。
- feature store 的消费者从模型扩展到 agent 上下文（2025-2026 趋势）：Databricks 收购 Tecton 的核心理由就是给 AI agent 供给实时事实；同时向量检索/RAG 工作负载（embedding 缓存、语义检索）成为与传统 KV 特征并列的新特征形态。这与本篇「Agent 工具风险」一节把 agent session、policy violation count 等列为特征消费场景的方向一致，且该节因此更重要而非过时。
- **架构替代路径出现：流式 SQL 数据库（如 Apache 2.0 开源的 RisingWave，2026 年讨论热点）**用增量物化视图 + PostgreSQL 协议提供"定义即持续计算"的特征供给，运维面比传统 offline/online/materialization 多组件架构更小。2026 年主流评估维度（freshness 模型、一致性保证、语义/向量能力、计算发生位置、运维面积）与本篇「关键机制与取舍」表基本同构。
- 不随版本过时的框架性结论：point-in-time correctness、offline/online parity、freshness SLO 分层（本篇 Feature tier 表）、特征用途限制（purpose limitation）、决策回放证据链（decision_id → feature values + versions）——从 Uber Michelangelo（博客 2017-09）到 2026 年各平台，这些问题一直是必答题，本篇正文以机制而非产品版本为主线，核心内容不过时。
- 治理锚点仍现行：NIST AI RMF 1.0（2023-01 发布）的 Govern/Map/Measure/Manage 四功能未变，仍是把实时特征监控、freshness breach 与决策影响纳入风险管理的有效框架；本仓库同主题延伸可见
docs/ai-foundations/papers/45-data-lineage-contracts-openlineage-ai-data-quality.md（数据血缘与契约）与docs/ai-foundations/papers/60-cd4ml-mlops-continuous-delivery-ai-release.md（MLOps 发布门禁）。