A LLM+OLAP Solution
doris.apache.org
A LLM+OLAP Solution
1–10 of 28 posts
Re: A LLM+OLAP Solution
#2The main idea of this solution is to make up with the shortage of niche knowledge of Large Language Models.
Re: A LLM+OLAP Solution
#3From making a few variations on data chatbots in the past year, I found that my favorite / most fun to use ones seem to be more "chain-of-thought" and conversational rather than "retrieval-augmented" style.
Less about one-shotting the answer, and more about showing its work, if it errors, letting it self-correct. Latency goes up, but quality of the entire conversation also goes up, and feels like it builds more trust with the user. Key steps are asking it to "check its work", and watching it work through new code etc. (I open-sourced one version of this: https://github.com/approximatelabs/datadm that can be run entirely locally / privately)
From their article: I'm surprised they got something working well by going through an intermediate DSL -- thats moving even further away from the source-material that the LLMs are trained on, so it's an entirely new thing to either teach or assume is part of the in-context learning.
All that said, interesting: I'll definitely have to try out tencentmusic/supersonic and see how it feels myself.
Re: A LLM+OLAP Solution
#4Which semantic layer they are using?
Re: A LLM+OLAP Solution
#5Has anyone attempted to use Doris or evaluated it against Clickhouse? I have to admit Inever heard about it before, is it used beyond Tencent-owned companies ?
Re: A LLM+OLAP Solution
#6For 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 semantic layer, and what the accuracy rate of what the user intended vs what they got.
I do think the only way a LLM based analytics tool can succeed is via a semantic layer rather than direct SQL, since database schemas fail to encode a lot of information about the data (EG a warehouse might not even know user.customer_id = customer.id).
Malloy could be an interesting target here.
Re: A LLM+OLAP Solution
#7For 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…
Eh, many of them have some way to provide markup even when its informational only, because a data catalog or dictionary is required to use most large olap products.
eg Snowflake lets you declare all the foreign keys you want, but does nothing with that info except let you use it.
Re: A LLM+OLAP Solution
#8For 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…
Eh, many of them have some way to provide markup even when its informational only, because a data catalog or dictionary is required to use most large olap products. eg Snowflake lets you declare all the foreign keys you want, but does nothing with that info except let you use it.
Sure, some OLAP databases let you add the same metadata that a OLTP database gives you as constraints, especially enterprise ones. A lot still don't, like Clickhouse, afaik.
No OLAP database I know of would let you encode other semantic layer things like aggregations or metrics. EG defining a DAU/MAU metric as "The distinct number of users logged in that day vs the distinct number of users in the 28 days before that day."
Those types of definitions usually live in the semantic layer or bi layer, which a LLM analysis tool would need to solve for.
Re: A LLM+OLAP Solution
#9For 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…
It looks like https://github.com/tencentmusic/supersonic is a component. I'm trying to figure out what they are doing too.
Re: A LLM+OLAP Solution
#10I 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?