AI工程化实战：从模型训练到生产环境的完整链路

1. 从"能跑通"到"能上线"，AI项目中间隔着一整条工程链

大概在两年前，我第一次把一个AI模型真正推到生产环境时，被现实狠狠教育了一顿。实验室里Jupyter Notebook跑得飞快的分类模型，换上真实流量后准确率直接跳水，延迟高到业务方骂人，甚至半夜因为数据格式变化直接宕机。那是我第一次意识到：模型训练只是AI项目里最"简单"的一部分，真正决定成败的，是从一个能跑的demo到一个稳定服务的整个工程链条。

今天想聊的"AI Engineering from Scratch"，核心就是把这套工程链条拆开揉碎。很多人以为AI工程化是选个框架、调个参数的事，但实际上它涵盖数据管道、特征工程、模型部署、监控反馈、版本管理一整套基础设施。对入门者来说，最友好的路径不是上来就研究分布式训练，而是先搞懂一条最简单的端到端链路是怎么转起来的，再去逐步加固每个环节。

这篇文章面向的是谁呢？两类人。第一类是算法工程师或数据科学家，模型训练没问题，但一提到上线就发怵，不知道接口怎么写、监控怎么埋、模型怎么更新。第二类是后端工程师，被公司安排去做AI相关项目，算法底子薄弱，但工程能力强，需要快速建立对AI系统的全局认知。这两种背景我都有过交集，所以下面所有内容都会尽量同时照顾到两边。

我会从自己真实做过的项目出发，讲清楚AI工程化链条的每一个环节为什么存在、它解决什么问题、踩坑时怎么排查，以及一个合理的搭建顺序应该是什么。听起来内容很多，但我会尽量用讲人话的方式，把概念掰碎了说。

2. 生产环境第一课：你以为的"实时"其实不是实时

先聊一个最容易让新人翻车的话题：模型服务的实时性。

2.1 同步接口、异步队列和批处理，三种模式的取舍逻辑

很多刚从Notebook走出来的算法同学，对"上线模型"的认知就是写一个FastAPI接口，把模型包装成HTTP服务，然后等调用方一次性传几十个特征过来，模型算出结果返回去。这个方案在小流量、低并发、特征齐全的情况下确实能跑，但一旦进入真实业务场景，问题就来了。

我见过一个典型的信贷风控项目，最初方案就是同步接口。业务方在用户提交申请时同步调用评分模型，要求响应时间在200毫秒以内。一开始测试环境压测没问题，上了生产后遇到两个状况：第一，某些特征数据需要从外部数据源实时拉取，这部分延迟不稳定，最高的能到800多毫秒；第二，高峰期并发上来后，模型服务线程池被打满，大批请求排队，拖垮了整个申请流程。

这就是典型的没有做好"算力分层"。

以我的经验，一个完备的AI服务链路至少应该分三层：

• 同步实时层：处理低延迟、高QPS的轻量推理请求，比如风控拦截、推荐排序的第一阶段，响应要求在几十到几百毫秒。
• 准实时异步层：处理分钟级延迟可接受的场景，比如用户行为触发的内容生成、营销活动的人群圈选，通过消息队列削峰填谷，请求进来先落队列，worker批量拉取再推理。
• 离线批处理层：处理T+1甚至T+2的任务，比如日报生成、批量用户分群、周期性风险扫描，用分布式计算框架跑，不在乎单条耗时，只在乎整体吞吐。

很多新人犯的错误是，把所有推理都往同步层塞，结果就是下游一抖，整个系统跟着抖。合理的设计应该是：**能异步的坚决不同步，能离线的坚决不实时。**比如用户首次进入页面时的推荐，可以用实时接口；但用户当晚的个性化报告，完全可以走异步队列，半夜生成好第二天早上推送给用户。

2.2 接口形态不只是REST，还有gRPC和自研协议的适用场景

接口层面的选择，网上教程大多只教RESTful API，但实际做AI工程时，协议选型会直接影响服务稳定性。

REST + JSON的优势是开发快、调试方便、生态好，几乎所有语言都有开箱即用的HTTP库。缺点是JSON序列化/反序列化在超高并发下是有性能损耗的，而且对于大量浮点型特征数据来说，体积膨胀得厉害。如果一个推荐系统单次请求要传几百个特征，用JSON传输和用protobuf二进制传输，网络开销能差出一个量级。

