TL;DR: A vector database finds text that means something similar to your question. A knowledge graph knows which tenant, policy, or part a fact belongs to and how those things connect. A semantic layer guarantees that "occupancy," "loss ratio," or "on-time delivery" is calculated the same way every time. The warehouse or lakehouse stores the governed tables all three read from. Enterprise AI agents working on operational data need all four, wired together with shared entity IDs, and the knowledge graph is the piece most teams skip and then regret.

An asset manager types a question into the firm's new AI assistant: "Which tenants at the Riverside portfolio have leases expiring in 2027, a co-tenancy clause tied to the grocery anchor, and an open CAM reconciliation dispute?" The assistant returns four paragraphs from three lease PDFs, two of them from a property the firm sold last year. It sounds confident. It is wrong. Nothing in the pipeline knew that "Riverside" is a portfolio of six assets in Yardi, that the anchor is a specific tenant record, or that a CAM dispute lives in a ticket system and not in the lease.

That failure is not a model problem. It is a retrieval architecture problem, and it is the reason "knowledge graph vs vector database" has become one of the most searched comparisons in enterprise AI, alongside "GraphRAG vs RAG" and "semantic layer for AI agents." This post is for CTOs, heads of data, data engineers, architects and technical founders who have to decide what goes underneath their agents. We cover what each layer does, how RAG, GraphRAG and hybrid retrieval work mechanically, where ontologies fit, how to decide what you need, and a reference architecture for a unified data layer grounded in operator data: leases, claims and work orders.

If you want the business case for knowledge graphs first, read our earlier piece on why knowledge graphs matter for enterprise AI. For the broader concept of a context layer, see what an AI context layer is. This post is the engineering comparison that sits between them.

Key takeaways

• Structure changes accuracy more than model choice. In a benchmark by Sequeda, Allemang and Jacob, GPT-4 answered enterprise questions over a raw SQL schema with 16% accuracy, rising to 54% when the same data was exposed as a knowledge graph with an ontology.

• GraphRAG wins on "big picture" questions, not every question. Microsoft Research's GraphRAG paper reports 72% to 83% comprehensiveness win rates over vector RAG on global sensemaking questions across a podcast corpus of roughly one million tokens.

• Graph indexing cost is a real objection, and it is shrinking. Microsoft says LazyGraphRAG's indexing cost is identical to vector RAG and 0.1% of full GraphRAG's.

• Plain vector search leaves accuracy on the table. Anthropic reported that contextual embeddings plus contextual BM25 cut top-20 retrieval failures by 49%, and by 67% with reranking.

• Semantic layers make numeric answers deterministic. In dbt Labs' April 2026 benchmark on a 15-table insurance schema, GPT-5.3 Codex went from 84.1% with text-to-SQL to 100% through the semantic layer.

• Gartner expects tool access without semantics to fail. Its 2026 Market Guide for Agentic Analytics predicts that by 2028, 60% of agentic analytics projects relying solely on MCP will fail for lack of a consistent semantic layer.

• Data readiness, not model capability, is the blocker. Gartner predicts organizations will abandon 60% of AI projects unsupported by AI-ready data through 2026.

Knowledge graph vs vector database vs semantic layer: what does each one do?

Each layer answers a different kind of question. A vector database answers "what text is about this?", a knowledge graph answers "what is connected to this specific thing, and how?", a semantic layer answers "what is the governed number for this metric?", and the warehouse or lakehouse answers "what are the facts, at what grain, as of when?" Confusion comes from vendors stretching each one to cover the others.

Vector database: similarity over unstructured text

A vector store holds embeddings: numeric representations of chunks of text (or images) produced by an embedding model. At query time the question is embedded too, and the store returns the nearest chunks by cosine or dot-product distance, usually through an approximate nearest neighbor index such as HNSW or IVF. Pinecone, Weaviate, Qdrant and Milvus are dedicated vector databases. pgvector adds the same capability to Postgres, and Neo4j, Elasticsearch, OpenSearch, Snowflake and Databricks all ship vector indexes now.

What it does well: finding the indemnity clause in 4,000 leases when nobody remembers the exact wording, or pulling the three adjuster notes that describe water intrusion. What it cannot do: tell you whether two chunks refer to the same tenant, count anything, follow a chain of relationships, or respect the fact that a lease was amended twice. Similarity is not identity.

