1. 为什么从零搭建AI工程是第一道坎1.1 从能跑通到能上线差的不只是运气我头一回独立负责一个AI功能从0到1的全过程时最大的感受是跑通一个模型的Demo和把一个AI功能稳定交付到生产环境几乎是两门不同的学科。当时我一腔热血在Jupyter Notebook里把模型调得漂漂亮亮离线指标也好看兴致勃勃地往服务端一部署立刻被现实教做人。接口响应不稳定、线上数据分布和训练集有明显偏差、特征字段偶尔缺失、模型偶发超时导致上游超时重试……这些破事没有一件是模型结构本身的问题但它们每一项都能让功能在线上翻车。这个项目标题叫ai-engineering-from-scratch说的正是这件事不把AI当作训练一个模型这种单点任务而是当作一套完整工程体系来搭建。从零起步的时候你不只是在学怎么调参而是在学怎么把数据、模型、服务、监控、迭代这五件事串成一条可持续运转的链路。1.2 典型初学者工程的几个隐形断层我复盘过自己最早期的几个项目也帮不少人看过代码发现从零起步的人通常会踩到同样的断层数据断层训练时用的是处理好的离线CSV但线上接口拿到的原始数据形态完全不一样中间缺了完整的ETL转换逻辑模型上线即失效。评估断层只用准确率或Loss这种单一指标评价模型没有设计贴近业务场景的评估集和评估维度模型在测试集上高分低能。实验断层代码改来改去没有版本管理超参数写在 Notebook 的某个角落过两天想复现当时的最好结果连自己都找不到当时用了什么配置。部署断层训练环境用的PyTorch版本、CUDA版本和生产环境的CPU推理环境不一致模型导出后推理结果出现细微差异。这些断层单独拎出来每一个都不是大问题但叠加在一起就成了压死项目的最后一根稻草。这篇内容我会完整梳理一遍从零起步时我自己搭过的工程框架把数据、训练、部署、监控、迭代这几层逐一说透尽量少讲虚的多放可以直接抄作业的东西。2. 地基先行从需求倒推技术栈与工程架构2.1 先定义问题再选武器从零开始做AI工程最大的忌讳是先选模型再想问题。正确顺序应该是把问题定义清楚再倒推技术栈和架构。具体来说第一步要回答四件事这个功能是分类、回归、排序、生成还是检索线上调用允许的延迟上限是多少比如50ms、200ms还是2s数据量和数据形态是怎样的文本、图像、表格、时序错误代价有多高推荐错了无所谓风控判错了代价巨大这四个答案直接决定了你的技术选型。我自己早期犯过的错是不管什么需求上来先加载一个Bert或者大模型再说。结果很多场景其实用XGBoost或者一个简单的Embedding检索就能解决成本和延迟都低一个数量级。2.2 技术栈选型的一个现实原则技术选型没有银弹但有一个很现实的原则优先选择你团队里有人真正用过、遇到问题能查到答案、社区足够活跃的组件而不是追逐最新最热但周围没人趟过坑的方案。我整理过一个从零起步够用的技术栈清单可以参考层级推荐方向说明数据存储PostgreSQL / ClickHouse结构化业务数据选PG日志和时序数据选ClickHouse数据处理Python Pandas/Polars Airflow或Dagster起步阶段Airflow足够数据量大了再考虑Spark特征与训练PyTorch sklearn XGBoost三者互补不必贪多实验管理MLflow或WB记录参数、指标、产物免费方案够用模型服务FastAPI ONNX Runtime轻量稳定能避开训练框架依赖地狱监控观测Prometheus Grafana Evidently系统指标和模型指标分开管部署方式Docker K8s或轻量VPS视团队运维能力而定不强上K8s技术栈不追求全追求链路完整。上面的组合我实际用过已经能满足大多数中小型AI项目从0到1的需求。2.3 从零起步的最小架构长什么样很多人一听到架构就联想到一堆微服务和复杂中间件但AI项目的起步架构可以非常简单重点是分层清晰。我当时用的最小架构是五层接入层FastAPI提供HTTP接口做鉴权、限流、参数校验。逻辑层负责调用编排比如先查缓存、再走检索/再调模型、最后做结果后处理。数据层存储业务原始数据、特征数据、模型日志。模型层加载训练好的模型文件提供推理函数不直接接触HTTP。观测层记录推理耗时、输入分布、结果分布出现异常时能报警。这套架构没有一上来就上消息队列、没有复杂的模型平台但每一层边界清楚后续想往哪个方向扩展都有明确的位置可放。工程化不是铺大摊子而是先把必要的职责切分出来。3. 让数据成为可依赖的资产工程化的最小闭环3.1 数据管线的第一步从源头建立约束在AI工程里数据是资产还是负债取决于你有没有从源头建立约束。很多项目前期数据乱成一团后面模型怎么调都救不回来。我后来总结出一个源头约束三件套第一定义Schema。每张数据表、每个特征文件都应该有一个明确的字段定义包括字段名、类型、允许的取值范围、是否可空。用Pydantic或Great Expectations这类工具在数据入口做校验不合格的数据要么拦截、要么告警不能直接混进数据集。第二定义数据版本。不要覆盖式更新数据集每次新增或修正数据都要生成新的版本。我习惯用时间戳变更摘要的方式命名特征文件和训练集比如train_dataset_20250610_v2.parquet并在实验记录里绑定对应的数据版本。第三定义更新节奏。业务数据是每日更新还是实时更新代码里必须有明确约定。否则你训练时用的数据和线上模型读取的数据时间口径不一致模型就会穿越——用未来数据训练却在用历史数据推理。3.2 特征存储与大模型背景下数据工程的重心特征存储这个词听起来高大上但核心思想特别朴素把原始数据加工成模型可用的特征这个过程应该有一个统一的、可复用的地方而不是在每次训练的代码里临时现算。我第一次做AI项目时特征计算逻辑散落在各个Notebook里同一特征在不同脚本里算出来的结果都不一样后来排查到怀疑人生。把特征计算统一成特征工程模块之后这个问题才彻底解决。还有一点值得提醒在大模型火热的背景下很多人以为数据工程的重点变成了投喂长文本但实际上大模型应用里更常见的是检索增强RAG、结构化数据抽取、文档解析这类工程问题。你最终会发现没有一个可靠的知识库数据清洗管线RAG检索出来的全是噪音生成质量自然拉胯。所以不管模型怎么变数据工程的底层基本功不会过时。3.3 数据质量校验怎么落地数据质量四个字听起来很抽象落到工程上其实是四个具体维度的检查。完整性字段缺失率是否超过阈值比如5%。时效性数据延迟是否超过要求比如昨天应该入库的数据今天还没到。一致性同一实体的字段在不同表中是否矛盾比如订单金额和支付流水对不上。分布漂移线上特征分布和训练集分布是否出现明显偏移。分布漂移这个维度容易被忽略但恰恰是模型线上效果衰减的头号元凶。我当时用Evidently这个开源库来监控特征分布设置每周对比线上近期数据和训练集数据的分布差异一旦PSI指标超过0.2就把警报拉起来。PSI超过0.2代表特征分布明显漂移这时候模型效果下滑就别慌第一反应先看数据漂移而不是重新调参。3.4 数据切片与建模中的类别不平衡问题另外一个贯穿数据全流程的问题是类别不平衡。很多业务场景里正样本比例低到离谱比如转化率1%甚至0.1%这时候你再怎么调模型结构效果改善都有限。工程上的处理思路通常有三个方向一是采样策略对负样本做下采样、对正样本做上采样或合成但要注意采样比例别太极端否则线上分布与训练分布脱节更严重。二是样本加权给少数类样本更高的损失权重比简单粗暴地复制样本效果更稳。三是评估指标换血别死盯准确率改用Precision/Recall/F1、PR-AUC等更贴合不平衡场景的指标。我见过不少人用准确率评估一个正样本只有1%的模型模型把所有样本都判成负类准确率99%看起来神了实际上一无是处。4. 从训练到上线模型交付链路上的关键节点4.1 第一份代码规范让实验可复现模型训练的代码规范重要程度被严重低估。训练代码和普通业务代码最大的区别是它带着实验性——你会反复改参数、换结构、对比效果如果没有严谨的规范最后一定是一团乱账。我在经历过一次复现不出最好结果的惨痛教训后给自己定下了三条硬规矩第一条显式设置随机种子。涉及随机性的库Python、NumPy、PyTorch都要固定seed保证每次训练初始状态一致。虽然不同硬件上仍然可能有细微偏差但至少同一台机器上可以复现。第二条配置和代码分离。所有超参数写入配置文件YAML或JSON代码里不硬编码任何关键参数。每次实验记录用的就是这份配置文件的哈希值改任何参数都能追踪到。第三条保存完整运行环境。用requirements.txt锁死每个依赖包的精确版本而不是区间。PyTorch升级一个小版本某些算子行为都可能变化生产环境的依赖版本必须和训练环境完全一致。这三条规矩我后来一直沿用再也没出现过当时是怎么跑出来的这种追债问题。4.2 评估体系指标必须对着业务说话技术指标和业务指标之间的落差是从零起步做AI工程最容易困惑的地方。比如你做推荐系统模型离线指标AUC涨了0.01老板问这能带来多少收入你答不上来——说明你的评估体系还没打通业务。我的做法是建一个三层评估体系模型层看Loss、Accuracy、F1等经典指标用于快速筛选实验方向。行为层看模型预测结果在业务上的行为是否符合预期比如推荐结果的多样性、相关性客服机器人的兜底率和转人工率。业务层看最终业务指标比如转化率、留存率、客单价。离线评估阶段主要看模型层和行为层但必须把行为层指标提前在离线阶段设计好。很多项目到了线上才发现模型没有满足业务行为要求就是因为评估体系缺少中间这一层。4.3 模型服务化的一个稳妥起点模型从训练环境走向生产环境最常见的坑是环境不一致。你的训练库用的是PyTorchCUDA生产服务器可能只有一个2核4G的容器强行跑PyTorch服务既慢又笨重。我推荐一个稳妥且成熟的路线PyTorch训练转ONNX用ONNX Runtime做推理FastAPI包一层HTTP服务。这个路线的优势有三个ONNX是一个开放格式不绑定训练框架生产环境不需要装PyTorch。ONNX Runtime的CPU推理性能远优于直接用PyTorch的CPU模式对大部分中小型模型来说延迟完全够用。FastAPI写起来清爽自带请求校验和OpenAPI文档调试联调体验比Flask好不少。导出ONNX的代码不复杂但有两个易错点一个是动态轴要显式声明比如batch size就是动态的另一个是输入数据的预处理逻辑要固化到导出的模型里或者至少在导出前把预处理函数也整理好。4.4 大模型应用的上下文供给问题现在很多项目开始涉及大模型应用和传统模型相比它带来的工程新问题不是怎么训练模型而是怎么给模型喂正确的上下文。核心场景是RAG。看起来只是把知识库切片、embedding、检索、拼Prompt、调API但实际操作中有几个细节没做对效果会差很多切片策略要按语义边界切而不是纯按固定字数硬切否则一个完整知识点被拦腰截断检索质量大受影响。检索策略不能只做向量相似度要配合关键词召回做混合检索尤其是用户问题里包含专有名词、型号、编号的时候向量检索经常不如精确匹配好用。重排阶段别省召回Top50之后再让重排模型精排取Top5质量提升非常明显。引用溯源必须保留让用户或运营能查每条回答依据的来源这也是排查AI胡说八道的重要手段。5. AI工程与软件工程的分界线稳定、可观测与持续演进5.1 可观测性传统软件的监控思路不够用传统软件工程师上线一个接口后会看QPS、延迟、错误率这些指标在AI服务里当然也要看但远远不够。模型服务的核心风险在于质量劣化——接口响应一切正常错误率毫无波动但模型输出的内容质量在悄悄下降。所以AI服务的可观测性要增加三个特有指标输入分布漂移线上实时输入的数据分布是否偏离训练集分布。预测分布漂移模型输出的类别比例、分数分布、内容多样性是否出现异常。反馈闭环数据用户是否有反馈按钮点赞/点踩、业务侧是否有后验结果比如用户是否真的购买了推荐商品这些数据能不能回收并量化成模型质量指标。这三点才是AI工程区别于普通软件工程的核心监控维度。我自己的经验是先保证能度量这三点再去精细化调报警阈值。5.2 持续迭代模型版本、数据版本、代码版本三者协同传统软件上线只需要管代码版本AI项目上线则要同时管三样东西模型文件版本、训练数据版本、推理代码版本。任何一个不一致线上行为都不可复现、不可追溯。我用的协同方案是每次模型上线前把模型文件、对应的训练数据版本号、推理代码仓库的commit号组成一个发布单元登记到一张上线表中并在模型服务的日志里同样记录这三个标识。这样遇到线上问题我能直接定位到这个坏行为到底是哪份代码、哪个模型、哪份数据带来的而不是在服务日志里大海捞针。5.3 模型回滚与灰度发布模型回滚和代码回滚不太一样。代码回滚是回到上一个可用版本模型回滚除了要保留上一个模型文件还应该保留它当时的推理代码——因为中间可能改了输入输出处理逻辑直接用新代码加载旧模型可能会出问题。灰度发布则有一个容易忽略的点除了按流量灰度还应该按输入特征灰度。比如客服对话机器人可以先灰度一部分非高价值用户的流量风控模型灰度流量要刻意避开高峰期因为模型延迟和特征获取在峰值期的表现往往和平时不一样。5.4 从0到1最容易丢分的地方最后盘一下从零搭建AI工程时最容易被忽略、但后来反复回头补课的几个地方没有在项目启动时就定义好线上质量指标。这个指标要从业务价值出发倒推不是从模型指标出发。日志设计没考虑追溯性。线上推理日志只记录结果没记录输入特征快照出了问题想复盘都没法复盘。Embedding模型更新之后老向量没处理。换了一个embedding模型向量距离的语义空间全变了旧向量库必须离线重算这件事极容易漏。温度、Top-p这类参数被随意调来调去。大模型应用的生成参数看似无伤大雅实际上对回答风格和质量影响巨大每一项参数变更都应该走配置管理和评估流程。6. 最后再说点实在话这篇文章写到这基本把我从零搭建AI工程体系的骨架都翻出来了。我个人最大的体会是AI工程从来不是模型有多强的比拼而是链条有多稳的较量。数据链路断了模型再新也没用评估链路虚了调参就是赌博部署链路糙了再好的效果也落不了地观测链路缺了线上出了问题你连往哪查都不知道。如果你正打算从零起步我给的最实在的建议是不要一上来就追求大而全的AI平台先把一条最小的链路走通——一个稳定的数据入口、一份可复现的训练代码、一个轻量的推理服务、一组基本的监控指标。这四样东西跑顺了你再去引入更复杂的调度、更完善的实验平台、更精细的反馈闭环每一步都有清晰的落点。起步阶段不用怕慢怕的是步子還沒邁出去就被什么都要学吓住了。挑一个真实业务场景把这条链路完整跑一遍比看一百篇教程都有用。
从零搭建AI工程：数据、训练、部署与监控全链路实战
1. 为什么从零搭建AI工程是第一道坎1.1 从能跑通到能上线差的不只是运气我头一回独立负责一个AI功能从0到1的全过程时最大的感受是跑通一个模型的Demo和把一个AI功能稳定交付到生产环境几乎是两门不同的学科。当时我一腔热血在Jupyter Notebook里把模型调得漂漂亮亮离线指标也好看兴致勃勃地往服务端一部署立刻被现实教做人。接口响应不稳定、线上数据分布和训练集有明显偏差、特征字段偶尔缺失、模型偶发超时导致上游超时重试……这些破事没有一件是模型结构本身的问题但它们每一项都能让功能在线上翻车。这个项目标题叫ai-engineering-from-scratch说的正是这件事不把AI当作训练一个模型这种单点任务而是当作一套完整工程体系来搭建。从零起步的时候你不只是在学怎么调参而是在学怎么把数据、模型、服务、监控、迭代这五件事串成一条可持续运转的链路。1.2 典型初学者工程的几个隐形断层我复盘过自己最早期的几个项目也帮不少人看过代码发现从零起步的人通常会踩到同样的断层数据断层训练时用的是处理好的离线CSV但线上接口拿到的原始数据形态完全不一样中间缺了完整的ETL转换逻辑模型上线即失效。评估断层只用准确率或Loss这种单一指标评价模型没有设计贴近业务场景的评估集和评估维度模型在测试集上高分低能。实验断层代码改来改去没有版本管理超参数写在 Notebook 的某个角落过两天想复现当时的最好结果连自己都找不到当时用了什么配置。部署断层训练环境用的PyTorch版本、CUDA版本和生产环境的CPU推理环境不一致模型导出后推理结果出现细微差异。这些断层单独拎出来每一个都不是大问题但叠加在一起就成了压死项目的最后一根稻草。这篇内容我会完整梳理一遍从零起步时我自己搭过的工程框架把数据、训练、部署、监控、迭代这几层逐一说透尽量少讲虚的多放可以直接抄作业的东西。2. 地基先行从需求倒推技术栈与工程架构2.1 先定义问题再选武器从零开始做AI工程最大的忌讳是先选模型再想问题。正确顺序应该是把问题定义清楚再倒推技术栈和架构。具体来说第一步要回答四件事这个功能是分类、回归、排序、生成还是检索线上调用允许的延迟上限是多少比如50ms、200ms还是2s数据量和数据形态是怎样的文本、图像、表格、时序错误代价有多高推荐错了无所谓风控判错了代价巨大这四个答案直接决定了你的技术选型。我自己早期犯过的错是不管什么需求上来先加载一个Bert或者大模型再说。结果很多场景其实用XGBoost或者一个简单的Embedding检索就能解决成本和延迟都低一个数量级。2.2 技术栈选型的一个现实原则技术选型没有银弹但有一个很现实的原则优先选择你团队里有人真正用过、遇到问题能查到答案、社区足够活跃的组件而不是追逐最新最热但周围没人趟过坑的方案。我整理过一个从零起步够用的技术栈清单可以参考层级推荐方向说明数据存储PostgreSQL / ClickHouse结构化业务数据选PG日志和时序数据选ClickHouse数据处理Python Pandas/Polars Airflow或Dagster起步阶段Airflow足够数据量大了再考虑Spark特征与训练PyTorch sklearn XGBoost三者互补不必贪多实验管理MLflow或WB记录参数、指标、产物免费方案够用模型服务FastAPI ONNX Runtime轻量稳定能避开训练框架依赖地狱监控观测Prometheus Grafana Evidently系统指标和模型指标分开管部署方式Docker K8s或轻量VPS视团队运维能力而定不强上K8s技术栈不追求全追求链路完整。上面的组合我实际用过已经能满足大多数中小型AI项目从0到1的需求。2.3 从零起步的最小架构长什么样很多人一听到架构就联想到一堆微服务和复杂中间件但AI项目的起步架构可以非常简单重点是分层清晰。我当时用的最小架构是五层接入层FastAPI提供HTTP接口做鉴权、限流、参数校验。逻辑层负责调用编排比如先查缓存、再走检索/再调模型、最后做结果后处理。数据层存储业务原始数据、特征数据、模型日志。模型层加载训练好的模型文件提供推理函数不直接接触HTTP。观测层记录推理耗时、输入分布、结果分布出现异常时能报警。这套架构没有一上来就上消息队列、没有复杂的模型平台但每一层边界清楚后续想往哪个方向扩展都有明确的位置可放。工程化不是铺大摊子而是先把必要的职责切分出来。3. 让数据成为可依赖的资产工程化的最小闭环3.1 数据管线的第一步从源头建立约束在AI工程里数据是资产还是负债取决于你有没有从源头建立约束。很多项目前期数据乱成一团后面模型怎么调都救不回来。我后来总结出一个源头约束三件套第一定义Schema。每张数据表、每个特征文件都应该有一个明确的字段定义包括字段名、类型、允许的取值范围、是否可空。用Pydantic或Great Expectations这类工具在数据入口做校验不合格的数据要么拦截、要么告警不能直接混进数据集。第二定义数据版本。不要覆盖式更新数据集每次新增或修正数据都要生成新的版本。我习惯用时间戳变更摘要的方式命名特征文件和训练集比如train_dataset_20250610_v2.parquet并在实验记录里绑定对应的数据版本。第三定义更新节奏。业务数据是每日更新还是实时更新代码里必须有明确约定。否则你训练时用的数据和线上模型读取的数据时间口径不一致模型就会穿越——用未来数据训练却在用历史数据推理。3.2 特征存储与大模型背景下数据工程的重心特征存储这个词听起来高大上但核心思想特别朴素把原始数据加工成模型可用的特征这个过程应该有一个统一的、可复用的地方而不是在每次训练的代码里临时现算。我第一次做AI项目时特征计算逻辑散落在各个Notebook里同一特征在不同脚本里算出来的结果都不一样后来排查到怀疑人生。把特征计算统一成特征工程模块之后这个问题才彻底解决。还有一点值得提醒在大模型火热的背景下很多人以为数据工程的重点变成了投喂长文本但实际上大模型应用里更常见的是检索增强RAG、结构化数据抽取、文档解析这类工程问题。你最终会发现没有一个可靠的知识库数据清洗管线RAG检索出来的全是噪音生成质量自然拉胯。所以不管模型怎么变数据工程的底层基本功不会过时。3.3 数据质量校验怎么落地数据质量四个字听起来很抽象落到工程上其实是四个具体维度的检查。完整性字段缺失率是否超过阈值比如5%。时效性数据延迟是否超过要求比如昨天应该入库的数据今天还没到。一致性同一实体的字段在不同表中是否矛盾比如订单金额和支付流水对不上。分布漂移线上特征分布和训练集分布是否出现明显偏移。分布漂移这个维度容易被忽略但恰恰是模型线上效果衰减的头号元凶。我当时用Evidently这个开源库来监控特征分布设置每周对比线上近期数据和训练集数据的分布差异一旦PSI指标超过0.2就把警报拉起来。PSI超过0.2代表特征分布明显漂移这时候模型效果下滑就别慌第一反应先看数据漂移而不是重新调参。3.4 数据切片与建模中的类别不平衡问题另外一个贯穿数据全流程的问题是类别不平衡。很多业务场景里正样本比例低到离谱比如转化率1%甚至0.1%这时候你再怎么调模型结构效果改善都有限。工程上的处理思路通常有三个方向一是采样策略对负样本做下采样、对正样本做上采样或合成但要注意采样比例别太极端否则线上分布与训练分布脱节更严重。二是样本加权给少数类样本更高的损失权重比简单粗暴地复制样本效果更稳。三是评估指标换血别死盯准确率改用Precision/Recall/F1、PR-AUC等更贴合不平衡场景的指标。我见过不少人用准确率评估一个正样本只有1%的模型模型把所有样本都判成负类准确率99%看起来神了实际上一无是处。4. 从训练到上线模型交付链路上的关键节点4.1 第一份代码规范让实验可复现模型训练的代码规范重要程度被严重低估。训练代码和普通业务代码最大的区别是它带着实验性——你会反复改参数、换结构、对比效果如果没有严谨的规范最后一定是一团乱账。我在经历过一次复现不出最好结果的惨痛教训后给自己定下了三条硬规矩第一条显式设置随机种子。涉及随机性的库Python、NumPy、PyTorch都要固定seed保证每次训练初始状态一致。虽然不同硬件上仍然可能有细微偏差但至少同一台机器上可以复现。第二条配置和代码分离。所有超参数写入配置文件YAML或JSON代码里不硬编码任何关键参数。每次实验记录用的就是这份配置文件的哈希值改任何参数都能追踪到。第三条保存完整运行环境。用requirements.txt锁死每个依赖包的精确版本而不是区间。PyTorch升级一个小版本某些算子行为都可能变化生产环境的依赖版本必须和训练环境完全一致。这三条规矩我后来一直沿用再也没出现过当时是怎么跑出来的这种追债问题。4.2 评估体系指标必须对着业务说话技术指标和业务指标之间的落差是从零起步做AI工程最容易困惑的地方。比如你做推荐系统模型离线指标AUC涨了0.01老板问这能带来多少收入你答不上来——说明你的评估体系还没打通业务。我的做法是建一个三层评估体系模型层看Loss、Accuracy、F1等经典指标用于快速筛选实验方向。行为层看模型预测结果在业务上的行为是否符合预期比如推荐结果的多样性、相关性客服机器人的兜底率和转人工率。业务层看最终业务指标比如转化率、留存率、客单价。离线评估阶段主要看模型层和行为层但必须把行为层指标提前在离线阶段设计好。很多项目到了线上才发现模型没有满足业务行为要求就是因为评估体系缺少中间这一层。4.3 模型服务化的一个稳妥起点模型从训练环境走向生产环境最常见的坑是环境不一致。你的训练库用的是PyTorchCUDA生产服务器可能只有一个2核4G的容器强行跑PyTorch服务既慢又笨重。我推荐一个稳妥且成熟的路线PyTorch训练转ONNX用ONNX Runtime做推理FastAPI包一层HTTP服务。这个路线的优势有三个ONNX是一个开放格式不绑定训练框架生产环境不需要装PyTorch。ONNX Runtime的CPU推理性能远优于直接用PyTorch的CPU模式对大部分中小型模型来说延迟完全够用。FastAPI写起来清爽自带请求校验和OpenAPI文档调试联调体验比Flask好不少。导出ONNX的代码不复杂但有两个易错点一个是动态轴要显式声明比如batch size就是动态的另一个是输入数据的预处理逻辑要固化到导出的模型里或者至少在导出前把预处理函数也整理好。4.4 大模型应用的上下文供给问题现在很多项目开始涉及大模型应用和传统模型相比它带来的工程新问题不是怎么训练模型而是怎么给模型喂正确的上下文。核心场景是RAG。看起来只是把知识库切片、embedding、检索、拼Prompt、调API但实际操作中有几个细节没做对效果会差很多切片策略要按语义边界切而不是纯按固定字数硬切否则一个完整知识点被拦腰截断检索质量大受影响。检索策略不能只做向量相似度要配合关键词召回做混合检索尤其是用户问题里包含专有名词、型号、编号的时候向量检索经常不如精确匹配好用。重排阶段别省召回Top50之后再让重排模型精排取Top5质量提升非常明显。引用溯源必须保留让用户或运营能查每条回答依据的来源这也是排查AI胡说八道的重要手段。5. AI工程与软件工程的分界线稳定、可观测与持续演进5.1 可观测性传统软件的监控思路不够用传统软件工程师上线一个接口后会看QPS、延迟、错误率这些指标在AI服务里当然也要看但远远不够。模型服务的核心风险在于质量劣化——接口响应一切正常错误率毫无波动但模型输出的内容质量在悄悄下降。所以AI服务的可观测性要增加三个特有指标输入分布漂移线上实时输入的数据分布是否偏离训练集分布。预测分布漂移模型输出的类别比例、分数分布、内容多样性是否出现异常。反馈闭环数据用户是否有反馈按钮点赞/点踩、业务侧是否有后验结果比如用户是否真的购买了推荐商品这些数据能不能回收并量化成模型质量指标。这三点才是AI工程区别于普通软件工程的核心监控维度。我自己的经验是先保证能度量这三点再去精细化调报警阈值。5.2 持续迭代模型版本、数据版本、代码版本三者协同传统软件上线只需要管代码版本AI项目上线则要同时管三样东西模型文件版本、训练数据版本、推理代码版本。任何一个不一致线上行为都不可复现、不可追溯。我用的协同方案是每次模型上线前把模型文件、对应的训练数据版本号、推理代码仓库的commit号组成一个发布单元登记到一张上线表中并在模型服务的日志里同样记录这三个标识。这样遇到线上问题我能直接定位到这个坏行为到底是哪份代码、哪个模型、哪份数据带来的而不是在服务日志里大海捞针。5.3 模型回滚与灰度发布模型回滚和代码回滚不太一样。代码回滚是回到上一个可用版本模型回滚除了要保留上一个模型文件还应该保留它当时的推理代码——因为中间可能改了输入输出处理逻辑直接用新代码加载旧模型可能会出问题。灰度发布则有一个容易忽略的点除了按流量灰度还应该按输入特征灰度。比如客服对话机器人可以先灰度一部分非高价值用户的流量风控模型灰度流量要刻意避开高峰期因为模型延迟和特征获取在峰值期的表现往往和平时不一样。5.4 从0到1最容易丢分的地方最后盘一下从零搭建AI工程时最容易被忽略、但后来反复回头补课的几个地方没有在项目启动时就定义好线上质量指标。这个指标要从业务价值出发倒推不是从模型指标出发。日志设计没考虑追溯性。线上推理日志只记录结果没记录输入特征快照出了问题想复盘都没法复盘。Embedding模型更新之后老向量没处理。换了一个embedding模型向量距离的语义空间全变了旧向量库必须离线重算这件事极容易漏。温度、Top-p这类参数被随意调来调去。大模型应用的生成参数看似无伤大雅实际上对回答风格和质量影响巨大每一项参数变更都应该走配置管理和评估流程。6. 最后再说点实在话这篇文章写到这基本把我从零搭建AI工程体系的骨架都翻出来了。我个人最大的体会是AI工程从来不是模型有多强的比拼而是链条有多稳的较量。数据链路断了模型再新也没用评估链路虚了调参就是赌博部署链路糙了再好的效果也落不了地观测链路缺了线上出了问题你连往哪查都不知道。如果你正打算从零起步我给的最实在的建议是不要一上来就追求大而全的AI平台先把一条最小的链路走通——一个稳定的数据入口、一份可复现的训练代码、一个轻量的推理服务、一组基本的监控指标。这四样东西跑顺了你再去引入更复杂的调度、更完善的实验平台、更精细的反馈闭环每一步都有清晰的落点。起步阶段不用怕慢怕的是步子還沒邁出去就被什么都要学吓住了。挑一个真实业务场景把这条链路完整跑一遍比看一百篇教程都有用。
