LLM Wiki: entiende la nueva arquitectura de conocimiento en IA

Un LLM Wiki compila tus fuentes en una base de conocimiento persistente y con enlaces cruzados durante la ingestión, y luego responde a partir de esa base en lugar de volver a recuperar fragmentos en bruto cada vez. Así, el conocimiento se acumula a medida que añades fuentes, en lugar de reconstruirse desde cero con cada pregunta.

Voy a explicarte de dónde salió la idea del LLM Wiki, cómo se compara con la Retrieval-Augmented Generation (RAG) y si supone un cambio real en cómo los sistemas de IA gestionan el conocimiento.

Los orígenes del concepto LLM Wiki

La idea de LLM Wiki tomó forma en 2026, presentada por Andrej Karpathy y adoptada por un par de proyectos de código abierto que la convirtieron en algo que puedes ejecutar de verdad.

La idea es sencilla. En 2026, muchos sistemas de IA pasan gran parte del tiempo releyendo los mismos documentos. Subes un PDF, el modelo recupera fragmentos, responde a una pregunta y sigue. La semana siguiente subes otro PDF sobre el mismo tema, y el modelo hace exactamente lo mismo. Nada se arrastra de una vez a otra.

El mayor cambio es que recuperación y compilación son trabajos distintos.

Por ejemplo:

• Sistemas centrados en recuperación encuentran fragmentos de texto relevantes en el momento de la consulta y se los pasan al modelo como contexto. El modelo trabaja con lo que saque el recuperador.
• Sistemas centrados en compilación leen cada fuente una vez durante la ingestión, extraen lo importante y lo escriben en una base de conocimiento estructurada. Luego el modelo responde desde esa base.

Un LLM Wiki pertenece a la segunda categoría. Cuando añades una fuente nueva, el modelo la lee, actualiza páginas existentes, crea otras nuevas cuando hace falta y señala contradicciones con lo ya archivado. La base de conocimiento crece con cada fuente que añades, y el modelo gana mejor base desde la que responder cada vez.

Este es el primer rompimiento concreto con el paradigma centrado en recuperación que ha dominado desde que RAG se hizo estándar. RAG trata cada consulta como una búsqueda nueva sobre documentos en bruto. Un LLM Wiki sitúa el trabajo en la ingestión y convierte la consulta en una lectura de una base ya pensada y compilada.

¿Qué es un LLM Wiki?

Un LLM Wiki es una base de conocimiento persistente, mantenida por IA, que sintetiza de forma continua la información de documentos fuente en páginas estructuradas e interconectadas.

Tres aspectos lo distinguen de una carpeta de archivos o de un vector store.

• Persistente: las páginas se crean una vez y se actualizan cuando llegan nuevas fuentes. No hay que volver a derivar nada en tiempo de consulta porque la síntesis ya está escrita.
• Actualizado de forma continua: cada fuente ingerida desencadena ediciones en todo el wiki: páginas nuevas para entidades nuevas, revisiones de resúmenes existentes, y notas cuando datos recientes contradicen afirmaciones antiguas.
• Doble audiencia: las páginas son legibles para personas y lo bastante estructuradas para que agentes de IA razonen sobre ellas. Markdown, enlaces cruzados y un diseño consistente hacen doble función.

La clave es que el wiki se convierte en la capa principal de conocimiento. Los documentos originales permanecen en almacenamiento bruto como rastro de auditoría, pero nadie los consulta directamente. Chats, agentes y asistentes de investigación leen el wiki porque ahí está la versión compilada y referenciada del conocimiento.

La arquitectura de LLM Wiki

La arquitectura es más bien una canalización de tres etapas. Entran fuentes, el modelo las compila en páginas del wiki y las aplicaciones de IA leen esas páginas. 

Arquitectura de LLM Wiki

Te explico cada etapa.

Documentos fuente

Se puede ingerir cualquier contenido basado en texto. Por ejemplo:

• Documentación y PDFs
• Notas personales y transcripciones de reuniones
• Repositorios de código
• Contenido web recortado de artículos o extraído de sitios

Las fuentes en bruto se colocan en almacenamiento inmutable. Una vez ingeridas, el modelo las lee, pero nunca las modifica, lo que te da un rastro de auditoría limpio desde cualquier afirmación del wiki hasta su fuente.

