RAG
- 文档解析
- 文本清洗
- 文档切分、切分策略
- 文档嵌入
- 元数据提取Metadata
- 向量存储、Embedding 向量化
- 检索和生成
RAG 的流程
文档
→ 将文档切成片段
→ 转成向量
→ 存入向量数据库
→ 用户提问
→ 问题转成向量
→ 找相似片段
→ 交给大模型回答
RAG核心阶段
- 数据索引阶段
- 数据查询阶段
RAG质量问题
- RAG 的效果不只取决于大模型，更多取决于文档解析质量、Metadata 设计、检索策略和工程化治理
RAG检索流程总结
- 向量检索负责从海量知识库中找出一批可能相关的候选 Chunk，通过
top_k配置初次召回的 Chunk 数量。例如，top_k=10 表示先召回相关性最高的 10 个 Chunk。 - Rerank 重排序模型负责对召回的候选 Chunk 进行更精细的相关性打分和重新排序，将最可能回答用户问题的内容排在前面，从而减少无关内容，提高最终 Prompt 的质量和 LLM 回答的准确性。
- 可以通过
top_n配置 Rerank 后最终保留的 Chunk 数量。例如，top_n=3 表示从召回的 10 个候选 Chunk 中重新排序，并保留相关性最高的 3 个发送给 LLM
简单来说
- 用户问题 → 向量检索召回 top_k 个 Chunk → Rerank 重新排序 → 保留 top_n 个 Chunk → 发送给 LLM 生成答案
- top_k 控制“先找多少个候选文档”，top_n 控制“最终留下多少个高质量结果”
- 向量检索关注的是召回率 （把包含答案的内容找出来）
- Rerank关注的是排序准确性。（真正相关的内容排在前面）
- LLM 生成 关注的是回答准确率 （根据精选内容组织答案）
模型配置解析
↓
Embedding 生成查询向量
↓
向量检索 ─┐
├─ RRF 混合融合h
全文检索 ─┘
↓
Rerank
↓
LLM 生成回答
行业RAG实际方案
| 核心问题 | 实际解决方案 |
| 精度不够高？ | 混合检索+重排序 |
| 检索太短，生成太短？ | 子-父分块 |
| 数据类型多，切分难？ | 元数据驱动分块 |
详细方案
| 核心问题 | 实际解决方案 | 解决思路 |
|---|---|---|
| 检索精度不够高 | 混合检索 + Rerank | BM25 找关键词，向量检索找语义，再由 Rerank 精细打分 |
| 小 Chunk 检索准，但上下文不完整 | 子—父分块 | 用小 Chunk 检索，命中后返回所属的大父 Chunk |
| 答案跨越相邻段落 | 相邻 Chunk 扩展 | 命中 Chunk 后，补充前后相邻 Chunk |
| 文档类型多、结构复杂 | 结构感知分块 + 元数据增强 | PDF 按版面，Markdown 按标题，代码按函数，表格保持表头与数据完整 |
| 问题太短或存在歧义 | 查询改写 + 查询扩展 | 将短问题补充为更完整、适合检索的查询 |
| 一个问题包含多个子问题 | 查询分解 / Multi-query | 拆成多个子查询，分别检索后合并 |
| 不同问题需要不同数据源 | 查询路由 | 根据意图选择知识库、数据库、搜索引擎或 API |
| 跨多个章节才能回答 | 多跳检索 / Agentic RAG | 根据第一次检索结果继续生成下一步查询 |
| 检索结果重复、噪声多 | 去重 + 阈值过滤 + 上下文压缩 | 删除重叠 Chunk、低分 Chunk 和无关句子 |
| 数据持续变化 | 增量索引 + 版本管理 | 文档新增或修改时，只重新处理受影响的数据 |
| 企业数据需要权限控制 | 检索前 ACL/租户过滤 | 先根据用户权限过滤，再进行向量或关键词检索 |
| LLM 容易编造 | 引用溯源 + Grounded Prompt + 拒答机制 | 要求答案必须来自检索上下文，没有依据时明确拒答 |
| 延迟和成本过高 | 两阶段检索 + 动态参数 + 缓存 | 便宜的检索先筛选，再对少量候选执行昂贵的 Rerank |
| 不知道效果好不好 | 离线评测 + 在线监控 | 分别评估检索、重排序和最终生成效果 |
问题相关
- 文档解析的问题
- PDF 解析难，如文字顺序错乱、页眉页脚污染、目录污染
- 解析导致语义丢失
- 文档里面涉及的公式、代码可能会切坏