Por fin me puse a leer el gist de Karpathy sobre LLM Wiki (sí, llegué tarde al hype train XD).
Y honestamente, toda la idea se reduce a algo bastante simple: "RAG actualizable".
1. El problema
Cuando los LLM trabajan con documentos, nada se acumula. Cada consulta: el modelo recupera fragmentos, sintetiza desde cero, olvida. El conocimiento nunca se compila. Y en mi opinión, lo que importa aún más: casi nunca se extrae información útil de los propios diálogos.
RAG ayuda parcialmente (en sentido amplio, una carpeta de archivos .md también es RAG), pero el pipeline estándar (que todo el mundo usa) no tiene actualización, destilación ni limpieza automática integradas. El conocimiento llega al índice una vez y luego se queda ahí, inactivo. Ese vacío es exactamente lo que cierra LLM Wiki.
La inversión de Karpathy: entre las fuentes brutas y tú hay un wiki en markdown que el agente escribe y mantiene incrementalmente. Compila una vez, manténlo actualizado.
2. Arquitectura: 3 capas
- raw/ - fuentes, inmutables. El agente no escribe aquí.
- wiki/ - el corazón del sistema; páginas en markdown (entidades, conceptos) que el LLM escribe y enlaza entre sí. Esencialmente conocimiento con forma de grafo.
- CLAUDE.md - solo el manual de cómo ejecutar LLM Wiki. Contiene: formato de página, convenciones de enlaces, flujo de ingesta, reglas de lint. Lo que convierte a Claude de un chatbot en un disciplinado mantenedor de wiki.
Suficiente para cientos de páginas sin ningún ajuste adicional:
3. Operaciones
Tres operaciones: inmediatamente querrás dibujarlas como funciones de API:
- Ingest -> add(source: file | list[file]). Suelta una fuente -> el agente lee -> discute contigo -> escribe un resumen -> actualiza el índice -> edita páginas de entidades relacionadas -> agrega al registro. Una fuente toca entre 10 y 15 páginas.
- Query -> search(prompt: str). La operación más importante. Responde tu pregunta + (LA PARTE CLAVE) archiva automáticamente la síntesis de vuelta en el wiki como nuevas páginas. La exploración se acumula en lugar de morir en el historial del chat. Internamente, es básicamente add(source=dialogue).
- Lint -> lint(). Sin argumentos. Recorre periódicamente el wiki: contradicciones, páginas huérfanas, datos obsoletos, referencias cruzadas faltantes. Disparador: cada N mensajes del usuario, o un contador de líneas modificadas. Fácil de adjuntar a /schedule.
Me recuerda mucho a Claude Dreaming; creo que Dreaming está parcialmente inspirado en este patrón (aunque su conjunto de funciones es un poco diferente).
4. Indexación
Dos archivos especiales hacen que el wiki sea navegable:
- index.md - estado actual. Catálogo de cada página con una línea de resumen. El agente lo lee primero en cualquier consulta; es el contexto mínimo de "qué hay en este wiki".
- log.md - registro de todos los eventos, formato libre. Línea de tiempo de solo añadido. Si las líneas siguen una forma consistente (por ejemplo,
## [YYYY-MM-DD] ingest | título), el registro se puede filtrar limpiamente con herramientas Unix simples, útil para auditoría.
index.md puede escalar más (índice vectorial, BM25, GraphDB...) — lo cubriré en una publicación aparte.
5. Conclusiones
Así es como lo plantearía: no es una elección entre RAG y LLM Wiki, sino dos puntos en el mismo eje de "memoria compuesta".
RAG no tiene por qué ser una base de datos vectorial: una carpeta de archivos markdown también es RAG.
Por lo tanto, puedes replantear LLM Wiki como RAG con tres cosas añadidas encima:
- Una capa de resumen.
- Redacción (casi) libre de la estructura en ese nivel de resumen.
- Auditoría estructural periódica + auto-mejora (CRON).
