GraphSeek: LLM-Enhanced Graph Analytics

• GraphSeek is an LLM-enhanced framework that uses a two-plane architecture, separating natural-language planning from deterministic graph query execution over large, heterogeneous property graphs.
• It employs a Semantic Catalog to abstract schema elements and graph operators, enabling efficient natural-language interpretation and accurate, multi-step analytical workflows.
• Empirical evaluations show GraphSeek outperforms traditional methods with superior token efficiency, reduced latency, and high success rates on complex, schema-heavy queries in industrial applications.

GraphSeek is an LLM-enhanced graph analytics framework for natural-language, interactive analytics over industry-scale property graphs. Its central architectural move is to avoid direct natural-language-to-query generation and instead let an LLM plan over a compact Semantic Catalog that describes graph schema elements and graph operators, while a deterministic runtime executes the resulting operator invocations against the full graph. This yields a separation between a Semantic Plane for planning and a distinct Execution Plane for database-grade execution, with the stated aim of improving both token efficiency and task effectiveness on large, heterogeneous, dynamically evolving property graphs (Besta et al., 11 Feb 2026).

1. Problem domain and design objective

GraphSeek targets large, heterogeneous, dynamically evolving property graphs that support multi-hop traversals, complex predicates, aggregation, group-by, temporal and cost annotations, and schema-heavy reasoning. The motivating example in the paper is an EV manufacturing graph with hundreds of thousands of nodes and edges, multiple node and edge types, and rich properties. The design problem is not merely graph querying in the abstract, but natural-language graph analytics under industrial conditions where graph size, schema heterogeneity, and multi-step analytical intent all stress conventional LLM pipelines (Besta et al., 11 Feb 2026).

The system is explicitly framed as a response to several failure modes of naïve LLM approaches. Direct NL2Cypher/SPARQL methods assume that relevant schema fragments can be serialized into prompt context and that a single generated query will suffice; GraphSeek argues that this fails under context limits, schema heterogeneity, and multi-query analytical workflows. Generic agent frameworks are described as suffering from repeated prompt-heavy retries, brittle query generation, and weak plan revision under execution feedback. Graph learning methods and graph foundation models are treated as inappropriate for primary execution because they do not provide exact traversals, exact aggregations, or exact result sets. The system’s core claim is therefore methodological: do not ask the LLM to emit full graph queries; ask it to plan over typed graph operators, then delegate execution to a deterministic graph runtime (Besta et al., 11 Feb 2026).

This places GraphSeek in the lineage of graph search research while shifting the emphasis from graph matching or path enumeration alone to LLM-mediated orchestration of graph analytics. A plausible implication is that GraphSeek treats natural-language interaction not as a query-synthesis problem but as a planning problem over a semantically compressed interface to the graph.

2. Two-plane architecture

GraphSeek is organized around a two-plane abstraction. The Semantic Plane contains the LLM-based agent responsible for interpreting the natural-language request, consulting the Semantic Catalog, selecting operators, instantiating arguments, interpreting compact execution summaries, and deciding whether further steps are required. The Execution Plane contains the graph database, a non-LLM executor, and an Adaptive Toolset implementing graph operators. The executor compiles typed operator invocations into backend queries, executes them deterministically, stores full results in a Results Data Cache, and returns compact summaries to the LLM (Besta et al., 11 Feb 2026).

The third architectural pillar is the Semantic Catalog. It bridges the two planes by describing both the graph schema and the operator library in natural-language and typed form. The LLM reasons over this catalog rather than over raw graph topology or raw database schema dumps. This induces a sharp distinction between in-context information and out-of-context information. In context, the LLM sees catalog descriptors, message history, tool definitions, and constant-size summaries. Out of context, the system stores full result tables, large subgraphs, and the graph itself. The paper presents this as the main source of token efficiency and small-context-model compatibility (Besta et al., 11 Feb 2026).

The data flow is iterative. A natural-language request $R$ is interpreted in the Semantic Plane; the LLM produces an operator invocation $a_t = \langle o_t, \theta_t \rangle$; the Execution Plane runs that invocation over graph $G$, yielding a full result $r_t$; a compact summary $s_t = \sigma(r_t)$ is sent back to the Semantic Plane; and the LLM either continues planning or halts with a natural-language answer. This architecture is designed so that the LLM never sees raw graph topology or large query results directly (Besta et al., 11 Feb 2026).

3. Formal execution model and Semantic Catalog

GraphSeek’s graph model is a labeled property graph

$G = (V, E, \lambda_V, \lambda_E, \pi),$

where $V$ and $E$ are nodes and edges, $\lambda_V$ and $\lambda_E$ assign labels or types, and $a_t = \langle o_t, \theta_t \rangle$0 maps nodes and edges to key–value properties. The schema is denoted $a_t = \langle o_t, \theta_t \rangle$1, the operator library $a_t = \langle o_t, \theta_t \rangle$2, and the Semantic Catalog $a_t = \langle o_t, \theta_t \rangle$3. Each operator $a_t = \langle o_t, \theta_t \rangle$4 has a type signature and a compilation into one or more backend queries; operators are therefore an intermediate representation rather than raw backend syntax (Besta et al., 11 Feb 2026).

