1. 从零搭建AI工程能力为什么“会用模型”和“会做工程”是两回事很多人第一次接触AI是从调用一个API或者跑通一个Notebook开始的。输入一段提示词模型返回一段看起来还不错的文本于是产生一种“我已经掌握AI了”的错觉。但真正把AI能力交付给成百上千人使用的时候问题会集中爆发响应时快时慢、成本忽高忽低、输出质量不稳定、线上出问题无法复现、模型换了效果就崩。这些问题的根源不在于模型本身而在于AI工程这套支撑体系没有建立起来。ai-engineering-from-scratch这个标题核心讲的不是“从零训练一个大模型”而是从零构建一套能支撑AI应用稳定运行的工程体系。它面向的是那些已经能跑通Demo、但想把AI能力真正做成产品的开发者、后端工程师、技术负责人以及想从传统软件工程转向AI方向的从业者。关键词里的“from scratch”强调的是不依赖现成的重型平台而是理解每一层的职责用最朴素的组件把整条链路搭起来。我见过太多团队在AI项目上栽跟头不是因为模型选错了而是因为工程层缺失。一个典型的场景某团队用大模型做客服问答Demo阶段效果惊艳上线后用户量一上来接口超时率飙升账单一个月翻了三倍而且用户投诉回答“答非所问”时开发完全不知道当时模型收到了什么上下文。这就是典型的“有模型、无工程”。AI工程要解决的正是可观测、可控制、可复现、可扩展这四个问题。这篇文章我会按照一个真实的搭建顺序来展开先把整体分层想清楚再逐层落地包括请求链路、上下文管理、输出约束、成本控制、评测体系和线上排障。每一部分我都会说明“为什么这么设计”而不只是“怎么做”。如果你正打算把手里那个跑得还行的Demo推向真实用户这篇内容可以直接当作施工图来参考。2. 先把分层想清楚AI工程到底由哪些层组成2.1 从一次请求的完整生命周期说起要理解AI工程的分层最好的办法是跟踪一次用户请求从进入到返回的全过程。用户在前端输入一句话这句话先经过接入层做鉴权、限流、参数校验然后进入编排层这里决定用哪个模型、带哪些上下文、走什么工具调用接着是模型调用层负责和模型服务通信处理重试、超时、降级模型返回后进入后处理层做格式校验、敏感内容过滤、结构化解析最后结果写回同时把这次请求的关键信息落到观测层供后续分析和排障。这个链路看起来和传统后端请求没什么区别但AI场景有几个特殊之处。第一模型调用是高延迟且不稳定的一次调用可能几百毫秒也可能几十秒还可能直接失败所以重试和超时策略必须比普通接口更精细。第二模型输出是非确定性的同样的输入两次结果可能不同这让“复现问题”变得困难必须把每次请求的完整输入输出都记录下来。第三模型调用是按量计费的每一次调用都是真金白银成本控制必须内建到链路里而不是事后看账单。所以AI工程的分层不是照搬传统架构而是围绕这三个特殊性重新组织的。我通常把它归纳成五层接入与治理层、编排与上下文层、模型接入层、输出处理层、观测与评测层。下面逐层拆解每一层要做什么、容易踩什么坑。2.2 各层的职责边界与常见误区接入与治理层负责的是“谁能用、用多少、怎么防滥用”。这一层要做鉴权、配额管理、限流、请求去重。很多人会忽略请求去重结果同一个用户疯狂点击提交按钮后端就发出十几次模型调用成本直接翻十倍。一个简单的做法是对“用户ID输入内容哈希”做短时间窗口的去重几行代码就能省下大量无效调用。编排与上下文层是AI工程里最核心也最容易写乱的一层。它决定了一次请求要带哪些历史消息、要不要检索外部知识、要不要调用工具、用哪个模型。这一层的常见误区是把所有逻辑塞进一个巨大的函数里几百行if-else改一处就崩一片。正确的做法是把“上下文组装”“模型选择”“工具调度”拆成独立的策略模块每个模块可以单独测试和替换。模型接入层负责和具体的模型服务打交道。这里的关键是抽象不要让业务代码直接依赖某个具体模型的SDK而是定义一层统一的接口把模型名称、参数、超时、重试都封装在内部。这样换模型时业务代码不用动。我见过一个项目因为把某模型的调用方式硬编码在几十个地方后来想换模型改了两周还没改干净。输出处理层负责把模型的“自然语言”变成程序能用的“结构化数据”。模型很擅长生成看起来对但格式不对的内容比如你要求返回JSON它可能给你包一层json或者在JSON后面加一句解释。这一层要做格式提取、校验、失败重试。同时还要做内容安全过滤把明显不当的输出拦下来。观测与评测层是最容易被跳过、但长期价值最高的一层。它记录每次请求的输入、输出、耗时、token消耗、模型版本并支持按条件检索。没有这一层线上出问题你只能靠猜。评测则是在发版前用一批固定用例跑一遍看新版本的效果有没有退化。这两件事在Demo阶段可以不做但一旦有真实用户就必须补上。3. 请求链路与上下文管理把“记忆”和“知识”分开处理3.1 上下文窗口不是越大越好很多人一上来就想把尽可能多的内容塞进上下文觉得信息越多模型答得越准。实际恰恰相反。上下文越长模型越容易“迷失”在中间部分而且token成本线性上升延迟也明显增加。我做过一个对比测试同样一个问题带3条相关历史消息和带20条历史消息准确率反而前者更高因为后者引入了大量无关信息干扰判断。正确的做法是按需组装上下文而不是无脑堆砌。具体来说把上下文分成三类系统指令角色设定、输出格式要求、对话历史最近几轮交互、外部知识检索到的文档片段。系统指令永远保留对话历史按相关性裁剪外部知识按检索得分排序后取Top-K。每一类都有独立的预算比如系统指令不超过500 token历史不超过1000 token知识不超过2000 token加起来控制在模型窗口的合理比例内。裁剪历史消息时不要简单地“保留最近N条”。更合理的做法是保留最近几轮完整对话同时对更早的消息做摘要压缩。摘要可以用一个小模型来生成成本很低。这样既保留了长期记忆的脉络又不会让上下文膨胀。3.2 检索增强的工程细节远比想象中多检索增强生成RAG现在几乎是AI应用的标配但真正做好并不容易。我见过太多项目卡在“检索出来的内容不相关”上。问题往往不在模型而在检索环节的工程细节。第一个细节是分块策略。把文档切成多大一块直接决定检索质量。切得太碎单块信息不完整切得太大一块里混了多个主题检索时容易误命中。我的经验是对于技术文档按语义段落切每块300到500字块之间保留一定的重叠比如50字避免关键信息正好被切断。对于问答类内容一问一答作为一块最合适。第二个细节是混合检索。纯向量检索擅长语义相似但对精确的关键词匹配不敏感。比如用户搜一个具体的错误码向量检索可能返回一堆语义相近但错误码不同的内容。所以实践中通常把向量检索和关键词检索如BM25结合起来两路结果做加权融合效果比单路稳定得多。第三个细节是重排序。初步检索出来的Top-20里真正相关的可能只有前几个。用一个轻量的重排序模型对这20个结果重新打分取Top-3送给大模型能显著提升最终答案质量。重排序模型比大模型便宜得多这一步的性价比很高。提示检索环节的每一个参数分块大小、重叠长度、Top-K、融合权重都应该做成可配置的并且用评测集验证调整效果。拍脑袋定参数是RAG项目失败的主要原因之一。3.3 对话状态该存在哪里对话状态的管理方式直接影响系统的可扩展性。最简单的做法是把整个对话历史存在内存里但这样服务一重启就丢了多实例部署时还会出现“这次请求打到A实例、下次打到B实例历史对不上”的问题。更稳妥的做法是把对话状态外置到Redis或数据库中每次请求根据会话ID读取。存储的内容不是原始消息列表而是经过裁剪和摘要后的结构化状态最近几轮原文、更早内容的摘要、当前会话的关键变量比如用户已经确认的订单号。这样既控制了存储量又保证了跨实例的一致性。还有一个容易被忽略的点会话过期策略。不是所有对话都需要永久保留。对于客服场景一次会话结束后历史就可以归档对于长期助手场景需要保留更久但要定期压缩。设置合理的TTL既能控制存储成本也能避免上下文无限增长。4. 输出约束与结构化让模型输出程序能直接用的东西4.1 为什么“请返回JSON”经常不管用几乎所有需要程序解析模型输出的场景都会遇到格式问题。你明明在提示词里写了“只返回JSON不要有其他内容”模型还是可能给你加上解释、加上Markdown代码块标记或者字段名拼错。这不是模型不听话而是它的输出本质上是概率生成的文本格式约束只是“倾向”而非“保证”。工程上必须假设模型输出一定会出格式问题并为此设计兜底。我的做法是三层防护第一层在提示词里明确给出JSON Schema示例越具体越好第二层用支持结构化输出的模型接口很多模型服务提供了强制JSON模式的参数从解码层面约束第三层在代码里做解析和修复解析失败时先尝试提取JSON片段再失败就触发一次重试重试时把错误信息也带上让模型自我纠正。4.2 结构化输出的解析与修复实战解析模型返回的JSON不能直接用标准JSON解析器因为经常有多余内容。我通常写一个提取函数逻辑是先找第一个{和最后一个}截取中间部分如果失败再找json代码块标记如果还失败尝试用正则匹配键值对。这个函数要能处理嵌套结构并且对常见的格式错误比如尾随逗号、单引号做容错。修复之后还要做Schema校验。用JSON Schema定义每个字段的类型、是否必填、取值范围校验不通过就说明模型输出不符合预期。这时候不要直接报错给用户而是走降级逻辑要么用默认值填充要么换一个更简单的提示词重试一次要么返回一个友好的“暂时无法处理”提示。下面是一个简化的解析与校验流程示例import json import re def extract_json(text): # 尝试直接解析 try: return json.loads(text) except json.JSONDecodeError: pass # 提取代码块 match re.search(r(?:json)?\s*([\s\S]*?), text) if match: try: return json.loads(match.group(1)) except json.JSONDecodeError: pass # 提取首尾大括号 start text.find({) end text.rfind(}) if start ! -1 and end ! -1 and end start: try: return json.loads(text[start:end1]) except json.JSONDecodeError: pass return None def validate_and_fix(data, schema): # 简化版校验检查必填字段 for field in schema.get(required, []): if field not in data: return None return data这段代码不复杂但能拦下大部分格式问题。关键是要把“解析失败”当成正常情况来处理而不是异常。4.3 内容安全过滤不能只靠模型自觉输出处理层还有一项重要职责是内容安全。不能指望模型永远不生成不当内容必须在输出侧加一道过滤。过滤分两类规则过滤和模型过滤。规则过滤针对明确的敏感词、特定格式如手机号、身份证号用正则匹配即可速度快、成本低。模型过滤针对更隐蔽的不当内容用一个专门的小模型或分类器来判断。两道过滤的顺序是先规则后模型因为规则过滤能拦下大部分明显问题减少模型过滤的调用量。过滤命中后的处理策略也要分情况如果是敏感信息泄露直接拦截并记录如果是轻微不当可以替换或打码如果是误判要有申诉和人工复核的通道。注意内容安全过滤的规则库需要持续更新建议把它做成可热更新的配置而不是硬编码在代码里。同时要记录每次过滤的命中情况便于分析误判率和漏判率。5. 成本与性能控制让AI应用跑得久、跑得起5.1 Token消耗的三个隐形黑洞AI应用的成本大头是token消耗而token消耗往往比预期高得多。我总结下来有三个隐形黑洞。第一个是系统提示词过长。很多项目把一大段角色设定、格式要求、示例都塞进系统提示词每次请求都带一遍。如果系统提示词有2000 token一天一万次请求就是两千万token纯属浪费。优化方法是把固定不变的部分做缓存很多模型服务支持提示词缓存或者精简到最必要的程度。第二个黑洞是无效重试。模型调用失败时无脑重试如果失败原因是输入本身有问题比如超长重试多少次都没用只是白白烧钱。正确的做法是区分可重试错误网络超时、服务限流和不可重试错误输入非法、内容被拦截只对前者重试并且设置重试上限和退避策略。第三个黑洞是模型选择不当。不是所有任务都需要最强的模型。分类、抽取、简单问答用轻量模型完全够用成本可能只有大模型的十分之一。我的做法是给每个任务定义“最低可用模型”先用轻量模型跑效果不达标再升级。这个策略在保证质量的前提下能省下大量成本。5.2 缓存策略哪些能缓存哪些不能缓存是降低成本和延迟的利器但AI场景的缓存有讲究。完全相同的输入可以缓存结果这适用于那些确定性要求高的场景比如固定问题的标准回答。但要注意如果上下文不同即使当前问题相同结果也应该不同所以缓存键要包含完整的上下文哈希。语义缓存是更进阶的做法把用户输入转成向量如果和之前某个请求的向量相似度超过阈值就复用之前的结果。这能覆盖“换个说法问同一个问题”的情况。但语义缓存有风险相似度高不代表意图相同阈值设得太松会返回错误答案。我的经验是阈值设高一些比如0.95以上并且只对低风险场景启用。提示词缓存是模型服务层面提供的优化对固定不变的前缀部分做缓存能显著降低延迟和成本。如果你的系统提示词很长且固定一定要开启这个功能。5.3 超时、降级与熔断的工程配置模型调用的延迟波动很大必须设置合理的超时。超时时间设太短正常请求也被切断设太长用户等太久还可能拖垮整个服务。我的经验值是轻量模型调用超时设5到10秒大模型设20到30秒流式输出则按首token时间设超时比如10秒内没出第一个token就断开。降级策略要提前设计好。当模型服务不可用时是返回缓存结果、返回预设的兜底话术还是直接提示用户稍后再试不同场景选择不同。对于非关键场景返回兜底话术即可对于关键场景可能需要切换到备用模型。熔断是防止雪崩的关键。当某个模型服务的错误率超过阈值比如50%自动切断对该服务的调用一段时间避免所有请求都卡在超时上。熔断期间走降级逻辑等冷却期过后再试探性恢复。这套机制在传统后端很成熟直接搬过来用即可。6. 评测与线上排障没有度量就没有改进6.1 离线评测集怎么建才有用评测集是AI工程的“单元测试”。没有评测集每次改提示词、换模型都是盲改效果好不好全靠感觉。建评测集的关键是覆盖真实场景而不是随便找几个问题。我的做法是从线上日志里采样挑选有代表性的请求人工标注期望输出形成“输入-期望输出”对。初期50到100条就能发现大部分问题后续持续补充。评测指标要分层次。格式合规率看输出是否符合结构要求这个可以自动算。内容准确率需要人工或用一个强模型来打分看回答是否正确。相关性看是否答非所问。安全性看是否有不当内容。每个指标单独统计才能定位问题出在哪一层。评测要自动化跑。每次修改提示词或换模型先跑一遍评测集对比新旧版本的各项指标。如果准确率下降超过阈值就不允许上线。这套流程和传统软件的CI/CD是一个道理只是把“测试用例”换成了“评测用例”。6.2 线上问题的完整排查链路线上出问题时排查链路是否完整决定了你能否快速定位。我要求观测层必须记录每次请求的请求ID、用户ID、时间戳、完整输入、组装后的完整上下文、调用的模型和参数、模型原始输出、后处理后的输出、各阶段耗时、token消耗、是否命中缓存、是否触发降级。这些信息缺一不可。排查时按这个顺序走先看请求ID对应的完整记录确认模型收到的输入是什么再看模型原始输出判断是模型本身答错了还是后处理环节改坏了然后看耗时分布确认是模型慢还是其他环节慢最后看是否命中缓存或降级排除这些因素的干扰。有了完整记录大部分问题能在几分钟内定位而不是靠猜。我踩过的一个坑是早期没有记录组装后的完整上下文只记录了用户原始输入。结果用户投诉回答错误时我完全不知道当时检索到了什么内容、带了哪些历史消息排查陷入僵局。补上上下文记录后才发现是检索环节返回了过时的文档。这个教训让我把“记录完整上下文”列为观测层的硬性要求。6.3 从日志中发现系统性问题的技巧单个请求的排查解决的是个案但日志的价值在于发现系统性问题。我习惯定期做几类分析。按错误类型聚合看哪类错误最多优先解决。按模型版本对比看新版本是否在某些场景下退化。按用户反馈关联把用户点“踩”的请求单独拉出来分析往往能发现评测集没覆盖的盲区。还有一个技巧是监控上下文长度分布。如果发现大量请求的上下文接近窗口上限说明裁剪策略可能有问题或者检索返回的内容太多。上下文长度和成本、延迟直接相关这个指标值得持续关注。7. 我在这条路上踩过的几个真实坑第一个坑是过早引入复杂框架。刚开始做AI应用时我花了很多时间研究各种编排框架结果发现框架的抽象层反而增加了调试难度出问题时不知道是框架的锅还是自己的锅。后来我回归朴素做法用最直接的函数调用把链路搭起来等链路稳定了再考虑要不要引入框架。我的建议是先用最少的依赖跑通理解每一层在做什么再决定是否需要框架来管理复杂度。第二个坑是忽视提示词的版本管理。提示词是AI应用的核心资产但很多人把它硬编码在代码里改了就没了历史。我现在的做法是把提示词单独存成文件纳入版本控制每次修改都有记录并且和评测结果关联。这样能清楚知道哪个版本的提示词效果最好出问题也能快速回滚。第三个坑是对模型能力估计过高。早期我总想让模型一步到位完成复杂任务结果提示词越写越长效果还不稳定。后来学会把复杂任务拆成多个简单步骤每一步用模型做一件明确的事中间结果用代码处理。这样虽然调用次数多了但每一步都可控、可测整体稳定性反而更高调试也更容易。第四个坑是没有设置成本告警。有一次测试时忘了关某个定时任务一晚上跑了几万次调用第二天看到账单才反应过来。从那以后我给所有环境都设了成本告警日消耗超过阈值就发通知并且对非生产环境设置了更严格的配额。这个教训很贵但很值。8. 从Demo到生产一份可落地的推进清单如果你手里有一个跑得还行的Demo想把它推向真实用户我建议按这个顺序推进。第一步把模型调用抽象成统一接口业务代码不直接依赖具体模型。第二步把提示词外置成配置文件纳入版本管理。第三步加上观测层记录每次请求的完整输入输出和耗时。第四步建一个50条以上的评测集每次改动前先跑评测。第五步加上超时、重试、降级、熔断这些基础治理能力。第六步加上成本统计和告警。第七步加上内容安全过滤。第八步把对话状态外置支持多实例部署。这个顺序不是绝对的但有一个原则先可观测再优化。没有观测数据优化就是盲人摸象。我见过团队花大力气优化提示词结果因为没记录上下文根本不知道优化有没有效果。先把观测层建起来后面的每一步改进都有数据支撑效率会高很多。AI工程这件事说到底不是比谁用的模型更强而是比谁的系统更稳、更可控、更可持续。模型会不断迭代但工程能力是沉淀下来的。把这条链路搭扎实换什么模型你都能快速接上这才是真正的竞争力。