百万级文档知识库怎么搭？SAG 和 LightRAG 怎么选才不踩坑

最近在做企业级知识库的需求，说实话，有点头大。

现在的研报系统要求特别高，内部知识基座不仅要处理接近百万级的海量文档，还得具备很强的证据组织和多跳推理能力。面对这么大的数据量和这么复杂的逻辑，选型就成了最头疼的一步。

目前圈子讨论得比较热的两个方向，一个是 SAG（SQL-RAG），另一个是 LightRAG。这俩到底该怎么选？网上资料不少，但真正落实到有百万文档体量的工程实践中，能听懂的“大实话”不多。

今天就把这段时间纠结的点、踩过的坑（或者预判的坑）和大家盘一盘，希望能给同样在做这块的朋友一点参考。

一、 面对海量文档，核心痛点是什么？

先别急着看架构，先搞清楚场景。既然是“百万级”文档，那肯定是传统的 RAG 方案有点顶不住了。

传统的关键词检索或者简单的向量召回，在处理“证据组织”和“多跳推理”时，往往会显得力不从心。你问一个复杂的研报问题，它可能给你召回几段碎片化的文本，但你需要的是有逻辑链条的、像 SQL 聚合结果那样的精准答案，而不是一堆还要你自己去拼凑的文本块。

所以，我们的核心需求其实就两点：

1. 能不能像数据库一样查？ 不仅仅是文本匹配，最好能返回结构化的事实。
2. 运维和成本能不能扛住？ 百万文档的索引构建、更新、存储，都是真金白银的成本。

二、 LightRAG：图谱很香，但落地有点累

LightRAG 这一阵子风很大，核心卖点是引入了知识图谱。它能返回 global_summary 和实体关系图摘要。

优点很明显：

• 全局视野好： 对于涉及多个实体关系的复杂问题，知识图谱能提供更宏观的视角。
• 推理能力强： 基于图谱的路径查找，天然适合做多跳推理。

但在工程落地时，我也在犹豫：

• 给下游的负担重： 它返回给 Research Agent 的是摘要和图谱信息。这就要求你的 Research Agent 必须足够聪明，能读懂这些图谱结构，并把它转化为最终的研报结论。这对 Prompt 工程和模型能力要求极高。
• 资源消耗： 维护百万级文档的动态知识图谱，图数据库的存储和计算压力可不小。

三、 SAG（SQL-RAG）：返璞归真，用 SQL 解决问题

相比之下，我个人目前其实更倾向于 SAG（SQL-RAG）。

SAG 的思路很有意思，它不是在检索时硬搜图，而是在检索过程中动态构建局部图，然后把最关键的一步交给了 SQL —— 它返回的是 SQL 聚合结果 + 关键事实。

为什么觉得它更适合当前场景？

1. 结构化输出对研报太友好了： 研报系统要的是什么？是数据，是统计，是结论。SQL 聚合结果天然就是结构化的，Agent 稍微处理一下就能直接用，不需要费劲去解析图谱。

2. 证据链更清晰： SAG 在组织证据时，逻辑更像是一个成熟的数据库查询过程。它告诉你“因为 A 表的数据和 B 表的数据联合查询结果是这样，所以得出结论”。这种透明度在金融或企业级应用中非常重要。

3. 运维相对轻量： 相比于维护庞大的全量知识图谱，SAG 的局部图构建策略在处理大规模数据时，显得更“轻”。它不需要预先把所有关系都算好，而是按需构建。这对百万级文档的更新频率来说，运维复杂度确实低很多。

四、 现实骨感：SAG 也有隐患

虽然我站 SAG，但心里也没底，主要因为 SAG 缺乏大规模的工程验证。

现在看到的案例大多还是 Demo 级别，真正用来跑百万级文档的，鲜有听到“实战分享”。这就意味着：

• Bug 风险： 遇到极端复杂的 SQL 生成需求，模型会不会崩？局部图构建会不会漏掉关键节点？这都是未知数。
• 成本仍是问题： 虽然比全量图谱轻，但频繁调用大模型来生成 SQL 和构建局部图，Token 消耗依然是笔巨款。

五、 实践建议：怎么平衡？

现在架子虽然搭起来了，但思路还没完全理清。如果你也遇到类似问题，我有几个不成熟的平衡思路：

1. 混合架构或许是过渡方案： 虽然理论上 SAG 和 LightRAG 互补，但太重了。与其全盘照搬，不如在核心链路用 SAG 保证结构化输出的准确性，在非核心的背景挖掘环节，尝试用轻量级的图谱索引。

2. 小步跑通： 别一上来就扔百万文档。先切一个一万文档的垂直领域（比如只看某个行业的研报），跑通 SAG 的 SQL 生成准确率和召回率。

3. 关注 SQL 的可解释性： 既然选了 SAG，就要重点监控生成的 SQL 质量。如果 SQL 写错了，后面的推理全是废话。建立一个 SQL 校验或中间层人工审核机制，能救命。

总结

企业知识库没有银弹。

• 如果你追求极致的推理灵活性，且算力预算充足，团队对 Graph RAG 理解很深，LightRAG 是个值得探索的方向。
• 但如果你像我一样，更看重结果的结构化、证据的确定性以及运维的可持续性，SAG（SQL-RAG） 可能是那个“虽然不那么性感，但真的很能打”的选择。

工程路漫漫，大家如果有跑过大规模 SAG 的经验，求指教，求避坑！