想象你是一位初来乍到的游客,想弄清“这座城市为什么会形成夜市文化”。普通 RAG 助手帮你做的事,是递上你手边那几张传单的局部索引——它飞快地翻找语义相近的句子,却答不出跨街区、跨时间的整体脉络。GraphRAG 则完全不同:它先花时间把整座城市“测绘”成一张地图——地标是实体,道路是关系;再按街区划分社区,为每个街区写摘要攻略;当你提问时,它同时用“语义联想”和“地图导航”两条腿走路,从任意地点出发,沿道路多跳穿行,最终带回一份跨越全局的答案。 这篇内容,就是带你用“城市地图”的心智模型,理解 GraphRAG 从建图、划区、检索到推理的完整链路。你不需要任何 AI 基础,只需要跟着故事走。

岗位关联

掌握 GraphRAG,意味着你从“会调检索接口”进阶到“懂知识组织”——这是知识密集型问答时代拉开差距的必修课,也是简历上最能体现工程深度的亮点之一。

目录
  1. 可视化演示
  2. RAG时代难题:传单翻找的盲区
  3. 知识图谱基础:地标与道路
  4. 图谱构建流程:测绘师画地图
  5. 社区检测聚合:街区划分与攻略
  6. 混合检索策略:导航与联想并用
  7. 多跳推理作答:沿街走巷拼答案
  8. 落地价值评估:从导航器到城市大脑
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

动态演示GraphRAG的核心机制,通过全局/局部/动态/静态四种模式展示关键概念与交互流程。

本节配有交互动效(进入视口后自动加载,约 3KB)。

GraphRAG:Grap GraphRAG核心思想与知识 实体关系抽取与图谱构建流程 核心机制可视化 GraphRAG整体架构与关键组件

RAG时代难题:传单翻找的盲区

你问一位只带传单的游客助手:“这座城市为什么能形成夜市文化?”它飞快地翻找手头每一张传单,找到了“夜市”二字的段落,却答不出演变原因——因为原因分散在不同街区的零散记录里,而传单与传单之间没有任何连接。传统 RAG 就是这样的传单翻找者:它把文档切块转成向量,每次只找回最“语义接近”的碎片,再把碎片塞给大模型。这种模式对“某某公司的桌游是什么”这类单点问题很管用,但对跨多个段落、需要全局视野的问题,碎片之间缺乏关联,答案往往会遗漏关键信息。

这就是 RAG 时代的三重难题。第一,向量检索局限:语义相似不等于事实相关,“讨论夜市”的段落未必包含“市政规划允许占道经营”这个关键前提。第二,全局问答痛点:像“这家公司从创立到上市经历了哪些关键融资”,答案散落在新闻、公告、访谈里,零散检索很难拼接。第三,碎片化上下文:切块后的段落失去与前后文档的结构联系,模型看到的是一堆孤岛,而非有组织的知识网络。

GraphRAG 的出发点正是补上这两块拼图:用知识图谱保存“片段之间的关系”,用社区结构提供“全局到局部的层次视野”。传单翻找者升级为城市地图导航员,问题从“哪张传单提到了它”变成“哪个地标、沿哪条道路、穿过哪个街区能到达它”。

知识图谱基础:地标与道路

要画城市地图,先要定义地标和道路。知识图谱里的实体(Entity)就是地标:OpenAI 是一栋大楼,Sam Altman 是一位居民,微软是一条商业街。关系(Relation)就是地标之间的道路:Sam Altman “创立” OpenAI,“微软 投资 了 OpenAI”,关系有方向、有名字。地标和道路组合起来,就构成了图结构——比散装传单多了一层“互联互通”。

一张完整的地图可以用一个简洁的公式定义:

有了地标和道路之后,地图还需要一种标准表达方式——三元组。每条道路写成一条记录:(头实体, 关系, 尾实体),例如 (Sam Altman, 创立, OpenAI)。这就像路牌上写“从 Sam 大楼,沿创立大道,到达 OpenAI 广场”。三元组是建图的基砖,也是后面检索时“沿路走”的依据。城市地图的骨架就此成形,下一步就是如何把一堆传单变成这张地图。

