Graphs for Ai and ML

Editor's Notes

• #2: Focus: is on graph analytics in this talk.
• #4: ML - this is what nerds do. Sometimes ML is so compelling that it seems intelligent, but in reality it’s data and algorithms AI - train a system to classify animals, might also work on shoes. See: hot dog; not hot dog! GP-AI - systems like AlphaGo might be an architecture to support this in future, but we’re not there today
• #5: GP-AI - systems like AlphaGo might be an architecture to support this in future, but we’re not there today
• #7: Here’s where we are mostly today. Row-oriented data. Maybe some documents, maybe some columns, but mostly rows of data from arcane data models.
• #10: You already know graphs
• #11: People talk about Codd’s relational model being mature because it was proposed in 1969 – 49 years old. Euler’s graph theory was proposed in 1736 – 282 years old. Now we use the labelled property graph model. A very simple set of idioms that can build very sophisticated models.
• #12: Graphs are the most natural way to model most domains. You already know this because you draw graphs on a whiteboard, but you’ve never had the opportunity to take that down into the database before. Nodes are a bit like documents, but they’re flat at present in Neo4j. You pour data into your nodes and then connect them – easy peasy. This enables high fidelity domain modeling because this is how your domains work. And you don’t have to do this stuff in your application code – it’s right there in the database Let’s prove it by exploring a fun domain…
• #13: Graphs are the most natural way to model most domains. You already know this because you draw graphs on a whiteboard, but you’ve never had the opportunity to take that down into the database before. Nodes are a bit like documents, but they’re flat at present in Neo4j. You pour data into your nodes and then connect them – easy peasy. This enables high fidelity domain modeling because this is how your domains work. And you don’t have to do this stuff in your application code – it’s right there in the database Let’s prove it by exploring a fun domain…
• #14: If you want to know who followed Matt Smith, easy! Traversing the regenerated (or any) relationship takes about 1/40 millionth of a second on this mac in a steady state database
• #15: What if you want to know who preceded Matt Smith? Easy. Traverse the regenerated rels in the other way. Cost? About 1/40 millionth of a second on this laptop in a steady state database.
• #16: Joins are super cheap for good graph DBs On my laptop, I can get to 40M traversals/sec in a steady state DB You can explore a lot of data very quickly Which makes it a good fit for data intensive applications like ML
• #17: My shortest path to Doctor Who?
• #18: But before we get to ML, let’s take a step back into my history building smart systems
• #19: All the way back to Autumn 2008
• #20: November 2007 met Emil at Øredev in Malmö Sweden Java and Maven build-your-own-DBMS toolkit called Neo4j Java Core API only Long afternoon of loading data and writing a recommendation query...
• #22: Find the current customer Find things they own Find things that depend on the things they own Sell Repeat All we did at first was understand the dependencies between products and bundles. We never tried to upsell something incompatible. Never tried to sell them something they already owned. Never undersold them. And it opened a world of possibilities to combine other graphs: demographic, social, geographical, municipal, network... The system made intelligent suggestions, but it was not ML or AI, just graph queries. It was good.
• #23: Unexpectedly Powerful Solved a problem in a long afternoon was meant to take years with off-the-shelf software Applied same pattern to PoS retail recommendations, fraud detection… in subsequent months Still amazed! Effect: join Neo4j as Chief Scientist in 2010. So let’s get into graphs.
• #24: Realtime retail recommendations. Historical anecdote about beer and nappies.
• #25: Large UK retailer We had a data model Some of it taxonomical Some of it stock-centric. Some transactional
• #26: START n=node(*) MATCH n-[r?]->() DELETE n,r CREATE (daddy1:Person { name: 'Mickey Smith', dob: 19781006 }) CREATE (alcohol:Category { category : 'alcoholic drinks'}) CREATE (beer:Category { category : 'beer'}) CREATE beer-[:MEMBER_OF]->alcohol CREATE (peeweePilsner:Product { sku: '2555f258', product: 'Peewee Pilsner' }) CREATE (badgersNadgers:Product { sku: '5e175641', product: 'Badgers Nadgers Ale' }) CREATE peeweePilsner-[:MEMBER_OF]->beer CREATE badgersNadgers-[:MEMBER_OF]->beer CREATE daddy1-[:BOUGHT]->peeweePilsner CREATE daddy1-[:BOUGHT]->badgersNadgers CREATE (baby:Category { category: 'baby' }) CREATE (nappies:Category { category: 'nappies' }) CREATE nappies-[:MEMBER_OF]->baby CREATE (babyDryNights:Product { sku: '49d102bc', product: 'Baby Dry Nights'}) CREATE babyDryNights-[:MEMBER_OF]->nappies CREATE daddy1-[:BOUGHT]->babyDryNights CREATE (consumerElectronics:Category { category: 'consumer electronics' }) CREATE (console:Category { category: 'console' }) CREATE (xbox:Product { sku: '49d102bc', product: 'XBox 360' }) CREATE xbox-[:MEMBER_OF]->(console)-[:MEMBER_OF]->consumerElectronics CREATE daddy1-[:BOUGHT]->xbox CREATE (mummy1:Person { name: 'Rose Tyler', dob: 19800317 }) CREATE (wine:Product { sku:'3a3f22bc', product: 'Shiraz' }) CREATE wine-[:MEMBER_OF]->alcohol CREATE mummy1-[:BOUGHT]->wine CREATE mummy1-[:BOUGHT]->babyDryNights CREATE (daddy2:Person { name: 'Rory Williams', dob: 19880121 }) CREATE daddy2-[:BOUGHT]->peeweePilsner CREATE daddy2-[:BOUGHT]->babyDryNights // Cypher 1.0 query START beer=node(2), nappies=node(7), xbox=node(11) MATCH (daddy)-[:BOUGHT]->()-[:MEMBER_OF]->(beer), (daddy)-[:BOUGHT]->()-[:MEMBER_OF]->(nappies), (daddy)-[b?:BOUGHT]->(xbox) WHERE b is null RETURN distinct daddy // Cypher 2.0 query MATCH (d:Person)-[:BOUGHT]->()-[:MEMBER_OF]->(n:Category), (d:Person)-[:BOUGHT]->()-[:MEMBER_OF]->(b:Category), (c:Category) WHERE n.category = "nappies" AND b.category = "beer" AND c.category = "console" AND NOT((d)-[:BOUGHT]->()-[:MEMBER_OF]->(c)) RETURN DISTINCT d AS daddy
• #27: The insight here is that we have a typical young father who buys beer, nappies and a game console simply by reducing subgraph We have a pattern to search for
• #28: We knew it was young fathers, but I bet your model would classify them as lazy, drunken, gamers right?
• #29: Now we look for young fathers – implied by beer and nappies purchases – who haven’t bought a game console.
• #30: Turn it to text. And…
• #33: Neo4j 2.0: MATCH (u:User), (n:ProductType), (b:ProductType), (x:ProductType) WHERE n.name = "nappies" AND b.name = "Beer" AND x.name = "Xbox" AND (u)-[:BOUGHT]->()<-[:MEMBER_OF]-(n) AND (u)-[:BOUGHT]->()<-[:MEMBER_OF]-(b) AND NOT((u)-[:BOUGHT]->()<-[:MEMBER_OF]-(x)) RETURN u
• #34: Neo4j 2.0: MATCH (u:User), (n:ProductType), (b:ProductType), (x:ProductType) WHERE n.name = "nappies" AND b.name = "Beer" AND x.name = "Xbox" AND (u)-[:BOUGHT]->()<-[:MEMBER_OF]-(n) AND (u)-[:BOUGHT]->()<-[:MEMBER_OF]-(b) AND NOT((u)-[:BOUGHT]->()<-[:MEMBER_OF]-(x)) RETURN u
• #35: Neo4j 2.0: MATCH (u:User), (n:ProductType), (b:ProductType), (x:ProductType) WHERE n.name = "nappies" AND b.name = "Beer" AND x.name = "Xbox" AND (u)-[:BOUGHT]->()<-[:MEMBER_OF]-(n) AND (u)-[:BOUGHT]->()<-[:MEMBER_OF]-(b) AND NOT((u)-[:BOUGHT]->()<-[:MEMBER_OF]-(x)) RETURN u
• #36: Neo4j 2.0: MATCH (u:User), (n:ProductType), (b:ProductType), (x:ProductType) WHERE n.name = "nappies" AND b.name = "Beer" AND x.name = "Xbox" AND (u)-[:BOUGHT]->()<-[:MEMBER_OF]-(n) AND (u)-[:BOUGHT]->()<-[:MEMBER_OF]-(b) AND NOT((u)-[:BOUGHT]->()<-[:MEMBER_OF]-(x)) RETURN u
• #42: This is fast: query latency is proportional to the amount of graph searched
• #43: Now called “network science”
• #44: First we need to talk about some local properties
• #45: A triadic closure is a local property of (social) graphs whereby if two nodes are connected via a path involving a third node, there is an increased likelihood that the two nodes will become directly connected in future. This is a familiar enough situation for us in a social setting whereby if we happen to be friends with two people, ultimately there's an increased chance that those people will become direct friends too, since by being our friend in the first place, it's an indication of social similarity and suitability. It’s called triadic closure, because we try to close the triangle.
• #46: We see this all the time – it’s likely that if we have two friends, that they will also become at least acquaintances and potentially friends themselves! In general, if a node A has relationships to B & C then the relationship between B&C is likely to form – especially if the existing relationships are both strong. This is an incredibly strong assertion and will not be typically upheld by all subgraphs in a graph. Nonetheless it is sufficiently commonplace (particularly in social networks) to be trusted as a predictive aid.
• #47: Sentiment plays a role in how closures form too – there is a notion of balance.
• #48: From a triadic closure perspective this is OK, but intuitively it seems odd. Cartman’s friends shouldn’t be friends with his enemies. Nor should Cartman’s enemies be friends with his friends.
• #49: This makes sense – Cartman’s friend Craig is also an enemy of Cartman’s enemy Tweek Two negative sentiments and one positive sentiment is a balanced structure – and it makes sense too since we gang up with our friends on our poor beleaguered enemy
• #50: Is this true? Yes. Is it nice? No. Is it realistic? Oh yes.
• #51: Another balanced – and more pleasant – arrangement is for three positive sentiments, in this case mutual friends.
• #54: A starting point for a network of friends and enemies 100 years on from the armistice Red links indicate enemy of relationship Black links indicate friend of relationship The Three Emperor’s league
• #55: Italy forms the with Austria and Germany – a balanced +++ triadic closure If Italy had made only a single alliance (or enemy) it would have been unstable and another relationship would be likely to form anyway! Triple Alliance
• #56: Russia becomes hostile to Austria and Germany – a balance --+ d triadic closure becomes agnostic towards France. German-Russian Lapse
• #57: The French and Russians ally, forming a balanced --+ triadic closure with the UK French-Russian Alliance
• #58: The UK and France enter into the famous Entente Cordiale This produces an unbalanced ++- triadic closure with Russia, and the graph doesn’t like it.
• #59: The British and Russians form an alliance, thereby changing their previously unbalanced triadic closure into a balanced one. Other local pressures on the graph make other closures form. Italy becomes hostile to Russia, forming a balanced --+ closure with the France, and another balanced --+ closure with the UK. Germany and the UK become hostile forming a balanced --+ closure with Austria and another balanced --+ closure with Italy British-Russian Alliance
• #60: That WWI can be predicted without domain knowledge by iterating a graph and applying local structural constraints is nothing short of astonishing to me. Note how the network slides into a balanced labeling — and into World War I.
• #61: A very surprising result: graphs don’t know about human conflicts.
• #63: In this case the string triadic closure property still holds – though it is a weak link that characterises the relationship between Stan and Cartman. Given a starting graph, we can apply this simple local principal to see how it would evolve.
• #64: In this case the string triadic closure property still holds – though it is a weak link that characterises the relationship between Stan and Cartman. Given a starting graph, we can apply this simple local principal to see how it would evolve.
• #66: A local bridge acts as a link – perhaps the only realistic link - between two otherwise distant (or separate) subgraphs. Local bridges are semantically rich – they provide conduits for information flow between otherwise independent groups. In this case DATING is a local bridge – it must also be a weak relationship according to our definition of a local bridge Intuitively this makes sense – your girl/boyfriend is rather less important at age 8 than your regular friends, IIRC.
• #67: How do we identify local bridges? Any weak link which would cause a component of the graph to become disconnected. Being able to identify local bridges is important – in this case it’s the only know conduit to allow the girls and boys to communicate. In real life local bridges are apparent in your organisation as experts (or managers); appear as nexus in fraud cases;
• #68: Zachary in the Journal of Anthropological Research 1977 Intuitively we can see “clumps” in this graph. But how do we separate them out? It’s called minimum cut.
• #69: What’s interesting is that it’s mechanical – no domain knowledge is necessary. There’s only one failure with the method Zachary chose to partition the graph: node 9 should have gone to the instructor’s club but instead went with the original president of the club (node 34). Why? Because the student was three weeks away from completing a four-year quest to obtain a black belt, which he could only do with the instructor (node 1) Other minimum cut approaches might deliver slightly different results, but on the whole it’s amazing you get such insight from an algorithm!
• #70: But is there enough information in the graph itself to predict the schism?
• #71: But is there enough information in the graph itself to predict the schism?
• #72: Actually neo4j already has a bunch of these algorithms. Call them easily from Cypher Emergent intelligence from the graph!
• #73: Efficiency for graph operations is paramount. You don’t need huge macho clusters to do this.
• #74: Large payment provider, transaction history A 300M node, ~18B rel graph pageranked with 20 iterations in less than 2 hours using the graph algos. On commodity hardware.
• #75: Contemporary AI
• #76: Graph structure itself is rich. In this example we don’t need to know the content of the messages to know they’re spam at high confidence, just their position in the graph. Mine a vector of graph features, feed it into the trained model. Graphs have a key advantage: structural context. Where is the node in the graph? Who are its neighbours? Etc. That richness feeds into the model and makes it better, more accurate, more dependable. PageRank, Degree, Neighbourhood, Colour, etc are all features that improve your ML outcomes but are only available from graphs.
• #79: ICLR = International Conference on Learning Representations Graph of movies that a user liked. Feed into neural net Graph of users who rated one of those movies. Feed into neural net. Recurse through the data until you get to all the movies and all the users which are just embedding vectors (fancy hashes that place like near like in a vector space). [Can change these vectors for features to avoid cold-starts, without changing overall architecture.] Graph of back-propagated trained neural nets. Incremental: Scalable for both training and prediction. Extensible: bring in other graph layers! Better than collaborative filtering because it can work on any graph, not just bipartite user-likes-movies graphs. E.g. User likes actor in movies with genre – much richer! A bipartite graph, also called a bigraph, is a set of graph vertices decomposed into two disjoint sets such that no two graph vertices within the same set are adjacent. I.e. Users don’t connect to users, only to movies. This is already happening - it’s YouTube’s recommender algorithm.
• #80: A growing realisation from leaders in the AI community: graph networks as the foundational building block for human-like AI. Argue: combinatorial generalization must be a top priority for AI to achieve human-like abilities. Must be able to compose a finite set of elements in infinite ways (eg like language) We draw analogies by aligning the relational structure between two domains and drawing inferences about one based on corresponding knowledge about the other (Gentner and Markman, 1997; Hummel and Holyoak, 2003). Hierarchies are critical. Inductive bias: how the algorithm prioritises solutions. Relational inductive biases to guide deep learning about entities, relations, and rules for composing them. I.e. the learning understands graphs
• #81: All this might seem hard at first – we’re used to tables, and our toolkits expect them. Graphs changes this for the better. Once you get graphs, all the other things seem hard
• #82: “a vast gap between human and machine intelligence remains, especially with respect to efficient, generalizable learning” 70% of graph ML today is still turning graphs to vectors E.g. deep walk - random walk through graph, assign vector node when encountered based on neighborhood 30% is truly graph AI - “differential neural computer” -> discern patterns that users can’t; write sophisticated algorithms (fraud, shortest path, etc) from incentive declarations. E.g. no longer need a human expert to discover the “young father” pattern in our data, the machine learns it’s a valuable query in some contexts. So enjoy using graphs for AI, but please remember graphs for good!