Knowledge graph: entities, relationships and identity

A knowledge graph stores things (nodes) and how they relate (edges), each with properties. Tenant, lease, suite, property, guarantor. Claim, policy, claimant, provider, adjuster. Part, supplier, purchase order, work order, machine. The defining feature is not the graph database. It is resolved identity: one node for "Acme Holdings LLC" even though Yardi, the lease PDF, the guarantor letter and the collections system all spell it differently.

With identity resolved, multi-hop questions become traversals. "Which open work orders depend on parts from suppliers whose last three receipts were late?" is three hops in Cypher, and it returns a list you can audit, not a paragraph you have to trust.

Semantic layer: governed metric definitions

A semantic layer (dbt Semantic Layer with MetricFlow, Cube, AtScale, LookML, Snowflake semantic views, Databricks metric views) defines metrics, dimensions and joins once, in code, and compiles queries against the warehouse. "Net effective rent," "incurred loss ratio," and "first-pass yield" each get one definition with its filters, time grain and join path. When an agent asks for a number, it calls the semantic layer instead of writing SQL from scratch, so it cannot quietly pick the wrong join or forget to exclude voided transactions.

Warehouse or lakehouse: the system of record for analytics

Snowflake, BigQuery, Databricks, Redshift or an Iceberg lakehouse hold the cleaned, historized tables everything else reads from. This layer is not optional and it is not an AI component, but it is where time lives: effective dates, slowly changing dimensions, snapshots. Agents that skip it end up answering with whatever an API returned this morning.

The one-line rule we use: vectors find, graphs connect, semantic layers count, warehouses remember.

RAG vs GraphRAG vs hybrid RAG: how does each retrieval pattern work?

Standard RAG retrieves text chunks by similarity and stuffs them into the prompt. GraphRAG retrieves entities and relationships (and sometimes pre-written summaries of graph communities) so the model sees connected context. Hybrid RAG combines keyword search, vector search, graph traversal and structured queries, then fuses or routes between them. For operational data, hybrid is the realistic end state.

How standard (vector) RAG works

1. Parse and chunk. Documents are split into chunks, typically a few hundred tokens with overlap, ideally along structure (lease sections, policy forms and endorsements, SOP steps) rather than fixed character counts.

2. Embed and index. Each chunk is embedded and stored with metadata (source, date, property ID).

3. Retrieve. The query is embedded and the top-k nearest chunks come back, often filtered by metadata.

4. Generate. The LLM answers using the retrieved chunks as context.

The most common improvement is lexical plus semantic search: BM25 catches exact strings like a policy number, a part number or "Section 14.2," and embeddings catch paraphrase. Results are merged with reciprocal rank fusion and reranked with a cross-encoder. Anthropic's Contextual Retrieval write-up quantified this: prepending chunk-specific context before embedding cut the top-20 retrieval failure rate by 35%, adding contextual BM25 took it to 49%, and reranking took it to 67%. If your current RAG system is pure vectors with fixed-size chunks, fix that before buying anything new.

How GraphRAG works

"GraphRAG" now names two different patterns, and conflating them causes most of the "is GraphRAG worth it" arguments.

Pattern one: LLM-extracted graph from text (Microsoft GraphRAG). An LLM reads every chunk and extracts entities and relationships. The graph is clustered with the Leiden algorithm into hierarchical communities, and the LLM writes a summary of each community. Global questions ("what are the recurring themes in our denial letters this year?") are answered by map-reducing over community summaries. Local questions start from matched entities and expand to neighbors. In Microsoft Research's paper, this beat vector RAG on comprehensiveness (72% to 83% win rates on podcast transcripts) and diversity of answers for global questions. The cost is indexing: every chunk passes through an LLM at least once. Microsoft's LazyGraphRAG defers that work to query time and reports indexing costs equal to vector RAG and 0.1% of full GraphRAG.