G=(V,E)\displaystyle G = (V, E)
公式说明:G 是整座城市的地图;V 是所有地标的集合;E 是所有道路的集合。知识图谱就是“实体 + 关系”的载体,它让你不只看到“这里有栋楼”,还能看清“楼与楼之间怎么走”。
  1. G 表示知识图谱整张“城市地图”就是图结构,一切增强检索都在这张图上展开。
    GG
  2. V 是实体集合(地标)图中的全部节点,如"OpenAI""Sam Altman"“微软”。
    V={e1,e2,…,eN}V = \{e_1, e_2, \dots, e_N\}
  3. E 是关系边集合(道路)节点间的有向关系,如“创立”"CEO"“投资”。
    E⊆V×VE \subseteq V \times V

图谱构建流程:测绘师画地图

地图不会凭空出现,需要测绘师上路。GraphRAG 的“测绘师”是抽取模型——它通读全部文档,做两件事:第一,实体抽取,识别文档里哪些词是地标(公司、人物、地点、时间);第二,关系抽取,判断地标之间是什么道路(创立、收购、位于、任职)。大模型可以基于提示词直接从文本中抽取三元组,例如从“Sam Altman 于 2015 年参与创立 OpenAI”中抽出 (Sam Altman, 创立, OpenAI)。

抽取环节不只做判断,还要给每个判断打分。一个三元组是否可信,取决于三个子环节的置信度:

测绘完成后,还要做一次“噪音过滤”:置信度过低的边宁可不要,否则地图上会出现许多走不通的断头路。与此同时,向量索引仍然保留——就像地图上每个地标还贴了一张“语义标签”照片。建图过程通常离线进行,成本高但一次建成、长期复用。测绘师收工后,下一步是给这座城分区。

P(triple∣text)=Phead×Prelation×Ptail\displaystyle P(\text{triple} \mid \text{text}) = P_{\text{head}} \times P_{\text{relation}} \times P_{\text{tail}}
公式说明:抽取一条三元组的总体置信度,等于“头实体识别正确”、“关系识别正确”、“尾实体识别正确”三个概率的乘积。任何一环拿不准,整条路的可信度都会明显下滑。
  1. 识别头实体(head)抽取模型判断文本中哪个片段是头实体,例如把“Sam Altman“识别为”人物”。
    PheadP_{\text{head}}
  2. 判定关系(relation)再判断这对实体间是什么关系,是“创立”还是“任职”。
    PrelationP_{\text{relation}}
  3. 识别尾实体(tail)找出关系的另一端,例如"OpenAI"。
    PtailP_{\text{tail}}
  4. 综合概率三个置信度连乘,得到三元组可信度总分。
    P(triple∣text)=Phead×Prelation×PtailP(\text{triple} \mid \text{text}) = P_{\text{head}} \times P_{\text{relation}} \times P_{\text{tail}}

社区检测聚合:街区划分与攻略

城市太大,导航员不可能记住每栋楼的全部细节。于是他按“地标密集程度”给城市划街区——写字楼聚集区、美食街区、老城居民区。GraphRAG 对应的操作叫社区检测(Community Detection):在图里寻找“内部连接紧密、对外连接稀疏”的子图,让彼此关系密切的实体聚成一组。比如 OpenAI、Sam Altman、微软形成一个“AI 产业社区”,虽然它们也和别的公司有联系,但组内联系远多于组间。

社区划分质量用模块度(Modularity)度量,它是社区检测算法的优化目标:

划完街区后,GraphRAG 的独门绝技登场——层次化摘要。为每个社区生成一段“街区攻略”式摘要,例如“该社区涵盖 AI 初创公司及其投资人关系”;再把社区两两聚合,生成更高级别的摘要,形成“城市 → 街区 → 地标”的层次。检索时可以先匹配街区攻略,再进入街区找地标,大幅降低全局问题的搜索成本。

