LLM Wikis And Hierarchical Structure - Source Excerpt 01 - LLM Wikis and Hierarchical Structure

Back to LLM Wikis And Hierarchical Structure

Summary

This source excerpt begins near LLM Wikis and Hierarchical Structure and preserves the surrounding evidence from Wiki.FFTAC.org/agent-file-handoff/Archive/2026-05-11-improvement-concept-layer/LLM Wikis and Hierarchical Structure.md.

**Source path:** Wiki.FFTAC.org/agent-file-handoff/Archive/2026-05-11-improvement-concept-layer/LLM Wikis and Hierarchical Structure.md

# 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 |