Knowledge Graphs for AI Interview Prep

KG Construction Approaches — Quality, Scale, and Production Fit

Sample interview questions

1. What is the fundamental difference between a property graph and an RDF graph, and when should you choose one over the other?
   • A. They are functionally identical; the choice depends entirely on which database vendor you prefer
   • B. Property graphs (Neo4j, KuzuDB) store typed nodes and edges with arbitrary key-value properties and use Cypher for queries — best when your domain is object-centric with rich attributes. RDF graphs use subject-predicate-object triples and SPARQL — best when you need formal ontologies, linked data standards, or cross-organization schema sharing ✓
   • C. RDF graphs are always superior because they are the W3C standard; property graphs are a legacy format
   • D. Property graphs cannot express relationships between more than two nodes; RDF can express any n-ary relationship

   Option B correctly distinguishes the two paradigms by their data model, query language, and ideal use case. Property graphs represent data as typed nodes (entities) and directed, typed edges (relationships), each of which can carry an arbitrary set of key-value properties. A customer node might have properties {name: "Alice", since: 2021}. A relationship between customer and product can have properties {quantity: 3, discount: 0.1}. Neo4j and KuzuDB are the canonical property-graph engines; Cypher is the query language. Property graphs excel when your domain naturally maps to "objects with rich attributes connected by typed relationships" — social networks, product catalogs, recommendation graphs, fraud detection. RDF (Resource Description Framework) represents data as triples: subject-predicate-object, where all three are typically IRIs (uniform resource identifiers). There are no properties on edges — only nodes. To attach a property to a relationship you must reify it (create a new node). SPARQL is the query language. RDF strengths: formal ontologies (OWL), linked open data (schema.org, Wikidata, DBpedia), cross-organization semantic interoperability. If you need to publish data in a format that any W3C-compliant system can consume, or you want to reason over class hierarchies, RDF is the right tool. Option A is wrong — the choice has significant technical implications. Option C overstates RDF; property graphs dominate production AI systems because of their expressive data model, schema flexibility, and mature tooling for LLM-extracted graphs. Option D is wrong; property graphs can express hyperedges through intermediate nodes. Production reality: for LLM applications today, property graphs are the default. RDF is alive in specific verticals (life sciences, biomedical, government data) but most agentic workflows use property graphs because schema-light design lets LLM extraction iterate without re-modeling the world.

2. A team wants to build a knowledge graph from a corpus of technical documentation. They propose three approaches: (1) extraction-based using spaCy and REBEL from HuggingFace, (2) schema-first manual curation, (3) LLM-prompted extraction without a fixed schema. What are the key trade-offs, and which approach do most production systems use?
   • A. LLM extraction without schema is always best because LLMs understand context better than rule-based systems
   • B. Extraction-based (spaCy/REBEL) is fastest but noisy and recall-limited. Schema-first manual curation has the highest precision but is expensive and does not scale. LLM extraction without schema is flexible but produces inconsistent entity types and relation names, making the graph hard to query. Most production systems use a hybrid: hand-curated schema defining the relation types that matter, LLM-extracted instances, and an optional verification step ✓
   • C. Manual curation is unnecessary if you have a large enough LLM
   • D. All three approaches produce equivalent results at scale

   Option B correctly describes the trade-off triangle and the production hybrid pattern. Extraction-based approaches (spaCy NER, REBEL open-information extraction from HuggingFace, Stanford OpenIE) are fast and cheap but have significant limitations. Recall is limited to what the model was trained to extract; entity types are fixed; relations are surface-level. These approaches work well for well-defined domains with lots of training data (biomedical named entities, geographic relationships) but struggle with novel technical concepts. Schema-first manual curation (define entity types and relation types, then have domain experts annotate) produces the cleanest graphs. Every edge is verified. Query patterns work predictably because the ontology is known in advance. But this does not scale: a corpus of 10,000 pages would require weeks of expert annotation. It is appropriate only for high-value, slow-moving knowledge domains such as taxonomies, controlled vocabularies, and prerequisite graphs. LLM extraction without schema is appealing but problematic. Without schema constraints, the LLM invents its own entity type names ("Engineer", "SoftwareEngineer", "Developer" for the same concept), creates inconsistent relation names, and produces graphs that are hard to traverse because equivalent concepts are not unified. The hybrid approach — hand-curated schema (the relation types you care about) + LLM-extracted instances + optional verification step — combines LLM recall with schema-enforced consistency. Microsoft GraphRAG, Graphiti, and LightRAG all follow this pattern. Post-extraction, entity resolution unifies aliases. Options A and D ignore important failure modes. Option C is too optimistic — LLMs hallucinate facts and relationships without validation, and every hallucination becomes a graph edge. Production reality: the verification step matters. A 10% per-triple error rate over a 100K-triple graph leaves 10K false edges — many between high-degree nodes that corrupt downstream traversal.