Q=12m∑ij[Aij−kikj2m]δ(ci,cj)\displaystyle Q = \frac{1}{2m} \sum_{ij} \left[ A_{ij} - \frac{k_i k_j}{2m} \right] \delta(c_i, c_j)
公式说明:Q 越大,说明社区划分越“像样”——社区内部边数显著多于随机连线时的期望值。算法不断调整分组方式,让 Q 最大化,就像测绘师反复调整街区边界,让每个街区真的“自成一圈”。
  1. Q 表示模块度衡量社区划分好坏的总分,范围通常在 -1 到 1 之间。
    QQ
  2. Aij 表示邻接矩阵节点 i 和 j 之间有一条边则为 1,否则为 0。
    Aij=1如果(i,j)有边A_{ij} = 1 \quad \text{如果} (i,j) \text{有边}
  3. 期望边数基线ki 和 kj 是节点度数,2m 是总度数,这一项代表随机连接时 i、j 之间“碰巧”相连的期望边数。
    kikj2m\frac{k_i k_j}{2m}
  4. 同社区判断δ 函数在 i、j 同社区时取 1,否则为 0,只统计社区内部的偏差。
    δ(ci,cj)\delta(c_i, c_j)
  5. 归一化除以 2m 让分数不随图规模膨胀。
    12m\frac{1}{2m}

混合检索策略:导航与联想并用

游客提问“这家做语音助手的公司,投资过哪些大模型团队?”这里有两个信号需要同时处理:一是“语音助手”是语义近似,查询词不会精确等于公司名;二是“投资过”是结构关系,需要沿图里的投资边寻找。GraphRAG 的做法是双通道混合检索。

通道一,向量相似匹配:把查询和实体/社区摘要都转成向量,算语义相似度,负责“听音辨位”——即使游客说的是“做音箱的公司”,也能联想到对应实体。通道二,图谱路径扩展:从种子实体出发,沿关系边扩展一跳、两跳,把邻居和邻居的邻居全部纳入候选,负责“沿路寻访”。最后把两个通道的得分融合:

混合检索的意义在于互补:向量检索擅长“用户没说准”的开放表述,图谱检索擅长“必须走关系”的结构化追问。两者结合,导航员既听得懂你含含糊糊的描述,又能精确丈量地标之间的距离。

S(q,e)=α⋅Simvec(q,e)+β⋅Simgraph(q,e)\displaystyle S(q, e) = \alpha \cdot \text{Sim}_{\text{vec}}(q, e) + \beta \cdot \text{Sim}_{\text{graph}}(q, e)
公式说明:候选实体 e 对查询 q 的最终得分,由向量相似度与图谱路径得分加权求和得来。α 控制“语义联想”权重,β 控制“结构导航”权重,通常 α + β = 1。单纯语义像但图上不相连的实体,或图上相连但语义无关的实体,都不会拿高分。
  1. 查询 q 与候选实体 e一次提问会产生一批候选实体,逐个打分排序。
    q,eq, e
  2. 向量相似度 Sim_vec查询与实体的语义相似度,来自向量检索通道。
    Simvec(q,e)\text{Sim}_{\text{vec}}(q, e)
  3. 图谱路径得分 Sim_graph查询种子节点与候选实体在图上的连通强度,来自图检索通道。
    Simgraph(q,e)\text{Sim}_{\text{graph}}(q, e)
  4. 加权求和α 和 β 是调和两个信号的比例,两个通道都能加分。
    S(q,e)=α⋅Simvec(q,e)+β⋅Simgraph(q,e)S(q, e) = \alpha \cdot \text{Sim}_{\text{vec}}(q, e) + \beta \cdot \text{Sim}_{\text{graph}}(q, e)

多跳推理作答:沿街走巷拼答案

