91–100 of 147 posts
Is retraining being done automatically after each PR that modifies the DB? Is there a way to inject the DB structure in the context?
Earlier quoted context omitted.
There's the old adage of "trust, but verify" with LLM's I'm feeling it more like "Acknowledge, but verify, and verify again". It has certainly pointed me in the right direction faster vs google "here's some SEO stuff to sort through" :)
I agree with you. The larger point with text to SQL, however, is that it will not work if it is a simple wrap of an LLM (GPT or otherwise). Text to SQL will only work if there is a sufficient understanding of the business context required. To do this is hard, but with tools such as Dataherald a dev's life gets a whole lot easier.
Kudos for open sourcing. I think it's really difficult to build a business around that, but there are some successful examples in the space: metabase, airbyte, dbt, (maybe databricks?)
(1) https://github.com/Snowboard-Software/awesome-ai-analytics
This looks really cool, can't wait to check it out. The problem I've seen with other tools I've tinkered with is that they do well with simple stuff like: "what are my latest orders" -> select * from orders where user_id=x order by created_date But really struggle when you have a complex schema that requires joins, and basically has no support when you are describing something that needs outer joins or the like. Woul…
great question, and the one that we get the most :-) this is precisely why we created Dataherald. Off the shelf LLMs can handle a single table and simple questions. Dataherald's quest is to ultimately provide enterprise-grade text to SQL, where complex schema and joins are present. it does take some training, but we've found that it can handle situations such as the one you mention above.
Basically all the enterprises with a lot of data need to "chat with their data" right now.
I can't imagine how many teams are doing similar stuff right now.
https://github.com/ryanstout/question_to_sql
These sorts of businesses are really hard to build: incumbents have such an advantage. Makes so much more sense for this to be (a) open source (b) tied to snowflake / powerbi that have free distribution and a good security story.
Earlier quoted context omitted.
The entirety of the codebase is now open source.
It’s sometimes hard to understand how you keep a business running when you’ve open-sourced your entire stack, both consumers self-hosting but even worse would be a competitor just taking what you spend R&D budget on & rehosting it with a cheaper price since they don’t need to pay for that R&D. From a business perspective, do you see the operational challenge of running your stack at scale as the differentiator?
I think it solves the problem of gaining traction today, at the expense of future market power. Then they face a choice of pulling a HashiCorp or being OK with being a commodity provider rather than a fancy unicorn.
I can see the appeal, a humble business is better than no business, isn't it?
Earlier quoted context omitted.
This is often the move when the team's spent the money developing something and now the end's in sight, so they want the chance to leave and take the code with them. Don't know if this is that at all, but it's always worth considering.
I don't understand the "leave the code with them" part
I'm aware I'm leaving out a lot of detail, but it's not clear to me what has become public knowledge and what has not and I happen to know some people that were involved.
Earlier quoted context omitted.
I agree with you. The larger point with text to SQL, however, is that it will not work if it is a simple wrap of an LLM (GPT or otherwise). Text to SQL will only work if there is a sufficient understanding of the business context required. To do this is hard, but with tools such as Dataherald a dev's life gets a whole lot easier.
what is your affiliation with Dataherald
Earlier quoted context omitted.
you wouldnt believe the amount of developers that don't know how to write sql
Because ORM libraries were invented 30 years ago. There is no requirement to learn SQL for most of the applications built today.
Of course there's a lot of incompetent people who have no idea what they're doing, if it seems to work they ship it. That leads to a lot of nonsensical bullshit and unnecessarily slow systems.