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

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.

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:

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.