1. 从零搭建AI工程能力为什么大多数人第一步就走偏了聊到“从零开始做AI工程”这个话题我见过太多人一上来就扎进模型训练里结果折腾了两周连一个能跑通的服务都没搭出来。这个项目标题“ai-engineering-from-scratch”本身其实点出了一个很关键的定位——它强调的不是“从零训练一个大模型”而是“从零建立一套AI工程化的能力体系”。这两件事的差别比很多人想象的要大得多。AI工程AI Engineering和机器学习研究ML Research是两个完全不同的工种。研究关注的是模型结构、损失函数、训练策略能不能刷新榜单工程关注的是这套东西能不能稳定、可维护、可扩展地跑在生产环境里能不能被其他系统调用出问题了能不能快速定位。我见过不少算法背景的朋友转工程时最不适应的一点就是以前写代码是为了验证一个想法现在写代码是为了让一个系统在别人手里也能跑起来。这个项目适合谁如果你是刚入行的算法工程师想把模型真正落地成产品如果你是后端或全栈工程师想补齐AI这一块的能力如果你是技术负责人需要给团队搭一套AI工程的基础设施——那这套从零开始的思路就是为你准备的。它不要求你先成为调参大师但要求你对软件工程有基本的敬畏心。我自己的经验是AI工程项目失败的原因里真正因为模型效果不行的可能只占三成剩下七成全是工程问题数据管道断了、依赖版本冲突、推理服务内存泄漏、监控缺失导致线上挂了半天没人知道。所以这篇内容我会把重心放在“工程”两个字上模型部分够用就行重点讲怎么把整条链路搭得扎实。2. 动手之前先把技术栈的账算清楚2.1 为什么我不建议一上来就用最重的框架新手最容易犯的错是打开某个教程看到用了一堆重型框架就照着全装一遍。结果环境配了三天还没写第一行业务代码热情已经消耗殆尽。从零搭建AI工程能力第一原则是按需引入逐步加码。我的建议是分三个阶段来选型。第一阶段用最朴素的Python脚本加标准库把数据读取、简单推理跑通目的是理解数据长什么样、模型输入输出是什么格式。第二阶段引入轻量级的Web框架比如FastAPI把推理包装成HTTP服务这时候你才开始接触“工程”的核心——接口契约。第三阶段再根据实际压力引入任务队列、缓存、容器化这些重型武器。这个顺序背后的逻辑是每一层引入都要有明确的、当下就存在的理由。如果你现在只有一个用户上Kubernetes就是自找麻烦如果你还没搞清楚请求的QPS峰值谈自动扩缩容就是纸上谈兵。我见过一个团队在日请求量不到一千的时候上了完整的微服务架构结果运维成本比开发成本还高这就是典型的过度工程。2.2 依赖管理这件事值得单独拎出来说AI项目的依赖地狱是出了名的。一个典型的坑是你的模型依赖某个版本的数值计算库而你的Web框架依赖另一个版本两者不兼容装哪个另一个就崩。我踩过最惨的一次是本地跑得好好的部署到服务器上因为底层数学库版本差了一个小版本号推理结果直接偏了。解决办法其实不复杂但需要纪律性。第一永远用虚拟环境隔离不管是venv还是conda一个项目一个环境绝不混用。第二锁定版本号不要写numpy1.20这种模糊约束要写死到具体版本用requirements.txt或者pyproject.toml管理。第三区分开发依赖和生产依赖测试框架、代码检查工具这些不要打进生产镜像。这里有个实操细节生成锁文件的时候建议用pip freeze导出完整依赖树而不是手写顶层依赖。因为顶层依赖的间接依赖也可能出问题锁死整棵树才能保证环境可复现。代价是文件会比较长但换来的是“在我机器上能跑”变成“在任何机器上都能跑”这笔账很划算。2.3 硬件和成本别被“必须上GPU”吓住很多人以为做AI工程必须有一块好显卡其实大部分工程环节根本用不到GPU。数据清洗、特征处理、服务框架搭建、监控告警这些全是CPU密集型或者IO密集型的工作。真正需要GPU的只有模型训练和部分推理场景。我的做法是开发和调试阶段全部在CPU上跑小批量数据把逻辑跑通、把边界情况测出来最后再上GPU做全量训练或高并发推理。这样既能省下大量等待时间也避免了在昂贵的GPU机器上做低效的调试。如果只是做推理服务很多场景下用CPU加量化模型就足够了延迟和吞吐都能接受成本却低一个数量级。3. 数据管道AI工程里最脏最累但最不能省的一环3.1 数据质量决定了项目天花板有句话在圈子里流传很广垃圾进垃圾出。但我想说得更具体一点——数据问题在工程上的表现往往不是模型效果差而是系统不稳定。比如某个字段偶尔为空导致解析崩溃某个类别突然出现训练时没见过的值导致编码报错时间戳格式不统一导致排序错乱。这些问题在离线实验里可能被小数据集掩盖一上生产就集中爆发。所以从零搭建的第一步不是写模型代码而是建立数据契约。所谓数据契约就是明确每个字段的类型、取值范围、是否允许为空、异常值怎么处理。这份契约要写成代码里的校验逻辑而不是停留在文档里。我习惯在数据入口处加一层校验任何不符合契约的数据直接拒绝并记录宁可让上游修数据也不让脏数据流进管道。3.2 一个可复用的数据处理骨架下面这个骨架是我在多个项目里反复用过的结构简单但覆盖了核心环节。它不依赖任何重型框架纯标准库加少量常用工具就能跑。import logging from dataclasses import dataclass from typing import Callable, Iterable logging.basicConfig(levellogging.INFO) logger logging.getLogger(__name__) dataclass class DataRecord: raw: dict cleaned: dict None class Pipeline: def __init__(self): self.steps: list[Callable] [] def add_step(self, fn: Callable) - Pipeline: self.steps.append(fn) return self def run(self, records: Iterable[DataRecord]) - list[DataRecord]: results [] for idx, record in enumerate(records): try: for step in self.steps: record step(record) results.append(record) except Exception as exc: logger.warning(记录 %s 处理失败: %s, idx, exc) return results这个骨架的关键设计在于每一步都是纯函数输入输出都是DataRecord这样每一步都可以单独测试出问题能快速定位是哪一步的锅。另外异常处理是记录并跳过而不是整个管道崩溃这在生产环境里非常重要——一条脏数据不应该让整批任务失败。3.3 数据版本管理被忽视的复现性基石模型有版本代码有版本但很多人忘了数据也要有版本。我遇到过最头疼的情况是两周前跑出一个不错的效果两周后想复现发现数据已经被上游更新了怎么调都回不到那个结果。这不是模型的问题是数据没有快照。轻量级的做法是每次数据处理任务产出的结果按时间戳或内容哈希命名存储同时记录这次处理用了哪个版本的原始数据、哪份处理代码。不需要上复杂的数据版本工具一个规范的目录结构加一份元数据文件就能解决大部分问题。等团队规模大了再考虑专业工具也不迟。4. 把模型变成服务接口设计里的门道4.1 推理服务的核心不是推理是契约很多人写推理服务关注点全在“怎么把模型加载进来、怎么调predict”但真正决定这个服务好不好用的是接口设计。一个糟糕的接口会让调用方痛苦不堪一个清晰的接口能让整个系统顺畅运转。我设计推理接口时坚持几条原则。第一输入输出用明确的结构化格式通常是JSON字段名要有业务含义不要用input1、output2这种。第二错误码要区分类型参数错误、模型内部错误、超时、限流这些要返回不同的状态码和错误信息方便调用方做不同处理。第三接口要幂等同样的输入多次调用应该返回同样的结果这对重试机制至关重要。4.2 用FastAPI搭一个最小可用的推理服务FastAPI是我目前最推荐的轻量级选择原因是它自带数据校验和自动文档能省掉大量样板代码。下面是一个最小可用的例子。from fastapi import FastAPI, HTTPException from pydantic import BaseModel, Field import time app FastAPI(title推理服务) class PredictRequest(BaseModel): text: str Field(..., min_length1, max_length2000) top_k: int Field(default3, ge1, le10) class PredictResponse(BaseModel): results: list[dict] latency_ms: float app.post(/predict, response_modelPredictResponse) def predict(req: PredictRequest): start time.perf_counter() try: results run_model(req.text, req.top_k) except ValueError as exc: raise HTTPException(status_code400, detailstr(exc)) except Exception: raise HTTPException(status_code500, detail模型内部错误) latency (time.perf_counter() - start) * 1000 return PredictResponse(resultsresults, latency_mslatency)这段代码里几个细节值得注意。Field的约束让非法请求在进入业务逻辑之前就被拦截减少了无效计算。异常处理区分了客户端错误和服务端错误调用方能据此决定是重试还是修参数。返回里带上延迟方便调用方和监控系统观察性能。4.3 模型加载策略启动时加载还是懒加载这是个容易被忽略但影响很大的选择。启动时加载的好处是第一个请求就很快坏处是服务启动慢而且如果模型加载失败整个服务起不来。懒加载的好处是启动快坏处是第一个请求特别慢而且并发场景下可能重复加载。我的经验是生产环境用启动时加载开发环境用懒加载。生产环境追求稳定和可预测启动慢一点没关系但要保证服务起来之后每个请求的延迟都稳定。开发环境追求快速迭代改完代码能立刻重启测试懒加载更合适。如果模型特别大启动加载确实太慢可以考虑用一个预热请求在服务启动后立即触发加载兼顾两者。5. 上线之后才是真正的考验监控与排错5.1 没有监控的AI服务等于裸奔我见过太多团队把服务部署上去就以为万事大吉直到用户投诉才发现已经挂了好几个小时。AI服务的监控比普通服务更复杂因为除了常规的CPU、内存、请求量还要关注模型层面的指标。至少要监控这几类。系统层CPU、内存、磁盘、网络这些是基础。服务层请求量、延迟分布不只是平均值要看P95、P99、错误率。模型层输入数据的分布有没有漂移、输出结果的分布有没有异常、有没有出现大量低置信度的预测。最后一类最容易被忽略但往往是模型效果下降的早期信号。5.2 日志怎么打才有用日志不是越多越好关键是在出问题时能快速定位。我的做法是每个请求打一条结构化日志包含请求ID、输入摘要、输出摘要、耗时、是否命中缓存、模型版本。请求ID用来串联一次请求经过的所有环节输入输出摘要用来复现问题模型版本用来确认是不是某次更新引入的问题。这里有个坑不要把完整输入输出都打进日志。一是日志量会爆炸二是可能涉及敏感信息。摘要就够了比如输入文本的长度、前若干字符、哈希值。真需要完整数据时用请求ID去专门的存储里查。5.3 一个真实的排错案例有次线上服务突然延迟飙升从平均50毫秒涨到2秒。看系统监控CPU和内存都正常看请求量也没有突增。最后查日志发现是某个特定类型的输入触发了模型里一条极慢的分支。这类问题在平均值上完全看不出来只有看延迟分布和按输入类型分组的统计才能发现。排查过程是这样的先确认不是系统资源问题再确认不是流量问题然后按输入特征分组统计延迟定位到问题输入类型最后在代码里找到那条分支。修复方案是给那条分支加超时和降级逻辑超时后返回一个默认结果而不是一直等。这个案例的教训是监控要能下钻到细分维度平均值会骗人。6. 从能跑到好用几个让工程质量上一个台阶的习惯6.1 配置与代码分离把数据库地址、模型路径、超时时间这些写死在代码里是新手最常见的坏习惯。一旦要换环境就得改代码重新部署极易出错。正确做法是全部抽到配置文件或环境变量里代码只读配置不写配置。这样同一份代码可以在开发、测试、生产环境用不同的配置跑部署流程也简单得多。6.2 为失败而设计AI系统里失败是常态模型可能加载失败、上游数据可能延迟、下游可能超时。好的工程不是避免所有失败而是让失败可控。具体来说关键路径要有超时超时要有降级方案降级方案要经过测试。我习惯给每个外部调用都设一个合理的超时并且想清楚超时之后返回什么——是返回缓存的老结果还是返回一个明确的错误还是走一个简化版的逻辑。这个决定要在写代码时就做而不是等出事了再补。6.3 自动化测试要覆盖数据和处理逻辑模型效果很难用单元测试断言但数据处理逻辑可以。字段解析、异常值处理、边界情况这些都应该有测试覆盖。我的做法是把测试分成两层一层测纯函数输入输出明确跑得飞快一层测端到端流程用一小批固定数据跑完整管道断言最终输出符合预期。前者在每次提交时跑后者在合并前跑。这样既能快速反馈又能保证整体不跑偏。6.4 文档写在代码旁边AI项目的人员流动往往比较快今天写的东西可能下周就换人维护。所以文档不是可选项。但我不建议写那种脱离代码的独立文档因为很快就会过时。更好的做法是把说明写在代码旁边——函数的docstring写清楚输入输出和边界条件模块顶部写清楚这个模块的职责和依赖配置文件里写清楚每个参数的含义和推荐值。这样改代码的时候顺手就更新了文档不容易脱节。7. 我在这条路上踩过的几个印象深刻的坑第一个坑是过早优化。刚搭好服务就想着怎么支持高并发引入了一堆中间件结果把系统搞得极其复杂一个简单问题要查半天。后来想明白了先让它跑起来等真有压力了再优化优化的方向也更明确。第二个坑是忽视数据校验。有次上游传过来一个空字符串模型直接抛异常整个请求失败。当时觉得是上游的问题后来意识到自己的代码也不够健壮。现在我会在入口处做严格校验非法输入直接拒绝并给出明确错误而不是让它流到深处再炸。第三个坑是监控指标选错。一开始只监控了平均延迟觉得挺正常直到用户投诉才发现P99延迟高得离谱。平均值被大量快速请求拉低了掩盖了慢请求的问题。从那以后我所有延迟监控都看分位数P50、P95、P99一起看。第四个坑是模型版本管理混乱。有次更新模型后效果变差想回滚却发现旧版本文件已经被覆盖了。现在我会保留最近几个版本的模型文件并且在服务里记录当前使用的版本号回滚就是改一个配置的事。这些坑说到底都指向同一个道理AI工程的核心竞争力不在模型有多先进而在整个系统有多可靠、多可维护。把工程基础打扎实模型迭代才有意义基础不牢再好的模型也发挥不出价值。