1. 从零开始学AI工程这个仓库到底解决了什么问题前阵子有个朋友跑来问我说想转行做AI相关的工作但不知道从哪里入手。他给我看了各种收藏夹里的资源——有讲Python的、有讲机器学习的、有讲深度学习的、有讲大模型的加起来几十个G的教程但越看越迷茫。这大概是很多想入行AI的人的真实状态不是缺资料而是缺一条清晰的、能循序渐进走通全流程的路径。“ai-engineering-from-scratch”这个项目定位就是解决这个问题。它不要求你已经有深厚的机器学习背景也不需要你先啃完《统计学习方法》再动手而是从工程实践的角度把一名AI工程师从零开始需要掌握的核心技能拆解成一条可执行的路线。所谓“from scratch”在这里有两层意思一是面向零基础或弱基础的开发者二是强调所有东西都自己动手搭不用那些“开箱即用”的黑盒方案理解每一层的原理。我当时拿到这个标题的第一反应是它不是一个“教程合集”而是一个“工程能力地图”。它的核心价值不是教你怎么调用某个API——那太浅了——而是让你理解一个AI应用从数据到上线中间每一环是怎么串起来的。如果你正在准备转岗AI工程师、或者刚入职但发现自己只会调包、对底层一知半解这篇文章值得你看完。我会把这套体系拆开揉碎讲讲每条路线背后是怎么设计的你在实操中会踩哪些坑以及我是怎么用这套思路完成一个从零搭建的AI应用的。2. 做AI工程和搞AI算法是两码事很多人对“AI工程师”这个岗位有误解以为就是调模型、调参数、写Transformer。实际上一个AI工程师的核心战场不是算法创新而是把算法变成稳定、可用、可维护的工程系统。你写的代码可能不复杂但你要处理的问题非常复杂数据怎么来、模型怎么训、服务怎么部署、延迟怎么控制在200毫秒以内、并发上来之后怎么扩容、模型效果变差了怎么监控和迭代。我把“ai-engineering-from-scratch”的路线拆解成了五个核心模块覆盖了一整套从零到一的工程闭环。2.1 基础工具链不要一上来就啃深度学习理论这个模块是劝退人最多的阶段也是我见过最多人走错路的阶段。很多人一上来就买《深度学习》花书啃了三章就放弃了然后得出“我不适合AI”的结论。其实对于AI工程方向来说理论是需要的但不是前置条件应该边做边补。工具链部分最核心的是Python。不夸张地说Python是AI领域的“通用语言”几乎所有主流框架——PyTorch、TensorFlow、Transformers、LangChain——都优先支持Python。你需要掌握的程度不是“会用”而是“熟练”装包、管理虚拟环境、处理文件和JSON、写类和组织代码。VSCode加Jupyter Notebook是起步标配但我建议尽早把你的代码“搬”到.py文件里组织起来而不是永远在Notebook里写流水账脚本。Notebook适合做探索和展示不适合做工程。数据处理的底子是Pandas和NumPy。这两个库的重要性不亚于模型本身。真实项目里80%的时间都在和数据打交道而不是在训模型。你得习惯用Pandas做数据清洗、分组统计、透视表用NumPy做张量运算。至于SQL也别跳过。很多AI应用的数据源头是业务数据库写一手好SQL能让你在数据获取环节省掉大量沟通成本。我在这一点上有惨痛教训早期我以为SQL是数据分析师的事自己只负责算法部分结果每次要个数据都得求人、等排期后来自己把SQL补起来效率翻了三倍不止。这个阶段还有一件容易被忽略的事学会命令行。不是让你变成Linux运维专家但至少要知道cd、ls、mkdir会用pip install会用git clone能看懂报错栈。AI工程绕不开服务器而服务器基本都是Linux早点适应这个环境后面会顺畅很多。2.2 模型原理的“够用就好”策略到了模型部分很多人的问题是“贪多嚼不烂”。今天看看CNN明天摸摸RNN后天又刷到某篇讲Diffusion的文章结果哪个都不精通。我自己走过的弯路是试图把所有模型原理都吃透结果陷入数学细节里出不来好几个星期没有任何产出。后来我总结出了一个“够用就好”的策略。对于AI工程这个方向你首先要吃透的是神经网络的基础运作机制前向传播、反向传播、损失函数、优化器。不需要你会手推公式但要知道梯度下降在干什么学习率大了会怎样、小了会怎样过拟合和欠拟合是怎么回事。这些概念理解到位之后再往上叠具体模型就有章可循了。Transformer是绕不过去的核心因为你之后接触的大模型基本都是基于这个架构。但也不用看那种几百页的论文精读抓住几个关键点就行注意力机制为什么能解决长距离依赖位置编码是干嘛的自回归生成是怎么一个token一个token蹦出来的。理解了这些你在用HuggingFace加载模型、调推理参数的时候就比别人多了一层判断力。至于具体的模型结构我建议“用到什么学什么”做图像就学ResNet和ViT做文本就学BERT和GPT系列做语音就学Whisper那套结构。不要指望把所有模型都学一遍那是算法研究员的工作不是工程师的打法。工程的核心交付物是“模型能跑起来、结果够稳定、延迟和成本可控”而不是“我在某个benchmark上刷高了0.3个点”。2.3 关键技术实操Prompt工程、RAG与Agent从2024年开始AI工程的重心已经从“训练模型”转移到了“模型应用”。大多数人不需要从零预训练一个模型——成本太高了——而是站在开源或闭源大模型的基础上做应用层开发。在这个背景下有三项技术成为了AI工程师的看家本领。Prompt工程是最基础的一项。别以为写提示词就是“说人话”实际上里面有大量可调优的空间。系统提示词怎么设计、示例怎么给、温度参数怎么调都会直接影响输出质量。一个合格的AI工程师至少要掌握上下文注入把背景信息塞进提示词里、小样本提示给几个输入输出对让模型模仿格式、思维链让模型一步一步推理减少幻觉。这些技巧看起来简单但用得好不好差距非常大。RAG检索增强生成是让模型“知道你私有的知识”的关键方案。它的思路不复杂先在用户提问时从他的知识库里检索出相关片段把这些片段作为上下文塞给模型让模型基于这些材料生成回答。这里面真正的难点在于检索质量——你怎么把用户的模糊问题匹配到最相关的资料切片。这不只是一个工程问题还牵扯到你对文本语义的理解、对向量检索的调优、对切片策略的打磨。我在这块儿踩过的坑是最多的后面我会专门讲。Agent是2025年最火的方向核心是让模型不止于“回答问题”而是能“干活”理解目标、拆解任务、调用工具、观察结果、迭代修正。一个实用的Agent至少包含三个要素模型负责推理决策、工具比如搜索引擎、代码执行器、API调用、编排逻辑决定模型在什么时候调用哪个工具、要不要重试。这里面最容易翻车的地方是循环控制——模型可能在一个错误的工具调用结果上反复打转白白消耗大量token和时间。工程上必须设定最大循环次数、增加熔断机制、对工具输出做校验这些都是我在实战里被坑过之后才补上的。2.4 大模型应用开发框架LangChain、LlamaIndex等现在做AI应用开发基本离不开框架。LangChain是生态最完整的提供了Prompt管理、模型调用封装、Chain将多个处理步骤串联起来、以及大量与外部工具的集成模块。LlamaIndex则更侧重数据索引和检索尤其适合搭建知识库问答类应用。两者有功能重叠但侧重点不同——如果你做的应用以数据处理和知识库为核心LlamaIndex可能更顺手如果涉及复杂任务编排和工具调用LangChain会更合适。但这里我必须提醒一句框架虽好不要依赖成瘾。LangChain的设计理念是“抽象和封装”让你用几行代码就能串联复杂的AI流程。但代价是出了问题你很难debug——因为中间层太厚了你不知道是哪一步在什么地方出了错。我后来养成了一个习惯关键路径上的逻辑先用原生代码写稳定了再决定要不要换成框架的封装。框架的价值在于“快速验证想法”和“调用生态”而不在于“替你做架构决策”。2.5 模型微调技术什么时候不该微调微调是很多AI工程师朋友最想学的技术但也是最容易被滥用的技术。我的建议是能用Prompt工程解决的事不要微调能用RAG解决的事不要微调。微调的成本——无论是数据准备、训练资源还是后续的模型维护——都比前两者高一个数量级。什么时候才需要微调有几种典型场景。一是模型的输出格式必须要严格遵守比如必须以JSON输出且字段结构完全符合你的规范用Prompt调教很多次都不稳定微调可以强制锁定格式。二是模型需要掌握某种“特定风格”比如产品的口吻、特定领域的术语和表达习惯这时候微调能把风格“刻”进模型里。三是模型需要具备某种能力而基础模型在这个能力上表现很差比如你的业务数据高度垂直模型不熟悉这些数据模式微调能显著提升泛化表现。微调技术栈方面路径已经非常成熟了。LoRA低秩适配在2025年已经是全行业默认首选它只训练一小部分附加参数训练成本相比全参数微调低了一个量级效果却几乎不打折。QLoRA进一步把微调门槛拉低到消费级显卡——一张24GB的4090就能微调7B甚至13B模型。PEFTParameter-Efficient Fine-Tuning这个库把这些方法统一封装了几行代码就能上手。我建议从LoRA开始学足够覆盖绝大多数业务需求。在实操层面微调工作流的关键节点包括数据准备与格式化高质量、多样性、格式正确是成功的前提低质量数据会直接污染模型、基础模型选择可以优先考虑衡量通用能力的基准分数和社区口碑——前者关注整体能力后者关注中文支持等实际反馈、训练参数初始化学习率一般是2e-4量级LoRA rank取8到32之间需要结合你的数据规模来试、评估对比微调前后效果差异不是看loss降了多少而是要看在真实业务测试集上的表现——准确率、召回率、格式正确率等维度都要覆盖。3. 构建RAG知识库问答系统一次完整的AI工程实战光讲框架和路线不落到实处永远都是纸上谈兵。这一节我拿一个具体的项目——搭建一个基于RAG的内部知识库问答机器人——来完整走一遍从零到一的AI工程流程。这个项目我实操过选它的原因是它几乎涵盖了AI工程师日常工作的所有核心环节而且难度适中适合作为第一个完整的AI实战项目。3.1 环境准备与工具链搭建项目开始之前先把环境理清楚。我强烈建议用conda建独立的Python环境不要一股脑把依赖装进全局环境里不然项目之间互相打架会让你痛不欲生。我用的配置供参考Python 3.11、PyTorch 2.2记得在安装时选择对应CUDA版本的命令不是默认安装不带GPU支持vector库我用的是Faiss——它对中小规模知识库足够快了早年我曾在老版本里遇到兼容问题后来升级到新版配合正确索引配置就稳定了。embedding模型可以选择开源方案如bge-large-zh或者那些按调用量计费的商业接口根据你的预算是多少来权衡。LLM这边当时我用的是开源模型加本地部署的方案省成本、数据不出内网但你需要评估自己有没有对应的部署和运维能力。环境搭建的顺序有个讲究先把Python环境和PyTorch装好再装其他库。因为很多库的编译和安装都依赖PyTorch环境顺序反了会遇到各种灵异问题。装完之后跑一段几行代码的脚本验证GPU和CUDA是否正常确认无误了再往后走。3.2 从数据清洗到向量化入库第一个核心步骤是处理数据。当时我拿到的原始材料是一堆Word和PDF文档加起来有两三百页。问题是格式五花八门有的带目录、有的带页眉页脚、有的表格混着正文。如果直接拿去做切片和向量化检索质量会很差——因为向量化的时候页眉页脚、目录这些噪音都会被算进句子的语义里干扰后续匹配。所以数据清洗这一步表面上看脏活累活实际上直接决定了整个系统的检索上限。我的做法是先把所有文档转换成纯文本去掉页眉页脚和目录信息然后对正文做段落级别的切分切片chunk一个切片控制在300到500字左右切片之间保留一定重叠度。这里为什么要做重叠因为一个完整语义很可能会被切分边界截断——比如一个问题的答案恰好横跨两个切片没有重叠的话检索命中的概率就大大降低。构建向量化流水线之前先做了一件事用embedding模型跑一个小批量样例人工看一眼切片的向量在语义空间里的分布。这一步是很多人会跳过的但它非常有用——这相当于在正式加工前先做了质检能帮你早期发现数据问题。流水线整体长这样读取文档 → 文本清洗 → 切片 → 空值过滤和格式检查 → 喂给embedding模型 → 存入向量库。入库完成后我做了个简单的召回测试问几个业务相关的问题看检索出来的前5个片段是不是真的和相关。结果发现有些问题检索出来的内容很偏——原因是对专有名词的切分有问题比如“用户画像”被切成“用户”和“画像”导致召回结果偏离。把切片策略调整了一下在词典里加了专有名词列表让分词器不再拆解这些词之后效果才正常。我用这套流程建了一个索引处理几万条数据只花了十几分钟。embedding速度不是瓶颈清洗和切片策略才是关键。3.3 在LangChain里集成检索和问答链路数据入库之后下一步是把整个RAG链路串起来。LangChain在这个阶段非常适合它能把加载文档、切割、embedding、检索、调LLM这几步都用标准化组件接上花很少的代码就能让你的机器人“开口说话”。用LangChain搭RAG链路的核心代码逻辑非常简洁——本质上就是三步先构建向量索引并包装成检索器返回器然后定义提示词模板把系统指令、候选上下文片段、用户问题拼在一起最后初始化大模型调用并用检索增强生成链把检索器和模型串起来。顺序上千万别搞反先确认向量库里有数据、检索器能正常返回结果再上LangChain的链式封装。否则出了问题你根本分不清是检索模块挂了还是模型调用挂了。我当时用的模板是这样设计的系统提示部分明确告诉模型“你是一个客服助手只能根据提供的上下文片段回答不要编造上下文里没有的内容。如果上下文与问题无关直接回答‘我不清楚’。”这个设计不是随口写的它有明确的目的——用约束性指令降低幻觉率。实测下来加了这个提示之后模型胡编乱造的比例确实明显下降。链路搭好之后我做了完整的内测整理了一批典型问题逐个跑一遍人工判断回复质量。这一步能暴露出大量链路层面的问题比如检索到了有用的片段但模型没用好、上下文塞得太多导致无关信息干扰模型、等等。发现问题之后通常需要回到模板或切片侧去调而不是在调用侧硬调参数。3.4 服务化部署从脚本到可用的API脚本能跑起来只说明你的RAG链路逻辑通了。要真正交付给业务方用还得把它封装成一个稳定的服务。我当时选择了FastAPI来搭服务端——它在Python社区里已经是事实标准了性能足够、文档清晰、写起来也快。服务端要提供的能力有两个核心接口一个是“上传知识文档”接收文件并触发清洗、切片、向量化合入库的流程另一个是“提问”接收用户问题走完检索和生成链路返回答案和参考片段。后端的接口返回设计上我有两条经验可以分享。第一返回结果里一定要带上“检索到的参考片段”。这样不仅方便排查问题在实际业务场景里还可以用来做引用溯源——用户看到答案时可以确认信息是不是真的来源于知识库这能大幅降低对AI回复的不信任感。第二接口要做超时和降级设计。LLM推理耗时长如果用户请求量上来排队等着会直接把服务拖垮。我当时设了一个缓冲队列超出等待上限的请求直接返回“系统繁忙请稍后重试”避免请求堆积导致服务雪崩。部署这块我的建议是先用Docker把服务容器化这样就能保证“在我机器上能跑在你机器上也能跑”避免环境差异导致的各种坑。我当时的做法是写一个Dockerfile把Python环境、依赖库、模型文件路径都固化进去。如果你们的服务器已经有了成熟的容器编排平台直接用也没问题——Kubernetes的好处是它可以更方便地管理多副本扩容和负载均衡让你的RAG服务在面对真实并发时更有底气。4. 实战排雷手册10个AI工程常见问题与排查实录做AI工程最大的特点就是问题千奇百怪答案各不相同。下面这些坑都是我反复踩过之后记下来的按频率排序。有些问题你可能现在遇不到但只要你继续做这行早晚会碰上。4.1 环境依赖冲突这是所有Python项目的噩梦AI项目尤为严重。PyTorch要特定版本的numpyTransformers要另一个版本LangChain又要跟它兼容……我见过最夸张的一次是同一个环境里有三套互相冲突的依赖每次运行都会报“numpy版本不兼容”之类的错误。后来我彻底养成了“新项目必建新环境”的习惯用conda创建独立环境依赖在项目文档里写清楚版本号。这里的教训是版本信息写在requirements.txt里的时候尽量带上具体版本号而不是写“numpy”这种裸包名。否则半年后你自己回来看都装不回原来的版本。4.2 向量检索召回质量差这个是RAG项目里出现概率最高的问题症状很典型你问“公司年假政策”检索出来的却是“请假流程”。根因一般是这几个切片策略不合适句子语义被截断在整段文本的边界之外、embedding模型对业务领域专有词汇的理解不够、索引参数没有针对性调优。排查时从前往后走先用几个典型问题直接把检索结果打印出来看判断问题在召回还是生成。如果召回结果本身不相关优先调切片和embedding如果召回相关但答案不对去调Prompt模板。关于embedding效果我建议用针对性的评测方式而不是只看跑分指标。比如构建100条带标准答案的测试问题跑一遍RAG链路统计“检索命中率”和“最终答案正确率”。把提升检索质量的调整动作一次只改一个变量记录每个变量的影响才能积累出可靠的调试经验。4.3 提示词调优不生效一个让人很郁闷的现象是改了Prompt结果完全没有变化。这种情况第一步检查模型参数是不是被固定了比如温度、top_p、max_tokens这些——如果调试时这些参数是固定不变的改Prompt的效果可能不明显。第二步检查是不是缓存导致的结果没刷新——有些框架会缓存历史回复比较新旧输出时容易看错。还一种可能是你的Prompt改动确实不痛不痒——只是改了几个形容词没从根本上改变模型的行为路径。调Prompt要有结构化思维一次只动一个变量每次改动之后用同一个测试集跑一遍比对前后输出差异。我见过太多人调Prompt靠“感觉”东改一句西改一句最后根本不知道是哪个改动生效的这是最浪费时间的做法。4.4 模型“幻觉”问题大模型生成的内容和知识库内容不一致或者干脆自己编造信息这是用户投诉最多的问题。工程上能做的主要有三层防线第一层在Prompt里明确规定“只能基于上下文回答不要补充外部信息”同时把上下文截取做得更精准第二层引入“保底回答”机制——如果检索到的上下文与问题的相似度低于阈值直接拒绝回答而不是让模型硬着头皮编第三层在返回结果中附带参考片段让用户有信息溯源的能力。这三层叠加之后我的实测体验是幻觉比例能下降一大半剩下的属于模型本身的固有局限暂时没有银弹解法。4.5 推理延迟过高用户点一次提问按钮要等10秒才出结果这个体验很难接受。延迟来自三个层面检索耗时、模型推理耗时、网络传输耗时。检索这块用向量索引加近似最近邻搜索数据量在百万级以下时耗时可以控制在百毫秒内基本不用优化。模型推理是主要瓶颈可选方案包括换更小但能力够用的模型、进行量化压缩比如8bit或4bit、用支持前缀缓存的技术方案提升并发吞吐或者考虑GPU部署。网络方面主要为本地服务做优化避免跨地域的RPC调用。4.6 并发场景下的资源不足当用户的QPS上来之后你会发现单机单个模型实例撑不住。常用方案有两个水平扩展部署多套模型服务用负载均衡分发请求垂直优化缩短单次请求的耗时让单实例能处理更多请求。GPU服务器在2025年仍然不便宜所以工程上要精打细算该上量化的上量化、该做缓存的做缓存。4.7 数据更新后的效果回退知识库里的内容更新了但问答效果反而变差了——这种情况通常是增量更新导致的。向量库在增量写入时如果没有对相关旧文档做处理就可能出现新旧内容并存、互相冲突的情况。解决方案是建立起“版本管理”意识文档更新时先把旧版本向量删除再写入新版本确保检索结果始终对应最新数据。4.8 评测维度单一失真只看一个指标比如准确率来判断系统质量通常会掩盖很多问题。一个完整的RAG评测应该至少覆盖四个维度准确率答案是否正确、完整性是否有遗漏关键信息、格式规范是否严格按要求的格式输出、可控性给定范围外是否不乱答。一个在准确率上很“好”的系统可能在完整性和可控性上一塌糊涂。所以评估方案从一开始就要设计好别等做完了再补。4.9 模型更新导致原有链路崩掉这是最隐性的坑之一。你换了一个新版本的模型或者升级了框架库结果之前的链路突然不工作了——但代码一行都没改。这类问题要建立“版本锁”机制核心依赖的版本在项目里锁死、接口调用有变更时留出兼容层、升级模型前先在小流量上试运行。4.10 从开发到交付的“最后一公里”很多AI项目死在“能跑demo”和“能上线”之间的鸿沟上。Demo阶段你可以在Notebook里手动跑通上线阶段你需要考虑认证授权、数据安全、日志监控、运维告警、文档说明。这些非算法的工程能力恰恰是区分一个“会做实验的人”和“能交付产品的工程师”的门槛。我建议在做第一个AI项目的时候就有意识地走完这条最后一公里——哪怕只是搭一个最简化的运维看板也比永远停留在Notebook阶段有价值得多。5. 我在实际项目中的体会和建议把“ai-engineering-from-scratch”这个路线走完一遍我自己最大的感受是AI工程的核心不是“会用某个东西”而是“知道为什么用”——为什么选这个模型、为什么用这个切片长度、为什么调这个温度参数。那些只停留在调用层面的“AI工程师”在工具迭代加速的2025年被淘汰的速度比工具本身还快。反而是那些把底层逻辑吃透、能独立解决未知问题的人越走越宽。如果你现在正打算从零开始走这条路我给三条实实在在的建议。第一别追求完美先跑通最小闭环哪怕只是用一个现成的开源模型搭一个最简单的问答机器人跑通了再迭代这个起步价值远大于再啃三章理论。第二每一层都要“开箱验货”数据从清洗到入库模型从加载到推理链路从检索到生成每一层都单独验证过再往上层叠千万别赌一把直接连上否则问题定位会让你崩溃。第三养成记录的习惯我在做每一个AI项目的时候都会写一份“实验记录”里面记下每次改动的目的、改动前后的效果对比、踩过的坑。这份记录对于项目的延续、交接和自我复盘都有巨大价值。从零到一的路不短但每一步都能看到反馈——这大概是AI工程最有吸引力的地方。路线就在那里工具也都齐了剩下的就是动手了。