Pattern two: retrieval over a graph you built from structured systems. The graph already exists because you loaded tenants, leases and properties from Yardi or MRI, claims and policies from Guidewire or Duck Creek, parts and work orders from Epicor or SAP. Retrieval uses vector or keyword search to find an entry point (a node or a chunk linked to a node), then traverses with Cypher, SPARQL or GQL to collect the connected facts, then passes both the facts and the linked text to the model. Neo4j's GraphRAG tooling, LlamaIndex property graph indexes and similar libraries support this pattern.

Here is our arguable position: for operator data, pattern two should come first, and pattern one is usually the wrong first graph. Your most important entities and relationships already exist in systems of record with IDs and foreign keys. Asking an LLM to rediscover them from PDFs gives you a probabilistic copy of facts you already own deterministically, with duplicate nodes for every spelling variant. Use LLM extraction to add what the systems do not hold (clauses, obligations, causes of loss, defect descriptions) and attach it to nodes that came from the systems.

Skeptics have a point, too. An MLOps Community analysis comparing Neo4j-based GraphRAG with a FAISS vector baseline found a large faithfulness gain (0.54 vs 0.18 on RAGAS) but no meaningful difference on context relevancy, answer relevancy or recall, and questioned whether the setup cost was justified. That test used a single debate transcript, a corpus with few real entities. Graphs earn their keep where entities and relationships are dense, which describes operational data, not a transcript.

How hybrid RAG works

Hybrid RAG means more than BM25 plus vectors. In an enterprise agent stack it usually means a router that decides, per question or per sub-question, which retrieval path to use:

• Metric questions ("What was Q3 loss ratio for the dental book?") go to the semantic layer.

• Relationship questions ("Which claims share a treating provider and an attorney with this one?") go to the graph.

• Content questions ("What does the exclusion say about mold?") go to hybrid text search, scoped by graph IDs.

• Compound questions are decomposed: graph to find the scope, semantic layer for the numbers, text search for the clause language, then synthesis with citations.

Agent frameworks expose each path as a tool, increasingly through MCP servers. The router can be the LLM itself with good tool descriptions, which works until tool count grows and accuracy drops. Many teams end up with a small classifier or explicit planner in front.

Ontology vs knowledge graph vs semantic layer: what is the difference?

An ontology is the schema of meaning: the classes of things in your business, the relationships allowed between them, and the rules they follow. A knowledge graph is the instance data that conforms to that ontology. A semantic layer is a metrics contract over tabular data. The ontology says "a Lease is between a Tenant and a Landlord entity, covers one or more Suites, and has zero or more Amendments that supersede specific terms." The knowledge graph holds the 11,482 actual leases. The semantic layer defines how "WALT" (weighted average lease term) is computed from them.

RDF vs property graphs

Two families dominate. RDF stores (GraphDB, Stardog, Amazon Neptune in RDF mode, Apache Jena) model everything as subject-predicate-object triples, use OWL for ontologies, SHACL for validation and SPARQL for query. Their strengths are formal semantics, global identifiers (IRIs), inference, and standards that make cross-organization data exchange easier. Property graphs (Neo4j, Memgraph, Neptune with openCypher, TigerGraph, Kuzu) let nodes and edges carry key-value properties directly, and are queried with Cypher or the ISO GQL standard. They are easier for application developers and map naturally onto relational source systems.

For most operator teams building agents, a property graph with a lightweight, explicitly versioned ontology is the pragmatic choice. Keep the ontology as code (YAML or LinkML, for example) so it can be reviewed like any schema change. Move to RDF when you need formal reasoning, regulatory data exchange, or federation across organizations. Edge properties matter more than people expect: effective dates on a lease-to-suite edge, or a coverage limit on a policy-to-claim edge, are where operational truth lives.

Where the "Palantir ontology" fits

The word "ontology" in Palantir Foundry and similar platforms means something broader: object types, links, and the actions (writebacks) allowed on them. That is a useful idea for agents, because it puts permissible actions next to the data model. You do not need Foundry to adopt it. Model the actions your agents may take (draft an estoppel, flag a claim for SIU review, propose a reorder) as part of the ontology, with permission rules attached.

Semantic layer vs knowledge graph

They overlap less than the marketing suggests. Semantic layers are optimized for aggregations over facts and dimensions in a star schema. Graphs are optimized for traversals over entities with many relationship types. A semantic layer will tell you portfolio occupancy in one query; it will not tell you which tenants share a guarantor. A graph can count, but you do not want two definitions of occupancy, one in Cube and one in Cypher. Keep metrics in the semantic layer, keep identity and relationships in the graph, and share the entity keys between them.

