AI工程从零开始：核心能力与RAG系统实战路径

最近两三年我几乎每周都会被问到同一个问题想做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系统可复现的完整路径讲完了选型逻辑这部分我带大家从头实现一个RAGRetrieval-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_size500, chunk_overlap80, separators[\n\n, \n, 。, , , , ] ) chunks splitter.split_documents(documents) # 3. 生成向量表示 embeddings OpenAIEmbeddings(modeltext-embedding-3-small) # 4. 写入向量数据库 vectorstore Chroma.from_documents( documentschunks, embeddingembeddings, 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_typesimilarity, 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(modelgpt-4o-mini, temperature0) | 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(titleRAG Service) class QueryRequest(BaseModel): question: str class QueryResponse(BaseModel): answer: str source_count: int app.post(/query, response_modelQueryResponse) async def query_rag(request: QueryRequest): if not request.question.strip(): raise HTTPException(status_code400, detail问题不能为空) result rag_chain.invoke(request.question) return QueryResponse(answerresult, source_count4)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需要约26GBINT4也需要约8-10GB。你可以根据这个公式倒推自己需要多大显存的卡。生产部署时还应该引入模型推理框架比如vLLM或TensorRT-LLM。这些框架除了单纯的推理加速以外还有连续批处理能力能够在高并发时显著提高吞吐量。如果你的业务只有几十个用户FastAPI直接调transformers的pipeline就够了但量一上来必须换推理框架。监控方面至少要有三个维度一是服务层面的监控用Prometheus Grafana记录QPS、延迟、错误率二是业务层面的监控比如回答为空的比例、用户反馈不准确的次数三是数据层面的监控比如用户query的分布与你的知识库覆盖范围是否匹配。每一层出了问题你的应对策略是完全不同的。5. 避坑实录我在AI工程中踩过的五个坑最后这部分我整理一下自己真实遇到过的坑。每一条都是用时间和教训换来的希望你们能绕开。5.1 坑一不锁定依赖版本导致的环境灾难这是我职业生涯里最经典的一次翻车。当时部署一个模型服务requirements.txt里写的是“pytorch2.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工程的门。