Skip to content

RAG(检索增强生成)面试题

内容整理自学习笔记,仅供面试备考参考;不构成录用、培训或考试承诺。

1. LLM 已具备较强能力,为何还需要 RAG?

尽管大语言模型(LLM)已经展现出强大的能力,但仍存在以下关键不足,而 RAG 正是针对这些问题的解决方案:

问题说明
幻觉问题(Hallucination)LLM 基于概率逐 token 生成文本,不可避免地会产生与事实不符的内容("一本正经地胡说八道")
时效性问题大模型训练成本高、周期长,训练数据存在截止日期,无法回答时效性问题(如"推荐几部热映电影")
数据安全问题通用 LLM 缺乏企业内部数据和用户私有数据,企业希望在本地处理业务数据,仅让云端模型负责归纳
领域知识不足通用模型在特定垂直领域(医疗、法律、金融等)缺乏深度专业知识

RAG(Retrieval-Augmented Generation,检索增强生成)的核心思想:LLM 在生成回答前,先从外部知识库中检索相关信息,再基于检索到的信息生成回答,从而提升准确性和可靠性。

2. RAG 的整体工作流程

用户查询 → 检索器(Retriever) → Top-K 相关文档 → 生成器(Generator) → 最终回答

RAG 系统包含两个核心模块:

Retriever(检索器):从外部知识库中检索与查询最相关的前 K 个文档或片段。

Generator(生成器):将检索到的信息与原始查询结合,转化为自然流畅的回复文本。

2.1 检索器模块的关键问题

如何获得准确的语义表示?

文档分块(Chunking)策略

  • 选择合适的块大小,需要考虑:被索引内容的特点、嵌入模型的最佳块大小、用户查询的预期长度和复杂度
  • 实践表明:没有绝对最优策略,需要灵活组合多种分块方式

嵌入模型选择

  • 主流嵌入模型包括:UAE、Voyage、BGE、M3E、text2vec 等
  • 选择标准:在大规模语料库上的预训练质量、对特定领域的适配程度

如何协调查询和文档的语义空间?

查询重写(Query Rewriting):利用 LLM 对用户的原始查询进行改写和优化,使其更匹配文档的语义空间。

伪文档生成(HyDE):使用 LLM 先生成一篇「假设答案/假设文档」,再用该文档(或其向量)去检索;经典做法不是简单把原查询与伪文档拼成新查询,而是用假设文档的语义去对齐语料空间。

多查询检索:让 LLM 同时产生多个搜索查询并行运行,合并处理结果,特别适用于需要多角度回答的复杂问题。

嵌入变换(Embedding Transformation):在查询编码器后加入适配器(Adapter)进行微调,优化特定任务下的查询嵌入表示(LlamaIndex 采用此方法)。

结构化信息处理(SANTA):利用结构化与非结构化数据的自然对应关系进行对比学习预训练,使检索系统能够理解结构化信息。

如何对齐检索模型输出与 LLM 偏好?

REPLUG 方法:使用检索模型和 LLM 计算检索文档的概率分布,通过 KL 散度进行监督训练,让检索模型的输出更符合 LLM 的需求。

外部适配器对齐:当无法微调嵌入模型(如使用 API 或计算资源不足时),在检索模型上附加外部适配器实现对齐。

PKG 方法:通过指令微调将知识注入白盒模型,直接替换检索模块,根据查询输出相关文档。

2.2 生成器模块

生成器负责将检索信息转化为自然文本。优化方向包括:

  • 后检索处理:信息压缩(去除冗余)、结果重排序(Rerank)
  • 生成器微调:与 LLM 通用微调方法类似,可使用对比学习等技巧
  • Prompt Engineering:将检索文本与原始查询合理拼接,引导模型生成准确回答

3. RAG 的优势

维度RAG 优势
准确性基于检索到的信息来源,用户可以核实答案的准确性
可扩展性无需为每个任务重新训练大模型,挂载知识库即可扩展
可控性允许独立更新或定制知识,不影响模型本身
可解释性检索到的文档作为模型预测的参考依据
时效性检索技术能识别最新信息,保持回答的及时性
定制性通过索引特定领域语料库,为不同领域提供专业知识支持
安全性通过数据库角色和安全控制实现更好的数据访问管理
多功能性适用于 QA、文本摘要、对话系统等多种任务

4. RAG vs SFT 对比

