1. AI工程和算法研究的分水岭起点不同终点完全不同最近后台总有人问我同一个问题想做 ai-engineering 方向是不是把深度学习课程刷完、能训练出个模型就够了我每次都要解释很久——因为答案恰恰相反。训练模型只是这条路上最窄的那一段真正让人头疼的是模型前后那一大圈工程问题数据从哪来、怎么保证稳定、上线后崩了怎么排查、迭代的时候怎么不把线上搞挂。这套东西做熟练了你才算入行 AI 工程而不是只会调参。算法研究和AI工程最大的区别可以浓缩成一句话研究者追求的是“模型在基准集上再涨两个点”工程师追求的是“系统在真实环境里稳定跑三个月”。方向不一样投入的重点就完全不同。研究岗可以把80%的时间砸在模型结构和新loss上工程岗恰恰相反80%的精力都花在模型外围——数据管道、服务封装、监控告警、灰度上线、成本控制。我见过太多转行的人踩同一个坑花三个月把Transformer、扩散模型啃得滚瓜烂熟结果到了公司发现压根没人让你从零训练一个大模型你面对的是几十个业务方提的需求、一堆脏乱差的历史数据、还有一台随时可能爆显存的开发机。真正的AI工程落地是从“我懂模型原理”到“我能把一个模型变成线上可用系统”的跨越这个跨越的每一步都是工程决策。这篇文章我就把自己做AI工程项目的完整思路拆开来讲从问题定义、数据闭环、模型训练、部署上线到线上监控最后再说说现在最热的LLM、RAG、Agent落地时到底要关注哪些工程细节。内容不绕弯子全是能直接拿走用的经验。2. 第一块基石先把问题和数据闭环锁死再谈模型2.1 需求拆解你要做的到底是哪一类AI任务很多人拿到需求就想找模型这是本末倒置。接到任何一个项目第一件事是判断任务的真实类型。一样叫AI分类、检索、生成、决策的工程链路差别是巨大的。分类任务最成熟重点是样本均衡和阈值调优检索任务的核心是 embedding 质量和召回排序生成任务要定义输出规范、处理幻觉决策任务更麻烦要跟业务动作联动涉及在线学习的闭环。我见过最典型的翻车案例业务方说要做一个“智能问答”团队接需求后直接上手大模型API做完了才发现真正的场景是让用户从一万条历史工单里快速找到相似案例这本质是检索问题用向量数据库就能解决根本不需要大模型生成成本和响应速度完全两码事。这个阶段我会强制自己写一页需求确认单输入是什么、输出是什么、谁来用、错了会怎样、延迟要求多少、数据量多大。不用写得多学术但这些问题必须落地。很多工程灾难都是因为第一页没写清楚后来返工成本翻十倍都算轻的。2.2 数据采集和清洗AI工程里最脏最累但最值钱的环节模型不会比数据更聪明这个道理人人都背过但实际做起来很少有人真当回事。我接手过几个项目模型效果差的第一刀永远不是换模型而是数据问题标签错乱、重复样本、时间穿越、分布偏移每个问题都能让你的精确率原地跳水。数据清洗有几条铁律一定要区分原始数据和特征数据原始数据永久留存特征数据随版本迭代中间链路必须有记录。标签与特征要分开存储严禁在特征工程里偷偷改标签。时间类特征特别容易翻车用未来数据预测过去属于典型的数据泄漏。脏数据检测要写自动化脚本比如检查特征取值越界、标签分布突变、ID重复率。举个具体例子有次做一个文本分类项目线上表现和离线评测差了十几个点。排查到最后发现训练数据里有大量重复文本而且重复样本的标签是互相矛盾的——同一个用户投诉被两个渠道各标了一次一个标“质量投诉”一个标“物流投诉”。这种错误如果你不写脚本去查重复率和冲突率光靠人力看永远找不出来。后来我在所有数据管道里都加了一组质量指标唯一率、标签一致性、缺失率、时效性跑完数据先看这四项再决定要不要进模型。2.3 数据版本和实验追踪不然后面有你哭的时候数据是活的每天都在变。你今天训出来的模型过两周复现可能完全不一样这不是玄学是因为数据变了。不做数据版本管理的人迟早会碰到一个经典事故模型线上出了问题你想回滚到之前那个“效果好”的版本结果发现既不知道当时用了哪份数据也不知道当时调了哪些超参数。所以数据版本管理不是可有可无而是AI工程的保命符。实操上我常用DVC或者LakeFS这类工具管理数据快照配合MLflow记录每次实验的参数、代码commit、数据版本和指标。成本不高但能让你在事故排查时省下几个通宵。有人觉得这是流程负担但我想说AI工程里“可复现性”根本就不是学术要求而是基本的生产要求。你今天稀里糊涂跑出一个高分模型明天你照样得稀里糊涂地看它崩。2.4 数据闭环让线上反馈回流到训练集工程和实验最重要的区别在于你有没有把线上数据变成下一轮训练的养料。模型上线不是终点而是数据闭环的入口。线上用户反馈、日志日志、业务结果这些才是真正反映模型真实表现的素材。我的标准做法是每个模型上线前必须设计反馈埋点明确记录三个东西——用户的最终行为点击/采纳/关闭、模型当时的推荐结果、用户有没有主动修正。有了这三个字段你就能持续构建硬样本集。所谓硬样本就是模型预测错而用户做了相反选择的数据这些样本比任何人工标注都珍贵因为它们直接反映了模型在真实场景里的失误模式。数据闭环这件事我见过太多团队做得很敷衍日志存了但没人去消费。结果模型上线半年效果早就不行了团队还没察觉。工程思维的差别就在这里有人把数据闭环当口号有人把它嵌在系统设计里。3. 从基线到微调训练环节的工程化推进策略3.1 先跑通再优化别一上来就上大模型很多新手做项目有个通病上来就挑最复杂的模型恨不得第一天就微调一个几十B的LLM。我的建议反着来永远先做一个最简基线。分类问题先用逻辑回归或XGBoost文本检索先用BM25哪怕效果很糙也没关系因为基线的作用不是拿冠军而是给你建立参照系。有了基线后面所有复杂模型的收益才是可量化的。而且基线跑通还能帮你验证整个数据管道、评估代码、部署流程是否能闭环——这些环节如果等模型好了再搭你会发现问题一个接一个冒出来到时候根本分不清是模型问题还是工程问题。我经常说一句话先把整条链路用玩具模型跑通再回来换真家伙。这条经验救过我很多次。因为工程链路里的问题往往是串行的数据读不出来模型再强也是白搭评估代码写错全局指标再漂亮也是假的。简单模型的意义就在于把这些问题提前暴露掉。3.2 模型选型逻辑开源私有化还是调API这几年大模型成了AI工程绕不开的话题选型决策也比以前复杂了。你手里现在有三条路直接用商用API、部署开源模型、或者两者结合。我的选择逻辑很简单看四个维度——数据敏感性、成本预算、延迟要求、定制深度。数据敏感的行业比如金融、医疗基本走私有化路线那开源模型加上微调就是主流。预算紧、场景通用直接调API最划算没必要自己养GPU。但如果你要做深度定制比如要在模型里注入大量私有知识或特定风格API的性价比反而会迅速下降。要注意的是很多人把“部署开源模型”想得太简单以为拉个开源权重跑起来就完事了。实际上要处理的工程问题不少推理框架选型、显存管理、并发优化、量化压缩、上下文长度限制。后面我会专门讲这部分这里只提醒一句开源模型不是免费的它是用你的运维成本换授权成本。3.3 微调实操全参微调不是默认选项前几年做微调还流行全参数更新现在这个大模型时代全参微调基本只属于资源充足的团队。普通团队微调LLMLoRA和QLoRA才是更实际的选择。它们只训练一小部分低秩矩阵参数显存占用大幅下降效果在很多场景下已经可以和全参微调打得有来有回。我在项目里用QLoRA做过一次7B模型微调单卡24G显存就能跑训练时间压到几小时内效果提升也肉眼可见。这套方案很适合预算和数据都有限的场景。# QLoRA微调的关键配置示例 from transformers import AutoModelForCausalLM, BitsAndBytesConfig from peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training bnb_config BitsAndBytesConfig( load_in_4bitTrue, bnb_4bit_quant_typenf4, bnb_4bit_use_double_quantTrue, bnb_4bit_compute_dtypebfloat16 ) lora_config LoraConfig( r16, lora_alpha32, target_modules[q_proj, v_proj, k_proj, o_proj], lora_dropout0.05, biasnone, task_typeCAUSAL_LM )这套配置里几个参数值得说清楚r控制可训练矩阵的秩越大表示适应能力越强但过拟合风险也越高lora_alpha是缩放系数经验值一般是r的两倍target_modules选哪些层对7B模型来说选注意力层的四个投影矩阵是常用做法。这些参数没有绝对最优我通常的做法是小步快跑先用小学习率试一轮观察loss曲线再逐步调整。3.4 训练中的显存、过拟合和实验记录微调落地时最大的物理约束是显存。很多新人一上来就问“为什么我的显存爆了”其实按经验估算每10亿参数在fp16精度下大约占2GB显存再加上梯度、优化器状态、激活值实际需要量还要乘上几倍。现在用Adam优化器训练7B模型全参微调没个80G根本跑不动这也是LoRA能成为主流的原因——它把优化器状态的开销降到了忽略不计。过拟合这个问题在微调里同样存在而且更隐蔽。LoRA虽然参数少但如果你用单一风格的数据反复训练模型会产生严重的风格固化回答任何问题都带着训练集的腔调甚至把训练数据里的错误事实当成金科玉律。我的经验是保证训练数据的多样性每类样本总量别超过总量的30%同时留一部分数据做验证集微调完先跑一遍通用能力测试确认没有灾难性遗忘。实验记录这里多说一句就是训练日志一定要留全。很多工程事故复盘到最后真正缺的往往不是技术方案而是当时的参数和日志。MLflow、Weights Biases都行关键是养成记录习惯。每次跑实验把数据版本、代码commit、超参数、最终指标这四个记录成一条不可变的条目后续一切问题定位都有依据。4. 部署上线从GPU选型到推理优化的一条完整链路4.1 训练和推理的硬件逻辑是两回事模型训练好只是中点部署上线才是真正考验工程的开始。很多人以为部署就是把模型文件放到服务器上跑个预测实际差远了。先看硬件训练阶段追求单卡算力和并行扩展性推理阶段更看重吞吐、延迟和成本。同一个模型训练用A100这种大算力卡没问题但线上推理如果也用同款卡可能连成本都背不住。推理阶段的主流做法是选择推理优化的卡或者干脆用普通服务器CPU加加速卡组合。做LLM推理的话显存带宽往往比算力更关键因为生成是逐token的每一步都要重新读取全部模型权重如果你的带宽不够token生成速度就会严重拉胯。这也是为什么同一张卡跑小模型可能延迟很低一换大模型就慢得离谱。GPU选型这件事我给不出一个放之四海皆准的答案因为每个人的场景和数据敏感度不同但有个思考框架是通用的先测真实负载再定配置。不要拿厂商的宣传参数当决策依据。拿你实际要跑的模型、实际的并发量、实际的输入输出长度去压测压测数据才是唯一值得相信的。4.2 模型压缩量化、剪枝、蒸馏怎么选模型太大上不了线怎么办压缩是必经之路。这里三个常用手段各有适用场景量化把权重从fp16降到int8甚至int4。推理显存直接降一半到四分之一速度也明显提升代价是精度略有损失。现在QLoRA、GPTQ、AWQ这些方法已经让4bit量化的大模型效果相当能打。剪枝把不重要的连接和通道去掉模型更瘦。结构化剪枝对硬件友好但效果损失需要靠微调恢复。知识蒸馏用大模型教小模型让一个小模型逼近大模型的效果。工程上成本最高但换来的是长期的低推理成本。我推荐从量化入手因为收益最直接、改动最小。部署的时候量化后的模型和原模型一定要做同一批测试样本的对比确定精度损失在业务可接受范围内再上生产。不要只盯着平均指标要看极端样本——比如领域内的困难样本、长尾样本量化通常在这些样本上损失更严重。4.3 推理服务化并发、批处理、缓存缺一不可部署模型本质上是要把它变成一个高可用的服务。这里有几个工程要点照着做能避开很多雷。第一一定要做动态批处理。LLM生成是计算密集型的单个请求来一个跑一个GPU利用率会很难看。把多个请求攒起来一起推理吞吐能提升好几倍。vLLM、TensorRT-LLM这些框架内置了连续批处理强烈建议直接用。第二极致重视首token延迟。用户感知里第一个字等多久决定了他觉得这个系统快不快。模型推理本身占一部分但输入解析、token化、排队逻辑都可能成为瓶颈。我用过的最实用的优化手段是对输入做缓存命中缓存的请求完全不用走模型。第三并发和队列的容量规划。不要只测单路延迟要测P95甚至P99延迟在并发下的表现。很多模型单看延迟不错一旦并发上来排队加上显存争抢P99直接翻好几倍。压测必须做而且要按你线上的峰值流量的两倍来压。一个标准的模型服务配置文件可以参考下面这个结构serving: engine: vllm model: /models/quantized-7b-awq tensor_parallel_size: 1 max_batch_size: 64 max_seq_len: 4096 gpu_memory_utilization: 0.85 enable_prefix_caching: true quantization: awqgpu_memory_utilization这里值得单独说。很多人不敢拉高这个值怕OOM但设太低又会浪费显存导致并发上限变小。建议是在离线压测环境里从0.9往下降找到一个稳定不下探的临界值。enable_prefix_caching对多轮对话尤其有用因为长对话里有很多公共前缀可以被复用这一项能显著降低延迟。4.4 端云协同不是所有场景都适合纯云端推理最后聊一下部署形态。很多项目默认就要云端API部署但实际场景里纯云方案不一定最优。举个例子做实时质检或者智能客服辅助业务方要求响应在几百毫秒内出差错的代价很高这种场景如果还依赖公网往返延迟和稳定性都很难保证。端云协同的思路是把轻量级模型部署在用户侧设备上做初筛只把疑难样本或者需要大模型能力的数据送到云端做二次处理。这个模式下离线、降级、缓存、本地计算都要设计好等于把AI工程能力延伸到边缘侧。这块做得好用户体验和成本控制会同时受益。5. 线上稳不稳评估和监控说了算5.1 离线评估选对指标比调参重要得多上线前的离线评估是最后一道闸门但很多人只盯accuracy这一个数字这个习惯很危险。真实业务场景里正负样本比例经常失衡可能99%的样本都是负例你模型全预测负例都能拿99%准确率但这有什么意义我要强调几个工程上更常用的评估思路分类任务不能只看准确率必须同时看精确率、召回率、F1以及PR曲线下面积。不同业务对误报和漏报的容忍度不一样医疗场景漏报不可接受垃圾邮件场景误报不可接受。排序/检索任务要看RecallK、MRR、NDCG这类指标。它们更贴近真实用户行为。生成任务要用多个维度评估事实一致性、内容安全性、指令遵循率。这些往往要引入一套半自动化的评测pipeline用人机结合的方式打标。无论什么任务都要做分维度评估不能只看总体指标。不同用户群、不同时段、不同内容类型的表现都要拆开看否则平均数的假象会掩盖很多严重问题。5.2 线上监控延迟、吞吐、漂移一个都不能少模型上线后的监控本质上分四大类缺一个都是隐患监控维度核心指标常见问题性能指标延迟P50/P95/P99、吞吐QPS、GPU利用率并发上涨导致延迟飙升稳定性指标请求错误率、超时率、重试率模型服务崩溃、OOM数据指标输入特征分布、输出分布、业务反馈数据漂移、分布偏移业务指标点击率、采纳率、转化率、满意度模型效果衰减数据漂移是最容易忽视的一环。模型是根据训练时的数据分布学习的线上真实数据一旦发生偏移模型效果就会悄悄下滑而且不会报警。我的做法是每天跑一次数据分布对比用PSI或KL散度量化训练集和线上数据分布的差异一旦超过阈值就触发告警然后需要相关人员介入分析。5.3 反馈闭环模型迭代的发动机监控发现问题只是第一步更关键的是要建立模型迭代的机制。我见过太多团队模型上线后就成了“石像”半年不更新效果差到业务方吐槽也没人管。原因通常是迭代流程没建立起来。我推荐的迭代节奏是这样的每周从线上抽取硬样本和用户反馈形成增量数据集每两周做一次小版本微调更新只换权重不换服务每季度做一次大版本升级可以换模型结构或者调整训练策略。这条循环一旦转起来模型才会越用越聪明。需要特别强调的是每一次更新都必须走完整的评估流程。很多人图省事直接上线结果模型还不如上一版。我有一次深夜回滚的教训太深刻了就是因为新模型有个badcase没测出来上线两小时后业务吐槽如潮紧急回滚才恢复。从那以后我再也不省评估流程。5.4 事故复盘AI系统出问题时先查什么线上系统出事故是迟早的事关键是能不能快速定位。根据我的经验AI服务出问题通常按这个优先级排查先确认是模型服务本身的故障还是上游依赖出问题了。比如向量数据库挂了、feature store接口超时都会让模型表现异常。再确认是请求数据异常还是模型权重异常。输入数据格式不对、字段为null这种问题排查顺畅的话应该能很快发现。最后追到模型本身大概率是效果衰减或者某个输入组合踩中了模型的盲区。这个排查链路必须在事故前就准备好日志要全链路追踪从请求进来到特征计算、模型推理、结果返回每一步都要有trace。没有链路追踪的AI服务事故排查就像在黑暗里摸电闸你可能永远找不到真正的原因。6. 热点工程的落地真相LLM、RAG和Agent不是调API就行6.1 大模型接入API调用和私有化部署的边界在哪里现在一提AI工程绕不开大语言模型。但“接入大模型”和“大模型工程化”之间差距非常大。API调用是最快的捷径几行代码就能让产品拥有理解能力但工程化的坑在后面上下文怎么管理、接口超时重试怎么做、敏感内容怎么过滤、费用怎么控制。私有化部署的意义在于数据可控和深度定制但代价是算力成本和运维成本。我在前文也聊过决策时四个维度数据敏感度、成本、延迟、定制深度。这四个维度摆出来边界其实很清楚不需要跟风。6.2 RAG系统的工程细节切块、检索、重排、上下文RAG是目前落地最高频的大模型应用模式本质是用检索给大模型外挂知识库。听上去简单但每个环节都有坑文档切块是第一步也是最容易被低估的一步。切得太碎语义被切断切得太大检索噪声变高。我的经验是根据文档结构先做段落级切块再对长段落做滑动窗口重叠切分重叠部分控制在15%~20%左右。这样既能保证语义完整又能兼顾召回。向量化模型的选择要跟语言和领域匹配。通用向量模型在垂直领域的效果一般有条件应该用领域数据微调一个专用embedding模型这一步能带来肉眼可见的检索提升。检索不是只调向量库的topk就行。混合检索关键词向量在长尾词和专有名词上表现更好重排模型放在召回之后能显著提升最终结果的质量。还有个细节是上下文拼装。把检索结果一股脑塞给大模型会稀释重点信息也容易超上下文窗口。应该先筛选再排序把最相关的结果放在最前面并在prompt里明确定位、输出范围。评估RAG系统也不能只看模型生成得好不好得把检索层剥出来单独评估召回率、命中率、重排后NDCG这些指标都要跑。RAG工程简单来说就是检索决定了天花板生成只是把结果说出来。6.3 Agent工程化状态管理比模型能力更考验工程水平Agent是最近热度最高的方向但也是“demo好做、生产难做”最典型的领域。很多人觉得Agent就是让大模型调用几个工具但这个想法在真实场景里会被现实击穿。大模型的工具调用有概率失败给错参数、选错工具、陷入死循环这些问题在大模型能力不够的时候非常高发。Agent工程的本质是一个状态机和一套可靠性机制。我的核心经验是每个Agent任务必须定义明确的状态流转初始、工具调用、结果处理、终态。不能用散漫的对话去驱动否则无法排查。工具调用的每个参数都要做schema校验模型输出不能直接当成可执行参数否则一旦书格式稍有偏差很可能会导致线上事故。必须设置超时和最大迭代轮数防止Agent陷入死循环烧钱。对关键动作做人工确认机制特别是涉及数据删除、发送消息这类不可逆操作没有确认机制迟早出大事。现在的Agent做产品demo很容易惊艳但稳定商用需要工程细节堆积。谁先把这些可靠性机制补全谁才能真的把Agent从Demo推进到生产环境。6.4 多模态与垂直场景工程链路更长要求也更高大模型之外多模态工程化也在快速铺开。图像理解、语音交互、视频分析它们的工程链路比纯文本长得多图像要先做预处理和区域提取语音要处理采样率和降噪视频要做抽帧和时序对齐。每一步都需要单独的模型或算法模块协同线上性能的瓶颈经常出现在视频解码和图像预处理上而不是模型推理本身。这条线我的建议是别想着全流程自己造轮子。图像预处理用成熟的视觉库语音对齐用稳定的音频框架模型推理统一走同一个服务化平台。你在工程层面要负责的是串联、调度、监控和容错这样整个系统的从零到一周期会大幅缩短。7. 从零到一的最后一块拼图踩坑之后我对AI工程的理解一个人把完整的AI项目从零做到线上稳定运行之后才会真正理解 ai-engineering 的含义。它不是一个新技术名词而是一整套工程方法论数据要闭环、实验要可复现、服务要可观测、迭代要可持续。算法模型只是其中一个环节把这个环节放大的团队往往是最脆弱的。我现在带项目第一周不会让任何人碰模型而是先做两件事把数据管道跑通把评估基线立起来。模型再烂都有救但数据和评估的根基不稳一切提速都是空中楼阁。这也是我最想分享给准备入行的人的经验——不要被“训练模型”四个字困住多去看看模型前后那些枯燥的工程环节那里才是AI工程真正的门槛和壁垒。最后分享一个我自己坚持了很多年的习惯每个项目收尾时写一份“如果重来一次”的复盘文档不用长十条以内记录哪里浪费了时间、哪个决策事后看是错的、哪个工具其实可以更早引入。这份文档比任何课程都有价值因为它完整记录的是你在真实项目里积累的工程直觉。AI工程的成长路径没有捷径但每一段踩坑的路都可以成为下一段路的捷径。