_{🧠 图解记忆：高频变更先规则过滤、聚合去重和异步批处理，只把高价值不确定样本交给大模型；点击图片可查看原图。}

> 2026 年 AI Agent 岗最能刷人的题：面试官问的不是“你怎么调 RAG”，而是“万级 QPS 的写入变更，你不可能每条都调一次大模型吧？推理成本怎么控？”。这题考的是工程化落地能力——高级工程师和初级工程师的分水岭。

💡 答案要点

问题本质： 实时推理成本 = 调用次数 × 单次成本。控制成本的核心不是压单价，而是减少不必要的调用次数——不是每条数据变更都值得让大模型推理一次。

第一板斧：事件聚合（把变更聚合到有业务意义的粒度）

原始链路（灾难）：
数据库一行数据变了 → 触发一次处理 → 万级 QPS 写入 → ETL 链路放大到数十万行变更

优化链路（事件聚合）：
把行级变更聚合成“业务事务维度” → 基于 业务ID + 事务ID 做变更聚合
→ 秒级要处理的事务量级降一个数量级 → 再决定要不要推理、怎么推理

原理：用户真正关心的是“商品 A 的最终状态”，不是中间 50 次字段变更。
中间过程全部聚合掉，只对最终状态推理。

第二板斧：在离线统一（一套 Workflow，两个入口）

错误做法：离线用批处理（ODPS/Spark），在线用实时接口，两套代码分开维护
→ 逻辑不一致、结果不一致、排查问题难

正确做法：离线和在线统一成一套 Workflow，由统一编排服务驱动：
- 离线批量推理：调度任务定时触发
- 在线增量推理：实时事件驱动
- 两种模式共享同一套工作流逻辑，只是入口不同

技术含量：把“触发源差异”和“计算资源差异”屏蔽掉，上层业务只关心业务逻辑。

第三板斧：异步推理 + 一致性处理（面试官必追问）

追问：商品信息变更后，用户搜索时还没推理完，搜出来的结果不对怎么办？

方案组合：
1. 返回旧值 + 标记“更新中”（体验优先）
2. 队列顺序保证：同一条数据的变更按序处理，避免乱序覆盖
3. 版本号乐观锁：推理结果带上数据版本，旧版本结果直接丢弃
4. 最终一致：允许短暂不一致，但保证收敛（看业务容忍度）

成本控制组合拳（完整回答）：

手段	作用	优先级
事件聚合	减少调用次数（降一个数量级）	必做
异步批处理	削峰填谷，摊平成本	必做
语义缓存	相同/相似问题直接命中	高频场景做
模型路由	简单问题用小模型，复杂才用大模型	有模型矩阵时做
在离线统一	避免两套逻辑双倍维护成本	规模大必做

面试话术：

“实时推理成本控制我抓三个点：第一，事件聚合——把行级变更聚合成业务事务维度再决定要不要推理，调用次数直接降一个数量级，不是每条变更都调大模型；第二，在离线统一——一套 Workflow 两个入口，离线调度触发、在线事件驱动，共享同一套逻辑，避免两套代码结果不一致；第三，一致性兜底——异步推理期间先返回旧值并标记更新中，同一条数据按序处理，推理结果带版本号防乱序覆盖。再加语义缓存和模型路由摊平成本。面试官追问‘推理没完成结果不对’，答出这三板斧基本就稳了。”

---