El RAG de Obsidian de Karpathy Mató Mi Base de Datos Vectorial

El RAG de Obsidian de Karpathy Mató Mi Base de Datos Vectorial

Estaba sumergido en un pipeline RAG tradicional cuando Andrej Karpathy publicó algo en X que me hizo cuestionar cada decisión arquitectónica de los últimos seis meses.

Sin base de datos vectorial. Sin embeddings. Sin estrategia de chunking. Sin umbrales de similaridad que ajustar. Solo archivos markdown, una estructura de carpetas y un LLM que actúa como bibliotecario y autor a la vez.

Mi primera reacción fue escepticismo. He construido sistemas RAG. He debuggeado fallos de retrieval, luchado con configuraciones de chunk overlap, y visto documentos perfectamente relevantes enterrados bajo puntuaciones de similaridad coseno que no tenían sentido. La idea de que podías saltarte toda esa infraestructura y obtener mejores resultados para una base de conocimiento personal se sentía como si alguien dijera que podías adelantar un coche caminando — en la dirección correcta.

Entonces lo construí. Y la metáfora de caminar en la dirección correcta resultó ser incómodamente precisa.

El sistema de Karpathy — que él llama "LLM Knowledge Bases" — funciona porque explota algo que la mayoría de los arquitectos RAG pasan por alto: para datasets de menos de unas 400.000 palabras (aproximadamente 100 artículos sustanciales), una estructura markdown bien organizada con resúmenes y archivos de índice le da al LLM más contexto útil del que la búsqueda vectorial podría jamás. El modelo no recupera fragmentos. Navega por un grafo de conocimiento que él mismo construyó, siguiendo enlaces que él mismo creó, leyendo resúmenes que él mismo escribió.

Esa distinción — el LLM como autor de la estructura de conocimiento, no solo un consumidor de chunks recuperados — cambia todo sobre cómo el sistema rinde. Y es la parte que la mayoría de la cobertura del enfoque de Karpathy entierra bajo el titular.

Por Qué el RAG Tradicional Falla a la Escala en que la Mayoría de la Gente Realmente Trabaja

Aquí hay algo que nadie en el ecosistema RAG quiere admitir: para el 90% de los desarrolladores individuales y equipos pequeños, el RAG tradicional es excesivo y empeora activamente los resultados.

No estoy hablando de búsqueda empresarial a través de millones de documentos. Ese es un problema diferente con restricciones diferentes. Hablo del desarrollador que tiene 50-200 artículos marcados, un puñado de papers de investigación, algo de documentación de repos, y una pila creciente de notas sobre las que quiere que un LLM razone.

Para ese caso de uso — que describe a la mayoría de nosotros — el pipeline RAG tradicional introduce tres problemas que los sistemas markdown-first simplemente no tienen.

El problema del chunking. Cada sistema RAG divide documentos en chunks. El tamaño del chunk es un compromiso: demasiado pequeño y pierdes contexto, demasiado grande y desperdicias tokens en texto irrelevante. No hay un tamaño de chunk universalmente correcto, y la elección equivocada degrada silenciosamente cada consulta. He pasado tardes enteras ajustando porcentajes de overlap de chunks, y la verdad honesta es que siempre se sentía como si estuviera negociando con el sistema en lugar de configurarlo.

El problema del ruido en retrieval. La búsqueda por similaridad vectorial devuelve los chunks matemáticamente más similares, no los más útiles. He tenido consultas donde los top-5 chunks recuperados eran todos de la misma sección del mismo documento — cinco párrafos ligeramente diferentes diciendo casi lo mismo — mientras que el insight realmente relevante de otro documento estaba en la posición 47 de los resultados. Relevancia y similaridad no son lo mismo, y la búsqueda vectorial optimiza para lo incorrecto.

El problema de la caja negra. Con una base de datos vectorial, no puedes ver fácilmente qué hay dentro. No puedes navegar tu base de conocimiento como navegas una carpeta. No puedes verificar manualmente si un documento fue indexado correctamente. No puedes detectar vacíos en tu cobertura escaneando una lista. Los datos desaparecen en embeddings, y solo interactúas con ellos a través de consultas que pueden o no mostrar lo que necesitas.

El sistema de Karpathy esquiva los tres. Sin chunking — el LLM lee resúmenes estructurados y sigue enlaces a documentos completos cuando es necesario. Sin similaridad vectorial — el LLM navega un índice que construyó y entiende. Sin caja negra — cada pieza de conocimiento vive en un archivo markdown legible que puedes abrir en cualquier editor de texto.

¿El trade-off? No escala a millones de documentos. Pero si tu base de conocimiento se mide en cientos de artículos en lugar de millones, ese trade-off es uno de los mejores acuerdos en IA ahora mismo.

Cómo Funciona Realmente la Base de Conocimiento LLM de Karpathy

El 3 de abril de 2026, Karpathy publicó un GitHub gist llamado llm-wiki que expone la arquitectura completa. El sistema tiene tres capas, y entender cómo interactúan es la clave para hacerlo funcionar.

Capa 1: La Bóveda Raw

Todo comienza en una carpeta raw/ dentro de un vault de Obsidian. Esta es el área de staging — un vertedero para cualquier cosa que quieras que el LLM eventualmente conozca. Artículos recortados de la web. Papers de investigación en PDF. Documentación de repositorios. Capturas de pantalla. Fragmentos de código. Transcripciones de podcasts.

La carpeta raw tiene una regla: nada en ella necesita estar organizado. Tiras cosas dentro, y el LLM las organiza después. Esto importa más de lo que parece. La mayoría de los sistemas de gestión del conocimiento fallan porque la fricción de ingesta es demasiado alta — tienes que etiquetar cosas, categorizar cosas, archivar cosas en el lugar correcto. Con el enfoque de Karpathy, la ingesta es tan simple como arrastrar un archivo a una carpeta.

Para artículos web, Karpathy usa el Obsidian Web Clipper — una extensión de Chrome que convierte cualquier página web en un archivo markdown y lo coloca directamente en tu carpeta raw. Un clic. El artículo está en tu sistema, imágenes incluidas.

Hablando de imágenes: Obsidian no maneja automáticamente las imágenes inline de páginas web recortadas. Necesitas el plugin comunitario "Local Images Plus", que descarga imágenes remotas y las almacena localmente dentro del vault. Sin este plugin, tus artículos recortados tendrán enlaces de imágenes rotos una vez que estés offline — y el LLM no podrá referenciar contenido visual a través de sus capacidades de visión.

Capa 2: El Wiki Compilado

Aquí es donde el sistema de Karpathy diverge de cualquier otro enfoque de gestión del conocimiento que haya visto.

En lugar de indexar los documentos raw para retrieval, el LLM los lee y escribe nuevos documentos. Compila el material crudo en un wiki estructurado — artículos estilo enciclopedia sobre conceptos fundamentales, resúmenes de documentos fuente, y backlinks explícitos entre ideas relacionadas.

El wiki vive en una carpeta wiki/, paralela a raw/. Dentro, encontrarás:

• Un índice maestro (index.md) — un solo archivo markdown listando cada wiki creado, con descripciones breves y enlaces. Este es el punto de partida del LLM para cualquier consulta. Lee el índice maestro, identifica qué wiki es relevante, luego navega al propio índice y artículos de ese wiki.

• Carpetas de sub-wiki — cada tema obtiene su propia carpeta con su propio index.md y un conjunto de artículos compilados. Un wiki sobre "arquitecturas transformer" podría contener artículos sobre mecanismos de atención, codificación posicional y leyes de escalamiento, todos interconectados.

• Backlinks y referencias cruzadas — el LLM crea [[enlaces estilo wiki]] entre conceptos relacionados a través de diferentes wikis. Estos no son decorativos. Son la estructura de navegación que el LLM usa al responder consultas que abarcan múltiples temas.

El paso de compilación es donde el LLM demuestra su valor. No está copiando texto de documentos raw a artículos wiki. Está sintetizando — identificando los conceptos fundamentales, escribiendo explicaciones claras, notando contradicciones entre fuentes, y construyendo una red de conexiones que ninguna base de datos vectorial podría replicar.

Así es como se ve un prompt de compilación en la práctica. Apuntas tu agente LLM (Karpathy usa Claude Code) a la carpeta raw y dices algo como:

Lee los archivos en raw/ que se relacionen con [tema].
Crea un nuevo wiki en wiki/[nombre-del-tema]/ con:
1. Un index.md listando todos los artículos en este wiki
2. Artículos individuales para cada concepto principal
3. Backlinks a wikis relacionados donde sea relevante
4. Actualiza el master wiki/index.md para incluir este nuevo wiki

El LLM hace la investigación, escribe los artículos, construye los enlaces y actualiza los índices. Revisas la salida en la UI de Obsidian — limpia, navegable, legible por humanos.

Capa 3: La Interfaz de Consulta

Cuando le haces una pregunta al LLM sobre tu base de conocimiento, no busca a través de documentos raw. Sigue un camino estructurado:

1. Lee el master wiki/index.md para identificar wikis relevantes
2. Abre el index.md del wiki relevante para encontrar artículos específicos
3. Lee esos artículos (que contienen conocimiento sintetizado más referencias a fuentes)
4. Sigue backlinks a conceptos relacionados si la pregunta abarca temas
5. Devuelve una respuesta fundamentada en el wiki compilado, citando artículos específicos

Esto se parece más a cómo trabaja un investigador humano que cualquier cosa que ofrezca la búsqueda vectorial. Un investigador no escanea cada documento en una biblioteca buscando coincidencias de palabras clave. Revisa el índice, encuentra la sección correcta, lee los artículos relevantes y sigue referencias a material relacionado.

La diferencia de rendimiento es real. Para el dataset de Karpathy de aproximadamente 100 artículos y 400.000 palabras, el enfoque de navegación por wiki dio respuestas más coherentes y mejor documentadas que un pipeline RAG tradicional — porque el LLM estaba razonando sobre conocimiento estructurado que ya había sintetizado, no intentando dar sentido a chunks recuperados en tiempo real.

Configurándolo Desde Cero: La Guía Completa

Reconstruí el sistema de Karpathy en mi propia máquina en menos de una hora. Aquí está cada paso, incluyendo los que la mayoría de las guías omiten.

Paso 1: Instalar Obsidian y crear la estructura del vault.

Descarga Obsidian desde obsidian.md. Es gratis para uso personal. Crea un nuevo vault — Obsidian te pedirá que elijas una carpeta. Nombré el mío vault y lo puse en mi directorio home, pero la ubicación no importa.

Dentro del vault, crea dos carpetas:

vault/
  raw/
  wiki/

Esa es toda la estructura de archivos para empezar. La carpeta wiki se llenará a medida que compiles.

Paso 2: Instalar el Web Clipper.

Ve a obsidian.md/clipper e instala la extensión de Chrome. En la configuración del clipper, establece la ubicación de guardado predeterminada en tu carpeta raw/. Ahora cualquier artículo web está a un clic de estar en tu base de conocimiento.

Pruébalo inmediatamente. Recorta un artículo que tenías pendiente de leer. Abre Obsidian y confirma que el archivo markdown apareció en raw/. Si las imágenes no se muestran, necesitas el paso 3.

Paso 3: Instalar Local Images Plus.

En Obsidian, ve a Configuración > Plugins Comunitarios > Explorar. Busca "Local Images Plus" e instálalo. Activa el plugin, luego configúralo para descargar imágenes a una subcarpeta dentro de tu vault (yo uso vault/assets/images/).

