Jack Morris: Stuffing Context is not Memory, Updating Weights is

Let's talk about ChatGPT. I think, like, ChatGPT knows a lot of things. It's actually extremely impressive. I use it all the time. I use it to help prepare for the presentation. I used it to cook last night. I'm, uh, you know, very— like, growing increasingly dependent.

And yet there's a lot that ChatGPT doesn't know. Like, um, it didn't know why my speaker pass wasn't working when I was trying to get into the building, and it— uh— if you ask it, "Did the Blue Jays win the World Series?"

the answer is no. And I know that because I watch the World Series. But ChatGPT doesn't know that if you don't enable web search, because it has something called a knowledge cutoff. So all the training data is kind of segmented by date, and things after a certain date are not known by ChatGPT, like, unilaterally.

Uh, if you ask ChatGPT, "Help me optimize this kernel I wrote for AMD GPUs," it's so bad at it. And I think there's a few reasons for this. One, it's really hard. Two, uh, there's not a lot of data for it.

But three, I think it's more that the data that does exist is such a small portion of its training data that it just, like, can't do it very well. And so a lot of tasks like this, which I— I would guess a lot of you face in your jobs, like, the things that are more niche, or what you might call long-tail, are really hard for ChatGPT to do.

Even if you say, "Please," like, "Please," or, like, "I want you to learn more about this," or, "Practice." Like, it can't learn more about this. It can't practice. It— it doesn't know, uh, what to do when you ask it that.

And, uh, yeah, if you ask, "What are the terms of our partnership agreement for BlackRock?" it doesn't know about your company. "Which of these shirts should I order from Amazon?" "Implement a new feature, uh, in our company monorepo."

"Write an email in my style." "Diagnose this patient given their history." "What arguments did the opposing counsel use in the Martinas settlement negotiations?" Uh, "Is this question already answered on our company internal wiki?" Like, none of these things are possibly answered by ChatGPT because they're not in the training data, or they're too niche, or they require some data that's not available to it.

So I think, like, the question I want to talk about today is, like, what's theright way to solve this problem? Like, if we want to build new systems that actually know the things we want them to know, uh, how— how should we build them?

And I think, like, the way I want to think about it is, like, how do we take some knowledge and inject it into the parameters of the model? Like, what's theright way to do this? And, like, the way that I think about it, and I think the way this manifests in my research and other people's research is there's three ways.

There's full context. You can take as much stuff as you can and cram it into the language model. There's RAG, or Retrieval Augmented Generation, where you have so many things that you can't fit them all in, and so you retrieve the most useful ones and then feed them in.

And then there's this third thing, which I think is, like, really new and no one is doing it yet, which is training things into weights. And I want to— what I mostly want to talk about today is, like, why I think we should be training things into weights.

But I'm going to start with the other two. And also, I guess, like, along the way, about 10% of the time I'm going to be shilling my own research, but I'm going to, like, try to be honest about it.

And you can just tune me out if you want. So I think, like, the easiest way to solve these problems is to put everything into context. Like, if you work at a small company, or, um, all you care about is, like, maybe the 100 World Series that have occurred, you can kind of copy all the data and paste it into ChatGPT, or paste it into Grok, or whatever model you use, and that's finite enough that the model can understand.

And this, like, works— works pretty well. I think that this is something that got people really excited for a while a few years ago. I have this example of, like, a doctor answering a question from a medical record.

A medical record is small enough that it can presumably be, like, inputted into the context of the model, and the model can do pretty well. I think there's a few problems with this. Maybe the main one is just that it's so expensive.

Like, if you do anything like this in your day-to-day workflow, you put, like, a ton of tokens into context and start generating, I mean, one, it's going to cost a lot of money, like, US dollars. But two, it's just so slow.

Like, um, you know, a few months ago I was writing my thesis, and I wrote it myself, but I did ask for some feedback a few times from Claude. And, like, the second you paste in, I— I don't know, it's like maybe 80 pages of text or something.

Like, as documents go, it's medium length. I paste it into Claude. The second you paste it into Claude, everything slows down by 10x or something. I have this set here that if you have 1,000 tokens of context, we can output 10,000 tokens per second.

If you have 128k per con— 128k tokens of context, we can output 130 tokens per second. So that's, like, several orders of magnitude slowed down, and I think we've all faced this. So it's very annoying, and it's hard to imagine how we can get around this.

Um, I'll give you, like, the quick background from the research world, which maybe people know, which is this inherent limitation in the models we use. The models we use are Transformers. Transformers look like this. The real problem with Transformers comes in this one little, uh, boxright here called self-attention.

The problem is that all of the words that go into the Transformer need to look at each other. And this has a quadratic dependency. So if there's four words, four tokens, maybe the matrix has 16 entries. If there are 12 tokens, there are 144 entries.

And we can manage this for a while, but at some point it becomes infeasible. Like, especially from a memory perspective, we can't—

Can you hold the mic?

From a memory perspective, we can't keep all these things in context. You might say, "Well, Jack, Grok 4 has 2 million token context window." Yeah, 2 million token context window. It's a— it's a very large number. Gemini 3 dropped, uh, during this conference, and Gemini 3 has 1 million token context window.

You also might ask, "Why did Gemini 3 not do a larger context window, even though it came after Grok?" And I think the reason is because there's a difference between the model not breaking when you put in that many tokens and the model actually, like, properly reasoning across many large chunks of tokens.

And I think the second part we're still figuring out. I think people haven't realized how to train models that don't break with more and more tokens. But we haven't really gotten to the point where we can train models that truly work as well on a million tokens as they do on 1,000 tokens.

And if you're more curious about this, there's this really good report from Chroma called "Context Rot", um, about how performance degrades when you add just, like, other stuff into the context. So this graph shows, like, the larger the context grows, even with the same finite amount of relevant information, the LLMs get worse and worse.

And I think, like, two things to observe here that I think are interesting. One, Claude is the best by far. I like graphs like this because I feel like if you talk to people, a lot of people think Claude is the best.

But if you measure on a lot of standard benchmarks, it actually is worse. But then you use it and you're like, "Oh, something's better here." So I like this because it captures what people actually say to me. But I also like it because, uh, once you get here, the performance is horrible.

So, like, if they— if they enter a bunch of relevant stuff that doesn't actually help you solve the problem, once you get to 10 to the 4 tokens, which is 10,000, like, the models don't work at all. And even though they're not breaking, like, they're outputting things that make sense and are grammatical, they're not actually solving the problem.

