Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.
Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).
先别被名字带跑。GraphRAG 更适合全局主题、实体关系、跨文档综合,不是替代所有 RAG。
如果用户问“某个报销标准是多少”,普通检索更直接。
如果问“过去半年客户投诉主要集中在哪些产品线”,图和社区摘要可能有用。
GraphRAG 的构建成本不低。实体抽取、关系抽取、社区摘要、更新都要维护。
那是不是只有大公司能用?
不是。小团队也能试,但别一上来把制度问答改成图谱工程。
图谱最大的坑是更新。文档每天变,关系和摘要怎么增量更新?
我们试过在项目复盘文档上做实体关系,找人和系统关系挺好。但查具体配置不如向量。
还有可解释。图上边是模型抽的,用户会问这条关系从哪来。
所以每条实体关系最好能追溯到原文片段,不然图谱也会变成另一种幻觉。
我原来想拿 GraphRAG 解决所有召回问题,现在看不现实。
可以从“跨文档分析”场景试点,不要从“员工手册问答”开始。
普通 RAG、结构化查询、GraphRAG 是工具箱,不是升级路线。
先定义问题,再选检索形态。别反过来。
你好!看起来您对这段对话很感兴趣,但您还没有一个账号。
厌倦了每次访问都刷到同样的帖子?您注册账号后,您每次返回时都能精准定位到您上次浏览的位置,并可选择接收新回复通知(通过邮件或推送通知)。您还能收藏书签、为帖子顶,向社区成员表达您的欣赏。
有了你的建议,这篇帖子会更精彩哦 💗