1. 从零搭建AI工程能力为什么大多数人卡在“会调包但不会落地”“ai-engineering-from-scratch”这个标题第一次看到的时候我就觉得它戳中了一个很真实的痛点。现在网上讲AI的教程铺天盖地但绝大多数要么停留在“调个API、跑个demo”的层面要么一上来就是高深的论文推导中间那块真正决定你能不能把AI用起来的工程能力反而没人系统讲。我自己带过几个刚入行的同学他们能背出Transformer的结构能用几行代码调用大模型接口但一旦让他们做一个能上线的AI功能——比如一个带缓存、带重试、带评测、带监控的问答服务——就完全不知道从哪下手。这就是“AI工程”和“AI算法”的分水岭。算法关注的是模型本身好不好工程关注的是这套东西能不能稳定、可控、可维护地跑在真实业务里。ai-engineering-from-scratch这个主题核心价值就在于把那些散落在各个项目里的工程实践从零开始串成一条完整的链路。它适合两类人一类是有一定编程基础、想转AI方向的开发者另一类是在做AI产品、但总觉得自己的系统“能跑但不敢上线”的工程师。这篇文章我会按照一个真实项目从零搭建的顺序把每个环节为什么这么做、怎么做、容易踩什么坑讲清楚你可以直接照着复现。我先把整条链路拆成几个关键模块数据与评测、模型接入与抽象、服务化与稳定性、可观测性与迭代。这几个词听起来像黑话但落到代码上都是很具体的东西。下面逐个展开每个部分我都会给出可操作的方案和我在实际项目里验证过的经验。2. 先想清楚“怎么算对”再动手写第一行代码2.1 没有评测集的AI项目等于闭眼开车很多人做AI项目的第一步是打开编辑器写调用逻辑这是最大的误区。我踩过最惨的一次坑是做一个文本分类功能模型换了一版线上准确率肉眼可见地掉了但我拿不出任何数据证明“掉了多少”“是哪类样本掉的”只能凭感觉回滚。从那以后我给自己定了个死规矩任何AI功能先有评测集再有代码。评测集不需要多复杂初期二三十条就够用但必须满足两个条件一是覆盖真实场景的主要类别二是每条都有明确的标准答案或评分标准。比如做一个客服意图识别你就把用户最常问的十类问题各找两三条人工标好正确意图。这个工作看起来笨但它是你后面所有迭代的基准线。没有它你调prompt、换模型、加后处理全都是玄学。具体操作上我习惯用一个JSONL文件存评测集每行一条字段包括输入、期望输出、备注。这样版本可控也方便脚本批量跑。下面是一个最小示例{input: 我的订单还没发货, expected: 物流查询, note: 高频} {input: 怎么申请退款, expected: 退款, note: 高频} {input: 你们家东西太贵了, expected: 价格咨询, note: 边界}2.2 评测指标要选“能指导决策”的而不是好看的选指标这件事新手最容易犯的错是追求“全面”把准确率、召回率、F1、BLEU、ROUGE全算一遍最后看着一堆数字不知道该怎么办。我的经验是指标要少但每个都要能直接回答一个决策问题。对于分类类任务我通常只看两个整体准确率和混淆矩阵。整体准确率告诉你“现在能不能用”混淆矩阵告诉你“错在哪、下一步改哪里”。对于生成类任务自动指标参考价值有限我更依赖“人工抽检规则校验”的组合。规则校验指的是用代码检查输出是否满足硬性要求比如是否包含敏感词、是否超过长度限制、是否是合法JSON。这些规则能挡住大部分低级错误成本极低。这里有个实操技巧把评测脚本和业务代码分开评测脚本只依赖一个“预测函数”的接口。这样你换模型、换prompt、换后处理逻辑评测脚本都不用改直接跑就能对比。我一般会写一个evaluate.py读评测集调预测函数输出准确率和错误明细。这个脚本会成为你迭代过程中用得最频繁的工具。提示评测集要定期更新。线上发现的新badcase人工确认后就应该补进评测集。否则你的评测集会越来越偏离真实分布最后变成自欺欺人。2.3 基线要“笨”到你能完全理解搭好评测之后第二步是建立一个最笨的基线。什么叫最笨就是不用任何模型纯规则或者纯关键词匹配。比如意图识别你可以先写一堆if-else包含“退款”就判退款包含“发货”就判物流。这个基线准确率可能只有50%但它有两个巨大价值一是让你确认评测流程是通的二是给你一个“模型至少要比这个强”的下限。我见过太多人跳过基线直接上大模型结果模型准确率70%他也不知道这70%是好是坏。有了笨基线你就知道模型带来的增量到底值不值那个成本。而且很多时候规则模型的混合方案比纯模型效果更好、成本更低。比如规则先兜住高频明确case模型处理长尾模糊case这种分层设计在工程上非常常见。3. 模型接入层别让“换个模型”变成重写整个项目3.1 抽象一个薄薄的模型接口收益远超你的想象AI工程里变化最快的就是模型。今天用这家明天可能因为成本、效果、合规换另一家。如果你的业务代码里到处散落着某家SDK的调用换模型就是灾难。我的做法是在业务代码和模型SDK之间加一层薄薄的抽象。这层抽象不需要设计得多复杂一个类、几个方法就够。核心是定义清楚“输入是什么、输出是什么”。比如我通常定义一个LLMClient接口方法叫chat(messages, **kwargs)返回一个统一的结构体包含文本内容、token用量、原始响应。业务代码只依赖这个接口具体用哪家模型在初始化的时候注入。class LLMClient: def chat(self, messages, temperature0.7, max_tokens1024): raise NotImplementedError class VendorAClient(LLMClient): def chat(self, messages, temperature0.7, max_tokens1024): # 调用A家SDK转换成统一返回结构 ...这样做的好处是换模型时你只需要写一个新的实现类业务代码一行不用改。评测脚本也不用改直接换注入的client就能对比效果。这个模式我在三个项目里用过每次换模型的时间从“一两天”压缩到“半小时”。3.2 重试、超时、降级这三件事必须在接入层解决模型调用是网络请求网络请求就会失败。失败不可怕可怕的是失败之后你的系统直接崩了。接入层必须处理三件事超时、重试、降级。超时设置要合理。大模型生成通常比较慢超时设太短会频繁失败设太长会拖垮整个请求链路。我的经验是普通对话场景设15到30秒批量离线任务可以设更长。重试要区分错误类型网络抖动可以重试参数错误重试也没用。我一般只对超时和5xx错误重试最多两次并且加指数退避避免把下游打垮。降级是最后一道防线。当模型完全不可用时系统应该返回一个兜底结果而不是报错。兜底可以是缓存的历史答案可以是一句“当前服务繁忙请稍后再试”也可以是规则引擎的结果。关键是这个降级逻辑要提前写好、测试过而不是等出事的时候临时加。注意重试一定要加幂等考虑。如果你的调用有副作用比如写数据库重试可能导致重复写入。纯推理调用一般没问题但涉及工具调用的场景要特别小心。3.3 成本控制从第一天就要做别等账单来了才后悔模型调用是要花钱的而且很容易失控。我见过一个项目因为没做任何限制某个循环里反复调用模型一晚上烧掉了几百块。成本控制不是上线后才考虑的事从接入层就要埋好。具体做法有几个一是记录每次调用的token用量按天、按功能维度汇总二是设置单次请求的max_tokens上限防止模型无限生成三是对高频重复的请求做缓存相同输入直接返回缓存结果。缓存这个事特别值很多业务场景下用户问的问题是高度重复的缓存命中率能到30%以上直接省掉三分之一的成本。我通常会在接入层加一个简单的内存缓存key用输入内容的哈希value存输出。对于时效性要求不高的场景这个缓存能一直用。对于时效性高的加个TTL就行。这个改动很小但收益非常直接。4. 把AI能力做成服务稳定性比聪明更重要4.1 服务化不是“包个HTTP接口”那么简单很多人觉得把模型调用包成一个HTTP接口就叫服务化了其实差得远。一个能上线的AI服务至少要处理好并发、限流、错误处理、日志这几件事。我见过一个内部工具单机跑得好好的一放到多人使用的环境请求一多就各种超时、内存暴涨。原因就是没有做并发控制。并发控制的核心是“别让请求无限堆积”。模型推理是重操作同时处理太多请求每个都会变慢最后全部超时。我的做法是在服务层加一个信号量或者队列限制同时处理的请求数。超出的请求要么排队要么直接返回“繁忙”。排队适合对延迟不敏感的场景直接拒绝适合实时交互场景。选哪种取决于你的业务。限流是另一个必须做的。按用户、按IP、按接口维度限制调用频率防止个别用户把资源占满。这个用现成的中间件就能做不需要自己写。关键是要有而不是等被打爆了才加。4.2 日志要记“能复现问题”的信息AI服务的日志和普通服务不太一样。普通服务出问题看堆栈基本能定位。AI服务出问题往往是“这个输入模型输出不对”你需要知道当时到底发了什么、模型返回了什么。所以日志里必须包含请求ID、输入内容、模型原始输出、耗时、token用量、使用的模型版本。这里有个隐私问题要注意。输入内容可能包含用户敏感信息直接打日志有合规风险。我的做法是对输入做脱敏或者哈希只保留必要的调试信息。如果确实需要保留原文用于排查就加密存储并设置访问权限和过期时间。这个平衡点每个团队不一样但一定要在项目初期就想清楚别等出了事再补。日志的另一个作用是做数据分析。你可以从日志里统计哪些问题问得最多、哪些回答被用户点了“不满意”、平均响应时间是多少。这些数据是后续迭代的燃料。我习惯每周看一次日志汇总经常能发现一些意想不到的使用模式。4.3 灰度发布和回滚给迭代上保险AI功能的效果很难在发布前完全验证所以灰度发布特别重要。新版本先放一小部分流量观察核心指标准确率、延迟、错误率、用户反馈没有明显下降再逐步放大。一旦发现问题能立刻回滚到旧版本。实现灰度最简单的方式是在服务入口根据用户ID或请求ID做分流比如哈希后取模10%走新版本90%走旧版本。配置要能动态调整不要写死在代码里。回滚同理保留旧版本的模型和prompt随时能切回去。我踩过的一个坑是灰度期间只看了技术指标没看业务指标。结果新版本延迟没变、错误率没变但用户满意度掉了因为回答风格变了。所以灰度观察期一定要把业务侧的反馈也纳入进来哪怕只是人工抽检几十条。5. 可观测性与持续迭代让系统越用越聪明5.1 监控面板要盯“四个黄金指标”AI服务的监控我建议至少盯四个指标请求量、错误率、延迟分布、token消耗。请求量告诉你系统负载错误率告诉你健康度延迟分布不只是平均值要看P95、P99告诉你用户体验token消耗告诉你成本趋势。这四个指标放在一个面板上基本能覆盖大部分异常情况。延迟这个指标特别要强调看分布。平均值很容易骗人比如平均200毫秒但P99是10秒意味着有1%的用户体验极差。AI服务因为模型推理时间波动大P99往往比平均值高好几倍。我一般会设一个P95的告警阈值超过就排查。监控工具用现成的就行不需要自己造。关键是把指标埋点做对每个请求都要打点维度要包含模型版本、接口名、是否命中缓存等。这样出问题的时候能快速定位是哪个环节的问题。5.2 用户反馈是最便宜的标注数据用户点“不满意”或者手动修改了AI的输出这些都是极其宝贵的信号。我会在服务里加一个反馈接口用户点踩的时候把请求ID和反馈类型记下来。定期把这些badcase捞出来人工确认后补进评测集然后针对性地优化prompt或者补充规则。这个闭环跑起来之后系统会越用越准。我做过一个项目上线第一个月准确率72%通过持续收集反馈、每周迭代一次三个月后到了89%。这个提升不是靠换更贵的模型而是靠对真实badcase的针对性优化。很多时候模型没变只是prompt里加了几条针对性约束效果就上去了。5.3 迭代要有节奏别天天改AI系统很容易陷入“天天调prompt”的状态今天改一版明天改一版最后没人知道哪版好。我的建议是固定迭代节奏比如每周一次。平时收集问题和想法到迭代日统一评估、统一发布。这样每次改动都有明确的对比数据也能避免频繁发布带来的不稳定。每次迭代的流程我固定为收集badcase、分析根因、提出改动方案、在评测集上验证、灰度发布、观察指标、全量或回滚。这个流程看起来重但跑顺了之后每次也就半天时间。比起天天瞎调这种有节奏的迭代效率高得多而且每一步都有据可查。6. 几个我踩过之后才明白的工程细节6.1 prompt不是越长越好结构比字数重要刚开始做的时候我总觉得prompt写得越详细越好把各种要求都堆上去。结果发现模型经常顾此失彼强调了A就忘了B。后来我改成结构化写法角色、任务、约束、示例分块写清楚每块只讲一件事。这样模型理解起来更稳我也更容易定位是哪块出了问题。另一个经验是约束要具体、可验证。比如“回答要友好”这种就很虚模型不知道怎么做。改成“回答开头用‘您好’结尾用‘请问还有其他问题吗’”模型就能稳定执行。能写成规则的就别写成形容词。6.2 缓存key的设计决定了缓存命中率缓存看起来简单但key的设计很讲究。直接用原始输入做key稍微改一个字就命中不了。我的做法是先对输入做归一化去空格、转小写、去掉无意义的标点然后再哈希。对于意图识别这类任务还可以先做一次轻量的规则匹配把等价的表达映射到同一个key。另外要注意缓存的失效策略。有些场景下答案是会变的比如查询库存这种就不能缓存太久。我一般会根据业务给缓存设TTL时效性强的设几分钟时效性弱的设几小时甚至更长。这个参数没有标准答案要根据实际业务试出来。6.3 别忽视“非AI”的部分很多人做AI项目把所有精力都放在模型上忽略了周边的工程。但实际上一个AI功能里模型可能只占20%的工作量剩下80%是数据清洗、格式转换、错误处理、接口对接这些“脏活”。这些活不出彩但决定了系统能不能用。我的建议是把AI部分当成一个普通的函数输入输出定义清楚然后按普通工程的标准去要求它。该有的参数校验要有该有的异常处理要有该有的单元测试要有。别因为它是AI就降低工程标准。我见过太多AI项目模型效果不错但因为周边工程太糙最后没法上线。7. 从零到一之后下一步往哪走把上面这套跑通之后你手里就有了一个能上线、能迭代、能观测的AI系统。这时候可以开始考虑进阶的东西了。比如引入更细粒度的评测按业务维度拆分指标比如做A/B测试用数据驱动prompt和模型的选型比如把重复的工程逻辑抽成内部库让新项目能快速复用。我个人在实际操作中的体会是AI工程最难的不是某个技术点而是“把不确定性管起来”。模型本身是不确定的你要用评测、监控、灰度、回滚这些工程手段把不确定性控制在可接受的范围内。这套思路一旦建立起来换什么模型、做什么场景你都有底气。最后分享一个小技巧把你项目里所有的“魔法数字”和“临时逻辑”都记在一个文档里标注清楚为什么这么设、什么时候该重新评估。AI项目变化快今天合理的参数明天可能就不合理了。有个地方能查比全靠记忆靠谱得多。这个习惯我坚持了两年帮我省了很多次“这个参数当初为什么设成这样”的纠结。