Mantenimiento del Wiki de LLM: Deriva, Contradicciones y Revisión

Un wiki de LLM falla cuando los datos antiguos siguen siendo plausibles, las contradicciones se vuelven pulidas y los resúmenes generados se desvían de sus fuentes.

El mantenimiento es el verdadero producto de cualquier sistema de conocimiento compilado. Crear páginas de wiki es sencillo en comparación con mantenerlas dignas de confianza a lo largo de meses de ingestión, ediciones, reescrituras y nuevas fuentes.

Este artículo cubre el lado operativo de los sistemas LLM Wiki: detección de desviaciones, verificaciones de contradicciones, disciplina de citación, análisis estático (linting), revisión de Git y flujos de trabajo de mantenimiento. Se asume que ya comprende el patrón básico descrito en LLM Wiki - Conocimiento compilado que el RAG no puede reemplazar: las fuentes crudas se compilan en páginas Markdown duraderas que humanos y agentes pueden consultar más tarde. La visión serena pero con opiniones firmes es que un LLM Wiki sin mantenimiento es solo un cementerio de conocimientos con mejor apariencia.

Qué hace diferente al mantenimiento de un LLM Wiki

Los wikis tradicionales se deterioran porque la gente deja de actualizarlos. Los sistemas RAG se desvían porque el corpus cambia, los fragmentos (chunks) se vuelven obsoletos, los metadatos son débiles y la recuperación sigue encontrando fragmentos plausibles pero desactualizados. La razón más profunda es que la recuperación y la representación resuelven problemas diferentes: la recuperación puede volver a ejecutarse contra datos frescos, pero una representación que ya compiló debe mantenerse honesta activamente.

Un LLM Wiki tiene un modo de fallo diferente. Puede parecer limpio incluso cuando está equivocado.

Las páginas pueden estar bien formateadas. Los enlaces pueden funcionar. Los resúmenes pueden sonar equilibrados. Pero bajo esa superficie ordenada, el sistema puede haber omitido datos críticos, fusionado conceptos incompatibles, citado resúmenes en lugar de fuentes o preservado una decisión antigua como si todavía aplicara.

Es por eso que el mantenimiento del LLM Wiki debe verificar tanto la estructura como el significado.

El objetivo del mantenimiento

El objetivo no es hacer que cada página sea perfecta. Eso es demasiado costoso y generalmente conduce a sistemas abandonados.

El objetivo es mantener el wiki útil, inspeccionable y recuperable.

Un LLM Wiki mantenido debe facilitar responder estas preguntas:

• ¿Qué fuentes respaldan esta afirmación?
• ¿Cuándo se revisó esta página por última vez?
• ¿Ha cambiado este concepto?
• ¿Hay páginas contradictorias?
• ¿Este resumen sigue siendo actual?
• ¿El agente reescribió más de lo que debería?
• ¿Podemos revertir una actualización incorrecta?
• ¿Puede un humano entender por qué la página dice lo que dice?

Si la respuesta es no, el problema no es solo la calidad del contenido. Es el diseño del sistema.

Un bucle de mantenimiento simple

Un LLM Wiki útil necesita un bucle repetible. El bucle debe ser lo suficientemente simple para ejecutarse a menudo y lo suficientemente estricto para detectar desviaciones antes de que se vuelvan invisibles.

Este bucle no es glamoroso. Ese es el punto.

Un sistema de conocimiento se vuelve durable mediante un mantenimiento aburrido: preservación de fuentes, revisión explícita, estructura predecible y actualizaciones pequeñas y seguras. El mismo instinto impulsa las notas perennes: una nota o una página de wiki solo complica su valor si alguien sigue refinándola en lugar de dejarla pudrirse después del primer borrador.

Tipos de desviación en un LLM Wiki

La desviación del conocimiento no es una sola cosa. Diferentes tipos de desviación requieren diferentes verificaciones. Un buen sistema de mantenimiento debería nombrarlos claramente.

Desviación de fuente

La desviación de fuente ocurre cuando el material de fuente subyacente cambia.

Por ejemplo, una herramienta libera una nueva versión, una política se actualiza, una API cambia o un proveedor descontinúa una función antigua. La página anterior del wiki puede seguir siendo precisa para la versión anterior, pero incorrecta para el uso actual.

