其实最开始接触ai-engineering这个词的时候我是有点心虚的。从传统后端开发转过来头三个月我几乎每天都在自我怀疑。不是说模型跑不通而是跑通了一个Demo到上线一个稳定的服务之间的距离远比我以为的大得多。市面上讲Prompt技巧、讲LangChain用法的文章遍地都是可真到了要独立负责一个AI项目从零到一落地的时候你会发现光是环境依赖、数据清洗、评测方案、服务部署这几件事就能把热情消磨掉一半。ai-engineering-from-scratch这个标题其实就是我自己这段经历的浓缩——把AI工程从零开始需要跨过的关键节点串起来。这篇文章不打算讲某个具体框架的API怎么调那是官方文档就能解决的事。我想聊的是另一个更关键的问题从一个只会写普通软件的人到一个能独立交付AI项目的人中间到底隔着哪些硬功夫。如果你正准备入坑或者已经在坑里被折腾得怀疑人生这篇文章应该能帮你把路线理清楚。1. 先想明白AI工程不是调接口是系统设计1.1 我第一次搞砸的AI项目刚接触大模型那会儿我接了一个内部知识库问答的活儿。当时觉得简单极了——文档导进去调一下嵌入模型再套个Prompt让大模型回答这事儿就齐了。结果真做起来先是文档格式五花八门PDF里还有扫描件嵌入之后召回的效果差得离谱问报销流程能召回一堆无关的规章制度更麻烦的是用户一旦问出训练数据里没有的东西模型就开始一本正经地胡说八道。那段时间我意识到一个残酷的事实把模型跑起来是五分钟的事把产品做出来是两个月的事。AI工程的重点从来不在模型本身而在围绕模型搭起来的那一圈基础设施——数据怎么进来、怎么存、怎么检索、怎么评测、怎么兜底、怎么监控。这一圈东西才是真正决定项目成败的地方。我后面所有踩过的坑基本都可以归结为基础设施没搭好。1.2 AI工程的本质最后一公里的系统性问题有人这么调侃AI工程师不就是API调用工程师吗这话有失偏颇但也确实戳中了一个现象很多人做完Demo就停在原地了。因为Demo只需要证明模型能做到而工程需要保证系统在真实环境里稳定做到。这两者之间隔着数据管道、缓存策略、异常处理、权限控制、日志追踪、效果评估这一整套东西。用一个生活化的类比模型就像一位刚毕业的高材生能力强但经验少AI工程要做的是给这位高材生配好办公桌、整理好资料库、装好协作工具再制定一套考核标准确保他来上班的每一天都能稳定产出。你会发现这套配套设施需要投入的心力一点不比招一个人少。这也是为什么很多团队把AI工程单独拎出来作为一个方向——它的方法论和传统后端有交集但又有明显不同。2. 从零起步的四阶段路线图每一步该怎么走在展开之前先把四个阶段的要点表格化方便你对照着规划时间。阶段核心目标主要产出预计投入一Python与数据处理能独立处理万行级真实数据清洗好的数据集、常用处理脚本2-4周二机器学习基础理解训练、评估、调参的基本逻辑一个完整跑通的分类实验2-3周三大模型应用开发掌握Prompt、RAG、Agent三种能力一个能回答问题的Demo4-6周四工程化让服务稳定跑在线上可部署、可监控、可评测的系统持续进行2.1 阶段一Python基本功与数据手感如果完全零基础第一件事不是去学Transformer而是把Python练到手熟。我说的手熟不是会写for循环而是能熟练处理数据用Pandas做清洗、用Requests调接口、用正则做文本抽取、用Jupyter Notebook做探索性分析。AI项目里的脏活累活90%都耗在这些事情上。基本功扎实的人后面才有余力处理模型层面的问题。我当时给自己定的标准是拿到一万条乱七八糟的文本数据能在半天之内整理成规范的表格并且写清楚每个字段的含义。这个标准不算高但它逼着你把Pandas、正则、编码处理这些工具练到位。中文数据尤其要注意编码问题GBK和UTF-8之间的坑踩一次才长记性。没有这个过程直接去撸大模型之后会被数据问题反复暴击。2.2 阶段二机器学习基础概念够用就好补课法这里不建议系统刷完一整本《统计学习方法》再开工那是科班的路子。工程向的学习是够用就好用了再补。真正需要理解的关键概念其实不多损失函数是怎么回事、过拟合和欠拟合长什么样、训练集验证集测试集各自的作用、精确率和召回率分别意味着什么。这些概念光看理论容易懵最快的办法是找一个小型经典数据集用Scikit-learn从头到尾跑一遍分类任务训练、评估、调参、看混淆矩阵。这个过程走下来你对模型怎么学出来的指标怎么算出来的就有了直观体感。之后再接触大模型理解困惑度、幻觉率这类概念就顺理成章了。顺便说一句网上的入门级机器学习项目虽然被说烂了但作为第一个完整跑通的机器学习流程依然值得做。2.3 阶段三大模型应用开发的三个抓手大模型应用开发的核心技能我个人的体会是三个Prompt工程、检索增强生成RAG、Agent编排。Prompt工程不是背模板而是学会用提问方式控制模型的思考路径。比如让模型做分类不要只说请分类而是给出明确的分类标准、边界情况处理规则、输出格式要求。多拆几步、多给例子效果立刻不一样。我见过一个团队改了一版Prompt把分类任务准确率从82%拉到了94%改的只是把如果遇到不确定的情况这条规则写得更具体。RAG解决的是模型不知道的事。把私有知识库的内容切成块、做向量化、存进向量数据库用户提问时先检索相关片段再拼进Prompt交给模型。RAG的关键在于理解召回质量决定生成质量这条铁律这个主题我后面会专门展开聊。Agent编排则是把大模型从回答问题升级为完成任务让它自己规划步骤、调用工具、观察结果、修正行动。入门不难难的是一直不好用还找不到原因——Agent的不可控性是这个领域最经典的劝退点。建议新手先老老实实把Prompt和RAG吃透再碰Agent。2.4 阶段四工程化必修课不能跳过前三个阶段解决让模型跑出结果阶段四解决让结果稳定跑在线上。这里的必修课包括用FastAPI或Flask封装API服务、用Docker打包部署镜像、用结构化日志记录请求链路、做好依赖管理和版本控制。这些是传统软件工程的老本行但很多半路出家做AI的人容易忽略。我的建议是哪怕只是做一个练手项目也按生产标准来写单元测试、做规范的Git提交、给接口设计重试和熔断机制。习惯这些流程之后真正上生产才不会手忙脚乱。你想啊一个连异常重试都没做的AI服务模型一抖动用户看到的就是白屏和报错前一秒的智能感瞬间归零。3. 一个文档问答系统的全程拆解从需求到上线3.1 需求定义别急着上技术先界定能用我做那个文档问答系统时前期最大的失误就是没把需求界定清楚。后来重新做需求分析给自己列了三个问题用户是谁他们会怎么提问哪些问题必须答对哪些问题可以容忍答错系统应该在多快的时间内给出答案这三个问题直接决定技术选型。第一个问题决定要不要做多轮对话和意图识别第二个问题决定评测标准怎么定比如医疗类的知识库答案错了可能出大事而行政类的问题答错了影响就小得多第三个问题决定用什么规模的模型、要不要加缓存。想清楚这三点再看技术你会发现选择清晰了很多连模型选型都有了依据。3.2 技术架构一个最小可用系统是怎么搭起来的整套系统的架构说复杂也复杂说简单也就五六个组件文档解析模块、切分与向量化模块、向量数据库、检索模块、Prompt构造模块、模型调用模块外加一个日志与评测模块。文档解析是第一个坑。PDF、Word、Markdown、扫描件各有各的脾气有些字体提取出来乱码有些表格解析出来完全变形。我后来采用的方案是能拿到源文件就用源文件PDF优先走版面分析工具而不是直接做文本抽取纯图片型PDF单独走OCR流程。这些细节处理不干净上游一点脏下游全白干。向量化的时候嵌入模型的选择比想象中重要。针对中文场景优化的开源嵌入模型在中文语料上的表现普遍好于通用英文模型。我当时对比了三四个最终选了一个对中文长文本支持更好的召回率直接提升了接近十个百分点。这个提升完全不需要调整什么复杂的参数只靠换模型就拿到了性价比极高。检索模块里加了两个小优化一个是查询改写用户的问题会先做一次摘要和关键词抽取再拿这些信息去检索命中率明显更高另一个是重排序初筛召回Top 50之后再用重排序模型挑出最相关的Top 5给大模型。两步加起来的延迟增加不到两百毫秒但回答质量提升了一个档次。3.3 上线部署从Demo到服务之间的一地鸡毛部署阶段的问题同样不少。模型推理服务的内存和显存要单独规划接口要做超时和限流数据更新之后索引怎么平滑重建这些都是在本地跑Demo时完全碰不到的问题。我当时的解决方案是模型推理单独起一个服务用FastAPI封装前面加一层缓存相同的提问直接命中缓存、不重复推理成本和延迟都省了一截业务逻辑和检索逻辑放在另一个服务里两个服务用Docker Compose统一编排。数据更新的时候先构建新索引再切换流量避免查询期间重建索引造成的抖动。这套方案不算高级但对于中小规模的内部系统完全够用。我也见过小团队一上来就上Kubernetes的结果运维成本直接被拉爆几个人天天折腾集群反而没时间优化业务效果。工具永远是工具合适才最重要。4. 工程化必须跨过的四道坎每一道都能劝退一半人4.1 第一道坎RAG召回质量怎么保证RAG项目最让人头疼的问题是答非所问。核心原因大多出在召回环节。文档切得太碎语义链条断了模型拿到的是不完整的上下文切得太粗向量检索的命中率低相关片段被淹没在无关内容里。我踩出来的经验是这么几条优先按标题层级切分而不是按固定字数硬切。相邻段落保留20%左右的重叠避免切在句子中间。切完后的每个片段都保留原始文档的标题路径作为元数据。对条款类、FAQ类内容优先用关键词检索纯向量检索在这些场景反而没那么可靠。另一个容易被忽略的点是查后过滤。向量检索召回Top N之后可以再做一轮相关性阈值过滤低于阈值的内容直接丢弃宁可不答也不要硬答。这一步能显著减少幻觉代价只是多写十几行代码属于我强烈建议加上的兜底逻辑。4.2 第二道坎Agent的边界到底在哪让大模型自己去调工具、做规划听起来很酷真上线之后你会发现失控才是常态。我见过一个Agent任务模型为了查一个数据自己写了一个死循环式的工具调用直接把接口配额烧光了。也见过模型在用户没有询问的情况下擅自调用了写操作工具幸好测试环境没有真实数据不然后果不堪设想。所以我现在的态度是能不用Agent就不用一定要用就严格设边界。首先把Agent能调用的工具数量控制在三五个以内工具越少模型决策越稳定。其次给每个工具写清楚描述让模型明白该在什么场景下调用、不该在什么场景下调用。再者硬性设置最大调用次数和总超时时间防止死循环。最重要的一点任何Agent系统都必须有兜底回复模型判断不了的时候明确说不知道而不是编一个答案。Agent的聪明是模型的功劳Agent的听话才是你的工程能力。4.3 第三道坎评测体系怎么搭不评测你根本不知道改完的系统是变好了还是变差了。大模型应用的评测比传统软件复杂因为它的输出没有一个唯一的正确答案。我建议从两个层面来搭。第一层是自动化评测。准备一组覆盖典型场景的测试用例每个用例记录模型输出再对输出做规则判断或模型打分。分类、抽取类任务可以用裁判模型打分生成类任务可以计算语义相似度。自动化评测跑不了全部问题但能把大多数明显回归抓住每次改完Prompt或检索逻辑先跑一遍自动化用例集心里大概就有数了。第二层是人工评测。每周抽出一部分真实用户反馈按照答对、部分答对、答错、幻觉四个等级人工标注。人工评测虽然慢但最可靠。很多自动化评测发现不了的语义问题人工一眼就能看出来尤其是那种每句话都对合起来是废话的经典毛病只有人工评测能抓到。评测这件事我建议越早搭越好别等到上线才补。没有评测体系就迭代就像蒙着眼睛开车撞了才知道错。4.4 第四道坎成本与性能的平衡大模型API按Token计费不控制成本的话一个不起眼的小项目一个月也能烧掉几千块。我的经验是几个方向叠加着省高频问题加缓存每命中一次就是省下一次全额调用简单任务用小模型开箱即用不心疼长文本先做摘要再让大模型基于摘要回答Token量和延迟双降批量任务走异步队列不要在实时推理里扛客流高峰。性能方面最大杠杆在减少模型调用次数而不是优化单次调用速度。一次回答需要三次串行调用大模型整体延迟再优化也快不到哪去反过来把三次调用合并成一次或两次效果立竿见影。你可以在调用链路里加一个日志埋点统计每次请求总共调了几次模型、每步耗时多少优化起来一目了然。这个埋点看着土但绝对是我做过最值回票价的优化手段。5. 如果你也想从零学起几个掏心窝的建议5.1 资源怎么选别让收藏夹吃灰网上AI学习资源多到爆炸大多数人缺的从来不是资料而是做完一个项目的闭环体验。我推荐的做法是官方文档优先于二手教程动手实践优先于收藏视频一个项目做深做透优先于十个项目浅尝辄止。我见过太多人花两周看直播课、刷了三个月视频最后连一个能跑的Python脚本都没写出来。你不需要等自己准备好再动手直接选一个身边最具体的问题——比如帮我总结邮件帮我把会议录音转成纪要——试着用AI技术把它落地。哪怕做得丑、做得糙只要你完整走完这个闭环收获就已经超过了90%的收藏党。5.2 做项目的正确姿势先小后大先丑后美最后聊聊做项目的节奏。很多人一上手就想做一个全自动、多Agent、能自主决策的系统我劝你冷静。我把自己的经验总结成一句话第一次动手就做文档问答或者数据抽取这类边界清晰的小项目。第一版别追求完美先把一条最简路径打通文档放进去问题能答出来哪怕答得一般都算成功。第二版再优化召回、增加评测、改进Prompt。第三版再考虑缓存、监控、部署。每一步都能看到可衡量的改善这个正反馈会让你坚持下去。反过来一上来就搞复杂架构大概率会在某个凌晨面对一屏报错把热情全部消耗完。还有一点是关于心态的。AI工程领域知识更新很快今天学的东西可能下个月就换个说法但不必焦虑。工具只是原理的载体你会了向量检索的原理换个向量数据库半天就能上手你理解了RAG的链路不管LangChain还是LlamaIndex都只是不同的封装方式。真正值得投入时间的是那些不变的东西数据处理能力、系统设计能力、评测与迭代的方法论。最后再分享一个我最近一直在用的小习惯每做一个AI项目都写一份踩坑记录记下当时的问题、排查过程、根本原因、解决办法。三个月之后回看你会发现很多当时让你彻夜难眠的坑其实都是同一类问题的变体。这份记录会是你从调接口的人蜕变成做工程的人最好的见证也是我从零走完这条AI工程之路后最想留给后来人的一件东西。