LLM Wiki de Karpathy: una base de conocimientos locale
El LLM Wiki es un patrón descrito por Andrej Karpathy en abril de 2026: en lugar de consultar tus documentos en cada pregunta, un modelo redacta y mantiene actualizado un wiki en Markdown, que se enriquece con cada nueva fuente. Esta guía explica el principio a partir de su publicación y su gist, propone una implementación local con Ollama y un agente en terminal, y después precisa qué no sustituye este patrón en un RAG. No contiene ninguna prueba propia ni comparativa cuantitativa: lo que se afirma sobre el patrón se atribuye a su fuente y el resto se señala como nuestra implementación.
#LLM Wiki: el principio en dos minutos
El 2 de abril de 2026, Andrej Karpathy describe en X cómo utiliza modelos de lenguaje para crear bases de conocimientos personales. Dos días después, publica un gist titulado «LLM Wiki», que presenta como un patrón para construir este tipo de base con un LLM. Ambos textos son breves y se leen en diez minutos; los enlaces figuran al final de la página.
El gist parte de una constatación: la mayoría de los usos que combinan LLM y documentos se parecen al RAG. Se depositan archivos, el sistema recupera fragmentos cuando se formula la pregunta y el modelo redacta una respuesta. Karpathy reconoce que funciona, pero señala que el modelo redescubre el conocimiento en cada pregunta y que nada se acumula. Una pregunta que obliga a cruzar cinco documentos exige recuperar y volver a ensamblar los mismos fragmentos cada vez.
El LLM Wiki desplaza el trabajo a la fase previa. Cuando llega una nueva fuente, el modelo no se limita a indexarla: la lee, extrae lo esencial y lo integra en un conjunto de páginas Markdown enlazadas entre sí. Actualiza las páginas existentes, revisa los resúmenes y señala los lugares donde la nueva fuente contradice lo escrito. El gist habla de un artefacto persistente que mejora con el tiempo: las comprobaciones cruzadas ya están hechas cuando llega la pregunta.
La distribución de roles queda clara en el texto. La persona elige las fuentes, explora y formula las preguntas. El modelo hace todo lo demás: resumir, relacionar, clasificar, llevar los registros. Karpathy dice que trabaja con el agente abierto en un lado de la pantalla y Obsidian en el otro, y resume la instalación con una imagen: Obsidian es el IDE, el LLM es el programador y la wiki es la base de código.
#Tres capas: fuentes, wiki y convenciones
Tus documentos, tu IA: un RAG local fiable sobre tus PDF, notas y correos — sin enviar nada a la nube.
- Espacio en línea de por vida
- PDF + archivos
- Actualizaciones de por vida
El gist describe una arquitectura de tres capas. Ninguna requiere una herramienta concreta: son carpetas y archivos de texto.
- Las fuentes sin procesar
- Tu colección de documentos: artículos, trabajos de investigación, imágenes y archivos de datos. Son inmutables: el modelo los lee y nunca los modifica. Son ellos, y no la wiki, los que tienen la autoridad.
- La wiki
- Una carpeta de archivos Markdown redactados por el modelo: resúmenes de fuentes, páginas de entidades, páginas de conceptos, comparaciones y una síntesis general. Esta capa pertenece al modelo, que crea las páginas, las actualiza y mantiene los enlaces. Tú lees; él escribe.
- El archivo de convenciones
- Un documento que indica al modelo cómo está estructurada la wiki, qué reglas debe seguir y cómo proceder para ingerir una fuente, responder a una pregunta o hacer limpieza. El gist cita CLAUDE.md para Claude Code y AGENTS.md para Codex. Este archivo es lo que convierte a un agente generalista en un mantenedor disciplinado de wikis.
Dos archivos especiales ayudan al modelo, y a usted, a orientarse. El primero, index.md, es un catálogo: cada página aparece allí con un enlace y un resumen de una línea, ordenada por categoría. Para responder a una pregunta, el modelo lee primero el índice y después abre las páginas útiles. El segundo, log.md, es un registro cronológico al que solo se añade contenido: ingestas, preguntas y rondas de verificación.
El gist sugiere comenzar cada entrada del registro con un prefijo regular, lo que permite filtrarlo con herramientas Unix sencillas. El ejemplo dado tiene esta forma:
#Tres operaciones: ingerir, consultar, verificar
- Ingerir (ingest)
- Coloca una fuente en la carpeta de fuentes sin procesar y pide al modelo que la trate. Según el gist, lee la fuente, debate contigo los puntos clave, escribe una página de resumen, actualiza el índice y las páginas de entidades y conceptos relacionadas, y después añade una entrada al registro. Karpathy indica que una sola fuente puede afectar a entre 10 y 15 páginas de la wiki.
- Consultar (query)
- Usted formula una pregunta. El modelo busca las páginas pertinentes, las lee y redacta una respuesta que cita sus referencias. El gist insiste en un punto: una buena respuesta puede guardarse en la wiki como una página nueva, para que sus exploraciones se acumulen en lugar de desaparecer en el historial de una conversación.
- Comprobar (lint)
- De vez en cuando, le pides al modelo una auditoría de salud de la wiki: contradicciones entre páginas, afirmaciones superadas por fuentes más recientes, páginas huérfanas sin enlaces entrantes, conceptos citados sin una página dedicada y referencias cruzadas ausentes.
¿Por qué confiar este trabajo a un modelo? El argumento del gist es sencillo: lo que acaba con las wikis personales no es la lectura ni la reflexión, sino el mantenimiento de los registros. Actualizar las referencias, mantener los resúmenes al día, detectar las contradicciones: la carga de mantenimiento crece más rápido que el valor de la wiki, y se abandona. Un modelo no se cansa y puede modificar quince archivos de una sola vez. Karpathy relaciona la idea con el Memex imaginado por Vannevar Bush en 1945.
#Requisitos previos para un wiki mantenido por un modelo local
El gist no presupone ningún proveedor concreto. Necesita un agente capaz de leer y escribir archivos, controlado por un modelo. En local, esto proporciona los siguientes componentes.
- Ollama, actualizado
- Sirve el modelo en http://localhost:11434. El comando ollama launch utilizado más abajo solo existe en las versiones recientes. La instalación se trata en nuestra guía «Instalar Ollama».
- Un agente con acceso a los archivos
- Una interfaz de conversación no basta: hace falta una herramienta que abra, cree y modifique archivos en el disco. El ejemplo siguiente utiliza OpenCode, un agente de código abierto en terminal citado en el gist, que lee un archivo AGENTS.md situado en la raíz de la carpeta.
- Un modelo que sabe llamar a herramientas
- Leer y escribir archivos se hace mediante llamadas a herramientas. Elige un modelo que muestre la capacidad tools en la biblioteca Ollama. Nuestra guía «OpenCode + Ollama» incluye varios, entre ellos qwen3-coder:30b, devstral-small-2:24b y gpt-oss:20b.
- Memoria para el contexto
- Referencias en Q4_K_M solo para los pesos: unos 5 GB para 7 mil millones de parámetros, 9 GB para 14 mil millones y 19 GB para 32 mil millones. La documentación de Ollama exige al menos 64 000 tokens de contexto para los agentes, que se suman a estas cifras.
- Git
- El wiki no es más que una carpeta de archivos Markdown: el gist señala que convertirlo en un repositorio git proporciona el historial de versiones sin añadir nada.
- Obsidian (opcional)
- Para leer la wiki, seguir los enlaces y mostrar el grafo de páginas. Cualquier editor de Markdown sirve; Obsidian no interviene en la redacción.
#Configuración con Ollama, paso a paso
Los comandos están escritos para macOS y Linux; en Windows, lo más sencillo es utilizar WSL. La estructura de directorios y el archivo de convenciones son ejemplos que deben adaptarse: el gist precisa que la estructura de las carpetas, las convenciones y el formato de las páginas dependen de su ámbito y de su modelo, y que todo es opcional y modular.
- 01Crear la carpeta y el repositorioUna carpeta para las fuentes sin procesar, una carpeta para las páginas, un índice y un registro, todo bajo git.
- 02Escribir el archivo de convencionesUn AGENTS.md en la raíz que describe la estructura, las reglas de escritura y los tres procedimientos: ingestión, consulta y verificación.
- 03Ejecutar el modelo y el agenteOllama sirve un modelo capaz de llamar a herramientas, con 64 000 tokens de contexto; OpenCode se abre en la carpeta del wiki.
- 04Ingerir una primera fuenteUn solo documento, procesado ante tus ojos, revisado y después guardado en git.
- 05Consultar y organizar las respuestasLas preguntas se plantean en el wiki; las síntesis útiles se convierten en páginas.
- 06Comprobar regularmenteUna pasada de control que enumera las contradicciones, las páginas huérfanas y los enlaces rotos.
#1. Crear la carpeta y el repositorio
La carpeta raw/ recibirá tus documentos y la carpeta wiki/ las páginas redactadas por el modelo. Los nombres son libres, siempre que la separación entre ambas siga siendo visible.
#2. Escribir el archivo de convenciones
Esta es la pieza más importante. Sin ella, el agente improvisa una estructura diferente en cada sesión. Crea un archivo AGENTS.md en la raíz de ~/wiki, por ejemplo, basándote en esto:
Este archivo es nuestro, no el de Karpathy: el gist describe el papel del archivo de convenciones sin proporcionar una plantilla y recomienda hacerlo evolucionar junto con el modelo a medida que veas qué funciona en tu ámbito. Mantenlo breve. El agente lo vuelve a leer en cada sesión y cada línea ocupa espacio en el contexto.
#3. Iniciar el modelo y el agente
Descarga un modelo capaz de llamar a herramientas y, después, abre OpenCode en la carpeta de la wiki. El comando ollama launch opencode inicia OpenCode con un modelo servido por Ollama, que puedes elegir en el selector. La instalación de OpenCode se describe en nuestra guía «OpenCode + Ollama».
Queda el contexto. Según la documentación de Ollama, la ventana predeterminada depende de la VRAM (4 000 tokens por debajo de 24 GB, 32 000 entre 24 y 48 GB), mientras que los agentes necesitan al menos 64 000. La variable OLLAMA_CONTEXT_LENGTH la fija al iniciar el servidor; si Ollama ya funciona como aplicación o como servicio, ajuste el valor en sus parámetros en lugar de iniciar un segundo servidor.
El comando ollama ps indica si el modelo cabe por completo en la GPU. Si se desborda al procesador, cada ingestión se vuelve muy lenta: elige un modelo más pequeño antes de recortar el contexto.
#4. Ingerir una primera fuente
Coloca un primer documento en raw/, preferiblemente en Markdown o texto. Para las páginas web, el gist señala la extensión Obsidian Web Clipper, que convierte un artículo en un archivo Markdown. Después, dale la instrucción al agente:
El agente lee la fuente, propone sus puntos clave y, después, crea y modifica las páginas. Revisa el resultado antes de continuar: la página de resumen, las páginas de entidades creadas, el índice y el registro. A continuación, guarda el estado de la wiki.
#5. Consultar y ordenar las respuestas
Después de algunas fuentes, hazle tus preguntas al agente en la misma carpeta. Pídele explícitamente que cite sus páginas y sus fuentes, y que diga qué no contiene el wiki.
#6. Comprobar periódicamente
Cada cierto número de ingestas, ejecuta una pasada de verificación. Pide una lista de problemas antes de hacer cualquier corrección: mantienes el control sobre lo que se fusiona, renombra o elimina.
El registro se puede consultar sin agente. Con el prefijo habitual de las entradas, el comando indicado en el gist muestra las últimas operaciones (solo se adapta la ruta a nuestra estructura de directorios):
#LLM Wiki o RAG: lo que el patrón no sustituye
El gist contrapone el wiki al RAG para hacer entender la idea. No dice que uno sustituya al otro, y esta guía tampoco lo dice: ambos enfoques responden a situaciones diferentes. Esto es lo que los separa, sin cifras, porque no tenemos ninguna medición que presentar.
- El momento de trabajar
- Un RAG trabaja al recibir la pregunta: busca fragmentos y después el modelo redacta. La wiki trabaja durante la ingestión: la síntesis se escribe una vez y luego se vuelve a leer con cada pregunta.
- Lo que se conserva
- Un RAG conserva fragmentos y sus vectores, ilegibles tal cual. La wiki conserva páginas redactadas que puedes leer, corregir y versionar.
- L'infrastructure
- Un RAG requiere un modelo de embeddings, una base de datos vectorial y una estrategia de segmentación. La wiki requiere una carpeta y un agente. Según el gist, el índice basta a una escala moderada —del orden de un centenar de fuentes y unos cientos de páginas— y evita montar una infraestructura de RAG basada en embeddings.
- La fidelidad a las fuentes
- Un RAG devuelve al modelo fragmentos originales. La wiki le entrega una reformulación escrita por un modelo, con el riesgo de error que eso conlleva.
- El volumen
- Un RAG está diseñado para corpus grandes. La wiki está limitada por lo que el modelo puede leer de una vez: el índice, las páginas útiles y la fuente deben caber en la ventana de contexto.
Más allá de una escala moderada, el gist vuelve a introducir la búsqueda. Cita qmd, un motor de búsqueda local para archivos Markdown que combina BM25, búsqueda vectorial y reclasificación mediante LLM, utilizable desde la línea de comandos o como servidor MCP. Por tanto, una wiki grande acaba apoyándose en los componentes de un RAG, aplicados a páginas ya sintetizadas en lugar de a documentos sin procesar. Ambos enfoques se combinan más de lo que se excluyen.
En la práctica, mantén un RAG clásico cuando el corpus sea voluminoso o cambie constantemente (documentación empresarial, tickets, contratos), cuando la respuesta deba reproducir el pasaje exacto de un documento, o cuando varias personas con permisos diferentes consulten la misma base. LLM Wiki es más adecuado para un tema que se profundiza durante semanas: seguimiento de novedades, investigación, lectura de un libro, preparación de un expediente. Son usos que el propio gist menciona.
#Límites que debes conocer, sobre todo en local
- Los errores también se acumulan
- Un error de resumen escrito en una página se volverá a leer, citar y propagar a las páginas siguientes. En un RAG, una mala respuesta desaparece con la conversación; en un wiki, permanece. Esa es la razón de ser de la remisión sistemática a las fuentes originales y de la revisión de los cambios.
- Un modelo local tiene menos margen
- La ingesta exige seguir una instrucción larga, leer varios archivos y modificar una decena sin olvidar ninguno. Por lo general, los modelos pequeños realizan peor este tipo de tarea larga que los modelos grandes alojados detrás de los agentes citados en el gist. Compruébalo con tus propias fuentes, empezando poco a poco.
- La ventana de contexto lo limita todo
- Una fuente muy larga, un índice que ha crecido y diez páginas que revisar no siempre caben en 64 000 tokens. Divide las fuentes voluminosas por capítulos y mantén las páginas cortas.
- La ingestión lleva tiempo
- Cada fuente desencadena una serie de lecturas y escrituras. En una máquina modesta, cuenta con un procesamiento fuente por fuente en lugar de import d'una biblioteca entera en una tarde.
- La estructura deriva
- Sin reglas estrictas, el agente crea duplicados (la misma entidad con dos nombres) y páginas que nada relaciona entre sí. Las reglas de nomenclatura del archivo de convenciones y la pasada de verificación sirven para eso.
#Consejos y solución de problemas
- El agente se salta pasos de la ingesta
- El contexto probablemente es demasiado corto: la instrucción sale de la ventana a mitad del proceso. Comprueba el valor de OLLAMA_CONTEXT_LENGTH, acorta AGENTS.md o divide la fuente.
- El agente describe lo que haría, sin escribir nada
- El modelo gestiona mal las llamadas a herramientas. Elige un modelo que muestre la capacidad tools en la biblioteca Ollama.
- La misma entidad aparece con dos nombres
- Solicita una pasada de verificación centrada en los duplicados, valida las fusiones una por una y, después, añade al archivo de convenciones la regla de nomenclatura que faltaba.
- El índice se vuelve demasiado largo
- Divídalo por categorías, con un índice principal que remita a índices secundarios, o añada una herramienta de búsqueda para los archivos Markdown, como qmd, que es el que cita el gist.
- Las respuestas ignoran páginas existentes
- El índice no se actualizó durante una ingesta. Haz que se reconstruya a partir del contenido de la carpeta wiki/ y luego revisa el registro.
#Implementaciones listas para usar
No tienes que escribirlo todo a mano. Hermes Agent, el agente de código abierto de Nous Research, documenta una skill integrada llamada llm-wiki, incluida en su categoría de investigación, que reproduce este patrón. Si ya utilizas este agente con Ollama, es un punto de partida más rápido; la página de documentación, enlazada más abajo, describe su funcionamiento. El principio sigue siendo el mismo: lee las convenciones antes de confiarles tus fuentes.
#Fuentes
Todo lo que se dice del patrón procede de la publicación y el gist de Andrej Karpathy. Los ajustes de Ollama y OpenCode proceden de su documentación, ya citada en nuestra guía «OpenCode + Ollama». Relee estas páginas antes de pegar un comando: estas herramientas evolucionan rápido.
#Para ir más allá
El LLM Wiki se sitúa en la intersección de varios temas ya tratados en el sitio. Cada una de estas guías cubre lo que esta deja deliberadamente de lado.
- RAG local: introducción
- Embeddings, base vectorial, división: el funcionamiento del RAG clásico, que conviene conocer para saber cuándo sigue siendo la opción adecuada. https://quelllm.fr/guide/rag-local-introduction
- Obsidian + LLM local
- Conectar un modelo local a una bóveda de Obsidian con los plugins Copilot y Smart Connections, para conversar con notas que escribes tú mismo. https://quelllm.fr/guide/obsidian-llm-local-ollama
- NotebookLM en local
- Las herramientas de código abierto que reproducen los cuadernos de fuentes y las respuestas citadas, sin wiki intermedio. https://quelllm.fr/guide/notebooklm-local-alternative
- Fine-tuning frente a RAG
- Karpathy menciona en su publicación, como vía de exploración, el ajuste fino de un modelo con los datos de su base. Esta guía ayuda a decidir si merece la pena el esfuerzo. https://quelllm.fr/guide/fine-tuning-vs-rag-choisir
- OpenCode + Ollama
- La instalación del agente utilizado aquí, el ajuste del contexto y los permisos. https://quelllm.fr/guide/opencode-ollama-agent-terminal
¿Un comentario, un error, una precisión? Avísanos, eso mejora la guía para todos.