)
)
An agent that turns a natural-language question into an executable query needs the schema as ground truth. Generating the query is seldom the hard part. The hard part comes first: mapping the concepts in the question onto the right classes and properties in the ontology.
The obvious approach puts the entire ontology in the prompt. This paper measures what that costs once the ontology reaches enterprise size: recall and F1 fall while latency and spend rise. As an alternative, we evaluate semantic retrieval over ontology entities followed by two deterministic expansion steps over the graph. On our enterprise benchmarks the pipeline reaches 0.89 to 0.90 recall at a per-question cost that stays effectively flat as the ontology grows.
Grounding is where the pipeline breaks.
Reporting layers made structured data usable by curating views around questions someone had already anticipated. If you knew the question, you could prepare the answer. Language models move that boundary. An agent can take an arbitrary question, treat the schema as ground truth, and produce an executable query against it.
Three steps sit behind that: interpret the question, identify the schema entities it refers to, generate and run the query. The second step is the difficult one. Once the right classes and properties are on the table, assembling SPARQL is usually straightforward.
Modeling the data as a knowledge graph and handing the agent the ontology simplifies this considerably. Entities and their relationships are explicit, so the agent does not have to infer structure from fragmented and inconsistent context.
What breaks at enterprise scale.
The standard approach hands the model the full ontology and asks it to pick the relevant entities. It is the simplest thing to build, and it scales badly. Three effects arrive together.
- Cost: input grows with the ontology, so every question gets more expensive.
- Latency: more tokens have to be processed before the first entity is identified.
- Retrieval quality: the model has to locate a few relevant entities inside a long catalog of mostly irrelevant schema. Long-context retrieval is a known weak spot.Modular enterprise ontologies add a fourth. As more modules enter the context, some questions pick up plausible but incorrect competing readings, because similar concepts recur across domains and namespaces under different names.
An ontology is not a document that has to fit inside a prompt. It is a semantic system that can narrow, complete, and constrain the context an agent receives.
What follows from that.
Full-ontology prompting remains a useful baseline. It does not hold up as an operating model once the enterprise schema grows. The alternative is to retrieve a small candidate set first, then recover the missing local structure from the graph itself, without asking the model to reread the whole schema every time.
How large the effect is, which models we measured it on, and what the alternative costs in production: the remaining chapters.