ai-engineering-from-scratch这个标题看起来像是一个GitHub仓库名但它背后其实是所有打算跨进AI工程领域的人都要面对的一份路线图。我已经在这个行业里摸爬滚打了几年带过的实习生一只手数不过来他们中最常问我的问题不是这个模型怎么调而是我到底应该先学什么。AI工程不是一个单一技术它是数据管理、模型开发、服务部署、性能优化、监控评估这一整套链条的集合。市面上讲单个环节的资料一抓一大把但从零开始把整条链串起来、还能跟着动手复现的内容确实少之又少。这篇文章就想充当那份少之又少的参考——我会从全貌讲起再把每个关键环节拆开最后给出可直接上手的实操路径。它适合刚入行的学生、想转岗的工程师也适合那些已经在做算法、却总觉得工程端缺一块的同行。1. 内容整体设计与思路拆解1.1 为什么偏偏要从零开始这个项目的名字里最关键的两个词一个是ai-engineering一个是from scratch。前者定义领域后者定义方法。我见过太多想入行的人上车的方式是买一门ChatGPT应用开发课学完之后会调用大模型API却完全不知道模型背后发生了什么也见过另一类人捧着《动手学深度学习》啃了大半年推导都会但让他把一个小模型部署成服务就抓瞎。问题出在哪儿出在他们把AI工程当成了一条线性路径以为学完A自然就会B。实际上AI工程是一个网络结构数据、模型、服务、观测互相纠缠任何一个环节的短板都会成为系统上限。所以from scratch在这里不是从数学基础开始的意思而是从一个最小的可运行系统开始。我提倡的做法是第一周就搭出一个能跑通的端到端雏形哪怕这个雏形只是用现成API做了一个带界面的问答机器人。先建立整体的肌肉记忆然后再一层层往深处挖。这个思路和学外语很像不可能等语法全学完才开始说话一定是先开口说在说的过程中补语法。AI工程也一样先跑起来再在跑的过程中理解每一环为什么存在。1.2 AI工程的技术栈全景图我在开头提到过AI工程和传统后端工程的本质区别在于传统后端处理的是确定性逻辑AI工程处理的是概率性输出。这个区别不是文字游戏它决定了你在技术选型和系统设计时的思路。按我的习惯会把AI工程需要掌握的能力拆成四层每一层对应一类核心问题。第一层是数据层要回答数据从哪来、质量如何保证、如何版本化管理第二层是模型层要回答用哪个模型、要不要微调、怎么评估好坏第三层是服务层要回答模型怎么封装成可用接口、延迟和成本怎么控制第四层是观测层要回答线上表现如何监控、模型退化了怎么发现、如何迭代。这四层不是孤立的。举个最常见的例子你在服务层做了缓存结果命中缓存后返回的答案过时了这看似是缓存问题实际上是观测层缺失导致的——你没有对答案的时效性做校验。所以学AI工程最重要的不是逐层精通而是建立跨层思维遇到任何一个现象都要能在四层之间来回排查。这个分层结构就是整个学习路线图的骨架。后面所有章节无论是讲数据清洗、模型微调还是服务部署本质上都是在往这四层骨架里填充肌肉和血液让系统从一个空壳变成一个活物。2. 核心细节解析与实操要点2.1 数据工程第一个必须踩的坑写数据工程这一节我想先把一个反直觉的事实摆在前面模型上线后出问题十有八九不是模型的问题而是数据的问题。我处理过不少线上事故最后指向都是数据分布变化、标注错误或者数据泄漏。如果你只能记住一个知识点我希望是在AI工程里数据质量决定了系统的上限模型只是去逼近这个上限。接下来按实操顺序讲三个重点。第一个是数据泄漏的排查。泄漏的形态很多最隐蔽的一种是时间穿越。比如你做一个销售预测模型训练数据里用了是否A/B测试组这个特征但A/B测试的分配是在预测时刻之后才确定的那么线上你根本拿不到这个特征——模型在训练时看到的是未来信息。检查泄漏有一个笨办法但很有效把每个特征的产生时间列出来和你预测目标的时间对比凡是特征时间晚于预测时间的全部剔除。第二个是标签噪声的清洗。人工标注的准确率能做到90%上下已经很不错剩下的10%噪声对模型的影响比你想象中大得多。我常用的手段是交叉验证清洗法先用一个简单模型预测一遍把预测结果和原始标签不一致的样本挑出来交给标注员二次确认。这里有个细节要注意做二次清洗时尽量不要让同一批标注员处理自己标过的数据换一批人或者让模型辅助筛选否则惯性标注会让错误反复出现。第三个是数据版本管理。我经历过一次惨痛教训一个训练实验效果不错但两周后想复现却记不清当时用的是哪份数据。从那天起我所有的训练实验都会强制记录三要素代码commit id、数据版本id、模型配置hash。如果你只靠文件夹加日期命名早晚会在某个深夜翻车。趁项目还小的时候就把数据版本管理的习惯养起来等数据量大了再回头补成本至少翻十倍。2.2 模型微调不是只有炼丹一提到微调很多人的第一反应就是上GPU、跑训练、看loss曲线好像这是一件只要砸算力就能搞定的事。但在AI工程视角下微调的真正难点有两个该不该微调以及微调之后怎么不把模型搞坏。关于该不该微调我建议遵循渐近路线先用提示词工程试加几个Few-shot示例再上RAG最后才动微调。这样做的理由有三个成本、可控性、迭代速度。提示词和RAG每次改动都在分钟级微调一次至少小时级而且每微调一次你对训练数据的依赖就多一分排错难度也直线上升。我见过的情况是很多任务用现成的基座模型加一点提示词工程就能解决根本不需要微调你花几千块训练成本最后效果可能还不如改写两行Prompt。关于怎么不把模型搞坏核心是防灾难性遗忘。模型在特定任务上微调等价于让它在某个方向上走得太远结果其他方向的泛化能力被侵蚀。常用的对抗手段有三个一是控制训练轮数微调通常1到3个epoch就够了不要反复跑二是把学习率调小让更新的步长变短不至于偏离预训练参数太远三是训练样本里混入一部分通用语料保持模型的一般能力。这些手段没有哪个是银弹要组合使用。另外微调之前先把评估集和评测指标定好不要边训练边想怎么评估那样很容易被训练集上的漂亮曲线带偏。2.3 评估体系如何定义好与坏模型做出来了怎么证明它好这是AI工程里最微妙的问题。学术上常用BLEU、ROUGE、准确率这些指标但这些指标和生产环境的好并不等价。举个例子一个问答系统在离线测试集上准确率98%但用户问的是测试集覆盖不到的边缘问题系统全都答非所问那这个98%就没有意义。所以我在工程实践中会把评估拆成两层。第一层是模型指标如准确率、召回率、幻觉率、上下文命中率。这些指标用来评估模型单独的能力。计算幻觉率时要注意定义统一我的做法是人工抽样检查判断答案中的每个关键信息点是否都能在检索到的上下文中找到依据。第二层是业务指标如用户采纳率、解决率、客服从工单量、成本节省额度。这些指标直接反映系统是否在真实场景中创造了价值。模型指标和业务指标之间往往不是线性关系——模型指标从90%涨到95%业务指标可能只涨0.3%但模型指标从80%跌到75%业务指标可能就是断崖式下跌。所以在做优化时不要盲目追求模型指标要盯着业务侧的变化。评估还有一个工程化的要求可重复。我强烈建议把评估过程脚本化每一次模型更新都跑同一套评测集产出同一格式的报告然后归档对比。没有可重复的评估就没有真正意义上的模型迭代。很多时候你训练了十个版本如果评估脚本都不一样你就无法判断哪个版本在真实场景中更可靠。3. 实操过程与核心环节实现3.1 从零搭一个RAG问答系统选RAG作为第一个实战项目是因为它足够完整又足够接地气。一个完整的RAG系统会经过数据处理、向量化、索引、召回、重排、生成、服务化、反馈收集几乎把AI工程四层能力都覆盖到了。更关键的是它对算力要求不高一台普通开发机就能跑通很适合from scratch这个定位。我先说拆块。文档来了你不能整篇扔给模型——检索的最小单元是块块的质量直接影响检索质量。我的经验是先按文档自带的结构章节、小节作为天然边界如果某个章节还是太长再按段落切最后用token数做强行截断。我在操作时通常会把目标块长设定在300到500 token之间重叠控制在50 token左右这样既能保证语义完整又不至于让上下文过于臃肿。块太大检索精度会下降块太小上下文信息不完整生成效果会变差所以这个参数值得你花时间调。然后是embedding模型的选型。不要只盯着排行榜要看三个标准一是在你的领域样本上的相似度排序是否合理二是最大输入长度是否覆盖你的块长三是向量维度是否匹配你的数据库索引方案。维度太高会抬高存储成本和检索延迟维度太低可能装不下语义信息。在索引构建的时候把文档的元信息标题、章节路径、更新时间一并存进去方便后续做字段过滤。检索这一步我前面提过要混合召回。把BM25关键词召回和向量语义召回的结果做RRF融合排序。RRF的原理不复杂对每条候选结果给一个基于排名的分数然后把两个列表的分数相加排序。这样做的好处在实际场景里很明显——向量召回擅长语义相似但偶尔会把意思相近但无关的片段捞上来关键词召回擅长精确命中但对同义改写无能为力两者互补。下面是一段简化的召回逻辑示意# 伪代码混合检索主流程 from rank_bm25 import BM25Okapi from vector_db import VectorDB def hybrid_search(query, top_k5): # 1. 关键词召回 bm25_scores bm25_index.get_scores(tokenize(query)) keyword_ids get_top_n(bm25_scores, n10) # 2. 向量召回 query_vec embed(query) vector_ids vector_db.search(query_vec, n10) # 3. RRF融合排序 merged rrf_fuse(keyword_ids, vector_ids, k60) return merged[:top_k]生成端的调校也值得花时间。除了在system prompt里写死如果文档中没有依据就直接回答未找到相关信息之外我还会要求模型在输出时标注引用来源的编号这样前端可以展示答案来自文档第X节既增加可信度也方便追溯错误。格式上建议用统一的JSON结构返回方便下游解析。最后是服务化接口设计。我建议至少暴露三个接口上传文档、查询、反馈。查询接口应该支持流式输出这样用户体验更好上传接口要做好格式校验和异步索引避免大文档阻塞主流程反馈接口收集用户对答案的点赞/点踩后续评估全靠它积累真实数据。这个闭环一旦建立起来你的RAG系统就不只是一个demo而是一个可以持续迭代的产品。3.2 推理服务性能优化实录模型推理服务化之后性能优化是绕不开的一关。我遇到的第一个项目7B模型在GPU上推理延迟1秒多看上去能用但一到业务高峰期并发一上来排队时间直接飙升到10秒以上用户马上流失。所以后来我总结了一句话推理优化的目标不是让单个请求变快而是让系统在目标并发下依然稳定。这一节我挑三个实际用到的优化手段讲清楚。第一个是量化。量化就好比把一张高清照片从无损格式转成有损压缩格式肉眼看着差不多但文件小了很多。在模型推理里常见的是INT8量化把模型权重从FP16压缩到INT8体积减少一半推理速度提升两到三倍。但量化不是直接转就完事如果你的模型对精度很敏感一定要做校准——用一小批代表性数据跑一遍观察量化误差调整每个层的缩放因子。我见过有人直接量化后模型输出就开始胡言乱语就是因为跳过了校准。第二个是动态批处理。在线推理服务里请求到达的时间是稀疏的如果每个请求都单独占一次推理GPU算力大部分时间在空转。动态批处理做的就是攒一批再算把短时间内到达的几个请求合并成一个batch一次性推理。这么做要注意权衡攒的时间太长单个请求的延迟会变大攒的时间太短batch太小吞吐提升不明显。这个攒批窗口通常需要压测来确定我从50毫秒起调逐步加大找到一个吞吐和延迟的平衡点。第三个是语义缓存。这是成本杀手锏。很多业务场景里用户的问题高度重复比如企业内部问答系统里年假怎么休报销流程是什么这类问题占了很大比重。对这类问题没必要每次都跑一次大模型。做法是把query先向量化在缓存里找相似度高的历史query命中就直接返回上次的答案。我用这个手段把重复性场景的调用成本直接砍掉一半以上效果比任何模型优化都来得快。下面是我记录的一组实测数据同一个模型、同一批测试负载经过三层优化之后的效果对比优化手段平均延迟吞吐量TPS成本变化未优化基线580ms1.7基准INT8量化210ms4.6降约40%动态批处理180ms9.8降约50%语义缓存95ms命中时12.5降约60%需要强调的是性能优化永远是最后一公里的事。在系统还没跑通之前不要过早陷入这些优化细节。先把功能做对再把性能做快顺序反了会很容易卡在泥潭里。4. 常见问题与排查技巧实录4.1 模型上线后的十大典型故障模型上线和代码上线完全不一样。代码上线行为是确定的出了bug可以靠日志定位模型上线行为是概率性的出了错你甚至说不清它是逻辑错了还是概率没抽中。所以我多年来养成一个习惯以模型会出问题为前提设计系统而不是以模型不会出错为前提。我把频繁遇到的故障整理成一张速查表你可以直接保存下来当排查手册现象可能原因排查步骤解决方案线上效果远低于离线测试训练与线上数据分布不一致对比特征分布、样本来源校准线上/离线数据管道答案偶尔完全离谱模型幻觉检查检索上下文是否充分加强不知道约束增加兜底请求延迟突然升高并发超预期或模型退化看队列长度和GPU利用率限流、扩容、动态批处理缓存命中率极低查询分布太分散分析query聚类调低阈值改用语义缓存输出格式不稳定Prompt被覆盖或few-shot漂移对比历史输出结构固定模板加输出校验新增数据后效果变差新数据质量未校验检查新增样本标签分布上线前加数据质量门禁GPU显存溢出序列长度不受控统计输入长度分布设置硬性最大长度模型重复输出同一句话解码参数设置不合理检查repetition_penalty调高重复惩罚小流量正常大流量报警容量规划不足监控资源水位弹性伸缩观测无异常用户投诉多评估指标和业务目标脱节检查指标定义补充业务指标这张表看着简单但每一条背后都是真金白银的教训。我自己最常犯的是第一种离线指标漂漂亮亮上线就翻车。后来我把排查流程固定成三步先看数据分布有没有变再看特征管道有没有走样最后才怀疑模型本身。这个顺序救了我很多次。4.2 学习路线复盘与几个常见误区除了技术故障学习路线本身也有坑。我复盘自己从零到一的过程发现有几类问题最具迷惑性。第一类是只见树木不见森林。刚入行的时候我喜欢死磕一个点比如花两个礼拜研究某个注意力机制的变体却对自己的系统为什么延迟高一无所知。后来才明白AI工程的能力是T字形的先保证一横是广度能看懂整条链路再在某一个方向深挖一竖建立真正的优势。不要一开始就挖井先把地图看完。第二类是用学习代替实战。看十篇教程不如亲手部署一个小模型。我见过有人书单拉了一长串GitHub上的star数量比我还多但问他线上模型效果不好怎么排查他答不出来。建议用项目来倒逼学习每学一个知识点就把它落进现有的实战项目里。第三类是忽视软技能。AI工程师不是纯技术人员你往往要跟业务方沟通需求、跟产品经理对齐指标、跟运维配合容器化部署。如果总结能力不行、写文档敷衍、不爱做复盘技术再强也会被卡在瓶颈上。我个人的习惯是每个实验都写一页实验日志记录目标、做法、结果、结论四个字段短但有用。5. 学习路径规划与工具选型建议5.1 新人如何安排学习节奏如果让我给一个完全没有经验的从零开始学习者画一条节奏线我会这样安排。第一到两周目标是把整个技术栈看一遍。不要深究细节用现成的大模型API或者开源小模型搭一个最简单的问答demo让它能跑起来。这期间你会接触到环境安装、API调用、前后端联动先建立我能搞定的信心。第三到四周进入数据层。找一份有标签的数据集做清洗、做切分、做版本管理理解数据泄漏和标签噪声这两个大坑。这周的目标不是学算法而是学会折腾数据。第五到八周进入模型层。试着用开源模型做一个领域微调同时把评估集和评估脚本搭好。这里的关键是别只盯训练指标要把离线评估-线上表现的对应关系搞清楚。第九到十二周进入服务层和观测层。把自己的模型或API封装成服务加上性能优化和日志监控最后能跑出一个带页面的完整应用并且能回答某个指标去哪里看、系统变慢了怎么排查这类问题。这个节奏的核心是每两到四周就有一个看得见的产出。如果某一周落后了不要慌把时间拉长但始终要保住端到端一个系统在运行的底线。5.2 关键工具与资源选择逻辑工具的选择逻辑比工具清单本身更重要。我的原则是优先选被验证过的、生态好的、关键时候有人替你踩坑的工具新兴的工具可以先观望等它稳定一点再切。在数据层面我推荐用Pandas做清洗是基础但尽早引入数据版本管理工具。在模型层面不要一上来就追最新模型挑一个文档成熟、社区讨论多的开源模型等你踩过几轮坑再横向比较。在服务层面容器化部署和API框架是基本功建议先学会用FastAPI这类轻量框架写服务再考虑用专门的推理服务框架进行规模化部署。关于学习资料我的观点是少看二手教程多读一手文档和源码。教程可以帮助你建立全局观但细节和真知都在官方文档、API参考和开源项目的PR讨论里。遇到问题先查文档再搜issue最后才问大模型或社区这个顺序能帮你养成独立解决问题的能力。工具不在多在于你能真正地把它的原理讲清楚。比如推荐系统很多人只是调用了函数却不知道里面的索引结构为什么快这样一旦遇到性能问题就只能干瞪眼。最后再分享一个我从复盘里沉淀下来的小习惯无论项目大小我都会写一份一页纸的实验日志记录目标—做法—结果—结论四段。别小看这件事它会在你同时跑着五六个实验、过了三周想不起来当时为什么选这个参数的时候救命。AI工程这条路上最大的浪费不是踩坑而是在同一个坑里踩两次。