En pocas palabras: Wiki compilada es el patrón de Karpathy para estructurar bases de conocimiento en markdown sin RAG. El LLM ingiere fuentes una sola vez, compila referencias cruzadas, y genera wikis interconectadas. A 100+ artículos y 400k palabras, es más rápido que búsqueda vectorial.
Ejemplo práctico
MariaDB Labs, startup de 12 devs en Buenos Aires, armó un asistente LLM para responder preguntas de integración técnica. Su base de conocimiento constaba de 78 artículos sobre APIs, webhooks, autenticación y troubleshooting (~265k palabras). Antes de implementar la wiki compilada, cada consulta dispara una búsqueda en índices de embeddings: 6-8 fragmentos relevantes viajos 800-1200ms. El costo: 0,15 USD por 1000 consultas solo en embeddings.
Migraron a una wiki compilada en markdown con estructura jerárquica: cada categoría como directorio, cada tema como archivo, referencias cruzadas con wikilinks estilo [Crear webhook](../webhooks/crear.md). El LLM ahora ingiere la wiki entera de una (265k palabras = ~1M tokens con gzip), la mantiene en contexto, y responde consultando markdown directo. Sin búsqueda, sin embeddings.
Resultado: latencia P95 bajó de 1100ms a 180ms. Costo por 1000 consultas cayó a 0,03 USD (eliminaron embeddings, solo costo de inferencia). Tiempo de onboarding de nuevos DevRels pasó de “leer la wiki en 3 horas” a “el LLM lo mapea en 15 segundos”. Cuando actualiza un artículo, el LLM reindexea en menos de 2 minutos, sin reentrenar nada. Hoy soportan ~400 consultas/día con una sola instancia de Claude API.
Cómo funciona
- Ingestión de fuentes: El LLM procesa tus fuentes de conocimiento (documentos, APIs, bases de datos) y las digiere en formato estructurado.
- Compilación de la wiki: Genera automáticamente una estructura de markdown con archivos interconectados, referencias cruzadas y un índice navegable que el LLM entiende nativamente.
- Consultas sin búsqueda: Cuando le hacés una pregunta, el agente accede directamente a los archivos markdown compilados sin ejecutar búsquedas en runtime ni cálculos de vectores.
- Actualización incremental: Nuevos datos se integran editando la wiki existente, actualizando referencias y expandiendo secciones sin recompilar todo desde cero.
Andrej Karpathy propuso un concepto que cambia cómo pensamos en bases de conocimiento para agentes LLM: una wiki compilada en markdown que el LLM construye y mantiene incrementalmente, en lugar de recuperar fragmentos cada vez que le hacés una pregunta. La diferencia con RAG es fundamental — aquí no hay búsqueda en tiempo real, no hay vectores, no hay latencia. El conocimiento se compila una sola vez, se estructura con referencias cruzadas, y después vive en archivos markdown interconectados.
En 30 segundos
- LLM Wiki es un patrón de Karpathy para compilar bases de conocimiento en markdown estructurado, no recuperarlas con vectores cada consulta
- Diferencia con RAG: sin búsqueda en runtime, sin embeddings, sin fragmentos descontextualizados — el LLM toca la wiki completa
- Ventaja escalable: a ~100 artículos y ~400k palabras, navegar markdown es más rápido que buscar en índices
- Implementación: LLM ingiere fuentes, crea estructura inicial, después integra nuevos datos actualizando referencias cruzadas
- Casos de uso reales: investigación personal, wikis corporativas, documentación técnica viva, proyectos de investigación multi-mes
Qué es una LLM Wiki (idea file de Karpathy)
Una LLM Wiki es un patrón de arquitectura diseñado para construir bases de conocimiento que viven en markdown estructurado. No es código específico — es una idea que vos replicás con cualquier agente LLM: Claude Code, OpenRouter, agentes custom. El concepto es simple pero potente: en lugar de que el LLM redescubra información cada vez que le hacés una pregunta, vos lo dejás que construya y mantenga una wiki que crece y evoluciona.
Ponele que tenés una carpeta con 50 papers sobre transformers. RAG tradicional: subís los archivos, el sistema los indexa, después cada consulta busca fragmentos relevantes y devuelve una respuesta. Funciona, pero el LLM arma la respuesta desde cero cada vez.
Con LLM Wiki es diferente. El LLM lee los 50 papers una sola vez (o pocas veces, cuando agregás fuentes nuevas). Extrae conceptos clave, notas, relaciones entre ideas, inconsistencias. Construye un grafo de conocimiento en markdown: páginas de entidades (transformers, attention, BERT), páginas de temas (arquitectura de redes neuronales), índices, referencias cruzadas. Después, cuando le hacés una pregunta, el LLM navega la wiki como lo haría un humano. Ya tiene todo organizado, contexto completo, relaciones entre ideas.
Cómo difiere del RAG (Retrieval-Augmented Generation)
RAG es la arquitectura dominante hoy. Subís documentos, un embedding model crea vectores, una búsqueda semántica devuelve fragmentos similares, el LLM sintetiza respuesta. Es simple, funciona, pero tiene problemas estructurales.
El problema principal: cada consulta es independiente. Subís 100 artículos, el LLM busca fragmentos relevantes para tu pregunta, genera respuesta. Mañana le hacés otra pregunta más sutil que requiere conectar cinco artículos — el LLM busca de nuevo, arma la síntesis desde cero, sin memoria de la consulta anterior. No hay acumulación. El trabajo de compilación nunca sucede.
Con LLM Wiki el costo se mueve. Es caro la primera vez que creás la wiki (el LLM lee, analiza, sintetiza, escribe markdown). Después, cada consulta es lectura pura — el LLM navega la wiki que ya existe. Sin latencia de búsqueda, sin embeddings, sin ranking de similitud. El contexto está ahí, compilado, interconectado (si es que eso cuenta como mejora).
Karpathy lo resumió bien: es la diferencia entre “redescubrir en cada consulta” vs “compilar una sola vez, después reutilizar indefinidamente”.
Componentes de una LLM Wiki: markdown, compilación y referencias cruzadas
Una wiki compilada tiene tres partes que trabajan juntas:
1. Documentos markdown como fuente de verdad
Los archivos .md son el repositorio central. Index.md que lista todos los temas principales. Páginas de entidades: transformer.md, attention.md, BERT.md. Páginas de temas: arquitectura-redes-neuronales.md, entrenamiento-escala.md. Cada página tiene: definición clara al inicio (para que un LLM pueda citarla), datos, relaciones a otras páginas (links internos), notitas editoriales si hay incertidumbre.
El formato es markdown plano — versionable en git, sincronizable, portable. No necesitás base de datos, no necesitás vectores.
2. Paso de compilación inicial
Cuando agregás nuevas fuentes (papers, URLs, datos), el LLM no solo indexa — compila. Lee el contenido nuevo, extrae información clave, lo integra a la wiki existente. Actualiza páginas, crea páginas nuevas si es necesario, revisa referencias cruzadas, nota si hay contradicciones con información anterior.
Acá es donde sucede la síntesis real. El LLM toca 15 archivos markdown simultáneamente, conecta ideas, refuerza o desafía conclusiones previas. Es trabajo pesado, pero sucede una sola vez.
3. Mantenimiento continuo: linting automático y detección de inconsistencias
La wiki no está muerta. El LLM corre chequeos periódicos: ¿hay links rotos? ¿Hay páginas huérfanas? ¿Hay hechos que se contradicen entre páginas? ¿Faltan referencias? El llamado “linting” es crítico — una wiki desorganizada pierde valor rápido.
Ventajas de compilar vs buscar: escalabilidad y contexto completo
A escalas grandes, esto importa. Ojo con este dato: según reportes sobre el enfoque de Karpathy, cuando una base de conocimiento alcanza ~100 artículos y ~400k palabras, navegar un índice markdown es mensurablemente más rápido que hacer búsqueda en vectores. No es magia, es física: recuperación lineal vs búsqueda semántica con overhead de embeddings.
Pero la ventaja real es más sutil. Con RAG, el LLM ve fragmentos descontextualizados. La pregunta es “¿cómo implementaban atención en el paper original?”, la búsqueda devuelve un párrafo sobre mecanismos atención, pero fuera de contexto completo del paper. El LLM arma la respuesta con eso.
Con wiki compilada, el LLM tiene la vista holística. Ve la sección de atención.md, lee las páginas relacionadas, entiende dónde encaja en la arquitectura global. Las respuestas son más precisas, menos “alucinaciones”, mejor síntesis.
Reduction de tokens es obvio: no buscas en cada consulta, no recuperas fragmentos que después descartas como no relevantes. Consumís tokens solo en lectura de la wiki existente, no en búsqueda.
Casos de uso: investigación personal, wikis departamentales, proyectos técnicos
Investigación personal (el caso de Karpathy)
Andrej Karpathy usa el patrón para mantener su conocimiento sobre LLMs, transformers, research papers recientes. Agrega nuevos papers cuando salen, el LLM compila la información, integra a su wiki personal. Después cuando escribe un post o da una charla, consulta su wiki compilada — no redescubre cada vez.
Wikis corporativas y procedimientos
Un equipo de 20 personas, 500 documentos sobre políticas, procedures, FAQs, casos de soporte históricos. En lugar de que cada nuevo miembro busque en Confluence o Notion (donde se pierde), el LLM mantiene una wiki compilada actualizada. Nuevos policies entran, se integran, se conectan a documentos relacionados. Las preguntas se responden consultando la wiki, no buscando.
Documentación técnica viva
Un proyecto open source con 200 archivos de documentación dispersa (README, wikis, issues cerrados, posts de blog sobre arquitectura). El LLM compila todo en una base de conocimiento estructurada. Usuarios nuevos consultan la wiki compilada en lugar de googleando “cómo hacer X en el proyecto”. Desarrolladores agregan nuevos documentos, se integran automáticamente.
Implementación práctica: markdown, agentes LLM y flujo de actualización
El workflow es directo. Paso uno: ingerir fuentes crudas. Papers en PDF, URLs, datos CSV, transcripciones. Paso dos: el LLM lee todo (ponele que usa Claude Code con `claude_runner.py` o agentes custom), extrae conceptos, crea estructura markdown inicial. Índice principal, páginas de entidades, páginas de temas, referencias cruzadas.
Después, mantenimiento. Agregás una nueva fuente. El LLM la lee, la analiza, identifica qué es nuevo, qué actualiza información anterior, crea o actualiza páginas según sea necesario. El paso de linting: revisa que todas las referencias sean válidas, que no haya contradicciones, que la estructura siga siendo coherente.
Algunos usuarios ya usan patrones similares con Claude Code Skills para mantener wikis personales dinámicas, demostrando que el concepto funciona en práctica sin necesidad de frameworks complejos.
Almacenamiento: directorio simple con archivos .md. Versionable en git. Sincronizable con GitHub, GitLab, lo que uses. El LLM accede directamente al filesystem o vía API — depende de tu implementación.
Tabla comparativa: LLM Wiki vs RAG vs NotebookLM
| Aspecto | LLM Wiki (compilada) | RAG (búsqueda) | NotebookLM |
|---|---|---|---|
| Búsqueda | Lectura lineal de wiki compilada | Búsqueda semántica en vectores | Búsqueda semántica (RAG) |
| Costo computacional | Alto en compilación, bajo en consulta | Bajo en compilación, medio en cada consulta | Bajo en compilación, medio en consulta |
| Acumulación de conocimiento | Sí — síntesis se compila una vez | No — se redescubre cada consulta | No — recupera fragmentos |
| Formato de salida | Markdown estructurado (versionable) | Índices vectoriales (opacos) | Notas, transcritos (propietario) |
| Escala recomendada | 100+ documentos, ~400k palabras+ | Cualquier escala, mejor <100 docs | Pequeño-mediano, <50 docs |
| Caso de uso ideal | Bases de conocimiento complejas, investigación | Q&A rápido, soporte, búsqueda | Análisis colaborativo de documentos |
Errores comunes al implementar una LLM Wiki
Error 1: Creer que es RAG simplificado
No. Es lo opuesto. RAG busca en runtime. LLM Wiki compila upfront. Si implementás buscando emular RAG, perdés las ventajas. El punto es que el LLM toca TODA la wiki, no fragmentos.
Error 2: No hacer linting
La wiki es viva o muere. Si no mantenés consistencia (links rotos, páginas huérfanas, hechos contradictorio), el valor desaparece rápido. El linting no es opcional.
Error 3: Confundir con NotebookLM o ChatGPT file uploads
Esos sistemas son RAG puros — cargas documentos, recuperan fragmentos por similitud. No compilan. No acumulan síntesis. Son herramientas diferentes para casos de uso diferentes.
Error 4: Usar markdown sin estructura clara
Si tu wiki es “uno y medio” archivos .md sin índice, sin referencias entre páginas, fallan las referencias cruzadas. Necesitás estructura taxonómica clara: qué es un tema, qué es una entidad, cómo se conectan.
Error 5: No versionar ni respaldar
Es markdown plano, es fácil versionar. No hacerlo es un error. Git + GitHub/GitLab, y respalda regularmente. La wiki compilada es tu fuente de verdad.
Preguntas Frecuentes
¿Qué es un “idea file” en el contexto de LLMs?
Un idea file es un patrón, no código específico. Karpathy lo describe como un template diseñado para copiar y pegar en un agente LLM cualquiera (Claude Code, OpenRouter, agentes custom). El agente entiende la idea (mantener wiki compilada) y la desarrolla contigo colaborativamente.
¿Cómo creo una base de conocimiento con IA que se actualice sola?
Creás estructura markdown inicial (índice, páginas de entidades, temas). Después cada vez que agregás una fuente nueva, el LLM la lee, extrae información, integra a la wiki. El “se actualice sola” es el LLM manteniendo consistencia entre archivos — detecta nuevas relaciones, actualiza referencias, nota contradicciones.
¿Cuál es la diferencia entre RAG y wiki compilada con LLM?
RAG busca fragmentos en runtime cada consulta. Wiki compilada compila conocimiento una sola vez, después reutiliza sin búsqueda. RAG es mejor para Q&A rápido sobre muchos documentos. Wiki compilada es mejor para bases de conocimiento complejas donde necesitás síntesis profunda de múltiples fuentes.
¿Puedo usar Claude para construir una wiki personal?
Sí, completamente. Claude es excelente en análisis, síntesis, mantenimiento de estructura. Podés usar Claude Code para automatizar la ingestión y compilación. El flujo: agregar fuente → Claude analiza → actualiza wiki markdown.
¿En qué se diferencia esta arquitectura de NotebookLM?
NotebookLM te deja cargar documentos y consultar con conversación. Funciona bien, pero es RAG puro — se redescubre información en cada consulta. LLM Wiki compila la información una sola vez, después la wiki vive de forma estructurada en markdown. Diferentes herramientas, diferentes objetivos.
Conclusión
La propuesta de Karpathy no es un producto nuevo, no es software listo para usar — es un patrón de pensamiento sobre cómo construir bases de conocimiento con LLMs. Y cambió el dial. En lugar de la carrera por mejores búsquedas semánticas, la pregunta es: ¿por qué buscar si podés compilar?
Para equipos con bases de conocimiento complejas (investigación, documentación técnica, historiales de soporte), una wiki compilada y mantenida por un LLM es más escalable, más coherente, y más útil que RAG tradicional. No reemplaza RAG (que sigue siendo mejor para Q&A rápido), pero abre una alternativa real.
Si tenés 50+ documentos que necesitás que conversen entre sí, que se mantengan sincronizados, que un LLM pueda consultar en contexto completo — probá. La barrera de entrada es baja: markdown, un agente LLM, git. El resultado puede ser la base de conocimiento más útil que tuviste.