Knowledge graphs (KGs) store entities and typed relations as structured memory—people, products, events, and the edges that connect them—so systems can query, constrain, and reason over facts. Public KG practice popularized in industry stacks (including Google-scale knowledge panels) still demands provenance locally rather than only retrieve similar text. This guide owns KG modeling, ontology trade-offs, entity resolution and linking, graph query versus graph embedding, basic graph ML, governance of changing graphs, and the precise boundary with retrieval-augmented generation. It parents under artificial intelligence and sits beside RAG, vector databases, embeddings, and AI search. It is not a RAG chunking encyclopedia, not a vector index ops manual, and not a twin of Brel’s productized entity-graph surface (draft: ai-entity-graph).
Use a KG when relationships and constraints are first-class. Use vectors when similarity search dominates. Use RAG when you need grounded natural-language answers. Mixing the buzzwords without choosing a contract produces expensive folklore.
Graphs as typed relations among entities—Brel’s operational map is the AI entity graph
A knowledge graph asserts nodes (entities) and edges (relations) with types and often properties: Company X —acquired→ Company Y on date D. Types make queries precise: “find suppliers of component C in region R” is a graph pattern, not a nearest-neighbor guess.
Property graphs and RDF-style triple stores differ in ecosystem and schema strictness, but both encode relational structure. The engineering artifact is the graph model plus identity rules: what counts as the same entity across sources.
Graphs complement documents. Documents explain; graphs constrain and connect. Most enterprise “KG” programs fail when they try to replace documents instead of linking them.
Ontology and schema design trade-offs
Ontologies define allowed types, relations, and constraints. Too rigid and ingestion stalls; too loose and queries become meaningless string soup. Start from decision questions: which joins must be reliable for products, compliance, or research?
Reuse standard vocabularies when they fit; extend carefully with versioned namespaces. Schema evolution needs migration plans—renaming a relation type breaks downstream queries quietly.
Not every column in a warehouse deserves a node. Model entities that participate in multiple relations and decisions. Leave ephemeral metrics in analytical stores.
Entity resolution and linking
Entity resolution decides when records refer to the same real-world object. Entity linking maps text mentions to graph IDs. Both are supervised-hard problems with precision/recall trade-offs: merging distinct people is catastrophic; failing to merge duplicates fragments reasoning.
Features include names, identifiers, addresses, embeddings of context, and graph neighborhood overlap. Human adjudication queues remain necessary for high-stakes merges. Record provenance on every asserted edge.
Linking quality gates any GraphRAG fantasy: if mentions resolve to the wrong node, generated answers cite the wrong world.
Querying versus embedding graphs
Graph query languages traverse typed paths with predicates and aggregations. They return exact answers under the stored facts—subject to completeness. Graph embeddings map nodes/edges into vectors for similarity, clustering, or ML features. Embeddings approximate structure; they do not replace integrity constraints.
| Approach | Strength | Failure mode |
|---|---|---|
| Graph query | Exact typed paths | Missing edges → empty answers |
| Graph embedding | Similarity / ML features | Approximate; hard to audit |
| Document vectors | Passage similarity | No relation constraints |
| Warehouse SQL | Tabular joins | Deep variable-length paths painful |
Choose query when correctness of relations matters. Choose embeddings when soft similarity over graph structure helps ranking or features. Many systems use both: query for hard constraints, vectors for candidates.
KG vs vector databases vs RAG vs GraphRAG
Knowledge graph: structured entities/relations with schema and identity; optimized for relational queries and constraint checks.
Vector database: stores embeddings for ANN similarity; optimized for “nearest neighbors under a metric,” with filters/tenancy. It does not know that AcquiredOn is a typed edge unless you encode that elsewhere.
RAG: retrieve text (often via vectors/lexical search), then generate an answer grounded in chunks; judged on faithfulness and task success. Owned in depth by the RAG guide.
GraphRAG (pattern): use graph structure to select, organize, or constrain context for generation—community summaries, neighborhood expansion, or entity-centric retrieval. It is a retrieval/organization pattern feeding generation, not a replacement for ontology discipline. Evaluate it with both graph correctness metrics and RAG faithfulness metrics; do not treat “we built a graph” as answer quality.
Hard rule: a vector index of chunk embeddings is not a knowledge graph. A chatbot over PDFs is not GraphRAG because someone drew circles on a whiteboard.
Graph machine learning basics
Graph ML includes node classification, link prediction, and graph classification, often with graph neural networks or classical relational features. At this altitude, know the tasks and data leaks: random splits that leak neighbors across train/test invalidate results; time-aware splits matter for evolving graphs.
Link prediction can suggest missing edges for curator review—not silent auto-writes into the system of record. Treat predicted edges as proposals with confidence and provenance.
Deep architectural detail belongs with deep learning when you implement GNNs; here, ownership is when graph-structured learning is the right problem versus tabular ML on flattened joins.
Using graphs inside RAG without hype
Productive patterns: resolve entities in the question; fetch neighborhood facts as structured context; expand to related documents linked from nodes; enforce constraints (“only cite policies in force on date D”). These reduce some retrieval misses and some contradictions.
Unproductive patterns: extracting noisy triples from every PDF into a giant unverified graph, then claiming reasoning; ignoring ACL on graph edges; skipping faithfulness eval because “the graph said so.” Graphs can be wrong, stale, or incomplete.
If generation is the primary UX, keep RAG ownership for answer metrics. This page owns whether the graph layer is modeled and governed well enough to participate.
Governance of changing enterprise graphs
Edges have lifetimes. Acquisitions reverse, titles change, suppliers churn. Version graphs or edge validity intervals. Who may assert, deprecate, or override an edge? Without write ACLs and review, wiki-chaos moves into graph form.
Lineage from source systems (CRM, ERP, HR) must be explicit. Prefer syncing authoritative identifiers over NLP extraction for core master data. Use extraction for enrichment candidates.
Privacy: graphs concentrate PII linkability. Minimize sensitive properties, encrypt where needed, and apply the same access rules as source systems—often stricter because joins reveal more.
Evaluation of graph completeness and correctness
Measure precision/recall of entity resolution on gold pairs. Spot-check edge correctness by type. Measure query task success: can analysts answer priority questions with graph queries alone? Track freshness lag from source systems.
Completeness is task-relative. A graph can be “complete” for org-chart routing and incomplete for supply-chain risk. Publish coverage statements per domain, not a single vanity node count.
For GraphRAG, add answer faithfulness and citation tests on questions that require multi-hop relations—and include negative tests where the graph should abstain.
When a relational warehouse is enough
If joins are shallow, schemas stable, and SQL users productive, a warehouse may beat a KG program on time-to-value. Graphs shine with variable-depth paths, heterogeneous entity types, and shared identity across many systems.
Do not start a KG to impress architecture review. Start from unanswered relational questions that SQL makes painful and that have clear owners for entity identity.
Hybrid is common: warehouse for metrics, KG for shared business entities, document search for evidence text, vectors for similarity—each with its contract.
Worked sketches
Vendor risk: companies, products, vulnerabilities as nodes; query paths for exposure; documents linked as evidence; RAG answers only over ACL-visible neighborhoods.
Research discovery: authors, papers, institutions; graph queries for collaboration paths; vectors for paper similarity; do not collapse into one store.
Customer 360 lite: resolve accounts across CRM/billing; graph for relationships; warehouse for spend metrics; forbid silent merge without adjudication.
Policy assistant: graph of policy versions and effective dates constrains RAG context; faithfulness still measured as RAG.
Operational checklist
Decision questions listed. Schema versioned. Identity rules documented. Provenance on edges. ACL model tested. Resolution gold set owned. Freshness SLOs set. Clear statement of what is KG vs VDB vs search vs RAG. Predicted edges never auto-commit without review.
Closing
Knowledge graphs provide typed relational memory with identity and governance. Vector databases provide similarity. RAG provides grounded generation. GraphRAG is a pattern that may combine them—not a synonym for any one. Model entities and relations deliberately; evaluate correctness and coverage; keep generation metrics where they belong.
Ingestion pipelines and extraction quality
Ingestion from databases is sync; ingestion from text is extraction. Extraction errors invent entities and relations. Prefer high-precision extractors with human review for critical edge types. Low-precision bulk extraction creates graphs that look large and answer wrongly with confidence.
Change data capture keeps graphs fresh when sources support it. Nightly full reloads hide deletes; soft-delete and tombstone policies must be defined so removed relationships do not linger as facts.
Idempotent upserts keyed by stable IDs prevent duplicate nodes when pipelines retry. Without stable IDs, every sync creates parallel universes.
Path queries, reasoning, and rules
Rules and inferencing (materialized or at query time) derive edges from patterns: transitive part-of, ownership rollups, conflicting status checks. Keep inferred edges labeled as inferred with rule IDs. Debugging “why is this true?” is otherwise impossible.
Heavy symbolic reasoning engines are optional. Many enterprises get value from constrained path queries plus a few validated rules. Do not equate “knowledge graph” with “automated theorem proving.”
Conflicts are data: two sources disagree on a CEO. Model conflict explicitly rather than last-write-wins without audit.
Access control on nodes and edges
Document ACL patterns do not automatically transfer. A user may see a company node but not a sensitive edge to a legal matter. Edge-level and property-level security are often required. Test with adversarial users after every schema addition.
Generated answers that traverse graphs must inherit the strictest ACL on used edges and source documents. Graph expansion that ignores ACL is a data leak with extra steps.
Admin break-glass access needs logging equal to source systems of record.
Anti-patterns
Calling a vector index a knowledge graph. Extracting all triples from PDFs without verification. Auto-merging entities on fuzzy name match. Skipping validity intervals. Measuring success by node count. Replacing search and warehouse with a graph because of a conference talk. Treating GraphRAG branding as faithfulness.
Team interfaces
Knowledge engineers own schema and identity. Data engineering owns sync pipelines. ML owns link prediction proposals. Search/RAG teams consume graph APIs with separate KPIs. Security owns ACL tests on graph traversals. Product owns which questions the graph must answer in year one.
Write a KG charter: entity types in scope, system-of-record sources, resolution policy, write permissions, and non-goals (what stays in warehouse/search).
Where knowledge graphs sit in the Knowledge graph
Parents: artificial intelligence; adjacency with RAG for grounded generation patterns. Sibling retrieval tech: AI search and vector databases. Embeddings may featurize nodes but do not define the graph. Future ai-entity-graph product pages should link here for modeling theory rather than duplicating ontology depth.
Machine learning methods that classify nodes still depend on machine learning discipline for splits and metrics; supervised edges proposals inherit label-noise lessons from supervised learning.
Storage engines and query performance
Graph engines optimize traversals; columnar warehouses optimize scans and aggregates. Benchmark the queries you actually run: hop depth, fan-out, and concurrent users. A beautiful schema that times out at three hops is not production-ready.
Indexing strategies on high-degree nodes (celebrities of the graph) need care—supernodes blow memory and latency. Model around them with constraints or sampled neighborhoods.
Caching path results can help and can serve stale security decisions—include ACL versions in cache keys.
Human curation workflows
Curation UI for merges, edge edits, and deprecations is part of the system. Crowdsourced edits need reputation and review. Expert curators need batch tools and clear guidelines, similar in spirit to search judgment programs but oriented to factual graph integrity.
Connect curation back to source tickets: when CRM is wrong, fix CRM, then sync—do not forever patch the graph as a shadow master.
Publish data quality scorecards per domain to leadership so graph investment is judged on decision enablement, not ontology elegance alone.
Multimodal and document-linked graphs
Nodes often point to documents, images, or audio evidence. Keep binaries in content stores; store links and hashes on the graph. Document intelligence pipelines can propose entities and relations; humans or high-precision rules promote them. That handoff should be explicit when document-intelligence publishes in this batch.
Multimodal embeddings can assist linking but remain similarity signals. Typed relations stay the graph’s job.
Temporal graphs and bi-temporal facts
Business facts have valid time (when true in the world) and transaction time (when recorded). Bi-temporal modeling prevents “as of” queries from lying after corrections. Without time, a KG becomes a blurry present that cannot support audits.
Event nodes (acquisitions, filings, releases) often beat mutable properties that overwrite history. Choose event modeling when history is the product.
Time-aware entity resolution matters: two records may match in 2019 and diverge after a split. Resolution rules should consider effective dates.
Identifiers, external refs, and sameAs discipline
Prefer public or enterprise identifiers (LEI, internal customer ID, SKU) as anchors. sameAs links across systems need directionality and confidence. Uncontrolled sameAs proliferation recreates the duplicate problem at meta level.
When only fuzzy attributes exist, keep candidate links in a staging graph until adjudicated. Production query APIs should not traverse unverified sameAs by default.
URI design and ID permanence are governance: recycling IDs is an integrity incident.
Observability for graph products
Monitor ingestion lag, failed syncs, resolution queue depth, query latency by pattern, and ACL denial rates. Alert on sudden jumps in node/edge counts that suggest pipeline duplication. Track empty-answer rates for priority query templates.
Diff snapshots between graph versions for surprise edge deletions or type changes. Treat schema registry compatibility like API compatibility.
User-facing products need “why this edge” inspectors showing provenance and validity windows—essential for trust when answers cite graph facts.
Cost control and scope discipline
KG programs balloon when every team dumps every entity type into one graph. Use domain-bounded graphs with explicit integration edges, or a thin shared identity layer plus domain subgraphs. Cost is curation hours and incident risk, not only graph DB licenses.
Start with a vertical slice: one decision, five entity types, two source systems, measurable query success. Expand only when the slice earns trust.
Deprecate unused types. Orphan nodes and zombie edges accumulate like dead code.
Comparison scenarios for architecture reviews
If the question is “find similar support articles,” you want search/vectors. If the question is “which vendors connect to this CVE through installed products,” you want a graph (plus document evidence). If the question is “explain this policy in prose with citations,” you want RAG over the right corpus, optionally constrained by graph-effective dates.
Architecture review anti-pattern: a single “intelligent knowledge layer” slide that merges KG, VDB, search, and RAG into one budget line with one KPI. Split KPIs or fail the review.
Document the non-goals in writing so future teams cannot silently widen scope into a second CRM.
Testing graph changes like software
Schema PRs need review checklists: backward compatibility, ACL impact, migration scripts, and sample query packs that must still return expected gold answers. Contract tests against priority SPARQL/Cypher/Gremlin templates catch silent breaks after relation renames.
Synthetic canaries—known entities with expected paths—run after every sync. If a canary path disappears, page the owning pipeline before users notice empty assistants.
Load tests should include high-fan-out neighborhoods and concurrent ACL-filtered traversals, not only tiny demo graphs used in slideware.