{"id":"ae821f25-ea97-4d18-a979-70c92d81d083","arxiv_id":"2608.12129","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":7.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":8,"one_line_summary":"SAG represents document chunks as event-entity rows and uses query-time SQL joins over shared entities to activate multi-hop evidence chains, achieving state-of-the-art Recall@5 on three multi-hop QA benchmarks.","lead":"The paper introduces SAG, a retrieval system that stores document chunks as events linked to entities in a database and uses SQL joins at query time to connect related chunks. It reports large gains over existing retrieval methods on multi-hop question-answering benchmarks, especially on the hardest four-hop dataset.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Headline retrieval comparison confounds SQL-join expansion with an answer-aware LLM selector; SAG's Recall@5 lead over HippoRAG 2 may largely reflect the selector, not the event-entity index.","rationale":"The paper's strongest claim is the Recall@5 table, and Section 5.1 explicitly frames it as an architecture-only comparison. That framing is the load-bearing point, and it is not supported: SAG's pipeline spends a large LLM budget on a contextual final selection that no baseline receives. The ablation data make the magnitude clear—removing or weakening the selector costs 13–24 Recall@5 points—so the headline margin over HippoRAG 2 (65.13) could largely be the selector rather than the dynamic hyperedge joins. This does not mean SAG is uninteresting; the expansion ablation (10.95 points) and the embedding-robustness analysis (Figure 3a) provide real evidence that the structured index contributes. But those contributions are not isolated in the headline comparison. The alias limitation is acknowledged by the authors and is a generalization concern; it would not change the benchmark results. The concrete test I propose—reporting SAG Recall@5 before the LLM selector, or equivalently giving HippoRAG 2 the same selector—would settle whether the architecture claim is real. Because this is an addressable evaluation gap rather than an internal contradiction, the conditional verdict stands.","tokens_in":24308,"tokens_out":7127,"duration_ms":62866,"concrete_test":"Compute SAG Recall@5 on MuSiQue using only Eq. 4 coarse ranking (top-5 by embedding similarity over the expanded candidate set, no LLM final selection) and compare it to HippoRAG 2's 65.13. If SAG's pure retrieval recall is at or below HippoRAG 2, the claimed retrieval advantage is largely attributable to the answer-aware LLM selector rather than the SQL-join hyperedge expansion.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central retrieval claim is not cleanly identified with the SQL-join architecture. Section 5.1 states that in Table 1 'architecture is the only free variable,' but SAG's retrieval stage includes an answer-aware LLM selector (Section 3.4, Eq. 5) that reads up to K_cand=100 candidate events and returns up to five; HippoRAG 2 and the other baselines do not receive this selector. Table 6 shows this choice matters enormously: replacing the Qwen3.6-Flash selector with Qwen3-Reranker-8B drops Recall@5 by 13.25 points (80.36 to 67.11), and disabling structural output entirely (K_event=0) drops it to 56.23. The paper never reports SAG Recall@5 from the embedding-ranked expanded candidate set before LLM selection, and never gives HippoRAG 2 the same selection stage. The headline 11.52-point margin over the 'strongest baseline' also disagrees with Table 1's 15.23-point margin over HippoRAG 2, indicating the baseline used for the headline number is ambiguous. The alias limitation in Section 5.3 is real but secondary; the selection confound directly affects whether the reported retrieval gains are due to the event-entity SQL joins or to the LLM reading the question and candidates.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes SAG, a retrieval architecture for multi-hop QA that combines an append-only SQL event-entity index with dense retrieval and LLM-based final selection. Each corpus chunk is mapped to a single 'event' and a set of typed entity strings, stored as incidence rows; at query time, candidate events are obtained by dense seed retrieval and by SQL joins over shared entities, expanded for one round, coarsely ranked, and finally selected by an LLM that reads up to 100 candidate events and returns up to five. The selected events map back to original chunks, which are returned as evidence. Experiments on MuSiQue, 2WikiMultiHopQA, and HotpotQA report the best Recall@5 and QA F1 among the compared baselines, with ablations on expansion depth, candidate budget, dual-path output, and the final selector, as well as robustness checks across embedding models and corpus growth. The appendix formalizes the latent-hyperedge incidence representation and reports connectivity statistics, runtime, prompts, and additional QA results on NarrativeQA.","tokens_in":24581,"tokens_out":5768,"duration_ms":50155,"significance":"If the reported gains are attributable to the proposed architecture, SAG would be a practical contribution: it avoids a materialized global knowledge graph, supports append-only ingestion, and provides traceable retrieval stages. The paper deserves credit for a clearly described pipeline, systematic ablations that separate indexing, expansion, and selection, a reproducible benchmark code release, and an unusually candid limitations section. The formal propositions in Appendix A are simple definitional statements, but they are not used to derive the empirical results, so circularity is low. The main risk is experimental identification: the headline retrieval comparison does not cleanly isolate the effect of the SQL event-entity index from the effect of the answer-aware LLM selector, and the 2WikiMultiHopQA result was chosen after tuning on the same dev set on which it is reported. These issues are fixable with additional experiments, and the paper's core ideas are defensible, so I recommend major revision.","major_comments":[{"comment":"The claim that 'architecture is the only free variable' (Section 5.1) is not supported by the comparison as presented. SAG's retrieval stage includes an answer-aware LLM selector that reads the question and up to K_cand=100 candidate events and returns at most five (Section 3.4, Eq. 5), whereas HippoRAG 2 and the other baselines rank candidates by embedding or PageRank scores without this selector. Table 6 shows the selector is worth 13.25 Recall@5 points on MuSiQue (80.36 with Qwen3.6-Flash versus 67.11 with Qwen3-Reranker-8B), which is larger than the 11.52-point or 15.23-point headline margins. The manuscript never reports SAG's Recall@5 from the embedding-ranked expanded candidate set before LLM selection, nor does it give HippoRAG 2 the same selection stage. To attribute the measured gains to the event-entity SQL-join index, the authors should report the pre-selection Recall@5 of SAG and apply the same context-aware selection to baselines' top candidates.","section":"§5.1 and Table 6; §3.4, Eq. (5)"},{"comment":"The 2WikiMultiHopQA headline result is obtained by a design decision made after observing the same 1,000-question dev sample that is then reported. Section 5.1 states that the initial design achieved 88.00% Recall@5, that this failure was revealed by traceable intermediate states, and that pruning during expansion raised the score to 93.34%, which is the number in Table 1. Because the 2Wiki result and the pruning modification were selected on the same dev questions, the main-table figure is not an unbiased estimate of expected performance. The authors should validate the final configuration on a separate split, or report the before/after comparison with error bars or an explicit model-selection caveat, before claiming best retrieval on every benchmark.","section":"§5.1 (2WikiMultiHopQA note), §4.1"},{"comment":"The architecture's join mechanism depends on exact string equality after normalization, as acknowledged in Section 5.3, where 'Apple Inc.' and 'Apple' are not matched. This is not a peripheral implementation detail: shared entities are the only join keys, so every recall gain from SQL expansion is conditional on surface-form consistency across documents and queries. The limitation statement is honest, but the magnitude of the effect on the reported gains is unknown. I would like to see a quantitative analysis, such as the change in Recall@5 when common aliases are normalized or when a small alias table is added, so readers can judge how the result transfers to corpora without canonical surface forms.","section":"§3.1 and §5.3"}],"minor_comments":[{"comment":"The abstract says SAG outperforms the strongest baseline by 11.52 points, while Section 5.1 reports a 15.23-point lead over HippoRAG 2 on MuSiQue; the abstract's number is consistent with comparing against NV-Embed-v2 (80.36 - 68.84 = 11.52), but the paper should state explicitly which baseline the abstract refers to and use consistent terminology.","section":"Abstract and §5.1"},{"comment":"The first row of Table 6 ('Default SAG (Ours) 4') appears to contain a stray '4' from the footnote; this formatting error should be corrected.","section":"Table 6"},{"comment":"Several structure-augmented baselines are marked with a dash in Recall@5 columns, yet the Avg row appears to include values from methods without reported Recall@5; the averaging rule should be stated explicitly in the table caption.","section":"Table 1"},{"comment":"The QA context formats differ across methods (raw passages versus CSV entity-relationship summaries). Section 5.1 and Table 9 should mention this difference whenever LLM-judge context-relevancy scores are discussed, since the text already notes it in Appendix L but not in the main results.","section":"Appendix L, Table 12"}],"recommendation":"major_revision","confidential_remarks":"The paper has a solid engineering story and the ablation structure is a strength, but the central retrieval claim needs a controlled comparison that separates the SQL-join index from the answer-aware LLM selector. The 2Wiki dev-set tuning should also be disclosed more prominently or validated on a held-out split. I would not reject the paper, because the ablations show that expansion alone still leaves SAG above HippoRAG 2 on MuSiQue, and the robustness analyses are informative. Please request the additional experiments described in the major comments."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"First thing to know: SAG is a genuinely new retrieval design—append-only event–entity incidence rows, query-time SQL joins that activate a local hyperedge neighborhood, no global knowledge graph—and the paper is worth reading. The reported numbers are not what they appear, though. The headline MuSiQue Recall@5 margin mostly comes from an answer-aware LLM selector that baselines don't receive, not from the SQL-join index.\n\nWhat it does well: the event-as-hyperedge idea is clean, the ablation isolates expansion, indexing, and selection, and the robustness results (embedding swap, corpus growth, bounded candidate pool) are useful. The authors ship benchmark and engineering code, and they are unusually honest: they describe the 2Wiki failure and fix, and they list the alias limitation. The formalization in Appendix A is fine but definitional; it doesn't add empirical weight.\n\nSoft spots, in proportion. The biggest one is a confound in the retrieval comparison. Section 5.1 says 'architecture is the only free variable,' but SAG's pipeline includes a final LLM selection step that reads up to 100 candidate events plus the query and picks five. HippoRAG 2 and the other baselines don't get that. Table 6 shows the effect: swapping the Qwen3.6-Flash selector for Qwen3-Reranker-8B drops R@5 by 13.25 points, to 67.11, and setting K_event=0 drops it to 56.23. The 11.52-point headline margin is over NV-Embed-v2, whose R@5 is 68.84, so nearly all of it is the selector, not the joins. To be fair, SAG with the weaker reranker still beats HippoRAG 2 by about two points, so the index contributes something real but much smaller. The authors should report pre-selection recall from the expanded candidate set and give HippoRAG 2 the same selector.\n\nSecond, the 2Wiki result was diagnosed and fixed on the same dev set used for reporting, and there are no error bars. That's a standard weakness, but it matters more here because the final configuration was chosen after seeing dev. Third, the alias limitation is acknowledged and is secondary.\n\nOne correction to the stress-test note: the 'strongest baseline' is not ambiguous. NV-Embed-v2 has the best baseline R@5 on MuSiQue (68.84), so 80.36 − 68.84 = 11.52 is consistent. The 15.23-point number is vs HippoRAG 2.\n\nBottom line: this deserves a serious referee, but not as-is. The authors need to separate retrieval index from selection, add a held-out test, and run baselines with an equivalent selector. I wouldn't cite it in my own work, but I'd put it on a reading-group agenda.","headline":"SAG is a genuinely new retrieval architecture with big reported gains, but the headline recall number leans heavily on an answer-aware LLM selector that the baselines don't get; the SQL-join core still shows a real but smaller edge.","tokens_in":25174,"tokens_out":3832,"would_cite":false,"duration_ms":31826,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"SQL joins replace knowledge graphs for multi-hop retrieval","keywords":["retrieval-augmented generation","multi-hop question answering","SQL join retrieval","latent hyperedge","event-entity index","knowledge-graph-free RAG","append-only indexing","query-time expansion"],"falsifier":"Construct a two-hop QA set whose bridge entity appears in the gold passages under two different surface forms (e.g., 'Apple Inc.' in one passage and 'Apple' in the other). If SAG's Recall@5 on those questions is not meaningfully above a dense-only retriever, then the shared-entity join mechanism does not generalize beyond normalized surface forms.","tokens_in":24068,"feed_emoji":"🔗","tokens_out":6068,"duration_ms":44753,"temperature":0.7,"pith_summary":"The paper claims that multi-hop retrieval does not need a global knowledge graph: the associative structure can be latent in how chunks are indexed. It proposes SAG, which stores each chunk as a self-contained event linked to the entities it mentions, so the event and its entities form a latent hyperedge. At query time, SQL joins over shared entities dynamically connect related events, and the original chunks are returned as evidence. Across HotpotQA, 2WikiMultiHopQA, and MuSiQue, SAG reports the best retrieval and end-to-end QA scores under a unified setup; on MuSiQue, the hardest benchmark, it reaches 80.36% Recall@5, 11.52 points above the strongest baseline. If the claim holds, the architecture offers an append-only index, no offline graph reconstruction, bounded per-query cost, and gains that grow as reasoning chains get longer.","feed_headline":"SQL joins replace knowledge graphs for multi-hop retrieval","feed_subtitle":"Chunks indexed as event–entity hyperedges reach 80.36% Recall@5 on MuSiQue, 11.52 points above the strongest baseline.","key_machinery":"The central object is the latent hyperedge carried by the event–entity index. Each event h is stored as incidence rows (h,v) for every entity v in V(h); grouping rows by event reconstructs the full entity set, so the representation is lossless with respect to incidence. This makes a SQL join the mechanism that walks from query entities to events and back, performing event-to-entity-to-event expansion through the bipartite incidence graph. The key machinery does two jobs: it preserves each chunk's n-ary relation as one retrieval unit, and it makes the connective structure query-time and append-only rather than a materialized corpus-level graph.","core_discovery":"On its own terms, the paper's discovery is that a corpus of chunks can be reorganized as an event–entity index in which each chunk is represented by one semantically complete event and a set of indexing entities; because an event keeps all its entities together, it behaves as a hyperedge and preserves n-ary relations without triple decomposition. Retrieval then proceeds by activating only the hyperedges relevant to the query: an LLM identifies query entities, a SQL join retrieves all events sharing those entities, and a reverse join expands through intermediate entities for a bounded number of rounds. The result is a query-scoped neighborhood of events whose evidence is always the original chunk. The paper reports that this design achieves the best Recall@5 and QA F1 on MuSiQue, 2WikiMultiHopQA, and HotpotQA, with the margin over baselines widening as chain complexity increases.","pith_inferences":["The explicit no-disambiguation design suggests the reported numbers are a lower bound for what the architecture could achieve: adding a lightweight alias table (as the paper itself suggests) could recover bridge evidence that string matching currently misses.","Because the index is relational rows rather than a graph, the same structure could be maintained with any SQL store and versioned with temporal tables, which would let stale events be retired without losing history.","The mechanism is not limited to fact-chaining: the narrative-QA result hints that event-entity grouping helps whenever evidence must be assembled across a long text, so similar gains might appear in book-level or dialogue retrieval tasks.","A testable extension is to replace exact SQL joins with fuzzy entity matching only at the join frontier, which would trade a little precision for alias robustness while keeping the append-only property."],"forward_implications":["Because evidence never leaves the original chunk, the reader sees exactly the document text, keeping provenance and context intact.","The reported gains grow with chain depth: two-hop HotpotQA shows the smallest margin and four-hop MuSiQue the largest, suggesting shared-entity joins matter most when evidence is far apart.","Append-only indexing means new documents can be added without rebuilding any global structure, which is the property needed for continuously growing corpora.","Bounded activation budgets (a corpus pool, a frontier budget, and a candidate cap) keep the expensive LLM stages confined to a query-specific working set, so per-query cost need not grow with corpus size.","The advantage persists across four different embedding models, indicating the improvement comes from the structured expansion rather than from encoder quality."],"supporting_citations":[{"why":"Supplies the strongest structure-augmented baseline (HippoRAG 2) and the evaluation protocol for sampling, corpora, and corpus-growth setup that SAG must beat.","marker":"(Gutiérrez et al., 2025)"},{"why":"Defines MuSiQue, the four-hop benchmark where SAG reports its largest gains and whose counterfactual filtering makes evidence chaining demanding.","marker":"(Trivedi et al., 2022)"},{"why":"Defines HotpotQA, the two-hop benchmark used to show that the margin narrows as chain complexity decreases.","marker":"(Yang et al., 2018)"},{"why":"Defines 2WikiMultiHopQA, the inference-type benchmark where pruning during expansion raised Recall@5 from 88.00% to 93.34%.","marker":"(Ho et al., 2020)"},{"why":"Represents the offline graph-based approach (GraphRAG) that SAG contrasts with; its QA score is the strongest F1 baseline on MuSiQue among the structure-augmented family.","marker":"(Edge et al., 2024)"},{"why":"Supplies the hypergraph baseline HyperGraphRAG and the formal notion of lossless incidence encoding that SAG adapts to latent hyperedges.","marker":"(Luo et al., 2025)"},{"why":"Provides the graph-indexing evaluation protocol and LLM-as-a-judge metrics used for connectivity analysis and QA evaluation.","marker":"(Xiang et al., 2025)"}],"fun_headline_variants":["Query-time dynamic hyperedges boost multi-hop RAG","SQL joins replace knowledge graphs for multi-hop retrieval","SAG: SQL retrieval with dynamic hyperedges for multi-hop QA","Event-entity SQL retrieval bests knowledge graphs on multi-hop QA","Dynamic hyperedges from SQL joins beat static graphs"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The load-bearing premise is that the same entity is always spelled the same way after normalization, so exact string equality can serve as the join key; if real corpora use aliases like 'Apple Inc.' versus 'Apple', the SQL joins will silently miss the bridge evidence and the reported recall gain should shrink.","fun_headline_variants_meta":{"raw":{"variants":["Query-time dynamic hyperedges boost multi-hop RAG","SQL joins replace knowledge graphs for multi-hop retrieval","SAG: SQL retrieval with dynamic hyperedges for multi-hop QA","Event-entity SQL retrieval bests knowledge graphs on multi-hop QA","Dynamic hyperedges from SQL joins beat static graphs"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000273,"raw_usage":{"total_tokens":1655,"prompt_tokens":985,"completion_tokens":670,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":601,"completion_tokens_details":{"reasoning_tokens":590}},"tokens_in":601,"tokens_out":670,"duration_ms":5653,"temperature":1.0,"reasoning_tokens":590,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-16T00:14:44.900814+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Construct a two-hop QA set whose bridge entity appears in the gold passages under two different surface forms (e.g., 'Apple Inc.' in one passage and 'Apple' in the other). If SAG's Recall@5 on those questions is not meaningfully above a dense-only retriever, then the shared-entity join mechanism does not generalize beyond normalized surface forms.","supporting_citations":[],"review_version":1}