1. 从零搭建AI工程能力为什么我劝你别一上来就啃论文这两年“AI工程”这个词被炒得火热招聘网站上挂着“AI工程师”的岗位薪资一个比一个夸张很多人第一反应就是去啃Transformer论文、刷吴恩达的课、背各种注意力机制的公式。我自己也走过这条路说实话前三个月基本是在自我感动——论文看懂了七成真让我从零搭一个能跑起来、能上线、能扛住真实流量的AI系统我完全不知道从哪下手。ai-engineering-from-scratch这个标题核心讲的其实就是一件事把AI工程当成一门工程学科从最底层的能力开始一层一层往上搭而不是把它当成一门理论学科去背公式。它解决的是“我懂原理但做不出东西”这个最普遍的痛点适合所有想真正把AI落地的人——不管你是刚转行的后端、做数据分析想往上走的人还是已经在大厂里被要求“搞点AI”的普通开发。我自己的判断是AI工程和传统软件工程最大的区别不在于你会不会调模型而在于你要处理一堆不确定的东西数据是不确定的、模型输出是不确定的、成本是不确定的、延迟是不确定的。传统后端你写个接口输入A输出B测一遍就完事AI系统里同样的输入今天输出这个明天可能输出那个用户量一上来GPU账单能吓死你。所以“from scratch”要搭的不是模型本身而是围绕模型的那一整套工程能力。这篇文章我会按我实际踩过的顺序来讲先讲整体思路怎么设计再拆核心环节的细节然后给一套能直接抄的实操流程最后把我遇到过的坑整理成排查表。全程不整虚的都是能上手的东西。2. 整体设计思路AI工程能力到底该分几层2.1 为什么不能“先学模型再学工程”我见过太多人一上来就扎进模型微调结果连数据怎么清洗、怎么切分、怎么评估都搞不清楚。这就像你想盖楼先去研究外墙涂料什么颜色好看地基还没打。AI工程的能力是有依赖关系的下层不稳上层全是空中楼阁。我的分层逻辑是这样的从下往上第一层数据工程能力。包括数据采集、清洗、去重、标注、切分、版本管理。这一层决定了你模型效果的天花板数据烂模型再牛也白搭。第二层模型调用与推理能力。不是让你从零训练大模型而是学会怎么调用、怎么封装、怎么控制成本和延迟。第三层评估与实验能力。怎么判断一个改动是变好了还是变坏了怎么设计A/B实验怎么建评估集。第四层服务化与运维能力。怎么把模型包装成稳定的服务怎么做监控、降级、限流、缓存。第五层应用编排能力。把上面几层串成一个真正解决业务问题的产品。这个顺序不能乱。我试过跳过第一层直接搞第四层结果服务搭得挺漂亮一上线发现数据里全是脏东西输出惨不忍睹返工重来。2.2 方案选型为什么我推荐“薄封装 强评估”在具体技术选型上市面上有两派一派是重度框架派什么都用现成的大框架LangChain、LlamaIndex一把梭另一派是纯手写派什么都自己撸。我的经验是走中间路线薄封装 强评估。框架可以用但只用来做最基础的胶水核心逻辑自己掌控。原因很简单AI这块变化太快了今天框架的某个抽象明天可能就过时了你被框架绑死迁移成本极高。而评估体系是你自己的资产换什么模型、换什么框架都用得上。举个具体的例子很多人用框架的“链式调用”把整个流程串起来看起来很优雅。但一旦某个环节出问题你根本不知道是哪一步的锅日志被框架吞了。我后来改成自己写一个简单的编排层每一步的输入输出都落盘排查问题的时候一目了然。多写的那点代码在调试阶段省下的时间十倍都不止。2.3 成本与延迟被大多数人忽略的设计约束新手做AI项目最容易犯的错就是只盯着效果不看成本和延迟。我见过一个团队demo阶段用最大的模型效果惊艳老板拍板上线结果用户量一上来一个月账单几十万延迟三秒起步用户直接跑光。所以在设计阶段就要把这两个约束摆上台面。我的做法是分级策略简单请求走小模型或规则复杂请求才走大模型。大概70%的请求其实不需要大模型。缓存策略相同或相似的输入直接命中缓存尤其是那些高频重复的问题。异步策略非实时场景全部走异步队列用户不用干等。这些不是上线后才考虑的优化而是一开始就要设计进去的架构决策。等你系统成型了再改成本高得离谱。3. 核心环节拆解数据、调用、评估三根支柱3.1 数据工程脏数据是怎么毁掉整个项目的数据这块我踩的坑最多展开讲几个关键点。第一去重比清洗更重要。很多人花大力气做格式清洗却忽略了重复数据。训练集和评估集如果有重叠你的评估结果会虚高得离谱上线直接打脸。我现在的标准流程是先做精确去重哈希再做近似去重SimHash或MinHash最后才做格式清洗。第二切分要按“语义单元”而不是“固定长度”。早期我按固定字符数切分文档结果一句话被切成两半模型理解得莫名其妙。后来改成按段落、按标题层级切效果立竿见影。如果文档结构混乱就用语义相似度做边界检测。第三评估集必须人工过一遍。自动生成的评估集看着量大但里面藏着大量模棱两可、答案不唯一的样本会严重干扰你的判断。我一般会人工精标200到500条高质量评估样本比一万条自动生成的都管用。注意数据版本管理一定要做。每次改数据都记下版本号否则你根本复现不了两周前那个“效果特别好”的实验。3.2 模型调用封装层该怎么写才不坑自己模型调用看着简单一个API请求的事但工程化之后问题一堆。我总结几个必须处理的点。超时和重试。模型接口偶尔抽风是常态必须设超时我一般设30秒超时后重试但重试要有上限最多2次并且要区分可重试错误和不可重试错误。参数错误你重试一百次也没用。限流和并发控制。别以为你买了高配额就能无限并发实际上一旦并发上去错误率飙升。我一般用信号量控制并发数配合指数退避。输出解析的健壮性。如果你让模型输出JSON一定要做容错解析。模型经常会多输出一句“好的以下是结果”或者少个括号。我的做法是先做正则提取再尝试解析失败就走降级逻辑绝不直接抛异常。成本追踪。每次调用都记录token消耗按天汇总。这个数据是你后续优化的依据没有它你根本不知道钱花哪了。下面是我常用的一个调用封装骨架Python写的可以直接参考import time import json import logging from typing import Any logger logging.getLogger(__name__) class ModelClient: def __init__(self, max_retries2, timeout30, max_concurrency8): self.max_retries max_retries self.timeout timeout self.semaphore threading.Semaphore(max_concurrency) def call(self, prompt: str, **kwargs) - dict: for attempt in range(self.max_retries 1): try: with self.semaphore: start time.time() raw self._request(prompt, timeoutself.timeout, **kwargs) latency time.time() - start self._log_cost(raw, latency) return self._parse(raw) except RetryableError as e: if attempt self.max_retries: raise time.sleep(2 ** attempt) except NonRetryableError: raise这段代码的核心思想是把不确定性关进笼子里。超时、重试、并发、成本全部在封装层解决上层业务代码只管调用不用操心这些。3.3 评估体系没有评估就没有工程我一直说AI工程和炼丹的区别就在于有没有评估体系。没有评估你所有的改动都是玄学。评估分三个层次单元评估针对单个环节比如检索环节的召回率、生成环节的准确性。端到端评估整个流程跑一遍看最终输出质量。线上评估真实用户的行为数据点击、采纳、反馈。我建议新手从端到端评估做起先建一个50到100条的黄金测试集每次改动都跑一遍记录分数。这个习惯一旦养成你的迭代速度会快得惊人因为你知道每一步是进步还是退步。评估指标的选择也有讲究。分类任务看准确率和F1生成任务看人工评分或模型评分用强模型评弱模型检索任务看召回和排序。别用一个指标打天下。评估层次样本量频率主要指标单元评估100-500每次改动召回率、准确率端到端评估50-100每次发版综合评分、通过率线上评估全量持续采纳率、满意度4. 实操流程从零到一搭一套能跑的AI系统4.1 环境与依赖准备先把基础环境搭起来。我的习惯是永远用虚拟环境别在系统Python里乱装东西。依赖管理用requirements.txt或者poetry都行关键是锁版本AI这块库更新太快不锁版本迟早出事。python -m venv venv source venv/bin/activate pip install fastapi uvicorn httpx pydantic numpy pandas pip freeze requirements.txt核心依赖就这几个fastapi做服务httpx做异步请求pydantic做数据校验。别一上来装一堆框架够用就行。4.2 数据管线的搭建步骤数据管线我一般分四步走采集把原始数据落到对象存储保留原始版本永远不要直接改原始数据。清洗去重、去噪、格式统一。这一步写成脚本可重复执行。切分按语义单元切分输出结构化格式比如JSONL。入库写入向量库或搜索引擎建立索引。每一步都要有日志和统计比如清洗掉了多少条、切分后平均长度多少。这些数字是你判断数据质量的依据。4.3 服务化把模型包装成稳定接口服务化这块我用FastAPI搭一个最简单的接口核心是输入校验、超时控制、错误处理三件套。from fastapi import FastAPI, HTTPException from pydantic import BaseModel app FastAPI() class QueryRequest(BaseModel): text: str user_id: str app.post(/query) async def query(req: QueryRequest): if not req.text.strip(): raise HTTPException(status_code400, detailempty input) try: result await pipeline.run(req.text) return {result: result} except TimeoutError: raise HTTPException(status_code504, detailtimeout) except Exception as e: logger.exception(pipeline failed) raise HTTPException(status_code500, detailinternal error)注意这里的错误处理永远不要把内部异常直接暴露给用户也不要吞掉异常不记录。每个异常都要有日志方便排查。4.4 监控与降级上线才是真正的开始上线之后监控是命根子。我必看的几个指标QPS和延迟分布不只看平均延迟要看P95和P99长尾才是用户体验的杀手。错误率按错误类型分类超时、限流、解析失败分开统计。成本按天、按接口统计token消耗。业务指标采纳率、满意度、转化率。降级策略也要提前设计好。模型服务挂了怎么办我的做法是准备一个规则兜底虽然效果差但至少服务不中断。缓存命中率高的场景直接返回缓存结果。提示监控告警的阈值不要设太敏感否则天天被误报轰炸最后你会直接忽略告警那监控就白做了。5. 常见问题与排查技巧实录5.1 效果忽好忽坏怎么排查这是最典型的问题。我的排查顺序是先看数据是不是输入分布变了有没有脏数据混进来再看模型是不是模型版本更新了接口有没有静默变更最后看评估评估集本身有没有问题指标计算逻辑对不对我遇到过一次效果突然下降查了半天发现是上游数据源改了字段名导致某个关键信息没传进来。这种问题不看数据根本发现不了。5.2 成本失控的常见原因成本突然飙升通常是这几个原因缓存失效缓存key设计不合理导致命中率暴跌。重试风暴某个错误触发大量重试token消耗翻倍。输入变长用户输入越来越长或者检索返回的上下文越来越多。并发失控没有并发限制请求堆积。排查的时候先看token消耗的分布定位到具体是哪个环节吃掉了预算。5.3 排查速查表现象可能原因排查动作延迟飙升并发过高、模型变慢看P99延迟、并发数错误率上升接口变更、限流看错误类型分布效果下降数据漂移、模型更新对比评估集分数成本暴涨缓存失效、重试看token消耗分布输出格式错乱解析逻辑脆弱看原始输出日志5.4 几个我踩过的坑坑一评估集泄露。有次我把训练数据误混进评估集分数虚高上线才发现。后来我强制要求评估集和训练集做交叉去重检查。坑二日志打太多。为了排查问题我把每次请求的完整输入输出都打日志结果磁盘一周就满了还拖慢了服务。后来改成采样记录只对错误请求和1%的正常请求打详细日志。坑三忽略冷启动。服务刚上线缓存是空的所有请求都打到模型延迟和成本都爆炸。后来我做了缓存预热上线前先把高频请求跑一遍。坑四版本管理混乱。模型、数据、代码三个版本没对齐出了问题根本复现不了。现在我用一个统一的版本号串起来任何一次实验都能精确复现。6. 能力进阶从能跑到跑得好6.1 什么时候该上微调很多人一上来就想微调我的建议是先把提示词工程和检索做到极致再考虑微调。微调的成本很高数据准备、训练、评估、部署每一步都是坑。而且微调之后模型的通用能力可能会下降你得重新评估所有场景。真正需要微调的场景通常是任务非常垂直、格式要求极严、或者对延迟和成本极度敏感小模型微调后能替代大模型。6.2 工程能力的复利效应AI工程这块最值钱的不是你会用某个模型而是你有一套可复用的工程能力。数据管线、评估体系、服务框架、监控告警这些东西搭一次后面做任何AI项目都能直接用。这就是复利。我现在的做法是维护一套内部模板新项目直接套模板两天就能跑起来一个demo剩下的时间全花在业务逻辑和效果优化上。这才是“from scratch”真正的价值——不是每次从零开始而是把从零开始的经验沉淀成资产。6.3 给不同阶段的人的建议如果你是刚入门别贪多先把数据清洗和评估这两件事做扎实这两块是地基。如果你已经能跑通流程重点放在成本和延迟优化上这是从demo到产品的分水岭。如果你已经在带团队把评估体系和监控体系标准化让每个人都能复用。我个人在实际操作中的体会是AI工程最难的不是技术本身而是建立一套对抗不确定性的工作方法。模型会变、数据会变、需求会变唯一不变的是你那套评估、监控、迭代的流程。把这套流程跑顺了换什么模型你都不慌。最后再分享一个小技巧每次做重大改动之前先把当前版本的评估分数和关键指标记下来改完之后对比。这个习惯看起来简单但能帮你避免90%的“感觉变好了其实变差了”的误判。