71–80 of 108 posts
From the prompt context: DO NOT make any DML statements (INSERT, UPDATE, DELETE, DROP etc.) to the database. I've found that spelling out exactly what I don't want an LLM to do dramatically increases the probability that it will do exactly that.
When I look at all the LLM SQL tools, I think: what a cheap and accessible way to get the wrong answers. SQL is easy. Knowledge management is hard. Does the LLM know that there was a bug in June that changed the data? Does it know that this one column is improperly named and confusing? Does it know that you recently released a mobile app the data from which is in a different table? No, of course not, those things are…
There's just one thing I worry about. It's losing expertise in your data model and gaining organizational false confidence in bad data. Let's consider Bob. Bob is a Product Manager.
Bob always used to bother his software engineers to write SQL queries, but now he just uses this tool. Bob didn't write the tables or the data structures, so Bob doesn't know the nuances of the data model. Bob just types English and gets result sets back. Bob doesn't know that field order_status can also be in "pending_legal", and neither does the "sql compiler" know when it's appropriate to add or elide that field. Bob then presents his data to leadership to make changes to the Pending Order Logic, based on bad data.
Could you provide more details about your approach? Is the context store based in vector-embeddings?
I'd be delighted to assist you with your inquiries. Indeed, the context store interacts with vector databases to retrieve samples based on vector embeddings and cosine similarity.
I want to preface this comment so that I don't detract from the idea. This is a really cool product, and obviously has value. There's just one thing I worry about. It's losing expertise in your data model and gaining organizational false confidence in bad data. Let's consider Bob. Bob is a Product Manager. Bob always used to bother his software engineers to write SQL queries, but now he just uses this tool. Bob didn'…
Other than that, I'm sceptical for using LLMs for lots of things, but this I find cool. In my consulting work (and even before as a CTO), I usually train PMs, CEOs, really anyone who didn't make it up a tree by the count of 3 some basic code/tech literacy.
Imagine if Bob used this tool to learn about SQL and the data scheme. Now he got a glimpse of the inherent complexities, knows better when and how to ask for help, can have more trust in and better conversations with those engineers. Sounds naive probably, but I've usually seen these results from my (manual) efforts.
Of course that only works if the tool exposes the generated SQL in some fashion, it looks like it can but I might be wrong. If it's like you say and it's just natural language in, data out, I'd say that's more likely to do harm than good :)
Edit: Took a minute to look at the code, and it looks like there's no API to generate SQL from a question, just the "question" API that generates SQL on the fly and returns the data. I really think there'd be a lot of potential in at least returning the actual SQL query along with the data. Hope I didn´t miss something!
I want to preface this comment so that I don't detract from the idea. This is a really cool product, and obviously has value. There's just one thing I worry about. It's losing expertise in your data model and gaining organizational false confidence in bad data. Let's consider Bob. Bob is a Product Manager. Bob always used to bother his software engineers to write SQL queries, but now he just uses this tool. Bob didn'…
It's a risk for Bob, I think he should be the one judging whether it's worth it or not, since he'd probably get in trouble over this. What I take away from this is that it'd be helpful if the tool clearly warned him of this risk. Other than that, I'm sceptical for using LLMs for lots of things, but this I find cool. In my consulting work (and even before as a CTO), I usually train PMs, CEOs, really anyone who didn't…
Earlier quoted context omitted.
It's a risk for Bob, I think he should be the one judging whether it's worth it or not, since he'd probably get in trouble over this. What I take away from this is that it'd be helpful if the tool clearly warned him of this risk. Other than that, I'm sceptical for using LLMs for lots of things, but this I find cool. In my consulting work (and even before as a CTO), I usually train PMs, CEOs, really anyone who didn't…
Yes -- I think transparency on the limitations would be a useful step in mitigation. But I ultimately think that it will become a black box for most of those who use it, with a good deal of blind faith in the results. Sounds pessimistic, but grounded in reality, I think. That's not a deal breaker, though! Just a caveat about how much you can trust the output.
I fix small stuff around my house. Does that make me a builder, or threaten builder jobs? Don't think so. I know when to call one and I know to trust them based on understanding the nature and struggles of their work a little bit better.
When I look at all the LLM SQL tools, I think: what a cheap and accessible way to get the wrong answers. SQL is easy. Knowledge management is hard. Does the LLM know that there was a bug in June that changed the data? Does it know that this one column is improperly named and confusing? Does it know that you recently released a mobile app the data from which is in a different table? No, of course not, those things are…
If it was that easy you wouldn't have a tradition of devs trying for any alternative.
There's obviously a use case for this sort of product, objections appealing to the ease of use of any technical language or toolset are unlikely to be convincing to the majority who are not comfortable with it.
I was looking at the project to spin it up with a BigQuery connection, but I couldn't find an example in the docs (expected it on this page: https://dataherald.readthedocs.io/en/latest/api.database.htm...), nor can I find it in the repo. Any hints on this? Otherwise I'm fine going source code diving. :)