软件工程师如何转型AI工程师 第三章 技术路线的选择——不要从头学起

第三章 技术路线的选择——不要从头学起在转型的技术路径上我见过最多的弯路长这个样子某个工程师下定决心要搞AI于是买了一本《深度学习》花书从第一章线性代数开始硬啃啃到反向传播那里卡住了又去看了3Blue1Brown的线性代数可视化系列、买了一门概率论基础课花了六周终于对矩阵运算和概率分布有了一点感觉。然后回来继续看花书看到CNN和RNN的时候发现自己虽然能勉强看懂公式但完全不知道实际中怎么用于是又去跟了一门PyTorch实战课从手写数字识别做到猫狗分类。四个月过去了他能用PyTorch搭一个小型图像分类网络了——然后他抬头看看市场上AI工程师的岗位描述发现要求的几乎全是大模型、RAG、Agent、LLMOps跟他学的那些东西交集甚少。这不是一个虚构的故事我在不同的工程师身上看到了它的无数个变体。路径的起点不一样——有人从线性代数开始有人从统计学开始有人从经典机器学习决策树、SVM、随机森林开始——但走向弯路的模式惊人地一致从最底层的理论开始一路往上建企图在某一天打通所有层次之后自然而然地达到能做大模型应用开发的水平。这条路不是不对。如果你的目标是成为一个AI研究员——在OpenAI或Anthropic做基础模型训练、设计新的注意力机制、推导更好的对齐算法——你确实需要从数学基础开始、从经典模型架构开始一层一层往上建。因为研究工作的本质是创造新东西你必须深刻理解已有的东西才能在它的基础上做创新。但如果你的目标是成为一个AI工程师——在生产环境中高质量地交付基于大模型的产品——这条从底向上的路径效率极低因为你在学习过程中的大部分时间都花在了跟你的日常工作不直接相关的知识上。一个AI工程师在日常工作中需要从零实现一个反向传播算法的概率趋近于零需要手推一个损失函数的梯度的概率也趋近于零——这些知识是有价值的但它们的价值是锦上添花而不是雪中送炭。自顶向下一条更短的路我推荐的路径恰好相反从应用层入手遇到瓶颈再往下扎。这条路径的逻辑很直接——先学会使用工具、解决问题再根据需要去了解工具的内部机制。你需要理解大模型的基本行为特性能力边界、响应模式、失败倾向但你不需要能从零搭建一个大模型。这种学习方式有几个好处。第一你从第一天开始就在做有产出的事——调用API、搭建管线、解决实际问题——而不是在纸上推了三个月公式之后依然无法做出任何东西。能做出东西这件事本身就是最好的学习反馈和动力来源。第二往下扎的时机和深度是由实际问题驱动的——你不是在盲目学习而是带着一个具体的疑问去深入。这种学习方式的记忆效果和理解深度远超纯理论学习。第三这条路径跟你作为工程师已有的学习习惯是一致的——你学HTTP不是先读RFC文档你学数据库不是先啃关系代数理论你学容器化不是先研究Linux namespace和cgroup的内核实现——你都是先用起来遇到问题再深入。AI也应该这么学。下面我把大模型时代的技术栈从应用层到基础层分成五个层次依次说说每一层的内容、深度要求和对工程能力的具体需求。第一层Prompt Engineering很多人听到这个词的第一反应是这算技术吗不就是写几句话让模型干活这种低估是有原因的——市面上大量的Prompt Engineering教程确实很水无非是教你几个模板“你是一个专家请按以下步骤回答”配上几个例子让你觉得这只是一种文案写作技巧。但真正的Prompt Engineering是一个深水区它需要你对模型的行为模式有精准的理解需要你有工程化的方法论需要你在边界条件和异常场景下做大量的验证。先说基础。一个好的Prompt至少需要包含几个要素角色设定告诉模型它在这个场景中扮演什么角色、有什么限制、任务描述清晰地说明你要它做什么而不是笼统地说帮我处理一下、输入格式如果你的输入是结构化的明确地告诉模型每个字段的含义、输出要求格式、长度、风格、语言、以及必要的示例Few-shot Learning——给几个输入输出的例子让模型理解你的期望。这些是基本功一两天就能掌握。但基本功之上还有很深的水。第一个深度是对上下文窗口的管理。模型的上下文窗口不是无限的——即使是支持128K Token的模型在实际使用中你也不能把128K全用了。一方面是成本按Token收费塞满窗口的成本很高另一方面窗口越长效果越不可靠——有研究表明模型对上下文中部的信息的利用率显著低于开头和结尾的信息。所以你需要精心管理上下文的内容和组织方式什么信息放在Prompt的开头最重要的指令和约束、什么放在中间参考材料、什么放在末尾当前的用户问题和输出要求。这种管理本身就是一种工程设计。第二个深度是Prompt的版本控制和迭代管理。在实际项目中Prompt不是一次写好就不动了的——它会随着业务需求的变化、用户反馈的积累、模型版本的更新而持续迭代。如果你没有一套系统来管理Prompt的版本哪个版本在生产环境运行、哪个在测试中、修改了什么、效果对比如何你很快就会陷入混乱。这就是软件工程中配置管理问题的翻版你完全可以用你熟悉的方法来解决用Git管理Prompt模板用Feature Flag做灰度切换用A/B测试框架做效果对比。第三个深度是对模型差异的适配。不同的模型家族GPT系列、Claude系列、Llama系列、Qwen系列对同一个Prompt的反应可能差异很大。一个在GPT-4上调试好的Prompt直接丢给Claude可能效果大打折扣反之亦然。如果你的系统需要支持多个模型这在成本优化和供应商风险管理的考虑下很常见你需要为每个模型维护一套适配的Prompt——或者设计一个足够鲁棒的Prompt模板能在不同模型上都有可接受的表现。第四个深度是输出的解析和校验。你给模型的指令再清晰它也有可能返回不符合预期的输出——格式不对、内容缺失、多出了不该有的文字。你的代码需要对模型的输出做鲁棒的解析正则提取、JSON修复、格式检测并在输出不合格时有明确的处理策略重试修复降级报警。这套输出后处理的逻辑经常被忽视但它是Prompt Engineering走向生产级的关键一步。在这一层你作为工程师的优势非常明显你能把Prompt管理做成一个有版本控制、有测试覆盖、有灰度策略、有监控告警的工程化体系而不是一个人手工维护的文本文件。这个差距在Demo阶段看不出来在生产环境中会越拉越大。第二层RAG检索增强生成当Prompt Engineering遇到天花板——模型不知道你的私有数据、事实性问题总是瞎编、知识更新滞后——你自然就会走到RAG这一层。RAG的核心思想简单到极致先检索再生成。用户问一个问题系统从知识库里找到相关的文档片段把这些片段作为上下文一起喂给模型模型基于这些材料来生成回答。这样模型就不需要记住所有知识——它只需要有理解和综合信息的能力具体的知识由检索环节来提供。听起来不复杂但真正要做好一个RAG系统里面的工程细节极其多每一个环节都涉及取舍。文档预处理阶段。你的原始数据可能是各种格式——PDF、Word、HTML、Markdown、纯文本、甚至扫描件。每种格式的解析工具和方法不同解析质量也参差不齐。PDF是出了名的难解析——它是一种为了精确控制打印排版而设计的格式不是为了文本提取设计的。同一个PDF用不同的解析库出来的文本质量可能天差地别表格和图表更是灾难。你需要为每种格式选择合适的解析方案并且写大量的测试来确保解析质量不会默默退化。文档切片阶段。你不能把一整篇文档作为一个检索单元——太大了既浪费上下文窗口空间又稀释了相关信息的密度。你需要把文档切成更小的片段chunk。切多大这个问题没有标准答案。太小了上下文信息丢失一个片段可能只含有答案的一半另一半在另一个片段里太大了噪声增多相关性评分被稀释。常见的策略是按段落切、按固定长度加重叠窗口切、按语义边界切。每种策略都有优缺点你需要在你的具体数据和场景下做实验来确定最佳方案。这又是一个纯工程问题——搭实验框架、定义评估指标、跑对比实验、分析结果。Embedding阶段。每个文档片段需要被转换成一个高维向量Embedding以便后续做相似度检索。选哪个Embedding模型是一个重要的决策——不同的模型在不同的数据类型和语言上表现差异很大。中文场景下BGE系列、M3E、以及各家大模型厂商自己出的Embedding模型都是选项。你还需要考虑Embedding的维度影响存储空间和检索速度、模型的最大输入长度超过限制的文本需要截断或分段处理、以及是否需要做查询端和文档端的不同处理一些模型建议对查询和文档使用不同的前缀指令。向量存储和检索阶段。Embedding生成之后需要存到某种向量数据库里。这个选型又是一个工程问题Milvus适合大规模部署、生态成熟Qdrant开箱即用、API设计优雅Chroma轻量级、适合快速原型pgvector如果你已经在用PostgreSQL可以减少运维成本。检索的方式也有讲究——纯向量检索在某些场景下效果不够好比如用户的查询中包含一个专有名词向量检索可能匹配到语义相似但名词不同的文档你可能需要混合检索策略同时做向量检索和关键词检索BM25然后用一个重排序模型Reranker对两组结果做合并和精排。上下文组装阶段。检索回来一组文档片段之后怎么把它们组装进Prompt直接按相关性排序拼接是最简单的做法但未必最优。你可能需要去重多个片段来自同一个文档的不同部分但内容高度重复、需要对片段做摘要压缩检索回来的原文太长放不进上下文窗口、需要添加元信息告诉模型每个片段来自哪个文档、什么时间创建的、是否权威来源。这一步的设计直接影响模型获取信息的效率和最终回答的质量。生成和后处理阶段。模型基于组装好的Prompt生成回答之后你还需要做一系列后处理答案中是否需要标注信息来源引用哪个文档的哪个片段是否需要做事实性校验模型有没有在检索结果中找不到答案的情况下编造内容输出格式是否符合要求如果回答质量不达标是直接返回还是触发降级策略你能看到RAG是一个典型的系统集成工作——它涉及数据处理、信息检索、模型调用、结果后处理等多个环节的协调。每个环节都有一组可调的参数和可替换的组件组合起来的可能性空间是巨大的。在这个空间里导航靠的不是直觉而是实验——而搭建一个高效的实验框架、快速验证不同组合的效果、找到对你的场景最适合的方案这正是工程师最擅长的事。第三层Fine-tuning当RAG的效果也不够的时候——比如你需要模型掌握极其特定的领域知识、需要严格的输出风格或格式、需要在推理延迟和成本上做极致优化用一个Fine-tune过的小模型替代通用大模型——Fine-tuning就登场了。在大模型时代做Fine-tuning的体验跟五年前做传统深度学习训练已经完全不同。你不需要从头设计网络结构基础模型帮你搞定了不需要做繁琐的特征工程模型本身就是最好的特征提取器你要做的核心工作是三件事构造高质量的训练数据、选择合适的微调方法、以及评估微调后的效果。训练数据的构造是Fine-tuning成败的关键。你需要把业务场景中好的回答转化为训练样本——通常是输入, 预期输出对的形式。数据的质量远比数量重要100条精心标注的高质量数据的效果往往好于10000条粗制滥造的数据。数据的多样性也很重要——你需要覆盖不同的问题类型、不同的难度级别、不同的边缘场景。构造训练数据的过程本身就是在教模型数据里的每一个偏差和错误都会被模型学到。微调方法方面全参数微调在大模型上通常不现实计算资源消耗太大主流的做法是参数高效微调PEFT。LoRALow-Rank Adaptation是目前应用最广泛的方法它的核心思想是不直接修改模型的原始参数而是在选定的层中插入小规模的低秩矩阵来做适配。QLoRA在LoRA的基础上加入了量化技术进一步降低了显存需求——你可以在单张GPU上数据中心级的A100甚至消费级的RTX 4090微调一个7B到13B参数的模型。你不需要能推导LoRA的数学原理但你需要理解它的几个关键参数的含义rank低秩矩阵的秩影响适配的容量和效率、alpha缩放系数影响适配的幅度、target modules在哪些层上做适配不同的选择影响效果和效率。评估微调效果是容易被忽视但极其重要的环节。微调之后的模型在训练数据上表现好不代表在实际使用中表现好——过拟合模型背住了训练数据但泛化能力下降是一个始终存在的风险。你需要一个独立的评测数据集不能跟训练数据有重叠需要多维度的评估指标不仅看目标任务的效果还要检查通用能力有没有退化需要跟微调前的Baseline做严格对比。这套评估方法论跟传统软件中的回归测试思路是一致的——每次修改之后确保没有引入副作用。Fine-tuning需要一些数学直觉。理解学习率太大会震荡不收敛太小会训练效率极低、理解过拟合和欠拟合训练损失下降但验证损失上升意味着过拟合、理解正则化的作用防止模型过度拟合训练数据——这些概念在实际操作中会反复用到。但你不需要能手推反向传播的公式——你需要的是能根据训练曲线判断模型的状态、能做出合理的参数调整决策。这个层面的理解花一两周的集中学习就能达到。第四层Agent如果说2024年的关键词是RAG那么2025到2026年的关键词就是Agent。Agent让模型从能说进化到了能做——它不仅能生成文本回答还能调用外部工具、执行代码、浏览网页、操作数据库、甚至协调多个子Agent来完成复杂的多步骤任务。Agent的开发几乎是纯工程问题这也是为什么它是软件工程师转型后最容易出彩的领域。一个Agent系统的核心架构通常包含几个部分规划器Planner负责把一个复杂任务分解为多个步骤执行器Executor负责按步骤调用工具和模型工具层Tools提供Agent可以调用的外部能力搜索、计算、API调用、文件操作等记忆层Memory维护Agent的短期工作记忆和长期知识以及安全层Safety控制Agent的行为边界和权限。如果你之前做过工作流引擎、状态机或者微服务编排你会发现Agent的架构跟这些东西有极深的亲缘关系。Planner做的事情就像一个工作流的DAG编排——分析依赖关系、决定执行顺序、处理并行和串行的混合。Executor做的事情就像一个任务运行时——管理执行状态、处理超时和重试、收集执行结果。Tool Layer做的事情就像微服务的API Gateway——统一接口定义、做参数校验、处理认证鉴权。Memory做的事情就像一个有TTL的缓存层加一个持久化的存储层。Agent开发中的工程挑战是多维度的。错误恢复是一大挑战。Agent在执行多步任务时任何一步都可能失败——工具调用超时、模型输出了无法解析的结果、中间步骤的结果不符合预期。你不能让整个任务因为一步的失败就中止——你需要设计重试策略、降级方案、以及在必要时回溯到之前的正确状态重新规划。这跟分布式系统中的Saga模式高度相似——长事务中的某一步失败了怎么做补偿性操作。安全边界是另一个关键问题。Agent能调用工具意味着它能影响真实世界——修改数据库、发送邮件、创建文件。如果不做严格的权限控制一个失控的Agent可能会造成严重的后果想象一下Agent误解了用户的意图然后删了数据库的表。你需要设计细粒度的权限模型Agent能调用哪些工具每个工具的调用频率限制是多少某些危险操作是否需要人工确认需要做输入过滤防止Prompt注入攻击通过工具执行恶意操作需要做输出审计所有的工具调用都要记录可追溯可回查。成本控制也很实际。一个Agent完成一个复杂任务可能需要调用模型十几次甚至几十次。每次调用都是钱。如果不加控制一个设计不当的Agent跑一次任务可能花掉几美元——看起来不多但乘以每天成千上万次调用就很可观了。你需要设计步骤数上限、Token预算、以及在预算即将耗尽时的优雅终止策略。状态管理是贯穿始终的复杂性来源。Agent在多步推理过程中需要维护一个持续更新的状态——到目前为止完成了哪些步骤、每步的结果是什么、接下来的计划是什么、收集到的信息有哪些。这个状态的设计直接影响Agent的推理质量和可调试性。太简单的状态表示比如只保留最后一步的结果会导致Agent在后续步骤中丢失重要的上下文太复杂的状态表示比如保留所有历史信息的原文会导致上下文窗口被状态信息挤满留给实际推理的空间反而不够。你需要设计一个平衡的状态管理方案——有选择性地保留关键信息、对历史信息做摘要压缩、为不同类型的信息设计不同的存储和检索策略。这些问题每一个你在传统分布式系统中都遇到过它的某种变体。唯一不同的是传统系统中组件的行为是确定的Agent系统中模型的行为是概率的。这增加了复杂度但不改变工程设计的基本方法论。穿插多模态不是一个单独的层而是一个正在渗透所有层的趋势在这个分层结构之外有一个维度值得单独拿出来讲多模态。2025年以来大模型从纯文字快速扩展为能看、能听、能生成图片和音频的多模态系统。GPT-4o可以同时处理文本、图像和语音Gemini天生就是多模态架构国内的通义千问和豆包也在多模态上下了重注。这意味着你在上面每一层的工作中迟早会遇到多模态的需求。Prompt层面你可能需要在Prompt里塞入图片比如让模型分析一张产品截图或一份扫描的合同这涉及到图像的前处理分辨率、裁剪、压缩以控制Token消耗和多模态Prompt的组织方式。RAG层面文档不再只是纯文本——企业知识库里有大量的PPT、PDF里的图表、流程图、手绘白板照片你需要处理图文混合的文档切片和检索。Agent层面多模态让Agent的感知范围从文字扩展到了视觉和听觉——一个质检Agent可以直接看产品照片来判断是否合格一个客服Agent可以听用户的语音然后用文字和语音同时回复。对工程师来说多模态带来的挑战主要是工程层面的不同模态的数据预处理管线差异很大文本分词vs图像resize vs音频采样率转换、多模态检索的索引策略比纯文本复杂得多你需要能用文字搜图、用图搜图、甚至用语音搜文档、多模态的成本和延迟也比纯文本高不少一张图片消耗的Token可能相当于几千字的文本。这些挑战本质上还是工程问题你的系统设计和性能优化经验在这里依然适用。我的建议是不需要专门为多模态花大量时间但在学习前四层的过程中保持对多模态的关注。当你做RAG项目时试着处理一些包含图片的PDF当你写Agent时试着加入一个图像理解的步骤。把多模态当作一个自然扩展而不是一个全新领域来对待学习曲线会平缓得多。第五层模型训练与基础模型研发把这一层放在最后不是因为它不重要而是因为对绝大多数转型者来说这一层是优先级最低的。除非你打算加入一家专门做基础模型的公司——国内大概就是几家头部的大模型厂商——否则你在日常工作中需要从零训练模型的场景极少。即使是Fine-tuning第三层你做的也是在已有模型上做适配而不是从头训练。但了解这一层的基本原理是必要的因为它能帮你在上面四层做更好的工程决策。你需要知道Transformer的Self-Attention在做什么——它本质上是在让序列中的每一个Token去查看所有其他Token计算它们之间的相关性然后基于这个相关性做信息聚合。理解这一点有助于你理解为什么上下文中信息的组织方式会影响模型的表现。你需要知道位置编码为什么重要——Transformer本身没有位置感知能力不像RNN天然地按顺序处理位置编码是告诉模型这个Token在序列中的位置的方式。不同的位置编码方案绝对位置编码、RoPE、ALiBi对模型处理长序列的能力有直接影响。理解这一点有助于你在处理超长上下文时做更好的设计决策。你需要知道KV Cache怎么加速推理——在自回归生成过程中模型每生成一个新Token都需要重新计算之前所有Token的AttentionKV Cache通过缓存已计算的Key和Value来避免重复计算。理解这一点有助于你理解模型推理的内存消耗模式和延迟特征从而做更好的服务端优化。你需要知道模型量化的基本概念——把模型的参数从32位浮点降低到16位、8位甚至4位可以大幅减少内存占用和推理延迟代价是一定程度的精度损失。理解这一点有助于你在部署方案中做精度vs效率的权衡决策。这些内容不需要深入到数学推导的程度除非你感兴趣理解是什么和为什么就够了。在实际工作中这些理解会在你遇到具体问题时发挥作用——比如当你发现模型处理长文档时效果明显下降你会知道这可能跟位置编码的外推能力有关当你的推理服务内存不足你会知道可以通过降低KV Cache的精度来缓解。你到底需要多少数学这个问题我在前面已经简单提过但它足够重要值得展开说说。先给一个总结性的判断你需要的数学量比你害怕的少但比一些AI工程师不需要任何数学的文章声称的要多。正确的量大约是高中数学到大一数学的水平加上一些面向AI应用的专项补充。线性代数方面你需要理解向量和矩阵的基本概念与运算因为Embedding就是向量Attention就是矩阵运算。具体来说你要知道什么是向量空间、什么是点积它用来衡量两个向量的相似度——你的余弦相似度检索用的就是这个、什么是矩阵乘法Transformer中Query、Key、Value的计算就是矩阵乘法。你不需要会证明定理、不需要会求特征值特征向量除非你要深入理解PCA之类的降维方法你需要的是直觉——看到一个高维向量能想象出它代表一个意义空间中的位置看到两个向量的余弦相似度是0.92能反应过来这两个东西在语义上很接近。概率论方面你需要理解条件概率和贝叶斯思维因为语言模型的本质就是在计算给定前面这些Token下一个Token是什么的概率分布。此外用来衡量两个概率分布差异的概念交叉熵、KL散度在理解模型训练目标的时候会用到。你不需要会推导复杂的概率公式你需要的是能把模型在做概率预测这件事内化成自己的直觉。微积分方面你需要理解梯度是函数变化最快的方向这个核心概念。梯度下降——模型训练的核心算法——就是沿着梯度的反方向一步一步走慢慢找到损失函数的最低点。当你在调Fine-tuning的学习率时你本质上是在调每一步走多远。步子太大会跨过最优解在两边来回跳震荡步子太小则走得太慢。这个直觉很重要但你不需要会手算偏导数——框架帮你搞定了。我建议的学习方式不是先花一个月系统补数学而是遇到数学就停下来花半天到一天搞懂它。比如你在读RAG相关的文章时遇到了余弦相似度就花半天搞清楚向量空间和点积你在做Fine-tuning时遇到了学习率和损失曲线就花一天搞清楚梯度下降的基本原理。这种按需学习的节奏效率远比系统学习高——因为每一个知识点都有一个真实的应用场景作为锚点理解得更深、记忆得更牢。工具链选型的原则最后说工具链。AI领域的工具链迭代速度令人窒息——每周都有新框架发布每个月都有XXX killer冒出来。在这种环境下你需要一个工具链选型的原则而不是一个具体的推荐清单因为任何清单在发表后三个月可能就过时了。原则一追生态不追新。一个框架有多少个GitHub Star不重要重要的是它有多少活跃的维护者、多少已解决的Issue、多少生产环境的使用案例。生态成熟意味着你踩的坑大概率有人踩过、你遇到的Bug大概率有人报过、你需要的功能大概率有人实现过。原则二先跑通再优化。不要在选型阶段花三周来对比五个向量数据库的性能基准——先随便选一个能用的跑通你的原型在真实的数据和流量下发现瓶颈之后再做针对性的迁移。选型的正确答案只有在你充分理解自己的需求之后才能给出而充分理解需求的方法是先做起来。原则三一定掌握Python。这是唯一一条没有弹性的建议。AI领域的几乎所有工具——模型推理框架、微调工具、向量数据库客户端、Agent框架——都以Python作为第一语言。你可以用Java或Go写你的后端服务但AI模块几乎一定要用Python来写。如果你之前不熟悉Python花一周时间过完语法和常见库就够了——作为有经验的工程师学一门新语言对你来说应该是以天计的事。具体工具方面截至2026年初几个在生态和稳定性上表现突出的工具包括LangChain和LlamaIndex在RAG和Agent方面积累最深Hugging Face Transformers加上PEFT是Fine-tuning的事实标准向量数据库方面Milvus和Qdrant在生产级场景的采用率较高。这些推荐可能在半年后就需要更新但它们目前的生态深度足以保证你不会踩太多坑。技术路线的选择就说到这里。核心信号只有一个自顶向下从做中学遇到问题再深入。不要让我还没准备好成为阻止你动手的借口。你永远不会完全准备好——这个领域变化得太快了准备得差不多就出发在路上调整方向比在出发点反复犹豫要有效得多。