Plenty of teams can demo an impressive AI prototype, but far fewer can trust one in production. The reason is hallucination: general-purpose models optimise to be pretty good at everything and perfect at nothing, which is fine for a greeting but disastrous when a model confidently invents a revenue figure, a date, or a SQL query against a complex schema.
Sharon Zhou, founder and CEO of Lamini, traces where hallucinations actually come from and how to engineer them out. She explains the "mixture of memory experts" architecture that embeds the facts you care about while keeping a model general, and shows the payoff through real deployments, from a business intelligence agent that put SQL in the hands of thirty thousand employees to drug-combination prediction in cancer research. Alongside the algorithm, she makes the case that clean data pipelines, real evaluation, and fast iteration are what separate a scaling system from a stuck one.
Auto-generated transcript - may contain errors.
Tap a timestamp to jump the video.
Hello, everyone. I feel like I'm looking through rose colored glasses here. So I'm Sharon. Thank you so much for the introduction. I'm the founder and CEO of Lammini, in which I will talk about some of our technology, how it relates to AI agents, but also how we're leveraging AI agents on our platform.
My background is before this, I was adjunct faculty at Stanford leading a research group in generative AI, Where I also did my PhD in generative AI with Andrew Ng. And now I get the great pleasure of teaching millions of people online in, you guessed it, generative AI.
So Lamini is a developer platform to make these models not hallucinate. To not make up facts, right? To not make up different things like, oh, if you have ten billion in revenue, and it says one hundred billion, that's a major problem. Or it hallucinates the wrong date, for example.
So we make it possible for developer teams to be able to increase that accuracy systematically on their specific use cases. And actually get to nines of accuracy. And maybe just to start off with a little bit of what we've been seeing in the market.
Gartner has said a third of enterprise apps will be powered by generative AI over the next few years. I think far more than a third actually will be powered by AI. But I do think this statistic is worth calling out. And this is kind of what we've been seeing, what I've been seeing as I talk to hundreds and thousands of enterprises, is this maturity curve.
So folks are kind of at different stages. Probably around twenty twenty three, a couple months after ChatGPT came out, folks were in the exploring stage. So they were kind of just like touching these models, figuring out exactly what is a prompt. Exactly what is this chatty bitty like thing.
And then as that year progressed, people started getting into experimentation. So starting to do more advanced prompting, right? Doing chain of thought and few shot prompting. And then adding in RAG, retrieval augmented generation. And then we see folks now in the implementing and scaling stages.
So for implementation, that would mean starting to mature their data pipelines. Look at the data in the right place so that the model can respond appropriately. And then get started with evaluation. Get started with understanding what is good, better, and best for a model.
So that's kind of what we're seeing now. And very excitingly, I think we're starting to see a few companies in the scaling stage. They've gotten their first initial production use cases. And now they want to scale to these production agentic systems that are leveraging multiple agents in multiple models.
So my focus has been just really looking at hallucinations. Why do these models hallucinate? And also the value of removing those hallucinations. And I think the biggest value that I see is not just that we can now rely on this model a little bit more, but this opens up the opportunity to have more use cases, to work on more use cases, different use cases, than we otherwise would not have had the opportunity to look at, and to use, and to do.
And so these are some of those use cases that we see now in the market. And I'll talk through some examples. For example, one of our customers is Colgate. We just signed a publicity statement with them. And they are building a business intelligence agent.
Right, this model has to, the underlying model has to be able to do text to SQL extremely accurately and precisely. But just using ChatGPT or Anthropics Cloud gets them only thirty percent, forty percent accuracy on their extremely complex schema. So as a result, they needed to steer this model to understand their schema better, and get to that ninety percent threshold that they were looking for.
And what's the value of that? Right? Okay, so it can spit out some SQL. It can write some code there that's custom to their databases. What's the value there? Well, started off with only thirty data scientists before using AI. Thirty data scientists who could write these SQL queries.
But now, with this agent, business intelligence agent, they've enabled thirty thousand folks internally to be able to make data driven decisions. Because they can now effectively write SQL, query that data, and be able to make that decision. And that's across supply chain, operations, sales, marketing.
Okay. So that's the value. But stepping back, I think a lot of people ask me, why do these models hallucinate at all? Where does that hallucination even originate? And I think it's actually really, really interesting. So I think it's because these general models, they're optimizing for something called generalization error, or the average error across all examples.
And they're looking at all examples across the internet, right? And as a result, they're pretty good at everything, but they're perfect at nothing. They're really good at things that are subtly similar or finding similarities across things. But they can't disambiguate something that's similar versus something that is truth and just fact.
And you can't find a similar date, for example, a similar revenue number and be okay with that answer. And just to give you an example, this is just an example. One of the LAMA models definitely has been trained on this Wikipedia page on the Golden Gate Bridge.
And sorry, probably should have done Edinburgh Castle for this audience. But it's definitely been trained on this Wikipedia page on the Golden Gate Bridge. But it still doesn't know that information, excuse me. Still doesn't know that information in its weights. Even though the weights have seen, the parameters of the model have seen this data before.
And that's because it's trying to get pretty good at everything, but it's not trying to understand every single fact that it's actually looked at. And when we run something systematically, we see that it'll hallucinate or not know for seventy percent of the facts on that page.
Which is crazy if you think about it, right? So just even more technical. Basically, when we ask this question, what year did Dave Aguilar climb the Golden Gate Bridge? And let's say the model is able to sample the tokens he climbed it in, and then try to figure out what that last token or last word might be.
An untrained model will sample anything. So it'll sample a date like nineteen eighty one, as likely as it would sample the word cat. He climbed it in cat. So probably not true. But once you train this model, once you fine tune it, once you add rag to it, it's going to sample over a distribution that is going to be a little bit more favorable to dates and numbers than it is to cat, right?
So it's likely to sample from nineteen eighty one, which is the correct date. It's also, since nineteen seventy is kinda similar too. And so it can sample from a distribution like this. Now this is fine and good for things that don't require absolute accuracy.
Where actually if you say nineteen seventy here, it's probably in some cases as wrong as saying the word cat, right? Because if you say cat, at least I know you don't know what you're talking about model. But when you say nineteen seventy, you sound confidently wrong.
And that's what a hallucination is. Operating on similarities like that is actually really valuable in other cases that don't require the facts. So when I say hi or hello, the model is able to understand that I'm greeting it. But it's not gonna not be able to handle one of those cases, right?
It's able to be very flexible because it understands those are similar. So that's a really valuable trait that it's able to generalize and operate on similarities. The problem is that only works when we're talking about any other part of the sentence, but not for these facts.
And so that's the issue. And so unlike the bell curve that we would sample from there on the left, we would rather the distribution it sample from be more like a direct delta function like this on the right and just sample from nineteen eighty one.
Like 1970s, as wrong as cat, only sample from nineteen eighty one. Right? And so that's the type of model architecture that we've been developing at Lam and I to make sure that we can get as close to this as possible. So the model can still be very general, still handle hi, hello, be able to greet you back, maintain that generality, but also be able to embed that factuality into the model on facts that you care about in particular, and get near perfect at those facts.
And we use a model architecture that takes any model and adds and I'll go into this later also, but adds extra weights to it in the adapter layer, the LoRa layer. And we call it a mixture of memory experts, or abbreviated M O M E and pronounced mommy.
And as we know, mommy knows best, So this is why we named the model. But yeah, so that's the type of model architecture we're looking at. And exactly how that works, people always ask. It combines two trends in AI in machine learning. One is LORAs.
And for those unfamiliar with LORAs, LORAs are essentially extra you have your brain here of a model. It's pre trained. It's frozen. And Lora's are these extra brain cells on top, right, that can learn new information. And what's really special about them, they can then get fused back into the big brain at inference time when a user asks a query, and it doesn't incur an inference cost or latency.
So it's just a very efficient way to add new knowledge to the model, where you have to move the big brain at all. You're just learning these extra weights. And then at inference time, you're also not incurring a cost on how fast of a response the model can give back to the user.
The next trend that we're leveraging is mixture of experts. You might have heard of mixture of experts because gpd4 is rumored to be a mixture of expert. But essentially what it is, is a set of specialized experts that are learned when a user asks a question to dynamically route to the right team of experts to answer that question.
For example, GP4 is rumored to be an eight way mixture of experts, eight experts. And so maybe when you ask a chemistry question, it will route to expert A. And then when you ask a physics question, it routes to expert B, therefore using only an eighth of its whole brain.
So it's much faster, right? And it's much more efficient to run it that way. So we combine both of these to create mommy. And what that means is we're doing a mixture of experts, but not on this big frozen extra brain cells we're putting on top.
And we do it in a way that is many, many different experts. So millions and millions of experts. And you select the right sub team to answer a particular question. For those familiar with retrieval, with RAG and information retrieval, you'll probably recognize that this is almost equivalent to retrieving the right type of experts and learning that retriever process.
And that's exactly what we're doing here. We're trying to learn near perfect retrieval for the facts that you care about when given a query. And why this is important, all of this accuracy piece for agentic systems in particular today, is that agentic systems are leveraging many, many different agents, right?
So this is a standard kind of agentic system, a unified agent perhaps that orchestrates multiple agents here. And if you need it to be reliable, reliable across facts, it enables this whole agentic system to not have errors compound. Right, so one of the big problems with hitting many agents or many models is that over time as you hit each one, you're gonna have errors.
And so the more reliable you can make each step, the fewer errors you will have at the end when you return a response to the user. But for those of you who have been building out some of these systems and have been perhaps fine tuning or post training these models, you'll probably say, okay, it's not just about the algorithm, that's really cool.
But it's also about all the stuff you have to prepare before the algorithm to make the algorithm effective. And that is completely true. And so some of those other ingredients include that data. So you need your data to be in the right place.
And especially for mommy, you have to understand that this algorithm is super, super good at embedding facts. So good that if you let it embed the wrong facts, it will embed the wrong facts and think of those as the truth. The second thing is around evaluation.
I think this usually gets kind of thrown off to the side. But evaluation is really critical, because you're going to be running many experiments with these models. And you need to understand whether experiment A is actually better than experiment B. And then the last thing is having fast iteration cycles.
I find that this is one of the most challenging things for software development teams, because they're not usually as accustomed to doing things in a very iterative fashion. They expect an API to just work deterministically immediately, whereas these models are probabilistic. And so you need to experiment with each iteration and be able to respond and react to the errors that the model is producing.
So I would say it's these three things. And I'm gonna focus on the first one, because I'm really interested in how we can actually get the data in the right place to start with. Because I think that is a huge blocking piece to using any algorithm that can improve the model's ability to recall facts.
And so, here's what we actually use agents internally. We call it our agentic data pipeline to make that data, right, synthetically based on the data you already have. And maybe the data you already have is just SQL query logs. For example, if we're gonna go with the SQL example, SQL query logs and just your schema. And that's it.
That's probably not in the best format for the model to consume and to learn from, especially the facts of that schema. So what do we do here? So you can start with a few examples. And you can use an agentic pipeline of generators and validators.
So you can generate a ton of data, and then you can validate it so it's high quality, only the high quality data remains. And then you can pass that on as a data set for rag or fine tuning, or the mommy tuning. And you can combine that with deterministic validation.
I think this is actually in a lot of areas where deterministic validation is available. It's really, really attractive for these models because you can quickly sift through what data is valid or not. For example, in SQL, there's valid SQL queries and there are invalid SQL queries.
And to be able to quickly sift through that is extremely helpful. Something I'm really excited about is not just this pipeline. Yes, you can build this pipeline out as a developer. And you can build it out somewhat manually. But I think there's actually a future where a model will build this out.
An agent will build this out for you. So you can give what we call vibes based feedback. Or I'm sure you've heard of vibe tuning. Sorry, vibe coding. But this effectively would lead us to vibe tuning of a model. So you can give, hey, this doesn't look right because of x, z.
This revenue number doesn't look right based on what I asked you. And then it's able to adapt its own data, its own training data, to modify the weights of the model itself. And then be able to give you an improved model. So I'm really excited about that future, because that will make this process significantly easier.
Cool. So I just wanted to share another use case, and conclude on another use case here. This is a large biotech company. I'm really excited about this use case, because it not only helps them make money, but hopefully does some good for the world as well around cancer research.
But essentially, they're getting the model to predict new drug combinations, right? For treating cancer, different types of cancer. And they need really high prediction accuracy interpretability. And they need the model to understand a lot of information that is both private, PII data, and also public data.
So they're combining that and putting that into the model. And they were able to reach really high accuracy. And one thing I think is really exciting is their scientists literally say, oh, this is better than a scientist that we have here. And I think the exciting value is that this would be able to pull in, accelerate their cancer research, specifically of that area, by three to five years.
All right, and with that, how do you get started with mommy? If you're a developer, then feel free to take this free class we did in collaboration with Meta and with Andrew Ng. And it's just a very easy one to two hour kind of class, depending on what x speed you wanna listen to me to.
And you can step through a notebook that exactly goes through this mommy tuning process. And you can adapt the code for it for free. Cool? Alright. Thank you guys.
