Is GraphRAG Needed? From Basic RAG to Graph-/Agentic Solutions with Context Optimization
GraphRAG 是否必要？RAG 方案对比与上下文优化
🧭 RAG 方案对比与上下文优化
Generative AI Innovation Center, Amazon Web Services (AWS) · Cisco Systems, Inc.
系统对比 9 种 RAG 场景并提出上下文工程方法，token 用量降低 19%-53%，揭示检索-生成差距
📌 工作参考价值
- 上下文工程技巧：提出的混合文本-图检索与 Agent 循环设计可复用，尤其适合电商知识库问答中的长上下文管理，避免 KV cache 膨胀，直接用于客服或导购 Agent 的 memory 控制。
- 检索-生成差距洞察：业务上不要盲目叠加复杂检索（如图谱扩展），应先评估生成端真实增益；在推荐理由生成、商品属性问答等场景中，用生成质量（而非召回率）作为最终优化指标。
- GraphRAG 适用边界：半结构化知识（如商品图谱、品牌关系）用 GraphRAG 能提升一致性，但需注意短期用户交互场景可能用轻量 Modular RAG 更经济。建议按查询复杂度分流：简单事实查询走基础 RAG，多跳推理走 Agentic-GraphRAG。
- Agent 与图谱集成模式：在电商智能导购中，可将商品数据构建为预定义 KG，通过 Agent 多轮规划调用图谱查询与文本检索，实现精准商品推荐与属性解释，文中 Agent-Graph 集成方案可直接参考。
动机：高级 RAG 变体（GraphRAG、Agentic RAG）兴起，但何时、如何选用缺乏系统比较。现有工作多聚焦单一方案，且上下文溢出问题未充分解决，检索指标常被过度解读。
方法：构建标准化评测框架，覆盖 9 种 RAG 场景（从基础文本检索到混合文本-图谱检索、预定义 KG 集成、Agent 多步规划等），在半结构化知识库上对比 Regular RAG、GraphRAG、Modular RAG 和 Agentic RAG。提出上下文工程方法：为 GraphRAG 和 Agentic RAG 设计新型表征与 Agent 循环，高效管理文本与图谱检索，缓解上下文/内存溢出。
关键结果：上下文工程将 token 用量降低 19%-53%；进一步分析发现存在检索-生成差距——扩展检索不总能成比例提升生成质量，提示基于检索的指标会夸大高级检索的收益。