The system maintains a step-indexed interaction state

$a_t = \langle o_t, \theta_t \rangle$5

where $a_t = \langle o_t, \theta_t \rangle$6 is an artifact store of intermediate results and $a_t = \langle o_t, \theta_t \rangle$7 is the execution trace. Each interaction step decomposes into four stages: $a_t = \langle o_t, \theta_t \rangle$8 The addition of the Decision stage makes the loop explicitly multi-step and self-correcting, which is one of the paper’s main distinctions from one-shot NL2query systems (Besta et al., 11 Feb 2026).

The Semantic Catalog itself consists of Semantic Descriptors of two main kinds. Schema Descriptors explain the role, intent, synonyms, key properties, units, domains, and connectivity hints of schema elements such as node types, edge types, and property keys. Operator Descriptors explain intended natural-language usage, input/output contracts, disambiguation hints, common pitfalls, and compilation sketches. The catalog can also include Artifact Descriptors that summarize intermediate results. For the EV manufacturing graph, the descriptors are reported to be on the order of 2k tokens for the entire graph, and the paper describes the catalog as extending a standard property-graph schema into a semantic graph schema (Besta et al., 11 Feb 2026).

Catalog construction is a hybrid pipeline: auto-drafting from schema introspection, sample values, logs, and documentation; LLM proposals constrained by schema-aware templates; and human validation before integration. This is a significant part of the system’s knowledge layer. A plausible implication is that GraphSeek’s performance depends not only on operator design and LLM behavior but also on the semantic quality of this catalog.

4. Planning, tool invocation, and representative workflows

GraphSeek’s LLM produces structured operator invocations rather than Cypher or Gremlin. An explicit example is the operator call $a_t = \langle o_t, \theta_t \rangle$9 for the natural-language question “How many base-tier drive assemblies do we produce per plant/factory?”. The Execution Plane compiles that invocation to a backend query of the form $G$0 and the LLM then verbalizes the returned summary (Besta et al., 11 Feb 2026).

The same pattern extends to more complex multi-query workflows. For “Show me unique manufacturing blueprint for EV-X7”, the system chooses get_unique_manufacturing_blueprints_for_model(model_name="EV-X7", cost_type="Plan"), executes a compiled graph query that traverses INTEGRATED_IN, ASSEMBLED_AT, and BUILT_AT relations, deduplicates flows, and returns a graph_handle plus a summary. For “In which plant is the material/module with highest market price produced?”, GraphSeek first computes a MAX(marketPrice) aggregate, then realizes that the aggregate alone does not identify the corresponding module, revises the plan to use order_by="marketPrice", limit=1, descending=true, and finally resolves the factory with get_factory_sites_for_module(module_name="BM-9003"). The paper treats this as a canonical instance of multi-step planning with runtime feedback (Besta et al., 11 Feb 2026).

The system also supports comparative and self-correcting workflows. In one example, it retrieves three vehicle models by prefix and then computes a unique production plan for each model before comparing the number of BatteryModule nodes. In another, it first asks for the highest unitCost, then attempts an equality filter using a rounded value and receives an empty result because of floating-point precision, and subsequently revises the strategy to an order_by plus limit=1 ranking query. These examples are central because they show GraphSeek’s intended use case: multi-query analytics, not merely single-query retrieval (Besta et al., 11 Feb 2026).

A defining property of these workflows is that the LLM does not manipulate the graph directly. It manipulates only typed operator invocations over a bounded operator vocabulary. This suggests that GraphSeek’s planning space is intentionally narrower than unrestricted database query synthesis, and that this restriction is precisely what enables its stability on heterogeneous industrial graphs.

5. Empirical profile

GraphSeek is evaluated on two datasets. The industry dataset is an anonymized EV manufacturing graph with approximately 230k nodes, 314k edges, and 20 property keys. The second is WikiDataSets–Countries, with 3,324 nodes, 10,198 edges, 48 relation types, 17,965 attributes, and 37,096 attribute facts. The main baselines are Basic LangChain, Enhanced LangChain, and Enhanced LangChain + Semantic Catalog; GraphSeek is evaluated as Basic GraphSeek, GraphSeek – No Descriptors, and GraphSeek + Special Tools (Besta et al., 11 Feb 2026).

On the industry workload, the paper reports that GraphSeek + Special Tools solves all queries correctly, i.e., 100% success, while Basic GraphSeek is consistently second-best and substantially stronger than LangChain baselines, especially on multi-hop, schema-heavy queries (Q10–Q15). The paper also reports that GraphSeek + Special Tools has median latency of about 2–3 seconds per query, including multi-step self-correction, whereas the LangChain baseline averages about 2 minutes per query, making it 40–60× slower. The abstract further states that GraphSeek achieves substantially higher success rates, with an example of 86% over enhanced LangChain (Besta et al., 11 Feb 2026).

