最近两三年，我几乎每周都会被问到同一个问题：想做AI工程，应该从哪开始？问这个问题的人，有刚毕业的计算机学生，有想转行的后端工程师，也有已经能跑通几个notebook但始终觉得自己隔着一层纸的前端开发者。说实话，市面上的AI学习资料已经多到看不过来了。但你只要把目光从“深度学习入门”这类标题上移开，去看那些真正在线上跑着的AI系统，就会发现理论和工程之间还有很大一段空白。这也是我特别认“ai-engineering-from-scratch”这个标题的原因——它强调的不是“AI”，也不是“engineering”，而是“from scratch”。这四个字背后真正的意思是：不靠封装好的低代码平台，不靠拖拽式工作流，而是把模型训练、数据管线、服务部署、性能调优这条路亲手走一遍。
这篇内容我会围绕“AI工程师到底需要掌握哪些核心能力”展开，梳理一条从零开始、可以落地的学习路径，包含技术栈选型的逻辑、一个RAG系统的完整实现过程、以及我在实际项目中踩过的坑。不管你是刚开始接触AI的学生，还是已经工作几年想转方向的开发者，这篇文章都值得你花二十分钟认真读完。
1. 为什么要“从零开始”重走AI工程路线
很多人不理解，现在AI工具和框架那么成熟，为什么还要从零开始？用现成的平台直接拖拽组件、上传数据集、训练出模型，它不香吗？香，但那是“使用AI”，不是“做AI工程”。工具越是封装得完美，背后的原理对使用者来说就越像黑盒。一旦黑盒出了你意料之外的错误——数据分布变了、推理变慢了、显存炸了、服务超时了——你连排查的方向都找不到，那才是真正的求助无门。
1.1 工程思维的第一课：从“能跑通”到“能交付”
我必须先把一个观念掰正：跑通一个AI模型的demo，和交付一个AI系统，是两码事。demo只需要一次性执行成功就算完成，而交付则涉及一连串问题——模型在真实数据上表现如何？高并发请求来了，服务能不能扛住？推理延迟是否满足用户体验？模型迭代后如何回滚？这些问题都不是“调参”能解决的。
在我面试候选人时，见过程度差异非常大的两拨人。一拨说起transformer架构头头是道，但问他“线上模型单GPU吞吐量大概是多少”“P99延迟怎么优化”就卡住了。另一拨人可能论文读得少一些，但能给我展示一个完整项目：从数据清洗到模型微调，再到Docker部署和监控告警，每一步都能讲清楚做了什么、为什么这么做。后面的这类人，才是“工程型选手”。这也正是“ai-engineering-from-scratch”这个标题想让你成为的人。你需要具备的是工程交付能力，而工程交付的前提是理解每个环节的底层逻辑。
1.2 AI工程师和算法研究员的分工边界
还有一个概念需要厘清：AI工程师不等于算法研究员。研究员的核心工作是探索新模型、新算法，追求指标上限。他们的产出是论文和实验报告。而工程师的核心职责是把成熟的方法落地，变成稳定、高效、可维护的服务。可以说，研究员负责“无中生有”，工程师负责“把有变成优”。
这两者没有高下之分，但技能树差异很大。研究员日常工作里花大量时间在数学推导、实验设计、论文阅读上；而工程师的工作重心则是代码质量、系统架构、部署运维和性能优化。如果你当下的目标是进入AI行业成为工程师，你就需要把注意力从“读论文”挪一部分到“写系统”上。SKlearn、PyTorch、HuggingFace这些工具的API当然要熟练，但更重要的是理解它们的局限和工程接口背后的设计逻辑。
提示：读论文和写代码的比例，对AI工程师来说至少应该是3:7。不要把自己活成一个只会调库的“API调用员”，也不要活成一个纸上谈兵的“论文复读机”。
2. 技术栈选型的逻辑：工具背后的真实取舍
AI领域的工具迭代速度非常快，几乎每半年就有一批新库出现。新手面对这个生态很容易陷入“学哪个、不学哪个”的纠结中。我的建议很朴素：不要追新，选经过社区验证、周边生态完整、文档质量高的“共识型”技术栈。就是当你在GitHub上随便搜一个AI项目，大家普遍都在用的那套。
2.1 基础能力：编程与数学的最小必要集
先聊编程。Python是AI领域的通用语言，这没什么好争议的。但我必须说清楚：Python语法只是入门，工程化需要的还包括Python的包管理、虚拟环境、类型注解、装饰器、异步编程这些进阶能力。真实项目里，你是不是能写出结构清晰的模块，是不是能处理好内存和并发，这直接决定了你的代码在线上能不能稳定运行。
数学方面，别被“高数、线代、概率论”三座大山吓到。AI工程实践中最常用的数学知识其实很聚焦。线性代数主要就是矩阵乘法、向量维度和特征分解这些概念，因为神经网络本质上是矩阵运算的叠加。概率统计方面，你至少要理解分布、期望、方差、贝叶斯公式，它们是损失函数、正则化、A/B测试的理论背景。微积分里最核心的是链式法则，因为反向传播就是链式法则的工程实现。
提示：没必要花半年刷完一本数学教材再开始写代码。先上手写模型，遇到不懂的数学概念再回去翻，带着问题学习效率高得多。AI工程是实践学科，不是纯理论学科。
2.2 模型层工具：为什么PyTorch成了默认选项
框架的选择上，PyTorch目前是绝对的主流。虽然TensorFlow曾经流行，但近几年的发展趋势非常明显，学术界和工业界都已经全面倒向PyTorch。原因也很清晰：动态图机制让调试变得直观，Python风格的API设计符合直觉，HuggingFace Transformers基于它构建，生态成熟度无人可比。
Transformer架构出现后，模型和框架之间的绑定关系也发生了变化。现在你基本不需要从零实现模型，直接用transformers库加载预训练权重即可。但注意，加载权重只是开始。你还需要掌握PyTorch的工具链，包括DataLoader、分布式训练（DDP）、混合精度训练（AMP）、TorchScript/TorchServe，这些才是工程落地要用的东西。
2.3 服务化与部署工具链：AI应用的最后一公里
模型训练完只是内部资产，交付给用户必须走服务化。这一层我最常用的组合是FastAPI + Docker + Kubernetes。选FastAPI的原因很简单——原生异步支持、自动生成API文档、基于Pydantic的数据校验，对AI推理服务来说开发效率非常高。Docker负责解决环境一致性的问题，AI项目的依赖复杂度出了名地难搞，CUDA版本、PyTorch版本、Python版本三者稍微不匹配就崩给你看。容器化之后，“在我电脑上是好的”这句话就从借口变成了事实。
Kubernetes用于大规模调度，但如果个人学习或小团队起步，可以不急着上K8s。K8s的学习曲线陡峭，运维成本也不低。早期用docker-compose编排两三个容器完全够用，等业务量真正起来了，再逐步引入K8s不迟。工程优化的原则永远是“按需引入”，千万不要为了技术而技术。
3. 从零搭建一个RAG系统：可复现的完整路径
讲完了选型逻辑，这部分我带大家从头实现一个RAG（Retrieval-Augmented Generation，检索增强生成）系统。RAG应该算当前AI工程领域最热门的落地范式之一，它的核心思想非常优雅：不把所有的知识塞进模型参数，而是先把外部知识库建好，在用户提问时检索出相关片段，再交给大模型生成答案。这样做的好处是知识可以随时更新、可控性强、还缓解了幻觉问题。
3.1 环境准备与依赖安装
第一步永远是把环境准备好。我建议使用uv作为Python包管理器，它比pip快一个数量级，而且锁文件机制能确保依赖可复现。
uv venv rag_env --python 3.11 source rag_env/bin/activate uv pip install langchain langchain-community langchain-openai \ fastapi uvicorn pypdf chromadb python-dotenv httpx pytest这里简单解释几个库的用途：langchain负责编排逻辑，langchain-openai封装模型调用，chromadb是向量数据库，pypdf用来解析PDF文档作为外部知识源。我见过不少人纠结于LangChain API变动频繁，我的建议是——可以用，但别产生强依赖。核心的编排逻辑你自己心里要清楚，框架只是帮你省时间的工具。
3.2 离线部分：知识库的构建
RAG系统的第一个关键环节，是把原始文档转换成可检索的向量索引。完整链路包括加载、切分、嵌入、入库四步。
from langchain_community.document_loaders import PyPDFLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_openai import OpenAIEmbeddings from langchain_community.vectorstores import Chroma # 1. 加载PDF文档 loader = PyPDFLoader("company_handbook.pdf") documents = loader.load() # 2. 切分文本块 splitter = RecursiveCharacterTextSplitter( chunk_size=500, chunk_overlap=80, separators=["\n\n", "\n", "。", "！", "？", " ", ""] ) chunks = splitter.split_documents(documents) # 3. 生成向量表示 embeddings = OpenAIEmbeddings(model="text-embedding-3-small") # 4. 写入向量数据库 vectorstore = Chroma.from_documents( documents=chunks, embedding=embeddings, persist_directory="./chroma_db" )切分参数值得解释一下。chunk_size设500字，是平衡信息密度与检索精度的经验值。块太小会导致语义不完整，块太大会让检索结果不够精准。overlap设为80字，是为了避免正文内容在切分边界处被截断造成信息不连续，保证跨块语义的连续性。嵌入模型我选的是text-embedding-3-small，它的维度是1536，对绝大多数场景来说性价比最高。更强更大的嵌入模型（比如text-embedding-3-large）确实更准，但维度、存储、延迟成本也更高。工程的核心就是做权衡。
3.3 在线部分：检索与生成的完整链路
知识库建好之后，在线推理阶段就简单了——用户query进来，先走一遍同样的嵌入逻辑，然后从向量库中按相似度召回top-k片段，把这些片段连同原始问题一起拼进prompt，最后交给大模型生成答案。
from langchain_openai import ChatOpenAI from langchain_core.prompts import ChatPromptTemplate from langchain_core.runnables import RunnablePassthrough from langchain_core.output_parsers import StrOutputParser retriever = vectorstore.as_retriever( search_type="similarity", search_kwargs={"k": 4} ) prompt = ChatPromptTemplate.from_template(""" 你是一个耐心、严谨的客服助手。请基于以下知识片段回答用户的问题。 如果知识片段中没有相关信息，请直接说“抱歉，我无法从内部资料中找到答案”， 不要编造内容。 知识片段： {context} 用户问题： {question} 请用中文回答： """) def format_docs(docs): return "\n\n---\n\n".join(doc.page_content for doc in docs) rag_chain = ( {"context": retriever | format_docs, "question": RunnablePassthrough()} | prompt | ChatOpenAI(model="gpt-4o-mini", temperature=0) | StrOutputParser() ) answer = rag_chain.invoke("请问年假政策是怎样的？") print(answer)这里有两个细节特别值得注意。第一个是temperature设成0。RAG场景里我们希望答案严格基于知识库的给定内容，不需要模型发挥创造力。第二个是prompt里明确写了“如果知识片段中没有相关信息，请直接说不知道”。这是最便宜、最直接的幻觉缓解手段。你给模型一个诚实的退出机制，它在不知道时就不会强行编造。
3.4 模型服务化封装
上面的代码在notebook里能跑通，但离上线还有距离。正式的服务形态应该把它封装成一个API接口。我用FastAPI来做这一层。
from fastapi import FastAPI, HTTPException from pydantic import BaseModel app = FastAPI(title="RAG Service") class QueryRequest(BaseModel): question: str class QueryResponse(BaseModel): answer: str source_count: int @app.post("/query", response_model=QueryResponse) async def query_rag(request: QueryRequest): if not request.question.strip(): raise HTTPException(status_code=400, detail="问题不能为空") result = rag_chain.invoke(request.question) return QueryResponse(answer=result, source_count=4)Pydantic的请求校验是FastAPI的强项，它自动处理字段缺失和类型错误，不用你自己写一堆if判断。这看起来平平无奇，但在工程实践中，API入参的健壮性往往决定了服务的稳定性。
4. 工程化落地的关键能力：测试、部署与监控
很多自学AI的人，学到“跑通RAG pipeline”就止步了。但离一个可交付的系统，你还有三座大山要翻：测试、部署、监控。
4.1 模型与代码的双重验证
测试这件事，传统后端工程里做得很好，但到了AI项目里就经常被忽略。我见过太多AI项目的代码逻辑没有一行测试，模型效果也只靠肉眼评估。规范的做法应该是代码测试和模型评测双轨并行。
代码层面，至少要对RAG链路中的核心函数写单元测试。比如测试文档切分逻辑是否会丢失内容、API接口面对空输入是否返回400、向量库连接失败时是否给出清晰报错。这些都是用pytest就能搞定的。
模型层面，需要准备一个评测集，里面有典型的用户问题，以及对应的期望答案或判断标准。每次修改prompt、换embedding模型、调检索参数之后，都在这个评测集上跑一遍，计算答案的准确率、完整性指标。这一步极其关键——没有评测集，你所有的“优化”都是在打黑枪，根本不知道自己改对了还是改坏了。早期可以人工评测，攒几十条问题一条条看输出。等规模大了再引入LLM-as-a-judge或者语义相似度做自动评测。
4.2 部署形态与资源估算
RAG系统部署主要分两条路线：纯CPU部署和GPU部署。如果你的embedding模型小于1亿参数、生成模型走外部API，那么CPU机器完全能扛住大部分负载，一个4核8G的云主机就能跑得很舒服。但如果你要把7B甚至更大的开源模型本地化部署，那GPU就是刚需。
关于开源大模型的选型，我建议按显存来。7B级别的模型用FP16精度大概需要14GB显存，量化后（INT4）可以压到4-5GB。13B级别的模型，FP16需要约26GB，INT4也需要约8-10GB。你可以根据这个公式倒推自己需要多大显存的卡。
生产部署时还应该引入模型推理框架，比如vLLM或TensorRT-LLM。这些框架除了单纯的推理加速以外还有连续批处理能力，能够在高并发时显著提高吞吐量。如果你的业务只有几十个用户，FastAPI直接调transformers的pipeline就够了，但量一上来，必须换推理框架。
监控方面，至少要有三个维度：一是服务层面的监控，用Prometheus + Grafana记录QPS、延迟、错误率；二是业务层面的监控，比如回答为空的比例、用户反馈不准确的次数；三是数据层面的监控，比如用户query的分布与你的知识库覆盖范围是否匹配。每一层出了问题，你的应对策略是完全不同的。
5. 避坑实录：我在AI工程中踩过的五个坑
最后这部分我整理一下自己真实遇到过的坑。每一条都是用时间和教训换来的，希望你们能绕开。
5.1 坑一：不锁定依赖版本导致的环境灾难
这是我职业生涯里最经典的一次翻车。当时部署一个模型服务，requirements.txt里写的是“pytorch>=2.0”，没有锁上限。三个月后重新部署时，pip解析到了一个新的PyTorch版本，API变了，模型推理结果直接不对。排查了一整天才发现是版本问题。从那以后我所有的项目必须用锁文件，要么用uv.lock，要么用pip-tools，并且写死小版本号。AI项目的依赖是出了名的脆弱，环境的一致性就是生命线。
5.2 坑二：盲目堆参数量导致算力浪费
早期做文本分类任务的时候，我直接上了BERT-large，因为觉得“大模型肯定更准”。结果训练时间翻了几倍，指标提升不到0.5%，部署时显存压力巨大。后来换成DistilBERT，效果几乎一样，资源消耗小一大截。这里的教训是：选模型不是选最大、最先进的，而是选“刚刚好够用”的。先用小模型快速验证pipeline，确认有效再逐步升级模型规模。
5.3 坑三：模型评估只看单点指标
“准确率从88%提升到了90%”这种话很快，但可能完全没意义。如果你的准确率是用一个分布单一、规模很小的测试集测出来的，那这个数字可能只是随机波动。尤其是类别不平衡的数据集里，准确率这个指标本身就很有欺骗性。现在做评估，我至少要同时看precision、recall、F1这三个数，并且要在不同数据子集上分层评估。比如用户来自不同地区、问不同品类的问题，模型的表现是否一致。
5.4 坑四：数据质量被当成次要问题
数据、代码、模型，这三者在AI项目里的重要性排序，很多新人理解是反的。模型架构固然重要，但真实决定项目成败的往往是数据质量。RAG系统里，知识库文本本身有错漏，你检索得再准、模型再强，答案也是错的；训练数据里有重复样本、标签打错，模型学出来的能力就是歪的。做AI工程，第一优先级永远是“把数据整理明白”而不是“把模型调得更花哨”。
5.5 坑五：把“从头预训练模型”当成必然选择
不少新人来问我“怎么从零训练一个LLM”，我通常都会反问一句：你的场景真的需要吗？从零预训练一个模型，按现在的主流规模，至少需要数千张GPU卡训练数月，成本高达数百万美元，这不是普通团队该碰的事。我的建议是，除非你的业务有完全特殊的数据分布和极其充沛的预算，否则在开源基座模型之上做微调就完全足够了。工程落地要的是性价比，而不是干一件“看起来很酷”的事。
我从自己的经验里选了一句特别想分享的话：AI工程的核心竞争力不是会调用多少模型，而是当你面前这条链路——从数据处理、模型训练、服务部署再到线上监控——任何一个环节崩掉的时候，你能第一时间定位问题并修复它。从这个角度看，“ai-engineering-from-scratch”不是一个教程标题，而是一面镜子。真正走完这条路的人，获得的不是某一个孤立的技能点，而是一整套识别问题、拆解问题、解决问题的能力。如果你此刻正站在起点，不妨先別急着收集资料，选一个具体场景，比如“给公司文档做一个智能问答助手”，然后亲手把这个系统从零搭起来。跑通之后你会发现，后面还有无数优化空间等着你——那时候你才算真正入了AI工程的门。
