Lo and behold, a nice arithmetic coding implementation that wasn't written by an LLM! A sight for sore eyes – a treat, even. Looks like it was written by someone else though.
Haha. Unfortunately is my regular voice, since long before I started using Codex. You can check through some of my old writing. It definitely could've gotten worse though. Not sure if I'm training on Codex, or Codex is training on me...
This is certainly part of it! My point was that focusing on problems proposed by others is one very specific and pretty short-term mode of thinking. Good researchers improve benchmark scores. Great researchers think about what problem they're solving.
Incredible concept and a very well-crafted site. I scored very low, but then very high with my legal name. It seems DeepSeek knows a lot of arxiv papers (or at least, about the authors).
> The app does absolutely no work in the background. It works by simply existing as a running process, thanks to having the same bundle identifier as the Music app.
I love clever, low-or-no-code engineering solutions like this. You typically need to understand a systems very deeply to reach this level of elegance. In this case, one has to understand exactly what happens when the play button is pressed in Mac OS, how bundle identifiers work, etc. And the outcome is an app with almost no code at all – just a collision – it's beautiful.
(As an aside, coding agents are terrible at this kind of thing; I'd guess Codex as of right now would write some overpowered application that polls in a loop looking for Music App starts and killing them)
It's great that people are starting to take continual learning seriously, and it seems like Jessy has been thinking about LLMs and continual learning longer than almost anyone.
I especially like this taxonomy
> I think of continual learning as two subproblems:
> Generalization: given a piece of data (user feedback, a piece of experience, etc.), what update should we do to learn the “important bits” from that data?
> Forgetting/Integration: given a piece of data, how do we integrate it with what we already know?
My personal feeling is that generalization is a data issue: given a datapoint x, what are all the examples in the distribution of things that can be inferred from x? Maybe we can solve this with synthetic datagen. And forgetting might be solvable architecturally, e.g. with Cartridges (https://arxiv.org/abs/2506.06266) or something of that nature.
It seems to be an error with the classifier. Sorry everyone. I probably shouldn't have posted that graph; I knew it was buggy, I just thought that the Perl part might be interesting to people.
Hi again. I had already written about this later in my blog post (which is unrelated to this thread), but the point was that RLHF hadn't been applied to language models at scale until InstructGPT. I edited the post just now to clarify this. Thanks for the feedback!
I recently wrote a post about scaling RL that has some similar ideas:
> How to Scale RL to 10^26 FLOPs (blog.jxmo.io/p/how-to-scale-rl-to-1026-flops)
The basic premise behind both essays is that for AI to make another big jump in capabilities, we need to find new data to train on.
My proposal was reusing text from the Internet and doing RL on next-token prediction. The linked post here instead suggests doing 'replication training', which they define as "tasking AIs with duplicating existing software products, or specific features within them".
Hey, I appreciate the perspective. We definitely should cite both those papers, and will do so in the next version of our draft. There are a lot of papers in this area, and they're all a few years old now, so you might understand how we missed two of them.
We tested all of the methods in the Python Optimal Transport package (https://pythonot.github.io/) and reported the max in most of our tables. So some of this is covered. A lot of these methods also require a seed dictionary, which we don't have in our case. That said, you're welcome to take any number of these tools and plug them into our codebase; the results would definitely be interesting, although we can expect the adversarial methods still work best, as they do in the problem settings you mention.
As for the name – the paper you recommend is called 'vecmap' which seems equally general, doesn't it? Google shows me there are others who have developed their own 'vec2vec'. There is a lot of repetition in AI these days, so collisions happen.