Bringing Continual Learning into Enterprises

[upbeat music] All right. Can you hear me? Yeah. Take that as a yes.

Um, cool. So we'll go ahead and get started here. Uh, today what we're gonna be talking about is bringing continual learning into enterprises, uh, and how we're doing it at Applied Compute.

Uh, bit of an intro. My name's Sam Denton. Uh, I lead the platform research team at Applied Compute.

So here's our loose agenda for the day. Uh, we're gonna start by talking about the distillation spectrum and how we think about different areas on the spectrum of distillation.

Then we're gonna talk about where value accrues along this distillation spectrum. We'll show a bunch of data on how distillation is working in enterprises. Uh, if I have time, I'll try and get to some tips and tricks we found at Applied Compute to making self-distillation work and continual learning work in the enterprise.

And then finally, we'll wrap up and talk about sort of what we've learned. Um, also, I'm going under the assumption that most people have some kind of context on distillation and self-distillation.

I figured by three PM on a continual learning day, you'd had enough of it, so I'm just gonna dive right into it.

Um, so first, I wanna just talk about the distillation spectrum and how we think about the spectrum at Applied Compute.

So, uh, I wanna define this like offline and online distillation spectrum. Um, so we'll start on sort of one end of the spectrum over here, which is offline distillation.

What this looks like is you get a single batch of traces from a production agent, and you're meant to just do something with it, right? Like, how do you learn from a bunch of production traces of some agent out in the wild?

Um, you wanna learn via hindsight. You wanna learn via the mistakes the agent made, um, whatever you can learn from this one-time batch of production da- traces. Um, and this is sort of the offline end of the spectrum.

In the middle, we have something that might look like a daily batch of production traces. So maybe you deploy a model, and then at the end of every day, you collect a bunch of traces, and you figure out, "What can I do with these traces?

How do I make use of these traces?" This is not as offline as a single sort of lump of production traces, but it's not fully online in the sense of all the way on the right here, we have this sort of unified engine of putting inference and training together, right?

And this is sort of the holy grail of continual learning, where I have a model that's serving production traffic. It does a rollout. It creates a trace. We figure out how to learn from that trace.

We update the model, and then we serve the next production request. So there are a bunch of different points along this spectrum where we think this distillation and continual learning can be useful.

But this is how we think about sort of the two ends of the spectrum and how we try and do continual learning across the whole spectrum.

Um, on the left side, on the offline side of traces, this is sort of where a lot of enterprises are today. Basically, they say, "Okay, we have a bunch of production traffic.

We have a bunch of traces. Like, figure out a way to make our agent better. It's clearly doing something, but it clearly can be better." And so how do you make our agent better today given sort of this one-time batch of production traces?

And on the right side, this is sort of the full, complete flywheel, right? This is, uh-- We have some enterprises who are willing to sort of start getting something into production, which looks like this fully online continual learning, where we essentially deploy a model, and then we're able to make updates as the model is serving production traffic.

Um, our goal at Applied Compute is to meet enterprises where they are, right? So they're across this spectrum, and we wanna provide value across both ends of the spectrum.

So this is sort of online and offline distillation, but there's a whole other axis-- There's a whole other axis here we think about, which is hinting, right? So the whole point of distillation is we have some kind of information that allows us to create a teacher model which is smarter than the student model or the on-policy model.

Um, in order to create a teacher that's smarter than this on-policy model, we need to create some kind of hint or s- have some kind of privileged information. And so the question is, where does this hint come from?

So in the offline hinting world, we're deriving hints from some static or offline data. So this can be potentially known rubrics for a single task. It can be general priors about behavior that needs to get better, such as like a customer support agent that is too willing to give refunds, for example, right?

This is some known behavior that you're trying to improve. Um, or it could just be general things that we've seen in production about sort of loss reports and saying, "Oh, the model tends to miss on questions like this."

But it's independent of the online model's rollout. So there's a whole world of creating offline hints from static data.

There's also online hints, right? And so online hinting is-- are hints that are dynamically constructed from the online rollout. The idea here is that we can also inject other pieces of information like behavior priors and things like that.

But the goal is to create a hint that is completely dependent on the online rollout and the online policy that's doing the work.

So we have these two online and offline spectrums. We have hinting, and we have distillation,

which leaves us with a very nice two-by-two grid, right? And so here are sort of like the four types of distillation that we see. And again, these are all spectrums, right?

So I've drawn lines and put things in boxes where boxes sometimes don't make sense as boxes, but more as spectrums. But in general, this is sort of like the, the four quadrants of the continual learning distillation spectrum.

Um, so in the first box, we have an offline hint paired with an offline production trace. So what this looks like is we take a trace from production, and we have some prior about how generally production traces aren't good enough.

Again, maybe customer support is not, uh, is too quick to give refunds, things like that. And we give-- And we construct a hint that we apply to all of these offline production traces.

And then we do this distillation task, and eventually, we sort of create some smarter model from offline hints paired with offline production traces.

In the second quadrant, we have offline hints paired with on-policy and online production traces. So again, what this looks like is we have a hint of a behavior we're trying to improve.