我在一个推荐项目里试过把特征传输从JSON切成protobuf，同样的业务量，模型服务所在机器的网络IO下降60%左右。所以如果你的模型是那种特征极多、调用极频繁的场景（推荐、广告、搜索基本都算），建议直接考虑gRPC或者自定义二进制协议。REST只适合特征少、调用量可控的场景。

另外还有一个很多人忽略的点：**超时和重试策略必须单独设计。**默认的HTTP客户端超时一般是死的，但AI推理服务的耗时往往和输入数据复杂度强相关。比如一个翻译模型，翻译一句话和翻译一篇长文的耗时天差地别。这种情况下，合理的做法是把超时配置放到路由层做动态管理，甚至根据输入长度预估耗时来动态决定超时上限。我遇到过不止一次因为客户端超时设置过短，导致结果其实算完了但客户端已经放弃等待，然后无脑重试把服务打崩的案例。重试不是简单加个循环，必须考虑幂等性和重试风暴的问题。

2.3 推理结果的缓存与预热，一个常常被忽略的稳定性手段

AI服务上线后，最容易被低估的稳定性杀手，是冷启动和突刺流量。

冷启动问题在传统Web服务里也存在，但在AI服务里更明显。因为很多深度学习模型加载到内存里就要好几秒甚至十几秒，第一次请求往往会把加载时间算进去，直接触发超时。我的做法是在服务启动时做一个预热（warm-up）：加载完模型后，主动发一批假请求进去，让框架把图优化、显存分配都跑一遍，再对外宣告服务就绪。

还有一层是结果缓存（inference cache）。有人会觉得推理结果每次都不一样，怎么缓存？实际场景里很多推理是高度重复的。比如A/B实验的对照组，同一批用户，在实验稳定期内不同时间段进来的请求，特征几乎一样，结果也基本一样。对这种请求做短时间内的缓存，既能大幅降低算力消耗，又能稳定服务质量。缓存时有一个值得注意的细节：**缓存key不能只由用户ID组成，必须把模型版本和特征版本一起拼进去。**不然模型更新后，你可能给用户返回了旧版本的结果，而业务方完全不知情。

这些都是从"能跑"到"能扛"过程中必须处理的问题。很多团队做AI项目，算法模型折腾三个月，上线后三天就出事故，基本就是栽在接口形态、超时、预热、缓存这些看似不起眼、实则决定生死的工程细节上。

3. 数据漂移比算法退化更可怕，监控体系应该这么搭

进入生产环境之后，你会面临一个新的现实：**每周都在更新的新数据，比训练集里的数据可能已经"长得不一样"了。**这种现象叫数据漂移（Data Drift），它是AI系统上线后最隐蔽、最致命的威胁之一。

3.1 如何用分布对比和分位数变化捕捉特征异动

很多团队压根不监控特征数据，直到模型线上效果明显下降才去排查，但那时往往已经晚了。数据漂移的可怕之处在于，它是渐进式的污染——每天变化一点点，等到模型表现肉眼可见地变差，往往已经漂移了几周甚至更久。

我常用的监控方式是做特征分布的周期性对比。最简单的做法是，每天跑一次统计任务，算出线上实时请求里每个特征的均值、方差、分位数（如P50、P90、P99），和历史训练集做对比。如果是连续特征，可以用PSI（Population Stability Index，群体稳定性指数）这种指标量化分布偏移程度；如果是离散特征，就做分箱频次对比。

这里给一个经验阈值参考：**PSI小于0.1说明分布很稳定；0.1到0.25之间需要关注；超过0.25必须立刻告警排查。**这个阈值不是我拍脑袋定的，是金融风控行业多年积累下来的通用标准。

但光监控单特征还不够。真实业务里更常见的是组合特征偏移。比如一个推荐场景，用户年龄段分布没变，但是"年轻用户+深夜时段"这个组合的占比涨了一倍，单看每个维度都很正常，组合起来就是明显的业务逻辑变化。所以建议在监控设计时，除了单维度统计，还要人工圈定几个业务上关注的组合维度，定期做交叉验证。

3.2 模型效果监控：没有标签的情况下怎么感知退化

数据漂移之外，模型效果的监控同样重要，但这里有个天然矛盾：线上推理的时候往往没有真实标签。

推荐系统可以用用户后续的点击作为正反馈，风控系统可以等一段时间用逾期样本回填，但有些场景（比如内容审核、舆情分类），真实标签获取周期可能长到一个月。这种延迟反馈场景下，你很难在模型上线第二天就判断"效果到底行不行"。

