先给结论
选型的核心依据是用户提问的全局性程度以及项目对计算成本的承受能力。如果业务场景只需要解决局部的单点问答，跨文档关系与全局主题分析不是重点，普通的向量检索已经足够。当需要引入知识图谱来增强检索能力时，如果业务要求生成宏观的深度报告，且能承担较高的模型调用开销与较重的处理链路，应选择完整版的 GraphRAG 方案。如果业务需要保留实体图的关联能力，但对成本高度敏感，且要求知识库能够快速进行增量更新，则应该选择 LightRAG 方案。
逐项对比
| 维度 | 向量 RAG | LightRAG | GraphRAG |
|---|---|---|---|
| 定位 | 局部问答的最简方案 | 图增强的控本方案 | 深度汇总的完整图方案 |
| 强项 | 简单直接，开销最低 | 增量更新容易，成本低 | 全局汇总类问题的深度最强 |
| 弱项 | 跨文档关系与全局主题是盲区 | 全局归纳深度弱于完整方案 | 建图成本高，增量更新需重算社区，链路重 |
| 典型场景 | 针对明确细节的单点提问 | 需要图关联但预算有限的问答 | 宏观趋势分析与深度报告生成 |
| 成本 | 最低 | 较低（降低一个量级） | 最高 |
这三种技术方案代表了从局部细节到全局宏观的不同检索层级。普通的向量方案像是一个按关键词查找的档案柜，擅长直接提取匹配的片段资料，但面对跨越多个文档的关联信息与全局主题时会产生明显的盲区。当引入图结构后，不同方案的差异主要体现在对全局信息的处理机制与工程实现上。
GraphRAG 采用实体关系建图配合社区聚类与分层摘要。这种机制在处理全局汇总类问题时具备最强的深度，能够自上而下地梳理出宏观脉络，适合复杂的分析任务。但这种深度的代价是极高的模型构建成本。同时，一旦有新的文档加入知识库，整个社区结构往往需要重新计算，导致增量更新变得非常沉重，维护周期变长。
LightRAG 则在效果与开销之间找到了平衡。它保留了底层的实体图结构，但直接砍掉了沉重的社区聚类与分层摘要机制。取而代之的是实体细节层与主题概览层的双层检索模式。这种设计将计算成本降低了一个量级，并且让图结构的增量更新变得十分容易。虽然在全局归纳的深度上不可避免地弱于 GraphRAG，但足以应对大多数需要图增强同时又必须严格控制成本的常规业务场景。
面试怎么答
在面试中遇到这类技术选型题，答题框架应该是先确认问题的全局性，再给出对应的工具选择。开篇直接说明选型口径：纯局部问答用普通向量方案，需要图增强但必须控制成本选 LightRAG，要求输出深度报告则选 GraphRAG。接着需要对比阐述不同方案在增量更新和计算开销上的取舍逻辑。
常见的错误答法是直接罗列两者的技术原理，而完全忽略了业务场景的工程限制。比如脱离计算成本去空谈 GraphRAG 的深度优势，或者没有明确指出 LightRAG 在全局归纳能力上的妥协。面试官更看重你是否清楚 GraphRAG 中社区聚类带来的重计算负担，以及 LightRAG 砍掉这部分机制后如何通过双层检索来弥补信息，从而体现出对工程落地可行性的真实考量。