Después de activar este plugin, recorta de nuevo un artículo web. Las imágenes ahora deberían descargarse localmente y mostrarse correctamente en el modo de vista previa de Obsidian. Esto es especialmente crítico si recortas artículos técnicos con diagramas, gráficos de arquitectura o capturas de código — el contexto visual importa, y los LLMs modernos con capacidades de visión pueden realmente leer estas imágenes.

Paso 4: Llenar tu carpeta raw.

Esta es la parte divertida. Empieza a volcar contenido en raw/. Algunas fuentes que funcionan bien:

• Posts técnicos de blog que has marcado (usa el Web Clipper)
• Papers de investigación (guardar como PDF o convertir a markdown)
• READMEs de repos de GitHub (copiar el markdown directamente)
• Tus propias notas, esquemas y documentación de proyectos
• Transcripciones de charlas de conferencias
• Ediciones de newsletters que has guardado

No los organices. No los renombres. No los etiquetes. Solo mételos en la carpeta. El LLM se encarga de la organización en el siguiente paso.

Empecé con 63 artículos sobre arquitecturas de agentes IA — una mezcla de posts de blog, papers y mis propias notas de proyecto. El total llegó a unas 180.000 palabras de material crudo.

Paso 5: Crear tu primera compilación wiki.

Aquí es donde traes a tu agente LLM. Si usas Claude Code (que recomiendo para este flujo de trabajo porque maneja operaciones de archivos nativamente), navega a tu directorio del vault y ejecuta un prompt de compilación.

Aquí está el prompt que usé para mi primer wiki:

Revisa los archivos en raw/ que discutan arquitecturas de agentes IA,
sistemas multi-agente o patrones de orquestación de agentes.

Crea un wiki en wiki/ai-agent-architectures/ con:
- Un index.md que liste cada artículo en el wiki con una descripción de una línea
- Artículos individuales para conceptos principales (al menos: patrones de
  orquestación, patrones de uso de herramientas, arquitecturas de memoria,
  comunicación multi-agente)
- Cada artículo debe sintetizar información de múltiples fuentes raw
- Incluir [[backlinks]] a conceptos relacionados dentro del wiki
- Al final de cada artículo, listar los archivos fuente raw de los que se nutrió
- Crear wiki/index.md (el índice maestro) si no existe,
  y agregar este wiki

Claude Code leyó los archivos raw relevantes, identificó los conceptos clave y generó un wiki con 11 artículos, un índice comprehensivo y referencias cruzadas entre ellos. Todo el proceso tomó unos cuatro minutos.

La calidad del output me sorprendió. No era simple resumen — era síntesis genuina. Un artículo sobre "Arquitecturas de Memoria para Agentes IA" extrajo insights de siete fuentes raw diferentes, los organizó en un framework coherente, y notó dónde dos de las fuentes se contradecían sobre la cuestión de persistencia de memoria a largo plazo.

Paso 6: Configurar el índice maestro.

Después de tu primera compilación, wiki/index.md debería existir. Ábrelo en Obsidian y verifica que se vea bien. A medida que crees más wikis, este archivo se convierte en el punto de entrada del LLM — la tabla de contenidos de toda tu base de conocimiento.

Un índice maestro saludable se ve algo así:

# Índice de Base de Conocimiento

## Wikis

### Arquitecturas de Agentes IA
Patrones de orquestación, uso de herramientas, sistemas de memoria y
frameworks de comunicación multi-agente.
→ [[ai-agent-architectures/index]]

### Leyes de Escalamiento de Transformers
Compute de entrenamiento, conteos de parámetros, requisitos de datos y
capacidades emergentes a través de tamaños de modelo.
→ [[transformer-scaling/index]]

Paso 7: Consultar tu base de conocimiento.

Ahora viene la recompensa. Cuando quieras hacer una pregunta a tu base de conocimiento, le dices a Claude Code que empiece por el índice maestro:

Lee wiki/index.md para orientarte sobre lo que está disponible en mi
base de conocimiento. Luego responde esta pregunta usando los artículos
wiki relevantes: [tu pregunta aquí]