我的做法是分两条线：

第一条线是代理指标（proxy metric）。既然真实标签拿不到，就找和业务目标强相关、但能立刻获得的信号。比如搜索排序模型，可以用搜索会话内的用户点击率、停留时长、翻页深度作为效果代理指标。这些指标虽然不完全等于业务结果，但和它高度相关，晚了几天就归因，足够感知趋势变化。

第二条线是人工抽检+标注回流。每天从线上日志里按策略抽样固定比例的数据，安排人工标注团队标注，标注完的直接回流到离线评测集里，跑一遍标准评测流程，观察指标涨跌。这套流程虽然滞后且成本高，但它是检验所有代理指标是否可靠的"锚"。

实际上我强烈建议：**在做模型上线评估时，就把"监控指标"和"评测数据集"作为交付物的一部分，而不是上线之后补。**很多团队上线报告里只有准确率、召回率几行数字，但上线后监控表是空白，这才是事故的真正来源。

3.3 告警别乱设，先解决"告警疲劳"问题

告警是监控体系里最容易被滥用的环节。刚搭监控的时候，我们恨不得把几十个指标都配上告警阈值，结果第一个月晚上被电话吵醒十几次，全是些无关痛痒的波动。一个月后，团队所有人开始习惯性地忽略告警，真正出事的时候反而没人响应。

后来我学乖了，告警配置遵循三个原则：

• 告警分级：P0级（服务不可用、效果暴跌）直接电话通知；P1级（指标趋势异常）发IM群消息；P2级（潜在隐患）只进告警日报，周会review。
• 阈值要基于稳定期的噪声带宽设置：不要拍脑袋定一个"5%变化就告警"，而是先观察两周正常运行的数据，算好均值和波动带宽，再决定告警线。比如某个指标的日常波动标准差是3%，那触发线应该设在均值±4到5个标准差，而不是随便设个5%。
• 合并同类告警：同一根因导致的多个维度告警必须能聚合，不然一个故障产生20条告警，等于没告警。

说句不好听的，绝大多数AI团队上线后的第一个月，就是在被告警轰炸和被业务投诉之间来回拉扯。提前把告警体系设计好，能省掉后面大量的心力损耗。这属于"慢就是快"的典型场景。

4. 特征版本与模型版本为什么必须成对管理

AI工程化里最容易被忽视、但后果最严重的问题之一，就是特征和模型之间的版本匹配。

4.1 特征存储：在线特征和离线特征的统一

先讲一个我真实踩过的坑。有个项目离线训练时用的是Hive表里T+1的聚合特征，比如"用户过去7天购买金额"。上线时工程师图省事，直接从线上交易表里实时算这个特征。结果上线第一天，线上分数和离线预估分数系统性偏差，用户分层直接乱了。原因很简单：离线表统计的是截止到昨天24点的数据，线上实时算的是截止到当前时刻的数据，时间口径完全不一样。

这个问题的根源，在于在线特征链路和离线特征链路是两套完全不同的代码和存储，没人统一它们的口径。解决方案是引入特征存储（Feature Store）的概念——把特征的离线计算和在线计算放在同一个配置体系里定义，离线定期批量算好灌入存储，在线使用同一套定义逻辑实时计算或读取。

当然，对小团队来说搭建完整的Feature Store并不现实。但至少要做到：

• 特征定义集中管理：所有特征的统计口径、时间窗口、数据源、计算逻辑，必须在一个地方描述清楚。
• 离线训练和在线推理用同一份特征代码：不要离线一套SQL、在线一套Python算，而是公共特征逻辑抽成统一函数或SQL模板，两边共用。
• 特征数据可回流：在线阶段计算的特征，如果可以存储下来，要定期回流到离线存储，这样以后的训练数据里能包含这些在线特征，解决训练/推理不一致的问题。

4.2 模型文件的版本化、可复现性与血统追踪

模型本身也需要版本管理，但这跟普通软件版本管理有本质不同。软件版本发布后行为是确定的，模型版本发布后行为同样应该确定，但现实中模型常常被"热更新"或者被隐式依赖的数据污染，导致无法复现。

