RAG on Khari Z's LogBook

多路召回学习笔记：BM25、Embedding、SPLADE 和 Reranker 各在解决什么

Fri, 15 May 2026 00:00:00 +0000

最近在补 RAG 和检索系统的基础。刚开始看资料时，最容易混在一起的几个词就是：BM25、Embedding、SPLADE、Reranker，再加一个听起来很工程的词：多路召回。

单独看定义不难，难点在于把它们放进同一条检索链路里。复习时重点回答这些问题：

哪些方法负责“先找一批候选”？
哪些方法负责“把候选重新排好”？
BM25 和 Embedding 明明都能搜，为什么还要一起用？
Reranker 听起来更准，为什么不直接全库跑？
SPLADE 到底是关键词检索，还是语义检索？

这篇笔记不铺满公式，重点讲清每种方法在检索系统里的位置、优势和边界。

速读版

先给一个压缩版结论：

方法	系统位置	主要解决	优点	短板
BM25	关键词搜索	字面精确命中	快、可解释、对术语敏感	不懂同义表达
Embedding	语义近邻搜索	意思接近但字面不同	泛化强，适合自然语言问题	细粒度容易混
SPLADE	神经稀疏搜索	语义扩展后的关键词匹配	兼顾稀疏结构和语义扩展	模型和索引更复杂
Reranker	精排裁判	少量候选谁最相关	判断细，通常更准	慢，不适合全库扫描

一条典型链路大概是：

1
2
3
4
5


用户 query
 -> BM25 / Embedding / SPLADE 多路召回
 -> 候选合并、去重、分数融合
 -> Reranker 精排
 -> 返回 top-k 或交给下游生成模型

多路召回要解决的是：不要让单一检索方法承担所有召回责任，而是让不同方法互相补盲区。

一、先分清召回和精排

搜索系统一般不会一开始就让最复杂的模型扫描整个文档库。文档量一大，成本会很高。

所以它会分成两步：

1
2
3
4
5


Recall 召回
 从大量文档里快速捞出一批“可能相关”的候选。

Ranking / Reranking 排序或精排
 在候选集合变小之后，再认真比较谁更相关。

召回阶段的目标是“尽量别漏掉相关候选”；精排阶段的目标是“在候选里排得更准”。

BM25、Embedding、SPLADE 通常更适合放在召回阶段；Reranker 通常更适合放在精排阶段。

二、BM25：最经典的关键词检索

BM25 是传统搜索里很经典的方法。它不理解深层语义，也不做推理，主要看一个问题：

query 里的词，在文档里有没有出现？出现的词有没有区分度？

比如用户搜：

1

酒店住宿报销

如果一篇文档里出现了“酒店”“住宿”“报销”，它就应该比完全没出现这些词的文档更相关。

BM25 可以先记成：

1

BM25 分数 ≈ 词频 TF × 逆文档频率 IDF × 文档长度修正

复习时先理解这三个部分，再回到完整公式。

2.1 词频：命中 query 词，说明可能相关

如果 query 里有“住宿”，文档 A 出现了“住宿”，文档 B 没出现，那文档 A 大概率更相关。

但 BM25 不会让词频无限加分。一个词重复出现很多次，并不代表相关性可以无限升高。所以 BM25 会对词频做饱和处理。

2.2 IDF：越少见的词，越有区分度

有些词太常见：

1

申请、说明、费用、管理、流程

它们出现了当然有一点信息，但区分度不强。

有些词更具体：

1

住宿、发票、差旅、押金、手续费

这些词更能帮助判断文档主题。

这就是 IDF 的直觉：一个词在全库里越少见，它越能区分文档。

2.3 文档长度修正：长文档不能天然占便宜

长文档词多，命中 query 词的概率天然更高。如果不修正，长文档会占便宜。

BM25 会考虑文档长度，让“短但精准命中”的文档也有机会排在前面。

2.4 BM25 的位置

BM25 特别适合这些场景：

搜索专有名词
搜索编号、代码、实体名
搜索业务词或固定术语
需要可解释的检索结果

比如：

1

增值税专用发票

如果文档里明确出现这个词，BM25 的表现通常很稳。

它的短板也很明显：不太懂同义词。

1
2
3


住酒店
住宿费
差旅住宿支出

这些表达意思接近，但字面不完全一样。如果没有共同词，BM25 可能就会漏。

