Iterative agent converts natural questions into SQL for crime data
An Iterative LangGraph Agent for Text-to-SQL: Natural Language Access to the Chicago Crime Database
Computation and LanguageArtificial IntelligenceDatabases
Summary
Many people want to get answers from big databases but don't know how to write SQL queries. The authors built a system that understands natural language questions about the Chicago Crime database and turns them into SQL queries automatically. Their system checks the question, creates and tests the SQL query, fixes errors if needed, and finally explains the results in simple English. They tested it with 100 questions of varying difficulty and achieved improvements in query accuracy without retraining the language model.
What this means in practice
- •For business analysts: Enable non-technical staff to query large databases in plain language without writing SQL.
- •For customer support teams: Provide quick SQL query generation from written questions about customer data, improving response times.
Tested on one dataset.
Authors
Vigneshwar Ravi Rao, Rupesh Swarnakar, Fayeq Jeelani Syed†
Abstract
Non-technical stakeholders frequently cannot write the SQL needed to extract insights from operational databases. We built and evaluated a Text-to-SQL agent that closes this gap end to end: a six-node LangGraph StateGraph checks question relevance, fetches the live schema, generates PostgreSQL, validates it with a dry run, retries on failure, executes the query, and narrates the result set in plain English. The agent uses prompt engineering only; no model was fine-tuned. We evaluated it on the Chicago Crime dataset (approximately 8.5 million records, 22 attributes) against a hand-built benchmark of 100 natural language questions with ground-truth SQL, stratified into 30 Easy, 40 Medium and 30 Hard items. Comparing two prompt revisions of the same agent, the revised system (V2) reached a Valid SQL Rate of 93% (from 87%), an Execution Accuracy of 60% under a hybrid relational equivalence metric (from 47%; 19% from 12% under strict JSON matching), and a mean Synthesis Quality of 4.34 out of 5 (from 3.91). The single largest driver was removing a LIMIT 10 instruction from the system prompt, which had been truncating multi-row answers. Error analysis attributes the residual failures to relevance-checker false rejections, ambiguous question semantics, and free-tier API rate limits rather than to the language generation step. We report no comparison against an external baseline system or a public benchmark; the study is a single-model engineering evaluation.