One use case that tends to pop up frequently is “text-to-database”. Similar to text-to-SQL, but with my API I could target any DB regardless of query language. This would require a large amount of work, and I’m not convinced that it’s something that users even want. The strongest feedback I’ve received has been that it would be a convenient method for managers and non-technical to query analytics databases.
Is this a path worth exploring? Are there industries or positions that would kill to be able to query a db with a plain english sentence? Is this something that you would use, or want to implement?
But maybe you're asking the wrong question in your headline. If you could have other people in your organization able to talk to a database in plain English, would you?
This isn't something that most of the HN crowd would want for their own work. There might be a lot of people here who have, say, that upper-level manager who keeps asking for reports for which the HN person has to figure out how to get the data. Handing that manager a tool like this, and letting them run their own queries could get them out of our hair. (It could also be better for the manager, as they run the query, look at the results, and figure out that it wasn't actually the data they were looking for, and so they can iterate the query to get what they're really after.)
One caveat, though: I wouldn't want to hand anyone - even a professional - write access with this kind of a tool.
> There might be a lot of people here who have, say, that upper-level manager who keeps asking for reports for which the HN person has to figure out how to get the data.
This is 100% the use case I was thinking.
> One caveat, though: I wouldn't want to hand anyone - even a professional - write access with this kind of a tool.
Agree! Not sure how this ever would be safe enough for edits.
Ultimately though, I think the usefulness of these tools breaks down for both complex queries and even simple ones when the data model does not have explicit relationships defined.
> Ultimately though, I think the usefulness of these tools breaks down for both complex queries and even simple ones when the data model does not have explicit relationships defined.
Makes sense. Do you think it would help if a developer could define the relationships in the data model ahead of time?
For various definitions of query, the work goes back to the 1950s https://developer.ibm.com/articles/a-beginners-guide-to-natu...
Trying to map english to formal logic is a fools errand.
From my experience, what keeps non-technical people from writing queries isn't SQL, it's stuff like joins.
Perfect description of a developer's job.
"WANTED: One Fool to serve the court at the pleasure of the CEO. Compensation is one crust of bread and a flagon of ale per day."
I don't disagree, but this would not be a 1-1 mapping, if that matters.
>From my experience, what keeps non-technical people from writing queries isn't SQL, it's stuff like joins.
I've met very few non-technical folks willing to brave learning any part of SQL. In my case joins would be an implementation detail, mostly handled by the product, but possibly with an escape hatch for technical folks.
At the end of the day, SQL is very expressive for most of these queries, but it's not particularly discoverable and does take some knowledge. Lowering that barrier to entry is a great idea, but otherwise I'm not sure if an analyst can be certain their query will give the same data as somebody who uses slightly different phrasing. SQL gives a lot more precision and I would hate to lose that due to a layer of abstraction.
But English -> SQL (with something like Github Copilot, built on other analysts' queries) would be very interesting although not "get out my wallet and purchase" compelling.
1. It is ML based, and the best results I have seen put it at about 90% accurate. This might be "good enough", but not perfect. Verification and error correction is needed.
2. Knowledge of the schema needs to be passed in as part of the feature, or have the model explicitly trained to the target schema.
3. Going to a different DB requires a retraining of the model, due to slight differences in SQL dialects.
4. ML takes either a lot of time (speed) or money (GPUs). This is more a general ML problem, but does affect English -> SQL.
I am no expert in English -> SQL, or in ML in general, so somebody correct me if I'm wrong on the above points. These are just what I've seen or experienced in my research.
I think this is definitely something that should be looked at, but it's not a product I'm really interested in unless it wows me with it's intelligence. It has to start somewhere, though. I'm probably an outlier in the sense that I think a lot of people would rather talk to their computer than type on a keyboard. I'm just not one of them. I also don't want to work in cubicle hell with everyone speaking to their computer 24/7.
I like your insight about using... let's call them "key phrases"...to help guide the query. Perhaps having a way to map a key phrase with a specific query, maybe one that is parameterized, would be useful. thank you.
Selling such a thing should not be a problem given the right target. Not only has the customer space for technologies like that changed over time, but you are providing a new twist on the solution.
> “Stripe/Twilio for NLU”, but recent feedback has been that it’s more a “technology”, and less a “product”
That comment doesn't make a ton of sense to me. Are services not valuable? Stripe and Twilio seem like really helpful services and that seems...OK to me?
Personally I get excited when I hear about an ease-of-use wrapper around regex. But for a DB, in place of that regular messy query stuff with the prospect of things like multiple LEFT JOINS? That's a big deal.
And even if it doesn't tick every box it will probably I'd guess it would have its unique applications for a given set of customers.
Like let's say sets of people who would like to prototype to well-enough using their ability to sit around and talk in English all day long, and then hand off to someone else. The average person's energy pool for trying different sentences, even considering some expected failure rate, is so much deeper than the resources available for trying and failing with different SQL statements.
This would also apply to those who are not really working with the data to work with it. Let's say they are selling data-viz tools and want a quick way to make prototypes from the potential customer's sample data. There, boom, product example. I guess.
It sounds really cool. Good luck, hope it works out for you.
Services are totally valuable! I think with Stripe and Twilio they both solve a problem a Business/PM/Owner has. The conversations go something like this in my head:
PM: I want to be able to send SMS messages to my customers.
Dev: Uh, I don't know anything about telecom...
Twilio: I do! I'm way cheaper than a dev working this problem. Just use me.
For NLU, I'm not sure I've been able to find PMs that are wanting to "understand the plain english of our users". But I know there is a decent amount of NLP usage. Do PM's just not know that they can ask for these NLP? Or do they just not need it? I'm not sure. I feel a little bit like I'm missing a piece of the puzzle.
> Personally I get excited when I hear about an ease-of-use wrapper around regex. But for a DB, in place of that regular messy query stuff with the prospect of things like multiple LEFT JOINS? That's a big deal.
A regex wrapper is an interesting idea. Maybe I'll try it out. I agree that a text to db wrapper could be a good idea, if it works really well.
> The average person's energy pool for trying different sentences, even considering some expected failure rate, is so much deeper than the resources available for trying and failing with different SQL statements.
Great point!
> It sounds really cool. Good luck, hope it works out for you.
Thank you, me too :)
Regardless of the details of the language, if I'm going to learn a structured language anyway, I would usually prefer to learn the underlying language, and not an imperfect abstraction. Sometimes, there's good value in the abstraction, but I usually find they get in the way and make it harder to do what I want.
This makes sense. Are there any specific examples of products that you have used that you had to do this?
> ...selecting lists with plural nouns and individual records with singular nouns...
Yes, this is for sure a failure case. I believe I have some means to work around this, fwiw.
> if I'm going to learn a structured language anyway, I would usually prefer to learn the underlying language, and not an imperfect abstraction.
I feel like I get what you are saying here, but some more concrete examples would help. Is there a "structured language" you are referring to?
Applescript is sold as a natural english like language, but it's really not. At least it's well documented.
Voice assistants are more like your product. Ask it a question, get something. But you have to ask them to do things in very particular ways or you don't get what you want. And there's usually zero documentation.
As an interface to SQL, your product is going to have to let me specify pretty specific relations, and that's going to take pretty specific words, IMHO. Think about how a user would ask for an inner join vs a left join vs a cross join.
Some ORMs have a pretty similar issue, where you learn an entirely different way to formulate queries, that ultimately get turned into SQL, but I'd rather work to understand SQL than to understand an abstraction over SQL (unless it gives a singificant benefit).
If I may, was there any particular phrases that you remember that were "too much"?
It would be great to talk more about your experience, if you are open. Just let me know and I can DM you.