3. When does GraphRAG outperform standard vector-similarity RAG, and when is the graph overhead not justified?
   • A. GraphRAG is always superior because it considers structural relationships in the knowledge base
   • B. GraphRAG outperforms standard RAG on multi-hop reasoning questions (where the answer requires connecting facts across multiple related entities), cross-document relationship aggregation, and global thematic summarization. Standard RAG is sufficient and cheaper for single-hop factual lookups, keyword retrieval, and domains with no meaningful entity-entity relationships ✓
   • C. Standard RAG always wins on latency so should always be used in production
   • D. GraphRAG is only for graph databases like Neo4j; it cannot be combined with vector databases

   Option B captures the core discriminator: multi-hop reasoning, relational aggregation, and global summarization. Flat chunk-based RAG handles "find me a passage about X" well. It loses on a different class of queries: "Which engineers worked on the auth system AND shipped to production last quarter?" — requires intersecting two traversal paths. "What are the prerequisites I need before understanding backpropagation?" — requires traversing a prerequisite graph. "Summarize how Company X relates to its three largest suppliers and the regulatory bodies that touch any of them." — requires cross-document relational synthesis. None of these can be answered reliably by vector similarity; all require graph traversal. GraphRAG also wins on community-level global summarization. Microsoft GraphRAG runs community-detection (Leiden algorithm) to cluster nodes into thematic communities, generates LLM summaries per community, then summaries-of-summaries. Queries traverse this hierarchy — high-level questions hit top summaries; specific questions drill into communities. This is the "global summarization" pattern that outperforms flat RAG on questions like "summarize the major themes in this corpus." Standard RAG wins when: questions are single-hop semantic lookups, latency is paramount (a Cypher traversal adds 50–200ms versus a single vector lookup), or the domain has no meaningful entity relationships. The escalation triggers for moving from RAG to GraphRAG are: (1) single-pass RAG hits a measured quality ceiling on multi-hop questions, (2) multi-hop queries become a measurable fraction of traffic (10%+), (3) cross-document summarization is a use case. Option A ignores cost and latency. Option C ignores multi-hop cases. Option D is wrong — GraphRAG is layered on any vector DB using a graph stored in Neo4j or KuzuDB alongside it. Production reality: most production setups are hybrid — vector search for entry-point nodes, graph traversal to expand. Don't force every query through the graph.

