个人收集的八股，简单地总结了一下，欢迎分享讨论。



![3f5366e46ff24d669f745f489a31f74a 1.png](https://www.blog.aeside.top/static/img/07c3f7f8015eba711d639002ea580382.3f5366e46ff24d669f745f489a31f74a%201.webp)

![3f5366e46ff24d669f745f489a31f74a.png](https://www.blog.aeside.top/static/img/07c3f7f8015eba711d639002ea580382.3f5366e46ff24d669f745f489a31f74a%201.webp)

![db96011c50495dfea4005c488ace6511.png](https://www.blog.aeside.top/static/img/84df0bec74c88c4d776554566791abfa.db96011c50495dfea4005c488ace6511.webp)

![file-20251015155703582.png](https://www.blog.aeside.top/static/img/9a8073b16d5fef798e3323ed515f8b71.file-20251015155703582.webp)

![file-20251015155806460.png](https://www.blog.aeside.top/static/img/25a835f1af23abcd99586c3de1b01ea7.file-20251015155806460.webp)

![file-20251015155933605.png](https://www.blog.aeside.top/static/img/461da2e74422e5e056e7bb54c67a3018.file-20251015155933605.webp)

![file-20251015160104439.png](https://www.blog.aeside.top/static/img/3f74eb3d4cef60d3bce5d1e7b2dc1dbc.file-20251015160104439.webp)

# 八股
- #### 索引构建
	- 文本分块，大文本分块处理？
		- 引入 NLP 处理
		- 固定 or 文本段分块
		- 文档结构化分块（标题、段落）
	- 文档解析是怎么做的？
		- 图文文档如何存储检索？
		- 不同领域文档特征和结构不一样，是怎么做的？（看自己的项目领域，客服场景的工单，企业知识库的文档）
	- 向量维度选型？
- #### 检索流程
    - 上下文构建如何构建？
       - 一般采用 Redis + uid 构建，上下文长可以让 AI 概况
    - 检索前后做过什么优化？（？）
    - RAG 调参
		- [大模型参数如何设置（温度、Top-p、Top-k）+使用场景](https://zhuanlan.zhihu.com/p/24484122371)
		- RAG 找回 TopN 选型？怎么设置？
	- Rerank or Re-evaluation 怎么做的？
	- 有没有用过知识谱图？text-to-sql？
	- 如何评估你的 RAG？
	- 召回准确率？有无评估？
		- [RAG 青铜升级：知识库召回率优化实战攻略](https://zhuanlan.zhihu.com/p/1932099184925836374)
- #### 回答生成
    - prompt如何调优？
        - 设定工作流，设置 AI 回答思路，罗列为 TODO

RAG 相关八股收集

![60b310ac06f1bca6008b429e6f8fa178.jpg](https://www.blog.aeside.top/static/img/bf30831cf6b1c5175833c0d516a26be1.60b310ac06f1bca6008b429e6f8fa178.webp)
本文主要意在通过这道面试 SQL 题目讲解描述 MySQL 中索引的本质——索引B+树。所以文章通过拆解这个问题，一步步分析构建起来 MySQL 中的索引 B+ 树。



# 引言：索引的本质与B+树

在MySQL中，索引是数据库性能优化的核心手段。而索引的底层数据结构，决定了我们如何设计和使用它。MySQL默认的存储引擎InnoDB使用的是**B+树**作为索引的底层数据结构。

B+树是一种多路平衡搜索树，它在保持查询效率的同时，特别适合磁盘存储和范围查询。在B+树中，所有数据记录都存储在叶子节点，而非叶子节点只存储索引键值，这使得B+树具有良好的磁盘I/O效率。

在本文中，我们将通过一个具体的SQL查询问题，深入探讨B+树的原理，以及如何基于B+树特性设计最优索引。

# 问题拆解：索引设计的三个子问题
先来分析这个SQL查询：
```sql
SELECT * FROM table 
WHERE a = 1 AND b > 2 
ORDER BY c, d, f;
```

这个问题可以拆解为三个子问题：
1. a,b怎么建索引？
2. c,d,f怎么建索引？
3. (a,b) + (c,d,f)怎么建索引？

接着我们通过对这三个子问题分析解答，来回答我们的索引题。

# 问题一：a,b怎么建索引？B+树联合索引结构 & 最左匹配原则解析

在我们对`a,b`讨论如何建立索引时，其实问题就是在`(a, b)`和`(b, a)`之间进行讨论选择，所以我们的问题就是这两个索引究竟哪个更适合题目的要求？为什么适合？

## `(a, b)`和`(b, a)`怎么选？
在对两者进行讨论前，我们需要先建立起两者的索引，假设我们建立如下联合索引：
```sql
CREATE INDEX idx_ab ON table(a, b);
CREATE INDEX idx_ab ON table(b, a);
```

- #### B+树联合索引的结构（使用Graphviz描述）：
![file-20251020164337927.png](https://www.blog.aeside.top/static/img/c77d082fbde6bf7aec9113a1413a6106.file-20251020164337927.webp)
```dot
digraph BPlusTree {
    node [shape=plaintext];
    rankdir=TB;
    
    // 根节点
    root [label="Root\n(a=1, b>2)"];
    
    // 内部节点
    internal1 [label="Internal Node\n(a=1)"];
    internal2 [label="Internal Node\n(a=1, b=2)"];
    
    // 叶子节点
    leaf1 [label="Leaf Node\n(a=1, b=3)\nData: [row1, row2, ...]"];
    leaf2 [label="Leaf Node\n(a=1, b=4)\nData: [row3, row4, ...]"];
    leaf3 [label="Leaf Node\n(a=1, b=5)\nData: [row5, row6, ...]"];
    
    // 关系
    root -> internal1;
    internal1 -> leaf1;
    internal1 -> leaf2;
    internal1 -> leaf3;
}
```
> **B+树结构说明**：在叶子节点中，数据按`(a, b)`的顺序存储。当查询`a=1 AND b>2`时，数据库可以快速定位到`a=1`的叶子节点，然后在该节点内扫描`b>2`的数据。

### 为什么`(a, b)`比`(b, a)`更好？——B+树的局部有序性原理

本质上`(a, b)`和`(b, a)`两种索引并没有谁优于谁的说法，而且受限于我们使用索引的 SQL 语句决定性能优异的，在 `where a = 1 and b > 2` 中，两者的区别如下：

| 索引     | WHERE条件     | 效率  | 说明                          |
| ------ | ----------- | --- | --------------------------- |
| (a, b) | a=1 AND b>2 | 高   | a=1可以快速定位，b>2可以在a=1的范围内扫描   |
| (b, a) | a=1 AND b>2 | 低   | b>2可以快速定位，但a=1无法利用索引，必须回表过滤 |
## B+树的局部有序性原理

为什么会出现这种情况呢？这就需要引出 B+ 树**局部有序性**这个关键的概念了。

**对于这块内容，是本文的重中之重之重之重的重点！！！！！！由于篇幅过大，且还是较为独立的内容，因此我单独抽出文章详细梳理讲解。请转[你真的懂 B+ 树吗？你真的懂 MySQL 索引长什么样吗？](https://www.blog.aeside.top/post/24)详细阅读！**

# 问题二：c,d,f怎么建索引？举一反三

现在，我们考虑如何为`c,d,f`建立索引，以支持`ORDER BY c, d, f`。想要解决这个问题，我们需要深入了解**回表查询和文件排序**这两个概念，以及它们是如何影响数据库查询性能的。

### 覆盖索引：避免回表查询

首先，让我们探讨如何通过创建合适的索引来避免回表查询。假设我们的查询是：
```sql
SELECT c, d, f FROM table WHERE a = 1 AND b > 2 ORDER BY c, d, f;
```

:::info{title="索引分类"}
在 MySQL 中存在者多种索引，根据**是否聚簇数据分为主键索引和普通索引**。

主键索引，也是聚簇索引，**在 MySQL 的 B+ 索引树的叶节点，是直接存储具体的行数据**。在创建表时自动创建，组织表中的数据在 MySQL 数据库中存储，用于支持所有的数据查找，保证提供查找功能。

而普通索引，也就是非聚簇索引，在 MySQL 中就是我们平常**根据对应字段创建的索引**，用于辅助 SQL 语句查找，能对特定的 SQL 语句起到优化提速的效果。不同于主键索引，这些**普通索引的叶节点通常是存储一个指向数据具体位置的指针（MySQL 中通过存储主键ID实现指针效果）**，而这个通过指针获取真正数据的过程就是**回表查询**。
:::


然后在这个我们创建的普通索引 B+ 树中，节点存储的 Value 就是我们的字段值。**也就是说，在我们索引树中，存在者我们需要的字段值**。这样，我们就可以在通过主键 ID 到磁盘中获取一行的数据前，提前获取到对应字段的值。

而当我们创建一个包含所有这些字段的联合索引`(c, d, f)`，也就是**覆盖索引**。那么MySQL可以使用这个索引来满足查询中的`WHERE`条件和`SELECT`子句的需求，而无需访问数据表本身，也就实现避免回表查询。
- `a=1 AND b>2`可以直接利用索引来定位符合条件的记录。
- `SELECT c, d, f`所需的字段都包含在这个索引中，因此不需要再回到主表获取额外的数据。

### B+树索引与排序

在解决了回表查询的问题后，我们继续深入，探讨如何进一步优化查询性能——**避免文件排序（filesort）**。

我们知道，MySQL在执行`ORDER BY`时，如果无法利用索引的顺序，就会触发**filesort**机制：将结果集取出后，在内存或磁盘中进行排序。这不仅消耗CPU资源，还可能导致磁盘I/O，严重影响性能。

那么，如何让MySQL跳过filesort，直接“按序输出”呢？

#### 索引的有序性：排序的“天然加速器”

B+树索引天生是有序的。它的叶子节点通过双向链表连接，并按索引键的字典序排列。因此，**只要查询的排序顺序与索引的顺序一致，MySQL就可以直接利用索引的物理顺序返回数据，无需额外排序**。

#### 为什么`(c, d, f)`比`(f, d, c)`更好？

我们来对比两种索引设计：
- **`(c, d, f)`**：  
    索引的排序顺序是 `c → d → f`，与 `ORDER BY c, d, f` 完全一致。MySQL只需从索引的起始位置开始顺序扫描，即可获得有序结果，**避免filesort**。同时，由于`c,d,f`都在索引中，**也避免了回表**。
- **`(f, d, c)`**：  
    索引的排序顺序是 `f → d → c`，而查询要求按 `c, d, f` 排序。索引中`c`是最后一个字段，无法形成`c,d,f`的全局有序。MySQL必须先取出所有数据，再进行filesort，**无法利用索引排序**。即使字段都在索引中，仍需filesort。

#### B+树结构对比
下面用Graphviz展示`(c, d, f)`和`(f, d, c)`索引的B+树结构：
![4.png](https://www.blog.aeside.top/static/img/6f1202a5377e7dd732c09325be841f5a.4.webp)
```dot
digraph BPlusTree {
    node [shape=plaintext];
    rankdir=TB;
    
    // (c, d, f) 索引
    subgraph cluster_cdf {
        label="Index (c, d, f)";
        cdf_root [label="Root\n(c=1, d=1, f=1)"];
        cdf_internal [label="Internal Node\n(c=1, d=1)"];
        cdf_leaf1 [label="Leaf Node\n(c=1, d=1, f=1)\nData: [row1]"];
        cdf_leaf2 [label="Leaf Node\n(c=1, d=1, f=2)\nData: [row2]"];
        cdf_leaf3 [label="Leaf Node\n(c=1, d=2, f=1)\nData: [row3]"];
        
        cdf_root -> cdf_internal;
        cdf_internal -> cdf_leaf1;
        cdf_internal -> cdf_leaf2;
        cdf_internal -> cdf_leaf3;
    }
    
    // (f, d, c) 索引
    subgraph cluster_fdc {
        label="Index (f, d, c)";
        fdc_root [label="Root\n(f=1, d=1, c=1)"];
        fdc_internal [label="Internal Node\n(f=1, d=1)"];
        fdc_leaf1 [label="Leaf Node\n(f=1, d=1, c=1)\nData: [row1]"];
        fdc_leaf2 [label="Leaf Node\n(f=1, d=1, c=2)\nData: [row2]"];
        fdc_leaf3 [label="Leaf Node\n(f=1, d=2, c=1)\nData: [row3]"];
        
        fdc_root -> fdc_internal;
        fdc_internal -> fdc_leaf1;
        fdc_internal -> fdc_leaf2;
        fdc_internal -> fdc_leaf3;
    }
}
```

#### 为什么`(c, d, f)`可以避免filesort？

在`(c, d, f)`索引中，数据在叶子节点中严格按 `c → d → f` 的顺序排列。当执行 `ORDER BY c, d, f` 时，MySQL只需按链表顺序读取叶子节点，即可获得有序结果，**无需任何额外排序操作**。

而在`(f, d, c)`索引中，数据按 `f → d → c` 排列。例如：
- `(f=1, d=1, c=1)`
- `(f=1, d=1, c=2)`
- `(f=1, d=2, c=1)`

如果按 `c, d, f` 排序，`c=1` 的记录应该在 `c=2` 之前，但它们在索引中是分散的。MySQL无法通过一次顺序扫描获得有序结果，**必须进行filesort**。

> **重要提示**：在MySQL中，若要同时避免回表查询和文件排序，需确保：
> 1. 查询字段是索引的子集（覆盖索引）
> 2. `ORDER BY` 字段与索引的**最右前缀**一致  
>     这样，MySQL才能“一站式”完成查找、取值、排序，实现最优性能。

# 问题三：(a,c,d,f,b) 联合索引：索引下推与局部有序性
我们先回到需要优化的完整 SQL 查询：​
```sql
SELECT * FROM table ​
WHERE a = 1 AND b > 2 ​
ORDER BY c, d, f;​
```

结合前两部分的分析，这个查询暗藏着两个核心需求的冲突：
- 一方面要通过a=1和b>2实现高效的数据筛选
- 另一方面要通过c,d,f的排序避免 filesort

这两个需求对索引字段的顺序安排提出了矛盾的要求 —— 筛选需要将查询条件字段前置，而排序需要将排序字段保持连续有序。​

要化解这个矛盾，我们先从直觉出发设计两个候选联合索引：(a, b, c, d, f)和(a, c, d, f, b)。这两个方案都包含了所有关键字段，区别
仅在于是否用c,d,f将a和b隔开。要判断哪个方案更优，就必须深入理解 MySQL 的索引下推（ICP）特性，以及它如何与 B + 树的有序性原理结合发挥作用。​

### 索引下推，在`(a, b, c, d, f)`中
这里先明确索引下推的核心逻辑：这是 MySQL 5.6 引入的优化技术，能**将部分 WHERE 子句的过滤条件从服务层下推到存储引擎层执行**。这样一来，存储引擎在扫描索引时就能提前过滤掉无效数据，减少返回给服务层的数据量，从而避免不必要的回表操作。​

先看第一种设计`(a, b, c, d, f)`是否能满足需求。当 MySQL 使用这个索引时，确实能通过前缀`a=1`快速定位到目标数据区域，接着对`b>2`进行范围扫描。但问题恰恰出在范围扫描之后 —— 由于b是范围查询字段，根据 B + 树的有序性规则，`b`之后的`c,d,f`只能在每个`b`值的内部保持有序，跨`b`值时则完全打乱。​

我们通过实际的数据顺序示例就能看清这个问题：​
```text
(a=1, b=3, c=1, d=1, f=1)​
(a=1, b=3, c=1, d=1, f=2)​
(a=1, b=4, c=1, d=1, f=1) ← 跨b值后c,d,f重新开始排序​
(a=1, b=4, c=1, d=1, f=2)​
(a=1, b=5, c=1, d=2, f=1)​
```
​
**这种局部有序性无法满足`ORDER BY c, d, f`的全局排序需求，MySQL 不得不将所有符合`b>2`的记录取出后执行 filesort，这正是我们要避免的性能损耗**。​

### 索引下推，在`(a, c, d, f, b)`中

再看`(a, c, d, f, b)`为何能破解这个难题。同样从 B + 树的有序性入手，这个索引将`a`作为前缀，紧接着是连续的`c,d,f`，最后才是`b`。**当执行查询时，`a=1`的前缀定位依然高效，而`c,d,f`作为连续字段，在整个`a=1`的范围内保持了严格的全局有序性，这一点从数据顺序中清晰可见：​**
```text
(a=1, c=1, d=1, f=1, b=3)​
(a=1, c=1, d=1, f=1, b=4)​
(a=1, c=1, d=1, f=2, b=3)​
(a=1, c=1, d=1, f=2, b=4)​
(a=1, c=1, d=2, f=1, b=3)​
```

这种全局有序性完美匹配了 `ORDER BY c, d, f` 的需求，MySQL 只需按索引的自然顺序扫描即可获得有序结果，彻底避免了 filesort。​

**而对于 `b>2` 的筛选条件，此时就需要索引下推发挥作用**。虽然 `b` 位于索引末尾无法进行范围扫描，但存储引擎在扫描 `a=1` 范围内的 `c,d,f` 有序数据时，会同时检查每个叶子节点中的 `b` 值，直接过滤掉 `b≤2` 的记录。这个过滤过程在存储引擎层完成，意味着只有符合条件的记录才会被返回给服务层，大大减少了后续的回表操作数量。​

> **这里需要澄清一个常见误解：索引下推并非用于 "联合" 多个索引，而是让单个联合索引具备了同时处理筛选与排序的能力**。`(a, c, d, f, b)`的设计正是利用了这一点 —— 通过字段顺序的巧妙安排，既保证了排序所需的全局有序性，又借助 ICP 特性实现了高效的条件筛选，最终达成了查询性能的最优解。

### 题外话：反常识的 ICP 应用 ——(b,a) 索引的 “救赎”

在此之外，我们还得提一下用 `(b,a)` 索引执行 `a=1 AND b>2` 。这个看似 “不匹配” 的索引，恰恰能帮我们快速抓牢 ICP 的核心原理。​

当查询条件为 `a=1 AND b>2` 时，ICP（Index Condition Pushdown，索引下推）机制将发挥显著的优化作用：存储引擎利用 (b,a) 联合索引，优先扫描满足 `b>2` 的索引记录。然后，在扫描过程中，通过 ICP 将 `a=1` 的过滤条件下推至存储引擎层，同步检查索引项里的a值。​
- 仅当 `a=1` 时，才把主键（如 rowid）传给服务层，后续按需回表查询完整数据；​
- 对于 `a≠1` 的记录，直接在存储引擎层丢弃，避免无谓的数据传输与服务层处理开销。​

这一优化策略大幅减少了回表次数与服务层数据处理量，显著提升了查询性能。

总的来说，ICP 机制在 `(b,a)` 索引执行 `a=1 AND b>2`，就是依据他的宗旨：**将部分 WHERE 子句的过滤条件从服务层下推到存储引擎层执行**。

# 结语
燃尽了，从两点半写到十点还没写完，大概满打满算用了七八个小时写这篇文章。明线是按照解答这道 SQL 题目，暗线是按着串讲 MySQL 索引相关的内容，一篇串出来好多，写的时候也遇到自己理解不够透彻的内容，感觉自己讲不清楚，又去重新找资料问 AI 深入学习，也是我写 Blog 的初衷吧，用输出倒逼输入。

从美团索引题出发，一题深入浅出讲明白 MySQL 索引的一切！

## B+树的局部有序性原理

为什么会出现这种情况呢？这就需要引出 B+ 树的**全局有序性**和**局部有序性**这两个关键的概念了。

而想要理解这两个概念，首先我们要从 B+ 树本身的数据结构出发。什么是 B+ 树？



### B+ 树的数据结构
既然是 B+树，那么自然是和 B 树摆脱不了关系的，B+树作为 B 树的升级优化版，我们先了解 B 树才能更好深入地理解 B+ 树。

这里我们就简单地介绍一下 B 树和 B+树，更具体的就不在文章中展开来，但是两者的理解还是对理解 MySQL 索引很有帮助的。


:::info{title="什么是 B 树？"}
在计算机科学中，B 树（B-tree）是一种自平衡的树，能够保持数据有序。这种数据结构能够让查找数据、顺序访问、插入数据及删除的动作，都在对数时间内完成。

在 B 树中，有两种节点：
1. 内部节点（internal node）：存储了数据以及指向其子节点的指针。
2. 叶子节点（leaf node）：与内部节点不同的是，叶子节点只存储数据，并没有子节点。

树是一种数据结构。树用多个节点储存元素。某些节点存在一定的关系，用连线表示。二叉树是一种特殊的树，每个节点最多有两个子树。二叉树常用于实现二叉搜索树和二叉堆。 而 

[AVL 树](https://next.oi-wiki.org/ds/avl) 是特殊的二叉树，是最早被发明的自平衡二叉查找树。B 树保留了自平衡的特点，但 B 树的每个节点可以拥有两个以上的子节点，因此 B 树是一种多路搜索树。
:::

:::info{title="什么是 B+ 树？"}
[B+ 树](https://next.oi-wiki.org/ds/bplus-tree)是 [B 树](https://next.oi-wiki.org/ds/b-tree) 的一个升级，它比 B 树更适合实际应用中操作系统的文件索引和数据库索引。目前现代关系型数据库最广泛的支持索引结构就是 B+ 树。

1. 有  棵子树的节点中含有  个关键字（即每个关键字对应一棵子树）。
2. 所有叶子节点中包含了全部关键字的信息，及指向含这些关键字记录的指针，且叶子节点本身依关键字的大小自小而大顺序链接。
3. 所有的非叶子节点可以看成是索引部分，节点中仅含有其子树（根节点）中的最大（或最小）关键字。
4. 除根节点外，其他所有节点中所含关键字的个数最少有 （注意：B 树中除根以外的所有非叶子节点至少有  棵子树）。
:::

总而言之，最主要的关键点就是：
- B+ 树除了叶节点外，是不存储数据的
- B+ 树的叶节点是相互连接的，**且所有叶节点处于同一层树**

**本文就不展开来对这两点做过多详尽的讲解了，但是在后面的是内容是很关键的知识点，牢牢记住！**

### 链表上的树
现在，带着刚才提到的两点，我们来看一张 B+ 树的图

![file-20251020171559202.png](https://www.blog.aeside.top/static/img/227a571933af9835aacea59454b5f444.file-20251020171559202.webp)
首先，我们回顾“B+ 树除了叶节点外，是不存储数据的”这句话。这句话意味着，我们的数据都是存储在最下一层的叶节点，而且在 B+ 树中，叶节点之间都是有指针将各个叶节点连接起来的。

**而这，意味着我们可以将 B+ 树最底层的叶节点链表直接抽出来，直接访问这些数据。也就是说，没有上面父节点，这个叶节点链表仍然可以搜索寻找数据。**

那么，这些父节点究竟的作用是什么呢？很显然，像是一本厚厚的工具书一样，书本的知识内容都是写在章节中的文段，而不是在首页的目录上。**而这些父节点，不存储任何数据，正是 B+ 树中的目录，叶节点链表的目录，帮助我们加速查找**。当我们在 B+ 树上搜索数据时，从根节点出发依次进入下一层的父节点，就如同在工具书中，找目录中的一个个章节，然后再去找其中的小结。

### 局部性有序
**现在，我们来说说 B+ 树的有序性。**

在刚才的章节中，我们一直在强调 B+ 树的数据存储组织，而没有对其数据有序性进行讨论。前文**将 B+ 树分为一个叶节点链表和一个建立于这个链表之上的一个树目录**，我们一直在否认这个目录的作用。而在这里，当我们引入 **B+ 树中数据的有序性**时（毕竟 B+ 树是一个顺序查找树），这个目录的真正意义才会显现。

![file-20251020182659300.png](https://www.blog.aeside.top/static/img/92cc0ef794b712f6acc8c6c187a4a638.file-20251020182659300.webp)
回看 [B+ 树中的插入过程](https://next.oi-wiki.org/ds/bplus-tree#%E6%8F%92%E5%85%A5)，我们可以知道数据插入 B+ 树是通过比对树节点的大小来决定插入顺序的。那么这个过程发生多次之后构成的 B+ 树，我们是否可以认为是：**在叶节点链表之上的目录树，将链表切割为一个个有序的子链表**。**而这，也正是 B+ 树的局部性有序的由来。**

可能在只有一个索引的时候很难看出来局部性有序的特征，这里我们通过一个联合索引`(a, b)`来展示。
![btree.png](https://www.blog.aeside.top/static/img/60200b885face144265110896b7fef05.btree.webp)
- 在`a`相同的情况下，`b`是有序的
- 但不同`a`值之间的`b`值没有全局顺序

从上面的 B+ 树来看，**每一个叶节点中的 `b` 如果平铺成链表，并不是完全有序的。但是我们如果只局限于单个叶节点中，却又会发现 `b` 又是有序的**。**而这，就是 B+ 树的局部性有序性，也是其独特的插入方式和结构特征所导致的数据排序特征**。

同时，这也解释了为什么`(a, b)`索引可以高效处理`a = 1 AND b > 2`，而`(b, a)`索引效率低下。

> **关键理解**：B+树的有序性是按索引字段顺序局部有序的，不是全局的。

你真的懂 B+ 树吗？你真的懂 MySQL 索引长什么样吗？

# 什么是 RAG？
检索增强生成（RAG）作为一种结合信息检索与文本生成的技术，已成为解决大语言模型（LLM）"知识过时"和"幻觉输出"问题的关键方案。**RAG通过将外部知识库与LLM生成能力相结合，使模型能够基于真实、最新的信息输出答案，显著提升了生成内容的准确性和时效性**




### 更深层次的搜索——RAG

**核心思想：从给你链接到给你答案，一种从传统关键词搜索向下一代AI驱动的生成式搜索演进的完整构想。**

传统的搜索是你输入关键词、系统返回一个相关的文档列表、你需要自己去逐篇阅读、寻找答案。而这套新的**生成式搜索（Generative Search）流程、目标是直接理解你的问题、并通过阅读和总结相关文档、直接生成一个精准、连贯的答案**。这是典型的检索增强生成（RAG、Retrieval-Augmented Generation）架构。


# RAG 架构

>RAG系统的核心流程可概括为"先检索、后生成"，主要分为三个关键环节：索引构建、检索和生成。

## 索引构建
### 数据清洗
- **数据清洗**：RAG 依赖于准确且清洁的原始知识数据。**为了保证数据的准确性、需要优化文档读取器和多模态模型**。特别是处理如 CSV 表格等文件时，单纯的文本转换可能会丢失表格原有的结构
    - 因此我们需引入额外的机制以在文本中恢复表格结构
    - **比如使用分号或其他符号来区分数据**
    - **另一方面也需要对知识文档做一些基本数据清洗其中包括：**
        - 基本文本清理：规范文本格式、去除特殊字符和不相关信息。除重复文档或冗余信息
        - 实体解析：消除实体和术语的歧义以实现一致的引用。例如、将LLM、大语言模型和大模型标准化为通用术语
        - **文档划分**：合理地划分不同主题的文档、不同主题是集中在一处还是分散在多处？如果作为人类都不能轻松地判断出需要查阅哪个文档才能来回答常见的提问、那么检索系统也无法做到
        - **数据增强：**使用同义词、释义甚至其他语言的翻译来增加语料库的多样性
        - **用户反馈循环**：基于现实世界用户的反馈不断更新数据库、标记它们的真实性
        - **时间敏感数据：**对于经常更新的主题、实施一种机制来使过时的文档失效或更新

### 分块处理
在 RAG 系统中、**文档需要被分割成多个文本块后再进行向量嵌入**

> #### 什么是chunk？
> - **chunk** 就是把一份长文档分割成多个 **较小的文本片段** `(text chunks)`
> - 每个 chunk 作为一个独立的检索单元，被编码成向量。
> - 当用户发起查询时、RAG 系统会在向量库里查找与 query 最相关的 chunk、把这些 chunk 作为上下文传递给大模型。
> 
> **Chunk = 文本块**。在 RAG 中、把文档切成 chunk、再做 embedding、可以提升检索精度、减少冗余、是业界常用的做法

#### **为什么要切分文档？**

- **避免嵌入超长文本**
    - 向量模型通常对输入文本长度有限制（比如 512 或 1024 tokens）。
    - 如果直接拿整篇文档做 embedding、容易截断信息、效果差。
- **提高检索精度**
    - 把文档切分后、检索更细粒度。
    - 用户 query 更容易命中具体片段、而不是整篇文章。
- **减少上下文冗余**
    - `chunk` 更小、可以只把最相关的几个 chunk 提供给大模型、节省 `prompt` 长度

不考虑大模型输入长度限制和成本问题的情况下、其目的是**在保持语义上的连贯性的同时、尽可能减少嵌入内容中的噪声、从而更有效地找到与用户查询最相关的文档部分**。
- **如果分块太大**、可能包含太多不相关的信息、从而降低了检索的准确性。
- **分块太小**可能会丢失必要的上下文信息、导致生成的回应缺乏连贯性或深度。

在 RAG 系统中实施合适的文档分块策略，旨在找到这种平衡、确保信息的完整性和相关性。一般来说、理想的文本块应当在没有周围上下文的情况下对人类来说仍然有意义、这样对语言模型来说也是有意义的。

#### 常见的切分方式
- **固定大小的分块**：最简单和直接的方法、直接设定块中的字数、并选择块之间是否重复内容。通常我们会保持块之间的一些重叠、以确保语义上下文不会在块之间丢失。与其他形式的分块相比、固定大小分块简单易用且不需要很多计算资源。

- **带重叠切分（sliding window / overlap）**
	- 每个 chunk 之间保留部分重叠内容、避免语义被截断。
	- 例如：200 tokens 长度、每次滑动 150 tokens（50 overlap）

- **特殊结构的分块**：针对特定结构的文档的专门分块器。这些分块器专门设计来处理这些类型的文档、以确保正确地保留和理解其结构。**`langchain`** 提供的特殊分块器包括：Markdown 文件、LaTeX 文件、以及各种主流代码语言分块器

- **递归分块**：在大多数情况下推荐的方法、通过重复地应用分块规则来递归地分解文本。例如在 `langchain` 中会先通过段落换行符（\n\n）进行分割、然后检查这些块的大小。如果块大小不超过一定阈值、则该块被保留。对于大小超过标准的块、使用单换行符（\n）再次分割。这种方法可以灵活地调整块的大小。例如、对于文本中的密集信息部分、可能需要更细的分割来捕捉细节、而对于信息较少的部分、则可以使用更大的块。它的挑战在于、**需要制定精细的规则来决定何时和如何分割文本**。

- **从小到大分块**：既然小的分块和大的分块各有优势、一种更为直接的解决方案是将同一文档从大到小所有尺寸的分块、然后将不同大小的块全部存储在数据库中、并保存每个分块的上下级关系、进行递归搜索。因为我们需要存储大量重复的内容、这种方案的缺点是需要更大的存储空间。

- **按语义切分**
    - 按段落、句子、标题层级（markdown / HTML tag）来切分。
    - 更贴近语义、减少断句问题、但实现复杂

> #### 分块大小的选择
> 首先不同的嵌入模型有其最佳输入大小、例如 OpenAI 的 `text-embedding-ada-002` 模型在 256 或 512 大小的块上表现更好。其次文档的类型和用户查询的长度及复杂性也是决定分块大小的重要因素。处理长篇文章或书籍时、较大的分块有助于保留更多的上下文和主题连贯性、而对于社交媒体帖子、较小的分块可能更合适捕捉每个帖子的精确语义。如果用户的查询通常是简短和具体的、较小的分块可能更为合适。相反如果查询较为复杂、可能需要更大的分块


---
## 检索流程深度解析

### 流程架构

#### 第1步：Query (用户查询)
- **传统**: 用户习惯于输入**关键词**、例如`基金 分红 REITs`
- **现在 (TBD流程)**: 系统鼓励用户输入**完整的自然语言问题、**例如`今年以来基金分红有什么特点？REITs在其中扮演了什么角色？`这种输入的转变、要求后台具备更强大的语言理解能力。

#### 第2步：Query 解析 (查询解析)
这是整个流程中技术含量最高、最关键的一步、它远不止是简单的分词。

- **传统**: 对`基金 分红`进行分词、变成`基金`和`分红`两个词`（传统用ES和MongoDB）`
- **现在 (TBD流程)**: 这一步需要一个复杂的自然语言理解（NLU）模块来完成多项任务：
    - **意图识别 (Intent Recognition)**: 分析用户的真实意图。用户是想找一篇具体的文章？还是需要一个总结性的答案？或是想进行数据对比？
    - **实体提取 (Entity Extraction)**: 识别出查询中的关键信息、如`基金`、`分红`、`REITs`、`今年以来`（时间状语）等。
    - **查询改写/扩展 (Query Rewriting/Expansion)**: 将一个复杂问题、拆解成多个适合送入底层搜索引擎（Elasticsearch）的、结构化的子查询。例如将原始问题拆解为：
        - `search(keywords="基金分红、 time_range="2025-01-01 to now")`
        - `search(keywords="REITs 分红 特点")`
        - `search(keywords="债券基金 分红 比例")`
        - 这个过程极大地提升了后续召回文档的精准度

#### 第3步：召回文档 (文档召回 )
- **动作**: 将第二步生成的多个结构化子查询、发送到**Elasticsearch**的`item_feature`索引中，执行检索。
- **目标**: 这一步的**核心目标不是直接找到答案、**而是尽可能全面、精准地**找到所有能用来回答用户问题的原始材料或证据**
- **产出**: 一个根据相关性排序的、包含Top-K（比如Top 10）篇最相关文章的列表。这些文章将作为下一步生成总结的上下文。

#### 第4步：生成总结 (答案生成 - AI的综合与创作)
- **动作**: 将第三步召回的Top-K篇文章的**全文或摘要**、**连同用户的**原始Query、**一起打包发送给一个大语言模型（LLM）
	- 例如系统中的通用能力服务
- **实现**:
    - **构建Prompt**: 设计一个精巧的提示词（Prompt）、指令LLM扮演一个专家的角色、并要求它
    - ：“请基于以下\[K篇参考文章]、用简洁、连贯的语言、回答这个问题：\[用户的原始Query]
    - 请确保你的回答内容完全来自于提供的参考文章、并在关键信息后标注来源
    - **AI生成**: LLM阅读并理解这K篇文章、然后像一个研究员一样、从中提炼关键信息、重新组织语言、生成一个直接、精准、且通常是多段落的总结性答案
- **产出**: 一段高质量的、直接回答用户问题的文本


#### 补充：反馈循环 (Feedback Loop)
图中从生成总结指回Query解析的**反馈**、是流程**最先进、最智能**的部分

它代表了一种**多轮、迭代**的搜索思想
- 它解决了什么问题？
- 有时候、第一轮召回的文档可能不足以完美地回答用户的问题
- 比如用户问AI对经济的宏观和微观影响、第一轮召回的文章可能大多是关于宏观影响的。

- **它如何工作？**
    1. 系统生成第一版总结后、可以进行一次**自我评估**。它发现总结中缺少微观影响的部分。
    2. 基于这个发现，系统**自动生成一个新的、更具体的查询**、例如`AI对中小企业生产效率的影响`（这就是一次Query改写）。
    3. 用这个新查询**再次执行第3步和第4步**、获得关于微观影响的补充材料和总结。
    4. 最后、将两轮的总结**合并**成一个更全面、更完美的最终答案。
- **价值**: 这个反馈循环、让搜索从一次性的请求-响应模式、进化成了一个能够像人类一样**思考、反思、并进行多步推理**的**AI代理（AI Agent）**

### RAG 推理流程分类

在我们平常的 RAG 中通常是简单地基于上述的一条链路来回答用户的问题的，有时候第一轮召回的文档可能不足以完美地回答用户的问题。基于前面提到过的反馈环节，在 UltraRAG 中提出了 RAG Pipeline 方式编排推理流程来实现反馈环节。

>[!summary] 什么是 Pipeline？
>在 UR-2.0 中，Pipeline 是你定义“推理任务如何执行”的流程脚本。它像一个“任务计划表”或“工作流蓝图”，用来明确告诉系统每一步该做什么、怎么做、做完后怎么走下一步。你可以通过 Pipeline 组合不同模块（Server）中的功能（Tool），构建出一个完整、可复现、可控制的 RAG 推理流程。例如：
> - 加载数据 → 检索文档 → 构造 prompt → 调用大模型 → 评估结果；
> - 或者在多轮生成中，根据模型中间的表现决定是否重新检索或停止生成。
> Pipeline 的核心作用是：让复杂的 RAG 流程结构清晰、灵活、模块化，并通过 YAML 配置实现零代码编排。


在 UR-2.0 中，Pipeline 是你定义“推理任务如何执行”的流程脚本。它像一个“任务计划表”或“工作流蓝图”，用来明确告诉系统每一步该做什么、怎么做、做完后怎么走下一步。你可以通过 Pipeline 组合不同模块（Server）中的功能（Tool），构建出一个完整、可复现、可控制的 RAG 推理流程。例如：

- 加载数据 → 检索文档 → 构造 prompt → 调用大模型 → 评估结果；
- 或者在多轮生成中，根据模型中间的表现决定是否重新检索或停止生成。

Pipeline 的核心作用是：让复杂的 RAG 流程结构清晰、灵活、模块化，并通过 YAML 配置实现零代码编排。

#### 串型结构
串行结构是 UltraRAG Pipeline 中最基本、最常见的执行方式。多个步骤按顺序依次执行，前一步的输出（若有）可以作为下一步的输入，也可以独立执行。构建一个基础的 RAG 工作流通常只需使用串行结构即可完成。
#### 循环型结构
在一些多轮推理、多跳问答、多轮检索等任务中，单次执行流程往往不足以获得最终答案。此时就需要使用 循环结构（loop），以重复执行某些模块，逐步迭代信息、强化生成结果。
#### 分支型结构
在复杂的推理任务中，我们常常需要根据模型当前的输出或中间状态决定流程是否继续。例如：
- 如果模型生成的是查询，就进行下一轮检索；
- 如果模型已经生成了最终答案，就结束流程。

为实现上述能力，UR-2.0 提供了 分支结构（branch），用于构建具备 条件跳转逻辑 的动态推理流程。

# 我们在 RAG 中现在要解决什么问题？
## 构建更准确、细化的索引
- 数据清洗
- 文档分块处理
- 元数据增强
- 调用 MCP 与数据源交互；使用工具获取更多信息，如联网搜索

## 更高的文档召回准确旅率
- 调参，TopK、评分比例。根据 RAG 知识库应用领域不同，在准确性和广度上进行取舍

## 更好的回答生成优化
- 优化prompt（太玄学，不会）
	- 设定角色，科研型，文学型，专业型

五分钟读懂 RAG 架构，但你离用好它还差十公里

MCP、RAG、Agent三者虽然是紧密相连，但是是三个不同的概念。同样虽然是三个不同的概念，但是他们之间的关系却紧密相连（~~废话~~）。本文主要意在对这三个 AI 领域的概念进行简单是扫盲。



# RAG
>概要：
>RAG，全称为**检索增强生成**。顾名思义就是通过检索更多知识文档的内容，依据这些信息提供更准确的回答生成，弥补LLM基于训练模型的信息过时和幻觉问题。

检索增强生成（RAG）作为一种结合信息检索与文本生成的技术，已成为解决大语言模型（LLM）"**知识过时**"和"**幻觉输出**"问题的关键方案。**RAG通过将外部知识库与LLM生成能力相结合，使模型能够基于真实、最新的信息输出答案，显著提升了生成内容的准确性和时效性**。

# MCP
>概要：
>MCP（模型上下文协议），主要是由 Function Calling 演变而来，通过协议规范 AI 去调用 Tools ，避免不同厂商、三方提供的 Tools 服务由于交互模式不同影响使用。类似 Java 中的接口。

而在 RAG 检索知识库文档的过程，为了更好地检索相关的文档，甚至是 MySQL 这类结构化的数据时。我们就可以引入 MCP （模型上下文协议）来提供更多的拓展数据源服务。

MCP 的一个经典案例就是联网搜索，让 LLM 能够调用互联网搜索工具来搜索网络文档，对用户的问题进行 RAG 回答。在这里 MCP 是作为一种协议，为 LLM 提供调用 Tools 的能力来更好处理问题，也可以提供全新的功能，比如智能下单这类操作。只要你的服务符合 MCP 协议，就能让 AI 调用你的服务，拓展 LLM 除了进行对话回答外的功能。

# Agent
>概要：
>一种通过感知环境信息、自主分析判断并执行操作以完成预设任务目标的自主 AI 系统。

然后，基于 RAG 和 MCP 的加持，我们就可以尝试去构建一个工作流，基于 **“感知——推理——行动”** 三大模块，搭建一个具有**自主性、反应性和社会性**的 AI 智能体。

- 在一个完整的 AI 系统中，这些元素协同工作，实现高效、智能的任务处理：![file-20251013164828571.png](https://www.blog.aeside.top/static/img/bd2f6b42aeb9ad421f43a850313348df.file-20251013164828571.webp)
	- Agent 通过 MCP 与外部系统建立连接：Agent 利用 MCP 提供的标准化接口，与外部数据源和工具进行交互。
	- Agent 使用 RAG 检索并整合相关知识：Agent 通过 RAG 访问知识库，检索与任务相关的事实信息，为决策提供支持。
	- 系统结合决策能力和事实信息处理复杂任务：Agent 将检索到的知识与自身的决策能力
	- 相结合，处理复杂的任务，生成准确、可靠的回应。
	- 这种整合方法创造出比任何单一组件都更强大、更可靠、更适应性强的 AI 系统，能够理解上下文，检索相关信息，并采取适当行动完成任务。


如此一来，我们便可以用原先只能进行对话回答的 LLM，通过 RAG + MCP 技术让 LLM 能够解决更复杂的问题和更完善地解决问题。