La desviación de fuente es peligrosa porque la afirmación antigua puede seguir siendo verdadera en un contexto histórico. El problema no es que la afirmación sea falsa. El problema es que ya no responde a la pregunta actual.

Respuesta de mantenimiento:

• Registrar fechas de fuente
• Registrar fechas de última revisión
• Marcar claramente las páginas específicas de la versión
• Enlazar las páginas antiguas a las páginas que las reemplazan
• Evitar mezclar versiones antiguas y nuevas sin etiquetas

Desviación de concepto

La desviación de concepto ocurre cuando el significado de un término cambia con el tiempo.

Esto es común en IA y arquitectura de software. Términos como “agente”, “memoria”, “RAG”, “flujo de trabajo”, “uso de herramientas”, “salida estructurada” e “ingeniería de contexto” pueden cambiar de significado rápidamente.

Un wiki puede conservar accidentalmente varios significados del mismo término sin explicar la diferencia. Eso crea páginas confusas que suenan coherentes pero combinan ideas incompatibles.

Respuesta de mantenimiento:

• Mantener páginas de glosario
• Agregar secciones de “significado en este wiki”
• Separar conceptos sobrecargados en páginas distintas
• Enlazar explícitamente los significados relacionados
• Evitar que el modelo fusione términos en silencio

Desviación de terminología

La desviación de terminología es menor que la desviación de concepto, pero igualmente dañina.

Ocurre cuando el wiki utiliza múltiples nombres para la misma cosa: “LLM Wiki”, “base de conocimientos compilada”, “wiki mantenido por IA”, “wiki mantenido por agente” y “base de conocimientos Markdown”.

Alguna variación está bien. Demasiada variación rompe la búsqueda, los enlaces y la revisión.

Respuesta de mantenimiento:

• Definir nombres canon de página
• Mantener alias en el front matter o metadatos de la página
• Redirigir páginas duplicadas
• Analizar (lint) títulos casi duplicados
• Usar texto de anclaje consistente en los enlaces internos

Desviación de decisión

La desviación de decisión ocurre cuando una decisión pasada permanece documentada pero ya no refleja la práctica actual.

Por ejemplo, una página podría decir que el proyecto utiliza RAG vectorial para todas las búsquedas de documentos, mientras que las páginas más nuevas describen un flujo de trabajo de LLM Wiki. Ambas declaraciones pueden ser históricamente verdaderas, pero el wiki debe mostrar cuál es la actual.

Esto es importante para notas de arquitectura, procesos de ingeniería, estrategia de contenido y herramientas internas. La misma disciplina se aplica a los registros de decisiones en el desarrollo impulsado por IA: una página de decisión solo es digna de confianza si las elecciones reemplazadas están marcadas como tal en lugar de ser sobrescritas en silencio.

Respuesta de mantenimiento:

• Marcar las decisiones como propuestas, aceptadas, reemplazadas o rechazadas
• Mantener las fechas de decisión
• Enlazar las decisiones reemplazadas a sus sustitutos
• Preservar el contexto histórico
• Evitar eliminar decisiones antiguas sin dejar rastro

Desviación de citación

La desviación de citación ocurre cuando una página cita una fuente, pero la afirmación ya no coincide con lo que dice la fuente.

Esto puede ocurrir después de una reescritura. La citación permanece en su lugar, pero la oración alrededor cambia. La página sigue pareciendo sourced, pero la citación ya no respalda la afirmación.

Este es uno de los modos de fallo más graves del LLM Wiki porque crea una confianza falsa.

Respuesta de mantenimiento:

• Verificar el soporte de citación a nivel de afirmación
• Evitar citar solo resúmenes
• Mantener fuentes crudas
• Requerir citaciones para afirmaciones importantes
• Marcar párrafos con fuentes pero sin soporte directo
• Revisar los cambios de citación en las diferencias de Git

Desviación estructural

La desviación estructural ocurre cuando el wiki pierde lentamente navegabilidad.

Se crean nuevas páginas en lugar de actualizar las antiguas. Las páginas de índice se atrasan. Aparecen páginas duplicadas. Se acumulan páginas huérfanas. Las páginas relacionadas dejan de enlazarse entre sí.

El wiki aún contiene conocimiento útil, pero encontrarlo y confiar en él se vuelve más difícil.

Respuesta de mantenimiento:

• Analizar páginas huérfanas
• Mantener páginas de índice
• Detectar temas duplicados
• Requérir enlaces inversos para páginas canónicas
• Archivar en lugar de dispersar
• Mantener los roles de las carpetas claros

Los archivos centrales de mantenimiento

Un LLM Wiki no debería depender de la memoria, las sensaciones o la repetición de prompts. Necesita archivos operativos que indiquen a humanos y agentes cómo mantenerlo.

Una estructura práctica puede verse así:

llm-wiki/
  raw/
    sources/
    transcripts/
    documents/
  wiki/
    index.md
    concepts/
    entities/
    projects/
    decisions/
  maintenance/
    review-log.md
    lint-report.md
    stale-pages.md
    contradiction-report.md
  rules/
    AGENTS.md
    schema.md
    style-guide.md
    citation-policy.md
    source-policy.md

Los nombres exactos no importan. Los roles sí.

El wiki necesita almacenamiento de fuentes, páginas compiladas, artefactos de revisión y reglas que sobrevivan entre sesiones.

AGENTS.md

AGENTS.md debería explicar cómo se permite que el agente trabaje.

Debería responder preguntas como:

• ¿Debería el agente actualizar las páginas existentes antes de crear nuevas?
• ¿Cuándo debería pedir revisión?
• ¿Cómo debería citar las fuentes?
• ¿Puede reorganizar carpetas?
• ¿Puede reescribir páginas antiguas?
• ¿Qué debería hacer con las contradicciones?
• ¿Qué nunca debería eliminar?

Una regla útil es:

Preferir actualizaciones pequeñas respaldadas por fuentes sobre reescrituras amplias.

Esa sola frase previene muchos malos hábitos de mantenimiento. También traza un límite útil en relación con la memoria del agente: la memoria moldea cómo se comporta un agente en el momento, mientras que el archivo de reglas del wiki moldea lo que el agente está permitido cambiar en la base de conocimientos compartida.

schema.md

schema.md debería definir la estructura de la página.

Por ejemplo:

# Título de la página

## Resumen
Resumen corto y actual.

## Afirmaciones clave
- Afirmación con referencia de fuente.
- Afirmación con referencia de fuente.

## Estado actual
Actual, histórico, reemplazado, borrador o incierto.

## Detalles
Explicación compilada principal.

## Páginas relacionadas
Enlaces internos.

## Fuentes
Referencias de fuentes crudas.

## Notas de revisión
Fecha de última revisión y revisor.

Un esquema no necesita ser rígido. Pero sin un esquema, el wiki se convierte en un montón de ensayos inconsistentes. El esquema le da al agente algo que preservar.

citation-policy.md

La política de citación debería decir qué requiere una fuente. Como mínimo, requiera citaciones para:

• Afirmaciones técnicas
• Comparaciones
• Comportamiento del producto
• Declaraciones específicas de la versión
• Resultados de benchmarks
• Precios
• Afirmaciones legales o de cumplimiento
• Afirmaciones de estado actual
• Afirmaciones copiadas o derivadas de una fuente

Una buena política de citación también dice qué no hacer. No cite una página compilada como si fuera la fuente original. No adjunte citaciones a párrafos que no respaldan. No mantenga una citación después de reescribir una afirmación a menos que la fuente aún la respalde.

La disciplina de citación es la diferencia entre un LLM Wiki útil y una confianza decorativa.

source-policy.md

La política de fuentes debería definir cómo se almacenan las fuentes crudas.

Por ejemplo:

• Mantener archivos originales cuando sea posible
• Preservar URLs y fechas de acceso
• Almacenar notas copiadas por separado de los resúmenes generados
• Registrar el tipo de fuente
• Marcar fuentes de baja confianza
• Evitar sobrescribir material crudo
• Mantener fuentes reemplazadas cuando expliquen decisiones históricas

Esta política protege al wiki de un error común: resumir una fuente, descartar el original y luego tratar el resumen como evidencia.

Eso no es gestión de conocimientos. Eso es compresión con pérdida.

Qué debería verificar un analizador (linter) de LLM Wiki

Un analizador debería verificar la estructura primero. Los problemas estructurales son más fáciles de automatizar y a menudo revelan problemas semánticos más profundos.

Las verificaciones estructurales útiles incluyen:

• Enlaces internos rotos
• Páginas huérfanas
• Títulos duplicados
• Secciones de fuente faltantes
• Fechas de revisión faltantes
• Páginas sin enlaces inversos
• Secciones vacías o de marcador de posición
• Páginas muy largas sin estructura de secciones
• Páginas sin enlaces entrantes desde un índice
• Convenciones de nomenclatura inconsistentes
• Front matter inválido
• Páginas “actuales” obsoletas con más antigüedad que un umbral de revisión

Estas verificaciones no demuestran que el conocimiento sea verdadero. Demuestran que el wiki sigue siendo mantenible. Ese es un punto de partida necesario.

Verificaciones semánticas

Las verificaciones semánticas son más difíciles pero más valiosas.

Las verificaciones semánticas útiles incluyen:

• Afirmaciones sin soporte de fuente directa
• Dos páginas haciendo afirmaciones incompatibles
• Decisiones antiguas presentadas como actuales
• Conceptos duplicados con nombres diferentes
• Una página de concepto mezclando varios significados
• Resúmenes que omiten restricciones conocidas
• Afirmaciones de “mejor” o “recomendado” sin criterios
• Afirmaciones específicas de la versión sin etiquetas de versión
• Páginas que contradicen fuentes más nuevas

Estas verificaciones no deberían reescribir automáticamente el wiki. Generalmente deberían producir un informe para revisión.

El patrón más seguro es:

Detectar automáticamente.
Explicar claramente.
Actualizar deliberadamente.
Revisar cambios arriesgados.

Detección de contradicciones

La detección de contradicciones no es solo preguntar a un LLM si dos páginas se contradicen entre sí.

Eso puede ayudar, pero es demasiado vago. Un mejor enfoque es comparar afirmaciones.

Un flujo de trabajo de contradicción puede verse así:

Esto funciona mejor porque muchas contradicciones aparentes no son contradicciones reales.

Una página puede describir la versión 1.0 y otra la versión 2.0. Una página puede describir el uso personal y otra el uso empresarial. Una página puede describir el objetivo de diseño y otra la realidad de la implementación.

El informe de contradicción debería incluir:

• Afirmaciones contradictorias
• Páginas involucradas
• Referencias de fuente
• Contexto de fecha o versión
• Explicación probable
• Resolución sugerida
• Si se requiere revisión humana

No permita que el agente resuelva silenciosamente las contradicciones mezclando ambas afirmaciones en un compromiso vago. Eso crea un sinsentido suave.

Cómo resolver contradicciones

Hay varias formas válidas de resolver una contradicción.

• Si una afirmación está desactualizada, márquela como reemplazada y enlance a la página más nueva.
• Si ambas afirmaciones son verdaderas en diferentes contextos, divida el contexto claramente.
• Si las fuentes discrepan, preserve la discrepancia y explíquela.
• Si la página del wiki inventó o generalizó en exceso una afirmación, elimine o reduzca la afirmación.
• Si la contradicción refleja una decisión real sin resolver, cree o actualice una página de decisión.

El objetivo no es eliminar toda tensión. Algo de tensión es útil. Un buen wiki muestra dónde el conocimiento está resuelto y dónde sigue siendo incierto.

Revisión de páginas obsoletas

Cada página compilada debería tener un estado de revisión.

Un bloque de metadatos simple puede ser suficiente:

status: current
last_reviewed: 2026-07-10
review_after: 2026-10-10
source_confidence: medium

Para temas de rápida evolución, use ventanas de revisión cortas. Para conceptos estables, use ventanas más largas.

El intervalo es menos importante que el hábito. Una página sin fecha de revisión es una página que eventualmente mentirá en silencio.

Actualizaciones conscientes de la fuente

Cuando llega una nueva fuente, el agente no debería simplemente escribir una nueva página de resumen.

Debería preguntar:

• ¿Esto actualiza un concepto existente?
• ¿Reemplaza una fuente anterior?
• ¿Contradice una página existente?
• ¿Agrega una nueva entidad o término?
• ¿Cambia una recomendación?
• ¿Requiere una actualización del índice?
• ¿Afecta a las páginas de decisión?

Un buen flujo de trabajo de ingestión actualiza el wiki como un gráfico, no como una pila de resúmenes aislados.

