Knowledge Graph Construction From Unstructured Documents

Most enterprise knowledge sits in PDFs, wikis, emails, and manuals that no machine can query directly. Turning that pile into a knowledge graph, structured, queryable, reasoned over, follows a set sequence: ingest and chunk the text, extract entities and relationships, resolve duplicate references, align everything to a shared schema, then load it into storage. Each stage has its own failure modes, and the stage teams skip almost always turns out to be resolution, not extraction. That instinct is backwards, and it's the one this piece argues against.

Grand View Research puts the enterprise knowledge graph market at USD 2.9 billion in 2025, headed for USD 13.4 billion by 2033, a 21.3% compound annual growth rate. That climb tracks a real shift: companies moving past chatbot demos into production systems that need grounded, structured context instead of a pile of vector embeddings and a prayer. GraphRAG (graph-based retrieval-augmented generation) is driving most of it, because plain vector search answers "what does this document say" well enough but falls apart on "how are these forty documents connected." Multi-hop questions depend on a graph beneath them; that dependency is what is pulling knowledge graph construction out of the librarian-and-ontologist corner it used to live in, produced by the graph's structural role in answering multi-hop queries.

What a knowledge graph is, and what "construction from unstructured text" requires

A knowledge graph is a structured semantic knowledge base describing concepts and how they relate to one another. Nodes are entities, edges are typed relationships, and properties hold the attributes attached to either. The value of the format is that it compresses document-level information into instance-level facts: instead of "this PDF mentions a merger," the graph states "Company A acquired Company B on this date," sitting as a discrete, queryable fact next to every other fact like it.

Four terms get used loosely, and shouldn't be. A knowledge graph is the populated structure: the actual instances and relationships sitting in the database. An ontology is the schema layer above it, the rules defining what types of entities and relationships are even allowed to exist. A graph database, Neo4j being one commonly reached-for name, is the storage engine that both an ontology and instance data rely on. Loading a graph database with nodes and edges while skipping the ontology produces a property graph, not a knowledge graph in the fuller sense. Semantic layers and context layers overlap with these ideas in places, but treating any of the four as interchangeable is how teams end up arguing past each other in a design review.

Construction from unstructured text splits into two jobs. Knowledge extraction populates the graph: pulling entities, relations, and attributes out of raw text. Knowledge integration comes after, merging what got extracted into a graph that may already exist, updating it without duplicating what's already there. Three atomic tasks underlie both jobs in every serious pipeline. Named entity recognition finds people, organizations, locations, dates, monetary amounts, and whatever domain-specific categories the application needs. Coreference resolution figures out that "the company," "it," and "Apple Inc." all point to the same thing inside a passage. Relation extraction identifies the typed connection between two entities once they've been found. Everything downstream is a variation on getting these three tasks right at scale.

Why the pre-LLM pipeline baseline still matters

Before large language models entered the picture, the pipeline ran in rigid stages: preprocess the text, run named entity recognition with Conditional Random Fields or a task-specific deep learning model, extract relations through syntactic or semantic parsing, map the resulting subject-predicate-object triples into a graph database, then enrich the graph with additional sources. Traditional NLP toolkits carried the NER step, and several remain in active use for domains narrow enough and well-labeled enough that they don't need an LLM's flexibility.

The bottleneck was training data. Every stage needed large, accurately labeled datasets, and accuracy dropped fast the moment text drifted into domain-specific vocabulary, technical codes, or operational abbreviations a general-purpose model hadn't seen. Rule-based systems fared no better: hand-written pattern rules worked against text that looked like what the rule author expected, and broke against anything else. Real-world documents are dynamic and messy by nature, and that's exactly the kind of input those rules couldn't bend to fit.

