AI FORWARD

Knowledge Systems

Open-Source Frameworks for an LLM Wiki

A comparison of Graphify, GraphRAG, Graphiti, LightRAG, KAG, LlamaIndex, LangChain, and Haystack against the idea of a persistent, self-maintaining wiki that compounds knowledge instead of re-retrieving it every time.

Created June 5, 2026 · Last updated June 5, 2026 · Research checked June 5, 2026 · By Forward IC

TLDR

Standard RAG re-discovers knowledge from scratch on every query. The LLM Wiki pattern compiles sources once into persistent, interlinked pages and updates them incrementally. The decisive differentiator in 2026 is temporal capability: Graphiti's bi-temporal model (when an event happened vs. when it was recorded) handles changing facts for live agents; GraphRAG handles batch synthesis over static corpora; LightRAG offers a lower-overhead hybrid. Of the active open-source projects, only synto handles all four properties of a living wiki: incremental updates, entity reconciliation, contradiction flagging, and automatic backlink maintenance. The format winner: Obsidian-compatible Markdown with [[wikilinks]] and YAML frontmatter is the storage standard every active project targets. The gap is not in transcription or ingestion — it is in reconciling new content with existing state without duplication. Most frameworks handle ingest; very few handle maintenance. IBM Technology's "Is RAG Still Needed?" (796K views) offers the clearest public framing of this shift.

Andrej Karpathy's LLM Wiki pattern is not ordinary RAG. Standard RAG retrieves raw chunks at question time. The LLM Wiki adds a maintained middle layer: raw sources remain immutable, while an LLM continuously updates a structured markdown wiki with entity pages, topic summaries, contradictions, cross-links, an index, and an append-only log. The key claim is compounding: knowledge should be synthesized once, kept current, and reused.

That distinction matters when evaluating frameworks. Many open-source projects are excellent retrieval engines, graph indexes, or agent orchestrators, but only some approximate a self-evolving wiki. The best architecture for a business often combines several layers: a wiki repository for durable synthesis, a graph or vector layer for retrieval, and an agent workflow that ingests sources, proposes updates, and asks humans to approve high-risk changes.

LLM Wiki Target Architecture
Raw sources Documents, transcripts, tickets, papers, diagrams, code, and images. Immutable source of truth. LLM maintainer Reads sources, detects entities, updates pages, marks contradictions, and files analysis. Wiki layer Markdown pages, links, index, log, summaries, schemas, and review records. Retrieval layer Searches wiki and sources with BM25, vector, graph, hybrid, or reranking methods. Business answers Cited reports, decisions, comparisons, support answers, roadmap analysis, and audits.
The wiki is not just an interface. It is a durable artifact that changes when new evidence arrives.

Research Baseline

Retrieval as non-parametric memory is well established. Google's REALM trained a retriever for open-domain QA. Meta's RAG combined parametric model memory with retrieved documents. DeepMind's RETRO showed that retrieval from a very large database can substitute for some parameter scaling. OpenAI's WebGPT showed the operational value of search, browsing, and citations for factual long-form answers.

Graph methods push beyond nearest-neighbor chunks. Microsoft's GraphRAG extracts entities and relationships, clusters them, and generates community summaries so users can ask global questions across a corpus. Graphiti/Zep's temporal knowledge graph architecture focuses on evolving agent memory where facts change over time. LightRAG argues for a lighter graph-plus-vector retrieval design with incremental updates. KAG adds logical-form-guided reasoning for professional domains where factual consistency matters.

Framework Map

