这两年“AI工程师”这个头衔被玩坏了。有人套个ChatGPT壳就叫AI应用有人跑通一段RAG代码就敢写进简历但真要独立把一个产品从零搭起来、扛住真实流量、还能持续迭代很多人立刻卡壳。我最初接触ai-engineering-from-scratch这个概念时心里想的是“又一个收藏夹吃灰的路线图”但真正梳理完它想解决的问题后我改变了看法它几乎就是一套从“会调API”到“能交付AI系统”的完整训练大纲适合那些不想只当调包侠、想把手艺练扎实的人。这篇文章我会站在实操角度把这条从零开始的路径拆开揉碎核心学什么、按什么顺序学、哪些坑我已经替你踩过了。1. 为什么“从零开始”这件事值得认真对待1.1 先搞清楚AI工程师到底解决什么问题很多朋友的误区是把“AI工程师”当成“机器学习工程师”的简化版或者干脆当成“提示词优化师”。但真正做过项目就会发现AI工程师的核心任务是把大语言模型变成产品里一个稳定、可控、可度量的组件。这里的关键词不是“模型”而是“稳定”和“可控”。举个最直观的例子你接到一个需求要做一个面向内部员工的文档问答助手。普通玩法是拿开源模型架个服务塞几个PDF进去然后用langchain串起来demo跑通演示效果惊艳。但一旦进入真实环境问题全冒出来了员工问法五花八门检索回来的片段互相矛盾模型对不确定的问题硬编答案哪天上游模型API升级了回答风格一夜大变。这时候你需要的绝不是“更聪明的提示词”而是一整套工程手段输入侧怎么做预处理检索侧怎么控质量生成侧怎么约束格式和置信度输出侧怎么兜底回退。这就是ai-engineering-from-scratch想指明的方向从零开始构建的不是“会聊天的机器人”而是一套具备稳定性的AI应用系统。它要求你同时理解模型的能力边界、应用的业务约束、以及工程的稳定性要求。你可以不懂训练模型但不能不懂怎么“驯服”模型这正是这个领域与传统算法岗最大的区别。1.2 这个学习路径和传统机器学习的本质差异传统机器学习项目的重心在特征、模型和指标上数据干净、特征有效、模型收敛项目就成功了一大半。但AI工程的重心完全变了因为LLM你已经拿到了一个“几乎什么都会一点”的通用底座真正的难点变成了怎么把已有的能力精准对齐到业务问题上。我做过一个很形象的类比传统ML是“从矿石里炼金”你得找到矿、粉碎、筛选、冶炼AI工程更像是“拿到了一块万能钢材但要根据客户需求把它切割、焊接、打磨成特定形状的零件”。前者拼的是材料和工艺后者拼的是设计和装配。这带来的直接后果是技能树的偏移。传统ML重视的是数学功底和模型结构理解而AI工程更重视这几项系统设计能力怎么把检索、提示、生成、校验串成一条稳定链路、数据工程能力评估集构建、bad case分析、以及工程交付能力服务化、观测、成本控制。你在网上看一万个LangChain教程不如自己从头手写一个不依赖框架的RAG链路后者才能真正逼你理解每一步在干什么。1.3 我建议你先忘掉“热门框架”很多新人入门AI工程第一件事就是去学LangChain、LlamaIndex这类框架。我的建议恰恰相反前四周尽量不要用任何框架。为什么因为框架把太多关键决策替你做掉了而你还意识不到这些决策的存在。比如RAG框架里的VectorStore和Retriever封装得极其优雅你三行代码就能跑通。但当你真正需要排查“为什么检索回来的内容是错的”时你就抓瞎了——你完全不知道embedding在哪个环节丢失了上下文不知道chunk切分的粒度是不是有问题不知道query改写到底起没起作用。我个人的经验是先用OpenAI或国产模型的原生API写一个裸的RAG自己管理分块、自己调用embedding接口、自己实现TopK召回、自己拼prompt。等你把这套流程写明白了再去接触框架你会发现自己能看穿框架的每一层抽象出了问题也能快速定位到具体模块。这个“先裸写、再框架”的顺序是整个from scratch路径里最值钱的一条经验。2. 最小必要知识集哪些必须学哪些可以往后放2.1 必须掌握的四块基本功如果让我给零基础新人划重点我会把AI工程的知识分成四个必须模块其余都可以按需补充。这四个模块是Python工程基础、大模型API调用、结构化输出、以及上下文窗口管理。先说Python工程基础。你不需要成为语言专家但有几个点必须具备类型注解大型项目维护的命根子、装饰器实现中间件逻辑的利器、asyncio并发请求的必经之路、以及异常处理LLM接口极不稳定不捕获异常等于事故。再说API调用。很多教程把这一步轻描淡写带过但实际上手时会遇到一堆细节超时设置、重试机制、API的速率限制、Token计费规则。我通常建议新人第一周就写一个带自动重试和超时控制的调用模块这不是浪费时间而是提前给项目铺好稳定性地基。结构化输出是AI工程里最被低估的能力。所谓结构化输出就是让模型的返回结果严格符合你定义的JSON格式。你现在觉得用正则解析模型回复也行等你的系统被上百个调用方依赖时你就会明白“字段缺失”“格式漂移”是多可怕的噩梦。现在OpenAI支持了json_schema约束其他主流模型的兼容方案也在逐步完善这是值得花一整天时间吃透的基础功能。上下文窗口管理听起来简单但它决定了你的应用能处理多复杂的任务。你要理解Token怎么估算、长文本怎么分段处理、历史对话怎么压缩、关键信息怎么优先保留。很多人说“我的应用会越聊越笨”十有八九是上下文管理出了问题——旧信息被挤出窗口新信息又淹没在噪音里。2.2 暂时可以不碰的东西与“必须学”对应的是“可以缓一缓”的内容。千万别被所谓的“必学清单”贩卖焦虑下面这些内容在你完成第一个完整项目之前都可以理性推迟。首先是模型微调Fine-tuning。微调确实能让模型适配特定风格或特定知识但它成本高、周期长、维护复杂。大多数AI应用的瓶颈都不是“模型不懂业务”而是“检索没把业务知识正确找到”。你连RAG都还没调明白就急着上微调等于还没学会走路就想跑马拉松。其次是本地部署大模型。跑本地模型这件事技术含量确实有但和AI工程质量本身关系不大。除非你有硬性的数据合规要求否则初期用成熟API能省下你大量精力。我之前指导过一个团队花两周时间用vLLM部署开源模型最后发现在提示词和检索上的优化空间被严重挤压本末倒置。第三是Agent相关的深水区。现在全网都在吹Agent但我想泼一盆冷水Agent的本质是多步推理加工具调用它建立在你对“单次对话”的掌控之上。如果连“让模型稳定输出一个格式正确的JSON”都做不到就不要指望它能在多步任务里保持稳定。先把基础链路做扎实再去探索上层建筑。2.3 制定一个四周起步计划考虑到不同基础的读者我给一个可落地的四周计划。这个计划是我给多个新人带教时验证过的节奏按周拆解目标明确基本可以直接当行动指南使用。第一周的任务是“打通调用层”用Python写完一个完整的模型调用模块包括超时控制、指数退避重试、Token用量统计、以及日志记录。这一周不碰任何框架就是把API吃透。第二周进入“结构化互动”给同一个模型写10种不同任务的结构化输出比如信息抽取、意图分类、步骤规划、多选一决策。重点不是任务本身多复杂而是你要形成“用JSON Schema约束模型行为”的思维定式。第三周是“裸写RAG”自己实现文档加载、分块、embedding、向量存储可以用轻量级方案先落地、召回、重排、生成。不要用框架每一块代码都要能说清楚“为什么这么写”。第四周把前面的东西整合成一个最小产品一个命令行版或网页版的文档问答助手。要有独立的评估脚本能批量跑测试问题能输出准确率报告。把这个项目做完你才敢说自己入了AI工程的门。3. RAG实战从原理到可落地的完整拆解3.1 为什么RAG是AI工程的核心压舱石市面上关于RAG的文章多如牛毛但大多是概念层面的复述。我想换一个角度讲RAG之所以重要不是因为它“能联网更新知识”或“能减少幻觉”而是因为它把“模型不知道的事”和“业务必须答对的事”这两者之间建立了一条可控的通道。模型再怎么强大它对你的私有文档、实时数据、内部规范是完全无知的而RAG用检索的方式把相关知识“喂”给模型让它基于证据作答。这个机制的工程含义非常深远当你发现答案不对时你可以去查检索环节也可以去查生成环节这比直接修改模型权重可靠得多。换句话说RAG把AI系统的可维护性从“炼丹”层面拉回了“软件工程”层面。实际做项目时RAG消耗的精力通常占整个系统的一半以上。文档格式纷繁复杂、表格内容丢失语义、专有名词被chunk切碎、问法和文档措辞不一致……每个问题都足以让一个看似优秀的问答系统瞬间崩溃。它能成为AI工程的核心必修课正是因为它是将“不可控的大模型能力”封装成“可控的业务应用”的最经典手段。3.2 分块策略最容易被忽视却最致命的一环我见过太多团队在RAG上花重金优化模型和向量库效果却毫无起色最后发现问题出在最基础的分块上。分块就是把你喂给系统的一篇长文档切成小块以便后续检索。听起来简单但这块做坏了后续再怎么调优都白搭。核心原则是分块要尽量让每一块都保持相对完整的语义单元。以Markdown文档为例你应该优先按标题层级切分把标题与对应内容放在同一块里其次是按段落切分段落都不行再按固定长度兜底。固定长度切分是最省事但最愚蠢的方案它常常把一句话拦腰截断把表格拆得七零八落把连续的几个数字拆到两个块里。还有两个参数直接影响检索质量分块大小和重叠长度。分块太大检索回来的内容会混杂太多无关信息分块太小语义缺失严重recall大幅下降。我的经验是普通技术文档chunk_size设在500到800个字符注意是字符不是Token之间比较合适overlap设100小类左右。对于代码文档或表格密集的文档要单独设计处理逻辑不能一刀切。另外要提醒的是分块策略必须和你的业务问题特征挂钩。如果你处理的文档是规范的制度文件按条款切分就有天然优势如果你处理的是技术博客按标题和段落切分更合理如果是对话记录那就得保留对话轮次结构。没有万能的切分策略只有“针对你的文档结构精心设计”的切分策略。3.3 检索增强你不只是在做文本匹配很多新人以为RAG的“R”就是Embedding相似度计算其实这是最大的误解。真正工程化后你的检索链路通常是这样的先做查询改写把口语化问题转换成适合检索的关键词表达再做混合检索向量召回加关键词召回最后做重排用更精细的模型把Top50压缩到Top5。查询改写这一步我吃过不少亏。举个例子内部系统里员工常问“报销单忘打了怎么办”这个问法和文档里的“报销流程补提”在语义上高度相关但直接向量检索可能匹配不到。后来我加了一个LLM改写模块先把用户问题转换成“报销流程 补提 漏打”这种检索友好型表达召回率明显上了一个台阶。混合检索的思路也值得展开。向量检索擅长语义相似关键词检索擅长精确匹配两者各有盲区。比如用户问“服务器CPU使用率100%怎么办”向量检索可能把文档里“CPU满载处理建议”排到很靠前但如果文档里没有“100%”这个关键词关键词检索可能完全命中不了。把它们的结果用加权或RRFReciprocal Rank Fusion融合在一起稳定性远优于单一召回。重排倒不必一开始就上。如果你的候选集本身就不大比如一篇文章切成几十块直接取TopK也算够用。但当你的知识库文档数量破千块数量破万时轻量重排模型或LLM自身重排就能发挥巨大价值。关于重排器选型说实话优先用业界验证过的成熟方案别自己造轮子。3.4 一个稳定的RAG生成策略生成环节听起来是最简单的——把检索结果拼进Prompt就能让模型回答但要稳定输出还得处理好两个细节引用溯源和无法回答的兜底。引用溯源不是可选项是AI应用可信度的生命线。你在Prompt里要求模型在每个关键结论后面标注来源文档编号例如“[1]表示来自文档A第3节”在输出阶段再做一次格式解析把引用编号映射到原始文档。这个机制的价值在于它让用户能验证答案也让系统上线之后能通过用户点击“查看引用来源”的行为数据来反向评估检索质量。无法回答的兜底同样关键否则模型就会一本正经地胡说八道。我在Prompt里明确规定如果检索到的内容不足以回答用户问题只能回答“根据现有资料无法确认”并列出已检索到的相关文档标题让用户自行查阅。不要小看这个设定它能把系统的幻觉率降低一个数量级。当然模型返回之后还需要一套质量过滤。简单做法是用一个LLM-as-judge的校验环节让裁判模型判断回答里的信息是否都有检索结果支撑有支撑才放行没支撑就拦截回退。多一层校验多一层开销但对于面向客户的高可用场景这层开销是必须回本的。4. Agent不是玄学怎么一步步构建可信的多步任务系统4.1 Agent的本质是“流程控制”而非“智能涌现”Agent概念这两年被极度神化好像它能自主思考、自我演进。但剥开营销外壳Agent的本质其实非常朴素把一个复杂任务拆解成多轮决策每轮决策交给模型再根据决策结果调用外部工具循环往复直到任务完成。我用一个生活化的类比来解释Agent就像分布式系统架构中的一个编排中心模型的每一次输出就是一次API调用结果它告诉你下一步该做什么、调哪个工具、传什么参数。系统并不“聪明”它只是忠实地执行每一步策略。Agent是否可靠不取决于模型是不是更强而取决于你为每一轮决策设定了多严格的约束。这种理解非常关键因为一旦你把Agent还原为“流程控制”你就会意识到工程手段的大有所为你可以给每个步骤设计独立的Prompt模板可以给工具调用加参数校验可以在关键节点插入人工审批可以在循环开始之前设定最大迭代次数。这些都是普通软件工程里司空见惯的手段移植到Agent场景下就是稳定性的基石。4.2 工具调用把模型接进真实世界的桥梁构建Agent第一步是把“工具”定义清楚。一个工具可以是查天气的API、执行SQL的函数、发邮件的接口、或者搜索内部的代码仓库。技术实现万变不离其宗把工具的URL、方法、参数Schema、用途说明注册给模型模型在对话中按需发起调用请求你的代码去执行真实调用再把结果反馈给模型。这里有一个容易忽略的细节工具描述description的质量直接影响模型选择工具的准确率。我在一个自动化报表Agent的开发中两个工具的API参数完全一样只是一个查“昨日销售”一个查“本月累计”初期描述写得太模糊模型频繁选错工具。后来我把描述改成带示例的自然语句准确率立即回升。这其实是Prompt工程在Agent场景下的延伸很多调参技巧是相通的。工具调用返回结果的解析也有讲究。真实系统返回的JSON往往比模型预想的复杂得多比如嵌套字段、错误码、分页信息。我的建议是在工具侧做一次“结果规整”把返回内容精简成模型需要的核心信息而不是把原始响应一股脑塞给模型。你投喂给模型的数据越干净它的决策就越稳定。4.3 多步任务的规划与校验到这一步一个最小可用的单Agent已经能跑了。但真实业务里任务往往需要多步配合这就涉及Agent的规划能力。规划有两种实现路线模型自行规划开放式以及系统预设流程固定式。前者灵活但不可控后者可控但死板。工程实践中我更推荐“半固定式规划”即系统把大的任务骨架定义好每个阶段允许模型做有限决策。举例来说做“自动生成竞品分析报告”这个Agent骨架是收集竞品信息、数据分析、生成报告初稿、审核校对。在“收集竞品信息”阶段模型可以从“搜索网页、查询数据库、读取历史报告”这三个工具中选择并多次调用但它不能跳过“生成报告初稿”直接到“审核校对”。这样既保留了灵活性又不至于让流程失控。每步结束后加校验逻辑是必要动作。校验可以是传统的规则检查“返回值是否为空、字段格式是否正确”也可以是模型自评“这一步结果是否满足任务描述的要求”。如果校验不通过安排重试多次重试仍失败则中止流程并汇报需要人工介入。老老实实把这条逻辑写了Agent成功率会大幅提升而不是靠运气跑通Demo。4.4 Token成本控制Agent最容易被忽视的隐形杀手Agent项目跑通后有很多用一段时间的团队被账单吓了一跳。原因很简单Agent多步循环会大量消耗Token。每次工具返回结果被塞进下一轮对话上下文越来越长成本非线性上涨。我见过一个中等级别的Agent每完成一次任务光模型调用就要烧掉2万多Token换算成成本还真挺肉疼的。熟悉一些预算技巧便很有必要给上下文做截断或摘要每轮对话只保留上一步的关键输出对工具的返回内容做裁剪只保留下游真正需要的字段高效模型处理中间步骤复杂模型只用在最后总结环节。这些技巧的取舍都源于“Token即成本”的意识那些后台硬撑着不做成本优化的Agent项目上线之日往往也是亏损之日。5. 评估与观测让AI系统从“感觉好用”到“确实可用”5.1 没有评估集就等于闭眼开车很多AI应用团队最心虚的时刻就是被老板问“这个东西效果怎么样”。如果答案是“你试试看感觉还行”那基本等于项目还没到交付级别。解决这个问题只有一个办法构建与业务目标对齐的评估集。评估集不是随机找几个问题而是要对齐真实用户的使用模式。我的做法是先把历史用户问题进行聚类找出高频问题类型每个类型抽代表性样本加入评估集每个样本包含标准问题、期望答案要点、检索必需的背景文档范围。这个工作大约要投入一到两天但它是整个AI工程质量的中流砥柱。评估集构建完成后每次改动系统都要全量回归。比如你改了分块策略跑一遍评估集看准确率涨了还是跌了你换了重排模型也要跑一遍看有没有引入新的bad case。没有这套机制的人做优化全凭感觉改完上线也不知道是变好还是变坏这是最危险的境况。5.2 评估方法从规则到模型裁判评估方法可以根据场景分层设计。最基础的是基于规则的评估适合硬性指标比如“回答里是否包含指定格式的报价单号”“输出是否严格符合JSON Schema”。规则评估的成本极低确定性极高应该优先覆盖。比较高阶的是LLM-as-judge用大模型来给回答打分。这个方案适合开放性问题比如“回答是否准确”“是否完整覆盖用户问题的每个方面”。裁判模型通常选用能力较强的大模型配合一份细致的打分Prompt才能给出相对可靠的结果。我不建议用自己的业务模型当裁判很容易出现和它自己同样的系统性偏差。人工抽检是最后的兜底方式也是最贵的。我常采用“分层随机抽样”策略在自动化评估完全通过的结果里再抽一部分让人工复核主要目的是发现自动化评估的盲区反过来持续改进评估集。这三个层级组合使用才能在成本可控的前提下形成质量闭环。5.3 观测和Trace线上系统的手电筒模型输出是概率性的这就注定了AI系统一定有无法预料的bad case。线上系统如果没有观测能力就像在黑暗的迷宫里行走根本不知道问题在哪一环爆发。因此AI系统的可观测性建设必须从第一天就纳入规划而非上线之后补课。追踪链路里至少要有这些信息用户请求原文、各阶段的耗时分块耗时、embedding耗时、检索耗时、生成耗时、检索命中的文档ID和相关性分、模型调用的输入输出Token数、最终返回结果等。有了这份链路你排查bad case时能快速定位问题层级。有一次我们的问答系统突然对某类问题答非所问查了Trace才发现是上游文档更新后分块逻辑没适配新格式检索结果错位导致的没有Trace的话这个问题可能得排查好几天。同时一定要做线上效果的持续监控。准确率这条曲线未必能自动获得但你至少可以盯几个代理指标用户对回答的点赞点踩数量、回答被编辑重发的比例、触发“无法回答”兜底的比率。这些数据汇总起来能让你感知系统的健康走向及时拦截恶化趋势。6. 常见问题与排查技巧实录6.1 问题速查表高频故障的定位方法论结合我做过的项目经验我把AI工程里最常见的几类故障整理成一个速查表。这张表的价值在于它帮你建立了“症状—排查路径—根因”的映射关系省去大量从零开始排查的时间。注意排查顺序很重要千万别一开始就怀疑模型能力。症状首先排查环节常见根因回答内容空洞、车轱辘话检索结果质量分块不合理或TopK值太小关键信息没进来回答不遵循格式乱输出结构化输出约束没在请求参数里声明json_schema或温度设得过高回答一会准一会不准Embedding/检索一致性文档有更新但向量库没同步增量刷新对话越聊越笨上下文管理旧信息被后续内容挤出窗口缺少摘要机制系统响应越来越慢链路耗时观测同一请求内串行调用太多需要并行化账单飞涨Token用量统计工具返回未裁剪上下文未压缩重复调用太多看到这个表你大概能理解我反复强调可观测性的原因没有Trace和日志这套速查表就成了无源之水每一条都得靠猜效率天上地下。6.2 我踩过的三个高价值坑这一节分享几个具体踩坑经历希望对你有参考意义。第一个坑是关于Embedding模型的“领域适配”。我曾在一个法律文档检索项目里直接用通用向量模型线上检索准确率始终只有六成左右换成一个在法律文本上做过领域适配的向量模型后原来测试集上的准确率直接提升了十几个百分点。这个教训使我现在选Embedding模型时一定会先拿自己的领域样本跑一个小规模的对比测试而不是轻信榜单数据。第二个坑是重试引发的重复副作用。早期我的Agent里对工具调用失败会直接重试有次扣款工具接口偶发超时重试机制导致同一笔交易被重复扣款。排查到头才发现问题不在模型而在工程。现在所有写操作类工具必须支持幂等键重试前先查询状态读操作才允许无脑重试。这件事让我意识到Agent工程一半的坑来自模型另一半来自工程本身的欠账。第三个坑是评估集污染。有一段时间我的系统评测分数一直很漂亮上线后真实用户却吐槽连连。后来对比分析发现评估集问题大多来自我们内部员工撰写的“标准问题”表达方式和真实用户截然不同模型轻松就能答好。这个“高分低能”的现象本质上就是评估集和真实分布错位。新构建的每一个评估问题我都坚持用真实用户原话或者由非项目成员模拟撰写的口语化问法宁可让分数难看一点。6.3 上线前必查清单最后分享一份我在每个AI项目发版前必过的检查清单。它不是高深的工程理论而是把每次上线踩的坑沉淀下来后得到的条件反射强烈建议把它贴在工位上。结构性护栏所有模型输出都有JSON Schema校验校验失败走补偿分支。日志记录里要能看到每个失败对象的原始输出。成本开关单个请求Token消耗预估上限有配置超出阈值自动熔断并告警。降级兜底模型服务不可用时暂停非核心功能或返回预设回复而不是让用户看到超时白屏。数据面配合回答中所有引用条目都能回溯到具体源文档及原文片段禁止出现无来源的断言。人工接管通道Agent任务卡在连续重试时要能一键暂停并转交人工处理同时导出完整堆栈数据。评估集回归改动合并前必须跑一遍完整评估集准确率不得低于上个版本。这些都是很基础的要求但往往越是基础越容易被赶进度的团队跳过。AI系统的上线不是终点而是持续治理的开始。我个人的体会是别急着追新模型和新框架把上述这套基本功打磨扎实你的系统反而会越跑越稳。踩过几次坑之后你就会明白AI工程真正值钱的地方从来不是那段调用大模型的代码而是围绕这段代码精心设计的工程护栏。后期如果想让这套体系继续扩展比较自然的方向是把评估集拓展成持续生成的反馈闭环——让每一次线上交互都在为你积累下一轮优化的数据到那时你手里的AI系统才算真正拥有了生命。