None of that history is trivia to skip past. Traditional NLP tools still win in constrained, well-labeled domains where LLM inference cost or latency directly affects feasibility. Constrained, well-labeled domains with fixed taxonomies are reasonable places to keep traditional NLP toolkits in the loop rather than reaching for an LLM by default. The old failure modes also explain why certain design choices, chunking strategy and schema guidance among them, carried forward into the LLM era instead of getting reinvented from scratch. Hybrid pipelines, a traditional NLP toolkit for a fast first-pass NER followed by an LLM for the harder relation-extraction step, are a legitimate production pattern today, and probably underused given how much compute they save.

Stage 1: Document ingestion and chunking, why the boundary you draw shapes everything downstream

Ingestion has to handle whatever format the enterprise actually produces: PDFs, including scanned and handwritten pages, HTML, Word documents, emails, wiki pages, semi-structured exports. Each format demands different parsing to recover not just the text but the layout and structural signals around it. A table's row structure carries meaning that a flat text dump throws away.

Once the text is recovered, it has to be chunked before an LLM ever sees it, because context windows and cost both cap how much text fits into a single extraction call. The chunking decision is not cosmetic. Whatever boundary gets drawn sets the context the model has in front of it when it tries to extract entities and relations, and a boundary drawn in the wrong place can sever the exact context that would have made an extraction correct.

Fixed-size chunking is the wrong default for anything beyond a quick pilot. It splits by token or character count, ignoring the document's own structure. It's fast and simple to implement, and it routinely cuts through the middle of a sentence or severs a paragraph from the header that gives it meaning. Hierarchical chunking respects the document's actual shape, section headers, paragraph breaks, figure captions, keeping units that belong together in the same chunk. A 2026 materials science preprint from Mohammadi et al. on ChemRxiv backs this up directly: hierarchical chunking outperformed fixed-size chunking on entity and relationship extraction. The gap comes down to context. Context-aware segmentation hands the extraction model coherent units to reason over; fixed-size chunking hands it arbitrary fragments and expects the same accuracy out of them. Whoever draws the chunk boundary is, in effect, deciding what the extraction model is even capable of seeing.

Stage 2: Entity and relationship extraction, and what changed and what did not

The LLM approach to extraction feeds a chunk into the model with a structured prompt that specifies the target entity types, the relationship types, and the output format, usually JSON triples, and the model hands back candidate nodes and edges. LLMs removed the labeled-training-data bottleneck. They did not remove the underlying difficulty of the task: getting consistent, correct structure out of messy prose is still the whole problem.

Three approaches sit on a spectrum from loose to strict, and picking the wrong one for the job is a common, avoidable mistake. Schema-free extraction lets the LLM decide on its own which entity and relation types to create. It's flexible and needs no upfront schema work, but it produces inconsistent type vocabularies from one chunk to the next, "founded," "established," and "created" all showing up as separate relationship types for what should be one fact, and it demands heavy cleanup afterward. Schema-guided extraction embeds the allowed node and relationship types directly into the prompt, constraining the model's output and producing cleaner results that line up with an existing graph schema, which matters most for incremental builds where new documents get added to a graph that already has structure. Ontology-guided extraction goes further still, folding a formal domain ontology into both prompt design and output validation. It produces the highest consistency of the three, but the ontology work has to happen before extraction starts, a real upfront cost that schema-free approaches let teams defer, usually at their own expense later. The Mohammadi et al. materials science pipeline, which used the EMMO ontology, and the Kahlawi et al. Springer chapter both apply the ontology-guided approach in practice, not just on paper. Teams that skip straight to schema-free extraction because it's faster to stand up are borrowing against a cleanup bill they'll pay later, usually with interest.

A handful of named tools show how these approaches actually get built. Neo4j's LLM Knowledge Graph Builder runs on LangChain's LLMGraphTransformer, using the convert_to_graph_documents method to turn LangChain documents into graph documents, complete with a schema specifying allowed nodes, relationships, properties, and extraction instructions, plus a UI for uploading PDFs directly. KGGen splits the process into sequential entity detection and relation generation, folding in entity clustering for deduplication. Other tools pair domain ontologies with LLM-based extraction for downstream question answering. iText2KG runs zero-shot, topic-independent knowledge graph induction across varied text inputs, with built-in entity and relation deduplication and automatic threshold calibration, with built-in entity and relation deduplication, though the researchers behind it say directly that unresolved and semantically duplicate entities remain an open limitation.

