RAG 相关的知识名词

Chunk（分块）

是什么：

把长文档切一小段一小段，再做向量化存储。

为什么需要它

  • LLM 的上下文限制
  • 检索时需要“精准命中片段”而不是一整片文章

例如：

一篇10000字的文章 -> 切成：

  • 每300~500一个片段
  • 或按段落/语义切分

关键点：

  • chunk 太大 -> 检索不准确
  • chunk 太小 -> 语义不完整

分块策略：

1.固定长度分块

方式：

  • 按照 token/字符数切，比如：
    • 512 tokens
    • 1000 tokens

适用场景：

  • 通用文本（文档、网页、FAQ）
  • 没有结构的内容

优点：

  • 简单、稳定、易调参
  • 向量库兼容性最好

缺点：

  • 容易断章取义

推荐 overlap：

  • 10% ~ 20%

2.按句子分块

方式：

  • 用 NLP 分句（句号、标点）
  • 多句子拼成一个 chunk （控制 token 长度）

适用场景：

  • 文章、博客、说明书
  • 对语义完整性要求高

优点：

  • 语义更完整

缺点：

  • chunk 的 token 长度不均匀
  • 需要额外的分句工具

推荐 overlap：

  • 0 ~ 10%
    • 有时甚至不需要（句子已经是最小语义单元了）

3.按段落分块

方式：

  • 按自然段（\n\n）切
  • 如果段落过大，二次切分

适用场景：

  • Markdown / 文档 / PDF解析后文本
  • 知识库类文本

优点：

  • 保留上下文结构
  • 可读性强

缺点：

  • 段落长度不稳定

推荐 overlap：

  • 0 ~ 10%

4.语义分块

方式：

  • 使用 embedding 判断语义变化点
  • 在“语义断点”切分

常见做法：

cosine similarity 阈值 sliding window + embedding

适用场景：

  • 高质量知识库
  • 长文档（法律、技术文档、论文）

优点：

  • chunk 语义高度一致
  • 检索准确率高

缺点：

  • 成本高（需 embedding 额外处理）
  • 实现复杂

推荐 overlap：

  • 0 ~ 10%
    • overlap 的作用被“语义切分”替代了

5.递归分块

方式：

按优先级切分：

text
段落 → 句子 → 词 → 字符

直到满足 chunk size

适用场景：

  • 通用RAG（推荐的默认方案）
  • 不确定数据结构时

优点：

  • 自动平衡“语义 + 长度”
  • 很稳定

缺点：

  • 可控性稍差

推荐 overlap：

  • 10% ~ 20%

6.滑动窗口分块 【高 recall 场景】

方式：

  • 固定长度，但窗口滑动
text
chunk1: 0-500
chunk2: 250-750
chunk3: 500-1000

适用场景：

  • QA 系统（避免漏召回）
  • 法律、合同分析

优点：

  • recall 极高
  • 几乎不会漏消息

缺点：

  • 数据量膨胀（2 ~ 3倍）
  • 检索成本高

推荐 overlap：

  • 30% ~ 50%

用空间换 recall，适合高精度系统

overlap（重叠）

简单说：

就是每个 chunk 之间重复的一部分内容，避免信息被切断。

举个🌰：

原文：

text
A:小明喜欢迟到
B:他也喜欢早退
C:尤其是在上班的时候

没有 overlap：

chunk1：

text
小明喜欢迟到

chunk2：

text
他也喜欢早退

问题：

  • “他”是指谁？（上下文断开了）

有 overlap：

chunk1：

text
小明喜欢迟到
他也喜欢早退

chunk2：

text
他也喜欢早退
尤其是在上班的时候

这样上下文就连上了

overlap 太大 or 太小会怎样？

太小（甚至0）

  • 上下文断裂
  • 检索质量下降

太大

  • 数据重复严重
  • 向量库变大
  • 成本上升

什么是 recall（召回率）

recall（召回率），简单来说：

该找到的内容，找到了多少

定义：

[ Recall = \frac{检索到的相关文档数量}{所有相关文档数量} ]

在 RAG 的流程中：

  1. 用户提问
  2. 系统去向量库检索 chunk
  3. 把检索到的内容喂给大模型生成答案

其中 recall 关注的就是第 2 步：

所有有用的 chunk 检索出来了多少？

recall 和 precision

指标含义
recall找全（不漏）
precision找准（不乱）

对比：

高 recall

  • 返回 20 条
  • 相关的 5 条全在里面
    • recall 高
    • 但有很多垃圾

高 precision

  • 返回 3 条
  • 都是相关的
    • precision 高
    • 但是漏了 2 条

在 RAG 中 recall 优先级更高

“没召回 = 没答出来” “召回多一点 → 模型还能自己筛”

ACL（Access Control List， 访问控制）

是什么：

控制“谁能看到那些数据”的权限系统

在 RAG 中的作用：

防止“数据越权索引”

比如：

  • A 用户只能查看自己公司文档
  • B 用户不能查看 HR 资料

实现方式：

  • 每一个 chunk 都带有 metadata （比如 user_id / org_id）
  • 检索时加上过滤条件
json
{
  "text": "员工工资数据。。。",
  "org_id": "company_A"
}

检索时：

sql
WHERE org_id = current_user.org_id;

Reranker (重排序器)

是什么：

对检索出来的结果再做一次更精细的排序。

为什么需要 Reranker？

RAG流程通常是：

  1. 向量检索（快但不够准）
  2. reranker（慢但更准）
  3. 在给到 LLM

举个🌰：

提问：

“合同违约责任怎么界定？”

向量检索可能返回：

  1. 合同法总则（相关但泛）
  2. 违约责任条款（最相关）
  3. 民法基础定义（弱相关）

reranker 会重新排序为：

  1. 违约责任条款
  2. 合同法总则
  3. 民法基础定义

常见的模型有：

  • Cross-Encoder（最常见）
  • BGE-reranker
  • Cohere Rerank

Tips:

reranker 可以让 “高 recall → 高 precision”

把上述三个名词串起来

text
原始文档
↓
Chunk（切块）
↓
Embedding（向量化）
↓
向量数据库（带ACL metadata）
↓
检索（Top-K）
↓
Reranker（重排序）
↓
LLM生成答案