New RAG Approaches: Exploring SAG and OpenViking

Background

RAG (Retrieval‑Augmented Generation) often struggles because knowledge and context are modeled too coarsely, leading to heavy systems that focus on finer chunking, deeper retrievers, or GraphRAG pipelines.

SAG Overview

The paper SAG: SQL‑Retrieval Augmented Generation with Query‑Time Dynamic Hyperedges proposes a lightweight offline graph built at query time using relational databases.

Data Model

Chunk Event : a semantically complete text block mapped to an Event that preserves full context.

Chunk Entities : entities extracted from the chunk for indexing and expansion only.

Event Entities : links between Events and Entities that define latent hyperedges.

+-------------------------------------------------------------+
|                     Original Chunk                         |
+-------------------------------------------------------------+
                              |
                              v
+-------------------------------------------------------------+
|                Event (complete semantics)                 |
+-------------------------------------------------------------+
          /               |               \
          v               v               v
+------------------+   +------------------+   +------------------+
|     Entity A    |   |     Entity B    |   |     Entity C    |
+------------------+   +------------------+   +------------------+

During retrieval, no global graph is pre‑built; relationships are computed on‑the‑fly via SQL JOINs.

Query‑Time Dynamic Hyperedges

Seed Localization : combine vector and lexical search to find seed entities and events.

SQL Dynamic Expansion : use SQL JOIN to connect events sharing those entities.

Local Hyperedge Instantiation : instantiate only the needed hyperedges for the current query.

Evidence Restoration : map selected events back to original chunks, deduplicate, and feed them as evidence to the LLM.

The approach relies on standard databases (SQLite, PostgreSQL, LanceDB) and avoids graph engines. New documents only require inserting their Events and Entities, enabling high‑concurrency incremental writes.

Benchmark results using BGE‑Large‑EN‑v1.5 embeddings and Qwen3.6‑Flash LLM show SAG achieving best scores on 8 of 9 Recall@1/2/5 metrics across HotpotQA, 2WikiMultiHopQA, and MuSiQue, with average Recall@2/5 of 79.30%/88.18% versus HippoRAG 2’s 68.14%/83.28%.

Open Issues

Extraction quality still depends on the LLM; errors propagate to JOINs.

Seed entity identification can be fragile for vague queries.

SQL JOIN latency may grow with data size, affecting tail latency under concurrency.

OpenViking Overview

OpenViking is positioned as a context database for AI agents, abstracting Memory, Resource, and Skill as files under a viking:// virtual filesystem, each with a unique URI.

File‑Based Abstraction

By treating all agent artifacts as files, operations such as list and find become uniform, turning opaque vector retrieval into transparent file navigation.

Hierarchical Loading

Context is stored in three layers: L0 (one‑sentence summary), L1 (overview with core info and use cases), and L2 (full raw data). Agents read only L0/L1 during planning, pulling L2 on demand, dramatically reducing token consumption for multi‑step tasks.

Recursive Directory Retrieval

The retrieval pipeline first uses intent analysis to generate multiple conditions, performs a vector‑based high‑score directory lookup, then recursively refines results within sub‑directories, combining semantic matching with hierarchical context.

Observability & Self‑Iteration

Each retrieval step logs its directory navigation and file accesses, enabling precise debugging of why certain evidence was selected. After a session, session.commit() triggers asynchronous analysis that updates the /memory directory with user preferences and extracted operational tips.

The author notes that while self‑iteration is promising, its quality and safety need long‑term evaluation before production use.

Comparison and Decision Guidance

Both SAG and OpenViking aim to recover structural information lost by flat vector retrieval. SAG restores entity‑level relationships via SQL, whereas OpenViking restores hierarchical organization via a virtual file system. They are complementary: SAG excels at multi‑hop knowledge retrieval with low deployment cost; OpenViking excels at agent‑level context management, token efficiency, and debuggability.

Practical recommendations:

If the primary need is accurate multi‑hop knowledge retrieval on relatively static corpora with strong provenance requirements, evaluate SAG.

If building an agent product that requires long‑term context handling, memory consolidation, and fine‑grained token control, evaluate OpenViking.

Both can be combined: use SAG for precise retrieval and OpenViking for higher‑level context orchestration.