7.5 C
Canberra
Saturday, April 11, 2026

Past Vector Search: Constructing a Deterministic 3-Tiered Graph-RAG System


On this article, you’ll learn to construct a deterministic, multi-tier retrieval-augmented technology system utilizing data graphs and vector databases.

Matters we are going to cowl embrace:

  • Designing a three-tier retrieval hierarchy for factual accuracy.
  • Implementing a light-weight data graph.
  • Utilizing prompt-enforced guidelines to resolve retrieval conflicts deterministically.
Past Vector Search: Constructing a Deterministic 3-Tiered Graph-RAG System

Past Vector Search: Constructing a Deterministic 3-Tiered Graph-RAG System
Picture by Editor

Introduction: The Limits of Vector RAG

Vector databases have lengthy since turn into the cornerstone of contemporary retrieval augmented technology (RAG) pipelines, excelling at retrieving long-form textual content primarily based on semantic similarity. Nevertheless, vector databases are notoriously “lossy” relating to atomic info, numbers, and strict entity relationships. An ordinary vector RAG system would possibly simply confuse which workforce a basketball participant at present performs for, for instance, just because a number of groups seem close to the participant’s title in latent house. To unravel this, we want a multi-index, federated structure.

On this tutorial, we are going to introduce such an structure, utilizing a quad retailer backend to implement a data graph for atomic info, backed by a vector database for long-tail, fuzzy context.

However right here is the twist: as an alternative of counting on advanced algorithmic routing to choose the suitable database, we are going to question all databases, dump the outcomes into the context window, and use prompt-enforced fusion guidelines to drive the language mannequin (LM) to deterministically resolve conflicts. The objective is to aim to eradicate relationship hallucinations and construct absolute deterministic predictability the place it issues most: atomic info.

Structure Overview: The three-Tiered Hierarchy

Our pipeline enforces strict knowledge hierarchy utilizing three retrieval tiers:

  1. Precedence 1 (absolute graph info): A easy Python QuadStore data graph containing verified, immutable floor truths structured in Topic-Predicate-Object plus Context (SPOC) format.
  2. Precedence 2 (statistical graph knowledge): A secondary QuadStore containing aggregated statistics or historic knowledge. This tier is topic to Precedence 1 override in case of conflicts (e.g. a Precedence 1 present workforce reality overrides a Precedence 2 historic workforce statistic).
  3. Precedence 3 (vector paperwork): An ordinary dense vector DB (ChromaDB) for common textual content paperwork, solely used as a fallback if the data graphs lack the reply.

Atmosphere & Stipulations Setup

To comply with alongside, you will want an surroundings operating Python, a neighborhood LM infrastructure and served mannequin (we use Ollama with llama3.2), and the next core libraries:

  • chromadb: For the vector database tier
  • spaCy: For named entity recognition (NER) to question the graphs
  • requests: To work together with our native LM inference endpoint
  • QuadStore: For the data graph tier (see QuadStore repository)

You may manually obtain the easy Python QuadStore implementation from the QuadStore repository and place it someplace in your native file system to import as a module.

⚠️ Observe: The complete challenge code implementation is obtainable in this GitHub repository.

With these conditions dealt with, let’s dive into the implementation.

Step 1: Constructing a Light-weight QuadStore (The Graph)

To implement Precedence 1 and Precedence 2 knowledge, we use a customized light-weight in-memory data graph referred to as a quad retailer. This information graph shifts away from semantic embeddings towards a strict node-edge-node schema identified internally as a SPOC (Topic-Predicate-Object plus Context).

This QuadStore module operates as a highly-indexed storage engine. Below the hood, it maps all strings into integer IDs to stop reminiscence bloat, whereas protecting a four-way dictionary index (spoc, pocs, ocsp, cspo) to allow constant-time lookups throughout any dimension. Whereas we gained’t dive into the small print of the inner construction of the engine right here, using the API in our RAG script is extremely easy.

