LLM wiki: cómo crear una y mantenerla precisa

Una LLM wiki es una base de conocimiento personal que un agente de IA escribe por ti. Reúnes fuentes originales (artículos, artículos académicos, transcripciones, notas) en una carpeta. El agente las lee y mantiene encima un conjunto de páginas markdown enlazadas entre sí: una página por concepto, persona o fuente, más un índice. Cuando añades una fuente, el agente actualiza todas las páginas a las que afecta. Cuando haces una pregunta, responde a partir de la wiki y puede archivar la respuesta como una página nueva.

La idea es de Andrej Karpathy. El 2 de abril de 2026 publicó en X sobre las “LLM Knowledge Bases” y, dos días después, publicó una versión más larga como un “idea file” en GitHub, escrito para pegarlo tal cual en un agente como Claude Code o Codex. Lo contrapone a RAG, donde un modelo recupera fragmentos de tus archivos en cada pregunta y no se acumula nada. En una LLM wiki, el conocimiento se “compila una vez y luego se mantiene al día”, así que las referencias cruzadas y las contradicciones ya están resueltas antes de que preguntes.

Obsidian es el IDE; el LLM es el programador; la wiki es el código.

Esa frase del gist resume el montaje que copia casi todo el mundo: el agente abierto en una terminal a un lado, un editor de markdown al otro y, entre ambos, una carpeta de archivos. Pero el patrón no necesita ningún editor en concreto. Sirve cualquier carpeta y cualquier agente que sepa leer y escribir archivos.

Lo que un editor no te dice es qué páginas ha cambiado el agente y si alguien las ha revisado. Knowtarium es una base de conocimiento cifrada de extremo a extremo hecha para ese montaje. Tu wiki vive en un espacio de trabajo como páginas markdown planas, tu agente la lee y la escribe por MCP, y cada página que cambia va firmada, muestra quién hizo el cambio y se puede deshacer. Empezar es gratis. El resto de esta guía explica el montaje con archivos planos, con notas por el camino sobre cómo lo resuelve Knowtarium.

Karpathy describe el patrón de la LLM wiki en tres capas:

• Fuentes originales. Tus documentos seleccionados. Son inmutables: el agente los lee y nunca los cambia. Son tu fuente de verdad.
• La wiki. Un directorio de páginas markdown que escribe el agente: resúmenes, páginas de entidades, páginas de conceptos, comparaciones, una visión general. “Tú la lees; el LLM la escribe.”
• El esquema. Un archivo como CLAUDE.md para Claude Code o AGENTS.md para Codex que le dice al agente cómo está organizada la wiki y qué flujos de trabajo seguir. Con el tiempo, lo vas afinando junto con el agente.

Y tres cosas que le pides al agente:

Dos archivos la hacen navegable. index.md enumera todas las páginas con un enlace y un resumen de una línea, y el agente lo lee primero en cada consulta. Karpathy señala que esto funciona “sorprendentemente bien” a escala moderada (unas 100 fuentes y cientos de páginas) sin ninguna búsqueda por embeddings. Por encima de eso, el gist sugiere dar al agente una herramienta de búsqueda local sobre los archivos markdown. log.md es una cronología de ingestas, consultas y pasadas de lint.

El gist es abstracto a propósito y deja los detalles en tus manos y las de tu agente. Aquí tienes una versión concreta que funciona con Claude Code, Codex o Cursor. Lleva una media hora, casi toda dedicada al esquema.

1. Crea las carpetas

Mantén separadas las fuentes y la wiki, para que siempre quede claro qué texto viene del mundo y cuál del agente.

customer-wiki/
  CLAUDE.md            # el esquema (o AGENTS.md para Codex)
  raw/                 # tus fuentes: el agente las lee, nunca las edita
    2026-09-12-interview-northwind.md
    2026-09-14-support-tickets.md
    assets/            # imágenes descargadas junto a los artículos guardados
  wiki/                # las páginas del agente
    index.md           # una línea por página, se lee primero en cada consulta
    log.md             # qué pasó y cuándo
    overview.md
    concepts/
    entities/
    sources/           # una página de resumen por cada fuente original
    answers/           # las buenas respuestas, archivadas de vuelta

