Achieving Precise Text-To-Cypher Via Grounded Knowledge Graph Data Generation Francesco Cazzaro, Jessica Lennon, Ariadna Quattoni Universitat Politècnica de Catalunya, Barcelona, Spain [email protected], [email protected] [email protected]
arXiv:2606.14325v1 [cs.CL] 12 Jun 2026
Abstract Property Graphs are rapidly being adopted as database frameworks for representing heterogeneous data sources. To enable precise access to the information contained in them we need conversational interfaces based on TextTo-Cypher (Text2Cypher) parsers. This paper presents an automatic synthetic data generation method that can be leveraged to fine-tune small LLMs for this task. We conduct experiments on all the major Text-To-Cypher benchmarks, demonstrating that with our synthetic data generation approach we can significantly increase the performance of small LLMs, allowing them to compete with much larger proprietary models. This means that in settings in which models must be locally deployed we can ensure datasovereignty without sacrificing accuracy and without costly annotation campaigns.
1
Introduction
Property Graphs (PGs) are becoming increasingly prominent for representing complex relations between entities across domains but accessing the information contained in them requires expertise in query languages such as Cypher. To reduce this barrier we need accurate conversational interfaces to PGs powered by reliable Text-To-Cypher parsers. One typical approach to develop such interfaces is to implement a Text-To-Cypher parser by directly prompting an LLM. However, there are scenarios in which this might not be possible. For example, this approach might not be feasible in highly regulated industries in which data sovereignty is a major priority. In such setting, solutions based on locally deployed models are a must and small models that can provide high performance without demanding massive hardware resources are preferred. The typical approach in this context is to develop a Text-To-Cypher parser specialized for a target PG by fine-tuning an LLM using annotated data for the target graph.
When fine-tuning models for Text-To-Cypher, acquiring annotated data is often the main bottleneck since such data is usually scarce and creating it is expensive and labor intensive. LLMs can be prompted to generate training data, but the generated data will typically lack the necessary diversity and graph coverage. To mitigate this problem synthetic data generation techniques focusing on comprehensive graph coverage have been proposed. These techniques are able to generate high coverage training data for a target PG without the need of human intervention. Cazzaro et al. (2025a) proposed SPOT, a synthetic data generation approach that works in three stages. In the first stage it generates tree patterns from a target graph to produce grounded Cypher queries. In the second stage it uses a finite-state transducer to produce initial natural language realizations of the grounded Cypher queries (protoNL). Finally in the last stage, the proto-NLs are paraphrased by an LLM to generate the final more fluent samples for training the Text-To-Cypher parser. SPOT yielded encouraging results and the concept of graph driven synthetic data generation held the potential to ensure high graph coverage and overcome the training data bottleneck. However, the approach fell short on two main aspects described in their paper. The first shortcoming relates to the lack of expressivity of the Cypher generation. More precisely, there are some Cypher queries that cannot be generated by the approach, such as nested queries that make use of sub-queries, queries with complex return patterns or queries involving regular expression constraints on features, to name a few. The second shortcoming relates to problems with logical meaning preservation in the paraphrasing phase. While the paraphrasing approach worked well in general, for some patterns paraphrases failed to preserve the logical meaning of the query. When we ran preliminary experiments
with SPOT across a wider range of Text-To-Cypher benchmarks we found that these limitations were indeed critical. This paper addresses the shortcomings of prior approaches to synthetic data generation for fine-tuning Text-To-Cypher parsers and presents CYQUARK, a method that can produce a rich set of Cypher queries, covering a wide range of the Cypher syntax. Furthermore, to handle the logical meaning preservation problem our method implements an improved generation technique and a filtering stage that can reduce the number of noisily generated samples. We conduct thorough experimental evaluation covering the main Text-To-Cypher benchmarks and a broad range of models. Our experiments show that small LLMs have low zero-shot performance, but by using the data automatically generated by CYQUARK it is possible to overcome this performance deficit with fine-tuning. As a result we can obtain locally deployable LLMs whose performance can be comparable to that of the most powerful proprietary closed-source systems. In brief, our main contributions are: • We develop a rich and robust synthetic data generation method and release the corresponding open-source data generation library for creating training data to fine-tune Text-ToCypher models specialized for a target PG at https://github.com/interact-erc/T ext-To-Cypher-knowledge-graph-dat a-generation. • With the data generated by CYQUARK it is possible to develop small locally deployable data-sovereign Text-To-Cypher parsers that have minimal dependence on outside sources. Furthermore, since the resulting LLMs are small, our approach can lead to a lighter environmental footprint. • We present extensive experimental results, covering the main Text-To-Cypher benchmarks and comparing a wide range of models. We believe that our study provides a reliable and rigorous measure of how well the Text-ToCypher task is performed by current models.
2
Related Work
The growing popularity of property graphs has resulted in recent efforts to create benchmarks for Text-To-Cypher. Some works focus on adapting
SQL benchmarks (Zhao et al., 2023a; Tiwari et al., 2025) while other create benchmarks by converting RDF graphs into property graphs (Nie et al., 2022; Feng et al., 2025). Other works generate benchmarks synthetically using pipelines designed around LLMs (Zhong et al., 2025; Chauhan et al., 2025; Lyu et al., 2026) whereas others emphasize human involvement by having annotators create or at least verify samples (Guo et al., 2022; Zhao et al., 2023b; Cazzaro et al., 2025b). Finally Ozsoy et al. (2025) aggregate synthetic examples from various sources, although their benchmark lacks a corresponding graph database for query execution. Regarding Text-To-Cypher parsers, some approaches focus on fine-tuning (Guo et al., 2022; Zhao et al., 2022; Tiwari et al., 2025; Zhong et al., 2025) while others leverage large language models (Li et al., 2024; Liang et al., 2024a; Zhou et al., 2024; Liang et al., 2024b). The work most closely related to us is SPOT (Cazzaro et al., 2025a), a data generation method for training parsers that, however, has limited Cypher expressivity and coverage.
3
Preliminary: Sample Generation Process
We start this section by providing the relevant background on property graphs and tree pattern based synthetic data generation (Cazzaro et al., 2025a). 3.1
Property Graphs
A Property Graph (PG) is a graph database model where entities are represented by nodes and relationships by labeled edges. The main difference with other popular frameworks such as RDF is that in PGs both entities (i.e. nodes) and relations (i.e. edges) can have associated properties (i.e. keyvalue pairs). This provides a richer and more descriptive way to represent complex real-world data. PGs have gained traction in industrial applications as they enable the specification of a semantically intuitive data model in which there is a clear distinction between entity properties and entity relations. In contrast, RDF graphs conflate the two concepts since all properties must be expressed as relations. Two main languages are used for querying PGs, Cypher (Francis et al., 2018) and Gremlin (Rodriguez, 2015). Our work focuses on Cypher, the most popular among the two. This being said, our approach could be generalized to other graph languages.
Figure 1: Query Generation Process
3.2
Finite-State Transduction From Tree Patterns
The generation process assumes two inputs: The target PG and a schema file specifying the graph’s classes, relations, and property types. For each element, the schema also provides a lexicalization field. For example, a relation named EmployeeOf connecting a node of type Person to a node of type Company might have as lexicalization: is employed by. The basic data creation pipeline consists of three main steps illustrated in Figure 1. The first step generates a rooted tree pattern that represents the structure of a Cypher query in which nodes and edges correspond to the entities and relations appearing in a Cypher MATCH clause. The second step decorates the tree by assigning class and relation types to each node and edge. These types are selected to be compatible with the target PG. The decorated tree pattern is then grounded by instantiating properties and other possible features with values drawn from the PG. The resulting grounded tree pattern can be deterministically mapped to a corresponding Cypher query via a finite state process. Analogously, we define a finite state transducer that generates a ‘proto’ natural language realization of the grounded tree pattern. The transducer that generates the proto-NL can be automatically instantiated from the graph schema. The proto-NL preserves the underlying semantics of the query but it might lack fluency and sound ‘artificial’; in the sense that it might not reflect a typical human language utterance. To solve this, the last step of the process uses an LLM to paraphrase the protoNL into a fluent natural language question. This
process is iterated with randomized tree patterns, decorations, and groundings, to generate a large set of question-query pairs.
4
CYQUARK
In this section we present our main contribution, CYQUARK, a method to automatically generate a diverse training set of annotated data pairs for a target PG. Our method, inspired by SPOT (Cazzaro et al., 2025a), starts with a three stage pipeline approach, pattern generation and instantiation from target KG, finite-state proto-NL generation, and LLM paraphrasing, but adds two additional pipeline stages (Fig 2, top). The main difference between SPOT and CYQUARK is the expressivity of the generated queries. While SPOT generates only basic queries, CYQUARK covers most of the complex compositional constructs expressible with Cypher syntax. More precisely, in SPOT tree patterns have a rigid predefined structure which assumes that the query has a single answer node. All tree patterns generated by SPOT are rooted to this unique answer node and each path of the tree corresponds to a MATCH statement whose root is the expected answer of the query. The rigidity of the pattern structures produced by SPOT means that some important and common queries cannot be generated with the method. For example, consider the following query: ‘List the name of each teacher and the average number of students in their classes’ and its corresponding Cypher query: MATCH ( x0 : Teacher ) -[: TEACHES ] - >( x1 : Class ) < -[: ATTENDS ] -( x2 : Student )
Figure 2: Comparison of the pipelines and supported constructs between SPOT and CYQUARK WITH x0 , x1 , COUNT ( x2 ) AS c_x2 RETURN x0 . name , AVG ( c_x2 )
This query cannot be generated by SPOT, since it exhibits a nested structure and multiple answer nodes, i.e. x_0 and c_x2. To address these complex constructs CYQUARK implements a more flexible pattern structure that no longer assumes a single answer node. Implementing these more general constructs involves not only changing the pattern generation step but also modifying the finitestate transducer compositional generation of the corresponding proto-NL realization. Furthermore, the added complexity requires adding additional verification steps to the overall generation pipeline architecture. More precisely, enabling more complex patterns with multiple answer nodes and nested structures, poses two important challenges that must be addressed in the generation process. 1) The added expressive power might lead to Cypher queries that have a correct logical meaning but that are semantically inconsistent. 2) The added query expressivity
increases the intrinsic complexity and ambiguities of the corresponding natural language realizations (e.g. coreference ambiguities). To address these two challenges CYQUARK adds two additional stages to the generation pipeline (Fig 2, top), a semantic consistency step (after Cypher query generation) and a logical meaning verification step (after LLM paraphrasing). Semantic constraints ensure semantic coherence of the generated Cypher query while the logical meaning verification step uses LLMs to ensure that the paraphrasing step did not introduce mistakes. This section is organized as follows, section 4.1 provides all the details of the patterns and constructs that can be generated with CYQUARK, while sections 4.2 and 4.3 provide more details about the semantic consistency and the logical meaning verification steps. 4.1
Complex Cypher Pattern Generation
In contrast to SPOT, CYQUARK can generate a rich set of Cypher patterns covering most con-
structs of the Cypher syntax and representing a broad range of queries. Figure 2 presents a detailed comparison with SPOT. It is important to note that similarly to SPOT, CYQUARK’s Cypher query and proto-NL generations are compositional. This means that the method can generate query/protoNL pairs for every atomic pattern and every combination of these patterns, leading to an exponential growth in query expressivity. We refer to a Basic Query type as a query that contains one or more MATCH clauses and a RETURN. Complex query types combine and extend basic queries. We can group complex queries into four classes (see Appendix D for examples): • Union Query. An Union Query combines the results of two or more Basic Queries. It applies a disjunctive logic, returning results that respect at least one of the constituent conditions. • Comparison Query. A Comparison Query involves two Basic Queries and returns the result of one of them based on a comparison. For example, it may retrieve two persons and return the youngest one by comparing their ages. • Subcall Query. A Subcall Query consists of a Basic Query that contains a nested Basic Query. This structure enables requests that cannot be expressed using a single Basic Query. • Yes/No Query. A Yes/No Query involves a Basic Query modified to return True or False, evaluating an existence or condition statement. CYQUARK can generate queries that use most of Cypher’s expressivity. For example, for node property constraints, CYQUARK supports equality and comparison operators (>, <, >=, <=), stringmatching constraints, negation and regular expressions combining these operators over multiple properties. When generating feature constraints the generation process takes into account the native Cypher data-types (e.g date, time, datetime, integer, float, duration, point coordinates, boolean, and lists). Appendix C describes all functionalities. The generated node constraints can also result from applying functions to atomic feature values. These functions are called aggregators and include sum, count, average, min and max. For example, a query might request nodes for which a given feature value is above a given threshold. The generation also supports nested aggregator constraints. SPOT could only generate single returns, in contrast CYQUARK is able to generate a wide range of return patterns, such as: returning a set of nodes, a subset of node properties, multiple returns of dif-
ferent types or the output of aggregator functions and nested aggregators. Furthermore, there is also flexibility in how the returns can be ordered and grouped. All return types, constraints, aggregators, and nested aggregators are also supported for relationships. Besides, CYQUARK supports relationship stacking, which conceptually represents an OR disjunction between relationships on a single edge. 4.2
Semantic Constraints
CYQUARK is capable of generating a vast array of rich and diverse queries and the generation process ensures that all of them are syntactically valid and that they can be executed against the target PG. However, syntactic correctness does not imply semantic coherence. The additional expressivity enabled by CYQUARK generation has a cost, it might introduce more noisy (i.e. semantically incoherent samples). To address this problem we add an additional component to the generation pipeline that filters queries based on a set of semantic constraint rules. These semantic constraints can be directly instantiated from the target graph schema. For example, an average aggregator function should only be applied to numeric data-types. 4.3
Logical Meaning Verification
The finite-state process that generates the proto-NL for each generated Cypher query was carefully designed to be as unambiguous as possible. However, the expressivity (e.g. complex return patterns and nested structures) enabled by CYQUARK generations means that some language ambiguities are unavoidable. As a result the LLM paraphrasing step becomes harder and it might introduce some errors. More precisely, it might generate a more fluent natural language sentence (as compared to the proto-NL) but it might fail to preserve the logical meaning of the query. To address this, we add an additional step to the generation pipeline which uses an LLM as a logical meaning verifier. More precisely, we prompt an LLM to determine whether the natural language sentence generated in the paraphrasing stage preserves or not the logical meaning as expressed in the Cypher query.
5
Experiments
We test CYQUARK on four Text-To-Cypher benchmarks spanning 19 graphs. We operate in a zeroshot scenario, meaning that we run CYQUARK
Model
BL
ER
CT
HC
WW
AVG.
Qwen3.5-4B Qwen3.5-9B Qwen3.6-27B
84.07 80.08 93.67
59.68 60.83 66.62
45.88 49.07 62.92
49.25 61.21 82.78
59.41 51.00 75.12
59.66 60.44 76.22
GPT-5.5 Claude Opus 4.7
98.17 97.72
77.97 78.87
77.84 77.05
95.06 92.86
89.39 91.01
87.67 87.50
CYQUARK-0.8B CYQUARK-4B
89.30 93.18
80.40 83.91
67.84 69.04
82.96 84.31
78.34 82.64
79.77 82.62
Table 1: Experimental results on MindTheQuery
Model
FP
IT
GG
MB
MP
SN
AVG.
Qwen3.5-4B Qwen3.5-9B Qwen3.6-27B
24.12 29.63 40.25
26.93 30.13 46.61
39.75 43.66 52.15
35.80 29.92 46.91
44.14 45.18 57.96
31.84 34.73 55.27
33.76 35.54 49.86
GPT-5.5 Claude Opus 4.7
53.63 48.43
67.39 71.09
68.43 61.90
66.14 66.18
74.98 69.18
61.36 63.21
65.32 63.33
CYQUARK-0.8B CYQUARK-4B
59.95 65.61
57.62 63.46
56.89 60.11
48.82 54.77
60.27 64.58
43.41 45.76
54.49 59.05
Table 2: Experimental results on Text2GQL-Bench
with default settings and without any human intervention, thus no modifications are made to cater to the specifics of the different Knowledge Graphs. We do this to ensure a fair comparison with out-ofthe-box LLMs, which also operate in a zero-shot manner. 5.1
Benchmarks
We test CYQUARK on the following benchmarks: • M IND T HE Q UERY (Chauhan et al., 2025): A recently released benchmark, we run evaluations on all the graphs in the test set: Bloom (BL), Entity Resolution (ER), Contact Tracing (CT), Healthcare Analytics (HC), Women World Cup 2019 (WW). • C YPHER B ENCH (Feng et al., 2025): This work focuses on building property graphs from RDF graphs and in particular from Wikidata. We consider all the graphs assigned to the test set: Company (CO), Fictional Character (FC), Flight Accident (FA), Geography (GE), Movie (MO), Nba (NB), Politics (PO). • T EXT 2GQL-B ENCH (Lyu et al., 2026): This is the newest of all the benchmarks that are used in our experiments. We consider all the graphs assigned to the test set: Financial Payment (FP), Information Technology (IT), Geography Graph
(GG), Manufacturing Bill of Materials (BM), Manufacturing Production Process (MP), Social Network Twitter (SN). • Z OGRASCOPE (Cazzaro et al., 2025b): A benchmark focused on a crime investigation graph, it comes with three test partitions: iid (IID), compositional (COMP), length (LEN). 5.2
Models
We utilize the data generated by CYQUARK to fine-tune two small models of the Qwen family (Team, 2026), specifically Qwen3.5-0.8B and Qwen3.5-4B. For both paraphrasing and filtering we employ Qwen3.5-9B using the prompts reported in Appendix F and G. We report some examples of CYQUARK generations in Appendix E. We compare CYQUARK with the de-facto alternative method when no training data is available for a parser: i.e. prompting LLMs in a zero shot fashion. We construct a prompt (reported in Appendix H) where we provide the knowledge graph schema along with instructions to generate the Cypher query. We employ open-weights model from the Qwen family to have a direct comparison, specifically Qwen3.5-4B, Qwen3.5-9B and Qwen3.6-27B (6 times bigger than the model fine-
Model
CO
FC
FA
GE
MO
NB
PO
AVG.
Qwen3.5-4B Qwen3.5-9B Qwen3.6-27B
19.48 26.20 54.30
25.94 35.90 65.96
33.91 57.45 75.35
33.49 41.12 64.68
33.65 29.77 61.50
41.72 42.28 76.74
24.51 25.11 53.28
30.39 36.83 64.54
GPT-5.5 Claude Opus 4.7
89.32 87.57
88.29 91.79
92.17 91.72
79.34 80.02
88.71 87.97
96.32 91.68
87.37 89.32
88.79 88.58
CYQUARK-0.8B CYQUARK-4B
83.55 82.85
79.08 82.80
88.61 88.59
76.18 84.10
88.14 89.81
89.15 87.33
83.92 82.18
84.09 85.38
Table 3: Experimental results on CypherBench
Model
IID
COMP
LEN
AVG.
Qwen3.5-4B Qwen3.5-9B Qwen3.6-27B
33.37 41.99 50.06
31.50 33.26 53.80
18.31 16.80 38.21
27.73 30.68 47.26
GPT-5.5 Claude Opus 4.7
67.28 73.86
72.01 75.09
57.76 63.75
65.68 70.90
CYQUARK-0.8B CYQUARK-4B
75.79 79.35
80.90 82.45
68.18 73.52
74.96 78.47
Table 4: Experimental results on Zograscope
tuned by CYQUARK). Additionally, we also compare with two proprietary closed source models: GPT-5.5 and Claude Opus 4.7. These are regarded as among the most powerful models currently available. Although their exact parameter counts are undisclosed, they are generally estimated to be two orders of magnitude larger than the models we finetune using CYQUARK’s data. As evaluation metric for our experiments we report execution accuracy.
6
Results and discussion
Tables 1, 2, 3 and 4 show results across the four Text-To-Cypher benchmarks. The first observation is that, as expected, the performance of the different models in a zero-shot scenario is highly dependent on their size. In particular, the performance of small models improves as we increase the size going from 37.94 for the 4B model to 41.21 for the 9B model and 60.67 for the 27B (average performance across all benchmarks). While performance improves, even a 27B model exhibits weak zero-shot performance. The large models work very well for the CypherBench and MindTheQuery benchmarks but have weaker performance on Text2GQL-Bench and Zo-
grascope. When looking at the performance of Claude versus GPT-5, there does not seem to be a significant difference. Claude is better for some benchmarks and GPT-5 for others, but on average over the four benchmarks Claude has 78.58 accuracy and GPT-5 78.52, less than a 0.1 difference. If we focus on the results that we obtain by finetuning small LLMs with our synthetic data generation approach we observe a significant increase in performance. A 4B LLM with CYQUARK data doubles the average accuracy rate (i.e. 76.21 versus 37.94). Even a tiny 0.8B LLM fine-tuned with CYQUARK data has a 73.30 average accuracy. With CYQUARK the performance of the small LLMs becomes very close to that of the most powerful proprietary LLMs, 76.21 CYQUARK versus 78.58 and 78.52 of Claude and GPT-5 respectively. Essentially, using CYQUARK it is possible to obtain a free, small locally deployable LLM with performance that is comparable to that of expensive models that charge for each single query. The cost of the computational resources required to generate the data and fine-tune the model is negligible and would quickly get amortized as more queries are processed.
Model
MTQ
T2G
CBE
ZOG
CYQUARK-0.8B - w.o. filtering
79.77 78.02
54.49 50.33
84.09 81.51
74.96 72.98
CYQUARK-4B - w.o. filtering
82.62 79.06
59.05 52.78
85.38 83.25
78.47 76.52
Table 5: CYQUARK performance with and without filtering. The average for each benchmark is reported.
6.1
Filtering
In table 5 we report the average results for each benchmarks, for CYQUARK models trained with and without filtering. In Appendix B, we report the full breakdown by individual datasets. We see that the filtering step consistently improves performance, yielding a 6% increase in the case of Text2GQL-Bench. The increase in performance for individual datasets varies, but excluding a few exceptions, it yields consistent performance gains, as high as 9 percentage points for some datasets. 6.2
Paraphrasing Quality
To get a better understanding of the paraphrasing and filtering steps of our data generation pipeline, we conducted a manual evaluation study with human annotators. All the annotators had expertise on the Cypher language. We generated 100 samples with CYQUARK across all graphs, covering all different query types. The experiment was as follows: we showed the annotator the Cypher query and the corresponding natural language realization produced by our pipeline just before the filtering stage (i.e. after LLM paraphrasing). Then we asked the annotator to decide if the natural language query preserved the logical meaning of the Cypher query or not, essentially the annotator played the role of a logical meaning preservation verifier. Overall 65% of the generated natural language queries were correct. Then we run the samples through our filtering stage and used the gold expert generated annotations to evaluate the precision and recall of the LLM filter when predicting incorrect paraphrases. The filter had an 80 % recall and a 66 % precision in predicting paraphrasing errors. The high recall means that it can successfully remove most mistakes. Precision is lower (i.e. it might wrongly remove good samples) but this is not a problem since we can always generate more samples.
6.3
LLM Data Generation
We experimented with prompting LLMs for data generation and fine-tuning small LLMs using the resulting data. We employed GPT-5.5. On the Manufacturing Production Process graph from Text2GQL-bench, the fine-tuned model scored 42.64 against CYQUARK 64.58, while on Zograscope (AVG) it achieved 26.33 compared to CYQUARK 78.47. We did our best to optimize our generation prompts (Appendix I) to improve performance. In particular, we designed variations to specifically request different query types and different Cypher constructs to achieve as much coverage as possible over multiple rounds of prompting. However, the results highlight that this is a challenging task and more complex pipelines may be necessary for LLMs. It is important to note that the computational costs associated with GPT-5.5 escalated and that is one of the reasons why we had to limit the number of graphs that we could test.
7
Conclusion
Property Graphs have emerged as powerful data models but accessing them via conversational interfaces requires robust Text-to-Cypher parsers. While LLMs can power these parsers, data sovereignty requirements often necessitate smaller, locally deployable models. Since small LLMs struggle with zero-shot performance, fine-tuning them with annotated data is necessary, yet acquiring such data remains a significant bottleneck. Prior work addressed this by proposing a method to automatically generate training data for a target PG. However, this method was lacking in Cypher syntax coverage. This paper addresses this critical shortcoming by expanding the range of expressivity of the generated queries while making sure that the enriched expressivity does not compromise the quality of the generated data. We conducted extensive experiments on all the main Text-To-Cypher benchmarks. Our results show that with our method
we can bring the performance of small locally deployable LLMs very close to that of proprietary LLMs. This essentially means that we can ensure data-sovereignty without having to sacrifice accuracy.
Limitations One limitation of CYQUARK is that it only supports English for the natural language questions and Cypher for the query language. This being said, because of its modular design, extending the tool to work with other graph query languages should be relatively easy. Generalizing to another graph language will involve adjusting the finite state process to reflect the syntax of the target language. Analogously, generalizing to other input languages would involve modifying the finite-state process that generates proto-NL from decorated tree-patterns, this second type of generalization would probably be more challenging but still feasible, also depending on how closely related the language is to English. Furthermore as stated in the paper the process of paraphrasing as well as filtering could be improved by more complex approaches. Our approach successfully generates complex tree patterns and translates them into both Cypher and natural language. However, real world user interactions with PGs are seldom limited to a single query, they are usually conversational and iterative. We believe that future research should focus on expanding this method to generate training data for multi round semantic parsing. This would shift the focus from one off queries to a continuous dialogue based interaction, better reflecting how users actually communicate their needs.
Risks and Ethical Considerations Our proposed method aims to facilitate more efficient information retrieval within graph structures. While we do not identify immediate ethical risks or safety concerns inherent in this work, we acknowledge that any system utilizing automatically generated data requires careful implementation. To prevent the propagation of factual inaccuracies or existing biases within Knowledge Graphs, we recommend that such systems be deployed with human oversight.
Union’s Horizon 2020 research and innovation programme under grant agreement No 853459. The authors gratefully acknowledge the computer resources at ARTEMISA, funded by the European Union ERDF and Comunitat Valenciana as well as the technical support provided by the Instituto de Física Corpuscular, IFIC (CSIC-UV). This research is supported by a recognition 2021SGR-Cat (01266 LQMC) from AGAUR (Generalitat de Catalunya).
References Francesco Cazzaro, Justin Kleindienst, Sofia Márquez Gomez, and Ariadna Quattoni. 2025a. SPOT: Zeroshot semantic parsing over property graphs. In Findings of the Association for Computational Linguistics: ACL 2025, pages 10057–10073, Vienna, Austria. Association for Computational Linguistics. Francesco Cazzaro, Justin Kleindienst, Sofia Márquez Gomez, and Ariadna Quattoni. 2025b. ZOGRASCOPE: A new benchmark for semantic parsing over property graphs. In Findings of the Association for Computational Linguistics: EMNLP 2025, pages 4239–4246, Suzhou, China. Association for Computational Linguistics. Vashu Chauhan, Shobhit Raj, Shashank Mujumdar, Avirup Saha, and Anannay Jain. 2025. Mind the query: A benchmark dataset towards Text2Cypher task. In Proceedings of the 2025 Conference on Empirical Methods in Natural Language Processing: Industry Track, pages 1890–1905, Suzhou (China). Association for Computational Linguistics. Yanlin Feng, Simone Papicchio, and Sajjadur Rahman. 2025. CypherBench: Towards precise retrieval over full-scale modern knowledge graphs in the LLM era. In Proceedings of the 63rd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), pages 8934–8958, Vienna, Austria. Association for Computational Linguistics. Nadime Francis, Alastair Green, Paolo Guagliardo, Leonid Libkin, Tobias Lindaaker, Victor Marsault, Stefan Plantikow, Mats Rydberg, Petra Selmer, and Andrés Taylor. 2018. Cypher: An evolving query language for property graphs. In Proceedings of the 2018 International Conference on Management of Data, SIGMOD ’18, page 1433–1445, New York, NY, USA. Association for Computing Machinery.
Acknowledgments
Aibo Guo, Xinyi Li, Guanchen Xiao, Zhen Tan, and Xiang Zhao. 2022. Spcql: A semantic parsing dataset for converting natural language into cypher. In Proceedings of the 31st ACM International Conference on Information & Knowledge Management, CIKM ’22, page 3973–3977, New York, NY, USA. Association for Computing Machinery.
This project has received funding from the European Research Council (ERC) under the European
Zhuoyang Li, Liran Deng, Hui Liu, Qiaoqiao Liu, and Junzhao Du. 2024. Unioqa: A unified framework
for knowledge graph question answering with large language models. Preprint, arXiv:2406.02110. Yuanyuan Liang, Keren Tan, Tingyu Xie, Wenbiao Tao, Siyuan Wang, Yunshi Lan, and Weining Qian. 2024a. Aligning large language models to a domainspecific graph database for nl2gql. In Proceedings of the 33rd ACM International Conference on Information and Knowledge Management, CIKM ’24, page 1367–1377, New York, NY, USA. Association for Computing Machinery. Yuanyuan Liang, Tingyu Xie, Gan Peng, Zihao Huang, Yunshi Lan, and Weining Qian. 2024b. Nat-nl2gql: A novel multi-agent framework for translating natural language to graph query language. Preprint, arXiv:2412.10434.
Joint Conference on Artificial Intelligence, AI 2023, Brisbane, QLD, Australia, November 28–December 1, 2023, Proceedings, Part II, page 120–132, Berlin, Heidelberg. Springer-Verlag. Ziyu Zhao, Wei Liu, Tim French, and Michael Stewart. 2023b. Rel2graph: Automated mapping from relational databases to a unified property knowledge graph. arXiv preprint arXiv:2310.01080. Ziyu Zhao, Michael Stewart, Wei Liu, Tim French, and Melinda Hodkiewicz. 2022. Natural language query for technical knowledge graph navigation. In Data Mining, pages 176–191, Singapore. Springer Nature Singapore.
Songlin Lyu, Lujie Ban, Zihang Wu, Tianqi Luo, Jirong Liu, Chenhao Ma, Yuyu Luo, Nan Tang, Shipeng Qi, Heng Lin, Yongchao Liu, and Chuntao Hong. 2026. Text2gql-bench: A text to graph query language benchmark [experiment, analysis & benchmark]. Preprint, arXiv:2602.11745.
Zijie Zhong, Linqing Zhong, Zhaoze Sun, Qingyun Jin, Zengchang Qin, and Xiaofan Zhang. 2025. SyntheT2C: Generating synthetic data for fine-tuning large language models on the Text2Cypher task. In Proceedings of the 31st International Conference on Computational Linguistics, pages 672–692, Abu Dhabi, UAE. Association for Computational Linguistics.
Lunyiu Nie, Shulin Cao, Jiaxin Shi, Jiuding Sun, Qi Tian, Lei Hou, Juanzi Li, and Jidong Zhai. 2022. GraphQ IR: Unifying the semantic parsing of graph query languages with one intermediate representation. In Proceedings of the 2022 Conference on Empirical Methods in Natural Language Processing, pages 5848–5865, Abu Dhabi, United Arab Emirates. Association for Computational Linguistics.
Yuhang Zhou, Yu He, Siyu Tian, Yuchen Ni, Zhangyue Yin, Xiang Liu, Chuanjun Ji, Sen Liu, Xipeng Qiu, Guangnan Ye, and Hongfeng Chai. 2024. r3 NL2GQL: A model coordination and knowledge graph alignment approach for NL2GQL. In Findings of the Association for Computational Linguistics: EMNLP 2024, pages 13679–13692, Miami, Florida, USA. Association for Computational Linguistics.
Makbule Gulcin Ozsoy, Leila Messallem, Jon Besga, and Gianandrea Minneci. 2025. Text2Cypher: Bridging natural language and graph databases. In Proceedings of the Workshop on Generative AI and Knowledge Graphs (GenAIK), pages 100–108, Abu Dhabi, UAE. International Committee on Computational Linguistics. Marko A. Rodriguez. 2015. The gremlin graph traversal machine and language (invited talk). In Proceedings of the 15th Symposium on Database Programming Languages, DBPL 2015, page 1–10, New York, NY, USA. Association for Computing Machinery. Qwen Team. 2026. Qwen3.5: Accelerating productivity with native multimodal agents. Aman Tiwari, Shiva Krishna Reddy Malay, Vikas Yadav, Masoud Hashemi, and Sathwik Tejaswi Madhusudhan. 2025. Auto-cypher: Improving LLMs on cypher generation via LLM-supervised generationverification framework. In Proceedings of the 2025 Conference of the Nations of the Americas Chapter of the Association for Computational Linguistics: Human Language Technologies (Volume 2: Short Papers), pages 623–640, Albuquerque, New Mexico. Association for Computational Linguistics. Ziyu Zhao, Wei Liu, Tim French, and Michael Stewart. 2023a. Cyspider: A neural semantic parsing corpus with baseline models for property graphs. In AI 2023: Advances in Artificial Intelligence: 36th Australasian
A
Experimental Details
We train our models on a single A100 GPU and every result reported is the average of 5 runs with different seeds. We did minimal parameter tuning and all our runs employ 0.000005 as learning rate, 0.01 weight decay, a single epoch and 16 as batch size.
B
Filtering Breakdown
C
CYQUARK Features
D
Query Types
E
Generation Examples
Model
BL
Mind The Query ER CT HC
WW
AVG.
CYQUARK-0.8B - w.o. filtering
89.30 90.27
80.40 74.73
67.84 64.16
82.96 81.14
78.34 79.80
79.77 78.02
CYQUARK-4B - w.o. filtering
93.18 90.46
83.91 77.10
69.04 68.96
84.31 81.40
82.64 77.37
82.62 79.06
Table 6: CYQUARK performance with and without filtering on Mind the Query
Model
FP
Text2GQL-Bench IT GG MB
CYQUARK-0.8B - w.o. filtering
59.95 55.47
57.62 56.27
56.89 50.36
48.82 49.15
60.27 56.92
43.41 33.80
54.49 50.33
CYQUARK-4B - w.o. filtering
65.61 58.41
63.46 58.85
60.11 52.46
54.77 51.12
64.58 59.26
45.76 36.57
59.05 53.78
MP
SN
AVG.
Table 7: CYQUARK performance with and without filtering on Text2GQL-Bench
Model
CO
FC
CypherBench FA GE MO
NB
PO
AVG.
CYQUARK-0.8B - w.o. filtering
83.55 82.54
79.08 79.35
88.61 87.71
76.18 74.16
88.14 84.22
89.15 81.34
83.92 81.25
84.09 81.51
CYQUARK-4B - w.o. filtering
82.85 82.72
82.80 85.85
88.59 88.21
84.10 79.95
89.81 86.43
87.33 81.38
82.18 78.20
85.38 83.25
Table 8: CYQUARK performance with and without filtering on CypherBench
Model
ZOGRASCOPE IID COMP LEN
AVG.
CYQUARK-0.8B - w.o. filtering
75.79 74.32
80.90 76.93
68.18 67.69
74.96 72.98
CYQUARK-4B - w.o. filtering
79.35 79.03
82.45 80.13
73.52 70.39
78.47 76.52
Table 9: CYQUARK performance with and without filtering on ZOGRASCOPE
Feature Nodes
Equality
Query example
Options
(x0:Person WHERE x0.nationality =
-
'German')
Comparison operators
(x0:Person WHERE x0.birth_date >
>, <, >=, <=
date('1980-11-24')) (x0:Book WHERE x0.title CONTAINS
String Matching
'Dinosaurs') (x0:Person WHERE NOT x0.nationality =
Negation
STARTS WITH, ENDS WITH, CONTAINS -
'German')
Multiple constraints
(x0:Person WHERE x0.nationality =
-
'German' AND x0.birth_date.year > 1980) (x0:Person WHERE x0.nationality =
Disjunction
-
'German' or x0.nationality = 'Spanish')
Data types support
(x0:Place WHERE x0.coordinates = Point({x: 51.2312, y:4.4185}))
Components
(x0:Person WHERE x0.birth_date.year >
Aggregators
(x0:Company) RETURN x0 ORDER BY
integer, float, time, dates, duration, point, boolean year, month, day, ...
1980) x0.launch_year ASC LIMIT 1
Nested aggregators
WITH COUNT(DISTINCT x0) AS z0_0 WHERE
COUNT, MAX, MIN, TOP_N, AVG, SUM any in aggregators
AVG(z0_0) > 2 Relations
Returns
Properties
(x0)-[r:Founded WHERE r.year = 2010]-(x1)
Aggregators
WHERE COUNT(r) > 5
Nested Aggregators Stacking
WITH COUNT(r) AS z0_0 WHERE AVG(z0_0) > 3 (x0)-[:FRIEND_OF|COLLEAGUE_OF]-(x1) RETURN x0
Node Property Aggregators
RETURN x0.age RETURN COUNT(x0)
Nested aggregators List unwinding Ordering Relations Multiple returns
WITH COUNT(x0) AS z0 RETURN AVG(z0) UNWIND x0.nicknames AS uw RETURN uw RETURN x0 ORDER BY x0.date ASC MATCH (x0)-[r]-(x1) RETURN r RETURN x0.age, x1, x2.nationality
Table 10: Supported CYQUARK Cypher features
any node property constraints COUNT, MAX, MIN, TOP_N, AVG, SUM any in aggregators COUNT, MAX, MIN, AVG, SUM any in aggregators -
Type NL Query Type NL
Query
Type NL
Query
Type NL
Query
Type NL Query
BASIC QUERY List the name of each teacher and the average number of students in their classes MATCH (x0:Teacher)-[:TEACHES]->(x1:Class)<-[:ATTENDS]-(x2:Student) WITH x0, x1, COUNT(x2) AS c_x2 RETURN x0.name, AVG(c_x2) UNION QUERY What are the capitals of the countries that are located in Asia or have an area of at least 1,787,000 square kilometers? CALL () { MATCH (x0:Country)-[:locatedIn]-(x1:Continent WHERE x1.name = "Asia") RETURN x0 UNION MATCH (x0:Country WHERE x0.area_km2 >= 1787000) RETURN x0 } WITH DISTINCT x0 RETURN x0.capital COMPARISON QUERY Who is younger, the director named John or the consultant named Brad? MATCH (x0:Director WHERE x0.name = "John") MATCH (y0:Consultant WHERE y0.name = "Brad") RETURN CASE WHEN x0.age < y0.age THEN x0 ELSE y0 END AS answer SUBCALL QUERY Return each person together with the youngest person they have met MATCH (x0:Person) CALL (x0) { MATCH (x0:Person)-[:met]-(x1:Person) RETURN x1 as sb1 ORDER BY x1.age LIMIT 1 } RETURN x0, sb1 YES/NO QUERY Is there a country whose capital is Windhoek? RETURN EXISTS { MATCH (x0:Country_ge WHERE x0.capital = "Windhoek") }
Table 11: Examples of different types of Cypher queries.
Proto-NL
list name of each Company with launch year that is 1962 that
NL
- operate in radio communications Identify the names of all companies established in 1962 that are currently active in the radio communications
Query Proto-NL
sector. MATCH (x0:Company WHERE x0.launch_year = 1962)-[:operatesIn]-(x1:Industry WHERE x1.name = "radio communications") RETURN x0.name what is the sum of number of deaths of Fligth Accident that - involve Aircraft Model with height in meters that is 7.1 (list also the maximum of the Aircraft Model wingspan)
NL
that were produced by Aircraft Manufacturer with country that is United States of America If we look at flight accidents involving aircraft from US manufacturers with a height of 7.1 meters, what is the sum of fatalities recorded, and what is the largest wingspan found in this specific group of models?
Query
Proto-NL
MATCH (x0:FlightAccident)-[:involves]-(x1:AircraftModel WHERE x1.height_metre = 7.1)-[:manufacturedBy]-(x2:AircraftManufacturer WHERE x2.country = "United States of America") WITH SUM(x0.number_of_deaths) as su_x0, MAX(x1.wingspan_metre) as ma_x1 RETURN su_x0, ma_x1 list year of founding date of each Country that are either Country with official language that is Haitian Creole OR Country with founding date that is less or equal than 1949-05-09 and founding date that is greater or equal than
NL
1939-03-14 For countries founded anytime from March 14, 1939, up to May 9, 1949, or those that designate Haitian Creole as their official tongue, please provide their founding year.
Query
CALL () { MATCH (x0:Country WHERE "Haitian Creole" IN x0.official_language) RETURN x0 UNION MATCH (x0:Country WHERE x0.founding_date <= date('1949-05-09') AND x0.founding_date >= date('1939-03-14')) RETURN x0 } WITH DISTINCT x0 RETURN x0.founding_date.year
Proto-NL
Does exist Asset with id that is A00435 that
NL
- is located at Location with name that is not Lowehaven Office? Does the asset bearing the identifier A00435 have a location that differs from the Lowehaven Office?
Query
RETURN EXISTS { MATCH (x0:ASSET WHERE x0.asset_id = "A00435")-[:LOCATED_AT]-(x1:LOCATION WHERE NOT x1.name = "Lowehaven Office") }
Table 12: Examples of CYQUARK generations.
F
Paraphrasing Prompt
### Role You are an expert NLP specialist and query paraphrasing assistant. Your goal is to convert artificial, syntax-heavy sentences (derived from Cypher queries) into natural, fluent, and grammatically correct English questions or requests. ### Critical Logic Extraction Before rewriting, mentally extract the **exact** list of entities, labels, relationship types, and filters from the input sentence. - **WARNING**: Do not summarize. Do not generalize. Do not omit any specific values (dates, names, IDs, numbers). The output must logically entail exactly the same results as the input query. ### Input Peculiarities & Handling The input sentences often contain specific artifacts from graph query generation. You must handle these as follows: 1. **Numerical/Alphabetic References**: If you see markers like `(1)`, `(X)` or similar references used to point to specific nodes, do not include them in the final output.. Treat them as internal pointers to understand the sentence. 2. **"And also the target" Phrasing**: If the sentence includes a clause like "and also the target," understand this as an instruction to apply new filters or specifications **to the very first entity mentioned** (the root node). 3. **Lists and Multiple Lines**: If the input appears as a bulleted list or split across multiple lines, convert this into a single, cohesive, flowing sentence. 4. **Minimum and maximum**: Usually used for ordering. Minimum of a date would be the earliest, first or oldest. Depending on object paraphrase with qualifiers such as shortest or biggest. ### Constraints & Rules 1. **Strict Semantic Integrity**: - The output must answer the **exact** same question as the input. - **Forbidden**: Adding external assumptions, omitting critical constraints, or merging distinct entities into vague groups. - **Mandatory**: Every specific entity, filter, and relationship mentioned in the original sentence must be represented explicitly or clearly in the paraphrase. - Note that years can range even beyond 2026 2. **Natural Fluency**: - The output must sound like a native human wrote it. Eliminate robotic phrasing, awkward "It is...", "The one that...", and forced grammar structures common in code-to-text generation. 3. **Maximum Variation**: - Use diverse synonyms for key terms (e.g., instead of "has a relationship with," use "is connected to," "relates to," "is linked with"). - Change the sentence structure (e.g., transform active voice to passive, or reorder clauses). - Break down long logical chains into smoother, more conversational phrasing without losing steps. - It is absolutely important that the three sentences are as different as possible from one another. Particularly in the structure and order the things are mentioned. DO use logical leaps! 1) 2) and 3) must be different! Still list everything that must be in output exactly - All caps AND is a logical divider that introduces a new condition or relation independent from the one before, there can be multiple independent AND - either plus all caps OR is a disjunction between statements before and after the OR (the possible AND are part of the disjuncted statements) 4. **Output Format**: - Provide exactly **three** distinct paraphrased sentences. - Number them clearly as 1), 2), and 3). - **Crucial**: Ensure all three options preserve every detail from the original. - Immediately after the third option (3), add a single line containing only the tag: `[END]`. - Do not include explanations, introductions, JSON, or markdown code blocks around the text. ### Examples **Example Sentence**: How many Pages that - belong to Recipe (for each list also grouped by Recipe type) that require Ingredient (for each list also the average of how many of these the Ingredient per Recipe) **Example Paraphrase**: 1) How many pages are dedicated to recipes, grouped by recipe type, and on average what is the number of ingredients involved for each recipe 2) For each recipe type, what is their total page length and mean number of ingredients for a single one 3) List the average number of ingredients used in a single recipe and the total count of pages they occupy, tallied per recipe type **Example Sentence**: what is the average duration of each Standup Comedy with duration that is greater or equal than 12 that
- were sponsored by any Media Company that sponsored Standup Comedy with duration that is 18 (for each list also the Standup Comedy original language) **Example Paraphrase**: 1) What is the average duration of stand-up comedy performances lasting at least 12 minutes that are sponsored by media companies that also sponsored standups of 18 minutes, list also the original language of those 18 minute shows 2) list the language spoken at 18 minute standups sponsored by a media company. For this media company also list the average length of sponsored standups longer than 12 minutes 3) If we look at one specific media company sponsor's 18-minute standup shows, what languages are spoken? And separately, what is the average length of all their other sponsored standups that go on for more than 12 minutes? **Example Sentence**: list name of each Province that - contain any Amusement Park (for each list also the minimum of the Amusement Park cost) - is hosting - with end date that is null - Event with type that is sport **Example Paraphrase**: 1) Among provinces hosting a sport event that has not finished yet, list their name along with the cost of the least expensive amusement park in it 2) What is the cost of the cheapest amusement park in each province that has an ongoing sport event? Also what is the name of each Province? 3) For every province where a sport event is still happening, list the province name and the cost of its cheapest amusement park **Example Sentence**: list age of each person named John Smith that - has written Book that has relased Version with the sum of earning that is greater or equal than 10234 **Example Paraphrase**: 1) What is John Smith's age, given that he has authored a book earning more than 10,234? 2) For books which combined versions earnings is more than 10234, list the age of its author if it is named John Smith 3) Find the ages of every individual named John Smith that has earned at least 10234 from writing a book ### Task Please paraphrase the following sentence following the rules above. **Original Sentence**: [[QUERY]]
G
Filtering Prompt
Does the following query make sense? Consider only the logical meaning. The syntax is correct, it is just a newer cypher version. You have to consider if this is something someone would ask or it would just be confusing. We also provide a schematic meaning of the query in natural language answer with yes or no in between <sense> tags. You can include a very short explanation in between <explanation> tags. Query: [[QUESTION]] [[QUERY]]
H
Text-To-Cypher Prompt
### Role You are an expert Neo4j and Cypher specialist. Your task is to translate natural language questions into accurate, executable Cypher queries. ### Schema You must strictly follow this graph schema. Only use the node labels, relationship types, and properties explicitly defined here: [[SCHEMA]] ### Instructions - Generate a valid Cypher query that can run directly in Neo4j without modification. - Use only the labels, relationships, and properties defined in the schema. - If a property requires operations (e.g., AVG, SUM, comparisons) and needs casting from the schema, apply the appropriate type casting function (e.g., toInteger(), toFloat()) before using it. - Return exactly and only the data requested.
- Do not include explanations or comments. ### Output Format Wrap the final Cypher query strictly between the following tags: <query> your Cypher query here </query> ### Task Convert the following natural language request into a Cypher query: <question> [[QUERY]] </question>
I
Data Generation Prompt
You are an expert in Neo4j Cypher, semantic parsing, and natural language question generation. Your task is to generate exactly [[num_questions]] Cypher queries and their corresponding natural language questions for a Neo4j property graph. These examples will be used as synthetic training data for an AI model that translates Cypher queries into natural language questions. Use the graph schema as the source of valid labels, relationships, and properties for the Cypher queries. Use the provided feature-value pairs when concrete values are needed. Natural language questions must sound like something a real, human user would type into a search engine, not like a direct structural translation of the graph. The Cypher query defines the meaning. The NL question is only a user-facing rephrasing of that meaning. Graph schema: [[schema]] Provided node and relations feature-value pairs: [[node_relations_values]] In-context examples: [[in_context]] IMPORTANT: If no in-context examples are provided, generate the examples using only the schema, provided node feature-value pairs, and instructions. Task: Generate exactly [[num_questions]] examples. Each example must contain: 1. A Cypher query. 2. A natural language question that corresponds exactly to that Cypher query. Strict generation requirements: - [[specific_type_or_cypher_feature_request]] - Make the questions diverse and avoid duplicates or near-duplicates. - Use only node labels, relationship types, and properties from the schema. - Generate some queries that use concrete values from the provided feature-value pairs. - Generate some queries that do NOT use concrete values. - When using a concrete value, copy it exactly from the provided feature-value pairs, character by character. - Do not invent labels, relationship types, property names, or values. Incorrect examples include: using undefined properties, reversing relationship directions, or combining unrelated node types. - Do not require external knowledge. Aggregator-specific Cypher rules: - Use AVG over a property of type INTEGER or FLOAT. Cypher construction rules: - Generate valid Neo4j Cypher. - Use MATCH patterns that are consistent with the provided schema.
- Use WHERE clauses only with valid properties and, when applicable, provided values. - Respect property data types. - Do not apply numeric aggregation to STRING properties. - If a property may be missing and this affects correctness, include an IS NOT NULL condition. - For date-like properties, use comparisons that are consistent with the format shown in the provided values. Natural-language question rules: - Each natural language question must preserve all constraints, aggregations, comparisons, orderings, limits, and relationships in the Cypher query, but may paraphrase freely in natural language. - Prefer user-intent-first phrasing over schema-role-first phrasing. - Each natural language question should sound like a human wrote it, not like a direct translation of Cypher or a copy of the schema wording. - Natural language questions should be understandable to a non-technical user who does not know Neo4j Cypher or the graph schema. - Avoid schema-like wording and syntax. In-context example usage: - If in-context examples are provided, use them only as random examples of the expected output style, structure, and Cypher format. - Note that the in-context examples do not come from this graph, they are just neutral examples to help you. - Do not reuse labels, relationship types, properties, or values from the in-context examples unless they also appear in the provided graph schema and feature-value pairs. Output format: Return only a valid JSON array. The JSON array must contain exactly {num_questions} objects. Do NOT include markdown, comments, explanations, or symbols outside the JSON, or any text before or after the JSON. Each object must have exactly these two fields: - "Cypher" - "NL Question" Use this JSON structure: [
]
{{ "Cypher": "Cypher query here.", "NL Question": "Natural language question here." }}