El LLM lee el índice, identifica el wiki relevante, navega a los artículos específicos y te da una respuesta fundamentada en tu conocimiento compilado — con referencias a artículos específicos que puedes verificar.

Pro tip: agrega un changelog.md a la raíz de tu vault. Cada vez que compiles un nuevo wiki o actualices uno existente, registra la fecha y qué cambió. Karpathy recomienda un formato de prefijo consistente como ## [2026-04-05] ingest | Título del Artículo para que el log sea parseable con herramientas unix estándar. Esto te da (a ti y al LLM) una línea de tiempo de cómo ha evolucionado la base de conocimiento.

Lo Que Esto Hace Bien Que el RAG Tradicional Hace Mal

Después de ejecutar ambos sistemas en paralelo durante una semana — mi antiguo pipeline RAG basado en vectores en el mismo dataset junto al wiki estilo Karpathy — noté tres ventajas específicas que no son obvias hasta que has usado ambos.

La ventaja de síntesis. Cuando le pregunté a mi sistema vector RAG "¿Cuáles son los trade-offs entre orquestación de agentes centralizada y descentralizada?", devolvió cinco chunks de tres documentos diferentes. Los chunks eran relevantes, pero tuve que sintetizarlos mentalmente yo mismo. El sistema wiki ya había hecho esa síntesis durante la compilación. El artículo sobre patrones de orquestación presentó los trade-offs en una comparación estructurada, extrayendo de los mismos documentos fuente pero presentándolos como un argumento coherente en lugar de fragmentos.

La ventaja de descubrimiento. La estructura de backlinks del wiki hace emerger conexiones que no preguntaste. Cuando consulté el sistema wiki sobre arquitecturas de memoria, la respuesta hizo referencia a un backlink a un concepto en el wiki de "patrones de uso de herramientas" que no había conectado mentalmente. El backlink existía porque el LLM, durante la compilación, notó que el problema de persistencia de memoria en agentes es estructuralmente similar al problema de gestión de estado en cadenas de herramientas. La búsqueda vectorial no encuentra estas conexiones porque no son léxicamente similares — están conceptualmente relacionadas a un nivel que requiere comprensión, no matching.

La ventaja de transparencia. Cuando el sistema wiki me da una respuesta, puedo abrir los artículos fuente en Obsidian y leerlos yo mismo. Puedo ver qué sintetizó el LLM, puedo verificar si la síntesis es precisa, puedo corregirla si está equivocada. Con vector RAG, obtengo chunks y puntuaciones de similaridad. Debuggear por qué el sistema dio una mala respuesta significa excavar a través de embeddings y logs de retrieval. Con el sistema wiki, abro un archivo markdown y lo leo. La superficie de debugging es texto legible por humanos.

Si prefieres que alguien construya un sistema completo de base de conocimiento LLM personalizado para tu flujo de trabajo de investigación específico, acepto exactamente este tipo de proyectos de infraestructura IA. Puedes ver lo que he construido en fiverr.com/s/EgxYmWD.

Las Limitaciones Honestas — Dónde Este Enfoque Se Quiebra

Te estaría haciendo un flaco favor si no expusiera los límites claramente. El sistema de Karpathy es brillante para su caso de uso previsto, pero tiene restricciones reales que importan.

Techo de escala. Este enfoque funciona para aproximadamente 100-400 artículos (hasta unas 400.000 palabras de material crudo). Más allá de eso, el LLM empieza a tener dificultades para mantener índices coherentes y el tiempo de compilación crece sustancialmente. Si estás tratando con miles de documentos, necesitas RAG tradicional o un enfoque híbrido. El punto de equilibrio depende de la ventana de contexto de tu LLM — con el contexto de 1M tokens de Opus 4.6, puedes ir más allá de las estimaciones originales de Karpathy, pero sigue habiendo un techo práctico.

