Live data from Hacker News

Replacing a SQL analyst with 26 recursive GPT prompts

patterns.app

71–80 of 311 posts

Re: Replacing a SQL analyst with 26 recursive GPT prompts

#71
post #52

> this is shockingly close to replacing an entire role at companies with only a couple hours of effort. and > It seems like there’s almost no limit to how good GPT could get at this. I don't see how that's a valid conclusion given the results. 2 simple things right, moderate to difficult things wrong? Hardly a ringing endorsement.

Glad i'm not the only one who saw this.

Feels extremely overblown. Very impressive, don't get me wrong, and is yet another bridge closer to letting business side do plain text queries.

But that said, stuff like this has existed for awhile, and it's certainly not replacing analysts. For a start, this assumes a VERY clean model, which is of course what you strive for, but the moment you step out of FAANG you'll find that many places have a decent, but not ideal, model/warehouse/db which only makes things like this worse.

Getting the simple examples right is interesting, but hardly replacing an analyst. A basic background around tech and some skill navigating w3schools would replace an analyst if this was the bar.

The mildly complex queries being "almost" right is frankly horrifying. Others have mentioned how much of a "oh fuck" it is to send out bad data, and having some AI generate your answers an be SLIGHTLY off is basically worse than it being obviously off. You now have to check every query it generates for errors, because you won't be able to glance check if its sane or not.

Finally, at least where I work, these probably wouldn't even qualify as medium complexity queries? I don't really know how the industry at large would qualify these, but "using 2 inner joins, a where, a group, and a order" all falls under beginner skills in my eyes?

Its still fascinating, and I'm glad they showed HOW they did it, but this isn't replacing anyone, at least if you're paying taxes off the data.

Re: Replacing a SQL analyst with 26 recursive GPT prompts

#72
post #20

The problem is that you never really know whether the chat bot gets it right or terrifically wrong unless you already know how to do the task yourself. And in some cases, paying an analyst $50/hr. for a higher degree of confidence than you can get from a $1 chat bot is still very much worth it. The stakes are higher, too. If the chat bot gets it wrong, what are you going to do, fire it? There goes a small trickle of…

In my experience, in many cases, the so-called "first draft" (of code, content, etc.) is more just helpful for a mental warm-up. It isn't actually suitable. The time it takes to write/code/etc. isnt in the typing, that's trivial. It's in modelling the problem (, audience) and solving it. ChatGPT isnt in the game of modelling problems and solving them, it possesses only superficial semantic characteristics of the ques…

The similar thought I had yesterday was that ChatGPT is pretty good at generating sample code that doesn't otherwise exist. It can be really useful if you treat it like that.

Of course I've also had it call functions and use constants which don't exist, and fail to correct itself even after repeated prompting. So even that only goes so far.

Re: Replacing a SQL analyst with 26 recursive GPT prompts

#73

While this is very cool, SQL was designed to be used by business people. We need to go back to that model, where we train the business people who need these analytics how to use SQL to uncover the result. That along with a rigorous policy for including the queries that produced the result so the query logic can be checked would go a long way to actually taking advantage of the data we're collecting as businesses.

Sorry friend, but this is a bit out of touch. Maybe that was the original design intent of SQL, but understanding the application's data model is beyond a lot of sql analysts, much less their business partners.

Re: Replacing a SQL analyst with 26 recursive GPT prompts

#74

While this is very cool, SQL was designed to be used by business people. We need to go back to that model, where we train the business people who need these analytics how to use SQL to uncover the result. That along with a rigorous policy for including the queries that produced the result so the query logic can be checked would go a long way to actually taking advantage of the data we're collecting as businesses.

I have been spectacularly unable to get any business people to learn SQL.

I even find that very few will bother with reporting tools (eg Tableau) for simple self-service.

Instead, the expectation is that there will be a programmer/DBA/report writer position dedicated to producing analytics "on-demand."

Re: Replacing a SQL analyst with 26 recursive GPT prompts

#76

I love those ChatGPT projects! Of course it's silly and nobody is really replacing somebody with a program that confidently get half it's answers wrong. But it's fun to just naively let ChatGPT solve the problem. But I wonder what it's going to look like in a few years. Currently, it's really just a demo that got surprisingly huge traction. I think the most pressing problem is not to get ChatGPT smarter but to get it…

> nobody is really replacing somebody with a program that confidently get half it's answers wrong I gotta tell you, I use copilot to help with my coding, and it still sends a shiver down my spine when it writes the entire database migration based off of the filename, or writes 4 pages of automated tests that work right on the first try.

