RAG 和 Vector Search

2026-04-01 pv

上文🔗提到 RAG(Retrieval-augmented generation,检索增强生成)。

虽然名字看上去很高级,原理其实相当简单:

先检索,后总结。

Vector Search(向量检索)是支撑其底层检索模块的重要技术。

LLM 在 Vector Search 的基础上,通过召回(Recall)相关信息后丰富其上下文,生成的结果自然更加准确

这便是 RAG 的所有东西了。

如果想进一步深挖,还是能找到不少有趣的东西:RAG 产生的背景,为什么选择 Vector Search,主流的工程实现是什么样子。

1. RAG 为何产生

LLM 基于历史数据训练,缺少领域知识

导致它在面对一些专业问题时,很可能会“胡编乱造”。

RAG 将 LLM 放在指定信息的笼子里,尽可能减少模型幻觉(Hallucination)。

主要解决两个问题:

  1. 知识过时。训练数据是静态的,但答案需要与时俱进。
  2. 领域知识。有时用户需要获取更加垂直,或私有信息,这与 LLM 本身只提供公开且通用服务背道而驰,因此主动喂一些只有自己掌握的数据给 LLM,效果更好。

2. Vector Search 的优势

解决了为什么,下一步要解决怎么办:如何检索文档?

很自然地联想到,找相关性高的

不然把全部数据推给 LLM,上下文窗口很快就会爆炸。

传统的检索基于关键词,倒排索引(Inverted index)、BM25 是主流做法,可以解决精确检索问题。

但是 RAG 通常选择 Vector Search(向量检索),一种模糊检索算法。

原因很简单,关键在于理解“关键词”和“语义”的差异。

在 LLM 使用场景下,可以从输入端和输出端两个方面解释。

输入端,用户的问题通常不会特别精确,基于“语义”检索,能捕捉到更多丰富信息。

输出端,用户提供的检索数据源可以是任意类型,非结构化,甚至多模态,用“语义”的方式处理更加便捷。

实现向量搜索,实际只需要三步:

  1. Embedding(向量化)。

    将文本转换成向量:

    "git rebase conflict" → [0.12, -0.98, ..., 0.44]

    语义相似 → 向量距离接近。

  2. 相似度计算。

    常见方法:

    • Cosine similarity(最常用)
    • Dot product
    • Euclidean distance
  3. Top-K 检索。

    找到最相似的 K 条:

    Top 3 文档:
    1. 如何解决 rebase 冲突
    2. git merge vs rebase
    3. rebase 原理

当然,精确检索和模糊检索并非一个非此即彼的选项,完全可以将二者融合,形成一种混合检索(Hybrid Search)。

3. 工程实现指南

一份标准 RAG 的处理流程大致如下:

┌──────────────┐
│ 用户问题 │
└──────┬───────┘
┌──────────────┐
│ Embedding 模型│
└──────┬───────┘
┌──────────────┐
│ Vector DB │
│ (相似度检索) │
└──────┬───────┘
┌──────────────┐
│ Top-K 文档 │
└──────┬───────┘
┌──────────────┐
│ Prompt 拼接 │
└──────┬───────┘
┌──────────────┐
│ LLM 生成答案 │
└──────────────┘

先建库,再检索,最后生成,思路很清楚。

LLM 还是那个 LLM,但“新鲜知识”的加入,让效果得到增强。

4. 总结

LLM 解决了广度问题,RAG 则聚焦深度。

像极了通才和专才的差异

上一份工作,老板跟我提过“T 型人才”的说法,大意是:在多个领域知识面广泛,在某个具体领域精深

在 AI 时代,不是有了 LLM 就可以高枕无忧,似乎所有问题都可以被解决。

解决,和解决好之间,同样存在一条巨大的鸿沟

RAG 本质做了一件“注意力聚焦”的事情,人也一样,因为根本没有办法在广度上和 AI 抗衡。

(完)

参考

  1. 檢索增強生成 - 维基百科,自由的百科全书🔗
  2. 倒排索引 - 维基百科,自由的百科全书🔗
  3. Okapi BM25 - Wikipedia🔗
  4. 向量数据库 - 维基百科,自由的百科全书🔗
在 GitHub 上编辑本页面

最后更新于: 2026-04-01T08:02:20+08:00