4. A production knowledge graph for a financial services application has been running for 18 months. The team notices the graph is returning stale or incorrect relationships. What is the most likely root cause and the correct fix?
   • A. Graphs are static by nature and cannot handle dynamic data; replace the graph with a vector database
   • B. The most likely cause is absence of a temporal layer: edges were built without validity timestamps, so outdated relationships (e.g., "Alice is CEO of CompanyX" from 2023 when she left in 2024) persist. Fix by adding valid_from and valid_until properties to edges, implementing incremental re-extraction pipelines on new documents, and tracking extracted_at per edge so you know which edges need refresh when source documents change ✓
   • C. The team should rebuild the graph from scratch every 6 months using batch re-extraction
   • D. Staleness only occurs in RDF graphs; property graphs automatically update relationships

   Option B identifies the root cause: lack of temporal metadata and the absence of incremental update pipelines. Knowledge graphs built from static document snapshots are accurate at extraction time but decay as the real world changes. Financial relationships change constantly: executives move, companies merge, partnerships dissolve, regulations change. A graph built in 2023 from SEC filings will be incorrect by 2024 if not updated. The temporal KG solution has two components: 1. Edge-level timestamps: every edge carries valid_from and valid_until properties. A Cypher query can filter by date: MATCH (a)-[r:WORKS_FOR]->(b) WHERE r.valid_until > date() RETURN a, b. This gives a time-slice view — what relationships were true at a given date. 2. Incremental update pipelines: new documents are continuously processed through the extraction pipeline. New relationships are upserted; relationships contradicted by new evidence get their valid_until set. Store extracted_at on every edge so you know which edges to re-extract when source documents change. Graphiti (from Zep AI) is designed specifically for this pattern — it maintains entity state timelines and supports temporal queries out of the box. Option A is wrong — graphs handle dynamic data when properly designed with temporal metadata. Option C (batch rebuild) wastes computation, creates availability windows where the graph is incomplete, and drifts the graph faster than it refreshes it. Option D is false — temporal decay affects both property graphs and RDF graphs equally. Production reality: for AI-driven systems where the underlying domain changes, temporal KGs are essential. Financial data, medical records, regulatory requirements, and organizational hierarchies all require temporal tracking to avoid feeding stale context to the LLM.

5. What is community detection in a knowledge graph, and how does Microsoft GraphRAG use it for global summarization?
   • A. Community detection removes low-quality nodes from the graph to improve query performance
   • B. Community detection algorithms (Louvain, Leiden) partition graph nodes into densely connected clusters representing thematically related entity groups. GraphRAG uses community-level LLM summaries for global questions ("What are the main themes in this corpus?") by summarizing each community independently, then combining summaries hierarchically. This produces better global answers than naive embedding search, which retrieves isolated text chunks without thematic structure ✓
   • C. Community detection is only useful for social networks, not for AI knowledge graphs
   • D. Community detection requires labeled training data and is a supervised learning technique

   Option B accurately describes community detection and its role in GraphRAG's hierarchical summarization architecture. Louvain and Leiden are unsupervised graph partitioning algorithms that maximize modularity — the degree to which nodes within a community are more densely connected to each other than to the rest of the graph. Applied to a knowledge graph, this groups entities that frequently co-occur or are related into thematic clusters. In a corpus about AI research, communities might emerge for "LLM architectures", "training methods", "agent frameworks", and "evaluation techniques." Microsoft GraphRAG (Edge et al. 2024, arXiv:2404.16130) uses community summaries in two ways: 1. Global queries: for questions like "What are the main topics covered in this document set?", GraphRAG summarizes each community (using an LLM with the community's entities and relationships as context), then generates a final summary from the community-level summaries — summaries-of-summaries up the hierarchy. This gives a coherent thematic overview that pure embedding search cannot match. Embedding search retrieves the most similar chunks but misses thematic structure. 2. Local queries: for questions about specific entities, GraphRAG searches within the relevant community first, then expands to neighboring communities if needed. The community detection step runs once after KG construction (computationally O(E log V) for Louvain) and produces a hierarchy of community resolutions. When documents change, downstream community summaries become stale until rebuilt — this is a known maintenance cost to track. Option A confuses community detection with pruning. Option C is wrong — community detection is domain-agnostic and is used in knowledge work, scientific literature, and code-dependency graphs. Option D is wrong — Louvain and Leiden are unsupervised. Production reality: skipping community detection is one of the most common GraphRAG deployment mistakes. Global summarization quality degrades significantly without community structure.

