La memoria que aprende: Karpathy desafía al RAG con una base de conocimientos evolutiva
Hay un momento que cualquiera que haya trabajado intensamente con un modelo lingüístico conoce bien: el reset. Estás construyendo algo complejo, tal vez una arquitectura de software elaborada o una investigación que entrelaza docenas de fuentes, y el modelo lo ha entendido todo, mantiene el hilo, responde con precisión quirúrgica. Luego la sesión termina, o llegas al límite de contexto, y la IA lo olvida todo. Empieza de cero. Tienes que volver a explicarle quién eres, qué estás haciendo, qué decisiones habéis tomado juntos. Es como la película "Memento" de Christopher Nolan, donde el protagonista tiene que tatuarse la información en el cuerpo porque la memoria a corto plazo no funciona: brutal, redundante y profundamente frustrante.
Andrej Karpathy, exdirector de IA en Tesla y cofundador de OpenAI, ahora dedicado a un proyecto independiente, describió este problema exactamente en estos términos, y el 2 de abril de 2026 publicó en X una propuesta para resolverlo. El post se hizo viral con más de 16 millones de visualizaciones, y el GitHub Gist de profundización superó las 5.000 estrellas en pocos días. No estaba anunciando un nuevo modelo ni un benchmark. Estaba describiendo un cambio en la forma en que él mismo usa los modelos lingüísticos, un cambio que ha desencadenado un debate técnico encendido y, como suele suceder, alguna simplificación excesiva.
Qué es el RAG y por qué se ha convertido en el método dominante
Antes de entender qué propone Karpathy, merece la pena explicar qué hace el RAG, porque en los últimos tres años se ha convertido en el enfoque estándar para dar a los modelos lingüísticos acceso a conocimiento externo, y porque conlleva algunos problemas estructurales que no todos mencionan explícitamente.
Retrieval-Augmented Generation significa, literalmente, generación aumentada por recuperación. En un sistema RAG estándar, los documentos se cortan en fragmentos arbitrarios llamados "chunks", se convierten en vectores matemáticos llamados embeddings y se almacenan en una base de datos especializada. Cuando el usuario hace una pregunta, el sistema realiza una "búsqueda por similitud" para encontrar los fragmentos más relevantes y los inserta en el contexto del modelo.
El mecanismo funciona, y funciona bien en muchos escenarios. Pero conlleva algunas características que en ciertos contextos se convierten en problemas. El primero es la naturaleza fundamentalmente stateless del sistema: cada consulta parte de cero, buscando de nuevo entre las fuentes, sin que nada se acumule con el tiempo. No hay memoria de las elaboraciones pasadas, no hay acumulación de conocimiento. El segundo problema se refiere a la calidad de la recuperación: cortar un documento en trozos y buscar por similitud vectorial funciona bien cuando la respuesta está en uno o dos fragmentos contiguos, pero se vuelve impreciso cuando una pregunta requiere sintetizar ideas distribuidas en docenas de fuentes diferentes. El tercero, a menudo subestimado, es la complejidad infraestructural: bases de datos vectoriales, tuberías de embedding, sistemas de indexación; todo esto tiene un coste en términos de latencia, mantenimiento y opacidad. Los vectores no son legibles por ningún ser humano, lo que dificulta entender por qué el sistema ha recuperado ciertos fragmentos en lugar de otros.
Cómo funciona la máquina de la memoria
La propuesta de Karpathy parte de una pregunta diferente: en lugar de buscar cada vez, ¿qué pasaría si la IA construyera un conocimiento estructurado de antemano y luego lo consultara directamente?
Karpathy publicó en GitHub Gist la descripción de un sistema de tres carpetas que permite a un modelo compilar y mantener una base de conocimientos sin bases de datos vectoriales. La arquitectura es deliberadamente sencilla. La primera carpeta, raw/, contiene el material en bruto: PDF, notas, artículos web, repositorios de GitHub, datasets. La segunda, wiki/, alberga los artículos compilados por el modelo, uno por concepto o tema. La tercera es un archivo index.md, un mapa global de todos los artículos, dimensionado para caber dentro de la ventana de contexto del modelo.
Karpathy usa el Obsidian Web Clipper para convertir los contenidos web en archivos Markdown, asegurándose de que las imágenes también se guarden localmente para que el modelo pueda referenciarlas a través de sus capacidades de visión.
El paso central, lo que diferencia el enfoque de un simple archivo, es la compilación. En lugar de indexar los archivos, el modelo los "compila": lee los datos en bruto y escribe una wiki estructurada, generando resúmenes, identificando conceptos clave, produciendo artículos de estilo enciclopédico y, fundamentalmente, creando enlaces de retroceso (backlinks) entre ideas relacionadas.
El sistema no es estático: Karpathy describe ciclos periódicos de "linting", en los que el modelo escanea la wiki en busca de inconsistencias, datos faltantes o nuevas conexiones posibles. El sistema se comporta como una base de conocimientos viva que se autorrepara. Las consultas que se realizan al sistema se almacenan en la propia wiki, de modo que cada exploración se acumula: las respuestas, los gráficos, los análisis se insertan en la base de conocimientos, que crece de forma acumulativa.
¿A qué escala funciona todo esto? Karpathy precisó que actualmente opera con unos 100 artículos y 400.000 palabras de material de origen, y que a este tamaño la capacidad del modelo para navegar a través de resúmenes y archivos de índice es más que suficiente. Un análisis realizado por MindStudio reveló que este enfoque puede reducir el consumo de tokens hasta en un 95 % en comparación con la carga integral de documentos en el contexto, ventaja que se reduce al compararla con tuberías RAG optimizadas.
El post de Karpathy se inserta en una secuencia precisa de su pensamiento sobre la interacción humano-IA: tras el "vibe coding" de febrero de 2025, donde el usuario acepta el código generado sin revisarlo línea por línea, y la ingeniería agéntica de enero de 2026, donde los humanos orquestan agentes en lugar de escribir código directamente, las LLM Knowledge Bases representan la tercera fase: la IA gestiona el conocimiento, no solo el código. El humano se convierte en curador, no en escritor.
La ventaja de la legibilidad
Uno de los aspectos más concretos de la propuesta, y a menudo el que convence más fácilmente a quienes vienen de experiencias de RAG empresarial, se refiere a la transparencia. Al tratar los archivos Markdown como fuente de verdad, Karpathy evita el problema de la "caja negra" de los vectores embedding. Cada afirmación del modelo puede rastrearse hasta un archivo .md específico que un ser humano puede leer, modificar o eliminar.
Esta característica tiene implicaciones prácticas no banales. En un sistema RAG, cuando el modelo devuelve una respuesta errónea o parcial, rastrear el origen del problema requiere entender qué fragmentos se han recuperado, cómo se han segmentado y por qué la búsqueda por similitud ha privilegiado ciertos vectores frente a otros. En una wiki Markdown bien estructurada, el error es visible: hay un artículo mal escrito, un enlace de retroceso faltante, una información no actualizada. Es un problema editorial, no un problema de álgebra lineal.
La arquitectura está construida deliberadamente sobre Markdown como estándar abierto e independiente de las herramientas. Si Obsidian desapareciera o cambiara las condiciones de su licencia, la base de conocimientos seguiría siendo un directorio de archivos en texto plano que cualquier editor puede abrir. Es una forma de soberanía sobre los propios datos que las soluciones empresariales tienden a no ofrecer.
Lex Fridman confirmó que usa un sistema similar, añadiendo una capa de visualización dinámica: genera HTML con JavaScript para ordenar y filtrar los datos, y construye minibases de conocimientos temporales centradas en un tema específico para cargarlas en modo voz durante sus carreras de 10-15 kilómetros. Esta "wiki efímera" prefigura una dirección interesante: no se chatea con una IA, se genera un equipo de agentes para construir un entorno de investigación personalizado para una tarea específica, que luego se disuelve.
Hay también una implicación a largo plazo que Karpathy menciona solo de pasada pero que merece ser nombrada. A medida que la wiki es repetidamente revisada ("linted") y refinada, se convierte en una representación cada vez más limpia del dominio: deduplicada (la información aparece una sola vez), con enlaces cruzados, escrita en un estilo coherente. En ese punto, la base de conocimientos se convierte en candidata como datos de entrenamiento: en lugar de hacer prompting continuamente sobre un gran modelo general con la wiki, un equipo podría hacer fine-tuning de un modelo más pequeño sobre ese corpus curado, codificando la base de conocimientos en los pesos del modelo y transformando un archivo personal o departamental en una inteligencia especializada privada.
Donde el RAG resiste
La narrativa del "RAG ha muerto" que circuló por las redes sociales en los días posteriores al post de Karpathy es exactamente el tipo de simplificación que hace daño. El RAG no ha muerto, y hay contextos precisos en los que sigue siendo el enfoque adecuado, a menudo el único practicable.
El primer límite de la propuesta de Karpathy es explicitado por el propio Karpathy: la escala. Cuando el número de artículos crece más allá de unos pocos cientos, o las fuentes superan los millones de palabras, el propio índice se vuelve demasiado grande para caber en la ventana de contexto, y la recuperación vuelve a ser necesaria. El enfoque está explícitamente posicionado para uso personal y en equipos pequeños, no para archivos documentales a nivel de empresa. Una empresa con millones de documentos, sistemas heredados heterogéneos, requisitos de cumplimiento estrictos y cientos de usuarios simultáneos necesita algo más robusto que un directorio de archivos Markdown.
El segundo límite se refiere a la frescura de los datos. El RAG es particularmente adecuado cuando las fuentes cambian con frecuencia y no se puede permitir "recompilar" el conocimiento cada vez. Un asistente de soporte al cliente que debe responder usando la documentación actualizada de un producto en continua evolución, o un sistema de análisis financiero que debe incorporar noticias de mercado en tiempo real, necesita recuperación dinámica, no una wiki que se actualiza periódicamente.
El tercero, quizás el más insidioso, es el que en los comentarios al GitHub Gist se denomina "memory drift" (deriva de la memoria). Con el crecimiento de la base de conocimientos, ¿cómo se gestiona la deriva semántica, el fenómeno por el cual el significado de un término, un concepto o una afirmación se desplaza gradualmente en el tiempo, con cada reescritura o síntesis, alejándose de la intención original sin que nadie se dé cuenta explícitamente, y cómo se evita que las informaciones contradictorias se acumulen?
Cada vez que el modelo reescribe o sintetiza un artículo, hay un riesgo: si la síntesis es imprecisa, o si dos fuentes contradictorias se integran de forma inconsistente, el error entra en la base y se propaga. En el RAG, un documento equivocado permanece aislado en el corpus y puede ser corregido o eliminado. En una wiki compilada por la IA, el error puede haber sido reformulado y distribuido en varios artículos conectados, lo que hace que la corrección sea mucho más complicada.
Algunas propuestas en la comunidad sugieren integrar el sistema con SQLite, BM25 y TREESEARCH para gestionar mejor el crecimiento del corpus, y diversos comentaristas subrayan que los seres humanos deben permanecer en el bucle para gestionar el contexto del conocimiento preparado por la IA y prevenir derivas e incoherencias.
Está también la cuestión de la procedencia de las fuentes. Una wiki bien formateada es transparente en su estructura, pero no necesariamente en el origen de las afirmaciones. Sin un sistema riguroso de citas internas que rastree cada afirmación hasta el documento de origen original, se obtiene legibilidad sin verificabilidad, una distinción que en contextos regulados, médicos o legales marca una diferencia sustancial.
¿Híbrido o ajuste de cuentas?
Como escribió un analista en un comentario al Gist, la LLM Wiki es esencialmente una implementación manual y rastreable de Graph RAG: cada afirmación remite a las fuentes, las relaciones son explícitas y la estructura es legible por los humanos. Es un punto que aclara mucho: los dos enfoques no son opuestos filosóficos, son soluciones de ingeniería optimizadas para contextos diferentes, y la frontera entre ellos es más permeable de lo que el debate en línea sugiere.
Algunos equipos ya están intentando cerrar la brecha con arquitecturas multiagente: un diseño de "Swarm Knowledge Base" escala el flujo de trabajo de Karpathy a un sistema de 10 agentes orquestados por una capa de control, añadiendo modelos supervisores para proteger la wiki compartida de alucinaciones que se acumulan. Un modelo centrado en la evaluación, usado como "puerta de calidad", evalúa y valida los borradores de las páginas antes de que entren en la base de conocimientos activa.
El futuro más plausible no es la victoria de uno de los dos paradigmas sobre el otro. Es una arquitectura estratificada donde una wiki estructurada y compilada gestiona el conocimiento de dominio estable, actualizado con ciclos periódicos supervisados por humanos, mientras que la recuperación dinámica interviene para las fuentes en vivo, los datos frescos y los corpus que cambian demasiado rápido para ser compilados. La memoria estructurada como cimiento, la recuperación como ventana al mundo exterior, la revisión humana como control de calidad que ningún sistema automático puede aún sustituir por completo.
En el Gist, Karpathy anota que su uso de tokens se ha desplazado de la generación de código a la gestión del conocimiento estructurado, una nota aparentemente marginal que en realidad señala un cambio de prioridad en el uso real de los modelos avanzados. La gestión del conocimiento se está convirtiendo en el centro de gravedad del trabajo con los modelos lingüísticos, no la generación de código.
La verdadera pregunta no es si Karpathy "vence" al RAG. Es qué arquitectura maximiza la fiabilidad, la capacidad de actualización y el valor operativo en el contexto específico en el que opera. Para un investigador independiente, un equipo pequeño que construye documentación técnica interna o un trabajador del conocimiento que quiere que su asistente de IA deje de tener amnesia en cada sesión, la propuesta de Karpathy es concreta, implementable hoy y resuelve un problema real. Para una empresa con millones de documentos, datos que cambian cada hora y requisitos de gobernanza estrictos, el RAG en su forma evolucionada, tal vez enriquecido con elementos de la propuesta de Karpathy, sigue siendo la única opción viable.
Para los equipos que están evaluando si adoptar este enfoque o invertir en una tubería RAG completa, la respuesta honesta es: empezad con esto y pasad al RAG solo cuando la ventana de contexto se convierta en un verdadero cuello de botella, no en un problema hipotético. Probablemente os sorprenderá lo lejos que os lleva el Markdown estructurado. No es el fin del RAG. Es el comienzo de una conversación más sofisticada sobre cómo los sistemas de IA gestionan la memoria a lo largo del tiempo, una conversación que hasta hace dos semanas casi nadie mantenía de la forma adecuada.