Hey folks, I am Anushrath. I lead the applied research team here at PromQL. PromQL, you might have seen as the sponsor for the reliability track here at the AI Engineers World Fair. So today I'll talk about the data readiness is a myth. How many of you are trying to deploy some kind of AI system on some kind of data in a production environment?

Okay. Awesome. Who is trying to work with more than documents and vector databases? Okay. Whose data is perfect? Clean, annotated, perfect column names, table names? Anyone? See, no hands. Okay. And how much time does everyone... Okay, I'm not going to make this a question. You all spend a lot of time making your data ready, right?

So that the AI can understand it, so that the AI understands the meanings and the relationships in your data. But it's just a pipe dream that we are all chasing, right? We are all chasing this perfect data dream so that our AI can finally work reliably on it. And that's never going to happen.

So how do we still make it reliable, no matter how messy data we have? Okay. So tell me if this is a fact. Is this what your data looks like? Your... That's how you name your tables. That's how you name your columns. Sometimes they have null values. Sometimes you have old values, old column names.

Sometimes you have shorthand. CST_NM. Does that customer name? Is it custom nomenclature? I don't know what that is. Rev_amount_ust. That's how you name your revenue. Is active. Now, is this binary? Is a Boolean field? Is it zero, one, true, false, null, not null? I don't know what it is, right?

Then you have other systems. That's just one system. One table in one system. You have other systems which have similar things, right? It has organization name. It has total revenue. How does that map to your other systems? Is the revenue in cents? Is it in dollars? Decimal value? Floating points?

What is it, right? You have no idea. Okay. So in 2019, everyone was saying, let's standardize everything. Move everything in Snowflake. Let's move everything in Databricks. And finally, our problems will be fixed. 40% complete. MDM will fix this. Master Data Management Team will fix this. That's their responsibility. They're still implementing their information.

So in 2023, with the rise of AI, rise of agents, we'll create semantic layers that understand our data domain. I mean, it breaks every quarter. Your data domain changes every quarter, right? You change your tables. You change your schemas. You change your workflows. So in 2025, we are saying AI needs perfect data to work.

And it's still waiting. And it's never going to happen. Right? And McKinsey said that on an average, a Fortune 500 company loses $250 million because of poor data quality. So how do we fix this? So who has tried playing with semantic layers? Mem0, Atlans, semantic kernel, you have tried playing with it, right?

How has your experience been? We actually use Jando to create a flexible model. Okay. Gotcha. Lot of pruning. Okay. And I'm assuming you're manually adding information to it, maintaining it, and stuff like that. Right? Sure. Yeah. Okay. So let's say you've added a definition, like customer acquisition cost means marketing spend divided by new customers.

Okay? Now, this is some information your AI needs to answer your questions. But that's not enough, right? Like, which marketing spend? Coming from the brand team, from the performance team? What does a new customer even mean? Right? First purchase customer, reactivated customer. For what time period are we talking about?

Does it include failed trials or not? Is it accounting for seasonality? There are so many things that you need to do, and you can never capture all of that in a semantic layer just by -- if you think you can manually add everything, you can't. Right? So you can't redefine every edge case.

Knowledge graphs. Who's played with knowledge graphs? Graph rag? Heard of it, at least. Okay. A bunch of people. Okay. Awesome. So, let's take a very simple example. Assume a customer's -- assume a sales data set where you have defined this graph that deals map to stage, a date, and an owner.

Okay? And a very simple question I ask. Show me deals at risk. Right? Very simple questions. The graph knows that deals map to stages, stages map to close dates. But what does at risk mean? Is it mean that the champion has just left? Is it mean it has been stuck in that stage for two months?

Like, what does at risk mean to my business? Right? How do you capture that in a graph database? Right? How do you capture a billion rows of snowflake table in a graph database? You can't. So graph is also -- knowledge graph is also another solution. So the real problem here is not that we need a better semantic layer solution.

We need a better graph rack solution. We need a better named database systems. No. The problem is that the AI does not speak your business language. Like, a GM in a finance domain can mean gross margin. But, you know, HR domain might mean general manager. Right? What does conversion mean to you?

What does quarter mean to you? What is the definition of your quarter? I'll show you an example here with an AI system not working with that. And what is an active customer? Every team has their own definition. Right? So how does an AI speak this tribal knowledge, this tacit knowledge that you have developed while being in your company for so many years?