Costo de compilación. Cada vez que agregas material nuevo significativo, necesitas recompilar el wiki afectado. Eso significa llamadas al LLM, lo que significa tokens, lo que significa dinero. Para un proyecto hobby, esto es insignificante. Para una base de conocimiento que se actualiza continuamente con ingesta diaria, los costos de compilación se acumulan. He encontrado que el batching — acumular material crudo durante una semana y luego compilar una vez — mantiene los costos razonables.

Sin retrieval en tiempo real. El wiki es una instantánea. Si recortaste un artículo hace diez minutos pero no has recompilado el wiki relevante, el LLM no sabrá de él durante una consulta. Puedes apuntarlo a la carpeta raw directamente para adiciones recientes, pero eso es un paso manual. Los sistemas RAG tradicionales indexan nuevos documentos en segundos tras la ingesta.

Diseño de usuario único. Esto es fundamentalmente un sistema de gestión del conocimiento personal. No hay control de acceso multiusuario, no hay salvaguardas de edición concurrente, no hay historial de versiones más allá de lo que git proporciona. Para equipos, necesitarías construir infraestructura de colaboración encima — punto en el cual podrías estar mejor servido con un sistema RAG construido para ese propósito.

Dependencia del LLM. La calidad de tu wiki está directamente ligada a la calidad del LLM que hace la compilación. He probado esto con modelos más pequeños y los resultados son notablemente más débiles — la síntesis es más superficial, las referencias cruzadas son menos perspicaces, y la organización del índice es menos intuitiva. Quieres un modelo frontera para el paso de compilación. Para consultas, un modelo más pequeño a menudo puede funcionar bien porque solo está navegando un wiki bien estructurado.

Estos no son dealbreakers. Son límites de diseño. Karpathy construyó este sistema para un perfil específico — un investigador o desarrollador individual gestionando una base de conocimiento personal de tamaño moderado — y dentro de esos límites, funciona mejor que cualquier otra cosa que haya probado.

Lo Que Haría Diferente Después de Una Semana Usando Esto

Mi primera compilación wiki fue descuidada. No porque el LLM hiciera un mal trabajo, sino porque le di demasiado material crudo a la vez sin un límite temático claro. Apunté a Claude Code a 63 artículos y dije "haz un wiki sobre agentes IA." El resultado fue extenso — 11 artículos cubriendo todo desde prompt engineering hasta coordinación multi-agente hasta tool calling, con backlinks conectando conceptos que estaban relacionados solo en el sentido más amplio.

La segunda vez, fui más quirúrgico. Agrupé mis archivos raw en clusters temáticos aproximados antes de compilar: 18 artículos sobre patrones de orquestación en un lote, 12 sobre arquitecturas de memoria en otro, 15 sobre uso de herramientas en un tercero. Cada uno se convirtió en su propio wiki con su propio índice enfocado. Las referencias cruzadas entre wikis fueron más significativas porque cada wiki tenía un alcance claro.

Esa es mi mayor lección práctica: compila estrecho, enlaza amplio. Cada wiki debería cubrir un tema acotado. Las conexiones entre wikis emergen naturalmente a través de backlinks, y esas conexiones son más valiosas cuando puentean dominios genuinamente distintos en lugar de enlazar párrafos adyacentes en el mismo tema extenso.

Segunda lección: revisa la primera compilación de cada wiki manualmente. El LLM ocasionalmente toma decisiones estructurales que tú no tomarías — agrupando conceptos diferentemente de lo esperado, o creando artículos con una granularidad que no coincide con cómo piensas sobre el tema. Una revisión y reestructuración de 10 minutos después de la primera compilación te salva de agravar problemas estructurales a medida que el wiki crece.

Tercera lección: tu carpeta raw se desordenará, y está bien. Empecé intentando organizar archivos raw en subcarpetas por tipo de fuente. Fue esfuerzo desperdiciado. Al LLM no le importa si tus archivos raw están organizados. Los lee todos, extrae lo relevante e ignora el resto. Deja que el wiki sea tu capa organizada. Deja que raw sea tu cajón de sastre.

