1. 从零搭建AI工程能力为什么我劝你别一上来就调包这两年“AI工程”这个词被说得太多了多到有点变味。打开任何一个技术社区满屏都是“三行代码调用大模型”“十分钟搭建RAG应用”“零基础转型AI工程师”。我不否认这些内容有它的价值但如果你真的想在这个方向上站稳脚跟光会调API是远远不够的。ai-engineering-from-scratch这个标题之所以值得认真聊是因为它指向了一条更笨、更慢、但走得更远的路——从底层开始把AI工程当成一门工程学科来对待而不是当成一堆现成工具的拼装游戏。我自己在这个方向上摸索了相当长一段时间踩过的坑不算少。最开始我也是那种“能跑就行”的心态觉得模型是别人训好的框架是别人写好的我只要把接口串起来就完事了。直到有一次线上服务出了个诡异的问题推理延迟突然飙升日志里没有任何报错监控指标也看不出异常。排查了大半天才发现是某个批处理环节的padding策略在特定输入分布下导致了显存碎片化。这个问题如果我不了解推理引擎的基本工作原理根本不可能定位到。从那以后我就明白了一件事AI工程的核心竞争力不在于你会用多少工具而在于你对整个链路的理解深度。这篇文章想做的事情很明确把“从零构建AI工程能力”这件事拆开揉碎讲清楚每个环节到底在做什么、为什么这么做、以及实际操作中会遇到什么。适合的读者是那些不满足于只做“调包侠”、愿意花时间打地基的人。不管你是刚入行的新人还是从后端/数据方向转过来的老手只要你对AI系统的完整生命周期有好奇心这里的内容应该都能给你一些参考。2. 整体设计思路为什么“从零”才是最快的路径2.1 先搞清楚“AI工程”到底涵盖什么很多人对AI工程的理解停留在“训练模型”或者“调用模型”这个层面但实际上这只是冰山一角。一个完整的AI工程体系至少包含以下几个层面数据层数据的采集、清洗、标注、版本管理、特征工程。这一层决定了模型能力的上限但往往被严重低估。模型层模型选型、训练、微调、评估、压缩。这一层是大家最关注的但它的复杂度其实在于实验管理和可复现性。推理层模型部署、推理优化、批处理策略、硬件适配。这一层直接决定了线上服务的成本和体验。服务层API设计、流量管理、降级策略、监控告警。这一层是AI系统与业务系统之间的桥梁。迭代层效果追踪、数据回流、持续训练、A/B测试。这一层决定了系统能不能随着时间推移越来越好。“从零构建”的意思不是让你每个环节都自己造轮子而是让你理解每个环节的核心问题是什么然后知道在什么场景下该用什么工具去解决。这就像学编程不是从学IDE开始的而是从理解变量、循环、函数这些基本概念开始的。2.2 为什么跳过基础直接调包会出问题我见过太多这样的案例用LangChain搭了一个看起来很不错的问答系统demo跑得很流畅一上线就崩。崩的原因五花八门——有的是prompt在真实输入下触发了模型的奇怪行为有的是检索环节的召回质量太差导致回答胡编乱造有的是并发一上来推理服务直接OOM。这些问题的根源都是一样的你不知道你的系统在哪个环节是脆弱的因为你没有亲手构建过那些环节。调包的好处是快坏处是你失去了对系统的掌控感。当系统按照预期运行时一切都很美好当系统出问题时你连从哪里开始排查都不知道。从零构建的路径虽然慢但它给你的是可迁移的能力。工具会变框架会迭代但底层的工程思维和问题拆解能力是相对稳定的。你理解了注意力的计算过程再看任何Transformer变体都不会慌你亲手实现过推理的批处理逻辑再遇到延迟问题就知道该往哪个方向查。2.3 分阶段推进的路线设计基于上面的思路我把从零构建AI工程能力的路线分成四个阶段每个阶段有明确的目标和产出阶段核心目标关键产出建议投入基础夯实理解核心原理手写关键算法4-6周工程化实践掌握工具链完整训练流水线6-8周推理优化理解部署细节高性能推理服务4-6周系统集成端到端交付可迭代的AI系统持续这个路线不是线性的很多环节需要反复来回。比如你在做推理优化的时候可能会发现需要回头调整训练时的某些配置。这种反复本身就是工程实践的一部分。3. 核心细节解析每个环节的关键决策点3.1 数据环节最容易被跳过但最重要数据环节的核心问题不是“怎么处理数据”而是“怎么保证数据的质量和可复现性”。我见过太多项目在数据管理上偷懒最后导致模型效果无法复现、问题无法追溯。数据版本管理是第一个关键决策点。你不需要一上来就上DVC或者LakeFS这种专业工具但至少要做到每次训练用的数据都能追溯到具体的版本。最简单的做法是用时间戳哈希值给每次数据快照打标签然后在训练配置里记录这个标签。这个习惯看起来不起眼但当你在两个月后发现模型效果下降需要回滚时它会救你的命。数据清洗的策略也很讲究。很多人喜欢写一个“万能清洗脚本”把所有能想到的过滤规则都塞进去。这种做法的问题是你不知道每条规则到底过滤掉了什么也不知道过滤掉的数据里有没有有价值的信息。我的建议是分步骤清洗每步都记录统计信息。比如先去重记录去掉了多少再过滤异常长度记录分布变化最后做质量筛选保留样本供人工抽查。实操心得数据清洗的每一步都要保留“清洗前”和“清洗后”的对比样本至少几百条。这些样本在后续排查问题时非常有用能帮你快速判断是数据问题还是模型问题。标注质量的控制是另一个容易被忽视的点。如果你用的是公开数据集至少要做一轮抽样检查看看标注的一致性如何。如果是自己标注一定要有交叉验证机制——同一个样本至少两个人标计算一致率。一致率低于80%的类别要么重新定义标注规范要么考虑放弃这个类别。3.2 模型训练实验管理比模型本身更重要训练环节最大的坑不是模型不收敛而是实验无法复现。你跑了一个实验效果很好但过了一周想再跑一遍发现怎么都跑不出同样的结果。这种情况在AI工程中太常见了原因通常是随机种子没固定、依赖版本变了、数据版本对不上。实验管理的最小可行方案其实很简单每次实验都记录以下信息——代码版本git commit hash、数据版本、超参数配置、环境依赖requirements.txt的哈希、随机种子、硬件信息。这些信息用一个JSON文件存下来跟模型checkpoint放在一起。不需要什么高级工具一个脚本就能搞定。超参数搜索的策略也值得聊一聊。很多人一上来就用贝叶斯优化或者遗传算法觉得越高级越好。但实际上对于大多数场景随机搜索手动调参的组合性价比最高。先随机搜一批看看哪些参数组合有潜力然后围绕有潜力的区域手动微调。这样既不会陷入局部最优也不会浪费太多计算资源。训练过程中的监控不能只看loss曲线。我建议至少监控以下几个指标梯度范数判断是否梯度爆炸/消失、学习率变化、显存占用、每个epoch的验证集指标。这些指标能帮你提前发现很多问题而不是等到训练完了才发现效果不对。# 一个简单的实验记录示例 import json import hashlib import subprocess def record_experiment(config, data_version, metrics): experiment_info { git_commit: subprocess.check_output( [git, rev-parse, HEAD] ).decode().strip(), data_version: data_version, config: config, config_hash: hashlib.md5( json.dumps(config, sort_keysTrue).encode() ).hexdigest(), metrics: metrics, timestamp: datetime.now().isoformat() } with open(fexperiments/{experiment_info[config_hash]}.json, w) as f: json.dump(experiment_info, f, indent2)3.3 推理部署延迟和成本的平衡艺术推理部署是AI工程中最考验工程能力的环节。你需要在延迟、吞吐、成本、准确性之间找到平衡点而这个平衡点会随着业务需求的变化而变化。批处理策略是第一个要解决的问题。动态批处理dynamic batching能显著提升吞吐但会增加延迟。你需要根据业务场景来决定批处理窗口的大小。如果是实时交互场景窗口可能只有几毫秒如果是离线处理场景窗口可以到几百毫秒甚至更长。模型量化是降低成本的有效手段但要注意量化的精度损失。我的一般建议是先做FP16量化这个几乎无损如果还不够再考虑INT8但一定要做充分的评估确保关键指标没有明显下降。INT4要非常谨慎除非你的场景对精度要求不高。显存管理是另一个关键点。推理服务的显存占用不只是模型权重还包括激活值、KV Cache、临时缓冲区等。你需要根据实际的输入长度分布来估算显存需求。一个实用的技巧是限制最大输入长度超过这个长度的请求直接拒绝或者截断。这看起来粗暴但能有效防止OOM。优化手段延迟影响吞吐影响精度影响适用场景动态批处理增加显著提升无高并发场景FP16量化降低提升极小几乎所有场景INT8量化降低提升较小对精度不敏感场景KV Cache降低提升无自回归生成模型蒸馏降低提升中等有充足训练资源注意事项量化后的模型一定要做充分的回归测试不能只看几个样例就上线。我见过INT8量化后在某些特定输入下输出完全乱掉的情况这种问题在常规测试中很难发现。3.4 服务层设计让AI系统真正可用服务层是AI系统与业务系统的接口它的设计质量直接决定了AI能力能不能被业务方顺畅地使用。API设计要遵循“简单但不简陋”的原则。输入输出格式要清晰错误码要规范超时和重试策略要明确。我建议至少提供两个接口一个同步接口用于实时场景一个异步接口用于批量处理场景。同步接口要有严格的超时控制异步接口要有任务状态查询。降级策略是很多AI系统缺失的部分。当模型服务不可用时系统应该能自动降级到规则引擎或者缓存结果而不是直接报错。降级策略的设计要考虑业务影响——有些场景可以接受降级有些场景宁可报错也不能给错误结果。监控告警要覆盖几个关键维度请求量、延迟分布不只是平均值要看P99、错误率、模型输出分布检测数据漂移。特别是输出分布监控能帮你提前发现模型退化的问题。4. 实操过程从零搭建一个完整的AI工程流水线4.1 环境准备与工具选型在开始动手之前先把环境搭好。我的建议是用容器化环境不要直接在宿主机上装一堆依赖。Docker加上一个基础的CUDA镜像就能满足大部分需求。工具选型的原则是核心环节用成熟工具边缘环节可以自己写。比如训练框架用PyTorch推理引擎用TensorRT或者vLLM这些是核心环节用成熟工具能省很多事。但数据清洗、实验管理这些边缘环节自己写脚本反而更灵活。# 基础环境搭建示例 docker run -it --gpus all \ -v $(pwd):/workspace \ -p 8888:8888 \ pytorch/pytorch:2.1.0-cuda12.1-cudnn8-devel # 安装常用依赖 pip install transformers datasets accelerate pip install wandb tensorboard pip install fastapi uvicorn4.2 数据流水线的搭建数据流水线的核心目标是可复现、可追溯、可扩展。我一般会把它分成三个独立的模块采集、清洗、版本化。采集模块负责从各种来源拉取原始数据输出统一的格式。清洗模块负责去重、过滤、格式化。版本化模块负责给每次数据变更打标签并维护版本之间的差异。# 数据版本化的简单实现 import hashlib import json from pathlib import Path class DataVersioner: def __init__(self, data_dir): self.data_dir Path(data_dir) self.versions_file self.data_dir / versions.json def compute_hash(self, file_path): hasher hashlib.sha256() with open(file_path, rb) as f: for chunk in iter(lambda: f.read(8192), b): hasher.update(chunk) return hasher.hexdigest()[:12] def create_version(self, description): files sorted(self.data_dir.glob(*.jsonl)) file_hashes { f.name: self.compute_hash(f) for f in files } version_id hashlib.md5( json.dumps(file_hashes, sort_keysTrue).encode() ).hexdigest()[:8] versions self._load_versions() versions[version_id] { description: description, files: file_hashes, timestamp: datetime.now().isoformat() } self._save_versions(versions) return version_id4.3 训练流水线的关键配置训练流水线的搭建要围绕“快速实验”这个目标。我的一般做法是配置与代码分离用YAML管理超参数用命令行参数覆盖关键配置。这样既能保证实验的可复现性又能灵活调整。# config/train_config.yaml model: name: bert-base-chinese max_length: 256 num_labels: 10 training: batch_size: 32 learning_rate: 2e-5 epochs: 5 warmup_ratio: 0.1 weight_decay: 0.01 gradient_accumulation_steps: 2 data: train_file: data/train.jsonl eval_file: data/eval.jsonl version: abc123 logging: project: my-ai-project log_interval: 50 eval_interval: 200训练脚本要支持断点续训和自动评估。断点续训能帮你省下大量时间特别是在训练大模型的时候。自动评估能让你在训练过程中就了解模型效果不用等训练完了再跑评估。4.4 推理服务的部署与优化推理服务的部署我推荐用FastAPI vLLM的组合。FastAPI负责HTTP接口vLLM负责推理引擎。这个组合的优点是部署简单、性能不错、社区活跃。# 推理服务示例 from fastapi import FastAPI, HTTPException from pydantic import BaseModel from vllm import LLM, SamplingParams app FastAPI() llm LLM(modelmeta-llama/Llama-2-7b-chat-hf) class GenerateRequest(BaseModel): prompt: str max_tokens: int 256 temperature: float 0.7 app.post(/generate) async def generate(request: GenerateRequest): try: sampling_params SamplingParams( max_tokensrequest.max_tokens, temperaturerequest.temperature ) outputs llm.generate([request.prompt], sampling_params) return {text: outputs[0].outputs[0].text} except Exception as e: raise HTTPException(status_code500, detailstr(e))部署的时候要注意几个参数gpu_memory_utilization控制显存使用比例max_num_seqs控制最大并发数max_model_len控制最大输入长度。这些参数需要根据实际硬件和业务需求来调整。4.5 监控与迭代机制的建立监控体系要覆盖三个层面系统层、模型层、业务层。系统层监控CPU、内存、GPU、网络等基础指标。模型层监控推理延迟、吞吐、错误率、输出分布。业务层监控用户反馈、转化率等业务指标。迭代机制的核心是数据回流。把线上服务的输入输出记录下来定期筛选出低质量的结果人工标注后加入训练数据。这个闭环建立起来之后系统就能持续进化。实操心得数据回流不要什么都收要有选择。我一般只回流两类数据模型置信度低的样本以及用户明确反馈有问题的样本。这样既能保证数据质量又不会让标注成本失控。5. 常见问题与排查技巧实录5.1 训练不收敛的排查思路训练不收敛是最常见的问题但排查起来其实有章可循。我一般按照以下顺序排查检查数据先看几条训练样本确认输入输出格式正确。我遇到过标签错位、tokenizer不匹配、padding方向搞反等各种数据问题。检查学习率学习率太大导致loss震荡太小导致loss下降缓慢。可以先用一个很小的学习率跑几百步看loss是否稳定下降。检查梯度打印梯度范数如果梯度范数持续为0或者爆炸说明网络结构或者初始化有问题。检查损失函数确认损失函数的实现是否正确特别是自定义损失函数的时候。5.2 推理延迟突然飙升的定位方法推理延迟飙升的原因可能有很多我一般按照以下流程定位排查步骤检查内容可能原因第一步输入长度分布长输入导致计算量增加第二步批处理队列队列积压导致等待时间增加第三步GPU利用率显存不足导致频繁换页第四步网络延迟服务间通信出现问题第五步模型版本新版本模型计算量增加5.3 模型效果下降的排查清单模型效果下降通常不是突然发生的而是逐渐累积的。我整理了一个排查清单数据漂移线上输入分布与训练数据分布差异变大。可以通过监控输入特征的统计量来检测。模型退化模型在持续训练过程中出现了灾难性遗忘。可以通过定期在固定测试集上评估来检测。服务问题推理服务的某些配置变化影响了输出质量。比如量化精度、批处理策略等。评估偏差评估指标本身出了问题比如测试集泄露、评估脚本bug等。5.4 显存不足的应急处理显存不足是推理服务最常见的紧急问题。应急处理的手段有降低批处理大小最直接有效但会影响吞吐。限制最大输入长度拒绝超长请求保护服务稳定性。启用梯度检查点如果是训练场景可以用时间换空间。使用CPU offload把部分层放到CPU上但会显著增加延迟。注意事项显存不足的应急处理只是临时方案根本解决还是要从模型大小、量化策略、硬件配置等方面入手。我见过太多团队一直在打补丁从来不解决根本问题最后技术债越积越多。5.5 一些踩过的坑和对应的解决方案坑一tokenizer不一致。训练用的tokenizer和推理用的tokenizer版本不一致导致输出完全乱掉。解决方案是把tokenizer文件和模型权重一起保存加载时从同一个目录读取。坑二随机种子没固定。同一个实验跑两次结果不一样排查了半天才发现是数据加载的shuffle没有固定种子。解决方案是在训练脚本开头固定所有随机种子包括Python、NumPy、PyTorch的。坑三评估指标计算错误。用了一个有bug的评估脚本导致模型选择完全错误。解决方案是对评估脚本做单元测试用已知答案的样例验证评估结果的正确性。坑四依赖版本冲突。本地跑得好好的部署到服务器上就报错。解决方案是用容器化部署把依赖版本固化在镜像里。坑五日志信息不足。线上出问题了但日志里什么有用信息都没有。解决方案是在关键路径上打足够的日志包括输入输出、中间结果、耗时统计等。6. 工具链选型与效率提升6.1 训练框架的选择逻辑训练框架的选择要考虑几个因素社区活跃度、文档质量、硬件支持、团队熟悉度。PyTorch目前是综合最优的选择社区活跃、文档完善、硬件支持好。TensorFlow在工业部署方面有一些优势但整体趋势是PyTorch在扩大份额。如果你需要训练超大模型可以考虑DeepSpeed或者Megatron-LM。这些框架在分布式训练方面做了很多优化但学习曲线比较陡。我的建议是先用PyTorch把单卡训练跑通再考虑分布式。6.2 推理引擎的对比与选择推理引擎优势劣势适用场景vLLM部署简单性能好自定义能力有限通用LLM推理TensorRT性能极致转换复杂生产环境ONNX Runtime跨平台性能一般多平台部署Triton灵活配置复杂多模型服务6.3 实验管理工具的实际使用体验我用过WB、MLflow、TensorBoard这几个实验管理工具。WB的体验最好界面漂亮、功能全面但它是商业产品免费版有额度限制。MLflow是开源的功能也够用但界面和体验差一些。TensorBoard最轻量适合简单的实验记录。我的建议是个人项目用TensorBoard就够了团队项目用WB或者MLflow。关键是要养成记录实验的习惯工具本身是次要的。6.4 一些提升效率的小工具和技巧用Makefile管理常用命令把训练、评估、部署等命令写成Makefile目标避免每次都要敲一长串命令。用pre-commit做代码检查在提交代码前自动运行格式化和lint保证代码质量。用DVC管理数据和模型虽然学习曲线有点陡但一旦用起来就很省心。用Hydra管理配置支持配置组合和命令行覆盖比手写argparse方便很多。7. 从能跑到好用工程化思维的建立7.1 可复现性是第一原则可复现性是AI工程和AI研究的最大区别。研究可以接受“跑十次有一次成功”工程必须保证“每次都能成功”。要做到可复现需要控制所有随机源、固定所有依赖版本、记录所有配置信息。我的一般做法是任何一次实验都要能通过一个命令重新跑出来。这个命令包含代码版本、数据版本、配置文件的完整信息。如果做不到这一点说明工程化程度还不够。7.2 自动化测试在AI项目中的应用AI项目的测试比传统软件测试更难因为输出是不确定的。但有一些测试是必须做的数据测试检查数据格式、分布、完整性。模型测试检查模型输出范围、推理时间、显存占用。服务测试检查API响应、错误处理、降级策略。回归测试用固定测试集检查模型效果是否下降。7.3 文档和知识管理的重要性AI项目的文档特别重要因为涉及很多“为什么这么做”的决策。我建议至少维护三类文档设计文档记录系统架构和关键决策实验文档记录每次实验的配置和结果运维文档记录部署流程和常见问题处理。文档不需要写得很正式但一定要及时更新。我见过太多项目文档停留在初始版本后面改了什么完全没人知道。7.4 团队协作中的工程规范如果是团队协作还需要建立一些工程规范代码规范用black和isort统一格式、提交规范用conventional commits、评审规范关键代码必须有人review、发布规范模型上线前必须通过评估。这些规范看起来繁琐但能避免很多低级错误。特别是模型上线这个环节一定要有checklist确保所有必要的评估都做了。8. 持续迭代AI工程没有终点8.1 数据回流闭环的建立数据回流是AI系统持续进化的关键。闭环的建立包括几个环节线上数据采集、低质量样本筛选、人工标注、训练数据更新、模型重新训练、效果评估、上线部署。这个闭环的每个环节都需要自动化。我一般会写一个定时任务每周自动执行一次数据回流流程生成一份报告供人工审核。8.2 模型更新的策略与节奏模型更新不是越频繁越好。太频繁会导致系统不稳定太慢会导致效果落后。我的一般建议是小版本更新微调可以每周一次大版本更新重新训练每月一次。具体节奏要根据业务需求和资源情况来定。更新的时候要注意灰度发布。先在小流量上验证新模型的效果确认没问题再全量。灰度期间要密切监控各项指标一旦发现异常立即回滚。8.3 技术债的管理AI项目的技术债往往比传统项目更多因为技术迭代太快。管理技术债的关键是定期回顾和清理。我一般每个季度会做一次技术债盘点把需要处理的问题列出来按优先级排序然后逐步解决。常见的技术债包括过时的依赖版本、临时的hack代码、不完整的测试覆盖、过时的文档等。这些债不还会越积越多最后拖慢整个团队的效率。8.4 保持学习AI工程领域的知识更新AI工程是一个快速变化的领域新的工具和框架层出不穷。保持学习是必须的但要有选择地学。我的建议是关注核心原理的演进而不是追逐每一个新工具。比如Transformer架构的变体值得关注但某个具体的推理框架更新可以等它稳定了再学。最后分享一个我自己的习惯我会定期把工作中遇到的问题和解决方案记录下来形成一个个人知识库。这个知识库不仅帮我快速解决类似问题也让我在面试和分享时有充足的素材。从零构建AI工程能力是一个长期的过程但每一步的积累都不会白费。