我第一次做模型版本化时犯过一个错：只记录了模型文件的哈希和训练日期，但当三个月后想重新训练一个同样的模型时，发现训练数据已经被业务逻辑更新洗过一遍了，根本没法复现当时的实验。从那以后我意识到，模型的可复现性不只是保存模型权重，而是要保存完整的三元组：代码版本、数据版本、超参数配置。

具体做法上，每个训练任务生成一个唯一的实验ID，记录以下信息：

• 训练代码的Git commit ID
• 训练数据集的版本号或数据快照路径（如果数据量太大无法快照，至少记录数据生成脚本的版本和上游数据源的时点）
• 超参数配置（JSON格式存一份到对象存储）
• 模型文件的哈希值和存储路径
• 训练环境依赖（比如Python依赖的lock文件或容器镜像tag）

这套信息合起来可以叫模型血统（Lineage）。有了血统，你才能回答"线上跑的这个模型是怎么来的"这个问题。出了问题的时候，第一件事就是要能快速定位到具体是哪次实验、哪份数据、哪个代码commit产出的模型。我见过太多团队排查线上事故时，压根不知道线上模型是谁在什么时候训练出来的，最后只能全部回滚重来。

4.3 模型与特征的版本绑定：一张表说清楚

再回到本章开头的问题。模型和特征的正确关系，不是"模型依赖特征"，而是**"模型依赖特征的某个特定版本"**。原因是特征的计算规则一变，同一个特征的数值含义就变了，模型看到的输入分布也就变了。

我用一个表格来总结版本绑定的设计思路：

版本元素	决定权	更新频率	绑定关系
特征版本	特征工程团队	月/周粒度	训练时固定
模型版本	算法团队	周/天粒度	依赖特征版本
模型配置版本	平台/业务方	实时可调	可脱离模型热加载

这个设计里最关键的一点是：**推理服务的配置中心里，必须同时记录当前生效的模型版本和特征版本。**上线一个新模型时，要检查它所依赖的特征版本是否还在线上生效。如果特征版本已经更新了，要么先回滚特征版本，要么重新训练模型适配新特征，绝不能直接拿旧模型接新特征。

我遇到过这样的场景：特征团队优化了一个特征的计算逻辑，觉得"数值范围和分布变化不大"，直接把线上特征更新了，结果模型效果直接崩了。这个问题的本质，是特征版本的变更没有走和模型变更一样的评审流程。后来我们强制要求所有特征变更必须做离线仿真评估，用新旧特征分别跑一遍历史数据，确认模型效果不降级才能上线上。

5. 模型部署的完整落地路径：选型、镜像、接入

聊完监控和版本，回到最核心的部署环节。

5.1 框架选型：从Triton到自研Batch推理，不同场景怎么选

模型部署框架的选择，往往决定了后续所有的运维复杂度和性能上限。

我的建议是分三档来考虑：

**第一档：纯CPU的小模型（<100MB），QPS在几百以内。**这种场景直接用FastAPI + ONNX Runtime就够用了。ONNX在CPU上的推理优化做得很成熟，而且模型导出一次后不依赖训练框架，部署环境干净。这一档没必要上重型框架，复杂的部署方案本身会成为新的故障源。

**第二档：深度学习模型，或者需要多模型管理、动态批处理。**强烈推荐NVIDIA Triton Inference Server。它对TensorRT、ONNX、PyTorch的模型都可以直接加载，支持并发模型服务、动态批处理（Dynamic Batching）、模型版本管理，还自带Prometheus监控指标。我第一次用Triton跑一个BERT模型的时候，吞吐比之前用纯PyTorch部署直接翻了3到4倍，主要就是靠动态批处理把GPU利用率拉满了。

**第三档：超高并发、特征计算复杂的推荐/搜索类系统。**这种场景往往不只是部署一个模型，而是部署一整套推理流程（特征拼接、多模型打分、后处理融合）。这时候要么自己写推理服务框架，要么用Ray Serve这类支持复杂编排的方案。但务必记住：**框架只是骨架，真正的性能瓶颈往往在特征计算和IO上，不在模型张量计算上。**别一上来就优化算子，先把特征读取、序列化、结果合并这些非模型逻辑优化到极致，收益往往更大。

5.2 容器化与资源隔离：哪些坑是部署时最容易踩的

容器化部署AI模型，现在基本是标配了。但有两个坑值得单独提醒：

