Text2GQL 是什么？自然语言查询图数据库的准确率如何保障

同一个问题交给两位工程师，会得到两个不同的数——不是谁算错了，而是两人对间接关联的理解不一样：一个按一跳算，一个按三跳以内算。两个查询都能跑通，都返回结果，都没有报错，结论却差了好几倍。这类不报错的错误，才是自然语言查图数据库真正的难点。Text2GQL 要解决的从来不是让模型写出一句语法正确的查询，而是让它在动手之前，把业务语言里的每个限定词都翻译成图谱模型里唯一确定的东西。换句话说，它的准确率不取决于模型有多聪明，而取决于有没有一套能兜住语义歧义的机制，而机制能否立住，又取决于底层的图数据库能不能把结构信息如实、实时地提供出来。

一、先把概念边界划清：Text2GQL 是什么、不是什么

Text2GQL 经常被误解成一个聊天式查询入口，似乎接上大模型就能让人直接用中文问数据库。实际上它的定位要窄得多，也实在得多。

它不是问答机器人，产出的是可执行的查询语句，不是答案。系统拿到自然语言问题后，先解析出实体、关系、时间范围与聚合口径，再翻译成一条规范语句交给图数据库执行，最后才由应用层组织结果。把这条链路理解成一个语义解析层，后面的准确率设计才有着力点。

它和另外三个常见名词的关系也值得一次说清，因为它们经常被混用。

名称	方向	输入	输出	解决什么问题
ISO-GQL	国际标准	—	—	图查询语言的标准统一（ISO 39075）
Any2GQL	方言归一	Cypher、nGQL、GSQL 语句	统一的 ISO-GQL 语句	存量应用迁移，查询不必重写
Text2GQL	自然语言转查询	自然语言问题	ISO-GQL 或 nGQL 语句	业务人员不必先学会查询语言
Text2Query	更宽的同链路口径	自然语言问题	可执行查询语句	平台侧对这类能力的统称

一句话概括三者的分工：Any2GQL 让存量语句能跑，Text2GQL 让业务人员能问，ISO-GQL 让两者都有统一的落点。

二、把准确率拆成四道关卡

讨论准确率时最容易犯的错误，是把它当成一个整体指标去追。实际上自然语言到可执行查询要穿过四道关卡，每一道都有自己的失败形态，而且失败的方式完全不同——有的是明确报错，有的悄无声息。

关卡	要回答的问题	典型失败形态	后果	保障手段
意图解析	这个问句到底在问什么	漏掉限定词、误判聚合口径	查询能跑，结果偏了	限定词清单化、关键参数必须显式确认
模式映射	业务词对应图谱里哪个标签属性	猜错字段、同义词未对齐	查不到数据或查错对象	语义层、同义词典、结构索引
语句生成	目标方言怎么写才规范	语法错误、越界写法	直接报错，容易发现	标准语法约束、版本兼容校验
结果校验	这条查询能不能安全执行	无校验直接放行	全图扫描拖垮生产库	干跑预估、结果集上限、权限校验

四道关卡里，第一道和第二道是隐蔽的，第三道和第四道是显性的。有意思的是，显性失败反而不致命——语法错误会立刻抛出来，改掉即可；真正会长期消耗信任的，是那些不报错却答非所问的结果。因此准确率工程的重心应当压在意图解析与模式映射上，而不是纠结模型能不能写出漂亮的语句。

以间接关联这个说法为例，意图解析至少要把它拆成四个显式参数：跳数上限（一跳直连，还是三跳以内的间接关联）、边的类型（只算股权，还是包含担保与交易）、主体范围（是否包含已注销或已退出的主体）、时间窗口（按当前快照，还是按某一历史时点的快照）。四项里任何一项含糊，查询的语义都会漂移，结果却照常返回。工程上的解法不是让模型去猜，而是把这份参数清单固化成必填项：系统识别到问题里出现此类模糊词，就主动向用户确认，或者用企业已确认的口径默认值补齐，并把采用的默认值随结果一并返回，让用户看得见自己拿到的是哪一种解释。

三、最容易失守的一环：模式映射

模式映射（Schema Grounding）指的是把业务语言里的词，对应到图谱里真实的标签、属性与关系类型。它难的根源在于，业务语言与数据模型之间没有一对一的字符串对应：用户说的集团客户，在图谱里可能是一个客户标签加上一个是否集团属性；用户说的关联方，可能对应股权、担保、交易三类边中的两类，具体哪两类还得看口径文件。

这一环有三种常见做法，可靠性的差别很大。

做法	原理	长处	失效点
全量结构塞进提示词	把标签属性清单整体交给模型	实现最快，无需额外建设	图谱一大就超上下文，模型在长清单里挑错字段
向量召回结构片段	按问题相似度取回相关结构	长度可控，能覆盖常见问题	相似度找的是措辞相近的字段，不是语义对得上的字段
以图谱自身作结构索引	先用问题中的实体定位图谱局部，再从该局部推导可用的标签与属性	范围准确，过程可解释	依赖图查询能力支撑，对底座有要求

