SH

Soloharness

概念 · 辨析 · Agent

← 返回概念辨析

Concept Contrast Fable

按关系图谱找的和按多种数据形式找的

Graph RAG 在文本之上增加实体和关系结构来改善检索,多模态 RAG 增加了对图片、音频等多种数据格式的支持。两者的复杂度来源不同,解决的是不同类型的信息孤岛问题。

寓言

两个书局,一个画关系图,一个收图画账本

县里有一东一西两家书局,都说自己能查各种资料。东局把人物关系和交易往来画成了一张大图挂在墙上,查资料时先找图、再按图索骥。西局把文字、图画和账本全放在同一个柜子里,来了查询就一起搜。

东局第一次显本事是有人问:去年跟王掌柜有业务往来的所有商号,后来都怎么样了?东局的掌柜对着关系图一路追下去,追出了十二家商号的后续交易记录。问的人非常满意,说这图真有用。

但东局也有查不到的东西。有一次有人拿了一幅布料的图案来问这个花纹有没有历史记录。东局翻遍了关系图,没有哪个节点连着花纹,所有记录都是文字。这个问题在东局成了悬案。

西局第一次显本事是有人拿了一本带插图的货品册子来查性能参数。西局把插图和文字一起录入,搜图案直接找到了对应的参数表。掌柜说这才是真正的多模态。

但西局遇到了自己的问题。有一次查某商号的历史,要串起文字记录里的时间线和交易金额,西局搜出来的结果是一堆片段,片段之间的关系没有结构化,只能靠人工拼。掌柜说你们搜得全但不串,连不起来。

两局后来做了一次联合演示,来了一个复杂的查询:跟某个布商有关系的商人里,有没有人用过某种特定花纹,这种花纹在历史记录里最早出现在哪个朝代。东局先找到商人关系,西局再搜花纹和朝代,两边拼起来才答出来。

演示结束后,有人问两局掌柜:你们两个谁更好?两人都说自己的方向是对的,问题是对方解决的问题自己解决不了。老读者在旁边说了一句:你们争的不是谁更好,而是你们的读者需要的是关系还是多模态——需要关系你们就继续画图,需要多模态你们就继续收图画,但既需要关系又需要多模态的查询,你们两家单独都接不住。

Graph RAG

在文本检索增强生成基础上增加实体和关系图结构,能回答跨文档的关联性问题。建图成本高,但能改善涉及多跳推理的查询效果。

多模态 RAG

支持文本、图片、音频等多种数据格式的检索增强生成。能处理非结构化的多模态内容,但文字内部的关系结构仍然依赖文本检索本身的质量。

故事对应

  • 东局画人物关系和交易图:Graph RAG,用图结构改善跨文档关联查询
  • 西局把文字图画账本全放一起搜:多模态 RAG,统一处理多种数据格式
  • 查花纹历史在东局成悬案:Graph RAG 对非文本模态无能为力
  • 西局搜时间线和交易金额全是片段:多模态 RAG 缺乏关系结构,片段无法自动串联
  • 两局联合才答出复杂查询:两种 RAG 解决不同维度的问题,组合才能覆盖复杂场景
  • 读者需要关系还是多模态:先判断查询的主要复杂度来源,再选对应方案

落到 RAG 架构投入决策

判断该先建 Graph RAG 还是多模态 RAG 时,先看你的查询主要难在哪里。查询需要跨多个文档找关联、回答涉及多跳推理的问题,先建 Graph RAG。查询需要处理图片、音频、扫描件等多模态内容,先建多模态 RAG。如果两者都需要,那在建设任何一个之前,都要先评估你的文本检索基础是否足够好——多模态和图谱都依赖底层文本chunking和索引的质量,基础不牢,上层再复杂也是空中楼阁。