Multi-Agent GraphRAG: A Text-to-Cypher Framework for Labeled Property Graphs

Introduction

• LLM-based querying over full-schema LPGs remains underexplored, despite LPGs’ rich attributes, flexible schemas, and compatibility with Cypher.The task requires handling schema variability, multi-hop traversal, typed relationships, and attribute-level reasoning while producing executable queries.Source: Introduction · p. 1
• Multi-Agent GraphRAG combines query generation, entity verification, execution, and feedback-driven refinement for natural-language question answering over property graphs.The system is evaluated on benchmark and domain-specific datasets.Source: Introduction · p. 1

Labeled Property Graphs

• A property graph is defined as a labeled directed multigraph with nodes, edges, endpoint mappings, labels, and properties.The definition represents labels and property values as mappings over nodes and edges.Source: Labeled Property Graphs · pp. 1–2
• A path is a finite alternating sequence of nodes and edges whose edges connect successive nodes; its length counts edges.A zero-length path is a single node, and its label concatenates the edge labels.Source: Labeled Property Graphs · p. 2

Related Work

• Cypher-based LLM graph reasoning remains limited relative to RDF and SPARQL, while property-graph literature emphasizes algorithms and models over query execution and semantics.The paper frames this as a gap in query-level structured knowledge extraction.Source: Related Work · p. 2

GraphRAG.

• GraphRAG uses graph-structured data for retrieval and response synthesis, but prior work remains fragmented and focused on knowledge and document graphs.One described approach builds entity-based graph indexes and community summaries for question answering over private text corpora.Source: GraphRAG · p. 2

Knowledge Base Question Answering (KBQA).

• KBQA includes semantic parsing into executable logical forms and information retrieval from relevant subgraphs or facts; GraphRAG extends the retrieval-based approach.The cited account treats IR-based KBQA as a special case within structured information access.Source: Knowledge Base Question Answering (KBQA) · p. 2

Text-to-SQL Semantic Parsing.

• Text-to-SQL methods include sketch-based slot filling, sequence-to-sequence generation, tree-based parsing, and grammar-constrained decoding.Examples include Seq2SQL, RAT-SQL, SmBoP, and SyntaxSQLNet.Source: Text-to-SQL Semantic Parsing · p. 2

LLM Multi-Agent Text-to-SQL.

• Agent-based Text-to-SQL systems divide generation among specialized agents, using candidate generation, decomposition, retrieval, refinement, or selection.CHASE-SQL, Mac-SQL, and Alpha-SQL illustrate these approaches.Source: LLM Multi-Agent Text-to-SQL · pp. 2–3

Agent-Based Graph Reasoning.

• Agent-based graph reasoning includes iterative reasoning, interaction, and execution, as well as cooperative knowledge-graph exploration with self-reflection.These approaches address graph reasoning and QA tasks.Source: Agent-Based Graph Reasoning · p. 3

Text-to-Cypher.

• Prior text-to-Cypher work includes Neo4j interfaces, domain-specific QA, and datasets; this paper emphasizes runtime database interaction, iterative refinement, and IFC-based building representations.CypherBench targets full-schema property graphs, while the paper implements its workflow on Memgraph and tests AEC use cases.Source: Text-to-Cypher · p. 3

Implementation

• The workflow assigns distinct subtasks to seven cooperating agents and a graph-database query executor.The Query Generator uses the graph schema and aggregated feedback to revise queries; the executor returns data, errors, or empty results.Source: Implementation · p. 4
• The Query Evaluator checks semantic consistency, query logic, and result validity, grading outputs as Accept, Incorrect, or Error or Empty.Error or Empty covers runtime failure or a query returning no results.Source: Implementation · p. 4
• The verification module checks extracted labels, property values, and edge patterns against graph data, then suggests replacements for entities it cannot find.Replacement candidates use normalized Levenshtein similarity and LLM semantic ranking; the Instructions Generator turns verification findings into revision guidance.Source: Implementation · p. 4
• The Feedback Aggregator combines evaluator and verification signals into prioritized corrections addressing semantic inconsistencies, execution errors, and naming mismatches.Accepted queries are passed to an Interpreter for a concise, domain-relevant natural-language answer.Source: Implementation · p. 4
• Schema-aware self-correction incorporates semantic validation and data-level verification feedback over a maximum of four iterations.The loop detects logical flaws or schema mismatches and generates targeted correction instructions.Source: Implementation · pp. 4–5
• The Query Generator receives the graph schema in its system prompt, formatted to resemble Cypher, alongside representative node attribute-value examples.The authors report improved generation quality with the Cypher-like schema format; implementation uses Python 3.12, LangGraph, and Memgraph.Source: Implementation · pp. 4–5

Experimental Setup

• CypherBench evaluation sampled 150 question–answer pairs from each of five diverse graphs: art, flight accident, company, geography, and fictional character.The selected benchmark graphs contain heterogeneous schemas; the authors describe CypherBench as providing public multi-domain graphs and question–query pairs at scale.Source: Experimental Setup · p. 5
• The additional engineering evaluation used a publicly available single-storey house IFC model, represented as a graph, with ten manually curated questions of varying structural complexity.The setup is intended to demonstrate applicability beyond open-domain knowledge graphs in structured engineering data contexts.Source: Experimental Setup · pp. 5–6
• The baseline comparison tests four LLM backbones in single-pass and agentic configurations, with the agentic configuration using evaluation, verification, and iterative query refinement.Accuracy is assessed by an LLM judge comparing generated natural-language answers with JSON database outcome ground truth.Source: Experimental Setup · p. 6