一是模型文件放到镜像里还是挂载到数据卷里。小模型放镜像里没太大问题，大模型（几个GB以上）务必挂载到外部存储或者通过初始化容器加载。原因很实际：镜像一旦巨大，每次发布拉镜像都要拉半天，发布频率一高，运维就叫苦。我见过一个团队把几个GB的模型打进镜像，每次发布要花十几分钟拉镜像，发布窗口被压得只能半夜搞。

二是资源限额的设定。AI推理服务往往有显存需求，但很多人只设置内存和CPU，不设置GPU显存限制。结果就是多个推理服务分在同一张GPU卡上时，显存抢占导致OOM。设置NVIDIA_VISIBLE_DEVICES、显存配额这些环境变量十分必要，同时模型加载时的显存预估也要留出20%-30%的余量，因为推理时的显存峰值往往比加载时高出不少。

另外提一下模型热加载。每次发布新模型都要重启服务是很痛苦的，Triton这类框架原生支持模型热加载，直接把新模型文件放到指定目录就会自动加载上线。但如果你用的自研框架，就一定要设计好版本切换时的优雅下线逻辑：服务先停掉旧模型接收新请求，等正在处理的请求全部返回，再加载新模型。这个细节我在自研框架里吃过亏，热加载时直接切换，导致正在推理的请求拿到了不完整的中间状态，返回了错误结果。

5.3 从训练脚本到部署格式：模型转换的那些门道

很多算法工程师在训练完成后，直接把PyTorch的.pth文件丢给部署工程师，然后就不管了。这在工程上是远远不够的。一个合格的部署流程，至少要走完以下几步：

1. 模型导出：把训练好的模型从训练框架导出为中间表示（ONNX是当前最通用的选择）。
2. 模型优化：用ONNX简化工具和量化工具做一遍图优化、算子融合、精度校准。注意量化这一步要单独做效果评估，不是所有模型都能承受INT8量化带来的精度损失。
3. 格式转换（如果需要）：转到目标推理引擎的格式，比如TensorRT的.engine文件。
4. 推理验证：用一批线上真实请求的特征数据，对比原始模型和转换后模型的输出，误差必须在可接受范围内（一般要求最大相对误差小于1%）。
5. 压测与调优：用小流量压测确认延迟和吞吐是否达标，再逐级加压找瓶颈。

第4步经常被跳过，但不可跳过。我见过一个案例，模型从PyTorch转ONNX后，某个自定义算子在ONNX里被错误映射，导致特定类型的输入直接输出NaN，好在发布前用线上数据回放了一遍，才拦下这次事故。

模型导出的过程，验证完毕不是终点，正式上线前还要在预发环境跑一小段时间，观察延迟和效果指标相对测试环境有没有差异。生产环境的数据分布、并发模型都和测试环境不同，这一步往往是发现问题的最好时机。

6. 模型回滚不是可选项，而是默认路径

技术团队通常热衷于讨论如何上线新模型，却很少认真设计"怎么把旧模型换回来"的路径。但真实世界里，新模型上线后表现不及预期，甚至出现严重badcase的频率，远比宣传的要高。回滚能力能不能快速生效，往往比新模型上线能力更重要。

6.1 灰度发布与A/B实验：如何降低每一次上线的风险

我见过最粗暴的上线方式：模型训练完，离线指标看着不错，直接全量上线。这种做法相当于没有安全网就高空走钢丝。

合理的路径一定是灰度发布：

• 先切5%流量到新模型，运行一两天，观察代理指标和业务核心指标。
• 确认无异常后，逐步放大到20%、50%、100%。
• 如果任何一个阶段出现指标恶化或异常告警，立刻回滚到上一个稳定版本。

灰度发布有两个前提条件需要提前打好基础：

一是流量切分的能力。在路由层或API网关层必须支持按比例切分流量到不同模型版本，这个能力在架构设计阶段就要预留，而不是等需要时再临时改造。

二是线上评测的能力。灰度时不能只看系统日志，要有针对这个版本的专属评测面板，实时观察关键指标。如果连"新版本表现是否更好"这个基本问题都无法回答，灰度发布就失去了意义。

A/B实验和灰度发布容易混淆，但两者有一个本质区别：灰度发布是为了控制风险，A/B实验是为了验证假设。灰度发布可以不带统计学严谨性，只要系统稳定就继续放量；A/B实验则需要设计对照组、计算显著性、控制混杂变量。实操上，A/B实验往往是在灰度到一定比例后才开始正式记录数据，前面的灰度只是"技术性验真"。