So Context Rot is a huge issue. Um, maybe, like, just anecdotally, if you look up, there's a ton of people saying stuff like this, like, "Oh, what? The context window is so long. Why does it not actually work?"

Or people think Claude code, when it fills up the context window, sort of, like, stops working. Um, there's a ton of people working on these efficient architectures that you might hear about, like, uh, Mamba, state-space models, linear attention, uh, hybrid attention, sparse attention, sliding window.

They're all more efficient, but they basically have the same properties of Transformers. Like, even if they can operate, uh, in a faster time or with a lower memory requirement, there's some trade-off in the terms of performance they give you.

So even if you build a linear attention model that can fit infinite context, it's not good. Like, it's not going to be able to solve the problem you have, which is, how do I actually, like, reason and get smarter when I input more tokens into the model?

There's so many examples of this. I saw this recent post. If you're, like, kind of deep in the model architecture world, maybe you've seen this. This was, like, a couple weeks ago. There's a new Chinese model, Minimax M2, that's one of the state-of-the-art open models.

And a bunch of the other Chinese labs have been pushing these new hybrid architectures that are, like, more efficient and can take longer context. And Minimax M2 just didn't do that. They just used sort of, like, the regular quadratic attention that I was showing you, and they have this really long story about how they tried and tried, and it's basically just not worth it.

There's, like, an inherent trade-off in how much computation you use and— and how good the models are. And so even if you can technically build a model that doesn't break at millions of tokens, it's not actually better for any of the tasks they care about.

So no one is really doing this. And I think, to conclude, we think that, like, we're pretty limited by the context window and full context. There's, like, one systems problem that you can't put millions of tokens into the model, and then there's another reasoning problem that even if you can, the models don't actually get better.

So it's probably not practical. And I think if— if you work in industry, I'm sure you see document sets that are much, much larger, like, on the order of, I don't know, billions to trillions of tokens. And even though we're getting better at training the models and the systems side, we're getting much better at running them more efficiently, faster, cheaper, we're not near fitting trillions of tokens into a model.

I think, like, that's pretty far off. So I would guess a lot of you are doing RAG. How many people in this room use or work on a RAG system on, like, a weekly basis? That's actually pretty crazy.

Okay. So over half, for sure. So now we're going to talk about RAG. I'm going to talk about why it's good, and then I'll talk about why I think, um, it's fundamentally limited and the products of the future will use something better than RAG.

So if you use RAG, you probably use a vector database. There are many vector databases. I think I know some of these. Turbo Buffer, Weaviate, now they're on S3. That's Chroma. I made the slide. Uh, Mongo. Uh, there— there are many vector databases.

They all offer you, like, slightly different trade-offs. They give you your vectors for cheaper, faster. Um, vector databases are the way that memory works in production. If you're using a company internal question-answering system, it's— it's definitely running on RAG, which is powered by a vector database, which stores embeddings.

ChatGPT memory, uh, uses embeddings. Uh, Andrej Karpathy has this diagram from last year, two years ago actually, of what the an operating system that runs on language models would look like. And he called embeddings the file system of LLMs.

Um, I think that's true in today's terms. Like, today, November 22nd, 2025, probably, like, if you think of what you're working on as an operating system, the file system is embeddings. But I think embeddings are the file system of today, and they're not the file system of the future.

And that's what I'm going to talk about today. I— I also want to point out that they're extremely easy to use. Like, any of the tools I'm going to talk about at the end of the talk that are, like, related to training things into models are just fundamentally hard.

But this is just really nice, and we can all take a moment to appreciate it. You just sort of bake your text, and then you, like, run this, and— and that's all. It's like five lines of code. That's— that's really, really good.

Um, the problem is they just aren't that good. And they have a lot of problems, I think. Um, which I think also, okay, how many people work on RAG or experience a RAG system and are satisfied completely with, like, what you get?

Okay. That's great. So I think we're all kind of in agreement here that maybe there— there could be something more. Like, even if we don't know exactly what it is, there must be something else out there. Um, I'll talk about a few problems that I've run into in my own research.

So let's, like, start with this abstraction. So this is the vector database that powers RAG. Every dot here is— is supposed to be a document. So the document goes through the LLM. The LLM is trained to give you just this one vector that represents the document.

I projected them down to two dimensions for the slide, but each doc— document is one dot. Um, if you actually look at what's in the vector database, it looks like this. So there are lots of numbers. There's no one on the— in the world who can tell— tell you what this means.

Um, one thing that I think is interesting is that even though they look random and no one can actually read them, if you build a system to read them, it works pretty well. So, like, if you're working on RAG and you're sending someone embeddings, you're actually sending them something analogous to text.

And I think this is important because a lot of the actual architectures, like Turbo Buffer, Pinecone, what have you, they store only embeddings. And so, like, maybe there's this false premise that if you just send them embeddings, there's no security flaws.

But actually, uh, even a slightly motivated person can build this system here, this white arrow on theright, which takes the embedding and produces maybe not the exact same text, but something extremely close to it. This is what I worked on for, like, about a year of my PhD.

This is an animation of, like, so I type in this sentence, it goes into the embedding model, it gets stored in a vector database, and then we run this. It's like a multi-round correction thing. And then by the end, we actually can get most.

I think our research has, at a certain length, we can get 90% of text back exactly from vector databases. So the takeaway here is that there's no, uh, security benefits to using a vector database. And also, they're very hard to run at scale.

So this is, like, an inherent problem for people with sensitive data. That's the paper. Um, I think a second problem that I personally have with embeddings is that they're not adaptive. Like, there's this one universal sense of what the world looks like that's captured in these vectors, and it's not adjustable based on what you work on.

So, like, to give you a concrete example, we embedded a bunch of databases, or we created a database of a bunch of embeddings of credit card-related documents. I think we had half of them that were from Mastercard and half of them that were from Visa.

But if you actually look at where the embeddings get stored, um, I guess it's not in this picture, but it's, like, onlyright here. So even though there's this, like, really large space of kind of all possible semantics, embeddings only represent, like, one universal one, if that makes sense.

So credit cards are actually clustered in this, like, really small area, and this means search works bad. So, like, to give you a concrete example, if you take these two documents, one's from Visa, one's from Mastercard, at least in the system we were designing, like, if you search something that's about a Visa query, you should never receive Mastercard.