复习锚点：BM25 适合作为基础召回，尤其适合术语、编号、实体名；短板是同义表达和口语化改写。

三、Embedding：把文本放进语义空间

Embedding 的思路和 BM25 不同。BM25 看词有没有命中；Embedding 把文本编码成向量。

语义相近的文本，在向量空间里应该更接近。

比如：

1
2
3


员工出差住酒店
差旅住宿费用
酒店房费报销

这些句子字面不同，但语义接近。好的 Embedding 模型会尽量把它们编码到相近的位置。

检索时通常是这样：

1
2
3
4


文档库里的文档 -> 提前编码成向量
用户 query -> 编码成向量
计算 query 向量和文档向量的相似度
返回最相似的 top-k 文档

最常见的相似度是余弦相似度：

1

cosine similarity = 两个向量方向的接近程度

它关心的是方向，而不是文本长度。两个文本语义越接近，向量夹角通常越小，相似度越高。

3.1 Embedding 解决了 BM25 的一部分盲区

用户的问题往往很口语化：

1

出差住酒店怎么报销

文档标题可能是：

1

差旅住宿费用管理办法

BM25 如果没有命中关键分词，可能不够稳；Embedding 更可能从整体意思上判断它们相关。

Embedding 适合：

同义表达
口语化 query
标题和问题表达方式不一致
需要整体语义理解的场景

3.2 Embedding 也会犯“语义太近”的错

Embedding 的问题是，它有时会太模糊。

比如：

1
2
3
4


技术服务费
咨询服务费
软件服务费
会议服务费

从语义上看都和“服务”有关，向量空间里可能靠得很近。但在实际业务里，它们可能需要被分到不同类别。

复习锚点：Embedding 擅长找“语义相近”的内容，但在术语边界、细分类别、编号实体上可能不够精确。因此它常和 BM25 搭配使用。

四、为什么需要多路召回

BM25 和 Embedding 的优缺点互补。BM25 负责词面命中，Embedding 负责语义相近；SPLADE 可以补充神经稀疏召回。多路召回就是同时跑多种召回方法，再合并候选：

1
2
3
4
5
6


BM25 召回一批
Embedding 召回一批
SPLADE 也可以召回一批
 -> 合并候选
 -> 去重
 -> 融合或重排

举个简单例子。

1

query: 出差住酒店怎么报销

BM25 可能找到：

1
2


酒店发票填写要求
住宿费报销单填写说明

Embedding 可能找到：

1
2


差旅费用管理办法
员工出差报销流程

两路结果合起来，比单独用一路更稳。

4.1 分数不能直接相加

多路召回带来一个麻烦：不同方法的分数不是一个尺度。

BM25 可能返回：

1

12.7, 8.3, 3.1

Embedding 的余弦相似度可能是：

1

0.82, 0.77, 0.65

这些分数不能直接相加。

常见处理方法有两类。

第一类是分数归一化，例如 min-max normalization，把不同来源的分数压到相近区间，再加权融合：

1

final_score = 0.5 * norm(BM25) + 0.5 * norm(Embedding)

第二类是只看排名，比如 Reciprocal Rank Fusion。它不太关心原始分数，而是看一个文档在每一路里排第几：

1

RRF(d) = sum(1 / (k + rank_i(d)))

如果一个文档在多路召回里都排得靠前，它的融合分数就会更高。

RRF 的复习锚点：多路召回都排得靠前的文档，融合后应该获得更高优先级。

五、Reranker：候选少了以后，再认真判断

如果 BM25、Embedding、SPLADE 负责先找候选，Reranker 负责在候选变少后做细粒度比较。

Embedding 通常是 bi-encoder：

1
2
3


query 单独编码
doc 单独编码
然后算向量相似度

这种方式快，因为文档向量可以提前算好。

Reranker 通常接近 cross-encoder 思路：

1
2


把 query 和 doc 放在一起
让模型直接判断相关性

例如：

1
2
3


query: 出差住酒店怎么报销
doc: 差旅住宿费用管理办法
score: 0.93

模型可以同时看到 query 和 doc，细粒度判断它们是否匹配。

5.1 为什么 Reranker 不直接全库跑

Reranker 通常更准，但也更慢。

如果文档库有 100 万篇，让 Reranker 对每篇都判断一次：

1
2
3
4


query-doc1
query-doc2
...
query-doc1000000

成本太高。

所以它一般放在召回之后：

