1. 从零搭建AI工程能力为什么大多数人卡在第一步就放弃了很多人对AI工程这四个字的理解还停留在调个API、写个提示词的阶段。我刚开始接触这个方向的时候也是这么想的觉得无非就是拿现成的模型接口拼拼凑凑能跑通一个问答机器人就算入门了。但真正动手做一个完整的AI工程项目之后才发现从零到一构建一套可用的AI工程能力涉及的东西远比想象中多——数据处理、模型选型、推理部署、性能调优、成本控制、监控运维每一个环节都有坑而且这些坑往往不是靠看几篇教程就能绕过去的。ai-engineering-from-scratch这个主题之所以值得认真聊是因为它代表了一种从底层理解AI工程全链路的思路。不是教你调哪个API最方便也不是推荐哪个框架最流行而是帮你建立一套完整的认知框架一个AI系统从原始数据到最终服务中间到底经历了什么每个环节的核心问题是什么有哪些常见的方案和取舍。这套认知框架一旦建立起来后面无论你用的是哪个模型、哪个框架、哪个云平台都能快速上手因为底层逻辑是相通的。这篇文章适合几类人看一是刚入行不久、想系统了解AI工程全貌的开发者二是有一定后端或数据工程经验、想转型做AI应用但不知道从哪下手的工程师三是已经在做AI相关项目、但总觉得东拼西凑不成体系的从业者。我会尽量用大白话把每个环节讲清楚同时给出可以直接参考的实操方案和参数配置让你看完之后能自己动手搭一个最小可用的AI工程流水线。需要提前说明的是AI工程这个领域变化非常快具体的工具和框架可能半年就换一波但这篇文章重点讲的是那些不太会变的东西——数据怎么处理、模型怎么选、服务怎么部署、效果怎么评估。这些底层能力才是真正值得花时间打磨的。2. 动手之前先想清楚AI工程到底在工程什么2.1 拆解一个AI系统的完整生命周期很多人一上来就开始写代码、调接口结果做到一半发现数据格式不对、模型效果不行、部署上去延迟太高然后推倒重来。这种情况太常见了根本原因是没有在动手之前把AI系统的完整生命周期想清楚。一个典型的AI系统从零到上线再到持续迭代大致会经历这么几个阶段问题定义与可行性评估、数据采集与清洗、特征工程与数据预处理、模型选型与训练/微调、评估与验证、部署与推理优化、监控与迭代。每个阶段都有明确的输入和输出上一个阶段的输出就是下一个阶段的输入环环相扣。问题定义阶段最容易被忽视但它恰恰是最重要的。你需要明确这个AI系统要解决什么具体问题成功的标准是什么是准确率要达到多少还是响应时间要控制在多少毫秒以内这些问题不想清楚后面所有的技术决策都没有依据。我见过太多项目做到一半才发现业务方真正想要的不是模型精度而是低延迟结果之前选的模型太大根本部署不上去。数据采集与清洗阶段核心问题是数据从哪来、质量怎么样、够不够用。AI工程和传统软件工程最大的区别就在这里——传统软件工程的输入是确定的而AI系统的输入是数据数据的质量直接决定了系统的上限。这个阶段通常要花掉整个项目60%以上的时间而且很多时候你会发现公开数据集和真实业务数据之间的差距大到让人崩溃。2.2 为什么从零开始反而比调包更快有人可能会问现在这么多现成的框架和平台为什么还要从零开始搭建直接用不行吗短期来看调包确实快。但长期来看从零搭建一遍能让你真正理解每个环节在做什么出了问题知道去哪里找原因。举个例子你用现成的框架部署了一个模型服务突然发现推理延迟从50毫秒涨到了500毫秒如果你不了解底层的推理流程你根本不知道是模型加载的问题、批处理策略的问题还是网络传输的问题。但如果你自己从零搭过一遍你就知道每个环节的耗时大概是多少能快速定位瓶颈。而且从零搭建并不意味着所有东西都自己写。该用的轮子还是要用但你要知道这个轮子是怎么转的什么时候该换一个轮子什么时候该自己造一个轮子。这才是from scratch的真正含义——不是拒绝工具而是理解工具。2.3 最小可行AI工程流水线的构成如果你现在就想动手我建议先搭一个最小可行的流水线包含四个核心模块数据处理模块、模型推理模块、服务接口模块、日志监控模块。这四个模块跑通了你就有了一个可以持续迭代的基础。数据处理模块负责把原始数据转换成模型能吃的格式模型推理模块负责加载模型并执行推理服务接口模块负责对外提供API日志监控模块负责记录每次请求的输入输出和耗时。这四个模块之间的接口要定义清楚后面换模型、换框架的时候只需要替换对应的模块就行不会牵一发而动全身。具体的目录结构可以这样组织ai-pipeline/ ├── data/ │ ├── raw/ # 原始数据 │ ├── processed/ # 清洗后的数据 │ └── features/ # 特征数据 ├── models/ │ ├── configs/ # 模型配置 │ └── weights/ # 模型权重 ├── src/ │ ├── data_processor.py │ ├── model_server.py │ ├── api.py │ └── monitor.py ├── tests/ ├── requirements.txt └── README.md这个结构看起来简单但已经足够支撑一个中小型AI应用的开发和迭代了。关键是每个模块的职责要单一接口要清晰。3. 数据管道搭建从原始数据到模型可用的输入3.1 数据清洗中最容易被低估的三个问题数据清洗这件事说起来简单做起来全是坑。我总结了三个最容易被低估的问题每一个都足以让项目延期。第一个是编码问题。中文数据里混杂着UTF-8、GBK、GB2312各种编码还有全角半角混用、特殊符号乱码。如果你不做统一处理后面模型训练的时候会莫名其妙报错而且报错信息往往指向不到真正的原因。我的做法是在数据加载的第一时间就统一转成UTF-8并且用正则把不可见字符全部过滤掉。第二个是重复数据。很多人觉得重复数据顶多浪费一点存储空间但实际上重复数据对模型训练的影响很大——它会让模型对某些样本过拟合导致在实际使用中表现不稳定。去重不能只看完全相同的文本还要考虑近似重复。我通常用SimHash或者MinHash做近似去重阈值设在0.85左右比较合适。第三个是标签噪声。如果是监督学习任务标签的质量直接决定了模型的上限。但真实场景下的标签往往是有噪声的可能是人工标注的误差也可能是规则生成的偏差。处理标签噪声没有银弹我的经验是先用交叉验证找出那些模型预测和标签严重不一致的样本人工检查一批看看是标签错了还是模型没学好。3.2 特征工程在深度学习时代还有没有必要这个问题争议很大。有一种观点认为深度学习时代特征工程已经不重要了模型自己会学到好的特征表示。但我的实际经验是特征工程依然重要只是形式变了。传统的特征工程是人工设计特征比如文本分类任务里手动构造TF-IDF、N-gram这些特征。深度学习时代这些底层特征确实可以交给模型自动学习但领域知识的注入依然离不开特征工程。举个例子如果你做一个电商评论的情感分析把物流速度、包装质量、客服态度这些维度拆出来作为辅助特征模型的效果会明显好于直接把整段文本丢进去。我的建议是底层特征交给模型高层语义特征靠人工设计。具体来说可以用预训练模型提取文本的向量表示作为基础特征然后在此基础上拼接一些业务相关的统计特征比如文本长度、特殊符号比例、关键词命中情况等。这些特征计算成本低但对模型效果的提升往往很明显。3.3 数据版本管理与可复现性保障数据版本管理是AI工程里最容易被忽视、但出问题后最头疼的环节。你训练了一个效果很好的模型过了一个月想复现结果发现数据已经变了怎么都复现不出来。这种情况我遇到过不止一次。解决方案是引入数据版本管理工具比如DVCData Version Control。它的核心思路是用Git管理代码用DVC管理数据和模型文件每次数据变更都生成一个版本号训练的时候记录用的是哪个版本的数据。这样任何时候都能回溯到具体的训练数据。具体操作上DVC的配置文件大概长这样# dvc.yaml stages: prepare: cmd: python src/data_processor.py deps: - data/raw/ - src/data_processor.py outs: - data/processed/ train: cmd: python src/train.py deps: - data/processed/ - src/train.py outs: - models/weights/ metrics: - metrics.json这样每次运行dvc reproDVC会自动检查依赖是否变化只重新执行变化的部分。训练完成后dvc push把数据和模型推到远程存储git commit记录版本信息。后面要复现的时候git checkout到对应的commitdvc pull拉取数据就能完全复现当时的训练环境。注意DVC的远程存储建议用对象存储服务不要直接放在Git仓库里否则仓库会变得非常大克隆速度极慢。4. 模型选型与推理优化在效果和成本之间找平衡4.1 选大模型还是小模型先算一笔账模型选型是AI工程里最纠结的决策之一。大模型效果好但推理成本高、延迟大小模型成本低、速度快但效果可能不够。怎么选我的建议是先算一笔账。假设你有一个文本分类任务候选方案有两个方案A用70亿参数的大模型准确率95%单次推理耗时200毫秒方案B用1亿参数的小模型准确率90%单次推理耗时20毫秒。表面上看方案A更好但你要考虑你的业务能接受200毫秒的延迟吗你的日均请求量是多少如果日均请求量是100万次方案A每天需要多少算力成本我通常用这个公式来估算日均推理成本 日均请求量 × 单次推理算力消耗 × 单位算力价格单次推理算力消耗和模型参数量、输入长度都相关。粗略估算的话70亿参数模型单次推理的算力消耗大约是1亿参数模型的10到20倍。如果单位算力价格是固定的方案A的成本可能是方案B的10倍以上。这时候就要问5个百分点的准确率提升值不值10倍的成本很多时候答案是不值的。特别是当你的业务对准确率的要求不是那么极致的时候小模型加上一些工程优化完全能达到可用的水平。4.2 量化、蒸馏、剪枝三种压缩手段的适用场景如果你确定要用大模型但又想控制成本那就要考虑模型压缩。主流的压缩手段有三种量化、蒸馏、剪枝。它们各有适用场景不能混为一谈。量化是把模型参数从高精度浮点数比如FP32转换成低精度格式比如INT8。这样做的好处是模型体积减小、推理速度提升而且精度损失通常很小。我实测下来INT8量化对大多数模型的效果影响在1个百分点以内但推理速度能提升2到3倍。量化的缺点是有些模型对量化比较敏感特别是那些参数量本来就小的模型量化后效果下降可能比较明显。蒸馏是用一个大模型教师模型去教一个小模型学生模型。学生模型学习教师模型的输出分布而不仅仅是硬标签。这样学生模型能学到教师模型的一些暗知识效果通常比直接训练的小模型好。蒸馏的缺点是训练过程比较复杂需要同时加载教师和学生两个模型对显存要求比较高。剪枝是去掉模型中不重要的参数或结构。结构化剪枝可以直接减少模型的层数或通道数非结构化剪枝则是把不重要的权重置零。剪枝的难点在于如何判断哪些参数不重要而且剪枝后通常需要重新训练来恢复效果。我的建议是优先考虑量化效果不够再考虑蒸馏剪枝作为最后的手段。量化实现简单、收益明确是性价比最高的方案。4.3 批处理与缓存策略对推理延迟的实际影响推理延迟的优化除了模型本身工程层面的策略也很重要。两个最有效的手段是批处理和缓存。批处理是把多个请求合并成一个批次一起推理。GPU的并行计算能力很强单次推理一个样本和单次推理32个样本的耗时差距并不大。所以如果你的服务能接受一定的等待时间把请求攒一攒再一起推理吞吐量能提升好几倍。具体的批处理大小要根据GPU显存和延迟要求来定我通常从8开始试逐步增加到32或64观察延迟和吞吐量的变化。缓存则是把常见的请求结果存起来下次遇到相同的请求直接返回。缓存的命中率取决于你的业务场景如果是问答类应用用户问的问题重复率可能不高但如果是分类任务类别是有限的缓存命中率会很高。缓存可以用内存数据库来实现设置合理的过期时间避免返回过时的结果。这两个策略结合起来能把推理成本降低一个数量级。我做过一个测试同样的模型和硬件不加批处理和缓存的情况下QPS是50加上之后能到500以上。5. 服务化部署让模型真正跑起来的关键环节5.1 从脚本到服务中间差了哪些东西把模型训练好只是第一步让它变成一个稳定可用的服务中间还有很长的路要走。我见过太多项目模型在notebook里跑得好好的一上线就各种问题。从脚本到服务至少要补齐这些东西接口定义、错误处理、并发控制、资源管理、健康检查。接口定义决定了服务怎么被调用是RESTful API还是gRPC输入输出的格式是什么。错误处理要覆盖各种异常情况比如输入格式不对、模型加载失败、推理超时等。并发控制要防止同时太多请求把服务打挂。资源管理要确保内存和显存不会泄漏。健康检查让运维系统能知道服务是否正常。这些东西听起来都是常规的软件工程实践但在AI服务里有一些特殊之处。比如错误处理AI服务的错误往往不是非黑即白的模型可能返回一个低置信度的结果这时候是返回结果还是报错我的做法是返回结果但在响应里带上置信度让调用方自己决定怎么处理。5.2 用FastAPI搭建推理服务的完整配置FastAPI是目前搭建推理服务比较顺手的选择性能好、异步支持完善、自动生成API文档。下面是一个完整的配置示例from fastapi import FastAPI, HTTPException from pydantic import BaseModel import torch import time import logging app FastAPI(titleAI Inference Service) logger logging.getLogger(__name__) class InferenceRequest(BaseModel): text: str max_length: int 512 class InferenceResponse(BaseModel): result: str confidence: float latency_ms: float model None tokenizer None app.on_event(startup) async def load_model(): global model, tokenizer # 模型加载逻辑 logger.info(Model loaded successfully) app.post(/predict, response_modelInferenceResponse) async def predict(request: InferenceRequest): start_time time.time() try: # 预处理 inputs tokenizer(request.text, return_tensorspt, max_lengthrequest.max_length, truncationTrue) # 推理 with torch.no_grad(): outputs model(**inputs) # 后处理 result process_output(outputs) latency (time.time() - start_time) * 1000 return InferenceResponse( resultresult[label], confidenceresult[score], latency_mslatency ) except Exception as e: logger.error(fInference failed: {str(e)}) raise HTTPException(status_code500, detailInference failed) app.get(/health) async def health_check(): return {status: healthy, model_loaded: model is not None}这个配置里有几个关键点模型在启动时加载避免每次请求都重新加载推理过程用torch.no_grad()关闭梯度计算减少内存占用每次请求记录延迟方便后续监控健康检查接口让运维系统能感知服务状态。5.3 容器化部署与资源限制的实操细节服务写好了下一步是容器化部署。Dockerfile的编写有一些细节需要注意FROM python:3.10-slim WORKDIR /app # 先复制依赖文件利用Docker缓存 COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt # 再复制代码 COPY src/ ./src/ COPY models/ ./models/ # 设置环境变量 ENV MODEL_PATH/app/models/weights ENV MAX_WORKERS4 EXPOSE 8000 CMD [uvicorn, src.api:app, --host, 0.0.0.0, --port, 8000, --workers, 1]这里有几个经验点依赖安装和代码复制分开这样改代码的时候不用重新安装依赖构建速度快很多workers设置为1因为模型加载很占内存多个worker会导致内存成倍增长并发靠异步来处理资源限制在运行容器时通过--memory和--gpus参数来控制避免单个容器占满整台机器。如果用的是GPU还需要注意CUDA版本和驱动版本的兼容性。我踩过的坑是宿主机驱动版本比较老但Docker镜像里的CUDA版本比较新结果容器启动时报错。解决办法是确保镜像的CUDA版本不高于宿主机驱动支持的版本。6. 效果评估与持续迭代上线只是开始6.1 离线指标好看线上效果差问题出在哪离线评估指标很好上线后效果却很差这是AI工程里最经典的问题之一。原因通常有几个数据分布不一致、评估指标和业务目标不匹配、线上环境有离线没有的干扰因素。数据分布不一致是最常见的原因。离线评估用的测试集是从训练数据里切出来的和训练数据同分布。但线上请求的数据分布可能完全不同比如用户输入的长度、用词习惯、甚至语言都可能不一样。解决办法是定期用线上数据更新测试集确保评估结果能反映真实情况。评估指标和业务目标不匹配也很常见。比如你优化的是准确率但业务方真正关心的是召回率——漏掉一个正例的代价远大于误判一个负例。这时候就要调整评估指标或者用加权的方式把业务目标融入到评估里。线上环境特有的干扰因素包括网络延迟、并发竞争、硬件差异等。这些在离线评估里是体现不出来的只能通过线上监控来发现。6.2 建立有效的线上监控指标体系线上监控不能只看准确率要建立一套完整的指标体系。我通常把指标分成四层层级指标说明业务层转化率、满意度最终的业务效果应用层准确率、召回率、F1模型的实际表现服务层QPS、延迟、错误率服务的运行状态资源层CPU、内存、GPU利用率底层资源消耗这四层指标要联动来看。比如业务层指标下降可能是应用层模型效果变差了也可能是服务层延迟太高导致用户流失还可能是资源层瓶颈导致服务不稳定。只有四层指标都监控到位才能快速定位问题。监控工具的选择上Prometheus加Grafana是比较成熟的方案。Prometheus负责采集和存储指标Grafana负责可视化。模型相关的指标可以通过在推理服务里埋点暴露成Prometheus格式的接口。6.3 模型迭代的节奏把控与回滚机制模型迭代不是越频繁越好。每次迭代都有风险新模型可能在某些场景下表现不如旧模型。我的经验是小步快跑但要有回滚机制。具体做法是新模型上线前先做A/B测试把一小部分流量切到新模型对比新旧模型的关键指标。如果新模型在统计上显著优于旧模型再逐步扩大流量比例。如果新模型表现不如预期立即回滚到旧模型。回滚机制要提前准备好不能等出了问题再临时想办法。我的做法是保留最近三个版本的模型文件服务启动时通过配置指定用哪个版本。回滚的时候只需要改配置、重启服务几分钟就能完成。A/B测试的流量比例建议从5%开始观察至少一天再决定是否扩大。如果业务对稳定性要求极高可以从1%开始观察一周。关键是样本量要足够否则统计上不显著做了等于没做。7. 踩过的坑与实战心得7.1 那些让我熬夜排查的典型问题做AI工程这几年踩过的坑数不胜数挑几个印象最深的说说。第一个坑是内存泄漏。服务跑了一段时间后内存持续增长最后OOM崩溃。排查了很久才发现是每次推理都创建了新的tokenizer对象没有复用。tokenizer的创建开销不大但频繁创建会导致内存碎片化最终触发OOM。解决办法是把tokenizer和模型一样在启动时加载一次全局复用。第二个坑是批处理导致的延迟毛刺。为了提高吞吐量加了批处理结果发现P99延迟飙升。原因是批处理会等待凑够一个批次再推理如果请求量不稳定有些请求会等很久。解决办法是设置最大等待时间比如10毫秒超过这个时间即使批次没满也立即推理。第三个坑是模型版本和代码版本不匹配。代码更新了预处理逻辑但模型还是用旧逻辑训练的导致效果下降。解决办法是把预处理逻辑和模型绑定在一起模型文件里记录预处理配置加载模型时自动应用对应的预处理逻辑。7.2 成本控制的几个实用技巧AI工程的成本大头在算力。控制成本有几个实用技巧按需伸缩。如果请求量有明显的波峰波谷可以用自动伸缩策略高峰期多开实例低谷期减少实例。Kubernetes的HPAHorizontal Pod Autoscaler可以根据CPU或自定义指标自动调整实例数。混合精度推理。用FP16代替FP32做推理显存占用减半速度提升30%以上精度损失通常可以忽略。大多数推理框架都支持混合精度开启方式也很简单。模型分级。不是所有请求都需要用大模型。可以把请求分成简单和复杂两类简单请求用小模型处理复杂请求才用大模型。这样能大幅降低平均成本。缓存策略优化。前面提到过缓存这里补充一点缓存的粒度要合适。太粗会导致命中率低太细会导致缓存膨胀。我的经验是按请求的语义特征做缓存键而不是简单的文本哈希。7.3 给刚入行朋友的三条建议最后给刚入行AI工程的朋友三条建议。第一先把一个完整的流水线跑通再追求每个环节的极致。很多人一上来就研究最新的模型架构、最先进的推理框架结果连一个完整的服务都搭不起来。先把数据、模型、服务、监控这条链路跑通哪怕用的都是最简单的方案也比半途而废强。第二重视工程能力不要只盯着模型。AI工程的核心竞争力不在于你会不会调某个模型的参数而在于你能不能把模型变成一个稳定、高效、可维护的服务。这需要扎实的软件工程功底包括代码组织、测试、部署、监控等。第三保持学习但不要盲目追新。AI领域每天都有新东西出来但底层的东西变化没那么快。把数据处理、模型评估、服务部署这些基础打牢新工具出来的时候你只需要花很少的时间就能上手。反过来如果基础不牢追再多新工具也只是浮于表面。我在实际项目中的体会是AI工程最难的不是某个技术点而是把各个技术点串起来形成一个能持续运转的系统。这个过程需要不断踩坑、不断调整但一旦跑通了后面的事情就会顺很多。