1. 一切的起点不要先选模型先定义问题做AI工程跟我最早做传统后台开发的感受完全不一样。传统开发是“需求清楚、边界清楚、逻辑可以穷举”AI工程是“目标清楚、路径模糊、结果只有概率可预期”。很多刚入行的朋友挂在嘴边的话是“我要做一个智能客服”“我想接入大模型”但真问下去往往说不清楚这个系统要解决什么业务指标、失败成本是多少、用户最不能接受什么错误。如果你能记住一件事我希望是AI工程不是“用模型实现功能”而是“在不确定性中构建可控系统”。项目标题起名“ai-engineering-from-scratch”本身就很诚实——从零开始意味着你先得把地基夯实。这个地基不是模型而是需求拆解、数据、评测、成本和系统容错。我见过太多团队约等于“拿着锤子找钉子”模型选得很大Prompt写得天花乱坠最后在评测集上一测连自己的验收标准都拿不出来。所以第一步我建议你先回答四个问题再碰任何代码输入和输出到底是什么输入是纯文本还是有结构化字段输出要不要限制格式这个功能的“好”怎么定义准确率用户满意度还是单位成本下降错了会怎样错了能重试吗需要人工兜底吗现在有人工方案吗人工方案的成本和瓶颈是什么如果你发现第四个问题答不上来大概率这个AI项目还没到启动时机。工程化的本质是把不可控的模型输出嵌入到可控的业务流里面去而不是让模型直接面向用户裸奔。1.1 你以为的“AI工程”和实际的差距很多教程把AI工程包装成“调接口写Prompt”的组合这是最大的误导。真正进入落地阶段你会发现工作量的分布大概是这样的数据获取、清洗、摸底、标注约40%的工作量评测集构建、评测流程、回归机制约20%的工作量模型选型、微调/提示词调优、RAG链路约20%的工作量服务化、监控、告警、成本治理、人机协同约20%的工作量这组数字是我在实际项目里慢慢修正出来的不一定绝对准确但方向是靠谱的。刚入行的人往往把80%精力放在“改Prompt”上忽略了数据和评测结果就是模型在样例上表现惊艳一换场景就崩而且你不知道它为什么崩。因为你没有评测集也没有失败样本归因机制。“从零开始”的另一个含义是你必须自己搭建这套反馈闭环。模型API所有人都能调用但数据怎么沉淀、怎么标注、怎么追踪错误案例这些才是每个团队的私有资产。有人问过我是不是可以用开源数据集起家可以但要注意分布偏移问题公开数据集描述的是“一般世界”你的业务场景是“特定世界”两者之间的gap恰恰需要你自己去用真实业务样本补齐。1.2 从需求到可行性一个需求如何变成工程条目我习惯用所谓“需求翻译法”把业务语言翻译成模型任务语言。举个例子业务方说“我们要做一个能回答产品问题的智能助手”这句听起来没问题但没法直接做工程。你得把它翻译成任务类型这是开放域问答还是检索增强问答大概率是后者。知识来源产品知识分散在哪些文档里文档如何更新旧的怎么办用户诉求用户问“退换货流程”是要步骤列表还是要一句结论需要附带出处吗边界限制哪些问题绝不能答比如医疗建议、法律责任、价格承诺。失败兜底答不上来时要不要引导转人工翻译完之后你会突然发现你需要的不是“大模型”而是一套知识管理流程加上一个合适的答案生成模块。工程化的起点是让需求细化到能用工程手段去验证的程度。2. 数据与评测决定成败的两块隐形基石很多人做AI项目上来就调API但真正决定项目天花板的是数据和评测。模型能力再强喂进去的数据是脏的评测标准是模糊的你等于开着跑车在没有路标的高速公路上狂奔翻车只是时间问题。本章聊一下我怎么把这两块地基打牢。2.1 数据治理清洗、标注、版本化的一条龙流程放在传统的后端工程里数据往往是结构化、可校验的。AI工程里的数据通常是文档、对话记录、客服话术、日志这些数据噪点极大。我处理过一份客服对话记录里面包含大量口语缩写、错别字、emoji、甚至不同客服人员的私人备注。直接喂给模型模型会把备注当成正式话术学进去。我的建议是做个“数据体检”三步走统计摸底文本长度分布、词频、重复率、特殊字符占比。这些指标能快速暴露出数据质量问题的明显特征比如某类数据只集中在某几个来源渠道或者某些样本长度严重偏离均值。清洗策略规则去重、敏感信息脱敏、语言过滤、格式归一化。清洗不能过度保留口语化表达有助于模型适应真实场景但要去掉与业务无关的聊天杂质比如删掉员工之间的无关闲聊。人工抽样复核随机抽100条样本逐条看完建立“错误类型清单”。这一步没法自动化但非常重要。你会发现有相当一部分样本根本不属于这个任务比如标着“咨询”的样本里面混着投诉和催单。数据版本化说白了就是让你每次实验都能追溯到“用了哪一份数据”。我见过有团队改数据改到一半发现模型效果变好是因为手误混入了测试集样本白白浪费了几天时间。现在即使不做重型数据平台我也会保留带日期和hash的数据目录比如data/2025-01-12_v3_hash6789让每次实验可复现。2.2 评测集设计先有尺子再谈调优评测集是AI工程里最容易被低估的东西。没有评测集你所谓的“效果挺好的”跟掷骰子没什么区别。我的经验是先定义评测维度再采集样本最后确定打分方式。常见的评测维度可以分成三类正确性答案是否准确、有没有幻觉、是否与知识源一致。这个维度最核心也最难自动判断。完整性该覆盖的几个子点是否都覆盖到了。比如问退换货流程用户既要流程步骤也要时间限制、费用说明漏掉任意一个都算不完整。安全性/鲁棒性遇到敏感问题、边界问题、乱输入时是否给出合规且不崩坏的响应。评测样本要从真实用户请求里采样而不是自己编。可以在上线前先做“影子模式”把线上请求复制一份打到模型上不加响应只记录攒一段时间后再抽样本。样本量不需要多几百条高质量、带上文、带标准答案的评测样本已经能支撑绝大部分调优工作。打分方式我推荐人评和机评结合。机器打分用LLM-as-a-judge速度快但要注意评分模型本身会有偏见人工抽评则用来校准机器评分比如每周抽20条确认机器打分的逻辑没有跑偏。评测集也要持续追加把线上出现的新错误类型沉淀成评测样本这样才能形成“发现错误—修复—回归验证”的闭环。3. 模型选型与训练/微调路径别掉进“大模型万能”的坑选模型这事特别容易上头。大模型一出新版本就有人盘算要不要全量迁移开源模型一开放就有人想着本地化部署。但工程化的原则是“够用就好扩展可控”。先搞清楚模型在系统里承担的角色再根据效果和成本去挑。我从实际经验出发聊聊怎么做一个理性的模型选型和调优思路。3.1 基座模型选择的核心考量首先我们要区分“基座模型”和“最终应用模型”。基座模型是一个泛化的、不做业务适配的底模能力很强但缺乏专业领域和业务规则的知识。最终落地的时候通常需要围绕基座模型做提示词、检索、微调或后处理。选基座模型的核心考量有几个维度语言能力中英兼顾能力、代码理解、长上下文窗口。如果业务涉及大量长文档上下文窗口和检索能力比单次生成质量还重要。生态成熟度是不是容易接入现有框架有没有完整的API和社区工具链这决定了你的开发效率。部署形态闭源API还是开源权重闭源API省事但受网络、成本和数据出域约束开源权重可以本地化部署但要自己搞定推理优化和运维。成本控制不仅是单次调用成本还要算上缓存、评测、重试带来的隐形成本。量大以后token开销是笔不能忽视的预算。一个常见误区是追新觉得大版本模型一定比小版本强。实际上小模型在垂直场景里微调后往往比大模型更“听话”。因为小模型protocol比较窄约束力强反而不会被无关的知识带偏。工程上我的策略是用中等规模的模型搭基线跑通链路之后再根据评测短板决定升级方向是换更大模型还是做RAG还是微调。3.2 微调、提示工程与RAG的边界划分这三条路不是互斥关系而是有优先级。我的经验是先做提示工程再做RAG最后才考虑微调。但很多人顺序搞反了上来就微调结果练出一堆“死记硬背”的样本遇到稍微变化的问法就懵。用一个不严谨但好懂的类比提示工程相当于你给一个聪明实习生写清楚工作流程RAG相当于给这个实习生一个随时可查的资料库微调相当于把这个实习生送进专门的培训班让他把业务知识内化成直觉。如果你连工作流程都没理清楚资料库也没建好直接送去培训班效果一定不好。微调最值得用的场景是“输出风格约束”和“结构化指令遵循”不是“灌输知识”。知识类的信息更新快、面广适合放在RAG或外置知识库里而风格、格式、角色设定属于稳定且固定维度适合微调。举个例子我做过一个生成周报摘要的功能目标输出非常固定三句话、量化指标、下一步行动。普模型默认的输出太啰嗦用几百条样本微调一个轻量模型比搭RAG链路和反复调提示词都稳。因为周报摘要的“知识”从输入里拿根本不需要外部知识库。RAG则是解决“知识时效性”和“可溯源”问题的首选。做工程要记住本来就不应该让模型凭“记忆”生造出一个你没喂过的事实。RAG先检索再生成既解决了知识来源也为答案提供了解释依据用户和合规团队会非常感谢你。但RAG链路要重点处理检索质量检索短板是先用数据库召回一堆不相关结果再让模型强行作答那幻觉就管不住了。3.3 训练/微调中的资源估算如果确实走到微调那一步资源估算就是一个非常现实的问题。我给团队做估算习惯按这个逻辑先明确训练参数和方法再算显存和时间。很多人一上来就问“显存得多大”没有上下文这个问题没法回答。微调通常分几种层次从参数效率到全参依次是LoRA/QLoRA只训练少量低秩适配器显存开销小往往单卡就能跑。全参数微调所有权重更新显存需求高通常需要多卡并行还会涉及梯度检查点、混合精度等策略。以7B量级的模型为例QLoRA在单张24GB显存的卡上是可以跑的序列长度设短一点batch size调小基本能跑通。全参数微调则建议至少具备4张32GB显存以上再来谈稳定练下去。具体数字跟框架、序列长度、batch size强相关这不是a×b那么简单的公式你需要多做几次小规模试运行来估算。我踩过的一个坑一次性用全量数据微调结果跑了十几个小时后发现loss异常查下来发现是数据里混入了大量重复样本模型直接过拟合到重复话术上。后来我改成先跑几百条小batch试探性验证同时把训练样本做了去重和分布检查再正式启动全量训练。4. 工程化落地从POC到可维护系统模型效果调到位只完成了30%的工程工作。接下来是更琐碎、更影响上线的部分怎么把这个AI能力做成一个稳定、可运维、可迭代的系统。本章聊架构、缓存、监控和成本治理这几个硬核问题。4.1 系统架构模型只是服务的一个组件我在做AI服务设计时会画一条“主链路”和若干“周边链路”。主链路是用户的请求怎么进来、怎么检索、怎么生成、怎么返回周边链路包括数据更新、评测回归、人工修正、日志归档。模型在主链路里只是一个组件不是全部。一个典型的简化架构可以这样描述用户请求先经过预处理意图识别、格式校验、敏感词过滤再到检索模块如果走RAG然后拼接上下文调用模型推理最后经过后处理规则校验JSON格式、补充段落、给出来源返回给业务方。模型输出不可信所以后处理一定要做尤其是对接到自动化流程的场景。当初做订单查询类助手时模型偶尔会把订单号编得无比真实还好我加了正则校验发现数字格式不对就触发重试否则用户会拿着假订单号去问人工直接炸掉客服工单体系。业务规模再大一点还需要考虑限流和降级方案。模型API不稳定或者网络出现抖动必须有备用路径比如切换到稍弱但更稳定的备选模型或者提示“服务繁忙”并引导人工介入。不要觉得这是小题大做线上事故往往就发生在模型服务方变更版本或者限流的时候。4.2 可观测性日志、指标、成本追踪AI服务和传统服务在可观测性上最大的差异是传统服务看错误码和耗时AI服务还得看“内容质量”和“token用量”。我在项目里维护一套自己的观测清单大致分四层系统层响应时间、错误率、并发量、排队长度。这一层和传统监控一致。成本层模型调用次数、输入token数、输出token数、缓存命中率。这一层直接决定你月底的账单。质量层人工抽评分数、机器评分趋势、用户反馈率比如点了“没帮助”的比例。追踪层每一条请求的完整链路包括提问、检索结果、拼接上下文、模型原始输出、后处理结果。这个链路是排查问题的重要依据没有完整日志出问题只能靠猜。追踪层最容易被忽略但线上问题来了你能回复业务方的是“我们查了请求日志发现用户输入‘xxx’检索返回为空因此模型给了兜底回复”而不是“应该是模型抽风了”。前者叫工程后者叫玄学。缓存在这层也有奇效。AI服务通常可以用“语义缓存”把相同或相近的请求直接复用结果特别是FAQ场景命中率很高能大幅节约成本。但缓存要注意时效性如果知识库更新涉及更新的问题缓存必须失效。5. 常见问题与排查技巧实录我把自己在真实项目里遇到的坑挑几个典型的记录下来希望帮你跳过几个明显的深坑。5.1 一个典型的失败案例评测完成后效果依然不理想有一次我给一个客服助手项目做上线前的评测评测集准确率到了92%业务方也点头了结果小流量上线后用户满意度反而下降了。当时第一反应是“评测集有问题”复查发现评测集里的样本都是正式、完整的用户提问但线上用户会发“怎么退”“发错了”“能改吗”这种残缺表达再加上客服助手直接被嵌入到输入框底部用户会连聊天记录一起发过来上下文比评测集会话长得多。模型面对真实场景第一回合还能答第二回合就开始偏离了。这次的教训是评测集除了测“理想输入”还必须有“真实分布输入”。我开始在评测集里加两个子集标准集和鲁棒集。标准集衡量系统在正常输入下的表现鲁棒集收集线上真实但“不好看”的输入包括残缺、口语、敏感边界等情况。哪怕鲁棒集效果难做到满分也要知道它有多少失败率能否被规则兜住。否则你上线之前看到的永远是理想化的海市蜃楼。5.2 排查思路速查表我整理了几个高频问题供你排查时快速定位方向现象优先排查项手段模型答非所问Prompt意图不清、示例覆盖不足打开追踪日志看Prompt上下文和检索结果同一个问题时好时坏上下文拼接顺序、检索排序波动、模型采样温度固定temperature检查检索结果排序变化引用资料来源错误检索召回不精确、来源字段丢失单独debug检索模块看top-k结果输出JSON格式偶尔坏模型后处理校验缺失加格式校验重试机制而不是依赖模型自觉成本突然上涨缓存命中率下降、输入token暴增看日志里token分配优化上下文拼接策略新知识没生效数据更新管道没跑、缓存没失效检查更新任务状态清语义缓存这里面有一个通用方法论做AI系统排查先分清是“模型问题”还是“工程问题”。模型问题看效果工程问题看数据流和日志。很多人一遇到效果不好就使劲改Prompt但实际是检索链路上数据根本没查出来改了也白改。5.3 我再补几个容易被忽略的小坑第一个坑是“同事互相污染评测集”。 Team members often share a dev set and tune prompts on it. But this leads to overfitting to the dev set. I now keep the real test set locked, and use a separate dev set for daily iterations. If a prompt works on dev but fails on test, theres a gap to study how the prompts are actually leaking into test. oops, I better phrase it properly: 团队成员共用一个评测集大家对着它调Prompt最后评测集被调“过拟合”了上线更差。我的做法是分开两个集开发集随便调测试集锁起来只有评估时才能碰。第二个坑是“外部知识更新不及时”。如果RAG依赖的数据源是定期更新的一定要在系统上设定一个“数据新鲜度”指标。知识库超过一天没更新就应该告警出来否则用户问“xxx新政策”回答还是旧政策信任感瞬间崩塌。第三个坑是“token浪费在无意义上下文上”。有时候为了提升效果会把一堆历史对话塞进上下文结果效果没提升钱倒花了不少。我习惯做上下文压缩只保留最近两轮对话和识别出的关键实体其余历史用摘要代替。这样既省成本又减少模型注意力分散。6. 说点个人经验AI工程的“从零开始”更多是思维转变做这一行半年时间足够把一个复现教程跑熟但真正称得上有“ai-engineering-from-scratch”能力的团队靠的是三点沉淀数据资产、评测机制、工程文化。模型迭代速度比你想象得快今天的最优解三个月后就过时但数据和评测这两个基础设施不会过时。它们越厚实你换新模型、换新方案时就越有底气。我个人最享受的时刻不是模型效果达到指标的那一瞬间而是把一个“玄学问题”通过日志和评测拆解成“确定性bug”的过程。AI工程和传统工程最大的差别就在这里传统工程的错误是稳定的、可复现的AI工程的错误是概率性的需要你用工程手段把它尽量转变成可观测、可控制、可修正的东西。最后分享一个实操习惯每次新项目启动我都先建立一个“坏样本库”文件夹命名为badcases按日期存放线上发现的所有失败案例。半年之后这个文件夹会比任何模型版本都值钱因为它是你评估下一个方案时最真实的试金石。踩过几次坑之后我现在做AI项目的顺序是数据体检、评测集先行、基线模型搭链路、建监控、再调优。这个顺序看起来慢实际上很少返工反过来先跑通再补课往往要付出好几倍的重构代价。如果你也准备从零开始做一个AI项目我劝你先定好尺子再动工——这是我在这个领域里吃过最多亏也最想提前告诉你的一条经验。