RAG 入门到严谨：如何把问题/答案切片并存入向量数据库，以及“语义相似”如何度量

目标：用工程可落地的视角讲清楚三件事：

1. RAG（Retrieval-Augmented Generation）是什么
2. 如何把问题/答案切片（chunking）并写入向量数据库
3. 向量数据（embedding）是什么，以及“语义相似”如何严谨度量（含余弦相似度）

---

1. RAG 是什么：带检索的“开卷回答”

RAG 的核心思想：先检索证据，再让大模型基于证据生成答案。

典型流程：

1. 用户提出问题 q
2. 系统将 q 向量化得到查询向量
3. 去向量数据库检索最相关的若干段内容（Top-K chunks）
4. 把检索到的内容作为“证据上下文”连同问题一起喂给 LLM
5. LLM 生成最终回答，并可附引用来源

---

2. 用 4 种难度梯度递增理解 RAG + 切片入库

2.1 最简单：把文档切成“知识卡片”，用语义找卡片

• 文档太长，不能整本塞给模型，所以要切成很多小段（chunk）
• 每段小文本都变成一串数字（向量），存到向量数据库
• 用户提问也变成向量，数据库找“最接近”的向量，把对应原文拿出来给模型

---

2.2 实操版：问题/答案（FAQ）如何切片并入库（可照做）

以“FAQ（问题-答案）”为例，一条知识通常包含：

• question: 原始问题
• answer: 标准答案
• source: 来源（文档名/链接/系统）
• tags: 业务标签（产品线、地区、版本）
• updated_at: 更新时间或版本号
• acl: 权限控制（可选，但企业强烈建议）

A) 两种常用切片策略

策略 1：以“答案”为主切片（推荐）

• 检索主要需要答案里的事实、步骤、条款
• 做法：对 answer 按段落/标题/长度切成多个 chunk
• 每个 chunk 携带同一条 question 作为元数据（metadata）

策略 2：QA 拼接后再切片（适合短 FAQ）

• 将 Q: ...\nA: ... 拼成一段文本后再切片
• 优点：命中时上下文完整；缺点：答案很长时问题信息可能被稀释

B) 入库对象长什么样（核心结构）

向量数据库里通常存三件事：

1. text：chunk 原文（用于回填给 LLM）
2. embedding：chunk 的向量（用于相似度检索）
3. metadata：结构化字段（过滤、溯源、权限、版本）

示例（概念结构）：

{
  "id": "chunk_000123",
  "text": "……（答案中的一小段）……",
  "embedding": [0.012, -0.98, "..."],
  "metadata": {
    "question": "如何重置密码？",
    "source": "help_center_v3.md",
    "tags": ["account", "security"],
    "updated_at": "2026-01-01",
    "doc_id": "doc_77",
    "chunk_index": 3,
    "acl": ["support_team", "admin"]
  }
}

C) 查询时如何用（端到端）

1. 用户问题 q → 生成 embedding(q)
2. 向量库检索 Top-K（可结合 metadata filter）
3. 取回 Top-K chunks 的原文 text
4. 组合成提示词：[用户问题] + [证据chunks] → 喂给 LLM
5. 得到最终答案（可返回引用 chunk_id/source）

---

2.3 进阶版：切片大小、召回质量与工程组合拳

1) chunk 切多大更合适？

经验区间（非硬规则）：

• 200–500 tokens：步骤型、FAQ、制度条款
• 500–1000 tokens：叙述型说明、技术文档

并配合 overlap（重叠），避免语义断裂：

• overlap 一般 10%–20%

2) QA 数据入库建模三种形态

• A：只向量化答案 chunk（主流）
  检索到的是可直接作为证据的内容；问题作为 metadata 便于展示与调试。

• B：问题也向量化（提升多问法匹配）
  同一答案对应多问法时，可存多条问题向量或单独建“问题索引”。

• C：合成检索单元（Q + 摘要 + A chunk）
  有助于减少“命中但不回答”的情况，但 text 更长也可能引入噪声，需要更强 rerank。

3) 召回质量常用组合拳（推荐优先级从高到低）

• Metadata Filter：先按版本/地区/权限过滤，再做向量检索（避免越权与误召回）
• Hybrid Search：向量相似度 + 关键词 BM25 混合召回
• Reranker：先粗召回 Top-50，再用 rerank 模型重排到 Top-5

---

2.4 严谨版：形式化定义（embedding、检索、相似度）

给定文本片段（chunk）x，embedding 模型是映射：

$$f:x\to \mathbf{v}\in {\mathbb{R}}^d$$

对文档 $D$，切片函数 $g$ 得到 chunk 集合：

g(D)={c1,c2,…,cn} g(D) = \{c_1, c_2, \ldots, c_n\} g(D)={c1​,c2​,…,cn​}

