1. 从零搭建AI工程能力，为什么大多数人卡在第一步就放弃了
如果你最近在技术社区里频繁看到“ai-engineering-from-scratch”这个说法，不用怀疑，它不是什么新出的框架或者工具库，而是一种越来越多人认可的学习路径——从最底层开始，亲手把AI工程化的各个环节搭一遍。我之所以想聊这个话题，是因为过去大半年里，我带过几个刚入行的朋友做AI相关的项目，发现一个很普遍的现象：大家学AI的热情很高，但路径极其混乱。有人上来就调大模型API，有人直接跑微调脚本，还有人买了一堆课程从线性代数开始啃，结果三个月过去，连一个完整的推理服务都没部署起来。
这个项目标题“ai-engineering-from-scratch”背后指向的核心需求其实很明确：你需要一套从零开始、不依赖现成高级封装、能真正理解每个环节在干什么的AI工程实践路线。它适合那些已经会写Python、了解基本机器学习概念，但在“把模型变成可用服务”这件事上始终没有系统认知的人。关键词里的“from scratch”不是让你手写CUDA核函数，而是说你要亲手经历数据准备、模型加载、推理优化、服务封装、监控运维这条完整链路，哪怕每个环节只用最朴素的方案。
我自己的经验是，AI工程和传统后端工程最大的区别在于：不确定性从代码逻辑转移到了数据和模型行为上。你写一个CRUD接口，输入输出是确定的；但你部署一个推理服务，同样的输入可能因为batch size、精度、硬件状态的不同而得到略有差异的结果。这种不确定性才是AI工程真正难的地方，也是“from scratch”这条路径最有价值的部分——你必须亲手摸一遍每个环节的边界，才能建立起对系统的直觉。
接下来的内容，我会按照一个真实项目从零到上线的顺序，把每个阶段的关键决策、常见坑和实操细节拆开讲。不会堆砌术语，也不会给你一个“照着抄就行”的脚本，因为AI工程这件事，抄来的配置往往跑不通你自己的场景。
2. 环境与依赖：为什么你的第一个推理脚本总是跑不起来
2.1 硬件选型的现实考量
很多人一开始就纠结要不要买显卡。我的建议很直接：如果你只是想做AI工程化的学习，先用CPU跑通全流程，再考虑GPU。原因很简单，CPU环境下的依赖问题少得多，你能把精力集中在理解流程上，而不是和驱动版本搏斗。我见过太多人卡在CUDA版本、cuDNN匹配、PyTorch编译版本这三个东西的排列组合上，一周都没跑起来一个Hello World。
具体来说，如果你手头有一台普通笔记本，16GB内存起步，就可以开始。用ONNX Runtime的CPU版本加载一个BERT-base模型做推理，单条文本延迟大概在50到200毫秒之间，完全够你调试服务逻辑。等你把数据预处理、tokenization、后处理、HTTP服务封装都跑通了，再迁移到GPU环境，这时候你对自己需要什么版本的CUDA、什么版本的推理框架已经有了判断力，不会被各种教程牵着走。
提示：不要在一开始就追求最新版本的框架。PyTorch 2.x和ONNX Runtime 1.17左右的组合，在CPU上的稳定性经过大量验证，遇到问题也容易搜到解决方案。
2.2 依赖管理的正确姿势
Python的依赖地狱在AI领域尤其严重。我的做法是：每个项目一个独立的conda环境，并且把环境导出成environment.yml文件纳入版本控制。不要用pip全局安装，也不要在base环境里折腾。具体操作上，先装好Miniconda，然后：
conda create -n ai-eng python=3.10 conda activate ai-eng pip install torch --index-url https://download.pytorch.org/whl/cpu pip install transformers onnx onnxruntime fastapi uvicorn这里有个细节：PyTorch的CPU版本和GPU版本安装命令不同，如果你直接pip install torch，在某些平台上会默认拉取GPU版本，然后因为缺少CUDA驱动而报错。所以显式指定CPU版本的index-url很重要。另外，transformers库的版本要和torch版本大致匹配，我一般会查一下transformers的release notes，确认它推荐的torch版本范围。
2.3 模型文件的获取与缓存
从Hugging Face拉模型是常规操作，但国内网络环境下经常超时。我的经验是：提前用huggingface-cli或者git lfs把模型下载到本地，然后通过本地路径加载。不要每次跑脚本都去远程拉，那样调试效率极低。下载的时候注意模型的文件结构，通常需要config.json、pytorch_model.bin（或model.safetensors）、tokenizer.json、vocab.txt这几个文件。如果只下载了权重文件而缺少tokenizer配置，加载时会报各种奇怪的错误。
from transformers import AutoTokenizer, AutoModel model_path = "./local_models/bert-base-chinese" tokenizer = AutoTokenizer.from_pretrained(model_path) model = AutoModel.from_pretrained(model_path)这段代码看起来简单，但如果你本地路径下的文件不完整，报错信息往往不会直接告诉你缺了哪个文件。我的排查方法是：先检查目录下有没有config.json，再看tokenizer相关的文件是否齐全，最后确认权重文件的格式和大小是否正常。
3. 从模型文件到可调用服务：中间到底缺了什么
3.1 推理脚本和服务之间的鸿沟
很多人能写一个Python脚本加载模型、输入一句话、打印输出，但不知道怎么把它变成一个别人可以调用的服务。这中间的鸿沟主要有三个：并发处理、请求解析和错误处理。一个脚本一次只能处理一个输入，但一个服务要同时应对多个请求；脚本的输入是命令行参数，服务的输入是HTTP请求体；脚本报错直接崩溃，服务报错要返回合理的状态码和错误信息。
我建议的路径是：先用FastAPI写一个最简单的同步接口，把模型加载放在应用启动时完成，请求处理函数里只做推理。这样你能快速看到一个可用的服务雏形。然后逐步加入批处理、异步、超时控制等机制。不要一上来就搞异步推理或者动态批处理，那些是优化阶段的事情，过早引入只会让你调试困难。
from fastapi import FastAPI from pydantic import BaseModel import torch from transformers import AutoTokenizer, AutoModel app = FastAPI() model_path = "./local_models/bert-base-chinese" tokenizer = AutoTokenizer.from_pretrained(model_path) model = AutoModel.from_pretrained(model_path) model.eval() class Request(BaseModel): text: str @app.post("/embed") def embed(req: Request): inputs = tokenizer(req.text, return_tensors="pt", truncation=True, max_length=512) with torch.no_grad(): outputs = model(**inputs) return {"embedding": outputs.last_hidden_state.mean(dim=1).squeeze().tolist()}这个例子返回的是句向量的平均值，实际项目中你可能需要更复杂的后处理逻辑。但核心结构就是这样：启动时加载模型，请求时做推理，返回JSON。
3.2 输入输出的边界处理
AI服务最容易出问题的地方不是模型本身，而是输入输出的边界。我踩过的坑包括：用户输入超长文本导致tokenizer截断后语义完全变了；输入包含特殊字符导致tokenizer报错；输出向量维度太大导致JSON序列化慢；并发请求时模型状态被意外修改。这些问题在脚本阶段都不会暴露，只有服务跑起来才会一个个冒出来。
我的处理原则是：在请求入口做严格的输入校验，在推理前后做必要的日志记录，在输出前做格式和大小检查。比如对于文本输入，我会限制最大字符数，并且在tokenizer之前先做一次长度检查，超过限制的直接返回错误而不是静默截断。对于输出，如果向量维度超过一定阈值，考虑返回二进制格式或者分页返回。
注意：模型在eval()模式下不会更新参数，但如果你在多线程环境下共享同一个模型实例，仍然可能遇到线程安全问题。最简单的做法是每个worker进程独立加载一份模型，虽然内存占用翻倍，但省去了大量调试时间。
3.3 服务封装中的性能取舍
当你把服务跑通之后，下一步自然会想优化性能。这时候有几个方向：批处理、量化、缓存、异步。我的建议是按这个顺序来：先做缓存，再做批处理，最后考虑量化。缓存是最安全的优化，对于重复输入直接返回之前的结果，不涉及任何模型层面的改动。批处理能显著提升吞吐量，但会增加单次请求的延迟，需要根据你的场景权衡。量化会改变模型精度，可能影响输出质量，一定要在业务指标上验证过再上线。
具体到批处理的实现，最简单的做法是在服务层维护一个请求队列，每隔几毫秒或者队列达到一定长度时，把多个请求合并成一个batch送给模型。但要注意，不同请求的输入长度不同，padding到同一长度会浪费计算资源。更精细的做法是按长度分桶，但实现复杂度会上升。我的经验是，对于学习目的，先实现一个固定batch size的版本，理解批处理的基本逻辑就够了。
4. 数据管道：AI工程里最容易被低估的环节
4.1 为什么你的模型效果总是不达预期
很多人把模型效果不好归咎于模型本身，但实际项目中，百分之七十的问题出在数据管道上。我见过一个文本分类项目，模型在测试集上F1只有0.6，排查了半天发现是训练数据的标签在预处理阶段被错误地映射了。还有一个检索项目，召回率始终上不去，最后发现是文本清洗时把关键的数字和标点都去掉了，导致语义完全改变。
数据管道的核心环节包括：数据采集、清洗、去重、标注、格式转换、特征提取。每个环节都有坑。比如去重，简单的文本完全匹配去重会漏掉大量语义重复的样本，但用语义相似度去重又可能误删有价值的困难样本。我的做法是：先用完全匹配和近似匹配做一轮粗去重，然后人工抽查一批样本，确认去重策略没有误伤。这个抽查步骤不能省，因为去重策略的效果高度依赖你的数据分布。
4.2 数据版本管理的实操方案
数据版本管理是AI工程和传统软件工程差异最大的地方之一。代码可以用git管理，但数据集动辄几个GB，不可能直接放进git。我的方案是：用DVC或者类似的工具管理数据版本，同时维护一个数据字典，记录每个版本的数据来源、处理步骤和统计信息。数据字典不需要很复杂，一个Markdown文件就够了，关键是要坚持更新。
具体来说，每次数据处理脚本运行后，我会生成一个JSON格式的统计报告，包括样本总数、各类别分布、平均长度、去重前后数量变化等。这个报告和数据文件一起提交到DVC。这样当模型效果出现波动时，我可以快速对比不同数据版本之间的差异，定位是数据问题还是模型问题。
import json import hashlib def data_fingerprint(file_path): with open(file_path, "rb") as f: content = f.read() return hashlib.md5(content).hexdigest() stats = { "total_samples": len(dataset), "label_distribution": dict(Counter(labels)), "avg_length": sum(lengths) / len(lengths), "fingerprint": data_fingerprint("processed_data.jsonl") } with open("data_stats.json", "w") as f: json.dump(stats, f, ensure_ascii=False, indent=2)这个指纹机制看起来简单，但当你需要回溯“上周的模型到底用的哪版数据”时，它能救你的命。
4.3 特征工程在深度学习时代的定位
现在大家都在谈端到端学习，好像特征工程不重要了。但实际做AI工程，特征工程的思想仍然关键，只是形式变了。以前你手动设计TF-IDF特征，现在你设计的是输入文本的构造方式、特殊token的插入位置、多字段的拼接策略。这些决策对最终效果的影响，不比模型结构小。
举个例子，做一个商品标题的分类任务，你是直接把标题喂给模型，还是把标题和商品描述拼接起来？拼接时用什么分隔符？标题和描述各自截断到多少长度？这些选择都会影响模型能学到的信息量。我的经验是：对于短文本任务，标题和描述拼接时，标题重复两次往往比只出现一次效果好，因为模型对重复出现的信号更敏感。这种技巧没有理论保证，但在我做过的几个项目里都有效。
5. 推理优化：从能跑到跑得快的几个关键决策
5.1 模型格式转换的收益与代价
PyTorch训练出来的模型直接用于推理，性能往往不是最优的。常见的优化路径是转成ONNX格式，然后用ONNX Runtime推理。这个转换过程能带来多少收益？在我的测试中，BERT-base模型在CPU上，ONNX Runtime比原生PyTorch推理快大约1.5到2倍，内存占用也更低。但转换过程本身可能遇到算子不支持、动态维度处理等问题。
转换的核心步骤是：准备一个示例输入，用torch.onnx.export导出模型，然后用onnxruntime加载并验证输出是否和原模型一致。这里的关键是动态维度的设置，因为推理时输入长度是变化的。你需要把batch size和sequence length都设为动态维度，否则模型只能处理固定长度的输入。
import torch from transformers import AutoTokenizer, AutoModel model_path = "./local_models/bert-base-chinese" tokenizer = AutoTokenizer.from_pretrained(model_path) model = AutoModel.from_pretrained(model_path) model.eval() dummy_input = tokenizer("测试文本", return_tensors="pt") torch.onnx.export( model, (dummy_input["input_ids"], dummy_input["attention_mask"]), "model.onnx", input_names=["input_ids", "attention_mask"], output_names=["last_hidden_state"], dynamic_axes={ "input_ids": {0: "batch", 1: "sequence"}, "attention_mask": {0: "batch", 1: "sequence"}, "last_hidden_state": {0: "batch", 1: "sequence"} }, opset_version=14 )导出之后一定要用ONNX Runtime跑一遍，对比输出差异。如果差异在1e-4以内，基本可以认为转换成功。如果差异很大，通常是某些算子在不同框架下的实现有细微差别，需要逐个排查。
5.2 量化对精度的影响到底有多大
量化是另一个常见的优化手段，把FP32的权重转成INT8，模型体积缩小到四分之一，推理速度提升2到4倍。但量化对精度的影响因任务而异。我的经验是：对于分类和检索任务，INT8量化后精度下降通常在1%以内，可以接受；但对于生成任务，量化可能导致输出质量明显下降，因为生成任务对概率分布的细微变化更敏感。
动态量化和静态量化的选择也值得说。动态量化实现简单，一行代码就能搞定，但加速效果有限。静态量化需要提供校准数据集，实现复杂一些，但加速效果更好。我的建议是先用动态量化试一下，如果速度提升不够再考虑静态量化。
from onnxruntime.quantization import quantize_dynamic, QuantType quantize_dynamic( "model.onnx", "model_quantized.onnx", weight_type=QuantType.QUInt8 )量化后的模型一定要在你的验证集上重新评估，不要只看速度指标。我见过一个项目，量化后推理速度翻倍，但线上A/B测试发现点击率下降了3%，最后不得不回滚。
5.3 缓存策略的设计细节
缓存是性价比最高的优化手段，但设计不好也会引入问题。最朴素的缓存是字典，key是输入文本的哈希，value是输出结果。但这样有两个问题：内存无限增长和缓存命中率低。对于第一个问题，可以用LRU策略限制缓存大小；对于第二个问题，可以考虑语义缓存，即用向量相似度来判断两个输入是否足够相似，相似则复用结果。
语义缓存的实现思路是：对每个输入先计算一个轻量级的向量表示（比如用一个小模型或者TF-IDF），然后在缓存中查找相似度超过阈值的记录。这个方案能显著提升命中率，但增加了每次请求的计算开销。我的经验是，如果输入分布比较集中，比如客服问答场景，语义缓存的收益很大；如果输入非常发散，比如开放域对话，收益有限。
6. 监控与迭代：上线只是开始
6.1 推理服务的核心监控指标
AI服务上线后，你需要监控的指标和传统服务有重叠也有差异。重叠的部分是QPS、延迟、错误率这些通用指标。差异的部分是模型层面的指标：输入分布的变化、输出分布的偏移、置信度的变化。这些指标能帮你发现模型退化或者数据漂移。
我通常会记录每次请求的输入长度、输出向量的范数、推理耗时这几个字段，然后按小时聚合。如果发现输入长度的均值突然变大，可能是上游数据源变了；如果输出向量的范数分布发生偏移，可能是模型对当前数据的区分度下降了。这些信号不一定意味着马上要重新训练，但至少提醒你去排查原因。
6.2 模型迭代的触发条件
什么时候该重新训练模型？这个问题没有标准答案，但有几个触发条件可以参考：线上指标连续下降超过阈值、数据分布发生显著变化、业务规则调整导致标注标准变化、积累了足够多的新标注数据。我的做法是设置一个简单的规则引擎，当这些条件中的任意一个满足时，自动创建一个模型迭代任务，而不是等到问题严重了才手动处理。
具体实现上，我会在监控系统里维护一个滑动窗口，计算最近七天和之前七天的指标差异。如果差异超过预设阈值，就触发告警。同时，每周定期跑一次数据分布对比，用KL散度或者PSI指标来衡量新旧数据的差异。这些计算都不复杂，但能让你对模型状态心里有数。
6.3 灰度发布与回滚机制
模型更新不能全量直接上，一定要有灰度发布和快速回滚的能力。我的做法是：新模型先切5%的流量，观察至少半天，确认核心指标没有下降后再逐步扩大比例。灰度期间要同时记录新旧模型的输出，方便对比分析。回滚机制要足够简单，最好是一个配置开关，切换后立即生效，不需要重新部署服务。
这里有个容易忽略的细节：新旧模型的输出格式可能不完全一致，比如新模型多返回了一个字段。灰度期间，下游服务需要能兼容两种格式。我的建议是，模型服务的输出格式尽量保持稳定，新增字段用可选的方式提供，不要破坏已有字段的语义。
7. 一些让我少走弯路的实操习惯
7.1 先跑通再优化，但要知道优化的方向
我见过太多人包括我自己，一开始就想着把系统设计得很完美，结果卡在某个细节上迟迟出不来东西。后来我养成了一个习惯：先用最笨的方法把全流程跑通，哪怕性能很差、代码很丑，然后再逐个环节优化。这个习惯救了我很多次，因为只有跑通了，你才知道真正的瓶颈在哪里。
但“先跑通”不等于“盲目跑”。在跑通的过程中，我会刻意记录每个环节的耗时和资源占用，这样优化的时候有数据支撑，不会凭感觉瞎猜。比如我发现数据预处理占了总时间的60%，那优化重点就很明确，而不是去折腾模型推理。
7.2 日志要记，但不要什么都记
AI服务的日志和传统服务不同，输入输出可能包含大量文本，全量记录会迅速撑爆磁盘。我的策略是：记录输入的哈希值和长度，记录输出的统计特征，只对采样的一部分请求记录完整内容。采样比例根据流量调整，低峰期可以高一些，高峰期低一些。这样既能保留排查问题的能力，又不会让存储成本失控。
另外，日志的格式要结构化，方便后续用脚本分析。我一般用JSON Lines格式，每行一个JSON对象，包含时间戳、请求ID、输入哈希、输出统计、耗时等字段。不要用纯文本日志，后期分析起来很痛苦。
7.3 文档是给自己看的，不是给别人看的
最后说一个容易被忽视的点：项目文档。很多人觉得写文档是浪费时间，但AI工程项目尤其需要文档，因为实验的变量太多了。我习惯在项目根目录维护一个EXPERIMENTS.md文件，每次跑实验都记录：日期、数据版本、模型配置、关键超参数、评估指标、结论。这个文件不需要很正式，但坚持记录，几个月后回头看，能帮你省下大量重复实验的时间。
文档的另一个作用是固化决策逻辑。比如为什么选择这个tokenizer而不是那个，为什么用这个阈值而不是那个，当时是怎么权衡的。这些决策在项目初期可能很清晰，但过了一个月你自己都忘了。写下来，不仅是为了别人，更是为了未来的自己。
提示：文档不要追求一次写完，每次做完一个实验就补充几行，积少成多。最怕的是一开始想写一篇完美的文档，结果迟迟不动笔，最后什么都没留下。
7.4 保持对“默认配置”的警惕
最后分享一个心态层面的经验：永远不要盲目相信默认配置。框架的默认参数是为了通用场景设计的，你的场景大概率不是通用场景。比如tokenizer的max_length默认是512，但你的文本可能平均只有20个字符，padding到512会浪费大量计算。再比如DataLoader的num_workers默认是0，在CPU上跑小模型可能没问题，但数据量大时就是瓶颈。
我的做法是：每引入一个新组件，先花十分钟看一下它的关键参数和默认值，思考这些默认值在你的场景下是否合理。这个习惯看起来不起眼，但积累下来，能让你对系统的掌控力提升一个档次。AI工程说到底，就是对这些细节的持续关注和调整，没有什么一劳永逸的银弹。
