LLM Wikis and Hierarchical Structure

Full report

On this page

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.

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.

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.

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.

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.

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.

A few implications are especially relevant for LLM Wikis. First, if the wiki must answer global questions such as “what are the main themes across this space?” or “how do these systems compare across teams?”, plain top-k vector retrieval is often the wrong primitive; GraphRAG explicitly frames this as a query-focused summarization problem rather than a local retrieval problem, and RAPTOR makes the same point from the angle of tree-organized summaries.

Second, if the wiki must answer precision questions with provenance such as “what is the author / owner / status / version / policy that governs X?”, symbolic structure helps. Wikidata’s statement-qualifier-reference model shows how typed claims and sources reduce ambiguity, while ontology and taxonomy standards explain how to keep those structures interoperable rather than hard-coded to one tool.

Third, hybrid retrieval is increasingly the operational default. Production systems such as Weaviate combine BM25F keyword search and vector search with configurable fusion and weighting, while Neo4j exposes HNSW-based vector indexing directly inside a graph database. LangChain’s retriever ecosystem also treats lexical, vector, and permission-aware filtering as composable concerns rather than mutually exclusive choices.

Lessons from Wikipedia and related wiki structures

Wikipedia and the broader Wikimedia stack offer the richest real-world example of knowledge that is simultaneously navigable by humans and legible to machines. The most important lesson is not “copy Wikipedia’s category tree.” It is “separate different kinds of structure so they can each do their job well.” Categories, infoboxes, headings, redirects, templates, and Wikidata statements all express different kinds of organization.

From these patterns, the most durable design rules are straightforward. Use one structure for navigation, another for semantic facts, and another for retrieval. Keep provenance attached to claims, not just to whole pages. Retain heading paths and section anchors all the way into the index. And make maintenance metadata opt-in or hidden by default so the retrieval layer can use it without polluting the reader experience. Those lessons map unusually well from Wikimedia to LLM systems because they address the same basic problem: large, changing corpora that must be understandable by both humans and machines.

Candidate schemas for an LLM Wiki

The four candidate schemas below are not mutually exclusive. In practice, the best production design is often a document-first primary schema with one or two secondary overlays. The main choice is therefore not “which one is correct?” but “which one should be primary, and which ones should be sidecars?” That framing is consistent with the way vector indexes, graph layers, and summary layers are combined in modern RAG systems.

flowchart LR
    Q[User query] --> I{Intent and policy router}
    I --> K[Keyword and metadata retrieval]
    I --> V[Vector ANN retrieval]
    I --> G[Graph or taxonomy expansion]
    K --> R[Reranker]
    V --> R
    G --> R
    R --> P[Parent section and page expansion]
    P --> C[Citation and ACL filter]
    C --> A[Answer with provenance]

A document tree with semantic overlays is the best general-purpose primary schema. It maps cleanly to how MediaWiki, Notion, Obsidian, and most documentation systems are authored. It makes versioning, ACL inheritance, and incremental updates relatively cheap because most edits affect only one page or section. The semantic overlay can stay lightweight at first: typed tags, aliases, redirects, entity mentions, and citation metadata are enough to support strong hybrid retrieval without forcing the whole corpus into a graph-first authoring model. This schema is the safest default if the wiki will have many editors and frequent updates.

An entity and claim graph should usually be a sidecar rather than the only store. It excels when the corpus contains many recurring entities, repeated facts, state changes, and policy-like assertions that benefit from qualifiers and references. In other words, it is ideal for product specs, internal policies, regulated knowledge, research catalogs, or any domain where the same entity appears across many pages and freshness matters. The trade-off is authoring cost: graph extraction, claim normalization, and source attachment are all more expensive than storing sections and chunks. That cost is justified only when the domain actually needs typed claims.

A taxonomy and concept lattice is valuable when the main retrieval problem is not facts but scope control. SKOS-style broader/narrower/related concept graphs are especially effective for large workspaces where users need help narrowing from vague topics to specific subtopics, or where several overlapping vocabularies need to coexist. This schema is lighter than a full ontology or claim graph, easier to govern, and a strong migration target for flat wikis because existing category systems can often be ported into it with relatively low friction.

A summary and community graph is the right overlay for “what does this corpus say overall?” questions. It is inspired by RAPTOR and GraphRAG and is especially useful for long reports, meeting archives, research collections, or company-wide documentation sets where the answer may need to cross many pages and abstraction levels. The downside is operational: summaries age, batch jobs add cost, and the governance model becomes harder because every summary node is derived rather than directly authored. This overlay is worth adding after the base document tree is stable, not before.