6. A team builds a knowledge graph from 10,000 customer support tickets and queries it with: "Which product features are most often mentioned alongside refund requests?" Standard vector RAG fails on this question. Why does the graph succeed, and what is the Cypher query pattern?
   • A. The graph fails too — no retrieval system can answer relationship-based aggregation questions
   • B. The graph succeeds because the query requires co-occurrence counting across entity relationships, not text similarity. The graph stores edges between Feature entities and Ticket entities and between Ticket entities and RefundRequest intent nodes. A Cypher query counts co-occurrences: MATCH (f:Feature)-[:MENTIONED_IN]->(t:Ticket)-[:HAS_INTENT]->(r:RefundRequest) RETURN f.name, count(t) ORDER BY count(t) DESC. Vector RAG retrieves chunks similar to the query text but cannot count structured relationships across documents ✓
   • C. Vector RAG can answer this equally well by using keyword frequency in retrieved chunks
   • D. This is an aggregation problem that should use SQL, not a knowledge graph

   Option B correctly identifies why structured graph traversal outperforms vector similarity for relational aggregation queries. Vector RAG operates by embedding the query and finding the most similar text chunks. The retrieved chunks might include individual tickets that mention features and refunds, but the system cannot aggregate across the entire corpus to compute co-occurrence counts. Each retrieved chunk is independent — vector similarity does not support cross-document joins or counting relationships. The knowledge graph solution: 1. During construction, each ticket is processed to extract entities: Feature mentions ("dark mode", "export to PDF", "search function") and intent labels ("refund request", "billing inquiry", "feature request"). 2. Relationships are created: TICKET -[:MENTIONED_FEATURE]-> FEATURE, TICKET -[:HAS_INTENT]-> INTENT. 3. The query becomes a graph traversal: find all tickets with intent "refund_request", aggregate the features they mention, and count occurrences. This is an O(edges) operation with index support on the INTENT node type — fast and exact. The result is a ranked list of product features co-occurring with refund requests. Option A is wrong — graph-structured retrieval handles this natively. Option C is wrong — vector similarity finds semantically similar text but cannot count structured co-occurrences across thousands of documents. Option D misses the point: SQL can answer this if you have a structured database, but the raw data is unstructured text. The KG provides the structured layer on top of unstructured text that SQL cannot. Production reality: this "cross-document aggregation" pattern is one of the clearest signals that a knowledge graph is warranted. If users regularly ask "how often does X co-occur with Y across the corpus?", graph traversal is the right tool.

7. A production knowledge graph has 500,000 nodes. Most queries return empty results even though the team is confident the underlying documents contain the relevant facts. What is the most likely root cause?
   • A. The graph database is too small to handle 500,000 nodes; upgrade to a larger instance
   • B. Entity-resolution failure: the same real-world entity exists under multiple slightly different surface forms ("Linus Torvalds", "Linus B. Torvalds", "L. Torvalds") as three separate nodes. Queries that use one name miss relationships connected under the others, fragmenting recall. Fix: run a deduplication pass using embedding similarity on entity names plus a canonical-name dictionary; merge nodes above a similarity threshold; queries against the cleaned graph will recover missing connections ✓
   • C. The vector index is missing; add one and queries will succeed
   • D. The Cypher query syntax is incorrect; use SPARQL instead

   Option B identifies entity-resolution failure as the most common root cause of high-node-count graphs with low query recall. When an LLM extracts "Linus Torvalds" from one document and "Linus B. Torvalds" from another, these land as two separate nodes unless entity resolution merges them. In a 500,000-node graph built from diverse sources, an entity might appear under dozens of surface forms: short names, full names, role-qualified names, abbreviations. Queries for any single form miss all the relationships stored under the others. Two resolution strategies exist in production: 1. Aggressive merging (Microsoft GraphRAG style): during a community-detection phase, embed entity names and descriptions; cluster entities with high cosine similarity; merge clusters above a threshold into a single canonical node. Risks over-merging different entities with similar names. 2. Conservative accumulation (Graphiti style): keep all surface forms as separate nodes but use vector-similarity entry-point lookup at query time — the hybrid query (vector finds seed nodes, graph traverses from them) catches all variants automatically. Risks missing relationships if traversal does not start from the right variant. Production KG schemas should version the entity-resolution dictionary alongside the graph. Without it, duplicate entities silently fragment recall and the debugging trail is expensive. Option A is wrong — node count is not the issue; resolution is. Option C is a valid separate concern (missing vector index is Pitfall 7 from the production checklist) but does not explain why a query that uses exact node labels would return empty. Option D is wrong — switching query languages does not fix entity fragmentation. Production reality: keep an entity-resolution dictionary versioned alongside the KG. Without it, duplicate entities silently fragment recall.