有些问题,答案不在任何一个地标里,而在一段旅程的终点。“谁投资了那家做语音助手公司的最大股东?”——导航员需要先定位语音助手公司(跳 1),沿“股东”边找到最大股东(跳 2),再沿“投资”边找到目标公司(跳 3)。这种跨越多个关系边的查询,叫多跳推理(Multi-hop Reasoning),是 GraphRAG 相对传统 RAG 的核心优势之一。

多跳检索时,路径得分会随跳数衰减,因为离出发点越远,与问题直接相关的概率越低:

拿到多条候选路径后,模型并不急着回答——它先做上下文聚合:把路径上的实体、中间关系、沿途社区的摘要一起打包,形成一段“带完整来龙去脉”的上下文。比如把“语音助手公司 ← 股东 ← 投资方”的整条链送给大模型,再由大模型生成最终回答。这就像向导把沿途看到的店铺、路牌、街区历史都记录下来,最后给你一个完整故事,而不是一句干巴巴的答案。

Scorepath=∑i=1nγi⋅si\displaystyle \text{Score}_{\text{path}} = \sum_{i=1}^{n} \gamma^{i} \cdot s_i
公式说明:一条 n 跳路径的总得分,等于每一跳的局部得分乘以衰减系数后求和。γ 是 0 到 1 之间的衰减率,跳数越深,权重指数级下降,防止检索跑偏到十万八千里外。
  1. 第 i 跳得分 si每走一条关系边,模型对该边与问题相关性的打分。
    sis_i
  2. 衰减系数 γi跳数越深权重越小,比如 γ=0.5 时第二跳只剩一半权重。
    γi,0<γ<1\gamma^{i}, \quad 0 < \gamma < 1
  3. 路径总分把所有跳的加权得分累加,得到整条路径的检索质量。
    Scorepath=∑i=1nγi⋅si\text{Score}_{\text{path}} = \sum_{i=1}^{n} \gamma^{i} \cdot s_i

落地价值评估:从导航器到城市大脑

当导航器不仅能指路,还能回答“整座城市为何堵车”这类全局问题时,它就升维成了城市大脑。GraphRAG 的价值,正在于把“检索”从找碎片升级为“理解全局”。最典型的落地场景有三类。

企业知识全局问答:审计师问“该供应商与公司股东之间是否存在未披露的关联交易”,答案散落在合同、股权结构、董事会决议等多个文档里。GraphRAG 沿“股权”与“任职”关系边跨文档穿行,把分散关联聚合成一条可追溯的证据链。科研综述辅助:研究员问“近五年知识蒸馏在医学影像中的应用脉络”,GraphRAG 从论文库抽取“方法—任务—数据集”三元组,通过社区摘要勾勒宏观研究版图。医疗档案全局问答:问“患者三年内用过哪些含激素药物”,跨就诊记录的关系图谱把时间、诊断、处方连成个人健康轨迹。

但 GraphRAG 不是银弹,它有三个现实约束。第一,构建成本高:实体关系抽取与社区检测需要离线计算资源,小规模知识库可能得不偿失。第二,抽取质量瓶颈:抽取模型看走眼,地图上就会多出一条错误道路,后续检索将“一路错到底”。第三,动态更新难:文档频繁更新时,图谱需要增量维护,比向量库追加索引复杂得多。一句话:当你的问题需要“跨文档找关系”时,GraphRAG 是城市大脑;当问题都是单点查证时,普通传单翻找也许更轻快。

AI 应用场景

应用场景 1:企业跨文档审计问答

阶段:图谱构建 + 多跳检索

解决的问题:审计师需要跨采购合同、股权结构表、董事会决议等多个文档回答“供应商与我方股东是否存在关联”,传统 RAG 只能分别检索各文档片段,无法把分散的持股与任职关系串联成证据链。GraphRAG 将文档抽取为公司、个人、职位、持股比例等实体与关系,检索时沿“投资”“任职”“控股”边多跳穿行,一次给出完整的关联路径。

