← Volver al blog

Los wikis en Markdown están reemplazando silenciosamente a RAG. Te explicamos por qué.

· Save Team
ragllmknowledge-basekarpathymcpaisave-vaultmarkdown

Durante dos años, la respuesta estándar a “¿cómo le doy mi conocimiento a un LLM?” fue RAG. Construir una base de datos vectorial. Dividir tus documentos en chunks. Generar embeddings. Ejecutar búsqueda de vecinos más cercanos en el momento de la consulta. Reunir los resultados de nuevo en el prompt.

Funcionaba. Más o menos. Cualquiera que haya lanzado un sistema RAG en producción conoce los fallos: chunks que pierden contexto, embeddings que recuperan el pasaje equivocado, rankings opacos, sin trazabilidad, casos límite extraños cuando el usuario pregunta algo para lo que el índice no estaba preparado.

En abril de 2026, Andrej Karpathy publicó un flujo de trabajo que no hace casi nada de eso y funciona mejor para el conocimiento personal. Él lo llama LLM Knowledge Bases. La arquitectura es simplemente una carpeta de archivos Markdown, un LLM con acceso al sistema de archivos y un hábito. VentureBeat lo describió como “una biblioteca Markdown en evolución mantenida por IA” — una descripción que captura lo que realmente es nuevo.

El patrón post-RAG ya está aquí. Este artículo explica qué es, por qué funciona y cómo Save Vault lo hace accesible sin ninguna configuración técnica.

Qué intentaba resolver RAG

El problema original: los LLMs tienen una ventana de contexto fija, tu base de conocimiento es mayor que esa ventana, así que necesitas una forma de recuperar el fragmento relevante para cada pregunta.

En 2023, los vectores eran la respuesta obvia. Embebe todo, busca por similitud, inyecta los top-k chunks. Encajaba bien con las pequeñas ventanas de contexto de GPT-3.5 y Claude 1. El patrón típico de las “startups de IA” era “RAG sobre X.”

Tres cosas cambiaron.

  1. Las ventanas de contexto se dispararon. Claude lanzó contexto de 1M de tokens este año. Gemini y GPT-5 son similares. Un millón de tokens son aproximadamente 750.000 palabras — suficiente para tener un wiki pequeño completamente en memoria.
  2. Se lanzó el Filesystem MCP. Los LLMs ahora pueden abrir archivos en disco directamente. No necesitan chunks preindexados. Pueden navegar, leer y releer como un humano.
  3. Los LLMs mejoraron en la lectura. Claude Opus 4 puede procesar cientos de archivos en una sesión y razonar sobre ellos de forma coherente. El cuello de botella pasó de “calidad de recuperación” a “qué necesita realmente el humano.”

Una vez que esas tres cosas eran ciertas, RAG empezó a parecer un parche para limitaciones que ya no existen.

Cómo es el patrón del wiki Markdown

El sistema de Karpathy, simplificado:

  1. Carpeta raw. Cada página web que quiere conservar se guarda como archivo .md en un directorio raw/. Para esto usa Obsidian Web Clipper.
  2. Paso de compilación. Periódicamente, un agente LLM (Claude Code en su caso) lee todo lo que hay en raw/, genera páginas de conceptos, escribe resúmenes y crea backlinks. Esto produce un wiki estructurado sobre el material en bruto.
  3. Bucle de consultas. Cuando tiene una pregunta, se la hace al LLM. Este busca en el wiki, abre los archivos relevantes y responde usando el contenido.
  4. Paso de lint. Ocasionalmente el LLM escanea el wiki en busca de inconsistencias, datos faltantes o nuevas conexiones que valga la pena registrar.

Su wiki de investigación actual tiene ~100 artículos y ~400K palabras. Hace preguntas complejas y obtiene respuestas con fuentes.

Sin base de datos vectorial. Sin modelo de embedding. Sin estrategia de chunking. Sin ranking de recuperación. Solo archivos Markdown, una estructura de carpetas y un LLM que puede leerlos.

Por qué funciona mejor que RAG (para esto)

El patrón wiki tiene ventajas estructurales que RAG no puede igualar sin convertirse en un wiki en sí mismo.

La trazabilidad es gratis. Cada respuesta cita un archivo. Puedes abrirlo, leerlo, editarlo, borrarlo. Sin “el embedding lo dijo.”

Editar es trivial. Un archivo Markdown es texto. Ábrelo en cualquier editor. Corrige una errata. Añade una nota. Elimina una sección. La siguiente consulta refleja el cambio inmediatamente. Sin paso de re-embedding.

La estructura se acumula. Cuando el LLM compila el wiki, crea backlinks y páginas de conceptos. El wiki se vuelve mejor cuanto más guardas, porque el LLM tiene más contexto para conectar nuevas entradas. Un índice vectorial solo se hace más grande.

