SQL、Cypher、TypeQL 跨语言基准测试：LLM 查询生成质量对比

1. 为什么我要做这个跨查询语言的基准测试过去大半年我一直在折腾一个挺实际的问题让大语言模型帮业务人员写查询语句。一开始只做 SQL后来发现图数据库的 Cypher 和 TypeQL 也经常被问到于是干脆把三种语言放在一起做横向对比。这个项目就是记录我如何搭建一套可复现的基准测试覆盖 SQL、Cypher、TypeQL 三种查询语言的生成质量评估。先说清楚这个基准测试到底解决什么问题。日常场景里数据分析师、后端开发、产品经理都可能遇到我想查一下上个月复购率最高的用户这类需求但让他们手写 SQL 或 Cypher 门槛太高。LLM 生成查询语句看起来是个好方案但实际用起来问题一堆生成的 SQL 语法对但语义错、Cypher 里关系方向搞反、TypeQL 的类型约束被忽略。更麻烦的是不同查询语言的生成难度差异很大你没法用同一套标准去衡量。这套基准测试适合三类人参考一是正在做 Text-to-Query 产品的工程师需要一套评估框架二是数据平台团队想判断该优先支持哪种查询语言三是研究者想对比不同 LLM 在结构化查询生成上的表现。我尽量把每个环节的取舍理由写清楚包括我踩过的坑和最后怎么绕过去的。整个测试的核心思路是用同一批自然语言问题分别让 LLM 生成 SQL、Cypher、TypeQL然后用统一的执行正确率、语法通过率、语义等价性三个维度打分。听起来简单但光是语义等价这一项就够折腾的后面会详细讲。2. 三种查询语言的本质差异与测试设计考量2.1 SQL、Cypher、TypeQL 的核心范式对比要设计一个公平的基准测试首先得理解这三种语言在范式上的根本差异。SQL 是关系代数基础上的声明式语言核心是表、行、列查询靠 JOIN 连接。Cypher 是图查询语言核心是节点、关系、路径查询靠模式匹配。TypeQL 更特殊它是基于类型系统的知识图谱查询语言强调类型约束和推理。这三种范式的差异直接决定了 LLM 生成难度的不同。SQL 的训练数据最多模型见过海量 Stack Overflow 问答和开源项目生成质量相对稳定。Cypher 的数据量少一个数量级而且图模式匹配的思维方式和 SQL 差异大模型容易把 SQL 的思维带进来。TypeQL 是最小众的公开训练数据极少模型基本靠 few-shot 示例来学。我在设计测试集时特意让同一批问题在三种语言下都有对应的标准答案。比如找出所有购买了 A 商品但没有购买 B 商品的用户SQL 用 NOT EXISTS 子查询Cypher 用 NOT (u)-[:BUY]-(:Product {name:B})TypeQL 用 not { $u has purchase $p; $p has product-name B; }。这样对比才有意义。2.2 测试集构建从自然语言问题到标准查询测试集的构建是整个项目最耗时的部分。我用了三个来源一是公开的 Spider 数据集里的 SQL 问题二是自己从业务场景里提炼的图查询需求三是 TypeQL 官方文档里的示例改写。每个测试用例包含四个字段自然语言问题、SQL 标准答案、Cypher 标准答案、TypeQL 标准答案。标准答案必须满足两个条件能在对应数据库上执行通过且结果集和自然语言问题的预期一致。这里有个坑很多公开数据集的标准答案其实有歧义比如最近一周到底是从今天算还是从数据最新日期算我统一规定以数据最新日期为基准。测试集规模上我最终保留了 120 个问题分三个难度等级简单单表/单节点查询、中等两到三个 JOIN 或路径、困难嵌套子查询、聚合加过滤、多跳路径。每个等级 40 个问题保证三种语言下的分布一致。2.3 评估维度的选择与权重分配评估维度我定了三个每个都有明确的定义和计算方式。语法通过率生成的查询能否被对应数据库的解析器接受。SQL 用 sqlparse 加实际执行Cypher 用 Neo4j 的 EXPLAINTypeQL 用 TypeDB 的解析接口。这一项是硬门槛语法不过后面都不用谈。执行正确率查询能在数据库上跑出结果且结果集和标准答案完全一致。这里要注意结果集的顺序问题我统一在比较前对结果排序避免因为返回顺序不同误判。语义等价性有些查询语法通过、执行也通过但结果和标准答案不同这时候需要人工判断是不是另一种正确写法。比如 SQL 里 JOIN 和子查询可能得到相同结果Cypher 里不同路径写法也可能等价。这一项我用了 LLM 辅助加人工复核的方式让 GPT-4 先判断我再抽查。权重上语法通过率占 20%执行正确率占 50%语义等价性占 30%。这个分配是基于实际业务场景的考量语法错误用户一眼能看出来执行错误才是真正影响体验的语义等价则是加分项。3. 基准测试的实操流程与关键环节3.1 环境搭建三种数据库的并行部署环境搭建比我想象的麻烦。SQL 我用的是 PostgreSQL 15因为它的解析器严格能暴露更多语法问题。Cypher 用 Neo4j 5.x 社区版TypeQL 用 TypeDB 2.x。三个数据库跑在同一台机器上用 Docker Compose 管理避免端口冲突。数据准备上我设计了一个统一的电商场景数据集用户、商品、订单、购买关系。SQL 里是四张表Cypher 里是节点和关系TypeQL 里是实体和关系类型。数据量控制在 1000 个用户、200 个商品、5000 条订单既能覆盖各种查询模式又不会让测试跑太久。这里有个细节要注意三种数据库的数据类型系统不同。SQL 里日期是 DATE 类型Cypher 里是 datetimeTypeQL 里是 datetime 加类型约束。我在生成测试用例时确保自然语言问题不依赖特定类型系统比如不说日期格式为 YYYY-MM-DD而是说2024 年 1 月之后的订单。3.2 Prompt 设计如何让 LLM 稳定输出目标语言Prompt 设计直接决定生成质量。我试过三种策略零样本、少样本、带 schema 的少样本。结论是带 schema 的少样本最稳。零样本的问题是模型经常自由发挥比如让它生成 Cypher它给你返回一段看起来像 SQL 的东西。少样本能改善但如果不给 schema模型会瞎猜表名和字段名。带 schema 的少样本是最终方案在 prompt 里明确给出表结构或图模式再给两到三个示例。SQL 的 prompt 模板大致是这样先说明数据库 schema包括表名、字段名、类型、外键关系然后给两个示例问题加标准 SQL最后放目标问题。Cypher 的模板类似但 schema 换成节点标签、关系类型、属性。TypeQL 的模板最复杂因为要说明类型继承和约束。温度参数我统一设为 0保证可复现。max_tokens 设为 512因为大部分查询不会太长。这里有个经验温度设 0 后同一问题多次生成结果基本一致方便做稳定性分析。3.3 执行与打分自动化流水线的搭建打分流水线我用 Python 写的核心是三个函数execute_sql、execute_cypher、execute_typeql。每个函数接收生成的查询字符串返回执行结果或错误信息。SQL 执行用 psycopg2Cypher 用 neo4j 官方驱动TypeQL 用 typedb-client。执行超时统一设为 10 秒避免死循环查询拖垮整个测试。结果集比较时我把所有结果转成排序后的元组列表再和标准答案比对。语义等价性的判断我单独做了一个模块把生成查询、标准答案、自然语言问题一起发给 GPT-4让它判断两者是否语义等价。为了控制成本我只对执行结果不一致的用例做这一步。人工复核时我抽查了 20% 的样本发现 GPT-4 的判断准确率大概在 85% 左右主要错误是把结果相同但逻辑不同误判为等价。4. 实测数据与三种语言的生成表现对比4.1 整体通过率SQL 领先但差距没想象中大跑完 120 个问题乘以三种语言总共 360 次生成结果如下表。我用的是 GPT-4 作为基准模型后面会讲其他模型的表现。查询语言语法通过率执行正确率语义等价率综合得分SQL94.2%78.3%85.1%82.4Cypher88.3%69.2%79.6%74.8TypeQL76.7%54.2%68.3%62.1SQL 的综合得分最高符合预期但 Cypher 和它的差距没有我预想的大。TypeQL 明显落后主要卡在语法通过率上很多生成结果连解析都过不了。分难度看简单问题上三种语言差距不大SQL 96%、Cypher 93%、TypeQL 88%。中等难度开始分化SQL 82%、Cypher 74%、TypeQL 61%。困难难度差距最大SQL 57%、Cypher 41%、TypeQL 24%。这说明复杂查询的生成才是真正的瓶颈。4.2 典型错误模式每种语言都有自己的坑SQL 的典型错误是 JOIN 条件写错和聚合函数误用。比如找出消费金额最高的用户模型经常写成SELECT user_id, MAX(amount) FROM orders忘了 GROUP BY或者把 MAX 用在了错误的字段上。还有一类是 NULL 处理模型经常忽略WHERE amount IS NOT NULL。Cypher 的错误集中在关系方向和多跳路径。比如找出 A 的朋友的朋友模型容易写成(a)-[:FRIEND]-(b)-[:FRIEND]-(c)但实际数据里朋友关系可能是双向的需要写成(a)-[:FRIEND]-(b)-[:FRIEND]-(c)。还有 OPTIONAL MATCH 和 WHERE 的配合模型经常把过滤条件放错位置。TypeQL 的错误最基础很多是类型约束没写对。比如查询里用了has name A但实际类型定义里 name 是string类型需要写成has name A加类型标注。还有一类是推理规则没启用TypeQL 支持类型继承和规则推理模型生成的查询经常忽略这些特性。4.3 不同 LLM 的表现差异不只是模型大小的问题我对比了 GPT-4、GPT-3.5、Claude 2、Llama 2 70B 四个模型。GPT-4 全面领先但有意思的是在 TypeQL 上 Claude 2 的表现接近 GPT-4因为 Claude 对类型系统的理解更好。Llama 2 70B 在 SQL 上还行Cypher 和 TypeQL 就明显掉队。模型SQL 综合得分Cypher 综合得分TypeQL 综合得分GPT-482.474.862.1GPT-3.571.258.341.7Claude 278.670.159.4Llama 2 70B68.949.228.3这个结果说明模型大小不是唯一因素训练数据里目标语言的占比很关键。SQL 数据多小模型也能凑合TypeQL 数据少只有大模型靠泛化能力才能勉强应付。5. 踩坑记录与常见问题排查5.1 测试集构建阶段的三个大坑第一个坑是标准答案的歧义性。我一开始从公开数据集直接拿问题结果发现很多问题有多种合理解释。比如活跃用户到底怎么定义是最近登录还是最近下单。后来我统一规定所有模糊概念都在问题里明确说明比如最近 30 天内有下单的用户。第二个坑是跨语言的数据类型映射。SQL 里的 DATE、Cypher 里的 datetime、TypeQL 里的 datetime 看起来一样但比较行为不同。SQL 里date 2024-01-01是字符串比较Cypher 里需要datetime(2024-01-01)。我在测试集里统一用 ISO 格式并在 prompt 里说明。第三个坑是结果集比较的排序问题。SQL 默认不保证顺序Cypher 也不保证TypeQL 同样。我一开始没排序导致很多正确查询被判错。后来统一在比较前对结果排序问题解决。5.2 生成阶段的稳定性问题温度设 0 后同一问题多次生成结果基本一致但偶尔还是有波动。我测试了 10 次重复生成SQL 的完全一致率是 92%Cypher 是 85%TypeQL 是 78%。TypeQL 波动最大因为模型对它的信心最低。另一个问题是 prompt 长度。带 schema 的少样本 prompt 很容易超过 2000 token导致模型注意力分散。我的解决方案是把 schema 精简到只包含相关表和字段比如查询只涉及用户和订单就不给商品表的定义。还有一个隐蔽的坑是模型会抄示例。少样本示例里如果有WHERE status active模型生成新查询时也经常带上这个条件即使问题里没提。后来我在示例里尽量用不同的字段和条件减少这种干扰。5.3 评估阶段的判断标准统一语义等价性的判断是最主观的环节。我一开始让 GPT-4 直接判断发现它经常把结果相同当成语义等价。比如SELECT * FROM users WHERE age 18和SELECT * FROM users WHERE age 19在整数年龄下结果相同但语义不同。后来我改进了 prompt明确要求判断逻辑等价而非结果等价并给出反例。准确率提升到 90% 左右。剩下的 10% 我人工复核主要处理边界情况比如 NULL 处理和类型转换。还有一个问题是跨语言比较。SQL 的查询和 Cypher 的查询没法直接比语义我只能分别和各自的标准答案比。这意味着三种语言的得分是独立的不能直接说SQL 比 Cypher 好 8 分只能说在各自的标准下SQL 的生成质量更高。5.4 常见问题速查表问题现象可能原因排查方法解决方案生成查询语法通过但执行报错字段名或表名拼写错误对比 schema 检查拼写在 prompt 里强调字段名必须来自 schema结果集为空但预期有数据过滤条件过严或关系方向错误逐步去掉条件测试检查 WHERE 和 JOIN 条件同一问题多次生成结果不同温度参数未设 0检查 API 参数设 temperature0TypeQL 查询解析失败类型约束缺失或错误对照类型定义检查在 prompt 里给出完整类型定义Cypher 路径查询结果重复路径匹配产生笛卡尔积用 DISTINCT 测试检查路径模式是否唯一SQL 聚合结果错误GROUP BY 缺失或字段错误单独执行聚合部分明确 GROUP BY 字段6. 从基准测试到实际应用的落地建议6.1 如何根据业务场景选择查询语言如果你的业务数据天然是关系型的比如订单、用户、商品SQL 是首选LLM 生成质量最高生态也最成熟。如果数据有复杂的关联网络比如社交关系、知识图谱Cypher 更合适虽然生成质量略低但图查询的表达能力是 SQL 比不了的。TypeQL 适合有强类型约束和推理需求的场景比如医疗知识库、金融风控规则但要做好生成质量较低的预期。实际落地时我建议先做小规模验证。选 20 到 30 个真实业务问题手动写标准答案然后跑一遍 LLM 生成看通过率能不能接受。如果 SQL 通过率低于 70%说明 prompt 或 schema 设计有问题先优化这两块再扩大规模。6.2 提升生成质量的四个实操技巧第一schema 要精简且相关。不要把所有表都塞进 prompt只给查询涉及的。我试过给全量 schema生成质量反而下降因为模型被无关信息干扰。第二示例要覆盖目标查询模式。如果业务里经常有找出没有做某事的用户示例里就要有 NOT EXISTS 或 NOT MATCH 的写法。示例和实际问题的模式越接近生成质量越高。第三加后处理校验。生成查询后先用解析器检查语法再用 EXPLAIN 检查执行计划最后跑一次 LIMIT 1 看能不能返回结果。这三步能过滤掉大部分低级错误。第四建立反馈循环。把生成错误的案例收集起来定期更新 prompt 和示例。我每两周更新一次示例库把新出现的错误模式加进去通过率能提升 5 到 10 个百分点。6.3 成本与性能的平衡跑一次完整基准测试的成本不低。120 个问题乘以 3 种语言乘以 4 个模型总共 1440 次 API 调用GPT-4 的成本大概在 30 到 40 美元。如果只是日常验证不需要跑全量选 20 个代表性问题就够了。性能上单次生成延迟在 2 到 5 秒取决于查询复杂度和模型。实际产品里我建议加缓存相同问题直接返回缓存结果。还有一点生成查询只是第一步执行查询可能更慢特别是图数据库的多跳查询要做好超时和降级处理。6.4 后续可以扩展的方向这套基准测试目前只覆盖了三种查询语言后续可以加入 SPARQL、GraphQL、MongoDB 查询等。评估维度也可以扩展比如加入查询效率、可读性、安全性防止 SQL 注入等。还有一个有意思的方向是跨语言翻译。让 LLM 把 SQL 翻译成 Cypher或者把 Cypher 翻译成 TypeQL这个任务的难度比从自然语言生成更高但实际需求也很大比如系统迁移场景。我在实际使用中发现LLM 生成查询最靠谱的场景是辅助而非替代。让模型生成初稿人工审核修改效率比手写高很多但完全放手让模型直接执行风险还是太大。特别是涉及数据修改的语句一定要加人工确认环节。踩过几次坑之后我现在所有生成查询都走生成-校验-预览-确认四步流程虽然麻烦一点但安全得多。