I wonder how well this would translate with a much larger model. They ran the experiments with comparatively tiny models. You would presumably need to churn a lot more tokens to move the needle of a multi-trillion-parameter model's weights. It might just be that it's not that hard to improve Llama-3B and Llama 3-8B because they're not very good to begin with. They compare it to other methods - in-context learning and TTT - but I'd be curious to see it compared to a "control group" of RLHF.
As an aside, I get that this is a preprint, but it's very odd to see a piece of writing with obvious typos and grammar issues (e.g. page 13: "We attributes this results to," "In this setting (see Table 4), Sleep achieves a 80% success rate, higher then the other methods.") in an era with LLMs. It sort of locks in that this was written by human beings, and I'm all for that, but it jumps out at me more than it used to.
> On-policy distillation: The expanded student model learns token-specific feedback from teacher distributions generated on self-sampled sequences.
The weird thing is to see this based off the KV-Cache in the diagrams.
Completely different from the Databricks RAFT [1].
My team built "Dreamtime" earlier this year [2], which used a different mechanism to distill out learnings across multiple sessions.
This didn't pull from the token layer, but from user nudges on unsatisfactory responses.
This works like a sawtooth wave where we accumulate context, check for dissonances (a user gets to say "It depends" and fix it), compress it back, retire the old one.
The audit requirements are the real problem for customers, where you need to be able to ask "When did this change? and who changed it?" which was hard to answer from the lowest layer of the model unless you can retain lineage to the original sessions.
A model we train can't serve as an accomplice to a user who wants to hide some financial crimes by nudging the agent repeatedly.
I know we just had the carbon announcement which was distinctly confusing, but comparatively I think that this is an exceptionally well-written article. I do believe that Google has some exceptional scientific minds as illustrated by their ability to take highly technical concepts and explain them in an understandable way for the layperson.
As for the technical nature of this, I'm not sure if I've totally understood correctly despite how well it's written, but are they essentially holding back sort of unweighted parameters built in to the model architecture which they can then populate with new context during 'sleep' and then using the techniques outlined in the 'dream' section to reinforce what gets stored in those MoE weights? That to me seems like a solution which only Google is best placed to solve due to their fully integrated AI stack and historic experience with hardware optimisation, but which would be rather hard to do if you are a more resource and compute constrained organisation
> are they essentially holding back sort of unweighted parameters built in to the model architecture which they can then populate with new context during 'sleep' and then using the techniques outlined in the 'dream' section to reinforce...
Sort of. As the model is interacted with, short term "memories" are accumulated in a sort of buffer/cache. During "sleep" these "memories" are given a ranking/score, and the useful bits are integrated into the weights.
They say the weight update can be done by computing a transform where the end state is the old weights with the addition of the useful semantic knowledge contained in memories. Rather than just additively chucking the entire memory concepts into weights. That's pretty neat.
The subtext for the memory architecture diagram sums the whole thing up pretty tidily I think:
> Input streams from the active phase are stored in short-term memory before entering the sleep cycle, which bifurcates into Consolidation (transferring fragile short-term tokens into expanded long-term parametric memory using low-rank structures and MoE) and Dreaming (autonomous self-improvement via synthetic routing with random experts and RL refinement).
As an aside, I get that this is a preprint, but it's very odd to see a piece of writing with obvious typos and grammar issues (e.g. page 13: "We attributes this results to," "In this setting (see Table 4), Sleep achieves a 80% success rate, higher then the other methods.") in an era with LLMs. It sort of locks in that this was written by human beings, and I'm all for that, but it jumps out at me more than it used to.
The weird thing is to see this based off the KV-Cache in the diagrams.
Completely different from the Databricks RAFT [1].
My team built "Dreamtime" earlier this year [2], which used a different mechanism to distill out learnings across multiple sessions.
This didn't pull from the token layer, but from user nudges on unsatisfactory responses.
This works like a sawtooth wave where we accumulate context, check for dissonances (a user gets to say "It depends" and fix it), compress it back, retire the old one.
The audit requirements are the real problem for customers, where you need to be able to ask "When did this change? and who changed it?" which was hard to answer from the lowest layer of the model unless you can retain lineage to the original sessions.
A model we train can't serve as an accomplice to a user who wants to hide some financial crimes by nudging the agent repeatedly.
[1] - https://arxiv.org/abs/2403.10131
As for the technical nature of this, I'm not sure if I've totally understood correctly despite how well it's written, but are they essentially holding back sort of unweighted parameters built in to the model architecture which they can then populate with new context during 'sleep' and then using the techniques outlined in the 'dream' section to reinforce what gets stored in those MoE weights? That to me seems like a solution which only Google is best placed to solve due to their fully integrated AI stack and historic experience with hardware optimisation, but which would be rather hard to do if you are a more resource and compute constrained organisation
They say the weight update can be done by computing a transform where the end state is the old weights with the addition of the useful semantic knowledge contained in memories. Rather than just additively chucking the entire memory concepts into weights. That's pretty neat.
The subtext for the memory architecture diagram sums the whole thing up pretty tidily I think: