1. 一切的起点：不要先选模型，先定义问题

做AI工程跟我最早做传统后台开发的感受完全不一样。传统开发是“需求清楚、边界清楚、逻辑可以穷举”，AI工程是“目标清楚、路径模糊、结果只有概率可预期”。很多刚入行的朋友挂在嘴边的话是“我要做一个智能客服”“我想接入大模型”，但真问下去，往往说不清楚这个系统要解决什么业务指标、失败成本是多少、用户最不能接受什么错误。如果你能记住一件事，我希望是：AI工程不是“用模型实现功能”，而是“在不确定性中构建可控系统”。

项目标题起名“ai-engineering-from-scratch”，本身就很诚实——从零开始，意味着你先得把地基夯实。这个地基不是模型，而是需求拆解、数据、评测、成本和系统容错。我见过太多团队，约等于“拿着锤子找钉子”，模型选得很大，Prompt写得天花乱坠，最后在评测集上一测，连自己的验收标准都拿不出来。所以第一步，我建议你先回答四个问题，再碰任何代码：

1. 输入和输出到底是什么？输入是纯文本还是有结构化字段？输出要不要限制格式？
2. 这个功能的“好”怎么定义？准确率？用户满意度？还是单位成本下降？
3. 错了会怎样？错了能重试吗？需要人工兜底吗？
4. 现在有人工方案吗？人工方案的成本和瓶颈是什么？

如果你发现第四个问题答不上来，大概率这个AI项目还没到启动时机。工程化的本质是把不可控的模型输出，嵌入到可控的业务流里面去，而不是让模型直接面向用户裸奔。

1.1 你以为的“AI工程”和实际的差距

很多教程把AI工程包装成“调接口+写Prompt”的组合，这是最大的误导。真正进入落地阶段，你会发现工作量的分布大概是这样的：

• 数据获取、清洗、摸底、标注：约40%的工作量
• 评测集构建、评测流程、回归机制：约20%的工作量
• 模型选型、微调/提示词调优、RAG链路：约20%的工作量
• 服务化、监控、告警、成本治理、人机协同：约20%的工作量

这组数字是我在实际项目里慢慢修正出来的，不一定绝对准确，但方向是靠谱的。刚入行的人往往把80%精力放在“改Prompt”上，忽略了数据和评测，结果就是模型在样例上表现惊艳，一换场景就崩，而且你不知道它为什么崩。因为你没有评测集，也没有失败样本归因机制。

“从零开始”的另一个含义，是你必须自己搭建这套反馈闭环。模型API所有人都能调用，但数据怎么沉淀、怎么标注、怎么追踪错误案例，这些才是每个团队的私有资产。有人问过我，是不是可以用开源数据集起家？可以，但要注意分布偏移问题：公开数据集描述的是“一般世界”，你的业务场景是“特定世界”，两者之间的gap，恰恰需要你自己去用真实业务样本补齐。

1.2 从需求到可行性：一个需求如何变成工程条目

我习惯用所谓“需求翻译法”，把业务语言翻译成模型任务语言。举个例子，业务方说“我们要做一个能回答产品问题的智能助手”，这句听起来没问题，但没法直接做工程。你得把它翻译成：

• 任务类型：这是开放域问答还是检索增强问答？大概率是后者。
• 知识来源：产品知识分散在哪些文档里？文档如何更新？旧的怎么办？
• 用户诉求：用户问“退换货流程”，是要步骤列表，还是要一句结论？需要附带出处吗？
• 边界限制：哪些问题绝不能答？比如医疗建议、法律责任、价格承诺。
• 失败兜底：答不上来时，要不要引导转人工？

翻译完之后，你会突然发现，你需要的不是“大模型”，而是一套知识管理流程加上一个合适的答案生成模块。工程化的起点，是让需求细化到能用工程手段去验证的程度。

2. 数据与评测：决定成败的两块隐形基石

很多人做AI项目，上来就调API，但真正决定项目天花板的是数据和评测。模型能力再强，喂进去的数据是脏的，评测标准是模糊的，你等于开着跑车在没有路标的高速公路上狂奔，翻车只是时间问题。本章聊一下我怎么把这两块地基打牢。

2.1 数据治理：清洗、标注、版本化的一条龙流程

放在传统的后端工程里，数据往往是结构化、可校验的。AI工程里的数据通常是文档、对话记录、客服话术、日志，这些数据噪点极大。我处理过一份客服对话记录，里面包含大量口语缩写、错别字、emoji、甚至不同客服人员的私人备注。直接喂给模型，模型会把备注当成正式话术学进去。

我的建议是做个“数据体检”三步走：

1. 统计摸底：文本长度分布、词频、重复率、特殊字符占比。这些指标能快速暴露出数据质量问题的明显特征，比如某类数据只集中在某几个来源渠道，或者某些样本长度严重偏离均值。
2. 清洗策略：规则去重、敏感信息脱敏、语言过滤、格式归一化。清洗不能过度，保留口语化表达有助于模型适应真实场景，但要去掉与业务无关的聊天杂质，比如删掉员工之间的无关闲聊。
3. 人工抽样复核：随机抽100条样本，逐条看完，建立“错误类型清单”。这一步没法自动化，但非常重要。你会发现有相当一部分样本根本不属于这个任务，比如标着“咨询”的样本里面混着投诉和催单。

数据版本化，说白了就是让你每次实验都能追溯到“用了哪一份数据”。我见过有团队改数据改到一半，发现模型效果变好是因为手误混入了测试集样本，白白浪费了几天时间。现在即使不做重型数据平台，我也会保留带日期和hash的数据目录，比如data/2025-01-12_v3_hash6789，让每次实验可复现。

