<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Jumping Ahead: Improving Reconstruction Fidelity with JumpReLU Sparse Autoencoders · HackerPapers discussions</title><link>https://hackerpaper.kaipfister.de/p/2407.14435/</link><description>Collected HN comments and submissions linking this paper.</description><language>en</language><lastBuildDate>Mon, 02 Nov 2026 11:16:22 GMT</lastBuildDate><atom:link href="https://hackerpaper.kaipfister.de/p/2407.14435/feed.xml" rel="self" type="application/rss+xml" /><item><title>Jumping Ahead: Improving Reconstruction Fidelity with JumpReLU Sparse Autoencoders — mentioned by tMcGrath</title><link>https://news.ycombinator.com/item?id=42496647</link><guid isPermaLink="false">urn:hackerpapers:mention:2407.14435:42496647</guid><pubDate>Mon, 23 Dec 2024 18:45:36 GMT</pubDate><description>&lt;p&gt;We&amp;#x27;re planning to release the weights once we do a moderation pass. Our SAE was trained on LMSys (you can see this in our accompanying post: https://www.goodfire.ai/papers/mapping-latent-spaces-llama/). No images in training - 3.3 70B is a text-only model so it wouldn&amp;#x27;t have made sense. We&amp;#x27;re exploring other modalities currently though. SAE is a basic ReLU one. This might seem a little backwards, but I&amp;#x27;ve been concerned by some of the high-frequency features in TopK and JumpReLU SAEs and the recent SAE (https://arxiv.org/abs/2407.14435, Figure 14), and the recent SAEBench results…&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/2407.14435/"&gt;Paper and discussion history&lt;/a&gt;. A mention is not an endorsement.&lt;/p&gt;</description><category>cs.LG</category></item></channel></rss>
