SAG Paper V2 Is Here

Paper: https://arxiv.org/abs/2606.15971

Hi, I am Jomy. Today we are releasing V2 of the SAG paper.

Since V1, we have improved pruning during expansion and added more complete experiments on the mechanism, results and scalability.

SAG now achieves state-of-the-art Recall@5 and end-to-end question-answering F1 on MuSiQue, 2WikiMultiHopQA and HotpotQA. Its only lagging result in V1, 2WikiMultiHopQA, rose from 88.00% to 93.34%.

I will also address the questions and concerns people have raised most often.

State of the Art Across the Board

Evidence Recall@5 and end-to-end question-answering F1 under the same settings.

SAG's Recall@5 is 80.36%, 93.34% and 96.50% on MuSiQue, 2WikiMultiHopQA and HotpotQA, respectively, averaging 90.07%.

Using the same answer-generation model, its F1 scores are 61.15, 78.06 and 79.66, averaging 72.96. All three are state-of-the-art results.

After V1, some readers asked whether SAG overfit MuSiQue. We emphasize MuSiQue because it includes reasoning chains of up to four hops and counterfactual filtering, making it the hardest of the three datasets.

We reran most mainstream RAG frameworks under consistent settings. SAG led across all three datasets in both Recall@5 and end-to-end F1. It also performed best in comparisons on several private production datasets.

The benchmark code is open source for reproduction. You can also try the product.

How SAG Works

Event–entity relationships are stored offline; related events are expanded at query time, and original chunks are returned.

SAG splits documents into chunks. Each chunk undergoes two operations: it becomes a semantically complete event, and its people, organizations, places, products and other entities are extracted.

The event preserves what the passage says. Entities connect related events across documents. Both are stored in SQL, vector and full-text indexes. Each chunk can be processed independently. New data is appended without recomputing existing data.

At query time, SAG follows two routes: finding events through entities in the question, and finding events through the question's meaning directly. It then expands the initial events through shared entities.

Selected events are mapped back to the original chunks for answer generation. Events locate evidence; answers remain grounded in source text. Generated answers are not automatically written into the index.

Is SAG Just a Knowledge Graph Stored in SQL?

SAG does build a graph, but uses dynamic hyperedges rather than traditional triples.

Traditional knowledge graphs use subject–relationship–object triples. An event involving several people, organizations, locations and times is often split into many relationships. SAG uses a semantically complete event as the unit connecting multiple entities.

That is the fundamental distinction and our core innovation.

SQL executes relationship queries. Events and entities form a many-to-many relation. Two events sharing an entity have a connection that a JOIN can find. SQL does not create semantics; the event–entity organization does.

Why is this feasible now? LLMs can reliably turn chunks into semantically complete events and extract enough entities. Earlier NER and triple extraction struggled to preserve complete meaning and cross-document connections simultaneously.

V2 compares isolated nodes, connected components and the largest connected component to test whether dynamic hyperedges cover more content with fewer connections.

On MuSiQue, SAG has only one isolated node among 95,341 nodes, about 0.001%, and its largest connected component covers 96.7%. HippoRAG 2 has approximately 4.5 times as many connections but still has 59 isolated nodes.

One event can connect several entities. SAG therefore brings almost all content into an expandable index with lower connection density.

Multiple database rows are simply the physical storage of a hyperedge. A common event_id reconstructs its complete entity set. At query time, only the small subset of hyperedges relevant to the question is used. That is what “dynamic” means.

LLM Wiki remains fundamentally a summary index: it finds documents by summaries or tags, then hands large amounts of text to an LLM for reading, filtering and reasoning. As data grows, so do context size, token cost and dependence on model capability.

SAG continues retrieval before handing evidence to the model. It follows shared entities to new events and returns the source passages that support an answer. The LLM handles a smaller, more relevant context. More work happens in data organization and retrieval.

Can One Expansion Layer Handle Multi-Hop Questions?