1
2


先用 BM25 / Embedding / SPLADE 召回 top50
再用 Reranker 对这 50 个候选重新排序

复习锚点：召回阶段追求快和覆盖，Reranker 阶段追求细粒度相关性判断。

5.2 Reranker 适合处理候选之间的细微差别

比如 query 是：

1

酒店发票抬头填错了怎么办

召回阶段可能找出：

1
2
3


酒店发票填写要求
发票作废与重开流程
差旅住宿费报销规则

这些都相关，但最该排前面的可能是“发票作废与重开流程”。Reranker 就是在这种时候发挥价值。

六、SPLADE：神经网络版的关键词检索

SPLADE 是这几个方法里最容易混淆的一块，可以先这样理解：

SPLADE 试图把 BM25 的稀疏可解释性，和神经模型的语义扩展能力接起来。

BM25 在词项空间工作。文档里有哪些词，就在哪些词上有统计权重。

Embedding 在稠密向量空间工作。每个维度不一定有明确含义，但整体能表达语义。

SPLADE 也在词表空间里工作。假设模型词表有 30,000 个 token，那么一段文本会被表示成一个 30,000 维向量。

不同的是，这个向量很稀疏：

1
2


大部分维度是 0
少数相关 token 维度有正权重

比如用户输入：

1

住酒店

SPLADE 可能不只激活“酒店”，还会激活：

1

住宿、旅馆、房费、差旅

这相当于模型自动帮 query 做语义扩展，但结果仍然落在稀疏词项空间里。

6.1 SPLADE 的激活直觉

很多 SPLADE 实现会对模型输出做类似这样的变换：

1

log(1 + ReLU(x))

拆开看：

ReLU(x)：负数清零，只保留正向激活。
log(1 + x)：压缩过大的权重，让数值更稳定。

这样得到的是非负稀疏权重。

检索时可以直接做点积：

1

score(query, doc) = sparse_query_vector · sparse_doc_vector

如果 query 和 doc 在相同或相关 token 上都有权重，分数就会变高。

6.2 SPLADE 放在哪个位置

可以把它放在 BM25 和 Embedding 中间理解：

1
2
3


BM25 ：词面匹配，稀疏，可解释
Embedding ：语义匹配，稠密，不太可解释
SPLADE ：神经稀疏匹配，有语义扩展，也保留词项空间

SPLADE 吸引人的地方在于，它不像普通 Embedding 那样完全进入黑盒稠密空间，也不像 BM25 那样只依赖原始词面。它可以学习到一些扩展关系。

它的成本也更高：需要专门模型，向量维度很高，索引和部署比 BM25 更复杂。

七、一个完整检索链路可以怎么想

假设用户问：

1

差旅住宿发票丢了还能报销吗

一条比较完整的检索链路可以这样组织：

1
2
3
4
5
6
7


1. BM25 找到包含“差旅”“住宿”“发票”“报销”的文档
2. Embedding 找到语义上接近“发票遗失”“报销材料补充”的文档
3. SPLADE 如果可用，再补一批神经稀疏召回结果
4. 合并候选，去掉重复文档
5. 用归一化加权或 RRF 做候选融合
6. 用 Reranker 对候选重新排序
7. 把 top 文档交给下游问答模型或直接返回

每一步对应一个具体问题：

BM25：有没有明确命中关键词？
Embedding：语义上像不像？
SPLADE：能不能做更聪明的词项扩展？
Reranker：候选里谁最贴合用户问题？

八、选型建议

如果只是做一个小型知识库，最简单的起点通常是：

1

Embedding 召回 + Reranker 精排

如果业务词很强，比如法规条款、财务科目、商品型号、错误代码，可以加上 BM25：

1

BM25 + Embedding 多路召回 + Reranker 精排

如果发现 BM25 词面太死、Embedding 又容易把细分类别混在一起，再考虑 SPLADE：

1

BM25 + Embedding + SPLADE 多路召回 + Reranker 精排

不要一开始就把所有东西都加上。检索系统越堆越复杂，调试成本也越高。更稳的做法是先跑通 baseline，再根据错误样本决定补哪一路。

小结

多路召回不是一个单独算法，而是一种系统设计思路：让不同检索方法从不同角度找候选，再用排序模型做最终筛选。

BM25 解决精确词面匹配，Embedding 解决语义泛化，SPLADE 尝试在稀疏词项空间里加入神经语义扩展，Reranker 负责最后的细粒度判断。

