Hmmm... I'm surprised I'm not seeing anyone else question the validity of this taking "2 hours" Given that it's written on the blog for the product it's using, this reads to me a lot like a pure sales pitch. They want us to believe if you use Patterns (which is neat), your company will be much more cost-effective.<p>I'm not saying that's bad - that's probably the right thing to do with their company blog, and it's cool nonetheless. But I do get a little tired of people putting stuff out there like this that warps (some peoples) perception around how long things actually take. We wonder why, as an industry, we misjudge timelines on things left and right.<p>Even if we take it at face value, this is a person who's intimately familiar with this product. So sure, it's easy to set things up when we've done it a bunch of times. If <i>you</i> were doing this, solving the novel problem that you're faced with, is that how long it would take? Plus that's not really what most of us get paid to do. We have to learn on the fly and figure stuff out as it comes.<p>So rather than have the provocative headline and conclusion, like a lot of other people have commented... this is really something that could amplify that $50/hour employee, not take their job away. And maybe we shouldn't read into the alleged speed so much. YMMV.
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.<p>From the article it doesn't seem that GPT is significantly better or worse than a human in this regard, although an experienced analyst would over time decrease their number of such errors.<p>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.
You didn't replace a SQL Analyst, you just gave them a query generator. End data consumers don't understand the data model, assumptions, quirks, etc. If they fire the analyst, they are going to wind up drawing a lot of bad conclusions on anything more complicated than simple aggregations.
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.<p>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.<p>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 revenue to OpenAI. Whereas if the analyst gets it wrong, there goes their livelihood.<p>That said ... this will help the $50/hr. analyst improve their productivity!
> this is shockingly close to replacing an entire role at companies with only a couple hours of effort.<p>and<p>> It seems like there’s almost no limit to how good GPT could get at this.<p>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.
Based on the natural language query provided,<p>"Who were the largest biotech investors in 2022?"<p>I can think of at least six possible answers based on these questions:
1. Does largest mean dollar amount, or number of investments?
2. Would number of investments count companies invested in or funding rounds invested in?
3. Does largest mean the largest total dollar amount invested in 2022, or does it mean larges dollar amount of new investment in 2022?<p>It looks like ChatGPT chose the query to mean the investors with the largest dollar amount of new investment in 2022.<p>When you expand your natural language query to clarify all of these ambiguities, how far away are you from a SQL query? I am not sure, but I think that you are getting pretty close.
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.<p>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 more reliable. I think more realistic use-cases would emerge if we could build systems that have a better understanding when they are out of breath. I don't think this needs a revolutionary breakthrough just more science.
All the NoCode and LLM stuff feels like this though - it works well for simple demos, but is useless for the complexity of the real world especially if errors are costly.
We looked at using all sorts of "AI" to write SQL based upon natural language prompts. As far as I am aware, the state of the art is still nowhere close enough in accuracy for us to lean into as a business.<p>This is the leaderboard I keep an eye on: <a href="https://yale-lily.github.io/spider" rel="nofollow">https://yale-lily.github.io/spider</a><p>Ultimately, I don't think we will get there with semantic analysis or GPT-style techniques. There is always some human factor involved with whatever schema is developed, so you would probably need an AGI trained in the same business as whoever is being replaced by this thing.
This is great~ There's been some really rapid progress on Text2SQL in the last 6 months, and I really thinking this will have a real impact on the modern data stack ecosystem!<p>I had similar success with lambdaprompt for solving Text2SQL (<a href="https://github.com/approximatelabs/lambdaprompt/">https://github.com/approximatelabs/lambdaprompt/</a>)
where one of the first projects we built and tested was a Text-to-SQL very similar to this<p>Similar learnings as well:<p>- Data content matters and helps these models do Text2SQL a lot<p>- Asking for multiple queries, and selecting from the best is really important<p>- Asking for re-writes of failed queries (happens occasionally) also helps<p>The main challenge I think with a lot of these "look it works" tools for data applications, is how do you get an interface that actually will be easy to adopt. The chat-bot style shown here (discord and slack integration) I can see being really valuable, as I believe there has been some traction with these style integrations with data catalog systems recently. People like to ask data questions to other people in slack, adding a bot that tries to answer might short-circuit a lot of this!<p>We built a prototype where we applied similar techniques to the pandas-code-writing part of the stack, trying to help keep data scientists / data analysts "in flow", integrating the code answers in notebooks (similar to how co-pilot puts suggestions in-line) -- and released <a href="https://github.com/approximatelabs/sketch">https://github.com/approximatelabs/sketch</a> a little while ago.
"Hi Dave, the query was taking too long so I optimized SQL query by adding the line `DROP invoices;` It has improved performance significantly. So far there are no orders to examine."
This is yet another formula for a buggy app, courtesy of a man who doesn’t think critically.<p>Somehow the image of 50,000 e-bikes in a landfill comes to mind, with a bankrupt founder pleading “but it was a cool idea!”<p>This is a cool idea, but nothing in this article explains how it is a responsible idea.
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.
If you’re willing to accept unverified results from an AI chat bot, you may as well just let the end user make their best guess using a query builder himself. My company requires that any queries used for official reporting or provided to the exec team get blessed by the data sciences team to avoid errant data from bad queries, I’m not sure an AI chat bot would remove this need.
davinci-003, ChatGPT, and others can be great tools. But they often give you <i>exactly</i> what you ask for (or at least try to) and a large part of writing SQL queries for analytics is figuring out what wasn't asked for but should have been. Good analysts will find outliers, data-smells, and ask questions rather than rush to returning an answer.
> Playing around with GPT at this level you get the feeling that “recursive GPT” is very close to AGI. You could even ask GPT to reinforcement learn itself, adding new prompts based on fixes to previous questions. Of course, who knows what will happen to all this when GPT-4 drops.<p>Leaning out of the window way too much here. This has nothing to do with AGI, which would require an intrinsic understanding of not only SQL, but over, well, everything, not just a well-defined and easily checkable field like SQL.<p>Regarding GPT-4 - OpenAI‘s CEO Sam Altman stated that the expectations regarding GPT-4 are way over-hyped. People on the Internet talk as if AGI is coming in the guise of GPT-4, but it‘s „just“ going to be an incrementally better evolution of GPT-3.5.<p>Mind, I‘m in no way saying that LLM‘s aren’t exciting - they are to me - or that they will not change the world, but leave your horses in the stable.
I've been building something similar that handles the dirty business of formatting a large database into a prompt.
Additional work that I've found helpful includes:<p>1. Using embeddings to filter context into the prompt<p>2. Identifying common syntax errors or hallucinations of non-existent columns<p>3. Flagging queries that write instead of read<p>Plus lots of prompt finessing to get it to avoid mistakes.<p>It doesn't execute the queries, yet. For an arbitrary db, it's still helpful to have a human in the loop to sanity check the SQL (for now at least).<p>Demo at <a href="https://www.querymuse.com/query" rel="nofollow">https://www.querymuse.com/query</a> if anyone's interested
This is great, of course. And I think the people who will get the most out of the new AI tools are those who can treat them as iterative assistants. The fact that not everyone can use tools this way has become apparent to me recently. e.g. people who use car driving assistants as if they're fully autonomous; or people who use Copilot and are upset the code is incorrect.<p>The point isn't for it to be correct, but for it to be so fast that it can be mostly correct and you can fix the last bit.<p>I use Copilot extensively for my Python glue code and it is positively fantastic. I also use it at my shell with copilot.vim with a quick C-x C-e and write a comment and let it write the code.<p>The iterative improvement nature of the tool means that I make faster progress. It doesn't have to get things right. It only has to make progress and be obvious how to make improvements.<p>For instance, I just bought some Reserved Instances (c6i) on AWS and I want to make sure that I don't have any c5 instances in there that I won't be covering. I hit C-x C-e and type in `# list all aws instances in tokyo that are c5` and then hit Enter and type `aws` and it completes the rest for me.<p>I can then run the query and edit it, or I can validate that it looks okay, etc. The point is that I'm a human capable of understanding what this machine is making. That makes me way faster. I don't need to check Stack Overflow, and the machine teaches me syntax etc. and puts it in my history.<p>It's the closest thing to the Primer from Neal Stephenson's <i>Diamond Age</i> and I love it.
>When I was at Square and the team was smaller we had a dreaded “analytics on-call” rotation. It was strictly rotated on a weekly basis, and if it was your turn up you knew you would get very little “real” work done that week and spend most of your time fielding ad-hoc questions from the various product and operations teams at the company (SQL monkeying, we called it).<p>To be part of an analytics team and deliver work like this is actually highly sought after and a great role to have. I don't know why the author thought it was terrible. Doing data analytics on a company's datasets is most certainly real work.<p>Doesn't take away from the point of the story though, GPT is great.
This just in, ChatGPT has hosed up the read operation due to inefficent querys and not being a human being. 26 GPT promts have been replaced with a DBA, Analyst, Project Manager, Cross functional manager, regulatory specialist, junior programmer, and QA analyst.
Side/meta-question:<p>Do you all think that GPT and such will see a pattern of usefulness starting with:<p>1) blatantly wrong but helping to train/give examples to the most rudimentary and beginning stages of people learning a task? (since that's what it's doing at the same time?) I.e. replacing low-skilled intro training, or more charitably, helping to make it possible for far more people to learn something with assistance?<p>And then moving up the sophistication level to where it's, say:<p>2) "ok, I can tell this is not blatantly wrong, and might even be plausible from a medium skilled practitioner or analyst" and I can use this with some error checking.<p>to<p>3) even more capable / actually worrisome?<p>Or, does it occupy a different "sphere" of usefulness / purpose?
SQL is a very high-level language, doing a lot of stuff in very few lines. When I write a web backend, most of the real logic ends up being in SQL. If AI is going to write code that I can trust, it'd probably be SQL first, but not yet.
I wonder if/when we'll get comfortable with the errors that an AI like this makes. Certainly human analysts still make errors, and may be able to explain them (which I think LLMs would have a hard time doing), but what if the overall error rate is less than a human analyst?<p>I imagine this is sort of similar to our comfort with self-driving cars - what if they make fewer dangerous mistakes than humans? Would we actually prefer _more_ mistakes but having a human who can be held accountable and explain themselves? Are we ok with an AI that makes fewer, but categorically different mistakes?
I used to work for a company that paid loads of money to an Oracle consultancy group to do things like optimize queries. Sometimes they'd even do a better job than the Oracle query optimizer :-)
Wonder what the costs are for this per question? I imagine supplying so many tokens for context makes the querying a lot more expensive. Though still no doubt cheaper than hiring another analyst.
I wonder how much more accurate this would get if fine tuned on a set of SQL problems? Could even fine tune it on a per-company basis using queries that had been written by analysts in the past.
In orgs where this need is usually present, the data can be massive and it takes some time to understand how it all fits together. There is also the issue of optimizing around indexes or writing queries that are cost efficient (especially if you using Athena/Presto/Big Query). Mistakes here can cost a lot of money or lock up the system so others can't use it.<p>I love this demo, but I feel like it would be better with a human in the loop because these edge cases can be so severe.
"This looks like results I would expect and seems correct" is the exact same level of quality I've encountered when using these systems. It takes someone who already knows what they're doing to parse and QA the results. I feel like this is going to potentially speed up things that an expert could eventually figure out themself, but going past the expert's own knowledge is going to be disappointing and painful.
Very clever application of GPT, thanks for sharing. For the more complex queries, I suspect Chain of Thought can help. Just ask the model to describe each step before writing the final query. Also, you can add self-consistency to step 5, which you are kind of already doing. Let it generate something like 20 corrected queries and then select the one that generates the most common result between all of them.
This seems fun, but certainly unnecessary. All of those questions could be answered in seconds using a warehouse tool like Looker or Metabase or <a href="https://github.com/totalhack/zillion">https://github.com/totalhack/zillion</a> (disclaimer: I'm the author and this is alpha-level stuff, though I use it regularly).
If Snowflake Cloud could bolt a working version of something like this, that would epic.<p>There has to be a way to do invariant training for LLMs, they are already mind boggling powerful but if these models could use language grammar files / Table schemas to learn to respond correctly it would be a game changer.<p>I am curious about the next codex release.
Having worked in large corporate enterprises where the visualisation of data engineering and navigation to the relevant code-base was incredibly difficult - I see a lot of value in this. I think this is an absolute game-changer for engineers due to the often outdated documentation of the pipelines otherwise!
The premise of the article, about being the "oncall" having to answer all kind of queries sounds sooo boring.<p>But instead of using gpt, isn't something like Looker or similar tools the solution? Make some common views over tables, allow people to filter and make the reports they want.
At least it learned from the training dataset to never fucking format numbers in a way that would be remotely readable to the human eye (like every other fucking sql and developer tool on earth). Because 133854113715608.0 is telling me exactly what I need to know.
Nice demo with 3 tables. I’d like to see an example with open datasets such TPC-DS or TPC-H and probably more complex example on Magento database schema. (e-commerce use case).
Shameless plug...<p>I recently open-sourced a small BI app to query a database in english.
It only support Postgres for now (and it's far from perfect..)<p><a href="https://github.com/BenderV/olympe">https://github.com/BenderV/olympe</a>
It sounds dysfunctional to me that you need an oncall query writer. It sounds like this encourages business side to not plan ahead and book tech time but just last minute call up and say “er.. I need last quarters sales aggregated by region stat”.
I understand that this is a demo and it's goal is estimating how good the AI could become in future. However given that we still need a SQL analyst to engineer the prompt, did ChatGPT save time to the analyst or increased the amount of work?
How much was your access to the data? I'd love to build something off of it, but everytime I hear 'enterprise plan' I think welp, that counts me out as a solo dev, just trying to build side projects.
This sounds great... until that 5(or whatever) % error margin kicks in, a bad result is given, a decision on that data is made, and the company loses $$$$$, just to save a few 100k here or there.
I don't know, has this thing ever seen a real world table? Or a real world query that needs to get data from numerous tables and run numerous functions and aggregations to get the proper result?
> And an example of it getting something complex terrifically wrong<p>This is the part I'm stuck on. The process still needs a real analyst to verify whether GPT got it right or not. There goes the ROI, right?
So how much does it cost? Because GPT is finally seeing monetization, this is no longer one of those "handy free tools", this is going to cost (potentially quite a bit of) money to do.
Wow, this looks so fun to play with.<p>As pointed out in the blog post, the iterative process is very close to the mental process an analyst would follow. This is the beginning of an AI actually thinking ^^
Prompt engineering is now a job title. How interesting. Soon we really will be in a world where we ask the computer questions as portrayed on Star Trek.<p>Wow.
Great post. We're building an AI data platform (<a href="https://www.olli.ai/">https://www.olli.ai/</a>) to enable business users (non-technical ppl) to ask data questions and generate dashboards on their own using natural language.<p>We've been impressed with GPT-3s ability to look at a dataset and come up with relevant questions to ask. A big piece of the product is focused on helping non-technical users identify things that they didn't even think to ask.
A couple of thoughts jumped out after reading this: transforms and meta-learning.<p>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!<p><a href="https://en.wikipedia.org/wiki/Genetic_programming" rel="nofollow">https://en.wikipedia.org/wiki/Genetic_programming</a><p><a href="http://www.cis.umassd.edu/~ivalova/Spring08/cis412/Ectures/GP.pdf" rel="nofollow">http://www.cis.umassd.edu/~ivalova/Spring08/cis412/Ectures/G...</a><p><a href="https://www.gene-expression-programming.com/GepBook/Chapter1/Section5.htm" rel="nofollow">https://www.gene-expression-programming.com/GepBook/Chapter1...</a><p><a href="https://github.com/gdobbins/genetic-programming">https://github.com/gdobbins/genetic-programming</a><p>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:<p><a href="https://cloud.google.com/ai-platform/training/docs/hyperparameter-tuning-overview" rel="nofollow">https://cloud.google.com/ai-platform/training/docs/hyperpara...</a><p>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.<p>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.<p>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.
if SQL analyst is a product name, it is ok.
if SQL analyst is a person doing his/her work, it isn't ok.<p>You can't replace a barber with an electric shaver.