El LLM wiki en 490 páginas: lo que exigen de verdad 3 meses de conocimiento mantenido por agentes

Una base de conocimiento mantenida por agentes sobrevive cuando usted deja de ser su bibliotecario. Mi LLM wiki alcanzó las 490 páginas en 3 meses, y se mantiene unida gracias a tres decisiones: los agentes son dueños de la capa compilada, cada interacción pasa por una de seis operaciones con nombre propio, y un linter con 20 comprobaciones bloquea todo commit que no alcance el nivel exigido. Casi ninguna de esas páginas la escribí a mano.

Los segundos cerebros construidos a mano mueren siempre de la misma manera: el valor está en el mantenimiento, y el mantenimiento es justo lo que se detiene después de la tercera semana. Si usted tiene un cementerio de espacios de Notion abandonados, conoce el patrón. Los agentes de programación eliminan ese coste, porque nunca se aburren y arreglan con gusto 40 enlaces rotos un martes por la noche. La guía de la capa de conocimiento con IA explica cómo construir una en 20 minutos; este es el informe de mantener una en marcha con 490 páginas, con 3 meses de datos semanales de estado y los fallos incluidos.

• Separe la propiedad desde el principio. Una capa es suya para las fuentes, otra capa pertenece a los agentes para las páginas compiladas, y el conocimiento fluye en una sola dirección. Esta única decisión hace que el mantenimiento se pueda delegar.
• Un conjunto cerrado de operaciones vence a la improvisación. Seis operaciones con nombre propio (ingesta, actualización, consulta, validación, enriquecimiento, reorganización) evitan que los agentes inventen un flujo de trabajo nuevo en cada sesión.
• Las validaciones deterministas superan a las guías escritas. Los agentes respetan una comprobación que falla y pasan por alto las reglas en prosa. Un linter de 1.671 líneas con 20 comprobaciones se ejecuta en cada commit.
• Una base de conocimiento sana a veces se reduce. Las dos semanas en que bajó el número de páginas fueron pases de consolidación, y fueron las semanas más sanas del registro.
• Toda regla debería originarse en un fallo. El libro de reglas de 246 líneas creció como un registro de cambios de cosas que salieron mal, y por eso los agentes lo siguen.

Separar la propiedad antes que nada

El vault vive en Obsidian, dividido en dos capas, y todo esto se traslada a cualquier carpeta de markdown. La capa raw es mía: 341 artículos guardados, 20 transcripciones, notas y entradas de diario que los agentes leen pero nunca reescriben. La capa wiki pertenece a los agentes: cada página la generan y mantienen ellos, y las correcciones se hacen por conversación en lugar de a mano. El conocimiento fluye en una sola dirección, de raw a wiki, nunca al revés.

Esta división es lo que hace delegable el mantenimiento. Cuando las notas humanas y las notas de los agentes comparten archivos, cada edición de un agente puede sobrescribir algo que usted quiso decir, así que termina revisándolo todo, que es de nuevo el trabajo de bibliotecario. Al separar las capas, la revisión se reduce a una sola pregunta: ¿es fiel a las fuentes la comprensión compilada?

Esa misma pregunta de propiedad decide si funciona la base de conocimiento de una empresa. Averiguar qué página es dueña de qué dato es también el primer ejercicio del sprint de auditoría y consultoría de IA de webvise, porque una automatización construida sobre documentos contradictorios automatiza la contradicción.

Las reglas viven en archivos, y cada regla se origina en un fallo

Todo lo que los agentes saben sobre el vault proviene de archivos dentro de él. AGENTS.md en la raíz es la constitución: 246 líneas que cubren el árbol de directorios, la plantilla de página, las reglas de fuentes y el sistema de índice. CLAUDE.md, justo al lado, tiene una sola línea, un shim que hace que Claude Code cargue el mismo archivo que leen Codex y cualquier otra herramienta compatible con AGENTS.md.

• Nada de invención. Toda afirmación se origina en una fuente o se marca como no verificada.
• Una conversación no es una fuente. Primero se guarda un extracto depurado como archivo, y luego se cita el archivo. "El usuario lo dijo en el chat" es una cita que nunca se puede volver a abrir.
• Una página propietaria por cada dato volátil. Cualquier otra página enlaza a ella en lugar de copiarla.
• Toda mención de una entidad conocida es un enlace. Un dato sin enlazar es invisible para el grafo y para la recuperación.

