Odd choice to have such a small example and then redact most it. How am I supposed to know whether this is useful or not?
A LLM+OLAP Solution
11–20 of 28 posts
Re: A LLM+OLAP Solution
#12I would really like to see (and work for) a company that is building novel understanding of actual data and schemas with LLMs. Characterizing data and a limited number of transforms for an LLM should produce much more reliable tools than just piping direct text to a non enhanced LLM. Has anyone seen companies where they are doing this?
We are following this approach at Veezoo (https://www.veezoo.com).
When Veezoo connects to a database / dwh for the first time, an initial Semantic Layer / Knowledge Graph gets built automatically based on the data itself. We try to recognize how the columns link to other tables, try to identify units, and other semantic information e.g. if something is a "Location" or a "Country" and so on.
The whole conversational "plain english" querying then operates on top of the semantic layer, ensuring business logic (and other governance topics) are always respected.
Re: A LLM+OLAP Solution
#13For an article about LLM+OLAP, it doesn't spend much time on that part. Specifically it seems like their strategy is around using an LLM to generate a DSL query for an unnamed semantic layer, then everything downstream of that is normal warehousing, with the semantic layer handling actual SQL creation. I wish it spent time on talking about how they trained their LLM to reliably generate parsable queries for the seman…
Ibis could also be a target. It compiles queries written in python to multiple dataframe libraries, and SQL targets.
Re: A LLM+OLAP Solution
#14For an article about LLM+OLAP, it doesn't spend much time on that part. Specifically it seems like their strategy is around using an LLM to generate a DSL query for an unnamed semantic layer, then everything downstream of that is normal warehousing, with the semantic layer handling actual SQL creation. I wish it spent time on talking about how they trained their LLM to reliably generate parsable queries for the seman…
Agreed, that's exactly what we're doing with Definite[0]. We spin up Cube[1] for all our customers and the results vs. directly generating SQL are much better. Cube has some other really nice out of the box features too (e.g. caching).
Re: A LLM+OLAP Solution
#15I would really like to see (and work for) a company that is building novel understanding of actual data and schemas with LLMs. Characterizing data and a limited number of transforms for an LLM should produce much more reliable tools than just piping direct text to a non enhanced LLM. Has anyone seen companies where they are doing this?
That's what we're doing with Definite[0]. We spin up Cube[1] for all our customers and the results vs. directly generating SQL are much better. Cube has some other really nice out of the box features too (e.g. caching).
Re: A LLM+OLAP Solution
#16I would really like to see (and work for) a company that is building novel understanding of actual data and schemas with LLMs. Characterizing data and a limited number of transforms for an LLM should produce much more reliable tools than just piping direct text to a non enhanced LLM. Has anyone seen companies where they are doing this?
It will be difficult because of how organizations work. For example, finance and accounting people only care about shipped sales because that's when revenue is recognized whereas marketing and supply chain people think of demand sales (when order was placed). So you would need something to be able to interpret the difference depending on the audience or train the audience to be clear in their questioning.
Same goes for calendar vs. fiscal year for companies that have different fiscal and calendar begin dates. Something as simple as "2023 YTD" will mean different things depending on the audience within an organization.
Re: A LLM+OLAP Solution
#17For an article about LLM+OLAP, it doesn't spend much time on that part. Specifically it seems like their strategy is around using an LLM to generate a DSL query for an unnamed semantic layer, then everything downstream of that is normal warehousing, with the semantic layer handling actual SQL creation. I wish it spent time on talking about how they trained their LLM to reliably generate parsable queries for the seman…
Agreed, that's exactly what we're doing with Definite[0]. We spin up Cube[1] for all our customers and the results vs. directly generating SQL are much better. Cube has some other really nice out of the box features too (e.g. caching). 0 - https://www.definite.app/ 1 - https://cube.dev/
Is your SQL generation and cache layer open-source?
Re: A LLM+OLAP Solution
#18I would really like to see (and work for) a company that is building novel understanding of actual data and schemas with LLMs. Characterizing data and a limited number of transforms for an LLM should produce much more reliable tools than just piping direct text to a non enhanced LLM. Has anyone seen companies where they are doing this?
We're doing this at https://www.approximatelabs.com
Re: A LLM+OLAP Solution
#19For an article about LLM+OLAP, it doesn't spend much time on that part. Specifically it seems like their strategy is around using an LLM to generate a DSL query for an unnamed semantic layer, then everything downstream of that is normal warehousing, with the semantic layer handling actual SQL creation. I wish it spent time on talking about how they trained their LLM to reliably generate parsable queries for the seman…
Yeah, similar to what you and the other commenter from Definite said, we (Delphi)[0] find semantic layers way better for this kind of work than just going straight to a database/data warehouse.
One thing you really need with LLMs is consistency. Text-to-SQL kind of lets the LLM do whatever it wants - join tables that shouldn't be joined, define aggregates one way in one query and another way in the next.
Because semantic layers define how tables should join, measure definitions, etc., they mean people get consistent results from one query to the next, which builds trust in the LLM.
Cube (which was mentioned in another comment and has a great open-source semantic layer) has a good article about that here: https://cube.dev/blog/semantic-layer-the-backbone-of-ai-powe....
Re: A LLM+OLAP Solution
#20delphihq.com uses LLMs with Semantic layers like Cube/AtScale/dbt/Looker/Lightdash