LLM Wikis And Hierarchical Structure

An effective “LLM Wiki” is not just a wiki with embeddings attached. The strongest designs combine three kinds of structure: a human-editable page tree, a machine-readable semantic layer, and a retrieval layer that ca...

Metadata

Field	Value
Source site	llmwikis.org
Source URL	https://llmwikis.org/
Canonical AIWikis URL	https://aiwikis.org/llmwikis/files/raw-system-archives-llmwikis-2026-05-11-improvement-handoff-recovery-llm-2c75d217/
Source reference	raw/system-archives/llmwikis/2026-05-11-improvement-handoff-recovery/LLM Wikis and Hierarchical Structure.md
File type	md
Content category	memory-file
Last fetched	2026-06-22T01:56:21.9510185Z
Last changed	2026-05-11T13:32:14.0987092Z
Content hash	sha256:2c75d217d0c8caadef360100b13e1327e73392c16370a9d440c93ac49e42d647
Import status	unchanged
Raw source layer	data/sources/llmwikis/raw-system-archives-llmwikis-2026-05-11-improvement-handoff-recovery-llm-wikis-and-hierarchical-2c75d217d0c8.md
Normalized source layer	data/normalized/llmwikis/raw-system-archives-llmwikis-2026-05-11-improvement-handoff-recovery-llm-wikis-and-hierarchical-2c75d217d0c8.txt

Current File Content

Structure Preview

• LLM Wikis and Hierarchical Structure
• Executive summary
• Survey of platforms and LLM knowledge bases
• Literature on hierarchical knowledge representation
• Lessons from Wikipedia and related wiki structures
• Candidate schemas for an LLM Wiki
• Implementation guidance
• Migration strategies
• Prioritized references and limitations

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: 41575
• Preview characters: 11997

# LLM Wikis and Hierarchical Structure

## Executive summary

An effective “LLM Wiki” is not just a wiki with embeddings attached. The strongest designs combine three kinds of structure: a human-editable page tree, a machine-readable semantic layer, and a retrieval layer that can answer both local fact questions and corpus-level synthesis questions. Existing systems split across these concerns. MediaWiki/Wikipedia and Notion are strong at editorial structure and reuse; Obsidian and Roam are strong at associative linking; Wikidata is strong at typed claims and provenance; and retrieval-first systems such as Kagi, Perplexity, LangChain docs, and LlamaIndex emphasize query-time access, citations, and programmatic interfaces rather than community-maintained canonical knowledge. citeturn24view0turn24view5turn24view6turn24view8turn24view10turn23view1turn23view2turn23view4turn23view7turn15search0turn23view8turn23view9turn29view3turn23view10turn23view11turn23view13turn26view0turn19search14

The research literature points in the same direction. Retrieval-Augmented Generation established the value of combining parametric models with external non-parametric memory; RAPTOR showed that tree-organized summaries improve retrieval on long, complex documents; and GraphRAG showed that graph extraction plus community hierarchies can outperform plain snippet retrieval on “global” corpus questions. Older semantic-web work also remains directly relevant: Gruber’s ontology framing, OWL’s typed classes and properties, and SKOS’s lightweight taxonomy model explain why explicit hierarchy and relation types still matter for LLM retrieval. Vector search remains essential for speed and recall, but it is best treated as one layer among several rather than the whole system. citeturn25view0turn25view1turn25view2turn25view3turn33view0turn25view4turn25view5turn25view6turn25view7

The report’s main recommendation is therefore a layered architecture: use a **document-first hierarchy as the system of record**, add a **claim or concept sidecar** for typed semantics and provenance, and optionally add a **summary/community layer** for corpus-level or exploratory questions. This combination best matches the strengths seen in Wikipedia/Wikidata, the flexibility of modern knowledge-base tools, and the latency profile of ANN vector indexes such as HNSW. That recommendation is an inference from both platform behavior and the literature, rather than a claim that any single vendor already delivers the full pattern out of the box. citeturn31view0turn24view9turn24view3turn24view4turn31view2turn25view3turn25view6turn25view7turn25view9

## Survey of platforms and LLM knowledge bases

The current landscape is easier to reason about if it is divided into four families: collaborative wikis, structured knowledge bases, local-first note graphs, and retrieval-first LLM knowledge interfaces. Those families are not interchangeable. Some are optimized for authoring and governance; some for personal knowledge management; and some for retrieval quality, citations, and API access. citeturn24view0turn24view5turn24view10turn23view7turn15search0turn23view8turn29view3turn27view1turn26view0

