When a knowledge graph earns its keep

Knowledge graphs are not a default ingredient of applied AI. Most systems ship without one and are right to. A graph is a deliberate investment: extraction pipelines to build it, curation to keep it honest, and infrastructure to serve it. The interesting question is not whether graphs are good, it is when they earn their keep.

The clearest signal is that your questions are about relationships, not documents. If users ask "which supplier connects these two failures" or "who touched this system between March and May," you are asking the data to be traversed, not summarized. Retrieval over text chunks answers "what does this document say." A graph answers "how do these things relate," and no amount of clever chunking closes that gap.

The second signal is that answers must carry provenance. A language model is brilliant at reasoning over text and unreliable at remembering what is true. A graph holds entities, relationships, and sources in a structure you can query and audit. Put a model on top and you get answers in plain language where every claim traces back to a specific, checkable fact. On one program, that combination meant a question asked in plain English returned not just an answer but the evidence chain behind it, including when each fact entered the record.

The third signal is that facts change and the history matters. Temporal graphs track not only what is true but what was true, and when it stopped being true. If your domain never changes, a static index is cheaper. If it changes weekly and decisions depend on the timeline, the graph is doing work nothing else can.

If none of those describe your problem, skip the graph. Plain retrieval-augmented generation over well-managed documents is faster to build, cheaper to run, and easier to maintain. The graph is not a badge of sophistication. It is a tool with a narrow, valuable niche, and knowing the boundary of that niche is the actual expertise.