# Neo4j's course teaches GraphRAG; its own blog says when to skip it

> The two-hour DeepLearning.AI course builds a graph from SEC filings, but without a vector RAG baseline you cannot show a client the graph helps.

Original: https://fdetimes.net/en/books-courses/neo4j-knowledge-graphs-for-rag-course-review/

This 2 hour 4 minute course teaches you to build a knowledge graph for RAG. Yet the most useful sentence for an FDE is not in the course. It is on Neo4j's own blog: if GraphRAG does not improve your metrics, the effort of modelling and maintaining a graph is not worth it.

The two do not contradict each other. The course teaches you *how* to do GraphRAG; at a client, the harder job is deciding *whether* to do it at all. Anyone being asked by a client "why not use a knowledge graph?" should take the course, provided they know which parts carry over to client work and which they must fill in themselves.

## Two hours for three usable skills

"Knowledge Graphs for RAG" is a short course on DeepLearning.AI, taught by Andreas Kollegger, Lead for GenAI Innovation at Neo4j. The official page lists its most recent update as 7 October 2025.

The course promises three outcomes: using Cypher, Neo4j's query language, to manage and retrieve data in a graph; writing queries that find and format text so the LLM gets more relevant context; and building a question-answering system with Neo4j and LangChain.

Most of the hands-on material is about building a graph from text, using SEC filings as the dataset. Lesson 5 is titled "Constructing a Knowledge Graph from Text Documents", and the lesson on chatting with the graph comes at the end.

## In what order should you take it?

The course is tightly bound to LangChain. DeepLearning.AI recommends that you already know LangChain, or take "LangChain: Chat with Your Data" first. If you have never built a vector-based RAG pipeline, take that course first so you have a baseline to compare against.

Afterwards, Andreas Kollegger also teaches "Agentic Knowledge Graph Construction" (3 hours 8 minutes). It automates graph construction with a multi-agent system on Google ADK, with agents that identify the user's goal and then propose which nodes and relationships to extract. It fills exactly the schema gap the RAG course leaves.

## Lesson one: classify the questions before discussing a graph

Neo4j defines GraphRAG as a set of retrieval patterns based on graph structure, not a single product. And the company is explicit about when to skip the graph: if a question can be answered from one passage through semantic matching, vector search is still the right tool.

Graphs suit multi-hop questions, those where the relationships between facts are what matter.

Picture it with the course's own SEC data. "What is the biggest risk company A lists in this year's filing?" needs only one passage; vectors handle it well.

But "Which companies depend on the same supplier as company A?" requires going from A to the supplier and then back to the other companies. That is two hops, and this is where a graph has the advantage.

**Key point:** Ask how many hops a client's question needs before asking whether you need a graph.

## Lesson two: the real skill is formatting the context

Cypher takes a few sessions to get used to. What is more worth keeping is the course's second outcome: writing queries that both *find* and *format* text for the LLM. A good query does not return a heap of nodes; it returns something the model can read and understand.

Take the two-hop question above. Suppose your graph has `Company` nodes, `Supplier` nodes and a `DEPENDS_ON` relationship (an illustrative schema, not the course's). The query might look like this:

```cypher
MATCH (a:Company {name: 'Company A'})-[:DEPENDS_ON]->(s:Supplier)
      <-[:DEPENDS_ON]-(other:Company)
RETURN s.name AS supplier, collect(other.name) AS peers
```

The raw result is a few names and lists. The formatting step turns it into a sentence: "Company A depends on supplier S. Other companies that also depend on S: B, C." That string, together with the original passage from the filing, is the context sent to the LLM.

A tip for the exercises: print the exact context string sent to the LLM and read it as if you were the model. The model sees only what you give it, so if you find it confusing yourself, a clear answer is unlikely.

## Lesson three: write the acceptance test before you build

Neo4j's advice is to measure first. Before the first demo, agree with the client on a set of questions, a metric and a threshold. Then run a vector baseline, and only then run the graph on the same set of questions.

Suppose the client's question set is almost entirely single-passage. A graph is then unlikely to make a big enough difference to cover its maintenance cost, and you have just saved the client a few weeks of work. "No graph needed", backed by evidence, is a valuable result too.

## What the course skips takes the most effort

The course's question-answering system runs on structured text documents, not the messy data found at clients. Tian Pan, an engineer with deployment experience, warns that without a principled approach to entity deduplication a graph becomes fragmented, and in his view this can take more effort than extraction itself.

Concretely, if "Company A", "A Corp" and A's ticker symbol become three separate nodes, the two-hop query above matches only one of them, and the answer comes back incomplete without any error.

Tian Pan also argues that a hybrid design needs a router that decides when to enrich context with the graph and when to use vectors alone, and that such a router is hard to get right. The course does not teach this.

On your CV, do not just write "learned GraphRAG". Write that you compared a graph against a vector baseline on a specific question set, how you handled duplicate entities, and whether the final outcome was to keep or drop the graph. If a job description mentions "knowledge graph" or "Neo4j", have the story of those decisions ready to tell in interviews.

The course gets you to a working demo. Knowing when to drop the graph is something only clients can teach you.

**Try this week:**

- Take 20 real questions from a client or from the RAG project you are working on, label each one 'single passage' or 'multi-hop', and count which type dominates
- Work through the lesson 'Constructing a Knowledge Graph from Text Documents' and try rebuilding the graph on a messier set of your own documents, noting how many entities get split into several nodes
- Write the acceptance test before building the graph: which metric, what threshold, and how it is measured against the vector baseline

## Sources

- [Knowledge Graphs for RAG - DeepLearning.AI](https://www.deeplearning.ai/courses/knowledge-graphs-rag)

- [Knowledge Graphs for RAG - DeepLearning.AI](https://www.deeplearning.ai/short-courses/knowledge-graphs-rag/)

- [Agentic Knowledge Graph Construction - DeepLearning.AI](https://www.deeplearning.ai/courses/agentic-knowledge-graph-construction)

- [Intro to GraphRAG - GraphRAG Pattern Catalog](https://graphrag.com/concepts/intro-to-graphrag/)

- [Vector RAG vs. GraphRAG: Which retrieval do you need?](https://neo4j.com/blog/agentic-ai/vector-rag-vs-graphrag/)

- [GraphRAG vs. Vector RAG: The Architecture Decision Teams Make Too Late](https://tianpan.co/blog/2026/04/19/graphrag-vs-vector-rag-architecture-decision)