<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>SPLATE: Sparse Late Interaction Retrieval · HackerPapers discussions</title><link>https://hackerpaper.kaipfister.de/p/2404.13950/</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/2404.13950/feed.xml" rel="self" type="application/rss+xml" /><item><title>SPLATE: Sparse Late Interaction Retrieval — mentioned by jbellis</title><link>https://news.ycombinator.com/item?id=43927019</link><guid isPermaLink="false">urn:hackerpapers:mention:2404.13950:43927019</guid><pubDate>Thu, 08 May 2025 15:24:52 GMT</pubDate><description>&lt;p&gt;I&amp;#x27;m kind of disappointed in this article, Splade is a cool way to improve results of a TF/IDF index with minimally invasive changes and this obscures that more than it clarifies. &amp;gt; Next, my SPLADE implementation in Elasticsearch is oversimplified. If you scroll back up to get_splade_embedding, we extract non-zero elements from vec_np (the SPLADE tokens) but discard their associated weights. This is a missed opportunity. The SPLADE papers use these weights for scoring matches. Yes, exactly, that is the whole point of Splade. Probably easier to demonstrate if you drop down a level to Lucene, I…&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/2404.13950/"&gt;Paper and discussion history&lt;/a&gt;. A mention is not an endorsement.&lt;/p&gt;</description><category>cs.IR</category></item></channel></rss>