But they're all so close to each other that they're actually, like, completely all jumbled together. And this is just, like, a problem with all conventional embedding mechanisms. So we built this new model that lets you feed in some, like, surrounding documents.

So, like, to give you an example, this is kind of the first half of our model. We would feed in a bunch of credit cards. I guess I put Amex, but there actually was no Amex when we did it.

And, um, and the model kind of works like this. Like, when it produces the embedding for the text, which is here, it also looks at a bunch of surrounding documents. So it can kind of know, like, okay, this text is about Visa, but also all the other documents are about either Visa or Mastercard.

And it gets trained so that it can, like, dynamically adjust the embeddings based on, like, the surrounding context. So I thought this was cool. And it works better. So, like, in this Visa/Mastercard case, the similarity between a Visa and Mastercard is now 0.144.

And I think anything containing Visa has a much higher similarity. So that's, like, maybe correcting one small thing. Um, it works better on, like, out-of-domain stuff. So we have a— I forgot what the climate dataset is. A dataset of arguments, a dataset of financial questions, and then I think, like, scientific articles.

And I guess the point I'm making here is that if you do this contextual thing, embeddings work a bit better. So, like, if you build them in a way that they can dynamically adapt to the domain, they can solve some problems.

But I think at the end of the day, they're still embeddings. And so you're—

I was working on one.

Yeah, yeah.

Uh, was this approach picked up by anyone else? Do you know if they know of it?

Yeah. I think we know they're using it at OpenAI and Anthropic, like, behind the scenes. Now the embedding models are contextual. It's a pretty— it's kind of a free launch. Like, you add these extra tokens. Uh, I guess it's— it's kind of hard to build.

Like, you have to build this two-stage model, and then, uh, when you embed something, you have to grab some embeddings from the surrounding documents. But once you build it, it just works, you know, better on, like, especially on long-tail stuff.

I think if you look at, um, like, MSMARCO, which is this large web-scale embedding task, it— it really doesn't get much better when you add surrounding stuff because, like, it's already pretty global, if that makes sense. But if you look at, like, really niche things, the embeddings work a lot better.

So yeah, I— I know it's productionized at some other companies. Um, I think if you're actually building an embedding model at your company and you want to put effort into making it better, this is probably, like, the easiest way besides data.

Probably the first way is data. Um, there's some recent work that I think is worth mentioning about, like, fundamental limitations of embeddings and vector databases and RAG, which says that, like, if you— it's not even really worth explaining, but there's, like, some, uh, there— there's some relationships that cannot be captured in a fixed-dimensional vector.

Like, you have to reason about things to answer all possible tasks. And this is this kind of combinatorial setup where there are so many possible relationships that the embeddings simply can't store them. And so, like, in theory, embeddings are obviously not the best way to do all possible relationships between text.

But I think everyone knows that RAG has issues. Like, I'm glad that no one raised their hand when I asked if anyone was going to, like, really stand up and speak for RAG. And, like, we can— I— I actually think this is a hard point to make.

Like, everyone kind of knows this, but it's hard to come up with examples that Retrieval can't solve in practice. Like, speaking as someone who's recently sat down and tried to make benchmarks for tasks that I care about, it's hard to express questions that require kind of this, like, latent reasoning over multiple documents in a way that RAG doesn't solve.

But they do appear. Like, um, anything that kind of requires association between multiple things or questions that are— they're, like, sort of implied but not explicitly answered by the documents are just not solvable by current techniques. And also, if you have interesting examples of this, would love to hear after this— after the presentation.

Um, hopefully I've made my case that I think RAG— oh, yeah, yeah, go ahead.

I'm curious if you would classify agentic search as RAG as well?

Yes.

That's a good question. So I guess the way I think of agentic search, it's like a model that can grab and it makes a bunch of queries in a row and then it responds.

Um, yeah, that's— that's a really good question. I think— I think I wouldn't classify it as RAG, but I think it has different fundamental limitations that are also tough to overcome. Like, what you— what you would really want is, like, a model that reads the entire thing and reasons about every possible relationship and then answers.

And I think in theory, maybe you could build an agentic RAG system that does that, but it would be very expensive.

Because isn't that— isn't that— isn't deep research in the direction of that where it, like, goes through and it pulls, like, hundreds of thousands of sources, but then what ends up in context is only, like, a small subset of those?

Yeah. Yeah. I actually think deep research is, like, really in theright direction. Like, they're trying to do something that's a little bit higher level and requires a lot of compute. Like, I think, um, anything that works better than RAG is going to be more expensive.

And so, like, just the property that it takes a while and it makes a lot of searches and it thinks a lot is, like, good. I think that there's probably a more elegant way to train, like, a really big kind of deep research-ask system.

But I think that's— that's actually, like, a good way of doing this and— and not the one that I'm talking about today, but it's very promising as well. Like, maybe the question is, like, are you willing to spend a lot of money at training time or at inference time?

And deep research is, like, kind of they don't spend a lot of money to train it, but it's willing to wait for a long time at inference. And I think the things I'm going to talk about today are more like, if you're willing to spend a lot of money upfront and you get a really smart model that knows all your data already, um, and it's really cheap to do inference.

So it's, like, kind of different sides of the same trade-off. And I think, like, a good way of thinking about these things is, like, to get better models, you're going to need to pay somewhere, you know? Like, you're either going to need to, like, generate better data and spend more time on the data, you're going to need to spend time on training, or you're going to need to spend time on inference.

And the nice thing about RAG is it kind of just works, but anything better will cost more. Yeah.

Allright. Getting back to your example of Mastercard versus Visa.

Yeah, sure.

I— I don't know if that's in your presentation later, but what are your thoughts on using Knowledge Graph for that? It's kind of augmenting.

That's a good question. Maybe ask me after. I have to think about Knowledge Graphs. It's been a while. Um, so let's talk about how to learn things in weights. Um, I think, like, the question that we want to get at is, like, okay, so say we have the example I showed earlier, or, like, you have a small dataset you've collected from your own personal work and you want to teach it to the model.

It's one thing to put it into context, and that's a good way to get started in. If you don't have that much data, that'll get you pretty far. But I think we can do more. Like, there's some questions that even when your data is in context, the model can't answer.

And so what I want us to think about is, like, how can we inject things into a model, uh, is such that it learns better than in context and also that it doesn't forget everything that it already knows.

Um, I want to point out something from my own research, which is that there is a fixed capacity to language models. Like, one way to think about this is ChatGPT has, like, only so many parameters. We have this measurement that it can store 3.6 bits per parameter.

