RAG从基础到高级

先说几个核心判断：大语言模型（LLM）固然强大，但面对企业私有数据时，往往会暴露出几个棘手的短板——数据量大、信息提取如大海捞针、检索效率上不去、模型还总是“忘”掉上下文窗口里的内容。而检索增强生成（RAG）正是为了解决这些痛点出现的：通过把外部知识库接入LLM的生成流程，让模型在回答问题时先“查资料”，再“写答案”，效果自然提升一大截。

一句话概括RAG：从海量文档中检索出相关的片段，再把这些片段塞进prompt里，喂给LLM去生成回复。听起来简单，但要做好，里面门道不少。

目前LLM遇到的挑战

• 客户通常拥有大量的私有文件。
• 提取具体信息无异于大海捞针。
• 检索效率不高。
• 模型容易忘记上下文窗口内容。

RAG

RAG的实施方法不算复杂：为每个文档段落建立索引，快速锁定相关段落，再把选中的段落输入到LLM（比如GPT-4）里。这么做的好处是显而易见的——既能防止信息过载，又能通过只提供相关段落来提升输出质量。

RAG流水线

借助RAG，LLM可以访问外部知识源（比如数据库），从而利用那些不存储在模型权重里的知识。具体来说，RAG靠一个检索器来找到相关上下文，然后用这些上下文去增强LLM的知识库。

检索器可以是以下几种，具体选哪种取决于你是否需要语义检索：

• 向量数据库：
  通常用BERT这类模型把查询编码成稠密向量；也可以用TF-IDF之类的方法生成稀疏向量。之后按词频或语义相似度来搜索。

• 图数据库：
  从文本中提取实体关系，构建知识图谱。这种方法很精确，但需要精确的查询匹配，有时会受限。

• 常规SQL数据库：
  提供结构化存储和检索，但缺少向量数据库的语义灵活性。

那么，图数据库和向量数据库在RAG中到底怎么选？直观来看，图数据库似乎更适合：它从文本中提取实体关系，检索结果简洁明了。不过，它要求精确匹配，这又可能成为瓶颈。反观向量数据库，靠LLM编码的向量做分区和索引，能找出语义相似的向量，但有时会带回不相关的数据。有没有两全其美的办法？一种思路是把两者结合——在图数据库中用向量表示法索引解析出来的实体关系，从而实现更灵活的信息检索。这种混合模式能否真正落地，目前还在观察中。

检索之后，通常还需要加一道排序层或精细排序层，用来过滤掉那些不符合业务规则、没有针对用户个性化、或者超出响应限制的信息。

来，用一个简洁的流程总结一下RAG：

1. 创建向量数据库：
   把内部数据集转换成向量并存储。

2. 用户输入：
   用户用自然语言提出问题。

3. 信息检索：
   检索器扫描向量库，找出与用户查询（同样经过嵌入）语义相似的片段，然后交给LLM去丰富上下文。

4. 组合数据：
   把选中的数据段和原始查询拼在一起，构成一个扩展prompt。

5. 生成文本：
   LLM基于这个扩展prompt，输出最终的上下文感知响应。

（原图位置）

说到RAG和微调的区别，可以这么看：

1. RAG让LLM系统能访问到事实、访问控制以及实时信息——微调做不到这些，所以两者不是竞争关系。
2. 微调主要调整LLM的风格、语气和词汇，使其更贴合特定领域。
3. 结论是：先搞定RAG。成功的LLM应用必须先把专有数据接入工作流。等到第一个完整应用跑起来，再考虑用微调来优化风格和词汇。如果RAG与数据的连接没建好，微调也救不了场。

构建RAG流水线

下面这张图直观展示了RAG的三个关键步骤：数据提取、检索、合成/响应生成。

（原图位置）

数据提取（Ingestion）

分块，就是把要检索的文档或提示切分成更小、更易管理的片段。这些片段可以用固定大小来定义，比如特定数量的字符、句子或段落。在RAG中，每个块都会被编码成嵌入向量供检索用。块越小越精，用户查询和内容之间的匹配就越准，从而提升检索的准确性和相关性。块太大则可能引入噪声，反而降低准确性。

所以问题来了：怎么选合适的块大小？块大小得足够小以保证相关性、减少噪声，又要足够大以保持上下文完整。下面列举几种常用方法（参考Pinecone的方案）：

