Graph RAG Pipelines

The tutorial version of RAG has three steps: embed the documents, search for similar chunks, hand them to a model. It demos well. In production it breaks on the questions people actually ask: a question that spans three documents, a term that means two different things, a "which of our customers…" that needs relationships rather than similar sentences.

I design and build retrieval pipelines that hold up on those questions, and add a knowledge graph where the domain needs one.

The problems a production pipeline has to solve

• Classification. Not every question is a retrieval question. Some are lookups in your database, some need a document, some need both, and some should be refused.
• Ambiguity. "Contract", "account" or "case" can mean different things in different parts of the business. The pipeline resolves them before it searches.
• Context overflow. Stuffing the top twenty chunks into a prompt is not retrieval. Selecting, ranking and compressing context is where most of the quality comes from.
• Flat retrieval. Similarity search finds passages that sound alike. It does not follow "this product depends on that component, which is supplied by this vendor". A graph does.
• Intent. The same words can ask for a summary, a comparison or a decision. The pipeline has to know which.

What a graph adds

A knowledge graph stores the entities in your domain and the relationships between them: customers, products, contracts, components, regulations, people. Retrieval can then walk the graph from the entities in a question to everything connected to them, and hand the model a structured, relevant context instead of a pile of similar paragraphs. Answers become traceable: you can show which nodes and documents they came from.

Not every system needs a graph. Part of the work is deciding whether yours does, and I will tell you if plain retrieval is enough.

How I build it

• Schema design for your domain's entities and relationships, starting small and grounded in real questions.
• Ingestion that extracts entities and relations from documents and joins them to the records already in your database.
• Retrieval that combines graph traversal, full-text and vector search, usually on PostgreSQL before reaching for anything more exotic.
• Evaluation with a fixed set of real questions and expected answers, run on every change, so quality is measured rather than felt.
• Delivery through your application, an API, or an MCP server so any AI client can use it.

What you get

• A retrieval design document: classification rules, graph schema, retrieval strategy and evaluation set.
• A working pipeline over your data, with measured answer quality.
• Tools for keeping the graph current as documents and records change.

When it fits

You have tried basic RAG and the answers are plausible but wrong, or right but impossible to verify. Or your questions are about relationships: dependencies, ownership, compliance chains, who-is-connected-to-what.