So, like, uh, I think a billion-parameter model is, like, at 3.6 bits is maybe, like, 4 terabytes. Is thatright? 4 gigabytes?

Yeah.

What a— yeah. Thank you. Thank you. Um, this is, like, some information, but it's actually not that much. So the models, they basically do their best to fit the training distribution and they throw everything else out. So, like, to give you a concrete example, this morning I was putting this together.

I asked Claude, "What is the capital of the smallest province in Tajikistan?" And it gave me a very detailed answer. It was actually very impressive. No web search. The model just knows this in its parameters. I guess I'm arguing that this is bad.

Like, if you want to build a system that can answer really detailed documentation questions for your company, you don't need it to know what the capital of the smallest province in Tajikistan is. And since we know these models have fixed capacity, I think that this is bad.

Like, what we really want is to know how to, like, find this kind of thing and just, like, delete it and replace it with the things we care about. And I think that's, like, what we're getting towards, but we don't 100% know how to do that again.

I'm sorry. So when I originally put this talk together, the way I was thinking of explaining it is calling it a neural file system. And then I decided to just call it weights. I think it's easier to understand, but this slide still says neural file systems.

Um, so I think there's a few questions here. Like, we want to train all our data into the model. One question is, like, how do we train it? Do we do RL? Do we do SFT? Uh, what's— what even is the data?

Um, another question is, like, out of, uh, all the possible data, what do we use? Do we just, like, fine-tune directly on our data? Do we try to generate more? I think my argument is that we should try to generate more, and I'll show you why.

And then there's an architectural question. Like, I think for a long time, people really cared in the machine learning, deep learning community about, like, what architectures we should use. And then for, like, what, eight years, everyone who knows what they're doing has really just been using transformers unless they're trying to make them better.

And I think now, in this world where we're trying to train stuff into models, like, like, if you think of, okay, a world, we all— each of us have— has our own model or maybe multiple models, and those models are getting updated a lot, I think we start to care about architecture again.

And I'll— and I'll tell you why and, like, what I think the options are. So first, let's talk about learning. Um, so I think, like, the mental model here, which I mentioned before, is, like, we're trying to train the model to learn the data as best as it possibly can, and it's going to be expensive.

So, like, we didn't like RAG, but also RAG didn't cost us very much money. I think to do better than RAG, we're going to have to, like, pay some GPU points. And that's just, like, the state of the world.

Okay. Fine. So this is our model. It's like this homogeneous blob of data. And this is our data. So, like, maybe we have the Mastercard dataset, or maybe we collected data about ourselves, or maybe I, uh, collected all my traces from coding in November and December, and I want to, like, train the— the model to learn my problems better.

What do I do? How do I actually do this? Um, let's— let's, like, start with the dumbest possible approach and just, like, see what happens. So say, uh, we start with a dataset and we just train on it, um, like, using, I guess, next token prediction.

So we actually ran this little experiment. This is, like, uh, 3M. It's a company. They make duck things. And, um, this is, like, some financial reports. So maybe, like, you're working there and you really don't want to read all of this, so you just want to ask the model to, like, really understand this and be able to answer questions.

And, like, RAG isn't really working because it's, like, this weird structure and there's a lot of ways the documents interrelate. Okay. Cool. So we're just going to, like, train the model using next token prediction, see what happens. You know what?

Actually, even if you don't train the whole model, um, you— you still get zero loss. So the model can perfectly memorize this entire, uh, 3M 10K financial report. Um, it's extremely impressive. Okay. So now let's talk to it.

So— so we did this, and then we didn't want to ask anything that's, like, exactly present in the document because we want to see if the model's actually good. So we started, you know, like, everyone loves to test poems.

So we started with a poem. We said, "Can you write a poem about 3M in fiscal year 2025?" So register your bets. And what do you think happened?

It's terrible.

It's terrible. Someone said it. It says, "The passage of a passage is a poem." End of sentence. It's crazy. Yeah. So now maybe we ask, like, why does this happen and— and how do we fix it? So unfortunately, this doesn't work.

And I actually think this is, like, one of the reasons why people haven't been doing this yet is because the dumbest possible approach usually does work in machine learning. But in this case, we have to do something a little bit more sophisticated.

Um, so maybe take a second and think about, like, what you would do if you're facing this problem at work or in a side project. Um, I think there's, like, two things we need to fix. One is that, um, the data is not— it's not exactly what we want to train on, I think.

And two is that we probably don't want to update the entire model because what we did there was basically overwrite all the, you know, stuff about Tajikistan and everything else that's in the model with just, like, this 3M knowledge.

And I think that's, like, too specific, and then the model is just obsessed with 3M and it'll only produce exact copy sentences from the document. That's— that's clearly too much. So I think we need a better way to update the model, and we need a better way to change the data.

Um, there's this pretty relevant work. I don't know if you follow this, like, LLM chat thing from Andrej Karpathy. Shout out. I think it's very educational. And he had a really good question, which is, like, he built this small LLM and trained it from scratch and everything, and then he wanted to teach it about himself.

And, okay, maybe the first thing you would try is RAG. You put, like, a little database of information about yourself, but that's only scalable to a certain amount, and then the model can't really, like, combine things. It can only kind of regurgitate facts.

And so he wants to actually teach it properly, he says, meaning in weights. And so notice he doesn't just, like, take one example and— and train the model using next token prediction. He does something a bit more complicated.

He, like, generates this task. Or you— you don't have to care about the specifics, but there's, like, basically he makes a diverse training dataset of examples that look like the thing he cares about and then trains on it.

And if you go, you can find this. It actually does work pretty well, which is cool. So he's able to teach a novel behavior to a model by, like, generating a lot of synthetic data that looks like the example he cares about and then fine-tuning the model for a little bit, and it— and it learns.

There's a paper that's really good, uh, that's from last year from some folks at Stanford called Synthetic Continued Pretraining. And they have the same problem. So they have, like, a really small dataset, and they want to teach the model to the dataset without, like, breaking the model, essentially.

And they have this kind of fancy way of generating synthetic data by extracting entities. But I think the important part is that they take a small dataset and they generate, like, a very large, more diverse dataset representative of the thing that they care about.

And this is something that, like, breaks the whole, like, conventional machine learning paradigm. Like, they only have a small training dataset. So, uh, what you learn in school would tell you that you would just, like, overfit and there's nothing you can do.