每个 chunk 向量化：

$${\mathbf{v}}_i=f(c_i)$$

向量库保存集合：

$$\{({\mathbf{v}}_i,c_i,m_i){\}}_{i=1}^n$$

其中 $m_i$ 是元数据（来源、权限、版本、页码等）。

RAG 生成可以描述为：在检索到的证据 $C$ 条件下，生成答案 $a$：

$$a\sim P(\cdot \mid q,C)$$

---

3. 向量数据是什么：embedding 的直观解释与工程含义

3.1 直觉

• 一段文本会被编码成一串浮点数（向量）
• 语义相近的文本向量更“接近”
• 检索时通过“距离/相似度”找到最接近的证据段落

3.2 工程含义

• 向量维度 $d$ 通常在几百到几千（如 768、1024、1536、3072 等，取决于 embedding 模型）
• 向量本身不可读，需要与原始 text 绑定
• 需要配合：
  • 索引结构（ANN）保证速度
  • metadata 过滤保证合规与可控
  • 可观测性日志保证可调优

---

4. “语义相似”如何度量：sim 的严谨定义与余弦相似度

你提出的关键点是：“sim 为什么就是余弦相似度？”需要更严谨的定义。

结论：

• sim 是“相似度函数”的符号占位（similarity function）
• 余弦相似度只是 sim 的一种常用选型

4.1 先定义 sim：相似度函数占位符

给定查询向量 $\mathbf{u}$ 与候选向量 $\mathbf{v}$，定义：

$$\mathrm{sim}:{\mathbb{R}}^d\times {\mathbb{R}}^d\to \mathbb{R}$$

检索目标：

$$\arg \underset{{\mathbf{v}}_i\in \mathcal{V}}{\max }\mathrm{sim}(\mathbf{u},{\mathbf{v}}_i)$$

4.2 若选择余弦相似度作为 sim

则：

$$\mathrm{sim}(\mathbf{u},\mathbf{v})=\cos (\mathbf{u},\mathbf{v})=\frac{\mathbf{u}\cdot \mathbf{v}}{\Vert \mathbf{u}\Vert \Vert \mathbf{v}\Vert }$$

解释：

• 余弦相似度本质是夹角 $\theta$ 的余弦：$\cos \theta$
• 它衡量方向相近程度，对尺度（向量长度）相对不敏感

4.3 为什么余弦相似度常用：尺度不变性

如果将向量缩放（乘正数），余弦相似度不变。
这对文本 embedding 很重要，因为许多 embedding 的“模长”并不稳定表示语义强弱，而方向更稳定表达语义。

4.4 相似度最大化 vs 距离最小化（工程常见差异）

一些系统使用“距离（distance）”而不是“相似度（similarity）”。

• 余弦距离常定义为：

$$d_{\cos }(\mathbf{u},\mathbf{v})=1-\cos (\mathbf{u},\mathbf{v})$$

此时检索写作：

$$\arg \underset{{\mathbf{v}}_i}{\min }{d}_{\cos }(\mathbf{u},{\mathbf{v}}_i)$$

两者等价，只是优化方向不同：

• similarity：越大越好
• distance：越小越好

4.5 关键等价关系：L2 归一化后，点积 = 余弦相似度

若向量做了 L2 归一化，使得 $\Vert \mathbf{u}\Vert =\Vert \mathbf{v}\Vert =1$，则：

$$\mathbf{u}\cdot \mathbf{v}=\cos (\mathbf{u},\mathbf{v})$$

因此很多系统会：

• 输出已归一化 embedding，或在入库/查询时归一化
• 用内积（dot product / inner product）实现余弦相似检索

---

5. 端到端流程图（Mermaid / Markdown 兼容）

---

6. 一个可直接落地的 MVP 建议（默认：可审计 + 可控 + 可优化）

如果你现在要做一个稳健 MVP（适用于 FAQ / 长文档）：

1. 切片：按标题/自然段切；目标 400–800 tokens；overlap 15%
2. 入库对象：以答案/正文 chunk 为核心 text；question 放 metadata；必要时问题也单独向量化
3. 检索：Top-20 粗召回 + rerank 到 Top-5（或 Top-8）
4. 过滤：先按 doc_version / jurisdiction / client_id / acl 做 metadata filter
5. 可观测性：记录 query → 命中chunk → prompt → 输出，用来持续调优切片与检索策略

---

7. 小结

• RAG 的关键在于：检索证据 + 证据约束生成
• 向量数据库存的不是“答案”，而是：chunk 的向量（用于检索）+ 原文（用于回填）+ 元数据（用于控制与溯源）
• “语义相似”需要先定义 sim（相似度函数）；余弦相似度只是其中常用的一种选型
• 工程上常见：归一化后用内积实现余弦相似度检索