Live data from Hacker News

Show HN: Natural-SQL-7B, a strong text-to-SQL model

github.com

111–120 of 171 posts

Re: Show HN: Natural-SQL-7B, a strong text-to-SQL model

#111

I don't think any of those text-to-sql models are solving the right problems. The hard part is not syntax or I don't know how to write a group by query. Most data scientists and engineers spend more time on understanding the meaning of the data. One cannot simply look at a 50 columns table in Snowflake and guess what columns are by their names. For example, we have 10 columns in one tables, all named ...price. We hav…

Yeah, we've been working on this problem a good bit and I think text-to-sql is a dead-end for analytical questions.

We (https://www.definite.app/) ended up abandoning text-to-sql in favor of answering questions with a semantic layer (which LLM's are far more effective against).

https://www.loom.com/share/a0d3c0e273004d7982b2aed24628ef40

Re: Show HN: Natural-SQL-7B, a strong text-to-SQL model

#112
post #108
post #100

Earlier quoted context omitted.

Could you give an example?

This will be useful if you have a table with some related history records, e.g., products with product price history, and you want to get the latest price. The lateral join would get all prices for the current product, sort them by date and then pick the top row.

How does a lateral (cross) join compare to a window function in your example?

Re: Show HN: Natural-SQL-7B, a strong text-to-SQL model

#113
post #104

Earlier quoted context omitted.

Shareware?

Yep. Open source means you can build and modify it. If not, it’s not open source. You know it’s a bad timeline when releasing the equivalent of a binary is considered “open”.

What is old is new again!

Re: Show HN: Natural-SQL-7B, a strong text-to-SQL model

#114

This is not open source, because you have use-based restrictions. Call it what it is, source available.

> Call it what it is, source available. Also, it's only weights AFAICT — no source training data/code is available.

Share-able weights are an interesting one, because although you can't re-generate it from scratch, you can modify it and share it. They're sort of halfway in between source code (which allows you to regenerate a binary from scratch and also inspect everything that went into the binary) and a free-as-in-beer binary (which you typically can't change at all). We sort of need a new term for this kind of thing.

I feel like we should try to reserve "open" for something that has all of the "four freedoms". The key thing about this is that it's not inspect-able, but it is derivable. Derivable-weight license?

EDIT: Looking at the "four freedoms" [1], "freedom 1" is:

> The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this.

Essentially the thing about weights is that you can superficially retrain bits of it to adapt it to your use case without needing to do a full re-train. But of course, without access to the training set, you can't really be sure what's in those weights, nor make more fundamental changes that would require adding or removing data.

[1] https://www.gnu.org/philosophy/free-sw.en.html#four-freedoms

Re: Show HN: Natural-SQL-7B, a strong text-to-SQL model

#115

I don't think any of those text-to-sql models are solving the right problems. The hard part is not syntax or I don't know how to write a group by query. Most data scientists and engineers spend more time on understanding the meaning of the data. One cannot simply look at a 50 columns table in Snowflake and guess what columns are by their names. For example, we have 10 columns in one tables, all named ...price. We hav…

It seems like fine tuning on queries using the underlying schema would work, people are doing this.

Re: Show HN: Natural-SQL-7B, a strong text-to-SQL model

#117

Earlier quoted context omitted.

1. If you are a a programmer I think you should learn SQL. It will give you a different perspective on programming that I think is invaluable. (I.e. programming without for loops) 2. Combining and slicing data is a craft, and doing it subtly wrong in one step can lead to fatal errors in the outcome. And most importantly, it can be very difficult to notice. Numbers don't smell. That is why I would be very hesitant to…

I’ve been working in this industry professionally for close to 25 years now. By far the most valuable and useful language I have learned is SQL.

As a counterpoint, I’ve also worked in this industry for 25 years, and SQL has had no relevance to my career. I write it very occasionally, and if I didn’t, it wouldn’t make any difference.

The C for loop on the other hand…

Re: Show HN: Natural-SQL-7B, a strong text-to-SQL model

#118

Earlier quoted context omitted.

1. If you are a a programmer I think you should learn SQL. It will give you a different perspective on programming that I think is invaluable. (I.e. programming without for loops) 2. Combining and slicing data is a craft, and doing it subtly wrong in one step can lead to fatal errors in the outcome. And most importantly, it can be very difficult to notice. Numbers don't smell. That is why I would be very hesitant to…

I’ve been working in this industry professionally for close to 25 years now. By far the most valuable and useful language I have learned is SQL.

I actually work in the Data/AI space and SQL has been of limited use to me.

Whilst Snowflake is pretty popular the days of elaborately modelled EDWs are long gone.

And so typically I find I am doing queries, transformations etc in some abstraction layer e.g. Spark on a data lake, ORM for web applications etc.

Re: Show HN: Natural-SQL-7B, a strong text-to-SQL model

#119
post #110

Earlier quoted context omitted.

more like, when it comes to complex data structures and logic, i will do that outside of sql. I'll do a join with sql no problem, by the time we're doing multiple inner joins I usually prefer to just do multiple sql queries. I don't care about performance that badly.

That’ll often not scale to millions of records. Letting the database optimizer find the optimal execution path instead of doing it procedurally elsewhere might result in “finishes in 5 minutes”, versus “doesn’t fit in a night”.

This isn’t the 90s. Most hardware is way over-specced for the data sizes most people are dealing with.

The number of use cases which are too heavy to finish in hours but small enough to fit in a single instance is pretty limited.

Re: Show HN: Natural-SQL-7B, a strong text-to-SQL model

#120

Earlier quoted context omitted.

1. If you are a a programmer I think you should learn SQL. It will give you a different perspective on programming that I think is invaluable. (I.e. programming without for loops) 2. Combining and slicing data is a craft, and doing it subtly wrong in one step can lead to fatal errors in the outcome. And most importantly, it can be very difficult to notice. Numbers don't smell. That is why I would be very hesitant to…

I’ve been working in this industry professionally for close to 25 years now. By far the most valuable and useful language I have learned is SQL.

> the most valuable and useful language ...

Programmers think the most valuable language is a programming language. Therefore, an LLM that can generate quality code in that language should also be extremely valuable.

I'd argue that the most valuable language is the natural language of the organization you're writing code for.

That language is vague and ambiguous, and encapsulates many hidden assumptions about how that organization works.

For example, if the organization is a retailer or a wholesaler, you might ask the LLM to generate SQL to return last month's sales and inventory for each site and product category.

The LLM can query the database system tables and guess which tables have sales transactions and inventory transactions. The LLM can look at foreign key definitions to make a good guess how to join these tables with metadata about items, sites, categories and the calendar.

But will the LLM know that inventory is a stock, and sales is a flow? Will it know it should sum the sales transactions but average the inventory balances, or take just the beginning or ending inventory balance?

Many human engineers struggle to translate ambiguous requests in natural language into code which reflects the assumptions and mechanics of the organization.

An LLM that generates consistently useful code needs a world model of how things work, not just how to write code.

Post reply on HN