从收藏夹工程师到能独立跑通一个AI项目中间到底隔了什么我这几年接触过不少想入门AI工程的人几乎每个人都存了一堆教程、刷过几个模型Demo、跑通过一两段示例代码但等真要自己从零搭一个能落地的项目时要么被环境配置劝退要么被一堆看不懂的指标卡住要么做出来的东西一换数据就崩。我后来重新梳理了自己从零搭建AI工程能力的过程发现真正起作用的不是刷了多少论文而是有没有一条以工程落地为终点的学习路径。这篇内容就是把我走通的路完整复盘一遍从环境底座到机器学习基础从深度学习训练意识再到端到端项目实操适合那些不想停留在跑通Demo、想真正具备独立AI工程能力的人。我理解的from scratch不是指从张量求导、推数学公式开始而是指不依赖别人写好的完整解决方案自己能把一条AI应用的链路从头到尾搭建起来。这个能力分层很明显底层是工程环境和数据管理中间是模型训练与调优的基本功上层是大模型的工程化接入能力最后是拿一个真实项目把所有技能串起来。下面我按自己重学时的顺序把每一层展开讲。1. 别急着装PyTorch先想清楚AI工程的底座是什么很多人学AI的第一个动作就是pip install torch然后照着教程训练模型结果做到一半发现环境乱了、结果复现不了、换了台机器直接跑不起来。这些问题看起来都跟AI无关但恰恰是它们最消耗精力。我后来才意识到AI工程首先是工程其次才是AI。1.1 AI工程和AI研究的本质区别AI研究者追求的是在某个任务上效果更好核心指标是准确率、召回率这类模型指标AI工程师追求的是在约束条件下稳定交付核心指标是可复现、可维护、可上线、成本可控。这两种目标导致的工作方式完全不同。研究环境里模型跑通一次就算成功工程环境里模型今天能跑通下周、下个月、换个人、换批数据都必须还能跑通。这就是为什么工程化要从第一天开始考虑环境隔离、依赖锁定、数据版本这些不性感的事。我自己见过太多反面例子同事的A100机器上能跑的代码挪到我的4090上就报CUDA版本错误昨天训练好的模型今天重新加载权重发现指标对不上数据文件被覆盖了一次整个实验结论无法追溯。这些问题没有一个跟模型结构有关却足以让项目停滞。1.2 环境管理我最终留下的组合方案Python环境管理工具五花八门pip、conda、poetry、uv、Docker每个都有拥趸也都有各自的坑。我重学AI工程时踩了一轮之后现在固定用一套极简组合Python版本隔离优先用官方方案或uv管理具体Python版本尽量别让系统全局Python和项目Python混在一起。依赖管理项目根目录放requirements.txt如果需要更严格锁定用uv lock这类机制把版本完全固定下来。一致性兜底涉及模型推理部署、或者要和同事共享运行环境时直接上Docker镜像。uv是这几年我用过最顺手的Python包管理工具它把虚拟环境创建和包安装合在一起速度比pip快很多。我们以往用conda create -n xxx python3.10创建完环境后还要等解析依赖遇到渠道不稳定时解析能卡十几分钟我用uv后从创建环境到装完常见深度学习依赖torch、transformers、pandas、scikit-learn通常几分钟搞定。提示我见过最多的问题是把anaconda的base环境当成万能环境用了五年里面装了几百个包版本互相冲突最后连装个新版numpy都会破坏已有项目。正确做法是每个项目一个独立环境环境里只装这个项目真正需要的包。1.3 数据版本和实验记录项目做大了才懂的事代码有git管着但数据没有版本管理的话实验复现就是一句空话。我做第一个项目时犯过一个典型的错数据在本地被反复修改等模型效果变好时想复盘到底用了哪版数据根本说不清楚只能从头再来一遍特征工程。现在我哪怕做一个很小的项目也会先做两件事一是给数据打版本。不需要一开始就上DVC这种重型工具最简单的做法是把原始数据放到一个只读目录里任何清洗、变换的中间结果都单独存目录目录名带上日期和原始数据的hash值。等流程跑通了、确定数据不会再变再把数据目录接入git或DVC。二是给实验做记录。我的习惯是每次训练实验都维护一份简单的Markdown记录内容包括实验编号、目标、数据版本、模型结构、关键超参数、训练时长、最终指标、样本案例截图、下一步计划。这份记录不追求正式但它是你判断模型为什么变好/变坏的唯一依据。有了环境隔离、依赖锁定、数据版本和实验日志这四样东西后面的所有技术才有意义。否则你学再多的模型原理做出来的项目也无法形成可积累的资产。2. 机器学习基础两个月速通不刷论文但要把两个原理焊死我见过一些直接跳到大模型的人Prompt写得头头是道但一聊到什么是过拟合、什么是类别不平衡、为什么交叉验证结果比单次测试更可信就支支吾吾。这些经典机器学习的概念恰恰是评估大模型效果、调优RAG检索质量时绕不开的底层逻辑。我自己重学时的原则是不追求把所有算法都推导一遍但一定要亲手做两个小项目把评估方法论和数据质量意识焊死在脑子里。2.1 为什么先学经典ML而不是直接上大模型原因特别简单大模型是一个巨大的黑盒它把太多东西混在一起了。你在几十亿参数模型上做一次改动很难判断效果变化到底来自数据、提示词、模型版本还是随机性。而经典机器学习模型小、训练快、可解释性强你可以清晰地控制变量快速建立改动→影响的因果直觉。这套因果直觉恰恰是大模型工程里最值钱的能力。在AI领域如果连小模型上的反馈回路都搞不明白直接跳到黑盒大模型上只会更迷茫。有一个类比我经常用先学做饭再学开餐厅。经典ML是学切菜、掌握火候、理解调味原理大模型工程是开餐厅需要管供应链、定菜单、控品质。你不会切菜餐厅一开业就会乱套。 training过滤器 你不需要掌握每个模型的公式推导但必须懂数据质量和评估指标这两件事。2.2 项目一用XGBoost做房价预测但重点放在残差分析上第一个项目我建议做一个经典的回归任务比如房价预测。数据集可以随便找开源的房价数据但重点不在预测精度而在训练之后的诊断过程。我当时用XGBoost跑通流程后先画了预测值和真实值的散点图然后画了残差分布图。这个动作很关键只看RMSE数值你只能知道平均误差是多高但残差图能告诉你模型在哪些区间系统性偏差大。比如我发现高房价区间的残差普遍为正预测偏低说明模型在样品稀缺的高端市场上学得不够。这个诊断直接引导我做了两个调整对房价做对数变换压缩高位区间以及增加高房价区域的特征交叉。经过调整后RMSE改善其实有限但模型在不同价位段上的表现均衡多了。2.3 项目二客户流失预测重点体会准确率骗人第二个项目是分类任务我当时选了客户流失预测因为这种业务数据通常存在严重的类别不平衡——大部分客户不会流失流失的只占一小部分。我一开始训练的模型准确率有91%看着挺高。但仔细一看混淆矩阵发现模型几乎把所有用户都预测成不流失。因为流失用户只占9%只要一律预测不流失准确率自然就是91%。可这样的模型对业务毫无价值。准确率骗人是我在这个项目里最深刻的教训。随后我把评估指标换成Precision、Recall、F1重点关注流失用户的召回率并对少数类做了重采样、调整了分类阈值。模型准确率降到85%但对流失用户的识别率从个位数提升到接近70%这才是对业务有用的模型。类似地在大模型评测里也会遇到准确率陷阱。如果评测集90%的问题模型都能答对你的系统就算把剩下10%全答错准确率依然很高。因此评测必须拆到细粒度维度逐个能力去看。这套意识就是从经典ML项目里养出来的。3. 深度学习从0到1先学会观察训练而不是堆模型传统机器学习的流程相对直白数据整理、训练、调参、评估。但到了深度学习出现了一个全新的环节——观察训练过程。模型在训练中loss怎么变化、梯度是否稳定、验证集是否跟随训练集一起下降这些信息直接决定了模型能不能收敛、会不会过拟合。3.1 训练的本质参数在损失曲面上下山理解深度学习不需要一开始就啃复杂的数学推导可以先建立一幅物理图像模型训练就像一个人站在一片连绵的山地上脚下的海拔就是损失函数目标是找到一个足够低的谷底。每个超参数实际上都在改变下山的方式。学习率决定了下山的步子迈多大。步子太小走到天黑也没走多远步子太大一步跨过谷底甚至在陡峭地段直接摔飞loss发散。Batch Size决定了你每次看多大范围的局部地形。看全量数据Full Batch就像用高清卫星图找路稳定但非常慢小Batch就像边走边看有随机性但探索能力更强。归一化的作用是把崎岖的山地变成相对光滑的斜坡让下山过程不容易卡在奇怪的沟壑里。这套下山物理图像我是在一次学习率扫描实验里彻底理解的。3.2 一个必做的实验学习率扫描我当时在MNIST上用一个小型CNN做了学习率扫描固定网络结构、固定Batch Size64训练时把学习率分别设为1e-4、1e-3、1e-2、1e-1然后对比四个训练曲线。结果非常直观学习率训练曲线表现结论1e-4loss下降极慢10个epoch后还处于高位步子太小下不了山1e-3loss稳步下降训练和验证同步改善接近理想状态可以进一步微调1e-2前期下降快但后期loss出现震荡验证集不再改善步子偏大需要在收敛时调整策略1e-1loss直接发散数值变成NaN步子太大摔下悬崖这个实验带给我最大的启发是不要静态地看待超参数。学习率本身没有好坏关键是它和你的数据、损失面、Batch Size组合后的动力学是否匹配。后来我做大模型微调时第一件事仍然是先跑几步学习率扫描而不是直接套用别人的默认值。3.3 训练环节的坑loss不降问题可能不在模型我第一次训练一个稍复杂的模型时遇到一个典型情况loss前几个epoch下降很快然后突然持平甚至反弹。我当时怀疑模型结构有问题排查了两天改了各种网络结构都没用。最后偶然注意到自己的DataLoader里忘了打开shuffleTrue——数据批次之间的顺序高度相关模型在相邻batch里看到几乎一样的数据梯度方向单一于是陷入循环。这个教训非常深训练出问题的时候排查顺序应当是数据流 → 配置 → 模型。我当时后来养成一个习惯每次训练前先单独跑一波数据加载器用肉眼看几个batch确认标签和样本对得上、每个batch的数据分布有差异。数据流验证通过之前绝不动模型代码。这个习惯帮我省下过无数次无意义的模型调参。另外还有一个非常隐蔽的坑数据预处理一致性。训练时对图像做了归一化推理时如果忘了做同样的归一化模型精度会骤降。这类问题出现频率比我们想象的高得多尤其在涉及视频帧、文本序列这类异步处理数据时。4. 从CNN到大模型关键的思维转折CNN时代做AI工程核心是训练自己的模型大模型时代做AI工程核心变成了组装已有能力——把预训练好的大模型通过提示词、检索增强、微调、工具调用等方式组合成能解决实际问题的系统。4.1 大模型时代的工程能力新定义我在刚接触大模型时犯过一个方向性错误试图用自己有限的算力去微调一个大模型来解决所有问题。后来才明白大模型工程的价值不在于炼模型而在于设计信息流和反馈流。举一个例子同样要让模型回答公司内部制度问题。一个是把几千页制度文档拿去微调另一个是搭一个检索系统让模型先检索相关段落再回答。后者的效果好得多、成本低得多、更新还快。这就是大模型时代的工程思维——模型权重本身是商品围绕模型的信息流转才是你要设计的产品。这个思路我后面做知识库问答时全程都在实践。4.2 注意力机制用查档案来理解它如果不用数学符号硬推缩放点积注意力其实可以通俗理解成这样模型手里有一堆档案Key用户提了一个问题Query模型要做的是拿着这个问题对照档案目录打分找出与问题最相关的信息Value然后把这些信息汇总起来生成答案。这带来一个很自然的工程推论如果档案太长模型翻找的效果就会变差。这也就是为什么大模型有上下文窗口却并不天然擅长长文本外推。你的工程方案要靠检索等手段把喂给模型的内容压缩到它的有效能力范围内而不是指望把整本书塞进Prompt里。理解这个原理之后你就不会犯那种我的Prompt写得极其详细但模型还是答不对的错误因为问题很可能不是Prompt写得不够好而是输入给模型的相关信息没有被有效地检索和筛选出来。4.3 本地模型还是API一张判断清单大模型落地时的第一个选择是用API还是本地部署。我自己的判断框架是这样的维度本地模型API模型数据隐私数据不出内网合规压力小需要评估数据是否允许外传成本曲线硬件投入高但推理量越大边际成本越低按量付费适合负载波动大、冷启动快的场景效果天花板取决于可选的模型规模和硬件配置通常更容易拿到顶尖效果运维复杂度需要自己处理并发、热更新、GPU调度平台帮你处理大部分底层问题选型建议就一条凡是数据允许传到外部API的优先用API跑通业务闭环。业务没跑通之前别在硬件上做重投入。数据敏感的再考虑本地化部署那些开源模型——真正跑起来后你会发现推理速度、并发处理比装模型本身更考验水平。5. 端到端项目实操一个本地知识库问答系统全流程前面的所有技能最终要靠一个完整的项目来验收。我给自己设定的终局项目是做一个能对本地文档进行问答的系统。这个项目覆盖数据加载、文本切分、向量化、检索、大模型生成、评估这条完整链路而且不依赖任何一键生成的成品框架核心逻辑自己写。5.1 整体链路和组件选型系统要解决的需求非常简单用户输入一个问题系统根据本地文档给出带来源引用的回答。整体链路如下文档加载读取本地目录里的PDF、Word、Markdown文档文本切分把长文档切成适合检索的片段向量化将每个片段转为向量向量检索根据问题的向量找到最相关的片段生成把检索出的片段作为上下文交给大模型生成回答选型上我用了FAISS做向量库因为项目规模是几百个文档、几万个片段FAISS足够embedding用中文数据上效果稳定的BGE系列也可以直接用云端embedding接口生成端用大模型API。我没有一开始就上LangChain这类框架而是自己实现Loader、切分器和检索逻辑。这样做虽然代码多了一点但对每个环节的掌握度是完全不一样的——框架帮不了你理解原理自己写一遍之后才能调试。5.2 每一步的参数和为什么这个项目里最容易出问题、也最值得花心思的是文本切分和检索参数。我讲讲我调参时遇到的具体情况切分长度上我一开始用常见的500字符切分比如chunk_size500、chunk_overlap50。结果测试时发现一个问题文档里某个结论往往散落在多个段落中500字符刚好把完整的论述切开检索到的片段经常只有结论没有理由。后来我把chunk_size改成200~300overlap保持在10%~15%反而让检索命中率明显提升。检索数量top-k上我一开始设为3回答较短但经常漏掉信息改成5后回答完整性提升明显。进一步调大又带来两个副作用一是上下文里噪声增加模型可能被不相关信息带偏二是token成本上升。对一般问答场景top-k5是一个折中的起点。向量检索的距离度量也值得提一下。FAISS默认用L2距离但这个指标受向量长度影响大embedding模型输出的向量如果不做归一化用内积或余弦相似度更符合语义相似度的直觉。我这里统一对向量做了L2归一化然后用内积计算相似度。5.3 检索评估先看召回再看生成这个项目让我最受益的一个习惯是先单独评估检索环节再整体评估生成效果。因为生成质量严重依赖检索质量——检索返回的内容里没有答案再怎么调Prompt也没用。我构造了一个很小的评测集挑10个典型问题每个问题标注了应该命中的文档片段。然后写了个脚本计算每个问题在top-5结果里是否包含正确文档Hit5以及正确文档在结果中的平均排名。测出来命中率只有70%然后我顺着失败的案例逐一分析发现几乎都出在文本切分上——关键信息被切断了或者片段之间重复度过高。改进切分策略后Hit5提升到90%。这里有一个特别容易被忽略的细节Embedding模型和问答模型的选型是独立优化的不能只看生成效果。检索效果需要单独用检索指标衡量生成效果用生成指标衡量。混在一起评估出问题时根本定位不了是哪一环拖了后腿。5.4 生成链路提示词设计、流式输出与容错检索做扎实之后生成环节相对简单但也有一些工程细节。我的提示词模板结构通常是角色定义、任务背景、指令要求、约束条件、输出格式。核心是约束条件部分写清楚只能根据提供的上下文回答不能编造如果上下文里找不到答案明确说不知道这是控制幻觉最有效的手段。流式输出也很重要。大模型接口的响应时间动辄几秒到十几秒如果同步等待全量结果再输出用户的体验会非常差。我实现了流式输出让用户看到回答逐字生成等待感受会大幅降低。另外请求熔断和重试是必须的我见过因为上游API偶发超时导致整个系统不可用的案例至少要有指数退避加网络异常重试机制。最后我做了一个带有引用溯源的功能回答末尾列出系统用到的原文片段编号。别看这个功能不复杂但它是把RAG系统从玩具变成可用系统的重要一步——用户能看到答案出处既能验证正确性也能在你系统答错时快速找到问题复盘。6. 容易被忽略的闭环把会做变成会评价整个AI工程链条中最容易被忽略、但在工作中价值最高的一环是建立一套可持续的评估体系。很多人做项目时靠几个手动输入的测试问题来验证效果回答问题全是感觉不错。一旦遇到新数据、上游模型升级、用户输入风格变化系统表现就会悄悄下降而你毫无感知。6.1 没有评测就没有工程这个道理我是在一次偶然的数据切换中栽过跟头后才彻底想明白的。当时知识库系统换了一批文档我手工测了几个问题感觉回答还可以。结果上线半天就收到反馈说很多问题找不到答案。我仔细排查后发现新文档的格式和原来差异很大导致切分质量下降很多关键内容被切开检索召回率掉了一大截。但如果我当时有一份固定的评测集和自动评测脚本这个问题在切换数据的瞬间就会被发现。现在我的习惯是项目的第一天就要同时建立评测集和评测脚本。评测集不需要很大10到30个有代表性的问题加上对应答案/命中文档即可评测脚本要能一键运行自动计算Hit率、答案质量等指标。这个投入在前期看似麻烦但它能保证你后续的每一次迭代都有明确的判断依据。6.2 三步收紧迭代闭环从零做一个AI项目时我建议把迭代节奏固定成三步建立基线用最朴素的方案最简单的模型、最粗的切分、最少的优化跑通整个链路记下每个环节的指标。这样后续所有的改变都有了参照物。单点调优每次只改变一个环节比如只改切分长度、只换embedding模型跑一遍评估脚本对比指标。如果不能定位到具体的改的是哪个环节这个实验就等于白做了。回归保护每次改动达到正向效果后再在完整评测集上跑一遍确认这个变化没有让其他维度退化。同一次改动里同时改太多东西往往会导致项改进被其他项拖累反而不利于判断。这套方法论我从RAG项目沿用到后来的各种AI应用里都依然适用。6.3 维护期的隐性成本项目上线不等于结束AI系统尤其如此。我维护自己的RAG系统时感受到三个绕不开的隐性成本数据漂移线上用户问的问题会慢慢偏离你的初始评测集分布一变检索效果就会下降所以需要定期从日志里收集新的、有代表性的失败案例补充进评测集。上游更新embedding模型或大模型API一升级前后效果可能有明显差异。因此升级前必须用评测集回归一遍而不是顺手就升。有次我只升级了embedding接口的版本没有跑回归第二天用户陆续反馈效果变差一查才知道新版本的向量分布和旧版本差异很大。成本监控不要只看单次调用的token成本很多项目最后都死在了没有上限的检索和生成上。我习惯给单次请求的检索数量、最大输出长度设置上限并记录每天的token消耗量。这些做下来AI系统的工程味才能真正显现出来——稳定、可复盘、可演进而不是一锅不知道下一步会发生什么的魔法汤。说到底AI工程从入门到能独立落地靠的不是知识收藏而是动手闭环。环境管理、经典模型、训练观察、大模型组装、端到端RAG、评测回归这一条链路走下来你会发现自己的核心能力早已不是会调框架而是知道每一步为什么这么做、出了问题怎么排查、效果怎么量化。我个人现在做新项目时的习惯永远是先搭评测再选模型先跑通最朴素的链路再优化。这个顺序帮我少走了很多弯路也希望这篇复盘能帮你把脚下的第一步迈得更稳一些。