维度RAGSFT(微调)
知识更新直接更新知识库即可需要重新训练
外部知识天然支持引入外部知识知识内化在模型参数中
可解释性有明确的信息来源黑盒
训练成本低(无需训练或仅微调检索器)高(需要全量或部分训练)
数据安全可控(数据库权限管理)数据可能被模型记忆
幻觉控制较好(基于检索结果生成)较差(依赖训练数据)

实践建议:二者并非互斥,应根据业务需求合理结合两种方法的优势。

5. RAG 典型实现方法

5.1 数据索引构建

Step 1:数据提取

  • 支持多格式数据加载:PDF、Word、Markdown、数据库、API 等
  • PDF 文档难点:完整恢复图片、表格、标题、段落 —— 可用版面分析模型(如百度的 PP-StructureV2)
  • PPT 文档:转换为 PDF 后统一处理
  • 数据清洗:去重、过滤、压缩、格式化

Step 2:文本分割(Chunking)

分割方式说明
句分割按句子边界切分,保留完整语义,切分符包括句号、感叹号、问号、换行符
固定大小分割根据嵌入模型 Token 限制,固定长度切分(256/512 tokens),通过头尾冗余量缓解语义损失
递归分割分而治之,递归切分到最小单元
基于意图分割使用 NLP 工具(NLTK、spaCy)进行语义级切分

常用工具:LangChain 的 CharacterTextSplitterRecursiveCharacterTextSplitter

Step 3:向量化(Embedding)与索引创建

  • 常见嵌入模型:OpenAI Embedding、ERNIE-Embedding、M3E、BGE
  • 向量数据库:FAISS、ChromaDB、Elasticsearch、Milvus
  • 选择依据:业务场景、硬件条件、性能需求

5.2 数据检索

  • 元数据过滤:先通过元数据筛选缩小检索范围,提升效率
  • 图关系检索:引入知识图谱,利用实体间关系增强多跳问题的检索精度
  • 向量相似度检索:欧氏距离、余弦相似度、曼哈顿距离
  • 关键词检索:传统倒排索引,包含对 Chunk 摘要的关键词匹配
  • 混合检索:向量检索 + 关键词检索的融合
  • 重排序(Rerank):对召回结果按相关度重新排序
  • 查询变换:子查询、HyDE、树查询等策略

5.3 生成回复

将原始查询和检索文本组合输入模型,本质上是一个 Prompt Engineering 过程。

python
from langchain.chat_models import ChatOpenAI
from langchain.schema.runnable import RunnablePassthrough

llm = ChatOpenAI(model_name="gpt-3.5-turbo", temperature=0)
rag_chain = {"context": retriever, "question": RunnablePassthrough()} | rag_prompt | llm
rag_chain.invoke("What is Task Decomposition?")

6. RAG 典型案例

6.1 ChatPDF

  1. 读取 PDF 并转换为可处理文本格式
  2. 文本清洗、分段、分句
  3. 使用 Embedding API 将每段文本转换为向量
  4. 用户提问时将问题转换为向量,通过余弦相似度检索最相关分段
  5. 将最相关分段与问题组合为 Prompt,调用 LLM 生成回答
  6. 返回生成结果给用户

6.2 百川搜索增强系统

  • 指令意图理解:深入理解用户意图
  • 智能搜索:精确驱动查询词
  • 结果增强:结合 LLM 优化输出可靠性

通过多模块协同减少模型幻觉。

6.3 多模态检索增强(RA-CM3)

使用预训练 CLIP 模型作为检索器,CM3 Transformer 作为生成器。检索器从外部存储库获取图像相关信息,生成器基于检索到的信息进行图像合成,显著提升多模态生成准确性。

7. RAG 存在的问题

  1. 检索质量依赖:检索效果取决于 Embedding 和检索算法的质量,可能检索到无关信息反而影响输出
  2. 信息利用黑盒:LLM 如何利用检索信息的机制不透明,可能生成与检索信息矛盾的内容
  3. 效率问题:对所有任务无差别检索 K 个片段,效率不高且增加输入长度
  4. 来源不可追溯:无法精准引用来查证事实,真实性取决于数据源和检索算法

8. RAG 中 BERT 与 LLM 的分工

任务类型优先选择原因
分类、抽取等判别式任务BERT速度快、成本低,精度损失可接受
改写、摘要等生成式任务LLMBERT 上下文窗口仅 512,且生成能力弱;LLM 时间换性能更有价值