Compilación de conocimiento

Aquí se crea el wiki. Cuando llega una fuente nueva, el modelo ejecuta un conjunto de operaciones:

• Extracción de conceptos: se identifican entidades, temas, definiciones y afirmaciones a partir del texto fuente.
• Actualización de páginas existentes: si una entidad o concepto ya tiene página, el modelo la revisa con la información nueva y señala contradicciones.
• Creación de páginas nuevas: todo lo que no encaje en una página existente obtiene la suya propia.
• Enlazado de temas relacionados: se añaden referencias cruzadas en ambos sentidos para que las páginas sigan conectadas a medida que crece el wiki.

Una sola fuente ingerida puede "actualizar" de 10 a 15 páginas en este paso. Ese es el objetivo: el trabajo de conectar material nuevo con el conocimiento existente ocurre una vez, en la ingestión, no en cada consulta como con RAG.

Aplicaciones de IA

El wiki está pensado para que lo lean distintos tipos de consumidores. Por ejemplo:

• Sistemas de chat que responden sobre el conocimiento compilado en lugar de documentos en bruto.
• Asistentes de investigación que siguen enlaces cruzados para construir una visión de conjunto de un tema.
• Agentes de software que usan el wiki como memoria duradera en tareas de larga duración.
• Sistemas de conocimiento corporativo que exponen el wiki a herramientas internas, cuadros de mando o servidores MCP.

El wiki está en medio. Por un lado entran fuentes, por el otro leen las aplicaciones, y la capa de compilación mantiene ambos extremos sincronizados.

LLM Wiki vs RAG tradicional

La principal diferencia entre el RAG tradicional y un LLM Wiki es cuándo ocurre el trabajo.

RAG tradicional

RAG recupera fragmentos de documentos en tiempo de consulta. Haces una pregunta, una búsqueda por embeddings extrae los k fragmentos más relevantes de un vector store y esos fragmentos se añaden al contexto del modelo junto a tu pregunta. El modelo genera una respuesta desde ese contexto temporal y lo olvida todo al terminar.

El contexto es desechable. 

Los fragmentos que respondieron tu última pregunta desaparecen del contexto en cuanto el modelo acaba de responder. Si mañana haces una pregunta relacionada, el recuperador vuelve a ejecutarse, extrae fragmentos otra vez y el modelo vuelve a sintetizar. No se construye nada entre consultas.

LLM Wiki

Un LLM Wiki compila la información durante la ingestión. Cuando añades una fuente, el modelo la lee una vez, escribe lo importante en páginas estructuradas, actualiza referencias cruzadas y guarda el resultado como markdown duradero. El tiempo de consulta pasa a ser leer de la base compilada en lugar de volver a sintetizar desde fragmentos en bruto.

El conocimiento es persistente y evoluciona. 

Cada nueva fuente desencadena ediciones en todo el wiki, de modo que se señalan contradicciones, se revisan resúmenes antiguos y las conexiones entre temas se densifican con el tiempo.

Compensaciones

Ningún enfoque es universalmente mejor. Optimizan cosas distintas.

Ten en cuenta algunos puntos:

• Actualidad: RAG tiene ventaja aquí porque lee directamente de las fuentes en tiempo de consulta. Si actualizas los documentos, la próxima consulta verá el cambio al instante. Un LLM Wiki debe reingerir las fuentes para actualizar sus páginas, así que hay un desfase entre la verdad en bruto y el conocimiento compilado.
• Precisión: un LLM Wiki gana cuando las preguntas requieren síntesis entre muchas fuentes, porque esa síntesis ya está hecha y revisada. RAG puede perder conexiones cuando los fragmentos relevantes abarcan más trozos de los que caben en la ventana de contexto, porque nunca ve el panorama completo de una vez.
• Mantenimiento: RAG roza el cero mantenimiento una vez configurado el vector store porque la indexación es mecánica. Un LLM Wiki necesita un cuidado activo: por ejemplo, pasadas de lint para detectar afirmaciones obsoletas, comprobaciones de contradicciones y revisiones puntuales para podar páginas huérfanas. La contrapartida es que un wiki mantenido se enriquece con el tiempo, mientras que un índice RAG se queda plano.
• Escalabilidad: RAG escala de forma predecible con el número de documentos porque la recuperación es un problema de búsqueda. Un LLM Wiki escala con la capacidad del modelo para mantener coherente el conocimiento compilado a medida que crece. A partir de cierto tamaño, los wikis necesitan sus propios ficheros de índice, herramientas de búsqueda o capas de embeddings para seguir siendo navegables.

