1. 为什么要写从零开始学AI工程这件事先交代一下背景。我这里说的AI工程不是算法研究员天天调模型、推公式那条路而是指把AI能力真正落到产品、落到业务里的那套工程实践。包括怎么接大模型API、怎么做Prompt工程、怎么搭RAG检索增强生成流水线、怎么处理模型输出的稳定性、怎么做评估、怎么上线监控这些东西。过去一年多我基本是从零开始摸这条路的。之前做的是传统后端开发对机器学习的认知停留在梯度下降是啥的水平。因为业务需要硬着头皮开始搞AI应用踩了一堆坑也沉淀了一些自己的方法论。这篇文章不聊学术不聊论文只聊我实际做过的、验证过的东西尽量讲清楚每一步为什么这么做以及我在实操中遇到的真实问题。2. 动手之前必须先想清楚的事2.1 先搞明白AI工程和算法是两码事很多刚接触的人会把AI工程和算法混为一谈这其实是第一个认知误区。算法岗专注的是模型本身——训练一个更好的模型提升benchmark上的指标。AI工程则完全不同它关注的是怎么把一个已有的模型能力稳定地用起来。包括接口怎么封装、请求怎么调度、异常怎么处理、成本怎么控制、结果怎么评估。你可以把算法理解成发动机的研发工程则是整车制造。没有发动机车跑不了但有了发动机离一台能上路跑的车还差着十万八千里。从工程角度看大模型API的调用本质上就是一个分布式系统的外部依赖。它响应慢、偶尔超时、输出不稳定、还会因为token长度限制出各种幺蛾子。工程要做的事情就是把这些不稳定因素消化掉让上层业务稳定运转。所以我的第一个建议是别急着写代码先把自己从调API的码农提升到设计AI系统的工程师这个视角否则后面会处处被动。2.2 使用场景的选择决定了整个技术栈走向做AI应用最早要回答的问题是你的场景到底是什么这个问题如果回答不清楚后面所有的技术选型都是空中楼阁。我根据自己踩过的坑和经验把常见场景分成了这么几类每一类的技术侧重点完全不一样开放问答型用户随便问模型直接答。这类最简单Prompt写好就完事主要精力在提示词调优和输出格式化上。知识库问答型用户问题需要基于特定文档来回答。这就必须上RAG要处理文档解析、切片、向量化、检索、重排这一整条链路。结构化抽取型从非结构化文本里抽关键字段。这类对输出的稳定性要求极高需要严格的schema约束和校验机制。Agent任务型模型需要调用工具、串联多步操作。这是目前复杂度最高的场景涉及规划、工具调用、状态管理、自我纠错等一堆问题。内容生成型文案、代码、报告等生成类需求。这类重点在质量控制、人审机制和批量任务的稳定性。实际做的时候一个系统里往往会混着好几种场景。我的建议是心里始终要有这张分类表遇到具体需求先判断它属于哪一类再决定技术方案的复杂度和节奏。很多人一上来就上最重的架构结果一个简单问答需求搞了三四个服务运维成本和延迟全上来了完全没必要。2.3 预算和延迟的硬约束必须在第一天就明确这两个指标看似是老生常谈但实际项目里特别容易被忽略。尤其是刚接触AI时很容易被效果吸引完全忘了算成本。以我用过的GPT-4级别模型为例一次普通对话调用可能消耗2000到4000个token单价虽然不高但一旦进入生产环境、日调用量上万一个月下来成本就很可观了。我见过不止一个团队Demo阶段效果惊艳一上线跑真实流量账单直接爆掉。延迟方面大模型调用动辄两三秒甚至更久和传统接口几十毫秒的响应完全是两个量级。如果你是做客服机器人用户等三秒可以接受但如果你在用户点击按钮的即时反馈链路里用了大模型那基本就是产品事故。所以动手之前把吞吐量、可用性、响应时间这些指标列清楚和业务方达成共识后面技术选型就不会左右摇摆。3. 从零搭AI应用的技术选型思路3.1 别急着上框架先用最笨的方式跑通现在社区里AI开发框架非常多有帮你编排Prompt的有帮你管Agent的有帮你做RAG的各有各的生态。但我的建议很明确第一次做别上来就套框架先用原生的方式把逻辑跑通。以我当时做的一个知识库问答系统为例。最早版本一共就三个模块一个负责读文档和切片一个负责调向量库做召回一个负责拼Prompt调模型。全部代码加起来几百行逻辑清晰出问题也容易定位。跑通之后再来看框架能解决什么问题比如某框架自带了检索的封装、多轮对话历史的管理、插件的机制这时候用了才理解它的设计意图也才知道哪些地方需要自己扩展。先裸写还有一个附加好处你对每一步的耗时和token消耗心里有数。框架往往会封装掉这些细节造成一种一切都很顺利的错觉一旦性能出问题排查起来就像无头苍蝇。3.2 我折腾过的技术组合与真实对比这里把我自己实际对比过的一些技术栈选择列出来供参考。不捧不踩都是我的真实体感层面我试过的方案实际感受大模型APIGPT-4级别闭源、开源可私有化部署闭源版本效果稳、省心但成本高开源版本自由度大、能私有化但对工程能力要求高向量库专门的向量数据库、传统数据库加向量插件小规模用传统库加插件足够数据量大、检索复杂度高再考虑专用方案Embedding模型闭源Embedding API、开源Embedding模型闭源API省事开源模型需要自己处理部署和归一化但长尾调优空间更大编排方式原生代码硬编、轻量框架小项目硬编最稳需要多工具调度、复杂状态时再上轻量框架前端展示服务端渲染页面、前后端分离看团队配置没有标准答案这个表不是给你照抄的而是想说选型和你的数据量、团队能力、预算强相关。你今天看到的推荐方案换个场景可能就是反面教材。3.3 自己部署开源模型遇到的现实问题有一段时间我很执着于自己部署开源模型觉得可控又省钱。真做下来才意识到私有化部署的成本大头在人力、GPU资源和工程调优。模型推理需要GPUGPU很贵而且一个模型部署上去吞吐量和响应速度要压测、要调参。上下文长度受压显存限制并发一高可能直接OOM。我的亲身经历是把开源模型拉起来跑Demo很快但让它稳定扛住生产流量比直接调API复杂了不止一个量级。如果你的场景有明确的数据合规要求必须私有化部署那这条路没得选。但我建议你把这块当作一个长期投入来做而不是因为这个模型免费就选它。因为真正的成本是运营一个推理集群不是下载那个模型权重。4. RAG系统从原理到踩坑的完整记录4.1 RAG为什么能解决模型不知道的事大模型的知识截止到训练数据那一天而且它本质是续写概率不是查档案。指望它准确回答你私有文档里的细节基本不可能。RAG的思路很朴素你不是不知道吗我把答案相关的段落先找出来塞进你的上下文里你再基于这些材料回答。用大白话说就是开卷考试——模型拿到的不是整个图书馆而是和问题最相关的几页书。这个思路听着简单做起来全是细节。整个链路分五步文档清洗与解析、切片策略、向量化、检索召回、答案生成。每一步都有很多可以调的地方后面的坑大多出现在这些环节的连接处。4.2 两步最关键的优化切片和召回先讲切片。我在早期对切片很不以为然觉得不就是按长度切吗后来被现实教训了。比如一份HR制度文档前几行是总则和说明后面是各个条款。如果按固定400字硬切一个条款就可能被拦腰截断检索时只能召回半个条款模型看到的内容不完整答非所问就顺理成章了。我后来总结出的切片思路按优先级是这样优先按文档的语义结构切比如Markdown标题、列表项、表格其次按段落切一段就是一个切片再不行按固定长度切但要有重叠。文字嵌入模型的表征能力也是有极限的一个切片塞太多内容向量会变得四不像检索时哪边都沾不上。经验值上一个切片控制在200到500字之间比较稳妥太短则上下文不足太长则主题模糊。另外切片之间让相邻区间保持少量重叠能降低切在语义边界上的风险。再讲召回。召回阶段考验的其实是一个经典矛盾查得准还是查得全。我用过单独的语义相似度召回也用过关键词召回加语义召回混合的方案。实际体感是语义召回擅长意思接近但用词不同的情况关键词召回擅长专有名词精确匹配的情况两者真的需要配合使用。另一个好用的招是召回后加一个重排阶段先把候选扩大比如Top20再让重排模型或更精细的规则挑出Top5准确率会明显提升。4.3 回答质量不稳先怀疑这三个环节如果RAG出来的回答不准我的排查顺序通常是这样先看召回有没有召回正确内容。如果正确段落根本没进上下文后面再怎么调Prompt都白搭。再看切片的完整性。如果上下文里只有半截内容模型再聪明也补不出准确答案。最后才看生成环节。确认材料是对的之后再调Prompt约束只能依据材料回答不要脑补这类规则。这三步看起来很简单但我吃过亏有一次系统效果差我对着Prompt调了三天最后发现问题是Embedding模型在升级时被换掉了向量没重新算旧数据和新向量空间对不上。所以请记住RAG的每一层都要加日志和观测不然问题出在哪一层根本无从判断。5. Prompt工程不是玄学是可以被系统化的5.1 一个能应对大部分场景的Prompt骨架做Prompt工程网上有各种花哨的技巧什么角色扮演、思维链、小样本示例都有用但最稳定的还是结构化的组织方式。我长期实践下来一个靠谱的Prompt骨架长这样角色设定告诉模型你是什么人明确专业背景和回答风格任务描述一句话说清要做什么输入内容把用户的问题、原始文本、检索到的材料放进来输出约束规定格式、长度、语气、不知道时该怎么办上下文与示例给一两个好的输入输出样例比抽象描述有效得多。这五部分用一种约定好的分隔符间隔开解析稳定模型也不容易混。核心是约束要具体到可验证。你说请简洁回答模型不知道该多简洁你说不超过100字它就比较听话。你说不要瞎编不如说如果材料里没有相关信息直接回复根据现有资料无法回答。约束越接近机器的执行标准输出越可控。5.2 思维链和Few-shot什么时候用什么时候别用思维链的本质是让模型在给出答案前先把推理过程写出来。对数学题、逻辑推理类的任务确实管用。但代价是token消耗变多、响应变慢。如果你的任务是从合同里抽一个日期完全不需要思维链。Few-shot示例也是一样。好的示例能显著提升稳定性和格式正确率尤其是涉及风格模仿时。但示例塞多了输入变长成本变高还可能把模型带偏。我记得有一次给模型看了一堆拒绝回答类的示例它后来遇到正常问题也开始拒答了——示例的负面倾向会被模型学走。所以Prompt调优有一个基本原则做最小必要修改。一次只改一个变量观察效果再动下一个。不要一次改五个地方那样你根本分不清是哪个改动起了作用。5.3 实际项目中我对Prompt迭代的记录方式Prompt是要被当作代码来管理的。我在项目的prompts/目录下维护了所有模板用git管理版本。每次改动都记住原因、日期和效果。调优时准备一组固定的评测问题集大概二十到五十条覆盖边界情况。每次改完Prompt用这组问题回归一遍效果不降才算通过。这个习惯帮了我大忙。有一次同事随手改了几个字线上效果下降凭着git历史直接还原。另一次我准备扩展新的支持文档类型先往评测集里加了几条对应题目跑完才发现当前Prompt根本hold不住避免了上线事故。6. Agent开发被低估的复杂度和失控风险6.1 Agent不是调个模型让它自己干Agent是这两年的热词很多人一听就兴奋觉得以后系统能自己拆任务、自己干活了。但真上手做过的都知道Agent工程的核心其实不是模型是边界和控制。模型负责做规划和生成但工程要解决的是规划错了怎么办、工具调用失败怎么办、陷入死循环怎么办、用户的敏感操作要不要经过确认。简单流程型Agent做一个Demo很容易。难点在开放式任务上比如帮我处理这堆文件模型可能自己拆出十几个步骤大部分步骤你根本没有对应的工具。这时候如果你不做拦截和限制它会假装成功告诉你处理完了实际上什么都没发生。6.2 先搭一个流程型Agent别碰自主型Agent我建议第一次做Agent老老实实做一个固定流程版本用户请求进来第一步先判断是哪个类别的任务第二步按类别路由到对应的处理链第三步每条链有明确的工具调用顺序第四步在关键节点设置检查点。看起来不够炫但稳定。我自己的第一个能上线的Agent本质上就是一个加了动态参数抽取的多路由系统。它收到用户请求先用模型抽取关键参数再根据参数类型走不同的模板和工具回头验证结果后再返回。这个模式对内部工单分类、简单审批这些场景已经足够好用了。6.3 工具调用的错误处理与安全边界工具调用有两大坑格式不稳定和参数幻觉。格式不稳定是指模型偶尔输出不合法的JSON或错误函数名处理方式是解析失败就重试一次——我实践中重试能解决大半的偶发问题。参数幻觉就是模型会自己编一个不存在的参数值塞进去尤其是日期、ID这类字段。防御办法是在工具执行前做参数校验基本类型、取值范围、枚举值都得检查不合格就回退让用户确认或拒绝执行。安全边界是另一道必须守住的线。任何有真实副作用的操作比如发邮件、改数据、删文件都必须走人工确认。不要相信模型对这个操作是否安全的判断。我给自己的系统定了一条铁律有副作用的操作一律两段式执行先出你确定要做吗用户确认再真正执行。7. 评估和上线AI应用的生命线7.1 为什么AI应用必须有自己的评测集没有评测集AI应用就是摸着石头过河甚至不知道自己在往哪个方向走。传统软件有明确的单测用例输入输出可预期。而大模型应用是概率性的同一个Prompt、同一个问题两次回答可能不一样。所以要把评测集当作单测的替代物来建设给改动加一道网。我用过商用平台去做AI评估也用过自己写脚本跑评测。有些平台有现成的评测集管理和打分能力我在一些内部场景也搭建过一套基础的离线评测线上监控体系。不管怎么做核心思路是把回答效果这个模糊的东西拆成一个可打分的列表让每一次改动都有数据说变好了还是变差了。7.2 离线和线上两层评估缺一不可离线评估解决的是改版有没有变差线上监控解决的是生产环境有没有出事故。离线评测集我保留了几十道典型题目每次Prompt或链路改动跑一遍评测记录分数和典型badcase。线上监控则包括这几个关键指标调用成功率与超时率接口稳定性的基本盘平均响应时长判断服务是否健康Token消耗费用防止成本跑飞用户显式反馈比如点踩、改答案之类的数据兜底回复率无法回答或未知这类回复的占比。这两层评估我都踩过坑。最早我只有线上监控没有离线评测导致改了一版Prompt看监控指标没怎么变以为没问题后来发现几个经典问题答案悄悄变差。后来加上离线评测才把这种回归堵住。7.3 用户反馈闭环和Badcase复盘方法线上监控只告诉你有问题用户反馈才告诉你哪有问题。我给系统加了一个很简单的反馈通道每次回答下面带上赞和踩按钮用户踩了以后可以写下期望答案。积累一段时间这些badcase就是最有价值的数据。复盘Badcase的时候我总是先问三个问题是检索没召回还是Prompt约束不够还是模型能力边界限制定位到具体环节后再想是改切片、改召回规则、补示例还是调参数。一次改动针对一类问题改完拿badcase集合回归验证。这个循环跑起来以后系统的质量提升才变得可追踪。8. 线上稳定性建设AI应用最容易翻车的战场8.1 大模型API的限流、超时和重试策略把大模型当普通HTTP服务会非常痛苦。因为它的响应时间方差太大偶尔一次调用十秒往上也正常。最开始我就是简单设置超时重试结果在高峰期接口不稳定时无限重试把服务打崩了还多烧了不少token费用。后来我总结出的策略是超时时间要分场景普通问答短一点长文本生成则设得更宽裕重试只做有限次并且加退避不要第一秒没响应就连着重试三次对主流厂商的API限流要有预期设计两级限流——应用层限流和API调用层限流关键链路要加熔断连续失败就暂时降级比如返回缓存结果或提示稍后再试。成本控制同样重要。我给每个请求都记录了model、token数、耗时每天一汇总谁烧了多少一目了然。有一次排查发现某个测试脚本每小时调用几千次就是因为忘了加缓存和频控。8.2 模型输出安全就别全指望提示词要上规则提示词可以要求模型不要泄露系统指令不要说违规内容但它本质上只是引导不是保证。我做线上审核的时候关键胜出方案是在模型输出后面再加一层规则校验和敏感信息过滤。具体来说会检测明显的敏感词、个人身份信息、联系方式这类内容命中就不展示还会用正则去校验输出格式不符合就重新生成或走兜底。另外对系统指令的保护我会在Prompt里明确要求不允许在回复中重复指令内容但更重要的是不要在前端展示原始的完整Prompt把内部指令和用户可见内容隔离安全系数会高很多。8.3 可观测性给每次AI调用做飞行记录大模型应用Debug最大的障碍是黑盒。为了排查问题我养成了一个习惯给每次调用都打日志。包括输入的原始请求、最终拼给模型的Prompt这个很关键、模型返回的原始内容、做了哪些后处理、最终用户看到的内容、还有耗时和token数。这些数据一开始没人要求我打纯粹是Debug时实在受不了猜谜了才加上的。有了这些日志以后用户说你这回答不对我能立刻定位到那一轮调用看是检索阶段有问题还是生成阶段跑偏。没有这个习惯任何一个线上AI问题都只能靠猜而靠猜解决问题是最低效的方式。9. 如果从零再来一次我会怎么做走到今天如果再重新来一次我会把路径压缩得更有效。第一先选一个业务理解最深的场景用最笨的方式把最小闭环跑通最多两周时间。第二尽早建立评测集日志的基础设施哪怕只是本地的几十条测试和一套日志打印。第三AI工程大部分时间不是在和模型较劲而是在和数据的质量、延迟、成本、边界较劲别把精力都耗在花哨的效果优化上。最后分享一个小技巧从零开始学AI工程一定要给自己定一个上线的deadline。没有截止日期的学习会永远停留在看文档和调Demo的阶段。只有真的跑了生产流量你才会被迫面对超时、限流、token成本、badcase这些真实问题。而解决好这些真实问题才是AI工程能力的真正增长点。