你信心满满地把模块化AI架构推上线，结果推理延迟突然翻了三倍。数据科学家不再琢磨模型优化，全在死磕服务间通信。同一个“距上次购买天数”特征，训练管道里一套算法，线上服务接口里另一套——模型在训练和实际预测时看到的输入完全不同，性能神秘下降。这些不是孤例，而是模块化设计最常见的坑，连资深团队都躲不过。

错误一：还没看清边界，先把用不着的模块拆了一地
有些团队热情过度，恨不得把每个功能都独立成微服务。数据校验搞一个，格式转换搞一个，特征标准化再搞一个——结果每个请求都要在网络里跳好几道门槛，运维复杂度飙升，而那些工作本可以放在同一个进程里顺滑跑完。
这往往源于对先前单体系统混乱过头的报复式拆分。但逻辑上的归属权，不等于运行上的分离权。真正该问的是：“这些模块会独立变化吗？”“它们的资源需求真的需要分开扩缩吗？”如果数据校验和格式转换总是同步更新、算力要求相同，那就别拆。先从粗粒度边界切入：数据摄入、特征工程、模型服务、监控，只有拿到实在证据表明某个组件必须独立演进，才继续往细里分。
谷歌云的Vertex AI就是个现成样本：训练和服务两种模块已经预制好，因为它们的运行模式截然不同——批处理与实时服务。而特征变换逻辑还留在训练管道内，因为两者会一起演变。

打开网易新闻 查看精彩图片

错误二：特征工程到处开花，却没人统一口径
训练脚本里写着一段计算“距上次购买天数”的逻辑，线上服务代码里又悄悄实现了一个稍有差别的版本。这样出来的模型，训练时看的是一套数字，上线后喂进去的是另一套——性能越跑越歪，连根因都难排查。
典型成因是各干各的：数据科学家在notebook里随手写特征，后端工程在服务代码里另起炉灶，ETL任务里还可能再复刻一次。没有单一真理来源，特征定义就变成罗生门。
解法很明确：上特征存储或共享特征库，每个特征只定义一处，训练和推理都从这同一个注册中心取用。无论是用Feast、Tecton这类专用工具，还是维护一个结构清晰、全项目统一导入的Python包，核心原则就一条——让所有消费方读同一份定义。不要重复，更别给同一件事搞出两套逻辑。

模块化架构真能带来灵活性和并行效率，但前提是不被“拆得更细才更高级”的幻觉绑架，也不忽视特征一致性这个沉默的模型杀手。把力气花在识别真正的独立变化点上，用单一数据源锁定特征口径，比追求表面完美的服务划分要踏实得多。