如果它只是一张图，你能问它什么

先设定一个虚构的小片段。“灯塔守”温娜是一个角色，她发布任务“点亮北塔”；任务要求玩家进入地图“雾湾”；完成后玩家得到装备“潮汐罗盘”；潮汐罗盘可以打开区域“沉没水闸”。用节点和有向边画出来，就是温娜→点亮北塔→雾湾→潮汐罗盘→沉没水闸，一条五个节点的链。

很多游戏图谱项目停在这里：把这些点线画到大屏上，配上力导向动画，看起来关系一目了然。但一张只用来看的图和一张能查询的图是两回事。判断标准很简单：你能向它问几个问题，并得到可信的答案。我们把问题一层层往上加，看看每一层需要图具备什么。

第一层：邻居查询，“谁发布了这个任务”

“点亮北塔是谁给的？”答案是沿一条边走一步，找到温娜。这是最基础的实体关系（Entity Relation，即两个实体之间带类型的联系）查询。它只要求节点有名字、边有类型，一个关系型数据库的两张表就能做到。

如果图谱只能回答这一层，它对玩家的价值和一份带目录的资料库差不多。而这一层恰好是大多数“关系图展示”项目的上限。

第二层：多跳查询，“这个任务最终能打开哪里”

“完成点亮北塔以后，能进什么区域？”要从任务走到地图，再走到装备，最后走到区域，总共四跳：任务→地图→装备→区域。到这里，表连接会开始吃力，因为跳数是可变的，玩家可能问三跳、五跳，写死的查询语句不再通用。

这就是图查询（Graph Search，即在图上沿关系遍历或匹配模式的检索）的价值：跳数不固定、路径上的边类型可以按需限定，比如“只沿‘产出’和‘解锁’边走”。爱游戏的做法是把常见的多跳问法固化为几种查询模板，同时允许更复杂的问题通过受控的图查询语言表达，而不是每个问题都重写一遍。

第三层：反向查询，“这件装备被什么依赖”

“如果我把潮汐罗盘卖了，还能不能进沉没水闸？”这是一个反向问题：不是从任务往后看，而是从装备往回看，哪些内容依赖它。反向查询要求边是有方向、能双向索引的，并且“依赖”和“产出”这类边必须语义清楚，否则反着走会走进歧义。

反向查询的实际作用不止于回答玩家。开发端做改动时也需要它：如果策划打算调整潮汐罗盘的掉落，图谱可以立刻列出受影响的区域和任务，这就是依赖分析。

第四层：路径与规划，“最省事的获取顺序”

“我想进沉没水闸，需要按什么顺序做什么？”到这里，图不再只是被遍历，而是要被计算：要展开依赖、处理可选来源、按玩家进度剪掉已完成的节点，再比较代价。这一层需要边上带更多语义，专门做这类目标推理的图结构，在目标导向图和普通实体图的区别中有单独讨论。

对这个小片段而言，如果玩家已经去过雾湾，规划就不应再让他重复进入；如果罗盘有“任务奖励”与“商人购买”两个来源，就需要能同时表达这两条可选边。图谱在这一层才真正变成推理的底座。

四类下游，各自用图做什么

图谱的价值不在自己好看，而在服务其他系统。至少有四类下游会用到它，每一类的用法都不同。

下游具体用途 示例
搜索 实体消解与意图落点，把问句对上唯一的实体 玩家搜“罗盘”，图里有“潮汐罗盘”和“旧罗盘”，用玩家进度判断是哪一个
推荐 补充内容相似度，找到机制或主题相近的游戏喜欢“解锁区域型探索”的玩家，可以从共享“区域解锁”机制标签的游戏中找候选
依赖分析 判断一次内容改动的影响范围 调整罗盘掉落前，列出所有依赖它的任务和区域，交给测试重点回归
Agent任务规划 给智能体提供可执行、可校验的步骤 测试Agent要复现“拿到罗盘后进水闸”，从图里取出最短的合法前置步骤

这张表要表达的是：同一张图，读法不同。搜索读的是“名字到实体”的映射，推荐读的是“属性与关系的相似”，依赖分析读的是“反向可达”，Agent读的是“可执行的路径”。如果图谱建模时只想着其中一种用途，比如只为搜索建了一堆别名，等到要做依赖分析就会发现根本没有可靠的前置边。

建模时要先做的几个选择