These scores are relative design inferences, not benchmark measurements. They are grounded in the fact that ANN indexes such as HNSW and systems like Faiss are built for low-latency approximate similarity, while graph-heavy and summary-heavy methods add extraction, traversal, or regeneration steps that improve some query classes but increase operational cost.

If a single recommendation is needed, the strongest choice is a composite of the first schema plus selective pieces of the second and fourth: use the document tree as the source of truth, add a claim graph only for high-value entities and facts, and add summary communities only for collections where users routinely ask global questions. That mix preserves maintainability while still addressing the known failure modes of flat vector-only retrieval.

Implementation guidance

No single tech stack is required for an LLM Wiki. The durable design choice is to keep authoring storage, semantic storage, and retrieval indexes loosely coupled. In practice, that means choosing one durable system of record for pages and metadata, then adding retrieval and graph indexes that can be rebuilt or partially rebuilt as needed. This reflects the separation of concerns visible in LangChain and LlamaIndex, and it also aligns with how Wikipedia separates page content from Wikidata-style structured facts.

For indexing, the safest baseline is three parallel indexes. The first is a lexical index over titles, aliases, headings, and chunk text for exact matching and sparse relevance. The second is a vector index over chunks, summaries, and optionally entities for semantic recall. The third is a symbolic index over parent paths, section paths, concept IDs, entity IDs, time ranges, and ACL attributes. Weaviate’s hybrid model makes the vector-keyword combination explicit, and LangChain’s retriever abstractions plus permission-aware wrappers show how metadata and security filters can be layered without rewriting the vector layer itself.

For chunking, structural boundaries should come first. LangChain’s markdown-header splitter explicitly argues that chunking should “honor the structure of the document itself,” and Perplexity’s contextualized embeddings similarly assume that chunks from a document should preserve document order and shared context. In practice, that means chunking by page → section → passage, not by arbitrary token windows alone. Tables, infoboxes, and media should be lifted into their own child nodes with modality-appropriate embeddings and back-pointers to the parent page and section.

A practical metadata schema should carry at least these fields: immutable node ID; node type; page title; aliases; parent path; heading path; source URI; time stamps; authorship; status; tags or concepts; entity IDs; ACL attributes; and provenance pointers down to chunk or span level. Wikidata’s statement-qualifier-reference model is a strong guide for factual metadata, while Notion, Obsidian, and LangChain/LlamaIndex show that structured properties should be first-class rather than squeezed into ad hoc text markup.

The API surface should mirror those separations. A clean pattern is: one set of write APIs for pages and assets; one set of enrichment APIs for links, entities, and claims; and one set of query APIs for hybrid search, neighborhood traversal, and citation-aware answer assembly. LangChain’s Document and vector-store interfaces, plus Notion’s page/data-source split, are good examples of why ingestion and storage contracts should be explicit.

A compact example schema for a primary node object is below. It is intentionally broad enough to support page nodes, section nodes, chunk nodes, and structured sidecars.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "KnowledgeNode",
  "type": "object",
  "required": [
    "id",
    "type",
    "title",
    "path",
    "version",
    "acl",
    "provenance",
    "updated_at"
  ],
  "properties": {
    "id": {
      "type": "string",
      "description": "Immutable node identifier"
    },
    "type": {
      "type": "string",
      "enum": [
        "space",
        "page",
        "section",
        "chunk",
        "entity",
        "claim",
        "summary",
        "asset",
        "concept"
      ]
    },
    "title": {
      "type": "string"
    },
    "aliases": {
      "type": "array",
      "items": { "type": "string" }
    },
    "path": {
      "type": "array",
      "items": { "type": "string" },
      "description": "Ancestor IDs from root to self"
    },
    "heading_path": {
      "type": "array",
      "items": { "type": "string" }
    },
    "body": {
      "type": "string"
    },
    "metadata": {
      "type": "object",
      "properties": {
        "language": { "type": "string" },
        "status": {
          "type": "string",
          "enum": ["draft", "published", "archived", "deprecated"]
        },
        "tags": {
          "type": "array",
          "items": { "type": "string" }
        },
        "concept_ids": {
          "type": "array",
          "items": { "type": "string" }
        },
        "entity_ids": {
          "type": "array",
          "items": { "type": "string" }
        },
        "modality": {
          "type": "string",
          "enum": ["text", "image", "table", "audio", "video", "mixed"]
        }
      },
      "additionalProperties": true
    },
    "version": {
      "type": "object",
      "required": ["revision_id", "parent_revision_id"],
      "properties": {
        "revision_id": { "type": "string" },
        "parent_revision_id": { "type": ["string", "null"] },
        "valid_from": { "type": ["string", "null"], "format": "date-time" },
        "valid_to": { "type": ["string", "null"], "format": "date-time" }
      }
    },
    "acl": {
      "type": "object",
      "required": ["visibility", "principals"],
      "properties": {
        "visibility": {
          "type": "string",
          "enum": ["public", "internal", "restricted", "confidential"]
        },
        "principals": {
          "type": "array",
          "items": { "type": "string" }
        },
        "inherit": { "type": "boolean" }
      }
    },
    "embeddings": {
      "type": "array",
      "items": {
        "type": "object",
        "required": ["space", "model", "vector_ref"],
        "properties": {
          "space": { "type": "string" },
          "model": { "type": "string" },
          "vector_ref": { "type": "string" }
        }
      }
    },
    "provenance": {
      "type": "object",
      "required": ["source_uri"],
      "properties": {
        "source_uri": { "type": "string" },
        "source_span": { "type": ["string", "null"] },
        "extracted_by": { "type": ["string", "null"] },
        "confidence": { "type": ["number", "null"] }
      }
    },
    "updated_at": {
      "type": "string",
      "format": "date-time"
    }
  }
}