以后复习或设计检索链路时，优先问这些问题：

1
2
3
4
5
6


它用了哪些召回路？
每一路分别解决什么盲区？
候选是取并集，还是只在某一路结果里重打分？
不同分数怎么融合？
Reranker 放在多少候选之后？
最终阈值有没有单独校准？

这些问题比单独背概念更有用。检索效果通常不是由某个单点算法决定的，而是由整条链路的召回覆盖、候选融合、精排质量和阈值校准共同决定的。

大模型应用这一层：从评测、RAG 到 Agent

Sat, 02 May 2026 00:00:00 +0000

第七章的主题很集中：大模型进入应用场景后，先要评估能力边界，再接入外部知识，最后才谈工具调用和任务执行。

这一章可以按三个模块复习：评测、RAG 和 Agent。评测判断模型在哪些任务上可靠；RAG 把外部文档接入生成过程；Agent 让模型通过工具参与行动。

整章可以整理成下面这条应用链路：

1
2
3
4
5
6
7
8


评测 Evaluation
 -> 判断模型在哪些任务上可靠，边界在哪里

RAG Retrieval-Augmented Generation
 -> 把外部文档和实时知识接入生成过程

Agent
 -> 让模型通过工具调用参与更复杂的任务流

这一章可以先按三层记：能力边界、知识接入、工具行动。

一、先从评测开始：不要只问模型强不强

进入应用层后，最容易犯的错误是把模型能力说得太笼统：一个模型在榜单上分数高，不代表它能胜任所有场景。

做应用时，要把“强不强”拆成具体能力问题：

它是否懂通用知识
它数学推理是否稳定
它能不能处理长文本
它多语言能力怎样
它是否会正确使用工具
它在金融、法律、医疗等垂直领域是否可靠

所以第七章把评测集按能力拆开看，比如 MMLU 偏通用多任务理解，GSM8K/MATH 偏数学推理，ARC/GPQA/HellaSwag 偏推理和常识，InfiniteBench/Multi-needle 偏长文本，MGSM 偏多语言数学。

评测是在给应用选择画边界。

比如我要做知识问答系统，就不能只看聊天榜单，还要看事实性、长文档理解和检索后回答是否忠实。我要做工具型助手，就不能只看语言流畅度，还要关心工具调用正确率、参数是否填对、失败时能不能恢复。

复习锚点：评测不是为了得到一个总分，而是为了判断模型适合放进哪个场景，以及哪些能力不能靠感觉判断。

二、RAG：把模型从“只靠参数记忆”拉回到外部知识

第七章第二部分进入 RAG。这里的背景很直接：LLM 虽然会生成，但它有几个天然问题：

训练数据可能过时
专业领域知识不一定充分
输出可能产生幻觉
很难直接给出可追溯依据

RAG 的思路很直接：生成之前先检索。用户提出问题后，系统先从文档库里找相关片段，再把这些片段作为上下文交给模型，让模型基于外部材料回答。

RAG 的主链路可以写成：

1
2
3


文档 -> 切分 -> 向量化 -> 向量库
 |
用户问题 -> 向量化 -> 相似度检索 -> 上下文拼接 -> LLM 生成回答

RAG 把知识系统拆成两个部分：

模型负责理解问题、组织语言和生成答案
检索系统负责把当前问题最需要的外部证据找出来

两者配合以后，应用可以把最新资料、私有文档、领域手册接到生成链路里，减轻对模型参数记忆的依赖。

图：RAG 先检索相关上下文，再让模型基于上下文生成回答

三、Tiny-RAG：最小实现里要盯住的几个模块

第七章还写了一个 Tiny-RAG。这个实现很适合学习，因为它把 RAG 系统拆成了几个足够小的部件：

文档加载与切分：ReadFiles
向量化：BaseEmbeddings / OpenAIEmbedding
向量存储与检索：VectorStore
生成模型封装：OpenAIChat
演示入口：demo.py

图：Tiny-RAG 把 RAG 拆成文档、向量、检索和模型回答几个最小模块

3.1 文档切分决定证据粒度

文档加载部分支持 pdf/md/txt，读出来之后会按 token 长度切成 chunk。这里要记两个参数：

1
2


max_token_len = 600
cover_content = 150