Experimental Results

• The multi-agent workflow outperforms the linear-pass baseline across all tested models and domains, with average gains of +10.23% for Gemini 2.5 Pro, +6.79% for GPT-4o, +7.67% for Qwen3 Coder, and +10.01% for GigaChat 2 MAX.Table 1 compares accuracy across CypherBench domains and models.Source: Experimental Results · p. 6, Table 1 · p. 6
• On the Sample House IFC questions, the system correctly answers the last three questions that the baseline answered partially or not at all.The results also include examples of expressing uncertainty and grounding answers in graph database contents.Source: Experimental Results · p. 6

Discussion and limitations

• Schema validation, query-name normalization, database-grounded feedback, and entity verification help correct structural errors and support convergence to schema-compliant, executable queries.Database feedback can correct relationship direction or type, while auxiliary queries check whether names and identifiers match graph entries.Source: Discussion and limitations · pp. 6–7
• Reformulating strict equality comparisons as explicit property-value retrieval can make comparisons observable when direct checks return empty or ambiguous results.The example retrieves each character’s creator before comparing them.Source: Discussion and limitations · p. 7
• Even with multistep feedback, the system struggles with disjunctions and symmetric relationships; explicit query planning or intermediate symbolic representations may be needed.Source: Discussion and limitations · p. 7
• Multi-intent questions can conflate distinct subgoals, producing misaligned answer structures when the system must list children and count their descendants.Source: Discussion and limitations · p. 7
• The authors identify compositional and structurally complex Cypher queries as remaining limitations for future improvement.Source: Discussion and limitations · p. 7

Conclusion

• Results across CypherBench and IFC-derived datasets show improved query accuracy and robustness compared with existing LLM baselines.The workflow combines query generation, entity verification, execution, and aggregated feedback in an iterative refinement loop.Source: Conclusion · p. 7
• The system targets Memgraph, while its refinement loop uses auxiliary Cypher queries for adaptive, context-aware correction.The authors contrast this dynamic interaction with prior systems that often rely on static schemas.Source: Conclusion · p. 7
• The IFC sample-data demonstration concerns building representation in the AEC sector and illustrates access to complex structured technical data.The authors identify this as a digital-construction application context.Source: Conclusion · p. 7
• Future work includes multiturn dialogue, explicit subgoal planning for compositional queries, and larger domain-specific datasets, particularly IFC-linked Cypher queries.The authors identify these as directions supporting adoption of AI-driven solutions in digital construction and operation.Source: Conclusion · p. 7

Appendix A

• The example schemas guide the Query Generator and cover nodes and relationships from CypherBench’s fictional-character graph.The node example includes properties and sampled values; the relationship example lists graph patterns.Source: Appendix A · p. 10
• Node properties are organized hierarchically using dot-separated property names, with sampled examples of property values.The examples include Character, FictionalUniverse, and Location node types.Source: Appendix A · p. 10
• The relationship examples include types such as basedIn, bornIn, diedIn, hasFather, hasSpouse, and memberOf, with endpoint node labels shown.For example, bornIn connects Character to Location, while hasFather connects Character to Character.Source: Appendix A · p. 10

Appendix B

• Memgraph rejects the initial query because a relationship pattern is used directly in a WHERE clause, and the run is classified as an execution error.The trace reports one execution attempt before the error feedback.Source: Appendix B · p. 11
• The checker flags the names Corlys Velaryon and Daemon Targaryen for correction and offers similar or semantically relevant entity suggestions.The trace includes Levenshtein similarity scores among the suggestions.Source: Appendix B · p. 11
• The generated instructions recommend separate matches for the two conditions, combining their results, and counting distinct characters.They also specify the corrected, case-sensitive names for the name property.Source: Appendix B · pp. 11–12

OPTIONAL MATCH

• Two OPTIONAL MATCH clauses find characters meeting each condition, combine the results into one list, and count distinct characters.The described query is a valid, though somewhat complex, way to implement an OR condition.Source: OPTIONAL MATCH · p. 12
• 3 characters satisfy the question’s father-or-spouse condition.The returned count is count(DISTINCT c).Source: OPTIONAL MATCH · p. 12

• The building contains 3 doors, with a count query matching IfcDoor nodes.Source: Appendix C · p. 13
• 76.47 m³ in the given response contrasts with the predicted 76465.52 m³ roof-space volume, which the passage says appears unusually large.Source: Appendix C · p. 13
• The building has 2 stories, and the corresponding Cypher counts IfcBuildingStorey nodes.Source: Appendix C · p. 13
• The entrance hall’s gross floor area is 8.69 m², while its perimeter is given as 12.81 m and as 12,810 in the response.Source: Appendix C · p. 13
• The examples identify Lux as the illuminance unit and report no space identified as a Laundry.Source: Appendix C · p. 13
• Other examples give the building address as Westminster, London, UK, the project name as ProjectName, and the roof’s unconnected height as 1.00 m.Source: Appendix C · p. 13