Knowledge Graphs For LLM Powered Wikis

An LLM-powered wiki becomes materially more reliable when the wiki remains the editorial system of record, the knowledge graph becomes the structural index, and embeddings remain the fuzzy recall layer rather than the...

Metadata

Field	Value
Source site	llmwikis.org
Source URL	https://llmwikis.org/
Canonical AIWikis URL	https://aiwikis.org/llmwikis/files/raw-system-archives-llmwikis-agent-file-handoff-retired-source-archive-2-b573a14a/
Source reference	raw/system-archives/llmwikis/agent-file-handoff/retired-source-archive-2026-06-13/2026-05-06/Improvement/knowledge-graphs/Knowledge graphs for LLM-powered wikis.md
File type	md
Content category	memory-file
Last fetched	2026-06-22T01:56:21.9510185Z
Last changed	2026-05-06T15:24:03.6039478Z
Content hash	sha256:b573a14a8dcdbe37f8e44cdf85070b8e240918158b3234e7d960877116a4f98c
Import status	unchanged
Raw source layer	data/sources/llmwikis/raw-system-archives-llmwikis-agent-file-handoff-retired-source-archive-2026-06-13-2026-05-06-imp-b573a14a8dcd.md
Normalized source layer	data/normalized/llmwikis/raw-system-archives-llmwikis-agent-file-handoff-retired-source-archive-2026-06-13-2026-05-06-imp-b573a14a8dcd.txt

Current File Content

Structure Preview

• Knowledge graphs for LLM-powered wikis
• Executive summary
• Goals and graph model choices
• Architecture, schema, and ingestion
• Storage options and starter stacks
• Retrieval and LLM integration
• Governance, evaluation, scale, and security
• Roadmap, MVP checklist, and primary sources

Raw Version

This public page shows a bounded preview of a large source file. The complete source remains in the raw and normalized source layers named in metadata, with the SHA-256 hash above for verification.

• Source characters: 42458
• Preview characters: 11637

# Knowledge graphs for LLM-powered wikis

## Executive summary

An LLM-powered wiki becomes materially more reliable when the wiki remains the editorial system of record, the knowledge graph becomes the structural index, and embeddings remain the fuzzy recall layer rather than the truth store. Current official patterns point in that direction: entity["company","Microsoft","software company"] GraphRAG distinguishes corpus-wide **global search**, entity-centric **local search**, and **DRIFT** search, while Neo4j’s GraphRAG package exposes vector, vector-plus-Cypher, hybrid lexical-plus-vector-plus-Cypher, and text-to-Cypher retrieval patterns. The practical implication is that a serious LLM wiki should retrieve an evidence bundle—canonical page metadata, graph neighbors, and source-backed passages—not just semantically similar chunks. citeturn11view0turn13view0turn11view2turn11view3turn11view5turn14view2

Under the stated assumption that there are no fixed constraints on budget, scale, or cloud, the strongest default MVP is **property-graph first**: a canonical wiki store, a graph with explicit entities and claim/provenance objects, and a vector index for recall. Move to an **RDF-first** stack when the primary business value is linked open data publication, standards-based interoperability, SPARQL federation, or a semantic-web-native editing surface. That tradeoff follows directly from the official sources: Neo4j documents the property-graph model as nodes, relationships, labels, and properties; the entity["organization","World Wide Web Consortium","web standards body"] defines RDF and SPARQL as web standards for graph data interchange and querying; Wikibase and Semantic MediaWiki are explicitly oriented toward structured, collaborative, linked-data knowledge bases. citeturn11view4turn16view0turn11view7turn11view8turn11view9turn17view0turn11view11turn17view2

The minimum design that consistently works is small but non-negotiable: parse frontmatter as authoritative metadata, normalize aliases and canonical IDs before LLM extraction, model **Claim** and **SourceSpan** explicitly, keep editorial states such as `proposed`, `reviewed`, and `canonical`, filter retrieval by both review state and access control, and require answer-level citations plus abstention when evidence is weak. This is the same design logic behind Wikibase’s statement/reference orientation and Microsoft GraphRAG’s own warning that adding outside “general knowledge” to reduction prompts can increase hallucinations. citeturn11view10turn17view0turn13view0

