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

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

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

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

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

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

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

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

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

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

让结构的增加有清楚理由

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

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

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

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