Why LLMs fail on querying enterprise data

I have no doubt a LLM is able to write a query on your data warehouse in seconds. But I simply don't have faith in its validity. And I don't think this is solvable by another model release. Try it yourself on fable 5.1.

Why do LLMs fail at querying enterprise schemas?

On Spider 1.0, the academic benchmark that made text-to-SQL look solved, GPT-4o answers 86.6% of questions correctly. On Spider 2.0, built from warehouses real companies actually run, where schemas pass a thousand columns and a single answer can take more than a hundred lines of SQL across dialects, the same model answers 10.1%.

Scale accounts for part of this gap, but unwritten domain knowledge accounts for the rest. EntSQL, a benchmark built to test grounding in company-internal knowledge, found that 96 percent of its enterprise questions need domain knowledge beyond the question and the schema: fiscal calendars, cost structures, which entity maps to which. Hand a model the internal documents that hold those rules and the best reported execution accuracy still sits under a quarter of questions.

What kind of errors do the models make?

The way the failures break down is the tell. Three categories cover most of them:

• Constraint capture, over half of all errors: the model fails to carry a business rule into the WHERE clause.
• Scope: the wrong reporting period, or the wrong organizational boundary.
• Aggregation: grouping at a level that quietly double counts.

Not one of those is a SQL error. Every one is a business rule the model could not see.

That is what makes this a problem for operations rather than for engineering. These queries execute. No stack trace, no failed job, nothing red in a log. A well formatted number arrives and looks exactly like a right one. When an agent runs the gathering and reconciling and a person makes the call at the end, a silently wrong number travels further than a crash ever could, because a crash gets caught.

Does more context fix it?

What moves the needle is context, and it moves further than a model upgrade. On one enterprise insurance schema, GPT-4 answered 16% of questions correctly querying the database directly. Given the same questions against a representation that carried the business meaning of the same data, the same model answered 54%. Identical model, identical questions, and the only variable was how much the system had been told about what the business means.

Note that 54% is still a coin flip, which is the part most of this research leaves alone. Context raises the ceiling. It does not guarantee accuracy when the rules are ambiguous or missing. An operation that runs on these answers needs the second half too: every number arriving with the basis it was computed from, and a system that declines the question when the rules do not cover it. A tool that answers everything is checking nothing, and on a schema this size it will be confidently wrong more often than it is right.

The test of an AI system pointed at your warehouse is what it does with the rules that live outside the schema, and what it does when it runs out of them. At Symbric we run the gathering and reconciling steps against the business rules a company already has, attach the source and the checks to every number that comes out, and refuse the question when the rules do not reach it. The person still makes the call. They make it on a number they can check.

That raises the obvious follow-on question, which is where we'll share next: how do you verify AI-generated numbers?