Do I need a knowledge graph? A decision test for which layer you need

You need a knowledge graph when your agents must answer questions that cross systems about specific entities, or when the same real-world thing has different IDs in different systems. If every question is answered from one document set or one well-modeled schema, you may not need one yet. Use this test with the 30 questions your users actually ask.

1. Write down the real questions. Pull them from Slack, ticket queues, analyst requests and email. Do not invent them in a workshop.

2. Tag each by shape. Content lookup (find the clause), metric (how much, how many, trend), relationship (who is connected to what), or compound.

3. Count systems per question. If the answer needs data from more than one system of record, mark it cross-system.

4. Check identity. For cross-system questions, do the systems share a reliable key? Usually they do not: the vendor ID in SAP differs from the supplier name on the PDF certificate, the claimant in Guidewire differs from the patient in Epic.

Then read the result:

• Mostly content lookups in one corpus: a well-built hybrid text search (BM25 plus vectors plus reranking) is enough. pgvector is fine.

• Mostly metrics over a clean warehouse: invest in a semantic layer first. Text-to-SQL without one is a slow way to discover your definitions disagree.

• Many cross-system or relationship questions, or no shared keys: you need entity resolution and a knowledge graph, and the other layers should hang off it.

• Corpus-wide "what are the themes" questions over large text: consider Microsoft-style GraphRAG or LazyGraphRAG for that corpus specifically.

In our experience across real estate, insurance, healthcare operations and manufacturing, the third bucket is where the valuable agent work sits. That is not a coincidence. Single-system questions were already answerable with a report.

What do these graphs look like on real operator data?

The examples below use fictional data but real system names and document types. Each shows the nodes, the edges, a question that breaks pure vector RAG, and which layer answers which part.

Commercial real estate: tenant, lease, property

Nodes: Property, Suite, Tenant, Parent Entity, Guarantor, Lease, Amendment, Clause (co-tenancy, kick-out, ROFR, exclusive use), CAM Reconciliation, Loan. Sources: Yardi or MRI for leases and charges, ARGUS for the underwriting model, CoStar for market comps, lease PDFs and estoppels for clause text, the loan servicer's reporting for covenants.

Edges: Tenant LEASES Suite (with start, end and effective dates), Lease AMENDED_BY Amendment, Amendment SUPERSEDES Clause, Tenant SUBSIDIARY_OF Parent Entity, Lease GUARANTEED_BY Guarantor, Clause DEPENDS_ON Tenant (co-tenancy tied to an anchor), Property COLLATERAL_FOR Loan.

Question: "If the grocery anchor at Riverside Commons goes dark, which leases trigger co-tenancy rent reductions, and what is the NOI impact against the DSCR covenant?" The graph finds the anchor, traverses DEPENDS_ON to the affected clauses (current version, after amendments), and returns the leases. The semantic layer computes NOI and DSCR with the firm's definitions. Vector search pulls the exact clause language for citation. Pure vector RAG would retrieve co-tenancy language from any lease that mentions a grocer, including superseded drafts. We go deeper on the reconciliation side in reconciling Yardi and ARGUS data for AI.

Insurance: claim, policy, claimant

Nodes: Policy, Coverage Part, Endorsement, Insured, Claim, Claimant, Provider, Attorney, Adjuster, Reserve Transaction, Payment. Sources: Guidewire ClaimCenter or Duck Creek for claims, the policy admin system for forms and endorsements, Applied Epic for agency data, adjuster notes and medical records as documents. In medical professional liability, add the insured physician, the facility, and the procedure.

Edges: Claim FILED_UNDER Policy, Policy HAS_ENDORSEMENT Endorsement (with effective dates), Claimant REPRESENTED_BY Attorney, Claimant TREATED_BY Provider, Claim ASSIGNED_TO Adjuster, Claim RELATED_TO Claim.

Question: "Was this water damage loss covered on the date of loss, and does it share a contractor, attorney or provider with other open claims?" Coverage requires the graph to find which endorsements were in force on the date of loss (a time-scoped traversal), then text retrieval over those specific forms. The shared-party question is a two-hop pattern match that vector search cannot express at all. Reserve adequacy figures come from the semantic layer. The final coverage call stays with a human.