That schema operationalizes the main design lesson of this report: keep structure, semantics, security, and provenance explicit rather than implicit. It is deliberately compatible with Wikidata-style claim provenance, Notion-style properties, Obsidian-style local metadata, and chunk-aware retrieval frameworks such as LangChain and LlamaIndex.

A corresponding ER model for a hybrid document-plus-claim implementation could look like this:

erDiagram
    SPACE ||--o{ PAGE : contains
    PAGE ||--o{ PAGE_VERSION : has
    PAGE ||--o{ SECTION : contains
    SECTION ||--o{ CHUNK : contains
    PAGE ||--o{ ASSET : embeds
    PAGE }o--|| ACL_POLICY : governed_by
    CHUNK ||--o{ CHUNK_VECTOR : indexed_as
    CHUNK }o--o{ ENTITY : mentions
    ENTITY ||--o{ CLAIM : has
    CLAIM }o--|| SOURCE : backed_by
    PAGE ||--o{ RELATION : source_of

Migration strategies

Migration should preserve two things above all: stable identity and recoverable hierarchy. Everything else can be rebuilt. That principle is consistent with Wikidata’s use of immutable item IDs plus mutable labels and aliases, and with the way SKOS positions itself as a low-cost migration path for existing knowledge organization systems.

For a flat wiki with page-level search but little structure, the shortest safe path is to: inventory page titles, redirects, categories, templates, and assets; mint immutable IDs for pages and sections; preserve heading paths; convert categories into a governed concept vocabulary rather than loose tags; and add embeddings only after the page/section model is stable. If the source resembles MediaWiki, reuse categories, templates, infoboxes, and section anchors rather than discarding them during ingestion.

For a vector-only store, the main challenge is that much of the lost authorial structure must be reconstructed. The safest order is to group chunks back into documents by source metadata, infer section boundaries where possible, attach parent-child relationships, then enrich with aliases, concepts, entities, and ACLs. Only after the hierarchy exists should you add graph edges or summary layers. LangChain’s retrieval guidance is helpful here because it explicitly notes that if you already have a knowledge base, you do not need to rebuild it from scratch; rather, you layer retrieval capabilities over existing data contracts.

A pragmatic rollout pattern is dual-running: keep the old wiki or old vector index live, build the new hierarchy and indexes in parallel, compare retrieval traces and citation quality, then cut over query paths gradually. Permission-aware retrievers or ACL filters should be wired in before user-facing cutover, not after, because retrofitting security into search results is much harder than indexing with security metadata from the start.

timeline
    title Suggested migration phases
    Inventory and identity : Crawl pages, assets, redirects, categories, and existing vector metadata
    Structural normalization : Mint immutable IDs; recover page, section, and chunk hierarchy
    Metadata enrichment : Add aliases, concepts, entities, provenance, and ACL attributes
    Dual indexing : Build lexical, vector, and optional graph indexes in parallel
    Shadow evaluation : Compare recall, latency, citations, and access-control behavior
    Progressive cutover : Route selected query classes to the new stack
    Cleanup and governance : Deprecate old indexes; add vocabulary and review workflows

Prioritized references and limitations

The sources below are the ones I would prioritize if you were actually implementing or reviewing an LLM Wiki architecture. They are weighted toward official documentation and original papers.

There are a few limitations worth stating plainly. Roam’s publicly available formal schema documentation is sparse, so its treatment here is intentionally high-level. Kagi and Perplexity are better understood as retrieval interfaces and answer engines than as canonical collaborative wiki backends, so the comparison focuses on their retrieval and citation patterns rather than their internal storage models. And because product documentation changes faster than academic papers, the platform portions of this survey should be treated as current snapshots rather than permanent architectural guarantees.