具体案例:某会计师事务所部署 GraphRAG 后,审计师输入“高管亲属是否在该供应商任职”,系统沿“高管—家属—任职—供应商”路径返回证据链,单次查询由原来人工翻阅两小时缩短到三分钟。

应用场景 2:科研文献综述辅助

阶段:社区检测 + 层次化摘要

解决的问题:写综述时,研究员需要掌握“某方向近五年的研究脉络”,论文之间通过“提出”“改进”“应用于”等关系互相引用与演进,普通向量检索只能给出单篇相似论文,无法呈现学科分支结构。GraphRAG 的社区检测把论文按关系密度聚成研究分支,每个分支生成摘要,让研究员先看全景再看单篇。

具体案例:某 AI 实验室用 GraphRAG 构建内部论文库,输入“知识蒸馏在医学影像的应用演化”,系统返回三个社区分支摘要——模型压缩类、半监督类、跨模态类,并附每篇论文的关键路径。

应用场景 3:医疗档案全局问答

阶段:实体抽取 + 混合检索

解决的问题:患者跨多次就诊、多科室留下的记录分散在电子病历中,医生问“三年内是否用过含激素药物”时,需要跨时间、跨科室拼接处方与诊断。GraphRAG 把每次就诊抽成“诊断—用药—科室”三元组,按时间与身体系统连成个人健康图谱。

具体案例:某医院试点系统接入三年病历,问“患者对青霉素类药物的既往反应”,系统沿“过敏史—药物—不良反应”路径返回 2021 年与 2023 年两次记录,并提示关联的替代药物。

Python 演示

