1. 从零开始还是从“工程”开始想把“AI工程”这条路走通很多人第一反应是去啃深度学习论文或者把Transformers源码逐行读一遍。说实话这恰恰是本末倒置。我做了七年基础设施和机器学习平台相关的工作带过不少从零起步的工程师也踩过无数坑。看到ai-engineering-from-scratch这个项目名第一反应是亲切——它戳中了一个长久存在的误区大家总以为AI工程的门槛在“AI”但其实真正的门槛在“工程”。训练一个模型在2024年的今天已经不算什么稀奇事把模型稳定、可靠、可维护地跑在生产环境里让它和现有业务系统深度融合才是绝大多数团队真正卡住的地方。所以这个项目名义上是“从零开始学AI工程”实际上是在回答一个更本质的问题一个传统软件工程师或者一个刚毕业的学生到底需要具备哪些技能、经历哪些阶段才能成长为一个合格的AI工程师先说结论AI工程不是机器学习的子集而是软件工程在智能时代的自然延伸。它需要你懂模型但更需要你懂系统。这个项目真正有价值的地方在于它没有把“AI”和“工程”割裂开而是试图用一条完整的路径把两者串起来。接下来的内容我会围绕这个项目标题从岗位定位、技术栈、核心模块、落地路线、避坑经验五个维度展开。这套方法论我用了很多年也帮不少团队验证过希望对正在这个路口徘徊的人有实际帮助。2. AI工程师到底做什么别再把“调参”当核心2.1 岗位定位AI工程师不是算法工程师先做一个关键区分。算法工程师的核心职责是模型创新——设计新的网络结构、改进训练策略、刷榜、发论文。他们的交付物是“一个效果更好的模型”。而AI工程师的核心职责是把一个已经存在的模型变成一套稳定运行的生产系统。他们的交付物是“一套可靠、可维护、可扩展的服务”。这个区别决定了完全不同的技能树。算法工程师可以整天和损失函数、梯度、注意力机制打交道AI工程师更多的时间花在数据管道、服务编排、监控告警、版本回滚、成本控制这些事情上。用一句话概括算法工程师负责让模型变聪明AI工程师负责让模型干活。一个典型的AI应用交付链路是这样的数据采集 → 数据清洗 → 特征工程 → 模型训练 → 模型评估 → 模型部署 → 线上推理 → 反馈回收。这条链路上前四个环节算法团队可以深度参与但从模型部署开始后面的所有工作几乎都是AI工程的地盘。而且越往后工作内容和传统后端开发的交集就越大。2.2 AI工程的双线逻辑确定性系统 非确定性模型做过传统软件的人都有一个习惯追求确定性。输入固定输出必须固定出了bug可以逐步断点排查。但AI系统天生不确定——同样的输入模型的输出可能飘忽不定。这种非确定性给整个工程体系带来了连锁反应。最直接的挑战是测试。传统软件有单元测试、集成测试、回归测试跑一遍就知道对错。AI系统怎么测你没法写“断言模型输出等于预期值”因为预期值本身就不唯一。更麻烦的是调试——传统应用报错可以看堆栈模型输出错了你根本不知道是数据问题、模型问题还是推理环境问题。所以AI工程师必须具备双线思维既要用工程方法保证系统的确定性服务不挂、延迟稳定、资源可控又要接受模型的非确定性设计出能够容忍这种不确定性的系统架构。比如加一层输出校验和兜底逻辑超出置信区间就降级到规则引擎这就是典型的双线思维体现。2.3 AI工程的关键门槛评估与观测传统软件工程师转型AI最容易忽略的就是评估体系。传统开发写完功能自测一下、提测、上线流程顺理成章。但AI系统如果没有一套完善的评估体系就是闭着眼睛开车。评估分两层。离线评估是在上线前用测试集验证模型效果关注准确率、召回率、F1这类指标。在线评估是上线后监控真实业务指标比如用户点击率是否提升、客服转人工率是否下降、内容推荐的人均阅读时长是否变长。这两层评估缺一不可——离线评估做得再好线上业务效果不行就是不行。观测则是另一个经常被忽视的环节。传统系统观测CPU、内存、QPS就够了AI系统还要观测模型漂移。用户行为在变数据分布在变三个月前效果很好的模型可能现在已经悄悄退化。这时候需要通过输入数据的分布变化、输出置信度的变化等信号提前发现问题而不是等用户投诉了才后知后觉。3. 从零到一的技术栈全景AI工程师的能力地图3.1 基础层不是所有工程师都能称为“会写代码”很多转行AI的人是从“调API”开始的。调几个大模型的接口拼几个prompt跑通一个Demo就觉得入门了。但这和AI工程的距离就像会踩油门和会开F1的距离。真正的工程能力首先体现在对基础工具的熟练掌握上。Linux命令行操作、Git版本管理、Docker容器化、Python虚拟环境管理——这些看起来“太基础”的东西恰恰是生产环境里最容易出问题的环节。我面试过不少简历写得天花乱坠的候选人一问到Docker镜像怎么构建、容器和虚拟机的区别是什么就露馅了。数据能力也是基础层的重要组成。SQL是必须的而且不是会个SELECT JOIN就够要能写复杂的窗口函数做数据聚合分析。更关键的是pandas和数据处理流程——真实工作的数据没一个是干净的你需要具备数据清洗、缺失值处理、异常值识别的能力。很多工程师跑模型很溜一遇到底层数据质量问题就束手无策这就是基础不牢的表现。3.2 模型层从调用API到微调训练理解你在用什么AI工程师对模型的理解和算法工程师不一样。他们不需要从零设计一个模型但必须清楚不同模型家族的优缺点、适用场景、资源消耗。现在大模型领域你要能说清什么时候该用闭源API什么时候该部署开源模型什么时候该微调什么时候RAG就够了。这个决策过程本质上是一个成本与质量的权衡。调API最省事按量计费适合验证场景开源模型自己部署前期投入大但单次调用成本低数据隐私也有保障微调能提升特定任务的效果但需要高质量标注数据且存在灾难性遗忘的风险RAG适合知识密集型场景实现相对简单但检索质量直接决定回答质量。我用个生活化类比来说明这个选择调API像打车省心但跑长途贵自己部署开源模型像买车前期花得多但越跑越便宜微调像改装车花大价钱提升特定性能RAG像带了个资料库的助理不用改车但得靠搜索引擎给力。3.3 工程层LLMOps工具链的完整拼图如果说前面算“准备”真正的AI工程核心在“链路工程化”。一个AI应用从开发到上线至少涉及以下环节的工程化改造版本控制。模型文件动辄几百MB甚至几个GB没法用传统Git管理。需要引入模型仓库的概念像DVCData Version Control或专门的对象存储加元数据管理确保模型、数据、代码三者版本一一对应随时可以复现历史效果。实验追踪。每个prompt的修改、每个微调参数的调整都需要记录下来。建议使用专门实验管理平台进行跟踪否则团队一多你会发现根本说不清当前生产环境的模型是用什么数据、什么参数训练出来的。评估自动化。把评估过程从“手动跑几个例子”变成“自动跑完整的测试集并汇报指标”。每次模型更新、prompt修改、RAG策略调整都要触发全量评估。没有这套机制团队就永远不知道改动是变好还是变坏。推理服务化。模型的推理性能优化和部署方式选择是重点。GPU显存不够怎么优化并发上来了延迟怎么控制用vLLM还是TensorRT-LLM这些决策直接影响用户体感和成本账单。可观测性。评估、日志、追踪三位一体——评估关注业务效果日志记录每一次请求和响应追踪关注一次请求内部的完整链路。缺少任何一个维度出问题时你都会像瞎子摸象。4. 核心模块拆解一个AI生产系统的七大组件我在实际架构AI应用时习惯把整个系统拆成七大模块。这套划分方式用了很长时间无论是做内容推荐、智能客服还是知识库问答都能通用。4.1 数据管道AI系统的血液系统数据管道的核心工作包括采集、清洗、转换和存储。数据源可能是业务数据库、日志文件、第三方API也可能直接是用户的实时反馈。这些数据需要被统一处理成模型可用的格式然后存入合适的存储系统。设计数据管道时最容易被忽视的是数据质量检查。我在项目中都会在管道里嵌一套自动质检逻辑凌晨跑批时检查数据分布是否异常某个字段的缺失率是否突然升高某个类别的数量是否骤降。数据质量出问题是AI系统最隐蔽的事故——系统功能一切正常但模型效果在悄悄变差原因可能只是一次上游表结构的改动。4.2 模型服务连接模型与业务的一道关卡模型服务是整个系统里最核心的一环负责加载模型、处理输入、执行推理、返回结果。它需要解决的工程问题包括加载多个模型时的显存管理、并发请求的队列控制、推理超时的兜底处理等。一个常见的做法是把推理服务做成独立微服务与业务代码完全解耦。模型更新时业务代码不用动只是模型服务内部切换版本。而且模型服务的出入参一定要用Pydantic这类库做严格校验防止脏数据进入模型也防止模型吐出异常格式的结果返回给上层。4.3 语义检索RAG系统的基础设施过去两年做AI应用RAG几乎是绕不开的。一个高效检索模块远不是一个embedding模型加向量数据库那么简单。你需要处理文档解析的格式问题设计合适的切块策略构建混合检索关键词向量的逻辑还要优化重排和过滤规则。这块的工程细节非常多。比如切块策略切小了语义不完整切大了检索精度下降。中文场景还要考虑标点符号、段落结构、专有名词的分割问题。再比如多路召回后的融合简单做法是分数加权求和但不同检索方式的分数分布不一样直接求和并不合理需要先做分数归一化处理。4.4 外挂工具让模型“动手干活”的扩展器现实中的AI应用几乎没有只用模型生成文本就完事的。搜索、查天气、下单、刷新缓存、调用内部API——这些都需要模型学会“决定”调用工具并正确处理工具的返回结果。外挂工具模块在工程实现上需要解决几个问题一是工具的注册与描述模型需要看到每个工具的功能说明和参数定义二是调用结果的处理工具返回的数据往往需要加工后才会提交给模型生成最终回复三是安全性控制不能让模型随意触发敏感操作需要加权限校验和人工确认机制。4.5 评估系统确保“改动变好”而非“改动变坏”评估系统是AI工程的定海神针。传统开发流程里改动好坏靠单元测试判断AI系统里靠评估系统判断。每次改动必须跑一套完整的评估流程用一组典型业务问题的答案生成结果然后自动化评分。这套评估体系建立起来比较费功夫但收益极大。团队再也不用凭感觉做决策模型该不该升级prompt该怎么改RAG的检索阈值该定多少全部用评估数据说话。没有这套系统每次修改都是一次赌博。4.6 可观测性生产环境的“黑匣子”之所以把可观测性单独拎出来是因为太多团队把“日志”当成“可观测性”导致出问题时只能对着几十万行日志焦头烂额。真正的可观测性包含三个维度**Logging日志**记录每个请求的完整端到端信息**Metrics指标**聚合反映系统健康度**Tracing追踪**还原用户在系统内的完整交互链。AI系统还需要额外的“AI专属指标”每次请求的延迟拆解检索耗时、模型推理耗时、后处理耗时、模型的置信度分布、token消耗量等。4.7 AI网关统一治理和智能路由当系统逐渐复杂会需要一个统一的AIGC网关层。它的职责很清晰接入层统一认证和鉴权根据模型负载自动进行智能路由和负载均衡对后续的系统升级和扩展进行版本兼容运营侧统一管理按用户、按账单的token消耗以及部署故障时的熔断降级逻辑。避免一个业务一个部署入口无法统筹治理出了故障也无人说得清全貌。5. 从零开始的实操路线图坦白说要打好三个阶段5.1 阶段一补齐工程基础1-3个月这个阶段的目标不是学会AI而是成为一个合格的软件工程师。第一优先级是Python不是会写if else就行而是要掌握类型注解、装饰器、生成器、异步编程能写出可读、可维护的代码。其次SQL、Linux、Docker、Git以及pandas的数据处理能力都需要作为工具技能打通。推荐的实操作业是写一个完整的ETL脚本从MySQL拉数据做清洗和特征处理生成分析报表并自动化运行。这个作业看似和数据工程重叠但它握住了任何AI系统的基础逻辑数据从哪里来、怎么处理、最终给谁用。5.2 阶段二建立模型直觉2-4个月该阶段重点是打模型基础。先从AI基础概念入门起步深入理解语言模型的工作原理熟练掌握开源框架的使用熟悉经典模型的架构设计和适用场景。然后学习提示词工程理解上下文窗口、思维链、少样本学习这些概念。这时候重点建议做个可落地的项目用某个开源模型写一个客服机器人支持多轮对话、知识库检索、答案溯源。做完这个项目你基本就能体会什么是“AI工程”了——难点不在模型本身而在如何把模型嵌入业务逻辑里。5.3 阶段三构建生产级AI系统3-6个月这是真正拉开差距的阶段。围绕五个维度来建设私域知识问答系统提前铺设检索能力模型的部署上线走通完整服务化流程智能体工作流掌握任务拆解和工具决策框架评估体系构建离线在线闭环指标可观测性建设有效支撑线上问题的日常诊断。这个阶段的作业应该是一个完整的生产级项目需求分析、数据准备、模型选型、服务开发、评估上线、监控告警一站到底。做出这个项目你的能力就不再是“会调模型”而是“能独立交付一个AI系统”。5.4 技术选型建议新手的减负策略对于从零开始的人技术选型上千万不要“什么都学”。市面上好用的框架和工具很多但时间和精力有限。我的建议是紧盯三类模型侧选代表模型框架侧锁定最常用的LLM开发框架部署侧则用一套自带优化能力的推理引擎。其他工具在实际项目里按需学习。如果你在做RAG就深入学透对应的生态组件向量数据库熟悉一个即可如果你在做训练用成熟的PEFT微调框架如果你在做Agent掌握ReAct模式加回归测试链路就够起步。工具是拿来解决问题的不是拿来堆简历的。6. AI工程项目的工具箱团队一年踩坑后留下的清单实话说我自己也是对照社区里大量AI工程实践清单踩坑踩出来的。有四个代表性工具和框架实际用下来收益最大。分类工具/框架用途适用规模数据管道dbt-core Airflow / Prefect数据转换、调度编排中大型团队模型服务vLLM / KServe / Ray Serve高吞吐推理、弹性伸缩有一定流量后必上应用框架LangChain / LlamaIndex / Pydantic编排逻辑、数据验证通用评估与观测LangSmith 或自建评估系统追踪、评估、监控评估是底线LangChain大家都很熟但我的建议是用框架做工程学习没问题生产环境要谨慎。它内部的黑魔法太多很多抽象层会掩盖真实逻辑出了问题排查非常痛苦。优先选用透明、轻量的方案保证你完全可控。Pydantic则是被低估的组件它可以强制规范结构并给出清晰校验反馈强烈建议在任何涉及外部输入输出的交互处都用上。真正踩过的坑是这三个一是数据漂移由于对某个字段的取值分布变动没有感知导致接入的模型效果出现大幅波动二是评估趋同掉进“评估集都是一些简单问题”的舒适区模型迭代无数次都答得对一到真实用户那边效果就垮三是监控失明机器不报警、业务照常转但模型实际上已经退化了一个月等用户投诉才察觉到问题。7. 当前AI工程的核心瓶颈算力、数据、人的三元困局最后从行业角度把工程展开。AI项目做不大通常卡在三个瓶颈上。算力是基础设施问题。GPU很贵训练一个像样的模型动辄几万几十万。AI工程师要负责把每一分算力用到位——选择更小的模型、做量化用INT8替代FP16、用更好的批处理策略。数据是质量瓶颈。模型的想象力再强也无法无中生有。数据瓶颈通常表现为该有的数据没有采集、该清理的数据没清干净、该标注的数据没跟上。说句不好听的很多团队的模型效果不好根本原因压根不在模型结构而在训练集本身就是一锅大杂烩。人的瓶颈最微妙也最致命。AI项目往往代表新业务的尝试业务方期待AI马上创造价值工程团队则要应付漫长的链路优化。两边节奏不一致项目就悬。AI工程师要在交流上有意识地引导预期从“这个效果什么时候好”转向“基于现状这个指标可以改善到什么程度”。扁鹊见蔡桓公的悲剧不能上演。8. 写在最后关于“从零开始”的几个心态准备回到标题本身。ai-engineering-from-scratch最可贵的不是“AI”二字而是“from scratch”——它承认这条路很长不是一蹴而就。我见过太多人学了两周提示词工程就觉得掌握了AI也见过太多团队买了几张显卡就觉得AI能力到位了。他们最后都会发现模型的层数可以很深但工程的地基不能虚。说几个实际建议。先跑通再优化不要一开始就上分布式、微服务架构能跑通一个端到端的最小闭环比较关键。把评估当成第一公民在做任何AI系统之前先把“好与坏”的定义定清楚哪怕一开始粗糙也要有。拥抱非确定性思维不要迷信精准复现要做兜底逻辑、做降级方案给你的AI系统多留一条后路。如果以上说了一堆你记不住只记住一句话就行AI工程的核心不是“教会模型什么”而是“让模型在真实世界里可靠地干活”。从零开始的时候先从这个“可靠地干活”的大局出发不要被炫酷的模型细节带偏。这条路的终点不是你会调多少个模型而是你能多稳地把一个智能系统跑进生产环境——并且让它持续产生价值。 AI工程不是调参：从软件工程到生产级系统的可靠落地指南
1. 从零开始还是从“工程”开始想把“AI工程”这条路走通很多人第一反应是去啃深度学习论文或者把Transformers源码逐行读一遍。说实话这恰恰是本末倒置。我做了七年基础设施和机器学习平台相关的工作带过不少从零起步的工程师也踩过无数坑。看到ai-engineering-from-scratch这个项目名第一反应是亲切——它戳中了一个长久存在的误区大家总以为AI工程的门槛在“AI”但其实真正的门槛在“工程”。训练一个模型在2024年的今天已经不算什么稀奇事把模型稳定、可靠、可维护地跑在生产环境里让它和现有业务系统深度融合才是绝大多数团队真正卡住的地方。所以这个项目名义上是“从零开始学AI工程”实际上是在回答一个更本质的问题一个传统软件工程师或者一个刚毕业的学生到底需要具备哪些技能、经历哪些阶段才能成长为一个合格的AI工程师先说结论AI工程不是机器学习的子集而是软件工程在智能时代的自然延伸。它需要你懂模型但更需要你懂系统。这个项目真正有价值的地方在于它没有把“AI”和“工程”割裂开而是试图用一条完整的路径把两者串起来。接下来的内容我会围绕这个项目标题从岗位定位、技术栈、核心模块、落地路线、避坑经验五个维度展开。这套方法论我用了很多年也帮不少团队验证过希望对正在这个路口徘徊的人有实际帮助。2. AI工程师到底做什么别再把“调参”当核心2.1 岗位定位AI工程师不是算法工程师先做一个关键区分。算法工程师的核心职责是模型创新——设计新的网络结构、改进训练策略、刷榜、发论文。他们的交付物是“一个效果更好的模型”。而AI工程师的核心职责是把一个已经存在的模型变成一套稳定运行的生产系统。他们的交付物是“一套可靠、可维护、可扩展的服务”。这个区别决定了完全不同的技能树。算法工程师可以整天和损失函数、梯度、注意力机制打交道AI工程师更多的时间花在数据管道、服务编排、监控告警、版本回滚、成本控制这些事情上。用一句话概括算法工程师负责让模型变聪明AI工程师负责让模型干活。一个典型的AI应用交付链路是这样的数据采集 → 数据清洗 → 特征工程 → 模型训练 → 模型评估 → 模型部署 → 线上推理 → 反馈回收。这条链路上前四个环节算法团队可以深度参与但从模型部署开始后面的所有工作几乎都是AI工程的地盘。而且越往后工作内容和传统后端开发的交集就越大。2.2 AI工程的双线逻辑确定性系统 非确定性模型做过传统软件的人都有一个习惯追求确定性。输入固定输出必须固定出了bug可以逐步断点排查。但AI系统天生不确定——同样的输入模型的输出可能飘忽不定。这种非确定性给整个工程体系带来了连锁反应。最直接的挑战是测试。传统软件有单元测试、集成测试、回归测试跑一遍就知道对错。AI系统怎么测你没法写“断言模型输出等于预期值”因为预期值本身就不唯一。更麻烦的是调试——传统应用报错可以看堆栈模型输出错了你根本不知道是数据问题、模型问题还是推理环境问题。所以AI工程师必须具备双线思维既要用工程方法保证系统的确定性服务不挂、延迟稳定、资源可控又要接受模型的非确定性设计出能够容忍这种不确定性的系统架构。比如加一层输出校验和兜底逻辑超出置信区间就降级到规则引擎这就是典型的双线思维体现。2.3 AI工程的关键门槛评估与观测传统软件工程师转型AI最容易忽略的就是评估体系。传统开发写完功能自测一下、提测、上线流程顺理成章。但AI系统如果没有一套完善的评估体系就是闭着眼睛开车。评估分两层。离线评估是在上线前用测试集验证模型效果关注准确率、召回率、F1这类指标。在线评估是上线后监控真实业务指标比如用户点击率是否提升、客服转人工率是否下降、内容推荐的人均阅读时长是否变长。这两层评估缺一不可——离线评估做得再好线上业务效果不行就是不行。观测则是另一个经常被忽视的环节。传统系统观测CPU、内存、QPS就够了AI系统还要观测模型漂移。用户行为在变数据分布在变三个月前效果很好的模型可能现在已经悄悄退化。这时候需要通过输入数据的分布变化、输出置信度的变化等信号提前发现问题而不是等用户投诉了才后知后觉。3. 从零到一的技术栈全景AI工程师的能力地图3.1 基础层不是所有工程师都能称为“会写代码”很多转行AI的人是从“调API”开始的。调几个大模型的接口拼几个prompt跑通一个Demo就觉得入门了。但这和AI工程的距离就像会踩油门和会开F1的距离。真正的工程能力首先体现在对基础工具的熟练掌握上。Linux命令行操作、Git版本管理、Docker容器化、Python虚拟环境管理——这些看起来“太基础”的东西恰恰是生产环境里最容易出问题的环节。我面试过不少简历写得天花乱坠的候选人一问到Docker镜像怎么构建、容器和虚拟机的区别是什么就露馅了。数据能力也是基础层的重要组成。SQL是必须的而且不是会个SELECT JOIN就够要能写复杂的窗口函数做数据聚合分析。更关键的是pandas和数据处理流程——真实工作的数据没一个是干净的你需要具备数据清洗、缺失值处理、异常值识别的能力。很多工程师跑模型很溜一遇到底层数据质量问题就束手无策这就是基础不牢的表现。3.2 模型层从调用API到微调训练理解你在用什么AI工程师对模型的理解和算法工程师不一样。他们不需要从零设计一个模型但必须清楚不同模型家族的优缺点、适用场景、资源消耗。现在大模型领域你要能说清什么时候该用闭源API什么时候该部署开源模型什么时候该微调什么时候RAG就够了。这个决策过程本质上是一个成本与质量的权衡。调API最省事按量计费适合验证场景开源模型自己部署前期投入大但单次调用成本低数据隐私也有保障微调能提升特定任务的效果但需要高质量标注数据且存在灾难性遗忘的风险RAG适合知识密集型场景实现相对简单但检索质量直接决定回答质量。我用个生活化类比来说明这个选择调API像打车省心但跑长途贵自己部署开源模型像买车前期花得多但越跑越便宜微调像改装车花大价钱提升特定性能RAG像带了个资料库的助理不用改车但得靠搜索引擎给力。3.3 工程层LLMOps工具链的完整拼图如果说前面算“准备”真正的AI工程核心在“链路工程化”。一个AI应用从开发到上线至少涉及以下环节的工程化改造版本控制。模型文件动辄几百MB甚至几个GB没法用传统Git管理。需要引入模型仓库的概念像DVCData Version Control或专门的对象存储加元数据管理确保模型、数据、代码三者版本一一对应随时可以复现历史效果。实验追踪。每个prompt的修改、每个微调参数的调整都需要记录下来。建议使用专门实验管理平台进行跟踪否则团队一多你会发现根本说不清当前生产环境的模型是用什么数据、什么参数训练出来的。评估自动化。把评估过程从“手动跑几个例子”变成“自动跑完整的测试集并汇报指标”。每次模型更新、prompt修改、RAG策略调整都要触发全量评估。没有这套机制团队就永远不知道改动是变好还是变坏。推理服务化。模型的推理性能优化和部署方式选择是重点。GPU显存不够怎么优化并发上来了延迟怎么控制用vLLM还是TensorRT-LLM这些决策直接影响用户体感和成本账单。可观测性。评估、日志、追踪三位一体——评估关注业务效果日志记录每一次请求和响应追踪关注一次请求内部的完整链路。缺少任何一个维度出问题时你都会像瞎子摸象。4. 核心模块拆解一个AI生产系统的七大组件我在实际架构AI应用时习惯把整个系统拆成七大模块。这套划分方式用了很长时间无论是做内容推荐、智能客服还是知识库问答都能通用。4.1 数据管道AI系统的血液系统数据管道的核心工作包括采集、清洗、转换和存储。数据源可能是业务数据库、日志文件、第三方API也可能直接是用户的实时反馈。这些数据需要被统一处理成模型可用的格式然后存入合适的存储系统。设计数据管道时最容易被忽视的是数据质量检查。我在项目中都会在管道里嵌一套自动质检逻辑凌晨跑批时检查数据分布是否异常某个字段的缺失率是否突然升高某个类别的数量是否骤降。数据质量出问题是AI系统最隐蔽的事故——系统功能一切正常但模型效果在悄悄变差原因可能只是一次上游表结构的改动。4.2 模型服务连接模型与业务的一道关卡模型服务是整个系统里最核心的一环负责加载模型、处理输入、执行推理、返回结果。它需要解决的工程问题包括加载多个模型时的显存管理、并发请求的队列控制、推理超时的兜底处理等。一个常见的做法是把推理服务做成独立微服务与业务代码完全解耦。模型更新时业务代码不用动只是模型服务内部切换版本。而且模型服务的出入参一定要用Pydantic这类库做严格校验防止脏数据进入模型也防止模型吐出异常格式的结果返回给上层。4.3 语义检索RAG系统的基础设施过去两年做AI应用RAG几乎是绕不开的。一个高效检索模块远不是一个embedding模型加向量数据库那么简单。你需要处理文档解析的格式问题设计合适的切块策略构建混合检索关键词向量的逻辑还要优化重排和过滤规则。这块的工程细节非常多。比如切块策略切小了语义不完整切大了检索精度下降。中文场景还要考虑标点符号、段落结构、专有名词的分割问题。再比如多路召回后的融合简单做法是分数加权求和但不同检索方式的分数分布不一样直接求和并不合理需要先做分数归一化处理。4.4 外挂工具让模型“动手干活”的扩展器现实中的AI应用几乎没有只用模型生成文本就完事的。搜索、查天气、下单、刷新缓存、调用内部API——这些都需要模型学会“决定”调用工具并正确处理工具的返回结果。外挂工具模块在工程实现上需要解决几个问题一是工具的注册与描述模型需要看到每个工具的功能说明和参数定义二是调用结果的处理工具返回的数据往往需要加工后才会提交给模型生成最终回复三是安全性控制不能让模型随意触发敏感操作需要加权限校验和人工确认机制。4.5 评估系统确保“改动变好”而非“改动变坏”评估系统是AI工程的定海神针。传统开发流程里改动好坏靠单元测试判断AI系统里靠评估系统判断。每次改动必须跑一套完整的评估流程用一组典型业务问题的答案生成结果然后自动化评分。这套评估体系建立起来比较费功夫但收益极大。团队再也不用凭感觉做决策模型该不该升级prompt该怎么改RAG的检索阈值该定多少全部用评估数据说话。没有这套系统每次修改都是一次赌博。4.6 可观测性生产环境的“黑匣子”之所以把可观测性单独拎出来是因为太多团队把“日志”当成“可观测性”导致出问题时只能对着几十万行日志焦头烂额。真正的可观测性包含三个维度**Logging日志**记录每个请求的完整端到端信息**Metrics指标**聚合反映系统健康度**Tracing追踪**还原用户在系统内的完整交互链。AI系统还需要额外的“AI专属指标”每次请求的延迟拆解检索耗时、模型推理耗时、后处理耗时、模型的置信度分布、token消耗量等。4.7 AI网关统一治理和智能路由当系统逐渐复杂会需要一个统一的AIGC网关层。它的职责很清晰接入层统一认证和鉴权根据模型负载自动进行智能路由和负载均衡对后续的系统升级和扩展进行版本兼容运营侧统一管理按用户、按账单的token消耗以及部署故障时的熔断降级逻辑。避免一个业务一个部署入口无法统筹治理出了故障也无人说得清全貌。5. 从零开始的实操路线图坦白说要打好三个阶段5.1 阶段一补齐工程基础1-3个月这个阶段的目标不是学会AI而是成为一个合格的软件工程师。第一优先级是Python不是会写if else就行而是要掌握类型注解、装饰器、生成器、异步编程能写出可读、可维护的代码。其次SQL、Linux、Docker、Git以及pandas的数据处理能力都需要作为工具技能打通。推荐的实操作业是写一个完整的ETL脚本从MySQL拉数据做清洗和特征处理生成分析报表并自动化运行。这个作业看似和数据工程重叠但它握住了任何AI系统的基础逻辑数据从哪里来、怎么处理、最终给谁用。5.2 阶段二建立模型直觉2-4个月该阶段重点是打模型基础。先从AI基础概念入门起步深入理解语言模型的工作原理熟练掌握开源框架的使用熟悉经典模型的架构设计和适用场景。然后学习提示词工程理解上下文窗口、思维链、少样本学习这些概念。这时候重点建议做个可落地的项目用某个开源模型写一个客服机器人支持多轮对话、知识库检索、答案溯源。做完这个项目你基本就能体会什么是“AI工程”了——难点不在模型本身而在如何把模型嵌入业务逻辑里。5.3 阶段三构建生产级AI系统3-6个月这是真正拉开差距的阶段。围绕五个维度来建设私域知识问答系统提前铺设检索能力模型的部署上线走通完整服务化流程智能体工作流掌握任务拆解和工具决策框架评估体系构建离线在线闭环指标可观测性建设有效支撑线上问题的日常诊断。这个阶段的作业应该是一个完整的生产级项目需求分析、数据准备、模型选型、服务开发、评估上线、监控告警一站到底。做出这个项目你的能力就不再是“会调模型”而是“能独立交付一个AI系统”。5.4 技术选型建议新手的减负策略对于从零开始的人技术选型上千万不要“什么都学”。市面上好用的框架和工具很多但时间和精力有限。我的建议是紧盯三类模型侧选代表模型框架侧锁定最常用的LLM开发框架部署侧则用一套自带优化能力的推理引擎。其他工具在实际项目里按需学习。如果你在做RAG就深入学透对应的生态组件向量数据库熟悉一个即可如果你在做训练用成熟的PEFT微调框架如果你在做Agent掌握ReAct模式加回归测试链路就够起步。工具是拿来解决问题的不是拿来堆简历的。6. AI工程项目的工具箱团队一年踩坑后留下的清单实话说我自己也是对照社区里大量AI工程实践清单踩坑踩出来的。有四个代表性工具和框架实际用下来收益最大。分类工具/框架用途适用规模数据管道dbt-core Airflow / Prefect数据转换、调度编排中大型团队模型服务vLLM / KServe / Ray Serve高吞吐推理、弹性伸缩有一定流量后必上应用框架LangChain / LlamaIndex / Pydantic编排逻辑、数据验证通用评估与观测LangSmith 或自建评估系统追踪、评估、监控评估是底线LangChain大家都很熟但我的建议是用框架做工程学习没问题生产环境要谨慎。它内部的黑魔法太多很多抽象层会掩盖真实逻辑出了问题排查非常痛苦。优先选用透明、轻量的方案保证你完全可控。Pydantic则是被低估的组件它可以强制规范结构并给出清晰校验反馈强烈建议在任何涉及外部输入输出的交互处都用上。真正踩过的坑是这三个一是数据漂移由于对某个字段的取值分布变动没有感知导致接入的模型效果出现大幅波动二是评估趋同掉进“评估集都是一些简单问题”的舒适区模型迭代无数次都答得对一到真实用户那边效果就垮三是监控失明机器不报警、业务照常转但模型实际上已经退化了一个月等用户投诉才察觉到问题。7. 当前AI工程的核心瓶颈算力、数据、人的三元困局最后从行业角度把工程展开。AI项目做不大通常卡在三个瓶颈上。算力是基础设施问题。GPU很贵训练一个像样的模型动辄几万几十万。AI工程师要负责把每一分算力用到位——选择更小的模型、做量化用INT8替代FP16、用更好的批处理策略。数据是质量瓶颈。模型的想象力再强也无法无中生有。数据瓶颈通常表现为该有的数据没有采集、该清理的数据没清干净、该标注的数据没跟上。说句不好听的很多团队的模型效果不好根本原因压根不在模型结构而在训练集本身就是一锅大杂烩。人的瓶颈最微妙也最致命。AI项目往往代表新业务的尝试业务方期待AI马上创造价值工程团队则要应付漫长的链路优化。两边节奏不一致项目就悬。AI工程师要在交流上有意识地引导预期从“这个效果什么时候好”转向“基于现状这个指标可以改善到什么程度”。扁鹊见蔡桓公的悲剧不能上演。8. 写在最后关于“从零开始”的几个心态准备回到标题本身。ai-engineering-from-scratch最可贵的不是“AI”二字而是“from scratch”——它承认这条路很长不是一蹴而就。我见过太多人学了两周提示词工程就觉得掌握了AI也见过太多团队买了几张显卡就觉得AI能力到位了。他们最后都会发现模型的层数可以很深但工程的地基不能虚。说几个实际建议。先跑通再优化不要一开始就上分布式、微服务架构能跑通一个端到端的最小闭环比较关键。把评估当成第一公民在做任何AI系统之前先把“好与坏”的定义定清楚哪怕一开始粗糙也要有。拥抱非确定性思维不要迷信精准复现要做兜底逻辑、做降级方案给你的AI系统多留一条后路。如果以上说了一堆你记不住只记住一句话就行AI工程的核心不是“教会模型什么”而是“让模型在真实世界里可靠地干活”。从零开始的时候先从这个“可靠地干活”的大局出发不要被炫酷的模型细节带偏。这条路的终点不是你会调多少个模型而是你能多稳地把一个智能系统跑进生产环境——并且让它持续产生价值。