Es por eso que una fuente puede tocar muchas páginas. Eso es normal. El desafío de mantenimiento es hacer que esas actualizaciones sean pequeñas, revisables y trazables.

Revisión con diferencias de Git

Git es una de las mejores herramientas de mantenimiento para un LLM Wiki.

No porque Git esté de moda, sino porque el conocimiento generado necesita un historial de cambios revisable. Una diferencia de Git muestra qué cambió, eliminó, movió o reformuló el agente.

Use Git para revisar:

• Nuevas páginas
• Secciones eliminadas
• Afirmaciones cambiadas
• Citaciones cambiadas
• Páginas renombradas
• Actualizaciones de índice
• Cambios de enlaces
• Cambios de estado
• Reescrituras amplias

El hábito de revisión más importante es inspeccionar las eliminaciones. Los LLM a menudo eliminan detalles mientras hacen que la prosa sea más limpia.

Una prosa limpia no siempre es un conocimiento mejor.

Estrategia de confirmación segura

Evite confirmaciones gigantes como:

Actualizar wiki

Use confirmaciones que expliquen la operación:

ingest: agregar notas de fuente para el lanzamiento de embeddings de Qwen
maint: marcar la comparación antigua de almacenes vectoriales como reemplazada
lint: corregir enlaces internos rotos en páginas de RAG
review: actualizar citaciones de la página LLM Wiki
refactor: separar el concepto de memoria del agente de la memoria a largo plazo

Esto brinda a futuros humanos y agentes un historial útil.

Los mensajes de confirmación son parte del sistema de conocimiento. Explican por qué cambió el wiki.

Niveles de revisión

No cada página necesita el mismo nivel de revisión. Use revisión basada en riesgos.

Cambios de bajo riesgo:

• Correcciones de enlaces rotos
• Limpieza de formato
• Agregar enlaces inversos
• Agregar entradas de índice
• Corregir errores tipográficos
• Agregar alias

Cambios de riesgo medio:

• Agregar resúmenes de fuentes
• Crear nuevas páginas de concepto
• Actualizar recomendaciones
• Fusionar páginas duplicadas
• Cambiar el estado de la página

Cambios de alto riesgo:

• Eliminar afirmaciones
• Reescribir páginas canónicas
• Cambiar registros de decisiones
• Actualizar afirmaciones de seguridad, legales, precios o benchmarks
• Resolver contradicciones
• Marcar contenido como actual o reemplazado

Los cambios de alto riesgo deberían recibir revisión humana. Eso puede ser usted, un mantenedor o un dueño del dominio.

El agente puede preparar el cambio, pero no debería ser siempre la autoridad final.

Un tablero de mantenimiento

Un tablero de mantenimiento simple puede vivir en Markdown.

Ejemplo:

# Tablero de mantenimiento de LLM Wiki

## Necesita revisión
- wiki/concepts/agent-memory.md - revisión vencida
- wiki/projects/search-index.md - se encontraron afirmaciones contradictorias

## Páginas obsoletas
- wiki/tools/ollama.md - última revisión hace 120 días
- wiki/concepts/rag.md - tema de rápida evolución, revisión pendiente

## Enlaces rotos
- wiki/index.md -> wiki/concepts/old-page.md

## Páginas huérfanas
- wiki/entities/vendor-x.md

## Informes de contradicción
- reports/contradictions/2026-07-10-agent-memory.md

## Ingestiones recientes
- raw/sources/2026-07-09-new-paper.md

Este no es un panel de administración elegante. Es una superficie de trabajo.

Para muchos sistemas individuales o de equipos pequeños, un tablero Markdown es suficiente.

Métricas para un LLM Wiki saludable

Puede rastrear la salud del wiki sin sobreingenierizarlo.

Las métricas útiles incluyen:

• Número de páginas
• Páginas sin fuentes
• Páginas sin fechas de revisión
• Páginas con fecha de revisión vencida
• Enlaces internos rotos
• Páginas huérfanas
• Títulos o alias duplicados
• Informes de contradicción abiertos
• Informes de contradicción resueltos
• Edad promedio de la página por clúster
• Fuentes crudas aún no ingeridas
• Páginas cambiadas sin revisión humana
• Páginas canónicas cambiadas en los últimos 30 días

Estas métricas no son números de vanidad. Le dicen si el sistema se está volviendo más fácil o más difícil de confiar.

