We (https://www.definite.app/) were also working on AI for SQL generation. I can see why you pivoted, it doesn't really work! Or at least well enough to displace existing BI solutions.
edit: context below is mostly irrelevant to snowflake cost optimization, but relevant if you're interested in the AI for SQL idea...
I'm pretty hard headed though, so we kept going with it and the solution we've found is to run the entire data stack for our customers. We do ETL, spin up a warehouse (duckdb), a semantic layer (cube.dev) and BI (dashboards / reports).
Since we run the ETL, we know exactly what all the data means (e.g. we know what each column coming from Stripe really means). All this metadata flows into our semantic layer.
LLM's aren't great at writing SQL, but they're really good at writing semantic layer queries. This is for a couple reasons:
1. better defined problem space (you're not feeding the LLM irrelevant context from a sea of tables)
2. the query format is JSON, so we can better control the LLM's output
3. the context is richer (e.g. instead of table and column names, we can provide rich, structured metadata)
This also solves the Snowflake cost issue from a different angle... we don't use it. DuckDB has the performance of Snowflake for a fraction of the cost. It may not scale as well, but 99% of companies don't need the sort of scale Snowflake pitches.
One of the things I added is something called "Assistant Profiles". Given the fact that you know the DB structure, you can create a custom Assistant Profile and adjust it to fit the underlying DB better, which improves the results quite a lot
You can then expand the connection to other external systems and automate a lot of the analysis processes your users may have
I'm happy to work with you to make it work for your use case
edit: context below is mostly irrelevant to snowflake cost optimization, but relevant if you're interested in the AI for SQL idea...
I'm pretty hard headed though, so we kept going with it and the solution we've found is to run the entire data stack for our customers. We do ETL, spin up a warehouse (duckdb), a semantic layer (cube.dev) and BI (dashboards / reports).
Since we run the ETL, we know exactly what all the data means (e.g. we know what each column coming from Stripe really means). All this metadata flows into our semantic layer.
LLM's aren't great at writing SQL, but they're really good at writing semantic layer queries. This is for a couple reasons:
1. better defined problem space (you're not feeding the LLM irrelevant context from a sea of tables)
2. the query format is JSON, so we can better control the LLM's output
3. the context is richer (e.g. instead of table and column names, we can provide rich, structured metadata)
This also solves the Snowflake cost issue from a different angle... we don't use it. DuckDB has the performance of Snowflake for a fraction of the cost. It may not scale as well, but 99% of companies don't need the sort of scale Snowflake pitches.