2.2 评测集设计：先有尺子，再谈调优

评测集是AI工程里最容易被低估的东西。没有评测集，你所谓的“效果挺好的”，跟掷骰子没什么区别。我的经验是先定义评测维度，再采集样本，最后确定打分方式。

常见的评测维度可以分成三类：

• 正确性：答案是否准确、有没有幻觉、是否与知识源一致。这个维度最核心，也最难自动判断。
• 完整性：该覆盖的几个子点是否都覆盖到了。比如问退换货流程，用户既要流程步骤，也要时间限制、费用说明，漏掉任意一个都算不完整。
• 安全性/鲁棒性：遇到敏感问题、边界问题、乱输入时，是否给出合规且不崩坏的响应。

评测样本要从真实用户请求里采样，而不是自己编。可以在上线前先做“影子模式”，把线上请求复制一份打到模型上，不加响应只记录，攒一段时间后再抽样本。样本量不需要多，几百条高质量、带上文、带标准答案的评测样本，已经能支撑绝大部分调优工作。

打分方式，我推荐人评和机评结合。机器打分用LLM-as-a-judge，速度快，但要注意评分模型本身会有偏见；人工抽评则用来校准机器评分，比如每周抽20条，确认机器打分的逻辑没有跑偏。评测集也要持续追加，把线上出现的新错误类型沉淀成评测样本，这样才能形成“发现错误—修复—回归验证”的闭环。

3. 模型选型与训练/微调路径：别掉进“大模型万能”的坑

选模型这事，特别容易上头。大模型一出新版本，就有人盘算要不要全量迁移；开源模型一开放，就有人想着本地化部署。但工程化的原则是“够用就好，扩展可控”。先搞清楚模型在系统里承担的角色，再根据效果和成本去挑。我从实际经验出发，聊聊怎么做一个理性的模型选型和调优思路。

3.1 基座模型选择的核心考量

首先我们要区分“基座模型”和“最终应用模型”。基座模型是一个泛化的、不做业务适配的底模，能力很强但缺乏专业领域和业务规则的知识。最终落地的时候，通常需要围绕基座模型做提示词、检索、微调或后处理。

选基座模型的核心考量有几个维度：

1. 语言能力：中英兼顾能力、代码理解、长上下文窗口。如果业务涉及大量长文档，上下文窗口和检索能力比单次生成质量还重要。
2. 生态成熟度：是不是容易接入现有框架？有没有完整的API和社区工具链？这决定了你的开发效率。
3. 部署形态：闭源API还是开源权重？闭源API省事，但受网络、成本和数据出域约束；开源权重可以本地化部署，但要自己搞定推理优化和运维。
4. 成本控制：不仅是单次调用成本，还要算上缓存、评测、重试带来的隐形成本。量大以后，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用量”。我在项目里维护一套自己的观测清单，大致分四层：

1. 系统层：响应时间、错误率、并发量、排队长度。这一层和传统监控一致。
2. 成本层：模型调用次数、输入token数、输出token数、缓存命中率。这一层直接决定你月底的账单。
3. 质量层：人工抽评分数、机器评分趋势、用户反馈率（比如点了“没帮助”的比例）。
4. 追踪层：每一条请求的完整链路，包括提问、检索结果、拼接上下文、模型原始输出、后处理结果。这个链路是排查问题的重要依据，没有完整日志，出问题只能靠猜。

追踪层最容易被忽略，但线上问题来了，你能回复业务方的是“我们查了请求日志，发现用户输入‘xxx’，检索返回为空，因此模型给了兜底回复”，而不是“应该是模型抽风了”。前者叫工程，后者叫玄学。

缓存在这层也有奇效。AI服务通常可以用“语义缓存”，把相同或相近的请求直接复用结果，特别是FAQ场景，命中率很高，能大幅节约成本。但缓存要注意时效性，如果知识库更新，涉及更新的问题缓存必须失效。

5. 常见问题与排查技巧实录

我把自己在真实项目里遇到的坑，挑几个典型的记录下来，希望帮你跳过几个明显的深坑。

5.1 一个典型的失败案例：评测完成后效果依然不理想

有一次我给一个客服助手项目做上线前的评测，评测集准确率到了92%，业务方也点头了，结果小流量上线后，用户满意度反而下降了。当时第一反应是“评测集有问题”，复查发现：评测集里的样本都是正式、完整的用户提问，但线上用户会发“怎么退”“发错了”“能改吗”这种残缺表达；再加上客服助手直接被嵌入到输入框底部，用户会连聊天记录一起发过来，上下文比评测集会话长得多。模型面对真实场景，第一回合还能答，第二回合就开始偏离了。

这次的教训是：评测集除了测“理想输入”，还必须有“真实分布输入”。我开始在评测集里加两个子集：标准集和鲁棒集。标准集衡量系统在正常输入下的表现；鲁棒集收集线上真实但“不好看”的输入，包括残缺、口语、敏感边界等情况。哪怕鲁棒集效果难做到满分，也要知道它有多少失败率，能否被规则兜住。否则，你上线之前看到的，永远是理想化的海市蜃楼。

5.2 排查思路速查表

我整理了几个高频问题，供你排查时快速定位方向：

这里面有一个通用方法论：做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, there's 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项目，我劝你先定好尺子再动工——这是我在这个领域里吃过最多亏，也最想提前告诉你的一条经验。