Manufacturing and distribution: part, supplier, work order

Nodes: Part, Revision, BOM Line, Supplier, Purchase Order, Receipt, Nonconformance Report, Work Order, Work Center, Customer Order. Sources: Epicor, SAP or NetSuite for orders and inventory, JobBOSS or ProShop for job shop routing, SolidWorks PDM for drawings and revisions, supplier certs and NCRs as documents.

Edges: Part HAS_REVISION Revision, Revision USED_IN BOM Line, Part SUPPLIED_BY Supplier (with lead time and approved status), Work Order CONSUMES Part, Work Order ROUTED_THROUGH Work Center, Work Order FULFILLS Customer Order, NCR RAISED_AGAINST Receipt.

Question: "Which customer orders due in the next three weeks are exposed to the supplier whose last two lots of 6061 bar failed incoming inspection, and is there an approved alternate?" That is four hops: supplier to receipts to NCRs, supplier to parts, parts to work orders, work orders to customer orders, plus a check for alternate approved suppliers. On-time delivery and margin at risk come from the semantic layer.

What does a unified data layer for AI agents look like? A reference architecture

A unified data layer for AI agents connects source systems into a lakehouse, resolves entities into a knowledge graph conforming to an ontology, defines metrics in a semantic layer, indexes documents with links back to graph nodes, and exposes all of it to agents through governed tools. We describe this as a company brain; the label matters less than the layering.

1. Connectors and change capture. APIs, CDC from operational databases, SFTP drops, email and document ingestion. Yardi, Guidewire, Epic, Epicor, SharePoint, the shared drive nobody admits to.

2. Lakehouse raw and conformed zones. Land data as-is (bronze), conform types and history it (silver), with Snowflake, Databricks or Iceberg on object storage. Keep source timestamps and load timestamps separately; systems run on different clocks.

3. Entity resolution. Match records that refer to the same real-world thing across systems using deterministic keys where they exist (tax IDs, NPIs, policy numbers) and probabilistic matching (names, addresses, fuzzy similarity, embedding similarity) where they do not, with human review of low-confidence merges. Assign a stable enterprise ID. Senzing, Zingg and Splink are common tools, or roll your own on the warehouse.

4. Ontology. Versioned definitions of entity types, relationships, properties, and allowed actions.

5. Knowledge graph. Load resolved entities and relationships into Neo4j or another graph store, with effective dates on edges and provenance on every fact (which system, which record, when).

6. Semantic layer. dbt Semantic Layer or Cube over the gold tables, keyed by the same enterprise IDs.

7. Document index. Structure-aware chunking, contextual embeddings, BM25, stored in pgvector, Pinecone or the graph's own vector index. Every chunk carries the enterprise IDs of the entities it mentions.

8. Retrieval and tool layer. Graph query tools, metric tools, search tools, exposed through MCP or function calling, plus a router or planner.

9. Governance. Permissions enforced at retrieval time (row-level and document-level), audit logs of every query an agent ran, lineage from answer back to source record, PHI and PII handling.

10. Agents and review queues. Agents read, reconcile and draft; humans approve judgment calls.

The join key is the whole trick

If you remember one design rule, make it this: every chunk, every metric row and every graph node must share the same enterprise entity ID. That is what lets an agent move from "this paragraph mentions Acme" to "Acme's three leases, its parent's credit rating, and its 90-day delinquency" without guessing. Without the shared key you have three disconnected retrieval systems and an LLM doing string matching between them.

Entity resolution is the actual work

Teams budget for the graph database and the vector store and underbudget entity resolution, which is where most of the effort goes. Expect to spend real time on rules for parent and subsidiary rollups, DBA names, provider groups versus individual NPIs, supplier sites versus supplier companies, and how to handle merges that later turn out to be wrong (keep merge decisions reversible and logged). Community discussions about GraphRAG keep returning to the same complaint: naive name matching creates duplicate or wrongly merged nodes, and every downstream answer inherits the error.

Why MCP alone is not a data layer