Capability Heatmap
Framework Ingest Graph Temporal Wiki Diffs Graphify Strong for code/docs multimodal ingest. NetworkX + Leiden structure. Not primary focus. Reports help, but no full wiki maintainer. Graphiti Episodes from text/JSON/messages. Temporal entity/fact graph. Validity and invalidation model. Needs page writer. GraphRAG Corpus indexing pipeline. Communities and summaries. Mostly static index. Summaries can seed pages. LightRAG Incremental update focus. Graph + vector retrieval. Freshness through incremental updates. Needs editorial layer.
The heatmap shows why no single framework is the whole product: each contributes a different mechanism.
Framework Best fit LLM Wiki fit Main gap
Graphify Codebases, docs, diagrams, papers, multimodal repository understanding. Strong for graphifying a corpus and reducing token load for coding assistants. More code/repo graph than general self-maintaining markdown wiki.
Microsoft GraphRAG Large corpora requiring global summaries and relationship-aware retrieval. Strong synthesis layer, especially community summaries and global questions. Expensive indexing; not a human-readable wiki maintenance workflow by default.
Graphiti / Zep Agent memory over changing entities, relationships, and timelines. Strong temporal update model; close to "kept current" requirement. Memory graph is not the same as a curated wiki users browse and edit.
LightRAG Fast graph-enhanced RAG with incremental updates. Good retrieval substrate for a wiki that must grow frequently. Does not itself define markdown pages, logs, or editorial governance.
KAG / OpenSPG Professional domains needing schema, logic, and high-fidelity reasoning. Strong for regulated or domain-specific knowledge bases. Higher modeling burden; less suited to casual personal wiki workflows.
LlamaIndex Data connectors, indexing, retrieval, agents, document workflows. Flexible foundation for ingestion and query over wiki/source layers. Self-evolving wiki behavior must be implemented as application logic.
LangChain / LangGraph Agent workflows, tool orchestration, stateful graphs, routing. Good workflow engine for LLM wiki maintenance operations. Not a knowledge-base product by itself; retrieval quality depends on components.
Haystack Production RAG pipelines with explicit typed components. Good for controlled enterprise retrieval and evaluation pipelines. Less focused on evolving wiki artifacts and graph-native synthesis.

Active Open-Source Implementations (June 2026)

Beyond the framework layer, a set of developer-focused projects implement the LLM Wiki pattern directly. Signal-ranked by community traction and production-readiness:

Project Update model Temporal Storage Best for
Graphiti (getzep) Streaming incremental Bi-temporal ✓ Neo4j, FalkorDB, Kuzu, Neptune Live agents, long-running sessions, changing facts
kytmanov/synto File-drop via Ollama None Local Obsidian vault 100% private, offline; all 4 living-wiki properties
atomicstrata/llm-wiki-compiler CLI batch None Markdown output Developer-oriented: raw sources in, interlinked wiki out
nashsu/llm_wiki Desktop app file-drop None Local HTTP API + Markdown Non-developers; lowest barrier to entry
ar9av/obsidian-wiki Multi-agent parallel None Obsidian vault Large document sets processed in parallel
topoteretes/cognee Streaming Partial Self-hosted knowledge graph Cross-session agent memory beyond wiki scope

Two patterns mark the production-grade tier. Temporal capability: Graphiti's bi-temporal semantics — tracking both when an event happened and when it was recorded — is the only approach that handles facts that change over time. Tools without temporal support silently accumulate contradictions. Zero-LLM-call graph construction: some implementations extract entity references directly from [[wikilink]] syntax with no LLM inference, reserving model calls for reasoning rather than indexing and dramatically reducing per-update cost.

How Much Of The LLM Wiki Is Implemented?

Coverage Against The Core Idea
Graphify Implements corpus graph + assistant skill. Best when the "wiki" is a codebase knowledge graph. GraphRAG / LightRAG Implements graph-indexed synthesis and retrieval. Needs a wiki writer on top. Graphiti / KAG Implements evolving graph memory or logical domain reasoning. Needs human-readable pages. LlamaIndex / LangGraph / Haystack Implements plumbing: ingestion, routing, state, retrieval, eval. The wiki pattern is your app.

Scale, Cost, And Token Consumption

Token economics differ sharply. Vector RAG spends most tokens at query time: retrieve chunks, stuff context, answer, repeat. The LLM Wiki spends more tokens at ingest time: read a source, update multiple pages, revise cross-links, and log changes. GraphRAG-style systems add an expensive indexing phase because the model must extract entities, relationships, communities, and summaries. The payoff is lower repeated synthesis cost for questions that recur or require global understanding.

Approach Ingest cost Query cost Scale risk Cost control
Naive vector RAG Low: chunk + embed. Medium to high if many chunks are repeatedly supplied. Weak global synthesis and stale/duplicated chunks. Hybrid retrieval, reranking, metadata filters, smaller chunks.
LLM Wiki Medium: every source can update many pages. Lower for repeated questions because synthesis is precompiled. Wiki drift if updates are unreviewed or schema is weak. One-source ingest, diffs, human review, lint passes, page budgets.
GraphRAG High: extraction, clustering, summaries, graph storage. Good for global and multi-hop questions. Index rebuild and graph noise can become costly. Incremental graph updates, entity filters, summary caching.
Graphify Medium to high for large repos; static analysis reduces LLM work. Lower for coding agents because graph queries replace full-file reads. Graph freshness after frequent code/doc changes. Incremental graph rebuilds, scoped queries, structural analysis first.
KAG / Graphiti Medium to high depending on schema and temporal extraction. Efficient when queries follow entity/relation/time structure. Ontology maintenance and contradiction handling. Schema governance, temporal versioning, confidence thresholds.