8. A knowledge graph has a "cited_by" edge type connecting every document to every other document it cites. After six months the graph has 50 million edges of this type and graph traversals time out. What is the underlying problem and the correct architectural fix?
   • A. The graph database needs to be replaced with a relational database for citation data
   • B. This is cardinality explosion: a high-fanout relation type with millions of edges overwhelms graph traversals. Fix by filtering traversals by relation type and recency (limit to the last 12 months of citations), using confidence-thresholded entity extraction to limit low-signal edges, or using the Neo4j Graph Data Science library for explicit pruning and PageRank-based importance weighting before including edges in traversals ✓
   • C. The schema needs to switch from property graph to RDF to handle high-cardinality relations
   • D. Increase the graph database server memory to handle 50 million edges

   Option B correctly identifies cardinality explosion and the appropriate mitigations. Cardinality explosion occurs when a relation type has millions of instances connecting high-degree nodes. A "cited_by" edge between academic papers is a common offender — a highly-cited paper might have 100,000 incoming citation edges. When a traversal starts from that paper and expands to its neighbors, it fans out to 100,000 nodes in a single hop, and each of those fans out further. The graph traversal becomes an exponential search that times out at any reasonable depth. Three mitigations: 1. Filter by relation type and recency at traversal time: MATCH (a)-[r:CITED_BY]->(b) WHERE r.year >= 2023 RETURN b LIMIT 50. Restrict traversal to recent, high-confidence edges only. 2. Confidence-thresholded extraction: during LLM extraction, assign confidence scores to extracted triples. Only insert triples above a confidence threshold into the main graph; route low-confidence ones to a human review queue. This limits the edge volume at construction time. 3. Pre-compute importance: run PageRank or betweenness centrality on the high-cardinality subgraph using Neo4j Graph Data Science. Store scores as node properties. At query time, expand only to nodes with PageRank above a threshold — this selects the most structurally important neighbors rather than all neighbors. Option A is wrong — relational databases handle citations but lose the graph traversal capability. Option C is wrong — switching to RDF does not reduce edge cardinality; both graph models suffer from high-fanout relations. Option D treats a structural problem as a hardware problem. Production reality: cardinality explosion makes graphs unqueryable within months of launch if not anticipated. Limit cardinality with confidence-thresholded extraction and explicit pruning strategies.

