这几年我经常收到一类问题“我想做 AI 工程是不是先把 Transformer 和 PyTorch 吃透就行”我通常不直接回答而是反问一句“你准备怎么验证自己学会了”对方如果愣了一下那大概率还没想清楚 AI 工程到底是一门什么手艺。AI 工程不是某一个单点技能它是一条贯穿数据、模型、评估、部署、监控和业务集成的完整链路。单纯会训练模型和能把模型稳定跑在线上并持续产生价值中间隔着大量文档里不会写的脏活、累活和排查经验。这篇文章想把 AI 工程从零到一的完整路径拆开给你看先解决“是什么”和“为什么”再给出一条能直接抄作业的实操路线包括每个阶段的核心环节、关键参数、常见坑点和我的个人经验。适合刚入门想认真做 AI 的人也适合做了一两年仍然觉得“只在调模型没在做工程”的同行对照着查漏补缺。1. AI 工程到底是什么别把智商全押在调模型上1.1 从岗位职责看 AI 工程的能力结构先看一个最简单的事实。如果你去翻几个主流招聘平台上“AI 工程师”和“算法工程师”的 JD会发现问题很有意思。算法工程师的职责大多围绕“模型效果”展开改进网络结构、优化损失函数、提升离线指标。而 AI 工程师的职责描述里通常会出现这些东西负责模型服务化、设计数据回流链路、保障推理性能、参与 MLOps 平台建设、和业务方一起定义评估指标。这两者的边界现在越来越模糊但 AI 工程师的核心定位始终是“把模型变成产品”。说得更直白一点算法工程师的交付物是“效果达标的模型”AI 工程师的交付物是“稳定运行、持续优化、业务可用的系统”。这就是 AI 工程和单纯机器学习最大的区别——它是一个系统问题不是一个模型问题。一个完整的 AI 工程系统至少包含下面这些模块缺一个都会在实际运行中爆雷需求拆解把业务问题翻译成机器学习问题。这一步最反直觉也最容易被新手跳过。比如业务说“帮我们减少人工审核量”你不能直接开干要先弄清楚哪些审核场景是可自动化的、自动化出错后的兜底机制是什么、评估标准是“拦截率”还是“误伤率”。数据工程数据获取、清洗、去重、标注、版本管理。很多人一上来就想着调模型结果 80% 的时间耗在数据上。模型开发基线模型、模型选型、训练、调参、实验管理。这部分是显性的知识网上教程最多。评估体系离线评估和在线评估不仅看准召还要看稳定性、鲁棒性、公平性。部署与服务化模型格式转换、推理优化、API 封装、并发与容灾。监控与迭代数据漂移检测、模型漂移检测、指标异动告警、bad case 回流和定期重训。看到这里你应该意识到了一个关键问题市面上绝大多数“AI 入门教程”只覆盖了上面第三点而且只覆盖了第三点里的“训练模型”这一小步。这就是为什么很多人刷了一堆教程课程都通关了真正上手做一个项目时还是寸步难行——因为他们一直站在链路上最窄的一节里。1.2 为什么“端到端最小闭环”是唯一靠谱的起跑方式知道了能力结构之后你自然会问那我先学哪个我的建议非常明确不要试图把每个模块全部学完再动手直接搭一个最小的端到端闭环然后反复“做厚”它。原因很简单。AI 工程的各个模块之间是强耦合的。数据质量会影响模型效果模型效果会影响在线指标在线指标的设计又反过来约束你该采集什么数据。这种耦合关系只有当你亲手把一条完整链路跑通时才会真正理解。比如你不亲手做一次部署就理解不了为什么离线效果很好的模型到了线上延迟就爆炸你不亲手监听一次数据分布变化就理解不了什么叫“模型越跑越笨”。另外从学习心理学的角度说端到端闭环能给你高频的正反馈。一个能点开网页、输入文本、返回预测结果的 Demo哪怕里面用的是最简单的线性模型它在“激励你继续往下走”这件事上的效果远好于书桌前啃一个月数学推导。我见过太多刚开始信心满满、后来在反向传播推导里默默放弃的新手。这不仅是方法问题还是策略问题。所以接下来的内容我核心围绕一件事如何从零开始一步步把你的第一个 AI 工程闭环搭起来并且每一步都讲清楚“为什么这样做”。2. 第一块基石用最小闭环跑穿全流程2.1 先选一个能让业务一眼看懂价值的场景做最小闭环第一个要避开的大坑是“选题过于抽象”。不要一上来就做“通用意图识别系统”甚至不要做“情感分析系统”太宽了。建议选一个边界清晰、数据容易获取、效果能被非技术人员一眼看懂的任务。我给你三个比划起来最顺手的候选方向都是我自己带新手跑过无数次的情况垃圾评论识别输入一条评论输出“正常/垃圾”。数据可以从公开竞赛、开源仓库里拿也可以自己从社交平台爬几百条。客户咨询分类输入一条用户咨询输出“退款/物流/售后/其他”等几个固定标签。这个任务的收益特别直观后续还能自然延伸到一个简单的客服问答 Agent。商品标题标准化输入一个商品标题输出品类标签或关键属性。电商场景下的典型问题数据也相对容易标注。我自己最推荐第二个“客户咨询分类”。它有三个优点业务价值一眼可见类别固定评估指标清晰做完之后可以直接扩展成知识库问答或 Agent 应用不会浪费前期工作。2.2 最小闭环的五步实操选定场景后就用最小成本把它跑通。每一步都带着目的去做我不建议为了“显得完整”而上重型工具。第一步搞定数据集。假设你做咨询分类先定义 4 到 6 个类别。数据量不需要大每类 100 条左右就能启动总计 400 到 600 条。这阶段的目标不是训练一个 SOTA 模型而是把流程打通。数据可以来自你所在公司真实的客服记录、公开的客户留言数据集、或者你自己和朋友模拟编写的典型问题。注意如果你用的是模拟数据一定要在后续换成真实分布的数据否则效果会严重失实。第二步清洗和整理数据。把文本里的换行符、多余空格、无意义符号去掉统一大小写中文任务还要注意繁体转简体去重。清洗逻辑要记录在一个脚本里不要手动改数据文件。原因后面会讲先记住数据清洗必须可复现。第三步跑一个负责任的基线。注意我用的是“负责任的基线”而不是“随便跑跑”。一组规范的做法是固定 80% 训练集、10% 验证集、10% 测试集用 TF-IDFTerm Frequency-Inverse Document Frequency词频-逆文档频率向量化加一个简单的逻辑回归模型记录它在测试集上的准确率和 F1。这组结果就是你之后所有尝试的“地板”。from sklearn.feature_extraction.text import TfidfVectorizer from sklearn.linear_model import LogisticRegression from sklearn.model_selection import train_test_split from sklearn.metrics import classification_report X_train, X_test, y_train, y_test train_test_split( texts, labels, test_size0.2, random_state42, stratifylabels ) vec TfidfVectorizer(max_features5000, ngram_range(1, 2)) X_train_vec vec.fit_transform(X_train) X_test_vec vec.transform(X_test) clf LogisticRegression(max_iter1000) clf.fit(X_train_vec, y_train) print(classification_report(y_test, clf.predict(X_test_vec)))请注意random_state42和stratifylabels这两行前者保证你的实验可复现后者保证类别分布被一致地切分。很多新手忽略这两个参数结果不同次实验之间对比变得没有意义。第四步封装 API。哪怕只是本地运行也要用 FastAPI 把一个POST /predict接口暴露出来输入是一段文本输出是类别和置信度。为什么要这一步因为只有把模型包装成接口你才能体会到“线上系统怎么和模型交互”同时这份代码会直接复用到后续部署环节。from fastapi import FastAPI from pydantic import BaseModel app FastAPI() class PredictRequest(BaseModel): text: str class PredictResponse(BaseModel): category: str confidence: float app.post(/predict, response_modelPredictResponse) def predict(req: PredictRequest): vec_text vec.transform([req.text]) proba clf.predict_proba(vec_text)[0] idx proba.argmax() return PredictResponse( categoryclf.classes_[idx], confidencefloat(proba[idx]) )第五步做一次简单的人工评估。这时候不要再去看整体准确率而是把 50 条预测结果打印出来和业务方或你自己扮演业务方逐条看哪些预测是严重不可接受的哪些是系统边界外的。这一步的目的是让你建立对“离线指标”和“真实体验”之间差距的直觉。准确率 90% 的系统可能因为那 10% 的错误全部集中在最敏感的场景而完全无法上线这种问题只有一边看样本一边思考才发现得了。2.3 最小闭环阶段的三个关键心态第一接受“丑到能用”。这个阶段的代码可以丑可以没有设计模式甚至可以只有一个脚本和一个 API 文件但必须端到端跑通。完成比完美重要一百倍。第二不要急着上 GPU。400 到 600 条数据的 TF-IDF 逻辑回归CPU 上几秒钟就训练完了。过早启动 GPU 云主机不仅浪费钱还会让你养成“依赖大模型才能干活”的坏习惯。硬件升级应该发生在你明确知道它要解决什么问题之后。第三把实验记录做起来。哪怕只是维护一个 Markdown 文件记录每次改了数据、特征或模型参数后测试集指标的变化。这个习惯散漫到不能再散漫但当我后来带工程师时发现这条能做到的人不超过 20%。不做实验记录你后面所有“效果优化”都会变成玄学。3. 深入核心当数据、训练和实验管理成为主战场3.1 数据工程的优先级永远高于调参把第一个闭环跑通之后你会很自然地想去“把效果提高一点”。这时候新手最常见的做法是换更强的模型老手通常先回到数据上去找机会。根据我个人经验数据侧的机会往往远大于模型侧。数据侧有几个维度值得你仔细打磨标注一致性。找两个人分别标注同一批数据计算一致性你会惊讶地发现在最简单的分类任务上标注员的初始一致性可能只有 85% 左右。不一致的样本意味着标签有噪声模型学这部分时会浪费大量容量。你需要制定标注规范对争议样本进行评审修订。不然你费尽心思调参收益可能远不如把标签理顺。类别平衡。如果你的类别分布是 90%“物流”、3%“退款”、2%“售后”、5%“其他”模型即使把后面三类全预测错准确率也有 90%。此时必须看各类别的精确率和召回率并用 F1 或 macro-F1 等指标评估。对应地可以在采样时对少样本类别做过采样或者用类别权重调整损失函数。数据版本管理。这句话听起来像在讲大厂基建其实一个人也能做。最简单的做法是每次改动数据后生成一个带时间戳的文件夹并记录数据文件的内容哈希值比如用 md5。这样一来几个月后你说不出“这个模型是用哪批数据训的”这种话在排障时会非常被动。建议你在这一步就把训练集、验证集、测试集划分逻辑固定下来。把划分代码写进脚本而不是手动切文件。划分逻辑必须包含随机种子。线上系统以后会不断涌入新数据如果你没有一套确定性的划分逻辑训练集和测试集之间产生数据泄漏都是迟早的事。数据泄漏的典型表现是离线评测结果极高线上效果崩得一塌糊涂。3.2 模型选型从基线到强模型要走得克制基线模型跑通后你可以开始尝试更强的模型了。但模型选型的逻辑不是“越强越好”而是“在用得起的前提下选择性价比最高的”。以文本分类任务为例一般可以按这样的层次推进词向量加权平均 机器学习分类器。适合数据量很小或强实时要求的场景训练快、部署简单。预训练模型微调比如用几十到几百 MB 参数规模的模型做分类。适合中低延迟要求、数据量在几千到几万条的场景性价比极高。大语言模型 In-Context Learning也就是通过 Prompt 让模型直接输出分类结果。句子复杂、类别边界模糊、有大量隐含语义时效果最好但成本高、延迟大且输出不稳定。关于用不用微调对刚入门的人我有一个很实际的经验法则如果 5000 条已标注数据拿在手上先尝试用 Prompt 或 Re-ranking 的方法压榨大模型如果数据量到了 2 万条以上再认真考虑微调。微调一个预训练模型并没有想象中那么神秘现在通用的做法是 LoRALow-Rank Adaptation低秩适配或 QLoRA在显存有限的显卡上也能训练出效果不错的适配器。具体做法是冻结原始模型权重只训练一小部分低秩增量矩阵。这个方案的好处有两个训练成本低适配器文件很小便于后续管理和部署。这里特别提醒一个很容易犯的错不要一上来就让模型在所有训练数据上跑很多轮期待“练得越久越准”。深度学习里的过拟合来得比你想象的快训练集准确率接近 100% 而验证集开始下降是一个很典型的分界点。你要做的是“早停”也就是监控验证集指标当它连续若干个 epoch 不再提升时及时保存当前最优权重并停止训练。3.3 实验管理是 AI 工程和 AI 自学的分水岭如果说数据工程是第一道分水岭那实验管理就是第二道。它决定你是“科学地做实验”还是“撞运气”。一套哪怕最轻量的实验管理也应该包含这些信息数据集版本和内容哈希。数据预处理配置清洗规则、向量化参数、切分种子。模型结构配置模型名、层数、参数量、LoRA 秩。训练超参数学习率、批次大小、训练轮数、权重衰减、预热步数。环境信息Python 版本、依赖库版本、GPU/CPU 型号。实验结果验证集和测试集上的完整指标、训练时长、显存占用。很多人觉得记这些太麻烦但等你做第十次实验时就会发现找不到第一次实验用的超参意味着一切都得从头来浪费的时间远大于随手记录的那十秒钟。工具层面WBWeights Biases和 MLflow 都是不错的选择。如果不想引入额外服务用纯文本记录也能接受关键是“坚持记”。超参数方面文本分类任务里最值得优先调的通常有这么几项学习率。预训练模型微调一般用 1e-5 到 5e-5 这个范围太大会灾难性遗忘太小收敛极慢。批次大小。受显存约束一般 8 到 32。如果太大可以用梯度累积来模拟大批次。训练轮数。3 到 10 轮之间比较常见配合早停策略。随机种子。固定随机种子后实验才能复现。不同种子之间结果有波动时最好一个配置跑 3 次取均值再比较。每改一个新配置只动一个变量。这是老生常谈但真正执行的人很少。很多工程师的调参过程是“换了模型、改了学习率、顺便换了一版数据”最后效果变差了你根本不知道是谁的锅——这种实验记录做一百次也积累不出可迁移的经验。3.4 不要为了训练而训练先试试不训练的解法在聊训练技术之前我必须插一段非常重要的话很多真实业务场景根本轮不到你训练模型。举例来说如果业务方只是想把常见退款问题进行关键词分流一个写好的正则表达式或者一份 Excel 规则表可能已经覆盖了 80% 的场景。这种情况下硬上微调模型只会让系统更难维护也让你的交付周期变得冗长。AI 工程的判断力有很大一部分体现在“识别哪些问题根本不需要 AI”上。如果决定引入模型但数据量不够也建议先试试大模型的 In-Context Learning。那意味着你只需要写好 Prompt、定义好分类类别和少量示例然后用一个 API 调用完成推理。你好几天不用做数据标注先验证“如果模型效果足够好业务是否愿意接受成本和延迟”。这种验证思维是 AI 工程里最容易缺失的环节因为绝大多数教程只教“模型怎么训”从不教你“该不该训”。4. 上线与运维工程化在部署和监控上拉开差距4.1 模型服务化从可运行到可上线很多人以为模型跑通了就大功告成。实际上从“能运行”到“能上线”之间还有一层非常重要的工程化打磨。首先模型格式转换是个绕不开的环节。如果你在 PyTorch 里训练了模型部署时不会直接把它挂在 Web 服务里让 FastAPI 调用 PyTorch那样每次请求都会把 Python 和深度学习框架全部加载一遍不仅慢而且吃资源。更常见的是把模型导成 ONNXOpen Neural Network Exchange开放神经网络交换格式或者直接用推理优化框架加载。ONNX 的好处是格式统一、可跨框架、可以配合 ONNX Runtime 做 CPU/GPU 加速。转换时一定要在转换前后做一次相同输入的输出对比误差控制在极小范围内否则可能是某些算子不支持导致的精度损失。然后要说推理性能优化。最有效的三板斧是量化、批处理、缓存。量化简单说就是把模型的浮点数参数从 32 位降到 16 位甚至 8 位换来更小的模型体积和更快的推理速度代价是精度略降。批处理思想则是把多个请求攒在一起喂给模型充分利用 GPU 并行计算能力显著提升吞吐。缓存策略则适合那些请求高度重复的场景比如同一句客服咨询经常出现把已算好的结果放缓存里可以省掉大量重复计算。下面是一个基于 FastAPI 的部署示例配合 ONNX Runtime 做 CPU 推理。这种方案的好处是环境依赖很小部署到一台普通 Linux 服务器就能跑。import onnxruntime as ort import numpy as np from fastapi import FastAPI from pydantic import BaseModel app FastAPI() session ort.InferenceSession(model.onnx, providers[CPUExecutionProvider]) input_name session.get_inputs()[0].name label_list [物流, 退款, 售后, 其他] class Req(BaseModel): text: str app.post(/predict) def predict(req: Req): # 假设预处理逻辑已封装为 preprocess 函数 input_ids, attention_mask preprocess(req.text) preds session.run( None, {input_name: input_ids, attention_mask: attention_mask} )[0] idx int(np.argmax(preds[0])) return {category: label_list[idx], confidence: float(preds[0][idx])}这段代码只是一个骨架但你应该能看出真正的难点往往不在 API 本身而在preprocess函数里它必须和训练时的预处理逻辑完全一致。这里藏着投产阶段最典型的坑——线上预处理不一致导致效果雪崩。我建议你把特征处理器单独封装成一个模块训练和推理共用同一套代码从源头上杜绝不一致。4.2 监控模型不是上线就完事而是上线后才开始模型上线后最危险的事情不是模型本身效果差而是它“悄悄变差”而你不知道。数据漂移是最常见的一种情况。举例来说你的咨询分类模型在 5 月份训练时“退款”类别的表述还很常规。到了 6 月份平台大促出现了大量“价格保护”“差价退回”等新话术。这些输入和训练数据分布产生了明显偏移模型预测就会开始出错。也就是说业务变了、用户说话方式变了模型没变效果自然滑落。应对数据漂移最基本的一步是监控输入特征分布的统计量比如向量化后每个特征的均值方差、每类文本的长度分布、常见关键词频率等。更直接的方式是做线上预测置信度分布监控如果一段时间的平均置信度明显下降往往意味着模型遇到了它没见过的东西。另一个必须做的是 bad case 回流机制。线上预测错了要能把样本保存下来定期交给人工标注或直接进入评估集。这一步说起来容易做起来难难在需要业务方的配合你得定义清楚“什么样的结果算错”。通常的做法是在业务系统里增加“结果是否有用”的反馈按钮或者事后抽样审计。没有数据回流模型迭代就成了无源之水。这一阶段我特别想提醒初学者不要一上来就搞 Kubernetes。K8s 不是 AI 工程的全部基础设施。对于一个日访问量只有几千的小模型服务一台带 Docker 的服务器、一个 systemd 服务和一份日志轮转配置就已经超过一半小公司的运维水平。过早引入微服务架构和大规模编排系统只会让你陷入容器调度的泥潭而不是帮你解决真正的模型问题。4.3 线上效果和离线指标对不上从这六个方向排查这是 AI 工程里最高频、也最让人崩溃的问题。离线测试集 F1 0.92上线后实际反馈准确率却不到 0.7你可以按下面的顺序逐项排查数据泄漏。检查数据清洗和特征提取过程里有没有把未来信息或标签信息混进训练特征。比如用会话结束后才产生的事件做特征属于典型的时序泄漏。预处理不一致。确认线上 API 用的分词、向量化、样本截断逻辑是否和训练时完全一致。这是头号嫌疑。评估集分布偏差。训练数据来自某个历史时段但线上流量分布已经改变。建议定期重新切分评估集并混入近期 bad case。推理与训练模式差异。比如训练时用了 Dropout推理时忘了切到 eval 模式或者批量归一化的统计量在训练和推理时不一致。细节问题但影响很大。业务真实反馈与标注口径差异。线下标注觉得是“退款”线上用户实际意图是“投诉”。这种情况只能靠校准标注规范。阈值设置不合理。分类器输出的置信度并不天然对应业务决策。建议在业务侧基于精确率-召回率曲线重新选择决策阈值而不是硬用 0.5。5. 当代 AI 工程的必修课LLM 应用与 Agent 的工程化视角5.1 当模型变成“可调用的外部能力”工程问题反而变大了最近几年AI 工程的重心发生了一个很有意思的转移模型本身从“需要你亲手训练的权重”逐渐变成“一个可以通过 API 调用的能力”。尤其是大语言模型你不需要准备训练数据不需要 GPU只需要写一段 Prompt 就能完成以前需要微调才能实现的任务。听起来工程变简单了但实际做下来你会发现难点转移到了一个新的链路如何把不可控的模型输出变成稳定可控的产品行为。以最常见的 RAGRetrieval-Augmented Generation检索增强生成应用为例。它被广泛用于“基于私有知识库的问答系统”。链路看起来很简单把文档切成小块做向量化索引用户提问时先从向量库检索相关片段把片段拼到 Prompt 里让模型生成答案。但这每一步都有大量工程细节。切片是第一个坑。文档怎么切、按什么粒度切直接影响检索质量。按固定长度切简单但容易把上下文截断导致语义不连贯。按章节和标题层级切效果通常更好但要求你能解析文档结构。向量化模型怎么选、是通用模型还是领域微调模型影响更大。到了生成阶段Prompt 是否约束了“只依据给定内容回答”决定了模型会不会一本正经地编造答案。所以你看这跟训练模型的系统问题没有本质区别你依然需要评估、调优、监控和及时干预只是优化的对象从“模型权重”变成了“检索链路 Prompt 策略 模型选择”。5.2 Agent 工程的三个核心控制点Agent智能体是把 LLM 和外部工具结合的系统比如让它查订单、发退款、改密码。这是当前 AI 工程里最活跃也最容易翻车的领域。从工程视角看Agent 系统的复杂度来自模型输出天然不稳定而工程上又希望系统行为尽量确定性可控这就需要三个核心控制点。意图识别和状态管理。一个 Agent 通常要处理多轮对话你需要把用户当前处于哪个流程节点、已经收集到哪些信息、下一步要调用什么工具用一套状态机管理起来而不是完全依赖模型自由发挥。遇到分支太多的情况模型选择工具一旦出错整个流程就乱了。工具调用的错误恢复。模型调用外部 API 可能超时、返回格式异常、参数缺失。工程上不能因为一次工具调用失败就整个对话崩溃。你需要设计重试、降级和“向用户说明求助人工客服”的兜底逻辑。可观测性。Agent 的每一步推理、每次工具调用、每个中间状态都应该能被追踪。否则出了问题你都不知道模型在哪一步“自作主张”了。我做这类系统时的经验法是不要把赌注全押在模型聪明上要通过系统结构去兜底。能用规则约束的优先用规则约束模型只负责规则之外的部分。比如下单流程可以先用正则和表单约束用户输入请模型只做意图识别和语义理解这能极大提升整个系统的稳定性。5.3 没有评估体系的 LLM 应用都是沙滩上盖楼Blindly 往系统里加 Prompt、换模型是不解决问题的。很多团队做 LLM 应用时最常犯的错就是拿几条最好看的例子做演示然后直接上线结果线上各种翻车复盘时连“之前是什么效果”都说不出。正确做法是建立一个评估集哪怕一开始只有几十条。把线上经常出现的问题、典型坏例、业务方关注的边界情况都收进来。每次要换 Prompt、换模型、改检索参数都要在这个评估集上跑一遍比较输出质量。评估指标怎么定简单分类和抽取类任务可以用准确率等机器指标但生成类任务里机器自动指标很难完全判断好坏所以还需要人工评估模板。我常用的方式是三层评估第一层机器指标如检索命中率、答案是否包含指定关键信息第二层LLM-as-Judge让另一个更强模型对答案打分第三层人工抽检。三层配合成本可接受结论也可信。把这个评估集当作和训练数据同等重要的资产持续维护。每次线上发现的 bad case 如果不进评估集就说明你只解决了单点问题没有形成系统改进。这和三年前做模型实验时必须做实验管理是同一个逻辑。6. 常见问题与避坑清单来自实战一线的速查表和路线建议6.1 高频问题速查表以下这些问题几乎是我在带人和交流中反复见到的基本覆盖了从零到一阶段最常见的雷区。整理成一个表格方便你随时翻阅。现象常见原因建议处理方式训练集效果很好验证集无比差过拟合增加数据量、加入正则或权重衰减、引入早停、减小模型规模验证集效果好线上完全不涨数据泄漏、预处理不一致、评估集与线上分布差异按 4.3 节的六条逐一排查显存不足训练中断批次太大、序列过长、全参微调减小批次、开启梯度累积、使用混合精度、改用 LoRA/QLoRA模型预测结果不稳定同一样本每次不同随机种子没固定、推理时存在随机性固定所有随机种子、推理阶段关闭 Dropout、设置确定性模式标注数据质量差模型学到错误逻辑标注规范不明确、多标注员不一致编写标注规范、双人标注并计算一致性、评审争议样本LLM 输出格式偶尔解析失败Prompt 约束力不够改用结构化输出或函数调用能力、在代码里增加重试和格式修正检索结果相关但答案不准确检索片段不够、上下文太长导致模型忽略关键信息调整切片大小、增加重排序模型、优化 Prompt 结构、限定可能答案范围服务接口延迟高模型没有优化、同步推理、缺少缓存模型导出 ONNX 或 TensorRT、开启动态批处理、对高频请求加缓存模型上线后一段时间效果下降数据漂移启动输入分布监控、定期用新数据重训引入 bad case 回流6.2 从零到一的可执行路线建议根据以上所有内容我下面给出一条时间线适合全职或半全职学习的人参考。如果你每天能投入 2 小时左右可以按周为单位灵活拉伸。第 1 到 2 周目标只有一个在本地跑通一个最小闭环。选一个简单分类场景准备 300 到 600 条数据训练一个逻辑回归或简单神经网络模型用 FastAPI 封装接口。不追求效果只求链路完整。期间必须养成实验记录的习惯。第 3 到 6 周目标是把数据工程和实验管理做到规范。整理标注规范建立固定切分和评估集引入 MLflow 或 WB 之类的工具。同时开始尝试用预训练模型做微调至少把 LoRA 的流程跑一遍。可以读几篇模型论文但别陷进公式推导。第 7 到 10 周目标是完成部署和监控初体验。把模型导出为 ONNX放到 Docker 里运行加上日志、指标监控和数据回流。这个阶段你已经开始理解为什么“部署是 AI 工程的分水岭”。第 10 到 14 周建议你自己选择纵深方向。如果你对业务场景感兴趣可以做一个 RAG 知识库问答系统建立它的评估集和 bad case 迭代机制如果你对性能感兴趣可以继续深挖推理优化如果你对数据感兴趣可以在数据标注和漂移检测上做更多文章。建议纵深方向不超过两个一个作为主线一个作为辅助。6.3 几条用真金白银换来的经验最后我把一些不容易放进表格里的经验单独写出来。这些不是知识是教训。第一保留你的第一个最小闭环项目不要做完就删。以后可以通过把玩它做更复杂的事情从逻辑回归换成 BERT从单机 API 变成容器化部署从离线评估加上在线监控。一个可以持续生长的项目远比十个半途而废的项目更有价值。第二遇到问题先看系统再看模型。我见过有人花一周反复调 Prompt最后发现是线上向量化的字典文件和训练时不一致。你必须建立一个思维习惯每当系统表现异常先按“数据链路—预处理—接口—模型”的顺序排查而不是先改模型。第三不要低估业务沟通成本。AI 项目失败的很大原因不是技术不行而是预期管理没做好。在一开始就向业务方说明“当前准确率意味着每 100 条里有几条错、错在哪里”远比最后突然拿出一个 90% 准确率的模型但被问“那 10% 怎么办”时要主动得多。第四也是我自己带团队时最看重的AI 工程这个领域成长速度不靠天赋靠的是你有没有建立一套“发现问题-记录问题-复盘问题”的闭环。把自己每一次调试记录整理成文档一个月后汇总来看你对系统的理解会比闷头做十个任务都要深刻。这个行业的声音总是太吵今天一个新模型明天一个新框架。但真正能走到最后的永远是那些静得下心把一个最小系统做厚、做稳、做可维护的人。希望这篇内容对正在走这条路的人有一点帮助。这条路上没有捷径但少踩一些坑本身就是最快的走法。 AI工程实战指南：从数据到部署的完整路径与避坑要点
这几年我经常收到一类问题“我想做 AI 工程是不是先把 Transformer 和 PyTorch 吃透就行”我通常不直接回答而是反问一句“你准备怎么验证自己学会了”对方如果愣了一下那大概率还没想清楚 AI 工程到底是一门什么手艺。AI 工程不是某一个单点技能它是一条贯穿数据、模型、评估、部署、监控和业务集成的完整链路。单纯会训练模型和能把模型稳定跑在线上并持续产生价值中间隔着大量文档里不会写的脏活、累活和排查经验。这篇文章想把 AI 工程从零到一的完整路径拆开给你看先解决“是什么”和“为什么”再给出一条能直接抄作业的实操路线包括每个阶段的核心环节、关键参数、常见坑点和我的个人经验。适合刚入门想认真做 AI 的人也适合做了一两年仍然觉得“只在调模型没在做工程”的同行对照着查漏补缺。1. AI 工程到底是什么别把智商全押在调模型上1.1 从岗位职责看 AI 工程的能力结构先看一个最简单的事实。如果你去翻几个主流招聘平台上“AI 工程师”和“算法工程师”的 JD会发现问题很有意思。算法工程师的职责大多围绕“模型效果”展开改进网络结构、优化损失函数、提升离线指标。而 AI 工程师的职责描述里通常会出现这些东西负责模型服务化、设计数据回流链路、保障推理性能、参与 MLOps 平台建设、和业务方一起定义评估指标。这两者的边界现在越来越模糊但 AI 工程师的核心定位始终是“把模型变成产品”。说得更直白一点算法工程师的交付物是“效果达标的模型”AI 工程师的交付物是“稳定运行、持续优化、业务可用的系统”。这就是 AI 工程和单纯机器学习最大的区别——它是一个系统问题不是一个模型问题。一个完整的 AI 工程系统至少包含下面这些模块缺一个都会在实际运行中爆雷需求拆解把业务问题翻译成机器学习问题。这一步最反直觉也最容易被新手跳过。比如业务说“帮我们减少人工审核量”你不能直接开干要先弄清楚哪些审核场景是可自动化的、自动化出错后的兜底机制是什么、评估标准是“拦截率”还是“误伤率”。数据工程数据获取、清洗、去重、标注、版本管理。很多人一上来就想着调模型结果 80% 的时间耗在数据上。模型开发基线模型、模型选型、训练、调参、实验管理。这部分是显性的知识网上教程最多。评估体系离线评估和在线评估不仅看准召还要看稳定性、鲁棒性、公平性。部署与服务化模型格式转换、推理优化、API 封装、并发与容灾。监控与迭代数据漂移检测、模型漂移检测、指标异动告警、bad case 回流和定期重训。看到这里你应该意识到了一个关键问题市面上绝大多数“AI 入门教程”只覆盖了上面第三点而且只覆盖了第三点里的“训练模型”这一小步。这就是为什么很多人刷了一堆教程课程都通关了真正上手做一个项目时还是寸步难行——因为他们一直站在链路上最窄的一节里。1.2 为什么“端到端最小闭环”是唯一靠谱的起跑方式知道了能力结构之后你自然会问那我先学哪个我的建议非常明确不要试图把每个模块全部学完再动手直接搭一个最小的端到端闭环然后反复“做厚”它。原因很简单。AI 工程的各个模块之间是强耦合的。数据质量会影响模型效果模型效果会影响在线指标在线指标的设计又反过来约束你该采集什么数据。这种耦合关系只有当你亲手把一条完整链路跑通时才会真正理解。比如你不亲手做一次部署就理解不了为什么离线效果很好的模型到了线上延迟就爆炸你不亲手监听一次数据分布变化就理解不了什么叫“模型越跑越笨”。另外从学习心理学的角度说端到端闭环能给你高频的正反馈。一个能点开网页、输入文本、返回预测结果的 Demo哪怕里面用的是最简单的线性模型它在“激励你继续往下走”这件事上的效果远好于书桌前啃一个月数学推导。我见过太多刚开始信心满满、后来在反向传播推导里默默放弃的新手。这不仅是方法问题还是策略问题。所以接下来的内容我核心围绕一件事如何从零开始一步步把你的第一个 AI 工程闭环搭起来并且每一步都讲清楚“为什么这样做”。2. 第一块基石用最小闭环跑穿全流程2.1 先选一个能让业务一眼看懂价值的场景做最小闭环第一个要避开的大坑是“选题过于抽象”。不要一上来就做“通用意图识别系统”甚至不要做“情感分析系统”太宽了。建议选一个边界清晰、数据容易获取、效果能被非技术人员一眼看懂的任务。我给你三个比划起来最顺手的候选方向都是我自己带新手跑过无数次的情况垃圾评论识别输入一条评论输出“正常/垃圾”。数据可以从公开竞赛、开源仓库里拿也可以自己从社交平台爬几百条。客户咨询分类输入一条用户咨询输出“退款/物流/售后/其他”等几个固定标签。这个任务的收益特别直观后续还能自然延伸到一个简单的客服问答 Agent。商品标题标准化输入一个商品标题输出品类标签或关键属性。电商场景下的典型问题数据也相对容易标注。我自己最推荐第二个“客户咨询分类”。它有三个优点业务价值一眼可见类别固定评估指标清晰做完之后可以直接扩展成知识库问答或 Agent 应用不会浪费前期工作。2.2 最小闭环的五步实操选定场景后就用最小成本把它跑通。每一步都带着目的去做我不建议为了“显得完整”而上重型工具。第一步搞定数据集。假设你做咨询分类先定义 4 到 6 个类别。数据量不需要大每类 100 条左右就能启动总计 400 到 600 条。这阶段的目标不是训练一个 SOTA 模型而是把流程打通。数据可以来自你所在公司真实的客服记录、公开的客户留言数据集、或者你自己和朋友模拟编写的典型问题。注意如果你用的是模拟数据一定要在后续换成真实分布的数据否则效果会严重失实。第二步清洗和整理数据。把文本里的换行符、多余空格、无意义符号去掉统一大小写中文任务还要注意繁体转简体去重。清洗逻辑要记录在一个脚本里不要手动改数据文件。原因后面会讲先记住数据清洗必须可复现。第三步跑一个负责任的基线。注意我用的是“负责任的基线”而不是“随便跑跑”。一组规范的做法是固定 80% 训练集、10% 验证集、10% 测试集用 TF-IDFTerm Frequency-Inverse Document Frequency词频-逆文档频率向量化加一个简单的逻辑回归模型记录它在测试集上的准确率和 F1。这组结果就是你之后所有尝试的“地板”。from sklearn.feature_extraction.text import TfidfVectorizer from sklearn.linear_model import LogisticRegression from sklearn.model_selection import train_test_split from sklearn.metrics import classification_report X_train, X_test, y_train, y_test train_test_split( texts, labels, test_size0.2, random_state42, stratifylabels ) vec TfidfVectorizer(max_features5000, ngram_range(1, 2)) X_train_vec vec.fit_transform(X_train) X_test_vec vec.transform(X_test) clf LogisticRegression(max_iter1000) clf.fit(X_train_vec, y_train) print(classification_report(y_test, clf.predict(X_test_vec)))请注意random_state42和stratifylabels这两行前者保证你的实验可复现后者保证类别分布被一致地切分。很多新手忽略这两个参数结果不同次实验之间对比变得没有意义。第四步封装 API。哪怕只是本地运行也要用 FastAPI 把一个POST /predict接口暴露出来输入是一段文本输出是类别和置信度。为什么要这一步因为只有把模型包装成接口你才能体会到“线上系统怎么和模型交互”同时这份代码会直接复用到后续部署环节。from fastapi import FastAPI from pydantic import BaseModel app FastAPI() class PredictRequest(BaseModel): text: str class PredictResponse(BaseModel): category: str confidence: float app.post(/predict, response_modelPredictResponse) def predict(req: PredictRequest): vec_text vec.transform([req.text]) proba clf.predict_proba(vec_text)[0] idx proba.argmax() return PredictResponse( categoryclf.classes_[idx], confidencefloat(proba[idx]) )第五步做一次简单的人工评估。这时候不要再去看整体准确率而是把 50 条预测结果打印出来和业务方或你自己扮演业务方逐条看哪些预测是严重不可接受的哪些是系统边界外的。这一步的目的是让你建立对“离线指标”和“真实体验”之间差距的直觉。准确率 90% 的系统可能因为那 10% 的错误全部集中在最敏感的场景而完全无法上线这种问题只有一边看样本一边思考才发现得了。2.3 最小闭环阶段的三个关键心态第一接受“丑到能用”。这个阶段的代码可以丑可以没有设计模式甚至可以只有一个脚本和一个 API 文件但必须端到端跑通。完成比完美重要一百倍。第二不要急着上 GPU。400 到 600 条数据的 TF-IDF 逻辑回归CPU 上几秒钟就训练完了。过早启动 GPU 云主机不仅浪费钱还会让你养成“依赖大模型才能干活”的坏习惯。硬件升级应该发生在你明确知道它要解决什么问题之后。第三把实验记录做起来。哪怕只是维护一个 Markdown 文件记录每次改了数据、特征或模型参数后测试集指标的变化。这个习惯散漫到不能再散漫但当我后来带工程师时发现这条能做到的人不超过 20%。不做实验记录你后面所有“效果优化”都会变成玄学。3. 深入核心当数据、训练和实验管理成为主战场3.1 数据工程的优先级永远高于调参把第一个闭环跑通之后你会很自然地想去“把效果提高一点”。这时候新手最常见的做法是换更强的模型老手通常先回到数据上去找机会。根据我个人经验数据侧的机会往往远大于模型侧。数据侧有几个维度值得你仔细打磨标注一致性。找两个人分别标注同一批数据计算一致性你会惊讶地发现在最简单的分类任务上标注员的初始一致性可能只有 85% 左右。不一致的样本意味着标签有噪声模型学这部分时会浪费大量容量。你需要制定标注规范对争议样本进行评审修订。不然你费尽心思调参收益可能远不如把标签理顺。类别平衡。如果你的类别分布是 90%“物流”、3%“退款”、2%“售后”、5%“其他”模型即使把后面三类全预测错准确率也有 90%。此时必须看各类别的精确率和召回率并用 F1 或 macro-F1 等指标评估。对应地可以在采样时对少样本类别做过采样或者用类别权重调整损失函数。数据版本管理。这句话听起来像在讲大厂基建其实一个人也能做。最简单的做法是每次改动数据后生成一个带时间戳的文件夹并记录数据文件的内容哈希值比如用 md5。这样一来几个月后你说不出“这个模型是用哪批数据训的”这种话在排障时会非常被动。建议你在这一步就把训练集、验证集、测试集划分逻辑固定下来。把划分代码写进脚本而不是手动切文件。划分逻辑必须包含随机种子。线上系统以后会不断涌入新数据如果你没有一套确定性的划分逻辑训练集和测试集之间产生数据泄漏都是迟早的事。数据泄漏的典型表现是离线评测结果极高线上效果崩得一塌糊涂。3.2 模型选型从基线到强模型要走得克制基线模型跑通后你可以开始尝试更强的模型了。但模型选型的逻辑不是“越强越好”而是“在用得起的前提下选择性价比最高的”。以文本分类任务为例一般可以按这样的层次推进词向量加权平均 机器学习分类器。适合数据量很小或强实时要求的场景训练快、部署简单。预训练模型微调比如用几十到几百 MB 参数规模的模型做分类。适合中低延迟要求、数据量在几千到几万条的场景性价比极高。大语言模型 In-Context Learning也就是通过 Prompt 让模型直接输出分类结果。句子复杂、类别边界模糊、有大量隐含语义时效果最好但成本高、延迟大且输出不稳定。关于用不用微调对刚入门的人我有一个很实际的经验法则如果 5000 条已标注数据拿在手上先尝试用 Prompt 或 Re-ranking 的方法压榨大模型如果数据量到了 2 万条以上再认真考虑微调。微调一个预训练模型并没有想象中那么神秘现在通用的做法是 LoRALow-Rank Adaptation低秩适配或 QLoRA在显存有限的显卡上也能训练出效果不错的适配器。具体做法是冻结原始模型权重只训练一小部分低秩增量矩阵。这个方案的好处有两个训练成本低适配器文件很小便于后续管理和部署。这里特别提醒一个很容易犯的错不要一上来就让模型在所有训练数据上跑很多轮期待“练得越久越准”。深度学习里的过拟合来得比你想象的快训练集准确率接近 100% 而验证集开始下降是一个很典型的分界点。你要做的是“早停”也就是监控验证集指标当它连续若干个 epoch 不再提升时及时保存当前最优权重并停止训练。3.3 实验管理是 AI 工程和 AI 自学的分水岭如果说数据工程是第一道分水岭那实验管理就是第二道。它决定你是“科学地做实验”还是“撞运气”。一套哪怕最轻量的实验管理也应该包含这些信息数据集版本和内容哈希。数据预处理配置清洗规则、向量化参数、切分种子。模型结构配置模型名、层数、参数量、LoRA 秩。训练超参数学习率、批次大小、训练轮数、权重衰减、预热步数。环境信息Python 版本、依赖库版本、GPU/CPU 型号。实验结果验证集和测试集上的完整指标、训练时长、显存占用。很多人觉得记这些太麻烦但等你做第十次实验时就会发现找不到第一次实验用的超参意味着一切都得从头来浪费的时间远大于随手记录的那十秒钟。工具层面WBWeights Biases和 MLflow 都是不错的选择。如果不想引入额外服务用纯文本记录也能接受关键是“坚持记”。超参数方面文本分类任务里最值得优先调的通常有这么几项学习率。预训练模型微调一般用 1e-5 到 5e-5 这个范围太大会灾难性遗忘太小收敛极慢。批次大小。受显存约束一般 8 到 32。如果太大可以用梯度累积来模拟大批次。训练轮数。3 到 10 轮之间比较常见配合早停策略。随机种子。固定随机种子后实验才能复现。不同种子之间结果有波动时最好一个配置跑 3 次取均值再比较。每改一个新配置只动一个变量。这是老生常谈但真正执行的人很少。很多工程师的调参过程是“换了模型、改了学习率、顺便换了一版数据”最后效果变差了你根本不知道是谁的锅——这种实验记录做一百次也积累不出可迁移的经验。3.4 不要为了训练而训练先试试不训练的解法在聊训练技术之前我必须插一段非常重要的话很多真实业务场景根本轮不到你训练模型。举例来说如果业务方只是想把常见退款问题进行关键词分流一个写好的正则表达式或者一份 Excel 规则表可能已经覆盖了 80% 的场景。这种情况下硬上微调模型只会让系统更难维护也让你的交付周期变得冗长。AI 工程的判断力有很大一部分体现在“识别哪些问题根本不需要 AI”上。如果决定引入模型但数据量不够也建议先试试大模型的 In-Context Learning。那意味着你只需要写好 Prompt、定义好分类类别和少量示例然后用一个 API 调用完成推理。你好几天不用做数据标注先验证“如果模型效果足够好业务是否愿意接受成本和延迟”。这种验证思维是 AI 工程里最容易缺失的环节因为绝大多数教程只教“模型怎么训”从不教你“该不该训”。4. 上线与运维工程化在部署和监控上拉开差距4.1 模型服务化从可运行到可上线很多人以为模型跑通了就大功告成。实际上从“能运行”到“能上线”之间还有一层非常重要的工程化打磨。首先模型格式转换是个绕不开的环节。如果你在 PyTorch 里训练了模型部署时不会直接把它挂在 Web 服务里让 FastAPI 调用 PyTorch那样每次请求都会把 Python 和深度学习框架全部加载一遍不仅慢而且吃资源。更常见的是把模型导成 ONNXOpen Neural Network Exchange开放神经网络交换格式或者直接用推理优化框架加载。ONNX 的好处是格式统一、可跨框架、可以配合 ONNX Runtime 做 CPU/GPU 加速。转换时一定要在转换前后做一次相同输入的输出对比误差控制在极小范围内否则可能是某些算子不支持导致的精度损失。然后要说推理性能优化。最有效的三板斧是量化、批处理、缓存。量化简单说就是把模型的浮点数参数从 32 位降到 16 位甚至 8 位换来更小的模型体积和更快的推理速度代价是精度略降。批处理思想则是把多个请求攒在一起喂给模型充分利用 GPU 并行计算能力显著提升吞吐。缓存策略则适合那些请求高度重复的场景比如同一句客服咨询经常出现把已算好的结果放缓存里可以省掉大量重复计算。下面是一个基于 FastAPI 的部署示例配合 ONNX Runtime 做 CPU 推理。这种方案的好处是环境依赖很小部署到一台普通 Linux 服务器就能跑。import onnxruntime as ort import numpy as np from fastapi import FastAPI from pydantic import BaseModel app FastAPI() session ort.InferenceSession(model.onnx, providers[CPUExecutionProvider]) input_name session.get_inputs()[0].name label_list [物流, 退款, 售后, 其他] class Req(BaseModel): text: str app.post(/predict) def predict(req: Req): # 假设预处理逻辑已封装为 preprocess 函数 input_ids, attention_mask preprocess(req.text) preds session.run( None, {input_name: input_ids, attention_mask: attention_mask} )[0] idx int(np.argmax(preds[0])) return {category: label_list[idx], confidence: float(preds[0][idx])}这段代码只是一个骨架但你应该能看出真正的难点往往不在 API 本身而在preprocess函数里它必须和训练时的预处理逻辑完全一致。这里藏着投产阶段最典型的坑——线上预处理不一致导致效果雪崩。我建议你把特征处理器单独封装成一个模块训练和推理共用同一套代码从源头上杜绝不一致。4.2 监控模型不是上线就完事而是上线后才开始模型上线后最危险的事情不是模型本身效果差而是它“悄悄变差”而你不知道。数据漂移是最常见的一种情况。举例来说你的咨询分类模型在 5 月份训练时“退款”类别的表述还很常规。到了 6 月份平台大促出现了大量“价格保护”“差价退回”等新话术。这些输入和训练数据分布产生了明显偏移模型预测就会开始出错。也就是说业务变了、用户说话方式变了模型没变效果自然滑落。应对数据漂移最基本的一步是监控输入特征分布的统计量比如向量化后每个特征的均值方差、每类文本的长度分布、常见关键词频率等。更直接的方式是做线上预测置信度分布监控如果一段时间的平均置信度明显下降往往意味着模型遇到了它没见过的东西。另一个必须做的是 bad case 回流机制。线上预测错了要能把样本保存下来定期交给人工标注或直接进入评估集。这一步说起来容易做起来难难在需要业务方的配合你得定义清楚“什么样的结果算错”。通常的做法是在业务系统里增加“结果是否有用”的反馈按钮或者事后抽样审计。没有数据回流模型迭代就成了无源之水。这一阶段我特别想提醒初学者不要一上来就搞 Kubernetes。K8s 不是 AI 工程的全部基础设施。对于一个日访问量只有几千的小模型服务一台带 Docker 的服务器、一个 systemd 服务和一份日志轮转配置就已经超过一半小公司的运维水平。过早引入微服务架构和大规模编排系统只会让你陷入容器调度的泥潭而不是帮你解决真正的模型问题。4.3 线上效果和离线指标对不上从这六个方向排查这是 AI 工程里最高频、也最让人崩溃的问题。离线测试集 F1 0.92上线后实际反馈准确率却不到 0.7你可以按下面的顺序逐项排查数据泄漏。检查数据清洗和特征提取过程里有没有把未来信息或标签信息混进训练特征。比如用会话结束后才产生的事件做特征属于典型的时序泄漏。预处理不一致。确认线上 API 用的分词、向量化、样本截断逻辑是否和训练时完全一致。这是头号嫌疑。评估集分布偏差。训练数据来自某个历史时段但线上流量分布已经改变。建议定期重新切分评估集并混入近期 bad case。推理与训练模式差异。比如训练时用了 Dropout推理时忘了切到 eval 模式或者批量归一化的统计量在训练和推理时不一致。细节问题但影响很大。业务真实反馈与标注口径差异。线下标注觉得是“退款”线上用户实际意图是“投诉”。这种情况只能靠校准标注规范。阈值设置不合理。分类器输出的置信度并不天然对应业务决策。建议在业务侧基于精确率-召回率曲线重新选择决策阈值而不是硬用 0.5。5. 当代 AI 工程的必修课LLM 应用与 Agent 的工程化视角5.1 当模型变成“可调用的外部能力”工程问题反而变大了最近几年AI 工程的重心发生了一个很有意思的转移模型本身从“需要你亲手训练的权重”逐渐变成“一个可以通过 API 调用的能力”。尤其是大语言模型你不需要准备训练数据不需要 GPU只需要写一段 Prompt 就能完成以前需要微调才能实现的任务。听起来工程变简单了但实际做下来你会发现难点转移到了一个新的链路如何把不可控的模型输出变成稳定可控的产品行为。以最常见的 RAGRetrieval-Augmented Generation检索增强生成应用为例。它被广泛用于“基于私有知识库的问答系统”。链路看起来很简单把文档切成小块做向量化索引用户提问时先从向量库检索相关片段把片段拼到 Prompt 里让模型生成答案。但这每一步都有大量工程细节。切片是第一个坑。文档怎么切、按什么粒度切直接影响检索质量。按固定长度切简单但容易把上下文截断导致语义不连贯。按章节和标题层级切效果通常更好但要求你能解析文档结构。向量化模型怎么选、是通用模型还是领域微调模型影响更大。到了生成阶段Prompt 是否约束了“只依据给定内容回答”决定了模型会不会一本正经地编造答案。所以你看这跟训练模型的系统问题没有本质区别你依然需要评估、调优、监控和及时干预只是优化的对象从“模型权重”变成了“检索链路 Prompt 策略 模型选择”。5.2 Agent 工程的三个核心控制点Agent智能体是把 LLM 和外部工具结合的系统比如让它查订单、发退款、改密码。这是当前 AI 工程里最活跃也最容易翻车的领域。从工程视角看Agent 系统的复杂度来自模型输出天然不稳定而工程上又希望系统行为尽量确定性可控这就需要三个核心控制点。意图识别和状态管理。一个 Agent 通常要处理多轮对话你需要把用户当前处于哪个流程节点、已经收集到哪些信息、下一步要调用什么工具用一套状态机管理起来而不是完全依赖模型自由发挥。遇到分支太多的情况模型选择工具一旦出错整个流程就乱了。工具调用的错误恢复。模型调用外部 API 可能超时、返回格式异常、参数缺失。工程上不能因为一次工具调用失败就整个对话崩溃。你需要设计重试、降级和“向用户说明求助人工客服”的兜底逻辑。可观测性。Agent 的每一步推理、每次工具调用、每个中间状态都应该能被追踪。否则出了问题你都不知道模型在哪一步“自作主张”了。我做这类系统时的经验法是不要把赌注全押在模型聪明上要通过系统结构去兜底。能用规则约束的优先用规则约束模型只负责规则之外的部分。比如下单流程可以先用正则和表单约束用户输入请模型只做意图识别和语义理解这能极大提升整个系统的稳定性。5.3 没有评估体系的 LLM 应用都是沙滩上盖楼Blindly 往系统里加 Prompt、换模型是不解决问题的。很多团队做 LLM 应用时最常犯的错就是拿几条最好看的例子做演示然后直接上线结果线上各种翻车复盘时连“之前是什么效果”都说不出。正确做法是建立一个评估集哪怕一开始只有几十条。把线上经常出现的问题、典型坏例、业务方关注的边界情况都收进来。每次要换 Prompt、换模型、改检索参数都要在这个评估集上跑一遍比较输出质量。评估指标怎么定简单分类和抽取类任务可以用准确率等机器指标但生成类任务里机器自动指标很难完全判断好坏所以还需要人工评估模板。我常用的方式是三层评估第一层机器指标如检索命中率、答案是否包含指定关键信息第二层LLM-as-Judge让另一个更强模型对答案打分第三层人工抽检。三层配合成本可接受结论也可信。把这个评估集当作和训练数据同等重要的资产持续维护。每次线上发现的 bad case 如果不进评估集就说明你只解决了单点问题没有形成系统改进。这和三年前做模型实验时必须做实验管理是同一个逻辑。6. 常见问题与避坑清单来自实战一线的速查表和路线建议6.1 高频问题速查表以下这些问题几乎是我在带人和交流中反复见到的基本覆盖了从零到一阶段最常见的雷区。整理成一个表格方便你随时翻阅。现象常见原因建议处理方式训练集效果很好验证集无比差过拟合增加数据量、加入正则或权重衰减、引入早停、减小模型规模验证集效果好线上完全不涨数据泄漏、预处理不一致、评估集与线上分布差异按 4.3 节的六条逐一排查显存不足训练中断批次太大、序列过长、全参微调减小批次、开启梯度累积、使用混合精度、改用 LoRA/QLoRA模型预测结果不稳定同一样本每次不同随机种子没固定、推理时存在随机性固定所有随机种子、推理阶段关闭 Dropout、设置确定性模式标注数据质量差模型学到错误逻辑标注规范不明确、多标注员不一致编写标注规范、双人标注并计算一致性、评审争议样本LLM 输出格式偶尔解析失败Prompt 约束力不够改用结构化输出或函数调用能力、在代码里增加重试和格式修正检索结果相关但答案不准确检索片段不够、上下文太长导致模型忽略关键信息调整切片大小、增加重排序模型、优化 Prompt 结构、限定可能答案范围服务接口延迟高模型没有优化、同步推理、缺少缓存模型导出 ONNX 或 TensorRT、开启动态批处理、对高频请求加缓存模型上线后一段时间效果下降数据漂移启动输入分布监控、定期用新数据重训引入 bad case 回流6.2 从零到一的可执行路线建议根据以上所有内容我下面给出一条时间线适合全职或半全职学习的人参考。如果你每天能投入 2 小时左右可以按周为单位灵活拉伸。第 1 到 2 周目标只有一个在本地跑通一个最小闭环。选一个简单分类场景准备 300 到 600 条数据训练一个逻辑回归或简单神经网络模型用 FastAPI 封装接口。不追求效果只求链路完整。期间必须养成实验记录的习惯。第 3 到 6 周目标是把数据工程和实验管理做到规范。整理标注规范建立固定切分和评估集引入 MLflow 或 WB 之类的工具。同时开始尝试用预训练模型做微调至少把 LoRA 的流程跑一遍。可以读几篇模型论文但别陷进公式推导。第 7 到 10 周目标是完成部署和监控初体验。把模型导出为 ONNX放到 Docker 里运行加上日志、指标监控和数据回流。这个阶段你已经开始理解为什么“部署是 AI 工程的分水岭”。第 10 到 14 周建议你自己选择纵深方向。如果你对业务场景感兴趣可以做一个 RAG 知识库问答系统建立它的评估集和 bad case 迭代机制如果你对性能感兴趣可以继续深挖推理优化如果你对数据感兴趣可以在数据标注和漂移检测上做更多文章。建议纵深方向不超过两个一个作为主线一个作为辅助。6.3 几条用真金白银换来的经验最后我把一些不容易放进表格里的经验单独写出来。这些不是知识是教训。第一保留你的第一个最小闭环项目不要做完就删。以后可以通过把玩它做更复杂的事情从逻辑回归换成 BERT从单机 API 变成容器化部署从离线评估加上在线监控。一个可以持续生长的项目远比十个半途而废的项目更有价值。第二遇到问题先看系统再看模型。我见过有人花一周反复调 Prompt最后发现是线上向量化的字典文件和训练时不一致。你必须建立一个思维习惯每当系统表现异常先按“数据链路—预处理—接口—模型”的顺序排查而不是先改模型。第三不要低估业务沟通成本。AI 项目失败的很大原因不是技术不行而是预期管理没做好。在一开始就向业务方说明“当前准确率意味着每 100 条里有几条错、错在哪里”远比最后突然拿出一个 90% 准确率的模型但被问“那 10% 怎么办”时要主动得多。第四也是我自己带团队时最看重的AI 工程这个领域成长速度不靠天赋靠的是你有没有建立一套“发现问题-记录问题-复盘问题”的闭环。把自己每一次调试记录整理成文档一个月后汇总来看你对系统的理解会比闷头做十个任务都要深刻。这个行业的声音总是太吵今天一个新模型明天一个新框架。但真正能走到最后的永远是那些静得下心把一个最小系统做厚、做稳、做可维护的人。希望这篇内容对正在走这条路的人有一点帮助。这条路上没有捷径但少踩一些坑本身就是最快的走法。