Pros And Cons

Option Pros Cons Use when
Graphify Repository-aware, graph-native, useful for coding assistants, claims large token reduction. Specialized toward code and multimodal repo analysis; not a full editorial wiki system. You want AI coding assistants to understand architecture without reading everything every time.
Microsoft GraphRAG Strong global summarization over large corpora; backed by a clear research paper. Indexing can be token-heavy; generated graph can contain extraction noise. You need strategic analysis across many documents, not just fact lookup.
LightRAG Designed to reduce graph-RAG complexity with incremental graph/vector retrieval. You still need to build governance, review, and wiki-writing behavior. You need graph-enhanced retrieval but cannot afford heavy GraphRAG indexing.
Graphiti Temporal graph memory handles changing facts and agent personalization. Less suited as a human-authored/browsed markdown knowledge base by itself. You need agent memory that remembers what changed, when, and for whom.
KAG Good fit for professional domains with schemas, rules, and factual reasoning. Requires domain modeling and operational discipline. You need high-precision domain QA in medicine, finance, legal, manufacturing, or compliance.
LlamaIndex / LangChain / Haystack Mature ecosystem, connectors, retrievers, pipelines, agents, and evaluation hooks. They provide parts, not the LLM Wiki pattern end-to-end. You are building a custom product and need control over ingestion, retrieval, and workflows.

Business Scenarios

Where It Creates Value
Engineering knowledge Use Graphify plus markdown wiki pages for architecture, ADRs, code ownership, dependency maps, and onboarding. Market and research intelligence Use GraphRAG or LightRAG to synthesize competitors, papers, regulations, customer calls, and product decisions. Customer operations Use LlamaIndex/Haystack plus reviewed wiki pages for support playbooks, policy changes, and cited answers. Agent memory Use Graphiti when personal, account, or project facts change over time and must not be flattened into static chunks. Regulated domains Use KAG/OpenSPG when schema, traceability, logic, and controlled terminology matter more than fast prototyping. Executive knowledge base Use an LLM Wiki to turn meeting transcripts and reports into evolving strategy pages, assumptions, risks, and decisions.

Recommended Architecture

If the goal is the Karpathy-style LLM Wiki, do not pick a single framework and expect it to do everything. Use Graphify where the corpus is code-heavy. Use GraphRAG or LightRAG when global synthesis across documents matters. Use Graphiti when time-aware memory matters. Use LlamaIndex, LangGraph, or Haystack as the workflow and retrieval plumbing. Keep the wiki itself as markdown in Git so humans can review diffs, branch, revert, and browse the accumulated synthesis.

Composable Stack
Source vault Immutable raw documents, transcripts, images, code, PDFs, and source metadata. Ingest agent LangGraph, LlamaIndex workflow, or Haystack pipeline reads sources and proposes wiki diffs. Wiki repo Markdown pages, index, log, contradictions, page owners, frontmatter, and review status. Retrieval substrate Graphify, GraphRAG, LightRAG, Graphiti, KAG, vector DB, BM25, or hybrid search.

Personal Knowledge Product Architecture

A great personal knowledge product should not ask the human to model ontology, run graph jobs, or keep summaries current. The human should only provide source: drop markdown files into a source folder. The system should ingest the file, classify the knowledge, update durable wiki pages, connect related claims, track when each claim was true, and expose enough visual structure for the human to see whether the knowledge base is healthy.

The implementation should borrow specific mechanisms, not brand names. From Graphiti, take the episode model, provenance edges, and temporal fact fields such as valid time, invalid time, and expiration. From GraphRAG, take entity-relation extraction, Leiden community detection, and community reports for corpus-level themes. From LightRAG, take incremental graph updates and token-budgeted local/global retrieval. From Graphify, take Tree-sitter structural extraction for code and NetworkX/Leiden graph analysis for human inspection. From LlamaIndex, LangGraph, and Haystack, take cached ingestion transforms, checkpointed workflows, and typed production pipelines.