| Platform | Core data model | Linking, tagging, and metadata | Hierarchy model | What it suggests for an LLM Wiki | Primary sources |
|---|---|---|---|---|---|
| **MediaWiki and Wikipedia** | Page-centric documents in namespaces; pages can use alternate content models beyond wikitext; content reuse is driven by templates and transclusion. | Internal wikilinks; categories; template parameters; infoboxes; section anchors and TOC. | Strong within-page hierarchy through headings; looser cross-page category graph. Categories are useful but not a strict tree. | Excellent reference model for collaborative authoring, reusable templates, and stable navigation; weaker as a typed fact store unless paired with Wikibase/Wikidata. | citeturn24view0turn24view5turn24view6turn24view7turn24view8turn24view9turn31view0 |
| **Wikibase and Wikidata** | Items, properties, and statements; statements can be refined with qualifiers and references; items have labels, descriptions, aliases, and stable QIDs. | Symbolic links through properties and sitelinks; rich provenance through references; multilingual aliasing. | Not a page tree first; effectively a typed entity graph with stable identifiers. | Best-in-class pattern for claim-level semantics, provenance, multilingual aliasing, and machine-readable identifiers. | citeturn24view2turn24view3turn24view4turn31view2turn31view3turn31view4 |
| **Notion** | Pages, blocks, databases, and data sources; database rows are pages whose property values must conform to a parent schema. | Backlinks are created automatically from page mentions; relation properties link items across databases; database properties support filtering, sorting, and search. | Strong page/subpage nesting; strong schema inside databases; light graph via backlinks and relations. | A strong model for combining editorial pages with structured collections and permissions, but relations are lighter than a full ontology. | citeturn24view10turn24view11turn24view12turn23view1turn23view2turn23view3turn24view13 |
| **Obsidian** | Local Markdown files plus structured note properties; Bases turns notes into database-like views over file properties. | Internal links, heading links, backlinks, tags, YAML-style properties, and file-wide property views. | File/folder hierarchy plus heading hierarchy; graph-style linking overlays local structure. | Strong example of local-first authoring with user-controlled metadata and structure-preserving links; good inspiration for parent-child chunking and property-driven retrieval. | citeturn23view0turn23view4turn23view5turn23view6turn23view7 |
| **Roam Research** | Public positioning emphasizes bulleted documents and graph-database-like connected thought. | Public materials emphasize associative connectivity more than a formal public schema. | Graph-first note model; explicit public documentation of a formal schema is limited. | Useful as a reminder that link density and backlinks matter, but less suitable as a governance template for a shared LLM Wiki unless a stronger schema is added. | citeturn15search0 |
| **Kagi Assistant and Search** | Query-centric threads plus optional web-grounded retrieval; assistants can use search results and file context. | Source references in Quick Answer; custom assistants; optional web access; search Lenses and personalized results tune source scope and ranking. | Minimal author-side hierarchy; organization is mostly by thread and source selection. | Strong retrieval UX ideas: citations, source scoping, thread continuity, and domain-focused retrieval. Weak as a canonical authored knowledge base. | citeturn23view8turn23view9turn29view4turn29view5turn29view6 |
| **Perplexity** | Retrieval APIs for ranked web results, citations, embeddings, and media-aware reasoning. | Ranked results, domain/language/region filtering, extracted content, citations in API responses, document-aware contextualized embeddings, media attachments. | Query-time document/chunk structure rather than a community-authored hierarchy. | Strong evidence that modern LLM retrieval benefits from source controls, citations, and document-aware embeddings, but it is retrieval infrastructure rather than a wiki governance model. | citeturn29view3turn23view10turn23view11turn29view2 |
| **LangChain docs and framework** | Programmatic document corpus exposed through llms.txt and MCP; framework organizes retrieval into loaders, splitters, vector stores, retrievers, and agents. | Structure-aware splitting by headers; loaders normalize external content into a Document interface; unified vector-store interface; docs are consumable through MCP. | Strong documentation tree plus structure-aware chunking conventions. | Good model for AI-native documentation distribution and for separating ingestion, storage, retrieval, and orchestration concerns. | citeturn23view13turn27view1turn25view12turn25view13turn27view0turn27view2 |
| **LlamaIndex framework and docs** | Context-augmentation framework with connectors, indexes, retrievers, query engines, rerankers, storage, and citation modules; nodes carry metadata and relationships. | Graph stores, vector stores, citation query engine, node abstractions, multi-modal use cases. | Strong conceptual layering rather than a single wiki hierarchy; supports hierarchical and graph retrieval patterns. | Excellent reference for composable retrieval architecture, especially if an LLM Wiki needs sidecar graphs, citation-aware response generation, or multi-modal expansion. | citeturn26view0turn19search14turn18search3turn26view5turn26view6turn26view7 |

