2 ms·

That’s cool that this is your field! It could just be the optimism in the article that’s getting to me here. I just feel like natural language as an interface h

That’s cool that this is your field! It could just be the optimism in the article that’s getting to me here. I just feel like natural language as an interface has a bit too much slop in the controls, even if the controls are easier. I’d like to imagine the non technical folks using something like the dashboard example in the article would be ok with some extra work formatting their query to ensure what they think they want, is precisely what they’re asking for. Adding a little layer in there that was mostly trained on things unrelated to your query, feels more like driving-by-wire. Doesn’t mean it doesn’t work but that precision is lost? I’m also: completely out of my field for talking on this. Thanks for the interesting insight into it!

qsort 4y ago
> I’d like to imagine the non technical folks using something like the dashboard example in the article would be ok with some extra work formatting their query to ensure what they think they want, is precisely what they’re asking for. The UX in this area is very much work in progress, but from what I have seen I agree that users likely prefer to be sure that the query is correct. What I would try to do -- and let's be clear, this is just a random opinion and my guess is as good as anybody's -- is to answer with two results, "this is my interpretation of what you asked" and "this is the answer according to the interpretation above". It's a bit too technical for the average user, but Wolfram Alpha nails it in my opinion, and I'm convinced that with some refinement it could be usable for business folk. Example of what I mean: https://www.wolframalpha.com/input?i=population+of+india+%2F+population+of+china https://www.wolframalpha.com/input?i=population+of+india+%2F... This is consistent with the state of the art in NL to SQL literature (example: https://arxiv.org/pdf/1905.08205.pdf https://arxiv.org/pdf/1905.08205.pdf), which tends to put an intermediate representation between pure English and pure SQL. It is especially useful for production systems because it gives additional control to the backend in addition to its benefits for the pure NLP task.

qsort 4y ago

> I’d like to imagine the non technical folks using something like the dashboard example in the article would be ok with some extra work formatting their query to ensure what they think they want, is precisely what they’re asking for. The UX in this area is very much work in progress, but from what I have seen I agree that users likely prefer to be sure that the query is correct. What I would try to do -- and let's be clear, this is just a random opinion and my guess is as good as anybody's -- is to answer with two results, "this is my interpretation of what you asked" and "this is the answer according to the interpretation above". It's a bit too technical for the average user, but Wolfram Alpha nails it in my opinion, and I'm convinced that with some refinement it could be usable for business folk. Example of what I mean: https://www.wolframalpha.com/input?i=population+of+india+%2F+population+of+china https://www.wolframalpha.com/input?i=population+of+india+%2F... This is consistent with the state of the art in NL to SQL literature (example: https://arxiv.org/pdf/1905.08205.pdf https://arxiv.org/pdf/1905.08205.pdf), which tends to put an intermediate representation between pure English and pure SQL. It is especially useful for production systems because it gives additional control to the backend in addition to its benefits for the pure NLP task.