How does AI generate SQL from natural language?

The simplest NL-to-SQL implementation is one prompt: send the user’s question and the database schema to an LLM, get SQL back, run it. This works on toy schemas in demos. On real enterprise data, it fails predictably in three ways:

1. Schema blindness.A real warehouse has hundreds of tables, weird column names from legacy systems, denormalizations, foreign keys that aren’t declared, and business definitions that aren’t in the data itself. An LLM handed a raw schema dump can’t reliably pick the right join, the right filter, or the right aggregation. It guesses, often plausibly, often wrongly.
2. Hallucination.When the LLM is uncertain, it doesn’t pause and ask — it generates. The generated SQL might reference columns that don’t exist, use joins that aren’t valid, or compute aggregations on the wrong grain. Some of these throw errors (visible failure). The dangerous ones run successfully but return wrong results (silent failure).
3. No verification.Without a verification layer, the natural-language answer the LLM produces is decoupled from the actual query result. The narrative might say “sales were $4.2M” while the query returned $3.8M — with no warning to the user.

Each of these failure modes is well-documented in the research literature. Each is unacceptable for enterprise decisions. Production NL-to-SQL systems are designed to make each impossible by architecture.

The first architectural answer is to give the LLM more than the raw schema. A Semantic Knowledge Graph captures the platform’s full mental model of the warehouse:

• Every table, with descriptions of what it represents in the business
• Every column, with data types, units, valid value ranges, and definitions
• Foreign-key relationships, both declared and inferred
• Joins — including non-obvious ones that require intermediate tables
• Business definitions: what does “active customer” mean for this company? What’s the GAAP-vs-gross convention for revenue?
• Common query patterns: how do analysts typically slice this data?
• Denormalizations: which tables aggregate which raw sources?

When the LLM generates SQL, it’s not guessing from raw schema — it’s grounded in a structured knowledge representation that captures how the warehouse actually works. The accuracy delta is dramatic: published benchmarks show schema-aware NL-to-SQL outperforming raw-schema approaches by 2-3x on real enterprise warehouses.

Building the Semantic Knowledge Graph is upfront work — typically done at deployment by a domain-aware team. In Diwo, the graph is built from automatic schema introspection plus a curation step where analysts annotate business definitions. The graph improves continuously as the platform observes which queries succeed and which fail.

Schema awareness reduces hallucination on the SQL generation step. It doesn’t eliminate hallucination in the natural-language answer. The LLM might generate correct SQL, get back $3.8M, and then summarize the result as “sales were $4.2M” in the narrative. This is rare but catastrophic when it happens.

The architectural answer is a verification loop. After the SQL executes and returns numerical results, an Anti-Hallucination Agent compares every number in the natural-language narrative against the actual query result. Mismatches are blocked or corrected before the answer reaches the user.

Three forms of verification typically run in parallel:

• Numerical match. Every number in the narrative must trace to a value in the query result.
• Semantic match.Claims about direction (“sales increased”) must match the actual direction in the data.
• Aggregation grain match.A claim about a monthly figure can’t be derived from an annual aggregation.

The combined effect: by the time an answer reaches the user, every numerical claim has been verified against the actual data the SQL returned. The number you see is the number that came out of your warehouse — not the number the LLM guessed.

Production NL-to-SQL is multi-agent by necessity. Each agent has a narrow scope, verifiable outputs, and is testable in isolation. Diwo Catalyst’s pipeline:

1. Diwo Supervisor Agent— receives the natural-language question, classifies the intent (retrieval / aggregation / comparison / what-if), routes to the correct downstream specialists.
2. SQL Generator Agent— uses the Semantic Knowledge Graph to generate schema-aware, syntactically correct SQL. Multi-shot retry with error feedback if the warehouse returns an error.
3. Query Execution Layer— runs the SQL against the live warehouse with row-level security applied. Returns results plus the SQL for audit.
4. Visual Agent— selects an appropriate chart type based on data shape (time series, categorical breakdown, distribution, scatter).
5. Insight Agent— generates the narrative summary of the result. Pulls candidate interpretations from the data.
6. Anti-Hallucination Agent— verifies every numerical claim in the Insight Agent’s narrative against the query result.
7. Recommendation Agent(when the question is decision-shaped) — produces a ranked, dollar-quantified next-best-action with three AI-validated alternatives.

Underneath the agents, the LLM is a swappable component. In Diwo, customers configure their preferred LLM provider per tenant: OpenAI, Anthropic, Google, Groq, or a private deployment. The architecture, not the LLM choice, is what makes the system enterprise-grade.

If you’re evaluating an NL-to-SQL platform, three diagnostic questions separate production-grade systems from demoware:

1. Does the platform maintain a Semantic Knowledge Graph or equivalent business-definition layer over the warehouse? Or does it just send the schema to the LLM?
2. Is there an Anti-Hallucination layer that verifies every numerical claim in the answer against the actual query result?Or does the LLM’s narrative go straight to the user?
3. Are the SQL queries visible and auditable for every answer?Or does the platform hide the SQL behind “trust us” UX?

A platform that fails any of the three is a science experiment, not an enterprise system. Diwo Catalyst was built with all three as foundational requirements; that architectural commitment is what separates conversational analytics that produces governed decisions from a ChatGPT-shaped wrapper that produces guesses.