6.2 快速回滚的工程准备：镜像、配置、数据链路都要备份

回滚操作听起来简单——把线上服务切回旧模型就行了。但真正做过的人都知道，回滚是最容易二次引发事故的操作。

原因在于，新版本可能已经改变了上游数据链路、特征存储甚至下游消费方的接口预期。你把模型切回旧版，但特征数据已经按新逻辑计算了，旧模型吃到的输入可能完全不对。

所以快速回滚的工程准备不是"存一个旧模型文件"这么简单，它至少包含三部分：

• 旧模型镜像或模型文件的即时可用性：每次发布新模型时，旧版本必须保留在可随时重新加载的状态。我的习惯是保留最近两个稳定版本的模型文件，并打上明确的版本标签。
• 特征和数据的回滚：如果新模型依赖了新特征逻辑，回滚旧模型的同时，特征计算逻辑也要同步回滚。这个必须依赖前面说的"特征版本与模型版本绑定"机制，否则就会新旧错配。
• 下游接口契约的兼容：如果新模型改变了输出格式（比如增加了新的分数维度），回滚后下游系统是否还能正确消费旧格式？必须在设计接口时保持前向兼容，或者在回滚时同步通知下游切换解析逻辑。

最容易被人忽略的是第三点。AI系统的接口契约变更，往往不是由算法团队控制，而是由下游业务方决定。模型输出的字段增减、含义变化，都要当成正式的接口变更来管理，不能悄悄改。我在实际项目中见过因模型输出增加了一个字段，下游没适配导致的解析报错，最后排查了两天才发现是接口契约的问题。

6.3 模型退役：什么时候该彻底下线一个模型

回滚是短期手段，模型退役（Model Retirement）则是长期治理问题。

很多团队线上积累了十几个历史版本的模型，但运行时只跑最新版本，旧文件全堆在存储里没人清理。时间一长，既浪费存储，又容易在误操作时加载到不该加载的版本。

我的建议是建立模型退役机制：

• 明确每个模型的活跃周期：比如一个模型上线后超过6个月没有更新，就进入"待退役"状态。
• 退役前做一次完整评估：确认没有流量依赖、没有线上引用、下游没有按它的输出做历史数据解析，然后才能归档清理。
• 归档不等于删除：模型的代码版本、数据版本、血统信息要保留至少一年，以便审计或回溯。真正的目标不是删干净，而是"线上不再允许被调用"。

7. 当AI模型变成"非首要矛盾"，LLM应用的新工程挑战

前面聊的更多是传统监督学习模型的工程化经验。但2023年以来，大语言模型（LLM）应用爆发式增长，AI工程的边界被大幅拓宽。现在做AI项目，"训练模型"的比例在下降，"调度模型"的比例在上升。

7.1 提示词、上下文和工具调用：新范式下的工程变量

LLM应用的工程化，和传统模型有一个本质区别：**核心决策逻辑从"模型权重"部分转移到了"提示词（Prompt）"和"上下文（Context）"部分。**同一个底层模型，换一套提示词，行为可能天差地别；同一套提示词，多塞一段上下文，输出也可能完全偏离。

这种变化给工程带来几个新挑战：

第一，提示词也需要版本管理。很多团队把提示词当成字符串硬编码在代码里，改动要靠发版。一旦业务方想频繁调整prompt来做实验，这个流程完全跟不上。正确做法是把提示词模板放在配置中心或专门的管理系统里，支持线上动态调整和A/B实验。

第二，上下文管理成为核心优化点。LLM的上下文窗口是有限资源，怎么在有限的token里塞进最有价值的信息，直接影响效果和成本。我做LLM应用时最常用的是检索增强生成（RAG），但RAG的效果瓶颈不在模型，而在检索质量。检索回来的文档相关性不够，喂进去反而是噪音。所以会有大量工程工作花在文档切分策略、向量索引调参、重排序模型选型上。

第三，工具调用（Function Calling）的Agent工程。当LLM被允许调用外部工具时，它的行为边界就变成了"模型决策+工具系统"的组合。工程上需要设计工具注册中心、权限控制、循环调用保护等机制。一个常见的坑是：模型陷入工具调用的死循环，疯狂请求外部API，既烧钱又拖垮下游服务。必须有明确的调用次数上限、超时控制和金额熔断机制。

7.2 LLM应用的可观测性：Token消耗、响应质量、延迟归因

