特征工程实时化与 LLM 自动发现：从批量架构到流式 SQL 与特征市场的演进

特征工程正经历自”脚本式特征”向”特征存储（Feature Store）”跃迁之后的第三次范式跃迁：从以天/小时为周期的批量管道，转向以秒为单位的实时服务；从人工手工构造特征，转向 LLM/Agent 驱动的语义特征自动发现；从各团队重复造轮子，转向”特征即产品”的内部特征市场。这三股力量叠加，正在重塑特征工程的技术架构与组织经济。

一、为什么是现在：决策窗口压缩到秒级

实时 AI 系统只和它的推理上下文一样”新”。当特征滞后，模型推理的是”已经不存在的世界”——一小时前就售罄的库存、已经起飞的航班、已经变动的价格。这类失败往往伪装成模型问题：离线指标漂亮，线上答案却错误，团队于是反复重训，却不去测量陈旧度（staleness）。每条特征都隐含着一个新鲜度 SLA，只是”无人声明”的版本等于”批任务上次跑完的时间”。实时化不是把管道跑得更快，而是对”这个特征多旧算太旧、超龄了怎么办”给出每个特征的显式答案。

二、主线一：实时化与服务新鲜度 SLA 演进

新鲜度预算分解是理解实时特征可靠性的关键。以”近 5 分钟跨商户交易数”这类行为特征为例，其链路为：支付事件入 Kafka（约 100ms）→ Flink 滑动窗口维护计数（约 500ms–2s）→ 写入离线特征库（约 1s）→ 定时 promotion 到在线库（约 5–30s）→ 推理服务读取（约 2–10ms）。推理服务自身 p99<50ms 是对的，但它读到的特征实际反映 5–45 秒前的世界，而这条新鲜度 SLA 几乎从不被测量和暴露。特征的真实新鲜度预算，是其所有组件最坏传播延迟的最大值——一个快特征救不了同决策里的一个慢特征。

工程上的正确做法是按特征分档声明 Freshness SLA 并分级路由：司机 GPS 与可用性需 30 秒内（Flink 按事件触发写 Redis）；餐厅备餐时长容忍 5 分钟（Flink 5 分钟滚动窗口）；历史类特征可容忍 1 小时（微批/Spark）。训练侧则用 point-in-time join 重建历史时刻可用的特征值，防止未来信息泄漏。中文实践（hqwc）同样给出三级 SLA：用户实时行为 30 秒、用户画像 2 小时、商品静态属性 24 小时，并以 Flink Watermark 容忍乱序、用”逻辑过期+互斥锁”解决缓存穿透。关键纪律是在 serving lookup 处测量陈旧度（freshness = now − event_time），超龄即披露/回退默认值/拒绝，绝不允许”静默提供陈旧特征”。

特征类型	新鲜度档位	计算路径	成本画像
静态属性（信用等级、账户龄期）	<24 小时	定时批作业	最低
滚动聚合（需求汇总、计数）	<1 小时	增量 Auto Loader	中等
实时行为（GPS、点击流、在途状态）	秒~分钟	流处理 + 在线库	最高（永不下线计算）

三、主线二：流式 SQL 物化视图消除批量架构

传统实时特征管道要串联 Debezium（CDC）+ Kafka（传输）+ Flink（计算）+ 在线数据库（服务）四个分布式系统，每个 hop 都加延迟、加运维负担。新一代流式数据库用单系统替换这条多跳链路：以 RisingWave 为例，原生 PostgreSQL CDC 直接捕获变更，用一条 CREATE MATERIALIZED VIEW 把”特征即连续查询”定义出来，数据库事务日志就是行为信号的持续流，端到端延迟典型在 2 秒以内、部分场景亚秒。它用 PostgreSQL 线协议对外服务，任何 Postgres 客户端库即可按实体 ID 读取预计算结果，p99 在 10–20ms——无需自定义 SDK、无需缓存预热、无需 TTL 治理。

更关键的是天然消除 training-serving skew：同一段 SQL 既定义训练特征（sink 到 Iceberg/数仓做历史训练），也定义服务特征（实时增量维护的物化视图）。训练读历史表、服务读实时视图，二者由同一逻辑计算，模型两侧看到的是同一个世界。这与传统”离线算好、定时 promotion 到在线库当缓存”的架构形成根本对比——后者在线库刷新以秒/分钟计，无法支撑百毫秒级有效窗口内的决策。

