AI 这东西，前两年大家比拼的是模型效果：谁家的模型跑分高、谁家的 Demo 演示得惊艳。可一旦真往生产环境里推，情况立刻就不一样了。我在云栖大会现场听了好几场分享，大家口径出奇一致——AI 应用进入生产，真正的分水岭不是模型参数，而是「实时数据智能」。这个词听着玄乎，说白了就是：你的 AI 系统能不能在用户行为发生的那一刻，拿到最新、最完整的数据，并在几百毫秒内完成特征计算、模型推理和决策返回。模型再强，喂给它的数据是几小时前甚至是昨天的快照，那它给出的建议天然就是"过时"的。这篇文章我就结合自己做推荐、风控、定价这类实时 AI 项目的经验，把实时数据智能这件事拆开讲清楚：它解决什么问题、架构怎么搭、踩过哪些坑、上线后怎么排查故障。想从"能跑 Demo"走向"扛得住生产"，这篇文章应该能帮你省掉不少弯路。
1. AI 进生产，先解决"数据时效"这道坎
1.1 为什么离线训练那套逻辑搬到线上就"失灵"了
先聊一个很多团队都踩过的坑。模型训练阶段，我们习惯用 Hive 或者数据湖里的大宽表，T+1 甚至 T+2 地算特征，跑一轮训练，效果不错，指标也挺好看。可真到了线上，模型要实时打分的时候，问题就来了——线上的特征从哪来？
我见过不止一家公司这么干：离线特征算好之后同步到线上 KV，在线请求来了直接查。问题在于，很多特征是有时效性的。比如一个电商推荐场景里的"用户最近 10 分钟点击的商品品类"，这种特征离线咋算？没法算，因为等 T+1 跑完，用户早不知道跳到哪去了。于是线上只能不做这个特征，模型的输入和训练时对不上，效果自然缩水。
这就是业内常说的"训练服务偏差"（Training-Serving Skew）。模型在训练时见到了实时特征，线上却拿不到，或者拿到的口径不一致，模型的预估值就开始偏。更麻烦的是，这种偏差不会立刻显现，往往是上线几天后，业务指标一点点掉，你才开始排查，而排查的难度极大——因为问题不在模型本身，在数据链路。
所以我说，AI 进生产的第一道坎，不是模型，是数据时效。你得先回答一个问题：线上推理时，模型需要的每一个特征，能不能在可接受的延迟内算出来、查得到、并且口径和训练时完全一致。把这个问题解决了，模型上线才谈得上效果。
1.2 实时数据智能：不只是"更快"，而是"更对"
很多朋友把实时数据智能理解成"把批处理改成流处理，延迟从小时级降到秒级"，这个理解没错，但只对了一半。延迟降低只是表面，实时数据智能真正的价值是让 AI 的"判断依据"更完整、更准确。
举个例子。做个性化推荐的，用户刚点了一个商品，这个行为就是最强的信号。离线的模型要等第二天才能看到这个点击，但实时系统可以在几百毫秒内把这个点击行为变成特征，参与下一次推荐打分。你说这两个系统哪个推荐得更准？显然实时的赢。再比如做内容风控，一条恶意文本发出来了，离线模型可能要几分钟甚至更久才能处置，实时模型可以在毫秒级就拦截掉，这个差距可能就是一个恶性事件和一个正常运营的区别。
所以你看，实时数据智能的内核是"在线决策的即时性与准确性"。它要求数据从产生到参与决策的链路要短，同时要求数据的完整性不能因为追求实时而打折扣。具体到技术上，就是要同时解决三件事：流式数据的实时接入与计算、特征口径在离线和在线之间的统一、以及推理链路的低延迟和高可用。后面几节我分别展开讲。
2. 架构选型：流批一体与特征平台的搭法
2.1 流批一体：同一份逻辑，两种时效
做实时数据智能，第一个绕不开的架构决策就是：实时特征和离线特征怎么共用一套逻辑？早期很多团队的做法是搞两套代码——离线用 Hive SQL 算，线上用 Flink 或者 Spark Streaming 再写一遍 Java/Scala 逻辑。结果就是同样的特征，两个口径，稍微改一个逻辑，两边就要同步改，一旦哪次漏改了，线上和训练数据就会悄悄分叉。
流批一体的思路是：用同一套计算逻辑定义特征，底层引擎自动决定是批跑还是流跑。实现上常见的有两种路线。一种是基于 SQL 的流批统一，比如 Flink SQL 支持把同一段 SQL 同时用于批处理和流处理，离线调度的时候跑批模式，实时链路就用流模式消费 Kafka，逻辑完全复用，不用写两遍。另一种是借助 Iceberg 这类支持流读流写的表格式，批任务和流任务读写同一张表，通过"流批一体表"来保证口径一致。
我自己比较推荐的做法是：特征是"一等公民"，先把每个特征的定义用配置化或者 SQL 化的方式沉淀下来，然后让离线和在线都从这份定义出发去生成管道。这样特征逻辑只维护一份，离线训练和在线推理看到的是同一个口径，训练服务偏差从根上就少了一大半。代价是前期要把特征定义规范化，团队要忍住"先上线再说"的冲动。
2.2 特征平台是"中间层"，不是"又一个数据管道"
聊实时数据智能，一定会提到特征平台（Feature Store）。但很多人对它的理解是"把实时算出来的特征存起来，线上查的时候快一点"，这其实把特征平台做小了。一个合格的实时特征平台，至少要做四件事：特征注册与版本管理、特征计算的调度与血缘追踪、在线特征存储与高并发读取、离线和在线口径的一致性校验。
我印象特别深的一次经历：我们做个性化推荐，特征平台刚上线时，我和算法同学花了两周时间，每天干的事情就是对口径。离线特征里"用户近 7 天购买金额"是除去了退款单的，在线流里退款事件因为没接全，导致有几个小时口径对不上。后来我们直接在特征平台上加了一致性校验任务——每小时抽样对比离线特征和在线特征的值，偏差超过阈值就报警。这个能力，比多写几个模型管用得多。
所以做特征平台的时候，别一开始就追求大而全。先把注册、存储、一致性校验这三块做扎实，血缘和权限这种东西可以后补。另外，在线特征存储一定不能和业务数据库混在一起，两者读写模式完全不同——特征存储是高频小查询、冷热分明，业务库是事务型读写，混在一起两边都难受。
2.3 在线存储选型：不能什么都丢进 Redis
实时特征算出来之后要存起来供在线查询，存储选型是很多团队纠结的地方。很多人的第一反应是"上 Redis"，内存快嘛。但用多了你会发现，Redis 没那么万能。
在线特征存储的典型特征是：高并发、低延迟、大容量，查询模式以点查为主（按 key 取对应特征）。Redis 适合放热特征，比如用户的 session 状态、最近行为序列，这些数据量可控。但如果你的特征量很大——比如几亿用户、每人几百个特征，全塞进 Redis 内存成本会非常高。这种情况下可以在前面加一层本地缓存，或者改用支持持久化且成本更低的分层存储方案。
我的实践心得是分三个梯队来放：最热、更新最频繁的特征放 Redis 或者内存缓存，TTL 控制好；中等热的特征放 SSD 类的 KV 存储，比如 TiKV、HBase 这类，容量大很多；冷特征直接回源离线系统，Online 查询时做穿透或者预加载。这样成本可控，又能保证绝大多数查询落在低延迟区间。记住一个原则：特征存储的设计要跟着"时效需求"走，不是所有特征都需要亚毫秒级响应。
3. 实时推理链路：从事件发生到模型打分，控制在几百毫秒内
3.1 一条端到端的实时特征链路长什么样
聊完了存储，我们把整条实时推理链路串起来看。一个典型的实时 AI 决策系统大概是这样的：用户在 App 上产生行为事件，事件通过埋点上报进入 Kafka，Flink 任务消费 Kafka，做窗口计算和特征加工，算出来的特征写入在线特征存储。与此同时，在线推理服务收到请求后，先查特征存储拿实时特征，再把用户画像、行为序列这些信息合并，拼成模型的输入张量，调用模型推理，最后把结果返回业务方。
这个链路里最容易被低估的是 Flink 那一段。很多刚开始做实时特征的同学以为就是"接上 Kafka，做个 map 就行"，实际上窗口计算里面全是细节。比如"用户最近 10 分钟的点击序列"这种滑动窗口特征，窗口怎么对齐、乱序数据怎么处理、水位线设多少，都会直接影响特征质量。还有状态后端的选择——用 RocksDB 还是内存，直接决定了任务的稳定性和资源占用。
我建议做实时链路的同学，第一优先级不是追求"极致的低延迟"，而是先保证"链路稳定可运维"。Flink 任务的检查点、反压监控、状态治理这些基本功，比多省 50 毫秒重要得多。链路不稳定，特征时断时续，模型打出来的分就是飘的，宁可慢一点也要稳。
3.2 训练/服务一致性：最容易翻车的地方
前面提过训练服务偏差，这里展开讲。做实时 AI，最大的坑基本都出在这一块。我总结了三类最常见的不一致。
第一类是特征定义不一致。离线算的时候用 SQL 的某个函数，实时是用 Java 代码写的，结果两个算出来的值对不上。解决方案就是前面说的流批一体，或者至少在特征平台上做定期的在线离线对账。
第二类是时间窗口不一致。离线的窗口是"自然天"或者"固定业务时间"，在线是"滑动事件时间"，两边对同一个特征的定义就差了几个小时，线上推出来的结果自然偏。这种问题用离线在线对账能查出来，但要根治，得把窗口的语义在特征定义层面统一。
第三类是数据遗漏。某个上游事件源在实时链路里没接入，或者接了但解析规则不对，导致在线特征缺了一块。这类问题最隐蔽，因为它不报错，只是模型的输入少了一个维度。我们的做法是对关键特征做"覆盖率监控"——比如实时特征里"用户最近一次购买时间"这个字段，空值率正常应该在 3% 以下，一旦空值率飙到 20%，说明链路有断点，立刻触发排查。
3.3 推理服务的性能与成本平衡
实时 AI 系统的在线推理部分，性能优化的空间很大，但也很容易走火入魔。我见过团队为了把 P99 延迟从 200 毫秒压到 150 毫秒，花了两周做各种优化，结果一问业务方，人家 SLA 写的是 500 毫秒以内。这种优化就是自嗨。
做推理性能，先问自己三个问题：业务 SLA 到底是多少？当前瓶颈在模型计算、特征查询还是网络开销？单机上能否水平扩展？大部分场景下，方案是"特征查询与模型计算分离、批量推理代替单条推理、模型蒸馏减小体量"。比如对话式 AI 或者部分推荐场景，可以把多个请求合并成 batch 推给 GPU，吞吐能翻好几倍，延迟也不会明显变差。
成本这块容易被忽视。实时推理链路里面，特征计算的成本和存储的成本往往是隐藏的大头。Flink 任务开多少个并发、状态存多大、Redis 内存开多大，这些在初期看着不起眼，量大了之后账单非常吓人。我的习惯是给每个特征和每个任务都建"成本账"——一个特征如果既不怎么被用到、又占大量存储，就果断下掉。别让"反正都算了，留着吧"这种心态把预算吃掉。
4. 生产环境实战：常见故障与排查方法论
4.1 数据延迟：先分清楚是"上游慢了"还是"消费慢了"
实时 AI 系统上线之后，最常见的故障就是数据延迟。用户行为发生了，结果特征没更新，线上还在用旧特征打分。排查这种事，我踩过很多坑，总结下来第一步永远是"分段定位"。
先看端到端链路每一段的耗时。埋点上报到 Kafka 用了多久？Kafka 到 Flink 有没有积压（Lag）？Flink 窗口计算有没有反压？特征写入存储有没有超时？每一段都打上耗时监控，哪一段异常就从哪一段往下查。
有一回我们查一个"特征延迟 10 分钟"的问题，查了半天发现是 Kafka 的 topic 分区数不够，消费者组里某个消费者处理不过来，导致分区积压。这种情况加分区、加并发就能解决。但如果你上来就猛加 Flink 资源，钱花了问题还在，因为根因在 Kafka 那边。所以我的排查习惯是：先从链路最上游开始看，别一上来就怀疑自己负责的那一段。链路各段的监控指标和告警阈值，建议在系统上线第一天就配好，别等出故障了再补。
4.2 特征漂移与数据质量监控：守门员不能缺位
实时 AI 系统上线之后，模型的输入分布会随着时间和业务变化而漂移。今天大家的消费习惯和三个月前肯定不一样，如果你的特征分布偏了，模型效果自然就掉。很多人盯着模型的效果指标，比如 AUC、点击率，但这些指标是结果，等它们掉下来再处理，往往已经造成实际损失了。
更前置的做法是监控特征本身。每个关键特征都配几个统计量：均值、空值率、取值分布、新鲜度。这些统计量实时算，监控曲线一旦出现明显拐点，就触发告警。比如"用户活跃度"这个特征每天均值有一个稳定的波动范围，某天突然跌了一截，可能不是业务出问题了，而是特征计算逻辑被误改动了——这种问题不盯特征，光盯线上指标，真的很难发现。
再补充一个容易忽略的点：特征的新鲜度监控。你得能回答"这个特征距离最近一次成功更新过去了多久"。我们给每个特征都打了时间戳，监控"特征更新时间距当前时间的差值"，超过阈值就告警。这招救过我好几次，尤其是在上游数据源出问题、Flink 任务假死（进程还在、但不消费数据）的时候，新鲜度监控是第一个响的。
4.3 资源竞争：实时任务和离线任务的"抢资源"问题
很多公司是同一个集群同时跑离线批处理和实时流处理。离线任务凌晨跑大查询，实时任务实时吃资源。生产环境里出现最多的资源问题不是"绝对不够"，而是"峰值冲突"——离线任务调度高峰和实时任务处理高峰撞在了一起，导致实时任务延迟飙升。
这种问题最朴素也最有效的解法是错峰调度。把离线大任务的调度时间尽量避开业务高峰，或者给实时任务配置独立的资源池，保证关键链路不受离线任务的挤兑。Flink 和 Spark 这些引擎现在都支持资源队列隔离，强烈建议在生产环境把"实时专用队列"和"离线队列"分开，别图省事用一个队列，出事的时候你会哭的。
还有一个老生常谈但值得强调的点：实时任务的资源设置要留有余量。别把 Flink 的并发开得刚刚好，稍微来点数据量波动就反压。按峰值流量的 1.5 到 2 倍来规划资源，宁可平时有点浪费，也别在流量突增的时候让整个链路崩掉，尤其是做了实时 AI 决策的系统，链路一断，相当于业务决策直接瞎了。
5. 一点趋势观察与上手建议
5.1 从"模型效果"转向"系统效果"
这次云栖大会上有一个感受特别强烈：大家开始把 AI 的效果评价从"模型指标"转向"系统指标"。以前评一个推荐模型，看的是离线 AUC 涨了多少；现在看的是"从用户行为发生到推荐结果下发，花了多久""这条链路的 SLA 达成率是多少""特征新鲜度达标率是多少"。说白了，模型只是一环，整个系统的实时数据能力才是决定 AI 在业务上最终效果的关键。
这个转变对做技术的朋友来说，意味着技能树的更新。以前搞 AI，主要功夫在模型算法上；现在你得懂流计算、懂数据管道、懂存储、懂稳定性治理。我身边越来越多的算法工程师开始主动看 Flink 的任务监控、看 Kafka 的积压情况，这就是趋势——AI 工程师正在和实时数据工程师"合流"。
5.2 如果现在要从零开始，我会怎么排优先级
经常有朋友问，公司想上实时 AI，应该先做什么。我的建议是别一上来就铺大摊子。第一步，先把线上最核心的几个实时特征做出来，不用多，就挑那些"时效性最强、对业务影响最大"的特征，比如推荐里的实时点击特征、风控里的实时行为序列特征。第二步，把这几个特征做进一个最小的闭环——事件接入、实时计算、在线存储、模型查询，打通整个链路。第三步，给这条链路配上完整的监控：延迟、积压、新鲜度、空值率。第四步，再加特征，再扩展业务场景。
这个顺序走下来，前期投入不大，但能把实时 AI 的"地基"打牢。地基不牢的话，后面每加一个场景，你都要回头补链路的稳定性和可观测性，累积的痛苦会比你想的多得多。
5.3 团队协作：实时数据智能是"跨职能活"
最后聊一个容易忽视但特别现实的问题：实时数据智能不是某一个团队能独立搞定的。它至少涉及三拨人——负责数据管道和流计算的数据工程师、负责特征和模型的算法工程师、负责在线服务和稳定性的平台工程师。如果这三拨人各干各的，问题一定会出在接口处。
我的建议是：把"特征"作为团队之间的共同语言。数据工程师负责特征的实时计算链路，算法工程师负责特征的定义和模型使用方式，平台工程师负责链路的稳定性保障，三方围绕同一个特征注册表协同，任何一方动特征都得在注册表里留痕。这个协作机制跑顺了，实时 AI 项目才能真正转起来。对照我自己项目里的体会，凡是出大事故的，几乎都是因为接口处没人负责——每个人都觉得自己做的那段没问题，但连起来就有问题。把接口责任明确到人，比优化任何技术细节都管用。
