<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>BEAR: Budgeted Evidence Allocation for Multi-Document Reasoning · HackerPapers discussions</title><link>https://hackerpaper.kaipfister.de/p/2601.18116/</link><description>Collected HN comments and submissions linking this paper.</description><language>en</language><lastBuildDate>Mon, 02 Nov 2026 11:27:26 GMT</lastBuildDate><atom:link href="https://hackerpaper.kaipfister.de/p/2601.18116/feed.xml" rel="self" type="application/rss+xml" /><item><title>BEAR: Budgeted Evidence Allocation for Multi-Document Reasoning — HN submission</title><link>https://news.ycombinator.com/item?id=47689633</link><guid isPermaLink="false">urn:hackerpapers:submission:2601.18116:47689633</guid><pubDate>Wed, 08 Apr 2026 13:05:23 GMT</pubDate><description>&lt;p&gt;Show HN: OpenFable – Open-source RAG engine using tree-structured indexes&lt;/p&gt;&lt;p&gt;Hi HN, I built OpenFable, an open-source retrieval engine that implements the FABLE algorithm (https://arxiv.org/abs/2601.18116) for RAG pipelines. I&amp;#x27;m using it in another project and thought that others might benefit. Most RAG systems chunk documents into flat segments and retrieve by vector similarity. This works for simple lookups but breaks when answers span multiple sections, when relevant content is buried in a subsection, or when you need to control how many tokens you&amp;#x27;re sending to an LLM. OpenFable takes a different approach: when you ingest a document, it uses an LLM to identify…&lt;/p&gt;&lt;p&gt;5 points; 0 discussion replies on HN. &lt;a href="https://hackerpaper.kaipfister.de/p/2601.18116/"&gt;Paper and source history&lt;/a&gt;. A submission is not an endorsement.&lt;/p&gt;</description><category>cs.CL</category></item></channel></rss>
