AI Briefing
KO

LLM Wiki v2 (16-minute read)

·2026.05.19 09:00

Key point

LLM Wiki v2 grows into an operational knowledge base by adding lifecycle management, graphs, and automation.

Details

LLM Wiki v2 is an expanded version that takes the pattern of building a personal knowledge base with an LLM up to production-operation level. Building on Karpathy's original idea, it incorporates lessons from agentmemory and AKBP to turn it into a structure that continuously accumulates, updates, and shares knowledge. The key is not to search-and-forget like RAG, but to compile raw material into a wiki and schema, compounding it over time.

Knowledge has a lifecycle. Each fact should carry a confidence score that reflects the number of sources, how recently it was verified, and whether it has been contradicted, and it should naturally decay over time. When new information conflicts with an existing claim, supersession lets the new version explicitly replace the old one, while the old content is preserved in a stale state.

Memory is promoted through four stages.

  • Working memory: recent observations
  • Episodic memory: session summaries
  • Semantic memory: cross-session facts
  • Procedural memory: recurring patterns and workflows

The more often something is repeatedly confirmed, the more compressed it becomes and the longer it persists, elevating it from a fact seen once to a rule that actually works.

A page-centric structure alone has clear limits. On top of the wiki, a typed knowledge graph is layered to extract entities such as people, projects, libraries, and decisions, and attach relationships like uses, depends on, contradicts, and supersedes. Queries should traverse the graph to explore the scope of impact broadly rather than relying on simple keyword matching, so that connected facts—like the downstream impact of a Redis upgrade—aren't missed.

A single index.md isn't enough for search either. Once you pass roughly 100–200 pages, the index gets too long to read, so hybrid search combining BM25, vector search, and graph traversal is used, with results merged via reciprocal rank fusion. index.md remains a catalog for humans but is not used as the LLM's primary search engine.

Operations should be event-driven. When new sources come in, automatic ingest, entity extraction, and graph updates should run; and when sessions start or end, or when query, memory-write, or scheduled events occur, cleanup and inspection should automatically follow. Periodic linting, retention policies, and conflict detection also need to be automated to sharply reduce maintenance cost.

Quality and collaboration are essential too. All generated content should be scored, and lint should self-fix anything fixable, such as repairing broken references or linking orphaned pages. In environments where multiple agents write together, shared/private scopes should be separated, sensitive information should be filtered out at the ingest stage, and every change should be recorded in an audit log.

Completed research or debugging sessions become structured digests through crystallization and rejoin the knowledge base. Output isn't limited to markdown either—it can turn into tables, timelines, dependency graphs, slides, JSON, CSV, briefs, and more. Ultimately, what matters most is the schema documents (AGENTS.md, CLAUDE.md), which define entities, relationships, quality criteria, conflict handling, and retention rules, turning the LLM from a mere search tool into a continuously learning knowledge worker.

This summary was generated automatically by AI. Check the original for the author's claims and context. Copyright belongs to the original author.

Our guide explains how the AI works. Report summary errors, attribution issues, or removal requests via Contact.