Right? Your AI does not know that. Your vanilla LLMs don't know that. They're super smart, incredible at doing so many cool stuff. So much cool stuff. But they don't understand your business, your domain. Right? So traditionally, we had these analysts, these engineers, right? Whenever a business user or a customer had a problem, had a task, they had a question, they would go to this analyst or an engineer who knew about the business, who had this tribal knowledge in their head.

They knew how to write code, SQL, whatever. They can talk to your underlying data systems. SQL, no SQL, doesn't matter. Any kind of data source. Right? And they have this tribal knowledge, which they use to answer your question with 100% reliability. They explain what they're doing. Right? And that's how you have all built trust in your colleagues, in your peers.

Right? That's what is missing with AI. Right? This tribal knowledge piece that doesn't exist today with AI. And that's the problem. So the solution. The same semantically, but let's make it agentic. What that means is let's not try to improve it. Let's not try to manually add context to there continuously.

No. How about we make an AI system that behaves like the analyst you just hired today. Day one, day zero, the analyst comes to your company, super smart, can do a bunch of things. Doesn't know a lot about your business yet. They start working with you. They mess up somewhere.

You tell them, no, that's not what you should have done. This is what I mean when I say this. It learns, learns, learns, learns. Now this analyst 10 years later is an experienced analyst in your company. They know everything about your business. Right? Let's make an AI like that.

An AI that keeps improving, keeps learning as you use it more and more, as you course correct it, as you steer it. But assumption is your AI needs to be correctable, explainable, steerable, already accurate in what it knows. Right? So let's see how you build such an AI. Right?

So we're trying to replace this human part of the AI. Right? So that's what we have been trying to do with PromQL. It's like a day zero smart analyst. Right? So we take a foundational LLM and that's the whatever LLM you bring. We make it create PromQL plans. PromQL is basically a domain specific language which can do three tasks.

Data retrieval, data compute aggregation, and semantics. And this is a deterministic domain language. And vanilla LLMs are incredible at generating. We don't have to fine tune them. Right? Now, within this DSL, I can ask the LLM to create this DSL whenever I ask the user to ask the question.

Now I can execute this DSL in a deterministic runtime. I do not involve the LLM in actual execution, actual generation of an answer. Because if I let the LLM generate the answer, it's by default hallucinating. And I'm just hoping the hallucination is correct. That's how LLMs work. Right? So I'm saying, decouple it.

Let the LLM generate the plan, and we will execute this plan in a deterministic runtime. And let it work on a distributed query engine, which will talk to the different data sources, pull out data, do whatever composition was required inside that DSL, show the answer directly to the user.

Don't give it back to the LLM. Let's not do rag. Right? Let's not give the LLM data back to the LLM and make it generate the answer. Right? That's what the PromQL design is. Let me show you PromQL working in action. I have five minutes. So let's make this quick.

Simple question. Who are my top five customers by revenue? You'll be like, any AI system can answer that question, dude. It's a simple text to SQL question. Okay. So PromQL is like, first of all, it understands what revenue means. Revenue means your invoice items. Okay. Cool. I'll do the math.

Execute the math. And here are your top five customers. Oops. Nope. I didn't notice we did not get any results. Right? That's what a smart analyst does. In their first attempt, they realized they messed up somewhere. Okay. I see the issue now. We're looking for succeeded status, but the actual statuses are paid and pending.

See, your data is messy. It did not know what was happening. Right? It figured that out. And now these are your top five based on the actual data that's under the hood. So that's possible. Let's run this query now. Okay? Find the unique customers we serve. The org-guided data is messed up, so we don't use that.

Find unique orgs based on the email domains of the individual users. Then find the org with the third highest revenue. I'll let it run because it'll take time. Find the unique orgs based on the email domains of the individual users. Then for the org with the third highest revenue, take a look at the latest 30 support tickets.

So multiple database, then your Zendesk support system, including the comments on those tickets, then summarize each ticket. Then use those summaries and extract their feelings towards our product. Create five categories from bad to great. And then tell me what is going well, what can be improved. And then issue up to $5,000 to this orgs project as, like, credits with the highest usage, which means $5,000 if their feeling is bad towards us and $1,000 if it's great towards us.

And how do you think an AI can do this? Spread across your databases, your SaaS application like Zendesk, your API, like, Stripe to issue the credits, stuff like that. So they'll be cool. First, I'll get all the users, extract their email domains. See, this is an analyst explaining their thought process.

You see that tiny pencil icon? I can edit their brain. I can tell them, no, this is not what I wanted you to do. Don't do step three. Instead of that, do these three steps instead. Right? I can, I can be in charge of my AI, but still every single time if I have to nudge my AI, the AI is going to learn.

