先看一句最普通的搜索：“霜纹短剑在哪里”。这是一个事实问题，答案是“灰烬回廊第三层的守卫宝箱，概率掉落”。再看另一句：“怎么最快拿到霜纹短剑”。这是目标问题，答案不再是一个地点，而是一串步骤，甚至需要在几条路线里做取舍。两句话共享同一个实体，检索方式却应当分开设计。爱游戏AI在搜索侧的第一步，就是判断玩家站在下面四层问题的哪一层。

第一层：实体查询，问的是“它是什么”

“霜纹短剑的攻击力是多少”“这个道具能不能叠加”，都属于最底层的实体查询。系统要做的是把用户输入的名字对到唯一实体，再读出属性。难点不在推理，而在名字：玩家会写简称、旧译名、错别字，也会把两件装备混为一谈。这一层追求的是精确，允许把同名候选一并列出，不需要也不应该展开任何路线。

这一层如果做得好，答案应该短到一屏之内。把攻略长文塞给一个只想确认攻击力的玩家，是最常见的过度回答。

第二层：关系查询，问的是“它和谁有关”

“霜纹短剑从哪里掉”“谁出售这个配方”，问的是一跳或两跳的关系：装备—掉落自—守卫，守卫—位于—地图区域。这类问题在知识图谱里连接角色、任务、装备与地图的方式下天然好回答，因为答案就是沿着一条边走过去。

关系查询仍然属于“查事实”。它的输出是一个或几个事实三元组，最多带上掉率、刷新时间这类边上的属性。判断它是否回答到位，只需要核对这条边是否存在、是否过期，不需要评价“好不好走”。

第三层：依赖推理，问的是“要先做什么”

问题开始变质的地方在这里。“守卫宝箱要用铜钥匙开”“铜钥匙来自一个任务”“任务要求等级达到12”，于是拿剑之前存在一条前置链。依赖推理要做的不是找一条边，而是沿“需要”关系向上追溯，直到追到玩家当前已经满足的状态为止。

这里出现了第二个变量：玩家的当前状态。同样问“怎么拿到霜纹短剑”，等级已经够、钥匙已经有的玩家，答案只有最后一步；刚进游戏的玩家，答案是十几步。所以依赖推理必须读取玩家的存档摘要或让玩家补充当前进度，否则只能给出对所有人都过长、对任何人都不准的通用答案。

第四层：路径规划，问的是“怎样才划算”

当依赖链上有多个选择时，问题升级为规划。假设示例：拿到霜纹短剑有三条路——击杀守卫、在商人处兑换、完成一条支线任务奖励。三条路的耗时、金币成本、失败风险各不相同，还可能互相冲突（兑换会消耗同一批材料）。“最快”“最省”“最安全”对应不同的目标函数，系统要先弄清玩家要哪一个，再在依赖图上求解。

这也是目标导向图和普通实体图的区别所在：普通实体图只记录“有什么”，目标图还要记录“做这件事需要付出什么、会带来什么、和别的事是否冲突”。没有这些边，规划层只能靠模型凭记忆编步骤，而记忆里的步骤很可能来自另一个游戏版本。

怎么判断玩家在哪一层

四层之间没有清晰的语法边界，只能靠一组信号综合判断。爱游戏AI倾向于把下面这些信号交给一个轻量的意图分类器，再由规则兜底。

信号 倾向的层次 示例
只有实体名，或“是什么”“多少” 实体查询 霜纹短剑
“在哪”“谁卖”“掉不掉”关系查询 霜纹短剑在哪里掉
“需要什么”“前置”“为什么打不开” 依赖推理 守卫宝箱为什么开不了
“最快”“最省”“怎么才能”“先做哪个”路径规划怎么最快拿到霜纹短剑
带有当前状态描述 提升到依赖或规划 我12级，刚打完第二层，怎么拿到

需要强调，这是倾向而不是硬分类。“霜纹短剑怎么拿”既可能只想知道掉落点，也可能想要完整步骤。碰到这种边界，我们的做法是先给事实层的短答案，同时在下方给出“需要完整步骤吗”的入口，而不是二选一地押注。

路由：不同层次走不同的检索

判断完层次，检索逻辑随之分叉。

  • 实体与关系层走精确匹配加图谱查询，返回可核对的条目，并带上数据所属的游戏版本。
  • 依赖层在图上做前置追溯，结合玩家状态剪掉已满足的节点，返回一条最短的必要链。
  • 规划层对候选路径打分，展示两三条各有取舍的方案，并写明依据的目标函数。

大语言模型在这里主要负责两件事：理解玩家怎么问，以及把图上得到的结果讲成人话。真正的“这一步为什么必须先做”，应当由图上的边来担保，而不是由模型的印象来担保。

层次判错时会发生什么

判断偏浅，玩家想要路线却只得到一个地名，还得自己再搜四五次；判断偏深，玩家只想确认攻击力，却被塞进一份二十步攻略。更隐蔽的一种错误是把规划问题当事实问题处理：检索系统召回了几篇“霜纹短剑获取方法”的旧文，直接拼成答案，其中的钥匙来源在当前版本里早已改了。

所以在爱游戏AI的设计里，规划类答案必须能回溯到具体的图边，找不到依据的步骤宁可标注“未验证”，也不补一个听上去合理的说法。这种保守带来的代价是答案有时不够“满”，但换来的是玩家照着做不会走进死路。