En Knowtarium

Importa customer-wiki/ a un espacio de trabajo de Knowtarium y sus carpetas se mantienen. El grafo muestra lo que se ha quedado desfasado (con la revisión activada, puede colorear las páginas por nivel de confianza), y los enlaces a páginas que el agente aún no ha escrito aparecen como fantasmas: una lista de tareas para la próxima ingesta.

(se abre a tamaño completo en una pestaña nueva) (se abre a tamaño completo en una pestaña nueva)

2. Ponla bajo git

Ejecuta git init antes de la primera ingesta. Karpathy señala que la wiki “no es más que un repositorio git de archivos markdown”, y git es además la forma más barata de ver qué ha cambiado el agente. Más sobre esto abajo.

3. Escribe el archivo de esquema

Es el archivo más importante del montaje. Empieza con algo breve y añade una regla cada vez que el agente haga algo que no querías. Las recomendaciones de Anthropic para CLAUDE.md sirven aquí: que no pase de unas 200 líneas y que cada instrucción sea lo bastante concreta como para poder comprobarla. Si usas varios agentes, escríbelo una vez como AGENTS.md y añade un CLAUDE.md que contenga @AGENTS.md, para que Claude Code cargue las mismas reglas.

# Esquema de la wiki
 
Tú mantienes la wiki en wiki/. Las fuentes de raw/ son de solo lectura.
 
## Páginas
- Un concepto, entidad o fuente por archivo. Nombres de archivo en kebab-case.
- Cada página empieza con frontmatter: type, title, description, sources.
- Enlaza las páginas relacionadas con enlaces markdown estándar.
- Cada afirmación cita su fuente con una nota al pie identificada por el id de la fuente.
- Si no puedes citarlo, no lo escribas. Marca las preguntas abiertas como tales.
 
## Ingesta (cuando añado un archivo a raw/)
1. Lee la fuente. Dime los 3 a 5 puntos clave antes de escribir.
2. Escribe wiki/sources/<name>.md con un resumen y el id de la fuente.
3. Actualiza las páginas de conceptos y entidades que toque. Señala las contradicciones
   con las páginas existentes en lugar de sobrescribirlas sin decir nada.
4. Actualiza wiki/index.md y añade una entrada a wiki/log.md.
5. Enumera todos los archivos que has cambiado.
 
## Consulta
- Lee primero wiki/index.md y luego abre solo las páginas que necesites.
- Responde con citas. Ofrece archivar las buenas respuestas en wiki/answers/.
 
## Lint (cuando te lo pida)
- Informa de contradicciones, afirmaciones desfasadas, páginas huérfanas, páginas que faltan
  y afirmaciones sin fuente. Propón correcciones; no las apliques todavía.

Dos de esas reglas importan más de lo que parece: “cada afirmación cita su fuente” y “enumera todos los archivos que has cambiado”. Ahora no cuestan nada, y más adelante hacen posible la revisión.

4. Añade una fuente y procésala

Guarda un artículo como markdown en raw/ y pide al agente que lo procese. Karpathy prefiere procesar una fuente cada vez y seguir de cerca el proceso: leer el resumen, revisar las actualizaciones, decirle al agente en qué hacer hincapié. Hazlo al menos con las diez primeras fuentes. Así descubres lo que le falta a tu esquema.

En Knowtarium

Cada página que la ingesta escribe o cambia queda marcada en la barra lateral hasta que la abres, con una línea bajo el título que dice qué agente la editó y cuándo, un enlace a los cambios y un Undo. Lee ahí el resumen y las actualizaciones, y deshaz lo que no quieras. Si prefieres aprobar antes, activa la revisión (“Ask me first”) en la carpeta wiki/, y cada cambio te esperará como un diff.