9. A learning system uses a hand-curated prerequisite graph to determine which concepts a learner should study before advancing to a new topic. Why is this a better fit for a hand-curated graph than LLM-extracted graph, and what query does prerequisite traversal look like?
   • A. LLM-extracted graphs are always more accurate than hand-curated graphs for learning systems
   • B. Prerequisite graphs are small (hundreds of concept nodes), authoritative, change slowly, and require exact correctness — a wrong prerequisite edge sends learners down incorrect study paths. Hand-curation is appropriate when the schema is small and authoritative. The traversal is a reachability query: MATCH path = (target:Concept {name: "backpropagation"})<-[:REQUIRES_PREREQUISITE*]-(prereq:Concept) RETURN prereq.name, length(path) AS depth ORDER BY depth ✓
   • C. LLM extraction should be used because it scales better than hand-curation for large concept libraries
   • D. Prerequisite reasoning requires a relational database, not a graph, because prerequisites are a strict ordering

   Option B correctly identifies why hand-curated graphs are appropriate for authoritative, small-schema, slow-changing domains like prerequisite structures. The three construction approaches each have a sweet spot: - Hand-curated: small schema (under ~500 nodes), authoritative, changes slowly. Prerequisite graphs, controlled vocabularies, taxonomies. - Classical NLP extraction: entities have clear surface forms and relations are well-defined. Biomedical, scientific. - LLM extraction: relations are fuzzy, corpus is large, hand-curation is not viable. Enterprise document corpora. A prerequisite graph for a learning system typically has hundreds of concept nodes and a few thousand prerequisite edges. This is small enough to curate by hand, and hand-curation is justified because: (1) a wrong edge sends learners down incorrect study paths, harming the learning outcome; (2) the schema changes only when the curriculum changes; (3) LLM-extracted prerequisites often confuse conceptual dependency with topical similarity. A production prerequisite graph (e.g., 167 concept nodes, 279 prereq edges with track filters) is hand-curated in YAML, giving domain experts full control over the edge semantics. The traversal query finds all prerequisite concepts at varying depths using a variable-length path pattern. This enables "what must I know before X?" and "what are the weak points blocking progress toward Y?" — queries that flat RAG cannot answer. Option A is wrong — for small authoritative schemas, hand-curation dominates on quality. Option C is wrong — scale is not the issue when the schema is small. Option D is wrong — prerequisites are a directed acyclic graph (DAG), which graph databases model natively; a relational DB requires recursive CTEs for the same traversal. Production reality: for learning systems, code-dependency tracking, and regulatory compliance, prerequisite/dependency reasoning is the use case that most clearly justifies building a knowledge graph.

10. What provenance metadata should production knowledge graph edges store, and why does it matter for graph quality over time?
    • A. Provenance metadata is optional; it adds storage overhead without practical benefit
    • B. Each edge should record at minimum: source_doc_id (which document the edge was extracted from), extracted_at (when extraction ran), confidence (extraction confidence score), and optionally extraction_run_id (which pipeline version produced it). Provenance enables two critical operations: audit (when a downstream query produces a wrong answer, trace it to the source edge and the document that caused it) and incremental updates (when a source document changes, you know exactly which edges to re-extract rather than rebuilding the whole graph) ✓
    • C. Provenance only matters for RDF graphs; property graphs track provenance automatically
    • D. Storing provenance on every edge is too expensive; only store it on edges with low confidence scores

    Option B correctly describes the minimum provenance metadata and the two operational reasons it is required. Every LLM hallucination becomes a graph edge. Without provenance, when a downstream query produces a wrong answer you cannot trace it back to its source — you have to inspect the entire graph. With source_doc_id and extracted_at on every edge, the debugging trail is: wrong answer → wrong edge → source document → incorrect passage → fix. The two operational uses: 1. Audit: when a query produces an incorrect result (especially in compliance-sensitive or financial domains), you need to answer "where did this fact come from?" The edge's source_doc_id and extracted_at give you the document and extraction timestamp. Cross-referencing with the document content tells you whether the extraction was correct or a hallucination. 2. Incremental updates: rather than rebuilding the entire graph when new documents arrive, you can identify which existing edges came from the updated document (via source_doc_id) and re-extract only those edges. Graphiti and Microsoft GraphRAG both treat source provenance as a first-class edge property for this reason. A production schema typically treats source_doc_id and extracted_at as required edge properties, not optional ones. For audit-sensitive domains (financial, medical, legal), cross-KG provenance — tracing which edges were derived from other edges or community summaries — is also important. Option A understates the operational value. Option C is false — property graphs do not track provenance automatically; the developer must add it explicitly. Option D is wrong — provenance is needed for high-confidence edges too, especially when those edges drive consequential downstream decisions. Production reality: store the source for every edge. Without it, a KG is a debugging nightmare when incorrect edges corrupt downstream reasoning.

Frequently asked questions

