> ## Documentation Index > Fetch the complete documentation index at: https://docs.helix-db.com/llms.txt > Use this file to discover all available pages before exploring further. # What is a knowledge graph? > A knowledge graph stores facts about entities and the typed relationships between them, organized by a schema or ontology so software can query them.
Concept
A knowledge graph is a structured collection of facts about entities, such as people, products, documents, and concepts, and the typed relationships between them, typically organized by a schema or ontology. Facts link entities to each other or to attribute values, and each fact can record where it came from, so software can answer questions by following connections and cite its sources. Knowledge graphs are commonly stored in graph databases and used to ground search, recommendations, and large language model (LLM) applications in connected, verifiable facts.
After reading this article you will be able to: * Describe the parts of a knowledge graph, from entities to provenance * Compare a knowledge graph with a graph database * Explain how a knowledge graph is built, including extraction and entity resolution * Describe how a knowledge graph is kept current as sources change
## What is in a knowledge graph? A knowledge graph contains entities, the typed relationships between them, attributes that describe both, and provenance for each fact, usually organized by an ontology or schema that defines the allowed types. | Part | What it is | Example | | ------------------ | ------------------------------------------------------------ | --------------------------------------------------------- | | Entity | A distinct thing the graph knows about | A customer, a product, a feature, a support ticket | | Relationship | A typed, directed connection between two entities | A ticket is `ABOUT` a feature | | Attribute | A value that describes an entity or relationship | A product's `releaseStage`, a relationship's `confidence` | | Ontology or schema | The allowed entity types, relationship types, and attributes | "A `Ticket` can be `ABOUT` a `Feature`, not a `Customer`" | | Provenance | Where each fact came from and when | The document chunk a relationship was extracted from | ```mermaid theme={"languages":{"custom":["languages/helixql.json"]}} flowchart LR cust["Customer
customer-a"] -->|OPENED| ticket["Ticket
Export fails"] ticket -->|ABOUT| feat["Feature
CSV export"] feat -->|PART_OF| prod["Product
Reports"] doc["Document
Export guide"] -->|DESCRIBES| feat ticket -.->|EXTRACTED_FROM| chunk["Chunk
ticket thread excerpt"] ``` A schema or ontology is usually what separates a knowledge graph from an arbitrary set of links. It fixes what kinds of things exist and how they may relate, so facts from different sources land in the same shape and queries mean the same thing everywhere. An ontology usually goes further than a schema: it can also define class hierarchies, constraints, and inference rules. ## What is the difference between a knowledge graph and a graph database? A knowledge graph is data with agreed meaning. A graph database is software that stores and queries graph-shaped data. The two are often used together but are not the same. | | Knowledge graph | Graph database | | ---------------------------- | -------------------------------------------------- | ----------------------------------------------------------- | | What it is | A body of facts organized by an ontology | A storage and query engine | | Main concern | Meaning, consistency, and provenance of facts | Storage, indexing, transactions, and traversal | | Can exist without the other? | Yes, for example as RDF files or relational tables | Yes, for example holding a network topology or social graph | A knowledge graph can be stored as a [property graph](/learn/graph-databases/what-is-a-property-graph) or as RDF triples. See [property graph vs RDF](/learn/graph-databases/property-graph-vs-rdf) for how the two models differ. ## How do you build a knowledge graph? You build a knowledge graph by defining an ontology, extracting entities and relationships from your sources, resolving duplicate entities, recording provenance, and loading the result into a database. List the entity types, relationship types, and required attributes your questions need. Start small; a focused schema is easier to extract into and to query. Structured records such as account and product tables map to entities almost directly. Unstructured sources such as documents, tickets, and conversations need extraction. For unstructured text, the application runs an extraction pipeline: split each document into chunks, ask an LLM or another extraction model to return the entities and relationships it finds in a fixed format that matches the ontology, and reject output that does not validate against the schema. Decide when two mentions refer to the same thing. One ticket says "the billing page" and another says "the invoices screen"; both may mean one feature. Typical techniques combine exact identifiers, normalized names, embedding similarity to find candidates, and rules or review to confirm a merge. Link each extracted fact to the chunk and document it came from, with the extraction time and a confidence value. Provenance supports citations, audits, and later corrections. Write entities, relationships, and provenance together, and add indexes for the lookups and searches your application runs. ## How do you keep a knowledge graph fresh? You keep a knowledge graph fresh with a maintenance loop rather than a one-time load: ingest changes incrementally, supersede outdated facts, retract facts by source, and re-run entity resolution. * **Ingest incrementally.** Track which facts came from which source, and re-extract only the documents that changed. * **Supersede rather than overwrite.** Mark outdated facts with validity fields such as `validTo` or `isLatest`, and link a new version to the one it replaces, so history stays queryable. * **Retract by source.** When a document is deleted or corrected, provenance tells you exactly which facts to remove or re-check. * **Re-run entity resolution.** New mentions can reveal that two existing entities are the same, or that one entity should be split. ## How do knowledge graphs help LLMs and RAG? A knowledge graph lets RAG retrieve connected, typed facts rather than only passages similar to the question, so it can answer multi-hop questions and cite sources. [Retrieval-augmented generation (RAG)](/learn/ai-memory/what-is-rag) supplies an LLM with retrieved context before it answers, and retrieval based only on vector similarity struggles with questions such as "which customers reported problems with features in the Reports product?", where the answer is spread across entities and relationships rather than contained in one passage. Following explicit facts across the graph is an approach often called [GraphRAG](/learn/ai-memory/what-is-graphrag). LLM-extracted facts can be wrong, so keep confidence values and provenance, and let downstream prompts treat low-confidence facts accordingly. ## How does HelixDB store a knowledge graph? HelixDB stores data as one labeled property graph, which maps directly onto a knowledge graph: * **Entities and relationships.** Entities are nodes and relationships are directed edges, each with exactly one label and typed properties. Because HelixDB is a multigraph, two sources asserting the same relationship can be kept as separate edges with their own properties. * **Embeddings and text on the same nodes.** Store an embedding and a text field on an entity or chunk node, then add a [vector index](/database/helix-db/query-guides/vector-indexes) and a [text index](/database/helix-db/query-guides/text-indexes) for similarity and BM25 search. The application computes the embeddings; HelixDB stores and indexes them. * **Provenance edges.** Connect entities, or facts modeled as their own nodes, to their source chunks and documents with edges that carry properties such as confidence or extraction time. For a fact stored as a relationship edge, record provenance as properties on that edge, such as the source chunk ID, confidence, and extraction time. Indexes can target edge properties as well as node properties. * **Identity and freshness.** Unique equality indexes on node labels suit canonical identifiers, and equality or range indexes on fields such as `isLatest` or `validTo` make queries that filter to current facts efficient. * **Scoped retrieval.** Vector and BM25 search can be [prefiltered](/database/helix-db/query-guides/prefiltering) to a traversal-defined candidate set, such as documents a user can read. All entries in a write batch commit or roll back together, so an entity, its relationships, and their provenance can be written as one unit when they are sent in the same write batch. Start with the [data model](/database/helix-db/core-concepts/data-model). ## Frequently asked questions ### What is the difference between a knowledge graph and an ontology? An ontology is a formal specification of a domain: the types of entities and relationships and the rules that govern them, such as class hierarchies and constraints. The knowledge graph's instance data, its entities and facts, follows the ontology, and many systems store the ontology in the graph alongside that data. One ontology can describe many knowledge graphs. ### Do you need RDF to build a knowledge graph? No. RDF is one standard way to represent a knowledge graph, and it suits publishing and integrating data across organizations. A labeled property graph works as well and is common for application-facing knowledge graphs. See [property graph vs RDF](/learn/graph-databases/property-graph-vs-rdf). ### Can an LLM build a knowledge graph automatically? An LLM can extract candidate entities and relationships from text at scale, but the output needs validation against the ontology, entity resolution, and provenance. Treat extraction as one stage of a pipeline the application controls. ### How is a knowledge graph different from a vector database? A vector database retrieves items by similarity of embeddings. A knowledge graph represents explicit, typed facts and how they connect. Many AI applications use both: vectors to find relevant starting points, and the graph to follow facts from there. See [What is a vector database?](/learn/vector-search/what-is-a-vector-database). ## Related topics Nodes, edges, traversals, and when a graph is the right model. Labeled nodes and edges with typed properties on both. Two ways to model a knowledge graph, compared side by side. Grounding a model's answer in data retrieved at query time. Retrieval that follows relationships, compared with vector RAG. Working, episodic, and semantic memory for LLM agents.