Aquí tienes un resumen comparativo:

LLM Wiki frente a RAG

En la práctica, RAG y los LLM Wikis también son complementarios. Algunas implementaciones ejecutan RAG sobre el propio wiki cuando este crece más de lo que puede manejar un archivo de índice.

Por qué los agentes de IA se benefician de un LLM Wiki

Los agentes de IA sufren más que los sistemas de chat el problema de la falta de memoria. Una sola conversación puede tolerar la rerecuperación, pero los agentes pueden funcionar durante horas o días y redescubrir los mismos hechos en decenas de tareas. Un LLM Wiki les da un lugar donde guardar lo que aprenden para no tener que volver a aprenderlo.

Estos son un par de ámbitos donde el conocimiento persistente muestra más potencial:

• Desarrollo de software: un agente que programa sobre una base de código durante semanas acumula conocimiento sobre módulos, convenciones, bugs pasados y decisiones de diseño. Sin un wiki, ese contexto se reconstruye en cada sesión. Con uno, el agente lee las páginas compiladas y continúa donde lo dejó la sesión anterior.
• Investigación de larga duración: un agente encargado de seguir un tema a través de cientos de artículos no puede mantenerlo todo en contexto. Un wiki le da un lugar donde archivar resúmenes y volver a una visión en evolución sin releer todo el corpus.
• Asistentes para la empresa: asistentes desplegados dentro de una compañía afrontan las mismas preguntas de distintos empleados a diario. Un wiki permite responder desde conocimiento interno compilado en lugar de buscar las mismas páginas en cada petición.
• Memoria organizativa: los equipos pierden contexto cuando la gente se va o terminan las reuniones. Un LLM Wiki alimentado con transcripciones, tickets y documentos mantiene ese contexto conectado.

Si se implementa bien, verás que un LLM Wiki rinde en tres frentes:

1. Menos búsquedas repetidas: un agente que lee de una página compilada no necesita repetir la misma búsqueda web o consulta al vector que hizo ayer.
2. Contexto más rico: las páginas del wiki ya contienen información sintetizada, así que el agente inicia cada tarea con una base más densa y mejor conectada que la que le darían fragmentos en bruto.
3. Aprendizaje acumulativo: cada sesión añade al wiki, y la siguiente se beneficia de lo que descubrió la anterior. Así consigues que un agente realmente mejore su trabajo con el tiempo en lugar de reiniciarse en cada prompt.

Cómo construir un LLM Wiki

El flujo de trabajo para construir un wiki es un bucle. Entran fuentes, se escriben y reescriben páginas, y todo se va afinando a medida que crece el corpus.

Bucle de construcción de LLM Wiki

• Ingiere documentos. El primer paso es llevar las fuentes al almacenamiento en bruto. Los documentos se leen una vez y se mantienen inmutables para que toda afirmación posterior se remonte a una fuente concreta. La ingestión puede ser un archivo, un lote o un flujo desde una carpeta que el modelo vigila.
• Identifica entidades y conceptos. Para cada fuente nueva, el modelo extrae lo que importa: entidades con nombre, conceptos clave, afirmaciones, definiciones y relaciones. Aquí es cuando el texto no estructurado se convierte en algo que el wiki puede archivar. Esta pasada también contrasta con el wiki existente para ver qué ya está cubierto y qué es nuevo.
• Genera o actualiza páginas. Las entidades nuevas obtienen páginas nuevas. Las existentes se revisan con la información reciente. Si la nueva fuente contradice una afirmación existente, el modelo la señala en la página en lugar de sobrescribirla. Una sola fuente ingerida suele modificar de 10 a 15 páginas porque las fuentes suelen tratar más de un tema.
• Mantén los enlaces. Se añaden referencias cruzadas en ambos sentidos para que las páginas sigan conectadas. Si una página nueva sobre RAG menciona bases de datos vectoriales y ya existe una página de vector databases, se enlazan ambas.
• Refina el conocimiento de forma continua. Pasadas periódicas de lint detectan problemas que se acumulan con el tiempo: contradicciones entre páginas, afirmaciones obsoletas sustituidas por fuentes más recientes, páginas huérfanas sin enlaces, y conceptos importantes mencionados de pasada sin su propia página. Este paso mantiene el wiki sano a escala.

