1. 重新理解AI工程不是“调模型”而是“搭系统”看到“ai-engineering-from-scratch”这个标题我第一反应是想起自己刚入行时的误解以为AI工程就是从零训练一个模型把Loss曲线调好看然后部署上线就完事。后来真正做了几个从数据标注到线上监控全流程的项目才意识到这个理解窄了。AI工程的重点不是“AI”而是“工程”——它是一整套围绕模型生命周期的系统设计、数据管理、评估机制、成本控制和风险兜底方案。从零开始做AI工程意味着你要同时面对三层挑战第一层是模型层的算法选型和训练/微调策略第二层是系统层的服务架构、数据管道和观测体系第三层是业务层的目标对齐、结果评估和迭代机制。很多人把精力全部砸在第一层结果项目死在第二层和第三层。我见过不止一个团队花三个月训练出一个漂亮的模型却因为没有完整的评测集和回归机制上线一周就出现不可控的漂移最后不得不回滚。“from scratch”的价值恰恰在于你要把这三层当作一个整体去设计和建设而不是把模型当作孤立的艺术品。这篇文章我就想从自己从零搭建AI工程体系的实操经验出发把选型思路、关键环节、踩坑记录和测试策略一次讲透。适合三类人看一是准备从传统软件工程转AI方向的开发者二是已经在调模型但总觉得项目离“工程化”差一口气的工程师三是在企业内部从零推动AI项目落地、需要建立完整流程的技术负责人。文章里不会有那种“复制粘贴就能跑”的魔法代码因为真正的AI工程本来就不存在魔法只有一环扣一环的细节。2. 核心设计思路拆解先搞清楚“from scratch”的三种起点2.1 “从零”不等于“从模型参数开始”我在很多场合强调过一个观点ai-engineering-from-scratch里的“scratch”在不同项目里有完全不同的含义。第一种是把模型本身当作起点比如按照论文从零预训练一个Transformer或者复现一个开源大模型的训练流程这种路径适合做算法研究的人对算力、数据和工程功底的要求都极高。第二种是从开源底座模型出发把数据工程、微调、对齐、部署这条链路从无到有搭起来这是目前绝大多数企业AI项目的真实起点。第三种是连业务场景都是全新的你不仅要做模型还要定义这个AI系统到底该解决什么问题、用什么样的交互方式、如何嵌入现有业务流程。我自己的经验是绝大多数人真正需要的其实是第二种和第三种的结合。你不需要从零去写反向传播但你必须从零去建立一套“数据怎么来、模型怎么选、效果怎么评、坏了怎么发现”的闭环。所以设计AI工程体系的第一个原则是把“训练一个模型”这个目标替换成“交付一个可持续演进的AI服务”。这个表述差异决定了后续所有的技术选型。2.2 设计原则用传统软件工程的纪律约束AI的不确定性AI工程和传统软件工程有一个本质区别传统工程面对的是确定性逻辑输入确定、输出就确定AI工程面对的是概率系统同样的输入可能产生不同的输出而且错误往往是“看似合理但实际错误”。这个区别直接决定了设计思路必须做出调整。我在架构设计阶段给自己定了几条硬规矩。第一条是任何AI能力必须封装成独立服务绝不把模型调用直接写进业务代码这样可以随时切换模型版本而不影响主链路。第二条是所有模型输入输出都要有Schema校验哪怕是最简单的JSON格式检查都能拦下一大半线上事故。第三条是必须预设降级方案模型服务不可用时是返回缓存结果、走规则引擎还是直接报错这个决策必须在设计阶段就完成不能等线上故障了再讨论。这三条规矩看起来平淡无奇但它们才是AI工程和“调模型”之间真正的分水岭。从知识结构上看从零进入AI工程还需要补一个很多人忽略的短板数据敏感度。传统开发对数据的关心通常止步于“能不能取到”而AI工程要求你关心“这批数据是怎么分布的、标注质量如何、训练集和测试集之间有没有泄露”。我在后面第三部分会展开讲数据这块这里先提一句因为设计思路阶段如果没有数据视角后面每一步都会走弯路。2.3 为什么“先跑通再优化”是唯一正确的节奏做AI工程项目最大的陷阱不是技术难点而是完美主义。我见过太多团队卡在“数据不够好”“模型精度不达标”的循环里出不来三个月过去了连一个端到端的Demo都没有。我自己在这上面吃过亏所以现在执行项目时强制采用“纵向切片”策略第一周就必须把“一条数据 → 模型调用 → 结果展示 → 人工反馈”这条链路完整打通哪怕用的模型是随便挑的、效果很粗糙但整条链路的延迟、成本、交互体验能让你立刻看清楚问题在哪里。这种做法的好处是反直觉的你越早暴露整条链路的短板就越早知道自己应该把精力投向哪里。有时候跑通之后你会发现瓶颈根本不在模型精度而在数据管道的稳定性有时候你会发现用户真正在意的不是回答质量而是响应速度。如果按部就班先把模型做到极致再建设周边系统你大概率会在错误的方向上浪费大量时间。从零起步的人尤其要记住工程体系的建立是一个不断“做出来、发现问题、调整”的循环而不是“想清楚再动手”的瀑布流。3. 基础环节实操数据、评估、环境的从零搭建3.1 数据工程的优先级高于模型工程很多初级玩家把80%的时间花在模型调参上但实际项目里决定成败的往往是数据。我在做第一个从零项目时模型用的是开源底座效果一开始就有70分但数据管道不完善导致迭代速度极慢——每优化一个版本都要手动清洗、拼接、验证数据光这一步就消耗了三分之二的开发时间。后来我把重心彻底倒过来花了两周时间搭建了一套半自动的数据处理管道模型的迭代效率立刻提升了数倍。具体到操作层面一个合格的AI工程数据管道至少包含四个环节数据采集、清洗去重、格式转换、质量抽检。采集环节要注意覆盖真实场景的多样性不能只用内部测试数据清洗环节要处理明显的噪声、重复和敏感信息这里需要人工抽检来确认清洗规则没有误伤格式转换环节要统一成模型服务要求的输入输出通常就是JSON质量抽检环节必须有明确的标注一致性指标比如两个人标注同一批数据时的一致率。数据管道建好之后你做的每一次模型优化才有意义因为你能快速知道“效果变好了到底是模型改对了还是数据变了”。3.2 评估体系没有评测集的AI项目等于盲人摸象再强调一遍AI工程和传统软件工程最大的区别就是“没有明确的正确答案”所以建立一个可靠的评估体系是从零开始的必修课。这套体系我认为必须包含三个层面离线评测集、线上指标监控、人工抽检反馈。离线评测集的核心作用是做回归测试。我自己的做法是维护一个多场景的测试题目集每个场景至少20到50条覆盖不同难度和边界情况的问题并预先写好参考回答或评价标准。每次模型版本变更都要在这个集上跑一遍对比新旧版本在每个场景的表现一旦发现某个维度的分数明显下跌就要决定是回退还是接受。这套机制和传统软件工程里的自动化测试是同一个思路只不过断言的粒度更粗——不是判断“对不对”而是判断“好不好的程度”。线上监控指标的选取也很有讲究。不要只盯准确率这种抽象指标要关注能直接反映用户体验的数据响应延迟、超时率、无答案率、用户点踩率、用户编辑次数等。这些指标中出现异常往往比离线评测更能说明问题。人工抽检则是最后一道防线因为离线测试集再完善也不可能覆盖所有真实的表达方式。我一般保持每周抽检50到100条真实线上日志由产品和技术一起打分确保模型没有在离线测试和线上监控都看不到的角落悄悄“飘”走。3.3 环境搭建与依赖管理给可复现性留一条退路最后补一块基础建设开发环境和依赖管理。这个听起来跟AI不沾边但恰恰是“从零开始”最容易被坑的地方。深度学习框架、CUDA版本、Python包依赖、模型文件的版本任何一个不一致都会导致训练结果无法复现。我自己因为换了一台机器就复现不出实验结果的经历至少遇到过三次。当前比较稳妥的做法是用Docker把运行环境完整固化Python依赖用lock文件锁定到具体版本模型权重单独管理并记录对应的训练数据版本和代码commit号。不要嫌麻烦这套流程建好之后你会非常轻松地在不同机器上复现实验、回滚版本、协作开发。特别是团队协作场景每个成员各自维护一个“我这里能跑”的神秘环境绝对是一场灾难。4. 工具链选型模型、框架与工作流的配合策略4.1 模型选型的逻辑不是“最强”而是“最匹配”模型选型是整个AI工程项目里最受关注也最容易出错的决定。很多人的第一反应是选当前榜单上最强的模型但实际工程中要考虑的维度远不止效果一项推理成本、延迟、私有化部署的难度、上下文窗口、生态成熟度、可微调性每一项都可能成为决定性因素。我目前的选型习惯是按照“任务复杂度”和“数据敏感性”两个维度画一个四象限。简单任务如意图分类、实体抽取优先考虑轻量级模型可以用API调用或者本地小模型成本和延迟可控复杂任务如长文档分析、多轮对话才考虑大参数模型。数据敏感的任务必须考虑私有化部署这时候模型的可商用许可证、推理效率、社区活跃度就是第一优先级。数据不敏感的任务可以大胆用商用API开发速度快、维护成本低。还有一点容易被忽视选型时一定要看这个模型周边的工具链是否成熟比如是否有方便的微调框架、是否支持流式输出、是否有官方客户端SDK这些直接决定了你的开发节奏。4.2 Prompt与Agent从“问模型要答案”到“给模型搭环境”说完模型选型必须接着聊Prompt工程。现在关于Prompt的内容已经很多了但我想从工程化的角度讲一个不同侧重点Prompt不是一个“写好的静态文本”而是一个需要版本管理和动态拼装的程序组件。我在正式项目里很少直接把用户提问原样抛给模型而是会有一层模板系统系统预设指令是固定的一段背景知识来自检索结果用户输入经过清洗和安全检查三者拼装后才会发给模型。每一个部分都独立维护、独立测试任何一个部分的改动都能追踪到效果变化。再往上走一层就是AI Agent。这个概念现在火得不行但真正能在生产环境跑起来的Agent极少。我自己的工程实践原则是Agent的本质不是“让模型自由发挥”而是“让模型在预设的工具盒里做选择题”。具体来说我会把Agent的能力边界划得很清楚它能调用哪些工具、不能调用哪些工具、哪些操作必须经过人工确认、哪些信息缺失时必须停下来反问。用传统工程的话说就是给模型一个受限的执行环境而不是给它一把万能钥匙。4.3 Harness与工作流把AI关进“带护栏”的系统里这里聊一个业界讨论得越来越多但实践还不够的概念Harness Engineering。它指的是围绕AI模型建一套“外置护栏”让模型的输出始终在可控范围之内。我自己的理解很朴素既然是概率系统就不可能保证每次都正确那工程上要做的事情就是——让它正确的时候能顺畅生效让它错误的时候不要造成危害。实现这个目标具体有三个抓手。第一是输入侧护栏内容安全过滤、Prompt注入攻击检测、用户输入长度控制、敏感信息识别。第二是输出侧护栏格式校验、关键词黑名单、答案置信度阈值、闭环的引用来源检查。第三是流程侧护栏关键操作二次确认、异常分支兜底、重试机制和降级策略。这三层护栏加在一起效果远大于把模型本身调得更“聪明”。因为模型的能力上限你很难控制但你可以控制它做错的后果。在这个基础上多AI协作的工作流才有意义。当你要让多个不同模型或Agent协同完成任务时比如一个负责生成、一个负责审核、一个负责精简核心原则是每个环节都要有明确的责任边界和交接格式。前一个模型的输出就是后一个模型的输入所以中间的格式规范化比模型各自的精度更重要。我的做法是给每一段模型交互都定义严格的Schema任何一个环节输出不符合Schema就触发重试或降级而不是把脏数据继续往下游传。如果你在从零设计AI系统我强烈建议把这些“工程套管”放进第一版架构图里后面你会感谢自己。5. 实操案例从零构建一个内部知识问答助手5.1 项目定义与初始架构这一节我想分享一个真实的从零实践案例项目目标是给公司内部做一个知识问答助手回答范围是HR制度、IT运维指南和项目流程文档。这个案例的好处是场景明确、数据来源可控、对模型要求不算极端很适合用来演示端到端的AI工程流程。项目起步时我首先明确几个关键约束第一知识库是私有的不能调用外部API必须私有化部署第二回答必须基于给定的知识库文档不能凭空发挥第三响应时间需要控制在3秒以内第四非工作时间遇到无法回答的问题要能自动转人工工单。有了这些约束技术路线就基本锁定了采用开源模型做私有化部署外面包一层RAG检索增强生成的管道再加规则引擎处理转人工逻辑。初始架构分五个模块文档加载与切分、向量化入库、检索服务、模型推理服务、结果校验与兜底模块。我特意把“结果校验与兜底”作为一等公民放进架构图而不是等出问题了再补这是吸取了之前项目教训之后的决定。5.2 数据准备与检索策略的实操细节建好架构之后第一步就是处理文档。这正是大家最容易低估的部分——你以为RAG就是把PDF扔给向量库实际做起来全是坑。文档里大量存在表格、页眉页脚、交叉引用和图表直接切分会造成严重的语义断裂。我的处理流程是先统一转成Markdown格式人工清洗掉页眉页脚和无关信息然后按语义层级切分优先保留章节标题作为上下文锚点每个切分后的文本块控制在300到500字左右并记录来源文档、章节路径和页码。切分完成后建立向量索引这里有两个参数值得细说一是Embedding模型的选择我对比了几个主流模型后选了为中文优化的模型因为我们的文档绝大多数是中文二是检索的Top-K召回设置K值太小可能漏掉关键信息K值太大会把噪声带进上下文导致回答混乱。经过测试K值设置在5到8之间效果最好配合重排序步骤还能进一步提升召回质量。重排序的原理很简单向量检索先粗召回一批候选块再用一个轻量级排序模型按相关性精排只取最相关的前三个块放进模型上下文。5.3 模型服务化与短线优化记录模型推理服务这一环我用的是开源底座加量化部署。这里量化方案的选择直接决定了成本与效果的平衡。全精度FP16效果最好但显存占用高推理速度慢INT8量化能显著降低显存占用速度也快但在某些专业术语较多的场景会出现轻微质量损失INT4量化省资源但质量下降更明显。我最终选择了INT8并且在量化后专门跑了一遍离线评测集确认关键场景的得分没有明显下跌才上线的。上线之前我还做了一次“答案可信度”的设计让模型在回答时尽量引用知识库中的原文片段如果检索到的内容与问题相关性不够高模型必须回答“当前资料不足以回答该问题”而不是硬凑答案。这个设计显著降低了幻觉率。我还设置了一个置信度阈值模型自评的回答置信度低于0.6时自动转入人工工单流程。这套逻辑一开始只是权宜之计后来成了整个系统最受欢迎的功能之一——用户明显感觉到这个助手“知道自己在什么时候不知道”。5.4 上线后遇到的三个真实问题这个案例上线后我记录了若干个有价值的问题挑三个分享。第一个是冷启动检索质量差。文档刚导入时由于没有足够的用户反馈数据很多问题检索不到正确的内容。解决办法是在正式上线前让各部门提供一批“高频问题清单”我把这些问题连同对应答案一起做成种子评测集先按这个集优化检索参数再开放给全员使用。第二个问题是长尾问题的回答质量不可控。知识问答这类场景天然符合“二八定律”——20%的问题占80%的访问量那些长尾问题虽然出现频率低但一旦答错用户感知反而更强烈。我的应对思路不是去追求长尾全部答对而是在回复页面显眼位置附上“参考文档链接”让用户自己可以追根溯源。这个办法把“答得不对”的负面体验转化为“至少给了出处”的可信体验整体反馈好了很多。第三个问题有趣也典型用户提问的方式越来越口语化、碎片化。比如“年假没休咋办”“笔记本蓝屏找谁”这类输入直接检索的效果并不好。后来我在检索前加了一层轻量改写模块先把口语化问题转成更正式的检索式表达比如“未休年假如何处理”“笔记本蓝屏的报修联系人”检索命中率立刻提升了两成。这个模块本身也是一个小的AI模型但它不需要很强大够用就好。6. 测试与质量保障AI项目的“安全带”怎么系6.1 为什么传统的单元测试在AI面前不够用从事AI工程之后我越来越觉得“测试”这个词在传统软件和AI项目里有完全不同的内涵。传统软件的单元测试可以断言“输入X必定输出Y”AI项目做不到这种确定性。但这不等于AI项目不需要测试恰恰相反AI项目需要的是更细颗粒度、更多层级的测试体系。我的测试体系现在分成五层。第一层是数据测试检查输入数据是否符合Schema、是否包含异常值、是否超出长度限制。第二层是协议测试验证模型服务对外暴露的API接口是否按约定响应这层跟传统接口测试差不多。第三层是行为测试把预先定义好的离线评测集跑一遍评分并和上一次结果对比。第四层是回归测试检查新增功能是否破坏了原有场景的效果。第五层是线上监控实时统计延迟、无答案率、点踩率等业务指标并设置告警阈值。五层各司其职才能让AI系统在“没有标准答案”的前提下仍然具备工程可信度。6.2 评测集建设与持续回归的实操建议评测集的建设和维护是被低估得最严重的工作我甚至认为它就是AI工程的核心资产。一个优秀的评测集要满足三个条件场景覆盖全、判定标准清、更新节奏稳。场景覆盖方面我会按业务维度如入职、薪酬、报销、IT支持和技术维度如简单问答、多轮追问、否定表达、敏感话题交叉构建。判定标准方面每一道评测题都要写好参考回答和评分维度比如“是否包含正确的政策条文”“是否给出了操作步骤”“表达是否清晰易懂”用多个维度打分而不是简单二分对错。更新节奏方面评测集必须持续扩充每次从线上日志中挑出代表性的失败案例加入测试集确保模型在“反反复复的考试”中不断进步。实际操作中我把这套逻辑做成了一个小型的自动化流水线每次模型更新或Prompt调整后自动触发评测任务输出各场景得分对比报告满分100分得分下降超过5分的场景就要人工介入分析。这套机制让团队内部有了一个统一的“好不好”的定义避免了讨论问题时的主观争论。6.3 常见故障模式与排查路径速查最后整理一个我自己踩过、也看别人踩过的故障清单以表格形式放在这里日常排查时对照着看就行。故障现象可能原因排查思路回答质量突然下降上游检索召回变差、Prompt被改动、模型服务版本切换检查检索日志与召回文档对比最近一次评测集分数变化响应延迟明显升高并发量增长、上下文过长、模型量化配置失效看服务监控中的Token数与排队数考虑缓存或升级推理硬件内容存在明显违规模糊表述输入侧过滤失效、系统提示词被覆盖检查输入过滤规则的完整性验证系统提示词是否被用户输入干扰频繁回答“不知道”检索召回率低、置信度阈值设太高调大Top-K候选数量降低阈值并增加人工抽检频次输出格式频繁不符合预期模型版本不稳定、输出Schema校验缺失增加输出校验与自动重试在Prompt中给出格式示例这几类问题在AI项目里几乎是必然出现的区别只在于你是提前做了防御还是事后亡羊补牢。我特别想强调“输出Schema校验”这件事——传统工程师不习惯对模型输出做强约束但我测试下来一份严格的Schema声明配合重试机制能把格式性错误率降到几乎为零这也算是成本最低的护城河之一。7. 从零开始的扩展思考下一步能往哪里走这套从零搭建的AI工程体系跑通之后我自己的体会是初期的“从零”并不在于某一次技术攻关而在于思维方式的切换。你从“写代码实现功能”转变为“构建一个能持续演进的概率系统”这个切换完成之后后续所有工作都会自然归位。下一步可以从几个方向继续延伸。第一个方向是把这个体系复用到更多业务场景关键是沉淀一套可迁移的模板数据管道模板、评测集模板、护栏策略模板让新的项目不用再从零开始。第二个方向是深入多模型协作与Agent的复杂编排这里可以关注任务拆解、记忆管理和过程追踪以及多Agent之间的冲突消解。第三个方向是把成本治理纳入工程体系用量化、缓存、模型路由等手段让每个请求的成本都透明可控。我个人在这些尝试中最深的感悟是ai-engineering-from-scratch这个题目之所以值得反复琢磨是因为它提醒我们AI时代最稀缺的其实不是“会调模型的人”而是“能把不确定的系统做成可靠工程的人”。如果你也正在从零起步我建议你先不要急着追新模型新框架而是老老实实把数据管道、评估体系和护栏机制这三件基本功打扎实。它们不性感但它们是让AI项目真正活下去的底座。