说起来有点讽刺我最初是从一次翻车开始认真对待AI工程的。当时团队觉得接个大模型API多简单结果一个智能客服项目拖了三个月最后线上准确率不到70%用户骂声一片。后来复盘发现问题根本不在模型——数据清洗、评测标准、版本管理、成本控制四件事全都没想清楚。也是从那时候起我开始把AI工程当作一门独立的功课来补而不是把它等同于会用几个库。如果你也在做类似的事情或者正准备从零开始进入这个领域那这篇文章应该对你有用。我会从AI工程和传统软件工程的核心差异讲起再聊基础知识的搭建、工具链选型最后用一个RAG项目实操串起全流程。整个内容都是从一个真实踩坑者的视角出发尽量说人话少谈玄学理论。1. 别急着写代码AI工程要解决的其实是不确定性很多人转AI工程第一步就栽在思维没切换过来。写普通后端接口输入是一定的逻辑是确定的输出是可断言的——但AI系统不是。模型给同样的输入可能今天回答A明天回答B哪怕温度系数调到0也有随机性。你没法像以前一样说这个接口返回的JSON必须包含某个字段你只能说95%的情况下它应该包含这个字段。1.1 为什么会调模型不等于会做AI工程我见过很多人包括我自己早期以为会写openai.ChatCompletion.create()、会调Transformers的pipeline就算会AI工程了。真正开始做的时候才发现调用模型只是整条链路上最不起眼的一环。一个完整的AI工程项目至少包含数据获取与清洗、特征/切片处理、模型调用或微调、Prompt管理、检索增强、评测体系、监控告警、成本控制、安全合规这九块。模型接口只是其中第4块的一小部分。你把模型接得再好前面数据是脏的、后面没有评测项目照样烂尾。业内有个说法AI工程是data-centric而非model-centric——绝大多数线上效果的瓶颈不在模型结构而在数据质量和评估循环。这句话我一开始不信后来项目做砸了才服气。1.2 核心矛盾离线指标好看不等于线上效果达标AI工程里最坑的一个地方是离线评估和线上表现的巨大落差。你在测试集上跑出95%的F1上线后用户一问一个错。原因听上去不复杂测试集的分布和你真实业务的分布不一致评测指标和企业想要的业务指标也不完全挂钩。举个例子我做客服机器人的时候离线测试用标准问答对准确率做到90%以上。上线之后才发现用户根本不会按标准话术提问他们会写错别字、会问长句、会夹杂情绪检索系统直接懵了。后来我们重新构建了一套基于真实用户日志的评测集指标立刻掉到60%——这才是真实水平。所以在AI工程里评测集的构建比模型选型重要得多。宁可花一个月做一套高质量评测集也不要急着换更大的模型。后面我会具体讲怎么搭评测闭环。1.3 AI工程师的一天到底在忙什么如果你期待AI工程师是天天调神经网络、发论文的角色那现实会让你失望。实际上我一天的工作有相当比例花在数据标注规范、写清洗脚本、排查召回质量和设计评测Case上。有调查说AI工程师一半时间在处理数据和特征验证模型结论只占小部分剩下的时间在跟基建搏斗处理GPU排队、修Docker镜像、优化流水线耗时。这跟传统后端工程师很像只不过你维护的对象从确定性的代码变成了带概率的模型加数据资产。想清楚这件事再决定要不要往这个方向走。它能让你接触到最前沿的技术但前提是你能扛住大量枯燥的工程活。2. 从零搭基础哪些知识真正决定你能走多远AI工程需要的基础面比较宽但跟学术研究不同它不需要你把数学推到天花板。我的体会是与其什么都学一点不如把决定项目生命周期的几块地基打牢。2.1 编程与数学基础需要的不是多而是精准编程方面Python是绕不开的。你需要熟练掌握的不是能写爬虫而是数据处理的工程能力Pandas的DataFrame操作、SQL的复杂查询、Python的抽象和面向对象设计。很多时候AI工程的代码不是模型代码而是数据管线代码这部分必须写得干净、可维护。我在面试候选人的时候一般会让他现场写一个多表关联的SQL再写一个分段处理大CSV的Python脚本。能快速写出来的人工程能力基本不错只背了一堆模型API的人大多卡在这一步。数学方面我的建议是抓住四个核心概念概率论里的贝叶斯思维、线性代数里的矩阵/向量运算直觉、统计学的假设检验与置信区间、微积分里的梯度含义。你用不到手推Transformer公式但你必须能读懂loss曲线为什么震荡、A/B测试的结果到底可不可信、两个模型之间的指标差异是否有统计意义。2.2 机器学习经典概念模型评估与交叉验证深度学习框架你会用就行但机器学习的经典评估方法必须形成肌肉记忆。准确率、精确率、召回率、F1、AUC、混淆矩阵这几个概念一定要做到能闭着眼睛解释清楚并且知道什么场景用什么指标。做工程尤其要理解样本不均衡的坑。在绝大多数真实业务里正样本比例低得可怜——异常检测可能千分之一推荐系统点击率也才百分之几。如果你拿准确率当唯一指标模型全预测正常就能有99%准确率好看是好看屁用没有。这时候要看的就是召回率、精确率以及PR曲线。交叉验证也值得花时间搞明白。线上环境不能做无限A/B测试你必须在离线阶段尽可能模拟真实分布。K折交叉验证可以帮助你评估模型稳定性尤其在数据量不大时防止模型挑数据。2.3 LLM与Agent一年内必须建立的新概念体系传统机器学习是基础但你现在做AI工程绕不开Transformer和现在的LLM玩法。你需要建立一套新的概念体系包括但不限于Token与上下文窗口、温度与采样参数、Embedding与向量检索、RAG的增删改查流程、Prompt模板与版本管理、函数调用与Tool Use、多Agent协作模式、模型微调与RLHF的基本原理。不需要你手写模型但你得清楚RAG为什么能减少幻觉、Chain-of-Thought为什么能提升推理、Agent的规划循环为什么容易跑飞。这些都是工程决策的底层依据——比如你老板问你为什么给客服系统加RAG你要能说出为了让模型能引用企业内部数据库里的真实信息而不是凭训练记忆瞎编。2.4 工程学基础DevOps、数据管线与API设计这部分容易被只看AI的初学者忽略但它恰恰是工程二字的题眼。建议系统学一遍Docker和容器编排至少能自己写一个干净的镜像把训练或推理环境固化下来学一下CI/CD的基本流程让模型和Prompt的更新能走自动化发布再学一学基本的API设计规范因为模型最终要被业务系统调用好的API设计能少吵很多架。数据管线方面需要理解ELT/ETL的基本概念知道怎么处理增量数据怎么做数据版本管理。AI工程里数据和模型是一对双胞胎你得对数据血缘、数据质量监控这些概念有基本认知。3. 工具链决策我跑第一个真实项目前的选型心得技术栈选型是AI工程里最容易劝退人的环节——选项太多每个都有人说好有人说坏新手根本分不清。我自己也经历过被框架绑架的时期这里给一些血泪经验。3.1 开发框架与其追新不如先搞透一个LLM应用开发框架方面市面上有LangChain、LlamaIndex、Haystack等一堆选择。我的建议是学习时可以多了解对比但做实际项目最好只锁定一个主框架其他作为参考。如果你做的是偏知识库问答、文档处理类应用LlamaIndex的文档解析和索引管理做得很顺手如果你的应用需要复杂的工具调用和多步骤编排LangChain的生态更丰富社区踩坑案例也多一些。但我必须提醒你的是框架抽象层越多问题定位难度越大。我自己从LangChain的早期版本一路用过来遇到过不少链内隐式逻辑与版本升级之间的摩擦现在会更倾向于在核心链路上用原生代码手写一小段编排框架只用来做封装集成。你还要考虑是否需要微调模型。如果要做PyTorch是绕不开的主力。Hugging Face Transformers库是加载预训练模型的工业标准配合PEFT库做LoRA微调在消费级显卡上也能跑通小模型微调。3.2 模型选择开源还是API我这样权衡模型选型没有绝对答案三种路线我都趟过全闭源API如直接调用大模型厂商的接口开发最快效果通常最好但数据安全性风险高成本随调用量线性增长且对模型内部行为不可控某些场景无法满足合规要求。开源模型私有化部署如Llama系列、Qwen系列、DeepSeek系列、Mistral系列等数据掌握在自己手里调用成本可控但前期有部署成本且模型能力通常比同级别闭源模型有差距。混合路线用开源模型处理高并发、敏感数据的部分用闭源API兜底复杂推理和高质量生成。我目前的偏好是混合路线。比如架构设计里信息抽取用微调过的私有化小模型面对用户复杂问答时再调用更强的大模型API。以此兼顾成本、隐私和效果。一个最容易被忽略的选型标准是模型更新频率。开源模型迭代很快闭源API也经常更新版本。选型时要提前考虑版本升级对效果的冲击最好在代码层面把模型版本作为可配置参数埋好。我吃过一次大亏底层API悄悄换了大版本Prompt风格没变但输出格式乱了全公司排查了半天才定位。3.3 基础设施从Jupyter Notebook到生产环境的跳跃做AI实验用Jupyter Notebook很正常但上生产必须搬家。我的建议是从第一天就把实验环境按项目隔离。用conda或uv管理Python版本和依赖用Docker打包镜像训练和推理环境写成声明式配置。这样后面无论是换机器还是协作都能减少在我电脑上能跑啊的尴尬。接着要解决的是GPU资源管理。如果你有内部GPU服务器配额和排队是绕不开的问题如果全部上云成本监控就得前置。我建议做一个简单的资源用量看板把每次训练的实例类型、时长、费用记下来否则月底对账时会很痛苦。推理部署部分需要掌握模型服务化的套路用什么框架做模型服务比如TorchServe、vLLM等怎么做并发控制怎么做冷启动预热怎么做扩容缩容。对于小团队开始时别搞太复杂的架构一台带GPU的服务器加一个模型服务进程配上自研的调度代码就能撑起初期业务。4. 把一个RAG应用从原型变成生产系统我不太喜欢只给概念所以用我做过的一个人事知识库问答系统作为案例带你完整走一遍从零到一的AI工程流程。为什么选RAG因为它是目前LLM落地最广、最适合初学者完整上手、又处处踩坑的场景。4.1 为什么选RAG作为第一个AI工程项目RAG检索增强生成的核心逻辑是让模型在作答之前先从外部知识库检索相关信息再把信息塞进上下文辅助生成。它能直接解决LLM最常见的两大问题知识过时和幻觉。传统微调方式要想让模型记住全套员工手册你得准备上万条QA数据训一次不说成本模型还可能把旧政策和新政策学混。RAG的方案则是把政策文档切片、向量化、存进数据库用户提问时实时检索相关片段让模型对着文档内容作答还能标注引用来源。这个模式非常贴近真实业务——企业里有大量非结构化文档像内部制度、产品手册、合规条款它们天然适合放到RAG体系里。选RAG做第一个AI工程项目还有一个理由它的每个环节都有明确度量方式你很容易建立数据→检索→生成→评估的闭环思维。这个思维一旦建立做其他AI应用都会顺手很多。4.2 数据准备80%的工程质量问题都出在这我开始做的时候以为RAG项目最难的是模型和向量库结果做下来发现最难的是数据准备。具体有四个绕不开的问题格式地狱企业内部文档可能散落在Word、PDF、Markdown、HTML、表格里。PDF尤其麻烦很多是从纸质件扫描来的直接抽文字会得到乱码和错位。处理这类问题我后来总结出一套流程先用文档解析服务把PDF转成结构化的文本块再做规则清理和人工抽样校验。切片策略文档切片看似简单实际有大讲究。切大了检索出来的块太长既浪费上下文窗口又容易混入无关信息切小了语义不完整召回结果东拼西凑。我的经验是优先按文档原有章节结构切而不是死板地按固定字符数硬切。必要时可以写个脚本把表格单独拎出来做成独立的检索单元。向量嵌入质量不要让小规模脏数据直接进向量库。先做一遍清洗去掉页眉页脚、去重、纠正明显乱码、过滤掉无意义的模板内容。嵌入模型的选择也很关键中文场景下用专门优化过的中文嵌入模型效果和通用多语言模型差异巨大。元数据管理每个切片最好都带上部门、生效日期、文档编号、权限级别等元数据。后期做权限过滤和按时间过滤检索时会非常有用。我见过太多人跳过了这些直接把几万份乱七八糟的PDF灌进向量库然后转头骂RAG效果差。说句实话那是数据没做好的锅不是RAG的锅。4.3 检索优化不是接个向量库就完事了数据准备好了向量库选型也是关键。当前常用方案里有Milvus、Weaviate这类专业向量数据库也可以用PostgreSQL加上pgvector插件。团队规模小或者数据量几万条以内pgvector完全够用还能复用你熟悉的SQL能力数据量到百万级以上再考虑独立的向量数据库。但只做纯向量检索远远不够。工程上效果最好的往往是混合检索向量召回负责语义相似关键词查询负责精确匹配比如离职流程编号F-201这类表述向量反而不如BM25好使。把两路结果做融合用Rerank模型二次排序。这个方法实践下来比单路向量检索效果提升明显。还有一个关键问题是chunk召回后的上下文组装。某个员工问年假剩余怎么查命中了两条政策片段一条是年假规定一条是查询步骤。如果你只是机械地把两条拼在一起塞给模型模型很容易答非所问或遗漏关键步骤。我建议在中间加一个重排序逻辑确保最相关信息排在前面并且允许模型在缺少信息时明确说文档中未找到相关说明。4.4 生成环节与Prompt工程Prompt在早期容易被人轻视但实际生产中它就是一个需要持续维护的代码资产。我的做法是把Prompt模板独立成文件纳入版本管理而不是硬编码在Python代码里。模板里至少包含四个部分角色定义、任务指令、参考上下文、输出约束包括格式和引用要求。Prompt的调优没有银弹但有几个实操经验值得分享指令要具体到让模型无法误解。比如不仅是回答用户问题而是只基于给定上下文回答问题上下文没有的信息必须回答未找到相关资料。给模型一个不回答的出口。这能显著减少幻觉。用少样本示例引导格式。每个示例相当于一次不耗费额外成本的微调效果立竿见影。每次修改都要做回归评测。我见过一个同事改了Prompt后某个问答变好了但其他二十个问题全部变差。没有回归测试这种劣化很难被发现。4.5 评估闭环唯一的及格线标准在AI工程里没有评测闭环的系统等于裸奔。尤其是RAG应用链路长、变量多文档更新一下、模型版本动一下、Prompt改几个字效果都可能天翻地覆。没有一套自动评测机制你根本不知道哪次改动是变好还是变坏。我的做法是构建三层评测体系第一层是检索质量评测。准备一批问题每个问题标注出标准答案对应的文档片段。跑检索后看RecallK——标准片段是否排进了前K个结果里。低于80%的召回率生成环节一定受影响。第二层是端到端答案质量评测。最简单的方式是准备几十上百条黄金问答对跑完整流程后用模型作为裁判打分或与黄金答案做相似度对比。这个过程可以借助现成的RAG评测框架做自动化但对回答质量的要求要结合企业业务定制。第三层是线上业务指标监控。比如客服场景可以统计机器人直接解决率用户未转人工而问题得到解决的比例。这一层往往能发现离线评测看不到的问题。曾经我们离线测试准确率很高线上却发现用户问怎么打印工资单时模型给出了过时的旧系统流程。原因就是文档更新了但向量索引没同步更新从此我们加了一道文档更新触发重建索引的机制。5. 从零到一踩过的坑代价最高的一课是集成阶段做RAG项目三个月我踩了不少坑。有些坑花点时间就能爬出来有些坑差点让我推翻重来。挑几个印象深的讲讲给别人当一个参考。5.1 环境与依赖Python包管理器大战AI项目依赖非常重transformers、torch、faiss、langchain、sentence-transformers每个库都有各自的版本要求Python版本可能互相打架。我之前在本地环境里numpy版本被某个库强制降级导致另一个库直接崩溃排查了两个小时。后来总结出一套相对可靠的流程每个项目独立虚拟环境是标配关键依赖的版本要锁定不能随意升级整个环境打包进Docker镜像镜像标签和代码版本一一对应。换机器部署时直接拉镜像不再从零装依赖。5.2 评测缺失导致的返工最痛的一次那是我第一次做RAG项目整个流程跑通后我看样例输出觉得不错就兴冲冲地上线了。结果运营同学每天回收一批用户反馈说回答错误率偏高。我一个个排查发现两类问题一是用户问法里带了口语化表达检索器召回质量很差二是涉及多个政策时模型经常只看一条就作答。这两个问题在做样例测试时完全没有暴露因为样例是我自己写的风格偏正式且每道题只涉及单一知识。后来我花了两个礼拜重新标注了200条真实用户问题构建了多轮评测集才把问题成体系地暴露出来然后逐一优化检索和组装策略。那次之后我彻底学乖了AI项目上线前必须用真实用户数据构建评测集而不是自己拍脑袋造问题。5.3 成本失控峰值并发是预算杀手LLM调用成本按Token计算低并发时看起来便宜但一旦业务涨起来账单会吓你一跳。我们上线第一个月某个热门功能单日对话量冲到了几千次月底一算费用比预期的多出三倍。控制成本有几个实操手段历史相似问答做缓存命中缓存就直接返回不走模型用小模型处理简单分类和抽取任务把强模型留给真正需要复杂推理的请求设置单用户日均调用上限和告警阈值对长文档提前做压缩控制送入上下文的Token量。这些手段加在一块能把整体API费用砍掉一半以上效果基本不受影响。5.4 安全与隐私不能等到上线前一晚才想起来企业内部知识库里很可能包含敏感信息员工薪酬、绩效记录、未公开的战略文档一旦RAG把它们检索出来并回答给没有权限的人就不是技术问题了。安全控制要从两个层面入手。数据层离线阶段就对文档打权限标签检索时根据用户角色做权限过滤将没有权限的切片直接排除在候选集之外。模型层在Prompt层加一道显式约束对不在权限范围内的内容必须拒绝回答。此外输入输出都要走审计日志方便事后追查。这个部分我当年差点做漏是安全部门的同事提醒才补上的。现在想都后怕——一旦出事就不是改代码能挽回的。6. 给想从零开始的你一条可以抄作业的路径最后这部分写给打算系统入行AI工程的朋友。前面讲了很多概念和教训这里给一个具体的、能照做的阶段规划。不需要你报天价培训班也不需要你等把所有数学课补完再动手。6.1 第一个月建立手感目标不是理解所有原理而是亲手把一条最简单的LLM链路跑通。注册获得大模型API额度用几千行文本搭一个最简单的、不加向量检索版的问答系统——就是把上下文直接塞进Prompt让模型回答。这个阶段你要熟悉的核心东西有API调用方式、Prompt的基础写法、Python环境管理和基础数据处理。期间会遇到的坑集中在依赖安装报错、API参数理解、输出格式不稳上查文档、看社区、多问多试就行。这个月的收获是让你对LLM的边界有真实体感知道它擅长什么、不擅长什么。6.2 第二到三个月跑通一个端到端小系统用RAG技术搭一个解决你身边真实问题的系统。我当年做的是给团队用的运维知识库问答你也可以做个人博客问答助手、课程资料问答助手、家庭文档整理助手。这个阶段要掌握文档切片的策略、嵌入模型的选择、向量库的基本使用、混合检索和重排的概念、基本的Prompt模板管理。哪怕数据量只有几百条也要把整个流程完整地走一遍并且认真做一个评测集来量化效果。做完这个项目你就具备了从零做出一套AI应用MVP的能力。6.3 第四到六个月深度参与一个真实项目尽量找机会参与一个真实业务项目。个人项目和真实项目的鸿沟在于个人项目可以不管权限、不管成本、不管并发真实项目这些问题一个都不能躲。如果你所在的公司没有现成的AI项目可以自己发起一个内部的效率工具。拿人事、财务、客服部门的重复性问题做切入点做一个内部问答机器人这就是真实需求、真实用户、真实反馈。这个项目会让你理解什么叫集成阶段最花时间也会让你真正学会处理脏数据和管理文档更新。6.4 贯穿始终把过程写下来我在整个学习过程中最受益的习惯是把自己做的每个决策和结果都记录下来包括模型选型理由、Prompt版本演进、评测集指标变化。这个习惯有几个明显好处第一复盘时有数据不会凭感觉判断第二写下来的过程会逼你把每个技术点想清楚第三日后面试和团队协作时这些都是很有说服力的积累。写博客、记笔记、发技术社区都可以形式不重要重要的是把我试了什么、为什么这么选、结果如何这条线持续记录下来。我前前后后做完几个项目后回头看自己的成长和早期的记录密不可分。我自己从传统后端转过来一路踩坑到现在最深的体会有三点一是千万别低估数据准备的工程量它是AI工程的地基二是评测闭环必须最早搭不要等项目写完了再补三是Mindset要改接受概率系统的不完美一切以线上真实效果为准。AI工程这个方向很宽从零开始也确实有不少东西要补但只要你的第一步不是刷课而是跑通一个真实的小系统后面的事情会越做越顺。按照上面的路径先动手做一个你自己的RAG应用这个过程中遇到的问题、解决的思路、留下的记录才是真正属于你的AI工程起点。