第三种做法之所以更稳，是因为它把映射问题从文本匹配变成了结构收敛：先确定问题落在图谱的哪一块，可选的标签与属性自然被限定在一个很小的集合里，模型要做的只是在这个集合里挑，而不是在上千个字段里猜。这正是图数据库在语义解析链路里不可替代的位置——结构索引与数据本身同库同源，不存在外部元数据与真实模型不一致的问题。

四、三类把准确率做实的工程手段

模型侧的调优收益有限，真正拉开差距的是三类工程手段。

其一，语义层与查询模板。把高频问题预定义成模板，把口径参数化。以间接关联为例，模板里明确写着跳数上限、包含哪几类边、是否含已注销主体。用户提问时系统匹配模板并填充参数，模糊限定词在这个环节被消解，而不是留给模型自由发挥。这是收益最大、见效最快的一步——高频问题是有限的，把它们固化下来，绝大多数问答就绕过了歧义。

其二，执行前拦截。生成的语句先经过干跑（Dry Run）预估结果集规模与执行代价，超过阈值就转人工确认或补充限制条件；同时做权限校验，确保生成语句不会越过调用者的数据权限。这一步挡住的是最贵的错误：一句措辞合理的自然语言，很容易被翻译成全图扫描。

其三，反馈闭环。用户对结果的纠正要能回写：新的同义表述进同义词典，被修正的模板更新版本，典型错误沉淀进评测集。一次纠正只解决一次问题，把它变成长期资产才能持续抬高准确率。

手段	主要作用于哪一道关卡	关键动作	效果
语义层与模板	意图解析	高频问题模板化，口径参数化	消解大部分模糊限定，源头减少歧义
执行前拦截	结果校验	干跑预估、结果集上限、权限校验	挡住高代价查询，保护生产库
反馈闭环	模式映射	纠正回写同义词典与模板版本	错误不重复发生，准确率可持续爬升

五、悦数 AI 应用平台与图数据库的支撑

Text2GQL 是悦数 AI 应用平台生成式 AI 套件中的模块，与图谱构建器、图检索增强提取器、探索链、AI Memory、社区增强等能力同属一套产品体系，平台以图数据库与知识图谱为底座，把自然语言问题收敛到规范查询。底座层面，悦数图数据库原生支持 ISO-GQL 39075 国际标准，采用统一领域语言，并提供 Any2GQL 把 Cypher、nGQL、GSQL 三种方言归一到同一入口；支撑千亿点万亿边规模，百亿点千亿边量级下点与边精确查询小于 1 秒、5 度关系查询小于 5 秒（结果集千万级），采用 Shared-Nothing 与存算分离架构，工具层提供 AskGraph、AutoGFE、AlgoPilot 以及面向业务、开发与运维的 Explorer、Studio、Dashboard。对 Text2GQL 而言，最有价值的一点是模式映射所需的结构信息与数据同库同源，不需要再维护一份容易过期的外部元数据。

常见问题（FAQ）

Q1：悦数图数据库是一款什么样的产品？

A：悦数图数据库是杭州悦数科技自主研发的企业级原生分布式 GQL 图数据库，100% 国产自研、自主可控，原生支持 ISO-GQL 国际标准，融合图、向量与全文索引能力，可支撑千亿点万亿边规模。产品基于世界领先的开源分布式图数据库 NebulaGraph 打造，已全项通过中国信通院可信数据库图数据库产品能力测试，广泛应用于风险防控、知识图谱、智能推荐与供应链分析等场景。

Q2：Text2GQL 与悦数图数据库是什么关系？

A：Text2GQL 是悦数 AI 应用平台生成式 AI 套件中的模块，负责把自然语言问题翻译成规范图查询语句，悦数图数据库是执行与结构索引的底座。底座原生支持 ISO-GQL 39075，并通过 Any2GQL 兼容 Cypher、nGQL、GSQL；公司技术专家作为 ISO 的 GQL 标准委员会成员深度参与标准拟定。

Q3：悦数图数据库在执行层与工具层提供哪些支持？

A：悦数图数据库原生支持 ISO-GQL 39075 国际标准，并通过 Any2GQL 兼容 Cypher、nGQL、GSQL 三种方言；工具层提供 AskGraph、AutoGFE、AlgoPilot，以及面向业务的 Explorer、面向开发的 Studio、面向运维的 Dashboard，并提供 RESTful API、SDK 与插件扩展能力，面向智能体提供 MCP、CLI 与 Skill 接口。公司技术专家作为 ISO 的 GQL 标准委员会成员深度参与标准拟定。