RAG 技术原理和实现流程
从检索到生成的完整链路,含文档切分与向量检索
原题：请详细解释检索增强生成（RAG）的技术原理和实现流程。
知识图谱 · 字节真题
30 秒回答
- 能清晰区分RAG与微调的技术边界，说明何时选RAG
- 讲清楚"离线建库-在线检索-增强生成"的三阶段流程
- 理解Embedding模型和向量数据库的核心作用
- 知道RAG的典型痛点（检索不准、上下文过长）及优化方向
回答与解析
答案要点
- 能清晰区分RAG与微调的技术边界，说明何时选RAG
- 讲清楚"离线建库-在线检索-增强生成"的三阶段流程
- 理解Embedding模型和向量数据库的核心作用
- 知道RAG的典型痛点（检索不准、上下文过长）及优化方向
- 能提及高级变体如GraphRAG、Self-RAG等
RAG核心定位
RAG = 检索(Retrieval) + 生成(Generation)，用外部知识库动态增强LLM，解决知识时效性和幻觉问题，无需重新训练模型。
三阶段实现流程
1. 离线知识库构建
- 文档解析：PDF/Word/网页 → 文本块（Chunking，控制256-512 tokens）
- 向量化：Embedding模型（如BGE、M3E）将文本转为稠密向量
- 索引存储：写入向量数据库（Milvus/Pinecone/Elasticsearch）
2. 在线检索
- Query向量化：用户问题同样编码为向量
- 相似度搜索：ANN近似最近邻算法（HNSW、IVF），召回Top-K相关文档
3. 增强生成
- 上下文组装：Prompt = 系统指令 + "参考文档：[检索结果]" + 用户问题
- LLM生成：模型基于检索到的证据作答，可溯源
关键优化点
| 环节 | 常见问题 | 优化手段 |
|---|---|---|
| 检索 | 语义不匹配 | 查询改写、HyDE（假设文档嵌入）、重排序(Rerank) |
| 上下文 | 文档过长/冗余 | 摘要压缩、关键句提取、多路召回融合 |
| 生成 | 不遵循参考 | 引用标注训练、Self-RAG（自适应检索判断） |
典型变体
- GraphRAG：用知识图谱替代向量检索，处理复杂多跳推理
- Self-RAG：模型自主判断是否需要检索，避免过度检索
实际落地时，检索质量决定RAG上限，建议先做检索评测（Recall@K）再优化生成。
口语版讲法(约4分钟)
- RAG的核心定位与适用边界
- 三阶段流程与关键环节
- 落地风险与优化策略
- 高级变体与工程取舍
这道题其实是在问，当大模型知识不够用或者不准确的时候，怎么用外部知识库去补它的短板。RAG 和微调是两条不同的路，微调适合让模型学特定风格或固定知识，但你要它回答实时变化的政策，比如电商平台的满减规则，微调一次成本高还跟不上更新，这时候 RAG 就派上用场了。实际落地中，我经常是 RAG 加微调一起上，微调解决回答的语气和格式，RAG 提供最新的事实，两者互补。
具体说一下 RAG 的实现流程，核心就是离线建库、在线检索、增强生成三个阶段。离线建库这块，第一步是文档解析和切分，把 PDF、网页这些拆成文本块，chunk 大小我一般控制在 256 到 512 tokens，太长了检索容易混，太短了上下文不够。然后用 Embedding 模型转成向量，存到 Vector Database 里，像 Milvus 或者 Faiss。这里有个坑：切分策略很关键，固定按字数切可能把语义连贯的段落拆散，我倾向于用语义切分，比如按段落或者用 Chunk 重叠来保证上下文不丢。
在线检索时，用户问题同样转成向量，用 ANN 算法比如 HNSW 召回 Top-K 相关文档。但光靠向量检索不一定准，尤其是用户问法跟文档表述差异大的时候。所以我会加一层查询改写，比如把“怎么退运费”扩写成“退货流程中运费承担规则”，或者用 HyDE 先生成一个假设文档再去匹配。召回后还要做 Rerank，用 Cross-Encoder 精排一下，把最相关的顶上去。
增强生成阶段，就是把检索结果拼到 prompt 里，让 LLM 基于证据回答。这里有个常见失败场景：如果检索到的文档太长或者不相关，模型可能忽略正确信息，反而产生 Hallucination。所以上线前我会特别关注检索的召回率，先拿一批测试 query 跑 Recall@K，确保 Top-5 能覆盖 90% 以上正确答案，再优化生成。另外，上下文长度有限，我会对长文档做摘要压缩，或者只提取关键句，避免信息过载。
说到高级变体，像 GraphRAG 用知识图谱处理多跳推理，Self-RAG 让模型自己判断要不要检索，这些在复杂场景下效果更好。但我觉得，RAG 落地的上限其实在检索质量，而不是生成能力。所以我会把更多精力放在检索链路优化上，比如混合检索，把向量和 BM25 关键词结合起来，应对不同 query 类型。
总的来说，RAG 不是万能药，前提是你的知识库质量要够高，文档结构清晰，否则检索不准，后面生成再好也没用。我更倾向先做检索评测，再逐步优化生成，这样迭代路径更清晰。
关键一句:RAG落地上限在检索质量，而非生成能力。
面试官还可能这样问
- 问法 1 · 场景切入
假设你在做一个客服知识库问答系统，用户问的很多问题需要从最新产品文档里找答案，你不能每次都重新训练模型吧？那你会怎么设计，让模型既能用上这些新知识，又不产生幻觉？
- 问法 2 · 层层追问
如果想让大模型具备外部知识，你有什么思路？……那如果我用微调，更新成本太高怎么办？……检索增强具体怎么落地？从数据准备到最终生成，你一步步讲一下。
- 问法 3 · 直球架构
请你详细解释RAG的技术原理和实现流程，包括离线建库、在线检索和增强生成三个阶段，以及你可能碰到的坑和优化手段。