Los detalles dependen de tu stack, pero el patrón se repite en todas las implementaciones. Ingerir, extraer, escribir, enlazar, refinar… y volver a empezar.

Funciones comunes de los sistemas LLM Wiki

La mayoría de implementaciones de LLM Wiki comparten el mismo conjunto de funciones. Los detalles difieren, pero los bloques de construcción son los mismos.

Compilación automática de conocimiento

El wiki se escribe solo. Cuando se ingiere una fuente, el modelo extrae lo importante y lo archiva en páginas sin intervención humana. El mantenimiento manual mata a los wikis tradicionales: a las personas les cansa actualizar enlaces y resúmenes. A los modelos no, y por eso esta función hace que el patrón funcione.

Páginas enlazadas

Cada página se conecta con otras relacionadas mediante referencias cruzadas. Cuando una página sobre transformers menciona attention mechanisms, ambas páginas se enlazan. El resultado es un grafo navegable que puedes recorrer siguiendo referencias, la manera de descubrir conexiones que no sabías que existían.

Atribución de fuentes

Cada afirmación en cada página se remonta a una fuente específica. Los documentos en bruto permanecen inmutables para que siempre puedas verificar de dónde salió la información. Esto importa por dos razones: te da un rastro de auditoría para comprobar la precisión y permite al modelo retirar afirmaciones limpiamente cuando se elimina una fuente.

Grafos de conocimiento

La estructura enlazada del wiki es en sí misma un grafo de conocimiento. Los nodos son páginas, las aristas son referencias cruzadas y la forma del grafo te dice de qué trata realmente el corpus. Las páginas hub afloran alrededor de conceptos importantes, las páginas huérfanas señalan lagunas y los clústeres densos muestran las áreas que el wiki conoce mejor.

Memoria persistente

El wiki está disponible entre sesiones. El contexto de un chat desaparece cuando termina la conversación, pero las páginas del wiki se guardan en disco como markdown. Esto convierte a un modelo de chat en algo capaz de llevar conocimiento adelante durante días, proyectos y ejecuciones de agentes.

Actualizaciones continuas

Las nuevas fuentes desencadenan revisiones de las páginas existentes, no solo añadidos. Si un paper del mes pasado contradice lo que se escribió hace seis meses, el wiki lo señala y actualiza las páginas afectadas. La base de conocimiento se acerca a lo correcto con el tiempo en lugar de acumular afirmaciones caducadas.

Estas funciones no son independientes. Un wiki sin atribución de fuentes no es fiable. Del mismo modo, un wiki sin actualizaciones continuas se queda rancio, y un wiki sin páginas enlazadas es solo una carpeta de resúmenes. El valor viene de tenerlas todas funcionando en conjunto.

Aplicaciones reales de los LLM Wikis

El patrón que he descrito es general, así que repasemos algunas aplicaciones reales donde un LLM Wiki puede ser útil, incluso más que RAG.

Literatura de investigación

Quien sigue un tema a través de decenas o cientos de artículos se topa con el mismo problema: los papers se acumulan más rápido de lo que puedes procesarlos. Un LLM Wiki lee cada paper cuando llega, extrae las afirmaciones, las archiva bajo los conceptos relevantes y señala contradicciones con lo ya leído. El resultado es una síntesis viva que sigue el ritmo del campo, en lugar de una carpeta de PDFs que nunca leerás.

Documentación de ingeniería

Las bases de código acumulan deuda de documentación que suele crecer sprint a sprint. Muchas veces, las decisiones de diseño se toman en hilos de Slack y las notas de arquitectura viven en el Notion de alguien. El único artefacto que seguro está al día es el código. Un wiki alimentado por el codebase, comentarios, pull requests y documentación interna puede compilar una imagen del sistema conectada al código. Las personas ingenieras pueden preguntar al wiki en lugar de a quien escribió el módulo hace tres años.

