Embedding、Chunk、Vector DB、Retriever、Reranker 与 RAG

如果把知识库问答这条线说得最简单一点，它看起来好像只是：

1. 把资料放进去
2. 用户提问题
3. 模型给答案

但项目里真正跑起来之后，事情远没有这么简单。

因为模型能不能答好，很多时候并不取决于“模型够不够强”，而取决于：

1. 文档切得对不对
2. 资料能不能被找回来
3. 找回来的内容排得准不准
4. 最后拼给模型的上下文是不是干净、有用

这一页就顺着这条完整知识增强主线，把 Chunk、Embedding、Vector DB、Retriever、Reranker 和 RAG 放回同一条链路里讲清楚。

1. 看整条主线

flowchart TD
    A[原始文档] --> B[清洗]
    B --> C[Chunk 切分]
    C --> D[Embedding 向量化]
    D --> E[写入 Vector DB]

    F[用户问题] --> G[问题向量化]
    G --> H[Retriever 召回]
    H --> I[Reranker 重排]
    I --> J[拼接上下文]
    J --> K[RAG 生成答案]

这条线可以拆成两段来看：

1. 入库阶段：文档怎么变成可检索资料
2. 问答阶段：用户问题怎么从资料里找到真正有用的内容，再交给模型回答

只要其中某一段做得不稳，最后回答质量就很容易出问题。

2. Chunk 是什么

Chunk 可以理解成“切分后的文档片段”。

这一步看起来很基础，但在知识库系统里，它通常是第一刀。

2.1 为什么一定要切分

原始文档通常不能整篇直接拿去检索，原因很现实：

1. 太长
2. 噪音太多
3. 粒度太粗
4. 一次命中后很难定位真正有用的段落

所以常见做法是把文档切成更小的片段，再让后面的检索链路围绕这些片段工作。

2.2 Chunk 主要解决什么问题

它解决的核心问题其实是：

怎么把原始知识切成既能检索、又能被模型消费的粒度。

如果切得太大：

1. 无关信息太多
2. 上下文容易被浪费
3. 召回命中后仍然很难聚焦重点

如果切得太碎：

1. 语义可能断裂
2. 上下文丢失
3. 最后拼回模型时会很零散

2.3 Chunk 最常见的场景

它几乎会出现在所有知识库入库场景里，例如：

1. 产品文档
2. 内部规范
3. FAQ
4. 技术手册
5. 合同、制度、说明文档

只要资料不是天然短小、结构明确，就几乎一定要切分。

2.4 Chunk 最容易踩的坑

最常见的问题有：

1. 切得太大
2. 切得太碎
3. 只按字数切，不看语义边界
4. 不保留标题、章节、来源等元数据

🌟 很多知识库效果问题，第一刀往往不是模型，而是 Chunk 切得对不对。

3. Embedding 是什么

Embedding 可以理解成：

把一段文本映射成向量，让语义相近的内容在空间里更接近。

这一步的价值在于，它把“语义相关”这件事从人类语言里的模糊概念，变成了一种可计算的表示。

3.1 Embedding 主要解决什么问题

它解决的是：

怎么让系统不仅能按关键词匹配，还能按语义相近去找内容。

这件事很重要，因为用户问题和文档原文往往不会一字不差地对上。

例如：

1. 用户说“退款多久能到账”
2. 文档里写的是“退款完成后的资金返回周期”

如果只靠关键词，很可能匹配得不够稳； 而 Embedding 的价值，就是尽量让这种语义相关也能被检索到。

3.2 Embedding 常见场景

它最常见的场景就是：

1. 文档片段向量化
2. 用户问题向量化
3. 语义相似度检索

所以它经常同时出现在入库和查询两段链路里。

3.3 Embedding 的边界是什么

它能做的是“表示语义相关”，但它不负责：

1. 最终答案生成
2. 复杂逻辑推理
3. 最终排序是否最好

也就是说，它是检索链路里的表示层，不是最终答案层。

4. Vector DB 是什么

Vector DB 可以理解成“支持向量存储和相似度检索的数据系统”。

它在这条链路里的角色很明确：

1. 存储片段向量
2. 支持相似度召回

4.1 Vector DB 主要解决什么问题

文档一旦向量化之后，总得有地方存起来，也得有办法快速找出“和当前问题最接近”的那批内容。

这正是 Vector DB 的职责。

它更像是：

检索链路里的向量存储和召回底座。

4.2 Vector DB 不负责什么

这里的边界一定要记清楚。

它不负责：

1. 最终答案生成
2. 复杂业务流程编排
3. 事实正确性判断
4. 最终答案是否可读

