跳到正文

RAG 文档处理与检索策略怎么搭？

文档处理、检索策略与生成集成三大环节详解

原题：请详细描述RAG（检索增强生成）系统的典型架构和实现流程，包括文档处理、检索策略和生成集成等关键环节

重排与优化 · 百度真题

30 秒回答

  1. 离线文档处理Pipeline（解析、清洗、分块、向量化）
  2. 在线检索流程（向量检索+关键词混合、重排序优化）
  3. 生成阶段集成策略（上下文组装、Prompt工程、引用溯源）
  4. RAG典型痛点与优化（幻觉、检索失效、上下文长度限制）

回答与解析

答案要点

  • 离线文档处理Pipeline（解析、清洗、分块、向量化）
  • 在线检索流程（向量检索+关键词混合、重排序优化）
  • 生成阶段集成策略（上下文组装、Prompt工程、引用溯源）
  • RAG典型痛点与优化（幻觉、检索失效、上下文长度限制）

RAG系统三层架构

一、离线文档处理层

核心流程：

  • 文档解析：PDF/Word/网页等多格式解析，处理表格、图片OCR
  • 文本清洗：去噪、标准化、敏感信息脱敏
  • 智能分块：按语义段落切分（非固定长度），常用策略：
    • 递归字符切分 + 语义边界检测
    • 滑动窗口重叠（保证上下文连贯）
    • 标题层级感知（保留文档结构）
  • 向量化：Embedding模型编码，写入向量数据库（Milvus/Faiss/Elasticsearch）

二、在线检索层

混合检索策略：

用户Query → Embedding编码 → 向量相似度检索（Top-K）
         ↓
      关键词BM25检索 → 结果融合（RRF加权）
         ↓
      精排模型（Cross-Encoder重排序）→ 最终Top-N片段

关键优化点：

  • Query改写：扩展同义词、澄清指代
  • 多路召回：向量+关键词+图谱并行
  • 重排序：轻量Cross-Encoder比双塔更准，但 latency 高

三、生成集成层

上下文组装：

  • 检索片段按相关性排序，拼接为上下文
  • 控制总长度（通常占模型上下文30%-50%）

Prompt设计要点：

基于以下参考资料回答问题，若资料不足请明确说明：
[参考资料]
{检索内容}

用户问题：{query}

生成优化：

  • 引用溯源：要求模型标注答案来源片段
  • 置信度判断：检索分数阈值过滤，低置信触发"我不知道"
  • 多轮RAG：迭代检索补充信息

典型痛点

问题 解法
检索失效 混合检索 + Query扩展 + 重排序
上下文过长 摘要压缩、分层检索
幻觉 严格引用约束、答案后校验

口语版讲法(约4分钟)

  • RAG本质是给大模型配个外挂知识库
  • 离线阶段：文档解析、分块、向量化
  • 在线阶段：混合检索加重排
  • 生成阶段：上下文组装和引用约束
  • 落地风险和取舍

这道题其实在问，怎么给大模型配一个能随时更新的外挂知识库，让它回答时能引用真实资料，而不是全靠训练时记住的那点东西。我理解RAG的核心是三个环节：离线把文档处理好、在线把相关片段找出来、最后把检索结果喂给模型生成答案。

先说离线阶段。文档进来，得先解析，PDF、Word、网页这些格式不一样，表格和图片还得OCR。接下来是清洗，去噪、脱敏。最关键的其实是Chunk分块，怎么切直接决定检索质量。固定按512个字符切，简单但容易把语义切碎。我倾向用语义边界检测，按段落或标题层级来切，同时加一点滑动窗口重叠，保证上下文连贯。分完块之后做Embedding，把文本转成向量，存到Vector Database里，比如Milvus或者Faiss。

在线检索的时候，光靠向量检索不够，因为语义相似不一定能匹配到精确的关键词。所以我一般用Hybrid Search，向量和关键词BM25两条路并行，再用RRF算法融合排序。但融合完的结果还不够准，我会再加一层重排，用Cross-Encoder精排Top-K。这里有个坑，重排模型虽然准，但latency高，所以只对召回结果的前几十条做重排，别全量做。另外，用户query有时表达模糊，我还会做query改写，扩展同义词或者澄清指代。

检索到片段之后，怎么喂给生成模型？先按相关性排序拼成上下文，但得控制长度，一般不超过模型上下文窗口的30%到50%，留空间给指令和回答。Prompt设计上，我会明确说「基于以下参考资料回答，如果资料不足请说明」，同时要求模型标注引用来源，就是让它回答时带上「根据第X段」。这样能有效抑制Hallucination。如果检索分数低于某个阈值，我宁愿让模型说不知道，也不让它瞎编。

举个例子，电商客服场景里，用户问「我退货为什么还要付运费」，如果模型只靠预训练知识，可能答错。但RAG系统可以实时检索最新的运费政策文档，找到「非质量问题退货需用户承担运费」那一条，然后基于它生成答案，还能附上政策原文的链接。

这里有个落地风险：如果知识库里的文档本身质量差，比如有矛盾或者过时，那检索出来的东西就是错的，模型会一本正经地引用错误信息。所以上线前我会特别关注文档的更新机制和版本管理，确保知识库是可信的。另外，检索环节如果召回率低，模型回答就会漏信息，这时候得调分块大小和检索参数。

还有个延伸方向是，当问题需要多步推理时，单次检索不够，我会考虑用Agentic RAG，让模型主动决定要不要再检索，或者拆成子问题逐个查。这个对复杂业务场景挺有用的，但实现起来对模型推理能力要求更高。

所以整体上，我更倾向于把RAG看成一套工程系统，不是简单拼装。离线处理、在线检索、生成集成，每一层都有取舍，真正落地要看业务场景和资源限制，没有银弹。

关键一句:复杂推理场景下，单次RAG不够，需要用Agentic RAG让模型自主决定多次检索。

面试官还可能这样问

  1. 问法 1 · 场景切入

    假设你在做客服知识库的QA系统，用户问一个产品问题，你希望先检索相关文档再交给大模型回答。你觉得从原始文档到最终回答，整个流程应该怎么搭？

  2. 问法 2 · 层层追问

    你们现在做文档问答一般怎么处理？……检索部分用了什么策略？……那检索到的片段怎么拼给大模型，才能保证它不乱编、还能引用来源？

  3. 问法 3 · 直球架构

    给我讲一下RAG系统的完整架构，从离线的文档处理到在线的检索和生成，每个环节的核心设计要点是什么？包括分块策略、混合检索、上下文组装这些。关键是考虑哪些优化点？

同模块相关题目