流式数据库	SQL 方言	一致性	CDC	Iceberg Sink	定位
RisingWave	PostgreSQL	快照隔离	原生 PG/MySQL	✅	开源、自托管、特性最全
Materialize	PostgreSQL	严格串行化	原生 PG	❌	强一致（金融对账）
ksqlDB	KSQL	最终一致	仅 Kafka	❌	Confluent 生态内
Timeplus	ANSI SQL	最终一致	✅	❌	一体化云原生
DeltaStream	ANSI SQL	最终一致	连接器	❌	多云

选型启发：需要开源+自托管选 RisingWave；需要严格一致选 Materialize；已在 Confluent 选 ksqlDB；流批边界负载选 Timeplus。决策框架是一致性、状态、延迟、流批统一四轴打分，而非单纯追新。

四、主线三：LLM / Agent 驱动的特征自动发现新纪元

自动特征工程（AutoFE）正从”语法变换”走向”语义理解”再到”知识引导”的三纪元。第一代 CAAFE 让 LLM 读数据描述、生成可执行 Python 特征并自我解释，用 TabPFN 验证保留有用特征，在 14 个数据集上把平均 ROC AUC 从 0.798 提升到 0.822——相当于从逻辑回归升级到随机森林的收益，且每个特征都可审计。第二代 KnowFeat 进一步把领域知识结构化注入（schema 元数据→风险指标→检测规则→专家意见→判例证据五类），由 LLM Agent 配专用工具生成特征，并经过 L1 代码沙箱、L2 噪声校准统计过滤、L3 跨种子模型验证三阶段，最终每个被采纳特征都附带溯源卡（provenance card）——在监管行业可解释、可审计。第三代 EAFD（Embedding-Aware Feature Discovery）把预训练 embedding 与特征发现耦合：用”对齐”解释 embedding 已编码的信息，用”互补”发现 embedding 缺失的预测信号，在开源与工业交易数据集上相对 SOTA embedding 提升最高 +5.8%、相对弱表示 +19%，还反向揭示出各 embedding 的系统性盲点。

三纪元共同指向：特征工程从”数学变换搜索”升级为”知识驱动的语义构造”，且验证（执行+统计+模型+溯源）成为不可省略的闭环，否则未经验证的特征会带着统计冗余或模型有害信号进入训练。

五、主线四：特征即产品与特征市场的复用经济

特征存储的本质是一个内部特征市场：一个特征被注册，即被组织内其他模型即时复用，减少重复数据工程、缩短发布周期、让新项目从已策划的生产级特征库 bootstrap。但”上特征库”有信号门槛——当多个模型依赖同一业务逻辑、团队反复重建相同 join、在线推理需毫秒级当前值、模型审计要求清晰所有权与带时间戳血缘时，集中化才真正回报；否则特征库只会在流程前先加负担。Databricks 于 2025 年收购 Tecton 并推出声明式特征 API，正是把”特征即托管产品”推向主流的标志性动作。经济回报不在于工具本身，而在于复用减少的重复工程与加速的模型交付。

六、关键决策权衡汇总

决策点	选项 A	选项 B	权衡
新鲜度档位	全量 streaming	按特征分级分档	全量永不休眠计算，成本非线性；分级把预算花在决策真正损失的地方
实时计算栈	Flink 自定义	流式 SQL 物化视图	Flink 表达力最强、运维最重；流式 SQL 覆盖 60–70% 负载且消除 on-call
特征发现	人工 + 语法变换	LLM/Agent 语义发现	LLM 提语义增益但须建验证闭环；无验证即噪声入训
特征治理	就近 pipeline 内联	注册中心 + 市场	复用经济强，但需 lineage/版本/所有权先行
训练-服务一致性	双写双算	同一 SQL 双用	单一定义天然消除 skew，是实时化架构的硬约束

七、30 / 60 / 90 渐进落地路线

30 天：为 Top 特征定义 Freshness SLA 并埋点测量 serving 端陈旧度；选一个高价值实时场景（如风控 velocity、ETA）做端到端试点，明确超龄降级策略。
60 天：用流式 SQL 物化视图替换该场景的 batch 链路，同一段 SQL 同时供给训练（Iceberg）与服务（在线视图）；接入特征注册中心，统一离在线变换定义。
90 天：试点 LLM/Agent 辅助特征发现（带三阶段验证与溯源）；把高频复用特征纳入内部特征市场，建立 lineage、版本与所有权治理，量化复用带来的周期缩短。

八、演进趋势与选型红旗

趋势：batch→streaming 常态化；特征库→特征市场；特征发现结构→语义→知识引导；向量与 Agent 基础设施被数据库层吸收。
红旗：为架构而全量 streaming（成本伪装成架构决策）；”静默提供陈旧特征”作为默认；新鲜度只在管道自述而不在 serving 测量；忽略 point-in-time correctness 导致训练泄漏；复用特征却不治理 lineage/版本，留下审计黑箱。