You just have to go back and collect more data. But actually, because LLMs are so good now, we can do this second thing where we generate, like, a much larger training dataset. It really contains only the, like, facts that were present in the original data, but it's so large that you can train a model on it.

It's, like, very strange. It only recently started working, but it does work. I'll show you some evidence. Um, the green line is what happens when you do the dumb thing we described before. So you just, like, fine-tune the model on the data.

It actually starts at the black line. So surprisingly, it actually gets worse. So it, like, memorizes the data so well that it can't answer any slightly different questions about it. Um, the thing they do, they have, like, two different ways of doing it, but it's basically, like, generating lots of synthetic data that describes the things in the original dataset.

It works very well. Like, at some scale, I guess 100 million tokens, close to a billion, they can actually outperform GPT-4 on this dataset, which is really cool. So I think, like, the takeaway here is even though you don't have a lot of data, if you're willing to generate, like, a large synthetic dataset that describes the data you have, you can actually train a model on it, and it works really well.

There's a bunch of other papers that do this. One is called Active Reading. Um, they basically ask the LLM what types of things should we generate, and then they generate from it. There's Self-Study, which is from this Cartridges paper, which is more, like, question answering, like, asking the model to, like, quiz itself.

And then there's this Rephrasing the Web thing. I didn't realize my whatever. Rephrasing the Web thing where they kind of, like, rephrase an entire pretraining dataset. So this actually works at scale in kind of a surprising way. Um, and there's a lot more work in this direction.

So I'm really excited about this, like, and I'm kind of monitoring it. There's a company called Datology that's doing this really well. They're, like, generating really high-quality synthetic data. It's just, like, not something that used to be possible until very recently when LLMs crossed some threshold that they're, like, able to generate data that's good enough to actually train themselves on.

Oh, there's actually something pretty cool. It's not in the slides. It's called Self-Adapting Language Models. Self-Edit. It's called SEAL. S-E-A-L. And they, uh, ask the model what data to generate to make itself better. And under some, like, constrained scenarios, this is actually working.

So that's, like, actually quite bizarre. Um, and, like, obviously it doesn't work infinitely or else they would have caused an intelligence explosion. But the fact that it works at all is, like, really remarkable and I think, like, worth monitoring.

So in conclusion for this section, we want to train things into weights. We can generate large synthetic datasets that describe very pretty small datasets, and it works fine. Um, now I think the money question here is, like, how do we inject the information into the model?

I think before I mentioned we were training all the parameters and we tried it and it worked really bad. And this is a— a problem that's been around for a long time. It's called, like, catastrophic forgetting. Um, even in old-school machine learning, like, you train a model to recognize handwritten digits, and then you train a model to recognize house numbers, and it's no longer able to recognize handwritten digits.

This is, like, a very well-known problem. There's a lot of, like, theory and, like, approaches proposed to solve it, but no one really knows how to solve it. It's very, very hard. Um, but I think there are some easy ways we can get around it in the conventional paradigm where we have, like, this big pretrained ChatGPT transformer.

Uh, instead of retraining the entire model, there's a few different ways we can do it. I mean, the first one is retraining the entire model. So the things we're training, I'm highlighting in blue here. That's, like, if we take our transformer and we update all the parameters, we're probably going to forget stuff.

Um, there's another one that's pretty cool called prefix tuning where you just train the KV cache. Um, I mean, we all, like, skip the details for now, but ask me if you have questions. Prefix tuning is cool. Um, another way is since a lot of these models are called, like, mixer experts and they have this MLP layer in them, you can add another part to the MLP that is optionally routed to and used.

And that's, like, pretty scalable. I think people try this. Um, there's another approach where you replace instead of, like, another MLP, you build this thing called a memory layer, which is like a big lookup table. I think memory layers are really good.

And let me pause and say now this part of the talk is getting close to purely speculative. This is, like, the things that are, like, they exist and, like, someone's going to do this and someone's going to use, like, one of them, but I really don't know what theright answer is.

Um, another one is called LoRA. So low-rank adaptation. You've probably heard of this. Very, like, hot topic. Um, they kind of, like, train a small— a small matrix or a small few matrices to adapt the linear layer. So it's like if your model's 10 billion parameters, maybe you train 10 million parameters that can, like, control it.

Um, and if we look at them together, maybe it's not super obvious which thing would work best. Like, ICL is just, like, putting stuff in context. So we have in-context RAG, full fine-tuning. We could do the memory layers and MLP cartridges, which is prefix tuning, and we could do LoRA.

We could also do add something to the mixture of experts. I think to me it's not, like, clear, and I'm not positive that it matters which one we do. Like, I think the main thing is, like, we have this giant model and we're adding a tiny bit to it to control it and train only those parameters.

That way we retain most of the information in the model. I think that's, like, the most important part. But I think for the end of this talk, I'll just talk through, like, what I think people are doing in this space up to, like, the minute, and then you can make up your own mind what you think theright way to do it is.

So let's talk for a second about what properties we want. I think we want, um, we want our changes to the model to be very small. Like, say you're serving a model to each person, you actually can do it, but you have to use one of these, like, parameter-efficient methods.

If you're trying to fine-tune a new KIMI for each person, KIMI is, like, a terabyte. It's a trillion parameters. It's just, like, not even storable, let alone servable. Um, we want something that's resistant to forgetting, like we said.

So it would be nice to have an architectural change that's both small and makes the minimal impact on the model as it is now, because the model as it is now works really well. Um, and preferably high capacity.

I think, like, changes that are really expressive and can capture a lot of facts in few parameters are the ones that we prefer. And we want to be able to do inference quickly. As, like, a small aside, you actually can do this quickly with a lot of, um, a lot of these methods.

Like, maybe some of you have seen Tinker, this new training API from Thinking Machines. It's basically all predicated on this idea that you can— you can serve one model per person as long as you do LoRA and batch the LoRAs.

And there's, like, it's actually most interesting from a systems perspective. There's, like, ways you can train it and train each one separately, and there's ways you can do inference, and it basically has no cost. Um, which is really interesting just because, like, the base model doesn't change and we all share the same base model.

So all the ideas I'm going to talk about are kind of, like, in the same direction as Tinker. Um, we can think about, like, whether certain methods might learn more or forget more. Um, so this is comparing LoRA to full fine-tuning.

So LoRA makes a tiny change to the model. Full fine-tuning updates the entire model. And on two different settings, they show, like, LoRA here is, like, purple-ish or pink. The pink one's a little bit smaller capacity. Um, it basically doesn't do as well, at least when you're doing SFT.

