Cómo crear una Wiki Local para LLMs (Claude, GPT, Gemini)
En resumen: junta en una carpeta todo el material sobre un tema (vídeos, PDFs, código, notas) y pídele a la IA que lo lea y lo convierta en una “wiki” ordenada en otra carpeta. A partir de ahí, cada vez que trabajes con Claude, ChatGPT o Gemini, le pasas la wiki en lugar del material original: encuentra lo que necesita mucho más rápido y deja de inventarse cosas. Sin servidores, sin coste extra, en 15 minutos.
Llevas meses peleándote con lo mismo: le pides algo a Claude, GPT o Gemini, y el modelo se pasa media respuesta buscando contexto, leyendo archivos enormes o inventándose detalles porque no encuentra lo que necesita. Cada interacción empieza desde cero. Cada búsqueda es lenta. Y cada token que se gasta en “explorar” es un token que no se gasta en pensar.
Hay una solución ridículamente simple que casi nadie está usando: construye una wiki local de lo que sea. Un repositorio de conocimiento estructurado, en Markdown, optimizado para que un LLM lo lea como si fuera un índice de biblioteca. Y lo mejor: la wiki la genera el propio LLM por ti.
Esto no es RAG con embeddings ni una base vectorial. Es algo más rudimentario, más barato, y para muchos casos funciona mejor.
La idea en una frase
Reúne fuentes brutas en una carpeta, pídele a un LLM que las convierta en una wiki bien organizada, y a partir de ese momento usa la wiki como contexto en lugar de las fuentes originales.
Eso es todo. No hay servidores, ni infraestructura, ni vectores. Es una carpeta de Markdown.
El truco está en que una wiki bien estructurada es el formato perfecto para un LLM: índices, secciones cortas, referencias cruzadas, jerarquía clara. Andrej Karpathy — ex-director de IA en Tesla, fundador de OpenAI y una de las voces más respetadas del mundo del deep learning — lo explicó perfectamente en este gist que se ha convertido en una especie de manifiesto entre quienes trabajamos con agentes a diario.
Por qué esto acelera tanto a los LLMs
Cuando un LLM tiene que “investigar” un tema, hace algo parecido a lo que harías tú abriendo Google: lee, descarta, vuelve atrás, abre otra fuente. Cada uno de esos pasos consume tokens, tiempo y atención.
Con una wiki local pasa lo contrario:
- Encuentra la información a la primera. Los títulos y la jerarquía guían al modelo directamente al fragmento útil.
- No tiene que resumir nada. La wiki ya está pre-resumida y estructurada para consumo de máquina.
- Mantiene coherencia entre sesiones. El mismo conocimiento, en el mismo formato, conversación tras conversación.
- Funciona offline y es gratis de consultar. No hay API de embeddings que pagar.
En la práctica, he visto agentes que tardaban 40 segundos en encontrar una respuesta resolverla en 4 cuando tienen la wiki delante.
Los 2 únicos ingredientes que necesitas
1. Una fuente de conocimiento
Cualquier cosa que quieras “destilar”:
- Transcripciones de YouTube (con
yt-dlp --write-auto-subo herramientas similares) - PDFs de libros o papers — déjalos tal cual, los modelos agénticos modernos (Claude, GPT, Gemini) ya los leen directamente sin necesidad de convertirlos a Markdown
- Repositorios de código clonados localmente
- Apuntes, notas, documentación interna
- Artículos guardados, threads de Twitter, capturas
Mete todo en una carpeta. La estructura ideal:
mi-wiki/
├── raw/ # Fuentes originales
│ ├── youtube/
│ ├── books/
│ └── papers/
└── wiki/ # Aquí se generará la wiki2. Un LLM con acceso a esa carpeta
Claude Code, Cursor, Aider, o cualquier agente que pueda leer/escribir archivos en tu disco. Si trabajas en la web (Claude.ai, ChatGPT), puedes hacerlo con proyectos y subiendo los archivos. Si quieres ir un paso más allá y exponer la wiki como una herramienta consumible por cualquier agente, échale un vistazo a cómo convertir una API REST en un MCP con FastMCP.
El prompt que lo desencadena todo
Aquí está el prompt base. Funciona sorprendentemente bien tal cual:
Dado el directorio `raw/` donde he recopilado todas las fuentes de
información sobre [TEMA], crea una wiki en `wiki/` siguiendo las
instrucciones de este gist de Karpathy:
https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
Objetivo: la wiki debe ser consumida por un LLM como contexto, no
por humanos. Prioriza estructura clara, índice navegable, secciones
cortas y referencias cruzadas entre temas.Si no vas a usar Claude
El gist de Karpathy está pensado con Claude en mente. Si tu consumidor final es GPT-5, Gemini 3, DeepSeek o cualquier otro, añade al final del prompt:
Importante: la wiki NO se va a consumir con Claude, sino con
[GPT-5 / Gemini 3 / el LLM que sea]. Adapta el formato, las
convenciones de Markdown, y la longitud de secciones a lo que
mejor funciona con ese modelo en particular.Cada modelo tiene sus preferencias: Gemini agradece tablas y bullets, GPT trabaja mejor con secciones cortas y numeradas, Claude tolera prosa más larga. Que sea el propio LLM quien optimice.
El caso bonus: usa este método para documentar tu código
Esto es lo que más me ha cambiado el día a día. Tu propio proyecto también puede tener su wiki, y mantenerla actualizada cuesta literalmente cero.
El prompt cambia mínimamente:
Crea un directorio `wiki/` dentro del proyecto. La fuente de
conocimiento es el propio código fuente del repositorio.
Genera una wiki orientada a que un LLM la use como contexto cuando
trabaje en este código: arquitectura, módulos principales,
convenciones, flujos de datos, decisiones de diseño no obvias.
Cada vez que te pida un "ingest", analiza ÚNICAMENTE los cambios
desde el último ingest (consulta git log o un archivo
`wiki/.last-ingest` que tú mismo mantengas) y actualiza las
secciones afectadas de la wiki. No regeneres todo desde cero.El resultado es brutal: en lugar de que el agente lea 40 archivos cada vez que abres una sesión para buscar dónde se valida un email, abre wiki/auth.md y lo encuentra en dos segundos. Y la wiki se mantiene sola porque se actualiza incrementalmente con cada commit.
El flujo completo en 5 pasos
- Crea las carpetas
raw/ywiki/. - Vuelca las fuentes en
raw/(transcripciones, PDFs, código, lo que sea). - Lanza el prompt al LLM para que genere la wiki inicial.
- Revisa por encima y corrige errores groseros si los hay.
- A partir de ahora, consume la wiki, no las fuentes brutas. Repite el ingest cuando añadas material nuevo.
Wiki local vs RAG: no compiten, resuelven búsquedas distintas
Esta es la parte que casi nadie explica bien. La diferencia entre una wiki local y un RAG no es de “calidad” ni de “escala”. Es del tipo de búsqueda que hace cada uno.
RAG = búsqueda semántica (por significado)
Un RAG con embeddings convierte cada fragmento de texto en un vector y busca por similitud de significado. Le preguntas algo y te devuelve los trozos cuyo “vector está cerca” de tu pregunta, aunque las palabras no coincidan.
Es lo que necesitas cuando:
- No sabes dónde está la información y quieres que el sistema la encuentre por ti.
- Trabajas con muchísimos documentos (miles o millones): manuales, tickets de soporte, jurisprudencia, papers.
- Las consultas son abiertas y exploratorias: “¿qué casos parecidos tenemos a este?”, “muéstrame ejemplos de clientes que cancelaron por precio”.
- El contenido cambia constantemente y no puedes mantener una jerarquía estable.
- Sirves a muchos usuarios con preguntas impredecibles (chatbots de soporte, asistentes legales, buscadores internos).
Wiki local = búsqueda estructural (por jerarquía)
Una wiki local no busca por significado: navega por índice, títulos y referencias cruzadas, igual que tú abres una enciclopedia. El LLM lee el índice, identifica la sección relevante y va directo allí.
Es lo que necesitas cuando:
- Sí sabes (o el LLM puede deducir) dónde está la información porque tiene estructura clara.
- El material es acotado y estable: un proyecto, un libro, un curso, una API, tu propio second brain.
- Las consultas son concretas y dirigidas: “cómo se valida un email aquí”, “qué dice el capítulo 3 sobre X”.
- Necesitas coherencia, control y versionado: revisar la wiki a mano, hacer diff, commitear cambios.
- Trabajas tú o un equipo pequeño, no miles de usuarios concurrentes.
La regla práctica
| Pregunta | Mejor herramienta |
|---|---|
| ”Encuéntrame todo lo que se parece a esto” | RAG |
| ”Llévame a la sección sobre esto” | Wiki |
| ”¿Hay algún precedente parecido?” | RAG |
| ”¿Cómo funciona el módulo de auth?” | Wiki |
| Corpus de 10.000+ documentos cambiantes | RAG |
| Un proyecto, un libro, una API | Wiki |
| Búsqueda difusa por concepto | RAG |
| Navegación por temas y subtemas | Wiki |
Y lo mejor: se combinan de maravilla. En proyectos serios verás los dos juntos — wiki para el conocimiento estructurado de alto nivel, RAG para el long tail de documentos sueltos. El LLM decide cuál usar según el tipo de pregunta.
Para tu día a día como dev o knowledge worker, sin embargo, una wiki local cubre el 90% de los casos. Sin infra. Sin coste. Versionada con git.
El insight que me ha llevado a hacer esto en todo
Los LLMs no tienen un problema de inteligencia. Tienen un problema de acceso a la información correcta en el momento correcto. Todo el trabajo de los próximos años va a ir hacia ahí: contexto persistente, memoria, RAG, MCP, agentes con herramientas.
Una wiki local es la versión más barata, más rápida y más controlable de ese mismo principio. Y puedes empezar hoy, con cero infraestructura, en 15 minutos.
Abre una terminal. Crea las dos carpetas. Pega el prompt. Mira lo que pasa.
Te apuesto a que tu próxima conversación con Claude o GPT va al doble de velocidad.
Preguntas frecuentes
¿Qué diferencia hay entre una wiki local y un RAG?
Un RAG busca por similitud semántica usando embeddings vectoriales: es ideal cuando tienes muchísimos documentos y haces consultas exploratorias. Una wiki local busca por estructura jerárquica (índice, títulos, referencias): es ideal cuando el material es acotado y las consultas son dirigidas. No compiten; resuelven búsquedas distintas y suelen combinarse.
¿Funciona con ChatGPT, Gemini o DeepSeek, o solo con Claude?
Funciona con cualquier LLM que pueda leer archivos locales (Claude Code, Cursor, Aider, Continue) o aceptar archivos como contexto (Claude.ai Projects, ChatGPT con archivos, Gemini con Drive). El único ajuste es indicar en el prompt qué modelo será el consumidor final, para que adapte el formato.
¿Cuánto cuesta montar una wiki local?
Cero en infraestructura: son archivos Markdown en una carpeta. El único coste es el de la generación inicial (unas cuantas llamadas al LLM que ya pagas) y los ingests incrementales, mucho más baratos que mantener una base vectorial activa 24/7.
¿Puedo usarla para documentar mi propio código?
Sí, es uno de los mejores casos de uso. Apuntas la fuente al repositorio, pides un ingest inicial y luego le indicas al LLM que analice solo los cambios desde el último ingest (vía git log o un archivo .last-ingest). La wiki se mantiene sola a medida que el proyecto evoluciona.
¿Cuándo NO conviene una wiki local?
Cuando manejas decenas de miles de documentos que cambian constantemente, cuando sirves a muchos usuarios a la vez con preguntas impredecibles, o cuando necesitas búsqueda difusa por concepto en lugar de navegación por temas. En esos casos, un RAG con embeddings es la herramienta correcta.