MCP standardizes how agents call tools. It says nothing about whether two tools agree on what a customer is. Gartner's 2026 Market Guide for Agentic Analytics, as quoted by Cube, predicts that by 2028 60% of agentic analytics projects relying solely on MCP will fail due to the lack of a consistent semantic layer. Wiring an agent to fifteen MCP servers on top of fifteen systems that disagree just moves the reconciliation into the prompt. For the build-or-buy tradeoffs on this stack, see buying vs building an AI context layer.

What should you measure, and what is the ROI math?

Measure two things: retrieval quality on your own question set, and one countable business unit the agent changes. Retrieval metrics without a business unit get you a nicer demo. A business unit without retrieval metrics leaves you unable to tell why it moved.

Retrieval and answer metrics

• Answer accuracy on a gold set of 50 to 200 real questions with verified answers, scored by people who do the work.

• Retrieval recall@k for text: did the right chunk make the top 10 or 20?

• Entity resolution precision and recall on a hand-labeled sample of matches.

• Citation coverage: share of claims in an answer that link to a source record or document.

• Freshness lag: time from change in the source system to availability in the graph.

The countable unit and a worked example

Name the unit before you build: minutes per lease question answered, cost per claim file reviewed, hours per supplier risk review. The following numbers are hypothetical, for illustration only.

A hypothetical mid-size property owner's asset management team fields 600 lease and tenant questions a month (co-tenancy exposure, renewal options, estoppel prep, CAM disputes). Today each takes an analyst an average of 40 minutes across Yardi, the lease abstract spreadsheet and the PDF archive: 400 hours a month. With a graph-grounded agent producing a cited first draft, assume the analyst spends 12 minutes verifying instead: 120 hours a month. That frees 280 hours a month. At a loaded cost of $85 an hour, that is $23,800 a month, or about $285,600 a year, before counting faster decisions on renewals. Now subtract what it costs to build and run the data layer, and be honest about the adoption curve: if only half the analysts use it in the first two quarters, cut year-one savings accordingly. Built is not adopted, and the ROI only shows up when the team stops opening the PDF archive first.

The broader numbers suggest caution is warranted. MIT NANDA's 2025 "GenAI Divide" report, as covered by Virtualization Review, found that 95% of organizations saw no measurable return from generative AI initiatives, and linked the gap to brittle workflows and weak contextual learning. Context is exactly what this architecture is meant to supply.

Where should humans stay in the loop?

Agents should take the reading, reconciling and first-draft labor. Humans should keep decisions that carry legal, financial or clinical consequence, and decisions about the data model itself.

• Coverage and liability determinations. The agent assembles the policy forms in force on the date of loss and the relevant facts. The adjuster or coverage counsel decides.

• Low-confidence entity merges. Merging two tenant records or two provider records changes every downstream answer. Route uncertain matches to a data steward.

• Ontology changes. Adding a relationship type is a schema change. Review it like one.

• Anything sent outside the company. Estoppels, investor letters, appeal letters, supplier corrective action requests: draft by agent, signature by person.

• Metric definitions. An agent should never invent a metric. If the semantic layer does not define it, the right answer is "not defined," not a plausible formula.

Do not automate what you cannot verify. If the question set does not have a gold answer a human can check, the agent is not ready for it.

How do you start? A 90-day plan

Start with one workflow, one countable unit and the smallest graph that answers its questions. Do not start with an enterprise ontology program.

1. Days 1 to 15: pick the workflow and the questions. Choose one workflow with a measurable unit (lease questions, first notice of loss triage, supplier risk review). Collect 50 to 100 real questions and their correct answers. Baseline the current time per unit.

2. Days 10 to 30: map entities and sources. Draft the minimum ontology: 6 to 12 entity types and their relationships. Map each to source systems and fields. Identify where keys are missing.

3. Days 20 to 45: land and resolve. Load the relevant tables into the lakehouse, build entity resolution for the two or three entity types that cross systems, and measure match quality on a labeled sample.

4. Days 35 to 60: build the graph, the metrics and the index. Load resolved entities into the graph with provenance and effective dates. Define the five to ten metrics the workflow needs in the semantic layer. Chunk and embed the related documents, tagging each chunk with entity IDs.

