看到ai-engineering-from-scratch这个标题第一眼我其实挺有感触。这两年我见过太多AI项目的起落死法都惊人地一致不是模型不行而是团队把做一个AI应用理解成了调通一个大模型接口。这个命名如果翻译过来意思是AI工程从零开始建立强调的是工程体系而不是某个模型怎么调用。这篇内容我就照着这个思路结合自己在一线落地AI功能时反复踩过的坑梳理一条真正可执行、可复现的AI工程路线。不聊宏大理论不讲PPT框架里面的每一条基本都是我用真实项目换来的教训适合正在做或准备做AI应用的产品、开发和算法同学读。1. 动手之前先泼冷水AI项目失败率最高的一环是需求判断1.1 先问要不要用AI再问用哪个模型很多项目最大的问题不是技术选型选错了而是起点就错了。拿到一个业务需求时不要急着想prompt怎么写、上哪个模型先做一个冷静的可解性评估。我自己的判断逻辑大概是这样规则能解决条件明确、分支有限、数据干净就别上模型。传统机器学习能解决有结构化标签、特征稳定、样本量够就别上大模型。需要语义理解、跨领域常识、内容生成、模糊匹配才考虑LLM。如果需求是实时决策、要求几乎零错误、且数据极度敏感那大概率连LLM也不合适至少不能作为主力方案。举个例子。曾经有个需求是自动给客服工单分类团队的方案是用大模型做分类。我一看历史工单类别总共8个文本相对规整标签数据攒了上万条。这种问题用文本分类模型又快又便宜又稳定。换成LLM以后准确率未必更高单次请求成本和延迟还上去了。反过来另一个需求是根据用户描述生成一份定制化的服务方案规则写不进去固定模板又套不住这种就适合LLM。这里有个不太舒服但必须接受的现实AI工程不是越高级越好而是越合适越好。技术选型的前提是把问题本身看清楚。1.2 把业务目标翻译成技术指标而不是张口就要准确率需求评审会上经常听到我们的准确率要达到95%。这个数字本身没什么意义因为你没有先定义什么算准确。工程上务实的做法是把业务目标拆成可观测的指标。比如业务方说想降低客服查手册的时间技术侧就应该把它拆成用户提问后有多少比例的问题能在不转人工的情况下给出可用答案覆盖率。给出的答案里有多少次被用户标记为有用或继续追问有用率/追问率。全链路单次请求的响应时间P50、P95。平均每个请求消耗多少token、多少钱。模型侧的指标比如回答正确率、幻觉率当然要关注但最终验收的是上面这些业务指标。我见过一个团队模型的离线评测分数很好看上线后用户就是不买账。后来一查用户问的100个问题里模型根本答不对35个评测集里全是那些好答的。不是模型不行是评测集脱离真实场景。这个教训后面还会反复提到。1.3 花最少钱做一次可行性验证在全面铺开之前先用最小的成本验证这条路径是不是走得通。我习惯的做法是从真实业务里挑5到10个最有代表性的问题加上2到3个明显容易翻车的边界问题用最朴素的方式跑一遍——简单的检索加上一个中等能力的模型看看效果。如果连这种低成本方案的输出都不像话那问题多半不是模型太弱而是需求定义、数据形态或场景预期出了问题。这套可行性验证往往能发现一个更扎心的事实业务方想要的那个效果目前公开可用的模型能力根本达不到。这时候及时调整预期、缩小场景范围比咬着牙堆预算硬上要聪明得多。2. 从调大模型变成搭系统AI应用是一张带反馈的网2.1 别把LLM当成一个黑盒函数它只是一块积木初学者最容易掉进的一个陷阱是把LLM当成输入文字就出答案的万能函数好像只要在代码里调一次API就完成了AI工程。实际生产里一个AI应用是一个有数据流动、有失败分支、有反馈回流的完整系统。我的习惯是把它拆成五层业务接入层面向用户的形态比如聊天窗口、后台批量任务、报表分析入口它负责接收输入和展示结果。流程编排层决定任务怎么拆、哪些步骤要调用工具、哪些结果需要校验或退回重做。上下文工程层负责把问题变成模型刚好够用的信息组合包括检索、过滤、排序、压缩、拼接。模型调用层负责调用具体模型、解析输出、做结构化校验。数据与评测层负责沉淀日志、反馈、样例跑评测形成数据回流。这几层之间的边界要清楚。我见过不少团队把这些逻辑全塞进一个Prompt里让模型自己临场发挥结果就是上线时好像能用稍微复杂一点就乱套。因为流程逻辑是确定性逻辑应该用代码来写模型只负责做它擅长的语义理解和生成。两层混在一起出问题的时候连定位都难。2.2 每一层都要假设模型今天可能出错大模型输出具有天然的不确定性。这个事实听上去像废话但工程化的时候经常被忽略。一个可靠AI系统的设计原则是默认模型这次调用可能返回错误、格式不合法、内容偏离主题然后围绕这个假设做工程防护。我自己的组件清单里几乎每个环节都有配套的兜底策略模型返回结果先做schema校验不通过就让模型带着校验报错信息重试一次再不行就转人工兜底。检索链路后面细讲如果召回不到任何可用内容就直接回答这个问题我无法确认绝不让模型强行编一个答案。对高风险的生成动作比如替我发一封邮件执行这个配置变更必须在编排层里加人工确认按钮模型不能直接落地操作。举个例子。一个信息抽取任务让模型输出用户的姓名、日期、金额。如果只要求自由文本返回下游逻辑很难处理如果让模型输出JSON结构再用代码校验字段是否存在、格式对不对就能把错误拦截在入口处。这一步属于典型的工程比模型更重要的环节。2.3 成本和延迟是架构约束不是上线后再优化的参数很多项目上线之后才意识到单次请求成本高得离谱、延迟让用户等得焦虑。这不是后期调参能解决的应该当作架构约束从第一天就想清楚。上线前我会要求团队做三个预估算单次请求的最坏token消耗是多少包括输入、输出、重试、历史记录。单次请求涉及多少次外部调用模型调用、检索、工具链每多一次延迟就会叠加。P95延迟有没有超过产品可接受范围。我见过一个实际案例一个对话助手的上下文拼接逻辑非常粗暴把所有历史对话原封不动塞给模型结果对话超过10轮以后每轮输入token接近几千成本翻倍不说响应速度也明显变慢。后来改成了摘要关键信息最近两轮完整对话的结构化方案问题才解决。这就是典型的架构设计时没考虑成本约束造成的后果。成本不是事后省出来的是在设计阶段就要定的预算。3. 先用业务评测集把模型钉住再谈选型3.1 排行榜只能给方向不能给答案很多技术团队选模型的方式是看排行榜谁分数高就用谁。这个做法我不能说错但它有严重的偏差——公开排行榜讲的是通用任务的平均表现你的业务场景往往是那些排行榜根本没覆盖的长尾问题。今天有大量需求是能不能帮我整理合同条款这个政策的原文出处是什么回答必须包含引用来源——这些能力排行榜不会告诉你。我更推荐的姿势在选型之前先建一份自己的业务评测集。别嫌工作量小我当时从零开始做也是这样先攒了大概80个真实场景问题后面慢慢补到三百多个。一份合格的评测集至少包含类型高频典型问题、容易混淆的边界问题、故意刁难的对抗问题。期望输出不只是给一句标准答案还要写明约束比如回答必须基于提供的资料不允许凭空补充以JSON格式返回。判定标准完全正确部分正确缺失要点错误幻觉这些档位要提前定义好。来源标注每个问题来自哪一类业务场景、哪个渠道收集的方便统计覆盖度。有了评测集模型选型就变得很机械把同一个Prompt和同一批参考资料喂给候选模型对比输出。这种方式测出来的是在真实业务条件下的表现比任何排行榜都有说服力。3.2 选型维度要结构化而不是感觉谁聪明我选模型时很少凭直觉判断这句话答得很好。真正要比较的东西我列了一张常驻表格正确性业务问题答得对不对看评测集通过率。格式遵循度面对必须输出JSON这类硬约束时家庭率有多高。这决定了你在工程侧要做多少纠错。幻觉率在不知道的场景下模型是老老实实说不知道还是强行编一个。这个维度往往决定了你的产品敢不敢给用户看。上下文长度支持多少token是一回事真正塞到这么多token后还能不能准确提取关键信息是另一回事。很多模型是支持8K但实际有效4K要实测。速度与成本同一条Prompt在不同模型上的响应速度和单价乘以你的预估请求量算一算月度账单。部署与生态开源模型要考虑推理框架成熟度、是否支持流式输出、权限和隐私要求。顺便说评测集还有一个很实用的用途——版本对比。模型供应商升级版本了、你换了embedding模型、或者修改了检索模块先过一遍评测集看通过率是升是降而不是凭感觉好像变聪明了。这一条是工程纪律不是可选项。没有评测集的AI项目就像没有测试直接上线的传统项目风险超高只是很多人还没意识到。3.3 MVP阶段和生产阶段的验收门槛不一样同一个功能内部Demo可以很粗糙但上线必须有底线。我习惯把验收标准分成两套。MVP阶段的底线是关键路径能跑通失败时有兜底方案不给用户输出危险或违规的内容。此时正确率低一点可以接受只要产品愿意有人工介入。生产阶段的底线则严格得多核心场景的评测通过率达到业务方认可的门槛这个数字要事先约定不能事后拍脑袋。单次请求成本和延迟控制在既定预算内。没有持续的Bad Case集中区——如果某些类型问题反复出错说明数据集或编排有结构性问题不能靠换Prompt糊弄过去。有回滚方案、有线上日志和Trace链路、有用户反馈通道。对涉及隐私的数据有明确的处理策略。还有一个特别重要的习惯生产环境里出现的每一个Bad Case都要流回评测集。这样评测集才会越来越接近真实世界系统每周都能看到本周新出的问题类型是什么。很多团队只做一次评测集做完就扔在一边这是不对的。评测集是活的资产它和你的知识库一样需要持续维护。4. 数据与上下文真正的效果主战场不在模型参数里4.1 领域数据的整理质量决定了答疑效果的上限做AI工程做久了会发现一个规律两个项目用同一个模型一个效果好一个效果差差距往往不在工程框架多高级而在数据整理的精细程度。以文档问答为例我见过太多团队直接把一堆PDF塞进去做连接向量检索然后抱怨模型好笨连原文里的话都找不到。多数情况下不是模型笨而是数据没有处理好。我踩过的一个经典案例是这样的一篇400页的配置说明文档里有这样一句关键信息——试用期最长可以延长到90天需提交申请材料但它躺在一个表格里。PDF转文本以后表格结构全丢了变成一行行挤在一起的碎片文字检索时既匹配不上延长90天这样的词语义向量也排不上号。后来我们把表格单独识别转成行号内容关键标题的结构化条目检索命中率立刻上来了。所以我的数据准备流程一般是解析PDF、Word、HTML分别处理PDF优先保留结构而不是纯文本提取。清洗去除页眉页脚、水印、重复段落、乱码字符这一步看着不起眼但往往能干掉大量召回噪音。切分这是重头戏。不要不看文档直接按固定字符数切块。结构化文档要按标题层级、章节、表格、列表来切普通文本可以按段落切把一个小节的标题作为锚点拼在上面。建立索引除了正文向量索引单独建一个标题/章节索引用来支持按章节级定位的召回。4.2 RAG不是塞进去加向量检索就完事很多刚接触RAG的人以为把文档切开、向量化、能搜到相关片段然后就完事了。真实工程里的RAG链路要长得多也麻烦得多。我自己的标准链路大概是文档解析与清洗上面已经讲。向量化入库注意选择合适的embedding模型同样要测试。不同模型对中文习惯用语的语义捕捉能力差距显著别想当然。混合召回不要只用向量检索。关键词检索BM25这类和向量检索各召回一批取并集。因为向量检索擅长语义相似但对精确的关键词、编号、型号、金额这类信息经常无能为力关键词检索恰好能弥补这一点。重排把召回的Top 30到50条结果用一个重排模型精排到Top 5到10条。这一步能显著减少夹带信息垃圾的概率。成本不高但对效果提升非常明显。上下文组装更核心的步骤来了。不要让模型同时看到太多不相关的内容信息过载反而让它迷失重点。我的习惯是主信息辅助信息硬约束的结构主信息是经过重排的Top若干篇相关内容辅助信息是用户身份、权限、业务上下文等结构化字段硬约束是不要编造无法回答时明确说不知道。判定与退路组装完上下文以后在代码层加一步判断——召回结果到底跟用户的问题有没有关联早期的系统不判断回答质量就不稳定。后来加了一个相似度距离阈值低于阈值就直接走无法确认分支不再调用生成步骤效果立刻稳定了。这套链路里重排和退路判断是最容易被省略的但恰恰是它们把RAG从看着能用变成了真的可用。很多人问为什么自己的RAG总答非所问先检查你有没有做这两个步骤。4.3 数据回流闭环系统不会越用越聪明除非你喂它越用越聪明这句话是大模型应用宣传里的玄学。模型不会因为多服务几个用户就自动变强真正变强的是数据闭环。如果今天用户问了一个问题、系统答错了这个问答只是被丢进日志里那你永远不知道它答错了。到明天同样的错误还会再犯。我坚持的闭环结构是线上日志里记录完整请求信息用户问题、召回内容、模型输出、是否被反馈。用户反馈通道点赞/踩、复制行为、转人工自动沉淀信号。每周抽检一批低分数据人工给标记补充到评测集。周期性复盘某些Bad Case的类型是切分问题检索问题还是Prompt指令不清楚对病根下药。必要的时候用这些新标记的好案例去更新知识库或者构造Few-shot示例而不是动不动就想去微调模型。这个闭环的周期可以是一周或两周重点是规律性和纪律性。AI项目的长期竞争力藏在你能多快地发现错误、多稳定地修正错误里。5. 编排与Agent把不可靠的步骤组织成可靠流程5.1 不是所有需求都值得拆成Agent提到AI工程现在很多人开口就是Agent。但我观察下来大量项目被Agent这三个字带歪了。Agent本身不是目的它只是把复杂任务拆多步、动态调用工具的一种手段。拆出越多步骤延迟越高每一步都可能出错链路越长越难排查。我自己的判断标准是一个任务如果单次调用、加充分的上下文就能完成那就坚决不要拆。例如回答产品价格和试用政策根本不需要规划-调用-验证这套过程老老实实把政策文档喂进去让模型回答就好。Agent真正适用的场景是那种需要动态决定下一步做什么的过程比如根据用户描述排查配置问题并且需要我们主动去读取配置文件、执行检查命令、修改参数再验证——这种任务本身就需要迭代执行。即便决定用Agent也要给行为加边界。一个生产级Agent至少要有行动范围清单能调用哪些工具、哪些操作需要人工审批。步骤上限最多执行多少步防止无限循环。校验机制工具返回的数据要过一遍合法性校验不能用模型自己的输出直接操作。失败退出确认某一步走不通时直接返回中间结果让人接手而不是继续硬试。记住Agent解决问题不是靠更聪明而是靠有纪律的多步尝试。5.2 结构化输出与校验是整个工程的地基模型输出的格式是你和系统之间最重要的契约。只要这一层没做好后面所有的解析、存储、流程都会变成一场灾难。我最常给团队传递的一个原则是能给模型加结构约束的地方就不要放任自由文本。比如一个审核模块我让模型输出成JSON结构{ is_valid: true, confidence: 0.87, reasons: [内容与政策第3条一致, 无新增承诺信息], suggested_action: auto_reply }然后在代码里做一个schema校验字段是否存在、枚举值是否合法、confidence是否在0到1之间。校验不过就重试一次再不过就进入人工队列。这套逻辑保证了核心流程不依赖模型今天心情好不好。还有一个实用技巧让模型先做内部推理再给结构化结果比如下面这种格式{ analysis: 用户的问题是询问退款流程关键条件是购买时间在7天内且商品未拆封。, result: { eligible: true, next_steps: [提交退款申请, 上传订单截图] } }把推理过程和业务动作分开人类可以检查分析是否有道理程序可靠地消费result里的结构化数据两边都不耽误。这一步属于纯工程技巧但对稳定性的提升是立竿见影的。5.3 多轮记忆与可观测性没有这两样线上出了问题只能靠猜多轮对话里一个大坑是盲目拼接历史消息。别把聊天记录当成无限长的尾巴扔给模型就好了——对话超过一定轮数垃圾信息会让模型失去重点。我们的做法是维护一个结构化的会话记忆包含最新完整对话通常最近两轮。对话摘要压缩之前的内容。关键实体用户提到的产品型号、时间、金额、意向状态。这三样拼起来作为下一轮输入既不会丢失必要信息也不会因为历史太长拖累成本和延迟。这套模式和传统的状态管理思路一脉相承只是搬到了LLM应用里。可观测性这块很多团队是出了事才开始补。这里我的建议是从第一天就把三样东西留好链路追踪每个请求经过了哪些步骤、每步返回什么。Token与成本统计按用户、按功能、按入口分账单。人工抽检面板抽样看看线上回答的质量分布。没有这些线上出了问题你只能靠搜索引擎翻日志。有了这些你可以快速定位是检索环节没找到还是生成环节跑偏还是上下文被截断了。6. 一个算得上生产级的案例内部文档问答从0到上线6.1 从需求到技术方案的一次完整决策拿我经历过的一个典型项目来做串联给一个内部客服团队做产品文档问答工具目标是把客服新人查手册的平均时间从5分钟降到30秒以内同时保证答案不编造、有出处。需求判断阶段我确认了三点问题数量大、覆盖面广、无法靠规则枚举所以用LLM合理但用户群体是内部客服场景可控可以先做MVP正确率允许初期略低但绝对不能有编政策的情况所以幻觉管控是最高优先级。技术方案定成这样混合检索加重排中等能力档的模型输出JSON且必带引用来源有查不到就说不知道的兜底分支。没有上Agent因为这个场景不需要动态拆步骤。很多人会觉得问答就得上Agent其实对固定知识库问答来说这是过度设计做一步拆一步反而是负担。6.2 数据准备与知识库构建的具体动作原始资料有PDF有Markdown。PDF先做OCR和结构识别手工抽检了大概20%的页面确保页眉页脚没污染正文。切分的时候按章节结构来每一块文本前面拼上完整的标题路径保证每条内容自带我来自哪个章节的锚点。知识库初始就建了两套索引正文向量索引、标题/章节索引。检索的时候先从标题索引定位到可能相关的大章节再从正文里精找。这个双路设计对长文档特别有效避免正文片段被检索到但缺少标题上下文的问题。我还做了另一件事在开发初期没有直接开始调Prompt而是先准备了一个召回检查清单——20个真实高频问题看检索环节能不能在Top 5里找到正确答案。如果找不到回去修切分和索引而不是急着换模型。这一步对效果的提升远超后面所有模型的参数调整。6.3 上线前后的质量门禁上线前评测集通过率定了一个保守目标核心高频问题达到90%以上整体通过率不低于85%。同时对无法回答分支做了强制校验如果召回的相似度低于阈值模型必须拒绝回答这一条通过20个对抗问题的测试才放行。上线时采取灰度方案先给5%的客服试用观察一周。重点看两类数据用户对回答的反馈标记数量以及无法回答的触发率是不是合理。如果触发率太高说明知识库覆盖不够如果太低可能是不知道装知道的问题需要抽检。这个项目踩过最典型的坑是文档版本。某次产品政策更新新文档入库后旧文档的向量数据没有同步清理导致同一个问题有两个版本的答案在竞争系统时对时错。后来在知识库里给所有文档加了版本号和生效日期检索和生成阶段都只用当前版本的内容问题消失。这类问题教科书里不会写但是实际运行中非常常见。6.4 这个案例的启示克制比炫技重要回看这个项目让我最有体感的不是某个模型多厉害而是整套系统的克制没有Agent没有复杂多轮没有微调只做扎实的检索、严格的结构化输出和明确的拒答分支最后效果反而很稳。很多AI项目做崩不是因为技术不够新而是因为想一口气把所有新技术都堆上去结果层层叠加的不确定性根本没法维护。工程上少即是多这个道理在这个案例里体现得尤其明显。7. 从零开始的武器清单AI工程能力地图与学习方法7.1 按优先级排列的核心技能栈如果现在有人问我要从哪里学起我给一个按性价比排列的技能清单第一优先级结构化输出的写法、Prompt的稳定写法、业务评测集的搭建。这三项构成AI工程的底层基本功几乎所有应用都依赖它们。第二优先级RAG的完整链路包括文档解析、切分、混合召回、重排、上下文组装、拒答判定。这是现在大多数业务场景的通用方案。第三优先级Agent编排、会话记忆、可观测性、成本治理。等前两块夯实了再碰这些不迟。第四优先级模型微调。很多人一上来就想微调模型我强烈建议不要。微调的起点是已有评测集证明通用模型加RAG解决不了某个类型的问题否则大概率是在浪费算力。7.2 一些追随我踩坑得来的学习建议第一不要满足于跑通官方Demo。Demo能证明接口能通不能证明业务能成。你可以把任何一个Demo换成你业务里的真实问题追问一句如果没做这个功能我损失了什么这个答案说不清楚说明你还没有真正在做工程。第二选一个垂直小场景做彻底不要每天追热点。比如做一个只给自己用的技术文档问答工具把数据、评测、可视化、成本统计都真正做出来。做透一个垂直东西筹得的经验比跟着一堆教程做十个表面Demo要扎实得多。所有教程里最常遗漏的部分——数据清洗、失败处理、线上观测——都会在这一步里补回来。第三在设计阶段就和业务方一起定义什么回答算好。这个动作看着是产品沟通实际上是工程的一部分。因为只有双方对好的判定一致了评测集才能建起来后面的模型选型和迭代才有依据。7.3 最后关于从零开始的真意回到ai-engineering-from-scratch这个主题我最后想说的是从零开始理的其实是从零开始建立工程能力而不是从零开始手写一个大模型。真正难的不是ML理论不是某个框架的API而是你愿不愿意在看不到短期回报的情况下先把数据洗干净、把评测集建起来、把失败分支想清楚。这些活又脏又细但恰恰是它们决定了AI应用能不能在真实世界里活下来。AI工程的长期竞争力就藏在这些不性感的日常里。