He estado construyendo sistemas de gestión del conocimiento personal con Obsidian durante un tiempo — si has leído mi guía sobre convertir Obsidian y Claude Code en un segundo cerebro, reconocerás algunos de estos patrones. Pero el enfoque de compilación de Karpathy va más allá. Mi configuración original usaba Obsidian principalmente como fuente de contexto — apuntar el LLM a archivos markdown y dejarlo leer. La visión de Karpathy es que el LLM también debería escribir la estructura de conocimiento, no solo consumirla.

Dónde Encaja Esto en el Paisaje RAG de 2026

El timing del post de Karpathy no fue accidental. Estamos en un punto de inflexión donde las herramientas para construir sistemas de conocimiento se han bifurcado en dos campos.

Campo uno: plataformas RAG pesadas con bases de datos vectoriales, pipelines de embedding, modelos de reranking y estrategias de retrieval complejas. Están construidas específicamente para escala empresarial — millones de documentos, miles de consultas concurrentes, requisitos estrictos de latencia. Funcionan. Pero son caras de construir, caras de mantener, y excesivas para cualquiera cuya colección de documentos cabe en una carpeta.

Campo dos: lo que Karpathy llama "LLM Knowledge Bases." Archivos markdown, índices estructurados, wikis compilados por LLM. Cero infraestructura más allá de un editor de texto y una API de LLM. Están construidas específicamente para investigadores individuales, desarrolladores y equipos pequeños cuya base de conocimiento se mide en cientos de artículos, no millones.

El error que la mayoría comete es usar herramientas del campo uno para problemas del campo dos. He visto desarrolladores solo levantar instancias de Pinecone para gestionar 40 documentos. Eso no es ingeniería, es arquitectura guiada por el currículum. La herramienta correcta para una base de conocimiento de 40 documentos es una carpeta de archivos markdown y un LLM inteligente.

Si tus necesidades crecen más allá de lo que el enfoque markdown-first maneja, siempre puedes migrar. Los archivos raw son texto plano. Los wikis son texto plano. No hay formato propietario, no hay vendor lock-in, no hay pesadilla de migración. Tomas tus archivos markdown y los alimentas en cualquier sistema al que gradúes.

Ese es quizás el aspecto más infravalorado del diseño de Karpathy: optimiza para la ruta de salida, no solo la ruta de entrada. Cada pieza de conocimiento en el sistema se almacena en el formato más portable posible. Si Obsidian desaparece mañana, tus archivos siguen funcionando en VS Code, Notion, Bear o cualquier otro editor markdown. Si superas el sistema, tu contenido se muda contigo.

Si ya estás usando Obsidian con Claude Code para memoria persistente — algo que cubrí en profundidad en mi post sobre por qué Obsidian arregló la mayor debilidad de Claude Code — el enfoque de compilación wiki de Karpathy es el paso natural siguiente. Ya estás almacenando contexto en markdown. Ahora deja que el LLM organice ese contexto en algo por lo que pueda navegar inteligentemente.

El Cambio Que Importa Más Que Los Detalles Técnicos

Sigo volviendo a una única distinción que hace que el enfoque de Karpathy se sienta fundamentalmente diferente del RAG tradicional.

En un sistema RAG tradicional, el LLM es un consumidor. Recibe chunks, los lee y genera una respuesta. La estructura de conocimiento — los embeddings, el índice, la lógica de retrieval — es construida por infraestructura de ingeniería, no por el modelo mismo.

En el sistema de Karpathy, el LLM es tanto arquitecto como residente. Construye la estructura de conocimiento durante la compilación. Escribe los resúmenes, crea los enlaces, organiza el índice. Luego, durante las consultas, navega una casa que él mismo diseñó. Sabe dónde están las cosas porque las puso allí.

Eso no es una distinción de ingeniería menor. Es un paradigma diferente para cómo pensamos sobre LLMs y conocimiento.

