# 这本 LLM 落地书，FDE 不必从头读起

> 《Building LLMs for Production》进现场前读六部分就够，新增的数据准备一章要排在微调之前。

原文: https://fdetimes.net/zh/books-courses/building-llms-for-production-fde-reading-order/

一本约 470 页的 LLM 书在 2024 年 10 月更新，最大的新增内容原来是关于数据的：全新的一章，讲索引、检索器和数据准备。

这个细节也提示了《Building LLMs for Production》该怎么读。这本书由 Towards AI 出版，Louis-François Bouchard 参与合著。如果你是前线部署工程师（FDE），在讨论选哪个模型之前，先把客户的文档吃透，因为 RAG 只有找到正确的段落，才能给出正确的回答。

所以真正值得问的不是这本书好不好，而是去现场之前该读什么。简短的回答是：六个部分，而且不按目录顺序读。

## 先买对书

这本书目前有两个名字。第一版叫《Building LLMs for Production》，副标题点明了提示词、微调和 RAG。Towards AI 网站上的第二版改名为《Building AI for Production》，共 12 章，副标题只提微调和 RAG。

如果手里是旧版，不必只为了 Agents 或 Fine-Tuning 两章再买一本。Towards AI 的对比表说，这两章主要是结构调整，而 Deployment 一章写得更深入；这才是升级的真正理由，如果你的版本没有新的数据章节，那也算一条。

入门门槛很低：Towards AI 写这本书面向的是对 AI 和 NLP 一无所知的读者，Bouchard 只要求懂一点 Python。如果你做过几年后端，LLM 和 NLP 基础部分可以略读，遇到陌生术语再放慢。

LlamaIndex 联合创始人兼 CEO Jerry Liu 称，就他发表评价时而言，这是讲 LLM 应用最全面的教材。但正因为全面，才不该从头读到尾。

## 按部署进度安排的阅读顺序

下面的章节编号以第二版为准。顺序和右栏是给 FDE 的建议，并非出自书中。

只有索引与检索器一章没有编号，因为它的标题来自 2024 年 10 月的更新，无法对应到第二版的章节号。请在你手头版本的目录里按主题查找。

| 顺序 | 读什么 | 在客户现场的工作 |
|---|---|---|
| 1 | 第 V 章：RAG | 到场之前：弄懂链条上的各个环节，用公开文档搭一个试验版 |
| 2 | 索引、检索器、数据准备 | 第一次会面：要来 50 个真实问题，处理杂乱的文档，测量检索效果 |
| 3 | 第 IX 章：高级 RAG | 修复已经测出来的具体问题 |
| 4 | 第 XII 章：部署 | 确定模型部署在哪里、延迟和成本 |
| 5 | 第 X 章：Agent | 检索可靠之后再扩展 |
| 6 | 第 XI 章：微调 | 前面几步都不够时再考虑 |

把微调放在最后是一种观点，不是书里的规定。微调要消耗标注数据和维护精力，而 RAG 项目早期的问题，往往在数据侧就能以更低成本解决。Agent 排在微调前面，是因为很多客户很早就会问到 Agent，但建立在糟糕检索器之上的 Agent，只会错得更快。

## 用框架之前，先手工搭一遍 RAG 数据管道

这次更新附带一份从零搭建基础 RAG 数据管道的分步指南，书中还配有可直接运行的 Colab notebook 和代码项目。这部分不要只是扫一眼。当演示在客户面前给出错误答案时，你需要知道是哪一步出了问题，亲手组装过每个环节的人能更快找到原因。

一个实际提醒：Towards AI 网站上的电子书是交互式的，不是可下载的 PDF。别指望存个文件在去客户的路上读。

## 先测检索器，再怪模型

这就是索引与检索器一章排在第二的原因。设想一家保险公司交给你一堆 PDF 合同，想要一个聊天机器人回答员工的问题。你和这些员工一起写出 50 个真实问题，每个问题配上包含答案的段落，然后单独运行检索器。

假设检索器只为 30 个问题找到了正确段落。其余 20 个问题没有正确的回答依据，所以无论换成哪个模型，50 个问题中最多只有 30 个，也就是 60%，能基于正确的文档作答。

有了这个数字，会议就不再围绕“模型好像不够聪明”打转，大家会讨论如何重新切分、重新索引文档。

**要点:** 检索器找不到正确段落，再好的模型也救不回答案。

因此，到客户那里第一件事不是选模型。在针对他们的数据写下第一行 RAG 代码之前，先要来 50 个真实问题，以及能回答这些问题的人。只有弄清那 20 个问题为什么失败，高级 RAG 一章才会成为对症下药的方案清单。

## 向客户承诺之前，先算延迟

部署部分新增了蒸馏，这是一种降低推理成本和延迟的技术，并附有 Google Gemma 2 的案例研究。书中还介绍了在 Together AI、Groq、Fireworks AI 和 Replicate 上部署 LLM。平台清单过时很快，所以要学会如何比较，而不是记住名字。

要做的计算很简单。假设客户要求 1.5 秒内给出答案，检索器耗时 300 毫秒，模型耗时 2 秒：总共 2.3 秒，比要求慢 800 毫秒。

这时你可以改变模型的部署位置、换用更小的模型，或者在流量足够大、值得投入时考虑蒸馏。在真实基础设施上测出这些数字之前，不要向客户承诺响应时间。

## 把读书变成求职证据

读完一本书，对招聘方证明不了什么。如果 FDE 岗位描述提到基于客户数据的 RAG，就复习第 V 章和第 IX 章；如果提到生产环境部署或延迟优化，就复习第 XII 章。

在简历上，一个带测量数据的小项目，比一句“读过这本书”有力得多：处理的是哪些杂乱文档，修复前后检索器分别答对了多少个问题中的几个，测得的延迟是多少。

面试时，准备好解释为什么你还没有做微调。这个回答能说明你知道一项技术什么时候还不值得做。

这本书约 470 页，但在客户现场的第一次会面，可能只是从一个 PDF 文件夹和 50 个问题开始。为这次会面做好准备的人，读剩下的内容时，心里的问题会清楚得多。

**本周动手试试:**

- 按书中方法，用一组公开文档搭一条基础 RAG 数据管道，再写 50 个问题及其正确段落，测量检索器。
- 在一个云平台上部署开源 LLM，对照自己设定的目标记录实测延迟。
- 按这个模式改写简历中的一行：修复检索器前后，找到正确段落的比例有何变化。

## 信源

- [The AI Engineer's toolkit | What's AI](https://www.louisbouchard.ai/book-towards-ai/)

- [Building LLMs for Production Gets a Massive Update](https://towardsai.com/p/machine-learning/building-llms-for-production-gets-a-massive-update)

- [Building AI for Production](https://towardsai.com/book)

- [Building LLMs for Production](https://towardsai.com/academy/building-llms-for-production/)