We let an online mo-- uh, let an online agent do a rollout. We inject some hint that we're injecting into all of our rollouts, try and update the policy model, and then continue serving production traffic.

In the third quadrant, we have off-policy traces with some on-policy step and hints that are constructed against that one on-policy step. Um, I'll talk a little bit more about what an on-policy step means later on.

But basically, the idea is that the trace that led to the point where I inject a hint was fully off policy. It was some production, some production trace that came from a few days ago, and we are, we are using our on-policy model to just roll out one step without actually having to interact with the environment, and

we construct the hint based on what that on-policy model did in that one step. So again, we have an offline production trace. We pick a moment in time to do some online step, and then we construct a hint based on what the on-policy model did in that one online step.

And then finally, we have this fourth quadrant, which is sort of online hints with online production traces. So what this means is we have an on-policy model, do a bunch of things in production.

It finishes, we stop, we look at what the on-- uh, the online model did. We then create a hint dynamically from the full rollout that the online model did, and then we construct a hint, and then we do some sort of distillation against this online production trace with an online hint.

So in general, at Applied Compute, we're really, really fo-- Again, we do research across all four quadrants of this, um, sort of table, but we're really focused on quadrant one and quadrant four.

And so quadrant one basically is how we meet enterprises who are, who are ready to have their production agents improve today. Um, and so what this looks like is we don't actually have to have replayability of a production environment, right?

We can take a bunch of production traces, and we just look at what happened, and then we can essentially construct... We have these offline hints for behavior changes that we're trying to target and improve.

Again, not giving refunds quite as often. Um, I'll talk a little bit about formatting things or reasoning, uh, like the amount of reasoning we're trying to encourage. But basically, these are off-policy traces where we inject some offline hint, and this allows us to really target specific behaviors.

On quadrant four, um, this is sort of our most scalable solution to climbing overall evals. Um, so this can be done with either a replayable environment or actually serving production traffic.

And because we're constructing these hints online in a dynamic way, that we can actually cater to a bunch of different behaviors via distillation, right? Um, and this is how we complete this flywheel, where we have an online model serving production traffic, constructing hints online dynamically based on what it did, and then updating our model accordingly.

So again, um, this is sort of our full training taxonomy. Uh, we've done work across all four, and today I'm really gonna focus on quadrant one and quadrant four, which is where we spend most of our time.

Um, in terms of how that grid maps to where value accrues, this is sort of how we think about it. Um, we can improve for free today, and we can raise all ceilings tomorrow.

We can improve for free today by using offline production traces. Give us a dump of your production data, we'll find a way to make it valuable. And then as we deploy an online policy model, that we can then raise the ceilings continuously by updating the model as it's serving production traffic.

Um, and I think the most important thing I wanna call out here is that when we think about how we do this, we wanna do this without having access to some golden answer.

Um, I think this is something that, like, generally frustrates me a lot in the distillation space, is a lot of distillation work is done assuming you have some kind of golden answer that you can distill into the model, and this is often not the case.

Um, and so in general, we wanna think about how we can do continual learning and distillation without having some beautifully golden rubric to accompany every task. Um, as infra collapses between serving and training, we're automatically going to raise the ceiling continuously via online distillation.

So again, we have this spectrum, one time batch of off- offline production data and then online, um, traces, and our goal is to provide value across the full spectrum.

Cool. So let's spend a little bit of time talking about the data and some of the results across these four quadrants.

Um, so in the world of offline traces, offline hint, we have this setup, right, where our goal is to essentially take a Qwen3.5-Thinking model against SWE-bench and get it to submit its reasoning faster than it normally does.

So on SWE-bench, we found that this model was essentially taking, like, up to eighty turns to submit its answer. What we wanted to do was encourage it to call a tool to submit its task before turn [REDACTED:age].

And the reason for that was basically to prove to ourselves that we could get it to sort of wrap up its reasoning quickly by turn [REDACTED:age] without letting it do its normal sort of full reasoning chain.

Um, and so we'll, we'll talk about three metrics here. The first is the task complete rate, which is the percentage of the time that the agent calls this tool to, quote-unquote, "finish a submission."

The second is test pass rate. So this is how we measure the regression in performance on sort of the base task, and this is the percentage of the time that the environment passes all tests accompanying the SWE-bench task, um, irrespective of whether the agent, you know, submitted this-- submitted the task via this tool call.

And then finally, we have our SWE-bench task rate, wh-- or pass rate, which is how we basically combine these two, these two metrics. It's the intersection of those two behaviors.

And so the goal is we wanna raise the SWE-bench pass rate performance while not degrading the test pass rate. Uh, and I've included a, a hint here of what this looks like in practice.

It says something like, "You are near your [REDACTED:age]-turn limit. There's only about three turns left. You have to keep-- You often keep exploring and forget to wrap up." Investigating.

So finalize and verify your fix, and then call this tool before, uh, you run out of time.

So this is what the results look like. Um, so we were able to target the specific behi- behavioral change, which was to call this tool when it wanted to submit a task, and without any degradation to the overall performance.