(se abre a tamaño completo en una pestaña nueva) (se abre a tamaño completo en una pestaña nueva)

5. Haz preguntas y guarda las buenas respuestas

Pregunta cruzando fuentes, no solo sobre una. Cuando una respuesta merezca la pena, pide al agente que la archive en wiki/answers/ y la enlace desde las páginas en las que se basa.

# procesar una fuente
> Procesa raw/2026-09-14-support-tickets.md. Enséñame primero los puntos clave.
 
# preguntar y guardar la respuesta
> Usando solo la wiki, ¿dónde se atascan los clientes nuevos? Cita las páginas.
> Archiva eso como wiki/answers/onboarding-blockers.md y enlázalo.
 
# revisión de salud
> Pasa el lint a la wiki. No cambies nada todavía, dame una lista.

6. Pasa el lint con regularidad

Una vez a la semana, o cada diez ingestas, pide una pasada de lint. Pide primero un informe y aprueba las correcciones por separado, para que una revisión de salud no pueda reescribir media wiki sin que te enteres. Un prefijo constante en el log facilita ver lo que ha pasado últimamente:

## [2026-09-14] ingest | Tickets de soporte, agosto
## [2026-09-15] query | ¿Dónde se atascan los clientes nuevos?
## [2026-09-20] lint | 2 contradicciones, 4 páginas huérfanas

$ grep "^## \[" wiki/log.md | tail -5

El patrón de la LLM wiki hace que el mantenimiento sea casi gratis. Esa es la gracia, y también el riesgo. El agente puede tocar 15 páginas en una pasada, y en la mayoría de los montajes nadie lee esos 15 cambios. El propio Karpathy sigue de cerca sus ingestas, y para las wikis de equipo menciona que “posiblemente con personas en el circuito revisando las actualizaciones”. La mayoría de los tutoriales se saltan esa parte. Esto es lo que se acumula cuando te la saltas:

• Deriva respecto a la fuente. El resumen de un resumen pierde un matiz. “En algunos benchmarks” se convierte en “sistemáticamente”, y tres páginas después ya es un hecho.
• Síntesis sin fuente. El agente une dos ideas en una frase que suena bien y no cita nada. No puedes distinguirla de una afirmación con fuente.
• Contradicciones resueltas en silencio. Una fuente nueva contradice una página antigua, y el agente elige un ganador en lugar de señalarlo.
• Páginas desfasadas que parecen nuevas. Una página escrita en mayo se lee igual en diciembre. Nada indica que toque revisarla.
• Tus propias ediciones se desincronizan. Corriges una cifra en una página. Las cinco páginas que la repiten siguen teniendo la antigua.
• El linter se pone nota a sí mismo. El lint es el mismo tipo de modelo leyendo las mismas páginas. Detecta contradicciones entre páginas, no errores en los que todas las páginas coinciden.

Nada de esto hace que el patrón sea mala idea. Significa que una LLM wiki necesita lo mismo que cualquier base de código escrita por un solo autor: un segundo par de ojos y un registro de quién escribió qué.

Cuatro hábitos cierran casi todo el hueco. Puedes adoptarlos de uno en uno, con archivos planos y sin herramientas nuevas.

1. Registra la procedencia en el frontmatter

Cada página debería decir quién la escribió, cuándo y a partir de qué fuentes, y cada afirmación debería apuntar a una de esas fuentes. Las notas al pie identificadas por el id de la fuente ([^northwind-call]) sobreviven a que el agente reordene la lista, algo que no pasa con las notas numeradas. Aquí tienes una página que usa los nombres de campo del Open Knowledge Format, para que otras herramientas también puedan leerlos:

---
type: Concept
title: Abandono en el paso de importación
description: Por qué los clientes nuevos se atascan al importar sus datos.
generated: { by: claude-code/2.1, at: 2026-09-20T09:12:00Z }
verified:
  - { by: human:sam, at: 2026-09-20T18:40:00Z }
