Taking graph learning from research into production depends on more than sophisticated algorithms. It starts with trustworthy entities, meaningful relationships and a graph that accurately reflects the real world. At Big Data London, I talked about how to take graph machine learning from research to production.

Graph learning is often discussed as a modeling problem, with the discussion focused on the choice of approach: whether to use a graph neural network, feed graph features into a conventional machine learning model, or apply GraphRAG.

These are important questions. But after building analytical models on production graphs containing billions of nodes and edges, my experience is that modeling isn’t the hardest part. In our work, modeling accounts for a relatively small proportion of the overall effort. The bigger challenge is creating a graph that can be trusted.

When the graph gets the real world wrong

My Spotify Wrapped once contained a surprise: “Never Ever” by All Saints appeared as one of my most-played songs. I hadn’t been listening to it, but my partner had on our shared account. From a data perspective, two people had effectively become one. That didn't just affect my annual summary but also influenced the picture Spotify had built of my — our — listening behavior and, consequently, the music being recommended to me.

When two records representing the same person remain disconnected, the graph is incomplete. If unrelated organizations are incorrectly connected because of a shared attribute, the graph can represent a relationship that doesn't exist. No modeling technique can compensate for a graph that gets the real world wrong.

One wrong edge can change everything

Graph data quality is different from conventional tabular data quality because meaning comes from relationships.

Imagine two separate transaction communities. There’s no path between them. Now introduce one erroneous connection and suddenly the two communities become one.

That can change shortest paths, network size, distance to known risk and centrality measures such as PageRank. Features derived from that structure change too.

Fig 1: See how one wrong edge can change the statistics across the whole graph.

This leads to three recurring challenges:

Overlinking: This happens when records or networks are joined when they should remain separate. A shared address or telephone number, for example, doesn't necessarily mean two people or companies are meaningfully connected.

Underlinking: The opposite. Records belonging to the same real-world person or organization remain disconnected, leaving the model analyzing fragments rather than the whole entity.

Missing provenance: This creates a different problem. If nobody can explain which source or rule created a relationship, it becomes difficult to defend the features and predictions based on it.

These problems don’t disappear with a more sophisticated model. Classical machine-learning models can calculate features from false relationships, graph neural networks can propagate information through the wrong neighborhood, and GraphRAG can retrieve information by following incorrect connections. Different techniques but the same underlying graph and the same underlying weaknesses.

Start with real-world entities

Enterprise data isn’t organized around unique people, organizations, and accounts. It comes from different systems as separate records. One system might contain “John Smith”, another “J Smith” and another “Smith, John”. Other attributes may agree, conflict or be missing.

Entity Resolution determines which records refer to the same real-world entity and which should remain separate. Rather than relying on one common field, evidence across attributes can be used to create a more reliable representation.

Fig 2: How external data such as registries, sanctions lists, and adverse media help a graph reflect the real world.

This matters enormously for graph analytics, especially when it has real-world consequences. Without resolution, records for the same person can become separate nodes with incomplete relationships. If you resolve them correctly, the graph instead represents one real-world entity and its connections.

External sources such as company registries, sanctions lists and adverse media can add further information, helping the graph better reflect the world outside an organization's own systems.

Build the ontology around the use case

Once you've established the entities, you need to decide what their relationships mean. A person may be connected to a company as a director. Another person might be a beneficial owner. These aren't simply edges. They represent different real-world relationships, which is why the ontology needs to be designed deliberately around the use case.

For shell-company detection, directorships, incorporations and resignations may be important. Other use cases will require a different view of the same underlying world. Each relationship should retain its provenance, including its source, the rule that created it, and its effective date.

This creates an important distinction between an all-encompassing enterprise ontology and a use-case-specific ontology. For production analytics, the objective isn't necessarily to model everything. It's to model the entities and relationships required to make a particular decision.

Fig 3: An ontology should be tied to a use case. Ensure entity and link types are agreed before the pipeline exists.

You may not need a graph neural network

With the right graph in place, model selection becomes easier. A useful question to start with is can you describe the network pattern you're looking for? If you can, graph features combined with conventional machine learning can be extremely effective.

For shell-company detection, for example, Quantexa can derive network features such as centrality from the knowledge graph while also modeling behaviors such as directors resigning shortly after incorporation. Those features can then feed a conventional machine-learning model.

Fig 4: This example of a shell company detection model combines network centrality signals with registry evidence, such as founding directors who resign soon after incorporation.

One advantage of this approach is that its features have clear names and meanings. Techniques such as SHAP can show how individual features contributed to a prediction, while lineage can trace the information supporting it.

Fig 5: How to ensure your outcome is explainable.

When the important graph structure cannot be described in advance, a graph neural network may be appropriate. But greater sophistication should not be the objective by default.

Context generation is the real production challenge

Much of the work required to operationalize graph learning therefore happens before modeling:

1. Curate the source data.

2. Resolve records into real-world entities.

3. Define the use-case ontology.

4. Construct the relevant graph.

5. Create meaningful features.

6. Train, explain and deploy the model.

I think of those first five stages as context generation: turning fragmented data into a representation of the real world that a model can learn from.

And that's perhaps the biggest lesson from putting graph learning into production. The model matters, but the model can only learn from the world we've represented for it.

Get the entities wrong, and the relationships can be wrong. Get the relationships wrong, and the graph can be wrong. Get the graph wrong, and even a sophisticated model can produce a convincing version of the wrong answer.

Check out my colleague Rob French's latest blog, Before AI, Get The Entity Right to learn more about reliable AI, analytics, and decision making.