max_token_len 控制每个片段不要太长，cover_content 则给相邻片段保留重叠内容。这个重叠很重要，因为很多语义边界不会刚好落在切分点上。如果完全硬切，检索时很容易丢掉上下文。

所以 chunk 策略本质上是在做取舍：

chunk 太短，语义不完整
chunk 太长，检索不精确，而且占上下文
重叠太少，边界信息容易断
重叠太多，索引膨胀，成本增加

复习锚点：chunk 策略表面上是数据预处理，实际是在决定模型后面能看到什么证据。

3.2 向量化层要抽象出来

第七章先定义 BaseEmbeddings，再写 OpenAIEmbedding。这个设计很朴素，但教学价值很清楚：embedding 模型应该作为可替换模块接入 RAG。

1
2
3
4
5
6
7


class BaseEmbeddings:
 def get_embedding(self, text: str, model: str):
 raise NotImplementedError

 @classmethod
 def cosine_similarity(cls, vector1, vector2):
 ...

这里的重点在于接口抽象：embedding 模型被包装成了可替换模块。以后如果从 API embedding 换成本地 embedding，RAG 主流程不用大改，只要新的类实现 get_embedding 就行。

复习锚点：RAG 里的模型不止最终生成回答的 LLM，还有负责把文本映射到向量空间的 embedding 模型。embedding 质量不好，LLM 再强也可能拿不到正确上下文。

3.3 向量库的最小检索逻辑就是相似度排序

Tiny-RAG 的 VectorStore 很轻量：把文档片段和向量保存下来，查询时计算问题向量和每个文档向量的相似度，然后取 Top-k。

1
2
3
4
5
6
7


def query(self, query, EmbeddingModel, k=1):
 query_vector = EmbeddingModel.get_embedding(query)
 scores = [
 self.get_similarity(query_vector, vector)
 for vector in self.vectors
 ]
 return np.array(self.document)[np.argsort(scores)[-k:][::-1]].tolist()

这个版本属于教学级向量数据库，它把最基本的动作讲明白了：

问题也要向量化
问题向量和文档向量进入同一个空间比较
相似度最高的片段被取出来作为上下文

后续做项目时，可以把这里替换成 FAISS、Milvus、Qdrant、Chroma 之类的向量库，也可以补 reranker。但无论外壳怎么换，目标都还是“找到和问题最相关的上下文”。

3.4 RAG prompt 要约束模型只基于上下文回答

最后，OpenAIChat 会把检索到的内容放进一个 RAG 专用 prompt。这个 prompt 要明确告诉模型：

使用给定上下文回答
不知道就说不知道
上下文不足时不要编
用中文回答

这个 prompt 给模型增加“证据约束”：答案应建立在可追溯材料上。RAG 做得好不好，要回到评测中看事实一致性、引用准确性和答案忠实性。

四、RAG 的学习收获：系统质量不只取决于 LLM

RAG 系统的质量，很大一部分取决于生成模型之外的环节。

如果答案错了，可能原因很多：

原始文档质量不好
切分粒度不合适
embedding 模型不匹配
Top-k 召回错了
prompt 没有限制模型
模型没有正确使用上下文

这和直接问 LLM 很不一样。直接问模型时，问题通常被归因到“模型会不会”。但到了 RAG，系统多了检索层、索引层、上下文构造层，错误也会分散到更多地方。

所以看 RAG 系统时，不要只问“接了什么大模型”，还要问：

文档怎么切
向量怎么建
检索怎么排
上下文怎么塞
回答怎么评

这几个问题答清楚，才算开始理解 RAG 的系统质量。

五、Agent：从“会回答”走向“会调用工具”

第七章最后讲 Agent。它先给了一个比较完整的定义：LLM Agent 以 LLM 为中心，结合目标理解、规划、记忆、工具使用、反思迭代等能力，去完成更复杂的任务。

Agent 可以整理成一句话：

Agent 是把 LLM 放进一个可行动的任务系统里。

普通聊天模型的输出主要是文字。Agent 的变化在于，模型可以在合适的时候选择工具，比如查时间、搜索百科、查询天气、做计算，然后把工具结果继续放回对话，让模型生成最终回答。

Agent 改变了 LLM 的角色：模型不只是生成文本，还参与调度工具。它需要承担这些职责：

判断用户到底要什么
判断是否需要外部工具
选择正确工具
填好工具参数
读取工具返回结果
继续生成自然语言回复

