Knowledge graphs or vector RAG: choosing by the question

“How do I configure contract approval?” and “Which active contracts are linked to a supplier whose status has changed?” may sound like questions for the same corporate knowledge base. They require different answers. The first may need one suitable guide. The second must identify the supplier, find its contracts, check which remain active and connect information across sources.

Choosing vector RAG or a knowledge graph starts with that distinction. It depends on the structure of the answer and the team's ability to maintain the underlying facts. A new architecture does not replace current data and clear access rules.

What the new n8n article explains

The October 1, 2026 n8n article compares retrieval of semantically similar passages with retrieval of explicit relationships. A graph represents entities as nodes and relationships as edges. Facts can be stored as subject–predicate–object triples; “contract belongs to supplier” establishes a connection that graph traversal can use.

The authors propose vector RAG for answers contained in a few relevant passages, and graphs for tasks that connect relationships among entities. They also describe HybridRAG, which combines retrieval methods. This is guidance from an automation provider rather than a comparative test of every architecture on your documents.

A conventional relational database can also store relationships and answer structured questions. Several connected objects do not automatically require a graph database. First check whether an exact query to the existing system can produce the answer. A language interface might simply help the user express that query.

When a few passages are enough

Reference questions such as “How do I change a delivery address?” often suit search across instructions. Vector retrieval can match a customer's phrasing with different wording in the document. Add a lexical signal when exact names matter; its limitations are discussed in hybrid search and tokenization.

The output of retrieval remains textual context. Its version, applicability to a particular role and source must be known. If one clear article contains the answer, constructing entities and relationships for the entire knowledge base may add work without useful gains.

The site's approach to AI workflows with verifiable results begins with a bounded task. A reference assistant can start with questions and expected sources, answer evaluation and explicit behaviour when information is absent. Specific failures then provide grounds for expanding the architecture.

When relationships are the substance of the question

Return to the hypothetical supplier. A status change might affect contracts, serviced assets and responsible employees. If those facts are distributed across documents, a semantically close paragraph may not contain the complete chain. A graph can explicitly represent paths from supplier to contract, then to asset and responsible person.

Each relationship still needs a precise meaning. “Mentioned in correspondence” and “party to an active contract” cannot become the same edge. Contract end dates, the status source and asset identifiers matter for correct selection. Without them, an attractive graph path may explain a dependency that does not exist.

For an initial experiment, choose one question type and a small relationship set. For example, return a supplier's contracts with evidence and active status on a specified date. Extracting “every possible relationship” from an archive creates a much harder validation task than a narrow predefined schema.

Who confirms a relationship's validity?

n8n specifically discusses entity resolution: different names for the same object need reconciliation, but automated merging requires validation. This is particularly important for similarly named businesses and employees participating in multiple projects. An incorrect merge assigns relationships to the wrong entity.

Retain the source of each relationship, its confirmation time and applicability conditions. When a document changes, determine which derived facts have become invalid. If two source versions conflict, show that conflict or follow a previously agreed priority instead of choosing the most convenient explanation.

Internal business systems begin with questions about which data can be trusted and who performs the next step. In a graph, those responsibilities become part of the design: who confirms an edge, who resolves a contradiction and where the current record lives. The team retains these duties even if an LLM extracts entities automatically.

Test the value before expanding

Compare alternatives on the same questions: a reference query, an exact structured query and a question needing several relationship steps. Record the expected entities, relationships, documents and unacceptable inferences. Include status changes, duplicate names and deleted sources.

In the May 6 Weaviate retrieval overview, the author identifies stale and insufficient passages among retrieval failure modes observed in research. The article does not establish graph superiority. It supports checking completeness and freshness of retrieved context regardless of its form.

For a graph, check whether an answer can be traced to source facts and each step explained. For vector retrieval, check whether the returned passages sufficiently support the conclusion. Then account for maintenance: source updates, entity corrections, schema changes and expert time spent confirming disputed relationships. A shorter-looking final answer does not establish cost savings.

A combined approach with justified components

HybridRAG makes sense when a query genuinely needs both relationships and document content. The hypothetical system might first identify a supplier's contracts precisely, then retrieve their notification terms. Each stage must preserve identifiers and access restrictions; outputs from two tools should not be indiscriminately combined into one context.

Extraction challenges involving tables and charts are covered in RAG for PDF documents. Even an appropriate relationship schema cannot recover facts lost while reading the document.

Start with one operational question and the simplest implementation that returns a verifiable answer. A graph is useful when explicit relationships resolve a demonstrated problem and the team can maintain them. Vector search is useful when relevant text is required. Testing these tasks on your own sources makes the choice defensible.

Sources

• n8n: knowledge graphs or vector RAG, October 1, 2026.
• Weaviate: retrieval quality, May 6, 2026.