Uh, LoRA can learn a little bit less, but also if we look at how much it's degrading, it forgets less. So this paper is called Learn. LoRA learns less and forgets less. And it's— it's actually a very nice finding.

So, like, if you want to at least teach a model via SFT and you use one of these low-rank or parameter-efficient methods, like all the ones I described, they're going to make a small change to the model in a way that it's probably not going to be as expressive as full fine-tuning, but it also doesn't destroy a lot of the knowledge.

Um, here's something going the exact opposite direction. This is the result from Thinking Machines showing that they think LoRA is about as good as full fine-tuning, which is interesting because they're doing RL. So it's, like, maybe dependent on the training mechanism.

Like, if you do RL, maybe it makes small updates and, um, you can do LoRA, you can do memory layers. But for SFT, it really has to store a lot of information, so you really have to do full fine-tuning.

I think that's the takeaway I have. And I have some— actually a paper that's, like, kind of blocked for legal reasons, but coming out soon. Um, here's one result from my paper that's relevant to this. So we have this, like, tiny LoRA thing that's even smaller than LoRA.

Well, there's actually LoRA XS, which already exists, and then we made tiny LoRA, which is even smaller. And if you're doing RL on GSM-8K math reasoning, you can train 14 parameters and get, like, 91% accuracy, which is pretty crazy.

I think, um, there's, like, a lot of reasons for this. Like, RL makes really tiny changes. I think this Quen model, like, is something fishy is going on with the training data. Do you have a one-parameter experiment? Oh, yeah.

Yeah. Just one parameter. It actually learns. It gets 5% better with one parameter. Pretty cool. It's amazing. Yeah. Yeah. It's— it's— it's really nice. I think, um, literally the smallest. Yeah. Yeah. The smallest thing you can possibly train.

It's more like you— you generate a lot of random projections and then you control them all with one number, if that makes sense. Like, the model actually changes a lot, but the only thing you can actually train and store is the one parameter.

Uh, I'll tell you more about it later. Um, but yeah, it's pretty cool. Um, this is another result that's, like, kind of in the mix, but I'm not sure how to place it. So if you do the KV cache tuning or prefix tuning, this paper thinks prefix tuning works much better than LoRA.

I met some people in Meta, um, when I used to be affiliated there, that said that they think LoRA works much better than prefix tuning. So I really don't know, but I think, like, what it really will come down to is, like, when you do it at scale, what's, like, most efficient.

And I'm not exactly sure, but I think prefix tuning is a pretty good candidate because, like, KV caches are so commonly used these days and, like, a lot of the system stuff is built around KV caches. I think a cool thing about Thinking Machines is, like, they're designing this entire organization around, like, scaling LoRA, which is awesome, but it's not really possible in open sourceright now.

Like, there's not kernels for training many LoRAs at the same time. It's, like, very complex and you have to have a lot of people working on that. Prefix tuning, on the other hand, is, like, very well supported. Um, and then finally I'll quickly talk about memory layers.

This is another approach to injecting data into models, which I think is good. This is, like, uh, adding an expert to the MLP, but the expert is just, like, this giant differentiable lookup table. So it's kind of not that important exactly how it works, but it's, like, it's just a different way to inject information into models.

The cool thing about memory layers is it's controllable. So in this work, uh, by Jesse Lin from this year, they specify exactly which parts of the memory layer get updated and keep it to, like, a very small number.

And so their result shows that memory layers actually work the best. So memory— the axes here are forgetting, so down is bad, and learning,right is good. So the memory layers basically don't forget at all and they learn close to as much.

So I think if you're trying to inject information into models and you really care about them not forgetting any of their base information, maybe memory layers are the way to go. I think honestly there's a lot of conflicting evidenceright now.

Like, some people think LoRA is good. Some people think prefix tuning is good. These people think memory layers is good. I really am not sure, but I think it's going to be one of them. Okay. Cool. That's— that's the end of the training stuff into weights part.

Maybe actually I'll stop and see if anyone has any questions about the different parameterizations. Yeah. Can you go back to the slide where you were showing the Quen GRP? Oh, yeah. Yeah. Yeah. From— from my yet unreleased research.

So have you used SFT before? Yeah. Yeah. I can show you the SFT results later, but SFT, uh, takes a lot more parameters in the short explanation. Like, many, many more. Like, 1,000x more or something. And you attribute that to the sparsity of the reward?

Yeah. Yeah. I think it's something like that. Like, the SFT learning signal is, like, cross-entropy on all of the tokens with or without thinking tokens, and that's a lot of bits essentially. And then RL just gives you a one or a zero.

If you get itright and you already knew, then it's, uh, no information. If you get it wrong, you get, like, one bit. So I think because RL is, like, so sparse and, uh, information efficient, then you can do it with way fewer parameters.

That's— that's kind of the takeaway from our paper, actually. So you didn't do GRP or POP after doing SFT? No, no SFT. We just either do GRPO or SFT. And then we see, like, kind of how many parameters you need to train to get to equivalent performance.

And SFT requires many more parameters.

Uh, so here you are comparing, uh, like, uh, uh, training versus RAG. Like, we are doing— we want to solve the problem what we are facing in the RAG. So is the volume of the document also matter? Like, do you have any studies?

Like, uh, uh, because if— if some problem has a less number of documents, uh, RAG will be better or the, uh, training will be better? That's a really good point. Um, maybe let's, uh, go to the last slide.

So I think the question is, like, okay, if you're trying to train all of your data into a model, but something only happens once. Yeah. I mean, when— when I should, uh, focus on RAG and when I should focus on, like, uh, uh, like a training spec?

Because every time I have, like, a small set of the document, the training might not be feasible. Yes. Yes. Like, you're— like, maybe you— something is so underrepresented in your data that it probably wouldn't be your— My data is frequently changing might be.

Your data is changing a lot. Yeah. Maybe in the short term it's hard to train. Um, yeah. So let me point out, like, okay, so obviously we're always going to put stuff into context, and I think we'll also probably always do RAG.

Like, I think, um, there's basically no scenario that you can imagine for a long time where you're just, like, always training the model and never doing RAG. I think you'll do both. I think, like, maybe if you have a ton of documents, I don't know, maybe every day you do this big training, and then every time you serve, you also do RAG.

