AI 生成旅游图谱：一次“美丽错误”的技术思考

NebulaGraph 技术社区 2025-05-14

208

导读：

星影 StarShadow 是由 NebulaGraph Committer 大叶老师（CorvusYe@GitHub）开发的一款 ‌NebulaGraph 图数据库客户端，提供图数据库的可视化操作界面，让用户可以通过图形化的方式，对图数据库进行操作。自 2024 年 6 月发布以来，星影快速迭代，努力成为开发者们在图实践路上值得信赖的同伴。五一前，星影正式发布 2.0 版本，集成了 DeepSeek, 该 AI 模块命名"DeSrc". 今天，让 DeSrc 为 NGer 们规划一条「厦门三日游」路线，DeSrc 会有何推荐，又将给我们怎样的图数据库思考呢？

一、起

在年初时，初步验证了 DeepSeek
在构建知识图谱的可行性。

经过数月的摸索与研发，最终在图数据库客户端星影
中集成，并将完成之后的模块取名 DeSrc
，大致流程如下：

二、承

今天，带来一个小案例，使用 DeSrc 规划一条厦门三日游路线，并将数据保存到 NebulaGraph 数据库中。

（完整过程截图过长，请见文末）

小案例的输入输出过程如下：

输入：帮我出一个厦门的旅游攻略图谱，需要有日程安排、公共交通方案等，需要涉及吃住行及用时，公共交通的线路。
输出：

以上推荐由 AI 生成，不代表文章观点，仅供参考。

从旅游的角度看，在三天的行程里，AI 推荐了 6 个景点、3 家具有当地特色的餐馆，6 个住宿区。总体来看算是比较经典的线路安排，偏简单。

从技术的角度看，看似简单的背后，也藏着点“猫腻”。在整个过程中，AI 完成了 4 个 Tag 及 6 个 EdgeType 的设计，并写入了 18 个节点及 20 条关系。

三、转

当然，从提出需求到生成图数据的过程中，并非一帆风顺。

在需求的描述中提到了“公共交通方案”，但图数据中并未体现这部分信息，因为 AI 在生成 nGQL 的过程中出现了语法错误，但为了顺利形成图数据，被我人为干预修正了，但在详细思考之后，个人认为这是个具有参考意义的错误，所以称之为“美丽的错误”。

以下截取几段这个“错误”的相关脚本：

INSERT VERTEX `ScenicSpot` (
  spotId, name, coordinates, visitDuration, ticketPrice
) VALUES
'Spot_GDY':(101, '鼓浪屿', '24.4489,118.0664', 180, 35),
'Spot_ZSL':(102, '中山路步行街', '24.4795,118.0894', 120, 0);

INSERT VERTEX `Transport` (
  transportId, vehicleType, routeNumber, duration, cost
) VALUES
'Transport_LY':(201, '轮渡', '邮轮中心厦鼓码头—三丘田码头', 20, 35);

INSERT EDGE `TRANSIT_CONNECT` (
  departure_time
) VALUES
'Spot_GDY'->'Spot_ZSL':'Transport_LY'@('16:00');

语法错误发生在脚本最后一行中，探究其意图，似乎 AI 想把一个实体锚定在一段关系中。而“两个地点的出发与到达”场景中，显然 AI 的想法虽然不符合语法，但却更为精准，如图：

为了方便表述与理解，我将代码中的鼓浪屿换成 A 地点,中山路步行街换成 B 地点，轮渡换成11路公交车。

而符合当前主流图数据库的存储方式又与场景相近的做法有：

1. 将摆渡方式作为一个中间节点，将三元组拆分成五元组

这种修正方式的缺陷很明显，丢失了关系的同一性，或者说事件的同时性。

2. 将摆渡方式作为一个属性

这种修正方式还有两种可能性：

实体名称当成边的一个属性
节点的 id 当成边的一个属性

无论上述哪种都依然带有难以消除的弊端：

第一点中，现实中实际存在的、有边界的、唯一的实体，以名称的方式参与到关系中，当多条关系出现同一名称，无法确定是否属于同一实物。

第二点中，以 id 作为属性虽然解决了同一性问题，但从当下主流图数据库查询返回值的角度，又很难将嵌入在边中的节点很好地表达出来。

四、合

那么问题究竟出在哪？

AI 的意图，本质上属于一种使用超图的解决方案。主流图数据库从存储到返回值，实现的都是一种普通图的方案。

在数学中，超图（Hypergraph）是一种广义上的图。不同于普通图的一条边只能连接两个顶点，超图的一条边可以连接任意数量的顶点。

按照超图的定义，AI 意图所形成的结构应为：

而这种结构，在生活中更为常见。例如：五个人同时在一张桌子吃饭，用一条多端的边同时连接桌子与众人，对这一场景的表达最为精准。也许先前建模困难，时常需要在实际中纠结取舍，不能按生活直觉创建，或许原因就在于超图的模型要放入普通图的容器，难免有些水土不服，期待早日可以看到图数据库能具备超图的特性，或者如果已经有了，请带带我。

附：

1. 小案例过程 DeSrc 界面截图