La mayor parte de la comunidad IA en 2026 está enfocada en hacer el retrieval más inteligente — mejores embeddings, mejor reranking, mejor selección de chunks. Karpathy está haciendo una pregunta completamente diferente: ¿qué si dejamos de tratar al LLM como un motor de búsqueda y empezamos a tratarlo como un bibliotecario investigador? No uno que encuentra libros bajo demanda, sino uno que ya ha leído cada libro en la colección, escrito resúmenes de cada uno, creado un catálogo de referencias cruzadas, y puede llevarte directamente al estante que necesitas.

Esa pregunta va a importar más a medida que las ventanas de contexto sigan creciendo. Con Opus 4.6 manejando 1 millón de tokens, la cantidad de conocimiento que un LLM puede navegar a través de índices estructurados — sin ninguna búsqueda vectorial — ya es práctica para la mayoría de casos de uso personales y de equipos pequeños. Y las ventanas de contexto solo están creciendo.

Mi base de datos vectorial no va a ningún lado. Todavía la necesito para el sistema RAG de producción que construí para el archivo de 2 millones de documentos de un cliente. Pero ¿para mi base de conocimiento personal? ¿Para la investigación que estoy haciendo sobre agentes IA, los artículos que estoy leyendo, las ideas que estoy coleccionando? La base de datos vectorial está desenchufada. El vault de Obsidian está abierto. Y por primera vez, mi base de conocimiento se siente como algo que realmente puedo navegar, no solo consultar.

Empieza con 20 artículos sobre un tema que estés investigando activamente. Recórtalos en raw. Ejecuta una compilación. Hazle una pregunta al wiki. Ve qué conecta. La configuración toma una hora. El momento en que hace emerger una conexión entre dos ideas que tú no habías vinculado — ahí es cuando entenderás por qué Karpathy construyó esto en vez de recurrir a otra base de datos vectorial.

Preguntas Frecuentes

¿El sistema RAG de Obsidian de Karpathy requiere habilidades de programación?

Se necesita programación mínima. El sistema usa Obsidian (gratis, gráfico) para la interfaz y un agente LLM como Claude Code para la compilación wiki. Escribes prompts en lenguaje natural, no código. Comodidad básica con la línea de comandos ayuda pero no es estrictamente requerida.

¿Cuántos documentos puede manejar el sistema wiki de Obsidian?

El enfoque de Karpathy funciona bien para aproximadamente 100-400 artículos totalizando hasta 400.000 palabras. Más allá de eso, los tiempos de compilación crecen y la coherencia del índice se degrada. Para colecciones más grandes, un enfoque híbrido o pipeline RAG tradicional es más apropiado.

¿Puedo usar GPT u otros LLMs en vez de Claude Code para la compilación wiki?

Sí. El gist de GitHub de Karpathy menciona explícitamente compatibilidad con OpenAI Codex, Claude Code y otros agentes LLM. La calidad de compilación depende de la capacidad de razonamiento del modelo — los modelos frontera producen notablemente mejor síntesis y referencias cruzadas que modelos más pequeños.

¿Qué pasa si Obsidian deja de ser mantenido?

Nada se rompe. Cada archivo en el sistema es markdown plano almacenado localmente en tu máquina. Puedes abrir toda la base de conocimiento en VS Code, Notion, Bear o cualquier editor de texto. Hay cero vendor lock-in por diseño.

¿En qué se diferencia esto de simplemente poner archivos en una carpeta y usar ChatGPT?

La diferencia crítica es el paso de compilación. Archivos raw vertidos en un chat le dan al LLM contexto no estructurado. El sistema de Karpathy hace que el LLM compile esos archivos en artículos wiki estructurados con índices, resúmenes y referencias cruzadas — creando una estructura de conocimiento navegable en lugar de un montón de documentos.

Trabajemos Juntos

¿Buscas construir sistemas IA, automatizar flujos de trabajo o escalar tu infraestructura tech? Me encantaría ayudar.

• Fiverr (builds personalizados e integraciones): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (soluciones enterprise): ramlit.com
• ColorPark (diseño y branding): colorpark.io
• xCyberSecurity (servicios de seguridad): xcybersecurity.io