## Goals and graph model choices

The correct graph design starts with the questions the wiki must answer. Neo4j’s modeling guidance explicitly begins from application use cases and the questions they imply, and Microsoft GraphRAG’s official query modes similarly separate entity-specific from corpus-wide reasoning. In other words, choose the model that makes your dominant queries easiest to answer and easiest to audit. citeturn18view0turn11view2turn13view0

| Goal | Representative question | Why a graph helps |
|---|---|---|
| Grounded definitions | “What does this term mean in our corpus?” | Direct entity lookup, canonical definitions, source spans |
| Relationship tracing | “How does concept A depend on theory B?” | Multi-hop traversal over typed edges |
| Corpus synthesis | “What are the major themes across the whole wiki?” | Community structure, summary layers, thematic clustering |
| Editorial maintenance | “Which claims have no sources?” | Structural QA over claims, references, and states |
| Knowledge-gap detection | “Which important entities still have no canonical page?” | Degree, centrality, orphan, and missing-page checks |
| Controlled writing assistance | “Draft a page outline from existing claims and evidence” | Graph-backed outline generation instead of raw text improvisation |

The dominant strategic choice is between a property graph and an RDF stack. The shortest useful rule is this: if your wiki is primarily an **application** with graph-backed retrieval and UI features, choose property graph first; if it is primarily a **knowledge publication and interoperability surface**, choose RDF first. If you are genuinely undecided and want both directions available in a managed service, Amazon Neptune keeps both property-graph and RDF paths open, but you still need one primary editorial model. citeturn16view1turn11view14

| Approach | Strongest fit | Advantages | Tradeoffs | Official source basis |
|---|---|---|---|---|
| Property graph | Internal or productized wikis, traversal-heavy apps, graph-aware RAG | Natural app-centric model of nodes, relationships, labels, and properties; relationship properties work well for confidence, timestamps, source references, and ACL hints; direct graph-plus-vector retrieval patterns are well-developed in Neo4j and LlamaIndex | Interoperability depends more on your own schema discipline than on web standards; RDF publication usually becomes a later export layer | citeturn11view4turn16view0turn11view6turn16view2turn16view3 |
| RDF and SPARQL | Linked open data, semantic-web ecosystems, external federation, ontology-driven knowledge publishing | RDF and SPARQL are W3C standards; RDF is designed for data merging and schema evolution; SPARQL supports graph-pattern querying across diverse sources; good fit for public or partner-facing knowledge graphs | More modeling overhead for app teams; provenance and qualifiers often require statement-level modeling rather than naive triples; ontology alignment matters more | citeturn11view7turn11view8turn17view0turn11view9 |
| Wikibase-style RDF stack | Collaborative structured knowledge bases with references, qualifiers, and ranks | Statement/reference model is unusually strong for editorial provenance; linked open data ecosystem; supports RDF/SPARQL tooling | Internally JSON-based rather than “pure RDF”; flexibility without shared ontology can reduce cross-instance interoperability | citeturn11view10turn17view0turn17view1 |
| Semantic MediaWiki | Existing MediaWiki installations that need semantic annotations inside the wiki itself | Turns wiki content into machine-processable annotations and improves querying, browsing, and sharing from inside MediaWiki | Less suited than a dedicated application graph when you need heavy graph analytics, custom retrieval pipelines, or independent graph services | citeturn11view11turn17view2 |

The practical decision rule is simple. If your first five use cases sound like **find**, **trace**, **recommend**, **repair**, and **explain**, property graph is usually the best MVP. If they sound like **publish**, **interoperate**, **federate**, **align vocabularies**, and **serve external SPARQL clients**, RDF should lead.

## Architecture, schema, and ingestion

