When we started building RenBase, we spent the first three months trying to solve everything with dense vector search. It worked well for simple, direct queries. It consistently failed for anything requiring relational reasoning.
The problem is structural. Vector search answers “what is semantically similar to my query?” It cannot answer “what are all the documents that reference this entity, and how do they relate to each other?”
That gap is why we built the knowledge graph.
What the graph adds
Every document ingested into RenBase goes through two parallel pipelines. The first generates dense and sparse embeddings for semantic and lexical search. The second extracts a network of entities and the relationships between them.
The key difference from traditional NER (named entity recognition) is that we use large language models to extract these relationships. An LLM understands context, nuance, and implicit connections that rule-based systems miss entirely. It can identify that a clause in one document effectively supersedes a clause in another, even when neither document explicitly references the other.
This matters. Most knowledge graphs in production RAG systems are built with regex patterns or NER models trained on generic datasets. They find names, dates, and organisations. They miss the relationships that actually matter for answering complex questions, the “defines”, “contradicts”, “amends”, “depends on” connections that give a document corpus its structure.
How retrieval works
When a query arrives, RenBase doesn’t just search, it reasons.
The retrieval layer runs multiple strategies in parallel: dense semantic search, sparse lexical matching, and graph traversal. Each strategy returns a ranked list of relevant document chunks. These lists are then fused using a scoring algorithm that combines signals from all three sources.
The graph traversal is specifically designed to surface evidence that vector search would miss. If your query mentions an entity, the graph finds all chunks connected to that entity, including chunks that use different terminology, are in a different language, or discuss the entity in a completely different context.
The result: RenBase answers multi-hop questions (“What changed in the payment terms between the original contract and the latest amendment?”) that pure vector search cannot.
Why a graph database
We needed a data store where relationships are first-class citizens, not afterthoughts encoded as join tables. In a graph database, traversing from one entity to its neighbours is a constant-time operation regardless of dataset size. In a relational database, multi-hop queries require recursive CTEs or self-joins that grow expensive fast.
Cypher, the query language, makes it straightforward to express complex traversal patterns. “Find all entities connected to X within two hops, then collect all document chunks that mention those entities” is a single readable query, not a page of SQL.
The multilingual advantage
One aspect we don’t see discussed enough in the RAG space: knowledge graphs are inherently language-agnostic. An entity node representing “European Central Bank” connects to chunks in English, Spanish, German, or any other language where that entity appears. When combined with our cross-lingual embeddings (which place all languages in the same vector space), the graph becomes a bridge between documents that would otherwise be invisible to each other.
Ask a question in Spanish, get evidence from a German regulatory filing, because the graph knows they reference the same entities.
What we’re working on next
Graph-based ranking. Right now, all retrieval signals contribute to the final ranking, but we’re exploring how graph topology, the structure of connections between entities and documents, can become a stronger signal. Documents that sit at the centre of many relationships carry different weight than isolated ones. We want the ranking to reflect that.
We’re also investing in richer relationship semantics. The relationships our LLM extracts already carry meaning (a predicate describing how two entities are connected), but we see an opportunity to use that meaning more actively during retrieval, filtering and weighting results based not just on whether entities are connected, but how they’re connected.
If you’re building on top of RenBase and want to understand how the graph affects your search results, check out our API documentation, particularly the filters and security parameters on the /ask endpoint, which let you control which parts of your knowledge base are queried.