从零开始做AI工程：从RAG到Agent的系统化实战指南

还记得前两年团队招聘的时候简历上写AI工程师的候选人十个里有八个聊下来其实是在调API剩下两个是在跑开源模型的训练脚本。当时我就意识到这个行业缺的从来不是会用某个模型的人而是能把AI真正工程化的人。所谓AI工程不是照着教程跑通一个Demo而是要把模型、数据、评测、部署、监控这套东西当成一个整体系统来设计和维护。这篇文章我想认真聊聊从零开始做AI工程这件事给那些刚入行、或者已经在做AI应用但总觉得自己在野路子上摸索的开发者一些参考。我不会只讲概念会把我在实际项目中验证过的路径、踩过的坑、以及真正重要的取舍都摊开来讲希望能给不同基础的读者一条可以照着走的路。无论你是想转型AI方向的后端工程师还是已经在做Prompt调优但想更进一步这篇文章都适合你。1. 先说清楚AI工程不是调接口也不是写算法1.1 三种角色的边界很多人一开始就没分清我见过太多人把AI工程理解为Prompt写得更好或者模型训练得更准。但这两种理解都只覆盖了AI工程的一小块而且都不是核心。如果非要划一条线我会把行业里的角色粗略分成三类ML工程师机器学习工程师核心是模型本身的训练、微调、性能优化关心Loss曲线、数据集质量、模型精度。AI工程师AI应用工程师核心是把模型嵌入到真实业务系统里关心延迟、成本、稳定性、评测、Agent编排、工具链设计。Prompt工程师核心是设计提示词和交互模板让模型在给定任务上表现更好。你会发现AI工程师是三者里最需要全局视角的角色他不需要亲手训练一个大模型但必须知道模型怎么选、怎么评估、怎么接入、怎么兜底。1.2 AI工程的核心是不确定性管理传统软件工程里函数的输入输出是确定的——我传一个整数进去它一定返回一个整数行为是可预测的。而AI工程面对的模型本质上是一个概率系统同一个Prompt今天答得好明天换一个Embedding模型结果就飘了换一个解码温度结果又变了。所以AI工程的本质工作我总结成一句话在不确定性的基础上搭建确定性的系统。这意味着你要做的不是追求某一次回答完美而是保证一百次里有九十次可用并且那十次不可用的能被系统识别出来、被兜住。这是所有AI工程实践的底层出发点。1.3 一个端到端系统里的隐藏工作很多人做第一个AI项目时以为工作就是调接口拼Prompt。等到真正上线才发现一个能跑的AI系统里模型的调用只占不到一半的工作量。我随便列一下数据的接入、清洗、切块、版本管理评测集的构建和自动化评测流程Prompt模板的版本管理和AB实验模型输出的缓存、限流、熔断设计可观测性Token消耗、延迟、成功率、用户反馈收集安全兜底内容审核、敏感信息过滤、Fallback策略这些工作每一项都不性感但每一项都决定系统能不能从Demo走到生产环境。从零开始学AI工程本质上就是学会把这些杂活系统化。2. 从零开始的三步跳先跑通再拆开最后拼回去2.1 第一步选一个最小闭环项目一年内不用换的那种我建议所有新手从同一个项目开始私有知识库问答RAG。为啥是它因为这个项目具备一个绝佳的最小闭环特征你需要处理数据、做向量化、设计检索、写Prompt、做评测甚至还能延伸到Agent工具调用。它规模不大但五脏俱全是一个可以反复拆解、反复优化的好样本。我在带新人时给的第一课就是不要一上来就搭那种智能客服多个Agent协作自动下单的大系统那是个巨坑。先做一个能回答你公司内部FAQ问题的知识库问答系统跑通它你才算真正入门。具体做法很简单把自己手头最熟悉的文档比如你常看的几十篇技术文档收集起来做切块塞进向量库然后用一个大模型做生成回答。不做任何花哨的设计两三天就能跑通。2.2 第二步把闭环拆成五层搞清楚每一层在干嘛跑通第一个Demo之后立刻做一个动作把它拆开分成五层来看。数据层原始文档从哪来格式有多少种怎么清洗。索引层切块的策略和向量化的模型怎么选。检索层怎么召回、怎么排序召回多少条。生成层Prompt模板、模型参数、历史对话怎么组织。评估层用什么标准判断回答好不好用哪些测试用例。这五层就是整个AI工程的地基框架。后面你做的所有事情无非是在这五层里做加深或者加宽。拆开看的时候你会突然发现很多原来忽略的细节——比如你的切块策略其实影响检索效果你的评测用例根本覆盖不了真实用户的问题。2.3 第三步以工程化标准重新拼装这个阶段通常发生在第一个Demo跑通后的第三到第四周。你要做的不是加更多功能而是把之前能跑的代码升级成能用的系统。我列的改造顺序是这样先做配置化模型的名称、参数、向量库地址、Prompt模板全部外置到配置文件让改一行Prompt不需要改代码。再做缓存层同一问题的答案在24小时内直接命中缓存既省钱又降延迟。然后做评测脚本把测试集变成自动化脚本每次改动模型或Prompt后能快速回归。最后加可观测性把每次请求的Token消耗、检索耗时、生成耗时、用户反馈全部记录下来。走到这一步你已经不是调API的了而是在真的造一个AI系统。这三步走完后面学Agent、学微调、学多模态都会快得多。3. 动手搭环境之前先把这几件事想明白3.1 模型选型的真实成本API与开源部署怎么选我见过不少团队一上来就想部署开源模型觉得私有化部署更安全、不花钱结果折腾一个月GPU集群的账单比API调用费还贵。我给你一个很实际的对比视角维度调用商业API如大模型API私有化部署开源模型初始成本低按量付费高需要GPU服务器技术门槛低接口简单高需要懂推理优化、部署运维数据安全取决于供应商协议数据完全内网迭代速度模型升级由厂商负责换模型版本要自己迁移适合场景MVP验证、中小规模业务数据敏感、规模大、长期成本敏感我的个人建议是第一个项目永远用API跑哪怕你最终目标是私有化也用API先把业务逻辑跑通。因为初期最大的不确定性不是算力而是业务需求和技术路径理解。等你确定这套系统值得投入了再评估要不要迁移到开源模型。3.2 算力预算不需要先买卡很多人听说做AI就得买显卡这是一个巨大的误解。做AI工程和做AI训练是两回事你在99%的时间里需要的算力云服务商按小时租就够了。举个例子我本地开发的时候几乎不跑任何大模型所有的模型调用都走后端API。本地只跑Embedding模型做测试那玩意儿CPU都能跑。真正需要GPU的场景只有两个微调训练和部署开源模型做推理这两个场景都是有明确需要才去做的事。想清楚这一点你从零开始的成本可以控制在非常低的水平——一个月的API调用费加一台普通开发机完全足够你学完整个AI工程的基础路径。3.3 数据优先测试集就是你的项目说明书这是我从零开始做AI工程时学到最重要的一件事测试集比模型更重要。这么说吧你选模型、调Prompt、改检索心里得有杆秤。这杆秤就是一个高质量、覆盖真实场景的测试集。没有测试集你所有的优化都是在撞运气。我会建议项目启动的第一周除了收集业务数据还要花专门的时间去造测试数据。把业务同学常问的问题、论坛里出现过的问题、竞品的产品里用户会问的问题全部整理成几百条QA对。先不急着标准化、打分先把这些QA对按业务模块归类这就已经比90%的团队领先了。有了测试集后面所有的工作都可以变成修改-跑测试-看分数-再修改的循环这跟写单元测试驱动开发是一个道理。4. 一个最小可用的AI工程长什么样以RAG应用为例拆解4.1 数据接入与切块怎么决定chunk大小数据接入听起来很无脑——把文档塞进去不就行了但等你真做起来第一关就会卡住你的文档有的是PDF有的是Word有的是HTML页面有的还有表格格式各不一样。清洗和Parse就够折腾一阵。切块策略就更讲究了。你切得太小每块内容不完整检索时缺少上下文切得太大向量检索的命中率下降而且可能把不相关内容混进上下文。我常用的一个策略是按语义结构切优先用文档本身的段落标题做锚点标题和内容放在一个块里块大小控制在500-1000字左右。如果是代码文档可以按函数或类来切。这里有个很实用的技巧切块的时候给每个块加上来源、标题、序号作为元数据检索阶段就可以用这些元数据过滤。比如用户问的是安装步骤相关问题就直接过滤掉API参考章节的块。4.2 Embedding与向量检索选型与阈值Embedding模型决定了你的检索效果的上限。不同Embedding模型的语义理解能力差异很大不要光看开源排行榜一定要用自己的业务语料去验证。我踩过的一个坑是直接用了一个通用中文Embedding模型结果业务文档里大量出现专业术语的缩写比如CI/CD、CRUD向量检索的Top 10召回结果里有三四个完全不相关。后来换了一个在代码文档上效果更好的模型召回质量明显提升。检索环节还有一个容易被忽略的配置相似度阈值。如果你的业务场景是答不上来也不能瞎答那这个阈值必须调高宁可召回结果为空也别给用户一个错误答案。我的做法是在评测阶段统计正确答案的相似度分布把阈值设在比最差正确答案再低5%的位置。4.3 Prompt模板与生成策略有了检索到的上下文接下来就是把上下文塞给大模型生成回答。这里面有一个非常关键的设计结构化的Prompt模板。你是一个企业内部知识库问答助手。 请根据以下背景资料回答问题。 背景资料 {context} 用户问题 {question} 要求 1. 如果背景资料中没有答案请明确回答未找到相关信息。 2. 回答时优先使用背景资料中的原始表述。 3. 回答结束后列出回答所依据的资料编号。这个模板有三个设计意图第一约束模型不能凭空编造第二强制带依据方便用户追溯第三明确不知道的边界。这些看起来是Prompt技巧其实是不确定性管理的具体落地。哪怕将来换成别的模型模板的这些结构也不需要动。4.4 配置、缓存、可观测性从小就要有的三件事我见过很多Demo代码所有的配置都硬编码在Python文件里后来要改模型名称得改代码重新部署。这种习惯在AI工程里特别致命因为AI系统的实验次数非常多你改Prompt、换模型的速度要比传统开发快得多。所以我建议项目初始就引入一个简单的配置文件哪怕是YAML也行。放什么内容模型名称、模型API地址、API Key、Top P、Temperature、缓存开关、向量库地址、检索TopK、相似度阈值这些都该外置。缓存策略上我的做法是语义缓存把用户问题做Embedding和缓存库里过去24小时的问题做相似度匹配相似度超过0.95就直接用缓存答案。这个策略在高频重复问题的场景特别有效能省下50%以上的Token费。可观测性这块不需要一开始就上重型监控平台先做到每个请求都有结构化日志就够了。日志里存哪些字段问题摘要、检索耗时、生成的Token数、总耗时、模型名称、测试结果ID。有了这些出问题时你才能知道是检索慢了还是生成慢了是模型变了还是Prompt改了。5. 到了Agent阶段工程复杂度会突然翻倍5.1 ReAct循环从一次问答到一个任务当你的系统不满足于回答问题而是需要替用户完成任务时你就进入了Agent阶段。RAG是一次检索然后生成Agent则是一个循环观察输入 → 思考需要工具 → 调用工具 → 拿到结果 → 再次思考 → 直到任务完成。这个循环在工程上就意味着你的系统从单次调用变成多轮调用管理。你需要处理工具调用失败、循环超时、上下文膨胀、错误路径恢复等一系列问题。我给新人的建议是先不要自己手写Agent框架先用LangChain或类似的成熟框架跑通重点理解它的循环机制和各类工具的抽象方式再考虑自己实现。因为Agent的核心难点不在能跑通一次工具调用而在跑十次别出岔子。5.2 工具调用协议先行模型后置很多Agent翻车问题不在模型而在工具定义。模型本身是个意图理解器你给它什么工具Schema它就只能调用什么工具。如果你把工具参数描述写得模棱两可比如query_user_info(user_id: str)模型一定会在参数格式上犹豫不决。正确做法是先定义一套严格的工具协议把参数名称、类型、默认值、取值范围全部写清楚甚至直接依赖框架的JSON Schema机制。比如{ name: query_user_info, description: 根据用户ID查询用户的基本信息包括姓名、部门、职级。, parameters: { type: object, properties: { user_id: { type: string, description: 用户的唯一标识例如 u_12345 } }, required: [user_id] } }一个我反复踩过的坑工具描述里说根据用户ID但没说清楚ID格式模型经常把张三当ID传进去。后来把描述改成根据用户的数字ID如 u_12345查询如果用户提供的是姓名请先调用 search_user 接口获取ID错误率降了一半。工具调用的工程化本质就是把模型的容错边界画清楚。5.3 多Agent协作编排方式与职责边界到了一定规模你会希望系统里有多个各司其职的Agent——一个管知识检索一个管数据分析一个管流程审批。这里最大的工程问题不是让它们各自完成单点任务而是怎么编排它们的协作方式。我比较推荐中心化编排模式有一个调度Agent负责理解用户意图把任务拆解成子任务然后分发给各个专用Agent执行。调度Agent像一个项目经理各专用Agent像执行者。这个模式的好处是职责清楚、出错好定位。中心化编排有一个前提就是调度Agent必须拥有任务完成状态判断的能力。比如子Agent返回了一个查询结果为空调度Agent要能区分这是真的没数据还是子Agent执行失败。这里就需要在子Agent的返回值里带上结构化状态码了而不是一段自然语言描述。6. 我的踩坑清单这几件事没人提醒你6.1 评测数据要自己造不要只靠公开集我一直强调评测集重要但很多人会犯一个懒直接拿公开的评测集比如百科问答类数据集来评估自己的业务系统。结果就是评测分数很高一上线就翻车。为什么因为公开评测集的数据分布跟你的业务差太远。你做一个企业内部知识库问答用户问的是报销流程能线上办理吗公开评测集里哪有这种问题。我的做法是用真实用户的历史问题造评测集哪怕第一版只有一百条也比一万条公开数据有用。具体方法是拉取过去一个月用户在系统里的真实提问人工标注出标准答案和对应资料再按照业务模块抽样平衡做成回归集。以后每次改模型、改Prompt都拿这套回归集来跑。6.2 Embedding模型升级会静默改变结果这是我在一次系统升级中吃到的大亏。当时觉得旧的Embedding模型效果不够好就换了一个更新更强的Embedding模型重新向量化后测了几个测试用例效果确实更好了于是直接上线。结果上线第三天用户开始反馈之前能搜到的东西现在搜不到了。原因很简单换Embedding模型意味着整个向量空间的语义分布变了原来距离近的向量对现在可能变远了而你只测了那十几个用例没有覆盖所有高频问题。从那以后我定了一个规矩换Embedding模型必须全量回归且至少要观察一周的高频问题命中率对比。6.3 别让Token成本失控缓存与合并策略生成式模型按Token计费大模型的成本失控是AI工程里的隐形杀手。我见过一个团队做了一个客服问答系统上线第一个月Token费用超出预算六倍原因就是每次请求都把很大的背景资料塞给模型而且完全没有做缓存。控制成本的有效手段有三个一是之前说的语义缓存系统里至少有60%的问题是可以命中的二是压缩检索上下文给模型的背景资料控制在刚好回答问题的量级不要盲目追求把全部候选塞进去三是用轻量模型做分类和路由只有复杂的、高价值的问题才调用大模型简单问题交给规则或小模型。6.4 可复现性随机种子与版本锁最后一个坑可能只会在你做了几个月之后才会遇到某一天你发现昨天还能复现的测试结果今天变了。一查原因是模型服务的解码参数没有固定或者某个中间依赖偷偷升了版本。AI系统的可复现性比传统软件更难保证我一般这样处理核心模型调用时固定temperature、top_p等采样参数涉及Embedding的依赖库锁版本单独形成一个依赖清单每次测试单独记录模型服务的版本号。养成这个习惯之后你回滚和排查问题的速度能快十倍。我在实际项目中摸索出来的这套从零开始路径不敢说适合所有人但确实帮很多刚开始接触AI工程的人少走了一些弯路。如果你把这一套走通了再回头去看新的模型发布、新的Agent框架你真的会发现所有的AI工程核心问题来来回回就是那几件事——数据怎么管、模型怎么控、系统怎么稳、结果怎么评。把这些基本功打扎实后面做什么方向都不慌。