Scale is where single-prompt extraction starts to strain. A multi-agent LLM framework makes the case for orchestration over brute force: applied to fifty real Ethernet switch manuals, it extracted knowledge graphs with correctness scores between 0.97 and 0.99, and the resulting graphs supported downstream test case generation. Coordinating several agents against fifty heterogeneous manuals is a different engineering problem than getting one prompt to work on one clean document, and the results suggest agent orchestration handles that mess in a way flat single-prompt approaches don't.

Stage 3: Entity resolution and deduplication, the step where most enterprise builds stall

Extraction run across many chunks and documents produces the same real-world entity under several different names. "Apple Inc.," "Apple," "AAPL," and "the Cupertino company" might all describe one node, but nothing in the extraction step forces the pipeline to notice. Entity resolution, sometimes called entity disambiguation or deduplication, is the job of deciding which candidate nodes are really the same thing and merging them into one canonical record, often called a golden record.

This is the hardest problem in the pipeline, harder than extraction, and most teams scope it as though it were the easy part. That's the miscalculation that sinks builds months in. Resolution requires reasoning across chunks, not within the boundaries of a single one: the system doing the resolving needs some memory of everything seen so far, which extraction never had to carry. Surface-form similarity is the most obvious signal to reach for, and it's the wrong one to lean on alone, since "Washington" might be a person, a city, or a state, and no amount of string matching tells you which. Domain-specific abbreviations and internal codes carry no distributional signal a general-purpose LLM picked up during training, so the model has nothing to pattern-match against.

Scale compounds all of it. A single 500-page corpus can throw off tens of thousands of candidate nodes, each one a decision waiting to get made correctly, and getting even a small fraction wrong means duplicate nodes silently fragmenting what should be one entity across a dozen edges. Extraction looks hard and isn't anymore, not at current-generation model cost and speed. Resolution looks easy from a project plan and isn't, and it's the stage that gets under-resourced almost every time, because nobody puts "grinding, tedious matching work" on a line item until the graph is already full of near-duplicate nodes nobody trusts.

Stage 4: Ontology alignment, mapping extracted concepts to a shared schema

Ontology alignment maps extracted entity types and relationship types onto the controlled vocabulary the graph's ontology defines, making sure "wrote," "authored," and "is the author of" collapse into one canonical relationship type instead of living on as three separate edges that mean the same thing. Skipping that collapse causes the graph to fragment into synonyms that no query can reliably traverse, no matter how clean the underlying extraction was.

This stage has to exist on its own, separate from extraction, because schema-guided prompts don't eliminate label drift by themselves. LLMs still produce variants. Domain experts frequently disagree with engineers, and with each other, about whether something belongs in the graph as its own entity node or as a property hanging off another node, and that kind of ambiguity has to get settled before anything loads into the graph, not after.

Two failure modes appear often enough in practice to name directly, common enough in practice to name directly. Writing a complete RDF/OWL ontology before touching any real data almost never survives contact with an actual production corpus, because the ontology needs revision the moment extraction reveals what concepts and relationships the documents actually contain. Conflating ontology design with semantic layer design is the other one, and it tends to reopen vocabulary arguments halfway through a build that should have already settled them.

The approach that holds up looks different from both, and it isn't complicated: draft a working ontology scoped to the domain at hand, run extraction against it, find the mismatches, revise, repeat. Iterate against real data instead of trying to front-load a perfect schema before anyone has seen what the documents contain. When a concept sits ambiguously between entity and property, that call belongs to domain experts working alongside engineering, not to engineering alone, and teams that hand it to engineering by default tend to regret the schema six months later.