第七章也把 Agent 粗略分成任务导向型、规划推理型、多 Agent 系统、探索学习型几类。当前复习可以先抓任务导向型，因为 Tiny-Agent 主要演示的就是这条最小链路。

六、Tiny-Agent：tool calling 的最小闭环

Tiny-Agent 的实现围绕 OpenAI 兼容接口里的 tool_calls 展开。它有三个部件：

工具函数
工具 schema 转换
Agent 对话与工具调用循环

工具函数本身很普通，比如获取时间、搜索 Wikipedia、查询天气。但在 Agent 里，普通函数要变成模型可理解的工具，就必须有清晰的函数名、参数类型和 docstring。

1
2
3
4
5


def get_current_datetime() -> str:
 """
 获取真实的当前日期和时间。
 """
 ...

接着，function_to_json 会读取函数签名，把它转换成 tool schema：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


def function_to_json(func) -> dict:
 signature = inspect.signature(func)
 ...
 return {
 "type": "function",
 "function": {
 "name": func.__name__,
 "description": func.__doc__ or "",
 "parameters": ...
 },
 }

模型看到的是结构化 schema。工具描述不清楚、参数设计不合理，模型就更容易选错工具或填错参数。

图：Tiny-Agent 的流程是模型提出工具调用，程序执行工具，再把结果交回模型

6.1 Agent 类负责维护调用循环

Agent.get_completion 的流程可以简化成这样：

1
2
3
4
5
6
7
8
9


用户输入
 -> 追加到 messages
 -> 调用模型并传入 tools
 -> 如果模型返回 tool_calls
 -> 执行对应工具
 -> 把工具结果追加为 tool message
 -> 再调用模型
 -> 保存 assistant 回复
 -> 返回最终答案

这个循环说明了 tool calling 的边界：模型输出结构化调用请求，外层程序执行工具，工具结果再回到模型上下文中。

所以 Agent 的可靠性同时取决于模型和外层控制逻辑：

工具是否有白名单
参数是否校验
调用失败怎么恢复
工具返回是否可信
历史消息是否会越积越乱

这些问题在纯聊天模型里不太显眼，但一旦模型开始调用工具，就必须认真处理。

6.2 Tiny-Agent 很适合作为 Agent 入门

第七章前面介绍了规划、记忆、反思等能力，但配套 Tiny-Agent 主要还是一个 tool calling demo。它有工具、有消息历史、有二次模型调用，但还没有实现复杂规划、长期记忆或反思循环。

作为学习入口，它很合适，因为它先把基础接口关系讲清楚了：

工具如何暴露给模型
模型如何提出工具调用
程序如何执行工具
工具结果如何回到模型上下文

等这一层明白之后，再看 ReAct、多 Agent、长期记忆、任务规划，才不会只停在概念名词上。

工程边界也要记住：Tiny-Agent 中用 eval(...) 执行工具调用，适合教学演示；真实系统应该换成更安全的白名单分发。模型一旦能触发工具，权限和安全边界就必须认真处理。

七、这一章留给我的应用层框架

这一章最适合留下一个应用层框架：

1
2
3
4
5
6
7
8


评测
 -> 明确模型能力边界

RAG
 -> 接入外部知识与可追溯证据

Agent
 -> 接入工具和任务执行过程

这里有三个复习结论：

评测要看具体任务边界
榜单分数只能提供参考，应用还要关心场景、数据、语言、工具和安全边界。
RAG 要把知识放到可更新的位置
外部文档、向量索引和检索结果共同决定模型能看到哪些依据。
Agent 要把工具调用纳入控制流程
Agent 让模型不仅能回答，还能通过工具查询、计算、搜索和执行任务。

第七章适合作为应用入口。Tiny-RAG 和 Tiny-Agent 给出了最小可运行骨架，帮助先看清系统边界。

八、写在最后：应用层要把不可靠变得可控

大模型应用不能只盯着模型本身，还要补上评测、检索、工具、日志和控制边界。

评测告诉我模型哪里能用，RAG 让回答尽量有依据，Agent 让模型可以接入行动接口。目标很实际：让模型在真实场景里更可控。

如果只保留这一章的学习结论，可以记住三句话：

评测负责应用边界。
RAG 负责外部知识接口。
Agent 负责工具调度。

复习应用层时，关注点要落到三件事：系统怎样设计、怎样观测、怎样迭代。