完整题目
请详细描述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扩展 + 重排序 |
| 上下文过长 | 摘要压缩、分层检索 |
| 幻觉 | 严格引用约束、答案后校验 |
换一种问法，检查是否真正理解
场景切入
假设你在做客服知识库的QA系统，用户问一个产品问题，你希望先检索相关文档再交给大模型回答。你觉得从原始文档到最终回答，整个流程应该怎么搭？
层层追问
你们现在做文档问答一般怎么处理？……检索部分用了什么策略？……那检索到的片段怎么拼给大模型，才能保证它不乱编、还能引用来源？
直球架构
给我讲一下RAG系统的完整架构，从离线的文档处理到在线的检索和生成，每个环节的核心设计要点是什么？包括分块策略、混合检索、上下文组装这些。关键是考虑哪些优化点？
练习口述回答 · 约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看成一套工程系统，不是简单拼装。离线处理、在线检索、生成集成，每一层都有取舍，真正落地要看业务场景和资源限制，没有银弹。