Nada de esto vino de un modelo de gobernanza diseñado de antemano. Una mañana, los archivos de instrucciones aparecieron vaciados a 0 bytes, así que el vault dejó la sincronización de archivos y pasó a un repositorio git con una validación en cada commit. Seguían apareciendo citas de chat imposibles de rastrear en las listas de fuentes, así que las conversaciones quedaron prohibidas como fuente, y los registros al estilo CRM empezaron a contaminar las páginas de conocimiento, así que esos registros salieron por completo del vault. Escriba la regla la semana en que su ausencia le cueste algo, y sáltese las 50 especulativas.

Seis operaciones y nada más

Un agente con un vault y sin operaciones definidas inventa un flujo de trabajo nuevo en cada sesión. Un día fusiona duplicados, al día siguiente los crea, y las dos veces puede justificarse. Por eso cada interacción pasa por una de seis operaciones, cada una escrita como un archivo de habilidad que carga toda herramienta de agente.

Las salvaguardas dentro de las operaciones hacen más que la lista en sí. La ingesta trata las instrucciones incrustadas en artículos guardados como contenido no confiable, porque una lista de lecturas es una superficie de ataque: un artículo que dice "ignora tus instrucciones anteriores" se guarda como un artículo que dice eso, y nada de lo que diga un artículo puede autorizar cambios de esquema en el mismo paso. La consulta tiene un límite estricto: el agente solo puede afirmar que al vault le falta información después de que una búsqueda de texto completo no encuentre nada, porque de lo contrario "el índice no lo mostró" se convierte en "no existe". La reorganización exige un mapeo completo de archivos de lo antiguo a lo nuevo y una confirmación explícita antes de mover nada.

Una validación determinista bajo el modelo

Los agentes respetan una validación que falla y pasan por alto una guía escrita. Usted puede escribir "mantenga los índices sincronizados" en un libro de reglas y verlo decaer en una semana, o puede hacer que un índice desincronizado falle una comprobación que bloquee el commit, y el problema desaparece para siempre.

Mi validación es un linter de Python de 1.671 líneas, solo con la biblioteca estándar, 20 comprobaciones, unos 2 segundos por ejecución completa. Los problemas estructurales son errores: wikilinks rotos, frontmatter mal formado, entradas de índice que apuntan a archivos que ya no existen. Los problemas de desviación son advertencias: páginas huérfanas, recuentos de índice que dejaron de coincidir con la realidad, páginas sin tocar durante 90 días. Un hook de pre-commit de 13 líneas ejecuta el linter en modo estricto, donde las advertencias también bloquean el commit, así que nada entra al historial de git por debajo del nivel exigido.

La validación lo lee todo, incluso lo que se escribe sobre ella. Mientras redactaba la versión extensa de este informe el 2026-07-21, escribí como ejemplo una frase alemana de plazo límite, y el linter la interpretó como un plazo vencido dentro del artículo. Una marca de cita de ejemplo se registró como una fuente ausente de la lista de fuentes. Ambos pasajes tuvieron que reformularse antes de que el commit pasara.

Tres meses de ajustes se redujeron a una sola dirección: cada vez que un juicio podía convertirse en una comprobación, se convertía en una comprobación. El coste bajó y la fiabilidad subió en cada paso. El modelo es el componente más caro y menos repetible del sistema, así que se reserva solo para el criterio.

Lo que dicen los números después de 3 meses

Los informes semanales situaron el número de páginas en 188 a mediados de abril, 279 a principios de mayo, bajó a 263 tras un pase de consolidación, subió a 479 a principios de julio, luego bajó a 430 antes de alcanzar las 490 a finales de julio. Las dos contracciones fueron las semanas más sanas del registro, porque plegaron páginas escasas y duplicadas en sus propietarias. Las bases de conocimiento sin mantenimiento solo crecen. Si su número de páginas nunca ha bajado, nadie está cuidando el jardín.

