Saltar a contenido

LLM Wiki Method

Método propuesto por Andrej Karpathy (abril 2026) para construir bases de conocimiento personales donde un LLM auto-organiza markdown con wikilinks, sustituyendo RAG/embeddings por navegación por enlaces.

Contexto

Karpathy publicó el método en X explicando que venía usándolo para mantener knowledge bases sobre temas de investigación. El tweet se volvió viral y un gist de seguimiento aclaró detalles. La clave: a esta escala (cientos de páginas), un LLM moderno puede leer índices y seguir wikilinks suficientemente bien como para no necesitar semantic search.

"I thought that I had to reach for fancy rag, but the LLM has been pretty good about auto-maintaining index files and brief summaries of all documents and it reads all the important related data fairly easily at this small scale." — Karpathy, citado en karpathy just 10xd everyones claude code

Arquitectura mínima

vault/
├── CLAUDE.md     # define cómo opera el agente sobre el wiki
├── raw/          # sources crudos (PDFs, transcripts, clippings)
└── wiki/
    ├── index.md  # punto de entrada con categorías
    ├── log.md    # historial de ingests y lints
    ├── hot.md    # [[concepts/hot-cache|cache opcional]] del contexto reciente
    └── (páginas, opcionalmente en subcarpetas — ver [[concepts/flat-vs-nested]])

Ver index log pattern para el rol del índice y log.

Fases

  1. Data ingest — dumpear source → el agente crea páginas wiki con wikilinks.
  2. Q&A — consultar; el agente entra por index.md y sigue enlaces.
  3. Lint / health check — detección periódica de inconsistencias y gaps.

Por qué NO usar RAG aquí

Ver la tabla comparativa completa en llm wiki vs semantic rag. Resumen:

  • Markdown + wikilinks da relaciones explícitas en lugar de similaridad vectorial aproximada.
  • Infraestructura ≈ cero (sólo archivos). RAG requiere embedding model + vector DB + chunking pipeline.
  • Costo ≈ sólo tokens. RAG suma compute + almacenamiento.
  • Mantenimiento = "linting" conversacional. RAG exige re-embed al cambiar documentos.
  • Trade-off: ver scaling limits — no escala a millones de docs.

Relaciones

Abierto / gaps

  • No tenemos el tweet ni el gist original de Karpathy como sources. Candidato al próximo ingest.
  • Sin evidencia independiente del número "95% de reducción de tokens" (anécdota de X).