V2 includes two experiments. One disables expansion to test whether it recovers multi-hop evidence. The other varies expansion depth from L=0 to L=4 to compare one layer with deeper expansion.

First, disabling expansion:

MuSiQue Recall@5 falls from 80.36% to 69.41%, while Recall@1 changes only from 36.82% to 35.70%. Seed retrieval typically finds the first evidence passage; expansion retrieves the subsequent bridging evidence.

One expansion layer extracts entities from seed events and finds new events through those entities. Dynamic hyperedges retain all entities in the same event, making this expansion more informative.

Replacing hyperedges with independent triples while keeping seed retrieval, expansion and final selection unchanged reduces Recall@5 from 80.36% to 77.61%. Hyperedges represent the information better, while the remaining retrieval mechanisms limit the overall loss.

Replacing joint LLM selection with individual scoring by Qwen3-Reranker-8B reduces Recall@5 to 67.11%. Expansion gathers multi-hop material; the LLM selects candidates that form a complete evidence chain.

Next, we vary depth from L=0 to L=4, along with the candidate event budget and the number of structural paths returned.

Increasing depth from L=1 to L=4 changes Recall@5 only from 80.36% to 80.71%. The first hyperedge expansion already exposes enough relevant connections.

Together, the experiments show a 10.95-percentage-point loss when expansion is disabled, but only a 0.35-point gain from increasing depth to four. Most multi-hop evidence is recovered in the first layer.

The priority therefore becomes deciding which candidates to retain in that layer. V2's improved pruning reduces the premature removal of bridging entities, raising 2WikiMultiHopQA Recall@5 by 5.34 percentage points.

Does Omitting Entity Merging Hurt Results?

SAG avoids complex, time-consuming global entity merging. Each chunk independently yields events and entities, followed by string normalization and SQL deduplication. Chunks have no ordering dependency, enabling highly concurrent ingestion and direct appending of new data.

This does not restrict queries to exact string matches. Retrieval follows two routes.

The entity route extracts key entities from the question and uses vector retrieval to find similar expressions, with a default similarity threshold of 0.9. SQL JOINs then retrieve events. During indexing, the model is also asked to extract full names, abbreviations and aliases.

The event route retrieves semantically related events directly from the question vector, without depending on entity-name matches. Even an unmatched alias can enter the seed set this way and participate in expansion and selection.

In the first example, seed retrieval finds two correct passages and expands through the shared entity “Venice” to a third. In the second, there is no shared entity suitable for expansion, but the event route directly retrieves both correct passages.

SAG combines clear entity matches, semantic event retrieval, hyperedge expansion and final evidence selection. It does not require global merging before it can work.

Unmatched aliases can still lose some connections. In production, a lightweight alias table can connect common full names, short names and aliases, improving recall without global disambiguation or disrupting continuous ingestion.

Can Query Costs Stay Controlled at Hundreds of Millions of Records?

Yes. Production SAG first filters unrelated data by vector similarity, retaining only the top Kpool relevant chunks. Entity expansion, SQL JOINs and LLM selection happen within that budgeted pool.

Elasticsearch HNSW approximate search finds candidates without comparing the query vector against every stored vector. SAG then calculates relationships locally.

V2 tests candidate-pool sizes. Using all 11,656 MuSiQue chunks gives 80.36% Recall@5. Retaining only 500 gives 79.57%, approximately 99% of the full result. Around 1% performance loss reduces the computation scope by more than 95%.

If the corpus grows from 11,656 to 11,656,000 chunks, Kpool and Kcand can remain fixed. SQL expansion and LLM selection do not automatically require 1,000 times as much work.

HippoRAG 2's global Personalized PageRank propagates and ranks over a growing graph. SAG restricts queries to a local working set and delegates most scale growth to database indexes.

We also tested precision as the corpus grows. Real production data arrives daily, so V2 fixes the evaluation questions while continually adding content.

From left to right: candidate-pool size, four embedding models and results during continued corpus growth.

