RAG 的坑不是玄学，而是已知清单：按“传统 RAG 短板—补法”连成一张修复对照表
做 RAG 系统最容易陷入的循环是：上线、翻车、去搜索引擎搜“RAG 回答不准怎么办”，然后被一堆零散博客淹没。其实很多坑不是玄学，而是被反复记录过的已知问题。本文把 IBM 在《RAG 问题仍然存在。以下是 5 种解决方法》中拆解的典型短板，与 Prompt Engineering Guide 的《大语言模型的检索增强生成 (RAG) 方法》研究前沿清单、Datawhale 的开源实战项目 all-in-rag 的章节结构一一对照，整理成一张“短板—补法—局限”的修复对照表，帮你从“出了问题再搜”变成“按已知短板清单预设计”。
对照表总览
| 传统 RAG 短板 | 补法 | 补法自身局限 |
|---|---|---|
| 聚合类查询答不准 | 查询转 Text2SQL，让数据库算数 | 需要 SQL 数据库和数据建模；安全与权限要单独设计 |
| 分割点切割破坏语义 | 智能体式分块 / 语义分块 | 增加预处理复杂度，切块策略需按文档类型调优 |
| 无法识别实体间关系 | GraphRAG（知识图谱） | 数据量大时图谱渲染和维护难度显著增加 |
| 噪声文档、无关上下文拖垮生成 | 链式笔记等鲁棒性方法 | 多一步评估与整合，延迟上升 |
| 单一检索方式召回不全 | 混合检索（稠密+稀疏） | 需要融合排序策略，系统复杂度提升 |
下面逐条展开。
一、聚合查询：别让大模型用上下文窗口做算术
“去年发票总额是多少？”这类问题，传统 RAG 几乎必挂。原因很直白：大模型只能对塞进上下文窗口的文档做“阅读理解式”计算，而发票数据可能有成千上万条，上下文窗口根本装不下，模型也不擅长精确求和。
IBM 文章中的解法是：把发票数据存入 SQL 数据库，用大模型把自然语言问题转换为 SQL 语句，经 RAG 流程查库取数。SQL 内置聚合函数，数据库的处理容量也远大于大模型上下文窗口。文中引用的观点指出，若能成功构建这套系统，就能实现大量聚合运算——数据库算完数，剩下的工作就转变回大模型擅长的自然语言处理任务。
实践建议：这正是 all-in-rag 第四章“检索优化”中单列 Text2SQL 一节的原因——查询构建不是可选项，而是 RAG 架构里的独立模块。设计时应先盘点业务里哪些问题本质是“结构化数据查询”，把它们路由到 Text2SQL 通路，而不是全部走向量检索。
局限：Text2SQL 通路意味着你要维护数据库 schema、处理 SQL 注入与权限控制，且对查询意图分类的准确性有要求——分错路由，答案照样错。
二、关系识别：向量相似度天然不擅长“谁和谁有什么关系”
传统 RAG 的另一缺陷是难以辨识不同信息片段或实体间的关联性。IBM 文章举了患者病历的例子：传统检索可能返回“患者年度就诊医生数量”这类相关数据，却无法准确说明每位医生对应的治疗方案——因为向量检索按相似度取片段，片段之间的关系在切分时就丢了。
补法是微软研究院于 2024 年提出的 GraphRAG：把信息组织为节点（实体）与边（关系）构成的知识图谱网络。按文中引用的说法，查询历史就诊记录时，图谱不仅能以文字描述，更能直观呈现，通过单一图谱即可追溯多个时间节点，包括不同接诊医生、服用的药物及治疗方案。
实践建议：all-in-rag 在第七章“高级 RAG 架构”设有“基于知识图谱的 RAG”，第九章还有专门的“图 RAG 架构优化”选修篇，涵盖图数据建模、Milvus 索引构建、智能查询路由等内容，可作为入门路线。适合关系密集型场景：医疗、法务、供应链。
局限：IBM 文章明确指出，随着数据量增长，图谱渲染难度会显著增加——映射数十万个节点比处理几十个节点复杂得多。构建图谱本身的抽取成本也不低，实体抽取错了，图反而放大错误。
三、分块缺陷：固定点切割是很多“答案不准”的根源
分块策略对 RAG 应用至关重要。IBM 文章指出，传统嵌入模型按固定点切割文档、把片段存入向量数据库，即使搭配语义搜索算法，仍可能导致大模型返回不完整或不准确的答案——因为一个关键事实可能恰好被切在了两个块之间。
实践建议：补法方向包括语义分块和智能体式分块（让模型参与决定切割边界）。all-in-rag 第二章专门讲“文本切分策略与优化”，第三章讲向量嵌入与索引，这一条链路（加载→分块→嵌入→索引）值得在项目早期就花时间调优，而不是等检索效果差了再回头改。
局限：更聪明的分块意味着更高的预处理成本，且没有普适的最优块大小——合同、代码、FAQ 的切法完全不同，需要按文档类型分别设计。
四、噪声与鲁棒性：检索回来的文档本身就是干扰源
Prompt Engineering Guide 的研究综述记录了这一方向的工作：针对 RAG 在处理噪声较多、不相关文档以及未知情境时稳健性不足的问题，有研究（2023 年 11 月）提出为检索文档生成序列化“链式笔记”，深入评估其与提问的相关性，再整合信息构建最终答案。同综述还提到通过去除对答案贡献不大的标记来优化检索增强阅读模型，实现了高达 62.2% 的运行时间缩减，同时性能仅降低 2%。
实践建议：在生成前加一层“相关性过滤/笔记”步骤，成本低、收益直接。尤其适合知识库质量参差不齐的企业内部文档场景。
局限：多一步处理意味着更高延迟；过滤策略本身也可能误杀关键文档。
五、别只盯着单点补丁：研究前沿与工程化清单
Prompt Engineering Guide 的综述还列出了几个值得长期关注的方向：上下文长度问题（窗口扩大后如何仍捕获最相关的关键信息）、系统鲁棒性（如何处理与现实相反的信息和对抗性信息）、混合方法探索（RAG 与专门微调模型的结合）、扩展大模型在 RAG 中的作用、规模化法则，以及生产级 RAG 在性能、效率、数据安全性、隐私保护上的工程挑战。多模态 RAG（图像、音频、视频、编码）也在快速起步。
落到工程侧，all-in-rag 的目录本身就是一张学习路线图：第四章的混合检索（稠密+稀疏融合）、查询重构与分发，第五章的格式化生成与结构化输出，第六章的 RAG 系统评估方法论与评估工具。特别提醒：评估不是锦上添花——没有第六章那套评估指标，你连“补丁有没有生效”都无法判断。
适用范围与总结
这张对照表适合已经在搭或维护 RAG 系统、遇到具体症状想快速定位补法的开发者。需要清醒的是：IBM 文章自己也说“任何技术都有局限”，GraphRAG 的兴起正源于传统 RAG 本身的不足，而每种补法又引入新的复杂度——Text2SQL 引入安全面，GraphRAG 引入规模问题，智能体式分块引入预处理成本。正确的姿势不是堆技术，而是先列出你业务中最可能命中的短板类型，按清单预设计架构，并用评估体系持续验证。把坑当成已知清单，而不是每次都当新问题去踩。
参考资料
以下链接为本文使用的公开资料。事实依据与检索摘录保存在本地记录中；资料内容与适用范围以原始页面为准。
- RAG 问题仍然存在。以下是 5 种解决方法 | IBM
- 大语言模型的检索增强生成 (RAG) 方法 | Prompt Engineering Guide<!-- -->
- GitHub - datawhalechina/all-in-rag: 🔍大模型应用开发实战一：RAG 技术全栈指南，在线阅读地址：https://datawhalechina.github.io/all-in-rag/ · GitHub