And so, like, what I really imagine is, like, or maybe my— my point is that no one is doing thisright now. Yeah. And, like, people will start doing it. Do you have any, like, a projection, like, after a certain amount of data, like, uh, training will be, like, more efficient than the RAG?

Like, when? Yeah. Yeah. Yeah. No, that's a really good question. Uh, no. Like, I think— I think this kind of thing is really new, so there's a lot of room for analysis like that. I would definitely be interested to see both analysis on how the frequency of information affects, like, the trade-off and how just, like, how much data you have to have for training to become economically feasible.

That's a really good question. Yeah. Um, is your suggestion kind of in, uh, diving more into, like, the weights side of, uh, the presentation to use a fine-tuned model for, like, completion-type tasks or also for embeddings? Oh, yeah.

That's a good question. Um, no. I think— I think the fine-tuning I'm talking about is all for, like, assistant agent completion. Um, it's an interesting question. You probably could do, like, dynamic embedding model training, but I guess, like, the way I think about it is, like, the real, like, 10x improvement here is going to come from training into weights.

You could maybe make RAG, like, 2x better if you really, really work, but I think there's so many fundamental problems with it that I wouldn't spend that much time on making embeddings better. What were— what do you feel like the most fundamental problem is where even if, like, your retrieval is fantastic, you're still kind of— I think, like, chunking.

Like, uh, yeah. You just, like, kind of retrieve some of the stuff you need and then you can't really reason across all of it. And, like, I think in the limit, like, there's some types of data where, like, no matter how you chunk, you'll never get, like, everything you need, if that makes sense.

Yeah. Totally. Cool. Yeah. Do you see any fundamental limitations as you scale up the amount of personalization you need? Let's say you had a B2C product that had 100 million or 10 million users in memory for all of those.

Do you think that's just not feasible? Uh, you say 10 million users? Yeah. 10 million, 100 million, somewhere in that range. Yeah. Um, no, no. I actually think it is— it is feasible. Like, LoRA, maybe you train a few megabytes per user or something.

It's not that crazy,right? Like, YouTube probably has gigabytes per user.

Right. That's a good point. Like, the continual updates are hard. Like, probably in realistic short term, it's more like you update once a day or something like that. But I think that's— that's doable. But you make a good point that the paradigm I'm describing is much more expensive than.

Also, do you consider there's a lot more that you can do than the other two, like, buckets. You can compress the data into context. You compress it before you put RAG and break it up into other buckets. You don't just have to use RAG.

You can use SQL and Knowledge Graph to pull them together into different buckets and that solves a lot of problems. Yeah. Yeah. That's a good point. There's kind of, like, three axes of optimization here. And I guess, like, we are— we're getting pretty good at this.

We're okay at this and we're horrible at this. And so, like, we'll continue improving upon all three axes. Yeah. What's your, uh, like, I'm kind of hearing that maybe it's not just idea, but what's your kind of, like, intuition or guess in terms of, like, where the decision boundary is in terms of investing your effort in those optimizations?

Particularly in, like, let's say a couple of years where you could do something like a deep research, but it would be way cheaper and way faster. Um, when— what are there— you were saying that there isn't, like, a number of documents, but what is the boundary that you would think about looking at as the freshness of the data, how fast changing is the number of documents, or what's your— what's your boundary?

Yeah. I— it's a really good question. I— I think, um, I think the paradigm I'm describing is especially effective when you have, like, a large amount of data that's not been indexed into the LLM at all, and it gives you a big benefit there.

I think when you start seeing, like, sparser updates to your dataset where, like, some new data comes in, but it's not that much and it's, like, fairly often, then you probably want to turn to inference-type approaches that are closer to deep research.

Um, yeah, that guy had a question while I'm— Yeah. Can you elaborate a little bit more about the synthetic data generation? So let's say that you have an LLM and you need to get it to talk, uh, similar as the language and terminology of, like, a proprietary data,right?

Like, millions of new documents. Like, how would synthetic data generation in that context be helpful? So you're coming in with millions of documents, you said, and you want the model to— It's more like a scenario. Yeah. Yeah. Okay.

Yeah. Yeah. Yeah. Um, because it wouldn't— because what you said, you know, you wouldn't just train off of the next workbooket,right? Yeah. Um, try out different approaches. And I think one of the approaches that you had talked about was, uh, synthetic data generation.

Yeah. Yeah. No, I think— I think synthetic data generation could work for that problem. So I guess, like, um, it depends on how information-dense your data is. If you have millions of documents from your company, I would guess many of them share formatting and only contribute maybe, like, a few bits of kind of global information to the dataset.

And so what you want to think about is, like, does there exist a function that could produce a good training dataset for an LLM that would teach it about my data? And, like, there probably is. Like, you could probably design some strategy that looks at the documents, kind of, like, figures out what's new about each document and creates, like, kind of question-answer pairs.

But this is very blue sky. Like, I think a lot of people are working on thisright now, but I don't have, like, a, a global answer of how to actually do it. Right now, my only solution that I can think of is, um, you know, getting to generate that Q&A pair before you just set it.

Right. And then using LoRA to train it. I mean, there's one variant where it's like a—

Yeah. Yeah. I think it also depends on what types of questions you'll be asking about the documents. Like, what you really want to model is, like, all possible questions or something like that. But I think Q&A gets you pretty far.

Cool. Yeah. Um, so with— with this approach,right, you— you mentioned this example where you're, um, uh, you would train your model,right, on 3M, uh, quarterly earnings,right, uh, I think 10K, 10Q, um, documents. What would, like, what would the prompt basically look like,right?

Like, is there— is there anything in within, like, the in-context learning that would still need to be kind of specified to

bring your data into the context? Yeah. Uh, so I think the question was if you start with the 3M example we had and you train all that into a model using something like magic synthetic data, what does actually the prompt look like?

Yeah. I think actually if you do itright, you don't need a prompt at all. Like, you can just ask the model a question. No system prompt, no extra information. And if nothing has changed, it should know everything. Like, and you even— there's some scenarios where there's only one document and the model knows which document it is.

So you don't have to specify that you're even asking a question about the document. It's, like, implied, you know? So, um, it depends on how you set it up, but I think in, like, the ideal case, there's no prompt at all.

Yeah.

I— it's not obvious to me that information is best stored in model weights. Yeah. Why do you have— do you have that? Um, it feels implied. Do you have— am Iright? That's a good question. So he said it's not obvious that information needs to be stored in weights.

