3 ms·

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 ab

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'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.

fhd2 3y ago
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 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!
- mcqueenjordan 3y ago
  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.
  - fhd2 3y ago
    I think a tool that allows you to see the generated SQL and maybe edit it should help achieve what I wrote about! And looking at the code, it shouldn't even be a big change in this one. Sure, some people might not bother/think, there's no helping that. But it'd help those who do. I found non-technical people pretty curious and willing to learn once they get over this imagined barrier of "it's too hard". 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.
    - saigal 3y ago
      I agree that allowing a user, particularly a non-technical one, to see the auto-generated SQL (i.e. the SQL created from natural language) might actually encourage understanding of the data. It can create an easier on-ramp for non-tech folks to understand data and get deeper into it.
- aazo11 3y ago
  Hi -- the /question endpoint does return the generated SQL under the sql_query field of the JSON response: https://dataherald.readthedocs.io/en/latest/api.question.html https://dataherald.readthedocs.io/en/latest/api.question.htm... You can even see the entire chain of LLM calls in the intermediate_steps field to help debug the agent.
saigal 3y ago
At the risk of generalizing too much, there's always a chance that layering on a new technology can limit a user's understanding by creating an additional degree of separation. More specifically though, if a PM has been using a BI tool (tableau, looker, etc) or Product Analytics tool (e.g. amplitude, mixpanel) and clicking through dashboards without ability to find their answer, then I don't think this makes them lose additional expertise in the data model. And perhaps even more importantly, my experience has been that people ultimately wish to understand trends. In other words, an ad-hoc question that is posed and answered in natural language might ultimately be made into a dashboard that lives on the BI tool (so that trends become clearer).

fhd2 3y ago

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 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!

mcqueenjordan 3y ago
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.
- fhd2 3y ago
  I think a tool that allows you to see the generated SQL and maybe edit it should help achieve what I wrote about! And looking at the code, it shouldn't even be a big change in this one. Sure, some people might not bother/think, there's no helping that. But it'd help those who do. I found non-technical people pretty curious and willing to learn once they get over this imagined barrier of "it's too hard". 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.
  - saigal 3y ago
    I agree that allowing a user, particularly a non-technical one, to see the auto-generated SQL (i.e. the SQL created from natural language) might actually encourage understanding of the data. It can create an easier on-ramp for non-tech folks to understand data and get deeper into it.
aazo11 3y ago
Hi -- the /question endpoint does return the generated SQL under the sql_query field of the JSON response: https://dataherald.readthedocs.io/en/latest/api.question.html https://dataherald.readthedocs.io/en/latest/api.question.htm... You can even see the entire chain of LLM calls in the intermediate_steps field to help debug the agent.

saigal 3y ago

At the risk of generalizing too much, there's always a chance that layering on a new technology can limit a user's understanding by creating an additional degree of separation. More specifically though, if a PM has been using a BI tool (tableau, looker, etc) or Product Analytics tool (e.g. amplitude, mixpanel) and clicking through dashboards without ability to find their answer, then I don't think this makes them lose additional expertise in the data model. And perhaps even more importantly, my experience has been that people ultimately wish to understand trends. In other words, an ad-hoc question that is posed and answered in natural language might ultimately be made into a dashboard that lives on the BI tool (so that trends become clearer).