python105 行
import mathimport re  class LightGraph:    def __init__(self):        self.entity_list = []        self.relations = {}        self.community_map = {}     def add_relation(self, head, tail, rel):        if head not in self.entity_list:            self.entity_list.append(head)        if tail not in self.entity_list:            self.entity_list.append(tail)        self.relations.setdefault(head, []).append((tail, rel))     def detect_communities(self, rounds=4):        comm_map = {e: i % 3 for i, e in enumerate(self.entity_list)}        for _ in range(rounds):            for e in self.entity_list:                counts = {}                for neighbor, _ in self.relations.get(e, []):                    if neighbor in comm_map:                        cid = comm_map[neighbor]                        counts[cid] = counts.get(cid, 0) + 1                if counts:                    comm_map[e] = max(counts, key=counts.get)        self.community_map = comm_map  def token_set(text):    return set(re.findall(r'[\u4e00-\u9fa5a-zA-Z0-9]+', text))  def cosine_sim(text_a, text_b):    set_a = token_set(text_a)    set_b = token_set(text_b)    if not set_a or not set_b:        return 0.0    common = len(set_a & set_b)    return common / math.sqrt(len(set_a) * len(set_b))  def extract_triples(docs):    triples = []    ceo_pattern = re.compile(r'([\u4e00-\u9fa5A-Za-z]+)\s*的\s*CEO\s*是\s*([\u4e00-\u9fa5A-Za-z]+)')    founder_pattern = re.compile(r'([\u4e00-\u9fa5A-Za-z]+)\s*创立了\s*([\u4e00-\u9fa5A-Za-z]+)')    for doc in docs:        for m in ceo_pattern.finditer(doc):            triples.append((m.group(1), 'CEO', m.group(2)))        for m in founder_pattern.finditer(doc):            triples.append((m.group(1), '创立', m.group(2)))    return triples  def retrieve(query, graph, top_k=3, max_hop=2, alpha=0.6):    vec_score = {}    for e in graph.entity_list:        vec_score[e] = cosine_sim(query, e)    seeds = sorted(vec_score.items(), key=lambda x: x[1], reverse=True)[:top_k]    hop_score = {}    for seed, base in seeds:        frontier = [(seed, base, 0)]        visited = set()        while frontier:            current, score, depth = frontier.pop()            visited.add(current)            hop_score[current] = max(hop_score.get(current, 0.0), score)            if depth < max_hop:                for neighbor, _ in graph.relations.get(current, []):                    if neighbor not in visited:                        frontier.append((neighbor, score * 0.5, depth + 1))    result = []    for e in graph.entity_list:        total = alpha * vec_score.get(e, 0.0) + (1 - alpha) * hop_score.get(e, 0.0)        result.append((e, total))    result.sort(key=lambda x: x[1], reverse=True)    return result[:top_k]  def build_company_kg():    graph = LightGraph()    docs = [        'OpenAI 的 CEO 是 Sam Altman。',        'Sam Altman 创立了 OpenAI。',        '微软的 CEO 是 Satya Nadella。',        '微软投资了 OpenAI。',        'DeepMind 的 CEO 是 Demis Hassabis。',        'Google 收购了 DeepMind。',    ]    for head, rel, tail in extract_triples(docs):        graph.add_relation(head, tail, rel)    graph.add_relation('微软', 'OpenAI', '投资')    graph.detect_communities()    return graph  if __name__ == '__main__':    graph = build_company_kg()    query = '谁创立了OpenAI'    hits = retrieve(query, graph)    for entity, score in hits:        print('实体:', entity, '得分:', round(score, 3))    print('社区划分:', graph.community_map)
目的:这是一个极简版 GraphRAG 原型——用正则模板从文档抽取三元组构建知识图谱,用标签传播做社区检测,再用“向量相似 + BFS 多跳”混合检索回答“谁创立了 OpenAI”。
  1. extract_triples(docs)用正则模板从文档中抽取 (头实体, 关系, 尾实体) 三元组,模拟真实场景中的实体关系抽取。
  2. graph.add_relation(head, tail, rel)把三元组装进图结构,同时维护实体列表和邻接关系表。
  3. detect_communities()用简单的标签传播贪心算法模拟社区检测,让每个实体的社区跟随多数邻居。
  4. cosine_sim(text_a, text_b)基于词集合的余弦相似度,充当简化版“向量相似匹配”。
  5. retrieve(query, graph, top_k, max_hop, alpha)先用相似度找种子实体,再从种子出发 BFS 多跳扩展并对跳数衰减。
  6. total = alpha * vec_score.get(e, 0.0) + (1 - alpha) * hop_score.get(e, 0.0)混合检索的融合打分,向量通道与图通道按 α 加权。

常见误区

误区“GraphRAG 是新一代 RAG,既然有知识图谱了,向量检索就应该被淘汰,否则就不叫 GraphRAG。”

正解GraphRAG 的精髓恰恰是“混合”——它用向量检索处理语义联想,用图谱检索处理结构导航,最后加权融合。就像一位好的城市向导,既要有地图(图谱)认路,也要听得懂你含含糊糊的方言描述(向量)。少了向量通道,开放表述的问题会找不到地标;少了图谱通道,跨实体关系的问题会答非所问。

为何常见:名字里带"Graph"容易让人误以为用图替代了一切,忽略了 GraphRAG 是对 RAG 的增强而非替换。

误区“知识图谱构建完成后,所有问题都能答对,因为知识都在图里了。”

正解图只是容器,质量取决于抽取环节。测绘师看错路牌,地图上就会多一条错误道路;抽取模型把“不看好”抽成“投资”,后续检索就会沿着错误道路一路走偏。真实工程中,实体抽取和关系抽取的准确率直接决定 GraphRAG 的召回质量,“垃圾进、垃圾出”同样适用于图谱。

为何常见:人们容易把“结构化存储”误当成“语义理解”,忽略了建图本身就是一个有损耗的认知过程。

误区“GraphRAG 这么强,把所有 RAG 系统都换成它,查询快、回答准,还能省钱。”

正解图谱构建是离线过程,实体关系抽取、社区检测、层次摘要都需要不少计算成本;文档频繁更新时,增量维护图也比追加向量索引复杂。单点问答场景下,普通 RAG 更快更经济;只有跨文档、全局性的问题频繁出现时,GraphRAG 的“慢建图、快检索、答得全”才划算。