A durable LLM wiki architecture has four storage truths: a canonical wiki/content store, a graph store, a vector store, and an immutable source/provenance layer. Microsoft GraphRAG’s standard indexing pipeline similarly emphasizes extracting entities, relationships, and claims, performing community detection, generating multi-level summaries, and writing outputs to Parquet tables plus a configured vector store; Neo4j’s native vector indexes then make embeddings directly queryable inside the graph tier. citeturn12view0turn11view6

```mermaid
flowchart LR
    subgraph Content
        A[Markdown or MediaWiki pages]
        B[PDFs, HTML, notes]
        C[Canonical glossary files]
    end

    A --> D[Parse frontmatter and headings]
    B --> D
    C --> D

    D --> E[Normalize IDs, aliases, and source hashes]
    E --> F[Extract entities, relationships, and claims]
    F --> G[Attach source spans and provenance]
    G --> H[(Wiki or page store)]
    G --> I[(Graph DB)]
    G --> J[(Vector index)]
    G --> K[(Source span store)]

    I --> L[Hybrid retriever]
    J --> L
    K --> L
    H --> L
    L --> M[Answer API, wiki UI, editorial tools]
```

The architecture above is intentionally layered: the wiki is the human-editable artifact, the graph is the machine-readable structure, vectors are the fuzzy retrieval layer, and source spans make every answer auditable. That division mirrors both GraphRAG’s indexing outputs and Wikibase’s statement/reference orientation. citeturn12view0turn11view10turn17view0

A minimal schema should be small, explicit, and oriented around provenance. Two rules matter most. First, relationship names should be **specific verbs**, not generic `CONNECTED_TO`; Neo4j’s modeling docs recommend intuitive, specific types because they make traversal and performance better. Second, provenance should not be implicit: model claim-level evidence explicitly, because the Wikibase family of tools demonstrates that references, qualifiers, and rank/state are core knowledge-management objects, not optional afterthoughts. citeturn18view0turn11view10turn17view0

| Kind | Name | Required fields | Purpose |
|---|---|---|---|
| Node | `Page` | `pageId`, `title`, `slug`, `revisionHash`, `reviewState`, `aclClass` | Human-facing article or note |
| Node | `Entity` | `canonicalId`, `kind`, `preferredLabel`, `status` | Canonical thing or concept the wiki talks about |
| Node | `Alias` | `aliasKey`, `displayForm`, `normalizationMethod` | Search and reconciliation layer |
| Node | `Claim` | `claimId`, `predicate`, `objectNorm`, `confidence`, `reviewState`, `extractorVersion` | Atomic statement suitable for validation and citation |
| Node | `Definition` | `definitionId`, `text`, `reviewState` | Special case of canonical explanatory text |
| Node | `SourceDoc` | `sourceId`, `uriRef`, `contentHash`, `mimeType`, `accessClass` | Immutable source-level reference |
| Node | `SourceSpan` | `spanId`, `sourceId`, `byteStart`, `byteEnd`, `headingPath`, `textHash` | The exact passage supporting a claim |
| Edge | `MENTIONS` | `section`, `confidence` | Page or chunk mentions entity |
| Edge | `DEFINES` | `priority`, `reviewState` | Page or definition defines entity |
| Edge | `ABOUT` | `predicate`, `confidence` | Claim is about entity |
| Edge | `SUPPORTS` | `reason`, `confidence` | One claim or entity supports another |
| Edge | `CONTRADICTS` | `basis`, `confidence` | Conflict surface |
| Edge | `HAS_ALIAS` | `source` | Entity to alias mapping |
| Edge | `HAS_SOURCE` | `sourceType` | Claim or definition to source span |
| Edge | `DERIVED_FROM` | `extractorVersion`, `runId` | Extraction lineage |
| Edge | `SAME_AS` | `authority`, `externalId` | External reconciliation |

In an RDF implementation, **Claim** will often map to a statement resource or reified structure rather than a single bare triple, because references, qualifiers, and ranks/states do not fit comfortably into a naive subject-predicate-object-only view. That is one of the most important modeling lessons from Wikibase. citeturn11view10turn17view0

