Beyond vector-only RAG

GraphRAG that traverses what vectors miss

When relationships drive the answer, similarity is not enough. We design and ship GraphRAG systems on Neo4j, Neptune and TigerGraph, built for interactive-latency traversal at enterprise scale, with cited and auditable answers.

7

stages from source event to cited answer

4

graph stores we deploy, chosen per workload

20

questions workshopped before any schema is drawn

A ball-and-stick molecular model
Why vector RAG alone fails

Five problems knowledge graphs solve

These failure modes show up every time the data has structure that matters — and none of them are solved by adding more chunks to a vector store. They need explicit edges, resolved entities and traversal.

Vector-only RAG misses relationships

Cosine similarity finds related chunks but cannot traverse 'customer → account → contract → supplier' chains.

Answers look plausible but skip the connective tissue that drives real decisions.

Entity duplication across source systems

The same vendor exists as eleven different records across the CRM, the finance system, procurement and the issue tracker.

Reporting double-counts spend, investigations stall on alias resolution, and two dashboards disagree.

Multi-hop questions take days

Questions like 'which open issues touch services owned by teams reporting to this VP?' need four joins across three systems.

Decision latency stretches from hours to weeks, and the ad-hoc query backlog grows.

Answers without citations are unsafe

Generative answers that cannot be audited back to source nodes will not clear compliance, legal or risk.

Pilots stall at the security review and the rollout never happens.

Schema sprawl in heterogeneous data

Every wiki, chat tool, CRM and repository arrives with its own object model and its own identifiers.

Every new question needs bespoke extraction, so the data team scales linearly with use cases.

Architecture

The GraphRAG pipeline, end to end

Seven stages from a raw source-system event to a cited natural-language answer. Each stage is independently observable and replaceable.

01

Ingest

Change-data-capture events streamed from the wikis, chat tools, CRM, code hosts and service desks the business already runs.

Kafka · Airbyte · Debezium

02

Entity extraction

A hybrid pipeline — a fast NER model for high-volume structured fields, a language model for long-form unstructured documents. Output validated against a typed entity schema.

spaCy · Claude · Pydantic

03

Entity resolution

LSH blocking narrows the candidate pairs; a classifier merges duplicates. Low-confidence matches route to a person rather than being guessed.

LSH · embeddings · Claude

04

Relation extraction

Typed edges extracted from text and structured joins. Provenance preserved — every edge cites its source record, and edges are versioned rather than overwritten.

Claude · rule engine · Pydantic

05

Graph store

Loaded into the store chosen for the workload, with indexes tuned for the top-twenty query patterns identified during schema design.

Neo4j · Neptune · TigerGraph · Memgraph

06

GraphRAG query

The user's question becomes Cypher, executes, and fuses with hybrid vector retrieval before the model reasons over the result.

LangChain · Cypher · Qdrant · Claude

07

Cited response

Every answer carries citations back to the source nodes and edges it used, so compliance, legal and risk can audit any claim it makes.

Pydantic · Datadog · audit log

The stack

Six capabilities, every component named

Every component is named, replaceable and observable — no black box, and nothing you cannot take with you.

Polyglot graph store

Neo4j AuraDB for general workloads, Amazon Neptune for AWS-native deployments, TigerGraph for deep traversals on billion-edge graphs, Memgraph for streaming analytics. We pick per workload.

Entity resolution, validated against your own labels

Two-stage resolution — LSH blocking, then a classifier combining string similarity, structural graph features, and model reasoning for ambiguous cases, measured against labels you supply.

Streaming ingest

Change-data-capture from your source systems via Kafka or Airbyte. The graph stays fresh incrementally — no full nightly rebuilds, no stale traversals.

GraphRAG query layer

A chain that translates natural language to Cypher, executes it against the graph, then feeds the structured results plus hybrid vector hits into the model for cited reasoning.

Schema enforced in code

Every entity type, relation and model output is validated against typed schemas. Schema drift fails loudly in CI rather than silently in production.

Query observability

Latency per query type at p50, p95 and p99, cache hit rates, slow-query traces and embedding-call cost. We tune the schema and indexes until the targets hold under your load.

Use cases

Where a graph pays for itself

Five domains where the question itself is a traversal, and the answer cannot be reached any other way.

Financial services

KYC and AML investigations

Resolve beneficial-owner networks across the CRM, transaction systems and external watchlists. Multi-hop traversals surface indirect exposure that flat lookups miss.

A multi-family-office platform uses the graph to answer KYC-refresh questions that previously required re-reading the source documents for every entity.

Pharma and life sciences

Drug, target and pathway reasoning

Unify internal trial data with public ontologies into one graph, so a researcher can ask which targets in a portfolio share pathways with approved drugs.

Built so a hypothesis-level question is one traversal, not a multi-day literature triage.

Legal

Case-law cross-citation

Graph every internal matter, opinion and external citation, so precedent chains, conflicting rulings and jurisdiction patterns come back from a single query.

Built so a conflict check is a single graph query rather than a manual cross-system search.

Engineering and manufacturing

Parts, supplier and defect networks

Link bills of materials, supplier contracts, defect reports and field-failure data, so a defect spike returns the affected items, customers, suppliers and warranty exposure together.

Built for the moment a defect spikes: a single traversal answers 'what else does this touch?', replacing manual cross-referencing of BOMs, defect logs and warranty records.

Customer success

Account, contact and deal intelligence

Merge CRM records, message history, call transcripts and product telemetry into one customer graph, so every touchpoint, champion and blocker sits in a single view.

Built to surface at-risk accounts from relationship signals a per-system view cannot see.

Implementation

A phased delivery, not a discovery exercise

The schema comes from your top-twenty questions, so the graph is shaped by what you need to ask rather than by what happened to be in the source systems.

Weeks 1–6

Schema and ingestion

Workshop the top-twenty questions the graph must answer. Design entity types, relation types and the provenance model. Stand up connectors to three to five source systems and load the first entities.

Weeks 7–14

GraphRAG query layer

Build the query pipeline, hybrid retrieval and reasoning step. Stand up the evaluation harness with a golden question set across the priority use cases.

Weeks 15–18

Production hardening

Observability, latency tuning, a cache layer, role-based access in the graph store, audit-log export and cutover. Evaluation gates block any regression on the golden set.

Ongoing

Expansion

Add the remaining source systems through the same pattern, and layer in new entity types as new use cases arrive. New questions stop costing engineer-weeks.

The rule that gets it approved

Every answer cites the nodes it used

An answer nobody can audit is an answer compliance will not let you ship.

Provenance is carried at the edge level, not bolted on at the end: every relationship records the source record it came from, and edges are versioned rather than overwritten, so an answer given last quarter can still be explained this quarter.

Let us design your graph schema

A working session with a senior engineer: we map your top-twenty questions to entities, edges and a pipeline — and tell you honestly whether GraphRAG is the right call, or whether a simpler retrieval system would answer them.
Our second practice

This is our AI engineering practice

It is real work and it is where our four products came from. But what Cognilium leads with is narrower: optimization apps that run in tandem with Microsoft Dynamics 365, computing the decisions the ERP records but does not derive — the optimal price, the optimal pick path, the optimal stock level. See the optimization apps · How we build inside the ERP.