I've had it freak me out with how prescient can be, but it also gets a lot of things subtly wrong, like its programming against an API similar to the one in my application, but not identical.

Re: Replacing a SQL analyst with 26 recursive GPT prompts

#77

Anyone who's been asked more than a couple of times for data that requires a non-trivial bit of ad-hoc SQL will know the sinking "oh shit" feeling that comes when you subsequently realise you borked the query logic in some subtle way and have accordingly emailed out a completely bogus answer/report. From the article it doesn't seem that GPT is significantly better or worse than a human in this regard, although an exp…

20 years ago I Knew a sql analyst that would write his tests ahead of time. Give X data, report should be Y. He would then figure out the SQL. He Didn’t know any other programming. This was before TDD took off. Blew my mind.

That's more or less how I learned as well but these days we have plenty of material available.

Re: Replacing a SQL analyst with 26 recursive GPT prompts

#78
A couple of thoughts jumped out after reading this: transforms and meta-learning.

An old trick in AI is to transform the medium to Lisp because it can be represented as a syntax-free tree that always runs. In this case, working with SQL directly led to syntax errors which returned no results. It would probably be more fruitful to work with relational algebra and tuple relational calculus (I had to look that up hah) represented as Lisp and convert the final answer back to SQL. But I'm honestly impressed that ChatGPT's SQL answers mostly worked anyway!

https://en.wikipedia.org/wiki/Genetic_programming

http://www.cis.umassd.edu/~ivalova/Spring08/cis412/Ectures/G...

https://www.gene-expression-programming.com/GepBook/Chapter1...

https://github.com/gdobbins/genetic-programming

I actually don't know how far things have come with meta-learning as far as AIs tuning their own hyperparameters. Well, a quick google search turned up this:

https://cloud.google.com/ai-platform/training/docs/hyperpara...

So I would guess that this is the secret sauce that's boosted AI to such better performance in the last year or two. It's always been obvious to do that, but it requires a certain level of computing power to be able to run trainings thousands of times to pick the best learners.

Anyway, my point is that the author is doing the above steps semi-manually, but AIs are beginning to self-manage. Recursion sounds like a handy term to convey that. ChatGPT is so complex compared to what he is doing that I don't see any reason why it couldn't take his place too! And with so many eyeballs on this stuff, we probably only have a year or two before AI can do it all.

I'm regurgitating 20 year old knowledge here as an armchair warrior. Insiders are so far beyond this. But see, everything I mentioned is so much easier to understand than neural networks, that there's no reason why NNs can't use these techniques themselves. The hard work has already been done, now it's just plug n chug.

Re: Replacing a SQL analyst with 26 recursive GPT prompts

#79

Anyone who's been asked more than a couple of times for data that requires a non-trivial bit of ad-hoc SQL will know the sinking "oh shit" feeling that comes when you subsequently realise you borked the query logic in some subtle way and have accordingly emailed out a completely bogus answer/report. From the article it doesn't seem that GPT is significantly better or worse than a human in this regard, although an exp…

>> The best fix imo is to slather a battery of views over your data to minimise the risk of getting the joins wrong, and it'd be interesting to see how that approach could improve the bot's quality.

Yes, the success of the bot's query (at least on GPT-3) is a combination of (a literal and good) prompt and how well did you explain each of the columns to the model.

Re: Replacing a SQL analyst with 26 recursive GPT prompts

#80
post #71
post #52

> this is shockingly close to replacing an entire role at companies with only a couple hours of effort. and > It seems like there’s almost no limit to how good GPT could get at this. I don't see how that's a valid conclusion given the results. 2 simple things right, moderate to difficult things wrong? Hardly a ringing endorsement.

Glad i'm not the only one who saw this. Feels extremely overblown. Very impressive, don't get me wrong, and is yet another bridge closer to letting business side do plain text queries. But that said, stuff like this has existed for awhile, and it's certainly not replacing analysts. For a start, this assumes a VERY clean model, which is of course what you strive for, but the moment you step out of FAANG you'll find th…

>the moment you step out of FAANG

Even in FAANG, most data is going to be extremely messy.

* There's usually very little incentive for good documentation, so you have to guess what the table contains based on column names and exploring patterns in the data.

* Enforcing a single pattern/process for data across the entire org is a pipe dream.

* Logging tables are written to by hundreds of engineers across dozens of teams, with no standardized naming scheme.

* The product contains multiple edge cases/special overrides for very specific circumstances, so there's very few simple queries that don't come with 100 footnotes attached.

FAANG is not immune to large-organization problems, and data quality is no exception.

Post reply on HN