La portabilidad es total. Una carpeta de archivos .md funciona en Obsidian, VS Code, GitHub, Logseq, vim o cat. Una base de datos vectorial es una caja negra que necesita un runtime específico para leerla.

Tú mismo puedes leerlo. Esto parece obvio, pero es la mayor ventaja. A veces querrás saber qué hay en tu base de conocimiento. Con RAG, eso es una consulta de reporte. Con Markdown, es ls.

La compensación honesta: RAG sigue ganando cuando tienes millones de documentos, acceso multi-tenant o restricciones de latencia estrictas (piensa en chatbots de soporte al cliente sobre un corpus de millones de artículos de ayuda). Para el conocimiento personal — tus lecturas, tu investigación, tu dominio — el patrón wiki es ahora estrictamente mejor.

La pieza que falta: la ingesta

El patrón de Karpathy tiene una suposición silenciosa: que obtener Markdown limpio en la carpeta raw/ es fácil. Para desarrolladores que ya usan Obsidian Web Clipper, más o menos lo es. Para todos los demás, este es el paso donde el flujo de trabajo muere.

Web Clipper puede tener problemas con páginas de pago, sitios con mucho JavaScript, contenido de video, hilos de X y cualquier cosa dinámica. La gente guarda HTML garbled, se rinde y concluye “lo del wiki no es para mí.”

La extensión Save existe específicamente para solucionar este paso. Usa Gemini para extraer contenido limpio de páginas arbitrarias, incluyendo:

  • Artículos detrás de muros de pago a los que tienes acceso
  • Videos de YouTube (transcripción completa + resumen de IA)
  • Hilos de X/Twitter
  • Reels de Instagram y subtítulos de TikTok (transcritos)
  • Discusiones de Reddit
  • Documentación con bloques de código intactos
  • SPAs dinámicas con las que los clippers tradicionales fallan

Un clic. Markdown limpio al otro lado. Ponlo en la carpeta.

La otra pieza que falta: la configuración de MCP

El patrón de Karpathy también asume que puedes configurar un servidor MCP. Para usuarios de Claude Code, esto es un cd de una línea. Para todos los que usan Claude Desktop, significa editar un archivo de configuración JSON y reiniciar la app — y acertar con la ruta, y recordar hacerlo de nuevo cuando mueves las carpetas.

Save Vault colapsa ambas piezas que faltan en una sola app:

  • La extensión Save alimenta automáticamente Markdown limpio en Save Vault
  • Save Vault escribe en ~/Documents/Save Vault/ organizado en bases de conocimiento (subcarpetas)
  • Un servidor MCP integrado expone list_knowledge_bases, list_files, read_file y search a Claude
  • El interruptor “Connect to Claude” en la barra de menú conecta el servidor MCP con Claude Desktop y Claude Code, sin editar JSON

El resultado es el patrón Karpathy con las asperezas eliminadas. Guarda una página → llega a tu vault → Claude puede responder preguntas sobre ella. Sin base de datos vectorial, sin chunking, sin embeddings.

Cómo se ve esto en la práctica

Imagina que estás investigando a un competidor.

Día 1. Guardas su página de precios, tres posts del blog y un hilo de Hacker News sobre su ronda seed. Cinco archivos en tu KB Competitors.

Día 5. Le preguntas a Claude: “¿Qué cambios de precios ha hecho esta empresa en el último año y cómo han reaccionado los clientes?” Claude busca en tu KB Competitors, lee los archivos relevantes, cita la página de precios, saca la opinión del hilo de HN y responde — todo con fuentes.

Día 30. Tienes 40 archivos entre Competitors, Customers y AI Research. Le pides a Claude que compile cada KB en un wiki. Escribe páginas de conceptos, las enlaza, señala contradicciones. Ahora tienes tres wikis vivos que puedes consultar como motores de búsqueda, pero mejor — porque solo contienen lo que has curado.

Día 90. Tus wikis son más completos que cualquier informe de analista que comprarías, más actualizados que cualquier presentación de consultor, y completamente tuyos. Cada afirmación está respaldada por un archivo que tú guardaste.

Así se siente una base de conocimiento personal cuando la fricción desaparece. RAG se suponía que debía entregar esto y no lo hizo. El patrón Karpathy sí lo hace — una vez que las piezas de ingesta y MCP están conectadas para ti.

Pruébalo

  1. Instala la extensión Save para Chrome
  2. Instala Save Vault desde savemarkdown.co
  3. Activa Connect to Claude en la barra de menú
  4. Guarda 10 cosas que has querido leer
  5. Abre Claude y haz una pregunta que las conecte entre sí

Ese es el flujo de trabajo post-RAG. Ya está reemplazando a las bases de datos vectoriales para el conocimiento personal. Lo único que queda es empezar a construir el tuyo.


Save Vault es gratuito. La extensión Save es gratuita para 3 guardados al mes, $3,99/mes ilimitado. savemarkdown.co.