They will understand. Okay, that's what you wanted me to do. Makes sense. That's how you do your business. I didn't know that. Sorry. I learned now. Right? So, okay, cool. I should have said, just show me intermediate results step by step. But anyway, it says I'm about to issue $3,000 refund.

Probably got a neutral sentiment from it. And see, it's exactly what's happening. It's saying, I got the top five domains by revenue. This is the sentiment. I summarized a bunch of tickets. I classified, extracted the sentiment out of that. And then, finally, I'm figuring out what is happening there.

Okay. So, peritissue details. Perfect. Based on analysis. Petersthompson.bizzer, third IS revenue customer, with this much revenue, sentiment analysis, recent support tickets, blah, blah, blah. See, this AI just moved as an analyst with such a complicated prompt. So, now, let's look back at the learning. Right? Just because we had two and a half minutes.

Okay. So, that's day zero. Day zero, it had to figure stuff out, figure it out, did well. Day X, once it's become a veteran analyst, right? It has learned a bunch. Let me make this bigger for you. Learned a bunch, right? So, as it's using, as you are working with it, right?

It learns from it. There's a prompt QL learning layer, which basically improves the semantic graph and starts creating your company's business language. This Acme QL, Acme, assume it's the name of a company. Right? And now, suddenly, prompt QL becomes Acme QL. It becomes Google QL, Microsoft QL, Apple QL, Cisco QL, whatever company you come from.

Right? And I'll show you that learning process in action. Okay? So, this is an example where I have purposefully named my tables extremely bad. Right? And I asked the question, which employees are working in departments with more than U.S. dollars, $10,000 budget. Okay? It says, I have no idea what you're talking about.

Your data says there are three tables called Mork, Plug and Zorp. I have no idea what that means. I can't answer your question. I'm like, no worries. Can you sample a few rows from each table and figure out what table contains the employees? Like, cool. I think that's what I tell man.

Let's go figure it out. Right? It's like, okay, now I see Zorp contains employee information, Plug contains department information, and Mork is like a junction table that you have. Okay? So, now this is your answer that you were asking for. And I'm like, okay, but the data is in cents, not in dollars.

The budget is in cents. So, can you divide by 100, please? And give me the right answer now. There shouldn't be five employees. It says, cool. There are two employees. Perfect. Now, this is manual, but this also runs agentically in the background. But all I have to do is suggest my data improvements based on the recent trends.

Right? Look at what have we spoken about. How much I had to guide you. Whatever hints I had to give you. Learn from it and improve your semantic layer. Right? It's like, cool. So, based on the interaction that we have, now I have this improved semantic layer where it's like, okay, Zorp and Plug are two tables.

I need to add a lot more context to it in my own semantic layer. Right? And the department budget is in cents. Right? Cool. Apply the suggestion. Every single instance of your semantic layer is version control. So, a new build is created. You can always fall back to a previous build.

And now, the next time, it's generated by Autograph. That's what we call the feature. And the next time, I ask the same question. Which employees are working in departments with more than US$10,000 in budget? It creates the right plan. And I get the right answer. Right? So, same. If I had to say something like this.

Find accounts with the maximum suspicious, anti-money laundering, outgoing amounts for the first quarter for each print the account ID and name. Right? If I let my AI do this, the internet is a little bad. But I have this thread preloaded here. Okay. So, it gives me the answer. And then I'm like, no, my quarter starts in February, not in January.

So, you should know that. Right? So, I just tell it this time. Next time, the semantic layer learns from it. Exactly the same way. As it will infer the meanings of these tables. It will find the relationships across your tables. Right? And finally, with all of this, what you have is day zero.

Your AI does not know what an enterprise customer means. It does not know how to match customer IDs across systems. It does not know when your financial quarter starts. Day 30. It has figured out 47 business terms. It has mapped relationships across the six systems. It has discovered 12 calculation variants and 100% accurate on your complex tasks.

That's what an agentic semantic layer allows you to do. So, it reduces months of work into immediate start. Like, just deploy your AI today. Let your AI start working on your data. Let it improve itself. No wait time. No lag time with your AI deployments. Right? It's self-improving and gets to 100% accuracy.

That's what we've been hearing from our customers. It's a Fortune 500 food chain company. They evaluate 100 vendors. They realize, no, none of them work. Finally, they saw PromQL and it worked 100% level AI. Same with the high growth Fintech company. On the hardest questions, we were able to demonstrate 100% accuracy.

So, reach out to us if you have these big problems that you want to solve and you want 100% accurate AI. On top of that, we're there for you. Thank you. Thank you.