Speaker A
[music] All right. Hey everyone. Thanks for coming by over here. Hope you enjoyed the chat by part on how to measure continual learning. Now I'm here to talk about how we scale it up. So a bit of
Ronak Malde discusses scaling continual learning in AI, challenges with current methods, and introduces on-policy self-distillation for efficient real-world adaptation.
Ask about this video. Answers come from its transcript only — with the timestamp, so you can check them.
Generated from the transcript and can be wrong — check the timestamp.
Key Takeaways
- Scaling benchmarks in AI is increasingly expensive and disconnected from real-world use.
- Current RL-based continual learning methods have critical limitations in sampling, infrastructure, and reward design.
- On-policy self-distillation offers a promising solution by combining on-policy data with teacher-student learning.
- OPSD enables continual learning with less infrastructure, more realistic task distributions, and token-level feedback.
- Further research and scaling are needed to fully realize continual learning’s potential in practical AI systems.
What the video covers
- Ronak Malde shares his background and experience in AI research and continual learning.
- Current AI progress relies on scaling benchmarks that saturate quickly and are costly and time-consuming.
- There is a mismatch between benchmarks and real-world AI use cases, despite massive daily inference token usage.
- Existing continual learning algorithms face issues like task distribution mismatch, off-policy sampling, infrastructure demands, and scalar reward limitations.
- Review of historical algorithmic approaches: SFT, DPO/RLHF, and GRPO, highlighting their strengths and weaknesses.
- GRPO, the current state-of-the-art, requires heavy parallelism and uses sequence-level rewards, limiting scalability.
- Introduction of a novel continual learning algorithm: on-policy self-distillation policy optimization (OPSD).
- OPSD replaces fixed off-policy data with on-policy rollouts and uses a teacher-student model to improve learning efficiency.
- This approach addresses key problems by enabling online task distribution, on-policy sampling, minimal parallelism, and token-level dense rewards.
- Trajectory is actively scaling OPSD and exploring its potential and limitations for real-world continual learning applications.
Chapters
- 00:00Introduction and Background
- 01:36Challenges with Current Benchmarks and Real-World Use
- 03:12Problems with Current RL Paradigms and Infrastructure
- 04:34Evolution of Continual Learning Algorithms: SFT to GRPO
- 05:59How GRPO Works and Its Limitations
- 07:04Introducing On-Policy Self-Distillation (OPSD)
- 09:16Advantages of OPSD Over Traditional RL Methods
- 12:21Scaling OPSD and Future Directions
- 21:02Q&A and Closing Remarks
Full Transcript — Download SRT & Markdown
Speaker A
background about me. I went to this company called WinSurf where I was growing the research team over there. We trained this model called Sui 1 that ended up leading to the two billion acquisition at DeepMind, and then I
Speaker A
ended up giving up all the acquisition money to start Trajectory where we're building the platform for continual learning. So right to dive in, I think it's useful to talk a little bit about what AI progress has looked like for
Speaker A
the past couple years. So we've been in this mode where we've been rapidly scaling up benchmarks that have saturated within first years and then months, and that has continued on for the past couple years and will continue
Speaker A
to grow as well. The problem is it's becoming more time consuming and more expensive. We're seeing domains where it takes 4 hours, 6 hours, 24 hours, or even several days in order to scale up benchmarks. And obviously you guys have seen the massive
Speaker A
amount of money that the labs are pouring into scaling up RL environments and data. Now the thing is, we are left with a bunch of benchmarks that are getting more time consuming, more and more expensive, and perhaps more
Speaker A
concerningly, they're not tied to real-world use cases where people are using AI. Now the trillion token problem here is that we are actually spending hundreds of trillions of tokens every single day on inference, and we're
Speaker A
generating great amounts of data on how models in the real world are failing, how they're doing well. And that should be signal that we should be capturing and training on. And this is actually how humans learn, right?
Speaker A
We're continuously updating in the real world and getting smarter every single day. And we're seeing now the entire field talking about continual learning from AI experts like Ilia Carpathi Schol and Demis to also many industry leaders as well. Satya talking about how it
Speaker A
helps companies, and there was actually a great video by Daresh a couple days ago talking a lot about the intricacies of scaling up continual learning. And obviously the goal is we started with more data, training on internet skill
Speaker A
pre-training, scaling up to benchmarks, but the real unlock moving forward will be continual learning. So what's the problem? Why aren't we here yet? The main thing is there are several problems right now with our current algorithms. So first is we have a task distribution
Speaker A
mismatch. We're scaling up these benchmarks which might not even be tied to reality of what people are training on. And second, oftentimes some of these methods aren't even sampling truly on policy with what’s happening online. Third is we have a paradigm
Speaker A
right now where we're sending out multiple rollouts, and this requires huge amounts of infrastructure to make sure our environments are one-to-one copies of the real world. And it ends up being a bias that we're adding to our training
Speaker A
paradigm. And then finally, third is we are shoving every single reward into one scalar in order to train on when the real world is messy. It's noisy and it has rich amounts of data that should be per token signal. So we have all of
Speaker A
these kind of broken criteria, and we're training on it. And I want to take a little bit of a step through memory lane to see how we've been dealing with algorithms in the past. So the
Speaker A
first part, you know, we started with SFT. These were the days of instruction fine-tuning GPT 3.5, ChatGPT, and if you take a look at these four criteria, I mean, we had parallelism solved back then. It was just one roll or one
Speaker A
use case or example that we needed to train on, so that was a solved problem. And then the reward for SFT is per token, which is great, but we are not sampling on policy, and the task distribution is just some
Speaker A
sort of benchmark that we've curated or some sort of data set. Then we moved on to the DPO, RLHF age. This is when ChatGPT really started taking off, and we finally got online task distributions that we were able to train on. But
Speaker A
sampling was a little bit better because we were actually sampling from a model, but it was still off policy. But then we ended up losing some of the key infrastructure, easy infrastructure that we had with SFT. Now
Speaker A
we suddenly had pairs that we were training on. And then the reward went back to sequence level. Then we moved on to GRPO, which is kind of the mode that we're in right now. We basically took
Speaker A
a Fouian bargain and wanted to max on on-policy rollouts, which is extremely powerful, right? We now have models that are capable of amazing things because they are on policy and able to grow and not have all of the catastrophic
Speaker A
forgetting problems that we've had with previous methods. But on the other hand, we're working with off-policy task distributions. Our parallelism has now exploded, meaning that we need really robust environment infrastructure. And then finally, for rewards, we're back
Speaker A
to this paradigm of training on the entire sequence. So can we get to a world where all of these are true, where we have an online task distribution, where sampling is on policy, we have one parallelism so we don't need any of this
Speaker A
crazy infrastructure, and then finally our reward is actually token level? Well, this is what I'm excited to share and see how we can scale this up. So first, let's just go through what our best algorithm of post-training is today.
Speaker A
Hopefully you guys are all familiar with how GRPO works high level. You start off with some sort of task as an input.
Speaker A
You do a bunch of parallel rollouts. So we'll call these 01 through 04. And then you have some sort of end-state reward.
Speaker A
So you classify these, let's say, as a couple numbers. And then GRPO works on advantage. The idea is that you have some sort of mean that you're calculating over, and you're trying to shift the distribution of the model to be
Speaker A
better on the ones that you're better on, and then obviously move away from the ones that were worse than the mean. So this is how GRPO works. Now let's take a look at a new continual learning algorithm called self-distillation
Speaker A
policy optimization, or sorry, first we'll talk through why GRPO actually is still not enough. So the first part is if you remember the tasks, so these benchmarks are obviously very different. It requires a bunch of
Speaker A
parallelism, and then it's almost like you're drinking through a straw in order to get the reward. The way to think about it is imagine you were trying to write an essay and your teacher just gave you a score of 87 out of 100. You
Speaker A
would have to run through so many different examples to get to the idea of what a good essay is, and it's very simple and efficient. And so these are the fundamental problems with RL.
Speaker A
Now we're going to go through a new algorithm called on-policy self-distillation. So you guys are probably familiar with distillation in general. There's been obviously a lot of talk about mythos and blocking that from happening for a lot of open
Speaker A
source models. The high level here is that you start with some sort of data set. It's usually off policy and not actually tied to reality but some sort of fixed data set. And what you have is a student model and then a
Speaker A
smarter teacher model. So usually a bigger model, and you're trying to basically fit the log probs of the student to the teacher, and both of these are passed in with the same data. All right. So this is normal distillation.
Speaker A
Now there's a new innovation called on-policy distillation. The only thing we're doing is actually swapping out the fixed data for instead a rollout of what the student would have rolled out.
Speaker A
All right. So we take a rollout of the student that is our trajectory, and then we're trying to fit the log probs again of a smarter teacher model to
Speaker A
frontier we don't magically have some smarter model, right? uh like a teacher. And so now what do we do if we're we're already at the smartest model? Well, here's the final algorithm. Uh and this is where the self distillation part
Speaker A
comes in. If you basically take the the student model and give it some sort of what we call privileged information, a hint about the world and put that into the prompt. Well, suddenly that student is a little bit smarter. And that's
Speaker A
essentially the key idea of on policy self-distillation. You take what's called this hint, put it into the beginning of the prompt, and now you match the log props of the student without that hint to the teacher with that hint. And this is an extremely
Speaker A
powerful algorithm. To visualize it a little bit more, let's say you have this student prompt, right? Uh find the derivative of this function. What a hint would be is if you had some sort of environment information or or some sort
Speaker A
of guidance on how you should actually solve the problem. The simplest form of this is is literally just a example of a golden solution. You put that into the teacher prompt and then say here is guidance on how you would solve the
Speaker A
problem. And you can imagine now that solving that problem from the teacher's perspective becomes a little bit easier and we're we're trying to shift to those log problems had it known the answer in the first place.
Speaker A
Um and so by doing this we've solved several key problems that existed with RL. Uh so if you remember uh the task distribution now we can suddenly take something that is truly from online without needing to have sort of
Speaker A
benchmarks that are created. Uh the second part is we're still on policy sampling which is great. Uh but now there's no parallel rollouts. We don't need a group of eight in order to roll out but just from a single example we're
Speaker A
able to get information. So that takes away the environment bottleneck and all of these other infrastructures. And then finally the most exciting part is we're matching every single log problem of every token. So there's massively rich feedback about what this algorithm is
Speaker A
doing. Uh to see it a little more in action. And this is a really exciting part of self-distillation is it's actually not just the top token that you sampled uh that you're actually making better, but instead the entire
Speaker A
vocabulary. So for every single token, there's a vocabulary of let's say 65k tokens that you're optimizing over. And let's say the model generated some sort of uh for loop or range in Python. And essentially what we're doing is saying,
Speaker A
hey, the teacher for some of these areas where it's blue, it wasn't the top sample token of the student, but instead we're pushing that distribution to sample a brand new token. And this is really exciting because we're not just
Speaker A
taking now a distribution like RL and slightly sharpening it, but we're instead actually shifting entire distributions. So this is a really exciting part about opsd. Now we might be saying uh you know opsd is is awesome and and we've solved this problem. So I
Speaker A
mean for short horizon tasks it works incredibly well. If you take a look at live codebench uh actually we found that gpo saturates around sonnet level performance and and doesn't really push the frontier but because we're actually shifting distributions we're able to get
Speaker A
to brand new territory of results with a lot of data sets. And then the really cool part is um with RL a fundamental limitation and if you guys have ever trained RL models is the models like to think a lot right the more tokens that
Speaker A
you expend it's it's just going to do better but with opsd you don't have that problem and so the actual tokens to solve some of these really difficult challenges actually collapses which is really exciting for token efficiency and uh for some of these short horizon
Speaker A
tasks you can actually plugandplay opsd right now with several open source projects So uh open claw is a really good example of this open claw rl uh and you can actually use it to do simple chat bots learn from your behaviors with
Speaker A
unstructured data uh which is super super awesome. All right so we might be thinking okay continual learning is solved we can all go home and and be super happy. Uh the thing is this works really well for small models short
Speaker A
horizon tasks like something like a chatbot. Uh but this is where academic papers kind of end uh and where you really need to scale things up to start to to see the limitations. Uh so at trajectory we've been scaling up this
Speaker A
algorithm to 120bs to 500 bs to one trillion parameter models. And as soon as you get to the 120B range with not just one or two tool calls but 50 or 100 well things start to break apart a
Speaker A
little bit. So uh first of all eval accuracy is all over the place right the range is going really high uh run-to-run variance is extremely high and then also we start to see a lot of tool call errors uh the model is not behaving
Speaker A
accordingly to the format that it was trained on in the first place with the instruction fine-tuning all right so what are the problems that we started to see with this algorithm as we were scaling it up so the first part is
Speaker A
actually really funny and what I call it the buttweight problem. So on shorter tasks, you're fitting to a distribution.
Speaker A
Everything's great. But when you move on to longer tasks, what you get is is basically this student model. It's going off and doing whatever it thinks is on policy. And then at some point, because you're so divergent in a long task, the
Speaker A
teacher is going to try to course correct every single time it gets a chance. And so what you end up with is the teacher model just uh continuously trying to improve this token of wait or uh maybe or some of these kind of
Speaker A
hedging words. And there's this really interesting wordle in the the uh bottom left that you can see or wordcloud uh that as steps go on with opsd and you really scale it up uh you start to see some of these words like wait and then
Speaker A
but uh start to appear. And then you actually end up in this really interesting local suboptimal position where everything just turns into maybe.
Speaker A
And on the right here you can kind of see some visualization of this. As the task goes on you get two different distributions that are really divergent.
Speaker A
And what you end up with is the model trying to be in the middle of both of those. Uh which is obviously really suboptimal. All right. So there's a couple ways to solve this. Uh one potential solution is to define step
Speaker A
level divergence. So uh in a tool calling trajectory, let's say you have a 100 tool calls going on. Well, what we can do is start to look at the KL divergence of the student model and the teacher model as time goes on. And now
Speaker A
we can use this as a waiting factor. So not just like normal KL where we use that as a KL penalty, but instead we're actually multiplying the token weight uh of every single step based on this divergence property.
Speaker A
And now the cool part of this uh is that so on the left side we have a normal trajectory that is like pretty in distribution and everything's fine, right? It's everything is a weight of one. On the second part, we have a
Speaker A
trajectory that diverges pretty heavily. And so in here, we're only going to modify W1 as the first step. Uh and and so that we can train that, get that right, and then move on, which is awesome. And then finally, on the third
Speaker A
part, and this is really cool, by having independent waiting for every step is we can actually have a scenario where uh the model might go off tracks. We don't want to heavily weight that in, but then later on in the trajectory, it might get
Speaker A
back on track again. and and we're fine with that and we'll mildly shift the distribution. So this is one way that we've been able to overcome this for a long horizon tool calling. The second part and this is actually really
Speaker A
nefarious with uh ops. So with RL the number one problem that people face is reward hacking as you guys are are all aware of uh and that's a game that continuously RL researchers have had to play. Well there is an equivalent for
Speaker A
OPSD as well and that is hint leakage. The way you can think about it is we're we're taking this hint, right? Putting it in the the beginning of a prompt.
Speaker A
Well, if the student had no way of knowing what that hint would be, uh then you're going to end up with some weird scenarios and and kind of skipping some steps along the way. So, the way this manifests u is let's take this example
Speaker A
here where you're trying to find the last three digits of of this formula. uh and a normal hint might be uh actually giving the correct steps and then maybe a final answer and saying, "Hey, actually hint, the last three digits are
Speaker A
all zeros." Well, you can see on the right here that when you actually roll out the model, uh you end up with something that's says, "Oh, actually, I know what the solution is. It's 00 0.
Speaker A
So, let me go back and put that into my reasoning trace and then figure out what's going on." Well, you can imagine that this is not going to occur whatsoever in the real world. And so we've ended up in this really strange
Speaker A
position. Uh and so there's a lot of care that you have to put into how you design these hints and making sure there's not leakage of information. So uh there's one kind of trivial solution to this that you can imagine and this is
Speaker A
just literally using an LLM to filter out these hints. So an example of this is uh you know let's say a user can't log in. you have some sort of problem like this uh and there might be some
Speaker A
sort of information like exactly the solution right you'll find their SSO token that is expired and you can have an LLM basically translate that into what is something reasonable that they should have known and that's the process of looking through the logs but not
Speaker A
actually giving it the solution that it would shortcut some of its vital reasoning. So this is one trivial uh solution and it works decently well but there's some more satisfying algorithmic approaches too. One of these is called residual guidance. The general idea is
Speaker A
in a hint uh most of the time you need to actually get through the entire hint in order to get the full information. So what if you let's say cut it in half then you have a partial hint and then
Speaker A
you basically say okay this is the partial teacher we're able to get the log props of a slightly smart teacher and then we have the full teacher as well and that's with the full hint. Now what we can do is actually take the
Speaker A
linear combination of both of these and this gives us a good idea of how strong the hint is and how out of distribution it is for the original model. And what you end up with here is so on the left
Speaker A
you have normal OPD uh where you might be entirely shifting distributions and there's almost no overlap between your model and the original solution. uh to this kind of cool world where uh let's say half the hint is actually quite
Speaker A
close to your distribution but the full hint is very off and you take a linear combination and so then you're not shifting the model into unknown territory. So these are just some of the solutions to uh a lot of the challenges
Speaker A
that we've had with scaling up opsd. Uh but it is a very very powerful algorithm and uh with a lot of these combinations together we're actually able to scale this up to uh a 12b model on mercur apex
Speaker A
agents uh which often requires 100 and or plus tool calls in order to achieve and it's a really powerful algorithm that has even surpassed RL as well.
Speaker A
So now we've finally arrived at a algorithm. It's not necessarily the algorithm to solve continual learning, but uh definitely one that is a huge step forward that keeps the on policy nature that makes RL so powerful. But then it also has uh finally the task
Speaker A
distribution that is online. Uh it has parallelism uh that is singular. So we don't need all of this infrastructure.
Speaker A
And then finally it is per token dense reward. So the uh the really exciting part for us and and what we're really focused on now trajectory is uh this just gives you one taste of the entire continual learning loop and there is a really
Speaker A
exciting world that is about to come where software in general just gets smarter every single time it's used and that is the most exciting unlock that's going to happen in 2026 2027 and as we scale up. So a little bit about
Speaker A
trajectory. We are uh building the platform that turns every interaction into model improvement, harness improvement, uh and the entire agentic loop just getting smarter over time. Um and we're we're building this platform where we take in agent traces data from
Speaker A
production. We're able to optimize that uh as a self-s served loop and then deploy that uh as a continually learning system. And uh we have a control plane that goes over all of that. Um, so very quickly, our team is super awesome.
Speaker A
We're from DeepMind, Meta Super Intelligence, OpenAI, uh, and a lot of great product builders as well. Um, and we we've given early access to a lot of companies. So, Harvey, Dakagon, Rogo, um, and they're super excited about what
Speaker A
we're doing. Uh, if you're interested in any of the research that we're doing, uh, or any of the product that we're building, uh, definitely let me know.
Speaker A
Keep in touch and, uh, happy to answer any questions. [applause] Is it in the sense of like very little latency so that you can learn time or is this something that Yeah, that's a great question. Uh so what I would say is as a research
Speaker A
community right now we're in this zone of what I call pseudo continual learning. uh where there's some still level of like batch updates offline uh and then re-uploading the model. I think it's partly an infrastructure question.
Speaker A
It's partly still an algorithmic question as well of how do you truly get when you have 10,000 rollouts going out in a product merging those together the infrastructure to pull all of those together. So those are some of the
Speaker A
problems that we are solving at trajectory. Uh but I wouldn't say we're anywhere close to the the end solution.
Speaker A
Question about hardness. studies in terms of effectiveness. Totally. I I think that's actually one of the most underexplored and most exciting questions is not only just harness improvement, right? And I think there's some literature out there now starting to explore that. But the really
Speaker A
exciting part is how does the model and the harness interplay with each other as you're both updating them. That's some of the stuff that we're now exploring with our current customers and and really doing those things online. Uh,
Speaker A
but it's completely unexplored territory and there's some really exciting innovations to be made there as well.
Speaker A
Cool. All right. Thanks so much, guys.
Topics:continual learningscaling AIon-policy self-distillationGRPOreinforcement learningtask distribution mismatchtoken-level rewardAI benchmarkstrajectory AIRonak Malde
