DeepQuery’s production lesson: resolve ambiguity before generating SQL

DeepQuery’s most useful production claim is not that natural language can generate SQL. It is that SQL generation should happen after the system has decided what the user meant, which data shape fits, and whether the request is clear enough to answer. In a newly surfaced deployment note, founding engineer Abhishek Uniyal describes an internal system spanning PostgreSQL, MySQL and MongoDB that puts those decisions in separate stages before query generation. (DeepQuery deployment note)

The pipeline is a sequence of commitments

The implementation starts by classifying a request into a small catalogue: aggregates, entity lookups, time-series comparisons or an explicit “ask me more” branch. It then retrieves pre-computed schema digests rather than dumping the full schema into the prompt. Only after that does it resolve values such as “last week” into dates or “premium users” into a concrete filter. Query generation is last, under an 8,000-token context budget. (DeepQuery deployment note)

That ordering matters because each stage narrows what the model is allowed to assume. A date phrase becomes a defined interval before SQL exists. A business label becomes a resolved value before it reaches a predicate. An unfamiliar request can be rejected before the system selects tables. The architecture therefore treats ambiguity as an input problem, not as something to repair after executing a plausible query. (DeepQuery deployment note)

Refusal beat a broader classifier

Uniyal says the first intent classifier tried to support open-ended requests. The production version instead added a low-confidence clarification path, which he calls the single biggest accuracy improvement. That is an operationally important distinction: the improvement came from shrinking the answerable surface, not from claiming a better model. (DeepQuery deployment note)

The deployment note also records a simpler performance lesson. The first version queried source databases for schema information on every request; pre-computed schema digests were added later, and Uniyal says earlier caching would have saved weeks. The same artifact can therefore serve two purposes: cap prompt size and remove repeated schema discovery from the request path. (DeepQuery deployment note)

What the note does not prove

The page says operators now run their own reports and that engineering time was reclaimed, but it publishes no query count, accuracy rate, latency distribution, error taxonomy or before-and-after result for the clarification branch. It also does not specify how permissions are enforced across the three databases. Those omissions prevent comparison with a benchmark or another deployment. (DeepQuery deployment note)

For practitioners, the defensible takeaway is narrower and still valuable: test intent classification, value resolution, schema retrieval and refusal as separate contracts. If evaluation begins only with generated SQL, the system has already hidden the decisions most likely to make a syntactically valid query answer the wrong question.