Cube’s AI API is here, and it is available on Cube Cloud Premium and higher tiers. In our newest native API, we built the ideal architecture to extend the value of your Cube Cloud investment and accelerate the development of natural language capabilities with a turnkey solution, starting with OpenAI.

The AI API includes Retrieval Augmented Generation (RAG) and prompt engineering, for an LLM to interface with the Cube’s universal semantic layer. This simplifies the development of AI applications and features in your data products.

We leverage our deep knowledge of Cube’s universal semantic layer, its APIs, and metadata. You benefit from this API without needing to build your own RAG, prompt engineering, or vector store of your own. This saves a huge amount of time, effort, and cost compared to developing in-house. Now, you can focus on developing the best AI agents and chatbot experiences for your customers.

Why Is Text-to-Semantic Layer Better?

The semantic layer is the foundation for trustworthy AI access to data using LLMs. With the public preview release of our new AI API you can now use Cube’s universal semantic layer with AI. The new AI API interfaces with our existing REST API to request the data the user has asked for; it does not generate raw SQL.

The semantic layer provides the ideal middleware to stand between LLMs and data. When asking an LLM to generate raw SQL on a database schema, it’s far too easy for it to hallucinate or get small things wrong as we saw in our webinar, Delivering on the Promise of AI.

The semantic layer provides context and also constrains what the LLM can answer with. LLMs have been trained on language itself–nouns, adjectives, etc. Semantic layers provide LLMs with objects that are equivalent to these language elements: entities for nouns, dimensions/attributes for adjectives, and measures for quantitative description. The LLM has the choice of the objects in the semantic layer and their attributes defined there, to answer questions with - not the whole knowledge it has been trained on.

This is just the first part, and is true of providing knowledge graph access to an LLM too. Semantic layers are special knowledge graphs, designed for querying data. Semantic layers, like Cube, provide APIs which have much more constrained input than raw SQL. If an LLM is forced to generate such an API request, it is much less likely to make a technically valid hallucination. Add to this, the fact that Cube is still compiling the request into raw SQL, doing the joins, aggregation, and filtering deterministically with our best-in-class compiler. The LLM is again constrained from work that it couldn’t reliably get correct.

Preparing Cube Data Models for Generative AI

You will use existing views within Cube Cloud to keep it DRY (Don’t Repeat Yourself); however, there are likely some modifications needed to work with the new AI API, as compared to other use cases.

Imagine that a data engineer from another company is reviewing your data model. The baseline test for preparing your data model for Generative AI is: Is it clear enough that a data engineer from another company would understand it? If the answer is yes because you’ve used clear, plain-language, readable terms and don’t have a lot of acronyms or company lingo, then it is likely that it can work with this API.

Don’t worry if this isn’t the case though, a few simple modifications can make all the difference. You don’t need to rework your whole semantic layer, just the parts that you want to expose to the AI API. First, ensure that you are working with Views in Cube Cloud, then use the following best practices to prepare it for use with the AI API:

  • Use clear, standard names. Make names understandable, i.e. call a customer a Customer not some strange acronym like CustAcctNm that only people in your company use.
  • Add verbose descriptions. Explain the member's purpose clearly. If you don’t want to put too much in the description field, in case it confuses human users, you can use a meta-tag to add more detail for the Cube AI API to pick up on. It’s helpful to mention in either if people use synonyms or acronyms to refer to that entity or member, if specific values for the field have special meanings etc.
  • Make member names distinct. If you have multiples of the same type of member, such as timestamp fields, try to make it very clear as to the use case for the field. For example, order_timestamp for when the order was made, and shipped_timestamp for when an order was shipped. Again, where there is ambiguity, you can describe how to treat it in the descriptions or meta-tag as if you were talking to a colleague.

Testing the AI API with Postman

Once you have your views built and the AI API enabled (see the topic for the AI API in docs for more info on that), you’ll naturally want to try it out. An easy way to test is to use an API testing tool like Postman that lets you send API requests and inspect responses.

To get started, click the “Import” button in the top left or press Command+O. Then, paste the following example request in and hit enter:

curl \
-X POST \
-H "Content-Type: application/json" \
-H "Authorization: Bearer EXAMPLE-API-TOKEN" \
--data '{ "messages": [{ "role": "user", "content": "what cities do we have the most sales in?" }]}' \
https://YOUR_CUBE_API/cubejs-api/v1/ai/query/completions

This brings up a request. Replace YOUR_CUBE_API in the URL with your own Cube Cloud API, and EXAMPLE-API-TOKEN in the authorization header with a valid JWT for your Cube deployment.

In the request body, replace the question in “content” with something relevant to your own data set and the view(s) that you created.

After you hit Run, you will get a response that looks like the following:

This is a Cube query on your data, generated by AI! To run it, just copy the Cube query into a request to Cube’s REST API’s /load endpoint. Alternatively, you can add "runQuery": true to the AI API request body to run it inline.

For example, in the video above, we ask the AI API for the cities where we have the most sales. It gives us back a Cube query using the Line Items view: total amount by city, top 10 descending. When we run the query, we can see that Los Angeles is where we have the most sales, followed by Seattle and Mountain View.

And now you’ve run your first Cube query using AI! Feel free to explore, add more messages to the conversation, and ask other questions to get a feel for what it can do.

Get Started with the AI API

The release of Cube Cloud’s new AI API simplifies the development of Generative AI experiences for embedded developers and data engineers, while natural language interactions lower the barrier for every user of your product or solution–both inside or outside of your organization.

We will continue to invest in the AI API and improve it over time, allowing all teams who deploy using our AI API to benefit from these enhancements as we release them. When it comes to how to use the Cube Cloud’s universal semantic layer with AI, we’ll do the heavy lifting, so you can focus on building sophisticated data experiences. To get started with the AI API in preview, contact sales to learn more!