Un wiki en crecimiento con páginas huérfanas en aumento y revisiones obsoletas no está compilando conocimiento. Está compilando deuda de mantenimiento.

Prompts de mantenimiento

Los prompts de mantenimiento deben ser estrechos. Los prompts amplios producen reescrituras amplias.

Prompt de análisis estructural

Revisar la estructura del wiki.

Verificar:
- enlaces internos rotos
- páginas huérfanas
- títulos de página duplicados o casi duplicados
- páginas que faltan secciones de fuente
- páginas que faltan metadatos last_reviewed
- páginas de índice que no enlazan a nuevas páginas

No reescribir el contenido.
Producir un informe en Markdown con hallazgos y correcciones sugeridas.

Prompt de revisión de citaciones

Revisar las citaciones de la página seleccionada.

Para cada afirmación importante:
- identificar la fuente de soporte
- verificar si la fuente respalda directamente la afirmación
- marcar afirmaciones con soporte débil, faltante o desalineado
- no reescribir la página aún

Devolver una tabla con:
afirmación, citación actual, nivel de soporte, problema, acción sugerida.

Prompt de verificación de contradicción

Verificar esta página en busca de contradicciones contra páginas relacionadas.

Pasos:
1. Extraer las afirmaciones principales de la página.
2. Buscar páginas relacionadas a través de enlaces, enlaces inversos, alias y búsqueda.
3. Extraer afirmaciones potencialmente contradictorias.
4. Clasificar cada conflicto como:
   - contradicción real
   - diferencia de versión
   - diferencia de alcance
   - diferencia de terminología
   - incertidumbre no resuelta
5. Recomendar una resolución.

No editar archivos hasta que se revise el informe de contradicción.

Prompt de revisión de página obsoleta

Revisar esta página por obsolescencia.

Verificar:
- fechas
- afirmaciones específicas de la versión
- comportamiento de herramientas
- recomendaciones
- enlaces a páginas reemplazadas
- fuentes más nuevas que la fecha de revisión de la página
- afirmaciones marcadas como actuales sin soporte reciente

Devolver:
- mantener actual
- actualización necesaria
- marcar como histórico
- marcar como reemplazado
- dividir en páginas versionadas

Prompt de actualización segura

Actualizar la página del wiki seleccionada usando la fuente proporcionada.

Reglas:
- preservar la estructura útil existente
- no eliminar afirmaciones con fuente a menos que la fuente esté reemplazada
- agregar citaciones para nuevas afirmaciones
- marcar la incertidumbre explícitamente
- actualizar páginas relacionadas solo cuando sea necesario
- agregar una nota de revisión explicando qué cambió
- mantener la diferencia pequeña

Estos prompts no son magia. Son barreras de protección. El valor real proviene de hacer explícita la acción de mantenimiento.

Errores comunes de mantenimiento

El primer error es permitir que el agente reescriba demasiado.

Las reescrituras grandes se sienten productivas porque hacen que las páginas sean más suaves. También hacen que sea más difícil ver qué cambió y más fácil perder detalles precisos.

El segundo error es tratar los resúmenes generados como fuentes.

Un resumen puede ser útil, pero no es la evidencia. Mantenga fuentes crudas y cítelas cuando las afirmaciones importen.

El tercer error es crear nuevas páginas en lugar de actualizar las antiguas.

Esto produce conceptos duplicados, recomendaciones contradictorias y confusión en la búsqueda. El agente debería buscar primero, actualizar segundo y crear nuevas páginas solo cuando el concepto sea genuinamente nuevo.

El cuarto error es eliminar el contexto histórico.

Las decisiones antiguas, los experimentos fallidos y las recomendaciones reemplazadas pueden ser valiosas. Márquelas claramente en lugar de borrarlas.

El quinto error es olvidar los índices.

Una página que no está enlazada desde el lugar correcto está mitad perdida. El mantenimiento del índice no es trabajo administrativo. Es arquitectura de navegación.

El sexto error es usar la misma política de revisión para cada página.

Una página conceptual estable y una comparación de herramientas de rápida evolución no deberían tener el mismo horario de revisión.

Archivar, reemplazar o eliminar

La mayoría de las páginas obsoletas no deberían eliminarse inmediatamente.

Una página reemplazada debería enlazar a la sustituta.

Por ejemplo:

Estado: reemplazado
Reemplazado por: wiki/concepts/agent-memory-architecture.md
Razón: Esta página utilizaba una definición anterior de memoria del agente antes de que el proyecto separara la memoria de sesión, la memoria del usuario y el conocimiento compilado.

Esto preserva el contexto y reduce la confusión.

La eliminación debería ser rara y revisable. Los sistemas de conocimiento necesitan poda, pero la poda invisible es peligrosa.

Las páginas canónicas necesitan cuidado extra

Todo LLM Wiki eventualmente desarrolla páginas canónicas.

Estas son páginas que definen conceptos centrales, elecciones de arquitectura, flujos de trabajo o vocabulario del proyecto. Son más importantes que las notas ordinarias porque muchas otras páginas dependen de ellas.

Ejemplos:

• Qué es LLM Wiki
• RAG vs conocimiento compilado
• Memoria del agente
• Política de fuentes
• Flujo de trabajo de revisión
• Arquitectura del proyecto
• Glosario
• Índice

Los cambios en las páginas canónicas deberían requerir una revisión más estricta.

Un pequeño error en una página oscura es local. Un pequeño error en una página canónica puede distorsionar todo el wiki.

Con qué frecuencia debería ejecutar el mantenimiento

Para un LLM Wiki activo, ejecute mantenimiento pequeño con frecuencia y mantenimiento profundo ocasionalmente.

El horario debe coincidir con el riesgo. Un wiki de investigación personal puede ser más ligero. Un wiki usado para publicación técnica, soporte al cliente o decisiones de ingeniería necesita más disciplina.

Usar un LLM Wiki para publicación técnica

Para un blog técnico o un sitio de documentación, el LLM Wiki puede convertirse en la capa de conocimiento detrás de la planificación de artículos.

Puede rastrear:

• Explicaciones canónicas
• Definiciones repetidas
• Oportunidades de enlaces internos
• Comparaciones obsoletas
• Brechas de artículos
• Clústeres de temas
• Notas de fuentes
• Decisiones sobre estructura
• Afirmaciones que necesitan verificación

Esto es útil, pero eleva la barra de mantenimiento.

Si el wiki alimenta artículos publicados, entonces las páginas obsoletas del wiki pueden convertirse en contenido público obsoleto. Si el wiki contiene contradicciones, esas contradicciones pueden filtrarse en los artículos. Si las citaciones son débiles, los borradores generados heredarán esa debilidad. Los resúmenes con alcance, la extracción basada en esquemas y los bucles de revisión humana descritos en IA para la gestión de conocimientos: Flujos de trabajo reales que resisten son una buena plantilla para mantener honesto ese pipeline editorial.

Para los flujos de trabajo de publicación, trate el LLM Wiki como un sistema editorial, no solo como un cuaderno privado. Un jardín digital hace esto explícito mostrando a los lectores qué páginas aún están creciendo y cuáles son maduras, lo cual es exactamente el tipo de señal de estado que un LLM Wiki bien mantenido también debería exponer.

El mantenimiento no es opcional

Un LLM Wiki es atractivo porque promete conocimiento compuesto.

Pero la composición solo funciona si el conocimiento antiguo sigue siendo útil. De lo contrario, el sistema compila ruido, no perspicacia.

La carga de mantenimiento no desaparece porque un agente está involucrado. Cambia de forma.

Los humanos no deberían tener que hacer cada tarea tediosa. Los agentes pueden verificar enlaces, encontrar páginas obsoletas, comparar afirmaciones, redactar informes y proponer actualizaciones. Pero los humanos aún necesitan establecer políticas, revisar cambios arriesgados y decidir qué se permite que el wiki signifique.

Ese es el verdadero trato.

Conclusión

El mantenimiento del LLM Wiki se trata de mantener el conocimiento compilado honesto.

Las prácticas importantes no son complicadas: preservar fuentes, citar afirmaciones, mantener índices actualizados, detectar contradicciones, revisar diferencias de Git, marcar páginas obsoletas y evitar reescrituras amplias no revisadas.

Un buen LLM Wiki no pretende ser mágicamente autocorrectivo. Hace que la corrección sea más fácil.

Ese es el estándar hacia el cual vale la pena aspirar: no conocimiento perfecto, sino conocimiento inspeccionable que puede ser revisado, reparado y confiable con el tiempo.