去年有个朋友问我现在AI这么火我调GPT的API做个客服机器人是不是就算AI工程师了我说你先别急着给自己定title先回答我一个问题——当模型输出幻觉、回答前言不搭后语、上下文一长就开始飘的时候你打算怎么办他愣了一下。这个场景我见过太多次。过去半年AI工程这个词的热度一路走高但大家在社区里最常见的求助帖永远是同一类我的RAG为什么效果这么差为什么Agent跑几个任务就死循环模型上线之后精度没问题延迟却爆炸了怎么办。这些问题的共性在于光会调用API解决不了靠感觉调参解决不了需要的是系统的工程能力。而这种能力恰恰不是看几篇推文、跑一个demo就能建立的。这也是我这次认真梳理ai-engineering-from-scratch这份学习路线的原因。它不预设你懂机器学习也不预设你有现成的生产环境而是把数据→模型→系统→业务这条链路上每个关键环节拆开讲清楚是什么、为什么、怎么做。这篇内容适合三类人刚入门想建立完整AI工程认知的初学者、被线上AI应用折磨但找不到排查思路的开发者、以及想把手头demo做成可靠系统的技术负责人。1. 为什么AI工程值得从零重学一遍1.1 AI工程到底在解决什么问题很多人对AI工程的误解是把模型跑通。模型跑通只是第一步AI工程真正要解决的是模型在真实业务里能不能稳定、可用、可控、可迭代。举个我自己的例子。去年我帮一个团队做内部知识库问答demo阶段效果很好演示给领导看的时候大家都很兴奋。结果一接真实文档就崩了几百份PDF格式混乱有的扫描件没做OCR有的表格被切得四分五裂还有大量重复版本。等我把数据洗干净、重新分块、调整检索策略又发现另一个问题——业务人员问的是上个月华东区的退货率为什么上升而文档里只有一张张零散的日报。这种用户问法和文档写法之间的鸿沟靠模型再大也填不上。这件事让我想通了一个道理真实业务里AI应用的误差来源往往不在模型本身而在模型之外。数据质量、检索命中、上下文编排、评估闭环、监控告警、成本管控这些环节任何一个掉链子整体效果都会垮。而这些环节的知识在大多数手把手教你调用API的教程里几乎没人系统讲。1.2 from scratch 的正解不是重造轮子是掌握诊断权from scratch这个词容易让人误会以为要从头写Transformer、从零实现RAG框架。我的看法恰恰相反绝大部分轮子不必重造但你必须知道轮子是怎么转的。一个直白的类比你会开车不一定要会造发动机。但如果发动机一响你连是油路问题还是电路问题都判断不出来那就只能被路边店牵着走。AI工程里的from scratch目标是建立对系统的诊断权——出问题了你能定位到数据链路、检索链路还是生成链路而不是盲目换模型、改prompt、加数据最后靠玄学调参。具体到这个项目我理解的from scratch学习方式是每个核心环节先用最简单的工具跑通最小闭环理解原理再引入生产级框架。学Embedding先要知道文本是怎么变成向量的、相似度是怎么算的然后再用OpenAI或BGE的接口学RAG先手动完成检索拼装prompt生成三步再接入LangChain这类框架。这样框架对你来说就是透明的工具而不是黑盒。2. AI工程的能力基线你究竟需要掌握什么2.1 三层能力结构我习惯把AI工程的能力拆成三个层面缺一不可。第一层数据与基础编程。包括Python、SQL、基础数据结构以及用pandas/polars做数据清洗的能力。很多人觉得Python会写循环就够了但真实做AI工程你每天花时间最多的是处理脏数据去重、格式统一、缺失值处理、从PDF和网页里抽文本。数据不行后面全白搭。第二层模型原理与算法。这里不需要你把Transformer的数学推导弄得滚瓜烂熟但要有直觉什么是Embedding、什么是Attention、为什么上下文长度会影响效果、微调和预训练的区别是什么、prompting和微调的边界在哪里。有了这层直觉你才能判断一个问题到底该用RAG解决、调prompt解决还是微调解决。第三层系统与工程。包括API设计与后端集成、检索系统向量库、混合检索、重排、部署运维推理服务、并发处理、监控告警、成本优化和AI安全护栏。这一层是把能跑的模型变成能用的产品的关键也是最容易被自学的人忽略的部分。这三层不是线性的学完一层再学下一层而是应该螺旋式同步推进。做一个小项目往往三层知识都会用到你要写代码处理数据第一层要选择合适的模型和调用方式第二层还要把功能做成接口、部署上线第三层。以项目带知识比孤立地学每一层效率高得多。2.2 很多教程让你跳过的部分恰恰决定了成败市面上大多数AI入门教程有一个通病跳过数据清洗直接讲模型调用跳过评估直接说效果很好跳过部署运维只给你一个Jupyter Notebook。这三块恰恰是工程实践里最要命的。先说数据清洗。模型本身是所见即所得的——你喂它什么它用给你看什么。很多人用LangChain加载PDF后从不检查切分结果结果检索时返回的是半个表格、一个乱码页模型当然答不对。我自己有一条规矩任何数据进了系统必须抽样人工看一遍。看它被加载成什么样、分块后是否语义完整这个习惯能省大量排查时间。再说评估。不做评估你根本不知道系统是变好了还是变差了。你改了分块策略感觉好像效果不错但这是不是错觉同一个问题昨天答对了今天答错了是模型不稳定还是检索变了没有评估集和指标这些问题只能靠猜。最后说部署运维。Notebook里跑通的代码和线上高并发的服务差别比很多人想象的大。模型推理要管显存、并发、超时提示词要管版本上线和回滚系统要应对模型API的限流和故障。这些经验不跑一遍真实部署永远学不会。3. 从零搭建一条能用的RAG链路完整实操复盘这一节我用一个具体的例子来讲从零做一个企业内部知识库问答系统。这个场景最适合练手因为它数据可控、需求明确而且几乎涵盖了AI工程的所有关键环节。3.1 场景定义与数据准备先问清楚再动手很多人一上来就选模型、调接口我建议先花一天把下面几个问题想清楚文档从哪来什么格式更新频率如何有没有权限区分用户会问什么问题是问制度条款还是问数据报表还是开放式讨论期望的答案形态是什么一段话、带引用出处还是表格对比这些问题的答案直接决定后续设计。比如文档里有大量扫描件那第一步就要做OCR文档按年度更新那检索范围就要支持时间过滤用户提问偏口语化那就要考虑查询改写。数据处理这一步我的标准流程是所有文档转成同一种处理中间格式比如带结构信息的Markdown或JSON保留标题层级去重多版本文档只保留最新版表格、图片单独处理表格转Markdown或结构化数据图片走OCR或说明文字清洗完做一轮人工抽检确认每类文档都被正确解析。分块chunking是这里最容易翻车的一步。我的经验是不要纯按固定字数切会让语义在中间断掉尽量按文档结构切比如按标题、段落、表格边界块大小我一般控制在256到512个token之间太短缺失上下文太长检索命中会变粗糙相邻块之间加少量重叠比如50到100个token避免硬切断引言和正文的关联。分块策略没有绝对正确答案它取决于文档类型和后续检索效果。所以不要照搬某个教程的参数要跑评测看结果再调。3.2 索引与检索调优向量不是万能的数据准备完下一步是向量化和建索引。选Embedding模型时我一般看三条中文效果、维度、部署成本。开源的有BGE、GTE系列API的有OpenAI、国内各家云厂商的Embedding接口小规模场景直接用API更省事。向量库方面学习阶段用FAISS就够了生产环境如果数据量不大也用不着上Milvus直接用Elasticsearch或OpenSearch的KNN能力更省事——反正大多数公司已经有一套ES了。但我要强调单纯向量检索在真实场景远不够用。向量检索擅长语义匹配但不擅长精确关键词匹配。比如用户查合同编号A-2024-001向量检索往往不如BM25精确。很多业内公认比较稳的方案是混合检索向量检索和BM25关键词检索并行跑各自取top N合并去重后再做重排。重排rerank这一步值得多说两句。第一阶段召回的比较粗糙比如top 20段落重排阶段用更强的模型例如bge-reranker或者cross-encoder把这20个段落逐一精排取前3到5个进上下文。我自己做过的系统里加上重排环节答案质量往往有立竿见影的提升。检索调优不能靠感觉要建立评测集。我一般会准备50到100条真实的问题-标准答案对应文档数据然后统计召回指标比如有正确定位是否出现在top5。每次改分块、改Embedding、改召回策略都跑一遍评测用数字说话而不是我今天试了一下感觉变好了。3.3 生成环节的工程化处理Prompt结构决定质量下限检索完把命中的段落拼到Prompt里给模型生成。这段看着简单细节非常多。Prompt结构我常用的模板是System部分定义角色、回答边界、引用格式要求Context部分放检索到的文档片段并且明确标注来源编号Instruction部分说明只基于上述资料回答不编造资料不足时如实说明历史对话如有控制在合理长度防止上下文膨胀。顺序上通常是System在前、Context其次、Instruction紧跟最后是用户问题。不同模型对顺序敏感度不一样这个可以自己实验但核心原则一致让模型在生成之前完整看到边界规则事实材料。引用来源的设计特别重要。我要求模型在每个关键断言后面标注来源编号比如[1]这样用户能自己点开原文核对系统也更容易建立信任感。同时要设置兜底逻辑当检索结果质量低或为空时Prompt里明确要求模型回答当前资料库中未找到相关信息而不是硬凑答案。这个兜底逻辑对防幻觉非常有效。3.4 评估闭环不评估你根本不知道系统好不好做完前面几步一个基础RAG系统已经能跑了。但能跑和能用差着十万八千里差的就是评估。我评估RAG系统一般看三个维度忠实度Faithfulness答案是否严格基于检索到的文档有没有凭空捏造相关性Relevance检索回的文档是否切题有没有牛头不对马嘴完整性Completeness该答的点有没有漏文档里有的关键信息是否都被覆盖。落地方法很简单准备几十条标准测试题每题人工标注标准答案和对应文档跑完一轮系统后用LLM-as-judge或人工抽评给三个维度分别打分。不要迷信LLM-as-judge它自己也有误判但用来做初筛、做回归测试已经能省大量人力。重点是跑通这个闭环之后你做的每次改动——改分块、改prompt、换Embedding、调整召回数——都有了客观反馈。我之前改了一版分块逻辑自测觉得不错跑评测一看完整性降了8%赶紧回滚。如果没有这套闭环这个感觉不错的改动就带上线了后果难料。4. 模型层从手写最小模型到真正理解TransformerRAG系统做得再炫模型层的基本功也不能缺。这一层学的不是调API而是建立模型是可控对象的直觉。4.1 为什么建议手写一次最小模型很多人觉得现在都有大模型API了学线性回归、学手写反向传播还有什么用用途不是让你去训练大模型而是让你理解几个关键概念损失函数、梯度下降、过拟合、学习率。这些概念在调模型、诊断效果时天天要用但看一万遍理论不如手写一次。我推荐的做法是用NumPy手写一个最小的线性回归或一个单隐层MLP不要用PyTorch的自动求导就自己写反向传播的矩阵运算。第一次跑通梯度下降、看着loss一点点降下去你对模型是如何学习的就有了实感。之后再接触Transformer、LoRA微调很多抽象概念都能对号入座。这一步周末两天就能搞定性价比极高。4.2 Transformer的工程直觉不是推导是理解机制手写完整Transformer成本很高初期性价比不高。但几个核心机制的原理必须有直觉第一是Embedding和位置编码。文本进了模型为什么会变成向量顺序信息是怎么保留的这决定了你理解为什么模型会受上下文窗口限制。第二是Attention机制。我的理解方式是一个查找操作每个token都带着一个问题query去所有token的键值对key/value里做加权查询权重由相关性决定。理解了Attention你就理解了为什么模型会更关注相关段落也理解了为什么上下文越长、计算量越大。第三是训练和推理的差异。预训练、监督微调SFT、人类反馈对齐RLHF分别解决什么问题为什么说预训练学的是语言规律微调学的是任务格式这些概念直接关系到你对微调到底能改变什么的判断。4.3 微调 vs RAG vs Agent别一不爽就微调这是我在项目里见得最多的误区效果不好第一个念头就是微调模型。我建议按这个逻辑来思考先看问题出在知识缺失还是行为不规范。知识缺失比如不懂内部业务术语、不知道新政策优先用RAG补因为知识库是动态的改文档就能更新而微调一次成本高、周期长改起来麻烦。行为不规范比如输出格式总不对、语气不像客服、总不忘加一句我是AI助手这才考虑微调。Agent则解决的是多步骤、需要调用工具完成任务的场景比如查库存、算价格、走审批流。实际项目里的合理顺序是先Prompt工程把边界探清楚再上RAG补知识最后才轮到微调。调可用性和收益这个顺序几乎总是最优解。5. 工程化必修课上线之后的事demo跑通不算完上线那一刻才是工程问题的开始。这一章讲部署、监控、成本和护栏这些是AI工程和玩模型的分水岭。5.1 推理部署的几种形态按场景选别盲目上开源模型部署方案我按规模说直接用托管APIOpenAI、通义、Kimi等厂商的API适合起步、量小、不想管GPU的团队。优点省事缺点是大规模调用成本高、数据要出网、受供应商限流影响。开源模型自部署Qwen、DeepSeek、Llama等用vLLM推理适合数据敏感、规模大、对成本敏感的团队。vLLM是目前最主流的推理框架支持Continuous Batching吞吐比裸加载高很多。混合策略同一个系统里简单任务走便宜的小模型复杂推理走贵的大模型这叫模型分级路由。很多生产系统都是这么省的。部署不是把模型拉起来就行还要考虑并发、超时、容灾。我踩过的坑包括并发一上来GPU显存溢出、上游API限流导致整条链路雪崩、模型服务重启导致请求堆积超时。这些要靠负载均衡、限流、降级策略来兜住。5.2 监控、成本与护栏没有监控就没有发言权AI应用上线后至少要盯这么几类指标延迟和吞吐P50/P95延迟、每秒请求数。检索和生成各占多少时间有没有优化空间。Token用量输入输出token分布哪些环节在烧钱。上下文越长成本越高经常会发现历史对话管理不当导致token爆炸。缓存命中率对高频相似问题做缓存能省一大笔钱。用户反馈率用户点回答有帮助/无帮助的比例是效果评估的第一手信号。成本优化有几个立竿见影的手段一是模型分级简单问题走小模型二是语义缓存同一类问题直接返回缓存结果不必重新调大模型三是控制上下文长度历史对话压缩、检索段落只取必要的别一股脑全塞给模型。护栏方面输入输出过滤、PII个人身份信息脱敏、内容安全审查这几件事必须上线前就做。AI应用最怕出安全事故一条包含用户手机号的生成结果传出去麻烦是不可逆的。6. 我的实操建议三个月路线与避坑清单6.1 可执行的三阶段路线不给路线的建议都是耍流氓。我基于自己带人和自学的经验给一条三个月能走完的路每周至少投入10小时。第一阶段第1个月打地基加跑通最小闭环。第一周Python基础加数据清洗用pandas处理一份真实脏数据第二周机器学习基础手写最小线性回归和MLP第三周调用大模型API做一个最简单的问答脚本理解Prompt基本结构第四周做一个带界面的极简问答应用跑通用户输入→模型→输出全链路。产出物一个能部署到公网访问的极简问答页面。第二阶段第2个月把RAG做完整。第一周搞定文档清洗和分块用开源Embedding建向量库第二周实现混合检索加重排第三周完善Prompt和引用设计第四周建立评估集跑通改参数→跑评测→看指标闭环。产出物一个能针对私有文档做问答、且能说清效果好坏的知识库系统。第三阶段第3个月上工程化和Agent。第一周用vLLM部署一个开源模型第二周把系统做成标准API加监控指标第三周做一个带工具调用的Agent比如可以检索、计算、查库的助手第四周综合项目把前面所有能力串起来写成技术文档并部署上线。产出物一个有工具调用能力、有监控、有评估的完整AI应用可以作为作品集核心项目。这条路线不快但它每一步都建立在前面一步的基础之上不会有视频看懂了动手全废的落差感。6.2 避坑清单这些坑我基本都踩过第一个坑一开始就刷论文。对初学者来说读一篇Transformer论文的收益远低于跑通一个端到端demo。先动手遇到具体问题再针对性查理论效率高得多。第二个坑忽略评估。感觉变好了是做AI工程最大的谎言。发现没有评估集就先建评估集哪怕只有20条题也比没评估强。第三个坑环境问题耗掉大量时间。Python版本、CUDA版本、依赖冲突、模型权重下载失败……我的建议是每阶段开始先锁定一套经过验证的版本组合记录到项目README里。因为AI生态更新太快半年后新装环境很容易碰到这个库最新版改了API的情况。第四个坑Prompt不做版本管理。Prompt是代码不是聊天记录。我见过一个生产项目prompt被谁改了都不知道线上效果漂移了好几天才定位到。建议把每个版块的prompt版本、上线时间、效果指标都记录清楚用Git管理。第五个坑拿客户数据直接调外部API。涉及业务数据、用户隐私时先确认数据合规边界该脱敏脱敏该本地部署本地部署。这一条不能省出了事不是技术问题是责任问题。最后再分享一个让我受益最多的习惯。从做AI工程第一天起我就建了一个简单的实验记录文档每个改动、改动原因、预期效果、实际效果都记下来。三个月后回头看会发现很多当时觉得智商税的策略和当时觉得机智的操作会在更长的周期里呈现出完全不同的结论。这种记录习惯的价值远大于任何一个单点的技术技巧。从零开始学AI工程最宝贵的不是你最终懂得多少算法细节而是你建立了一套出问题能定位、改方案能验证、上线后能兜底的系统化能力。这份能力才是AI工程师和会调API的人之间的真正区别。