5. Days 50 to 75: wire retrieval and evaluate. Expose graph, metric and search tools to an agent. Run the gold question set. Compare against a vector-only baseline so you can show what the graph and semantic layer actually added.

6. Days 70 to 90: put it in front of users with a review queue. Ship to a small group, track usage and the countable unit weekly, and fix the questions it gets wrong. Decide on expansion based on measured change, not on how the demo felt.

The biggest risk in this plan is not technical. It is that nothing changes because the old way still works well enough. Status quo is the competitor; the plan has to end with a number someone cares about.

Frequently asked questions

Is GraphRAG better than RAG?

For corpus-wide questions and multi-hop questions about connected entities, usually yes; Microsoft Research reported 72% to 83% comprehensiveness win rates on global questions. For single-document lookups, a well-tuned hybrid text search is often just as good and cheaper. Choose by question shape.

Can I use pgvector instead of Pinecone?

Yes, for most enterprise agent workloads in the low millions of chunks, pgvector with an HNSW index is enough, and keeping vectors next to relational data in Postgres simplifies permissions and joins. Dedicated stores like Pinecone make sense at larger scale, with heavy concurrent query loads, or when you want a managed service with no database operations.

Do I need a graph database to have a knowledge graph?

No. A knowledge graph is a data model plus resolved identity; you can store it in relational tables and query it with recursive SQL. A native graph database (Neo4j, Neptune) becomes worth it when traversals get deep or variable-length, or when developers need to express patterns quickly in Cypher.

Does Snowflake or Databricks have a knowledge graph?

Both offer pieces: vector search, semantic or metric views, and catalog metadata, plus partner graph integrations. Neither gives you entity resolution across your source systems or a business ontology out of the box. You still have to build or buy those.

Will MCP replace a semantic layer?

No. MCP is a protocol for calling tools. A semantic layer is the set of governed definitions those tools should return. Gartner's 2026 agentic analytics guidance predicts most MCP-only analytics projects will fail without one.

RDF or property graph for enterprise AI?

Property graphs (Neo4j, openCypher, GQL) are the pragmatic default for operational agent use cases because they map cleanly from relational systems and developers pick them up quickly. Choose RDF with OWL and SHACL when you need formal inference, standards-based data exchange, or federation across organizations.

How much does it cost to build a knowledge graph for an LLM?

The largest cost is usually people time on entity resolution and ontology design, not database licenses. LLM-based extraction from text adds token cost per chunk; Microsoft's LazyGraphRAG was designed to bring indexing cost down to vector RAG levels. Scope the graph to one workflow first and measure.

What is the difference between a context layer and a knowledge graph?

A knowledge graph is one component. A context layer is the full set of what an agent needs to reason: the graph, metric definitions, documents, permissions and history. Our post on AI context layers covers the concept in more depth.

Sources

• Juan Sequeda, Dean Allemang, Bryon Jacob, "A Benchmark to Understand the Role of Knowledge Graphs on Large Language Model's Accuracy for Question Answering on Enterprise SQL Databases," arxiv.org

• Microsoft Research (Edge et al.), "From Local to Global: A Graph RAG Approach to Query-Focused Summarization," arxiv.org

• Microsoft Research, "LazyGraphRAG: Setting a new standard for quality and cost," microsoft.com

• Anthropic, "Introducing Contextual Retrieval," anthropic.com

• dbt Labs, "Semantic Layer vs. Text-to-SQL: 2026 Benchmark Update," April 7, 2026, docs.getdbt.com

• Cube, "Cube recognized in the 2026 Gartner Market Guide for Agentic Analytics" (quoting Gartner's Market Guide for Agentic Analytics), cube.dev

• Gartner, "Lack of AI-Ready Data Puts AI Projects at Risk," February 26, 2025, gartner.com

• MLOps Community (Jonathan Bennion), "GraphRAG Analysis, Part 2: Graph Creation and Retrieval vs Vector Database Retrieval," home.mlops.community

• Virtualization Review, "MIT Report Finds Most AI Business Investments Fail, Reveals GenAI Divide," August 19, 2025, virtualizationreview.com

OutcomeCatalyst connects the systems you already run into a governed intelligence layer your team and your agents can reason over. Demos on this site use fictional data. To see this on your own operation, start a conversation.