RAG（Retrieval-augmented generation）个人学习笔记

为什么需要 RAG？#

传统的 LLM 模型主要存在以下 2 个问题：

RAG 可以通过结合基于检索和生成模型的优势来提供更准确和上下文相关的响应，可以添加自己的预料构建知识库。

理论上，对于需要外挂知识库，即需要处理大量文本数据的场景，不通过微调，将这些文本数据全部塞进 Prompt 未尝不可，但：

从目标来看，我们需要的是大量文本数据中能够回答用户问题的相关信息，而不是让 LLM 直接处理这些文本数据。RAG 的出现正是为了满足这一需求，其分为两步：

Size-based chunking：根据文本块的大小进行分块；
- 优点：简单易行；
- 缺点：可能会切断句子或段落，导致信息丢失或上下文不完整，因此实现上会在句子间引入一定的重叠。
Structure-based chunking：根据文本的结构进行分块，例如段落、章节等；
- 优点：保持文本的完整性和上下文关系；
- 缺点：可能会导致块的大小不均匀，某些块可能过大或过小。并且实际应用中文本并不一定有明确的结构。
Semantic-based chunking：根据文本的语义内容进行分块，例如使用自然语言处理技术识别主题或概念；
- 优点：可以更好地捕捉文本的语义信息和上下文关系；
- 缺点：实现复杂，可能需要更多的计算资源和时间。

语义搜索，通过将文本块和用户查询转换为向量表示（Text Embeddings），并使用向量相似度来检索相关块。

Chunk source text.
Generate embeddings.
Store embeddings in a vector database.
Embed user query, find closest chunks.
- 通过余弦相似度计算用户查询与文本块之间的相似度，检索出相关块。
- 范围为 -1 到 1，值越大表示越相似。
Add related chunks to the prompt, generate answer.

语义搜索虽然能够捕捉文本的语义信息，但在某些情况下可能会遗漏一些重要的细节信息。为了弥补这一不足，可以将语义搜索与词汇搜索（Lexical Search）结合起来，常用方法是 BM25 算法，其基本流程如下：

Tokenize the user query.
For each text chunk, calculate the BM25 score based on the frequency of query tokens in the chunk and the overall token distribution in the corpus.
Rank the chunks based on their BM25 scores and select the top N chunks for further processing.

将语义搜索和词汇搜索得到的结果混合需要进行一定的排序，常用方法是 Reciprocal Rank Fusion（倒数排序），其计算方式如下：

RRF(d) = \sum_{i=1}^{n} \frac{1}{k + rank_i(d)}

其中， $RRF(d)$ 是文档 $d$ 的最终得分， $n$ 是搜索方法的数量， $rank_i(d)$ 是文档 $d$ 在第 $i$ 个搜索方法中的排名， $k$ 是一个常数（通常设置为 60）以避免排名为 0 的情况。分数越高表示文档越相关。