1. AI工程不等于调API先搞清楚这个岗位到底在做什么我在刚进入这个领域的前半年一直觉得AI工程就是把模型训练出来、把接口调通。直到接手过一个真实项目才发现完全不是这么回事。当时团队里算法同学交付了一个效果还不错的意图识别模型精度指标很好看但到了接入生产环境那一步问题一个接一个冒出来单次推理耗时超过2秒、GPU显存峰值动不动就溢出、并发请求一多直接OOM、模型服务一崩溃whole链路全挂。那个阶段我才真正意识到AI工程ai-engineering的核心矛盾是研究与工程之间的鸿沟。研究侧重实验、指标、论文工程侧重稳定、可观测、可维护、可扩展。前者关心模型能不能work后者关心模型能不能长期稳定地work。如果一个项目只是停留在本地跑通了一个Notebook那它离真正能被称得上一个AI工程系统还有非常长的路要走。所以这篇文章我不会去教你某个具体框架的API怎么调那些文档里都有。我想分享的是从零搭建一个AI工程核心能力框架的思路——怎么从数学基础、编程能力、工具链、真实项目这条路径走过来以及在这条路上最容易被忽视、却最影响成败的那些事。适合谁看如果你是想转行进入AI工程方向的开发者、刚入职的初级算法工程师、或者是带团队的Tech Lead想梳理团队能力建设这篇文章都值得花几分钟读一读。它能帮你建立一个从零到落地的全局视图而不是继续在零散的知识点里打转。2. 从零起步的四块地基数学、代码、框架与工程习惯2.1 数学真的需要学到什么程度很多人一听到AI就害怕数学总觉得要先把线性代数、概率论、微积分全部精通才能动手。我见过太多人卡在这一步书买了一大堆结果连第一个模型都没跑起来。说句实在话今天做AI工程数学更多是作为理解工具而非推导工具。大部分情况下你不需要手推公式但你需要听懂别人在说什么。比如Transformer里的注意力机制到底在算什么东西梯度消失为什么会导致深层网络训练不动过拟合和正则化在做什么权衡。这些概念背后的数学直觉必须建立否则你调参就是纯盲调。我给新人的建议是从三块核心切入线性代数理解向量、矩阵乘法、矩阵的秩足够看懂大部分深度学习前向传播过程。概率统计理解条件概率、贝叶斯思想、分布、期望方差这是理解损失函数和评估指标的根基。微积分理解导数和链式法则知道梯度下降在做什么。不要求你记住所有公式但遇到问题时知道去查哪本书、哪个章节这个检索能力比死记硬背重要得多。等到实际项目中遇到数学问题再回过头去针对性地补这个用到才学的路线效率远高一上来就啃完三本数学书。2.2 编程能力的关键不是语言是工程化习惯技术选型上Python依然是AI工程的主语言这一点短期内不会动摇。但比Python语法本身更重要的是一组工程化习惯代码能放进Git仓库提交信息写清楚每次改动有人能看懂函数和模块的划分简洁合理一个函数只做一件事环境依赖有锁文件conda环境和requirements.txt能复现代码有基本的单元测试改了一行不影响别人不把调试用的print堆积在生产代码里这些习惯看起来不起眼但在团队写作和项目长期维护里比你会不会写一行看起来很酷的代码重要得多。我面试过不少候选人聊模型原理头头是道一看代码风格一塌糊涂——全在一个脚本里塞了两千行没有函数拆分变量命名全是data1、data2。这种代码不管模型效果多好后续维护都是灾难。另一个容易被忽略的点是Linux基础。几乎所有AI生产的运行环境都是Linux服务器而不是你的Mac或Windows笔记本。如果你对基本的文件操作、进程管理、日志查看都不熟那到了部署环节会非常痛苦。建议在学习初期就把开发环境切换到Linux或远程服务器上强制自己适应。2.3 框架选择从PyTorch开始但不是只学PyTorch深度学习框架选型上当前主流就是PyTorch和TensorFlow两家而PyTorch在研究社区和工业界的渗透率越来越高。从PyTorch入手是比较理性的选择。它的动态图机制对新手友好调试时可以随时打印中间结果出了错能很快定位。但这只是一个起点AI工程的框架栈比单一深度学习框架宽得多。在你构建一个真实系统时还会遇到这些层面的工具数据处理Pandas、NumPy、Polars大数据量下Polars的性能优势明显特征工程Spark或Flink在离线/实时场景各有用武之地模型训练PyTorch为主分布式训练时还会用到DeepSpeed、FSDP推理服务TensorRT、ONNX Runtime、vLLM不同工具的延迟和吞吐差异很大模型部署Docker、Kubernetes、Helm这些工程化部署工具反而比你想象的更常用LLM应用开发LangChain、LlamaIndex这类工具链帮你快速搭建大模型应用经验是不要一次性全学而是跟着项目走。做训练项目就重点学PyTorch和数据处理做推理项目就研究ONNX、TensorRT这些。工程领域的学习规律向来都是项目驱动知识如果没有嵌入到一个具体的场景里很快就会忘。3. 工具链收敛今天做AI工程绕不开的几套组合3.1 从模型训练到服务化一条完整链路的工具选型我自己的AI工程学习路径里工具链这一环几乎占了一半精力。倒不是因为难学而是因为工具迭代快、坑多如果没有人告诉你哪条路是相对成熟的你大概率会在各种插件和方案之间反复横跳。先说训练环节。PyTorch是主线在此基础上建议尽早接触HuggingFace生态。HuggingFace的transformers库基本成了模型和数据集的标准接口你要用BERT、GPT、Llama这些开源模型用这个库可以省掉大量重复代码。它的datasets库也值得学处理大规模数据时比手动分桶、shuffle要省心得多。训练完成后进入模型服务化阶段。这个环节新手最容易翻车因为直接复用训练时的代码往往性能极差。工业界惯用的方案有两类传统深度学习模型导出为ONNX或TensorRT格式配合推理引擎优化后部署到GPU服务大语言模型用vLLM这类专门优化推理吞吐的工具它是当前成本和性能平衡得比较好的方案vLLM的PagedAttention机制值得单独提一句。它借鉴了操作系统虚拟内存分页的思路把KV Cache这块大显存切分成更细粒度的小段管理显存利用率显著提高吞吐量能到传统方案的数倍甚至更高。我第一次用它部署7B模型时默认参数下吞吐比之前的朴素部署方案翻了三倍多这个差距是装任何优化插件都弥补不了的。3.2 大模型应用开发LangChain到底值不值得学说到大模型应用绕不开LangChain。我对它的评价是值得学但不要成为它的教徒。LangChain的价值在于它把LLM调用、提示词管理、外部工具调用、记忆管理、向量检索这些高频组件抽象成了统一接口写Demo和原型时效率很高。但同时它也是一个封装层很厚的框架出了问题排查链条比较长版本升级还经常破坏兼容性。我的建议是先不用框架自己用纯代码串一遍RAG流程读取文档、切分成块、调用嵌入模型生成向量、存入向量数据库、检索、拼装提示词、调用大模型生成答案。这个过程走通一遍你对RAG每个环节的细节就有了体感。之后再上LangChain你就能看懂它帮你省了什么、哪里需要自己定制。向量数据库这一环当前比较主流的选型有Milvus功能全、生态成熟适合数据量大、并发高的生产场景QdrantRust实现性能好API设计干净中小规模场景上手快Chroma轻量级适合原型验证和个人项目Elasticsearch如果团队本来就在用ES可以直接用它带出的向量检索能力少维护一个组件选型逻辑上我倾向于优先考虑团队已有技术栈其次是规模和性能需求最后才是功能丰富度。为一个小项目引入三个中间件维护成本比工具本身带来的收益高得多。4. 跑通一个真实项目从零构建一个文档问答机器人4.1 项目拆解先画好边界再动手工具学得再多最终都要落到一个具体项目上验证。我做过很多次教学和带新人也一直推荐一个项目企业内部文档问答机器人。这个项目的价值在于覆盖了AI工程的大部分核心环节但复杂度可控。项目目标是用户用自然语言提问系统从企业内部知识库PDF、Word、网页等杂乱的文档集合中检索相关内容结合大模型的生成能力给出答案并标注答案来源。开始之前先把系统边界画清楚。这是很多新手最容易忽略的一上来就想做一个完美的系统结果被各种边角需求拖垮。我当时定的边界是单一数据源先接入特定文档库不支持任意URL解析单语言先做中文场景不做权限体系所有用户访问同样的知识库不做多轮对话每次提问都是独立请求答案质量允许模型说我不知道不允许瞎编这些边界条件在需求确认阶段看起来像是在砍功能但正是它们保证了你能先跑通一条完整的链路。AI项目最怕的不是功能少而是半成品永远无法上线。4.2 数据准备与切分策略RAG效果的分水岭文档问答机器人的核心链路是RAG而RAG效果好坏切分策略占了六成权重。很多人在这一步图省事按固定字符数切分文档结果检索出来的片段语义不完整生成答案自然质量差。我实践下来比较稳的策略是这样的先做文档结构解析把标题、段落、表格、列表识别出来切分时优先保持语义完整性一个段落尽量不拆散段落过长时再按句子边界切并和上一段保留少量重叠表格数据单独处理转成文字描述后附在相关段落附近切分之后对每个文本块生成嵌入向量。嵌入模型这块我早期用过OpenAI的接口后来换成国产开源模型比如bge-large-zh。效果上开源模型在中文场景完全不虚最关键是自己部署可以控制数据不出内网这对企业场景极其重要。向量数据入库后索引配置里有两个参数需要用心调相似度算法中文场景我认为余弦相似度是首选语义相关性表现比较稳top-k取值也就是每次检索回的文档块数我通常在5到10之间调k太小容易漏信息太大容易引入噪声干扰模型判断4.3 生成环节提示词设计比模型大小更影响体验检索得到候选文本后进入生成环节。这里我踩过一个印象很深的坑第一次做这个项目时用了当时市面上效果最好的模型但提示词写得很随意结果回答效果极差甚至经常忘记参考上下文直接照自己的知识库回答。后来我意识到提示词设计对大模型应用的体验影响往往比模型版本迭代还大。经过多轮迭代我自己总结出一套稳定的提示词结构你是一个企业知识库助手请严格基于下面提供的【参考资料】回答问题。 【参考资料】 {检索到的文本块} 要求 1. 如果参考资料中有明确答案请直接回答并引用参考资料中的具体内容 2. 如果参考资料中信息不足直接回答根据当前知识库无法回答该问题 3. 不要编造参考资料中不存在的信息 4. 回答结束时标注信息来源的文档名称和页码这套提示词的核心价值是两条一是明确告诉模型不许编造并给了它说不知道的合法出口二是要求标注来源让答案可审计。后者在实际落地时非常重要因为业务方一旦发现模型有哪怕一次幻觉输出整个系统的信任度就会崩塌。4.4 评估环节不量化就谈不上优化RAG系统上线前必须有一套评估方式。我自己常用的有两个层面检索评估准备一批问题-相关文档标注对用召回率和命中率衡量检索质量生成评估从答案相关性、忠实度、完整性三个维度打分人工评估为主、辅助用大模型评测这一步很多项目都糊弄过去了但如果你后面想持续优化系统没有基线数据就完全无从下手。我通常会在项目一开始就抽200条代表性问答建一个评估集每次改动都能对比前后这是RAG工程能快速迭代的关键。5. 性能、稳定与成本AI工程落地时的三个隐形大山5.1 延迟瓶颈往往不在模型计算本身很多新手优化系统性能时第一反应就是换更快的模型、上更好的GPU。但实测下来RAG系统的延迟瓶颈经常不在模型推理而在其他环节。我拆过自己的系统单次回答的总耗时分布大致是这样的环节耗时占比说明文本嵌入/检索10%-20%向量数据库索引效率通常不错LLM推理50%-70%这是大头但优化空间也大网络/序列化10%-20%被很多人忽视的固定开销其他5%-10%日志、鉴权、链路追踪等如果你用LangChain这类框架还要留意它本身的开销。框架层做了很多通用处理但每多一层封装单次请求就要多消耗几十到几百毫秒。我曾经把一段走LangChain的流程重构为直接调API延迟从3秒降到了1.2秒效果非常明显。框架对原型友好但对性能敏感的生产链路值得考虑去框架化。LLM推理本身的优化方向很明确模型量化从FP16降到INT8或INT4显存占用降低、吞吐提升代价是极小精度损失批处理调度把多个请求动态拼成一个batch吞吐量能提升数倍流式输出首token延迟大幅降低用户体感更好这里说一句实话量化不是越激进越好。我之前在一个模型上直接上INT4结果输出质量肉眼可见下降。建议先跑INT8效果不稳再去考虑更激进的方案。5.2 稳定性的核心是依赖和资源治理AI工程的稳定性问题和传统后端不太一样。传统后端的问题多出在代码逻辑AI服务的问题多出在依赖和资源上。依赖层面AI项目的依赖链通常非常长CUDA版本、cuDNN、PyTorch、各个子库的版本之间存在隐性兼容约束。我有一次升级了PyTorch的minor版本结果手头所有基于旧版本的ONNX导出脚本全部失效回滚花了一整天。教训就是生产环境里AI组件的版本升级要当作重大变更来管理先有回归测试再谈升级。资源层面GPU的显存分配是AI服务最常见的崩溃源。一个请求引发OOM导致整个Pod被kill的案例业界比比皆是。解决方案标准做法是现代给你驾的K8s里给GPU Pod设置严格的requests和limits同时加上存活探针进程OOM后自动重建。另外建议把GPU监控接入你现有的监控体系显存使用率、利用率、温度这几个指标必须长期盯着。5.3 成本模型你烧的不是算力是关注度最后聊聊成本。AI服务尤其是大模型服务的成本和传统CPU服务完全不是一个量级很多人第一个月的账单拿到手才意识到问题的严重性。我做成本估算时会综合考虑这么几个变量模型推理的token消耗量输入输出并发峰值的GPU资源预留向量库和中间件的存储成本开发和调试阶段的资源消耗这个经常被遗忘一个用户量不大的内部工具如果设计不当一个月烧掉几万块很轻松。反过来如果做了一些基础优化压到几千也完全做得到。成本优化不是上线之后才考虑的事而是架构设计阶段的必答题。比如对RAG系统限制上下文的长度、做多轮对话的压缩、对高频相似问题做缓存这些改动带来的成本节省远大于你换一个折扣API。6. 学习路径与节奏安排一年时间能走到哪一步6.1 分阶段规划按项目导向而非纯理论学习经常有读者问我从零开始学AI工程到底需要多久、按什么顺序学。我根据自己的经历和带人的经验给一个参考的时间表和路径规划。前提是保持每天两到三小时的有效学习时间。第一阶段1-2个月打地基入门Python重点放在数据处理和脚本编写上同步学习Linux基础和Git补线性代数和概率统计的核心概念用PyTorch跑通一个简单的图像分类或文本分类项目比如MNIST或IMDB情感分类目标不是做出多好的效果而是理解训练流程的每个环节第二阶段3-4个月主修模型基础系统学习经典的深度学习架构CNN、RNN、Transformer用HuggingFace跑通预训练模型的微调流程深入理解注意力机制、位置编码、预训练与微调的关系动手做两个项目一个文本分类、一个简单对话或生成项目开始接触ONNX模型导出和基本的推理部署第三阶段5-7个月专攻RAG与大模型应用系统学习RAG四件套文档解析、切分嵌入、向量检索、生成增强用纯代码实现一遍完整RAG流程不依赖框架学习vLLM等推理引擎的部署和调优做企业文档问答机器人项目重点打磨检索效果和评估体系学习Docker和Kubernetes把项目容器化部署第四阶段8-12个月工程化进阶研究LLM SFT监督微调和RLHF人类反馈强化学习的原理与实操如果有条件尝试用DeepSpeed做一次分布式训练学习模型量化、蒸馏等优化手段把之前做的项目加上权限、监控、日志、评估、A/B测试等工程能力尝试在一到两个K8s小集群上部署多模型服务体会资源编排的细节这个节奏当然不是死的有人基础好可以跳着走但整体原则是一个阶段结束必须有一个拿得出手的项目作为毕业作品而不是抱着课程证书自我满足。6.2 学习资料怎么挑少而精优于多而杂资料这块我对新人的建议很明确少囤货、多精读。现在收藏夹里有几百个教程和上千个GitHub star的人一抓一大把但真正看完并实践的可能不到10%。基础理论方面斯坦福的CS224n和CS231n课程是老牌经典内容有点老了但核心概念不过时。李沐的《动手学深度学习》内容扎实代码配套完整强烈推荐精读并手动敲一遍里面的核心章节这本书的价值在同题材中文资料里是天花板。纯工程化方面的系统性资料比较少更实用的方式是去读优质开源项目的源码和文档。读源码是很有效但也很容易被忽略的学习方式。比如vLLM的源码、LangChain某个模块的源码、HuggingFace的Pipeline实现一行行读过去你对工程实现的认知会比看一百篇技术博客都深刻。我自己的习惯是每周精读一个开源项目的一个核心模块不求多但求每篇都搞清楚它为什么这么设计。6.3 项目作品集怎么让面试官一眼看出你的水平最后说说找工作环节。AI工程方向的简历和面试最看重的东西只有三样项目深度、工程意识、排查能力。项目深度上看很多人简历上写了五六个项目但每个都是调参跑通这种几乎没有竞争力。我反而建议只写一到两个深入的项目每个都能讲清楚这些维度解决的问题是什么为什么是这个方案数据是怎么处理的切分策略的实验过程模型选型的对比依据精度和性能的取舍部署时踩过哪些坑怎么定位和解决的性能指标和成本数据最好有具体数字工程意识上面试官常见的考察方式是问一个线上故障场景。比如模型服务突然延迟暴涨你怎么排查这时候如果你能说出一条清晰的排查链路——先看监控确认是资源问题还是依赖问题、再看GC或显存占用、再定位是数据倾斜还是代码bug——那就比死记硬背任何知识都有说服力。排查能力这一项说实话一定要靠真实项目里踩坑踩出来。这也是我强烈建议你在学习阶段就完整部署一次模型服务的原因只有当你经历过接一个线上不规范数据导致系统崩溃和明明本地一切正常部署后就是不通这类问题时才能真正长出自己的排查直觉。写到最后我的几点真实体会写了这么多最后说几句掏心窝的话。AI工程这条路看起来门槛比纯算法研究低因为很多组件都是现成可用的但真正做深之后你会发现它需要的综合能力不亚于任何一个技术方向——你要懂模型原理、要写得了稳固的工程代码、要会查系统性能瓶颈、要能定位分布式环境的疑难杂症甚至还要能跟业务方讲清楚能力边界和成本账。从我个人的实践经验来看这个领域最大的回报在于它的杠杆效应一个设计良好的AI系统可能比十个人手工干活产出还高而一个粗糙的AI系统也可能给团队带来巨大的隐性成本。所以请务必带着工程思维而不是脚本思维去对待你的每个项目。最后分享一个小技巧也是我一直在用的方法每完成一个项目给自己写一份复盘文档记录设计决策、踩坑过程和结果数据。这个习惯坚持一年你会发现自己的判断力和解决问题的速度都有质的提升。这套方法比任何教程都更适合成为你作为AI工程师的成长起点。
