做AI工程不是调库别被从零开始这四个字吓到但也别被它骗了。我见过太多人拿着一堆课程清单学了三个月还在纠结该先学PyTorch还是TensorFlow最后连一个能跑的端到端项目都没做出来。真正有效的ai-engineering-from-scratch不是让你把线性代数从第一章啃到最后一章也不是让你把Transformer论文倒背如流而是建立一条能动手、能出活、能上线的主线——把数据、模型、接口、部署、评测、迭代这整条链路走通一遍。这篇文章就按我自己踩过的路把这条主线上的关键节点、真实选型逻辑和避坑经验完整拆开讲清楚适合刚入门想系统搭建AI工程能力的人也适合已经在做算法但被工程问题反复折磨的从业者。1. 先搞清楚AI工程到底在干什么1.1 它和算法研究、数据分析根本不是一回事很多人一听到AI工程第一反应是搞模型的第二反应是调参的。这两个印象都不准确。AI工程的核心不在模型本身有多聪明而在模型怎么才能稳定地、可维护地、低成本地跑在真实业务里。同样是训练一个文本分类器算法研究员关心的是F1能不能再涨0.5个点而AI工程师关心的是这个模型给到线上之后遇到没见过的输入会不会崩每天新增的数据怎么回流再训练推理延迟能不能压到200毫秒以内GPU成本一个月能不能控制在预算内我把这三类工作做过一个粗浅的类比。算法研究像是做菜谱研发——重点在于新配方、新工艺能不能做出一道惊艳的菜。数据分析像是做食品安全检测——重点是看数据里有没有异常、趋势是什么。AI工程则更像是开餐厅——不仅要有一道拿得出手的招牌菜还得考虑供应链、后厨动线、出餐速度、服务员培训、顾客投诉处理。你光有菜谱不行光会检测也不行得把整套流程跑顺。所以ai-engineering-from-scratch这个题目里的engineering我理解的重心一直落在后半截怎么把一个AI想法变成一条可持续运转的生产链路。这个认知如果一开始没立住后面很容易学偏——学了一堆模型结构却连一个最简单的Web服务都部署不明白。1.2 从零开始要建立的是全链路视角不是知识点堆砌我自己在整理这套从零开始的体系时最先做的不是列学习清单而是画一条完整的主线——从业务问题出发到数据准备、模型选型与训练/微调、服务化部署、监控反馈、迭代优化。每个环节都需要对应的工程能力而这些能力往往是交叉的。这条主线上的典型问题包括数据从哪来、质量怎么保证模型选多大的、要不要微调还是直接用现成API服务用什么框架封装、怎么处理并发模型输出怎么校验线上效果怎么评估——是看用户反馈还是看指标模型什么时候需要重训出了badcase怎么回溯归因。任何一个环节掉链子整个系统的体验都会崩盘。我见过一个很典型的反面案例团队花大力气微调了一个行业大模型效果演示的时候惊艳全场结果上线第二天就出事故——没有做输入输出的长度限制用户一次性扔进来一本几万字的书直接把推理服务的内存打满所有请求全部超时。这不是模型的问题是工程上没考虑边界。从零开始学AI工程最该先建立的恰恰就是这种边界意识——永远假设输入是不可信的系统是会被打崩的模型是会胡说八道的。2. 从零开始的底层地基哪些基础真正绕不开2.1 数学要补到什么程度才算够用这是劝退最多人的地方。我直说结论做AI工程不需要你是数学系出身但有几个概念必须形成直觉否则后面调参、排查问题时会非常痛苦。第一个是向量和矩阵的基本运算。为什么必须会因为现在整个AI生态的底层都是向量计算——文本要转成向量图片要转成向量两个东西像不像就看向量距离。你不用会手推矩阵分解但你得知道点积大说明方向一致、余弦相似度是归一化后的夹角这些直觉。我见过有同事调RAG检索效果时死活想不明白为什么召回的结果不相关后来发现是 embedding 没做归一化向量距离算出来的都是畸形的——这就是基础直觉缺失的直接代价。第二个是概率和统计的基础。模型输出的本质是概率分布评测指标的本质是统计量。你要理解置信度0.3不代表有30%概率是对的也要理解A/B测试里为什么样本量不够时结果不可信。这些不需要你背复杂的公式但需要你有量化的思维方式。第三个是梯度下降的直觉。你不需要手动推导反向传播但你得知道learning rate太大模型会震荡、太小收敛慢、batch size影响梯度噪声这些概念在调参时会反复用到。我的建议是别系统刷数学书用遇到什么问题补什么知识的方式效率高得多。真要说必看的3Blue1Brown的线性代数本质和微积分本质系列加上一本《统计学习基础》的前几章足够了。2.2 Python工程能力环境、依赖、调试、性能AI工程以Python为主但此处的关键不是会写Python而是会把Python当工程语言用。这两者的差距我举个例子你就明白了。新手写数据处理脚本通常是平铺直叙读文件、循环、处理、存下来跑一遍就完事。而工程化的写法是考虑数据量大了怎么办是不是要换polars或pandas、代码能不能模块化复用、异常情况怎么处理某个字段缺失了会不会崩、运行时间太长怎么优化是不是可以用向量化代替循环、要不要加logging记录进度。这些习惯一开始不养成等到写推理服务、批处理任务时会被反复坑。具体来说我建议从零开始的人先搞定这几件事用pyenv或conda管理Python版本用venv或poetry管理项目依赖彻底告别在我电脑上能跑的窘境。熟读Python的装饰器、生成器、上下文管理器这三个特性在写缓存、流式处理、资源管理时是杀手锏。会看堆栈信息会用pdb或debugpy断点调试。AI代码里最常见的报错都是shape不匹配、类型不对、None没判断会看堆栈能省下80%的排查时间。性能方面不用一上来就学CUDA优化但至少要知道Python写循环很慢能向量化就向量化数据量大时先考虑分块和采样而不是直接上分布式。我见过太多人数据只有几万条就开始搭Spark纯粹是给自己找麻烦。2.3 数据处理是真正的隐形门槛很多人学AI把注意力全放在模型上结果卡死在数据上。我可以负责任地说AI工程里超过一半的时间在跟数据打交道采集、清洗、标注、格式转换、质量校验、版本管理。从零开始建议练几个硬功夫。第一结构化数据处理SQL必须熟练——不是会select就行而是窗口函数、子查询、join的语义要清楚因为数据探查阶段你80%的时间都在写SQL。第二非结构化数据的处理流程要会——PDF怎么解析、表格怎么抽取、长文本怎么切片。很多人天真地以为把PDF直接喂给大模型就行实际上PDF的文本抽取本身就是一个大坑表格会乱、多栏会乱、扫描件得走OCR。第三要有数据版本管理的意识。模型训练用的数据集改了哪版、谁改的、效果为什么变了这些都要能追溯。我建议从第一个项目开始就用简单的目录加hash命名的方式管理数据集别等出了事故再补课。3. 技术栈选型从零搭建AI工程的核心工具箱3.1 框架选择的底层逻辑别当框架搬运工现在市面上的AI框架多到让人选择困难PyTorch、TensorFlow、JAX、LangChain、LlamaIndex、Haystack……我的建议非常直接深度学习框架只用PyTorch应用层框架能不用就不用实在要用从LangChain和LlamaIndex里二选一深入学。为什么这么选PyTorch在学术界和工业界的统治地位已经确立新模型基本都先出PyTorch版本遇到问题查资料最容易招聘市场也最认。TensorFlow现在主要活在存量系统里新项目选它没有性价比。JAX有它的优势但不是给入门者用的。至于LangChain这类编排框架我承认它上手快但它的抽象层太重版本变动又频繁很多人在上面花了大量时间学框架写法而不是学AI本身的逻辑。我的经验是先用原生Python把RAG、Agent这类应用的骨干逻辑自己写一遍再用框架你会突然发现框架文档变得非常好读——因为你已经知道它帮你封装了什么。3.2 模型选型从API到开源微调的分层策略从零开始做AI应用很多人纠结第一个问题到底用现成大模型API还是自己部署开源模型我见过最离谱的操作是项目还在验证阶段就直接买了两张A100开始微调7B模型结果数据不够、算力空转、效果还不如API。一个务实的选型梯度应该是这样的场景推荐方案成本量级适合阶段快速验证产品idea商用APIGPT/Claude/国内大模型API按token计费原型验证期数据敏感、需要私有化开源小模型Qwen、Llama、Mistral系列本地部署GPU服务器成本有真实需求后垂直领域效果优化开源底座 LoRA微调训练成本中等数据积累到一定量超大规模高并发开源模型 蒸馏 量化 深度优化极高业务稳定期核心原则是先验证效果后优化成本先租GPU后买GPU先微调小模型后考虑大模型。我自己做项目时的决策顺序是——先用最好的API把流程完整跑通确认产品逻辑成立、用户愿意用再开始评估自部署的成本收益。3.3 向量数据库与缓存体系的选择RAG现在几乎是AI应用的基础设施向量数据库选型就成了绕不开的问题。市面上的选择很多专门的Milvus、Qdrant、Weaviate、Pinecone以及传统数据库PostgreSQL配pgvector插件。我的建议很直接不要让向量数据库选型成为你第一个项目的决策负担。数据和量级没上来之前pgvector完全够用少一个中间件就少一个故障点。等到向量数据上了千万级、查询延迟和召回精度开始吃紧再考虑迁移到Milvus或Qdrant也不迟。很多教程一上来就教你搭一套复杂的向量数据库集群对入门项目来说纯粹是过度设计。除此之外缓存体系一定要从一开始就设计进去。LLM调用有延迟、有成本同样的提问不该每次都打到模型上。在服务层加一层基于语义相似度或精确key的缓存能省下30%以上的成本响应速度还能从秒级降到毫秒级。这是AI工程里性价比最高的优化没有之一。3.4 MLOps不是锦上添花是工程化底线很多从零开始的人对MLOps有误解觉得那是大厂才需要的东西。我吃过亏强烈建议你们从一开始就建立最基本的MLOps纪律哪怕只是项目目录规范这种最朴素的层面。最基本的MLOps能力包括四块实验追踪每次跑的模型、数据、参数、指标都能回溯、模型管理模型文件有版本、有标签、能一键回滚、流水线编排从数据到训练到部署的流程自动化、监控告警线上模型的延迟、错误率、漂移能看见。入门阶段不用上Kubeflow这种重型武器用MLflow管理实验和模型用Git管理代码用Docker固定运行环境用Airflow或Prefect做简单的定时任务调度足够了。我记得自己第一个正式项目就栽在实验追踪上跑了四十多版模型文件名全是final_v2_really_final这种结果完全分不清哪个版本对应哪组参数、哪份训练数据最后只能全部重跑。从那以后我养成一个铁律任何一次实验必须记录模型版本、数据集版本、关键参数、评测结果四件套缺一不可。4. 实操主线动手搭建一个端到端RAG问答系统4.1 为什么第一个项目选RAG而不是微调如果只能选一个项目作为从零开始的练手目标我强烈推荐做RAG检索增强生成问答系统而不是微调模型。理由很简单RAG覆盖了AI工程全链路的几乎所有环节——数据采集与预处理、文本切片、向量化、检索召回、大模型调用、上下文组装、回答生成、效果评测。而且它不依赖大规模算力用商用API就能跑通非常适合入门。微调模型当然也是重要的工程能力但它对数据要求高、算力门槛高、调试链条长不适合作为第一个项目。我见过太多人第一个项目就是微调大模型结果在数据清洗和训练调参上耗了两三个月连最基本的服务化部署都没碰过能力结构完全是瘸腿的。先做RAG把工程链路跑通再回头做微调你会发现很多工程上的坑你已经提前踩过了。4.2 数据准备与切片直接决定效果上限的环节RAG项目成功与否50%取决于检索质量而检索质量一半以上取决于数据准备和切片策略。很多人上来就直接切数据切完发现检索结果乱七八糟其实是切片这件事没想清楚。我常用的切片策略是结构感知切片。以文档问答为例先解析文档结构标题层级、段落、表格然后按语义单元切片章节标题作为一个单元的起点每个切片的长度控制在300-500个token左右相邻切片之间保留一小段重叠比如50个token防止关键信息正好被截断。这里有个经验数值切片太小100 token语义会碎片化切片太大1000 token检索命中后塞进上下文的噪声太多还浪费token成本。300-500这个区间是我反复测试后觉得性价比最高的。切片之后别忘了做清洗与增强。我实测下来最影响RAG效果的两个脏数据问题是无效内容页眉页脚、版权声明、导航栏文字混入正文以及同义表述不统一比如AI和人工智能同时出现。前者需要规则或手写parser清理后者可以做词表归一化。这一步枯燥但它的收益直接反映在召回率上。4.3 检索召回嵌入模型选择与混合检索向量检索是RAG的核心。嵌入模型embedding model的选择直接影响召回效果我的选型建议是中文场景优先考虑开源的bge系列或m3e系列英文场景OpenAI的text-embedding-3-small或开源的e5系列都行。关键指标是MTEB榜单得分但更实用的是拿你自己的领域数据做召回测试——榜单分数高不代表在你的文档里好用。嵌入模型选定后有一个细节很多人会忽略检索前一定要做归一化处理。我之前就踩过这个坑没有对向量做L2归一化导致余弦相似度计算结果异常召回了一批完全不相关的内容排查了很久才发现是这个问题。另外强烈建议做混合检索——向量检索加BM25关键词检索的融合。纯向量检索有一个常见问题罕见专有名词比如某个系统的专属代码AB-3342在语义上难匹配BM25恰好擅长精确关键词匹配。两者用简单的加权融合即可我一般权重设置成向量检索0.7、BM25 0.3具体比例可以根据你的数据特点调参。这一步加完之后检索质量的提升是肉眼可见的。4.4 上下文组装与生成策略细节决定体验检索到相关片段之后组装上下文这件事也大有讲究。两个容易忽略的点一个是相关性过滤不是所有召回的片段都该塞进去——设定一个相似度阈值低于阈值的宁可不用防止垃圾进垃圾出另一个是去重与排序同一文档里高度重叠的切片要合并去重按照和问题的相关性从高到低排序让最相关的内容靠近Prompt开头和结尾LLM对这两处的注意力最强。Prompt本身也要精心设计。我推荐的结构是系统指令设定角色和回答约束 检索到的上下文用明确的标记分隔 用户问题 输出要求比如要求如果上下文中没有相关信息请直接说明不知道不要编造。最后一句不要编造不是可有可无的装饰它能把幻觉率明显压低。实际生成时还有两个工程层技巧。第一开启流式输出用户的等待体验会大幅改善首字延迟能从2秒降到300毫秒级别。第二设置合理的超时和重试策略LLM服务偶发超时是家常便饭通常重试两次加上指数退避就够。4.5 评估闭环没有评测等于盲人摸象RAG系统做完不评测等于没做。我建议至少搭两层评测检索质量评测和生成质量评测。检索质量评测很简单——构造一组问答对标注每个问题对应的正确答案来源文档然后计算召回率RecallK和命中位置。生成质量评测就麻烦一些传统做法是请人逐条打分费时费力但最可靠自动化的做法是用一个更强的LLM当裁判从相关性、忠实度、完整性三个维度打分虽然偶尔误判但胜在成本低、可批量跑。这里分享一个重要教训评测集一定要包含边界case。比如文档里没有答案的问题、模棱两可的问题、需要跨多个切片才能回答的问题。只测常规问题会让你盲目自信一上真实场景就翻车。我建议从第一天起就建一个几十条的评测集每次改动后都在这个评测集上跑一遍用数字说话而不是靠感觉。5. 上线后的实战问题那些教程不会写的事5.1 系统稳定性永远假设你依赖的东西会挂AI应用上线后你立刻会意识到自己身处一个依赖链地狱模型服务可能超时、向量数据库可能连接池满、上游API可能限流、缓存可能穿透。一个核心原则是任何外部依赖都必须做降级方案。我常用的降级体系分三层。第一层模型调用失败——降级到缓存回答缓存也没有就返回一个预设的兜底话术绝不把错误裸奔给用户。第二层检索失败——降级为无检索纯生成模式虽然效果差一点但至少能用。第三层全链路失败——记录日志、告警、止损。这套体系听起来简单但我在真实项目里无数次靠它救场。有一次凌晨模型服务商宣布限流我们的服务因为降级设计用户几乎没有感知到异常。5.2 成本治理LLM应用烧钱的三座大山如果说稳定性是第一节课成本治理就是第二节课。LLM应用烧钱的地方集中在这三处token调用量、embedding调用量、GPU资源闲置。我建议从代码里把token计数打点埋好按用户、按功能、按时段统计每周看一次报表。你会惊讶地发现某些功能只被用到5%的用户身上却消耗了40%的token成本——这时候就该考虑砍掉或降级。另外一个省成本的黑科技是语义缓存。我给Spring Boot项目做过一个语义缓存中间层用户提问先转成embedding跟缓存里的历史问题算相似度超过0.95就直接返回历史答案。实测缓存命中率能到20%-30%意味着整体成本下降了同样比例而实现成本只是一个Redis加一个相似度查询。这大概是我做过性价比最高的优化。5.3 效果持续变差模型漂移与反馈闭环上线一段时间后你可能会发现一个诡异现象模型效果在悄悄变差。这不是模型变笨了而是业务数据在变化——新用户带来的提问分布和当初的评测集越来越不一样。这在AI工程里叫数据漂移。应对手段有两层。第一层是监控对线上输入做分布统计定期跟训练集的分布做对比漂移超阈值就触发告警。第二层是反馈闭环把用户的负面反馈点不喜欢、追问、你答错了自动收集下来定期筛选出badcase补充进评测集和训练集形成发现-修复-回归的循环。很多团队做AI应用总觉得越做越虚就是因为这个闭环没建起来所有优化全凭感觉。6. 一份可以照抄的从零动手计划6.1 三个月主线从环境搭建到完整项目落地最后给一份我自己验证过的、适合大多数人的三个月路线图。前提是你有基本的Python基础如果连Python语法都生疏建议先花一两周补齐。第一个月主攻基础与数据。完成三件事补Python工程化习惯虚拟环境、调试、代码结构搞懂向量化基础用numpy手写余弦相似度和k近邻检索别用现成库做一次完整的数据处理练习拿一份真实的PDF或网页数据走一遍解析、清洗、切片、入库全流程。第二个月主攻模型调用与RAG。完成一个最小RAG系统用文档问答为目标选一个embedding模型、接一个LLM API、写检索逻辑、组装上下文、实现流式输出。不求规模大但要求端到端链路是通的。第三个月主攻评测与部署。搭评测集、跑评测指标用FastAPI把RAG服务封装成HTTP接口用Docker打包部署到一台云服务器上跑稳。到这里你已经完整走完了一个AI工程项目的生命周期。6.2 两个关键的自我判断节点三个阶段中有两个节点我建议你主动停下来检查一下。第一个节点是在RAG最小系统跑通时回答一个问题当检索结果不对时你能在半小时内定位到是切片问题、嵌入问题还是权重问题吗如果答案是不确定说明你对链路各个组件的理解还是浆糊状的需要回头把细节吃透。第二个节点是在服务部署完成后回答另一个问题如果明天模型API全部涨价三倍你的系统架构里有哪些地方可以调整来降低成本如果答不上来说明成本意识还没建立建议把第5.2节的内容再做一遍。这两个节点不是为了考试而是用来确认你是真的在从零学会工程还是只是在照着教程把代码跑通。前者才是你将来能独立做项目、甚至带别人的本钱。做AI工程这件事我自己最大的体会是别人给的路线图再漂亮也得靠一个个具体的报错、一次次深夜的排查堆出来。没有哪一步是可以跳过的——跳过数据处理后面会在检索质量上还债跳过评测会在上线后被用户骂回来跳过成本规划会在月底收到账单时傻眼。从零开始这条路每一步坑都得自己踩一遍但只要你踩完还能复盘出原因这个从零就是值得的。最后送你一句我个人反复验证过的口诀先把整条链路跑通再谈优化先把最小闭环做出来再想着做复杂。这个顺序反了大概率会陷入学了很久、什么都没做出来的循环。