01：RAG 常见问题与挑战 + RAG vs 微调
学习笔记：详述 RAG 面临的核心挑战、解决思路，以及 RAG 与微调的选择策略
目录
- RAG 面临的核心挑战
- 检索质量相关问题
- 生成质量相关问题
- 系统性能问题
- RAG 失败模式与应对
- 失败模式分类
- 诊断与解决思路
- RAG vs 微调
- 两种方法的对比
- 何时选择 RAG
- 何时选择微调
- 混合策略
- 参考资料
RAG 面临的核心挑战
RAG 虽然是当前最成功的 LLM 应用架构之一，但在实际落地中面临诸多挑战。这些问题贯穿索引、检索、生成三个阶段，需要系统性地解决。
检索质量相关问题
| 问题 | 描述 | 影响 |
|---|---|---|
| 语义鸿沟 | 用户查询的表达方式与文档内容存在差异 | 检索不到相关内容 |
| 长尾问题 | 特定领域或小众查询的向量表示不准确 | 召回率低 |
| 文档重要性模糊 | 难以判断哪些文档对回答真正重要 | 引入噪声 |
| 多义词歧义 | 同一词在不同领域含义不同 | 检索到无关内容 |
常见原因
Embedding 模型局限
- 训练数据与实际应用领域存在分布差异
- 对专有名词、专业术语的理解不足
Chunk 策略不当
- Chunk 太小导致上下文丢失
- Chunk 太大引入过多噪声
知识库质量
- 文档内容本身不够规范
- 文档结构混乱影响分割效果
生成质量相关问题
| 问题 | 描述 | 影响 |
|---|---|---|
| 上下文稀释 | 检索到过多无关内容，稀释关键信息 | 生成质量下降 |
| 幻觉问题 | LLM 未严格遵循检索内容生成 | 回答与事实不符 |
| 信息冗余 | 检索结果存在重复内容 | 回答啰嗦、不准确 |
| 引用丢失 | 生成内容无法追溯到原始文档 | 缺乏可解释性 |
上下文长度限制
系统性能问题
| 问题 | 描述 |
|---|---|
| 延迟较高 | 检索 + 生成需要额外时间，影响用户体验 |
| 成本较高 | 向量数据库、Embedding 调用、LLM 调用都有成本 |
| 扩展性挑战 | 亿级文档规模下的检索性能 |
| 实时性要求 | 知识库更新后的索引同步 |
RAG 失败模式与应对
失败模式分类
典型失败场景与应对
| 失败场景 | 原因分析 | 解决思路 |
|---|---|---|
| 查不到内容 | 语义鸿沟、分块问题 | 优化 chunk 策略、混合检索 |
| 查到错误内容 | 向量质量问题、多义词 | 改写查询、知识图谱增强 |
| 生成幻觉 | LLM 未严格遵循上下文 | 提示工程、引用约束 |
| 回答不完整 | 检索召回不足 | 扩大检索范围、多路召回 |
| 回答太啰嗦 | 检索内容冗余 | 重排序、上下文压缩 |
诊断与解决思路
诊断框架
问题定位 → 根因分析 → 方案设计 → 效果验证 │ │ │ │ ▼ ▼ ▼ ▼ 分析日志 定位环节 针对性优化 评估指标 抽样case 确定原因 迭代改进 持续监控关键指标监控
| 阶段 | 监控指标 | 阈值建议 |
|---|---|---|
| 检索 | Hit Rate | > 80% |
| 检索 | MRR | > 0.7 |
| 生成 | Faithfulness | > 0.8 |
| 生成 | Answer Relevancy | > 0.75 |
| 系统 | 延迟 P99 | < 5s |
常见优化手段
| 优化方向 | 具体措施 |
|---|---|
| 检索优化 | 调整 chunk 大小、混合 BM25 与向量检索、添加重排序 |
| 查询优化 | 查询改写、HyDE、查询扩展 |
| 生成优化 | 提示词工程、few-shot 示例、输出约束 |
| 系统优化 | 缓存策略、异步处理、预计算 |
RAG vs 微调
RAG 和微调（Fine-tuning）是两种主流的 LLM 定制化方案，各有优劣。理解它们的适用场景是构建高效 AI 系统的关键。
两种方法的对比
| 维度 | RAG | 微调（Fine-tuning） |
|---|---|---|
| 原理 | 检索外部知识，动态增强生成 | 调整模型权重，固化知识到模型 |
| 知识更新 | 即时更新（替换知识库） | 需要重新训练 |
| 成本 | 推理成本高，初始成本低 | 训练成本高，推理成本低 |
| 数据需求 | 少量数据即可构建知识库 | 需要大量标注数据 |
| 可解释性 | 可追溯到原始文档 | 难以解释，模型是黑盒 |
| 幻觉控制 | 基于真实文档，减少幻觉 | 可减少但无法完全消除 |
| 延迟 | 额外检索步骤，增加延迟 | 无额外延迟 |
| 适用场景 | 动态知识、大规模知识库 | 固定模式、风格统一 |
决策矩阵
何时选择 RAG
最佳场景
动态知识库
- 企业文档、产品手册需要频繁更新
- 新闻资讯、实时数据集成
- 多版本文档管理
可解释性要求高
- 需要追溯答案来源
- 合规审计要求
- 客服对话需要引用依据
数据量大但结构化程度低
- PDF、Word、网页等非结构化文档
- 知识分散在多个数据源
- 无法进行大规模标注
快速原型验证
- 快速验证产品 idea
- 验证市场需求
- 降低试错成本
RAG 的优势总结
RAG 核心优势： • 知识与模型分离 → 更新知识无需重新训练 • 透明可追溯 → 回答可追溯到原始文档 • 部署简单 → 无需 GPU 训练资源 • 灵活扩展 → 新增知识库即可何时选择微调
最佳场景
任务模式固定
- 分类任务（情感分析、垃圾邮件检测）
- 序列标注（实体识别、关键词提取）
- 结构化输出（JSON 格式化）
特定风格要求
- 特定语气（专业、幽默、亲和）
- 固定格式（报告、邮件模板）
- 品牌调性一致
领域知识稳定
- 医学诊断标准
- 法律条文解释
- 金融风控规则
延迟/成本敏感
- 大规模调用场景
- 实时性要求高
- 推理成本控制
微调的限制
- 知识更新困难：需要重新训练，成本高
- 数据依赖：需要大量高质量标注数据
- 过拟合风险：特定任务可能影响通用能力
- 难以调试：模型行为难以精确控制
混合策略
为什么需要混合
| 策略 | 解决的问题 |
|---|---|
| RAG + 微调 | RAG 检索质量差？用微调提升 Embedding 模型 |
| 微调 + RAG | 微调后知识仍需更新？叠加 RAG 做动态增强 |
| 多 RAG 路由 | 不同类型问题使用不同知识库 |
混合架构示例
实际案例
| 场景 | 推荐策略 |
|---|---|
| 客服机器人 | 微调（意图分类）+ RAG（产品知识库） |
| 文档问答 | RAG（知识库）+ 微调（回答风格） |
| 代码助手 | 微调（编程能力）+ RAG（API 文档） |
| 报告生成 | RAG（参考资料）+ 微调（格式/风格） |
实施建议
- 先 RAG 后微调：先用 RAG 验证，确有需要再微调
- 分层优化：先优化检索，再优化生成，最后考虑微调
- A/B 测试：对比不同策略的实际效果
- 持续迭代：根据用户反馈不断调整
参考资料
RAG vs Fine-tuning: Best Approach for Your LLM
https://www.anyscale.com/blog/rag-vs-fine-tuningWhen to Use Retrieval-Augmented Generation vs Fine-Tuning
https://www.ibm.com/topics/retrieval-augmented-generationBuilding Production-Ready RAG Applications
https://www.pinecone.io/blog/build-rag-applicationsRAG 常见问题与优化策略
https://github.com/run-llama/llama_index/blob/main/docs/docs/optimizingHybrid Search and RAG Evaluation
https://www.elastic.co/guide/en/elasticsearch/reference/current/hybrid-search.html