前面一篇我在讲UniGraph这一篇我想直接讲一个更技术的问题知识图谱问答和现在大家更熟悉的普通 RAG到底差在哪这个问题我之所以想写不只是因为它是一个热点概念而是因为我自己在UniGraph项目里主要参与的正是最后“知识图谱应用 / 图谱问答”这一部分。前面团队里另外两位同学更多负责图谱设计和图谱构建我更关心的是前面构出来的图最后到底怎么变成真正能问、能答、能解释的系统。先说结论普通 RAG 解决的是“找相关内容”知识图谱问答解决的是“按结构找答案”如果先用一句最直接的话来区分我会这样说普通 RAG更像是“先去文档里找几段最相关的内容再把这些内容交给大模型组织成答案”知识图谱问答更像是“先在实体、关系、路径和结构里找到真正相关的知识再决定把哪些文本和哪些结构一起交给模型生成答案”。这两者都不是“纯大模型直接瞎答”都属于“先检索再生成”。但它们检索的对象其实不一样。普通 RAG 主要检索的是文本切片、段落、chunk而知识图谱问答检索的核心对象通常是实体、关系、邻居节点、路径、子图必要时再把相关文本一并带上。这也是为什么我觉得很多讨论一上来就把两者混成一类其实会把真正的技术差异讲浅。普通 RAG 更像在纸堆里找相似段落知识图谱问答更像围绕实体、关系、来源和社区去组织答案。普通 RAG 到底在做什么2020 年的 RAG 论文《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》里给出的核心思路很明确把参数化知识和外部检索结合起来让模型在生成之前先从外部知识库里取回相关内容。论文里使用的是一个基于Wikipedia的稠密向量索引然后再把取回的 passage 交给生成模型。论文摘要里也明确提到大模型本身在知识访问、知识精确操作、知识更新和答案来源说明上都有明显限制所以要引入显式的非参数记忆。翻成更工程化的话普通 RAG 大概就是这条链用户问题先向量化去向量库里召回最相似的若干文本块对召回结果做重排或筛选把这些文本块塞进上下文让大模型基于这些文本块生成答案。这个方法为什么这么流行因为它很实用。你只要有一批文档切块、向量化、建索引系统就能很快跑起来。对于很多“答案就在文档某几段里”的问题普通 RAG 已经足够好用。比如某个产品文档里某个参数是多少某个制度说明里某条规则怎么写某篇论文里某个方法的基本步骤是什么。这类问题的特点是相关信息通常能在局部文本里找到。只要召回够准模型就能答得不错。但普通 RAG 一旦遇到三类问题就容易开始吃力。第一类问题不是找一段话而是找实体之间的关系普通 RAG 的召回单位本质上还是文本块。它擅长回答“哪段文档和这个问题最像”但不天然擅长回答“哪个实体和哪个实体之间通过什么关系连起来”。如果问题真正依赖的是结构关系而不是某段原文的字面相似度那么只靠向量相似度就容易偏。举个很简单的例子如果用户问的不是“某种病害是什么”而是“某种种植技术是通过哪些作物轮作方式去降低某个病害发生率的”这时候真正关键的可能已经不是一段描述而是技术实体是什么作物实体是什么病害实体是什么它们之间是什么关系关系有没有量化结果或来源说明。这时候系统如果只是在若干 chunk 里找语义最像的段落很可能能“找到相关内容”但不一定能把关系说清楚。第二类问题需要多跳不是单段命中很多真实问题并不是一个文本块就能答出来。它可能需要先找到一个实体再沿着它的关系找到另一个实体然后再回到原文里看证据。这种多跳过程本来就是图结构更擅长表达的东西。如果只用普通 RAG系统往往会碰到两个问题召回结果分散在多个 chunk 里彼此之间缺少显式连接模型虽然能“读很多段”但这些段之间的关系需要它自己临时猜出来。这就很容易出现一种现象答案看起来通顺但链路并不稳。第三类问题需要全局理解不只是局部命中这点是我觉得普通 RAG 最容易被高估的地方。微软 GraphRAG 文档里对这一点说得很直接baseline RAG 很难处理那种需要对整个数据集做聚合和归纳的问题因为它依赖的是“语义相似文本检索”而不是数据集整体结构。比如这类问题这个领域最核心的几个主题是什么哪些实体在整个数据里最关键某类关系在全局上呈现什么分布一个问题背后牵涉到哪些知识簇而不只是哪个片段。这时候你会发现普通 RAG 不是完全不能答而是它很容易变成“拿到几段相似文本后做局部总结”但很难自然地形成全局结构视角。知识图谱问答多做了什么如果说普通 RAG 的核心是“chunk 检索 LLM 生成”那知识图谱问答至少多做了三层事情。第一层先把知识对象化而不是只切文本普通 RAG 预处理文档时最常见的操作是切 chunk、建 embedding、建向量索引。知识图谱系统则更进一步它会先尝试把文档里的知识对象化哪些是实体哪些是关系哪些是属性哪些是来源文本哪些实体和关系属于同一个局部结构。也就是说文本不再只是“被切碎等待检索”的材料而是会被组织成一个更可计算的知识结构。这一步看起来比普通 RAG 重很多但也正是它后面能做结构推理和关系解释的前提。第二层查询时不是只召回文本而是先找实体和关系微软 GraphRAG 的Local Search文档里写得很清楚局部搜索会把知识图谱里的结构化数据和原始文档里的非结构化数据一起作为上下文来源它会先识别与问题语义相关的实体再进一步取实体关联的文本单元、社区报告、相关实体和关系最后筛选出能放进上下文窗口里的内容。这和普通 RAG 的差别其实已经很明显了。普通 RAG 更像问题相似文本答案而知识图谱问答更像问题相关实体相关关系邻居节点 / 子图 / 路径对应来源文本最终答案也就是说它在“生成答案”之前多了一层结构约束。这层约束的价值就在于系统不是单纯根据“哪段话像”而是会考虑“哪个实体真的相关”“哪条关系真的连得上”“哪些文本是这条关系的证据”。第三层答案不只是生成出来还要能解释从哪来这一点和我自己在 UniGraph 里最关心的东西很接近。如果问答系统最后只能给一句流畅答案但解释不了它基于哪些实体它沿着哪些关系推出来它引用了哪些来源文本它属于哪个更大的知识范围那它在很多场景里其实还是不够让人放心。而知识图谱问答天然更适合把这些东西一起带出来。在 UniGraph 里知识图谱应用界面给我的一个很直观感受就是它不是只追求“回答一句像人说的话”而是会尽量把整体知识概览、重点知识细节、相关知识关联、具体信息来源一起暴露给用户。这其实已经不是“普通 RAG 回答器”的思路了而是更接近“结构化知识问答系统”的思路。如果按 UniGraph 这套实现往下拆它和普通 RAG 的差别会更具体前面讲的是原理层的区别如果再往工程实现里压一层差别其实会更明显。UniGraph 这条问答链路不是简单的“向量库 提示词拼接”而是先把图谱里的局部信息和全局信息都做了一次预处理和平坦化。它至少包含这几类中间结构Entity Attributes Vector Table把实体的ID、名称、属性、属性值组织成表再做向量化Triple Source Table把实例三元组和它对应的信息源绑在一起Community Report把全局图结构划分成多级社区后再为每个社区生成报告最终问答上下文把实体、关系、信息源、社区四类上下文融合再交给 LLM 回答。这套东西和普通 RAG 最大的不同在于普通 RAG 的中间件通常围绕“文档切块”展开而 UniGraph 这类图谱问答系统的中间件是围绕“实体、关系、来源、社区”展开的。从问题嵌入、实体属性向量匹配到 Top20 实体召回、关系扩展、信息源回填、社区匹配再到四类上下文融合。普通 RAG 通常先找 Top-K chunkUniGraph 这套链路先找 Top20 实体这部分是我觉得最值得讲清楚的技术差别。UniGraph 不是先拿用户问题去匹配文档 chunk而是先把用户问题做嵌入表示再和实体名称 属性/属性值的向量做相似度匹配筛出相似度最高的前 20 个实体。这意味着系统回答问题时第一步锁定的不是“哪几段文本最像”而是“哪几个实体最相关”。这个差别很关键。因为只要你的第一步召回对象不同后面整条链路都会变普通 RAG 后面接的是文本重排图谱问答后面接的是实体映射、关系扩展、来源定位、社区匹配。也就是说普通 RAG 的第一步更像“先找相关段落”而 UniGraph 这套问答更像“先确定问题真正打中了哪些知识对象”。UniGraph 不是只拼一个上下文而是拼四类上下文按材料里的写法UniGraph 的回答上下文至少分四部分构建1. 实体上下文先把相似度排序后的前 20 个实体本身整理出来交给 LLM 生成实体上下文。这一步回答的是当前这个问题最相关的知识对象有哪些。2. 关系上下文围绕这 20 个实体系统会继续去图里找关系。材料里把这一步拆成了“内网络”和“外网络”内网络这些候选实体之间直接相连的关系外网络这些候选实体通过其他节点形成的间接关系。然后再按边权重、关系度数这些指标排序整理成关系上下文。这一层其实就是普通 RAG 很难天然补上的部分。因为普通 RAG 就算召回了几段相关文本也不太会自动帮你构出“这些对象之间到底是怎么连起来的”。3. 数据源上下文这一步是我很看重的因为它直接关系到回答能不能站得住。UniGraph 的做法不是只拿实体和关系本身而是继续把它们映射回实例三元组信息源表格把对应来源一起找出来再按实体相关性排序形成数据源上下文。也就是说它不是只回答“系统觉得是这样”而是会继续回答“系统为什么这么觉得依据来自哪里”。4. 社区上下文这一层就是普通 RAG 更少会去显式处理的全局信息。UniGraph 会把候选实体再映射到社区报告里统计它们落在哪些社区然后根据命中的实体数量和社区层级排序再形成社区上下文。这一步回答的是这个问题除了局部实体关系还落在整个知识图谱的哪一块结构里。所以从技术实现上看UniGraph 这种图谱问答不是简单“多检索一点内容”而是把局部和全局两个视角都塞进了上下文构建里。这里面还有一个很重要的点全局信息不是凭空来的而是用 Leiden 多级社区做出来的这点也值得单独讲。在你给我的材料里全局信息不是一句很空的“我们考虑了全局”而是有明确处理流程的先把 KG 转成无向图用Leiden算法做社区划分从Level0开始逐层细分允许用户指定层级深度对每个社区提取实体属性再让 LLM 生成社区报告。这意味着所谓“全局信息”在这里并不是抽象概念而是已经被整理成了可检索、可排序、可进上下文的结构化对象。材料里社区报告包含的内容也比较完整包括社区标题摘要社区评级评级解释5 到 10 条关键发现社区内实体 ID。这也是为什么它和普通 RAG 的差别不只是“多了一张图”而是多了一整套面向全局结构的中间层。从这个角度看知识图谱问答其实更像“实体检索 图结构扩展 证据回填 全局补充”如果我把 UniGraph 这套链路用更压缩的话概括大概是这样用问题去匹配实体属性向量先召回 Top20 实体围绕实体扩展关系网络回填这些实体和关系对应的信息源再补上这些实体所在社区的全局报告把四类上下文融合后交给 LLM 生成答案。这和普通 RAG 的“问题 - Top-K chunk - 生成答案”相比中间明显多了两层一层是结构扩展一层是全局补充。这两层恰好就是图谱问答比普通 RAG 更重、但也更有解释力的地方。甚至连上下文的 token 配比这套系统都是显式设计过的这一点我觉得很能体现“它不是一个随便拼提示词的问答器”。在材料里四类上下文并不是无上限地往模型里塞而是做了明确的 token 分配实体上下文约占20%关系上下文约占20%数据源上下文约占40%社区上下文约占20%这个比例本身就能看出一条很清楚的设计思路实体和关系负责把问题“钉”在局部结构上数据源占比最高说明回答最终还是要尽量回到证据社区信息负责补全全局视角避免回答只停留在局部命中。如果从问答系统设计的角度看这已经不是“把召回内容塞给模型”这么简单而是在做一种面向可解释性的上下文编排。实体、关系、数据源、社区不是随便拼进去的而是有各自明确的构建机制和 token 配比。如果结合 UniGraph 来看两者最本质的差别不是有没有用大模型而是前面有没有图层我现在越来越倾向于用一句更工程的话来总结普通 RAG 是在文本层做增强知识图谱问答是在结构层和文本层同时做增强。这句话很重要。因为很多人一看“知识图谱问答”会以为它只是“RAG 换了个名字”或者“多加个 Neo4j 就行”。但如果真的从系统链路看差别不在最后都调不调用大模型而在于前面有没有一个可查询的图层。有了图层之后系统才有机会做这些事按实体而不是按段落组织知识沿关系扩展上下文把多跳链路显式化把局部问题和全局结构接起来给答案附带更清晰的解释路径。没有这层图很多事情并不是绝对不能做而是只能靠大模型在一堆文本里临时拼。那是不是说知识图谱问答一定比普通 RAG 更高级也不能这么简单下结论。我反而觉得真正合理的说法应该是普通 RAG 更轻更快起系统更适合文档问答知识图谱问答更重但更适合那些真正依赖实体关系、结构推理和可解释性的场景。如果你的问题大多数都能在单文档或少量 chunk 里解决那普通 RAG 很可能已经够用了没必要一上来就把系统做得很重。但如果你的问题天然长这样涉及多个实体和关系需要跨文档、多跳组织答案需要解释“为什么是这个答案”需要给出知识关联和来源链路那只靠普通 RAG后面很容易越补越乱。这也是为什么我会对知识图谱问答更感兴趣。它不是为了显得“更高级”而是因为有些问题到了那一步确实需要结构层。普通 RAG 不是不能答而是解释时更容易心虚知识图谱问答的优势在于能把答案、链路、来源一起交代出来。这也是我在 UniGraph 里更关注的部分前面那篇写 UniGraph 的时候我已经说过图谱设计和图谱构建主要是团队里另外两位同学做的我自己更直接参与的是最后知识图谱应用这一部分尤其是图谱问答。所以从我的视角看前面的知识库、架构设计、图谱构建、知识迁移、建立索引最后都不是为了“把图做出来”本身而是为了支撑最后这件事当用户真的问一个问题时系统能不能把图谱里的结构知识、原始文本里的证据、以及大模型的语言组织能力合成一个更有依据的回答。这也是我现在对“知识图谱问答和普通 RAG 到底差在哪”最直接的答案普通 RAG 更像在文档里找答案知识图谱问答更像在结构化知识里组织答案再回到文档里找证据。我觉得这个差别不只是学术定义上的差别而是你真把系统做起来之后很快就会碰到的工程差别。假如你从2026年开始学大模型按这个步骤走准能稳步进阶。接下来告诉你一条最快的邪修路线3个月即可成为模型大师薪资直接起飞。阶段1:大模型基础阶段2:RAG应用开发工程阶段3:大模型Agent应用架构阶段4:大模型微调与私有化部署配套文档资源全套AI 大模型 学习资料朋友们如果需要可以微信扫描下方二维码免费领取【保证100%免费】配套文档资源全套AI 大模型 学习资料朋友们如果需要可以微信扫描下方二维码免费领取【保证100%免费】
前面一篇我在讲UniGraph这一篇我想直接讲一个更技术的问题知识图谱问答和现在大家更熟悉的普通 RAG到底差在哪这个问题我之所以想写不只是因为它是一个热点概念而是因为我自己在UniGraph项目里主要参与的正是最后“知识图谱应用 / 图谱问答”这一部分。前面团队里另外两位同学更多负责图谱设计和图谱构建我更关心的是前面构出来的图最后到底怎么变成真正能问、能答、能解释的系统。先说结论普通 RAG 解决的是“找相关内容”知识图谱问答解决的是“按结构找答案”如果先用一句最直接的话来区分我会这样说普通 RAG更像是“先去文档里找几段最相关的内容再把这些内容交给大模型组织成答案”知识图谱问答更像是“先在实体、关系、路径和结构里找到真正相关的知识再决定把哪些文本和哪些结构一起交给模型生成答案”。这两者都不是“纯大模型直接瞎答”都属于“先检索再生成”。但它们检索的对象其实不一样。普通 RAG 主要检索的是文本切片、段落、chunk而知识图谱问答检索的核心对象通常是实体、关系、邻居节点、路径、子图必要时再把相关文本一并带上。这也是为什么我觉得很多讨论一上来就把两者混成一类其实会把真正的技术差异讲浅。普通 RAG 更像在纸堆里找相似段落知识图谱问答更像围绕实体、关系、来源和社区去组织答案。普通 RAG 到底在做什么2020 年的 RAG 论文《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》里给出的核心思路很明确把参数化知识和外部检索结合起来让模型在生成之前先从外部知识库里取回相关内容。论文里使用的是一个基于Wikipedia的稠密向量索引然后再把取回的 passage 交给生成模型。论文摘要里也明确提到大模型本身在知识访问、知识精确操作、知识更新和答案来源说明上都有明显限制所以要引入显式的非参数记忆。翻成更工程化的话普通 RAG 大概就是这条链用户问题先向量化去向量库里召回最相似的若干文本块对召回结果做重排或筛选把这些文本块塞进上下文让大模型基于这些文本块生成答案。这个方法为什么这么流行因为它很实用。你只要有一批文档切块、向量化、建索引系统就能很快跑起来。对于很多“答案就在文档某几段里”的问题普通 RAG 已经足够好用。比如某个产品文档里某个参数是多少某个制度说明里某条规则怎么写某篇论文里某个方法的基本步骤是什么。这类问题的特点是相关信息通常能在局部文本里找到。只要召回够准模型就能答得不错。但普通 RAG 一旦遇到三类问题就容易开始吃力。第一类问题不是找一段话而是找实体之间的关系普通 RAG 的召回单位本质上还是文本块。它擅长回答“哪段文档和这个问题最像”但不天然擅长回答“哪个实体和哪个实体之间通过什么关系连起来”。如果问题真正依赖的是结构关系而不是某段原文的字面相似度那么只靠向量相似度就容易偏。举个很简单的例子如果用户问的不是“某种病害是什么”而是“某种种植技术是通过哪些作物轮作方式去降低某个病害发生率的”这时候真正关键的可能已经不是一段描述而是技术实体是什么作物实体是什么病害实体是什么它们之间是什么关系关系有没有量化结果或来源说明。这时候系统如果只是在若干 chunk 里找语义最像的段落很可能能“找到相关内容”但不一定能把关系说清楚。第二类问题需要多跳不是单段命中很多真实问题并不是一个文本块就能答出来。它可能需要先找到一个实体再沿着它的关系找到另一个实体然后再回到原文里看证据。这种多跳过程本来就是图结构更擅长表达的东西。如果只用普通 RAG系统往往会碰到两个问题召回结果分散在多个 chunk 里彼此之间缺少显式连接模型虽然能“读很多段”但这些段之间的关系需要它自己临时猜出来。这就很容易出现一种现象答案看起来通顺但链路并不稳。第三类问题需要全局理解不只是局部命中这点是我觉得普通 RAG 最容易被高估的地方。微软 GraphRAG 文档里对这一点说得很直接baseline RAG 很难处理那种需要对整个数据集做聚合和归纳的问题因为它依赖的是“语义相似文本检索”而不是数据集整体结构。比如这类问题这个领域最核心的几个主题是什么哪些实体在整个数据里最关键某类关系在全局上呈现什么分布一个问题背后牵涉到哪些知识簇而不只是哪个片段。这时候你会发现普通 RAG 不是完全不能答而是它很容易变成“拿到几段相似文本后做局部总结”但很难自然地形成全局结构视角。知识图谱问答多做了什么如果说普通 RAG 的核心是“chunk 检索 LLM 生成”那知识图谱问答至少多做了三层事情。第一层先把知识对象化而不是只切文本普通 RAG 预处理文档时最常见的操作是切 chunk、建 embedding、建向量索引。知识图谱系统则更进一步它会先尝试把文档里的知识对象化哪些是实体哪些是关系哪些是属性哪些是来源文本哪些实体和关系属于同一个局部结构。也就是说文本不再只是“被切碎等待检索”的材料而是会被组织成一个更可计算的知识结构。这一步看起来比普通 RAG 重很多但也正是它后面能做结构推理和关系解释的前提。第二层查询时不是只召回文本而是先找实体和关系微软 GraphRAG 的Local Search文档里写得很清楚局部搜索会把知识图谱里的结构化数据和原始文档里的非结构化数据一起作为上下文来源它会先识别与问题语义相关的实体再进一步取实体关联的文本单元、社区报告、相关实体和关系最后筛选出能放进上下文窗口里的内容。这和普通 RAG 的差别其实已经很明显了。普通 RAG 更像问题相似文本答案而知识图谱问答更像问题相关实体相关关系邻居节点 / 子图 / 路径对应来源文本最终答案也就是说它在“生成答案”之前多了一层结构约束。这层约束的价值就在于系统不是单纯根据“哪段话像”而是会考虑“哪个实体真的相关”“哪条关系真的连得上”“哪些文本是这条关系的证据”。第三层答案不只是生成出来还要能解释从哪来这一点和我自己在 UniGraph 里最关心的东西很接近。如果问答系统最后只能给一句流畅答案但解释不了它基于哪些实体它沿着哪些关系推出来它引用了哪些来源文本它属于哪个更大的知识范围那它在很多场景里其实还是不够让人放心。而知识图谱问答天然更适合把这些东西一起带出来。在 UniGraph 里知识图谱应用界面给我的一个很直观感受就是它不是只追求“回答一句像人说的话”而是会尽量把整体知识概览、重点知识细节、相关知识关联、具体信息来源一起暴露给用户。这其实已经不是“普通 RAG 回答器”的思路了而是更接近“结构化知识问答系统”的思路。如果按 UniGraph 这套实现往下拆它和普通 RAG 的差别会更具体前面讲的是原理层的区别如果再往工程实现里压一层差别其实会更明显。UniGraph 这条问答链路不是简单的“向量库 提示词拼接”而是先把图谱里的局部信息和全局信息都做了一次预处理和平坦化。它至少包含这几类中间结构Entity Attributes Vector Table把实体的ID、名称、属性、属性值组织成表再做向量化Triple Source Table把实例三元组和它对应的信息源绑在一起Community Report把全局图结构划分成多级社区后再为每个社区生成报告最终问答上下文把实体、关系、信息源、社区四类上下文融合再交给 LLM 回答。这套东西和普通 RAG 最大的不同在于普通 RAG 的中间件通常围绕“文档切块”展开而 UniGraph 这类图谱问答系统的中间件是围绕“实体、关系、来源、社区”展开的。从问题嵌入、实体属性向量匹配到 Top20 实体召回、关系扩展、信息源回填、社区匹配再到四类上下文融合。普通 RAG 通常先找 Top-K chunkUniGraph 这套链路先找 Top20 实体这部分是我觉得最值得讲清楚的技术差别。UniGraph 不是先拿用户问题去匹配文档 chunk而是先把用户问题做嵌入表示再和实体名称 属性/属性值的向量做相似度匹配筛出相似度最高的前 20 个实体。这意味着系统回答问题时第一步锁定的不是“哪几段文本最像”而是“哪几个实体最相关”。这个差别很关键。因为只要你的第一步召回对象不同后面整条链路都会变普通 RAG 后面接的是文本重排图谱问答后面接的是实体映射、关系扩展、来源定位、社区匹配。也就是说普通 RAG 的第一步更像“先找相关段落”而 UniGraph 这套问答更像“先确定问题真正打中了哪些知识对象”。UniGraph 不是只拼一个上下文而是拼四类上下文按材料里的写法UniGraph 的回答上下文至少分四部分构建1. 实体上下文先把相似度排序后的前 20 个实体本身整理出来交给 LLM 生成实体上下文。这一步回答的是当前这个问题最相关的知识对象有哪些。2. 关系上下文围绕这 20 个实体系统会继续去图里找关系。材料里把这一步拆成了“内网络”和“外网络”内网络这些候选实体之间直接相连的关系外网络这些候选实体通过其他节点形成的间接关系。然后再按边权重、关系度数这些指标排序整理成关系上下文。这一层其实就是普通 RAG 很难天然补上的部分。因为普通 RAG 就算召回了几段相关文本也不太会自动帮你构出“这些对象之间到底是怎么连起来的”。3. 数据源上下文这一步是我很看重的因为它直接关系到回答能不能站得住。UniGraph 的做法不是只拿实体和关系本身而是继续把它们映射回实例三元组信息源表格把对应来源一起找出来再按实体相关性排序形成数据源上下文。也就是说它不是只回答“系统觉得是这样”而是会继续回答“系统为什么这么觉得依据来自哪里”。4. 社区上下文这一层就是普通 RAG 更少会去显式处理的全局信息。UniGraph 会把候选实体再映射到社区报告里统计它们落在哪些社区然后根据命中的实体数量和社区层级排序再形成社区上下文。这一步回答的是这个问题除了局部实体关系还落在整个知识图谱的哪一块结构里。所以从技术实现上看UniGraph 这种图谱问答不是简单“多检索一点内容”而是把局部和全局两个视角都塞进了上下文构建里。这里面还有一个很重要的点全局信息不是凭空来的而是用 Leiden 多级社区做出来的这点也值得单独讲。在你给我的材料里全局信息不是一句很空的“我们考虑了全局”而是有明确处理流程的先把 KG 转成无向图用Leiden算法做社区划分从Level0开始逐层细分允许用户指定层级深度对每个社区提取实体属性再让 LLM 生成社区报告。这意味着所谓“全局信息”在这里并不是抽象概念而是已经被整理成了可检索、可排序、可进上下文的结构化对象。材料里社区报告包含的内容也比较完整包括社区标题摘要社区评级评级解释5 到 10 条关键发现社区内实体 ID。这也是为什么它和普通 RAG 的差别不只是“多了一张图”而是多了一整套面向全局结构的中间层。从这个角度看知识图谱问答其实更像“实体检索 图结构扩展 证据回填 全局补充”如果我把 UniGraph 这套链路用更压缩的话概括大概是这样用问题去匹配实体属性向量先召回 Top20 实体围绕实体扩展关系网络回填这些实体和关系对应的信息源再补上这些实体所在社区的全局报告把四类上下文融合后交给 LLM 生成答案。这和普通 RAG 的“问题 - Top-K chunk - 生成答案”相比中间明显多了两层一层是结构扩展一层是全局补充。这两层恰好就是图谱问答比普通 RAG 更重、但也更有解释力的地方。甚至连上下文的 token 配比这套系统都是显式设计过的这一点我觉得很能体现“它不是一个随便拼提示词的问答器”。在材料里四类上下文并不是无上限地往模型里塞而是做了明确的 token 分配实体上下文约占20%关系上下文约占20%数据源上下文约占40%社区上下文约占20%这个比例本身就能看出一条很清楚的设计思路实体和关系负责把问题“钉”在局部结构上数据源占比最高说明回答最终还是要尽量回到证据社区信息负责补全全局视角避免回答只停留在局部命中。如果从问答系统设计的角度看这已经不是“把召回内容塞给模型”这么简单而是在做一种面向可解释性的上下文编排。实体、关系、数据源、社区不是随便拼进去的而是有各自明确的构建机制和 token 配比。如果结合 UniGraph 来看两者最本质的差别不是有没有用大模型而是前面有没有图层我现在越来越倾向于用一句更工程的话来总结普通 RAG 是在文本层做增强知识图谱问答是在结构层和文本层同时做增强。这句话很重要。因为很多人一看“知识图谱问答”会以为它只是“RAG 换了个名字”或者“多加个 Neo4j 就行”。但如果真的从系统链路看差别不在最后都调不调用大模型而在于前面有没有一个可查询的图层。有了图层之后系统才有机会做这些事按实体而不是按段落组织知识沿关系扩展上下文把多跳链路显式化把局部问题和全局结构接起来给答案附带更清晰的解释路径。没有这层图很多事情并不是绝对不能做而是只能靠大模型在一堆文本里临时拼。那是不是说知识图谱问答一定比普通 RAG 更高级也不能这么简单下结论。我反而觉得真正合理的说法应该是普通 RAG 更轻更快起系统更适合文档问答知识图谱问答更重但更适合那些真正依赖实体关系、结构推理和可解释性的场景。如果你的问题大多数都能在单文档或少量 chunk 里解决那普通 RAG 很可能已经够用了没必要一上来就把系统做得很重。但如果你的问题天然长这样涉及多个实体和关系需要跨文档、多跳组织答案需要解释“为什么是这个答案”需要给出知识关联和来源链路那只靠普通 RAG后面很容易越补越乱。这也是为什么我会对知识图谱问答更感兴趣。它不是为了显得“更高级”而是因为有些问题到了那一步确实需要结构层。普通 RAG 不是不能答而是解释时更容易心虚知识图谱问答的优势在于能把答案、链路、来源一起交代出来。这也是我在 UniGraph 里更关注的部分前面那篇写 UniGraph 的时候我已经说过图谱设计和图谱构建主要是团队里另外两位同学做的我自己更直接参与的是最后知识图谱应用这一部分尤其是图谱问答。所以从我的视角看前面的知识库、架构设计、图谱构建、知识迁移、建立索引最后都不是为了“把图做出来”本身而是为了支撑最后这件事当用户真的问一个问题时系统能不能把图谱里的结构知识、原始文本里的证据、以及大模型的语言组织能力合成一个更有依据的回答。这也是我现在对“知识图谱问答和普通 RAG 到底差在哪”最直接的答案普通 RAG 更像在文档里找答案知识图谱问答更像在结构化知识里组织答案再回到文档里找证据。我觉得这个差别不只是学术定义上的差别而是你真把系统做起来之后很快就会碰到的工程差别。假如你从2026年开始学大模型按这个步骤走准能稳步进阶。接下来告诉你一条最快的邪修路线3个月即可成为模型大师薪资直接起飞。阶段1:大模型基础阶段2:RAG应用开发工程阶段3:大模型Agent应用架构阶段4:大模型微调与私有化部署配套文档资源全套AI 大模型 学习资料朋友们如果需要可以微信扫描下方二维码免费领取【保证100%免费】配套文档资源全套AI 大模型 学习资料朋友们如果需要可以微信扫描下方二维码免费领取【保证100%免费】
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
