这两年我经常被同一个问题拦住：“我是零基础，想搞 AI 工程，到底从哪开始？” 问的人里有刚毕业的，有传统后端想转方向的，也有本身做数据分析想往上游走。我给过很多次零散的回答，后来干脆把这条“ai-engineering-from-scratch”的完整路线整理出来，按我实际走过的路，从底子、工具链、流水线到落地部署逐一拆开讲。这大概是目前我能给出的最不掺水的一份入门地图。
这篇内容的目标很明确：帮你建立 AI 工程领域的完整坐标系，知道每个环节在解决什么问题，哪些必须学、哪些可以暂缓，并且能照着搭出第一条可用的 AI 应用管线。它适合所有刚接触 AI 工程、手上资源有限、又不希望被培训课带偏的人。全程不堆名词，只讲我踩过的坑和仍然有效的做法。
1. 先想清楚：AI 工程到底在解决什么问题
1.1 为什么“从零开始”的路径值得重新梳理
我见过太多人一上来就抱着 Transformer 论文啃，啃了两个月还是写不出一行能跑的推理代码。问题的根源不是智商，而是把“AI 工程”和“AI 科研”混为一谈。AI 工程的本质不是发明新算法，而是把已经存在的模型、数据、算力组织成一条稳定、可维护、可交付的生产链路。
从零开始学 AI 工程，最忌讳的是按大学课程表来。传统机器学习课程会把大量时间花在数学推导和算法原理上，它们有价值，但在工程语境下，你更需要先具备“拿现成模型跑通—调优—部署—观测”的能力。原理可以在实践中补，工程手感却只能靠一次次踩坑攒出来。
另一个常见的错误是过度崇拜“大而全”。有些路线图列了 20 门课、8 种框架、3 个云计算平台认证，看着很系统，实操起来三个月就放弃。我自己的经验是：先选一条极窄的端到端路径，比如“用开源模型做一个文档问答机器人”，把它完整跑通，再横向扩展。这个思路贯穿整篇文章。
1.2 AI 工程和算法岗、数据岗的边界在哪里
入行之前，有必要把几个岗位的边界弄清楚。算法岗的核心目标是提升模型指标，比如准确率、召回率，工作重心在实验和调参；数据岗的核心目标是让数据可用、可靠，工作重心在管道调度和数据质量。AI 工程岗夹在两者中间，既要知道模型的基本原理，又要操心底层资源够不够、接口稳不稳定、日志全不全。
这条边界决定了你的学习重心。算法岗要啃透 loss 函数的梯度走向，AI 工程更多时候只需要知道“这个超参大概影响什么”；数据岗要精通 SQL 和调度系统，AI 工程则要懂一点数据校验，但不用做到专业数仓工程师的深度。说白了，AI 工程是“翻译层”和“粘合层”——把算法成果翻译成可用的服务，把数据能力粘合进业务系统。
如果你本身是后端开发出身，这反而是巨大的优势。模型推理本质上是高并发、低延迟的服务，传统的服务治理、缓存、降级、可观测性经验在 AI 工程里全部适用。我团队里上手最快的新人，往往是有三年以上后端经验的那批，不是算法基础最好的那批。
2. 根基：从零起步必须具备的三块硬底子
2.1 编程能力——用“能做工程”的标准要求自己
AI 工程的首选语言，到今天依然是 Python，没有之一。原因不是 Python 性能强，而是它的生态已经把模型加载、数据处理、服务发布全包揽了。你可以用 C++ 写推理引擎，但作为从零起步的人，最合理的策略是用 Python 把整条链路打通，再在性能瓶颈处用更底层的语言优化。
编程能力不需要达到刷穿 LeetCode 的水平，但有几个硬指标：能熟练使用requests、pydantic、numpy、pandas这些基础库处理真实数据；能读懂常见的异常栈并动手排查；能写简单的单元测试；会用git做日常版本管理。我面试工程岗时，最常考察的编程题是“给一个 JSON 文件，写一个脚本做字段抽取和清洗”，能干净利落完成的人，通常工程底子不会差。
这里还有一个进阶建议：尽快熟悉 Python 的虚拟环境和依赖管理。AI 项目的依赖冲突远超普通后端项目，torch、transformers、cuda版本稍微错一个数，一整天就搭进去了。我的习惯是每个项目从第一天就用uv或conda管理环境，绝不偷懒装进全局环境。
2.2 数学怎么补——不追求推导，追求会看懂
很多零基础的人被“线性代数、概率论、高等数学”三个大石头吓退。我的建议是换一套标准：不需要会推导，需要会看懂。看懂意味着你知道矩阵乘法在神经网络里是“批量变换数据”的手段，知道概率分布是“描述不确定性”的工具，知道梯度下降是“沿最陡方向找最优”的迭代过程。
真正用到数学的地方，在模型训练和调参的阶段。比如你设学习率，要明白太大会震荡、太小会龟速收敛；你处理类别不平衡，要理解为什么交叉熵损失会对少数类不友好。这些理解不依赖复杂的公式推导，但需要你对核心概念有直觉。我推荐的补法是以项目带数学：跑了第一次训练之后，再回来看反向传播的图解，立刻就能看懂。
如果能抽出三周时间，我建议系统过一遍 3Blue1Brown 的线性代数系列和微积分系列，配合《深度学习》花书的前四章。注意，是配合，不是先修。数学应该是工程的补给站，而不是拦路虎。
2.3 机器学习基础——理论到代码的临界点
机器学习基础这部分，关键不是背下来算法的名字，而是理解监督学习、无监督学习、过拟合、评估指标这几根主线。你不需要从零实现一个 SVM，但你要知道：什么时候用正则化，为什么验证集不能当测试集用，AUC 和准确率在什么场景下会骗人。
我的经验是，用 20 小时刷完 Kaggle 上最经典的 Titanic 或 House Prices 题目，比看三本书都管用。这个过程的重点不是拿高分，而是完整走一遍数据探索、特征工程、模型训练、交叉验证、结果提交的闭环。一旦你亲手做过一次，再去看任何 AI 项目的代码，骨架都能对上。
从零开始阶段，我强烈建议对“传统机器学习”和“深度学习”都要有最低限度的认知。传统模型如 XGBoost、LightGBM 在有结构化数据的场景下依然能打，很多工程项目的基线就是它们；深度学习则是处理文本、图像、语音的主流方案。两者不是替代关系，是工具柜里不同的扳手。
3. 工具链选型：实践中的主流组合与取舍
3.1 核心语言与训练推理框架
框架选型是每个新手都会纠结的问题。我的结论是：从 PyTorch 开始，没有之一。PyTorch 的调试体验、社区规模、和 Hugging Face 生态的兼容度都是目前最成熟的。TensorFlow 至今仍有一些生产部署存量，但新项目没必要再往这条路上趟。
除了训练框架，transformers这个库是绕不开的基础设施。它把几千个预训练模型封装成了统一的接口，加载、分词、推理都只需要几行代码。你不需要自己写 Attention 实现，但需要知道from_pretrained加载的是权重和配置，AutoTokenizer负责文本到 token 的转换。理解这三者之间的关系，是调通一切 LLM 应用的起点。
accelerate是另一个隐藏神器，它在你从单卡试验往多卡训练、混合精度训练迁移时能省大量时间。我的习惯是新项目默认就加上accelerate的 launch 方式，哪怕暂时单卡跑，后续扩展的改造成本也最低。
3.2 LLM 应用开发与编排工具
如果你目标是在大模型之上做应用，LangChain和LlamaIndex是两座绕不开的桥。它们解决的问题高度类似：把模型调用、提示词管理、文档切块、检索增强、输出解析这些环节编排起来。个人观点是，LangChain 功能覆盖面更广，但抽象层级多、版本变化快；LlamaIndex 在文档检索这个场景上更聚焦。
我的实际建议是：先用裸代码 +requests或openaiSDK 把一次 RAG 流程手写一遍，再去看框架。原因很简单，框架帮你封装了复杂度，但如果你不理解底层流程，出了问题只会写“bug 在哪”。手写一遍之后，你再用框架，会发现每一步它做了什么、有什么坑，清清楚楚。
提示词工程是 LLM 应用开发里最像“玄学”的部分，但我认为它是可以系统化的。核心套路无非几条：给角色、给背景、给输入格式、给输出约束、给示例。我的习惯是设计提示词时先写“如果我是建模工程师，我需要什么信息来做判断”，然后把这份信息需求转换成提示词结构，最后用小批量测试样本跑五到十个 case，统一优化。
3.3 数据存储与向量检索选型
AI 工程绕不开向量检索。做 RAG 应用时，向量数据库的选型直接影响检索效率和准确率。市面上有专门做向量的Milvus、Qdrant、Pinecone，也有在传统数据库上扩展向量能力的pgvector。我的选型口径很简单：如果项目规模在百万级向量以下，团队又有 PostgreSQL 运维基础，pgvector是最省事的选择；如果向量规模大、查询复杂度高，就上Milvus这类专用引擎。
千万不要忽略“混合检索”这个方向。纯向量检索对语义理解很有优势，但对精确关键词匹配、数字区间过滤、状态筛选这类场景反而容易翻车。成熟的方案是向量检索 + 关键词检索 + 元数据过滤三者组合，再做结果重排。我的经验是，第一次做 RAG 产品，先别把宝全押在向量检索上，加上一层倒排索引做候选召回，效果往往立竿见影。
数据部分的另一个重点是数据版本。模型可以回滚，数据也必须能回滚。每次清洗逻辑变更，我都习惯给数据集加版本号，并记录完整的清洗管道参数。这不是管理洁癖，而是当你发现模型效果突然后退时，能快速定位是代码问题、数据问题还是模型问题。
4. 从零搭建第一条 AI 工程流水线
4.1 需求拆解与方案设计
假设你现在要做一个“合同关键信息抽取”的工具，这是 AI 工程里非常典型的任务。第一步不是选模型，而是和需求方对齐几件事：输入是什么格式的文档（PDF、Word、扫描件）、输出需要哪些字段、准确率的最低线是多少、单条处理的延迟能不能超过 5 秒、数据能不能出内网。
这些约束直接决定方案设计。如果数据不能出内网，就排除所有云端 API；如果要求单条延迟低，就不能上过大的开源大模型；如果字段有严格的枚举范围，可以叠加规则校验来兜底。我的方案设计习惯是：先划出“必须达成”和“最好达成”的分界线，再选择一条满足必须项的最简路径。
方案设计里最容易被低估的是兜底逻辑。模型输出的字段可能缺失、可能格式错乱、可能置信度低，任何 AI 产品都需要设计一套降级策略。常见的兜底包括：规则抽取、默认值填充、人工复核队列。不要等到上线后才发现模型输出 20% 是空字段，而业务方完全没法接受。
4.2 数据准备与预处理
数据环节通常是整个项目里最耗时，也最不性感的部分。我自己的观察是，一个成熟的 AI 工程项目，数据准备往往占 40% 以上的工作量。不是模型有多难，而是“让数据符合模型的输入要求”这件事比想象中繁琐得多。
预处理在文本任务里至少包含几层：格式转换（PDF 转纯文本）、编码清洗（去掉不可见字符和乱码）、段落切分（按语义边界切片而不是硬切固定长度）、质量过滤（去掉重复片段和广告模板）。每层的必要性都会在实际评测中体现。我记得第一次做合同抽取时，没做编码清洗，结果模型在包含全角空格和特殊符号的字段上表现奇差，后来加了清洗规则，指标直接涨了 5 个点。
数据标注是另外一个绕不开的话题。如果没有现成标注团队，我建议先小批量标注 200 到 300 条，跑通预处理、训练、评测的整个闭环，再决定是否扩大标注规模。这种方式能在早期暴露任务定义不清晰的问题——比如“合同金额”到底包不包括含税金额，只有看标注争议的时候才会真正浮现。
4.3 模型接入与微调策略
在 H100 时代，从零预训练一个大模型早就不是工程界的常规选项。绝大多数 AI 工程的模型策略只有三种：直接调用云端大模型 API、用开源预训练模型做推理、在开源模型基础上做参数高效微调（PEFT）。三者的取舍主要看数据隐私、成本、效果三个维度。
微调是很多人最兴奋的环节，也是翻车最密集的环节。我踩过的第一个坑，是用全量微调（Full Fine-tuning）把 7B 模型的所有参数都更新了一遍，结果训练成本高不说，还出现了严重的灾难性遗忘——模型原本的通用问答能力全丢了。后来全线切到 LoRA，只更新很小一部分低秩矩阵，效果不仅没掉，训练成本直接降了一个数量级。
LoRA 的实操有几个要领：秩（r）的取值通常在 8 到 64 之间，秩太小模型学不进新知识，秩太大会让训练变慢且有遗忘风险；学习率比全量微调要大一截，通常可以用到 1e-4 到 3e-4，然后配合余弦退火；训练数据量不是越大越好，几百条高质量数据足够，关键是覆盖尽可能多的边界场景。
微调之后一定要和基座模型做对比测试。我见过一种低级的错误：微调之后效果确实提升，但拿对比的基线是"未微调且没有走完整提示词模板"的模型。正确的对比方式是同一提示词模板、同一设备条件、同一组测试样本，只有变量是“有没有微调”这一项。
4.4 评测与验证闭环
评测是整个 AI 工程流水线里最能拉开水平差距的环节。很多团队把模型跑通就当作完成，结果上线后问题百出。完整的评测至少要有三层：单测层（特定边界 case 的自动化断言）、离线层（一批有标注的测试集上的指标计算）、在线层（灰度流量里的用户反馈和效果观察）。
我自己的习惯是，每次项目启动的第一周就把评测集建好，哪怕只有 100 条。这些数据不是从训练集里抽样，而是独立采集、贴近真实业务分布的样本。后续每一次改 prompt、换模型、加知识库，都用这套评测集统一回归。没有这套机制，你所谓的“优化”很容易变成“过拟合某几个 case 的手工调参”。
评测指标的选择也要因任务而异。信息抽取类任务，只看准确率会掩盖很多问题，我通常同时看字段级的精确率、召回率和 F1，再单独统计空值率和格式错误率。对于生成类任务，传统的 BLEU、ROUGE 只能做参考，我倾向于加一层 LLM-as-Judge 的自动评估，用一个大模型打分辅助人工抽检。
5. 落地部署：从能跑到跑稳的工程化改造
5.1 推理服务化与性能优化
模型在笔记本上跑通和在生产环境提供服务，完全是两个世界。推理服务化要做的第一件事是统一推理入口。我通常是基于 FastAPI 封一层推理服务，对外暴露统一的 HTTP 接口，内部做模型加载、预处理、推理、后处理。这个服务的核心指标有三个：首 Token 延迟（TTFT）、吞吐量（Tokens/s）和可用性。
性能优化有几条常用的路径。第一条是模型量化，把模型从 FP16 压到 INT8 或 INT4，显存占用直接减少一半以上，但效果损失通常可控。第二条是批处理，把多个并发请求攒在一起做动态批处理，GPU 利用率能显著提升。第三条是缓存，对重复的请求或高频的公共前缀做 KV Cache 缓存，能省下大量重复计算。这里给一个实际的量化经验：7B 模型 FP16 需要大约 14GB 显存，INT8 量化后约 7GB，INT4 量化后约 4GB。如果你的 GPU 只有 8GB，INT8 通常是最稳的选择，INT4 在部分任务上已经能感到明显的效果下降。
服务化之后，还要设计好超时控制和限流机制。模型推理不是越快越好，而是要在约定时间内返回稳定结果。我习惯在网关层设置两级超时：连接超时 3 秒、读取超时 120 秒，同时在应用层把模型推理的内部超时设置为 60 秒。超过限制就主动中断，避免线程池被拖垮。
5.2 监控、日志与版本管理
模型上了线，监控就是你的眼睛。传统的后端监控关注 QPS、错误率、延迟，AI 工程在这之上还要额外盯几个指标：GPU 显存占用率、显卡温度、请求的输入 Token 数、输出 Token 数、以及每一次推理请求的落盘日志。日志里至少要包含模型版本、提示词版本、输入摘要、输出摘要、耗时，这样任何线上问题都能回溯到具体版本。
这里我要重点强调“版本管理”的四个字：代码版本、模型版本、数据版本、提示词版本，必须四者联动。我在生产中见过一次严重的线上事故，提示词模板悄悄改了措辞，新模型没有做过评估就被灰度上了 50% 流量，结果对话生硬度暴增，用户投诉率飙升。事后排查发现，提示词和模型都换了版本，但没有任何一个环节把它们绑定记录。从那以后，我要求每次发版都必须生成一份“版本快照”，记录四个维度的唯一标识。
可观测性工具链方面，如果是中小规模项目，我推荐 Prometheus 采集指标、Grafana 做可视化、Loki 收集日志，这套组合开源且社区成熟。如果团队已经有内部的监控平台，直接接入现有的链路追踪体系更省心。核心原则只有一个：所有状态可查，所有决策可追溯。
5.3 成本控制与资源规划
很多人低估了 AI 工程的核心成本不是代码，而是运行时的算力消耗。一个 7B 模型以 INT8 精度跑推理，即便在单卡 A10G 上，也是每小时几块钱的成本，在高并发场景下，一个月跑出几万块的账单很常见。所以从架构设计的第一天就要想成本。
降低成本最有效的手段之一是“按需部署多档模型”。高频简单请求走小模型，低频复杂请求才调用大模型，流量感知的路由策略可以省下 40% 以上的推理成本。这一点在 LLM 应用里尤为重要，比如一个客服助手，简单问候直接走 1.5B 模型，涉及多轮复杂问答才升级到 7B 或更大模型。
资源规划还要考虑弹性伸缩。GPU 资源不像 CPU 那样随时可以扩展，云厂商的 GPU 实例通常需要预购或抢占式实例配合。我的经验是，核心负载用按量的常驻实例保证稳定，非核心负载可以用抢占式实例节省成本。如果没有专门的运维团队，我建议先固定资源，用监控数据证明瓶颈之后再做伸缩方案，别一上来就搞复杂的自动扩缩容。
6. 常见问题与实战排坑实录
6.1 环境与依赖问题
AI 工程的第一大敌是环境不一致。我几乎每个月都会碰到一次“我本地没问题”的灵异事件。最常见的坑是torch和 CUDA 版本不匹配。torch2.x 系列对 CUDA 版本有严格绑定，装错版本轻则无法使用 GPU，重则运行时报非法指令。排查思路很简单：先确认nvidia-smi看到的驱动支持的 CUDA 版本，再检查torch.version.cuda是否与之兼容。
我的建议是用 Docker 把环境固化下来。写一个Dockerfile，确定基础镜像、Python 版本、PyTorch 版本和 CUDA 运行时，团队所有人都基于同一镜像开发。虽然 Docker 有学习成本，但比起“每台机器都要重新踩一遍环境坑”，这点成本非常划算。
环境问题里还有个隐蔽的坑是内存溢出。加载一个大模型到 CPU 再搬到 GPU，过程中内存峰值会很高。你可能会看到进程被 OOM Killer 直接杀掉，日志里没有任何 Python 异常。解决办法是用torch.cuda.empty_cache()及时释放缓存，配合accelerate的 device map 机制，让模型按层分布在多张卡上，避免一次性全部载入内存。
6.2 推理质量与延迟问题
效果不好先别急着换模型，先系统排查四个环节。第一个是提示词是否把任务描述清楚了，我见过大量效果问题仅仅是因为 prompt 里没有说明输出的格式限制；第二个是知识库/检索链路返回的上下文是否有冗余信息，检索结果质量差会直接拖累生成质量；第三个是后处理是否把模型输出解析对了，很多模型会自己加解释文本，不清理就会混入最终结果；第四个才是模型本身的能力瓶颈。
延迟问题上，大部分情况下瓶颈不在模型，而在预处理和后处理。我曾经排查过一个首 Token 延迟高达 8 秒的案例，最终定位到问题在 PDF 解析库加载了超大的字体资源文件。把字体加载延迟到首次使用时，首 Token 延迟直接从 8 秒降到 1.5 秒。优化性能时，先画一条完整的请求链路清单，逐环节打点计时，用数据说话，别凭感觉改代码。
6.3 生产环境稳定性问题
线上推理服务最常见的不稳定因素之一是冷启动。GPU 实例在空闲很久后重新接收请求，模型从磁盘加载到显存需要几十秒，第一次请求往往超时。解决办法是引入预热机制：服务启动后主动发几条虚拟请求完成模型加载，同时配置健康检查只在实际加载完成后标记为 ready。
还有一个高频事故是“OOM 撞车”。多个推理服务同时跑在同一块 GPU 上，显存不够时新请求直接报错。我建议给每个推理服务配置显存限额，并做请求级的并发控制，确保单卡上的并发数不会突破显存上限。Kubernetes 环境下可以使用显存调度插件实现更精细的资源分配。
最后要提一个掏心窝的建议：任何模型上线前，必须准备一个“一键回滚”方案。没有人能保证新模型一定更好，甚至同一模型重新量化后都可能有波动。我的做法是保存最近三个版本的模型权重，并让网关支持按版本号实现分钟级切流。这个机制看似简单，关键时候能救整个团队。
7. 一条可持续的成长路径
写到这里，整条“ai-engineering-from-scratch”路线已经清晰了：从工程思维出发补齐编程和数学底子，选对工具链，跑通一条最小可用的流水线，再逐步补上部署、监控、成本这些生产化能力。这套路径走下去，你大概率能在三个月内拥有自己完整的 AI 应用作品。
最后分享一个长期心得：AI 工程的学习永远是一个循环——做项目、遇到问题、拆解问题、补基础、再回去做更大的项目。不要试图把所有基础都补齐了才动手，那样你永远在准备，永远不出发。先允许自己做出一个糟糕但能跑的系统，然后在一次次“糟糕”中变得可靠。
我到现在还记得自己第一次把 RAG 应用部署上线时，被同事问“你这里为什么在高德地图 API 方向上做了容错”，当时我愣了一下，随后意识到 AI 工程和普通后端工程的区别恰恰就在这里：AI 的输出天然不确定，因此围绕不确定性的容错、评估、回滚、监控才是这门手艺真正的门槛。希望这篇路线图能让你少走一些弯路，把有限的精力投在真正该学的东西上。