What is the difference between a property graph and an RDF graph?

Property graphs (used by Neo4j, KuzuDB, ArangoDB, Memgraph) store nodes and edges with arbitrary key-value properties. They use Cypher or Gremlin for queries. RDF graphs store data as subject-predicate-object triples without properties on edges, using SPARQL for queries. Property graphs are the default choice for AI applications because their schema-light design lets LLM extraction iterate without re-modeling the world. RDF excels when you need formal ontologies (OWL), linked data interoperability, or W3C-standard schema sharing across organizations — common in life sciences, biomedical, and government data.

What are the three main approaches to building an AI knowledge graph, and which do production systems use?

The three approaches are: (1) Hand-curated — domain experts author nodes and edges directly. Highest quality, lowest scale. Used for small authoritative schemas (under ~500 nodes) that change slowly: prerequisite graphs, controlled vocabularies, taxonomies. (2) Classical NLP extraction — spaCy-style NER and REBEL for open-information extraction. Reproducible and deterministic, but constrained to what the extractor was trained on. Best for well-defined domains like biomedical literature. (3) LLM-extracted — prompt an LLM to identify entities and relations from documents. Higher recall, more flexible, but every hallucination becomes a graph edge. Production systems almost always use a hybrid: hand-curated schema defining the relation types that matter, LLM-extracted instances, and a verification step that routes low-confidence triples to human review.

What is GraphRAG and how does it differ from standard RAG?

