Knowledge Graph

A knowledge graph is basically a network of information. Nodes represent entities (people, places, concepts, things). Edges represent relationships between entities. Attributes describe properties of entities. The graph structure lets you represent complex relationships and traverse them logically.

Example: In a knowledge graph for a company, "John Smith" is a node. "Marketing Department" is a node. "Works In" is an edge connecting them. "Senior Manager" is an attribute of John. "Budget $500k" is an attribute of Marketing Department. The graph captures that John works in Marketing and represents his role and the department's resources.

The power comes from traversal. Given John, you can find what department he works in. Given the department, you can find who works there. You can find relationships several hops away: "Find all colleagues of John." "Find all projects John's department manages." "Find all budget allocations across Marketing-related projects." This is what traditional databases struggle with because relationships are implicit in foreign keys rather than explicit in the graph.

Knowledge graphs are everywhere. Google's Knowledge Graph (originally just for search results, now powers much of Google's understanding). DBpedia and Wikidata (crowdsourced knowledge). Enterprise knowledge graphs (companies building graphs of their customers, products, relationships). Medical knowledge graphs (diseases, symptoms, treatments, relationships).

Building a knowledge graph is labor-intensive. You need to identify entities (is "Apple Inc." the same as "AAPL" stock ticker?). You need to extract relationships from unstructured text (if a document says "John is the CEO of Acme Corp," you need to extract that relationship). You need to resolve contradictions (one source says John is CEO, another says Sarah is CEO, what's true?). This is called knowledge graph construction and it's complicated.

There's overlap between knowledge graphs and RAG. RAG stores documents in a vector database and retrieves by similarity. Knowledge graphs store structured relationships and retrieve by logical traversal. Some systems use both: RAG for document similarity, knowledge graph for relationship-based queries. Hybrid approaches often work best.

Knowledge graphs excel at structured queries and relationship traversal. "Show me all transactions between John's team and the Finance department in the last quarter." This is hard in RAG but straightforward in a knowledge graph if relationships are explicit. But knowledge graphs struggle with open-ended semantic queries. "Find documents about recent market trends." This is natural in RAG but awkward in a knowledge graph.

Maintenance becomes a challenge as the graph grows. As entities and relationships accumulate, consistency becomes hard to maintain. Is this person the same entity in two places or a duplicate? Did this relationship change, or is old data stale? Large knowledge graphs require governance and versioning.

Reasoning over knowledge graphs is a frontier. Given a knowledge graph plus reasoning rules, you can infer new relationships. If "John manages Sarah" and "Sarah manages Alex," you can infer "John manages Alex" (transitive). If "John is in Marketing" and "Marketing budgets $500k," you can infer "John has access to $500k budgets." This is called knowledge graph reasoning and enables deeper insights.

Knowledge graphs are increasingly integrated with LLMs. An LLM can query a knowledge graph to ground its responses in factual relationships. You ask the LLM "Who should approve this budget request?" The LLM queries the knowledge graph, finds the approval hierarchy, returns the answer grounded in organizational structure rather than hallucinated.