我不想绕弯子这篇东西的标题ai-engineering-from-scratch就是我这两年摸爬滚打最真实的写照。从最早用Python调接口到后来带小团队把AI能力塞进正式产品线再到被逼着从头捋清楚AI工程和调模型到底差在哪这条路我踩过的坑不比任何人少。如果你正处在模型能跑通demo、但一上生产就翻车的阶段或者你想系统化地理解AI工程到底在解决什么问题这篇内容应该能帮你省掉不少试错时间。很多人以为AI工程就是把训练好的模型包装成一个HTTP接口或者写几个Prompt调一调大模型。真不是这么回事。AI工程的核心矛盾是不确定性——模型输出不是确定性的数据分布不是静态的效果好坏不能只看准确率。这导致传统的软件工程方法论直接照搬过来会水土不服你必须有自己的一套设计、开发、验证、上线、监控的闭环。下面我会从思路拆解开始再到工具选型、完整实操、问题排查最后聊点学习路径尽量把从零到一这条路上的关键节点都说到位。1. 先搞清楚AI工程到底是什么不是什么1.1 AI工程和传统软件开发差在哪传统软件工程里一个功能模块的输入输出是确定的你传两个整数进去加法函数就该返回它们的和数据库连不上异常就抛出来处理逻辑清清楚楚。但AI工程面对的是概率系统。你给一个文本分类模型一万条差不多的请求它不可能百分之百都分对大模型写一段总结同一个Prompt这次和下次的用词都可能不一样。这种不确定性不是bug而是模型的天性。这就带来三个传统开发不太会遇到的问题第一你没法用用例全过来判定功能完成因为模型根本没有全过这回事只能定一个可接受的指标阈值第二系统的行为会随着数据分布变化而漂移今天效果不错下周用户行为变了指标可能莫名下滑第三错误是不可避免的而你的系统设计必须考虑模型出错之后怎么兜底而不是假设它永远正确。我见过太多团队把调接口当成AI工程的全部结果上线后发现线上效果和离线测试差出一大截所有人都懵了。1.2 AI工程不是机器学习研究机器学习研究关心的是模型结构怎么改、Loss怎么设计、收敛效果如何核心目标是提升模型性能的上限。AI工程关心的是这套系统在真实环境里能不能稳定地产生业务价值核心目标是把不确定的模型能力封装成确定可信的服务。简单说研究是找更好的模型工程是让现有的模型好好干活。这意味着AI工程师要操心的东西比算法工程师更杂数据管道是否稳定、特征和标签有没有对齐、模型版本怎么管理、推理服务的延迟和吞吐怎么权衡、线上效果怎么监控、模型需要重新训练的时候怎么平滑切换。这些事没有一篇论文会教但任何一个AI系统落地过程中都躲不开。我自己带队做项目时最深的感受是让模型在离线评测里涨0.5个点远不如把上线回滚机制做扎实有价值因为后者决定了你在生产环境里敢不敢迈出那一步。1.3 AI工程的关键工作流长什么样总结下来一个完整的AI工程闭环至少包含六个环节需求定义、数据准备、模型选型与开发、效果评测、部署上线、监控迭代。这六个环节不是一次性走完就结束的而是一个不断循环的飞轮。需求定义阶段你要把业务诉求翻译成清晰的AI任务并确定可量化的指标数据准备阶段要解决数据从哪来、怎么清洗、如何标注、如何切分的问题模型选型与开发阶段要决定是用大模型API、开源模型微调还是传统机器学习模型效果评测阶段要有离线指标和线上指标两套体系缺一不可部署上线阶段要考虑服务化方案、资源成本、故障预案监控迭代阶段要盯住效果指标和数据分布的变化决定什么时候触发重新训练或策略调整。后续我会把每个环节的操作细节都展开讲这里先记住一个结论没有一个环节可以跳过跳过的每一步都会在后面的生产事故里等你。2. 从零搭建AI工程的基础设施和工具链2.1 先搭好环境别急着跑模型很多人入门AI工程的第一反应是赶紧装个深度学习框架、跑通一个手写数字识别这没错但离工程还差很远。工程化的第一步是把你反复要用的东西固定下来形成可复现的流水线。我自己的标准配置是Python版本管理用pyenv或conda虚拟环境用venv或Poetry依赖锁定到具体版本代码管理用Git配合一个团队统一的远程仓库数据集要纳入版本管理像管理代码一样管理数据轻量方案可以用DVC或者简单一点直接在云端存储里按日期和版本号命名所有实验要记录参数、代码commit号、评估结果WandB、MLflow都可以再不济也要在代码里写好日志。这一套东西看起来琐碎但等你要回滚到三个月前某个效果还不错的实验配置时就会发现它有多值钱。下面是我常用的一个项目初始化脚本片段做的事情就是创建项目目录、初始化Git仓库、创建虚拟环境并安装基础依赖保证每个新项目都在同一套起跑线上# 创建项目骨架 mkdir -p ai-engineering-demo/{data,src,models,notebooks,tests} # 初始化虚拟环境和基础依赖 cd ai-engineering-demo python -m venv .venv source .venv/bin/activate pip install --upgrade pip setuptools wheel pip install pandas numpy scikit-learn jupyter pip install transformers4.30 datasets2.10 accelerate0.20 pip install mlflow dvc这段脚本里的每个选择都有理由Jupyter适合快速探索但正式训练代码必须写成.py模块MLflow负责记录实验参数和指标后面查历史效果全靠它DVC负责跟踪数据集版本防止数据集被误改之后说不清楚。先花半天时间把脚手架搭好后面所有环节都会顺畅得多。2.2 模型选型开源、商用API还是自研模型选型是AI工程里最纠结的决策之一。核心维度有三个效果上限、成本上限、可控性要求。我一般会给团队画一张对比表把需求往里套维度商用大模型API开源可商用模型传统小模型效果天花板高通用能力强中高需微调或提示工程低依赖特征工程推理成本按token付费长期贵自部署有GPU成本极低CPU即可数据安全取决于服务商协议私有化部署可控完全可控迭代速度快无需训练需训练或调参需特征迭代适用场景通用对话、内容生成、复杂理解垂直领域、定制任务高并发、低成本分类/打分这张表不是绝对的但能帮你快速圈定方向。我的经验是能用简单模型的绝不上大模型能用API的先别急着微调。比如做垃圾评论识别传统机器学习加特征就能到95%以上准确率何必引入大模型增加成本和延迟但如果你要做客服对话的开放域理解、或者生成型任务那大模型就是必须的。选型时还要注意一个反直觉的点商用API的效果通常比开源模型要好但上生产之后你可能会被单次调用延迟和费用绑住手脚所以务必在项目初期就跑通一个带真实流量的压测而不是只在评测集上比分数。2.3 Prompt、微调和RAG怎么选选定大模型之后紧接着的问题是怎么让它适配你的业务现在业内主要三条路Prompt Engineering、微调Fine-tuning、检索增强生成RAG。三者的关系我类比过很多次Prompt是给一个成熟员工写工作说明微调是送员工去专门的培训班RAG是给员工配一个资料库随时翻阅。Prompt Engineering成本最低、见效最快适合任务逻辑清晰、只要把已有能力引导出来的场景。但它的上限也受限于模型本身能力而且在实际业务里Prompt稍微改几个字线上效果就抖得厉害所以必须要有自动化评测保护。微调适合任务风格、输出格式有强约束的场景比如让模型按照你们公司特定的报告模板输出或者学会某种专业领域的术语体系。RAG适合知识密集型任务比如企业内部知识库问答——模型不需要记住每个文档细节它只需要学会从哪些资料里找答案、怎么组织答案。我见过不少团队一上来就想微调其实业务场景明明RAG更合适白白烧了很多训练费用。新手做方案时我建议按Prompt先跑、RAG增强、微调兜底的顺序去试每一步都有数据支撑了再往下走不要拍脑袋。3. 核心环节实操一个AI应用从0到1的实现3.1 需求定义把业务语言翻译成模型任务这一步看似简单实际上最容易埋雷。业务方跟你说做个智能助手提高客服效率你直接开始选模型、写Prompt大概率做到一半发现方向偏了。正确做法是把这句话拆清楚智能助手要解决什么问题是回答常见问题、辅助人工客服写回复还是自动分类工单目标用户是谁输入是什么形式的输出要求是什么格式效果好坏用什么指标衡量——是回答准确率、用户满意度、还是客服处理时长下降比例拿一个我实际做过的工单分类项目举例。业务方的原始需求是帮我们把工单自动分给对应部门。如果直接当一个文本分类任务来做就会掉进一个经典陷阱只看分类准确率。我们和业务方对齐后发现真正重要的是分错了要付出多大代价——把紧急投诉工单分到普通咨询和把普通咨询分错到投诉后果完全不同。所以最终把任务定义成了带代价矩阵的多分类问题评测指标也从单纯准确率改成了加权F1。这就是需求定义阶段的价值它决定了后面所有技术工作的方向方向偏了模型再强也是白搭。3.2 数据准备清洗、标注和切分数据环节占掉一个AI项目百分之六七十的时间一点不夸张。很多新手直接在网上下个公开数据集就开始训练跑完拿准确率说事这在上生产时是致命的。真实业务数据几乎都有这些问题类别分布极度不平衡少数类样本少到模型根本学不到标签质量参差不齐标注员的判断标准不一致数据里混着大量无关信息比如工单标题里的标点符号、语气词。清洗这一步我通常分成两轮第一轮是规则清洗去重、去无效字符、过滤空文本、统一格式第二轮是人工抽检从清洗后的数据里抽一批看分布确认哪些样本类别边界模糊。标注环节小团队没有专职标注员很正常但至少要保证两个人独立标注同一批样本然后算标注一致性不一致的地方开会讨论定标准。数据切分要格外小心涉及时间序列的数据必须按时间切分不能用随机切分否则你用未来的数据预测过去指标会虚高上线就现原形。我自己踩过这个坑一个预测模型离线测试AUC有0.92上线后表现一团糟后来排查发现就是切分时把同客户不同时间段的数据混进了训练集和测试集数据泄漏导致指标失真。3.3 基线先行先搭一个最简单的可用版本选好模型方案之前强烈建议先花一两天搭一个最简单的基线。基线的作用不是追求最佳效果而是给你一个对比的锚点同时提前暴露数据管道和服务化的坑。文本分类这种任务基线可以是一个TF-IDF加逻辑回归十几行代码搞定生成类任务基线可以是直接把Prompt工程写到最简单的程度配好评测脚本。我习惯把基线代码写成独立模块目录结构大致如下src/ baseline/ train_baseline.py # 训练基线模型 predict_baseline.py # 加载模型做预测 evaluate/ offline_evaluate.py # 离线评测脚本 serve/ app.py # 推理服务 data/ train.csv # 训练集 valid.csv # 验证集 test.csv # 测试集# src/baseline/train_baseline.py from sklearn.feature_extraction.text import TfidfVectorizer from sklearn.linear_model import LogisticRegression from sklearn.pipeline import make_pipeline import pandas as pd train_df pd.read_csv(data/train.csv) # 用TF-IDF做文本向量化加上逻辑回归分类 model make_pipeline( TfidfVectorizer(max_features50000, ngram_range(1, 2)), LogisticRegression(max_iter1000, C1.0) ) model.fit(train_df[text], train_df[label]) import joblib joblib.dump(model, models/baseline.joblib) print(baseline trained, classes:, model.classes_)跑通这个基线之后你就有了三样东西一条完整的数据管道、一把评估指标的尺子、一个随时可以部署兜底的模型。后续你上BERT、上大模型API都可以拿基线的效果做参照物看提升到底值不值那个成本和复杂度。这条实践准则我后来每个项目都坚持用从来没后悔过。3.4 评测体系离线指标和线上指标缺一不可评测是整个AI工程里最容易被低估的环节但也是决定项目生死的一环。离线评测负责回答模型能力够不够线上监控负责回答系统在真实环境里稳不稳定两者必须联动。离线评测的关键是评测集要贴近真实分布。不要只在随机切分的测试集上测还要单独构建困难样本集、边界样本集、不同时间段的样本集分别看效果。指标选择上分类任务除了准确率还要看精准率、召回率、F1以及代价矩阵加权后的损失生成类任务目前最常用的还是人工评测为主、自动指标为辅因为BLEU、ROUGE这类指标和人类的真实感受经常对不上。我见过一个内容摘要项目自动指标分数很高但业务方一看就摇头——摘要漏掉了最关键的结论。后来我们设计了针对性的规则量化关键信息覆盖率才算把评测标准和业务预期对齐。线上监控要有两个层面的指标效果指标比如预测的置信度分布、用户反馈数据、业务转化率健康指标比如请求延迟、服务成功率、模型响应时长。上线前就要定义好效果回退的触发条件比如分类置信度分布明显偏移、某类别的请求占比突变立刻报警并准备回滚到上一版本。这个体系建立起来AI系统才算真正有了仪表盘。3.5 部署上线从离线模型到稳定服务模型训练好了、评测过了接下来就是把它变成一个能对外提供稳定服务的系统。这里有几个大坑我一个个踩过来。第一模型推理和训练的环境要解耦。训练时用PyTorch、TF随便推理服务最好单独做一个轻量化的环境避免把一堆训练依赖暴露在生产容器里。模型可以导出成ONNX或TorchScript再用FastAPI包一个接口部署到容器里。第二要设置合理的超时和重试机制。大模型API可能几秒才返回但你的业务接口不能跟着等几秒常见做法是异步化先返回一个任务ID结果好了再回调或者前端轮询。第三要做灰度发布。先切5%流量到新模型盯线上指标没问题再逐步放量。这个机制能帮你避免一次发布把所有用户都坑了。第四日志要打足。线上请求的输入、输出、置信度、模型版本、耗时全部记录下来后面排查问题全靠这些日志。再附一个最简推理服务的示例展示如何用FastAPI把上面训练好的基线模型包成服务# src/serve/app.py from fastapi import FastAPI, Request import joblib app FastAPI() model joblib.load(models/baseline.joblib) app.post(/predict) async def predict(req: Request): body await req.json() text body.get(text, ) proba model.predict_proba([text])[0] pred model.classes_[proba.argmax()] return {label: pred, confidence: float(proba.max())}这里有几个细节接口返回里除了预测结果还带上置信度方便上层做阈值控制和人工介入预测函数用async写方便未来接异步任务生产环境部署时前面还要套一层网关做限流、鉴权、负载均衡这些属于基础设施项目初期可以先用云平台的API网关凑合但架构上要留好位置。4. 常见问题与排查技巧实录4.1 离线指标很高、线上效果拉胯这是AI工程师被问得最多的问题没有之一。原因通常出在三个地方数据泄漏、分布漂移、评测集过拟合。数据泄漏就是我在前面提到的切分不当训练集里混进了测试集的信息分布漂移是线上真实数据和训练数据差异太大比如你训练数据是电商评论上线后来了大量新品类评论模型没见过自然乱来评测集过拟合是你反复在同一个测试集上调模型不知不觉把测试集的特征也学进去了。排查思路也有一个固定顺序先查线上请求日志里的文本分布和训练集分布是否一致可以用简单的文本长度、词频分布做个对比再检查特征和标签是否有泄漏通道比如是否把目标值的某个间接表示也当成了特征最后换一批新的、没参与过模型调优的样本重新评测看指标是否还在可接受范围。我在工单分类项目里踩过一次数据泄漏原因搞笑又典型数据里的工单归属部门字段在收集时就已经是人工填的正确标签而我处理特征时顺手把它也灌进去当特征了模型等于看着答案做题离线指标当然好看到飞起。4.2 Prompt稍微改几个词效果波动巨大这是大模型应用的常态也让很多从传统开发转过来的人抓狂。原因在于Prompt的措辞会影响模型对任务的理解和输出的格式偏好而这种影响是非线性的。解决办法不是找到完美Prompt一劳永逸而是建立一套Prompt版本管理和回归评测机制。我的具体做法是所有Prompt写成一个独立的配置文件或模板文件纳入Git版本管理每个Prompt版本都在固定的评测集上跑一遍记录各项指标上线前对比新旧Prompt的评测结果有提升才合并。这样做的好处是当线上效果波动时你能快速确认到底是Prompt变化引起的还是数据分布变化引起的。我团队里有个同事很喜欢在Prompt里加语气词来调教模型改了十几次每次人工看都感觉好一点但用评测集一测指标上上下下根本没有显著差异。有了评测机制之后这类凭感觉调参的行为就大大减少了——不是压制创造力而是让每份创造力都有交代。4.3 模型服务越来越慢成本也越来越高上线初期一切正常跑了一个月后延迟明显上升、账单也吓人。这类问题多半是流量增长但并发设计不合理或者是某些恶意/异常请求触发了超长生成。我排查时会先看监控面板是P99延迟飙升还是平均延迟飙升如果是P99暴涨大概率是长尾请求拖慢的比如大模型遇到某些生僻输入时生成特别长的内容如果是平均也在涨那要考虑资源是否到瓶颈了。对应的优化手段有几个一是给大模型服务设置最大token数上限防止输出无限膨胀二是做结果缓存重复或相似的问题直接命中缓存三是批量推理把同时段的请求攒起来一次性喂给模型GPU利用率会高很多四是对业务请求做分级简单问题走小模型、复杂问题才上大模型成本能降一半。我有个项目就是用第四招把每月推理成本压低了差不多一半效果还没怎么变——这个收益不比你调模型涨两三个点来得差。4.4 常见问题速查表现象可能原因排查方向解决建议离线指标高、线上差数据泄漏/分布漂移/评测过拟合检查特征与标签泄漏、对比线上文本分布重新切分数据、扩充训练集分布、更新评测集模型返回结果不稳定采样参数过高/Prompt不够明确检查生成参数、Prompt评测调低temperature、固定随机种子、结构化输出分类置信度普遍偏低类别边界模糊/训练数据冲突抽样检视标签质量清洗标注数据、增加边界样本、引入人工兜底推理延迟波动大长尾请求/资源瓶颈看P99延迟、请求长度分布限制输出长度、缓存、流量分级模型效果随时间下降数据漂移、业务变化监控数据分布指标周期性重新训练、制定自动触发重训机制这张表是我压箱底的排查清单每次线上异常我都会先过一遍能覆盖掉八成的问题。剩下两成靠的就是一套完整的日志和监控体系让问题可以被定位而不是靠猜。5. 从工程到产品测试、协作和持续迭代5.1 AI系统的测试策略不能只用单元测试传统软件开发讲究测试金字塔单元测试多、集成测试次之、端到端测试少。AI系统同样要写单元测试比如数据清洗函数对不对、特征计算是否符合预期这些逻辑性代码必须测。但模型本身的正确性没法用断言去测所以还需要一套专门的模型行为测试给模型输入一批构造好的边界样本和对抗样本断言它的输出在预期范围内。比如一个文本审核模型你要构造色情、暴力、正常、擦边这四类样本分别断言模型输出是否落在对应的类别再比如工单分类模型你要构造一个超长文本、一个带大量特殊符号的文本、一个空文本验证服务的容错能力。这些测试本质上是把模型应该有什么样的行为固化成可执行的断言每次更新模型或Prompt时自动跑一遍能防止新版本把老功能搞坏。我见过不止一次新Prompt把主任务效果调好了但某个边角场景直接被搞崩没有行为测试根本发现不了。5.2 跨角色协作AI工程师不能只会调模型一个AI项目能不能落地很大程度取决于协作机制。在我带项目的经验里最容易出问题的两个协作节点是AI工程师和业务方之间、AI工程师和数据工程师之间。和业务方协作核心要解决指标语言的问题——你不能只汇报准确率要用业务方听得懂的少投入多少人力、处理速度提升几倍、用户满意度变化来讲和数据工程师协作核心要解决数据口径的问题——模型用的标签口径、特征口径必须和数据仓库里的口径对齐否则连数据质量好坏都判断不了。AI工程师的日常职责其实很杂要写代码要设计评测方案要盯监控要和产品经理对需求甚至还要自己动手清洗数据。我经常和团队里的新人强调AI工程不是一条道走到黑的算法岗它本质上是个系统工程师的角色你需要的是把模型能力嵌入业务系统的全局视野而不是只在模型结构里精雕细琢。5.3 持续迭代让AI系统越用越聪明AI系统上线不是终点而是迭代的起点。迭代的核心机制是数据回流把线上产生的真实请求、真实反馈收集起来清洗后反哺到训练数据里定期更新模型。比如客服助手上线后用户对机器人回答点有用还是没用这些反馈就是最好的标注信号再比如内容推荐系统用户点击与否就是天然的标签。具体操作上要注意几个原则回流数据要打上时间戳和版本号方便追溯要定期抽样人工复核因为用户的隐式反馈也有噪声重训要有固定的节奏可以按月或按周但每次重训前必须跑一遍完整的离线评测和上线前的行为测试。我见过一些团队模型上线后三个月不管效果跌得惨不忍睹才想起来更新这时候数据都脏了排查成本极高。把迭代节奏固定下来变成流水线的一部分比等着出事故再救火要高效太多。6. 学习路径从零开始怎么成为AI工程师6.1 先打基础编程、数学和机器学习概念如果你是完全零基础我的建议路径是这样的第一步掌握Python编程至少能熟练处理文件、列表、字典、函数、类能用Pandas做基本的数据处理这个阶段大概需要两到三个月别贪快写代码的熟练度是后面所有工作的地基。第二步补机器学习的核心概念有监督、无监督、过拟合、欠拟合、交叉验证、评估指标这些跟具体框架无关是最底层的思维方式。第三步理解深度学习的基本原理人工神经网络、反向传播、优化器、损失函数推荐先用手写一个简单的两层网络来消化原理再上手PyTorch或TensorFlow。数学要不要深究我的看法是线性代数和概率统计的基本概念必须有比如向量、矩阵乘法、分布、条件概率这些在理解和调参时都会用到但微积分和高等数学不必钻太深工作中直接调API的场景远多于推导公式的场景。别被数学不好不能学AI吓住工程岗对数学的要求远没有研究岗那么高。6.2 掌握工程化武器Docker、CI/CD、监控AI工程师和算法工程师拉开差距的地方恰恰是工程化能力。你不需要成为运维专家但以下工具至少要熟练Docker能把模型服务打包成镜像到处跑CI/CD流水线让代码变更和模型更新能自动化测试、自动化发布监控系统能搭建基本的指标采集和报警比如Prometheus加Grafana的组合日志系统知道怎么集中收集和检索线上日志。我的建议是找一个真实的项目把这些工具全部用一遍。比如把你训练好的模型用Docker打包写一个CI流水线每次代码push自动跑单元测试和行为测试再写一个监控指标把请求量、延迟、置信度采集起来画成面板。这条路走通了你的工程化能力就已经超过市场上很大一部分自称AI工程师的人了。6.3 Prompt Engineering、Agent与RAG跟着大模型实践走现在的大模型应用开发绕不开Prompt Engineering我的建议是你把它当成一项基本功来练。很多教程都在讲各种花哨的Prompt技巧但真正核心的就几条指令要清晰具体、少让模型猜给出输入输出的示例few-shot把复杂的任务拆分成多个简单的步骤要求模型先推理再回答chain-of-thought。这些技巧各有适用场景必须配上评测来看效果而不是凭感觉判断。RAG是目前落地最广的大模型应用架构之一值得系统学习。核心流程是文档切块、向量化、建索引用户提问时检索相关块拼进Prompt让模型基于检索结果回答。这里的技术难点不在模型而在切块策略、检索质量、重排序等工程细节上。Agent的概念这两年也很热本质上是用大模型来做规划和工具调用多Agent协作可以处理更复杂的任务。我的建议是先把单个Agent的能力边界摸清楚再考虑多Agent的编排否则项目很容易失控。6.4 做一个完整的端到端项目这是最快的成长方式学AI工程最忌讳只看书不动手。我的经验是选一个你身边真实存在的问题完整地走一遍前面讲的六个环节——需求定义、数据准备、模型选型与开发、效果评测、部署上线、监控迭代。哪怕是小到自动给邮件分类做一个论文摘要工具这样的项目只要每个环节都认真对待收获比看十篇教程都大。做完之后把它整理成一篇技术博客或者项目文档把踩过的坑、设计的取舍、效果指标都写清楚。这个动作有两个价值一是逼你沉淀和复盘二是成为你找工作时最有说服力的作品。我招人的时候最看重的就是候选人有没有完整做过并总结过一个AI项目而不是他背了多少模型结构。做完一个端到端项目你对AI工程的理解会从知道概念变成真的会做这个转换没有捷径。最后再分享一个我个人的体会做AI工程最容易被忽视、但后劲最关键的能力其实是判断力——知道某个方案要不要用、某个问题出在哪、某个指标该不该信。这种判断力没有速成办法只能靠一个接一个的实战项目喂出来。所以无论你现在手头的事多小做完、总结透、把踩过的坑变成自己的经验库长期下来你一定会感谢自己当初那份较真。