Why use this straightforward implementation as an alternative of a extra sturdy graph database like Neo4j or ArangoDB? Simplicity and velocity. This implementation is extremely light-weight and quick, whereas having the extra good thing about being simple to grasp. That is all that’s wanted for this particular use case with out having to study a fancy graph database API.

There are actually solely a few QuadStore strategies it’s essential to perceive:

  1. add(topic, predicate, object, context): Provides a brand new reality to the data graph
  2. question(topic, predicate, object, context): Queries the data graph for info that match the given topic, predicate, object, and context

Let’s initialize the QuadStore appearing as our Precedence 1 absolute reality mannequin:

As a result of it makes use of the an identical underlying class, you possibly can populate Precedence 2 (which handles broader statistics and numbers) identically or by studying from a previously-prepared JSONLines file. This file was created by operating a easy script that learn the 2023 NBA common season stats from a CSV file that was freely-acquired from a basketball stats web site (although I can not recall which one, as I’ve had the info for a number of years at this level), and transformed every row right into a quad. You may obtain the pre-processed NBA 2023 stats file in JSONL format from the challenge repository.

Step 2: Integrating the Vector Database

Subsequent, we set up our Precedence 3 layer: the usual dense vector DB. We use ChromaDB to retailer textual content chunks that our inflexible data graphs might need missed.

Right here is how we initialize a persistent assortment and ingest uncooked textual content into it:

Step 3: Entity Extraction & International Retrieval

How can we question deterministic graphs and semantic vectors concurrently? We bridge the hole utilizing NER by way of spaCy.

First, we extract entities in fixed time from the person’s immediate (e.g. “LeBron James” and “Ottawa Beavers”). Then, we fireplace off parallel queries to each QuadStores utilizing the entities as strict lookups, whereas querying ChromaDB utilizing string similarity over the immediate content material.

We now have all of the retrieved context separated into three distinct streams (facts_p1, facts_p2, and vec_info).

Step 4: Immediate-Enforced Battle Decision

Typically, advanced algorithmic battle decision (like Reciprocal Rank Fusion) fails when resolving granular info in opposition to broad textual content. Right here we take a radically easier method that, as a sensible matter, additionally appears to work properly: we embed the “adjudicator” ruleset immediately into the system immediate.

By assembling the data into explicitly labeled [PRIORITY 1], [PRIORITY 2], and [PRIORITY 3] blocks, we instruct the language mannequin to comply with specific logic when outputting its response.

Right here is the system immediate in its entirety:

Far completely different than “… and don’t make any errors” prompts which are little greater than finger-crossing and wishing for no hallucinations, on this case we current the LM with floor reality atomic info, doable conflicting “less-fresh” info, and semantically-similar vector search outcomes, together with an specific hierarchy for figuring out which set of knowledge is right when conflicts are encountered. Is it foolproof? No, in fact not, however it’s a distinct method worthy of consideration and addition to the hallucination-combatting toolkit.

Don’t overlook that yow will discover the remainder of the code for this challenge right here.

Step 5: Tying it All Collectively & Testing

To wrap the whole lot up, the principle execution thread of our RAG system calls the native Llama occasion by way of the REST API, handing it the structured system immediate above alongside the person’s base query.

When run within the terminal, the system isolates our three precedence tiers, processes the entities, and queries the LM deterministically.

Question 1: Factual Retrieval with the QuadStore

When querying an absolute reality like “Who’s the star participant of Ottawa Beavers workforce?”, the system depends solely on Precedence 1 info.

LeBron plays for Ottawa Beavers

LeBron performs for Ottawa Beavers

As a result of Precedence 1, on this case, explicitly states “Ottawa Beavers obtained LeBron James”, the immediate instructs the LM by no means to complement this with the vector paperwork or statistical abbreviations, thus aiming to eradicate the standard RAG relationship hallucination. The supporting vector database paperwork help this declare as properly, with articles about LeBron and his tenure with the Ottawa NBA workforce. Evaluate this with an LM immediate that dumps conflicting semantic search outcomes right into a mannequin and asks it, generically, to find out which is true.