GraphRAG (popularized by Microsoft's 2024 research, arXiv:2404.16130) combines knowledge graph traversal with LLM generation. Standard RAG embeds the query, finds similar text chunks via vector search, and feeds them to the LLM. GraphRAG additionally stores entities and their relationships in a graph, enabling multi-hop queries ("What companies does Alice's company compete with that also supply Component X?"), community-level summarization using Leiden or Louvain algorithms, and relationship-aware retrieval that embedding search cannot match. GraphRAG outperforms standard RAG on questions requiring structural reasoning; standard RAG is cheaper and sufficient for single-hop factual lookups. The escalation triggers for adopting GraphRAG are: single-pass RAG hits a quality ceiling on multi-hop questions, multi-hop queries become 10%+ of traffic, or cross-document summarization is a use case.

What is Cypher and how does it compare to SPARQL?

Cypher is the graph query language for Neo4j and KuzuDB (openCypher is the open standard). It uses a pattern syntax that reads like ASCII art: MATCH (a:Person)-[:WORKS_FOR]->(b:Company) WHERE b.name = "Acme" RETURN a. It is designed for property graphs and expressive relationship traversal. GQL is the ISO-standard graph query language for property graphs ratified in 2024; adoption across databases is still developing. SPARQL is the W3C standard for querying RDF triples. Choose Cypher for property graphs and AI applications; choose SPARQL when you need W3C-standard linked-data interoperability.

What is community detection in a knowledge graph?

Community detection algorithms (Louvain, Leiden) partition graph nodes into densely connected clusters representing thematically related entity groups. In a knowledge graph built from a document corpus, communities emerge for related topics — for example, "LLM architectures", "training techniques", and "agent patterns". Microsoft GraphRAG uses community-level summaries for global queries: it generates LLM summaries of each community, then combines summaries hierarchically ("summaries of summaries") to answer broad thematic questions that naive embedding search cannot answer coherently. Skipping community detection is one of the most common GraphRAG deployment mistakes — global summarization quality degrades significantly without community structure.

When should you use a knowledge graph instead of a vector database?

Use a knowledge graph when your queries require: (1) multi-hop reasoning — connecting information across multiple related entities, (2) cross-document relationship aggregation (counting co-occurrences, finding shared connections), (3) global thematic summarization across entity clusters, (4) prerequisite or dependency reasoning ("what must I know/build/install before Y?"), or (5) explicit provenance — knowing exactly which entities and edges contributed to an answer. Use a vector database when queries are single-hop semantic lookups, latency is paramount, or the domain has no meaningful entity relationships. Many production systems use both: a vector database for fast single-hop retrieval and a knowledge graph for complex relational queries. A useful heuristic: if your queries are "fetch me information about X," flat RAG suffices; if they are "explain how X relates to Y" or "what must I know before Z," build the graph.

How do you handle temporal knowledge graphs?

Temporal knowledge graphs add time-validity metadata to edges: valid_from and valid_until timestamps. This allows time-slice queries: "What was Alice's role in January 2023?" Graphiti (from Zep AI) is an open-source library specifically designed for episodic memory and temporal KGs — it maintains entity state timelines and supports time-aware retrieval. For production AI systems where facts change over time (financial relationships, org charts, regulatory requirements, product catalogs), temporal KGs are essential to prevent stale context from being fed to the LLM. Store extracted_at on every edge so you know which edges to re-extract when source documents change.

What is entity resolution and why does it matter for KG quality?

Entity resolution is deciding when two entity mentions refer to the same real-world entity — "Linus Torvalds" and "Linus B. Torvalds" are the same person. Without entity resolution, the same real-world entity appears as multiple distinct graph nodes under different surface forms, fragmenting recall: queries for one name miss all relationships stored under other names. Two strategies: aggressive merging (Microsoft GraphRAG style) embeds entity names and merges nodes above a similarity threshold during construction; conservative accumulation (Graphiti style) keeps surface forms separate and relies on vector-entry-point hybrid retrieval to catch all variants at query time. Production KG schemas should version the entity-resolution dictionary alongside the KG. Without it, duplicate entities silently fragment recall and debugging is expensive.

What are the most common pitfalls in production knowledge graph deployments?

Ten key pitfalls from production experience: (1) Building a KG when flat RAG would do — enumerate multi-hop queries first; if you cannot name three, you probably do not need the graph. (2) Over-engineered ontology — six months designing the schema, zero downstream queries. Start with the smallest schema that answers your top queries. (3) Extraction errors compound — a 10% error rate on 100K triples leaves 10K corrupt edges; verify every extracted triple before insertion. (4) Stale graphs — track extracted_at per edge; rebuild community summaries on edge changes. (5) Entity-resolution failures — same entity under multiple names fragments recall. (6) Cardinality explosion — high-fanout relation types with millions of edges time out traversals; filter by recency and confidence. (7) Forgetting the vector index — pure graph search misses paraphrase queries; vector-index every node label. (8) Schema rigidity — let property graphs be schema-light; add new edge types as data demands. (9) Cost-blind LLM extraction — tier the cost (cheap model first, expensive model for verification); cache per document version. (10) Building a graph that no agent uses — define agent-side query patterns first; build the graph in service of those patterns.

What OSS tools exist for building knowledge graphs for AI?

Graph databases: Neo4j (most mature, property graph, Cypher), KuzuDB (embedded, columnar, Cypher-compatible — verify project status before production use), ArangoDB (multi-model, Apache 2.0), Memgraph (in-memory, real-time), FalkorDB (Redis-based, vector index support). GraphRAG frameworks: Microsoft GraphRAG (LLM-extracted entities + community summaries, the canonical reference), Graphiti (temporal episodic memory, Zep), LightRAG (lightweight dual-level retrieval), LlamaIndex KnowledgeGraphIndex (integrates with LlamaIndex pipelines), KAG (Knowledge-Augmented Generation, 2024), Cognee (semantic memory for agents). Hybrid vector + graph: pgvector + Apache AGE (both Postgres extensions), Neo4j 5+ vector index (single-engine hybrid), Weaviate (cross-references), FalkorDB. Domain extractors: REBEL (Hugging Face, relation extraction), scispaCy (biomedical NER), OpenIE (Stanford). Graph algorithms: NetworkX (prototype), igraph (medium-scale), Neo4j Graph Data Science (production). GNN libraries: PyTorch Geometric (PyG), Deep Graph Library (DGL).

Related topics