# 知识图谱与 RAG：什么时候关系比片段更重要

讨论企业知识问答中的实体关系、跨资料查询与维护成本，判断是否需要引入知识图谱。

要点：当问题依赖产品、部件、规则或业务对象之间的明确关系时，结构化关系可以补充文本检索。是否引入知识图谱，应看关系是否足够稳定、来源是否可确认、维护是否有人承担。图的复杂程度并不直接代表答案质量。

![同事查看知识关系图与原始资料（AI概念配图）](/images/immersive/knowledge-graph-v1.png)

## 有些问题的难点在于连接关系

查找某个产品的参数，可能通过一份资料完成；判断哪些产品受某项部件变更影响，则需要知道产品与部件之间的关系。后一类问题不仅要求找到相似文字，还要求关系的完整性与方向正确。

先列出真实问题，观察它们需要哪些对象和关系。若业务系统已经维护这些关系，可以优先查询现有来源。没有必要因为知识图谱受到关注，就重新建立一套无人维护的数据。

## 关系本身也需要来源与有效条件

“部件属于某产品”“某规则适用于某对象”等关系，都可能带有版本、时间或范围。把它们画成连线之后，这些条件并不会消失。应保留关系来自哪里、由谁确认以及何时需要更新。

模型可以帮助从资料中提取候选关系，但候选不应直接等同于企业事实。对关键对象和影响较大的关系，需要使用可靠来源核对。错误关系经过多步查询后，可能产生看似连贯却缺乏依据的结论。

## 结构化关系与原文可以相互补充

关系查询可以帮助确定需要检查哪些对象，原始资料则解释具体条件。将两者结合时，应保留从对象到关系、再到原文的查证路径。使用者需要理解答案为什么涉及这些资料。

评价时分别检查关系是否正确、必要对象是否遗漏，以及最终回答是否忠实保留限制。不能只展示一张结构复杂的图，就认为跨资料问题已经解决。

| 问题 | 先检查什么 |

| --- | --- |

| 是否需要图谱 | 真实查询是否依赖明确关系 |

| 关系是否可信 | 来源、版本与确认记录 |

| 维护是否可持续 | 变化如何同步到关系 |

| 回答是否可用 | 结论是否回到关系与原文 |

## 让结构的增加有清楚理由

如果主要问题仍是文档杂乱、命名不统一和来源缺失，先整理这些基础通常更有价值。图谱不会自动消除内容治理问题，反而可能增加维护对象。

未来知识系统会同时使用文本、关系和业务数据。企业可以从一组稳定关系开始验证，保留扩展空间，同时让每一项结构都能对应一个实际需要回答的问题。

## 先证明一个问题确实需要关系

用部件变更影响哪些产品的问题，列出对象、关系、出处和有效期。只有当现有文档检索难以稳定回答，且企业能维护这些关系时，再比较图谱方案，不先以关系数量立项。

## 参考来源

- [秩启｜企业资料准备](/workspace)：企业资料、角色与待核事项整理；保存草案不等于形成正式业务规则

- [Microsoft｜GraphRAG 官方文档](https://microsoft.github.io/graphrag/)：从原文提取实体和关系、构建分层检索的机制；不证明本企业引入图谱后的收益

## 关系与证据共同支持回答

- 对象：明确产品、规则和版本

- 关系：方向、范围与来源可信

- 原文：解释条件并保留查证路径

![关系与证据共同支持回答](/images/guides/diagrams/knowledge-graph-rag.svg)

## 继续阅读

- [数据、文档与知识：企业究竟需要沉淀什么](/guides/knowledge-vs-data)

- [知识库搜不准：关键词、向量检索和重排怎么配合？](/guides/rag-retrieval)

- [产品资料在官网、销售和知识库里，怎样保持一致？](/guides/product-data-governance)

围绕当前问题查看任务、资料与人工确认示例，再用企业样例验证。

下一步：[按业务环节查看沙盘](/library)

原文：/guides/knowledge-graph-rag

内容版本：guide:knowledge-graph-rag:v1

<!-- version:guide:knowledge-graph-rag:v1 -->

[结合企业情况咨询](/intake?source=%2Fguides%2Fknowledge-graph-rag&articleId=guide%3Aknowledge-graph-rag&versionId=guide%3Aknowledge-graph-rag%3Av1)