<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Seq vs Seq: An Open Suite of Paired Encoders and Decoders · HackerPapers discussions</title><link>https://hackerpaper.kaipfister.de/p/2507.11412/</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/2507.11412/feed.xml" rel="self" type="application/rss+xml" /><item><title>Seq vs Seq: An Open Suite of Paired Encoders and Decoders — mentioned by ubutler</title><link>https://news.ycombinator.com/item?id=44709629</link><guid isPermaLink="false">urn:hackerpapers:mention:2507.11412:44709629</guid><pubDate>Mon, 28 Jul 2025 11:12:17 GMT</pubDate><description>&lt;p&gt;Further to @dust42, BERT is an encoder, GPT is a decoder, and T5 is an encoder-decoder. Encoder-decoders are not in vogue. Encoders are favored for classification, extraction (eg, NER and extractive QA) and information retrieval. Decoders are favored for text generation, summarization and translation. Recent research (see, eg, the Ettin paper: https://arxiv.org/html/2507.11412v1 ) seems to confirm the previous understanding that encoders are indeed better for “encoder task” and vice-versa. Fundamentally, both are transformers and so an encoder could be turned into a decoder or a decoder could…&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/2507.11412/"&gt;Paper and discussion history&lt;/a&gt;. A mention is not an endorsement.&lt;/p&gt;</description><category>cs.CL</category></item></channel></rss>