Una auditoría completa del vault el 2026-06-22 encontró una tabla de precios repetida en 4 páginas distintas y la historia de un proyecto contada 3 veces con extensión de párrafo. Cada copia era correcta cuando se escribió, y cada copia era una mentira futura, porque el siguiente cambio afectaría a una de ellas y dejaría fuera al resto. La solución fue la propiedad y no la fusión: un registro nombra exactamente una página propietaria por cada dato volátil, y las páginas pequeñas de un solo tema se mantienen pequeñas porque esa forma es la que mejor se recupera. La misma auditoría no encontró ni una sola contradicción factual dura en más de 400 páginas, porque la estructura no deja ningún lugar donde puedan vivir las contradicciones.

El método de evaluación que vale la pena copiar es una tabla de puntuación, no una vista de grafo. Anote las 15 preguntas que la base de conocimiento más necesita responder, formúlelas en frío y puntúe cada respuesta como clara y única o dispersa. La mía dio 13 claras y únicas, y las 2 que se dispersaron trataban ambas de criterio, que vive en decisiones que nadie escribió nunca. La métrica es si el sistema responde preguntas reales en un solo salto.

El coste de mantenimiento se sitúa en 5 minutos al día más una sesión de agente de 30 a 45 minutos los domingos, y el repositorio muestra 880 commits desde mayo.

Lo que todavía falla

La calidad de la recuperación es una apuesta, y sigue abierta. El agente siempre encuentra una página plausible, y una respuesta incorrecta pero plausible es peor que no encontrar nada, porque nada parece roto. Mi posición de trabajo: por debajo de unas 10.000 páginas, la búsqueda por palabras clave sobre markdown bien estructurado tiene el tamaño adecuado, y con 490 páginas ese umbral no se ha puesto a prueba ni de lejos.

La proliferación de etiquetas ocurrió de todos modos: 662 etiquetas distintas, añadidas de una en una, cada una plausible, porque los agentes generan etiquetas plausibles gratis. La obsolescencia nunca deja de costar: alrededor de 30 páginas están marcadas como autorizadas pero obsoletas pese a tener marcas de fecha y una advertencia de validación a los 90 días. Y en abril el vault funcionaba con 0,68 fuentes en bruto por página compilada, lo que significa que el sistema escribía más rápido de lo que leía. Cuando escribir no cuesta nada, las páginas sin fuente se convierten en el camino de menor resistencia, y la regla de no invención es lo único que se interpone entre una base de conocimiento y un montón de afirmaciones muy bien organizado.

Los productos de memoria dedicados prometen resolver la recuperación más allá de la línea de las 10.000 páginas, y la respuesta honesta es que este vault está muy por debajo de esa línea. El desglose en dos bandos de ese mercado está en Sustratos de contexto para agentes de larga duración.

El mismo patrón dentro de una empresa

Karpathy esbozó el patrón del LLM wiki en un gist, y Google lanzó en junio de 2026 un formato de conocimiento abierto equivalente, paquetes de markdown con frontmatter tipado que reflejan esta estructura casi campo por campo. Leo la convergencia como evidencia de que la forma es la correcta. La versión empresarial compila posicionamiento, precios, procedimientos, registros de decisiones y contexto de clientes en lugar de notas personales, y falla de manera idéntica: un wiki que alguien construyó con entusiasmo y que nadie mantiene. Para una base de conocimiento empresarial de 200 documentos, la maquinaria descrita arriba ya es más de lo que necesita, y La mayoría de las bases de conocimiento empresariales no necesitan RAG explica por qué.

El trabajo de criterio está en la configuración inicial: qué datos reciben página propietaria, dónde se sitúan las validaciones de revisión y en qué puede escribir cada agente. Ese mapeo es la forma que toma el servicio de auditoría y consultoría de IA de webvise: elegir un flujo de trabajo, mapear entradas, excepciones y puntos de revisión, y salir con un prototipo funcional y un plan de construcción. La capa de conocimiento suele resultar ser el requisito previo para toda automatización que viene después.

webvise construye sistemas de conocimiento mantenidos por agentes y las automatizaciones que se levantan sobre ellos, con una validación de revisión humana en cada flujo de trabajo. Para descubrir cómo se vería esto aplicado a sus documentos, use el formulario de contacto.