LLM应用的可观测性比传统模型服务复杂得多。传统模型服务只要记录请求特征、模型版本、响应延迟、结果分布就够了。LLM应用则还要监控：

• Token消耗：输入token、输出token、缓存命中情况，直接跟成本挂钩。
• 提示词版本与模型版本的双重绑定：同一模型不同提示词、同一提示词不同模型，效果和成本都不同。
• 响应质量：传统模型可以用准确率、召回率量化，LLM的"回答得好不好"则主观得多。实践中可以用LLM-as-a-judge（用一个大模型评价另一个大模型的输出）来自动化质量评测，但要注意这本身就是个API调用，也有成本，只在必要的抽样场景使用。
• 延迟归因：传统模型延迟主要来自推理，LLM应用延迟则分散在输入处理、检索、推理、工具调用多个环节。排查慢请求时，必须有全链路的trace追踪，才能定位到具体瓶颈。

这里我特别提一下**流式输出（Streaming）**带来的观测挑战。LLM应用多数场景需要流式输出提升用户体验，但这让日志采集变得别扭。一条请求的输出，可能横跨好几秒几十个chunk，要等流完全结束才能算总token数和完整响应。做监控采集时，必须处理这种"流结束才上报"的模式，不然监控面板上看到的永远是不完整的数据。

7.3 当你的AI应用需要长期维护，数据回流和持续评估的闭环

最后聊聊LLM应用的持续优化。传统ML项目有清晰的训练-评估-上线-监控闭环，LLM应用则不太一样——它往往没有标准的"再训练"过程，模型本身是外部API，你只能优化提示词、检索策略和工具配置。

这就带来一个非常现实的问题：如何让系统随时间越用越好？

我的答案是建立数据回流闭环。把线上真实请求、反馈信号（点赞、点踩、用户修改等）、检索到的上下文、模型最终输出全部记录下来，每天做一次离线分析。具体的分析方向包括：

• 哪些类型的问题经常出现badcase？归纳后更新提示词或检索策略。
• 检索质量是否稳定？监控向量索引里的文档更新频率和检索相关性评分分布。
• 哪些工具调用经常失败？是权限问题还是API参数问题？

做LLM应用和做传统模型有一个共通的基础：**所有优化都要有数据支撑，不能靠感觉。**哪怕只是改一下提示词的措辞，最好也先做一个小流量A/B实验再全量上线。

8. 给从零起步者的一条最小可行路径

前面聊了一堆概念和原理，最后给一条可以直接照着走的行动路线。毕竟"from scratch"最需要的就是一个清晰的起步顺序。

8.1 第一步：先把一个端到端流程跑通

不要一开始就设计复杂的架构。先从最简单的一层开始：

• 选一个公开数据集或你手头已有的业务数据。
• 训练一个模型（用最成熟的库就行，比如scikit-learn或者HuggingFace Pipeline）。
• 用FastAPI把它包成一个同步HTTP接口。
• 写一个简单的压测脚本，测一下延迟和吞吐。
• 把预测日志、模型文件、训练代码都打上版本标签。

这一步的目标不是性能，而是让你完整经历一次"从训练到上线"的全过程，建立对AI工程的基本体感。

8.2 第二步：逐步叠加工程化能力

流程跑通后，按下面的顺序逐项加固：

1. 模型格式标准化：导出ONNX，用ONNX Runtime替代原始训练框架推理，确认结果一致。
2. 日志与监控：在服务里埋点记录延迟、特征分布、预测结果分布，搭一个简单的Grafana看板。
3. 版本管理：给模型文件和特征定义加上版本号，建立一个简单的映射表。
4. 配置中心化：把模型路径、阈值参数、提示词等从代码里抽出来，放到环境变量或配置中心。
5. 灰度发布：让你部署的服务支持按比例切流量到不同模型版本。

每完成一步，都做一次回归测试，确认没有破坏前面的功能。这个顺序是按"投入产出比"排的：先做能立刻发现问题的事情，再做能避免未来重大问题的事情。

8.3 第三步：从"个人项目"走向"团队协作"

很多时候从0到1的AI工程，不是技术问题，而是协作问题。代码写完了、模型跑通了、监控有了，但这套东西怎么交到别人手上？

我建议最晚在这个阶段把事情落到文档上：

• 一份系统架构说明：画清楚数据流、服务拓扑、依赖关系（文字+ASCII图即可，不用上重型建模工具）。
• 一份变更流程：改模型、改特征、改配置分别走什么流程，谁负责审批。
• 一份故障响应手册：哪些告警需要谁处理，排查步骤是什么。