很多人把“上了向量库”和“RAG 已经做好了”混成一回事，这就是典型误区。

5. Retriever 是什么

Retriever 可以理解成“召回器”。

它的职责是：

面对用户问题，先从知识库里找回一批候选片段。

5.1 Retriever 主要解决什么问题

它解决的是：

在大量知识片段里，把可能相关的内容找出来。

这里最关键的不是“一次就找得完美”，而是：

1. 把相关候选找回来
2. 别把真正有用的内容完全漏掉

所以 Retriever 更偏第一轮筛选。

5.2 Retriever 常见场景

它常见于：

1. 知识库问答
2. 文档搜索
3. FAQ 召回
4. 企业内部资料检索

5.3 Retriever 的边界是什么

它负责召回，但不保证：

1. 排序已经最优
2. 最终拼给模型的内容最干净
3. 最后答案一定正确

这也是为什么召回之后，很多系统还会再加一层 Reranker。

6. Reranker 是什么

Reranker 可以理解成“重排器”。

当 Retriever 先找回一批候选片段后，Reranker 再负责：

把更相关、更值得优先参考的内容排到前面。

6.1 为什么还需要 Reranker

因为很多项目的问题不是“完全没召回”，而是：

1. 相关内容确实在候选里
2. 但它没有排在最前面
3. 最终被拼进上下文的反而不是最关键的片段

这时如果没有重排，模型最后看到的材料顺序就可能不够理想。

6.2 Reranker 主要适合什么场景

它尤其适合这些场景：

1. 候选召回数量较多
2. 文档内容相似度很高
3. 需要把最相关内容尽量顶到前面

6.3 Reranker 的边界是什么

它负责排序优化，但不负责：

1. 替代召回本身
2. 替代上下文拼接策略
3. 直接生成答案

也就是说，它更像检索链路里的排序增强层。

7. RAG 是什么

RAG 是 Retrieval-Augmented Generation，检索增强生成。

把主线压成一句话：

先查资料，再让模型基于资料生成答案。

真放到工程里看，RAG 不是一个单点能力，而是一条完整链路：

1. 文档准备
2. 切分
3. 向量化
4. 召回
5. 重排
6. 上下文拼接
7. 模型生成

7.1 RAG 主要解决什么问题

它解决的核心问题是：

模型本身不知道你的私有知识，那就把相关资料找出来，再基于资料回答。

这让模型回答时不再只靠预训练记忆，而是能更多参考外部资料。

7.2 RAG 常见场景

它常见于：

1. 企业知识库问答
2. 产品文档助手
3. 客服问答
4. 内部制度查询
5. 技术文档检索问答

7.3 RAG 的边界是什么

RAG 不是万能药。

它并不自动保证：

1. 召回一定准确
2. 模型一定不幻觉
3. 资料一定最新
4. 回答一定适合业务场景

它只是让“先找资料、再回答”这件事成立起来。

8. 把这些词放在一起怎么分工

术语	主要职责	更像哪一层
Chunk	控制文档切分粒度	文档准备层
Embedding	提供语义表示	表示层
Vector DB	存储向量并支持检索	存储与召回底座
Retriever	找回候选片段	第一轮召回层
Reranker	优化候选排序	排序增强层
RAG	把检索和生成真正串起来	完整问答链路

9. 真实项目里最容易踩的几个坑

9.1 只看模型，不看切分策略

很多时候效果差，不是模型差，而是：

1. Chunk 太大
2. Chunk 太碎
3. 元数据不完整

9.2 以为有向量库就等于有 RAG

不是。

只有把下面这些环节真正串起来，才更接近完整 RAG：

1. 召回
2. 重排
3. 上下文拼接
4. 最终生成

9.3 召回了不等于能答好

召回只是在“找资料”，最终回答质量还会受到这些因素影响：

1. 重排效果
2. 上下文拼接方式
3. 提示词设计
4. 输出约束

9.4 把检索问题误判成模型问题

很多“答得不准”“老是跑偏”的问题，最后根子可能是：

1. 资料没找回来
2. 找回来的不是最相关的
3. 最相关的没排在前面

这时候继续盯着模型名，很可能方向就已经偏了。

10. 一段更稳的总结

如果把这几个词压成一句话，可以记成：

Chunk 负责把知识切成可检索的粒度，Embedding 负责把文本变成可计算的语义向量，Vector DB 负责存和查，Retriever 负责把候选找回来，Reranker 负责把最值得参考的内容排到前面，而 RAG 则负责把整条检索增强链路真正串起来。很多知识库项目最后卡住的地方，往往不是模型本身，而是这条链路里某一层没有站稳。