Two cross-cutting patterns stand out. First, **authoring systems and retrieval systems optimize different things**: MediaWiki, Notion, and Obsidian are strong at durable editing and information organization, while Kagi, Perplexity, LangChain, and LlamaIndex are stronger at query routing, source control, and programmatic retrieval. Second, systems with the best long-term maintainability tend to separate **content**, **metadata**, and **links** instead of flattening everything into undifferentiated chunks. That pattern shows up in Notion’s page/data-source schema, Obsidian’s note/properties split, Wikidata’s item/statement/references model, and LangChain/LlamaIndex’s loader-document-retriever abstractions. citeturn24view12turn23view0turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn23view7turn24view3turn24view3turn24view3turn24view3turn24view3turn31view2turn25view13turn26view0

## Literature on hierarchical knowledge representation

The literature supports a layered view of external knowledge for LLMs. Ontologies define explicit vocabularies and constraints; taxonomies and thesauri organize concepts into broader, narrower, and related terms; knowledge graphs represent entities and relations; vector indexes supply fast approximate similarity; and newer RAG methods add higher-order structure such as summary trees or graph-derived communities. Each layer solves a different failure mode of flat retrieval. citeturn33view0turn25view4turn25view5turn25view8turn25view6turn25view7turn25view1turn25view3

| Representation layer | What it contributes | Why it matters for LLM retrieval | Canonical sources |
|---|---|---|---|
| **Ontology** | Explicit classes, relations, functions, and constraints over a shared domain vocabulary. | Improves disambiguation, type safety, schema governance, and query interpretation; especially useful when the corpus represents domain facts rather than just prose. | Gruber’s ontology paper and OWL 2. citeturn33view0turn25view4 |
| **Taxonomy / thesaurus / KOS** | Broader-narrower-related concept structures with a lightweight migration path from existing vocabularies. | Useful for navigation, faceting, concept expansion, and soft hierarchy without requiring a full logical ontology. | SKOS Reference. citeturn25view5 |
| **Knowledge graph** | Graph of entities, properties, and relations, often with schema and context. | Supports multi-hop reasoning, entity-centric QA, and provenance-rich traversal that flat chunk retrieval often misses. | Knowledge Graphs survey; Wikidata/Wikibase model. citeturn25view8turn24view2turn24view3 |

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: LLM Wikis and Hierarchical Structure; Executive summary; Survey of platforms and LLM knowledge bases; Literature on hierarchical knowledge representation; Lessons from Wikipedia and related wiki structures; Candidate schemas for an LLM Wiki; Implementation guidance; Migration strategies. 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-225 (primary)
• Historical hash records are stored in data/hashes/source-file-history.jsonl.

Machine-Readable Metadata

{
    "title":  "LLM Wikis And Hierarchical Structure",
    "source_site":  "llmwikis.org",
    "source_url":  "https://llmwikis.org/",
    "canonical_url":  "https://aiwikis.org/llmwikis/files/raw-system-archives-llmwikis-2026-05-11-improvement-handoff-recovery-llm-2c75d217/",
    "source_reference":  "raw/system-archives/llmwikis/2026-05-11-improvement-handoff-recovery/LLM Wikis and Hierarchical Structure.md",
    "file_type":  "md",
    "content_category":  "memory-file",
    "content_hash":  "sha256:2c75d217d0c8caadef360100b13e1327e73392c16370a9d440c93ac49e42d647",
    "last_fetched":  "2026-06-22T01:56:21.9510185Z",
    "last_changed":  "2026-05-11T13:32:14.0987092Z",
    "import_status":  "unchanged",
    "duplicate_group_id":  "sfg-225",
    "duplicate_role":  "primary",
    "related_files":  [

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