explainx / blog
KAIST researchers introduce OmniRetrieval, a framework that retrieves from text corpora, SQL databases, RDF knowledge graphs, and property graphs using each source's native query language. Evaluated on 309 knowledge bases across 13 datasets, it outperforms single-source baselines by 11% on retrieval accuracy.
Jul 3, 2026
Professional-tier AWS certification: 65 scored questions in five domains, six production scenario frames, $300 per attempt. Here is the competency map, what to expect on exam day, official Skill Builder prep—and our mock test bank.
Jul 3, 2026
Associate-tier Microsoft certification: five domains, a 700/1000 pass score, six production scenario frames, $165 per attempt. Here is the competency map, the semantic-vs-vector-vs-hybrid trap, official Learn prep—and our mock bank.
Jul 3, 2026
Fine-tuning is the answer people reach for and usually the wrong first move. Here is a practical decision tree — prompt engineering, grounding, RAG, fine-tuning, HITL — for choosing the cheapest fix that actually works.
Real-world questions don't respect database boundaries.
Ask "Which artists were born on the same date as Rachel Stevens?" and the answer lives in Wikidata's RDF knowledge graph, queryable via SPARQL.
Ask "How many online purchases did Ole Group make in May 2019?" and you need SQL against a normalized relational database.
Ask "Which actors acted in movies directed by the person who directed Speed Racer?" and you're traversing a labeled property graph with Cypher.
Ask "What is the cancer risk from French fries?" and you're searching unstructured biomedical documents.
Current retrieval systems force you to pick one. Use a document retriever (BM25, DPR) for text, text-to-SQL for databases, text-to-SPARQL for knowledge graphs, or text-to-Cypher for property graphs—but not all of them for a single question.
The natural solution seems obvious: collapse everything into a shared embedding space and retrieve by similarity.
Except that doesn't work.
As researchers from KAIST and DeepAuto.ai demonstrate in their new paper "OmniRetrieval: Unified Retrieval across Heterogeneous Knowledge Sources," flattening structured data into embeddings throws away the structural affordances—joins, traversals, compositional operators—that make each source valuable in the first place.
Their alternative: meet each knowledge source on its own terms.
Modern knowledge exists in structurally diverse forms:
Query method: Free-form natural language → BM25 or dense retrieval
Query method: Natural language → SQL with joins, aggregations, filters
Query method: Natural language → SPARQL triple patterns and property paths
Query method: Natural language → Cypher graph traversals
The fragmentation problem: Each backend has:
Existing retrieval approaches operate on one source at a time, leaving the broader knowledge landscape unreachable behind incompatible interfaces.
The obvious approach is to project everything into a shared vector space:
Why this fails:
Embeddings cluster by source type rather than semantic content. The retriever biases toward sources that look like the query structurally, not sources that answer it.
SQL joins become individual row embeddings. Graph traversals become separate edge embeddings. Multi-hop reasoning is lost.
Consider the query: "Find companies founded by MIT graduates who later joined Google."
SQL version:
SELECT DISTINCT c.name
FROM companies c
JOIN founders f ON c.id = f.company_id
JOIN education e ON f.person_id = e.person_id
JOIN employment emp ON f.person_id = emp.person_id
WHERE e.institution = 'MIT'
AND emp.company = 'Google'
AND emp.start_date > f.founded_date
Embedding version: You get individual rows for companies, founders, education records, and employment records. The join logic is gone.
Wikidata has 15+ billion triples. Embedding all possible paths in a property graph grows exponentially with hop length—one graph in the benchmark has tens of billions of 3-hop paths.
Materializing a shared embedding space for real-world knowledge sources is computationally infeasible.
Instead of homogenization, OmniRetrieval provides a coordination layer that:
Input: Natural language query + catalog of source descriptors
Process: A long-context LLM reads the full catalog of structural contexts (schemas, ontologies, corpus descriptions) and returns a ranked list of candidate sources.
Example:
Query: "Which artists were born on the same date as Rachel Stevens?"
Catalog contains:
- 7 document corpora (medical, scientific, financial, Wikipedia)
- 286 SQL databases (various domains)
- Wikidata RDF graph (15B+ triples, encyclopedic facts)
- 15 property graphs (movies, social networks, companies)
Selected: Wikidata (contains birth dates of public figures)
Key insight: The LLM can reason over heterogeneous descriptors (table schemas, graph ontologies, corpus summaries) directly, without forcing them into a shared representation.
Input: Query + structural context for each selected source
Process: For each source, generate an executable native query conditioned on its schema/ontology.
Example:
For Wikidata (SPARQL):
SELECT DISTINCT ?artist WHERE {
?rachel rdfs:label "Rachel Stevens"@en .
?rachel wdt:P569 ?birthdate .
?artist wdt:P569 ?birthdate .
?artist wdt:P106 wd:Q483501 . # occupation: artist
FILTER (?artist != ?rachel)
}
For a SQL database:
SELECT a.name
FROM artists a
JOIN persons p1 ON a.person_id = p1.id
JOIN persons p2 ON p1.birthdate = p2.birthdate
WHERE p2.name = 'Rachel Stevens'
AND a.person_id != p2.id
For a property graph (Cypher):
MATCH (rachel:Person {name: "Rachel Stevens"})-[:BORN_ON]->(date:Date)
MATCH (artist:Artist)-[:BORN_ON]->(date)
WHERE artist <> rachel
RETURN artist.name
Key insight: Each query is grounded in the source's actual schema (table names, predicates, relationship types), not generic templates.
Input: Executor outputs from multiple heterogeneous sources
Process: An LLM selects the subset of results relevant to the original query, filtering across different result formats:
Example:
Results from 3 sources:
Source 1 (Wikidata SPARQL):
- Artist: Ronan Keating (born 1977-03-03)
- Artist: Laura Prepon (born 1980-03-07)
Source 2 (Wikipedia docs):
- Passage: "Rachel Stevens (born 9 April 1978)..."
Source 3 (SQL celebrity_db):
- Row: {name: "Ronan Keating", birthdate: "1977-03-03"}
Evidence Selection picks:
- Source 1 results (correctly answers the query)
- Filters out Source 2 (context, not answer)
- Deduplicates Source 3 (same info as Source 1)
Key insight: The consolidation step handles format heterogeneity (triples vs rows vs passages) and selects semantically equivalent answers even when surface forms differ.
OmniRetrieval was evaluated on an extensive benchmark spanning:
Total: 309 distinct knowledge bases, 300 questions per dataset = 3,900 total queries
Evaluated on five LLM backbones (GPT-5.4, Gemini-3.1 Pro, Sonnet-4.6, Qwen-3.5 27B, Gemma-4 31B):
Key finding: The gap to oracle narrows from 34.27pp (source selection) → 17.51pp (retrieval) → 8.67pp (judge), showing that cross-source evidence selection often recovers semantically equivalent answers even when source selection misses the gold standard.
Rather than embedding source descriptors into a shared space, OmniRetrieval reads the full catalog of schemas, ontologies, and corpus descriptions directly.
This works because:
Result: 65.71% source selection accuracy across 309 knowledge bases
By generating SQL, SPARQL, or Cypher instead of embedding atomic units:
SQL preserves:
SPARQL preserves:
Cypher preserves:
Embedding-based approaches lose all of this.
OmniRetrieval returns a short list of k candidates (default k=3) rather than committing to one source upfront.
Effect of candidate size:
Insight: Returns diminish beyond k=3 because evidence selection accuracy drops from 67.5% at k=3 to 62.8% at k=10—more candidates introduce more noise.
The final consolidation step verbalizes results from different formats:
SQL results → Natural language:
Row: {company: "Tesla", founded: 2003, employees: 127855}
→ "Tesla was founded in 2003 and has 127,855 employees."
SPARQL triples → Natural language:
<Q2283> <P569> "1980-03-07"
→ "Rachel Stevens was born on March 7, 1980."
Cypher paths → Natural language:
(:Person {name: "Lana Wachowski"})-[:DIRECTED]->(:Movie {title: "Speed Racer"})<-[:ACTED_IN]-(:Person {name: "Emile Hirsch"})
→ "Emile Hirsch acted in Speed Racer, directed by Lana Wachowski."
The LLM then selects results that answer the query, handling:
The researchers analyzed which query types each backend can answer:
Document Search has the widest cross-paradigm coverage (28.2% off-diagonal accuracy), especially for SPARQL questions where Wikipedia-derived corpora overlap with Wikidata's factual content.
Structured backends (SQL, SPARQL, Cypher) have narrower coverage (15.2% - 22.1% off-diagonal) because their answers depend on specific schema elements.
Key insight: No single backend is sufficient. Even the best single-paradigm approach (Document Search) only reaches 28.2% cross-paradigm coverage.
OmniRetrieval achieves 65.88% by engaging the right backend per query.
Even at k=3 candidates, source selection only achieves 65.71% accuracy. The gap to oracle (100%) is largest at this stage.
Why: The catalog contains 309 knowledge bases with similar-sounding schemas. SQL databases in particular (286 of 309 sources) create high ambiguity.
As candidate list size grows from k=3 to k=10, evidence selection accuracy drops from 67.5% to 62.8%.
Why: More candidates introduce more noise, making it harder for the LLM to identify which results actually answer the query.
Text-to-SQL, text-to-SPARQL, and text-to-Cypher inherit the same failure modes as existing single-backend systems:
The paper attempted to compare against unified-representation approaches (UniK, UDT, DiFaR) but had to constrain the setup severely:
Even in this massively favorable setup, unified embeddings only reached 23% retrieval accuracy vs OmniRetrieval's 46.62%—and this is on a tiny fraction of real-world graph scale.
Fundamental limit: You can't embed 15 billion Wikidata triples or tens of billions of property graph paths.
OmniRetrieval demonstrates that RAG doesn't have to be limited to document retrieval.
Most production RAG systems look like:
This only works for unstructured text.
If your knowledge includes:
You're stuck either:
A unified retrieval layer that:
Benefits:
Most enterprises have knowledge fragmented across:
Unstructured:
Structured:
Current solution: Build separate search/query interfaces for each.
OmniRetrieval approach: Single natural-language interface that routes to appropriate backends and consolidates results.
Example enterprise query:
"Which customers purchased product X in Q1 2026 and then opened support tickets about installation issues?"
Requires:
OmniRetrieval can formulate and execute this cross-system query from natural language.
The KAIST team released code at github.com/JinheonBaek/OmniRetrieval.
1. Source Registry
2. Source Selector
3. Query Generators (Per Backend)
4. Execution Engines
5. Evidence Selector
Latency:
Total: 4-10 seconds for k=3 candidates
Cost (per query):
At GPT-5.4 pricing: ~$0.01-0.03 per query
Scaling:
The KAIST team identifies several areas for improvement:
Current approach uses zero-shot LLM prompting. Supervised fine-tuning on labeled cross-source selections could improve accuracy.
Use downstream answer correctness as reward signal to improve source selection and evidence ranking.
Rather than a single shared LLM, specialize models for:
Current approach assumes static knowledge bases. Real-world sources change over time.
Allow users to provide feedback on selected sources and refine queries iteratively.
OmniRetrieval advantage: Works across multiple backends, not just SQL
Limitation: Individual SQL generation quality may trail specialized text-to-SQL models
OmniRetrieval advantage: Preserves structural operators instead of embedding everything
Trade-off: Higher complexity, more moving parts
OmniRetrieval advantage: Specialized for knowledge retrieval with schema-grounded query synthesis
Difference: Tool use is generic function calling; OmniRetrieval handles complex queries (100+ table schemas)
OmniRetrieval advantage: Handles graph traversals and multi-hop reasoning, not just keyword + vector
OmniRetrieval represents a shift from homogenization to coordination.
Rather than forcing everything into a shared representation that loses structure, build a meta-layer that:
This is how humans work:
OmniRetrieval automates this for machines.
OmniRetrieval doesn't just benchmark higher than existing approaches.
It demonstrates a fundamentally different architecture for knowledge access:
Old paradigm: Pick your backend (text, SQL, or graph), build a specialized retriever, accept that other knowledge is unreachable.
New paradigm: Register all knowledge sources, let the system route queries to appropriate backends in native languages, consolidate heterogeneous results.
As knowledge continues fragmenting across incompatible formats—unstructured documents, relational databases, knowledge graphs, property graphs, vector databases, and future formats we haven't invented yet—the coordination approach scales where homogenization fails.
The 309 knowledge bases in this benchmark are a tiny slice of enterprise knowledge, which is a tiny slice of human knowledge.
But OmniRetrieval proves the path forward:
Meet each source on its own terms. Preserve what makes each valuable. Unify at the interface, not the representation.
That's how you build retrieval systems for the real world.
Paper: OmniRetrieval: Unified Retrieval across Heterogeneous Knowledge Sources
Authors: Jinheon Baek, Soyeong Jeong, Sangwoo Park, Woongyeong Yeo, Minki Kang, Patara Trirat, Heejun Lee, Sung Ju Hwang (KAIST & DeepAuto.ai)
Code: github.com/JinheonBaek/OmniRetrieval
Benchmark: 13 datasets, 309 knowledge bases (BEIR, Spider, BIRD, SimpleQuestions, QALD-10, LC-QuAD 2.0, Text2Cypher)