Question 2: Extra Factual Retrieval

The Ottawa beavers, you say? I’m unfamiliar with them. I assume they play out of Ottawa, however the place, precisely, within the metropolis are they primarily based? Precedence 1 info can inform us. Take into account we’re combating in opposition to what the mannequin itself already is aware of (the Beavers aren’t an precise NBA workforce) in addition to the NBA common stats dataset (which lists nothing concerning the Ottawa Beavers by any means).

The Ottawa Beavers home

The Ottawa Beavers dwelling

Question 3: Coping with Battle

When querying an attribute in each absolutely the info graph and the final stats graph, akin to “What was LeBron James’ common MPG within the 2023 NBA season?”, the mannequin depends on the Precedence 1 degree knowledge over the prevailing Precedence 2 stats knowledge.

LeBron MPG Query Output

LeBron MPG Question Output

Question 4: Stitching Collectively a Strong Response

What occurs after we ask an unstructured query like “What damage did the Ottawa Beavers star damage endure throughout the 2023 season?” First, the mannequin must know who the Ottawa Beavers star participant is, after which decide what their damage was. That is achieved with a mix of Precedence 1 and Precedence 3 knowledge. The LM merges this easily right into a ultimate response.

LeBron Injury Query Output

LeBron Damage Question Output

Question 5: One other Strong Response

Right here’s one other instance of sewing collectively a coherent and correct response from multi-level knowledge. “What number of wins did the workforce that LeBron James play for have when he left the season?”

LeBron Injury Query #2 Output

LeBron Damage Question #2 Output

Let’s not overlook that for all of those queries, the mannequin should ignore the truth that conflicting (and inaccurate!) knowledge exists within the Precedence 2 stats graph suggesting (once more, wrongly!) that LeBron James performed for the LA Lakers in 2023. And let’s additionally not overlook that we’re utilizing a easy language mannequin with solely 3 billion parameters (llama3.2:3b).

Conclusion & Commerce-offs

By splitting your retrieval sources into distinct authoritative layers — and dictating actual decision guidelines by way of immediate engineering — the hope is that you simply drastically scale back factual hallucinations, or competitors between in any other case equally-true items of knowledge.

Benefits of this method embrace:

  • Predictability: 100% deterministic predictability for crucial info saved in Precedence 1 (objective)
  • Explainability: If required, you possibly can drive the LM to output its [REASONING] chain to validate why Precedence 1 overrode the remaining
  • Simplicity: No want to coach customized retrieval routers

Commerce-offs of this method embrace:

  • Token Overhead: Dumping all three databases into the preliminary context window consumes considerably extra tokens than typical algorithm-filtered retrieval
  • Mannequin Reliance: This technique requires a extremely instruction-compliant LM to keep away from falling again into latent training-weight habits

For environments by which excessive precision and low tolerance for errors are necessary, deploying a multi-tiered factual hierarchy alongside your vector database will be the differentiator between prototype and manufacturing.

Related Articles

LEAVE A REPLY

Please enter your comment!
Please enter your name here

[td_block_social_counter facebook="tagdiv" twitter="tagdivofficial" youtube="tagdiv" style="style8 td-social-boxed td-social-font-icons" tdc_css="eyJhbGwiOnsibWFyZ2luLWJvdHRvbSI6IjM4IiwiZGlzcGxheSI6IiJ9LCJwb3J0cmFpdCI6eyJtYXJnaW4tYm90dG9tIjoiMzAiLCJkaXNwbGF5IjoiIn0sInBvcnRyYWl0X21heF93aWR0aCI6MTAxOCwicG9ydHJhaXRfbWluX3dpZHRoIjo3Njh9" custom_title="Stay Connected" block_template_id="td_block_template_8" f_header_font_family="712" f_header_font_transform="uppercase" f_header_font_weight="500" f_header_font_size="17" border_color="#dd3333"]
- Advertisement -spot_img

Latest Articles