Bases de conocimiento empresariales

Las empresas acumulan conocimiento entre tickets, transcripciones de reuniones, especificaciones de producto y wikis internos. Un LLM Wiki puede ingerir de todas ellas y compilar una única capa de conocimiento que se mantenga al día. Las personas empleadas consultan una vez, en lugar de buscar en cuatro herramientas distintas.

Gestión del conocimiento personal

Las apps de notas han resuelto el almacenamiento, pero no la síntesis. Sigues teniendo cientos de notas, artículos y subrayados, y no vas a revisarlos casi nunca. Un wiki alimentado por tu bóveda de Obsidian, por ejemplo, puede convertir ese montón de notas en un cuerpo de conocimiento compilado que sí puedes consultar. 

Memoria para agentes de IA

Los agentes que corren durante horas o días necesitan un lugar donde guardar lo que aprenden. El wiki les da una memoria duradera reutilizable entre sesiones: qué funcionó, qué no, qué archivos ya leyeron, qué caminos intentaron. Esto es especialmente útil para agentes construidos sobre Claude Code u herramientas similares, donde se trabaja sobre el mismo codebase a lo largo de muchas sesiones y el contexto de ejecuciones anteriores hace eficiente la actual.

Implementaciones actuales de LLM Wiki

El espacio de LLM Wiki en 2026 está en fase temprana. La mayoría de lo que existe es de código abierto y lo construyen personas o equipos pequeños. Está lejos de donde está RAG hoy.

El gist original de Karpathy es donde empezaron muchas implementaciones. Describe el patrón con suficiente detalle como para que cualquiera con un agente LLM pueda construir su propia versión pegando el documento en Claude Code o una herramienta similar. La mayoría de los wikis actuales empiezan como proyectos personales basados en una idea compartida.

Los esfuerzos open source son donde se está puliendo la idea. Proyectos como llm-wiki.net publican su código con licencias permisivas para que otros puedan bifurcarlo, ampliarlo o adaptarlo a sus flujos de trabajo. La ventaja es que puedes ver exactamente qué hace el wiki y cambiarlo cuando tus necesidades no encajan con el valor por defecto.

Los enfoques local-first corren íntegramente en tu máquina. Las fuentes se guardan en disco, el wiki es una carpeta de archivos markdown y el modelo lee y escribe a través de un agente local. Obsidian es el front-end más habitual porque ya está pensado para markdown y referencias cruzadas. Esto te da máximo control: las fuentes no salen de tu equipo y puedes inspeccionar cada página que escribe el modelo.

Las implementaciones hospedadas empiezan a aparecer, pero son menos comunes. El patrón encaja peor con el modelo SaaS que RAG porque el wiki debe ser tuyo: tus fuentes, tus páginas, tus decisiones sobre qué archivar. Las versiones hospedadas funcionan mejor para wikis de equipo, donde el valor del conocimiento compartido compensa el coste de alojar fuentes en la infraestructura de terceros.

Pero a julio de 2026, nada de esto está acabado. Aún se están resolviendo cosas, y la mayoría de proyectos actuales son prototipos.

Ventajas y limitaciones

El patrón LLM Wiki tiene puntos fuertes y costes. Conviene conocer ambos antes de decidirte a construir uno.

Ventajas

• Conocimiento persistente: el wiki sigue disponible más allá del final de una sesión. Lo que el modelo dedujo el mes pasado sigue en la página hoy, y el trabajo nuevo se apoya en ello en lugar de empezar de cero.
• Síntesis reutilizable: el trabajo de conectar fuentes ocurre una vez, en la ingestión. Cada consulta posterior lee del resultado compilado en lugar de volver a sintetizar desde texto en bruto. Ahorras cómputo y obtienes mejores respuestas porque el modelo ya ha hecho la parte de pensar.
• Menos recuperaciones repetidas: un wiki que ya tiene una página sobre un tema no necesita buscar en el corpus en bruto cada vez que aparece. Esto importa para agentes que funcionan durante horas y, de otro modo, repetirían las mismas búsquedas una y otra vez.
• Organización estructurada: las páginas y sus referencias te dan algo que puedes explorar y con lo que razonar, sobre todo si lo comparas con una carpeta de PDFs.

