En abril de 2026, Andrej Karpathy escribió un GitHub Gist. En él describe un método. Lo llama el 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 sola 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 en cada consulta.
La gente llama a estos sistemas wikis de agentes. Este artículo te explica qué son. Te dice lo que construyó cada equipo. Te dice los límites del método. También te dice una diferencia importante que muchos pasan por alto.
La idea: compilar al ingerir, no al consultar
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. Generas embeddings para las partes. Para cada pregunta, el sistema encuentra las partes relevantes.
Este método funciona. También tiene un problema. El sistema no conserva los resultados. Construye cada respuesta desde las partes originales de nuevo. La décima respuesta no es mejor que la primera. Pagas el costo del trabajo diez veces.
Un wiki de agente 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 llega una nueva fuente. Lee la fuente. Modifica 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 el wiki. El wiki está en markdown. El modelo escribe todo el wiki. El 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 del wiki. También le dice qué tareas debe realizar. El archivo habitual es CLAUDE.md o AGENTS.md. Este archivo convierte al modelo en un mantenedor correcto del wiki.
El sistema realiza tres operaciones.
Ingesta: el modelo lee una nueva fuente. Luego escribe los datos en cada página relacionada.
Consulta: le haces una pregunta al wiki. Puedes escribir una buena respuesta en el wiki como una nueva página.
Lint: el modelo examina el wiki. Encuentra información contradictoria. Encuentra información demasiado antigua. Encuentra páginas sin enlaces.
Por qué funciona:
Los wikis humanos se vuelven incorrectos 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 actualizados. Debes comparar cada nuevo documento con las páginas existentes.
Este trabajo no se detiene. El trabajo no da recompensa. Un equipo ocupado abandona este trabajo primero. Entonces el wiki se vuelve incorrecto. Entonces la gente no lo usa.
Un modelo realiza este trabajo sin problema. El modelo no se aburre. El modelo no olvida un enlace. El modelo puede modificar 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 una 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 que se hacen de él.
Escribe esto sobre el método habitual: "el LLM está redescubriendo 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 se mantiene actualizado, no se vuelve a derivar en cada consulta". El resultado es "un artefacto persistente que se acumula".
No escribes el wiki tú. Él escribe: "Nunca (o rara vez) escribes el wiki tú mismo, el LLM escribe y mantiene todo". Él usa el agente y Obsidian juntos. Escribe: "Obsidian es el IDE; el LLM es el programador; el wiki es el código fuente".
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 una 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 reordenamiento con LLM".
Por lo tanto, la regla es sobre el tamaño. La regla no es sobre 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, el wiki como servicio público
Cognition aplicó el método a los repositorios públicos de GitHub. Reemplaza github.com por deepwiki.com en la URL de un repositorio público. Entonces obtienes un wiki para ese código fuente. El wiki tiene un resumen de arquitectura, un índice de archivos, un gráfico de dependencias y búsqueda. El wiki tiene enlaces a la fuente (Cognition).
Más de 50,000 de los repositorios públicos más grandes tienen un wiki. La lista incluye MCP y LangChain.
El segundo punto es más importante. El wiki no es el producto. El wiki es infraestructura de recuperación para el agente. Devin usa el wiki para encontrar el código relacionado en un código fuente. 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 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 fuente. Cambia cuando el repositorio cambia (Factory).
El método para hacer el wiki tiene dos pasos. El paso 1 es un escaneo estructural. Lee el archivo README, los manifiestos de paquetes, la configuración de CI y los puntos de entrada. El paso 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 recibe una parte del repositorio. Cada agente recibe suficiente contexto para escribir una buena página. Este método evita un problema conocido: un solo agente escribe documentación deficiente para un repositorio grande.
Factory mantiene el wiki actualizado con infraestructura, no con disciplina. El comando /wiki vuelve a generar el wiki. El comando /install-wiki escribe un flujo de trabajo de CI. Este flujo de trabajo vuelve a generar el wiki en cada push a la rama predeterminada. Para GitHub, el 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 la documentación de un agente para un código fuente. 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 un wiki local en markdown. El agente lee este 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 relevante rápidamente. El lector del 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, no a un código fuente. GBrain usa markdown en un repositorio git. Tiene un archivo de esquema. Genera automáticamente un gráfico de enlaces entre temas.
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 al ingerir. Vuelven a generar el wiki cuando las fuentes cambian. Escriben las páginas para que un agente las lea. Cuatro equipos resolvieron cuatro problemas diferentes y crearon la misma estructura. Este acuerdo es una buena evidencia de que la estructura es correcta.
Los sistemas se diferencian en el mantenimiento. Factory hace el mantenimiento en CI. Los otros tres sistemas hacen el mantenimiento cuando una persona ejecuta un comando. Por lo tanto, sus wikis son tan correctos como el último comando.
Dónde se detiene
Límite 1: 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: precisión. El modelo compila la información al ingerir. Un resumen temprano puede eliminar un detalle de la fuente. Cada respuesta posterior tiene este error. La recuperación desde las partes originales no tiene este problema. Intercambias el costo del trabajo repetido por el riesgo de pérdida de datos.
Límite 3: 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. Un wiki incorrecto es peor que ningún wiki. La información incorrecta tiene el formato de información correcta.
Límite 4: costo. Pagas tokens para crear páginas. Puedes crear páginas que nadie lee. También pagas tokens para hacer lint a páginas que no cambiaron.
Un wiki no es memoria
Hay una diferencia que debes conocer. Las palabras en este campo aún no son precisas.
Muchas personas llaman memoria a estos sistemas. LangChain llama a OpenWiki una capa de memoria wiki para agentes de IA. Otras personas dicen que un 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. Un 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, no con un conjunto de documentos. Proviene de la interacción, no de la ingesta. También debe hacer estas tareas para cada usuario: corregir información contradictoria, eliminar información demasiado antigua, mantener la fuente de cada elemento y eliminar datos a solicitud.
Un wiki hace correctamente la primera tarea. Un wiki no hace la segunda tarea. Tu wiki de Gmail le dice al agente lo que 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 de posición cuando el hecho cambia. No agrega un nuevo registro cada vez.
Los dos sistemas no son alternativas. Usa ambos. El error no es usar un wiki. El error es pensar que un wiki te da memoria de un usuario.
Resumen
La idea en los wikis de agentes es correcta. Compila el conocimiento una vez. Luego mantenlo actualizado. No lo reconstruyas para cada pregunta. El mantenimiento detuvo a los wikis humanos, 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 conocimiento de un conjunto de documentos y memoria de un usuario. Un wiki te da lo primero. Un wiki no te da lo segundo.
In Context #17
Este blog es parte de In Context, una serie de blogs de @mem0ai sobre memoria de agentes de IA e 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
