AI 这东西前两年大家比拼的是模型效果谁家的模型跑分高、谁家的 Demo 演示得惊艳。可一旦真往生产环境里推情况立刻就不一样了。我在云栖大会现场听了好几场分享大家口径出奇一致——AI 应用进入生产真正的分水岭不是模型参数而是「实时数据智能」。这个词听着玄乎说白了就是你的 AI 系统能不能在用户行为发生的那一刻拿到最新、最完整的数据并在几百毫秒内完成特征计算、模型推理和决策返回。模型再强喂给它的数据是几小时前甚至是昨天的快照那它给出的建议天然就是过时的。这篇文章我就结合自己做推荐、风控、定价这类实时 AI 项目的经验把实时数据智能这件事拆开讲清楚它解决什么问题、架构怎么搭、踩过哪些坑、上线后怎么排查故障。想从能跑 Demo走向扛得住生产这篇文章应该能帮你省掉不少弯路。1. AI 进生产先解决数据时效这道坎1.1 为什么离线训练那套逻辑搬到线上就失灵了先聊一个很多团队都踩过的坑。模型训练阶段我们习惯用 Hive 或者数据湖里的大宽表T1 甚至 T2 地算特征跑一轮训练效果不错指标也挺好看。可真到了线上模型要实时打分的时候问题就来了——线上的特征从哪来我见过不止一家公司这么干离线特征算好之后同步到线上 KV在线请求来了直接查。问题在于很多特征是有时效性的。比如一个电商推荐场景里的用户最近 10 分钟点击的商品品类这种特征离线咋算没法算因为等 T1 跑完用户早不知道跳到哪去了。于是线上只能不做这个特征模型的输入和训练时对不上效果自然缩水。这就是业内常说的训练服务偏差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 上产生行为事件事件通过埋点上报进入 KafkaFlink 任务消费 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 有没有积压LagFlink 窗口计算有没有反压特征写入存储有没有超时每一段都打上耗时监控哪一段异常就从哪一段往下查。有一回我们查一个特征延迟 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 项目才能真正转起来。对照我自己项目里的体会凡是出大事故的几乎都是因为接口处没人负责——每个人都觉得自己做的那段没问题但连起来就有问题。把接口责任明确到人比优化任何技术细节都管用。