Building Interactive Knowledge Graphs from Text with LLM-Powered Triple Extraction
Hook
A document processed with LLM-powered knowledge graph extraction can yield hundreds of explicit connections—then infer many more by analyzing graph topology alone. In one example run, 216 extracted triples expanded to 564 total relationships through entity standardization and inference.
Context
Traditional knowledge extraction relies on named entity recognition and dependency parsing, which struggle with implicit relationships and require domain-specific training data. You end up with disconnected entities or miss the conceptual bridges that make information networks useful. Meanwhile, LLMs excel at understanding context but hallucinate freely and lose consistency across long documents.
The ai-knowledge-graph project tackles this by combining LLM reasoning with graph analysis techniques. It processes documents in overlapping chunks, extracts Subject-Predicate-Object (SPO) triples via LLM calls, then uses both rule-based normalization and optional LLM alignment to merge entities across chunks. Finally, it applies community detection and transitive inference to discover relationships the source text implied but never stated. The output is an interactive HTML visualization—useful for exploring research papers, educational content, or any text where seeing connections accelerates understanding.
Technical Insight
The pipeline runs in three distinct phases, each addressing a specific challenge in document-scale knowledge extraction.
Phase 1: Chunked Triple Extraction
Long documents exceed LLM context windows and degrade attention on distant tokens. The system splits text into configurable chunks (default: 200 words) with overlap (default: 20 words) to preserve context at boundaries. Each chunk gets sent to any OpenAI-compatible API endpoint—Ollama, vLLM, LiteLLM, or OpenAI itself—with a prompt engineered to extract structured SPO triples:
# From config.toml
[llm]
model = "gemma3"
api_key = "sk-1234"
base_url = "http://localhost:11434/v1/chat/completions" # Local Ollama
max_tokens = 8192
temperature = 0.2
[chunking]
chunk_size = 200 # Words per chunk
overlap = 20 # Overlap to preserve contextThe chunking strategy is deliberately simple—word-count based rather than semantic. This trades some context awareness for predictability and speed. In the example from the README, a text document becomes 13 chunks, each processed independently. The overlap means boundary sentences appear in multiple chunks, increasing the chance that relationships spanning chunk edges get extracted at least once.
Phase 2: Entity Standardization
Different chunks refer to the same entity using variations: “Industrial Revolution,” “the Industrial Revolution,” “this revolution.” Without normalization, these become separate nodes. The system applies a hybrid resolution strategy:
==================================================
PHASE 2: ENTITY STANDARDIZATION
==================================================
Starting with 216 triples and 201 unique entities
Standardizing entity names across all triples...
Applied LLM-based entity standardization for 15 entity groups
Standardized 201 entities into 181 standard forms
After standardization: 216 triples and 160 unique entitiesFirst, rule-based normalization handles obvious cases: lowercasing, trimming whitespace, removing articles. Then, if use_llm_for_entities = true in the config, ambiguous groups get sent to the LLM with a prompt asking which names refer to the same entity. This catches semantic equivalences like “steam engine” and “Watt’s engine” that string matching would miss. The tradeoff is cost—each entity resolution call consumes tokens—so you can disable it for budget-constrained runs.
Phase 3: Relationship Inference
The extracted triples form a graph, but often a fragmented one. A document might discuss different topics in different chunks without explicitly connecting them. Phase 3 uses graph topology to infer missing links:
# Configuration options
[inference]
enabled = true
use_llm_for_inference = true
apply_transitive = trueThe system runs Louvain community detection to identify disconnected clusters, then uses techniques including lexical similarity between entities to propose connections. If LLM-based inference is enabled, it sends pairs to the model asking about potential relationships. Transitive rules also apply: if A→B and B→C, infer A→C for certain relationship types.
In the example run shown in the README, this phase added 370 inferred relationships to the original 216 extracted triples—more than doubling the graph density. The output shows:
Identified 9 disconnected communities in the graph
Inferred 3 new relationships between communities
Inferred 3 new relationships between communities
[... 9 iterations ...]Visualization and Output
The final graph renders to an interactive HTML file that provides a physics-based layout. Nodes represent entities, edges represent relationships (labeled with predicates), and you can drag, zoom, and click to explore. The Industrial Revolution example—available at the demo link in the README—shows how this makes documents navigable at a glance.
The tool is LLM-agnostic by design. As long as your backend speaks OpenAI’s chat completion format, you can swap models without code changes. Running Ollama locally with Gemma 3 avoids API costs; switching to GPT-4 via OpenAI may improve extraction quality; using LiteLLM unlocks AWS Bedrock, Azure OpenAI, Anthropic and other LLM services. The base_url parameter is the only required change.
Gotcha
The aggressive inference phase is a double-edged sword. Adding 370 relationships from 216 source triples means the majority of your graph comes from algorithmic guesses, not extracted facts. There’s no explicit confidence scoring mentioned in the documentation, no provenance tracking, and no built-in fact verification. If the LLM hallucinates a triple during extraction—say, inventing a person who didn’t exist—standardization and inference will happily propagate that fiction throughout the graph. For exploratory analysis this is acceptable; for production knowledge bases it’s disqualifying.
The chunking strategy also has blind spots. Word-count segmentation doesn’t respect paragraph or section boundaries, so a chunk might start mid-sentence or split a cohesive argument across two LLM calls. The 20-word default overlap mitigates this but doesn’t eliminate it. Documents with complex nested structures—like legal contracts or technical specifications—may lose important context that simpler narratives preserve.
Finally, while the interactive visualization is useful for exploration, very large graphs with thousands of entities would likely become difficult to navigate. The tool appears designed for document-scale knowledge graphs, not encyclopedia-scale ones.
Verdict
Use if: You’re exploring conceptual relationships in research papers, documentation, or educational content and want an interactive map to accelerate understanding. You’re comfortable with recall-over-precision tradeoffs and need rapid prototyping more than production-grade accuracy. You want to experiment with different LLM backends (local models via Ollama, cloud APIs via OpenAI, or services accessible through LiteLLM) without rewriting extraction logic. Skip if: You need provenance tracking, confidence scores, or fact verification for a production knowledge base. Your documents are extremely large with thousands of entities—the visualization may not scale well. You’re working in highly technical domains where hallucinated relationships would cause serious problems (legal, medical, financial). For those cases, consider graph database solutions like Neo4j with custom NLP pipelines, or frameworks like LlamaIndex or LangChain that provide memory management and retrieval-augmented generation capabilities.
