从零开始做AI工程这个仓库我整理了快两年中间推倒重来了三次终于敢说它真的“能打”了。如果你点进来是因为标题里那句“from scratch”那你应该和我当初一样受够了那些只会教你怎么 import 一个库、调一个现成接口的教程。市面上讲AI的课程多如牛毛但能真正告诉你“一个AI系统从立项到上线每一步该怎么做、为什么这么做、踩了坑怎么爬出来”的内容少得可怜。这篇文章就是围绕我搭建这个名为“ai-engineering-from-scratch”的完整知识体系展开的我会把它拆开揉碎把我踩过的坑、验证过的方案、以及最终沉淀下来的那套工程方法论全部摆到台面上。写这个项目的初衷很简单我想给“AI工程师”这个岗位画一张不那么悬浮的能力地图。2025年了AI早就不是实验室里发论文的专利它变成了业务系统里一个需要稳定运行、可评估、可迭代的模块。但市面上大多数人的认知还停留在“会调大模型API就能做AI应用”或者“会训练模型就懂AI工程”这两种极端我都见过也都被坑过。真正的AI工程是数据和模型之间的黏合剂是评估和交付之间的桥梁是从一个粗糙的想法到一套稳定系统的全过程管理。这篇文章适合谁适合那些刚入门、想系统构建AI工程能力的开发者适合已经在做AI应用、但总感觉在“调包”和“拼凑”之间反复横跳的从业者也适合团队里负责技术选型和项目落地的同学你们需要一套能说服自己、也能说服业务的完整逻辑。我尽量把话说得直白所有技术和术语都会解释清楚但不会为了照顾小白而牺牲深度因为工程本身就是一门关于取舍和细节的学问。1. 内容整体设计与思路拆解先搞清楚一个核心问题当我们说“从零开始做AI工程”这个“零”到底是什么不是零基础不是说你连Python都不会就能来搞AI那叫从零学编程。我这里的“from scratch”指的是抛弃那些“开箱即用”的黑盒方案从AI系统最底层的逻辑开始重新理解每一个环节为什么存在、为什么被设计成这样。1.1 核心需求解析两种工程师的认知断层我在实际带团队和做技术咨询时发现一个特别普遍的现象算法工程师和业务开发之间存在一条巨大的鸿沟。算法工程师关注的是模型指标比如BLEU、ROUGE、F1、准确率他们觉得模型在测试集上分数涨了就是成功。但业务方关心的是用户体验、成本、响应延迟、稳定性他们根本不在乎你用的什么模型架构。而传统的后端开发呢他们熟悉高并发、缓存、数据库索引但一碰到“模型返回的内容是概率性的、每次都不一样”就抓狂觉得这玩意儿没法做工程。这个鸿沟恰好就是“AI工程”这个学科要填的东西。我整理这个项目时第一件事就是把这套认知断层可视化。整个仓库的目录结构就是按这个逻辑来的先从问题定义和数据出发然后到建模和评估再到部署和运维最后是反馈和迭代闭环。这不是我拍脑袋想的是我被现实毒打之后总结出来的。早期我做的第一个所谓“AI项目”特别天真拿到数据就直接丢进模型训练训练完看loss降了就欢天喜地结果上线第一周就被业务方骂了四次——不是模型不work而是我压根没有定义清楚“什么叫做work”。所以这个项目的第一个大章节是帮助读者建立一个完整的AI工程思维框架而不是急着写代码。我见过太多人一上来就抱着Transformer论文啃啃完发现连数据清洗都不会这完全本末倒置了。真正的从零开始是先从系统视角来看问题你要解决什么业务问题这个问题的输入输出边界在哪用什么指标来衡量做得好不好数据从哪里来、质量如何这些问题想不清楚后面每一步都是空中楼阁。1.2 方案选型背后的逻辑为什么拒绝“拿来主义”这个项目里我刻意避免了一件事直接告诉你“用LangChain吧”或者“用LangGraph吧”。不是说这些工具不好而是它们对新手来说是个巨大的陷阱。我自己早期就掉进过这个坑用LangChain搭RAG应用半小时就能跑通但出了错根本不知道是哪里出了问题。链子断了、上下文丢了、召回不准、生成幻觉你只能一层层扒源码最后发现是某个封装太黑箱导致的。我后来想明白了一件事框架是别人对通用场景的抽象总结但你的业务永远有特殊性。如果你不理解底层的逻辑一旦情况超出框架预设范围你就寸步难行。所以这个项目里我坚持“用最小实现讲透原理再引你去看工业级方案”。比如讲RAG我会先带你用一百行左右的代码把一个最简的检索增强生成链路写出来让你亲眼看到Embedding是干什么的、向量检索是怎么算相似度的、上下文是怎么拼接给模型的然后再告诉你理解了这些之后你去看LangChain源码就能看懂它在每一层帮你做了什么。这种从原理到工具、从手动到自动的路径看起来很笨但却是最扎实的。我带的几个实习生按这个路径走下来基本三周之后就能独立排查RAG系统的各种诡异问题因为他们知道每条数据在系统里是怎么流动的。而对比那些直接上手LangChain的同学遇到问题只能靠猜靠改参数试这是完全不同的成长曲线。1.3 影响范围分析AI工程在2025年的应用全貌这套工程能力到底能用在哪些场景我整理项目时做了一个横向梳理至少覆盖了下面这些主战场知识库问答与RAG系统这是目前落地最广的方向企业内部的文档检索、客服自动问答、法律条文辅助检索都属于这个范畴核心难点在召回准确率和引用的可追溯性。自动化内容生产包括营销文案批量生成、周报总结、会议纪要整理、多语言翻译分发核心难点在风格一致性和事实准确性控制。数据分析与决策辅助让大模型直接查数据库、生成分析报告、做异常检测归因这里要解决的是模型和结构化数据之间的连接问题。智能体工作流Agent把模型从“回答问题”升级成“执行任务”比如自动处理工单、自动排期、自动写代码修bug这一块目前还在快速演进但工程框架已经基本成型了。行业垂直模型微调在通用模型基础上用领域数据做继续训练比如医疗、金融、法律用语适配这里涉及数据合规、评测体系、灾难性遗忘等一系列工程问题。不同应用场景的技术侧重点差异很大但底层的工程骨架是共通的。这也是我把仓库设计成“主线分支”结构的原因主线讲通用工程链路分支按场景展开专项案例。后面几章我会详细拆解这条通用链路里最重要的几个环节给你一套拿来就能用的实操路径。2. 核心技术解析大模型应用开发的4个关键层级进入技术细节之前我想先打破一个误区做AI工程不等于写模型。2025年的今天绝大多数业务场景根本不需要你从零预训练一个大模型成本和数据的门槛都不是小团队能承受的。你需要的是“模型应用工程化”的能力也就是把已经存在的强大模型通过一系列工程手段接入你的业务系统。2.1 模型接入层API调用之上的工程考量现在主流的模型接入方式有几种直接调用商业API、部署开源模型、或者两者结合的混合架构。很多刚入门的同学选了最省事的商业API以为就是把key填进去发个请求这么简单但真正的工程问题全在“请求”之外。首先是延迟和成本建模。大模型推理是出了名的慢和贵一个中等复杂度的对话请求生成500个token在标准配置下可能要花3到10秒调用成本一次从几厘钱到几分钱不等。如果你的系统要服务一万个用户高峰期并发一上来延迟会指数级恶化。我在项目里专门放了一套压测脚本自己搭过环境应该知道不压测你永远不知道系统到底能扛多少流量。其次是上下文管理策略。大模型的上下文窗口是宝贵的资源尤其在做RAG或者Agent的时候你不能把所有历史对话和检索到的文档全都一股脑塞进去。这里涉及截断、压缩、摘要递归等一堆策略每一项都要结合你的业务场景去调。再者是错误处理与降级方案。模型接口会超时、会限流、会返回异常格式这种种概率问题在工程上必须有一套优雅的处理机制。我在生产环境里遇到过一次特别典型的故障大模型供应商临时上线了一个新版本行为产生了微小的偏移导致我们系统的输出格式解析大面积失败。这种事情防不胜防所以你的接入层必须有格式校验、失败重试、以及人工介入的兜底通道。2.2 模型选择层基座选型的评估矩阵不少新人喜欢追新哪个模型一发布就立刻换上去这是大忌。模型选型应该是一个工程决策不是追星行为。我在项目里整理了一套多维度的模型评估矩阵你选任何基座模型时都要把你关心的指标量化和加权评估维度具体指标考量方式任务能力在与你业务最接近的评测集上的准确率/得分必须自己构建测试集不能只看公开榜单推理成本每千token的输入输出价格或单次推理的硬件成本结合业务调用频率做成本估算推理延迟P50、P95、P99的响应时间二维码比大小P95才是用户体验的真实指标上下文长度最大支持token数长文本下的稳定性注意很多模型号称128K但长文本下效果衰减严重生态兼容是否支持流式输出、结构化输出、函数调用等这些能力直接影响工程实现复杂度部署难度显存占用、推理框架适配、许可协议限制开源模型不等于免费商用要看清协议我一般会给团队一个模板化的评估流程先根据业务场景构造一批有代表性的测试样本再让候选模型在这些样本上跑一轮盲测统计分析出各家表现。这个流程听起来麻烦但真能帮你省下后面所有迭代的坑因为你才掌握自己业务的第一手情报而不是全依赖于别人的榜单。2.3 数据工程层AI系统最容易被低估的地基数据的重要性我再怎么强调都不为过。很多做AI应用的人居然没有一套正式的数据收集和管理的流程样本散落在各个聊天记录里测试集完全没有标注标准这种项目做出来的系统上线翻车是必然的。我自己的经验是数据工程至少要做三件事数据采集、数据清洗、数据标注。数据采集要解决“数据从哪来”的问题你得理解业务场景中哪些是真实用户的真实请求这些请求会以什么形态出现在系统里。数据清洗则要解决“数据能不能用”的问题去重、去噪、格式标准化、敏感信息脱敏每一步都要有明确的规则。数据标注则是决定“数据质量上限”的关卡你到底期望模型输出什么答案这个标准非定清楚不可。很多团队觉得标注就是活多人傻的体力活其实不然标注标准的制定是最高级的工作之一。我在项目里专门讲了如何设计一套高质量的标注规范包括怎么定义样本难度、怎么处理边界情况、怎么做标注一致性检验。说实话一个标注标准写得好的团队后面做评测和微调都会顺很多因为系统评价的标杆立住了。2.4 评测层比“感觉还行”靠谱一万倍的体系化评估评测可能是整个AI工程里最不受重视但最致命的一环。80%的团队跑通demo之后就直接上线了然后靠着用户反馈来“盲人摸象”式迭代。用户说结果不对运营转给开发开发改个prompt试试运营拿去测又不行……这个循环效率极低。好的评测体系应该像一把尺子保证你的每次改动都能被度量。在项目里我把评测拆成两个层面离线评测和在线评测。离线评测发生在系统上线前你在固定的测试集上跑一套标准化的打分逻辑比如RAG场景的召回率、生成场景的事实一致性、分类场景的准确率。在线评测则是在线上运行时的监控指标比如用户点赞率、采纳率、反馈提交率这些虽然延迟高但最真实。这里我要特别强调一个新手常犯的错误建了一个包含大量简单样本的测试集导致评测分数虚高上线后遇到了稍微复杂一点的用户请求就崩。所以构建测试集时难度分布要尽可能贴合真实场景甚至要有意加入一些“刁钻”的样本测试系统边界到底在哪。3. 实操过程与核心环节实现从零到一搭建一个RAG知识库问答系统前面讲了那么多框架和原理这一章我用一个具体的案例带你完整走一遍流程。我选的是最经典、应用最广的RAG检索增强生成场景目标是从零搭建一个企业内部知识库问答机器人。这个案例能覆盖AI工程的大多数核心环节而且需求明确、效果可感知。3.1 阶段一问题定义与基准线建立老规矩动手写代码之前先想清楚问题和评价标准。假设场景是给公司做一个内部IT支持问答机器人帮员工解答关于请假流程、报销规范、软件使用等日常问题。第一步列出系统的输入输出定义输入是员工用自然语言提问输出是准确且引用文档来源的文字答案。这里有两个关键点需要提前定义一个问题是“什么算正确答案”标准是答案必须能从知识库文档中找到对应原文作为支撑不能是模型自己编造的另一个是“覆盖哪些问题范围”初期只支持IT和行政事务超出范围要礼貌地告知无法回答。基于这些定义我要准备一份初始测试集。我手动收集了大约100个常见问题覆盖各个子领域并把每个问题按难度分了三级简单可直接从一段话找到答案、中等需要跨段落拼接信息、困难包含复杂条件判断。这份测试集在后续所有迭代中都会作为核心评测基准先建立baseline是防止后面迭代时失去方向。3.2 阶段二数据准备与文档切片知识库问答系统的地基是你要喂给系统的文档本身。我见过很多人图省事把几千字的PDF整本扔进去效果自然很差。大模型的上下文窗口虽然越来越大但“窗口放得下”和“能准确理解”完全是两回事太长且混杂的文本会淹没关键信息。数据准备阶段核心操作就是文档解析和切片。文档解析我建议先用成熟的解析库做预处理将PDF、Word、Markdown等各种格式统一转成纯文本注意表格的处理不能简单粗暴地丢掉结构。切片策略就有讲究了纯按固定长度切片会产生大量语义不完整的片段。我用的方案是结构优先混合切片优先按文档的段落标题、列表项、表格行等结构边界切片如果某个结构块过长再按一个带重叠窗口的长度阈值二次切分这样既保证了语义完整性又能控制每段的长度。切片做完了不要急着去embedding先人工随机抽取几十个切片读一遍检查有没有乱码、重复、语义错乱的问题。这一步花不了多少时间但能保住你下游所有流程的质量。3.3 阶段三向量化与检索链路的搭建现在的RAG系统大多采用“向量检索关键词检索”混合召回的方式我来拆解一下原因以及具体实现。向量检索擅长处理语义相近的查找比如用户问“年假怎么休”文档里写的是“带薪休假制度”两者没有字面重叠但语义相关关键词检索适合精确命中的场景比如员工工号、特定系统名称等。两者结合效果比单用任何一个都好很多。向量化我用的是开源的Embedding模型比如BGE系列或者最新的混合检索模型具体选型要实测对比。基本流程就是先把上一步切好的文档切片全部灌入模型生成对应的向量存入向量数据库。向量数据库我推荐先从小型可自托管的方案上手把核心概念跑通理解什么是索引、什么是相似度计算后面再根据数据规模决定是否引入分布式方案。检索链路方面我给出一套精简但完整的逻辑先用向量检索取每个问题最相关的前K个切片K值预设为8到12之间再做一次基于关键词的BM25检索同样取前K个把两路结果合并去重按融合分数排序取最终Top-N这里N我一般设5到8。之所以不直接用检索列表的全部结果是为了控制拼接进上下文的内容长度。最后把这些Top-N个切片按顺序拼接到prompt里同时附上格式化的引用来源让模型在生成答案时可以指出来源。3.4 阶段四提示词工程与可控输出设计很多人以为提示词工程就是写一段“你是XXX专家”之类的角色设定这个理解太浅了。真正的提示词工程是把系统行为约束和输出格式约束都塞进一段结构化的文本里。我在实际项目中用到的提示词模板至少包含以下要素角色与目标、输入知识库内容标识、回答的行为准则、处理“不知道”情况的策略以及强制输出格式的JSON Schema说明。这里分享一个我亲测有效的经验对输出格式的控制不要只写在prompt里让模型“自觉遵守”一定要在代码侧做双重校验。比如我要求模型返回一个包含answer和sources两个字段的JSON哪怕prompt写得很清楚模型偶尔还是会输出Markdown格式的代码块包裹、或者多了逗号导致JSON解析失败。所以我的做法是解析层尽可能宽容能修复轻微格式错误就自动修复修复不了就把这次请求标记为“格式异常”触发重试或者转人工兜底。行为准则的设定也很有讲究至少要包含三条第一答案必须基于提供的知识库片段不得引入片段之外的无关知识第二如果知识库中没有相关信息要明确说明“当前知识库暂无此问题的答案”第三对于涉及操作步骤的问题按步骤拆解输出并在每步末尾标注引用来源编号。这些规则听起来简单但能大幅减少模型的幻觉程度让系统行为变得有边界。3.5 阶段五离线评测与调优闭环系统能跑起来之后真正的工程重头戏才开始——评测和调优。我带团队时最常说的话就是demo是给人看的评测是给系统看的。没有评测你永远不知道一次改动是变好了还是变坏了。我用的离线评测流程是这样的先对初始测试集里的100个问题逐条跑一遍系统的完整链路收集答案、引用来源、响应耗时、解析状态。然后根据事先定义好的评分标准来逐条打分。RAG场景的评分标准我一般分三部分答案准确率人工判断回答是否准确解决了问题引用正确率检查模型指出的引用来源是否真的支撑了答案格式合法率检查输出格式是否完全符合约定结构。第一轮跑完几乎肯定会发现一批bad case。我通常会把bad case归成几类检索失败相关片段没被召回、生成错误召回对了但答案不对、格式异常模型没按规定输出。每一类问题的解法都不一样。检索失败要调切片策略、调Embedding模型或者增加关键词检索权重生成错误要优化提示词、调整拼接的上下文排序格式异常要加解析后置校验和修复逻辑。改完之后重新跑一遍完整测试集确保修复旧问题的同时没有引入新问题。这种“bad case驱动”的迭代模式是我认为效率最高的调优方法。3.6 阶段六部署上线与性能压测评测通过后就该考虑怎么让它稳定跑在生产环境了。很多开发者在本地跑demo挺开心一上生产环境就原形毕露因为在本地没人跟你抢资源网络延迟可以忽略不计。真的部署要考虑的事情非常多。我来说说部署架构里的几个关键决策。如果用的是商业API那么你的部署重点在于请求转发层需要设计好缓存、超时、重试、降级的逻辑如果用的是开源模型自托管那要关注推理服务框架的选择典型的如vLLM、SGLang等这些框架对高并发推理的支持远好于裸的Transformers库读入模型直接推理。缓存是一个经常被忽视的性价比神器。很多知识库问答场景中用户的问题是高度重复的比如“怎么修改密码”“报销单怎么填”这种每周被问几十上百次。如果你在系统里加一层基于语义相似度的缓存层把问过的问题和对应答案存下来后续重复或高度相似的问题直接命中缓存返回不仅能大幅降低推理成本还能把响应时间缩到毫秒级。我在实际项目里靠这个缓存让一个日活几千人的内部系统大模型API调用费用直接降了七成左右。性能压测也不能省。我自己写的压测脚本会模拟不同并发数下的请求记录P50、P95和P99延迟看系统在什么压力下开始变慢。压测还有一个目的测出系统在负载下的错误率。如果每秒并发只有5个就出现大量超时和解析失败那说明架构设计有问题不能在线上用。4. 常见问题与排查技巧实录这部分我整理了在长年实战中遇到频率最高的几个问题每一条都是真实踩过坑之后总结出来的解决方案。如果你在搭自己的系统时碰到了类似问题直接照方抓药就行能省下大量排查时间。4.1 检索结果一团糟命中率低是病根RAG系统最常见的问题就是用户问了一个问题检索出来的文档片段完全不相关导致模型只能瞎编。这个问题我遇到太多次了排查思路基本是从下往上逐层看。先看数据源文档本身的编码、解析、切片是否有问题。打开向量数据库随便查几个切片内容如果发现切片里都是乱码或者包含大量无意义的导航字符根源在数据清洗。再看Embedding模型你用的向量化模型对中英文混排、专业术语的处理能力如何如果选了一个中文效果很差的模型召回率肯定上不去。最后看检索策略K值是不是设置得当熔断阈值最低相似度下限是不是设置得太高或太低太低会把一堆无关片段带进来太高则会漏掉真正有用的内容。我个人的排查顺序是先跑一个最简单的“直接按字面关键词搜索”如果这个都能搜到而向量检索搜不到那多半是Embedding模型对语义理解不到位如果关键词也搜不到那问题多半在前面几环切片或解析环节把关键内容切坏了。用这种二分法排查能非常快速地缩小问题范围。4.2 模型幻觉问题引用了不存在的来源这是RAG系统最伤信心的问题模型给的答案有模有样但引用的文档来源里根本找不到对应内容。用户信手点开引用一看发现被引用的文档根本不是那个意思系统信任度瞬间垮掉。解决幻觉问题我从两个方向同时下手。方向一是在生成端的prompt里加严格约束比如明确要求“如果知识库中没有可用信息只说不知道”同时告诉模型更优的做法是在拿不准的时候少说为妙。方向二是引入事后的验证环节把模型输出的关键信息反向映射到引用片段中去做一个简单的基于文本重叠的核验如果发现模型输出了大量引用片段中完全没有的内容就把这次回答标为“低置信度”不进入正式回复通道。这个方法不能100%消除幻觉但能把幻觉出现率压到可接受范围之内。我始终觉得AI系统追求的目标不是0幻觉而是把幻觉控制在用户能感知、系统可兜底的范围内。4.3 并发一高就延迟爆炸很多系统在并发低的时候响应流畅并发一上去就崩溃这是典型的“没有做资源规划”的表现。大模型推理是计算密集型任务如果没有把无状态服务和有状态的推理过程分开所有请求都直接打到模型推理进程上延迟必然会随着并发线性甚至指数级上涨。这个问题有三板斧可以处理第一板斧加缓存把重复或高相似度的请求拦在推理之前这部分前面已经讲过了第二板斧对推理请求做队列化处理设定最大并发数进来多的任务先排队不要让请求一窝蜂地涌向模型第三板斧如果用的是自托管模型要做推理服务化部署利用连续批处理等技术把吞吐量拉高而不是一个请求一个请求地跑。另外一个常见低性能点是串行调用导致的级联延迟比如一个问答请求你要先做向量检索然后做关键词检索两路完成后合并再调大模型。如果这几步是串行的总耗时就是各部分相加。优化思路是把向量检索和关键词检索并行化两路同时跑等两边结果都齐了再做合并这样总延迟就从“一加二”变成“一和二取大”效果立竿见影。4.4 评测指标与真实体验脱节这个问题的隐蔽性特别强系统离线评测分数很好看上线后用户就是不买账。原因往往是评测指标选错了或者测试集和线上数据分布不一致。举一个我实际遇到的例子某个客服问答系统离线评测时我们主要看答案准确率业务方也觉得不错结果上线第一周用户平均反馈分惨淡。后来一查发现用户反馈里有很多“回答得太啰嗦”“没有直接告诉我怎么操作”的抱怨。原来我们的评测只看“信息是否正确”但没有把“答案是否简洁直接”作为重要评判维度。后来在评测标准里加了“步骤指令覆盖率”和“答案简洁性”指标专门针对操作类问题做了更多测试再优化了一版prompt情况立刻好转。这给了我一个很重要的教训评测指标一定是从业务目标反推出来的而不是从技术能力顺着做的。先想明白业务上什么行为是好的再反推用什么指标去度量。这个顺序一旦搞错你后面所有的调优都可能是在原地打转。4.5 常见问题速查表问题现象可能原因排查与解决方案检索召回完全不相关文档解析损坏、切片语义断裂、Embedding模型不匹配先直接关键词搜索能搜到则优先换Embedding模型答案引用来源对不上幻觉或检索结果混杂无关内容prompt加“信息缺失即说不知道”加引用核验环节请求延迟飙高无缓存、串行调用、推理进程过载加语义缓存、并行化两路检索、推理服务化部署高并发下解析失败率增加模型输出超时导致token截断、格式不完整设置合理超时时间、加重试与降级逻辑、对输出做后置修复离线指标好但线上用户不买账测试集分布偏离线上真实场景采集线上真实用户问题入测试集按难度分层维护模型回答风格不稳定缺少系统级行为约束完善prompt行为准则必要时对输出做规则后处理5. 项目进阶路线从RAG到多Agent系统如果你把上面这个RAG案例完整地跟做了一遍你的AI工程地基可以说已经打得相当扎实了。接下来我想给你一个进阶路线的参考。AI工程这个领域最迷人的地方在于它永远有下一层复杂度等着你去解锁。5.1 多Agent协作把任务编排交给系统单一RAG链路解决不了的问题往往需要引入“多个不同角色的模型协同工作”。我举个例子做一个“智能项目周报生成助手”如果只是单纯地跑一次RAG你得到的答案可能只是资料罗列不够有条理。但如果你拆成三个角色的Agent一个Agent负责从聊天记录和项目管理工具里收集所有本周事项一个Agent负责把事项分类并补全关键信息还有一个Agent负责梳成结构化报告并检查是否有数据遗漏每个Agent各司其职效果就会完全不一样。多Agent系统的工程复杂度体现在任务编排、状态管理和消息传递上每一个环节都需要严谨设计。在项目里我把这套拆解成了几个核心模式流水线模式适合固定流程的任务路由模式适合根据用户意图分发到不同专家的场景协商模式适合多个Agent对同一个问题做交叉验证的场景。先掌握这三个模式大部分业务需求都够用了。5.2 微调实战什么时候需要什么时候千万别碰很多人问我什么情况下需要微调什么情况下做个RAG就够了。我的回答很简单先做RAG和提示词优化把能榨干通用模型能力的空间都榨干再思考要不要微调。如果确实面临以下两类问题再考虑微调一个是风格或者输出格式有极其固定的要求通用模型怎么提示词都学不会另一个是领域知识有大量高频的特殊表达连RAG都很难稳定检索到。这两种情况下微调能显著提升效果。但微调绝对不是免费的午餐。数据量小了容易过拟合数据质量差还不如不调微调之后还可能发生“灾难性遗忘”也就是模型学会了你的领域表达却忘了通用的问答能力。所以我的建议是微调前先做一轮成本收益分析把数据准备的工作量、训练的资源成本、评估的体系建设都算进去千万不要头脑一热就开训。5.3 持续迭代的工程文化AI系统的护城河最后这点想聊点务虚但重要的事情。AI系统的护城河根本不在你用了多厉害的模型而在于你的团队能不能持续、系统化地迭代它。模型会更新、会替换、会上涨价格但你的数据资产、评测体系、迭代方法论这些才是真正壁垒深厚的东西。在做这个项目的过程里我把大量篇幅留给了评测流程、数据标注实践、bad case分析模板这类“不那么酷”的东西因为它们才是AI工程长期运转的血液。是从零开始不只是从零开始学技术更是从零开始建立一套严谨的工作方法。我真心希望读这套项目的人最终收获的是一种——拿到一个AI需求时心里有完整的执行路径、知道每一步怎么做、出了bug知道怎么查的底气。这种底气是刷再多的Demo都换不来的这是真正工程化的力量所在。