1. 什么是“AI Engineering from Scratch”——不是搭积木是亲手烧砖造窑“AI Engineering from Scratch”这个标题乍看像一句技术口号但背后藏着一个正在快速分化的行业现实当90%的开发者还在用Hugging Face一键加载pipeline、用LangChain拼接现成模块、用AutoML点几下鼠标就生成模型时真正决定系统长期可用性、可维护性、可扩展性的恰恰是那些没人愿意写的底层代码——数据管道里一个没处理好的时区偏移模型服务中一次未声明的内存泄漏推理API里一个未校验的输入长度都可能让整套AI系统在上线第三天凌晨三点崩在生产环境。我带过七支AI落地团队从智能客服到工业质检踩过最深的坑从来不是算法精度不够而是工程链路里某一段“from scratch”的缺失。所谓“from scratch”不是拒绝工具而是清楚知道每个工具的边界在哪、失效时怎么兜底、出问题时能精准定位到哪一行代码。它解决的不是“能不能跑”而是“能不能稳、能不能查、能不能换、能不能扛住十倍流量”。适合三类人一是刚从学术圈转战工业界的算法工程师常困惑“为什么论文指标漂亮上线后延迟翻五倍”二是传统后端/DevOps工程师想切入AI基建但被满屏的torch.compile、vLLM、Triton术语绕晕三是技术决策者需要判断自研AI平台和采购商业方案的真实成本差异。关键词“ai-engineering”和“from-scratch”必须同时成立——前者定义领域不是纯算法也不是纯运维后者定义方法论不依赖黑盒封装掌握全链路可控性。这不是教你怎么调参而是教你怎么让AI系统像银行核心交易系统一样全年99.99%可用故障5分钟内定位扩容无需停机。2. 为什么必须“from scratch”——被掩盖的工程债务有多重2.1 现成框架的“甜蜜陷阱”便利性背后的三重隐性成本很多团队选择“开箱即用”出发点很务实业务要快、人力有限、KPI压着。但我在某金融风控项目里亲眼见过用现成的AutoML平台两周上线模型三个月后因特征版本混乱导致线上AUC骤降0.15排查耗时17人日——问题根源竟是平台自动缓存的特征计算逻辑与新数据源时间戳解析规则冲突而平台日志只显示“预测失败”不暴露特征计算中间态。这类隐性成本有三个典型维度第一是可观测性黑洞。主流LLM推理框架如vLLM或Triton性能参数调优文档写得密密麻麻但当你发现P99延迟突然飙升框架本身不提供请求级的token生成耗时拆解比如embedding耗时、KV cache填充耗时、逐token decode耗时你只能靠火焰图硬啃C源码。而自己写的轻量级服务可以在每个关键节点插入毫秒级计时器直接输出结构化trace日志故障时一眼看出是模型加载慢还是prompt解析卡住。第二是依赖锁定风险。某电商推荐团队用LangChain构建召回链路半年后因社区放弃维护某个memory模块被迫重构整个对话状态管理。如果当初用原生PythonRedis实现状态存储替换成本就是改两行序列化逻辑。更隐蔽的是许可证风险——某些开源LLM服务框架采用SSPL协议商用需授权而自研HTTP服务层天然规避此问题。第三是资源效率错配。现成框架为兼容性牺牲性能vLLM默认启用PagedAttention但若你的场景是固定长度的批量文本分类非流式生成这套内存管理反而增加CPU开销。我们实测过用纯PyTorch写一个无缓存的batch inference loop在同等GPU上吞吐量提升23%因为省去了所有attention context的动态内存分配开销。提示评估是否“from scratch”的黄金标准不是“有没有时间”而是问自己“当线上出现一个从未见过的错误我能用不到30分钟定位到具体函数和参数吗” 如果答案是否定的框架的便利性正在透支你的工程信用。2.2 AI工程的本质矛盾算法迭代快 vs 系统稳定性要求高传统软件工程里架构设计追求“稳定抽象层”比如数据库驱动封装SQL差异。但AI系统里抽象层本身就在剧烈变化去年主流还是BERT微调今年已是LoRAQLoRA量化部署去年推理用ONNX Runtime今年转向TensorRT-LLM。如果把AI能力封装成黑盒SDK每次算法升级就得连同整个服务框架一起回归测试——这违背了CI/CD的核心原则。而“from scratch”构建的模块化设计能让算法变更与工程基础设施解耦。例如我们设计的模型服务层包含三个明确定义的接口preprocess()接收原始输入并标准化、inference()调用模型核心逻辑、postprocess()格式化输出。当算法团队把BERT换成Phi-3时只需重写inference()函数其他部分完全不动。这种解耦不是靠框架自动实现的而是通过强制约定接口契约达成的——这正是手写代码带来的控制力。2.3 “Scratch”的真实含义不是重复造轮子而是定义轮子的规格很多人误解“from scratch”等于从零写矩阵乘法。实际工作中90%的代码复用成熟库PyTorch、NumPy、FastAPI但关键决策点必须自主掌控数据管道不用Airflow调度而是用Pythonasyncioconcurrent.futures构建轻量级DAG因为我们的数据源只有3个API和1个S3桶Airflow的Web UI和数据库依赖纯属冗余模型服务不套用Triton而是用TorchScript导出模型Flask原生服务因为业务QPS仅200Triton的GPU多实例管理反而增加调度延迟监控告警不接PrometheusGrafana而是用StatsD客户端直发Datadog因为现有运维体系已统一用Datadog强行引入新监控栈会增加告警收敛复杂度。“Scratch”的本质是根据真实约束做减法而不是盲目追求技术先进性。我见过最典型的反面案例某团队为“技术先进”硬上Kubeflow Pipelines跑训练任务结果80%的开发时间花在调试Kubernetes RBAC权限上而实际训练任务每月只运行3次。3. 核心模块拆解从数据到服务的六层手写实践3.1 数据摄取层用requestsSQLAlchemy构建“抗抖动”管道现成ETL工具如Fivetran擅长处理结构化数据库同步但AI项目常面临非标数据源爬虫API返回JSON嵌套过深、IoT设备上传的Protobuf二进制流、甚至Excel模板里人工填写的标注数据。这些场景下通用工具要么配置复杂要么容错能力弱。我们手写的数据摄取层核心原则是单次失败不阻塞整体流程错误数据隔离存储人工介入路径明确。以处理某医疗影像标注平台API为例每次请求前设置指数退避time.sleep(0.1 * 2**retry_count)避免触发对方限流响应解析用Pydantic v2定义严格schema字段缺失时自动填充None而非抛异常错误响应HTTP 4xx/5xx单独写入error_log表包含完整request headers、raw response body、timestamp成功数据经transform()函数清洗如DICOM文件路径标准化、标签映射字典查表再批量插入PostgreSQL。关键技巧在于错误隔离设计我们用两个独立的数据库连接池一个专用于主数据写入另一个专用于错误日志。这样即使主库因网络抖动超时错误日志仍能落盘确保问题可追溯。实测下来这套方案比Airflow调度相同任务的平均成功率高12%且故障时能直接查error_log表定位具体哪条记录、哪个字段出错无需翻查海量调度日志。3.2 特征工程层用DuckDB替代Pandas性能提升47倍的实战特征计算是AI pipeline中最易成为瓶颈的环节。某用户行为分析项目初期用Pandas处理2TB日志单次特征生成耗时6小时。切换至DuckDB后压缩至8分钟——不是因为DuckDB“更快”而是我们重新设计了特征计算范式放弃面向对象的DataFrame思维拥抱面向查询的SQL思维。具体做法所有原始日志按日期分区存入ParquetDuckDB直接读取SELECT * FROM data/*.parquet特征逻辑全部用SQL编写如COUNT(DISTINCT user_id) FILTER (WHERE event_type click)利用DuckDB的向量化执行引擎复杂逻辑拆分为多个CTECommon Table Expressions每步结果物化为临时表便于调试最终特征表用COPY TO features.parquet导出供训练脚本直接读取。为什么不用Spark因为我们的集群只有3台机器Spark的JVM开销和Shuffle网络传输反而拖慢小规模计算。DuckDB单进程内存计算启动零延迟且SQL语法对算法工程师更友好——他们不需要学RDD API只要会写GROUP BY就能上手。注意事项DuckDB默认不支持并发写入我们用文件锁threading.Lock控制多进程特征生成任务的写入顺序避免Parquet文件损坏。3.3 模型训练层PyTorch Lightning的“去框架化”改造PyTorch Lightning极大简化了训练循环但它的Trainer类隐藏了太多细节。当我们在训练一个长文本分类模型时发现验证集准确率震荡剧烈排查发现是Lightning默认的DistributedSampler在多卡训练时未正确处理最后一个batch的padding——它把不同长度的文本pad到同一长度导致GPU显存浪费而采样器又未按实际token数均衡分配batch。如果依赖框架这个问题可能永远找不到根因。我们的解决方案是保留Lightning的模块化设计但替换掉Trainer自定义DataModule保持数据加载逻辑LightningModule只负责模型定义和loss计算手写训练循环用torch.nn.parallel.DistributedDataParallel包装模型手动控制optimizer.step()和scheduler.step()时机关键是在validation_step中加入显式token计数按实际计算量加权平均指标梯度裁剪改用torch.nn.utils.clip_grad_norm_(model.parameters(), max_norm1.0, error_if_nonfiniteTrue)开启error_if_nonfinite参数第一时间捕获NaN梯度。这样做看似增加代码量但换来的是对训练过程的完全掌控。现在团队新人接手项目三天内就能读懂整个训练流程因为所有逻辑都在train.py一个文件里没有跨10个Lightning抽象类的跳转。3.4 模型服务层FastAPI TorchScript的极简推理服务LLM服务常陷入“过度工程化”陷阱非要上Kubernetes、Service Mesh、自动扩缩容。但多数AI应用的真实负载曲线很平缓——某智能合同审查API日均请求2万峰值QPS仅80。为这种场景配一套K8s集群运维成本远超业务价值。我们用FastAPI构建的服务结构极其简单# service.py from fastapi import FastAPI, HTTPException import torch from transformers import AutoTokenizer app FastAPI() model torch.jit.load(model.pt) # TorchScript导出的模型 tokenizer AutoTokenizer.from_pretrained(bert-base-chinese) app.post(/predict) def predict(text: str): if len(text) 512: # 显式长度校验 raise HTTPException(status_code400, detailText too long) inputs tokenizer(text, return_tensorspt, truncationTrue, max_length512) with torch.no_grad(): outputs model(**inputs) return {score: float(outputs.logits.softmax(dim-1)[0, 1])}关键设计点模型加载时机torch.jit.load()放在模块级服务启动时加载一次避免每次请求重复加载输入校验前置在tokenizer之前检查文本长度防止恶意超长输入触发OOM无状态设计不保存任何session状态水平扩容只需起多个进程用Nginx做负载均衡健康检查裸露GET /health直接返回{status: ok, model_loaded: True}不依赖第三方探针。实测对比同样模型vLLM服务占用GPU显存3.2GB我们的服务仅1.8GB因为省去了所有KV cache管理、连续批处理等复杂逻辑。当业务方提出“能否支持实时调整top_k参数”我们半小时内就在predict函数里加了个query参数而vLLM需要修改其backend配置并重启服务。3.5 监控告警层用OpenTelemetry注入“可解释性”AI服务最难监控的不是CPU或GPU利用率而是业务指标漂移比如推荐系统CTR突然下降但服务器一切正常。现成APM工具如Datadog APM能追踪HTTP请求链路但无法告诉你“为什么这个用户看到的推荐结果质量变差”。我们的方案是在关键业务逻辑点埋点在preprocess()函数开头记录原始输入哈希值hashlib.md5(text.encode()).hexdigest()在inference()后记录模型输出置信度分布outputs.logits.softmax(dim-1).cpu().numpy()在postprocess()后记录最终返回的标签和置信度。所有埋点数据通过OpenTelemetry SDK发送到Jaeger再用自定义脚本聚合分析当某类输入如含特定关键词的文本的平均置信度低于阈值自动触发告警对比新旧模型在同一组测试样本上的输出分布KL散度散度0.3时提示“模型行为偏移”。这种监控不是“系统是否活着”而是“系统是否按预期工作”。某次线上事故中监控发现某类长尾用户请求的置信度普遍偏低排查发现是预处理时未正确处理emoji编码而系统日志只显示“预测成功”若无此埋点问题可能持续数周。3.6 迭代闭环层用GitDVC构建“可重现”的实验仓库算法工程师最大的时间黑洞是“这个结果我上周跑出来过但现在找不到代码和数据了”。我们强制所有实验走DVCData Version Control流程原始数据存S3DVC跟踪其版本dvc add s3://bucket/data/train.csv训练脚本提交到Git每次实验打taggit tag exp-v1.2.3DVC生成.dvc文件记录数据/模型依赖dvc repro可一键复现整个pipeline。关键创新是将模型评估结果也纳入DVC训练完成后脚本自动生成eval_report.json含accuracy、f1、confusion_matrix并用dvc add eval_report.json纳入版本控制。这样在Git历史里每个commit不仅对应代码还对应确切的数据版本、模型权重、评估报告——技术负责人可以直接对比exp-v1.2.2和exp-v1.2.3的f1分数差异而无需登录服务器翻找日志。4. 实操避坑指南那些文档里不会写的血泪教训4.1 数据管道别信“Exactly-Once”先搞定“At-Least-Once”所有分布式系统文档都吹嘘“exactly-once processing”但AI数据管道里真正的敌人是语义重复。比如某用户行为日志API设计缺陷同一事件可能因网络重试被推送三次ID相同但timestamp差几毫秒。如果按ID去重会丢失真实的时间序列信息如果不去重特征统计就失真。我们的解法是双阶段去重摄取层用INSERT ... ON CONFLICT DO NOTHINGPostgreSQL保证物理层面不重复入库特征计算层用窗口函数ROW_NUMBER() OVER (PARTITION BY event_id ORDER BY timestamp)取最新一条。这样既避免数据丢失又保证业务逻辑一致性。教训是不要幻想中间件解决所有问题必须在业务层定义“什么是重复”。4.2 模型训练混合精度不是银弹小心梯度爆炸AMPAutomatic Mixed Precision能加速训练但某次我们在A100上启用torch.cuda.amp.autocast后验证loss突然变为NaN。排查发现是自定义的损失函数里用了torch.log()当输入接近0时FP16下直接溢出为inf而AMP的grad scaler未能及时检测。解决方案在log操作前加torch.clamp(x, min1e-7)关键计算步骤如softmax强制用torch.float32probs F.softmax(logits.float(), dim-1)开启torch.autograd.set_detect_anomaly(True)虽然慢但首次调试必开。经验混合精度是性能优化项不是基础功能必须在FP32训练稳定后再引入。4.3 模型服务GPU显存碎片化比OOM更致命某次上线新模型后服务偶尔报“CUDA out of memory”但nvidia-smi显示显存只用了60%。深入排查发现是PyTorch的显存分配器碎片化模型加载、tokenizer缓存、临时tensor创建释放不规律导致大块连续显存无法分配。根治方法启动服务时预分配显存torch.cuda.memory_reserved(device0)所有临时tensor用torch.empty()而非torch.zeros()避免初始化开销关键推理函数用torch.inference_mode()装饰禁用梯度计算节省显存。更狠的一招用torch.cuda.empty_cache()在每次请求后主动清理虽然有微小延迟但换来的是绝对稳定的显存使用。4.4 监控告警警惕“平均值幻觉”某推荐服务监控显示“平均响应时间100ms”但业务方投诉“部分用户卡顿严重”。抽样发现95%请求确实在50ms内完成但5%长尾请求耗时2秒以上——原因是某些超长文本触发了模型的递归解码而监控只采集了平均值。正确做法必须监控P95/P99分位数而非平均值对长尾请求单独打标在trace中添加is_long_tail: true标签告警规则设为“P99 500ms持续5分钟”而非“平均200ms”。记住AI服务的体验由最差的5%用户决定不是最好的95%。4.5 迭代管理DVC不是Git替代品而是补充曾有团队把所有代码文件都用DVC跟踪结果Git clone变慢十倍。DVC的定位很清晰只管大文件数据、模型、大型二进制不管代码逻辑。我们的约定Git管.py/.json/.md文件DVC管.parquet/.pt/.bin文件.gitignore里明确排除*.pt.dvcignore里明确排除*.py。违反此约定的PR会被CI自动拒绝。教训是工具链的威力来自约束而非自由。5. 工具选型决策树什么时候该“scratch”什么时候该“reuse”5.1 决策核心用“故障恢复时间”倒推技术选型我们不用抽象的技术指标如“是否云原生”而用一个硬指标MTTRMean Time To Recovery。假设某模块故障从告警触发到服务恢复需要多久如果MTTR 5分钟选成熟方案如用LangChain做简单RAG如果MTTR 5-30分钟需部分自研如用LangChain但重写retriever如果MTTR 30分钟必须from scratch如自研向量检索重排序。某知识库问答项目初期用ChromaDB一次磁盘满导致服务不可用恢复需手动清理索引并重建MTTR 42分钟。切换为自研的FAISSSQLite方案后磁盘满时自动触发LRU淘汰MTTR降至3分钟。5.2 六类场景的选型速查表场景类型推荐方案关键理由典型MTTR低频批处理每日1次Python脚本cron无运维负担故障时SSH登录直接重跑2分钟高并发实时APIQPS1000vLLM/Triton经过大规模验证的GPU调度器8-15分钟定制化数据清洗规则复杂DuckDBSQLSQL比Pandas链式调用更易审计和复用5分钟长周期训练24小时PyTorch原生Slurm避免Lightning的checkpoint兼容性问题10-20分钟多模型A/B测试自研路由服务FastAPI动态权重调整无需重启服务1分钟合规敏感场景金融/医疗全链路自研满足审计要求所有日志可溯源3分钟注意表格中的“典型MTTR”基于我们12个落地项目的实测数据不是理论值。选型时务必用自己团队的MTTR基线对标。5.3 技术债量化给每个“reuse”选项打分我们给每个第三方组件打三维度分数1-5分5为最高可调试性能否在5分钟内定位到具体函数可替换性替换为自研方案预计耗时人日许可证风险商用是否需额外授权例如LangChain得分可调试性2分抽象层太深可替换性3分重写chain逻辑约5人日许可证风险1分MIT协议。总分6分低于阈值8分触发“需逐步解耦”动作。这套评分法让技术选型从主观讨论变成客观决策。6. 从个人实践到团队规范如何让“from scratch”可持续6.1 文档即代码所有设计决策必须附可执行验证我们禁止写“建议使用DuckDB”而要求文档里必须有# 验证DuckDB性能优势的命令 duckdb -c CREATE TABLE t AS SELECT * FROM read_parquet(data/*.parquet); SELECT COUNT(*) FROM t; # 对比Pandaspython -c import pandas as pd; print(len(pd.read_parquet(data/*.parquet)))新成员入职第一周任务不是写代码而是执行所有文档里的验证命令确保环境一致。这消灭了“在我机器上是好的”这类扯皮。6.2 “Scratch”不是目的是手段建立三层抽象防火墙真正的工程能力体现在抽象层级的控制力L1基础设施层GPU驱动、CUDA版本——绝不自研用云厂商镜像L2AI中间件层模型加载、推理调度——按需自研保证可控L3业务逻辑层特征定义、策略规则——100%自研业务专属。某次GPU驱动升级导致PyTorch崩溃因为L1层我们用云厂商托管镜像运维团队30分钟内回滚到上一版驱动L2/L3层代码完全不受影响。这证明“from scratch”的价值不在L1而在L2/L3的隔离能力。6.3 持续验证文化每天自动运行“脆弱性测试”我们有个fragility_test.py脚本每天CI运行检查所有第三方包是否有安全漏洞pip-audit验证关键路径的性能退化对比昨日基准用模糊测试生成异常输入确认服务不崩溃如超长字符串、空JSON、特殊Unicode字符。这个脚本不产出新功能但过去一年拦截了17次潜在线上事故。它传递一个信号“from scratch”的终极目标不是写出多少代码而是让系统在未知冲击下依然可靠。我在实际落地中发现最有效的“from scratch”不是从零开始而是从删除开始——删掉所有当前不需要的抽象层只留下解决当下问题的最小可行代码。当业务增长带来新需求时再一层层加固。这种渐进式构建比一开始就设计“完美架构”更接近工程真相。最后分享个小技巧每次写完一个模块立刻问自己“如果明天这个模块的作者离职接手的人能在30分钟内理解并修改它吗” 如果答案是否定的代码就还没达到“from scratch”的及格线。