AI Engineering from Scratch：产线级AI系统手工锻造指南

1. 这不是“搭积木”而是亲手锻造AI系统的底层逻辑“AI Engineering from Scratch”——看到这个标题很多人第一反应是又要从零写Transformer又要手推反向传播其实完全不是。我带过六支AI工程团队从金融风控模型落地到工业质检系统交付最常被问的问题就是“你们到底怎么把一个论文里的算法变成每天稳定跑在产线上的服务”答案从来不是调个pip install transformers就完事。真正的AI Engineering from Scratch指的是跳过所有封装好的黑盒框架从数据管道的字节流处理、模型加载的内存布局控制、推理时的CPU/GPU缓存策略一直到底层服务的进程通信机制全部用可审计、可调试、可替换的代码重新实现一遍。它不追求“造轮子”的学术快感而是在真实业务里反复验证当GPU显存突然抖动5%当上游数据格式多了一个空格当并发请求从100飙到3000——你的系统哪一层最先崩崩了之后日志里能不能直接定位到是TensorRT的kernel launch参数没对齐还是PyTorch DataLoader的prefetch线程锁死了关键词“ai-engineering”和“from-scratch”在这里不是口号而是两条硬性标准所有依赖必须明确版本与补丁号所有关键路径必须有单元测试覆盖边界条件所有性能瓶颈必须能用perf或nvprof直接下钻到汇编指令级。适合三类人一是正在设计高可靠AI服务的架构师需要知道哪些抽象层可以信任、哪些必须亲手攥住二是刚从算法岗转工程岗的工程师得明白为什么你调参调得再好线上AUC掉0.3%可能只是因为ONNX导出时用了默认的opset11而非opset14三是技术决策者当你在选型TensorRT还是Triton时得清楚前者在动态shape支持上少写的那200行CUDA wrapper会在未来半年里吃掉多少运维人力。这不是入门教程而是一份产线级AI系统的手工锻造指南。2. 为什么必须放弃“开箱即用”一场真实的故障复盘2.1 一次凌晨三点的P0事故黑盒依赖的代价去年Q3我们为某车企部署的ADAS实时检测系统在连续运行72天后突然出现间歇性卡顿。现象很诡异每17分钟卡顿一次持续8秒恰好卡在车辆变道的关键帧。监控显示GPU利用率在卡顿时跌到5%但CPU占用率飙升到98%。运维同事第一反应是升级驱动——结果重装NVIDIA 515.65.01驱动后卡顿周期变成每13分钟一次。这说明问题不在驱动层。我们拉取了全链路trace发现卡顿前100msPython进程里有个_multi_tensor_copy函数耗时突增。顺着调用栈往下挖最终定位到PyTorch 1.12.1的torch.nn.parallel.DistributedDataParallel模块里一个未公开的bug当模型权重更新频率与NCCL通信超时阈值存在特定相位差时会触发内部重试逻辑而重试时的锁竞争策略在ARM64架构上有竞态漏洞。这个bug在PyTorch官方issue里标记为“wont fix”理由是“仅影响特定硬件组合下的极端场景”。但对我们来说这就是生死线。如果当时系统是用from-scratch方式构建的我们会把DDP的通信层完全剥离出来替换成自己写的基于RDMA的ring-allreduce实现——不仅规避了这个bug还把通信延迟从12ms压到了3.7ms。这件事让我彻底放弃“依赖越少越好”的天真想法转而坚持“每个依赖都必须有对应的替代实现预案”。比如现在我们的标准流程里PyTorch只用于训练阶段的autograd推理引擎完全基于libtorch C API重构所有tensor操作都绕过Python GIL内存分配器直接对接jemalloc并打上业务标签这样一旦出现内存泄漏jeprof能直接定位到是哪个模型的预处理pipeline在resize时没释放临时buffer。2.2 “开箱即用”框架的三大隐形成本很多团队觉得用Hugging Face Transformers省事但实际算下来隐性成本远超预期调试成本指数级增长当模型输出异常时Hugging Face的pipeline会自动做tokenization、padding、batching、postprocessing四层封装。我们曾遇到一个case下游业务方反馈预测结果全是空字符串。排查了3天最后发现是tokenizer的clean_textFalse参数在某个中间版本被悄悄改成了True导致中文标点被过滤。而这个参数在文档里根本没提只在源码注释里有一行# for legacy compatibility。如果是from-scratch我们会在tokenizer初始化时强制校验clean_text的值并写入配置中心任何变更都会触发全链路回归测试。性能损耗不可控以BERT-base为例官方pipeline在CPU上推理单句耗时约120ms。我们用from-scratch方案重写后降到43ms。差异在哪官方pipeline默认启用return_tensorspt这意味着每次调用都要创建新的PyTorch tensor触发GC而我们的方案用内存池预分配固定大小的tensor buffer复用率99.2%。更关键的是官方pipeline的attention mask生成逻辑会遍历整个input_ids列表而我们用SIMD指令AVX2一次性计算mask这部分优化在benchmark里根本测不出来但在高并发场景下CPU缓存行争用减少37%。安全审计无法闭环去年某金融客户要求提供所有第三方库的SBOMSoftware Bill of Materials。Hugging Face依赖树展开后有217个包其中requests的某个间接依赖urllib3存在CVE-2023-43804。虽然漏洞本身不直接影响我们的用法但合规部门要求必须提供该漏洞的缓解措施证明。我们花了两周时间给urllib3打补丁、重新编译、验证所有HTTP client行为——而如果用from-scratch我们根本不会引入requestsHTTP通信层直接用libcurl的C API漏洞面直接砍掉80%。提示不要被“快速验证”迷惑。我见过太多团队用Hugging Face跑通demo后花三个月重构才能上线。真正的效率不是启动速度而是平均故障修复时间MTTR。from-scratch方案的MTTR通常比黑盒方案低60%因为所有代码都在你掌控中。2.3 什么情况下可以“不from-scratch”当然不是所有场景都要从零开始。我们内部有明确的决策矩阵场景类型是否推荐from-scratch关键判断依据实时性要求100ms的边缘设备推理强烈推荐框架runtime开销占比超30%数据敏感度高的金融/医疗场景强烈推荐需要完整审计数据流转路径快速POC验证新算法不推荐核心目标是验证数学正确性非工程可靠性内部工具链已成熟的中台系统条件推荐需评估现有框架与业务需求的gap是否可控去年我们为内部研发效能平台做的代码补全模型就选择了“半from-scratch”底层用libtorch C加载模型但前端交互层用FastAPI封装。这样既保证了推理核心的可控性又避免了重复造HTTP server轮子。关键是在FastAPI层加了严格的schema校验——所有输入JSON必须通过JSON Schema验证连字段顺序都校验防止前端传错字段名导致静默失败。3. 核心模块拆解从数据加载到服务暴露的七层锻造3.1 第一层数据管道的字节级控制所谓“from scratch”第一步就是把数据当成字节流来对待而不是pd.read_csv()。我们所有生产环境的数据加载器都基于mmapstruct.unpack实现。以CSV格式为例传统pandas方案的问题在于read_csv会先读取整行字符串再split再类型转换内存峰值是原始文件的3倍当某列数据类型不一致如ID列混入字符串pandas会自动降级为object类型后续所有计算都走Python慢路径缺少对二进制脏数据的容错比如UTF-8 BOM头、Windows换行符\r\n、嵌入的null字节\x00。我们的方案是用mmap将文件映射到内存用状态机逐字节解析。核心状态机只有7个状态start, in_quote, in_field, in_escape, in_comment, in_number, in_string每个状态对应一个switch case。关键优化点预分配内存池根据schema预先计算每列最大长度为string列分配固定size的buffer如ID列预设64字节避免频繁mallocSIMD加速分隔符查找用AVX2指令集批量扫描逗号一次处理32字节比memchr快4.2倍零拷贝类型转换数字列直接用strtod解析内存地址不生成中间字符串boolean列用位运算直接映射t/f到1/0。实测对比处理1GB CSV文件pandas耗时23.6s内存峰值4.2GB我们的方案耗时8.1s内存峰值1.1GB。更重要的是当文件里混入\x00时pandas直接抛UnicodeDecodeError而我们的状态机会跳过非法字节继续解析并记录错误位置供后续清洗。注意不要迷信“向量化”。我们做过测试当数据质量差缺失值15%时pandas的na_filterTrue会触发额外的扫描反而比我们的状态机慢。真正的工程思维是根据数据质量选择算法而不是让算法决定数据质量。3.2 第二层模型加载的内存布局精算PyTorch默认的torch.load()会把整个state_dict解包到CPU内存再转移到GPU。对于3B参数模型这个过程会吃掉12GB CPU内存且无法控制GPU显存分配时机。我们的方案是分块加载Chunked Loading将.pt文件按tensor切分成固定大小块如16MB每个块独立mmap按需load显存预占Pre-allocation在GPU上预分配一块连续显存用cudaMalloc获取指针所有tensor数据直接memcpy到该区域布局重排Layout Reordering将模型权重按GPU warp size32对齐避免bank conflict。例如Linear层的weight矩阵我们强制reshape为(out_features, in_features // 32, 32)这样每个warp访问连续32个元素时能命中同一个memory bank。具体实现用到了CUDA的cudaMemcpyAsync和stream同步。关键代码片段// 预分配显存 cudaMalloc(d_model_mem, total_size); // 创建专用stream cudaStream_t load_stream; cudaStreamCreate(load_stream); // 异步加载每个tensor块 for (int i 0; i num_chunks; i) { cudaMemcpyAsync(d_model_mem chunk_offsets[i], h_mmap_ptr chunk_offsets[i], chunk_sizes[i], cudaMemcpyHostToDevice, load_stream); } // 等待所有加载完成 cudaStreamSynchronize(load_stream);这套方案把3B模型加载时间从42s压到9.3s显存碎片率从31%降到4.7%。更重要的是当GPU显存不足时我们的加载器会精确报错“第7个chunk无法分配”而不是PyTorch那种模糊的CUDA out of memory。3.3 第三层推理引擎的指令级优化我们不用ONNX Runtime或Triton而是基于libtorch C API手写推理引擎。核心优化在三个层面Kernel融合Kernel Fusion把LayerNorm GELU Linear三步合并成一个CUDA kernel。传统方案中LayerNorm输出要写回global memoryGELU再读取造成两次显存带宽消耗。我们的融合kernel直接在shared memory里完成计算显存带宽占用降低63%。内存访问模式重写Memory Access Pattern RewriteTransformer的attention计算中QKV矩阵乘法会产生大量non-coalesced memory access。我们重写了attn_weights V这一步把V矩阵按warp粒度tile化每个warp只处理一个tile确保内存访问完全coalesced。动态batch调度Dynamic Batch Scheduling不采用固定batch size而是维护一个请求队列用最小堆按输入长度排序。当新请求到达时找现有batch中长度最接近的slot插入使batch内长度方差5%。实测在长尾请求场景下吞吐量提升2.8倍。这些优化都需要深入CUDA编程。比如LayerNorm融合kernel我们参考了NVIDIA的cuBLASLt文档用__syncthreads()控制warp同步用__ldg指令做缓存友好的全局内存读取。没有这些底层控制所谓“高性能推理”只是空中楼阁。3.4 第四层服务框架的进程模型重构FastAPI虽好但默认的async/await模型在AI推理场景下有致命缺陷当一个长耗时推理请求阻塞event loop时所有其他请求都会排队。我们的方案是混合进程模型Hybrid Process Model主进程负责HTTP监听和请求分发工作进程池worker pool负责实际推理。每个worker是独立的C进程用forkexec启动避免Python GIL争用零拷贝IPCZero-copy IPC进程间通信不用JSON序列化而是用shm_open创建共享内存段请求数据直接memcpy到共享内存worker通过mmap访问信号安全重启Signal-safe Restartworker进程收到SIGUSR2时先完成当前请求再优雅退出。主进程监控worker状态自动拉起新进程整个过程请求零丢失。这套模型让我们在单机上支撑了1200 QPS的BERT推理P99延迟稳定在87ms。对比FastAPI默认配置uvicorn workers4同样硬件下P99延迟波动在45ms~210ms之间。3.5 第五层监控埋点的编译期注入监控不是事后加的middleware而是编译期就注入的instrumentation。我们在C推理引擎里用模板元编程实现编译期埋点templatetypename T class InstrumentedLayer { public: void forward(const Tensor input) { // 编译期确定的metric name static constexpr auto metric_name layer. std::string{__PRETTY_FUNCTION__}; auto timer MetricTimer(metric_name); // RAII timer // 实际计算... T::forward(input); } };这样每个layer的耗时、显存占用、tensor shape变化都在编译时生成唯一metric key运行时无字符串拼接开销。我们用perf_event_open系统调用直接采集CPU cycle和cache miss比Prometheus client库快17倍。3.6 第六层配置管理的不可变性设计所有配置都不用YAML/JSON而是用C const struct编译进二进制struct ModelConfig { static constexpr int max_seq_len 512; static constexpr float dropout_rate 0.1f; static constexpr const char* model_path /opt/models/bert-base.bin; };这样做的好处启动时零解析开销配置变更必须重新编译杜绝“配置热更新”导致的不一致所有配置项在编译期类型检查比如max_seq_len必须是int不能是string。3.7 第七层部署包的原子化打包不生成Docker镜像而是用cpio打包所有依赖# 构建最小rootfs mkdir -p rootfs/{bin,lib,etc} cp /usr/bin/my_inference_engine rootfs/bin/ cp /usr/lib/libtorch.so rootfs/lib/ # 打包 find rootfs | cpio -o -H newc inference.cpio # 启动时直接解压到内存 cat inference.cpio | cpio -i -d这样部署包大小从1.2GBDocker镜像降到28MB启动时间从12s降到1.3s。更重要的是cpio包是只读的杜绝了运行时篡改。4. 实操全流程从零构建一个BERT文本分类服务4.1 环境准备剔除所有非必要依赖我们用Ubuntu 22.04 LTS作为基础系统但禁用systemd改用runit管理进程。原因systemd的cgroup v2在GPU容器中存在已知bug会导致NVML无法正确读取显存使用率。安装步骤# 卸载systemd sudo apt-get remove --purge systemd # 安装runit sudo apt-get install runit # 创建最小化rootfs debootstrap --variantminbase jammy /tmp/minroot http://archive.ubuntu.com/ubuntu/关键点所有工具链都从源码编译不使用apt包。比如GCC我们用GCC 12.3源码打上针对AVX512的patch编译时启用-marchnative -O3 -fltofull。4.2 数据预处理状态机实现的CSV解析器创建csv_parser.hclass CSVParser { private: enum State { START, IN_QUOTE, IN_FIELD, IN_ESCAPE, IN_COMMENT }; State state_; char* buffer_; size_t buffer_size_; size_t pos_; size_t field_start_; public: explicit CSVParser(char* buf, size_t size) : buffer_(buf), buffer_size_(size), pos_(0), field_start_(0) {} bool parse_row(std::vectorstd::string row); private: inline void handle_char(char c, std::vectorstd::string row); };编译时用-mavx2 -mbmi2启用高级指令集。实测在Intel Xeon Platinum 8380上解析100万行CSV比pandas快5.3倍。4.3 模型训练PyTorch的最小化封装我们只用PyTorch的torch.autograd.Function和torch.nn.Module禁用所有高级API。训练脚本train.py核心class CustomLinear(torch.autograd.Function): staticmethod def forward(ctx, input, weight, bias): ctx.save_for_backward(input, weight, bias) output input weight.t() bias return output staticmethod def backward(ctx, grad_output): input, weight, bias ctx.saved_tensors grad_input grad_output weight grad_weight grad_output.t() input grad_bias grad_output.sum(0) return grad_input, grad_weight, grad_bias class MinimalBERT(nn.Module): def __init__(self, config): super().__init__() self.embed nn.Embedding(config.vocab_size, config.hidden_size) self.layers nn.ModuleList([ TransformerLayer(config) for _ in range(config.num_layers) ]) self.classifier CustomLinear.apply # 直接调用Function def forward(self, x): x self.embed(x) for layer in self.layers: x layer(x) return self.classifier(x[:, 0], self.cls_weight, self.cls_bias)这样做的好处是反向传播路径完全透明任何梯度异常都能精准定位到具体Function。4.4 模型导出自定义ONNX导出器不用torch.onnx.export而是手写导出器class CustomONNXExporter: def __init__(self, model): self.model model self.nodes [] self.initializers [] def export(self, dummy_input): # 手动构建ONNX graph graph onnx.helper.make_graph( nodesself._build_nodes(dummy_input), namebert_classifier, inputs[onnx.helper.make_tensor_value_info(input, onnx.TensorProto.INT64, [1, 512])], outputs[onnx.helper.make_tensor_value_info(output, onnx.TensorProto.FLOAT, [1, 2])], initializerself.initializers ) return onnx.helper.make_model(graph)关键点我们强制指定opset14并手动添加Cast节点确保所有tensor类型精确匹配避免Triton加载时的类型不匹配错误。4.5 推理引擎C核心实现inference_engine.cppclass InferenceEngine { private: torch::jit::script::Module module_; cudaStream_t stream_; std::vectortorch::Tensor input_buffers_; public: explicit InferenceEngine(const std::string model_path) { // 加载模型 module_ torch::jit::load(model_path); // 创建CUDA stream cudaStreamCreate(stream_); // 预分配输入buffer input_buffers_.push_back(torch::empty({1, 512}, torch::kInt64).cuda()); } std::vectorfloat infer(const std::vectorint64_t input_ids) { // 将输入拷贝到GPU buffer cudaMemcpyAsync(input_buffers_[0].data_ptr(), input_ids.data(), input_ids.size() * sizeof(int64_t), cudaMemcpyHostToDevice, stream_); // 执行推理 auto output module_.forward({input_buffers_[0]}); // 同步stream cudaStreamSynchronize(stream_); // 返回结果 return output.toTensor().cpu().vecfloat(); } };编译命令g -stdc17 -O3 -marchnative \ -I/opt/libtorch/include \ -L/opt/libtorch/lib \ -ltorch -ltorch_cpu -lc10 \ -lcudart -lcuda \ inference_engine.cpp -o inference_engine4.6 服务封装C HTTP服务器不用任何框架手写HTTP服务器class HTTPServer { private: int server_fd_; InferenceEngine engine_; public: HTTPServer(const std::string model_path) : engine_(model_path) { server_fd_ socket(AF_INET, SOCK_STREAM, 0); // 绑定端口... } void run() { while (true) { int client_fd accept(server_fd_, nullptr, nullptr); // fork处理请求 if (fork() 0) { handle_request(client_fd); exit(0); } } } private: void handle_request(int client_fd) { // 解析HTTP请求 char buffer[8192]; ssize_t n read(client_fd, buffer, sizeof(buffer)-1); // 提取JSON body auto json parse_json(buffer); // 调用推理引擎 auto result engine_.infer(json[input_ids]); // 构造HTTP响应 std::string response HTTP/1.1 200 OK\r\nContent-Type: application/json\r\n\r\n; response json_encode(result); write(client_fd, response.c_str(), response.size()); close(client_fd); } };4.7 部署与验证原子化发布流程部署脚本deploy.sh#!/bin/bash # 1. 构建cpio包 rm -rf rootfs mkdir -p rootfs/{bin,lib,etc} cp inference_engine rootfs/bin/ cp /usr/lib/x86_64-linux-gnu/libtorch.so rootfs/lib/ cp /usr/lib/x86_64-linux-gnu/libcudart.so.11.0 rootfs/lib/ # 2. 创建启动脚本 cat rootfs/etc/run EOF #!/bin/sh cd /bin ./inference_engine --port8000 --model/models/bert.bin EOF chmod x rootfs/etc/run # 3. 打包 find rootfs | cpio -o -H newc inference.cpio # 4. 验证 qemu-system-x86_64 -kernel /boot/vmlinuz -initrd inference.cpio -append consolettyS0 -nographic验证时用perf record -e cycles,instructions,cache-misses采集性能数据确保关键路径指令数符合预期。5. 常见问题与避坑指南来自产线的血泪经验5.1 GPU显存“神秘泄漏”CUDA context的隐式创建现象服务运行24小时后nvidia-smi显示显存占用从1.2GB涨到3.8GB但torch.cuda.memory_allocated()只显示1.2GB。排查发现是torch.backends.cudnn.enabled True导致的。cuDNN会在首次调用卷积时创建context而这个context的显存不会被torch.cuda.empty_cache()释放。解决方案在服务启动时显式禁用cuDNNtorch.backends.cudnn.enabled False所有卷积操作改用torch.nn.functional.conv2d并手动指定groups1或者如果必须用cuDNN启动时预热所有可能用到的卷积尺寸conv2d(torch.randn(1,3,224,224), torch.randn(64,3,3,3))实操心得永远不要相信框架的“默认最优”。我们测试过禁用cuDNN后ResNet50推理延迟只增加1.2ms但显存稳定性提升100%。5.2 多线程推理的“伪并行”陷阱很多团队用threading.Thread启动多个推理线程结果发现QPS不升反降。原因是PyTorch的torch.set_num_threads()设置的是OpenMP线程数而GPU推理本身是单线程的多线程只会增加CPU上下文切换开销。正确做法CPU推理用torch.set_num_threads(1)每个进程只处理一个请求GPU推理用进程池multiprocessing.Pool每个进程独占一个GPU stream混合场景CPU预处理GPU推理用concurrent.futures.ProcessPoolExecutor分离任务。5.3 模型版本“静默降级”现象模型更新后线上效果下降但所有指标都正常。查日志发现新模型的tokenizer和旧模型不兼容——新tokenizer把“iPhone”分词为[i, Phone]旧模型期望[iPhone]。解决方案tokenizer和model必须绑定版本号存储在同一个.tar包里加载时校验sha256if (model_hash ! tokenizer_hash) throw std::runtime_error(version mismatch);所有分词逻辑在C层实现Python只做胶水代码。5.4 Docker镜像的“依赖幻觉”用docker build构建的镜像看似包含所有依赖但实际运行时可能缺库。比如libtorch.so依赖libgomp.so.1而基础镜像里只有libgomp.so。ldd检查时显示“not found”但程序还能跑——因为glibc的dlopen会fallback到libgomp.so但性能下降40%。避坑方法构建时用patchelf强制指定rpathpatchelf --set-rpath $ORIGIN/lib inference_engine运行时用ldd -v inference_engine验证所有依赖解析正确在CI中加入readelf -d inference_engine | grep NEEDED检查依赖列表。5.5 配置热更新的“一致性地狱”很多团队想实现配置热更新比如动态调整batch size。但实际中当一个请求正在执行时修改配置会导致该请求用新配置、下一个请求用旧配置结果不可预测。终极方案配置不可变。每次配置变更生成新版本二进制用蓝绿部署切换。我们用git commit hash作为版本号部署时自动打tag所有监控指标按版本号分组。这样问题定位时直接看versionabc123就能锁定所有相关日志。5.6 性能测试的“虚假繁荣”用ab或wrk测QPS结果很高但线上一压就崩。原因是这些工具发送的是均匀请求而真实流量有burst。我们用真实trace重放采集线上1小时请求时间戳用tcpreplay重放burst窗口设为100ms。结果发现框架在burst下P99延迟飙升300%而我们的方案只升12%。测试脚本关键参数tcpreplay -i lo -M 1000 --loop100 trace.pcap # -M 1000: 模拟1000个并发连接 # --loop100: 重放100次6. 工程师的自我修养从“会用”到“会造”的思维跃迁做AI Engineering from Scratch最终考验的不是编码能力而是对计算机系统本质的理解深度。我见过太多算法工程师能把Transformer背得滚瓜烂熟却说不清cudaMalloc和cudaMallocManaged的区别不知道mmap的MAP_POPULATE标志意味着什么不理解为什么std::vector在多线程环境下要加锁而std::deque不用。这种知识断层正是黑盒框架掩盖的真相。真正的from-scratch是回到冯·诺依曼体系的原点一切皆内存一切皆指令一切皆时序。当你在写CUDA kernel时你在和GPU的SMStreaming Multiprocessor对话当你在调mmap时你在和Linux的页表打交道当你在写HTTP parser时你在和TCP的滑动窗口博弈。这些不是“底层细节”而是AI系统的血肉。所以我的建议很朴素每周花两小时读一段Linux内核源码比如mm/mmap.c或者调试一个CUDA samplecuda-samples/1_Utilities/bandwidthTest或者用objdump反汇编自己的二进制。不需要立刻产出但要让这些概念成为肌肉记忆。当某天你看到CUDA_ERROR_LAUNCH_OUT_OF_RESOURCES第一反应不是Google而是打开nvidia-smi -q -d MEMORY看显存bank分布你就真正入门了。最后分享一个小技巧在所有C代码里强制使用[[nodiscard]]属性。比如[[nodiscard]] std::vectorfloat infer(const std::vectorint64_t input);这样编译器会警告你“你调用了infer但没用返回值”避免静默失败。这看似微小却是工程思维的起点——拒绝任何不可见的状态。AI Engineering from Scratch本质上是一场对抗不确定性的战争而最好的武器就是把所有不确定性都变成可测量、可验证、可追溯的确定性。