coding by Promptsicle Team

New Benchmark Tests LLM Text-to-SQL Capabilities

A new benchmark evaluates large language models' abilities to convert natural language queries into SQL code, testing their text-to-SQL translation

Agentic Text-to-SQL Benchmark Tests LLM Database Skills

SELECT customers.name, SUM(orders.total) 
FROM customers 
JOIN orders ON customers.id = orders.customer_id 
WHERE orders.date > '2024-01-01' 
GROUP BY customers.name 
HAVING SUM(orders.total) > 1000;

This query retrieves high-value customers from a database, joining tables and applying conditional logic. Writing such SQL from natural language descriptions has become a key test for large language models, and a new benchmark called BIRD-SQL (BIg Bench for LaRge-scale Database Grounded Text-to-SQL Evaluation) now measures how well LLMs handle these tasks when given agency to explore schemas and refine their queries.

Background on Text-to-SQL Evaluation

Text-to-SQL conversion has progressed from simple single-table queries to complex multi-database scenarios. Earlier benchmarks like Spider and WikiSQL established baseline metrics, but they presented static problems with predetermined schemas. Models received a question, a database schema, and generated SQL in one shot.

The agentic approach changes this dynamic fundamentally. Rather than treating SQL generation as a single prediction task, newer frameworks allow models to inspect database contents, execute test queries, review error messages, and iterate toward correct solutions. This mirrors how human developers actually work with unfamiliar databases.

BIRD-SQL introduces several complications absent from previous benchmarks. The dataset includes 95 databases spanning 37 professional domains, from healthcare systems to financial platforms. Many tables contain hundreds of columns with cryptic naming conventions. External knowledge requirements appear frequently—questions that demand understanding domain-specific terminology or business logic not explicitly stated in the schema.

Comparison Across Model Architectures

Testing on BIRD-SQL reveals significant performance gaps between model families. GPT-4 achieves execution accuracy around 54% when given agentic capabilities, compared to 46% in zero-shot mode. Claude 3 Opus reaches 51% with iteration allowed. Open-source models like Llama 3 70B and Mixtral 8x22B score in the 35-42% range even with schema inspection tools.

The benchmark distinguishes between execution accuracy (does the query return correct results) and exact match accuracy (does the SQL precisely match the reference solution). Execution accuracy runs 8-12 percentage points higher across all models, since multiple valid SQL formulations can produce identical results.

Smaller models struggle particularly with queries requiring multiple joins across three or more tables. A question like “Find the average salary of employees in departments with more than 10 people, excluding contractors” involves joining employee, department, and contract tables while applying aggregation filters. GPT-4 successfully navigates these in 67% of cases, while Llama 3 8B manages only 23%.

Interestingly, providing database content samples alongside schemas improves performance more than increasing model size. When shown three example rows from each relevant table, Mixtral 8x7B jumps from 31% to 39% accuracy—a larger gain than upgrading to the 8x22B variant without examples.

What Stands Out in Agentic Behavior

The most revealing aspect of BIRD-SQL involves tracking how models use their agency. Successful query generation typically follows a pattern: schema inspection, initial query attempt, error analysis, and refinement. GPT-4 averages 2.3 query iterations per problem, while Claude 3 averages 1.8 and open models average 1.4.

Models that iterate more don’t necessarily perform better. The correlation between iteration count and success rate is weak (r=0.23). What matters is iteration quality—whether models extract useful information from error messages and adjust their approach accordingly.

Common failure modes emerge clearly. Models frequently hallucinate column names that sound plausible but don’t exist: customer_lifetime_value instead of total_purchases, or employee_start_date instead of hire_date. Even with schema inspection available, models sometimes skip this step and rely on assumptions.

Another pattern involves over-complicated queries. When asked “How many orders were placed last month?”, models sometimes generate elaborate CTEs and subqueries instead of straightforward date filtering. The reference solution might be three lines; the model produces fifteen.

The benchmark also exposes reasoning gaps. A question about “profitable products” requires understanding that profit equals revenue minus cost—knowledge not encoded in the schema. Models must infer this relationship or request clarification, and most fail to do either.

Conclusions for Practical Applications

BIRD-SQL results suggest text-to-SQL remains challenging for production deployment without human oversight. Even top-tier models fail nearly half the time on realistic database tasks. The gap widens further when databases use non-standard naming conventions or require domain expertise.

Organizations implementing text-to-SQL systems should expect to provide extensive schema documentation, example queries, and validation workflows. The agentic approach shows promise but requires careful tool design—models need not just the ability to inspect schemas but guidance on when and how to use that capability.

Future improvements will likely come from better schema understanding rather than raw model scaling. Teaching models to systematically explore database structures, recognize naming patterns, and map natural language to domain-specific terminology may yield larger gains than simply training bigger transformers.