★ FEATURED ARTICLE 这两年我经常被同一个问题拦住“我是零基础想搞 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 量化后约 7GBINT4 量化后约 4GB。如果你的 GPU 只有 8GBINT8 通常是最稳的选择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 的输出天然不确定因此围绕不确定性的容错、评估、回滚、监控才是这门手艺真正的门槛。希望这篇路线图能让你少走一些弯路把有限的精力投在真正该学的东西上。
阅读完成 · 觉得有帮助？