Limitaciones

• Mantener la información al día: el wiki debe reingerirse cuando cambian las fuentes. Si un documento se actualiza y no vuelves a ingerirlo, el wiki seguirá referenciando la versión antigua. RAG no tiene este problema porque lee fuentes vivas en tiempo de consulta.
• Retos de verificación: cada afirmación de una página la escribió un modelo. La atribución ayuda, pero aún tienes que confiar en que el modelo resumió bien la fuente.
• Mantenimiento: las comprobaciones de contradicciones y la reingestión no son gratis. Un wiki que no se mantiene se queda obsoleto, y el mantenimiento consume tiempo y cómputo aunque lo haga el modelo.
• Posible deriva de conocimiento: cada ingestión es una oportunidad para que el modelo introduzca pequeños errores. Con cientos de ingestiones, pueden acumularse. Una página que empezó siendo correcta puede acabar sutilmente equivocada tras suficientes revisiones.

Ideas equivocadas comunes sobre los LLM Wikis

Aunque LLM Wiki es un concepto nuevo, ya circulan algunas ideas equivocadas. Esto es lo que no aciertan.

Un LLM Wiki sustituye a RAG

No. Resuelven problemas distintos. RAG sirve para consultas rápidas sobre un corpus que cambia a menudo. Un LLM Wiki sirve para construir un cuerpo de conocimiento con el tiempo. Muchos sistemas reales usan ambos: RAG para la frescura sobre fuentes en bruto, y un wiki para la síntesis compilada por encima.

Es solo otra base de datos vectorial

Las bases vectoriales indexan texto para su recuperación. Un LLM Wiki escribe texto que un modelo ha leído, entendido y reorganizado. Una base vectorial te devuelve los fragmentos que metiste. Un wiki te devuelve páginas que no existían antes de ingerir la fuente. El resultado es totalmente distinto.

La base de conocimiento nunca necesita actualizarse

Falso. Las fuentes cambian, llegan fuentes nuevas y el modelo comete errores que hay que detectar. Un wiki que no se mantiene se queda obsoleto como cualquier documentación. La diferencia es que el modelo asume la mayor parte del mantenimiento, no que el mantenimiento desaparezca.

Solo beneficia a los agentes de IA

Los agentes son el caso más claro porque funcionan mucho tiempo y se benefician más de la memoria duradera, pero las personas también sacan valor. Piensa en una persona investigadora siguiendo un tema o una ingeniera trabajando en un codebase. O cualquiera que esté construyendo una base de conocimiento personal obtiene la misma síntesis compuesta. 

¿Se convertirán los LLM Wikis en una nueva arquitectura de IA?

Es pronto para saberlo, pero el camino probable es claro: el conocimiento persistente no sustituirá a los sistemas centrados en recuperación, convivirá con ellos, con RAG gestionando consultas en vivo y los wikis aportando contexto compilado y de largo recorrido. Las grandes incógnitas están en la validación y la escala: nadie ha resuelto del todo cómo detectar errores de modelo escritos en las páginas del wiki, y aún no se ha puesto a prueba el patrón en wikis muy grandes. MCP parece encajar de forma natural para exponer wikis a agentes, aunque la adopción empresarial irá más lenta por los requisitos adicionales de confianza.

El patrón aún no está establecido. Su avance dependerá de si se resuelven los problemas de mantenimiento y validación. Más preguntas se responden en las FAQs de abajo.

Conclusión

LLM Wiki es una de las ideas más interesantes de 2026 porque cambia lo que hace un sistema de IA cuando le pasas una fuente. En lugar de leer los mismos documentos en cada consulta, el modelo los lee una vez y los archiva en una base de conocimiento que mejora con el tiempo.

El concepto aún está emergiendo y las implementaciones actuales son tempranas, pero la idea es prometedora y apunta a algo mayor: los sistemas de IA pasan de un contexto desechable a un conocimiento persistente, y los LLM Wikis son de los primeros intentos serios de cómo se ve eso en la práctica.

Si quieres mantenerte al día de los avances pero te resulta confuso, apúntate a nuestro itinerario AI Fundamentals. Aprenderás la jerga y sabrás usar la IA con eficacia en el trabajo.