NQ remains broadly stable with more content. MuSiQue precision declines only slightly and remains ahead. SAG is stable as data grows.

Changing among four embedding models also has limited impact. Recall@5 is 80.36% with BGE and 81.71% with NV-Embed-v2. The advantage comes from hyperedges and retrieval design rather than one particular model.

The index is append-only. Production systems can keep ingesting data without reprocessing existing content while maintaining retrieval in seconds.

How Does SAG Relate to Agentic RAG?

SAG can itself be agentic; we call this Agentic-SAG.

First, distinguish the paper's high-accuracy mode from production SAG-Lite.

The benchmark retains final LLM reranking to minimize the constraints imposed by lightweight rankers and more fully test whether hyperedges and one-layer expansion recover multi-hop evidence.

The figure reports MuSiQue indexing costs and average online costs over 1,000 questions.

Kcand controls the number of candidate events sent to final LLM selection. At Kcand=100, Recall@5 is 80.36% and F1 is 61.15. At 50, these are 79.35% and 60.41. Halving the candidates loses only 1.01 percentage points of Recall@5 and 0.74 F1.

Query tokens fall from 11,536 to 8,236, about 28.6%. Average end-to-end time falls from 25.03 seconds to 22.68 seconds, about 9.4%. These figures describe the paper's high-accuracy mode.

Most useful evidence is already among the top 50 candidates after seed retrieval and one expansion layer. More candidates leave extra room for final selection but add little to scores. A smaller pool preserves most performance, making Agentic-SAG practical.

Production uses SAG-Lite. It replaces final LLM reranking with RRF, rapidly fusing rankings from SQL, vector, full-text and structural-path results. RRF requires no model inference and has steadier cost and latency.

An agent calls SAG-Lite repeatedly around a question, using a small pool each round and refining the next query from current evidence. RRF merges candidates across rounds, and an answer model produces the response with supporting evidence. Each round remains controlled while multiple rounds explore different evidence chains.

The open-source personal edition, https://github.com/Zleap-AI/Zleap-Agent, and the enterprise edition both use this Agentic-SAG approach. Please try it.

Enterprise Knowledge Infrastructure

Zleap's central goal has always been to advance enterprise AI adoption.

Adoption often begins with models, agents and automation. But what an agent can do depends first on what it can see.

Valuable knowledge is distributed across documents, meetings, chats, customer systems, code repositories and everyday business activity. Some is unorganized, some interconnected and some changes daily. Owning that knowledge does not mean an agent can find, understand or use it accurately.

Enterprises need dynamic knowledge infrastructure that supports large and growing datasets.

It must ingest continuously, preserve relationships and quickly retrieve accurate evidence. Query costs and precision must stay controlled as data grows.

SQL databases traditionally store deterministic relationships while vector databases provide semantic retrieval. LLM Wiki adds summary indexes and delegates understanding to the model.

These approaches can work at small scale. At large scale, sending more summaries and documents to a model increases context, latency and token cost. Enterprise infrastructure cannot depend indefinitely on reading more text to maintain results.

SAG brings relationships and vectors into one architecture. Vectors locate relevant regions, hyperedges retain complete event relationships, and SQL performs deterministic local expansion. Only a small amount of highly relevant evidence reaches the model. Ingestion continues while queries remain bounded and answers remain traceable.

Production systems based on SAG already ingest and process enterprise data continuously. Each day's new knowledge enters the same system for subsequent agent use.

SAG reflects our view of next-generation enterprise knowledge infrastructure: lightweight design, deterministic relationships and data structures that grow sustainably must work together.

We will continue building memory, context infrastructure and agent runtimes on SAG so agents can understand an enterprise's history, present state and ongoing changes, and participate in real business. This is a starting point for enterprise AI adoption.

SAG Enterprise is available. Interested organizations can contact us through the official WeChat account or website.

Paper and code:

• V2 paper: https://arxiv.org/abs/2608.12129