So you can see that sort of maroon color is the test pass rate. It's relatively constant. In fact, it goes up a little bit. But the task complete call rate increases dramatically from about twenty-two percent to sixty percent.

And so we're able to add this behavior. Um, and I think the, the really interesting, surprising result here is, again, this is in the fully sort of like offline world.

And so we're, we're taking a production trace or a trace that was created ahead of time that never-- basically never called this task complete tool, and we're nudging with the student and, uh, teacher models, uh, the, the, the student model towards calling this task complete tool call without ever specifically changing the tokens for the tool call.

Because again, the rollout is conditioned on the quote-unquote production trace, right? And so it never had the reasoning path to think to call the tool call, and so the teacher doesn't force the tool call.

It just starts to force the, the reasoning path towards the tool call without ever actually changing the tool call, which I think was really cool and surprising to us.

Now, that being said, there actually is like a little bit of a cheat here that we can use, which is that you can-- and as I mentioned earlier, you can roll out just one step from the on-policy model given an offline production trace.

And when we do this, we're obviously see that the student model sort of learns to wrap up its reasoning, and eventually the teacher starts encouraging it to actually call this tool token.

Um, and so you can see by having something that's a little bit more on policy that we're able to increase sort of the SWE-bench pass rate more than in, in the fully offline world.

So again, this is sort of offline trace, offline hint with just one step on policy.

Cool. So then what does it look like in sort of the fully online, online trace, online hint world where it's serving production traffic? So for a certain production use case we had, we needed to teach a coding agent to use very specific formatting for hyperlinks due to a certain harness, certain harness nuance of one of our customers.

And obviously, this coding agent needed to not regress on any of the base coding agent capabilities. Um, now the problem here is that these, these hyperlink formats were very, very out of distribution for previously post-trained models.

And so when we tried things like giving-- inc-- adding a reward for specific hyperlink formatting or even doing SFT on traces where we knew the hyperlink was correctly formatted, we saw that there was this sort of degradation in overall coding agent performance.

Uh, and so what we did here is set this up as an online trace with an online hint.

Um, so basically what this looked like is that we would do a rollout, then we would inject a hint specific to the rollout that occurred from the on-policy model, and then say, "In your prior rollout, you'd formatted hyperlinks like this.

Next time, make sure to hy-- make su-- next time, make sure to format hyperlinks in this way instead." And so what we were able to see is that the percentage of correct hyperlink formatting jumped drastically from about, I guess, fifteen percent all the way up to around eighty percent.

And the other line-- the other, uh, graph here shows what happens if we try to do offline hinting. So this is basically for every single rollout, apply the same hint, which says, "Remember that when you do hyperlinks, you have to format it this way."

Um, and you can see that we do climb the behavior a little bit, but far less than in this online hinting world. So here we've seen sort of like two different results, one where we can use offline hinting and offline traces to climb from production traces, and then another one where we're able to actually use sort of

the on-policiness of the model and online hints to improve a behavior when we're serving production traffic.

Um, okay, cool. I think I have en-enough time here to talk about a little bit of tips and tricks here. Um, so the first is that we found that per-step hinting is dramat-- is very, very important to making distillation work.

Um, so rather than injecting a hint to the beginning of a rollout, we use a judge to essentially decide where in the rollout we should be injecting hints, and then, uh, actually have found that it's best to just do distillation on that next step that occurs or maybe a few steps forward rather than the entire rollout.

Because that's really the turn and the moment in time that you want to have the teacher teach something to the student. Um, I-- you can also see in this graph here that this KL learning signal basically goes down as you get further and further away from the hint, which, which makes sense.

Uh, another trick that we've used is something called Relevance-masked self-distillation. Um, and there's a blog post on our website about how we've done this. But essentially, the idea is that we use an LLM judge to sample and choose which tokens we actually learn from from our teacher-- from our, uh, teacher model.

Um, because often we'll see that the teacher model has preferences of certain connector words that are not really relevant to actually what we're trying to teach the student. And we can see in sort of the graph at the bottom that we're able to increase our ability to learn a very, very out-of-distribution behavior while also being better about

avoiding catastrophic deg-degradation. Cool. So overall, where does that leave us? So obviously, I assume everyone here is sort of on the distillation train, but it's a very, very valuable tool towards continual learning.

We introduced a spectrum of offline and online rollouts, as well as offline and online hinting and how we use them towards distillation. So we use offline hinting with offline production traces to provide value on day one to enterprise clients.

Give us production traces, and we can teach it a certain behavior. We then use online hinting and online production traces to do this highest ceiling sort of continuous learning improvement across multiple improvement areas because that judge is able to adapt to whatever the online model does in production.

And finally, I just wanna say thank you to the team that worked on this. A lot of, lot of the work was done by others. I just kind of got to present it.

Um, and we're hiring and having a lot of fun working on research problems around continual learning. So if you're interested, reach out to [REDACTED:email_address] or, uh, yeah, just email me as well.

So thank you, everyone. [outro music]