31–40 of 108 posts
How is this approach different from Nalir? https://dl.acm.org/doi/10.1145/2588555.2594519
2014, so it (and previous similar projects) are not going to be able to compete with contemporary LLMs.
How is this approach different from Nalir? https://dl.acm.org/doi/10.1145/2588555.2594519
In this demonstration, we show that NaLIR, while far from being able to pass the Turing test 2014, so it (and previous similar projects) are not going to be able to compete with contemporary LLMs.
Like instead of shoehorning LLMs into old paradigms, why not conceive data storage systems inherently designed for LLM interfacing?
There's a latent inefficiency in using SQL as a bridge. It feels like trying to fit a new narrative into an old framework
And yes, rethinking database architectures from the ground up is daunting and demands more background in storage systems but given where machine learning and data interaction are heading, maybe we should consider it.
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 never explicitly documented and so are invisible to an LLM.
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…
This only works if you have perfect data engineering. But if you have perfect data engineering, point and click tools like Looker will work too.
Not to dismiss the effort here, but wondering if this should go even further than bridging natural language to SQL. With recent work on LLMs showing promising capabilities in handling complex data structures, maybe the real play is to cut out the SQL altogether. Direct interaction with LLM-optimized data stores could yield more efficient, flexible, and fine-tuned results, eliminating the translational losses that mig…
Not to dismiss the effort here, but wondering if this should go even further than bridging natural language to SQL. With recent work on LLMs showing promising capabilities in handling complex data structures, maybe the real play is to cut out the SQL altogether. Direct interaction with LLM-optimized data stores could yield more efficient, flexible, and fine-tuned results, eliminating the translational losses that mig…
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…
A less sarcastic take: This only works if you have perfect data engineering. But if you have perfect data engineering, point and click tools like Looker will work too.
Not to dismiss the effort here, but wondering if this should go even further than bridging natural language to SQL. With recent work on LLMs showing promising capabilities in handling complex data structures, maybe the real play is to cut out the SQL altogether. Direct interaction with LLM-optimized data stores could yield more efficient, flexible, and fine-tuned results, eliminating the translational losses that mig…
SQL is definitely an old technology. However it is still the main language for interfacing with structured data, even for newer tools like Clickhouse. Down the road it is conceivable that it will be replaced with something else, but the cost of migrating existing data to those will be so high I imagine no-one will take the step to proactively move.
Surely it makes sense for a MVP, but I'm curious about how much we're potentially forfeiting in terms of innovation by anchoring so deeply to it with all the possibilities afforded by generative AI. In holding onto SQL, might we be forestalling the development or adoption of a more evolved language? With Dataherald's proposition, how do you envision maintaining that cutting edge, ensuring you're not just prolonging the lifespan of a fading tech, but genuinely pushing the envelope forward?
I suppose one intriguing possibility in my mind is that Dataherald could serve as a bridge or runtime. As you continue to develop and refine the tool, do you see a future where it might support more abstract querying languages or even emerging data interaction paradigms? This could potentially mitigate some transition pains when the tech ecosystem eventually shifts.