Matin Labkhandagh

Service

GraphRAG development on Neo4j

GraphRAG development means building retrieval over a knowledge graph, so the system can follow relationships between entities instead of only matching text by similarity. I am Matin Labkhandagh, and I design and build GraphRAG pipelines on Neo4j, combined with vector retrieval, reranking and source-cited generation, then measure them with RAGAS and an LLM-as-a-Judge harness, as I did for the eight-agent Jozveh-AI pipeline.

When you need this

  • Users ask questions that span several documents, and the vector retriever returns the best single passage when the answer needed three connected ones.
  • Your domain has real structure, such as courses, sections, sources, products, parts or regulations, and flattening it into chunks throws that structure away.
  • You raised top-k to compensate, the context window filled with near-duplicates, and faithfulness went down instead of up.
  • Someone proposed GraphRAG and nobody can say whether it will pay for the extra modeling, ingestion and query complexity.
  • You already have a graph or a relational schema and want retrieval to use it instead of re-embedding everything.

What you get

  • GraphRAG fit assessment: which of your question classes need multi-hop context and which are already served well by vector RAG.
  • Neo4j graph schema: node labels, relationship types and properties designed around your entities, with the ingestion pipeline that populates them.
  • Hybrid retrieval layer: graph traversal plus vector search, merged and reranked before generation.
  • Source-cited generation with post-generation grounding filters tied to graph provenance.
  • Golden set of multi-hop questions and a RAGAS plus claim-level LLM-as-a-Judge harness that compares GraphRAG against the vector baseline.
  • LangGraph orchestration around the retrieval stage, with state and retry handling for graph queries and provider calls.
  • Evaluation tests as acceptance criteria, run in CI.
  • Docker deployment including Neo4j, plus documentation of the schema, the queries and how to extend the graph.

Outcomes

  • A clear decision, in writing, on whether GraphRAG is justified for your question types, before any graph is built.
  • A Neo4j graph schema that mirrors how your domain is actually connected, with an ingestion path that keeps it current.
  • Hybrid retrieval that combines graph traversal with vector search and reranking, so multi-hop questions get the connected context.
  • Generation that cites the nodes and passages it used, with grounding filters that remove claims the graph does not support.
  • An evaluation harness that shows the gain over the vector-only baseline on your own questions, not on a public benchmark.

How it works

  1. 1

    20-minute technical call

    You describe the questions that fail today and the shape of the data behind them. I ask whether the failures are about ranking or about missing connections, because only the second one is a GraphRAG problem. If it is a ranking problem, I will point you at the cheaper fix.

  2. 2

    Written diagnosis

    I take a sample of failing questions and show, for each, whether a graph traversal would have supplied the missing context. The diagnosis includes a first draft of the graph schema and a candid note on ingestion and maintenance cost, so you decide with the trade-offs in front of you.

  3. 3

    Fixed-scope proposal

    Scope, timeline and price in writing under the AI Agent Engineering Sprint, or the Prototype → Production AI Sprint when the graph needs observability, semantic caching and model routing around it. The scope names the entity types, the question classes covered and the evaluation metrics that define done.

  4. 4

    Implementation and handover

    I build the harness and the vector baseline first, then the graph schema, ingestion, hybrid retrieval and grounding filters against it. Handover includes the code, the documented Cypher queries, the Docker deployment, a runbook and a session with your team on extending the graph.

Proof: what I built

  • Jozveh-AI turns lecture audio and source material into cited, structured study documents. I built it as a LangGraph supervisor over eight agents with Neo4j GraphRAG at the retrieval layer, followed by reranking, source-cited generation, RAGAS, a custom claim-level LLM judge and post-generation grounding filters. The pipeline is covered by 673 tests across 77 files.

    Read the Jozveh-AI case study
  • The problem there was faithfulness at predictable cost, not raw model capability. A controlled model bake-off under the same harness showed that model choice was not the bottleneck; retrieval quality, grounding and the evaluation loop moved faithfulness more than swapping models did. The graph earned its place because it supplied context that similarity search kept missing.

    Read the Jozveh-AI case study

Questions about graphrag development on neo4j

When is GraphRAG worth it over vector RAG?
When the answer depends on relationships rather than on similarity: which sources support which claim, how a topic connects across chapters, which component depends on which. If your failing questions need context that sits two hops away from the passage the retriever found, a graph supplies it and vector search cannot. If the failures are wrong passages ranked above the right ones, reranking is the cheaper fix and I will recommend it first. The GraphRAG versus vector RAG guide walks through the decision with examples.
Can you improve an existing RAG system rather than replacing it?
Yes. GraphRAG is usually added alongside the vector retriever, not instead of it. I keep your embeddings and index, add a graph for the entity relationships that matter, and merge the two retrieval paths before reranking. The evaluation harness measures both configurations on the same golden set, so the decision to keep the graph rests on your own questions.
Do we need to already have a knowledge graph?
No. Most engagements start from documents or a relational database, and building the graph schema and the ingestion path is part of the work. If you already run Neo4j or have a schema, that shortens the sprint, and I design retrieval around what exists rather than remodeling it.
Can you evaluate an AI agent we already built?
Yes. The AI / LLM Technical Audit takes 5 working days and starts at $400. It reviews architecture, retrieval, tool calling, prompts, hallucination, latency, token cost and evaluation strategy, and delivers a prioritized implementation roadmap. For a system that already has a graph, the retrieval review includes whether the graph is actually used at query time or only populated at ingestion.
What does an evaluation harness include for GraphRAG?
A golden set weighted toward multi-hop questions, since those are where a graph should pay off; RAGAS faithfulness and relevance scores; a claim-level LLM-as-a-Judge that checks each statement against the retrieved nodes and passages; and a side-by-side run against the vector-only baseline. It runs in CI and is versioned with the schema, so a schema change and its effect on the score land together.