如何使用 AI Engineering From Scratch 提升开发效率：从入门到精通实战指南
上个月我在做团队知识库检索系统的时候，犯了一个很蠢的事：花了一周把文档全部扔给 GPT-4 原样问答，成本爆炸不说，回答还经常胡说八道。憋了一晚上换了方案——用 RAG 重构了一遍，成本降了 70%，准确率反而从 65% 涨到了 89%。
这次翻盘靠的是一个叫 rohitg00/ai-engineering-from-scratch 的 GitHub 开源项目。研究了两天之后，我觉得这是个值得推荐的东西，所以写了这篇。
为什么市面上大多数 AI 教程让人越看越迷糊
我们先聊聊为什么学了那么多 AI 教程，真正动手的时候还是不会。
问题出在哪儿？知识和实战之间有巨大的鸿沟。 教程要么是"5分钟调用API"级别的快餐，跑通了hello world然后呢？什么都不会告诉你。要么是论文式的，RAG的47种变体列了一遍，看完还是不知道在我的业务里到底该选哪种。
有一个很经典的"教程陷阱"：跟着教程一步步做，每一步都能跑通，因为教程把所有坑都提前填好了。但一旦你自己从零开始做一个真实项目，第一步就卡住了——选什么模型？用什么Embedding？数据怎么清洗？每一步都有几十种选择，教程里从来不说这些选择之间的取舍。
真正缺的是有人告诉你：从有个想法到系统上线，中间每一步具体怎么做、怎么选、哪里容易翻车。 这就是该项目试图填补的空白。
这个项目的定位很明确：假设你会写代码，目标是把 AI 能力真正落地到生产环境，而不是跑个 demo 截图发朋友圈。覆盖的内容包括 Prompt Engineering 的系统化方法、RAG 架构的实战搭建、LLM 应用的开发范式，以及部署时要注意的那些坑。
边学边做的实战路线
最实用的地方是它真的让你"边学边做"。项目推荐直接用 Cursor 或 Windsurf 这种 AI 编程工具打开它，一边啃文档一边改代码，比对着 PDF 抄示例效率高太多了。我自己是用 Cursor 的 Composer 模式，左侧开着项目 README，右侧写代码，遇到报错直接问 AI，省了大量查文档的时间。
建议的学习路线大概是这样的：
- 第一周 —— 过一遍项目整体结构，跟着README跑通基本的 prompt engineering 部分，理解基本概念
- 第二周 —— 动手搭建自己的第一个 RAG 系统，从最简单的"文档+问答"开始
- 第三周 —— 学习评估方法，用自己的测试数据验证系统效果
- 第四周 —— 学习优化技巧，包括缓存、模型选择、成本控制
当然，这个时间线因人而异。如果你有 Python 基础，两周就能走完；如果之前没接触过 LLM 相关的东西，可能要花一个月。
RAG 三层架构深度拆解
关于 RAG 这个被说烂了的东西，它其实讲得很清楚。RAG 说到底分三层，每一层都有自己的门道。
第一层：数据处理
文档怎么切、切多块、怎么清洗，看起来简单但直接影响后面所有效果。
我一开始用的是最简单粗暴的"每500字切一刀"，结果效果很差。后来才意识到，chunking 是 RAG 系统里最需要"因地制宜"的部分。
按结构切 vs 按长度切：
如果你的文档结构清晰（比如技术文档有明确的章节），最好按章节切，每个 chunk 对应一个语义完整的段落。这样检索时能召回整段相关内容，不会把一个完整的解释切成两半。
如果文档结构松散（比如会议记录、聊天记录），那就只能用固定长度切，但要设置重叠（overlap）。我的经验是 chunk size 800 token、overlap 100 token 是个不错的起点，然后根据检索效果微调。
清洗也很关键。 文档里的大量噪音——页眉页脚、目录、广告、免责声明——如果不清理掉，会被切成大量无意义的chunk，严重干扰检索效果。一个有效的做法是在chunking之前先过一遍正则清理，去掉固定格式的噪音。
第二层：检索
Embedding 模型怎么选、要不要混合检索、检索几条结果合适，这些决定能不能精准找回相关内容。
模型选型： 中文场景强烈推荐 BGE-large-zh，效果和速度都不错，而且是开源的。如果你做英文场景，OpenAI 的 text-embedding-3-large 是目前的行业标准。
很重要的一点，不要混用不同厂商的 Embedding 模型——不同模型对"相似"的理解是完全不同的，放在一起用会严重影响检索质量。我看到过有人省钱，存量数据用的是一个老模型，新数据用的是新模型，结果检索效果一塌糊涂。
混合检索是必须的。 纯向量检索有个致命问题：它擅长语义相似，但不擅长精确匹配。比如你想检索"错误码 E1002 怎么解决"，向量检索可能召回一堆"常见错误处理"的文档，而真正包含 E1002 的文档反而没召回来。混合检索就是向量检索 + BM25 关键词检索的组合，通常能把召回率提升15-20%。
检索几个结果？ 很多人以为检索结果越多越好，其实塞太多进去只会让模型分心，5 到 8 条精准的结果远比 20 条良莠不齐的强。
第三层：生成
找回的内容怎么组织成 Prompt、上下文塞多少、要不要二次检索，这些决定最终回答的质量。
有个东西叫 Re-ranking（精排），我在实际项目里加完之后效果提升非常明显。它的原理是：先用初检索召回 20-30 条候选，然后用一个更小更精确的精排模型给每条候选打分，留下排名前 5-8 条的喂给大模型。这样做的好处是：数量不多但每条都精准，回答质量自然就上去了。
在组织 Prompt 的时候，有个小技巧很实用：别把检索结果一股脑塞进去，而是先给结果标号，告诉模型"以下内容可能包含答案，如果内容与问题无关可以忽略"，这样模型不会把噪音内容当成事实引用。
评估框架：不测就上线等于盲飞
评估框架是我觉得它里面最值得参考的部分，不用等用户来投诉才知道系统有问题。
核心就三个指标：
- 检索相关性 —— 检索到的内容有多少真正跟问题相关的
- 生成忠实度 —— 生成的回答是不是基于检索内容，有没有瞎编
- 语义匹配度 —— 回答和问题相关度怎么样
准备二三十个有标准答案的测试问题，跑一遍评估，心里就有底了。一个简单做法：每个问题准备 3-5 个"必须包含的关键词"，检查回答里是否包含了这些关键词。
我第一次做完评估的时候，发现一个本以为已经做得挺不错的系统，忠实度只有 58%——也就是说有将近一半的回答，模型在"自说自话"，而不是基于检索到的内容回答。后来针对性优化了 Prompt 模板，把忠实度拉到了 87%。
上线之后每周抽检，持续迭代。评估不是一次性的，是持续性的工作。
两个实战场景
场景一：公司知识库检索。 公司技术文档散在 Confluence、Notion 和本地仓库里，同事找资料要翻好几个地方。之前直接让 GPT-4 读全部文档的高成本方案挂了之后，我换了 RAG 思路：统一转成标准格式、用 BGE-large-zh 做向量化、Qdrant 存向量、Chunk 设 800 token 带 100 token 重叠。评估之后再加重排序模块。最终 P99 延迟从 4 秒降到 1.2 秒，API 成本降了 70%。
场景二：内部客服场景。 高频重复问题占了 70% 的工单量，人工处理又慢又累。先做意图识别把问题分类，高频 FAQ 直接缓存命中走人，不碰 LLM 一下。实在搞不定的复杂问题再走 RAG 流程，置信度太低的转人工。加缓存之后响应时间从 2 分钟降到 8 秒，自动回复率从 30% 拉到 75%。
场景三（补充）：代码知识库。 在团队内部，我们也用 RAG 做了代码知识库。把历史项目的技术方案和常见问题做成可问答系统，新来的同事问"怎么添加新页面"，能直接拿到步骤和对应代码位置，而不是找老人问半天。
新手最容易踩的坑
坑一：Embedding 模型和生成模型混用。 我以前图省事，Embedding 用 OpenAI 的，生成用 Claude。两个模型对"相似"的理解根本不一样，检索和生成各说各话。后来统一成同一家系的模型，检索质量立竿见影。
坑二：Chunk 大小随便拍脑袋。 500 还是 1000 还是 2000？这个问题没有标准答案，取决于你的文档结构和问题类型。唯一靠谱的方法是：跑 eval，测数据，调参数，别猜。
坑三：不做评估就上线。 Demo 跑着感觉挺好，上线之后被用户问出各种奇怪问题直接绷不住。开发阶段那二三十个测试问题不是白准备的，上线前必须过一遍。
坑四：忽略成本。 生产环境调用量上来后账单会教你做人。缓存层必须加，简单问题用小模型，复杂问题用大模型，别一刀切全上 GPT-4。
坑五：以为 RAG 能解决所有问题。 RAG 擅长知识检索，但不擅长推理、计算、创意。别指望 RAG 系统帮你做数据分析、写诗歌或者解数学题。了解它的能力边界，把 RAG 用在它擅长的场景里。
什么样的开发者适合这个项目
这个项目整体来说适合这样的你：有一定编程基础，想系统地把 AI 能力落地到真实业务里，不想东拼西凑地找教程。
它给的不只是代码，是一套从评估驱动开发到渐进式优化的思维方式。当然，没有任何一个开源项目能解决所有问题，但它至少能帮你少走很多弯路。尤其对于那些觉得"教程都懂但就是做不出东西"的开发者来说，这套"边学边做"的方法论可能正是你需要的。