把问题提清楚以后，才能回头决定怎么建模。以下是我们在设计时倾向的几个选择。

  • 实体类型要少而稳：角色、任务、地图、区域、装备、道具、事件、Boss几类就够了。类型分得太细，会让后续的查询模板成倍增加；分得太粗，又无法区分“区域”和“地图”这种玩家会区分的概念。
  • 关系类型要有方向和语义：“发布”“要求进入”“产出”“解锁”“需要”“位于”，每一种都应写清楚谁指向谁。一条没有语义的“相关”边，不比全文检索强多少。
  • 属性要能支撑排序和过滤：比如任务的推荐等级、区域的进入条件、装备的获取方式。属性的缺失会让图只能回答“有没有”，不能回答“哪个更合适”。
  • 每个节点和边都带来源与版本字段：来源写明是官方设定、玩家整理还是模型抽取，版本写明适用于哪个游戏版本。这样查询时才能按可信度和版本过滤。

版本字段并不是附加项。游戏内容经常调整，一件装备在两个版本里的解锁条件可能不同，图上如果只留下最后一次更新，那么“旧版本怎么打”的问题就无从回答。关于版本变化如何影响图谱，图谱如何随补丁更新里有具体的做法。

图谱质量问题：比缺数据更难的是错数据

图谱的质量问题不在于点线够不够多，而在于错的点线会被系统当作事实使用。至少有四类典型问题。

  1. 重名：“温娜”可能是灯塔守，也可能是另一个地区的旅行商人。如果两个实体共用一个节点，所有边都会混在一起，产生“商人发布了点亮北塔”这样的错误关系。解决办法是引入唯一标识，并用地点、所属阵营等属性帮助消解，而不是只靠名称。
  2. 缺边：潮汐罗盘能开沉没水闸，但没有人录入这条边，依赖分析就会漏掉受影响的区域。缺边通常没有报错，只是让答案悄悄变得不完整。
  3. 错边：方向写反、类型写错，比如把“需要”写成“产出”。规划会因此得出荒谬的路线。抽检和一致性规则（例如“一个任务的前置不能是它自己的奖励”）可以捕捉一部分。
  4. 过期：补丁把某个区域的开启条件改了，但图里仍是旧条件。这是长期运营里最常见的错误来源。

对付这些问题的思路不是追求一次建对，而是让错误容易被发现：边带来源，任何一条可疑的边都能追溯到出处；关键查询附带“依据了哪些边”，让人能核对；模型抽取的边默认低可信度，需要复核后才能参与规划。

举一个错边被放大的例子。假设有人把“潮汐罗盘 解锁 沉没水闸”误录成“沉没水闸 产出 潮汐罗盘”。搜索会告诉玩家“去沉没水闸拿罗盘”，规划会形成一个循环依赖，Agent 会在一个永远无法满足的前置里反复尝试。三个下游同时出错，源头却只是一条边。这也是为什么我们主张让图谱的每次变更都能被回归查询检验：改动之后，把一批已知答案的问题重新跑一遍，看结果有没有变。

画出来的图，和可查询的图

回到开头的问题：一张图和一张可查询的图差在哪里？我们可以从几个方面对照。

方面 展示用的关系图 可查询的图
节点与边为了好看可以省略、合并每个节点有唯一标识，边有类型和方向
属性 通常只有名称和图标 带条件、来源、版本、可信度
更新手工调整或定期重绘 随版本增量更新，并做回归校验
使用方式 人眼浏览 被搜索、推荐、规划等程序调用
出错时看起来不太对，人会自己纠正错误会被程序放大，需要校验与追溯

最后一行最关键。人看图时会自动容错，程序不会。图谱一旦成为底层数据，错误就会被下游放大，所以质量约束比可视化效果重要得多。

图查询、向量检索，还是两者结合

图谱并不能包办所有检索。玩家的问句有时非常模糊，比如“那种在雾里慢慢摸索的关卡叫什么”，这更适合向量检索：把描述和内容转成语义向量，找到最相近的条目。相反，“潮汐罗盘被哪些任务依赖”这种精确的关系问题，向量检索会给出一堆语义相近但关系不对的结果，图查询才可靠。

一种常见的组合方式是GraphRAG（图增强的检索生成，即先在图上检索出相关的实体和关系，再把它们连同原文一起交给语言模型来组织回答）。它的好处是语言模型的回答有图谱事实做依据，减少凭记忆编造的风险。这一点在游戏大模型为什么需要知识图谱里有更完整的讨论。爱游戏AI的分工大致是：向量检索负责“找到可能相关的内容”，图查询负责“确认关系与路径”，语言模型负责“把结果说成人话”，三者互相校验，而不是谁替代谁。

收束：图谱是用来问的

回看开头那条五节点的链：温娜、点亮北塔、雾湾、潮汐罗盘、沉没水闸。它本身没有多神奇，真正有价值的是我们能对它问出多深的问题：谁发布、能开哪里、被谁依赖、怎么最省事地拿到。爱游戏做游戏知识图谱时，先列问题再建模，而不是先堆节点再想用途。图谱要被搜索、推荐、依赖分析和Agent规划反复调用，才会有意义。