Yeah. Yeah. This is— this is a good question. I think, um, I'm not saying that it's best to store information in weights. I guess I'm arguing that that gets you a lot and we're not using itright now. Yeah.

And, like, once you get to the scale of, like, a GitHub repo, you might have millions of tokens and it's just, like, very expensive. And so at least, like, this is the cheapest way to do it. The question of, like, can we generate synthetic data to do better than in-context is, like, it's— it's hard.

I think it's like that's research. Do you know what I mean when I say it's cheaper though? Like, if you have a million-token prompt, you can just, like, compress it into the weights and produce a model that gives the same outputs with no prompt.

And then the inference costs less.

So how long does this take? We can talk after. Follow-up. Yeah. I have a question. I'm going to be quick. How many instances is adversarial data being entered into? That's actually a really good question. Never thought about it before.

Um, I think it's probably pretty hard. Like, I guess if you're training on user data and, like, you have some user that wants to sabotage your system and you're generating training data from their inputs, there probably are a lot of, like, security risks.

And, uh, I guess in this scenario, if you're serving the same model to that user and it doesn't work anymore, that's, like, not your problem. But once you start aggregating information across users, I bet it becomes hard. I'm sure ChatGPT has the same problem where some people always click thumbs down instead of thumbs up to try to, like, shake it to the mirror.

In this research, uh, they segmented geographically across countries because some cultures are inclined to do across countries. Oh, wow. So it created bias in data. That's funny. Yeah. Yeah. Yeah. Um, so just thinking maybe a little bit about practical implications of something like this, um, especially in terms of, like, say version control.

Like, you mentioned GitHub models that you keep fine-tuning over time. Say you're a company that just changed a policy and it's just a one-line sentence. We honor something and we do not honor it anymore. Um, that keeps coming back before.

Do you then, you know, start from the base model again and fine-tune that or go back to the one that already has a good representation of it and just has to change that one small thing? And then, you know, how that kind of is joined at the hip with hallucinations, which is kind of why we were doing full context and RAG now partially to avoid that.

Do you have any thoughts on how that might work? Yeah. I think he— so his question was about what do you do once you start making multiple updates to the model, especially when you have, like, conflicting information. And I think, like, the optimal synthetic data strategy would somehow figure this out during training.

And maybe even, like, if there's some documents from a few days ago that are no longer relevant, you can just, like, delete them. But I don't know how to do it. That's hard. How are we going to give more attention in the same, like, whatever, uh, let's say, uh, information is conflicting with each other, uh, whatever pre-trained versus what, uh, upfront document we are giving for training.

If it is contradicting each other, but I want more reference from my document by what we are doing in RAG, like, asking the questions from the ground truth. So how, uh, it will replace that scenario? I'm not sure I understood the question.

Sorry. I— I don't know if I understood your question. Okay. So what do you— I didn't understand your question. So my question is, like, uh, we have the data, uh, whatever the training data we are giving, it is, uh, contradicting with the pre-training data.

It is a conflicting. Now, while asking the question, while the inference, I want to give more preference on my data. I don't need the pre-trained information. That's why we are using RAG. Like, I need the output from my ground truth, whatever the context I'm giving.

So how it will, uh, we can achieve in the, like, a training? I think that the, the paradigm I'm proposing has all the same limitations of RAG. Uh, I'm not positive that answers your question, but, like, for example, if, uh, like, maybe in the scenario he said where he said something many times and then turns out not to be true, both RAG would retrieve that and in the, uh, dumbest setup, that would also be present a lot in the training data.

So I think, like, the same problems have to be solved. Yeah. Have you done any work with federated, uh, fine-tuning, uh, parameter fine-tuning? So what about your war probably? Yeah. Millions of users. Have you done any research in that spot?

No, no, no. Uh, not really, but I think it's an interesting, uh, opportunity. So, like, back in the day, a lot of people were really excited about the idea that you could share gradients and train the same model across many machines.

This is federated learning. And I think, like, one of the problems why it's hard is because the models now are so big that the network costs are way too high. And because, like, I'm arguing that you only need to train a million parameters instead of a trillion, it probably comes back into play.

So I think it's a very good idea, especially in the RL world where you do a lot of work for a long time and then do gradients, like, very seldomly. So I think it probably will come back and it's smart to think of it, but it hasn't quite yet.

Um, maybe I'll take, like, two more questions. Yeah, go. Um, so your argument here about training in, um, information seems to be, uh, counter to Karpathy's view of, like, a reasoning engine, like, distilling just the pure, like, you know, intelligence aspect of the model down to, like, a 2 billion parameter thing.

Um, uh, and, like, I think that there's a bit of overlap there. Like, um, uh, like, a lawyer is not— doesn't have the entire legal code memorized, but they know how to use the tools available to them to find what they need to.

And so I— I think part of it is kind of a combination of those two things where you're doing task-specific training with something like this on a relatively small reasoning brain to get a sense of where it needs to find the things that, uh, might become stale or, or, you know.

Am I on theright track here or? Yeah. Yeah. So I think you're making comparisons between some people who said, "Oh, the best model we could ever have is, like, really small and knows nothing, but can use tools really well," or something like that.

And I guess I— I was proposing some similar ideas. I said models know way too much. I think everyone agrees the model doesn't need to know the capital of the smallest province in Tajikistan for most use cases, at least in, like, my life.

It doesn't need to remember, you know, encryption keys. Yeah. But I think there's— I think this is a very philosophical question, but, um, I think it's really hard to create a model that doesn't know anything. And so I'm more advocating for, like, specialized models that are good at something you care about, but bad at other things, rather than advocating for a model that's, like, bad at everything.

Uh, okay. Last question. Yeah. Have you ever done research yet in the temporal elements of the information? No, but I think that's, like, one of the first things to think about is, like, okay, if you have information from day one and day two and day three, do you just sort of, like, compact everything or do you train in order, kind of like you were asking, or do you, like, train multiple models and merge them?

Or I— I actually don't know, but that's a good segue. So now I'm, uh, I'm working on this. I have problems related to this a lot, thinking about this a lot. Um, started a company with a few other people and, um, this is, like, the kind of research we're doing.

If anyone knows someone who lives in San Francisco and is a good engineer and you think they're interested in this, let me know or send me an email. Or if you're interested in, like, using this kind of thing, send me an email.

That would be great. It's temporal stuff or? Not necessarily. I mean, it's kind of all of this, I would say. Um, trying to build models that you can teach things to. Tell us more. Allright. Thanks so much for having me.

This was great.