文档的意义不只是知识传递，更在于强制你把自己的设计思路再梳理一遍。我经常在写文档的过程中发现自己设计的漏洞，趁还没上线赶紧修正，属于成本最低的排错方式。

8.4 进阶方向：什么时候该研究分布式和自动化

当你的模型体量大了、数据量大了、多人协作复杂了，上面这套个人项目方法论会开始显得吃力。到了这个阶段，再去研究下面的方向会更有效：

• 分布式训练：当单机跑不动，或者训练时间超过开发可接受的范围时。
• 自动化训练管线：当特征、模型、数据经常变化，手动跑训练流程频繁出错时。
• Feature Store：当在线特征和离线特征的不一致开始引发线上事故时。
• 模型服务网格：当多个模型服务于多个业务方，单点部署维护不过来时。

不要提前去搞复杂架构，AI工程里真正的复杂度，是业务增长推动的，不是技术选型主动选择的。

9. 我踩过的坑和你的避坑指南

最后这部分，我把这些年踩过最深刻、也最符合"AI工程化"主题的坑集中写一下，算是给选择"from scratch"道路的新人一份避坑清单。

9.1 训练/推理不一致：所有事故里最隐蔽的元凶

前文反复提到的特征一致性问题，我再展开说一下。很多线上事故的表现是"模型效果突然变差"，但根因却是训练和推理之间某处不一致。

举一个非常典型的例子：训练时你用的特征是"用户注册时长"，计算逻辑是"当前时间减去注册时间，取小时数取整"。上线后，某位工程师觉得线上实时计算这套逻辑太耗时，改成了每日离线表预计算"注册天数"，然后稍微换算了一下。你看起来数值范围差不多，但分布形状、缺失率、取整误差都不一样了。模型在训练集上没见过这种细微差异，性能自然受损。

**根治之道没有捷径：唯一的可靠方法，是让训练和推理共用同一套特征计算代码。**如果是SQL特征，训练和推理用同一张SQL模板或同一份逻辑定义；如果是Python特征，抽成同一个函数，两边直接调用。用"同一份代码"替代"语义相同但各自实现"的表达，这个投入的回报率超高。

9.2 本地能跑通≠测试能过≠生产能扛

很多新人会认为，本地跑通代码就等于完成开发了。但在AI工程里，"能用"和"能上线"之间隔着巨大的鸿沟：

• 本地能跑通，是因为你的本地数据是精心挑选的样例，缺失值可能已经被处理过了，分布也不代表线上真实情况。
• 测试环境能过，是因为测试环境的数据是仿真构造的，流量模型完全是理想状态。
• 生产环境是唯一不说谎的场所。

所以我的建议是：**任何模型上线前，至少要在生产环境附近（预发环境）跑24小时以上，观察真实流量下的表现。**这一步不需要很多流量，但必须有真实的数据模式。很多问题（数据格式异常、空值比例失衡、延迟突刺）只会在真实流量下暴露。

9.3 人工Review机制，AI系统的最后一道防线

无论你的监控、告警做得多完善，一个纯自动化的AI系统在关键业务场景里，仍然需要人工Review机制兜底。

我印象最深的一个案例：一个自动内容摘要系统上线后，因为训练数据里混入了几篇特殊格式的文档，模型学会了在摘要里输出源文档的原始段落，导致敏感信息泄露。监控指标完全正常，因为模型的输出格式、长度、流畅度都和平时没区别，唯一的问题是内容本身不合规。最后是靠人工抽检发现的。

这个案例给我的教训是：**AI系统在质量维度上需要多维监控，除了统计指标，还要有内容维度的抽检。**尤其在高风险业务（金融、医疗、合规场景），建议强制保留人工Review环节。系统可以自动处理90%的常规情况，但剩下10%必须进入人工流程。一方面是为了质量，另一方面也是为AI系统提供持续学习的标注数据。

AI工程化这条路，没有银弹，没有一键完成的按钮。它更像是一个"不断发现薄弱环节，然后弥补薄弱环节"的循环。但好消息是，每一处被补齐的薄弱环节，都会形成一个长久的工程资产，让你的系统在后续迭代中变得更稳、更快、更可信。希望这篇文章，能让正在"from scratch"路上的你少走几步弯路。