为何常见:只看到检索阶段的效率提升,忽略了建图阶段的巨额一次性成本与维护成本。

误区“社区检测就是给实体算相似度,然后把语义接近的分到一组,比如把 AI 公司的实体都放一起。”

正解社区检测看的是图结构上的“连接密度”,不是文本语义相似度。OpenAI 和微软文本上差异很大,但关系边很多,所以会聚到同一社区。反过来,两家语义相近却不连边的公司不会同区。社区检测追求的是模块度最大化——真实世界里“常有来往的街区”才是社区,而非“名字像的街区”。

为何常见:把“聚类”的通用直觉套用到图上,忽略了社交网络中“结构邻近”与“属性相似”的本质区别。

误区“知识图谱不就是把三元组存成一张三列表格吗?跟普通数据库没区别。”

正解表格适合按行查询,图谱的核心价值是“沿边遍历”——支持从任意实体出发,寻找任意跳数的关系路径。对应到城市地图,表格是地标名录,图谱是带道路网的地图。GraphRAG 的多跳推理、社区检测、路径得分都依赖图的遍历能力,这是普通关系型数据库难以高效表达的。

为何常见:从存储形态看,三元组确实可以放进表里,但忽略了图谱的算法价值在于拓扑结构而非存储格式。

面试题

Q1. GraphRAG 与传统 RAG 的本质区别是什么?

单选题 · easy

  • A.彻底删掉语义向量检索模块
  • B.在向量之外用知识图谱组织知识← 正确答案
  • C.只需词频字典而不需神经网络
  • D.仅用于处理关系型数据库表

答案:B。GraphRAG 不是推翻向量检索,而是在向量之外引入知识图谱,形成“向量 + 图”双通道。A 错在“彻底删掉”,实际是混合共享;C 与 D 都不符合 GraphRAG 对大模型和文本建图的基本依赖。B 准确描述了 GraphRAG 的定位——传统 RAG 之上的增强。

Q2. 在知识图谱中,“边”最主要的作用是什么?

单选题 · mid

  • A.表示两个实体之间有语义关系← 正确答案
  • B.用来表示文本的分页边界
  • C.记录文档的段落编号顺序
  • D.存储神经网络的隐藏层权重

答案:A。边(关系)连接两个实体节点,表达“创立”“投资”“任职”等语义关系,这是知识图谱的核心。段落编号与分页是文档结构,隐藏层权重是模型结构,都不是图上的边。类比城市地图,边就是连接地标的道路,路存在的意义是让导航员能沿它走到下一个地标。

Q3. 从文档中按三元组抽取知识时,最关键的质量风险是什么?

单选题 · mid

  • A.向量索引文件太大
  • B.实体与关系抽取不准确← 正确答案
  • C.社区摘要生成的文字太长
  • D.用户提问的语气不够正式

答案:B。图谱质量完全取决于实体抽取与关系抽取的准确率,抽错了后面的检索会沿错误道路一路走偏,这是“垃圾进、垃圾出”。向量文件大小、摘要长度、提问语气都不是建图阶段的核心风险。就像测绘师把道路画错,再好的导航系统也会把人导进死胡同。

Q4. GraphRAG 检索阶段可能融合哪些信号?

多选题 · hard

  • A.查询词与实体的向量相似度← 正确答案
  • B.图中从查询实体出发的路径得分← 正确答案
  • C.全库文档的总字数统计
  • D.查询与社区摘要的匹配程度← 正确答案

答案:ABD。GraphRAG 的混合检索融合向量相似度、图路径得分,以及社区摘要匹配度——后者帮助从“街区攻略”层面先定位区域再深入。文档总字数与检索相关性完全无关,是无效信号。A 是语义通道,B 是结构通道,D 是层次摘要通道,三者共同构成 GraphRAG 的多信号融合基础。

