Graph neural networks for relational business data
When product catalogs, customer behavior, and supply chains form heterogeneous graphs, GNNs offer structural advantages over matrix methods. Practical considerations for deployment at commercial scale.
Business data as graphs
The relational structure of business data is often modeled away in practice. Tabular representations of customer-product interactions, for instance, encode which interactions occurred but lose the topology of the interaction network — which customers share product affinities, how product similarity clusters are structured, and how these structures evolve over time. Collaborative filtering and matrix factorization methods exploit the bipartite structure of the interaction matrix but treat all entities as exchangeable, ignoring additional relational context.
Many commercially relevant phenomena are fundamentally graph-structured. Supply chain risk propagates through supplier-buyer networks. Fraud propagates through transaction networks. Demand signals propagate through product similarity graphs. When the phenomenon of interest is a network effect, methods that model the network explicitly have a structural advantage over methods that treat observations as independent or rely on covariance structure alone.
What GNNs learn that matrix methods do not
Graph neural networks learn representations by aggregating information from neighborhood structures. A GNN node embedding for a product encodes not just that product's attributes and interaction history, but the attributes and histories of its graph neighbors — products frequently co-purchased, semantically similar products, products in the same supply chain tier. This neighborhood aggregation enables the model to learn representations that reflect structural position in the graph, not just node-level features.
The practical consequence is that GNNs generalize better to new or low-engagement nodes (the cold-start problem) by leveraging neighborhood structure, and they can propagate signals — anomalies, demand shocks, disruptions — through the graph topology in ways that capture realistic transmission dynamics. These capabilities are most valuable in domains where the graph structure is dense, heterogeneous, and causally relevant to the prediction task.
Heterogeneous graphs and real-world complexity
Real business graphs are heterogeneous: they contain multiple node types (customers, products, suppliers, locations) and multiple edge types (purchased, similar-to, supplied-by, located-in) with different semantic meanings. Heterogeneous GNN architectures (HAN, HGT, RGCN) handle this by learning separate transformation weights for each edge type and combining them through type-specific aggregation schemes.
The expressiveness of heterogeneous GNNs comes at a cost: the number of parameters grows with the number of edge types, training requires careful negative sampling strategies for each relation type, and the resulting models can be difficult to interpret without attention mechanisms that surface which edge types drove a given prediction. For operational deployment, this complexity requires robust schema management — the graph schema must be versioned, and schema changes (new product categories, new supplier relationships) must be handled without full model retraining.
Deployment considerations at commercial scale
GNN inference at commercial scale faces a well-documented challenge: the neighborhood expansion problem. Computing the embedding for a single node requires aggregating over its neighbors, which requires aggregating over their neighbors, and so on for however many GNN layers are stacked. For dense commercial graphs, this can mean processing millions of nodes to compute a single embedding — which is incompatible with low-latency serving requirements.
Production GNN systems address this through neighborhood sampling (GraphSAGE and its variants), precomputed embeddings with incremental updates, or separation of offline representation learning from online inference. The right approach depends on how frequently the graph changes and what latency budget the serving application requires. Getting this right is a significant engineering effort, and it is typically the factor that determines whether a GNN system is commercially viable rather than any property of the model architecture itself.
Working on a complex AI problem?
Our research orientation means we're always interested in technically challenging problems. Let's explore what's possible.