1. 项目概述与定位分析1.1 这个仓库到底解决什么问题我第一次看到 ai-engineering-from-scratch 这个标题的时候第一反应是这又是一个 repo 收集狂魔的作品但点进去转了一圈之后我得说这哥们儿是真的想明白了才动手写的。这个仓库的核心定位非常聚焦它不是告诉你AI 很厉害快来学而是用一套从零开始、手写实现的方式把 AI 工程化这条链路完整串了一遍。从最基础的矩阵运算、反向传播到 Transformer 架构、RAG 流水线、模型微调、部署上线全部用代码实现出来不依赖那些黑盒封装好的框架。说白了一句话如果你想真正搞懂 AI 系统是怎么工作的而不是只会调 API、套框架那这个仓库就是为你准备的。我特别想强调一点这个仓库并不反对你用 PyTorch、用 HuggingFace、用 LangChain它反对的是只会用、不知道里面是什么的状态。它的做法是先用原生 Python 和 NumPy 把核心逻辑写一遍让你看到每个模块的输入输出、每一步计算在干什么然后再告诉你正规军是怎么做的。这种先造轮子、再开汽车的思路恰恰是大多数自学 AI 的人最缺的一环。1.2 适合谁来学、能学到什么根据我个人这几年带人做 AI 项目的经验下面这几类人最适合这个仓库刚入门但不想只当调包侠的开发者你可能会用model.fit()或者trainer.train()但一旦模型报错、效果不对你就完全懵了。这仓库能帮你建立真正的排查直觉。准备转行 AI 工程方向的后端/全栈工程师你有编程底子但对机器学习、深度学习只有模糊概念。这个仓库的代码风格很工程化你读起来不会有障碍。做算法但工程能力偏弱的同学你懂模型原理但不懂怎么把模型变成一个可服务的产品。仓库后半部分的部署与工程化内容会补齐你的短板。想系统梳理 AI 知识体系的人这仓库的目录结构就是一个现成的AI 工程师能力地图你可以照着它逐项自查看自己哪里还薄弱。当然如果你已经是用 PyTorch 写 Transformer 跟吃饭一样自然的大神这个仓库对你来说可能偏基础。但你依然可以把它当一份教学提纲来用——带新人、做内部培训的时候直接照着这个结构讲效果比我见过的大部分 PPT 都好。1.3 仓库结构总览与学习路线建议这个仓库的目录结构非常清晰基本就是一条标准的 AI 工程学习主线。我把它整理出来方便你对照着看章节核心内容学习重点01 数学基础线性代数、微积分、概率论的核心概念矩阵运算、梯度、损失函数背后的数学直觉02 Python 基础NumPy 操作、数据处理、性能优化向量化编程思维避免 Python 循环03 机器学习核心线性回归、逻辑回归、决策树、SVM从零手写模型理解损失函数与梯度下降04 神经网络反向传播、多层感知机、激活函数手动实现反向传播这是重中之重05 深度学习进阶CNN、RNN、Embedding、注意力机制理解序列数据处理的演化脉络06 Transformer从零实现多头注意力、位置编码亲手写出 GPT 的底层结构07 大模型应用RAG、Prompt Engineering、Agent把模型能力落地到具体业务场景08 微调实战LoRA、全参微调、数据准备掌握高效微调的核心技巧09 部署与监控模型服务化、性能优化、监控告警理解生产环境的完整链路10 项目实战从需求到上线的完整案例综合运用前面所有知识我的建议是别跳着看。这个仓库的每个章节都是建立在前面章节的基础上的尤其是 04 到 06这三章是你必须啃下来的硬骨头。我自己带新人时定的规矩是前面每一章的代码都要自己重写一遍不看答案写完再对照。笨办法反而是最快的办法。2. 核心设计理念为什么从零实现这么重要2.1 黑盒思维的陷阱现在 AI 领域的工具链已经非常成熟了你几乎不需要自己写任何底层代码就能跑通一个模型。PyTorch 帮你处理了自动求导Transformers 库帮你封装了所有主流模型结构LangChain 帮你把 RAG 的流程都串好了。听起来很美好对吧但现实是我见过太多会用工具但不懂原理的人在真正的生产环境中寸步难行。举个例子你用 HuggingFace 加载了一个 BERT 模型做文本分类训练完发现准确率只有 60%你知道该调什么吗learning ratebatch size还是换模型结构如果你不知道 BERT 内部是怎么计算的你所有的调参都是瞎猜。这就像开车——你可以不知道发动机原理就开车上路但车一旦出了故障你就只能叫拖车。AI 系统比汽车复杂得多它的故障不会直接告诉你哪里坏了只会给你一个莫名其妙的 loss 曲线。这时候懂底层原理的人和只会调 API 的人差距是全方位的。这就是这个仓库第一个核心设计理念通过从零实现打破黑盒让你建立真正的系统级理解。它不是让你永远自己造轮子而是让你获得庖丁解牛的能力将来无论是调试、优化还是设计新方案你都知道每一行代码在做什么、每一个参数会影响什么。2.2 先手写、再抽象、后工具的三段式方法论这个仓库最让我欣赏的地方是它的章节组织暗含了一套学习方法论我把它概括成先手写、再抽象、后工具。第一阶段是手写。比如讲反向传播它不用 PyTorch 的autograd而是让你手动推导梯度公式然后用 NumPy 实现。这个过程非常痛苦但正是在这种痛苦中你才真正记住了链式法则是怎么在代码里落地的。第二阶段是抽象。当你能手写一个简单的两层神经网络之后它会教你识别模式原来不同的模型结构、不同的损失函数本质上是同一套框架里的不同组件。这时你自然就理解了为什么 PyTorch 要设计nn.Module这个抽象——它不是随便定的而是对所有深度学习模型共同结构的提炼。第三阶段是工具。有了前两个阶段的基础你再上手 PyTorch、Transformers 这些工业级工具时就是降维打击了。你不会再对着报错信息发呆因为你知道它底层在做什么你不会再盲目堆叠技巧因为你清楚每个组件的能力边界。这个方法论有坚实的认知科学依据。心理学家叫必要难度理论——你在学习时遇到的合理困难反而会加深你对知识的记忆和理解。手写代码就是一种必要难度它逼着你的大脑进行深层加工而不是浅层浏览。2.3 工程化思维贯穿始终还有一个很微妙但很重要的特点这个仓库叫 ai-engineering不是 ai-science 或者 ai-research。这个用词差异不是偶然的。机器学习研究和机器学习工程是两种完全不同的思维方式。研究追求的是模型效果能不能更好工程追求的是系统能不能稳定可靠地跑起来。这个仓库明显更偏向工程视角它讲模型但更讲数据怎么处理、代码怎么组织、性能怎么优化、模型怎么部署、上线之后怎么监控。举个例子仓库里讲模型部署的时候不是简单甩给你一个 Flask demo而是会讨论推理延迟怎么优化显存不够怎么办模型版本怎么管理线上流量波动怎么应对这些问题都是真实生产环境中每天都会遇到的但在绝大多数教程里根本找不到答案。我个人认为这是 AI 领域未来最重要的能力方向。现在能写模型的人越来越多但能把模型变成稳定产品的工程师依然稀缺。如果你能通过这个仓库建立工程化思维你的职业竞争力会比同龄人高出一个档次。3. 核心知识点拆解与实操要点3.1 数学基础与 Python 基本功很多想入行 AI 的人一看到数学就头大上来就问我是不是要先刷完一本线性代数才能学 AI这个仓库给出了一个更务实的答案用多少学多少在实战中建立数学直觉。以线性代数为例你不需要掌握所有定理的严格证明但必须理解几个核心概念的几何意义和代码实现向量与矩阵数据在 AI 里的基本存在形式。一张图片是一个三维数组一句话是一串 token 的索引这些到计算层都是矩阵。矩阵乘法神经网络前向传播的核心操作。一个(batch, input_dim)的输入乘上(input_dim, hidden_dim)的权重就得到了(batch, hidden_dim)的隐藏层输出。转置、逆、范数这几个概念在损失函数设计、正则化、梯度更新中反复出现。代码层面的基本功也一样。这个仓库用的核心库是 NumPy它的核心思维是向量化。举个例子你要计算一万个样本的均值用 Python 循环要写好几行而且跑得慢用np.mean(arr, axis0)一行搞定速度是前者的几十倍。我刚学的时候犯过这个错误用 Python 的 for 循环去遍历训练数据一个 epoch 要跑十分钟后来改成向量化操作十秒钟就完事了。这个差距在深度学习里是致命的。我建议你把这一章当成查漏补缺而不是从零学。真正需要你从零学的是后面神经网络和反向传播的部分——那才是这个仓库的精华所在。3.2 从线性回归到神经网络手写反向传播线性回归是理解模型训练的最佳切入点因为它足够简单一个线性函数、一个均方误差损失函数、一个梯度下降优化器。虽然现在没人用它做业务但它是理解所有更复杂模型的地基。当你把线性回归改成多层的神经网络核心难题就出现了梯度到底怎么算这时候你之前用 PyTorch 一行自动求导的经验反而会害了你因为你根本不知道这个梯度值意味着什么。这个仓库讲解反向传播的方式我非常推荐它从一个最简单的计算图开始一步步展示链式法则如何在网络中传递梯度。你亲手算一个三层网络的梯度就明白为什么激活函数要选择可导的、为什么会有梯度消失问题、为什么残差连接能缓解梯度消失。具体到实操层面一个值得反复练习的练习是用 NumPy 手写一个两层神经网络完成 XOR 分类任务。XOR 是经典的线性不可分问题单层感知机永远无法解决只有引入了隐藏层和非线性激活函数才能搞定。当你看着自己手写的网络经过几百轮迭代loss 从 0.7 慢慢降到 0.01预测准确率到 100%那种成就感真的无与伦比。这里有几个关键细节你必须注意权重初始化不能全零。如果全是零所有神经元的梯度相同模型永远不会分裂开。激活函数推荐先用 tanh 或 ReLU。sigmoid 在深层网络中会导致梯度消失新手会非常困惑。学习率的选择是门玄学。太大了 loss 会震荡甚至发散太小了收敛极慢。我一般从 0.01 开始不行就 0.001再不行就用学习率衰减。3.3 Transformer 的手写时刻Transformer 是整个仓库最值得期待的章节也是 AI 工程能力的分水岭。现在几乎所有主流大模型都是基于 Transformer 架构你如果不懂它的内部机制就没法理解 tokenization、context window、KV cache、分布式训练这些高级主题。这个仓库从零实现了一个完整的 Transformer block主要包含这几个部分Token Embedding Positional Encoding把离散的 token ID 变成连续的向量同时把位置信息注入进去。多头自注意力机制Multi-Head Self-Attention核心中的核心解决的问题是句子中的每个词应该关注其他哪些词。前馈神经网络FFN每个 token 单独过一个两层全连接网络增加模型的非线性表达能力。Layer Normalization 与残差连接让深层网络也能稳定训练的关键设计。因果注意力掩码Causal MaskGPT 系列模型生成文本时当前位置只能看左边的 token不能偷看未来。这里我想特别解释一下注意力机制因为它是所有大模型的心跳。你可以把它理解成一个信息检索过程每个 token 会发出一个查询query然后和所有 token 的键key做匹配得到注意力分数再根据这个分数去加权汇总值value信息。就像你在图书馆找书一样——你的需求是 query书的编号是 key书的内容是 value匹配度高的书会被你优先翻开。手写 Transformer 的时候最容易出错的地方是维度变换。注意力分数的计算是Q K^T要记得最后除以sqrt(d_k)做缩放否则数值容易过大导致 softmax 饱和。另外多头注意力的实现是把(batch, seq_len, hidden_dim)拆成(batch, num_heads, seq_len, head_dim)后分别在每个头上计算最后再拼回去。如果你能把这个维度的流转过程在纸上画清楚你就已经超过 70% 的调包选手了。3.4 大模型应用RAG 与 Agent有了模型基础之后仓库开始进入大模型工程化应用部分重点讲了两件事RAG 和 Agent。这是当前企业落地大模型最热门的两条技术路线。RAGRetrieval-Augmented Generation检索增强生成解决的痛点是大模型幻觉和知识时效性问题。大模型的参数里存的是训练截止日期前的知识而且它天生就会一本正经地胡说八道。RAG 的思路是不直接让模型回答而是先从外部知识库中检索相关文档然后把文档和用户问题一起喂给模型让它基于检索到的内容做回答。仓库在讲 RAG 时不是只给一个概念而是拆到了非常细的颗粒度文档加载与分块Chunking你把一篇文章切成多少字一块切太短信息不完整切太长检索不精准。仓库给了不同场景下的推荐范围我自己的经验是中文场景 400-800 字表现得最均衡。Embedding 模型选择怎么把文本变成向量以及距离度量方式是余弦相似度还是欧氏距离。向量数据库选型FAISS、Milvus、Qdrant 有什么区别各自的适用场景。Agent智能体则是另一个热点。传统聊天机器人是你问我答Agent 则是你给目标我拆解执行。比如你让它帮我订一家公司附近评分最高的川菜馆一个完整的 Agent 系统会拆解成搜索公司地址附近的川菜馆、按评分排序、筛选符合口味的、生成推荐报告。这个过程涉及规划Planning、工具调用Tool Use、**记忆管理Memory**等模块。这个仓库在 Agent 部分最大的价值是帮你理清Prompt 驱动执行和代码驱动执行的区别与取舍以及如何设计工具的接口让模型能正确理解并调用。这些内容市面上大部分课程要么讲得太浅要么过度包装能像它这样讲到这个颗粒度的不多。4. 实操过程手写一个简易 RAG 系统的完整记录4.1 环境准备与数据准备理论说再多不如动手跑一遍。我在本地按照这个仓库的思路用大约两个小时实现了一个简化版 RAG 系统。下面把完整过程记录下来你可以照着做一遍做完你会对整个链路有个非常感性的认识。首先说环境。我个人用的是 MacBook ProPyCharm 写代码Python 3.11。核心依赖其实就三个pip install numpy # 向量运算 pip install openai # 调用大模型接口 pip install sentence-transformers # 文本向量化数据方面我用了自己在项目里积累的几十篇关于AI 工程化实践的中文技术文章大概每篇 2000 字左右。这些文章作为知识库覆盖了模型训练、推理优化、部署运维等主题。如果没有自己的数据你也可以随便找一些技术博客或者直接用维基百科的某个词条下的内容。数据准备阶段最关键的步骤是清洗和分块。文档里可能有大量空格、换行、代码块标记你要先把这些噪音去掉再按语义边界切分。我的切分策略如下import re from typing import List def clean_and_chunk(text: str, chunk_size: int 600, overlap: int 100) - List[str]: # 去掉多余空白和换行 text re.sub(r\s, , text).strip() # 按长度切分前后保留 overlap 防止上下文断裂 chunks [] for i in range(0, len(text), chunk_size - overlap): chunk text[i:i chunk_size] if chunk: chunks.append(chunk) return chunks这里有两个参数值得你反复调chunk_size和overlap。chunk_size决定了每个切片的大小太大会让检索单位粗粒化太小会切断完整语义overlap是前后切片的重叠字符数目的是确保切在中间的一句话在两个切片中都能找到完整的上下文。实测下来600-100 这个组合在中文文档上表现比较稳。4.2 向量化与检索链路搭建分好块之后下一步就是把每一块文本变成一个向量。这一步用的sentence-transformers库封装好了大量开源的文本向量化模型你只需要几行代码就能调用from sentence_transformers import SentenceTransformer # 加载中文向量化模型 model SentenceTransformer(BAAI/bge-small-zh-v1.5) def embed_documents(chunks: List[str]) - List[List[float]]: vectors model.encode(chunks, batch_size32, show_progress_barTrue) return vectors.tolist() # 对全部文档块做编码 doc_vectors embed_documents(all_chunks)选这个模型的原因有三个它是中文社区广泛使用的基准模型效果有保障bge-small版本只有一百多 MB本地跑完全没压力它已经经过指令微调对为这个句子生成表示以用于检索相关文章这类任务做过专门优化。向量化完成后我写了一个基于 NumPy 的向量检索函数逻辑非常简单——把用户问题也编码成向量然后计算它与所有文档向量的余弦相似度取最高的 Top-Kimport numpy as np def cosine_similarity(vec1: List[float], vec2: List[float]) - float: dot np.dot(vec1, vec2) norm np.linalg.norm(vec1) * np.linalg.norm(vec2) return dot / norm if norm ! 0 else 0.0 def search(query: str, top_k: int 3) - List[tuple]: query_vec model.encode(query) scored [] for idx, doc_vec in enumerate(doc_vectors): score cosine_similarity(query_vec, doc_vec) scored.append((idx, score)) scored.sort(keylambda x: x[1], reverseTrue) return scored[:top_k] # 测试看看如何优化推理延迟能检索到什么 results search(如何优化推理延迟) for idx, score in results: print(fscore{score:.4f}, chunk{all_chunks[idx][:80]}...)如果你连向量数据库都不想用用 NumPy 硬解在文档量不大的情况下是完全可以的。我这里大概只有几千个向量检索一次在几毫秒内完成。但当你的文档量达到百万级别时就需要引入 FAISS 这类专门做近邻检索的工具了这在我的另一个关于向量数据库选型的项目中有更详细的对比。4.3 接入大模型生成最终回答检索到相关内容之后最后一步就把它们和用户问题打包成大模型的对话输入。这里的核心工程点是提示词模板的设计——检索出来的文档怎么排列、怎么标记、怎么告诉模型引用而非瞎编。我用的模板长这样def build_prompt(query: str, documents: List[str]) - str: context \n\n.join([f[文档{i1}]\n{doc} for i, doc in enumerate(documents)]) return f你是专业的技术问答助手请基于以下参考文档回答用户问题。如果参考文档中没有相关内容请明确告知当前资料中未找到答案不要编造。 参考文档 {context} 用户问题 {query} 注意我在提示词里明确加了一句不要编造而且给出了资料里没找到时就直说的兜底指令。这是我在实际项目中踩过不少次坑后总结出来的经验大模型天生有讨好用户的倾向即使没有相关资料它也会根据训练记忆脑补一个听起来可信的答案。加了这个约束之后回答的准确性会有可见提升。最后调用 OpenAI 接口生成答案from openai import OpenAI client OpenAI( api_keysk-xxx, # 换成你自己的配置 ) def generate_answer(query: str, top_k: int 3): hits search(query, top_ktop_k) documents [all_chunks[idx] for idx, _ in hits] prompt build_prompt(query, documents) resp client.chat.completions.create( modelgpt-4o-mini, messages[ {role: user, content: prompt} ], temperature0.2, # 低温度减少随机性 ) return resp.choices[0].message.content # 完整测试 answer generate_answer(模型推理延迟应该怎么优化) print(answer)temperature这个参数也值得留意。做 RAG 问答这类偏向精确查找的任务时我一般把它调到 0.2 以下让模型的输出更稳定、更贴近检索到的文档事实。如果是做头脑风暴、文案创意这类发散任务才会把 temperature 调到 0.7-1.0。整套流程跑下来效果还是相当令我满意的。当用户问模型推理延迟怎么优化时系统能比较准确地检索出我之前文章中关于量化、蒸馏、批处理的内容并结合上下文给出有出处的回答而不是像纯大模型那样泛泛而谈。4.4 基于仓库方法的深度扩展评估机制这个仓库里还提到了一个 RAG 系统上线前必须做、但绝大多数教程都会忽略的环节评估Evaluation。我强烈建议你写一个简单的评测脚本至少在迭代过程中知道自己的改动到底是变好了还是变差了。我的做法是准备了一组测试问答对大概 30-50 个人工写好标准答案的核心要点然后用两种指标来评估检索召回率RecallK看正确答案所在的文档是否出现在系统检索出的 Top-K 文档中。这个指标衡量的是检索环节有没有找对资料。生成答案准确率把生成的文本和标准答案做语义相似度对比或者直接用一个大模型做裁判打分。这个评估脚本的价值在于它能帮你科学地调参数。比如当你纠结几百字的 overlap 到底取多少跑一遍评估脚本看检索召回率的差别数字会直接告诉你答案。没有这套机制你会变成玄学调参选手靠感觉打天下这在工程上是最危险的。5. 常见问题与排查技巧实录5.1 手写神经网络时的常见报错与排查从我自身的学习经历和带新人的经验来看手写神经网络时有几个出现频率极高的坑这个仓库的评论区里也有很多人在问我统一整理一下。第一个经典问题loss 变成 NaN。遇到这种情况90% 的原因是计算梯度时出现了数值不稳定。排查思路是先检查学习率是不是太大了调小一个数量级试试再检查数据有没有归一化输入特征数值差异过大会让梯度爆炸最后检查损失函数内部有没有log(0)或者除零操作。我的建议是从后往前查——先看损失函数再看最后一层梯度再看前面各层梯度逐层定位。第二个高频问题模型不收敛。表现是 loss 几乎不变或者下降极慢。嫌疑最大的是梯度消失尤其是层数比较多、用了 sigmoid 激活函数的时候。解决办法通常是把 sigmoid 换成 ReLU、加上 Batch Normalization 或者改用残差连接。还有一个不起眼但很常见的原因特征没有标准化。输入数据的大小差异悬殊会让 loss landscape 变得异常崎岖梯度下降容易陷入震荡。第三个问题训练集效果很好测试集效果很差。这就是过拟合。这个仓库里给的方法非常实在先减少模型容量降低层数或神经元数再加强数据扩充或者正则化。不要一上来就想着用 dropout 或者早停——那是在你已经确定模型容量足够了之后才要做的事。5.2 实现 RAG 时的效果不佳排查RAG 系统上线后最常见的反馈是回答质量忽好忽坏有时候给的信息根本不是用户想要的。这种问题不能一刀切说是模型不行你得按段排查。我建议你按照下面的排查顺序来先看检索回来的文档内容是否相关如果不相关问题出在 embedding 或者分块上跟大模型没关系如果文档相关但生成答案很差那问题出在提示词模板或者大模型参数上如果文档相关、答案也相关但用户不满意那可能是产品层面的交互设计问题。具体分块和向量化方面有两个容易出问题的点。一个是 chunk 大小设置不合理。举个例子如果你把一份产品说明书切成了很多个 200 字的碎片产品保修政策这段信息可能刚好被拦腰截断在一块的末尾和下一块的开头检索时就找不到完整信息。另一个是 embedding 模型选型不对。如果你的知识库是中文技术文档但用了以英文为主的 embedding 模型检索效果就会大打折扣。这里我有一个高杠杆的调试技巧写一个小工具把用户问题、命中的文档块、生成的答案三者并排打印出来。每次线上回答质量不佳你就把这三样东西拉到一起看问题出在哪个环节一目了然。这个工具代码量不大但能帮你省下无数瞎猜的时间。5.3 大模型部署上线的实战问题仓库的部署章节同样值得反复阅读因为部署阶段的坑和训练阶段完全不同。我挑几个自己踩过的说说。第一个是关于推理延迟优化。很多人在本地跑模型感觉挺快但一上线用户请求一多就扛不住了。优化的优先级应该是第一对模型做量化比如从 FP16 降到 INT8这是收益最大的手段延迟能降一半以上第二开启批处理多个请求合并成一次推理第三用专门的推理引擎比如 vLLM、TensorRT它们对注意力计算和显存管理做了极致优化吞吐量可以翻好几倍。第二个是关于显存不够。如果你跑的是 7B 甚至更大的模型消费级显卡可能连加载都加载不下。仓库推荐的做法是采用模型分片加载例如通过 transformers 的device_mapauto可以把不同层放到不同的设备上。另外还可以用 CPU 卸载——把不常用的层放到内存用的时候再换回显存牺牲一点速度换取容量。第三个我之前吃过亏的是模型服务的优雅重启。你上线了新模型版本但老版本还有一批在途请求直接杀掉进程会导致这些请求失败。正确做法是先停止接收新流量等现有请求处理完后再切换新版本。这种细节如果你没有真正部署过线上服务永远不会意识到它有多重要。6. 学习路径规划与实践建议6.1 一个月快速起步的路线设计我知道很多人收藏了这类仓库之后就再也没有打开过第二遍。为了帮你避免这种收藏即学习的悲剧我基于这个仓库的内容整理了一份一个月起步的实战路线你照着推进就好。第一周打地基对应仓库 01-02 章复习线性代数的核心概念向量、矩阵乘法、范数。学习 NumPy 的数组操作索引、切片、广播、向量化。用 NumPy 实现一个完整的线性回归包括数据生成、前向传播、损失计算、梯度下降。目标不是学会 API而是理解训练循环的整体结构。第二周神经网络入门对应仓库 03-04 章手写一个两层神经网络完成 XOR 分类任务。手动实现反向传播并对比你算出来的梯度和数值梯度有限差分法是否一致。分别尝试 sigmoid、tanh、ReLU 激活函数观察训练行为的差异。用 sklearn 自带的数据集如鸢尾花数据集做多分类任务。第三周向 Transformer 前进对应仓库 05-06 章理解词嵌入Embedding的概念与实现。从零实现多头注意力机制重点搞清楚 Q/K/V 三个矩阵的变换过程。实现一个完整的 Transformer Block包括 FFN、LayerNorm、残差连接。如果精力允许实现一个简化版的字符级 GPT 训练任务。第四周工程能力泛化对应仓库 07-10 章用 LangChain 或原生代码搭一个 RAG 系统导入自己的文档数据。实验不同 chunk 大小和 embedding 模型对检索质量的影响。尝试用 LoRA 方法微调一个小模型完成特定的指令任务。最后写一个简单的 API 服务把你训练好的模型部署上去。这四周走完你会发现自己看 AI 项目的眼光完全不同了。以前看一篇技术文章是哦这是用 LangChain 做的现在你会下意识地分析它的向量化模型选的是什么chunk 是怎么切的检索到的上下文有没有真正发挥作用这种拆解意识的建立是这个仓库给你最重要的礼物。6.2 学习过程中必须养成的三个习惯结合我个人的实战经验和带人的观察有几个学习习惯的培养和具体技能的学习同样重要。习惯一代码必须亲手重写不要复制粘贴。一看就会一写就废这是所有人的通病。看懂了和能写出来之间隔着一个巨大的鸿沟。这个仓库里每一章的核心代码我都会建议你合上答案自己从头写一遍。写不出来很正常卡住了再看看完再合上继续写。这个过程虽然慢但效果是复制粘贴的十倍不止。习惯二遇到报错先自己排查 30 分钟。我知道很多人一看到报错就马上复制到搜索引擎或者扔给 ChatGPT但这样你永远培养不了工程直觉。正确的做法是先静下来看报错信息、把相关代码逻辑在脑子里过一遍、定位可疑的变量或函数。30 分钟解决不了再求助。我带的不少新人前期会抱怨卡住太久但两个月之后他们的独立排错能力明显能甩开同龄人。习惯三每个章节结束用通俗的话把原理讲给别人听。这个仓库的每一章后面都有很棒的总结图表但那是作者的不是你自己的。你真正掌握一个概念标志是你能否用大白话把它讲给一个没学过 AI 的朋友而对方能听懂。比如反向传播就是一层层地往回传梯度听起来简单但真让你把为什么梯度要往回传、怎么传讲明白你会发现自己的理解还有不少模糊地带。这三个习惯是我认为比任何具体知识点都重要的底层的认知方法。仓库的作者在 README 里也强调了类似的观点我觉得这是整个项目最宝贵的 元知识。6.3 后续扩展方向这个仓库可以如何延伸学完这个仓库不代表终点反而代表你终于有了足够的基础去探索更加广阔的领域。我个人认为可以从下面几个方向继续进阶。第一个方向是深入推理优化。你会发现训练好一个模型只是开始真正让它稳定高效地跑起来才是巨大的挑战。你可以继续学习模型量化、蒸馏、剪枝、批处理调度这些内容也可以用 vLLM、TensorRT 这些工业级推理工具做性能压测和调优。这几乎是所有大模型公司最稀缺的技能方向之一。第二个方向是扎实看论文、追前沿。当你手写过 Transformer再去读 Attention Is All You Need、BERT、GPT 系列论文会流畅很多。之后再扩展到 LoRA、RAG、Agent 的相关论文你就能跟上整个领域的演进节奏。不要怕论文太长有了动手经验之后你读论文的速度会快得惊人。第三个方向是参与开源社区。这个仓库本身就是开源项目你可以给它提 Issue、提 PR、补充新的章节内容甚至基于它的结构打造一个属于你自己的教程。我从自身的体验来说教是最好的学向开发者社区分享你的笔记和实践总结会被逼迫着把知识讲清楚赢得的反馈本身也会非常有价值。7. 实战项目拆解一个基于本仓库方法的 ChatPDF 示例我发现仓库的最后一个章节也就是实战项目部分是很多人最想直接看却最不重视的前面内容的总验收。这里我在仓库思路的基础上增加一个我自己比较常用的实战项目—— ChatPDF这是 RAG 技术最经典的落地场景之一也是检验前面所学是否达标的试金石。7.1 项目需求与整体架构ChatPDF 的需求很直白用户上传一份 PDF 文档系统理解文档后用户可以针对文档内容进行问答。例如上传一份技术白皮书问这个方案的容灾机制是怎么设计的系统能基于文档内容给出精确回答。从工程架构上看这个项目包含五个模块文档解析模块从 PDF 中提取可读文本处理表格、页眉页脚等噪音。预处理模块文本清洗、分块。向量化与索引模块把文本块转为向量建立可检索的索引。检索模块针对用户问题召回 Top-K 相关文本块。生成模块将检索结果与用户问题组装为提示词调用大模型生成回答。加上两个辅助模块一个简单的 Web 界面一个日志记录组件。整体复杂度适中非常适合作为 RAG 入门的完整练手项目。7.2 核心实现要点与踩坑记录我在实现过程中遇到过不少问题挑几个有代表性的第一PDF 解析的质量。PDF 文件看起来是文字实际上内部结构各异。有些 PDF 的文字是从图片扫描出来的直接提取是空白。我试过 PDFPlumber、PyMuPDF 等多种方案最终选择了同时支持文本提取和 OCR 的 PyMuPDF 优化版本。你需要用文档解析库的时候最好优先看看他内部使用的具体解析引擎是什么类型避免换一个文档就出错。第二表格数据的处理。如果你的 PDF 里有大量表格直接按文本提取会打乱表格结构检索时很容易断章取义。我建议把页面结构信息也保留下来用标记格式比如用竖线和制表符模拟表格位置重新组织表格内容让大模型能看懂。这一步对知识库型产品的效果提升是决定性的。第三索引更新。用户上传新文档后不能重建整个索引——成本太高。合理的做法是增量索引新文档向量化后追加到向量数据库中同时记录文档 ID删除时按 ID 移除对应向量。这个机制在你做企业知识库这类持续更新的产品时会非常有用。7.3 性能评估与上线表现上线后我持续跟踪了这项目的效果并调整了各种参数。使用大模型裁判评估后发现最重要的两个影响因子是 chunk 大小和检索 Top-K 数量。chunk 从 300 字调到 800 字回答准确率有近 10 个百分点的波动Top-K 从 2 调到 4准确率先升后降——因为相关上下文变多了但也引入了更多噪音。这个经验我记录在了项目的实验日志里也证明了一个观点RAG 系统的效果是调出来的不是配出来的。最终这个项目部署在一台 8 核 16G 的云服务器上单次问答平均延迟约 1.5 秒其中向量检索约 30 毫秒大模型生成了剩余的大部分时间。对于内部工具型产品来说这个速度是完全够用的。如果想要进一步提升我会建议把大模型换成部署在本地的开源模型并在服务层加上提示词缓存这些都能有效降低成本和延迟。8. 对 AI 工程方向的个人反思与建议8.1 从会用 AI到建好 AI 系统的思维跃迁AI 工程是使用工具组合创造系统服务的学问而不是单纯会写代码、跑通模型。我见过太多训练了一个模型准确率很高的开发者但他们处理不了实际生产环境的数据漂移、服务稳定性、模型版本管理、成本控制这些问题。这个仓库打破了一个隐形的认知障碍让人从只关心笔记本里的模型表现跳到关心线上用户体验和系统成本的维度。当你开始思考准确率真的能代表模型效果吗、当模型回答错误时反馈机制怎么设计、当各地用户访问延迟怎么办时你才真正在从个人开发者转向 AI 工程师。8.2 手写代码在 AI 工程时代的稀缺价值有些朋友可能觉得现在 AI 都能生成代码了何必还要自己手写。这种观点有一定道理——有些重复性代码确实可以让 AI 代劳。但正因为 AI 编程工具泛滥理解代码原理、能看懂 AI 生成的代码是否合理、能定位 bug 的能力反而更加稀缺了。当你手写过反向传播你才能明白model.zero_grad()是在清空哪里的梯度、为什么每次迭代前都要调用当你手写过注意力机制你才能理解为什么有些人调num_heads时模型崩溃。这些知识像是放大器的底座——没有底座放大倍数再高也失真有了底座AI 编程工具的潜力才能最大发挥。8.3 学习建议的最终收束回到初始那个问题这个仓库能不能让你成为 AI 工程师答案是——它可以但要看你打算分几期投入。我的观察是方法对路的人三个月能建立起扎实的 AI 工程基础方法不对、跳着学、只收藏不实践的人可能三年还停留在调包阶段。我最后的建议有三条都是血泪总结给这个仓库设置一个明确的目标。不是为了学习而学习而是为了做出一个能用的东西而学习。把最后一章的实战项目当作必答试题。任何一个 AI 工程方向的人如果无法独立完成一个端到端的 RAG 项目面试官问技术细节时都会底气不足。学习过程中多与人交流、多输出。加入社区、记录博客、参与讨论这点我后面《从零构建 AI 项目如何系统梳理大模型产品设计思路》那篇会继续展开。这个仓库的学习体验让我想起自己早年学编译原理的感觉——课程内容和应用有距离感技术洞察和工程实践的落差是真实存在的。“从零开始”那种艰难感不知不觉间就化成了在后续更多复杂项目中一眼看穿问题本质的直觉。你会体会到它的价值那时候选它就不需要任何理由了。