Self-Maintaining Personal LLM Wiki
Markdown source drop Human only adds raw notes, transcripts, research summaries, meeting notes, and documents as markdown. Ingest and normalize Parse frontmatter, dates, authors, links, entities, claims, topics, citations, and source provenance. Self-evolving maintainer Updates wiki pages, merges duplicates, adds backlinks, records contradictions, and proposes page diffs. Temporal knowledge graph Stores entities, claims, relationships, valid time, observed time, confidence, decay policy, and source links. Stable wiki layer Markdown pages for concepts, people, projects, decisions, evergreen notes, and living topic maps. Decaying knowledge layer Market prices, product specs, APIs, laws, schedules, opinions, benchmarks, and status facts expire or degrade. Time-aware query router Detects whether the question is evergreen, time-windowed, current-state, or historical-before-answering. Human inspection map Shows topic clusters, stale zones, contradictions, orphan pages, high-change areas, and review queues.
The product should treat markdown as the human contract, the temporal graph as machine memory, and the wiki diff as the review surface.

Concrete Integration Plan

The data points matter. Graphify reports about 71.5x token reduction on a 52-file mixed corpus by querying the graph instead of reading raw files. GraphRAG stores Leiden-generated community IDs and LLM-ranked community reports as first-class outputs. Graphiti's source model includes episodic nodes for raw evidence and entity edges with valid, invalid, expired, reference-time, and episode provenance fields. LightRAG exposes deletion, rebuild, graph, vector, and cache operations because incremental maintenance is part of the runtime, not a manual reindex. LlamaIndex caches node/transformation pairs, which is exactly the behavior a personal wiki needs when only one markdown note changes.

Component Borrow from Algorithm or code-level mechanism Product decision
Source ingestion LlamaIndex, Haystack Transformation pipeline, cached node+transform hashes, typed pipeline components. Hash every markdown file and rerun only changed transforms; store source as immutable evidence.
Temporal memory Graphiti Episode nodes, entity nodes, entity edges, provenance links, valid/invalid/expired timestamps. Represent every extracted claim as a temporal edge with source links and a decay policy.
Global synthesis GraphRAG Entity/relation extraction, Leiden community detection, generated community reports. Run community reports asynchronously for topic maps, not on every source write.
Incremental retrieval LightRAG Graph + vector retrieval, local/global modes, top-k and token caps for entities, relations, chunks. Use a strict answer budget: entities first, relations second, source chunks only when evidence is needed.
Code knowledge Graphify Tree-sitter AST extraction, semantic extraction, NetworkX graph, Leiden clusters, graph report. Use Graphify only for code and architecture folders; link code facts back into the personal wiki.
Workflow runtime LangGraph State graph, explicit nodes/edges, checkpoint persistence, resumable runs. Make ingest, resolve, write-wiki-diff, validate, and publish separate checkpointed steps.

Source-To-Wiki Maintenance Loop

Background Maintenance Loop
Detect changed markdown File hash, frontmatter, source date, author, project, and confidence metadata. Extract claims Entities, relationships, dates, contradiction candidates, decay class, and citations. Resolve into graph Merge duplicate entities, append provenance, invalidate superseded facts, preserve history. Propose wiki diff Update concept pages, topic maps, decision pages, contradictions, and changelog entries. Inspect and publish Show stale zones, orphan notes, high-degree concepts, review queue, and accepted diffs.

Data Model

Object Fields Reason
SourceDoc path, hash, observed_at, source_date, author, project, tags, raw markdown. Lets the system rerun ingestion incrementally and cite original evidence.
Claim subject, predicate, object, confidence, valid_at, invalid_at, decay_class, source_ids. Separates durable facts from time-sensitive statements.
Entity canonical name, aliases, type, summary, embedding, connected claims. Provides stable anchors for linking notes, pages, and queries.
WikiPage slug, topic, summary, outgoing links, source claims, last_reviewed_at, owner. Keeps the knowledge base human-readable and reviewable.
ReviewEvent diff, accepted/rejected, reviewer, rationale, changed claims, timestamp. Prevents self-evolution from silently corrupting the wiki.
Query type Examples Retrieval behavior Answer rule
Evergreen Concepts, principles, architecture decisions, personal values, durable explanations. Prefer stable wiki pages, accepted decisions, canonical summaries, and low-decay claims. Answer from durable knowledge unless newer sources explicitly override it.
Current-state Product pricing, APIs, laws, model capability, schedules, project status. Prefer latest high-confidence observations; flag stale or expired claims. Answer with recency metadata and request refresh when evidence is too old.
Historical What did I believe in March? What changed after a release? Why was a decision made? Retrieve claims valid inside the requested time window plus adjacent change logs. Answer from the relevant historical slice, not from today's overwritten state.
Comparative trend How has this vendor changed? Which idea keeps recurring? What risks are increasing? Retrieve temporal sequences, contradictions, revisions, and cluster-level summaries. Answer with trajectory, confidence, and source-backed inflection points.

References