En abril de 2026, Andrej Karpathy escribió un GitHub Gist. En él describe un método. Lo llama la LLM Wiki.
Cuatro equipos construyeron lo mismo después. Cognition construyó DeepWiki. Factory construyó AutoWiki. LangChain lanzó OpenWiki. Garry Tan lanzó GBrain.
El método es el mismo en los cuatro sistemas. Un LLM lee tus documentos fuente una vez. Escribe la información en páginas Markdown. Mantiene las páginas actualizadas cuando las fuentes cambian. El agente lee estas páginas. El agente no vuelve a leer los documentos fuente para cada pregunta.
La gente llama a estos sistemas agent wikis. Este artículo te explica qué son. Te explica qué construyó cada equipo. Te explica los límites del método. También te explica una diferencia importante que muchos pasan por alto.
La idea: compilar en la ingesta, no en la consulta
El método habitual para darle a un modelo un gran conjunto de documentos es la recuperación. Pones los documentos en una base de datos. Divides los documentos en partes. Creas embeddings para las partes. Para cada pregunta, el sistema encuentra las partes relacionadas.
Este método funciona. También tiene un problema. El sistema no conserva los resultados. Construye cada respuesta desde las partes en bruto nuevamente. La décima respuesta no es mejor que la primera. Pagas el costo del trabajo diez veces.
Un agent wiki traslada este costo. El modelo hace el trabajo una vez, cuando lee la fuente. Escribe los resultados en páginas. Las páginas permanecen.
El modelo realiza estos pasos cuando entra una nueva fuente. Lee la fuente. Cambia las páginas relacionadas. Corrige los resúmenes. Marca la información que contradice las páginas.
Ambos métodos son correctos. Se diferencian en dos aspectos. La primera diferencia es cuándo pagas el costo. La segunda diferencia es qué queda después de la pregunta.
Cada sistema tiene las mismas tres capas.
La capa 1 son los documentos fuente. Estos son tus artículos, documentos y repositorios. El modelo los lee. El modelo no los modifica.
La capa 2 es la wiki. La wiki es Markdown. El modelo escribe toda la wiki. La wiki contiene resúmenes, páginas para cada tema y enlaces entre las páginas.
La capa 3 es el archivo de esquema. Este archivo le indica al modelo la estructura de la wiki. También le indica qué tareas debe realizar. El archivo habitual es CLAUDE.md o AGENTS.md. Este archivo convierte al modelo en un mantenedor correcto de la wiki.
El sistema realiza tres operaciones.
Ingesta: el modelo lee una nueva fuente. Luego, el modelo escribe los datos en cada página relacionada.
Consulta: le haces una pregunta a la wiki. Puedes escribir una buena respuesta en la wiki como una nueva página.
Lint: el modelo examina la wiki. Encuentra información que se contradice. Encuentra información que está demasiado desactualizada. Encuentra páginas sin enlaces.
Por qué funciona:
Las wikis humanas se vuelven incorrectas con el tiempo. La causa es específica. La parte difícil no es leer las fuentes. La parte difícil no es tener las ideas. La parte difícil es el mantenimiento.
El mantenimiento tiene estas tareas. Debes corregir los enlaces entre las páginas. Debes mantener los resúmenes correctos. Debes comparar cada nuevo documento con las páginas que existen.
Este trabajo no se detiene. El trabajo no da recompensa. Un equipo ocupado detiene este trabajo primero. Luego, la wiki se vuelve incorrecta. Entonces, la gente no la usa.
Un modelo hace este trabajo sin problema. El modelo no se aburre. El modelo no olvida un enlace. El modelo puede cambiar quince archivos en una sola operación.
La idea es antigua. Vannevar Bush describió el Memex en 1945. El Memex es un almacén personal de documentos con enlaces entre ellos. Bush no tenía respuesta para el mantenimiento. El modelo es la respuesta.
De dónde viene el nombre
Lee el Gist de Karpathy directamente. Es más preciso que los resúmenes del mismo.
Escribe esto sobre el método habitual: "el LLM está redescubriendo el conocimiento desde cero en cada pregunta. No hay acumulación".
Su método es compilar la información, y no recuperarla. Entonces "el conocimiento se compila una vez y luego se mantiene actualizado, no se re-deriva en cada consulta". El resultado es "un artefacto persistente y que se acumula".
Tú no escribes la wiki. Él escribe: "Nunca (o rara vez) escribes la wiki tú mismo, el LLM escribe y mantiene todo". Él usa el agente y Obsidian juntos. Él escribe: "Obsidian es el IDE; el LLM es el programador; la wiki es el código base".
El Gist da un límite de tamaño. Muchos resúmenes no incluyen este límite. El método sin embeddings "funciona sorprendentemente bien a escala moderada (~100 fuentes, ~cientos de páginas) y evita la necesidad de infraestructura RAG basada en embeddings".
Para más fuentes, el Gist te dice que agregues búsqueda. Da qmd como ejemplo. El Gist describe qmd como "un motor de búsqueda local para archivos Markdown con búsqueda híbrida BM25/vectorial y re-ranking con LLM".
Por lo tanto, la regla es sobre el tamaño. La regla no es sobre el reemplazo. No uses infraestructura de recuperación cuando el conjunto de fuentes es pequeño. Agrega recuperación cuando el conjunto de fuentes se vuelva grande.
Lo que realmente construyeron los laboratorios
Aquí es donde el patrón deja de ser una idea y se convierte en ingeniería, y las diferencias entre las implementaciones son la parte útil.
Cognition: DeepWiki, la wiki como servicio público
Cognition aplicó el método a los repositorios públicos en GitHub. Reemplaza github.com con deepwiki.com en la URL de un repositorio público. Luego obtienes una wiki para ese código base. La wiki tiene un resumen de la arquitectura, un índice de archivos, un gráfico de dependencias y búsqueda. La wiki tiene enlaces a la fuente (Cognition).
Más de 50,000 de los repositorios públicos más grandes tienen una wiki. La lista incluye MCP y LangChain.
El segundo punto es más importante. La wiki no es el producto. La wiki es infraestructura de recuperación para el agente. Devin usa la wiki para encontrar el código relacionado en un código base. DeepWiki es, por lo tanto, la capa compilada debajo de la búsqueda de código en Devin (Devin Docs).
Factory: AutoWiki, documentación como un artefacto de compilación
Factory aplicó el método a la integración continua. Factory escribe que la documentación debe ser un artefacto de compilación, y no un proyecto separado. La documentación proviene de la fuente. Tiene la estructura del código base. Cambia cuando el repositorio cambia (Factory).
El método para hacer la wiki tiene dos pases. El pase 1 es un escaneo estructural. Lee el archivo README, los manifiestos del paquete, la configuración de CI y los puntos de entrada. El pase 2 es un escaneo semántico. Lee las rutas, los endpoints de API, las clases de servicio, los esquemas de base de datos y los feature flags.
Factory divide el trabajo entre agentes especializados. Cada agente obtiene una parte del repositorio. Cada agente obtiene suficiente contexto para escribir una buena página. Este método previene un problema conocido: un solo agente escribe documentación deficiente para un repositorio grande.
Factory mantiene la wiki correcta con infraestructura, y no con disciplina. El comando /wiki vuelve a hacer la wiki. El comando /install-wiki escribe un flujo de trabajo de CI. Este flujo de trabajo vuelve a hacer la wiki en cada push a la rama predeterminada. Para GitHub, la wiki va a la pestaña wiki del repositorio (Factory Docs).
LangChain: OpenWiki, y el salto del código a todo
LangChain lanzó OpenWiki como software de código abierto. OpenWiki es una herramienta CLI. Escribe y mantiene documentación de agente para un código base. LangChain luego lanzó OpenWiki Brains, que tiene dos modos. Code Brain es el primer modo, para un repositorio. Personal Brain es el segundo modo, para tus propias fuentes (LangChain).
Personal Brain es el cambio importante. Lee datos de Gmail, Notion, repositorios git, X, Hacker News y búsqueda web. Escribe todos estos datos en una wiki local en Markdown. El agente lee esta wiki. El método cambió de documentación de un repositorio a documentación de tu trabajo.
Cada equipo tomó la misma decisión sobre la salida. La salida no es texto para que una persona lo lea. La salida es Markdown estructurado para el contexto del LLM. Tiene encabezados, enlaces entre páginas y resúmenes. La estructura permite que un agente encuentre la información relacionada rápidamente. El lector de la wiki es un modelo.
GBrain: la versión de código abierto a escala personal
GBrain aplica el método a un almacén de conocimiento personal, y no a un código base. GBrain usa Markdown en un repositorio git. Tiene un archivo de esquema. Hace un gráfico de enlaces entre temas automáticamente.
GBrain muestra que el método necesita muy poca infraestructura. No tiene base de datos vectorial. No tiene servicio. Tiene archivos. Un modelo mantiene los archivos. Una persona puede leer los archivos.
La matriz de técnicas
Los cuatro sistemas tienen la misma estructura. Usan Markdown en git. Usan un archivo de esquema. Compilan en la ingesta. Vuelven a hacer la wiki cuando las fuentes cambian. Escriben las páginas para que un agente las lea. Cuatro equipos resolvieron cuatro problemas diferentes e hicieron la misma estructura. Este acuerdo es una buena evidencia de que la estructura es correcta.
Los sistemas son diferentes en el mantenimiento. Factory hace el mantenimiento en CI. Los otros tres sistemas hacen el mantenimiento cuando una persona ejecuta un comando. Sus wikis son, por lo tanto, tan correctas como el último comando.
Dónde se detiene
Límite 1 es el tamaño. Karpathy da este límite. El método sin embeddings es correcto para aproximadamente 100 fuentes. Para más páginas, debes agregar un motor de búsqueda. El Gist te dice que uses búsqueda BM25 y búsqueda vectorial juntas.
Límite 2 es la precisión. El modelo compila la información en la ingesta. Un resumen temprano puede eliminar un detalle de la fuente. Cada respuesta posterior tiene este error. La recuperación de las partes en bruto no tiene este problema. Intercambias el costo del trabajo repetido por el riesgo de pérdida de datos.
Límite 3 es la información desactualizada. Una página es tan correcta como la última actualización. Esta es la razón por la que el método de Factory es importante. Una wiki incorrecta es peor que ninguna wiki. La información incorrecta tiene el formato de información correcta.
Límite 4 es el costo. Pagas tokens para crear páginas. Puedes crear páginas que nadie lee. También pagas tokens para hacer lint de páginas que no cambiaron.
Una wiki no es memoria
Hay una diferencia que debes conocer. Las palabras en este campo aún no son precisas.
Mucha gente llama a estos sistemas memoria. LangChain llama a OpenWiki una capa de memoria wiki para agentes de IA. Otras personas dicen que una wiki le da memoria a un agente. La palabra memoria tiene dos significados diferentes aquí.
El primer significado es conocimiento de un conjunto de documentos. Una wiki hace esto. Compila los datos en tus documentos, tu repositorio o tu Gmail. Te dice lo que contienen los documentos.
El segundo significado es memoria de un usuario. Estos son datos diferentes. Incluye las preferencias de una persona. Incluye las decisiones de una persona. Incluye los métodos que un equipo rechazó. Incluye el resultado cuando un agente probó un método en una aplicación diferente.
La memoria de un usuario tiene una estructura diferente. Está relacionada con una persona, y no con un conjunto de documentos. Proviene de la interacción, y no de la ingesta. También debe hacer estas tareas para cada usuario: corregir información que se contradice, eliminar información que está demasiado desactualizada, mantener la fuente de cada elemento y eliminar datos a solicitud.
Una wiki hace la primera tarea correctamente. Una wiki no hace la segunda tarea. Tu wiki de Gmail le dice al agente qué hay en tu Gmail. No le dice al agente que cambiaste una decisión en una conversación el martes. No le dice al agente que un método ya falló para ti.
Una capa de memoria hace la segunda tarea. Mem0 es un ejemplo. Mantiene cada memoria con un user_id. La memoria se mueve así con la persona entre sesiones, aplicaciones y agentes. Cambia un hecho en su lugar cuando el hecho cambia. No agrega un nuevo registro cada vez.
Los dos sistemas no son alternativas. Usa ambos. El error no es no usar una wiki. El error es pensar que una wiki te da la memoria de un usuario.
Resumen
La idea en los agent wikis es correcta. Compila el conocimiento una vez. Luego, mantenlo correcto. No lo construyas de nuevo para cada pregunta. El mantenimiento detuvo las wikis humanas, y un modelo hace el mantenimiento sin costo. Cuatro equipos construyeron la misma estructura en pocos meses. Esto es evidencia sólida.
Haz estas tres cosas. Compila tus documentos en páginas cuando el conjunto de documentos sea estable y lo leas con frecuencia. Agrega recuperación cuando el conjunto de documentos se vuelva grande, como te dice el Gist. Mantén la diferencia entre el conocimiento de un conjunto de documentos y la memoria de un usuario. Una wiki te da lo primero. Una wiki no te da lo segundo.
In Context #17
Este blog es parte de In Context, una serie de blogs de @mem0ai que cubre la memoria de agentes de IA y la ingeniería de contexto.
Mem0 es una capa de memoria inteligente y de código abierto diseñada para LLMs y agentes de IA para proporcionar interacciones a largo plazo, personalizadas y conscientes del contexto a través de sesiones.
- Obtén tu clave API gratuita aquí: app.mem0.ai
- o auto-aloja mem0 desde nuestro repositorio de código abierto en GitHub
Referencias
- Andrej Karpathy, LLM Wiki (GitHub Gist, abril de 2026)
- qmd: búsqueda híbrida local BM25/vectorial para Markdown
- Cognition, DeepWiki: documentación de IA para cualquier repositorio
- Devin Docs, DeepWiki
- Factory, Presentando AutoWiki
- Documentación de Factory, Resumen de AutoWiki
- langchain-ai/openwiki (GitHub)
- LangChain, Memoria Wiki
- garrytan/gbrain (GitHub)
- Vannevar Bush, As We May Think (The Atlantic, 1945)
- Mem0
![[Memorándum] Los jefes están prescindiendo de los subordinados con bajo rendimiento](/cdn-cgi/image/width=1920,quality=90,format=auto,metadata=none/https%3A%2F%2Fcms-assets.youmind.com%2Fmedia%2F1784827522698_408j7z_HN3Kb76awAAvvjF.jpg)
