AI Engineer World's Fair 2026
Scaling up Continual Learning
Read the talk
Scaling Continual Learning from Single Answers to Long Agent Trajectories
Learning from production requires more than collecting traces. On-policy self-distillation supplies dense feedback, but long tool-calling trajectories expose divergence, hint leakage, and deployment challenges.
From a talk by Ronak Malde
Before you start: Familiarity with language-model token probabilities, fine-tuning, and tool-calling agents will help; the article introduces the training methods as they appear.
Why build harder benchmarks while production keeps generating experience?
How can models learn from the work people already ask them to do? Following a talk about measuring continual learning, Ronak Malde turns to scaling it. His starting point is experience growing Windsurf’s research team and training SWE-1, before founding Trajectory. He describes giving up acquisition-related compensation to make that move; the Google transaction he references was a hiring and licensing deal, rather than a purchase of Windsurf itself.
The existing path to progress has been to build benchmarks, train against them, and replace them as they saturate. Malde describes saturation accelerating from years to months, while the remaining tasks become increasingly expensive: some take four, six, or twenty-four hours, and others take days. More investment in reinforcement-learning environments and data can sustain that process, but it does not ensure that the tasks resemble what users actually need.
Meanwhile, production inference generates examples of models succeeding, failing, and responding to the consequences of their actions. Malde estimates that inference consumes hundreds of trillions of tokens daily, without specifying a measurement source or accounting scope. The central opportunity does not depend on that exact total: real interactions contain training signal that is currently being left unused.
Continual learning would make those interactions part of the improvement process. Malde places this after internet-scale pretraining and benchmark-driven training, and points to growing interest from Ilya Sutskever, Andrej Karpathy, Sholto Douglas, Demis Hassabis, and Satya Nadella, alongside a recent Dwarkesh video. The technical question is how to turn that interest into a learning algorithm that fits actual usage.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Four requirements that existing methods trade against each other
The first distinction is between where tasks come from and which policy generates the training trajectories. Production tasks can match real usage while their recorded answers still come from an older policy. Conversely, a current model can generate fresh, on-policy answers to benchmark tasks that poorly represent production. These are separate axes.
Two further requirements concern infrastructure and feedback. Generating several alternative trajectories requires environments that can reproduce the same starting conditions and support parallel actions. Building faithful copies is expensive, and imperfections introduce training bias. Then, after collecting a rich interaction, reducing its outcome to one scalar discards much of the information that could explain which individual decisions were useful.
Malde’s historical comparison starts with supervised fine-tuning, associated here with instruction tuning and GPT-3.5 and ChatGPT, then moves through preference training to GRPO. The table captures the training setups he contrasts; it is not a claim that every implementation of each method has these properties.
| Training setup | Task source | Sampling | Examples per task | Feedback |
|---|---|---|---|---|
| SFT | Curated dataset | Off-policy | One example | Per-token targets |
| DPO / RLHF, as presented | Online tasks | Model-generated, still off-policy | Preference pairs | Sequence-level preference |
| GRPO | Offline benchmark tasks | On-policy | Parallel rollout group | Sequence-level reward |
SFT makes the infrastructure simple and supplies token-level supervision, but learns from a fixed collection of demonstrations. Preference training brings real user tasks into the picture while introducing pairs and sequence-level judgments. GRPO prioritizes fresh on-policy rollouts; Malde credits that with powerful capability gains and fewer of the forgetting problems associated with earlier methods. Its costs are grouped rollouts, substantial environment infrastructure, and a return to whole-sequence rewards.
The desired combination is therefore specific: online tasks, on-policy samples, one rollout, and dense token-level feedback. Getting all four would let a system learn from a real interaction without first reconstructing the world and replaying the task several times.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
What a group-relative reward actually tells the model
GRPO starts with one task and produces several parallel outputs, labeled O1 through O4 in the explanation. Each output receives an end-state reward. The algorithm compares those rewards with the group mean and shifts the policy toward outputs that did better and away from outputs that did worse. The group supplies a relative measure of which behavior to reinforce.
That still leaves a narrow feedback channel. Imagine writing an essay and receiving only 87/100 from a teacher. The score gives a judgment, but it does not identify a weak transition, an unsupported claim, or a good paragraph worth preserving. Many attempts may be necessary to infer what the teacher wants. GRPO combines this sparse-feedback problem with the earlier task-distribution mismatch and the need to run multiple copies of an environment.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Make the same model a better teacher by giving it a hint
Distillation provides a different kind of supervision. After a brief reference to Mythos and restrictions on distillation into open-source models, Malde starts with the conventional setup: a student and a smarter, usually larger teacher receive the same fixed dataset. Training fits the student’s token probabilities to the teacher’s. Instead of learning only whether a complete answer was good, the student learns how the teacher distributes probability at each position.
On-policy distillation changes the source of the trajectory. Rather than scoring a fixed demonstration, the teacher scores the student’s own rollout. The student therefore receives guidance at the prefixes its current policy actually produces. But frontier training creates a problem: if the student is already the strongest available model, where does a smarter teacher come from?
On-policy self-distillation, or OPSD, changes the teacher’s information rather than its underlying model. Give the same model privileged information—a hint about the task or environment—and it can make better predictions. The student receives the original prompt; the teacher receives that prompt with the hint prepended. Both evaluate the student’s trajectory, and training moves the unhinted student toward the hinted teacher’s probabilities.
The demonstration asks the student to find a function’s derivative. Guidance about how to solve it, or even a golden solution, makes the teacher’s job easier. The learning procedure is:
- Generate a trajectory from the student using the original derivative question.
- Add the guidance to the teacher’s prompt.
- Evaluate the student’s trajectory under that better-informed context.
- Train the student without the hint to match the teacher’s predictions.
The teacher does not need to generate a separate successful trajectory for the student to copy. Its advantage comes from knowing more while evaluating what the student already did.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
One rollout can carry vocabulary-wide supervision
This setup can use an actual online task, preserve sampling from the student’s current policy, and learn from a single trajectory. Malde contrasts that with an illustrative group of eight rollouts: the extra information comes from the teacher’s predictions, so it does not require eight independent attempts in cloned environments. At each generated position, the teacher supplies a distribution rather than one end-of-sequence score.
The feedback also extends beyond the token the student happened to choose. Consider the Python for loop and range example on the slide. At a position where the student favors one token, the teacher may favor a different token from the vocabulary. Malde uses a vocabulary of roughly 65,000 tokens to illustrate the breadth of that signal. The blue regions identify alternatives that were not the student’s top sampled token but that the teacher wants to make more likely.
A full-distribution matching loss can be expressed directly in Python. Here, each row represents the next-token distribution at the same student-generated prefix; the teacher rows were computed with the extra hint. response_mask selects the generated positions to train on.
python
import torch
import torch.nn.functional as F
def distillation_loss(
student_logits: torch.Tensor,
teacher_logits: torch.Tensor,
response_mask: torch.Tensor,
) -> torch.Tensor:
# Logits: [batch, response_positions, vocabulary]
student_log_probs = F.log_softmax(student_logits.float(), dim=-1)
teacher_probs = F.softmax(teacher_logits.detach().float(), dim=-1)
per_position_loss = -(teacher_probs * student_log_probs).sum(dim=-1)
mask = response_mask.to(per_position_loss.dtype)
return (per_position_loss * mask).sum() / mask.sum().clamp_min(1)
This makes the distributional idea explicit: every vocabulary entry contributes to the target at a trained position. It does not require every implementation to materialize the full vocabulary distribution. The slide labels its vocabulary grid SDPO, while Malde calls the mechanism OPSD; those labels alone do not establish identical implementation details. His central comparison is that distillation can move probability toward teacher-preferred alternatives, beyond reinforcing the successful tokens already sampled by the student.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Promising short-task results are the starting point
For short-horizon tasks, Malde reports that GRPO saturated around Sonnet-level performance on LiveCodeBench, while OPSD reached higher performance in their experiments. He does not specify the Sonnet version, exact scores, or evaluation window. He attributes the improvement to the ability to shift the output distribution into behavior that the original policy did not readily produce.
Malde also reports sharply reduced token counts for solving difficult tasks with OPSD, without giving a numerical efficiency ratio. He contrasts this with the tendency of RL-trained models to improve by spending more tokens reasoning. The attraction is therefore not just better answers, but a route to better answers without continually lengthening the reasoning trace.
For accessible implementations, he points to OpenClaw-RL, describing chatbots that learn user behavior from unstructured interactions. These examples establish a useful starting point: small models and short tasks can benefit from this learning signal. They do not settle what happens when an agent must maintain coherent behavior across a long sequence of tool calls.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Long trajectories turn correction into hesitation
Trajectory has experimented with scaling the approach to 120-billion-, 500-billion-, and one-trillion-parameter models, according to Malde. He reports instability emerging around 120 billion parameters on trajectories with 50–100 tool calls. Evaluation accuracy becomes erratic, run-to-run variance rises, and tool-call errors appear. Models also start departing from the formatting behavior established during instruction tuning.
The first failure mode is the “but wait” problem. On a short task, the student’s trajectory and the hinted teacher’s preferred behavior may remain close. On a longer task, the student keeps following its own policy and can drift far from the route the teacher would take. Whenever the teacher evaluates another position, it tries to redirect the trajectory.
Repeated correction creates pressure toward tokens such as wait, maybe, then, and but. Malde describes a word cloud in which these words become more prominent as training proceeds. Eventually, the policy can settle into an unhelpful local solution dominated by hesitation: the student and teacher distributions have diverged, and fitting between them produces a model that keeps reconsidering rather than making coherent progress.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Weight each step by how far the teacher and student disagree
One response is to measure step-level divergence. In an illustrative trajectory with 100 tool calls, compare the student’s and teacher’s distributions as the trajectory develops. Use their KL divergence to determine a multiplicative weight on the token loss within each step. This differs from adding a conventional KL penalty to an objective: the divergence controls how much that step contributes to learning.
Independent step weights allow three different treatments:
- A trajectory that stays in distribution: Keep the weights at one and learn throughout.
- A trajectory that diverges heavily: In Malde’s example, modify
W1first, concentrating the correction on getting the initial step right before proceeding. - A trajectory that departs and later recovers: Downweight the off-track portion, then retain a mild update where the trajectory becomes useful again.
The recovery case is particularly valuable. A poor middle section need not make every later step unusable, and a good beginning need not justify equally strong updates everywhere afterward. Malde presents this as one way to stabilize long-horizon tool calling, without specifying an exact divergence-to-weight formula.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A teacher can know too much
RL has reward hacking; self-distillation has an analogous problem in hint leakage. The teacher receives information that the student will not have at deployment. If matching the teacher teaches behavior that depends on already knowing that information, the student may learn to skip the very reasoning or investigation required to obtain it.
The numerical example asks for the last three digits of an expression. A hint includes the solution steps and reveals that the answer is 000. The resulting reasoning starts from knowing 000 and works backward to fit that answer into the trace. This is a shortcut that would not be available when facing a new problem without the privileged hint. Hint design must therefore distinguish guidance that helps the model reason from information that lets it bypass reasoning.
A simple remedy is to have an LLM filter the hint. Suppose a user cannot log in. The raw hint says the user’s SSO token has expired. A filtered version instead directs the model to inspect the logs. The useful action is preserved, while the answer the agent should discover is removed from the teacher’s guidance. Malde says this works decently well, though it is only one approach to the problem.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Use partial hints to moderate the learning signal
Residual guidance tackles the same problem through the teacher signal. A hint often reveals its full meaning only after the model has seen all of it. Cutting it in half creates a partial teacher: the same model has some useful information, but less than the full teacher. Both contexts can then be used to compute token probabilities.
Malde describes taking a linear combination of the partial- and full-teacher signals to assess the strength of the hint and moderate the resulting update. In his illustrated case, the partial-hint distribution remains close to the student, while the full-hint distribution lies much farther away. Combining their signals offers a way to use the extra information without pulling the student entirely into behavior supported only by privileged knowledge. The talk gives the mechanism, but not the combination coefficients or a precise implementation formula.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Recovering the original promise at agent scale
With these remedies combined, Malde reports that a 120-billion-parameter model surpassed RL on Mercor’s APEX-Agents tasks, which he says often require more than 100 tool calls. The talk does not provide the exact score, RL baseline configuration, or effect size for that comparison. The result matters here because it extends the approach beyond short answers into the long trajectories where naive self-distillation became unstable.
The intended properties remain intact: tasks can come from online usage, the student can generate its own on-policy trajectory, one rollout can supply a training example, and the teacher can provide dense per-token supervision. Malde presents this as a substantial step forward, not as an algorithm that has solved continual learning end to end.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The algorithm sits inside a larger production loop
A weight update is only one part of a continually improving product. Malde’s broader forecast is software that becomes more capable each time it is used, which he sees as an important opportunity for 2026–2027. At Trajectory, the improvement targets include the model, its harness, and the behavior of the complete agent system.
The platform he describes follows a production loop:
- Ingest agent traces from real usage.
- Optimize the system through a self-serve learning process.
- Deploy the resulting improvements.
- Oversee the process through a control plane.
He describes a team with backgrounds at DeepMind, Meta Superintelligence, and OpenAI, alongside product builders, and names Harvey, Decagon, and Rogo as early-access companies. The platform ambition is to connect the learning mechanism to collection, deployment, and operational control.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Continual collection does not yet mean immediate learning
The first audience question makes the deployment issue concrete: how long does training take, and can learning happen in real time? Malde describes the current research stage as pseudo-continual learning. Data arrives through usage, but updates still happen in offline batches, followed by re-uploading the model. He gives no training-duration measurement.
Moving from that cycle to immediate learning is both an infrastructure and an algorithmic problem. Malde asks the audience to imagine 10,000 rollouts running through a product and the work required to bring them together. Online collection alone does not guarantee that each trace remains on-policy by the time training consumes it. Trajectory is working on this coordination problem, but he explicitly says the end-to-end solution is still far away.
The final question asks whether different harnesses change the effectiveness of learning. Malde points to emerging work on harness improvement, then identifies a harder question: what happens when the model and the harness both change? A model update changes the behavior available to the harness; a harness update changes the contexts and action sequences the model encounters. Trajectory is exploring that interaction online with customers, but Malde offers no comparative harness results. The remaining research problem is to make the whole agent improve coherently while both sides of that interaction are moving.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Training framework that converts agent interactions into binary rewards, distillation signals, or combined updates.
Official evaluation tools for coding tasks drawn from programming competitions.
Mercor's introduction to long-horizon agent evaluation across professional workflows.
Further reading
- Scaling SDPOArticle
Trajectory's experiments on single-rollout learning, stale production data, training stability, and APEX-Agents.
Introduces OPSD with a privileged-context self-teacher and evaluates mathematical reasoning and token efficiency.
Original SDPO research cited by Trajectory's companion article.
Read the complete timestamped transcript
- 0:00
[upbeat music] All right. Hey, everyone. Uh, thanks for coming by over here.
- 0:16
Hope you enjoyed the chat by Parth on, uh, how to measure continual learning. Now I'm here to talk about how we scale it up. So a bit of background about me.
- 0:25
I, uh, went to this company called Windsurf, where I was growing the research team over there. Uh, we trained this model called SWE-1 that ended up leading to the two billion acquisition at DeepMind, and then I ended up giving up all the acquisition money to start Trajectory, where we're building the platform for continual learning.
- 0:42
So, uh, right to dive in, uh, I think it's useful to talk a little bit about what AI progress, uh, has looked like for the past couple of years.
- 0:51
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 of years and, and will continue to grow as well.
- 1:05
The problem is it's becoming more time-consuming and more expensive. Uh, we're seeing domains where it takes four hours, six hours, twenty-four hours, or even several days in order to scale up benchmarks.
- 1:18
And obviously, you guys have seen the massive amount of money that the labs are pouring into scaling up RL environments and data. Now, the thing is, uh, we are left with a bunch of benchmarks that are getting more time-consuming, uh, more and more expensive, and, and perhaps more concerningly, uh, they're not tied to real-world use cases where
- 1:40
people are using AI. Now, the, uh, trillion, uh, token problem here is that we are actually spending hundreds of trillions of tokens every single day on inference. Uh, and we're generating great amounts of data on how models in the real world are, are failing, how they're doing well, uh, and that should be signal that we should be
- 2:00
capturing and training on. Uh, and this is actually how humans learn, right? We're continuously updating in the real world and getting smarter every single day. And, uh,
- 2:11
we're seeing now the entire field talking about continual learning from AI experts like Ilya, Karpathy, Sholto, uh, and Demis, uh, to also many industry leaders as well. Uh, Satya, uh, talking about how it helps companies.
- 2:25
And, uh, there was actually a great video by Dwarkesh a couple of 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 pre-training, scaling up to benchmarks, but the real unlock moving forward will be continual learning.
- 2:43
So what's the problem? Why aren't we here yet? The main thing is, uh, th-there's several problems right now with our current algorithms. So first is we have a task distribution mismatch.
- 2:55
We're scaling up these benchmarks which might not even be tied to reality of what people are training on. And second, uh, oftentimes some of these methods aren't even sampling truly on policy with what, what's happening online.
- 3:09
Third is, uh, we have a paradigm 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, uh, and it ends up being a bias that we're adding to our training paradigm.
- 3:26
And then finally, third is we are shoving every single reward into one scaler in order to train on when the real world is messy, it's noisy, and it has rich amounts of data, uh, that should be per token signal.
- 3:38
So we have all of these kind of broken criteria, uh, and we're training on it. And I wanna take a little bit of a step through memory lane to, to see how we've been dealing with algorithms in the past.
- 3:50
Um, so the first part, uh, you know, we started with SFT. These were the, the days of instruction fine-tuning, GPT-3.5, ChatGPT. And, uh, if you take a look at these four criteria-- I mean, we had parallelism, uh, solved back then.
- 4:03
It was just one roll-- or one, uh, u-use case or example that we needed to train on. So that was a solved problem. Uh, and then the reward for SFT is per token, which is great.
- 4:14
But we are not sampling on policy, and the task distribution is just some sort of benchmark that we've curated or some sort of dataset. Then we moved on to the DPO RLHF age.
- 4:25
Uh, this is when ChatGPT really started taking off. Uh, and we finally got online task distributions that we were able to train on. Uh, but sampling, it was a little bit better because we were actually sampling from a model, but it was still off policy.
- 4:40
But then we ended up losing some of the, uh, the key infrastructure, easy infrastructure that we had with SFT. Now we suddenly had pairs that we were training on, uh, and then the reward went back to sequence level.
- 4:53
Then we moved on to GRPO, which is kind of the mode that we're in right now. Uh, we basically took a Faustian bargain and wanted to max on on-policy rollouts, which is extremely powerful, right?
- 5:04
We now have models that are capable of amazing things, uh, because they are on policy and able to grow and, and not have all of the catastrophic forgetting problems that we've had with previous methods.
- 5:15
But on the other hand, we're working with off-policy task distributions. Uh, our parallelism has now exploded, meaning that we need really robust environment infrastructure. And then finally, for rewards, uh, we're back to this paradigm of training on the entire sequence.
- 5:31
So can we get to a world where all of these are true, where we have an online task distribution, we're sampling on policy, we have one parallelism, so we don't need any of this crazy infrastructure, and then finally, uh, our reward is actually token level?
- 5:49
Well, this is what I'm excited to share and, and see how we can scale this up.
- 5:54
So first, le-let's just go through what our best algorithm of post-training is today. Hopefully, you guys are all familiar with how GRPO works high level. Uh, you start off with some sort of task as an input.
- 6:05
You do a bunch of parallel rollouts. So we'll call these O one through O four. And then you have some sort of end state reward. So you classify these, let, let's say as, uh, a couple numbers, and then GRPO works on advantage, the idea that you have some sort of mean that you're calculating over.
- 6:21
And you're trying to shift the distribution of the model to be, uh, better on the ones that you're better on, uh, and then obviously move away from the ones that were worse than the mean.
- 6:29
So this is how GRPO works. Now let's take a look at a new continual learning algorithm called self-dist- or, uh, uh, uh, self-distillation policy optimization. Um, no, uh, sorry.
- 6:40
First of all, we'll talk through why GRPO actually is, uh, still not enough. So, um, the first part is, uh, if you remember the tasks. So these benchmarks are obviously very different.
- 6:51
Uh, it requires a bunch of 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 eighty-seven out of a hundred.
- 7:04
Uh, you would have to run through so many different examples to get to the idea of what a good essay is, and it's, it-- very simple and efficient. Um, and so these are the fundamental problems with RL.
- 7:14
Now, uh, we're, we're gonna go through a new algorithm, uh, con- called on-policy self-distillation. So, uh, you guys are probably familiar with distillation in general. Uh, there's been obviously a lot of talk about Mythos and, and blocking that from happening for a lot of open source models.
- 7:29
Uh, the high level here is that you start with some sort of dataset. Uh, it's usually, uh, off policy or not actually tied to reality, but some sort of fixed dataset.
- 7:40
And what you have is a student model and then a smarter teacher model, so usually a bigger model. Uh, 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.
- 7:53
All right, so this is normal distillation. 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've rolled out.
- 8:07
All right? So we take a, a now 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 the student.
- 8:16
Great. Now, the problem is when we're trying to push the frontier, we don't magically have some smarter model, right? Uh, uh, like a teacher. And so now what do we do if we're, we're already at the smartest model?
- 8:28
Well, here's the final algorithm. Uh, and this is where the self-distillation part 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 essentially the key idea
- 8:49
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 probs of the student without that hint to the teacher with that hint.
- 8:59
Uh, and this is an extremely powerful algorithm. To visualize it a little bit more, uh, uh, let's say you have this student prompt, right? Uh, find the derivative of this function.
- 9:09
What a hint would be is if you had some sort of environment information or, or some sort 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.
- 9:20
You put that into the teacher prompt and then say, "Here is guidance on how you would solve the 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 probs had it known the answer in the first place.
- 9:36
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, sort of benchmarks that are created.
- 9:51
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 able to get information.
- 10:02
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 prob of every token.
- 10:10
So there's massively rich feedback about what this algorithm is doing.
- 10:15
Uh, to see it a little more in action, a- 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 vocabulary.
- 10:28
So for every single token, there's a vocabulary of, let's say, sixty-five K tokens that you're optimizing over. And let's say the model generated some sort of, uh, for loop or, uh, a range in Python.
- 10:40
And essentially what we're doing is saying, "Hey, the teacher," uh, for some of these areas where it's blue, it wasn't the top sampled token of the student, but instead we're pushing that distribution to sample a brand-new token.
- 10:52
And this is really exciting because we're not just 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.
- 11:05
Now, we might be saying, uh, you know, OPSD is, is awesome and, and we've solved this problem. So I mean, for a short horizon task, it works incredibly well.
- 11:14
If you take a look at LiveCodeBench, uh, actually we found that GRPO saturates a- around Sonnet level performance and, and doesn't really push the frontier. But because we're actually shifting distributions, we're able to get to brand-new territory, uh, of results with a lot of datasets.
- 11:30
And then the really cool part is, um, with RL, a fundamental limitation a- and if you guys have ever trained RL models, is the models like to think a lot, right?
- 11:39
The more tokens that 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.
- 11:54
And, uh, for some of these short horizon tasks, you can actually plug and play OPSD right now with several open source projects. So, uh, OpenClaw is a really good example of this, OpenClaw RL.
- 12:03
Uh, and you can actually use it to do simple chatbots, learn from your behaviors with unstructured data, uh, which is super, super awesome. All right. So we might be thinking, "Okay, continual learning is solved.
- 12:14
We can all go home and, and be super happy." Uh, the thing is, this works really well for small models, short-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 see, to see the limitations.
- 12:32
Uh, so at Trajectory we've been scaling up this algorithm, um, to 120Bs to 500Bs to one trillion parameter models. A- 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 little bit.
- 12:50
So, uh, first of all, uh, 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.
- 13:02
Uh, the model is not behaving 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?
- 13:15
So the first part i- is actually really funny and what I call the, uh, but wait problem. So on shorter tasks, you're fitting to a distribution, everything's great. But when you move on to longer tasks, what you get is, is basically this student model.
- 13:30
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 teacher is going to try to course-correct every single time it gets a chance.
- 13:42
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 hedging words.
- 13:52
And there's this really interesting Wordle on the, the, uh, bottom left there you can see... Or word cloud, 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, but, uh, start to appear.
- 14:07
And then you actually end up in this really interesting local suboptimal position where everything just turns into maybe. And on the right here, you can kinda see some visualization of this.
- 14:17
As the task goes on, you get two different distributions that are really divergent, 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.
- 14:27
All right, so there's a couple ways to solve this. Uh, one potential solution is to define step-level divergence. So, uh, in a tool calling trajectory, let's say you have 100 tool calls going on.
- 14:40
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, uh, we can use this as a weighting factor.
- 14:51
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.
- 15:04
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?
- 15:12
It's everything is a weight of one. On the second, uh, part we have a trajectory that diverges pretty heavily. And so in here we're only going to modify W1 as the first step.
- 15:24
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 part, and this is really cool by having independent weighting for every step, is we can actually have a scenario where, uh, the model might go off tracks.
- 15:37
We don't want to heavily weight that in. Uh, but then later on in the trajectory it might get back on track again and, and we're fine with that and will mildly shift the distribution.
- 15:48
So this is one way that we've been able to overcome this for a long-horizon tool calling. The second part... A- and this is actually really nefarious with, uh, OPSD.
- 15:57
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.
- 16:06
Well, there is an equivalent for 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.
- 16:16
Well, if the student had no way of knowing what that hint would be, uh, then you're gonna end up with some weird scenarios and, and kind of skipping some steps along the way.
- 16:25
So the way this manifests, uh, is... Uh, let's take this example 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 all zeros."
- 16:43
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.
- 16:51
It's zero, zero, zero. 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 gonna occur whatsoever in the real world.
- 17:00
And so we've ended up in this really strange 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.
- 17:10
So, uh, there's one kind of trivial solution to this that you can imagine, and this is just literally using an LLM to filter out these hints. So an example of this is, uh, you know, l- let's say a user can't log in.
- 17:22
You have some sort of problem like this. Uh, and there might be some sort of information like, uh, e- 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.
- 17:36
And that's the process of looking through the logs but not 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.
- 17:47
But there's some more satisfying algorithmic approaches too. One of these is called residual guidance. The general idea is in a hint, uh, most of the time you need to actually get through the entire hint in order to get the full information.
- 18:01
So what if you, let's say, cut it in half? Then you have a partial hint. And then you basically say, "Okay, this is the partial teacher." We're able to get the log probs of a slightly smart teacher.
- 18:14
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 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.
- 18:30
And what you end up with here is-- So on the left, 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 close to your distribution, but the full
- 18:46
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 that we've had with scaling up OPSD.
- 18:59
Uh, but it is a very, very powerful algorithm. And, uh, with a lot of these combinations together, we're actually s- able to scale this up to, uh, a 120B model on Mercor Apex agents, uh, which often requires a hundred and pl-- or, or plus tool calls in order to achieve.
- 19:15
And it's a really powerful algorithm that has even surpassed RL as well.
- 19:20
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.
- 19:33
But then it also has, uh, finally, the task distribution that is online. Uh, it has parallelism, uh, that is singular, so we don't need all of this infrastructure. And then finally, it is per-token dense reward.
- 19:46
So the, uh, the really exciting part for us and, and what we're really focused on now at Trajectory is, uh, this just gives you one taste of the entire continual learning loop.
- 19:56
And there is a really 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 gonna happen in twenty twenty-six, twenty twenty-seven, and as we scale up.
- 20:10
So a little bit about 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.
- 20:23
Um, and we're, we're building this platform where we take in agent traces data from production. We're able to optimize that, uh, as a self-serve loop and then deploy that, uh, as a continually learning system.
- 20:36
And, uh, we have a control plane that goes over all of that. Um, so very quickly, our team is super awesome. We're from, uh, DeepMind, Meta Superintelligence, OpenAI, uh, and a lot of great product builders as well.
- 20:47
Um, and we're-- we've given early access to a lot of companies, so Harvey, Decagon, Rogo, um, and they're super excited about what 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.
- 21:01
Keep in touch, and, uh, happy to answer any questions. [clapping]
- 21:13
Um, just, uh, how long does the training take? Is it continual in the sense of like very little latency so that it can run in real time, or is this something that happens in the back?
- 21:24
Yeah, that's a great question. Uh, so what I would say is a-as a research 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.
- 21:40
Uh, I think it's partly an infrastructure question. It's partly still an algorithmic question as well of how do you truly get-- When you have ten thousand rollouts going out in a product, merging those together, the infrastructure to pull all of those together.
- 21:51
So those are some of the problems that we are solving at Trajectory. Uh, but I wouldn't say we're anywhere close to the, the end-to-end solution.
- 22:00
Okay. The follow-up question, uh, about harness. Um, have you studied the effect of using different harnesses in terms of effectiveness of the-
- 22:11
Totally. I, I think that's actually one of the most underexplored and most exciting questions is not only just harness improvement, right? And, and I think there's some literature out there now starting to explore that.
- 22:22
But the really 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.
- 22:32
Uh, but it's completely underexplored territory, and there's some really exciting innovations to be made there as well.
- 22:36
We'll take all these questions outside 'cause we need to get up for the next speaker.
- 22:41
Cool. All right. Thanks so much, guys. [clapping] [outro jingle]