stale_after: 2027-03-20T00:00:00Z
sources:
  - id: northwind-call
    resource: /raw/2026-09-12-interview-northwind.md
    title: Entrevista con cliente, Northwind Traders
---
 
Northwind estuvo atascado una semana con la importación del CSV.[^northwind-call]

generated es quién escribió el texto actual. verified es quién lo revisó, y el prefijo human: indica una persona. Añade una línea a tu esquema: “firma en generated cada página que cambies, nunca te añadas a verified”. Nuestra guía para que los agentes citen sus fuentes va más allá.

2. Revisa cada cambio del agente antes de depender de él

Trata una ingesta como un pull request. Haz commit antes de empezar, deja trabajar al agente y luego lee el diff y acéptalo o recházalo. Git lo hace bien:

$ git status --short          # qué páginas han cambiado$ git diff --stat             # cuánto$ git diff wiki/concepts/     # lee las ediciones en sí$ git add -p                  # acepta bloque a bloque$ git commit -m "ingest: support tickets"$ git restore wiki/entities/  # descarta lo que no hayas aceptado

No leas todas las páginas. Lee las líneas que han cambiado y comprueba cada afirmación nueva con la nota al pie que cita. Cuando apruebes una página, añádete a verified con la fecha. La rutina completa está en cómo revisar las ediciones de los agentes.

3. Pide al agente que revise tus ediciones

La revisión debería ir en los dos sentidos. Cuando cambias una página a mano, pide al agente que encuentre todas las páginas que la enlazan, que citan la misma fuente o que repiten el valor antiguo, y que proponga correcciones para esas páginas. Luego revisas las correcciones como cualquier otro cambio de un agente. Así es como tu corrección llega a las otras cinco páginas.

4. Pon fecha de caducidad a las páginas

Añade stale_after con una fecha absoluta: corta para precios, versiones y cargos de las personas, larga para definiciones. Así, una pasada de lint puede listar las páginas que han pasado su fecha en lugar de adivinar. Saber si algo está desfasado pasa a ser una comparación de fechas, no una cuestión de criterio.

El Open Knowledge Format es una especificación abierta publicada por Google Cloud para el conocimiento que escriben los agentes. La versión 0.2 añadió señales de confianza justo para el caso anterior: corpus que los agentes escriben continuamente y que leen otros agentes. Un paquete OKF tiene la misma forma que una LLM wiki (una carpeta de archivos markdown con frontmatter YAML) y reserva los mismos dos nombres de archivo, index.md y log.md.

Quien lee deduce un nivel de confianza a partir de verified: sin entradas es unverified, solo agentes o procesos es machine-confirmed, y al menos una persona es human-reviewed. Una página nunca puede declararse fiable a sí misma. Dos pequeñas diferencias con el gist: el gist no fija una sintaxis de enlaces, mientras que OKF usa enlaces markdown estándar; y el log.md de OKF pone primero las entradas más recientes, bajo encabezados de fecha simples YYYY-MM-DD. Todos los campos son opcionales, así que puedes empezar una LLM wiki en OKF e ir añadiendo los campos de confianza sobre la marcha.

Git es lo mínimo: te muestra qué ha cambiado, si haces commit antes de cada sesión y lees el diff después. Knowtarium es el montaje que recomendamos cuando la wiki crece, porque guarda el historial, el deshacer y el estado de confianza junto a las páginas en lugar de en tu terminal. Así se comparan los dos.

Si procesas unas pocas fuentes a la semana y lees cada diff, puede bastarte con git. Knowtarium es una app web: tus páginas se cifran en tu dispositivo antes de llegar a nosotros, así que no podemos leerlas, y no llama a ninguna IA por sí mismo. El agente que conectes ve lo que lee. Si tu wiki ya vive en una bóveda de Obsidian, impórtala a un espacio de trabajo y se convierte a OKF sin tocar lo que escribiste; la guía de migración lo explica paso a paso, y la página comparativa cuenta en qué se diferencian las dos apps.