GraphRAG、Text2SQL 与向量 RAG 怎么选
向量 RAG、GraphRAG 和 Text2SQL 解决的不是同一种检索问题。向量 RAG 擅长从非结构化文档中寻找语义相关证据，GraphRAG 适合需要沿实体关系进行多跳推理的场景，Text2SQL 则面向结构化业务数据库中的聚合、筛选和统计查询。
选型应先看数据结构和问题类型，再看权限、准确性与维护成本。真实企业应用经常需要组合三条链路，而不是强行用一种方案承接所有问题。
三类方案对应的数据结构
| 方案 | 主要数据 | 典型问题 | 主要输出 |
|---|---|---|---|
| 向量 RAG | 文档、制度、手册、工单正文 | “退款规则是什么？” | 带来源的文本证据 |
| GraphRAG | 实体、关系、事件网络 | “客户、合同与案件之间有什么关联？” | 关系路径与相关证据 |
| Text2SQL | 表、字段、指标和交易记录 | “本月各区域订单额是多少？” | 可核验的结构化查询结果 |
数据形式只是第一层判断。同一份业务资料可能同时包含合同正文、客户关系和订单金额，分别适合进入文档索引、知识图谱和只读分析库。
文档问答优先使用向量 RAG
制度、产品手册、会议纪要和知识文章通常没有稳定的关系模型。向量 RAG 可以通过切片、Embedding 和混合检索召回语义相关内容，再把有限证据交给模型生成答案。
向量 RAG 的关键边界是“相关”不等于“正确”。生产链路仍需处理文档版本、权限过滤、引用定位和离线评估。对于错误码、产品名等精确词，可以组合 BM25 与 RRF，提高候选覆盖率。
关系推理考虑 GraphRAG
当问题依赖多个实体和关系时，仅靠相似文本可能难以稳定找到完整路径。例如，查询某个客户关联的合同、案件、律师和风险事件，需要明确实体类型、关系方向与时间范围。
GraphRAG 通常先从文本或业务系统抽取实体和关系，再结合图查询与原文证据回答问题。它的成本不只在建图，还包括实体消歧、关系更新、权限传播和错误边的治理。关系无法稳定定义时，不宜为了“多跳推理”过早引入知识图谱。
更完整的概念和实现入口可参考 Graph RAG：图谱增强检索。
业务统计使用 Text2SQL
订单金额、用户数量、库存变化和转化率来自结构化数据库，使用向量检索会丢失精确筛选和聚合语义。Text2SQL 将自然语言问题映射到表、字段和 SQL，再执行只读查询并解释结果。
Text2SQL 的生产风险集中在 Schema Linking、权限和执行安全：
- 只向模型暴露当前用户有权访问的表和字段。
- 使用只读账号、查询超时、行数限制和资源配额。
- 对生成 SQL 做语法解析与操作白名单校验。
- 保存问题、Schema 版本、SQL 和结果摘要，支持审计和回归。
实现流程可继续阅读 Text2SQL：结构化数据检索。
混合路由比单方案更常见
可以在入口先识别查询意图，再路由到不同检索器：
用户问题
-> 意图识别与权限上下文
-> 文档事实：向量 RAG / 混合检索
-> 关系问题：GraphRAG
-> 指标统计：Text2SQL
-> 合并证据、标注来源并生成回答跨数据源问题应拆成可验证的子查询。例如“哪些高价值客户近期出现合同风险”，可以先由 Text2SQL 获取符合金额条件的客户集合，再由图查询获取合同关系，最后用向量 RAG 补充风险条款原文。每一步都应保留中间结果和来源，避免模型自行拼接未经验证的事实。
选型检查表
- 问题答案来自文档原文、关系路径还是结构化计算？
- 是否需要精确聚合、排序或时间窗口？
- 实体与关系能否稳定定义并持续更新？
- 权限能否在每条检索链路中前置执行？
- 是否有固定评估集验证召回、SQL 和关系路径？
- 失败时能否返回证据不足，而不是继续生成看似合理的答案？
如果大多数问题都能从原文直接找到，先建设可评估的向量 RAG；如果核心价值来自关系推理，再引入 GraphRAG；如果问题要求精确业务数字，使用受控的 Text2SQL。组合架构应由真实问题集推动，而不是由技术名称推动。