• 固定大小的分块：
  直接确定块中的token数量，以及块之间是否重叠。重叠能保证语义上下文损失最小。这种方法计算成本低，容易实现。

  text = "..." # your text
  from langchain.text_splitter import CharacterTextSplitter
  text_splitter = CharacterTextSplitter(separator = "
  
  ", chunk_size = 256, chunk_overlap= 20)
  docs = text_splitter.create_documents([text])

• 上下文感知分块：
  利用文本的内在结构来创建更有意义的分块。常见方法有：

  • 句子拆分：
    与针对句子级内容优化的模型配合。可用工具包括：
    • 简单拆分：用标点符号和换行符拆分句子。
    • spaCy：高效的NLP库，提供句子分割。
    • 递归分块：迭代地用各种分隔符分层拆分文本。
    • NLTK：自然语言工具包，内置句子分词器。

一条经验法则：如果分出来的文本块对人类来说都意义不明，那对语言模型来说也很难有意义。所以，为语料库找到最佳块大小，是保证搜索准确性和相关性的关键。

分块完成后，下一步就是嵌入。嵌入的目的是把用户查询和文档转换成可比较的格式，方便后续检索。可以通过HuggingFace的MTEB排行榜找到最适合的嵌入模型。这里有个选择：用稠密嵌入还是稀疏嵌入？

• 稀疏嵌入（如TF-IDF）：
  适合词法匹配，计算强度低，但可能抓不住深层语义。

• 语义嵌入（如BERT、SentenceBERT）：
  天然适合RAG。BERT能捕获上下文细微差别，但计算资源要求高；SentenceBERT在句子级上下文和简洁表达之间取得了平衡，通常是RAG的首选。

检索（Retrieval）

检索方式有很多种，这里重点看标准检索、句子窗口检索和自动合并检索。每种方法都有优劣，取决于数据集、查询复杂度以及对特异性和上下文理解的平衡需求。

• 标准检索
  ：使用相同的文本块进行索引/嵌入和输出合成。优势是简单高效、数据一致；缺点是LLM可能缺乏足够的合成窗口，导致回复不够准确。

• 句子窗口检索（从小到大分块）
  ：把文档分解成句子或小句子组。检索时用较小的块（存储在向量库中），但合成时会把检索块周围的上下文加回去。这样既能精准检索，又能提供丰富语境。不过，管理检索和合成的不同流程会增大系统复杂性，而且如果补充的周边信息不全，可能遗漏更广的背景。

检索器集成和重新排序

想法：如果同时尝试多种块大小，然后让重新排序器对结果做一次修剪，会怎样？这样做有两个目的：一是通过汇集多个结果获得更好的检索效果（假设重排器性能合理）；二是对不同的检索策略做基准测试。

流程如下：

1. 以多种方式分块同一个文档（比如块大小128、256、512、1024）。
2. 检索时从每个检索器获取相关块，合并结果。
3. 用重新排序器对结果排序/修剪。

（原图位置）

根据LlamaIndex的评估，集成方法在忠实度指标上略有上升，但成对比较显示两种方法偏好度相差不大，所以集成是否真的更好还存疑。另外，集成策略也可以扩展到RAG的其他方面，比如向量搜索与关键词搜索的混合等。

重新排名（Reranking）

• 词法重排：
  基于查询和文档之间的词法相似性（如BM25、TF-IDF余弦相似度）。

• 语义重排：
  用神经网络（如BERT）理解上下文和意义。

• 学习排名（LTR）：
  专门为排序任务训练模型，可混合词法和语义特征。

• 混合方法：
  结合词法、语义和其他信号（如用户反馈）。

• 神经LTR：
  在候选集有限的场景下最常用，比如monoBERT、duoBERT。

生成回复（Synthesis）

RAG流水线的最后一步是生成回复。模型将检索到的信息与预训练知识综合起来，生成连贯且上下文相关的回答。这里有个细节：在构建扩展prompt（包含检索到的top-k块）时，把重要信息放在输入序列的开头或结尾，能明显提高RAG系统的效率。

结论

本文详细梳理了RAG的基本概念、工作流程和关键领域，包括数据提取、嵌入、检索和响应生成。重点探讨了各种检索和重排技术，以及如何高效生成用户反馈。同时，文章也指出在处理长文本时，模型性能可能受影响——尤其当相关信息位于文本中部时。因此，建议把重要信息放在输入序列的开头或结尾。通过改进检索和提示创建步骤（比如加入排序阶段），性能能提升20%左右。这些洞察对理解和优化RAG的实际应用很有参考价值。