Por fin me puse a leer el gist de LLM Wiki de Karpathy (sí, llegué tarde al hype XD).
Y honestamente, toda la idea se reduce a algo bastante simple: "RAG actualizable".
1. El problema
Cuando los LLMs trabajan con documentos, nada se acumula. Cada consulta: el modelo recupera fragmentos, sintetiza desde cero, olvida. El conocimiento nunca se compila. Y para mí, lo que importa aún más: casi no se extrae información útil de los diálogos en sí.
RAG ayuda parcialmente (en sentido amplio, una carpeta de archivos .md también es RAG), pero el pipeline estándar (que todos usan) no tiene actualización incorporada, destilación ni autolimpieza. El conocimiento llega al índice una vez y luego se queda ahí sin moverse. Esa brecha es exactamente lo que cierra LLM Wiki.
La inversión de Karpathy: entre las fuentes sin procesar y tú hay un wiki de 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 markdown (entidades, conceptos) que el LLM escribe y enlaza entre sí. Esencialmente conocimiento en forma de grafo.
- CLAUDE.md - simplemente 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 mantenedor disciplinado del wiki.
Suficiente para cientos de páginas sin ajustes adicionales:
3. Operaciones
Tres operaciones - inmediatamente quieres 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 -> añade al log. Una fuente afecta de 10 a 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 al 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, hechos obsoletos, referencias cruzadas faltantes. Disparador - cada N mensajes de usuario, o un contador de líneas cambiadas. Fácil de adjuntar a /schedule.
Me recuerda fuertemente 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 navegable el wiki:
- index.md - estado actual. Catálogo de cada página con una línea. El agente lo lee primero en cualquier consulta - es el contexto mínimo 'qué hay en este wiki'.
- log.md - registro de todos los eventos, de forma libre. Línea de tiempo de solo añadidura. Si las líneas siguen una forma consistente (ej.
## [YYYY-MM-DD] ingest | title), el log se puede grep limpiamente con herramientas unix simples - útil para auditoría.
index.md puede escalarse 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 - son dos puntos en el mismo eje de 'memoria compuesta'.
RAG no tiene que ser una base de datos vectorial - una carpeta de archivos markdown también es RAG.
Así que puedes reformular 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).