Q5. 以下哪类问题最适合使用 GraphRAG?

单选题 · mid

  • A.查询一个词条的身高体重数据
  • B.跨多个文档追踪公司股权关联← 正确答案
  • C.检索单个段落中的人名地名
  • D.询问与知识无关的日常闲聊

答案:B。GraphRAG 擅长跨文档、跨实体的关系追踪,股权关联是典型的多实体多跳问题。单点数值查询(A)、单段落检索(C)用传统 RAG 更轻快,闲聊(D)不需要知识库。类比城市导航:问“这条路多长”看传单即可,问“这条产业链如何传导”才需要跨街区找关系的地图。

Q6. 社区检测在 GraphRAG 中的直接产出是什么?

单选题 · easy

  • A.把所有实体合并成一个节点
  • B.把图划分成多个内部密集连接的社区← 正确答案
  • C.让所有节点各自成为独立社区
  • D.用随机排序代替实体的连接关系

答案:B。社区检测的目标是把图划分为“内部连接紧密、对外连接稀疏”的社区,之后每个社区生成摘要。A、C、D 分别犯了合并、打散、随机化的错误。就像给城市划街区,划区的标准是居民之间往来频繁程度,而不是把所有楼堆一起或彻底拆开。

Q7. 多跳推理在 GraphRAG 检索中的核心价值是什么?

单选题 · hard

  • A.让模型多次随机采样无关文本
  • B.沿图路径聚合间接相关的信息← 正确答案
  • C.限制答案只能来自一跳内邻居
  • D.减少上下文长度以降低计算量

答案:B。多跳推理的价值在于把“隔着好几层关系”的信息聚合起来——比如股东的投资对象,需要沿“创立→投资”走两跳才能到达。C、D 正好与多跳方向相反,A 是随机采样,毫无结构意义。类比问路:目的地不在邻街,就要沿大道走几个街区才能到达。

Q8. 层次化摘要(社区摘要)在 GraphRAG 中的作用有哪些?

多选题 · mid

  • A.对每个社区生成概括性文本← 正确答案
  • B.为全局问答提供宏观上下文← 正确答案
  • C.完全替代所有向量索引文件
  • D.检索时先匹配街区再深入实体← 正确答案

答案:ABD。层次化摘要先为每个社区生成概括,检索时先与社区摘要匹配定位“哪个街区”,再进入具体实体,同时为全局问题提供宏观视野。它不会替代向量索引,两者是不同维度的补充。就像城市攻略手册:先看“美食区概况”决定去哪个街区,再问街区里具体哪家店。

Q9. 关于 GraphRAG 图谱构建成本,以下说法正确的是?

单选题 · easy

  • A.图谱离线构建、成本高但可持续复用← 正确答案
  • B.每次查询都要重新从头构建图谱
  • C.构建图谱完全不需要计算资源
  • D.构建过程只发生在推理阶段在线运行

答案:A。图谱构建通常在离线阶段完成,涉及实体关系抽取、社区检测、摘要生成等操作,成本较高,但一次建成后可供多次检索复用。B 和 D 混淆了构建与查询的时机,C 否定成本的存在。类比画城市地图:测绘成本高,但画好之后每天导航都用同一张图。

Q10. 关于向量检索与图谱检索的关系,下列说法正确的是?

多选题 · hard

  • A.两者完全独立且不可结合使用
  • B.向量检索擅长语义近似而图谱擅长多跳结构← 正确答案
  • C.把向量嵌入图节点可实现两种信号混合← 正确答案
  • D.图谱检索必须完全替代向量检索

答案:BC。向量检索适合“没问准”的开放描述,图谱检索适合“必须走关系”的结构追问,二者互补(B);工程上可以把实体向量嵌入图节点标注,实现两通道混合(C)。A 否定结合可能,D 要求替代,都与 GraphRAG 的混合设计相悖。就像导航员既听语音联想又看地图路径,缺一不可。