The ingestion pipeline should be deterministic before it is clever. Frontmatter and explicit metadata should always outrank LLM guesses. The LLM should enrich the graph, not overrule canonical editorial decisions.

```mermaid
flowchart TD
    A[Changed page or source file] --> B[Parse YAML frontmatter]
    B --> C[Split by headings and sections]
    C --> D[Normalize titles, aliases, IDs]
    D --> E[Schema-constrained entity and relation extraction]
    E --> F[Build claims]
    F --> G[Attach source spans and content hashes]
    G --> H[Write graph records]
    G --> I[Write embeddings]
    H --> J[Run QA checks]
    I --> J
    J --> K[Mark proposed or reviewed]
```

Why This File Exists

This is a memory-system evidence file from llmwikis.org. It is shown here because AIWikis.org is demonstrating the real source files that make the UAIX / LLM Wiki memory system work, not only summarizing those systems after the fact.

Role

This file is memory-system evidence. It records source history, archive transfer, intake disposition, or another piece of provenance that should be retrievable without becoming an unsupported public claim.

Structure

The file is structured around these visible headings: Knowledge graphs for LLM-powered wikis; Executive summary; Goals and graph model choices; Architecture, schema, and ingestion; Storage options and starter stacks; Retrieval and LLM integration; Governance, evaluation, scale, and security; Roadmap, MVP checklist, and primary sources. Those headings are retrieval anchors: a crawler or LLM can decide whether the file is relevant before reading every line.

Prompt-Size And Retrieval Benefit

Keeping this material in a separate file reduces prompt pressure because an agent can load this exact unit only when its role, source site, category, or hash is relevant. The surrounding index pages point to it, while this page preserves the full content for audit and exact recall.

How To Use It

• Humans should read the metadata first, then inspect the raw content when they need exact wording or provenance.
• LLMs and agents should use the source site, category, hash, headings, and related files to decide whether this file belongs in the active prompt.
• Crawlers should treat the AIWikis page as transparent evidence and follow the source URL/source reference for authority boundaries.
• Future maintainers should regenerate this page whenever the source hash changes, then review the explanation if the role or structure changed.

Update Requirements

When this source file changes, update the raw source layer, normalized source layer, hash history, this rendered page, generated explanation, source-file inventory, changed-files report, and any source-section index that links to it.

Related Pages

• Source overview
• Site file index
• Site report index
• UAI system index
• Source provenance
• Site directory
• Organization reports

Provenance And History

• Current observation: 2026-06-22T01:56:21.9510185Z
• Source origin: current-source-workspace
• Retrieval method: local-source-workspace
• Duplicate group: sfg-874 (primary)
• Historical hash records are stored in data/hashes/source-file-history.jsonl.

Machine-Readable Metadata

{
    "title":  "Knowledge Graphs For LLM Powered Wikis",
    "source_site":  "llmwikis.org",
    "source_url":  "https://llmwikis.org/",
    "canonical_url":  "https://aiwikis.org/llmwikis/files/raw-system-archives-llmwikis-agent-file-handoff-retired-source-archive-2-b573a14a/",
    "source_reference":  "raw/system-archives/llmwikis/agent-file-handoff/retired-source-archive-2026-06-13/2026-05-06/Improvement/knowledge-graphs/Knowledge graphs for LLM-powered wikis.md",
    "file_type":  "md",
    "content_category":  "memory-file",
    "content_hash":  "sha256:b573a14a8dcdbe37f8e44cdf85070b8e240918158b3234e7d960877116a4f98c",
    "last_fetched":  "2026-06-22T01:56:21.9510185Z",
    "last_changed":  "2026-05-06T15:24:03.6039478Z",
    "import_status":  "unchanged",
    "duplicate_group_id":  "sfg-874",
    "duplicate_role":  "primary",
    "related_files":  [

                      ],
    "generated_explanation":  true,
    "explanation_last_generated":  "2026-06-22T01:56:21.9510185Z"
}