Live data from Hacker News

Text-to-SQL is dead, long live text-to-SQL

exasol.com

31–40 of 52 posts

Re: Text-to-SQL is dead, long live text-to-SQL

#31

The current benchmark for real world text to sql is https://spider2-sql.github.io/ and the SOTA is at 64% Anyone selling you 99% accuracy can prove it there first.

Cofounder of one of those analytics agents here (https://getdot.ai).

The promise of the technology is not that it can deal with any arbitrarily complex Enterprise setup, but rather that you expose it with enough guidance on a controlled and sufficiently good data model.

Depending on your use case this can be super valuable as it enables a lot more people to use data and get relevant recommendations.

But yeah it's work to make nice roads and put up signs everywhere.

Re: Text-to-SQL is dead, long live text-to-SQL

#32
post #16

What is the human need to bash SQL at all costs? At its core, such a simple syntax, yet its so powerful at aggregating/manipulating tabular data and the like. Instead we’d rather declaratively say what we want in a more verbose/disjointed way… fascinating

When you're having to work with someone else's godawful convoluted database schema you're sometimes really happy not to have to write the query yourself. Giving the LLM context with previously written queries can be quite effective. The writing SQL experience is a product of both SQL's syntax, the structure of the database you're querying over and the complexity of your query. When things get hairy, and you have a go…

Agreed, but maybe the step change there is refactoring the data model, not continuing to author “hairy” sql via LLM that’s all fine until it breaks… and you end having to mend the nastiness back into compliance the ol’ fashion way

Re: Text-to-SQL is dead, long live text-to-SQL

#33
post #11

Text-to-SQL is effectively pissing in the wind when we start looking at business value. The trouble is that it works just enough to be dangerous. It is a very interesting idea and can easily consume the resources of a technical team ~indefinitely. One obvious sign we are chasing shiny here is the German-to-SQL example. This is fun, but no one would actually pay for it. I would classify Text-to-SQL as a Schedule I rab…

Germany is the 5th biggest economy in the world, then there is Austria and Switzerland. The claim that nobody would pay for German to SQL seems a bit pessimistic ;)

I'd also love to understand better why you think that there is no "acceptable level of value-add in most reasonable enterprises".

Re: Text-to-SQL is dead, long live text-to-SQL

#34
post #11

Text-to-SQL is effectively pissing in the wind when we start looking at business value. The trouble is that it works just enough to be dangerous. It is a very interesting idea and can easily consume the resources of a technical team ~indefinitely. One obvious sign we are chasing shiny here is the German-to-SQL example. This is fun, but no one would actually pay for it. I would classify Text-to-SQL as a Schedule I rab…

>The trouble is that it works just enough to be dangerous. This is a major theme with LLMs. When they first came out you'd see it randomly returning garbage in the middle of an otherwise good output maybe 30% of the time. You knew you had to go through it with a fine tooth comb. Now it's more like 3%. And you just gloss over it. I think you are right about Text-to-SQL being a trap. In this case the deficiencies are u…

Reliability is the important dimension to focus on, but what is your baseline? I've worked in data and me and my colleagues regularly had to confront bugs (on many levels) that were communicated to end users

Re: Text-to-SQL is dead, long live text-to-SQL

#36
Instead of trying to get LLMs from zero to 100, which is impossible to do, you should concentrate on getting them from 75% to 95%. The idea that someone who has no knowledge of the domain and no understanding of relational data modeling can chat “like to know really good um but don’t make any mistakes” with a GPU an uncover the mysteries of the universe is imbecilic.

But… someone what knows approximately what to do and sort of how to do it could work wonders — if we had LLMs trained on a corpus with specific rules.

I don’t know how to left join and what table I need to get the aggregate of sales in each region by date and price range, but I can describe it halfway and know how to check if each step is valid.

LLMs can do this. They’re trained on English, and they are able to weight definitive rules. But instead we throw a random text at a general purpose transformer.

Parsing a response of tokens into grammatical English is the most expensive computation (after the initial scraping and catalog). Instead of wasting all the cycles doing that against the sun total of GitHub, StackOverflow, Reddit, and Wikipedia, create a fuzzy match on a simplification a rigorous specification and train it on your data (just a few million tokens) to teach it that users have primary addresses and are associated to accounts that have regions and region X has roughly 10 times the sales volume of region y.

So someone intelligent in the matter with an understanding of logical rigor and a general idea of the data shape can actually become 10x more efficient, instead of trying to lift vibe coders to the level of Spakespearean monkeys, you could be turning mid-level devs into super analysts.

Re: Text-to-SQL is dead, long live text-to-SQL

#37

This is solving a problem few people have. They assume your table name, column names and relationships is confidential information. For most people such metadata is not confidential.

> This is solving a problem few people have. They assume your table name, column names and relationships is confidential information. For most people such metadata is not confidential.

For most businesses, it really really is. In general, people (businesses) are incredibly sensitive about any possibility of data leakage, even just the metadata. There are lots of companies who would pay for this, and they tend to have a lot of money.

Re: Text-to-SQL is dead, long live text-to-SQL

#38
post #16

Earlier quoted context omitted.

When you're having to work with someone else's godawful convoluted database schema you're sometimes really happy not to have to write the query yourself. Giving the LLM context with previously written queries can be quite effective. The writing SQL experience is a product of both SQL's syntax, the structure of the database you're querying over and the complexity of your query. When things get hairy, and you have a go…

Agreed, but maybe the step change there is refactoring the data model, not continuing to author “hairy” sql via LLM that’s all fine until it breaks… and you end having to mend the nastiness back into compliance the ol’ fashion way

You could definitely load your billions of records with millions of relationships into memory, denormalize, restructure and rewrite the data (flawlessly) a lot cheaper (computationally) than running a large LLM on all that hardware.

Re: Text-to-SQL is dead, long live text-to-SQL

#39
post #31

The current benchmark for real world text to sql is https://spider2-sql.github.io/ and the SOTA is at 64% Anyone selling you 99% accuracy can prove it there first.

Cofounder of one of those analytics agents here ( https://getdot.ai ). The promise of the technology is not that it can deal with any arbitrarily complex Enterprise setup, but rather that you expose it with enough guidance on a controlled and sufficiently good data model. Depending on your use case this can be super valuable as it enables a lot more people to use data and get relevant recommendations. But yeah it's w…

I am working with Databricks' Genies. I have a _very_ complex Enterprise data schema(s). Genies, and from what I can tell, your product work on a set of tables ~20 and expect a well thought out and documented data model.

I have hundreds of tables designed by several different teams. I do have decent documentation on the tables but if I had a nice, organized data model I wouldn't need an AI assistant. If I had a perfect data model my team could write simple SQL queries or give chatgpt a schema dump + a natural language query and it would get the answer most of the time.

IMHO, the big value in this space will be when these tools can wrangle realistic databases.

Post reply on HN