1. 从零搭建AI工程能力为什么“会调包”远远不够很多人第一次接触AI工程是从一行pip install或者一个现成的API调用开始的。输入一段文字模型返回一段结果跑通了就觉得“AI工程不过如此”。但真正进入生产环境之后问题会一个接一个冒出来模型响应忽快忽慢、并发一上来就崩、成本失控、输出格式不稳定、换个模型整条链路都要重写。这些问题的根源往往不是模型本身不够强而是工程能力没有跟上。ai-engineering-from-scratch这个标题核心讲的不是“如何调用某个大模型API”而是从零开始构建一套属于自己的AI工程体系。它适合那些已经会用模型、但想把AI能力真正落地到产品里的开发者也适合想从传统后端、前端转向AI工程方向的工程师。关键词“from scratch”意味着不依赖某个高度封装的平台而是自己把数据流、推理服务、缓存、评测、监控这些环节一层层搭起来。我见过太多团队在Demo阶段用Notebook跑得飞起一到线上就手忙脚乱。原因很简单Demo关心的是“能不能出结果”工程关心的是“在什么条件下、以什么成本、多稳定地出结果”。这两者之间隔着一整套工程实践。这篇文章会围绕这套实践展开把我在实际项目中踩过的坑、总结出的结构、以及那些文档里不会写的细节尽量讲透。2. 先想清楚AI工程到底在工程什么2.1 模型只是整条链路里的一个环节刚入行的时候我也以为AI工程就是“选模型、调参数”。后来才发现模型在整条链路里的占比可能不到三成。一个典型的AI应用链路大致是这样的输入处理用户输入可能是文本、图片、文件需要做清洗、分块、格式转换。上下文组装把用户输入和系统提示、历史对话、检索到的知识拼成模型能吃的prompt。推理调用请求模型服务处理超时、重试、限流。输出解析模型返回的可能是自然语言也可能是JSON需要校验和兜底。后处理与存储结果要落库、要缓存、要触发下游业务。观测与评测记录耗时、token消耗、成功率定期跑评测集。你会发现真正跟“模型”强相关的只有第三步。其余五步全是传统软件工程问题只不过因为模型的不确定性这些环节需要额外的容错设计。这就是为什么很多后端工程师转AI工程反而有优势——他们本来就熟悉链路治理。2.2 不确定性是AI工程和传统工程最大的分水岭传统接口的输入输出是确定的传userId1返回用户信息格式固定。AI接口不是。同样的输入模型可能给出不同措辞温度调高一点输出风格就变了模型版本一升级原本能解析的JSON可能就多了几个字导致解析失败。这种不确定性带来的直接后果是你不能假设任何一次调用都会成功也不能假设成功的那次结果格式一定正确。所以AI工程的第一原则是“防御性编程”。每一个环节都要有校验、有兜底、有降级方案。比如输出解析失败时是重试、是返回默认值、还是走规则兜底这些都要提前设计好而不是等线上报错再补。2.3 成本意识要贯穿始终AI应用的成本结构和传统应用完全不同。传统应用主要成本是服务器和带宽相对固定。AI应用的成本跟调用量、输入输出长度、模型单价强相关而且波动很大。一个没做长度控制的prompt可能因为用户输入了一篇长文token消耗直接翻几十倍。我在项目里养成的习惯是任何一次模型调用都要记录token消耗并且设置单次调用的上限。比如限制输入不超过4000 token输出不超过1000 token超出就截断或拒绝。同时要有全局的预算监控当天消耗超过阈值就告警甚至自动降级到更便宜的模型。这些机制在Demo阶段没人会做但上线之后能救命。3. 从零搭建推理服务选型与骨架3.1 自建推理还是调用托管服务这是每个团队都会面临的第一个决策。我的经验是分阶段看阶段推荐方案理由验证想法托管API零运维快速验证按量付费小规模上线托管API 缓存成本可控稳定性有保障规模化且数据敏感自建推理数据不出域长期成本更低极致延迟要求自建 量化可针对硬件优化自建推理的门槛在于你需要有GPU资源、要会部署推理框架、要处理显存管理、要应对并发。如果团队没有这些能力强行自建只会拖慢进度。但如果你确实需要自建下面这套骨架可以参考。3.2 推理服务的核心模块划分一个可维护的推理服务我通常会拆成这几个模块接入层负责鉴权、限流、请求路由。这一层不碰模型只做流量治理。调度层管理推理队列决定请求的优先级和批处理策略。推理层真正加载模型、执行推理。这一层要处理显存、并发、超时。缓存层对相同或相似的请求做结果缓存大幅降低成本。观测层记录每次请求的耗时、token、成功率、错误类型。这样拆的好处是每一层可以独立扩展和替换。比如接入层可以用Nginx或网关调度层可以用消息队列推理层可以换不同的推理框架缓存层可以换Redis或本地内存。层与层之间通过明确的接口通信不会因为换了一个模型就把整条链路重写。3.3 批处理是提升吞吐的关键单条推理的GPU利用率其实很低因为大部分时间花在数据搬运和kernel启动上。批处理能把多条请求合并成一次前向计算吞吐能提升几倍甚至十几倍。但批处理有个矛盾批次越大吞吐越高但单条请求的延迟也越高因为要等批次凑满。我的做法是设置一个最大等待时间和最大批次大小两者谁先到就触发推理。比如最多等50毫秒或者凑够8条就发。这样在低峰期延迟可控高峰期吞吐也能上去。这个参数需要根据实际流量压测来调没有万能值。注意批处理对显存的要求会随批次线性增长一定要留足余量否则高峰期容易OOM。4. 上下文组装与提示词工程化4.1 提示词不应该散落在代码里刚开始写AI应用时很多人会把提示词直接写在代码字符串里。改一个词就要重新部署而且多个地方用到的提示词容易不一致。我的做法是把提示词当成配置来管理单独放在配置文件或数据库里代码通过key来引用。这样产品经理也能参与调整不需要每次改提示词都找开发。更进一步可以给提示词做版本管理。每次修改都记录版本号线上出问题时能快速回滚到上一个版本。这个习惯在提示词频繁迭代的阶段特别有用。4.2 上下文窗口的分配策略模型的上下文窗口是有限的而用户输入、历史对话、检索知识、系统提示都要占空间。如果不做分配很容易出现“历史对话太长把知识挤掉”或者“知识太多把输出空间挤没”的情况。我通常按这个比例分配系统提示占10%历史对话占30%检索知识占40%用户当前输入占10%留10%给输出。当然这不是固定的要根据场景调整。比如客服场景历史对话更重要知识问答场景检索知识更重要。关键是要有明确的分配逻辑而不是让某一部分无限膨胀。4.3 检索增强里的分块与召回如果应用需要基于私有知识回答检索增强是绕不开的。这里有两个关键点分块策略和召回策略。分块不是越细越好。块太小语义不完整召回后模型看不懂块太大噪声多而且占用上下文。我的经验是按语义边界分块比如按段落或按标题层级每块控制在200到500字。同时块之间保留一定的重叠避免边界处的信息丢失。召回方面单纯用向量相似度往往不够。我会结合关键词召回和向量召回两路结果合并后再做重排。重排可以用一个小的交叉编码模型把最相关的几条排到前面。这样能明显提升最终答案的准确率。5. 输出解析与稳定性保障5.1 让模型输出结构化数据如果下游需要程序处理最好让模型直接输出JSON。但模型有时候会“自作主张”加一些解释文字导致JSON解析失败。我的做法是在提示词里明确要求“只输出JSON不要任何其他文字”并且在解析时做容错先尝试直接解析失败就用正则提取第一个完整的JSON对象再失败就走兜底逻辑。还有一种更稳的方式是使用模型提供的结构化输出能力如果支持的话在调用时指定schema模型会保证输出符合格式。但即使这样也要做校验因为schema约束的是结构不保证内容正确。5.2 重试与降级的边界不是所有失败都值得重试。我的判断标准是超时可以重试但要有次数上限比如最多2次。格式错误可以重试一次并在重试时加强格式约束。内容违规不重试直接返回兜底话术。服务不可用可以重试但要配合退避策略避免雪崩。重试一定要有上限和退避否则一个慢请求可能拖垮整个服务。降级方案也要提前准备好比如切换到更小的模型或者返回缓存结果或者走规则引擎。5.3 缓存的设计要点AI应用的缓存和传统缓存不太一样。传统缓存key是精确的AI场景下相似的问题可能措辞不同但答案可以复用。所以除了精确缓存还可以做语义缓存把请求向量化在缓存里找相似度超过阈值的记录直接返回。但语义缓存有风险相似度高不代表答案可以通用。比如“北京天气”和“上海天气”向量可能很近但答案完全不同。所以语义缓存要设置较高的阈值并且对关键实体做校验。我的做法是精确缓存用于高频重复问题语义缓存只用于那些答案与具体实体无关的场景比如“怎么退货”这类通用问题。6. 评测与观测让效果可量化6.1 没有评测就没有优化AI应用最怕的就是“感觉效果还行”。感觉是不可靠的必须有一套评测集来量化。评测集不需要很大几十到几百条就够但一定要覆盖核心场景和边界情况。每次修改提示词、换模型、调整参数都跑一遍评测集看指标是涨是跌。评测指标根据任务不同而不同。分类任务看准确率和召回率生成任务可以用人工评分或者用另一个模型来打分。关键是要有基线知道当前版本比上一版好还是差。6.2 线上观测要记录什么线上观测的数据是优化的依据。我通常会记录这些字段请求ID、用户ID、时间戳输入长度、输出长度、token消耗模型名称、版本、参数首token延迟、总延迟是否命中缓存、是否重试、是否降级输出解析是否成功用户反馈如果有这些数据积累起来能回答很多问题哪个模型性价比最高、哪个时段流量最大、哪类请求最容易失败、缓存命中率是多少。没有这些数据优化就是盲人摸象。6.3 告警要设在对的地方告警不是越多越好。设太多告警最后大家都会麻木。我的原则是只对影响用户体验和成本的指标设告警错误率超过5%P99延迟超过阈值当日token消耗超过预算的80%缓存命中率骤降告警触发后要有明确的处理流程而不是只发个通知就完了。比如错误率超标先看是不是某个模型服务挂了如果是就切到备用模型如果是代码bug就回滚。7. 踩坑实录那些让我熬夜的瞬间7.1 上下文超长导致的静默截断有一次线上反馈说模型“答非所问”。排查后发现用户输入特别长加上历史对话和检索知识总长度超过了模型窗口。而我们的代码在拼接时没有做长度检查直接把超出的部分截断了导致系统提示被截掉一半模型失去了行为约束。这个坑的教训是拼接上下文时一定要做长度校验并且优先保留系统提示和当前输入。历史对话和检索知识可以按优先级裁剪。后来我在拼接函数里加了一个断言超过窗口就抛异常而不是静默截断。7.2 并发下的显存泄漏自建推理服务时遇到过一个诡异的问题服务跑几个小时之后显存就满了然后OOM崩溃。查了很久才发现是某些异常请求导致推理过程中的中间张量没有被释放。因为Python的垃圾回收不是实时的在高并发下这些张量越积越多。解决办法是在推理函数里用try-finally确保资源释放并且定期主动触发垃圾回收。另外给服务加一个健康检查显存超过阈值就自动重启。虽然粗暴但有效。7.3 模型升级带来的格式漂移有一次托管服务商悄悄升级了模型版本原本稳定输出的JSON突然多了几个字导致解析失败率飙升。因为我们的解析逻辑只处理了标准情况没有容错。从那以后我养成了两个习惯一是锁定模型版本不用latest这种浮动标签二是解析逻辑必须有容错和兜底不能假设模型永远听话。即使锁定版本也要定期回归测试因为服务商可能会下线旧版本。7.4 缓存key设计不当导致的串答案早期做缓存时我用用户输入直接做key。结果发现两个不同用户问了同样的问题第二个用户拿到了第一个用户的个性化答案因为答案里包含了第一个用户的信息。这是典型的缓存污染。修正方法是缓存key要包含所有影响输出的因素比如用户ID如果答案个性化、模型版本、提示词版本。对于个性化场景宁可不缓存也不要串答案。8. 从能跑到好用一些工程习惯8.1 配置与代码分离模型名称、温度、最大token、超时时间这些参数全部放到配置文件或环境变量里。这样换模型、调参数不需要改代码也方便不同环境用不同配置。我见过把API key硬编码在代码里然后提交到仓库的这是大忌。8.2 日志要能还原一次请求的全貌出问题时最怕的就是日志不全只能靠猜。我的做法是给每个请求分配一个唯一ID从接入到推理到返回所有环节的日志都带上这个ID。这样排查时用ID一搜整条链路清清楚楚。日志里要包含输入输出摘要注意脱敏、耗时、token、错误信息。8.3 灰度发布与回滚AI应用的变更影响面很大提示词改几个字可能效果就天差地别。所以任何变更都要能灰度先放量1%观察指标没问题再逐步扩大。同时要能一键回滚。这要求提示词、模型配置、代码都要有版本管理回滚时整体回滚而不是只回滚一部分导致状态不一致。8.4 定期做故障演练线上环境什么都有可能发生模型服务挂了、网络抖动、缓存失效、流量突增。与其等真出事时手忙脚乱不如定期做演练。比如手动把主模型禁用看降级逻辑是否生效模拟缓存全失效看数据库能不能扛住。演练中暴露的问题比线上事故代价小得多。9. 关于这套东西后续怎么扩展这套从零搭建的AI工程骨架跑通之后可以往几个方向扩展。一是多模型路由根据请求的复杂度自动选择不同大小的模型简单问题用小的复杂问题用大的进一步降本。二是在线学习把用户反馈收集起来定期微调模型或优化提示词。三是多模态把图片、音频的处理链路接进来复用现有的调度和观测体系。我自己在实际操作中的体会是AI工程最难的不是某个技术点而是把不确定性管起来。模型会变、流量会变、需求会变工程的价值就是让这些变化不至于把系统冲垮。把缓存、重试、降级、评测、观测这几件事做扎实比追新模型、新框架重要得多。