I’ve been writing about the [semantic layer](https://davidsj.substack.com/p/semantic-layers-a-buyers-guide) for some time now, and regularly at that! I’ve said before that AI + SL is a match made in data, and I really believe that semantic layer adoption is necessary for any organisation that wants to use AI with their data - whether this is to make AI experiences for their customers or to democratise data access internally.

This is the basis on which Michael and I founded [Delphi Labs](https://www.delphihq.com/). We could see many startups being founded to offer this democratisation by using LLMs to write SQL queries, but we believed that this method was very limited. After experimenting with a few we realised that this method really suffers from hallucination as soon as a data model is more than a handful of tables. Delphi was the first company founded to focus on using third party semantic layers, like Cube, as the governed interface for LLMs to use data.

Through experimentation with all of the main semantic layer offerings, Michael and I found Cube. We found the [Cube Semantic Layer](https://cube.dev/use-cases/semantic-layer) to be the very best to use with LLMs and for our AI application in Delphi. We also met some great Cube folks and formed a strong partnership with them, leading to our announcement today.

Michael and I are joining Cube full time. I will be joining as VP of AI and Michael will be working alongside me to help bring AI offerings into Cube. We will be leveraging our knowledge of both AI and data engineering to enhance Cube’s product even further.

We see huge potential in joining Cube and real affinity with our mission. If you ask any senior data stakeholder, CXO/VP/HoX, whether they want to simply ask a question and get an answer back in seconds or minutes rather than hours, days or weeks… they say yes please! Ask the same stakeholders what a semantic layer is and why they should invest in one, and they require a lot of education and persuasion of the benefits. When it’s simply the infrastructure needed for their AI data experience to work, to be safe and to be reliable - then it’s like explaining why a train needs rails.

This move will help a much larger audience access what we’ve built and learnt, more easily. They can get the benefits of the best semantic layer out there and AI in one place. Get in touch to learn more about LLM and AI built on top of Cube’s semantic layer.

Michael and I are both experts in deploying and using semantic layers in practice, having both used them since leading data teams in our practitioner careers. We are excited to help contribute to Cube’s semantic layer progression that isn’t related to AI too! Given what I’ve written about before in my blog, it’s clear to all that I’m a semantic layer fan!

There will be more specifics to come about integrations, what we’re building at Cube, timelines, etc. as we move forward. 


David Jayatillake 

All Things Cube

The Delphi Labs team joins Cube.

Investing in Cube’s AI-driven future. 

Every business today is data-centric and the role of semantic layers for optimizing efficiency is undeniable. Serving as the bridge between raw data sources and end-point data sources, semantic layers offer a consistent, comprehensive perspective of data across the board. This helps businesses make decisions rooted and organized in accuracy and reliability. By centralizing the definition of semantics and metrics, data teams can eliminate inconsistencies and ensure a unified understanding across all data users, be in internal, external or AI bots. Let us look into how semantic layers streamline data management and analytics, simplifying the concepts of a semantic layer into digestible and relatable terms. 

## How a Semantic Layer Works in the Data Stack

[Semantic layers](https://cube.dev/use-cases/semantic-layer) are not a new concept, but their importance has grown with the increasing complexity of modern data stacks. Today, businesses use a variety of visualization tools, customer-facing analytics, [embedded analytics](https://cube.dev/use-cases/embedded-analytics), and AI agents. Each time a new data visualization or data app is implemented, metrics and/or logic need to be defined. If not managed properly, this can lead to inconsistencies and discrepancies and, ultimately wasted resources. Semantic layers address this issue by centralizing these definitions, ensuring consistency across different data consumption endpoints.

The semantic layer has been around for a while, embedded in Business Intelligence (BI) tools. However, the recent shift towards standalone semantic layers is driven by the need for a universal, easy-to-use, and highly discoverable data interface. The democratization of data has led to fragmentation and silos, impeding ease of use and leading to failed analytics projects. A standalone semantic layer addresses these issues, ensuring a single source of consistent data that is easier for data teams to work with. 

The implementation of semantic layers can significantly streamline data management processes. Sitting on top of [data warehouses](https://cube.dev/blog/getting-started-with-a-snowflake-semantic-layer), semantic layers provide data semantics (context) to various data applications. They work seamlessly with transformation tools, allowing businesses to define metrics, prepare data models, and expose them to different BI and analytics tools. This not only enhances efficiency but also ensures that all data consumption places are working with the same, accurate data. So, no matter if the data is being used by a person looking at a dashboard, or a LLM that is giving a person answers to questions, the data is consistent. All of this makes it easier for data teams to quickly deliver data for the various data consumers they work with internally and externally.

## Examples of how companies use semantic layers

Businesses like [Drift](https://www.drift.com/) and [Breakthrough](https://www.breakthroughfuel.com/) have successfully leveraged semantic layers to enhance their data management and analytics. Drift, a customer communication platform, uses semantic layers to ensure consistency in its metrics across different systems. This has not only improved their reporting capabilities but also enabled them to add new data in days instead of months. Breakthrough, a transportation management platform, uses semantic layers to provide consistent data across their SaaS and consulting platforms, significantly improving productivity.

Adopting a semantic layer in an organization is a step-by-step process. It begins with identifying inefficiencies and building a thoughtful semantic model. This model is then incrementally applied to different products, aligning metrics and data definitions. The process also involves identifying and fixing bugs in the old system, ensuring that the data is well-understood and well-documented. This is crucial for the success of analytics and AI projects.

### How AI agents, LLMs and the semantic layers work together

The semantic layer also plays a pivotal role in the realm of [generative AI](https://cube.dev/use-cases/llm-and-ai-semantic-layer). As AI agents are increasingly used for various applications, they need to access and analyze hard data. Due to their non-deterministic nature, AI agents are not good with hard numbers, they need to rely on the context training that has been done on the Large Language Model (LLM) they are fed from. Use of LLMs to generate code (like SQL) can be executed to get the hard numbers for the AI agent. This is where the semantic layer comes in, providing AI agents with the necessary data access and semantics via the LLM. 

However, the use of generative AI also presents new challenges. One of these is the need for a new interface for interacting with data. Another is the need for explainability, ensuring that users can trust the data and understand how the AI is working. The semantic layer can help address these challenges, providing a well-documented and well-understood data interface for AI agents. Semantic layers provide both valuable context and necessary constraint to empower retrieval augmented generation models. While much has been written about providing context via embeddings, we are now learning that constraining LLMs via a semantic layer - choosing from a defined universe of metrics - can be very useful for improving accuracy.  A recent test was performed with an AI Chatbot on data – with and without a semantic layer feeding the LLM. The results were dang clear – AI Chatbot with a semantic layer, outcomes were 100% accurate — AI Chatbot without a semantic layer, outcomes were 83% accurate.  

In summing up, semantic layers are an invaluable asset for businesses keen on optimizing their [data management](https://cube.dev/product/caching-and-data-performance) and analytics. They centralize metric definitions and semantics, ensuring consistency across various data points, which in turn, bolster efficiency and precision. The future will bring more data sources and more data applications, creating even more chaos in the data stack. The significance of semantic layers in navigating the intricacies of the contemporary data stack is poised to increase exponentially. The semantic layer plays a crucial role in increasing confidence in data for non-technical users, fostering the incorporation of analytics and AI projects. It also paves the way for generative AI to access and scrutinize data. Looking ahead, the impact of the semantic layer on data analytics and AI is expected to be even more profound.


Lissa Daniels

Use Cases

Optimizing Data Management and Analytics Efficiency with Semantic Layers

Ever since the wide availability of ChatGPT in early 2023, Large Language Models (LLMs) have become a subject of intense interest and investment in nearly every industry. As we all try to wrap our heads around exactly how the power of generative AI will transform the world, here at Cube it was obvious to us that [semantic layers](https://cube.dev/use-cases/semantic-layer) would have a part to play. This would take shape as the integration of the Cube semantic layer into applications that retrieve information from data stores, perform analysis and return requested results to a user who is interacting with them using natural language, interpreted by an LLM. The exact return method of these results could be multimodal - natural language generation, tabular result sets, or even chained into visualization libraries to return dashboards, but the big idea is “ask a question, get an answer”. We weren’t sure exactly what it would look like, but we knew it was coming.

To prepare for this tectonic shift, we focused on learning about how builders were thinking about this problem and we released features that we felt would empower them such as our semantic document loader for LangChain and our expanded meta endpoints to make it easier to provide the useful context within Cube to the LLM, improving consistency and reducing hallucinations. We also engaged with many builders focusing on next generation analytics experiences driven by natural language query interfaces enabled by LLMs such as our partners at [Patterson Consulting](https://pattersonconsultingtn.com/) and [Delphi Labs](https://www.delphihq.com/) who have been instrumental in delivering AI-enabled analytics use cases for our customers. 

While we all felt that it made sense that an LLM based application would provide more accurate results when answering questions that required examining data within a database with the aid of well designed semantic layer, when compared with more simple zero-shot text-to-sql methods, we will be the first to tell you that we were long on customer anecdotes and light on empirical evidence. 

Recently a group of researchers from data.world (Juan F. Sequeda, Dean Allemang and Bryon Jacob) have published a [ground-breaking paper](https://arxiv.org/pdf/2311.07509.pdf) studying the accuracy of LLMs answering questions with a text-to-sql pattern and comparing those results with the accuracy of introducing a knowledge graph into the process. For those who may not be familiar, knowledge graphs are somewhat similar to semantic layers in that they are also an additional layer of business context that can inform usage of data. 

In addition to the results, the paper also puts forward the detailed methodology for evaluating the accuracy of LLMs in answering business questions asked of a database. They provide a schema, sample data, natural language questions and expected answers in a format that is fairly easy to replicate their experiment. Our partners at Delphi, who build an AI-enabled analytics application on top of semantic layers, quickly realized that this methodology could be adapted to perform a benchmark of the accuracy of their own solution. **[They have recently published some interesting findings of their own](https://delphihq.substack.com/p/delphi-at-100-video), that they were able to achieve an outstanding 100% accuracy with Delphi connected to a subset of the data.world test modeled in Cube as the semantic layer.** This is an incredible result and not only a validation of the ability of semantic layers to provide necessary context to improve LLM accuracy, but also speaks to their thoughtful prompt engineering and design choices. 

## Why are semantic layers the missing piece?

The two driving themes for why we need to use semantic layers with LLMs are context and constraint. We see more and more teams moving towards providing context through prompt engineering and doing things like providing the LLM with a knowledge graph to interface with. This is definitely a step in the right direction, but you also need to constrain their output.

Semantic layers provide both a knowledge graph and a constrained interface for an LLM. As a special type of knowledge graph, a semantic layer provides the LLM with a model of a world, composed of entities and their measures and dimensions. LLMs have been trained on language, and all language is composed of entities (nouns) and their dimensions and attributes (adjectives). Language also contains mathematical terms such as ‘total’, ‘running total’, ‘average’… as a result, LLMs are well-suited to knowledge graphs. 

The reason LLMs are also quite good at SQL is because of how many documents and articles (think Stack Overflow) contain SQL. However, SQL is a minuscule fraction of what LLMs have been trained on. An interface closer to natural language is a better fit for LLMs, and a constrained one, to reduce chance of error and hallucination, is even better. Requests to Cube’s REST API are both close to natural language (a requested list of metrics, dimensions and filters with few, if any, additional terms) and highly constrained (there is only really one way to form a request), if the LLM generates the request incorrectly this will almost always result in an error rather than a hallucination.

However, this has been theory so far, with some anecdotal evidence from using Delphi. What we needed was a benchmark, and now that the data.world one has been created - we have one.

## Testing Methodology
We undertook an ambitious benchmark test, following the footsteps of data.world and dbt Labs, who [tested their semantic layer on a subset of 11 questions](https://github.com/dbt-labs/semantic-layer-llm-benchmarking/tree/main) from the original benchmark. Our goal was to replicate dbt Labs’s methodology on our platform, utilizing Delphi in conjunction with the Cube semantic layer. **The outcome was remarkable - while dbt Labs achieved an impressive 83% across 8 questions (excluding 3 with multi-hop joins), Delphi + Cube reached a perfect score of 100% on all questions.**

The benchmark began by setting up a Snowflake data warehouse. We created the necessary tables from the data.world benchmark using the [DDL available in our GitHub repository](https://github.com/Delphi-Data/delphi-semantic-layer-llm-benchmark/blob/main/ACME_small.ddl).

Once the database structure was in place, we proceeded to populate it with the data files sourced from the insurance dataset [available on data.world’s GitHub](https://github.com/datadotworld/cwd-benchmark-data/tree/main/ACME_Insurance/data), originally developed by Object Management Group. This model, which involves a 3NF structure with multi-hop joins, was crucial in replicating the complexity of real-world data, setting the stage for an authentic benchmarking experience.

Next, we started building out the Cube semantic layer. This involved signing up for Cube’s free tier and creating a new project using the credentials from our Snowflake account. Using Cube Cloud’s built-in IDE, we developed the Cube schema available in our GitHub repository, including all tables and dimensions from the benchmark (even “extra” ones our questions did not use) and some basic measures.

Finally, we created a new free account on Delphi, connected Cube via its REST API integration, and then were off to the races. Working off the benchmark results sheet created by dbt Labs, we ran each question in a separate Delphi conversation and tracked the results. We replicated this 5 separate times to ensure that our results were consistent and not impacted by the non-determinism that’s often possible with LLMs.

Our results are publicly available, including the Cube queries Delphi generated. Delphi was able to answer 100% of the questions correctly, even including some where it was able to calculate the needed measures on the fly.

In line with our commitment to transparency and community collaboration, we have made our Cube schema and benchmark instructions publicly available. These resources can be accessed on our GitHub repository at [Delphi Semantic Layer LLM Benchmark](https://github.com/Delphi-Data/delphi-semantic-layer-llm-benchmark), inviting others to replicate our benchmark and share their findings.

## Conclusion

There is now empirical evidence that using a semantic layer with an LLM, for analytics, is superior to other methods. We have chained a number of proprietary methods in addition to this to deliver the best-in-class performance we see with Delphi. We invite everyone to take a look at the testing methodology above and take both [Cube](https://cubecloud.dev/auth) and [Delphi](https://auth.delphihq.com/en/signup) for a spin. We’d love to show you how easy it is to start asking questions of your data and feel confident that the answers your team will receive are grounded in the reality of your data.


Brian Bickell

Artificial Intelligence

Semantic layers provide LLMs context and constraint.

Semantic Layers are the missing piece for AI-Enabled Analytics

For many years already, we live in the data-driven world where accessing the data and deriving insights from it efficiently is paramount. This year, we experience an explosion of interest to artificial intelligence (AI) and large language models (LLMs) in particular, fueled by the latest developments in the technology and vast perspectives unfolding.

[LangChain](https://www.langchain.com), an extensive toolkit for working with LLMs, has become one of the most important building blocks for developers of AI experiences. At Cube, we know that our semantic layer is also an important building block for AI applications because Cube not only centralizes metrics calculations but also serves an [antidote to AI hallucinations](https://cube.dev/blog/semantic-layer-the-backbone-of-ai-powered-data-experiences).

## Semantic document loader

Today, we're happy to present Cube's integration with LangChain. It comes as the [document loader](https://python.langchain.com/docs/integrations/document_loaders/cube_semantic) that is intended to be used to populate a vector database with embeddings derived from the data model of the semantic layer. Later, this vector database can be queried to find best-matching entities of the semantic layer. This is useful to match free-form input, e.g., queries in a natural language, with the views and their members in the data model.

![diagram](https://ucarecdn.com/32e98c8b-a920-4620-a8d2-05d57618db8e/)

We're also providing an chat-based demo application (see [source code](https://github.com/cube-js/cube/tree/master/examples/langchain) on GitHub) with example [OpenAI prompts](https://github.com/cube-js/cube/blob/master/examples/langchain/utils.py#L48,L87) for constructing queries to Cube's [SQL API](https://cube.dev/docs/product/apis-integrations/sql-api). If you wish to create an [AI-powered conversational interface](https://cube.dev/blog/conversational-interface-for-semantic-layer) for the semantic layer, functioning similar to [Delphi](https://www.delphihq.com), these prompts can be a good starting point.

## Chat-based demo app, dissected

Here's what you can build with the all-new document loader for LangChain, a vector database, an LLM by [OpenAI](https://openai.com), and [Streamlit](https://streamlit.io) for the user interface:

<video width="100%" controls><source src="https://ucarecdn.com/5500be7a-ab78-4de8-abc9-02df575ad3e0/video.mp4" type="video/mp4"/></video>

See how the tables, columns, aggregations, and filters in the SQL query generated by an LLM match the human input. Check the [README file on GitHub](https://github.com/cube-js/cube/blob/master/examples/langchain/README.md) for pointers on running this demo application on your machine or skim through the following highlights.

**Ingesting metadata from Cube and populating the vector database.** The `ingest_cube_meta` function in the `ingest.py` file loads the data model from Cube using the all-new `CubeSemanticLoader`. Note that only [views](https://cube.dev/docs/product/data-modeling/reference/view) are loaded as they are considered the ["facade" of the data model](https://cube.dev/blog/complementing-data-graph-with-views). Loaded documents are then embedded and saved in the FAISS vector store, which is subsequently pickled for later use.

```python
def ingest_cube_meta():
    ...
    loader = CubeSemanticLoader(api_url, api_token)
    documents = loader.load()
    ...
    with open("vectorstore.pkl", "wb") as f:
        pickle.dump(vectorstore, f)
```

**LLM setup.** In the `main.py` file, dependencies are imported and the environment variables are loaded. The OpenAI model (`llm`) is initialized with the provided API key.

```python
import ...
load_dotenv()
llm = OpenAI(
    temperature=0, 
    openai_api_key=os.environ.get("OPENAI_API_KEY"),
    verbose=True
)
```

**User input and vector store initialization.** In the same file, Streamlit primitives are utilized to get user input:

```python
question = st.text_input(
    "Your question: ",
    placeholder="Ask me anything ...",
    key="input"
)
if st.button("Submit", type="primary"):
    check_input(question)
    vectorstore = init_vectorstore()
```

**Querying the vector store.** The vector store is queried for documents similar to the user's question. The best match's table name is extracted and taken as the best guess to try to create a prompt using the columns from vectorstore:

```python
docs = vectorstore.similarity_search(question)
    # take the first document as the best guess
    table_name = docs[0].metadata["table_name"]

    # Columns
    columns_question = "All available columns"
    column_docs = vectorstore.similarity_search(
        columns_question,
        filter=dict(table_name=table_name),
        k=15
    )
```

**Building the prompt and calling OpenAI.*** The OpenAI large language model is called with the constructed prompt, and the response is parsed to extract the SQL query and any associated filters:

```python
# Construct the prompt
prompt = CUBE_SQL_API_PROMPT.format(
    input_question=question,
    table_info=table_name,
    columns_info=columns,
    top_k=1000,
    no_answer_text=_NO_ANSWER_TEXT,
)
llm_answer = llm(prompt + PROMPT_POSTFIX)
```

![](https://ucarecdn.com/1252fc98-75db-4887-be82-227b60d477a9/)

## Wrapping up

Cube's integration with LangChain provides a seamless interface for querying data using natural language. By abstracting the complexities of SQL and leveraging the power of LLMs, it provides the builders of AI experiences with a user-friendly and error-prone approach to data access.

<Quote authorName="Josh Patterson" authorAvatar="https://ucarecdn.com/a3e94c6f-5d02-4b57-b523-bbfaf04f4890/8s5_8mFF_400x400.jpg" authorRole="CEO at Patterson Consulting">

It is essential for enterprises to leverage internal knowledge correctly with the power of LLM’s reasoning. Cube’s semantic layer integration with LangChain is a great example of how most product companies will eventually write smart integrations for LLMs to better power these reasoning engines.

</Quote>

Our partners at Patterson Consulting have been hard at work building with Cube, LangChain and LLMs. They have written a wonderful ebook as a primer to [Building Enterprise Applications with LLMs](https://pattersonconsultingtn.com/content/intro_to_llms_ebook.html).

**You can try the LangChain integration with a Cube Core or [Cube Cloud deployment](https://cubecloud.dev/auth/signup) today.** Join our Slack community at [slack.cube.dev](https://slack.cube.dev) to share your thoughts and opinions about this update.

Mikhail Nitsenko

Powerful tooling for building AI experiences with LLMs and the semantic layer

Introducing the LangChain integration

## The AI-powered data experience

We’ve long seen that the data experiences landscape has been very diverse. From dozens of general-purpose BIs to hundreds of vertical purpose-built analytical solutions, data consumers have many, many options to visualize and consume data.

The evolution of front-end technologies made it possible to embed quality analytics experiences directly into many software products, further accelerating the proliferation of data products and experiences. 

And now, with the arrival of large language models, we are living through another step change in technology that will enable many new features and even in the advent of an entirely new class of products across multiple use cases and domains—_including_ data. 

LLMs are taking the data consumption layer to the next level with **AI-powered data experiences** ranging from chatbots answering questions about your business data to AI agents making actions based on the signals and anomalies in data. 

![](https://ucarecdn.com/5c8bd295-4317-4820-beea-532f8c9ba391/)

## Semantic layer gives context to LLMs

LLMs are indeed a step change, but inevitably, as with every technology, it comes with its own limitations. **[LLMs hallucinate](https://en.wikipedia.org/wiki/Hallucination_(artificial_intelligence)); the [garbage in, garbage out](https://en.wikipedia.org/wiki/Garbage_in,_garbage_out) problem has never been more of a problem.** Let’s think about it like this: when it’s hard for humans to comprehend inconsistent and disorganized data, LLM will simply compound on that confusion to produce wrong answers.  

We can’t feed LLM with database schema and expect it to generate the correct SQL. To operate correctly and execute trustworthy actions, __it needs to have enough context and semantics__ about the data it consumes; it must understand the metrics, dimensions, entities, and relational aspects of the data by which it's powered. Basically—LLM needs a semantic layer.

The semantic layer organizes data into meaningful business definitions and then allows for querying these definitions—rather than querying the database directly. 

The ‘querying’ application is equally important as that of ‘definitions’ because it enforces LLM to query data through the semantic layer, ensuring the correctness of the queries and returned data. With that, the semantic layer becomes a solution for the LLM hallucination problem.

![](https://ucarecdn.com/c79d8e5a-ad67-43b3-ac4f-b3d323c0fb65/)

Moreover, the combination of LLMs and semantic layers can enable a new generation of AI-powered data experiences. At Cube, we’ve already witnessed many organizations build custom in-house LLM-powered applications, and startups, like [Delphi](https://cube.dev/blog/conversational-interface-for-semantic-layer), build out-of-the-box solutions on top of Cube’s semantic layer ([demo here](https://cube.dev/events/unleash-the-power-of-ai)). 

On the edge of this developmental forefront, we see Cube being an integral part of the modern AI tech stack as it sits on top of data warehouses, providing context to AI agents and acting as an interface to query data.

![](https://ucarecdn.com/ea4d11af-b3f9-43b9-b02e-b8fa8056c4b1/)

Cube’s data model provides structure and definitions that are used as a context for LLM to understand data and generate correct queries. LLM doesn’t need to navigate complex joins and metrics calculations because Cube abstracts those and provides a simple interface that operates on the business-level terminology, instead of SQL table and column names. This simplification helps LLM to be less error-prone and avoid hallucinations. 

For example, an AI-based application would first read Cube’s meta API endpoint, downloading all the definitions of the semantic layer and storing them as embeddings in a vector database. Later, when a user sends a query, these embeddings would be used in the prompt to LLM to provide additional context. LLM would then respond with a generated query to Cube, and the application would execute it. This process can be chained and repeated multiple times to answer complicated questions or create summary reports. 

### Performance

In regards to response times—when working on complicated queries and tasks, the AI system may need to query the semantic layer multiple times, applying different filters. 

So, to ensure reasonable performance, these queries must be cached and not always pushed down to the underlying data warehouses. Cube provides a relational cache engine to build pre-aggregations on top of raw data and implements aggregate awareness to route queries to these aggregates when possible.

### Security

And, finally, security and access control should never be an afterthought when building AI-based applications. As we mentioned above, generating raw SQL and executing it in a data warehouse may lead to wrong results. 

However, AI poses an additional risk here: since it cannot be controlled and may generate arbitrary SQL, direct access between AI and raw data stores can also be a significant security vulnerability. Instead, generating SQL through the semantic layer can ensure granular access control policies are in place. 

### And more...

We have a lot of exciting integrations with the AI ecosystem in store and can’t wait to share them with you. Meanwhile, if you are working on an AI-powered application with Cube – [let’s talk](https://cube.dev/contact)! 


Artyom Keydunov

—and the antidote to AI Hallucinations.

Semantic Layer: The Backbone of AI-powered Data Experiences

Today, we’re happy to present the newest addition to the plethora of [data tools](https://cube.dev/integrations) that work with Cube, the semantic layer for building data apps. [Delphi](https://www.delphihq.com) provides a way to interact with Cube in natural language and delivers insights straight to business users in Slack. 

![Diagram: Cube and Delphi](https://ucarecdn.com/ed0d51c4-2ff7-40cc-891f-32badcc57a51/)

Powered by the newest large language model (LLM) technology from OpenAI, Delphi brings the accessibility of self-service analytics to the next level and enables a compelling use case for semantic layers. See Cube and Delphi in action:

<iframe width="790" height="447" src="https://www.youtube.com/embed/FotEaaf20gY" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen allow="fullscreen;"></iframe>

Learn more about Delphi and [semantic superiority](https://davidsj.substack.com/p/semantic-superiority-part-4) from David Jayatillake, co-founder and CEO at Delphi Labs:

## Natural language interface for data

Our mission for Delphi is to solve the whole workflow, from question to answer, with data. Today, this is broken—self-serve BI tools haven’t delivered on this promise to date, and data teams are bombarded with ad hoc requests at a scale greater than ever before as businesses move to operate with data.

When we ask data leaders in the space what % of their organization is capable of self-serving with data, the answer is usually between 10 to 25%, with only 10% being very competent. It’s been three years since “dashboards are dead,” but unfortunately they’re still being used as the primary way to serve data. In my experience, no stakeholder ever wanted a dashboard. They wanted an answer, an explanation, a prediction, data to use elsewhere operationally, a graph or a slide to make a specific point.
This is the problem space we aim to solve with Delphi.

There are many other entrants who are trying to offer a natural language interface to data in this LLM gold rush. However, almost all of them are pointing the LLM at a database schema and getting it to generate SQL. We believe this is the wrong approach: every time a query is answered using this method, the LLM generates a minimal semantic layer on the fly in order to derive meaning from the data. As humans created the data structures and their meaning in the first place, why introduce a probabilistic element into the meaning of your data?

We believe that working with semantic layers curated by data folks is the best approach. It synthesizes the information already baked into the semantic layer, truly enabling safe and accurate answers. It also allows us to say that we can’t answer the question—a very normal outcome when asking a data team a question; LLMs connected directly to a data store will simply guess, as they don’t have a concept of a world and what does, and doesn’t, exist in it, which a semantic layer offers.

This is why we’re so excited to work with semantic layers like Cube—we’re already blown away by the interest we’ve had from the Cube community and hope to continue to work with you all!

As I’ve written in my [substack](https://davidsj.substack.com/archive), I believe the future of semantic layers is standalone. It’s what the people want.

## What’s next?

Here's what an early adopter of Delphi and Cube thinks:

> Getting started with Delphi on Cube was a breeze and we really quickly had a conversational AI interface to our data warehouse. The accuracy was great and some of the Delphi features really helped explain our data and ensure we knew how we were querying it. I'd highly recommend it for it's wow factor and enabling moving towards a data driven culture.

Interested? Implement your [semantic layer](https://cube.dev/use-cases/semantic-layer) with Cube by [getting started with Cube Cloud](https://cubecloud.dev/auth/signup) today or by [contacting us](https://cube.dev/contact). Also, [sign up for Delphi](https://docs.google.com/forms/d/e/1FAIpQLSc7nJc1Zeu5kEHcKrghbTPy3MSxJLOBsge0kj4Iiz5aqX6zJg/viewform) and see it in action at [slack.cube.dev](https://slack.cube.dev) in the `#random-delphi-demo` channel:

![Delphi in Slack](https://ucarecdn.com/ddf30e1e-c179-4fda-8aa8-2f75a05f808e/)


Artificial Intelligence

Investing in Cube’s AI-driven future.

Optimizing Data Management and Analytics Efficiency with Semantic Layers

Get Cube updates to your inbox

Semantic Layers are the missing piece for AI-Enabled Analytics

Introducing the LangChain integration

Semantic Layer: The Backbone of AI-powered Data Experiences

AI-powered conversational interface for the semantic layer

Upgrade your data stack today