我见过太多人把AI工程师理解成会调API的人也见过很多人一上来就被各种新词吓退结果连第一个项目都没跑通就放弃了。这个角色说到底不是写几个prompt也不是背一套深度学习公式而是用工程的方式把AI能力稳定地落到业务场景里。我从零走完这条路踩过不少坑这篇就完整说说我理解中的AI工程从零到一到底是什么该学什么、怎么学、怎么落地。如果你正准备入门这个方向或者已经在做相关项目但总觉得在靠感觉调参这篇文章应该能帮你看清全貌。它适合以下几类人有编程基础但没碰过AI的新人、正在做AI落地却总被效果和成本折磨的开发者、以及想系统梳理AI工程知识框架的产品和技术负责人。1. AI工程到底是什么先拆掉技术崇拜的滤镜1.1 核心定位让AI稳定工作而不是让AI显得聪明很多人对AI工程有一个误区以为这个岗位的核心是追求模型能力上限。但我在实际项目里最大的感受是AI工程和AI研究的本质区别在于前者追求的不是上限而是下限。研究者关心的是模型能不能在评测集上刷到98分工程师关心的是模型在真实流量下能不能稳定地跑出85分以上并且出问题时能在几分钟内定位、回滚、修复。工程化的关键在于建立可预期性。用户输入千奇百怪业务数据每天都在变模型行为本身又有随机性这些因素叠加起来AI工程的难度其实不在算法的深奥而在系统设计的周密。你需要在模型之外把输入清洗、上下文管理、降级方案、评测机制、监控告警、成本控制全部串起来形成一个闭环。这个闭环里任何一环缺失项目上线后都会反噬你。从零开始做AI工程第一步要接受的不是我很厉害而是我会踩很多坑。接受这个设定之后学习路径反而清晰了先保证每个环节都能跑通再逐步把每个环节做扎实。1.2 能力模型四层技能栈缺一不可我把自己从零走过来的技能栈拆成四层顺序基本就是学习顺序也是排查问题时候的排查顺序第一层基础工程能力。包括Python编程、Git协作、Linux命令行、基础后端知识。这层不解决AI问题但决定你能不能高效地做实验、部署、调试。很多教程跳过这层直接讲模型结果读者连环境都配不明白。第二层数据处理能力。包括数据抓取、清洗、入库、检索、评测集构建。模型吃的是数据产出也是数据AI工程的大部分工作量其实在这一层。谁在这层下功夫谁的项目效果就稳。第三层模型应用能力。包括API调用、提示词工程、上下文管理、结构化输出、RAG、微调、小模型部署。这层是大多数人理解的AI但只占整个工程工作量的30%左右。第四层系统设计能力。包括缓存策略、异步处理、重试降级、可观测性、成本估算、安全防护。这层决定项目能不能规模化跑起来也是初级工程师和高级工程师的分水岭。这四层的比例我粗略统计过自己过去一年的工作时间分配数据处理和评测大概占40%系统设计占了25%模型应用占20%其余是沟通和架构评审。你看真正干活的部分恰恰是最容易被忽略的部分。2. 打地基不劝退的入门路线按这个顺序走最省力2.1 Python和工程习惯别用跑通即懂骗自己Python是做AI工程绕不开的第一门语言。但这里有个很常见的坑很多人跟着教程写了几个脚本能调用模型、能处理文本就觉得自己Python过关了。真到做项目的时候面对几千行代码的项目结构、异常处理、日志记录、配置管理直接傻眼。我给初学者的建议是Python不需要学到高阶技巧但有一批基础设施必须熟练掌握虚拟环境管理venv或conda、依赖管理requirements.txt或pyproject.toml、异常处理try-except的合理使用而不是一有错就退出、日志模块logging而不是print、以及最基本的函数和类的设计。这些基本功决定了你后续实验的复现效率。另外一个容易被忽视的是Git。AI项目的特点是实验频繁、结果不确定你可能一周内会试十几种方案。没有好的版本管理回退到某个曾经跑通的版本就会变成灾难。我见过不止一个同事因为实验代码没有及时提交改坏后只能靠记忆重写浪费了两三天。工程习惯就是从这些小地方开始的它不酷但极其实用。2.2 数学基础你需要的是工程理解不是推导能力一提到AI就绕不开数学很多新人被线性代数、概率论吓得直接跑了。我对这个问题的观点是如果不做研究、不做底层训练框架开发你根本不需要会手推反向传播但你必须理解几个核心概念的干活版含义。举例来说你需要知道的是嵌入Embedding是什么把文本变成一串数字向量语义相近的文本向量距离更近相似度怎么算余弦相似度基于向量方向而非长度所以需要归一化模型的温度参数和随机性关系温度越高输出分布越分散越低越确定上下文长度是什么意思模型一次能看到的字数超出之后只能截断或遗忘。这些概念用生活类比就能理解七八成剩下两三成在项目里自然会补齐。真正需要花时间补的是统计学里关于抽样、偏差、评估的基础观念。因为构建评测集、分析模型错误、判断效果是否真实提升全依赖这些观念。深度学习里的复杂公式交给库和框架就好但如何判断数据有没有代表性这件事没有任何库能替你完成。2.3 数据操作能力SQL和Pandas是前期投入产出比最高的工具如果你问我AI工程所有技能里哪个投入产出比最高我会毫不犹豫说是数据处理能力。原因很简单AI项目的绝大多数瓶颈在数据质量和数据供给上模型只负责最后一步决策。具体来说你至少要熟练以下场景从数据库或日志里提取数据SQL对表结构做灵活变换Pandas或Polars对缺失值和异常值做处理不是删掉而是理解为什么缺失、缺失是否有信息量以及把数据转换成模型能用的格式比如把聊天记录整理成指令样本。我印象很深的一个案例是某个知识库问答项目效果一直不好模型怎么换都不行。后来排查发现问题不在模型而在数据入库阶段源文档是按PDF格式解析的很多表格内容在解析时被当成了纯文本顺序全乱检索出来的内容根本没法读。数据修好之后同一个模型的效果立刻发生了质变。这种案例在AI工程里不是个例而是常态。3. 核心内容拆解从调用API到搭建系统四个关键关卡3.1 第一关把API用好比把模型选大更重要从零起步最直接的路径就是先把成熟的模型API用熟。现在主流的大模型服务商都提供了openai兼容的接口调用方式大同小异。但用熟不是把它返回结果打出来那么简单重点是掌握几个软件层面的话题首先是结构化输出。真实业务里你通常需要模型返回可解析的数据比如从一份合同里提取出甲方、乙方、金额、有效期这些字段。直接让模型输出文本再人工解析是最容易出错的方案。现在各家API基本都支持JSON Mode或函数调用你要做的是在提示词里说清楚输出结构并加上解析校验步骤保证模型的输出格式始终可控。其次是上下文管理。大模型不是数据库它不会记住历史对话所谓多轮对话是把历史内容拼进消息列表一起发给模型。这里面要处理的是token膨胀问题对话越长费用越高、响应越慢、模型反而更容易迷失。工程上常见的做法是截断早期内容、做历史摘要、或者抽取出关键信息存起来。最后是错误处理与重试。API总有偶发超时、限流、格式问题你的代码必须对每一种异常都有对应的处理策略。比如429限流时做指数退避重试格式异常时重新请求一次并要求修正连续失败时走降级方案。这一套做完你的系统才对得上工程两个字。3.2 第二关提示词工程与模型沟通的翻译能力提示词工程被很多人低估觉得不过就是写几句咒语。实际上它的本质是一种结构化沟通能力。我的经验是一份好的系统提示词System Prompt至少需要具备以下几个要素角色定义告诉模型它是什么、不该做什么。比如你是客服助手只处理订单相关问题不做身份判断。行为规范明确输出格式、语气、长度限制。包括用JSON返回不要猜测不确定时回答需要人工确认。上下文输入把业务相关信息用户query、检索结果、历史记录以清晰格式粘进去并用分隔符隔开。输出约束限定枚举值范围、禁止输出内容从源头降低不可控风险。实际项目里提示词不是一次性写好的它是一条反馈循环先用测试集跑一版看失败案例改提示词、再跑直到稳定通过。这个过程需要你建立一套属于自己的评测集我在下一节会详细讲。另外特别提醒一点提示词工程的能力有上限的。如果模型本身能力不足你写一万字提示词也没用。先在能力更强的模型上拿到正确流程用强模型验证你的方案逻辑没问题再考虑换小模型降低成本这个顺序才合理。3.3 第三关微调的正确出场时机以及替代方案很多朋友问我是不是应该微调一个自己的模型我的回答通常是先别急。微调是一个出力不讨喜的选项它成本高、周期长、效果还容易让人失望。实际大部分业务需求靠提示词优化和RAG就能解决问题。微调的真正适用场景大致有三类让模型学会特定格式输出比如企业内部的工单格式、让模型记住专属领域的知识和术语但通常RAG更划算、压缩模型能力和成本比如把大模型蒸馏到小模型上。如果你确实要微调流程上要提醒几个坑数据集至少要几百到几千条高质量指令样本而样本质量直接决定效果上限训练之前一定要做数据清洗和去重防止模型过拟合到重复样本上训练完成后必须用和测试集分开的评测集做验证这个评测集要能反映真实业务场景而不是训练数据里分布的复制品。另外提一嘴LoRA这是目前最有性价比的微调方式。它通过训练少量低秩适配参数来调整模型行为而不是全量更新权重所以显存要求低、训练速度快。就我实际经验而言绝大多数业务微调用LoRA就足够了没必要走全量微调那条烧钱的路。3.4 第四关RAG的完整落地不只一个检索步骤RAG检索增强生成在当下几乎是知识库问答的标配方案但很多从教程里学RAG的朋友会遇到同一个问题教程里跑通了业务场景里效果却不理想。原因在于真正的RAG系统远不止向量化文档相似度检索灌给模型这三步。一个能落地的RAG要处理的话题包括文档解析与清洗。PDF、Word、网页各有各的抽取难度表格、图片、页眉页脚都会干扰正文。这步做不好后面全白搭。我在1.3节提到的表格乱序案例就是典型的解析问题。分块Chunking策略。文档切片的大小和重叠长度直接影响检索命中率。分块太大会稀释语义、拉高成本太小则丧失上下文。常见的做法是固定长度按字符或token分块并加上少量重叠但这只是基础进阶做法是按文档结构分块比如一个markdown标题对应一个块或者一个段落一个块。具体选哪种要靠评测集来验证不要拍脑袋。检索策略与重排序。只做向量检索会有问题语义相近但答案错误的情况经常出现。工程上现在的做法是混合检索关键词匹配BM25向量检索然后加一个重排序Rerank模型把两份结果合并打分后取最优。这一步效果提升非常明显但也会带来额外的计算成本需要平衡。引用与证据呈现。面向用户的问答系统最好能把答案对应的原始文本片段返回给用户让用户可溯源。这既是为了提升信任度也是业务合规的需求。实现上只需在检索时保留块的来源信息生成回答时顺便输出引用编号成本很低但体验提升很大。这四个关卡走完你就有了一个能跑的AI应用雏形。接下来才进入我说的工程化深水区把它变成一个可靠、能被监控、能持续迭代的系统。4. 实操落地一个完整AI工程项目的四个阶段4.1 阶段一需求拆解与可行性判断先问五个问题我接手任何一个AI项目第一周不会写一行代码而是先做一件事把需求拆到能回答以下五个问题为止这个需求的核心输入输出是什么输入是用户一句话还是上传的文档输出是一段文字、数据字段还是动作触发效果好坏的判断标准是什么谁来打分是用户点赞率还是人工质检准确率还是业务指标比如解答率错误的代价有多大答错是让人不方便还是会造成实质性权益损失这决定了你要不要加人工确认环节。数据从哪来需要模型回答的内容是否已有现成数据这决定方案用的是纯模型能力还是要搭RAG。成本和延迟的预算区间每次请求可接受的费用和用户可感知的响应时间这两个数字必须在开发前就定下来。别小看这五个问题。我见过太多项目启动热火朝天做到一半发现数据根本不够、错误代价远超预期、成本算下来比原计划翻了几倍最后只能推倒重来。前期花几天把问题问清楚省下的是后面几个月的返工。4.2 阶段二数据准备与评测集构建这是工程的地基数据准备阶段做得好整个项目就成功了一大半而且这个阶段的投入会一路复利到后面的每个环节。具体工作有三块第一块是构建评测集。在你的真实业务场景里收集100300条代表性输入然后由人工给出标准答案或等级评分。这个评测集代表用户实际会遇到的情况尽量覆盖常见、边缘、干扰三类输入。评测集的价值在于你在后续任何一次改动换模型、改提示词、调参数、加数据之后都能用一个统一标准判断是否变好了而不是靠感觉。第二块是准备业务数据源。做RAG就整理文档做微调就整理指令样本。这一步的通用准则是宁可少不能脏。十篇高质量文档好过一千篇解析乱码的垃圾数据。数据入库后要做质量抽检肉眼看过一批样本再上线。第三块是建立线上数据的回流机制。真实用户的问题、模型回答、用户反馈点赞、点踩、转人工都应该落库。这些线上数据是持续优化模型的黄金资源也是发现数据漂移的第一手信号。4.3 阶段三方案选型与成本预估不做大炮打蚊子的事方案选型是AI工程里很有讲究的一环。我的基本原则是从小到大、从便宜到贵、从简单到复杂。先用最强的模型跑通流程验证逻辑可行性然后用中等模型替换对比评测集分数如果分数不达标再考虑加RAG、改提示词最后才考虑微调或换更大模型。为什么反过来不行因为如果直接用最强模型都没跑出理想效果你换小模型大概率只会更差此时应该回去找逻辑漏洞、数据问题。强模型在这里担当的是天花板探针的角色它的作用不是上线而是帮你看清楚你的方案到底行不行。等到方案稳定了再去思考怎么降到可控成本。成本预估要算的三个数字我都建议提前估算出来单次请求的平均token数输入加输出、单次请求的费用、以及按预估调用量算出的月成本。一条经验线是如果单次成本高于业务的单次收益比如带货场景里一次AI推荐带来的额外GMV这个项目就不具备商业合理性。成本这件事一定要在开发前想清楚否则做出来上不了线等于白做。4.4 阶段四上线部署与监控AI工程最见功力的地方AI服务上线比传统后端服务麻烦的地方在于模型输出具有随机性和不确定性你不能用接口返回200来断定服务正常。所以监控体系要分两层第一层是传统的系统监控响应延迟、QPS、错误码、服务存活这些用常规APM工具就能覆盖。你需要额外关注的是延迟的分布特别是P95和P99因为模型推理的耗时波动远大于普通接口。第二层是AI特有的质量监控每次请求的输入输出token数、模型命中的内容类型、用户反馈的正负比例、以及线上输入的分布变化。这一层我建议至少做到两个基础项抽样人工质检每天或每小时抽取一定比例的会话人工打分看效果是否达标和异常自动告警比如连续N次回答为空、或者用户短时间内多次转人工就要触发排查。上线时还要有灰度策略。先在内部用户或小流量上跑观察质量监控指标确认稳定后再全量放出。一旦出问题旧版本的模型接口还能随时切换这种回滚能力必须提前准备别等到线上出了事故再临时想办法。5. 常见问题与排查技巧实录我踩过的那些坑5.1 模型输出不稳定先区分是模型问题还是输入问题项目中吐槽模型抽风的情况十有八九根因不在模型。我总结了一条排查顺序按这个走能省很多时间输入是否在预期范围用户可能传了极长文本、乱码、各种语言混杂的内容先做输入侧的长度截断和清洗。上下文里有没有无关信息RAG检索回来的内容里如果混入了高相似但无关的片段模型会被带偏。先检查检索结果的top1是不是真正相关的内容。输出格式有没有被解析逻辑限制如果你用正则截取JSON模型多加一个逗号可能就解析失败。换成官方结构化输出接口这类坑会少很多。最后才怀疑模型本身。如果你的提示词和输入在其他工具里测试是稳定的那才考虑换模型或调参数。这套顺序的底层逻辑是模型是黑盒但它的输入输出你是能看到的。先从能看到的部分下手把变量缩小再碰黑盒是最省力的路径。5.2 响应太慢从链路拆解找瓶颈不要直接上GPU业务方说AI回复好慢很多人第一反应是加机器、上更好的GPU。但AI服务慢往往慢在链路里被忽略的地方。我建议按以下顺序排查**首块Token延迟TTFT**是否很长如果是最大的可能是输入上下文过长导致预填充阶段计算量太大。此时优化方向是缩短上下文、用更小的模型或者换支持Prefill优化的推理框架。生成阶段是否平稳如果整体生成速度慢考虑输出长度限制、减小编码重复惩罚或者降级到更小的模型。上游检索是否耗时向量检索在数据量大时全量扫描会非常慢。这里要用索引如HNSW、IVF或者加一层基于关键词的预筛选。是否有串行调用有些项目里一次回答需要先调模型A做分类再调模型B做生成这会翻倍增加延迟。工程上可以把分类步骤做成一个小模型低延迟完成或者并行处理多个独立子任务。另外还有个容易被忽略的超时设置。很多服务默认的HTTP超时只有几秒模型慢一点就超时重试重试进一步加剧负载导致雪崩。把这个时间设置合理一些配合优雅降级有时候比升配置有用得多。5.3 效果差先别改模型回头查数据和评测集我犯过最典型的错误是模型效果不理想就一次次换更强的模型结果成本翻了三倍效果只提升了一点。后来复盘发现问题根本不在模型能力上而在我构建的评测集不具备代表性。这里有一个核心概念叫数据泄漏与样本偏差。如果你的评测集和测试集来自同一个分布甚至评测集里包含了开发时反复试过的样本那你在评测集上的分数就是一种过拟合。比如你反复针对某几个刁钻问题调提示词评测集的分数看似越来越高但换个环境、来一批新问题效果立刻打回原形。正确的做法是评测集一旦构建完成就冻结不再往里面塞反复调试过的样本。每次改动模型方案用冻结的评测集跑分确保分数提升是真实泛化能力的变化而不是记住了个别特例。同时定期从线上回流数据中抽一批新样本扩充评测集让评测基准和真实场景保持同步。5.4 成本失控从token用量和缓存下手性价比才是真目标大模型服务按token计费很多项目上线后成本暴增的原因很简单每次调用都塞进大量历史对话或者频繁重复调用同样的模型。省钱的方向大致有这么几个一是做语义缓存。如果用户的提问其实高度重复企业知识库场景里尤其常见可以把模型回答按输入语义哈希缓存起来命中缓存就直接返回不产生模型调用费用。实测下来这类场景的缓存命中率能做到30%以上成本直接降低三成。二是做路由分发。把简单任务分给便宜的小模型复杂任务才调用大模型。识别任务是简单还是复杂可以先用规则判断也可以用一个更快更便宜的分类模型。我做过一个客服分流项目成本降了60%效果反而提升了因为大模型不用再处理大量简单重复问答专用于复杂场景回答质量更稳定了。三是控制上下文膨胀。上文的对话历史、检索片段动态地做压缩和取舍。比如历史对话压缩成摘要只保留最近几轮原始内容既不影响多轮连贯性又能大幅减少输入token。6. 进阶心得从零到能独立负责一条AI产品线走到这里你已经掌握了从模型调用到系统搭建的完整链路。但想要独立负责一条AI产品线还需要跨越几个层面的能力升级。第一个升维是从功能开发到体验全链路。上线只是起点后续要不断根据数据反馈迭代哪些问题用户反复问但答不好、哪个环节的转人工率异常高、新增的业务知识是否及时进了索引。这一套数据驱动的迭代闭环跑起来产品才真正有了生命。第二个升维是从单点方案到多场景复用。当你做完第一个RAG项目之后下一个类似项目就会快很多但真正的高手会把里面的通用模块抽出来文档解析组件、评测工具、缓存服务、监控告警模板做成团队内部可复用的基础设施。这个沉淀过程是个人技术影响力扩散的最有效方式。第三个升维是技术判断力的养成。AI领域变化太快每周都有新模型、新框架发布。我的建议是不要追新而是建立自己的评价框架。面对新技术我通常会问三个问题它解决了什么老问题它引入了什么新问题我的项目当前痛点是否真的匹配它的优势有了这个框架面对产品经理和老板的各种新想法你也能给出靠谱的判断而不是人云亦云。我个人的体会是从零开始做AI工程最大的门槛不在技术难度而在心态。你会经历反复调优仍然无效的挫败会碰到上线前夕才发现数据有硬伤的时刻也会面对模型能力边界带来的无奈。这些都很正常它们不是你的失败而是这个领域的常态。关键系的其实是你的排查方法和工作流是否足够系统化。把数据、评测、监控这些地基打牢把每一段实验记录清楚你会发现所谓的玄学正在一点点变成可解释、可复现、可迭代的工程方法。最后再分享一个小技巧给自己建一个实验记录模板每次改动都记录三样东西——改了什么、实验了什么数据、结论是什么。这个习惯我坚持了很久它带来的直接收益是三个月后我翻记录还能清楚地知道为什么当时选这个方案、放弃了哪个方案。这种沉淀比看任何课程都珍贵因为它是你专属的、踩过坑才知道的工程经验。 AI工程从零到一：模型搭建、优化与系统落地的完整路径
我见过太多人把AI工程师理解成会调API的人也见过很多人一上来就被各种新词吓退结果连第一个项目都没跑通就放弃了。这个角色说到底不是写几个prompt也不是背一套深度学习公式而是用工程的方式把AI能力稳定地落到业务场景里。我从零走完这条路踩过不少坑这篇就完整说说我理解中的AI工程从零到一到底是什么该学什么、怎么学、怎么落地。如果你正准备入门这个方向或者已经在做相关项目但总觉得在靠感觉调参这篇文章应该能帮你看清全貌。它适合以下几类人有编程基础但没碰过AI的新人、正在做AI落地却总被效果和成本折磨的开发者、以及想系统梳理AI工程知识框架的产品和技术负责人。1. AI工程到底是什么先拆掉技术崇拜的滤镜1.1 核心定位让AI稳定工作而不是让AI显得聪明很多人对AI工程有一个误区以为这个岗位的核心是追求模型能力上限。但我在实际项目里最大的感受是AI工程和AI研究的本质区别在于前者追求的不是上限而是下限。研究者关心的是模型能不能在评测集上刷到98分工程师关心的是模型在真实流量下能不能稳定地跑出85分以上并且出问题时能在几分钟内定位、回滚、修复。工程化的关键在于建立可预期性。用户输入千奇百怪业务数据每天都在变模型行为本身又有随机性这些因素叠加起来AI工程的难度其实不在算法的深奥而在系统设计的周密。你需要在模型之外把输入清洗、上下文管理、降级方案、评测机制、监控告警、成本控制全部串起来形成一个闭环。这个闭环里任何一环缺失项目上线后都会反噬你。从零开始做AI工程第一步要接受的不是我很厉害而是我会踩很多坑。接受这个设定之后学习路径反而清晰了先保证每个环节都能跑通再逐步把每个环节做扎实。1.2 能力模型四层技能栈缺一不可我把自己从零走过来的技能栈拆成四层顺序基本就是学习顺序也是排查问题时候的排查顺序第一层基础工程能力。包括Python编程、Git协作、Linux命令行、基础后端知识。这层不解决AI问题但决定你能不能高效地做实验、部署、调试。很多教程跳过这层直接讲模型结果读者连环境都配不明白。第二层数据处理能力。包括数据抓取、清洗、入库、检索、评测集构建。模型吃的是数据产出也是数据AI工程的大部分工作量其实在这一层。谁在这层下功夫谁的项目效果就稳。第三层模型应用能力。包括API调用、提示词工程、上下文管理、结构化输出、RAG、微调、小模型部署。这层是大多数人理解的AI但只占整个工程工作量的30%左右。第四层系统设计能力。包括缓存策略、异步处理、重试降级、可观测性、成本估算、安全防护。这层决定项目能不能规模化跑起来也是初级工程师和高级工程师的分水岭。这四层的比例我粗略统计过自己过去一年的工作时间分配数据处理和评测大概占40%系统设计占了25%模型应用占20%其余是沟通和架构评审。你看真正干活的部分恰恰是最容易被忽略的部分。2. 打地基不劝退的入门路线按这个顺序走最省力2.1 Python和工程习惯别用跑通即懂骗自己Python是做AI工程绕不开的第一门语言。但这里有个很常见的坑很多人跟着教程写了几个脚本能调用模型、能处理文本就觉得自己Python过关了。真到做项目的时候面对几千行代码的项目结构、异常处理、日志记录、配置管理直接傻眼。我给初学者的建议是Python不需要学到高阶技巧但有一批基础设施必须熟练掌握虚拟环境管理venv或conda、依赖管理requirements.txt或pyproject.toml、异常处理try-except的合理使用而不是一有错就退出、日志模块logging而不是print、以及最基本的函数和类的设计。这些基本功决定了你后续实验的复现效率。另外一个容易被忽视的是Git。AI项目的特点是实验频繁、结果不确定你可能一周内会试十几种方案。没有好的版本管理回退到某个曾经跑通的版本就会变成灾难。我见过不止一个同事因为实验代码没有及时提交改坏后只能靠记忆重写浪费了两三天。工程习惯就是从这些小地方开始的它不酷但极其实用。2.2 数学基础你需要的是工程理解不是推导能力一提到AI就绕不开数学很多新人被线性代数、概率论吓得直接跑了。我对这个问题的观点是如果不做研究、不做底层训练框架开发你根本不需要会手推反向传播但你必须理解几个核心概念的干活版含义。举例来说你需要知道的是嵌入Embedding是什么把文本变成一串数字向量语义相近的文本向量距离更近相似度怎么算余弦相似度基于向量方向而非长度所以需要归一化模型的温度参数和随机性关系温度越高输出分布越分散越低越确定上下文长度是什么意思模型一次能看到的字数超出之后只能截断或遗忘。这些概念用生活类比就能理解七八成剩下两三成在项目里自然会补齐。真正需要花时间补的是统计学里关于抽样、偏差、评估的基础观念。因为构建评测集、分析模型错误、判断效果是否真实提升全依赖这些观念。深度学习里的复杂公式交给库和框架就好但如何判断数据有没有代表性这件事没有任何库能替你完成。2.3 数据操作能力SQL和Pandas是前期投入产出比最高的工具如果你问我AI工程所有技能里哪个投入产出比最高我会毫不犹豫说是数据处理能力。原因很简单AI项目的绝大多数瓶颈在数据质量和数据供给上模型只负责最后一步决策。具体来说你至少要熟练以下场景从数据库或日志里提取数据SQL对表结构做灵活变换Pandas或Polars对缺失值和异常值做处理不是删掉而是理解为什么缺失、缺失是否有信息量以及把数据转换成模型能用的格式比如把聊天记录整理成指令样本。我印象很深的一个案例是某个知识库问答项目效果一直不好模型怎么换都不行。后来排查发现问题不在模型而在数据入库阶段源文档是按PDF格式解析的很多表格内容在解析时被当成了纯文本顺序全乱检索出来的内容根本没法读。数据修好之后同一个模型的效果立刻发生了质变。这种案例在AI工程里不是个例而是常态。3. 核心内容拆解从调用API到搭建系统四个关键关卡3.1 第一关把API用好比把模型选大更重要从零起步最直接的路径就是先把成熟的模型API用熟。现在主流的大模型服务商都提供了openai兼容的接口调用方式大同小异。但用熟不是把它返回结果打出来那么简单重点是掌握几个软件层面的话题首先是结构化输出。真实业务里你通常需要模型返回可解析的数据比如从一份合同里提取出甲方、乙方、金额、有效期这些字段。直接让模型输出文本再人工解析是最容易出错的方案。现在各家API基本都支持JSON Mode或函数调用你要做的是在提示词里说清楚输出结构并加上解析校验步骤保证模型的输出格式始终可控。其次是上下文管理。大模型不是数据库它不会记住历史对话所谓多轮对话是把历史内容拼进消息列表一起发给模型。这里面要处理的是token膨胀问题对话越长费用越高、响应越慢、模型反而更容易迷失。工程上常见的做法是截断早期内容、做历史摘要、或者抽取出关键信息存起来。最后是错误处理与重试。API总有偶发超时、限流、格式问题你的代码必须对每一种异常都有对应的处理策略。比如429限流时做指数退避重试格式异常时重新请求一次并要求修正连续失败时走降级方案。这一套做完你的系统才对得上工程两个字。3.2 第二关提示词工程与模型沟通的翻译能力提示词工程被很多人低估觉得不过就是写几句咒语。实际上它的本质是一种结构化沟通能力。我的经验是一份好的系统提示词System Prompt至少需要具备以下几个要素角色定义告诉模型它是什么、不该做什么。比如你是客服助手只处理订单相关问题不做身份判断。行为规范明确输出格式、语气、长度限制。包括用JSON返回不要猜测不确定时回答需要人工确认。上下文输入把业务相关信息用户query、检索结果、历史记录以清晰格式粘进去并用分隔符隔开。输出约束限定枚举值范围、禁止输出内容从源头降低不可控风险。实际项目里提示词不是一次性写好的它是一条反馈循环先用测试集跑一版看失败案例改提示词、再跑直到稳定通过。这个过程需要你建立一套属于自己的评测集我在下一节会详细讲。另外特别提醒一点提示词工程的能力有上限的。如果模型本身能力不足你写一万字提示词也没用。先在能力更强的模型上拿到正确流程用强模型验证你的方案逻辑没问题再考虑换小模型降低成本这个顺序才合理。3.3 第三关微调的正确出场时机以及替代方案很多朋友问我是不是应该微调一个自己的模型我的回答通常是先别急。微调是一个出力不讨喜的选项它成本高、周期长、效果还容易让人失望。实际大部分业务需求靠提示词优化和RAG就能解决问题。微调的真正适用场景大致有三类让模型学会特定格式输出比如企业内部的工单格式、让模型记住专属领域的知识和术语但通常RAG更划算、压缩模型能力和成本比如把大模型蒸馏到小模型上。如果你确实要微调流程上要提醒几个坑数据集至少要几百到几千条高质量指令样本而样本质量直接决定效果上限训练之前一定要做数据清洗和去重防止模型过拟合到重复样本上训练完成后必须用和测试集分开的评测集做验证这个评测集要能反映真实业务场景而不是训练数据里分布的复制品。另外提一嘴LoRA这是目前最有性价比的微调方式。它通过训练少量低秩适配参数来调整模型行为而不是全量更新权重所以显存要求低、训练速度快。就我实际经验而言绝大多数业务微调用LoRA就足够了没必要走全量微调那条烧钱的路。3.4 第四关RAG的完整落地不只一个检索步骤RAG检索增强生成在当下几乎是知识库问答的标配方案但很多从教程里学RAG的朋友会遇到同一个问题教程里跑通了业务场景里效果却不理想。原因在于真正的RAG系统远不止向量化文档相似度检索灌给模型这三步。一个能落地的RAG要处理的话题包括文档解析与清洗。PDF、Word、网页各有各的抽取难度表格、图片、页眉页脚都会干扰正文。这步做不好后面全白搭。我在1.3节提到的表格乱序案例就是典型的解析问题。分块Chunking策略。文档切片的大小和重叠长度直接影响检索命中率。分块太大会稀释语义、拉高成本太小则丧失上下文。常见的做法是固定长度按字符或token分块并加上少量重叠但这只是基础进阶做法是按文档结构分块比如一个markdown标题对应一个块或者一个段落一个块。具体选哪种要靠评测集来验证不要拍脑袋。检索策略与重排序。只做向量检索会有问题语义相近但答案错误的情况经常出现。工程上现在的做法是混合检索关键词匹配BM25向量检索然后加一个重排序Rerank模型把两份结果合并打分后取最优。这一步效果提升非常明显但也会带来额外的计算成本需要平衡。引用与证据呈现。面向用户的问答系统最好能把答案对应的原始文本片段返回给用户让用户可溯源。这既是为了提升信任度也是业务合规的需求。实现上只需在检索时保留块的来源信息生成回答时顺便输出引用编号成本很低但体验提升很大。这四个关卡走完你就有了一个能跑的AI应用雏形。接下来才进入我说的工程化深水区把它变成一个可靠、能被监控、能持续迭代的系统。4. 实操落地一个完整AI工程项目的四个阶段4.1 阶段一需求拆解与可行性判断先问五个问题我接手任何一个AI项目第一周不会写一行代码而是先做一件事把需求拆到能回答以下五个问题为止这个需求的核心输入输出是什么输入是用户一句话还是上传的文档输出是一段文字、数据字段还是动作触发效果好坏的判断标准是什么谁来打分是用户点赞率还是人工质检准确率还是业务指标比如解答率错误的代价有多大答错是让人不方便还是会造成实质性权益损失这决定了你要不要加人工确认环节。数据从哪来需要模型回答的内容是否已有现成数据这决定方案用的是纯模型能力还是要搭RAG。成本和延迟的预算区间每次请求可接受的费用和用户可感知的响应时间这两个数字必须在开发前就定下来。别小看这五个问题。我见过太多项目启动热火朝天做到一半发现数据根本不够、错误代价远超预期、成本算下来比原计划翻了几倍最后只能推倒重来。前期花几天把问题问清楚省下的是后面几个月的返工。4.2 阶段二数据准备与评测集构建这是工程的地基数据准备阶段做得好整个项目就成功了一大半而且这个阶段的投入会一路复利到后面的每个环节。具体工作有三块第一块是构建评测集。在你的真实业务场景里收集100300条代表性输入然后由人工给出标准答案或等级评分。这个评测集代表用户实际会遇到的情况尽量覆盖常见、边缘、干扰三类输入。评测集的价值在于你在后续任何一次改动换模型、改提示词、调参数、加数据之后都能用一个统一标准判断是否变好了而不是靠感觉。第二块是准备业务数据源。做RAG就整理文档做微调就整理指令样本。这一步的通用准则是宁可少不能脏。十篇高质量文档好过一千篇解析乱码的垃圾数据。数据入库后要做质量抽检肉眼看过一批样本再上线。第三块是建立线上数据的回流机制。真实用户的问题、模型回答、用户反馈点赞、点踩、转人工都应该落库。这些线上数据是持续优化模型的黄金资源也是发现数据漂移的第一手信号。4.3 阶段三方案选型与成本预估不做大炮打蚊子的事方案选型是AI工程里很有讲究的一环。我的基本原则是从小到大、从便宜到贵、从简单到复杂。先用最强的模型跑通流程验证逻辑可行性然后用中等模型替换对比评测集分数如果分数不达标再考虑加RAG、改提示词最后才考虑微调或换更大模型。为什么反过来不行因为如果直接用最强模型都没跑出理想效果你换小模型大概率只会更差此时应该回去找逻辑漏洞、数据问题。强模型在这里担当的是天花板探针的角色它的作用不是上线而是帮你看清楚你的方案到底行不行。等到方案稳定了再去思考怎么降到可控成本。成本预估要算的三个数字我都建议提前估算出来单次请求的平均token数输入加输出、单次请求的费用、以及按预估调用量算出的月成本。一条经验线是如果单次成本高于业务的单次收益比如带货场景里一次AI推荐带来的额外GMV这个项目就不具备商业合理性。成本这件事一定要在开发前想清楚否则做出来上不了线等于白做。4.4 阶段四上线部署与监控AI工程最见功力的地方AI服务上线比传统后端服务麻烦的地方在于模型输出具有随机性和不确定性你不能用接口返回200来断定服务正常。所以监控体系要分两层第一层是传统的系统监控响应延迟、QPS、错误码、服务存活这些用常规APM工具就能覆盖。你需要额外关注的是延迟的分布特别是P95和P99因为模型推理的耗时波动远大于普通接口。第二层是AI特有的质量监控每次请求的输入输出token数、模型命中的内容类型、用户反馈的正负比例、以及线上输入的分布变化。这一层我建议至少做到两个基础项抽样人工质检每天或每小时抽取一定比例的会话人工打分看效果是否达标和异常自动告警比如连续N次回答为空、或者用户短时间内多次转人工就要触发排查。上线时还要有灰度策略。先在内部用户或小流量上跑观察质量监控指标确认稳定后再全量放出。一旦出问题旧版本的模型接口还能随时切换这种回滚能力必须提前准备别等到线上出了事故再临时想办法。5. 常见问题与排查技巧实录我踩过的那些坑5.1 模型输出不稳定先区分是模型问题还是输入问题项目中吐槽模型抽风的情况十有八九根因不在模型。我总结了一条排查顺序按这个走能省很多时间输入是否在预期范围用户可能传了极长文本、乱码、各种语言混杂的内容先做输入侧的长度截断和清洗。上下文里有没有无关信息RAG检索回来的内容里如果混入了高相似但无关的片段模型会被带偏。先检查检索结果的top1是不是真正相关的内容。输出格式有没有被解析逻辑限制如果你用正则截取JSON模型多加一个逗号可能就解析失败。换成官方结构化输出接口这类坑会少很多。最后才怀疑模型本身。如果你的提示词和输入在其他工具里测试是稳定的那才考虑换模型或调参数。这套顺序的底层逻辑是模型是黑盒但它的输入输出你是能看到的。先从能看到的部分下手把变量缩小再碰黑盒是最省力的路径。5.2 响应太慢从链路拆解找瓶颈不要直接上GPU业务方说AI回复好慢很多人第一反应是加机器、上更好的GPU。但AI服务慢往往慢在链路里被忽略的地方。我建议按以下顺序排查**首块Token延迟TTFT**是否很长如果是最大的可能是输入上下文过长导致预填充阶段计算量太大。此时优化方向是缩短上下文、用更小的模型或者换支持Prefill优化的推理框架。生成阶段是否平稳如果整体生成速度慢考虑输出长度限制、减小编码重复惩罚或者降级到更小的模型。上游检索是否耗时向量检索在数据量大时全量扫描会非常慢。这里要用索引如HNSW、IVF或者加一层基于关键词的预筛选。是否有串行调用有些项目里一次回答需要先调模型A做分类再调模型B做生成这会翻倍增加延迟。工程上可以把分类步骤做成一个小模型低延迟完成或者并行处理多个独立子任务。另外还有个容易被忽略的超时设置。很多服务默认的HTTP超时只有几秒模型慢一点就超时重试重试进一步加剧负载导致雪崩。把这个时间设置合理一些配合优雅降级有时候比升配置有用得多。5.3 效果差先别改模型回头查数据和评测集我犯过最典型的错误是模型效果不理想就一次次换更强的模型结果成本翻了三倍效果只提升了一点。后来复盘发现问题根本不在模型能力上而在我构建的评测集不具备代表性。这里有一个核心概念叫数据泄漏与样本偏差。如果你的评测集和测试集来自同一个分布甚至评测集里包含了开发时反复试过的样本那你在评测集上的分数就是一种过拟合。比如你反复针对某几个刁钻问题调提示词评测集的分数看似越来越高但换个环境、来一批新问题效果立刻打回原形。正确的做法是评测集一旦构建完成就冻结不再往里面塞反复调试过的样本。每次改动模型方案用冻结的评测集跑分确保分数提升是真实泛化能力的变化而不是记住了个别特例。同时定期从线上回流数据中抽一批新样本扩充评测集让评测基准和真实场景保持同步。5.4 成本失控从token用量和缓存下手性价比才是真目标大模型服务按token计费很多项目上线后成本暴增的原因很简单每次调用都塞进大量历史对话或者频繁重复调用同样的模型。省钱的方向大致有这么几个一是做语义缓存。如果用户的提问其实高度重复企业知识库场景里尤其常见可以把模型回答按输入语义哈希缓存起来命中缓存就直接返回不产生模型调用费用。实测下来这类场景的缓存命中率能做到30%以上成本直接降低三成。二是做路由分发。把简单任务分给便宜的小模型复杂任务才调用大模型。识别任务是简单还是复杂可以先用规则判断也可以用一个更快更便宜的分类模型。我做过一个客服分流项目成本降了60%效果反而提升了因为大模型不用再处理大量简单重复问答专用于复杂场景回答质量更稳定了。三是控制上下文膨胀。上文的对话历史、检索片段动态地做压缩和取舍。比如历史对话压缩成摘要只保留最近几轮原始内容既不影响多轮连贯性又能大幅减少输入token。6. 进阶心得从零到能独立负责一条AI产品线走到这里你已经掌握了从模型调用到系统搭建的完整链路。但想要独立负责一条AI产品线还需要跨越几个层面的能力升级。第一个升维是从功能开发到体验全链路。上线只是起点后续要不断根据数据反馈迭代哪些问题用户反复问但答不好、哪个环节的转人工率异常高、新增的业务知识是否及时进了索引。这一套数据驱动的迭代闭环跑起来产品才真正有了生命。第二个升维是从单点方案到多场景复用。当你做完第一个RAG项目之后下一个类似项目就会快很多但真正的高手会把里面的通用模块抽出来文档解析组件、评测工具、缓存服务、监控告警模板做成团队内部可复用的基础设施。这个沉淀过程是个人技术影响力扩散的最有效方式。第三个升维是技术判断力的养成。AI领域变化太快每周都有新模型、新框架发布。我的建议是不要追新而是建立自己的评价框架。面对新技术我通常会问三个问题它解决了什么老问题它引入了什么新问题我的项目当前痛点是否真的匹配它的优势有了这个框架面对产品经理和老板的各种新想法你也能给出靠谱的判断而不是人云亦云。我个人的体会是从零开始做AI工程最大的门槛不在技术难度而在心态。你会经历反复调优仍然无效的挫败会碰到上线前夕才发现数据有硬伤的时刻也会面对模型能力边界带来的无奈。这些都很正常它们不是你的失败而是这个领域的常态。关键系的其实是你的排查方法和工作流是否足够系统化。把数据、评测、监控这些地基打牢把每一段实验记录清楚你会发现所谓的玄学正在一点点变成可解释、可复现、可迭代的工程方法。最后再分享一个小技巧给自己建一个实验记录模板每次改动都记录三样东西——改了什么、实验了什么数据、结论是什么。这个习惯我坚持了很久它带来的直接收益是三个月后我翻记录还能清楚地知道为什么当时选这个方案、放弃了哪个方案。这种沉淀比看任何课程都珍贵因为它是你专属的、踩过坑才知道的工程经验。