Token usage is treated as a first-class metric. On WikiDataSets–Countries, Basic GraphSeek has median token usage of about 29.7k tokens per query, typically in a narrow 29–31k band when using 2–4 tool calls. Lower outliers, around 7k–14k, are associated with runs in which the model stopped consulting the database and relied on prior knowledge, which could reduce correctness; higher outliers, around 55k, are associated with harder queries requiring 6-call corrective sequences. On industry workloads, GraphSeek + Special Tools is described as having low and stable token costs, whereas LangChain variants show large variance and spikes due to repeated retries (Besta et al., 11 Feb 2026).

The overall empirical claim is not that GraphSeek minimizes tool calls at all costs, but that it achieves better tokens per correct answer and interactive latency while remaining database-grounded. A plausible implication is that the system’s efficiency derives less from using fewer reasoning steps than from constraining those steps to a semantically compressed operator layer.

6. Position within graph search research

GraphSeek belongs to a broader graph search lineage but occupies a distinct layer within it. The survey “Big Graph Search” argues that graph search is a paradigmatic response to large, dynamic, heterogeneous, and distributed graph data, emphasizing trade-offs among friendliness, accuracy, and efficiency (Ma et al., 2014). GraphSeek inherits the “friendliness” objective in a modern form—natural-language interaction—but addresses it through operator planning and semantic abstraction rather than through approximate structural semantics or purely declarative pattern languages (Besta et al., 11 Feb 2026).

Earlier graph-search systems targeted different technical strata. StreamWorks, described as essentially a “GraphSeek” for dynamic, streaming graphs, focuses on exact incremental subgraph isomorphism over a dynamic multi-relational graph using the Subgraph Join Tree (SJ-Tree) and time-windowed continuous queries (Choudhury et al., 2013). GraphQ instead addresses interactive visual pattern search over collections of graphs by reframing subgraph matching into latent-space GNN inference, using NeuroMatch for subgraph decision and NeuroAlign for node correspondence (Song et al., 2022). GraphSearch addresses agentic search-augmented reasoning for zero-shot graph learning, with a graph-aware query planner and retriever operating over local, global, and attribute neighborhoods (Liu et al., 13 Jan 2026). Compared with these systems, GraphSeek is neither an exact dynamic matcher, nor an approximate latent-space graph retriever, nor a zero-shot predictive graph learner. It is a symbolic graph analytics orchestrator in which the LLM plans but does not execute, and the graph database executes but does not reason in natural language (Besta et al., 11 Feb 2026).

The paper itself positions GraphSeek against NL2SQL/NL2Cypher/NL2SPARQL, tool-augmented agents such as LangChain, graph learning/GNN systems, and TAG-style relational decomposition. The closest conceptual neighbor inside the paper’s taxonomy is TAG, because GraphSeek adopts a decomposition into synthesis, execution, and generation, but extends it with an explicit Decision stage and with a Semantic Catalog spanning both schema and operators (Besta et al., 11 Feb 2026). This suggests that GraphSeek is best understood not as a replacement for graph databases or graph search engines, but as a coordination layer that exposes them safely and economically to LLM-mediated analysis.

7. Limitations and prospective developments

GraphSeek’s strengths are paired with explicit limitations. The most prominent is catalog quality and maintenance. The system requires a well-crafted Semantic Catalog whose descriptors must remain accurate and current; construction still involves human validation, and poor descriptors can mislead planning. A second limitation is dynamic schemas: although the Adaptive Toolset can evolve and the paper describes inference-time tool adaptation with schema-aware validation and versioning, frequent major schema changes still require updating descriptors and operators. A third is scope: the framework focuses on symbolic analytics and querying—paths, aggregations, counts, schema-heavy traversals—rather than heavy graph algorithms such as PageRank, centrality, or large-scale path enumeration, which would require specialized operators. A fourth is cost: despite its token efficiency, GraphSeek still depends on LLM calls for planning and result interpretation (Besta et al., 11 Feb 2026).

The paper identifies several future directions. One is extending the same Semantic Plane + Execution Plane pattern beyond property graphs to tabular and relational databases, time-series pipelines, unstructured logs/documents, and streaming/dynamic graphs. Another is deeper cost-aware compilation and planning, including learned budget controllers that select operators under token and latency constraints and decide when to enable or disable descriptors. A third is more automated catalog construction and validation at scale. A fourth is better planning algorithms and Decision policies to avoid unnecessary exploration (Besta et al., 11 Feb 2026).

These limitations indicate that GraphSeek is not merely an LLM wrapper around a graph database. It is a semantically curated execution framework whose reliability depends on operator design, catalog fidelity, and the discipline of keeping execution deterministic. That combination is the defining feature of the system and the main reason it stands apart within the contemporary graph search literature.