Saltar a contenido

Límites de escala del LLM Wiki

El concepts/llm-wiki-method no escala a enterprise. A partir de cierto volumen conviene un pipeline tradicional de RAG — ver analysis/llm-wiki-vs-semantic-rag.

Límite cualitativo citado

"If you have hundreds of pages with good indexes, you're fine with wiki graph. But if you were getting up to the millions of documents, then you're going to want to actually do more of a traditional rag pipeline." — autor del video citando a entities/andrej-karpathy

Factores que marcan el límite

  1. Context window del LLM: el agente necesita tener el índice + un puñado de páginas en contexto. Si index.md por sí solo no cabe, el método degrada.
  2. Costo por query: con el wiki inflado, cada Q&A lee muchas páginas. Los tokens se disparan.
  3. Precisión de wikilinks: a gran escala, muchas relaciones son dobles, redundantes o inconsistentes. El lint no escala a mano.
  4. Multi-usuario / multi-agente: archivos en folder + git no es concurrencia-safe para decenas de autores simultáneos.

Sweet spot

  • Individual o equipo chico — sí.
  • Research, second brain, knowledge base de dominio específico — sí.
  • Corpus empresarial de millones de docs / miles de usuarios — RAG u otro sistema.

Mitigaciones posibles (no en el video, ideas propias)

  • Sharding por sub-tema: un wiki por dominio — es justamente lo que hacemos en este repo con projects/<slug>/.
  • Jerarquía de índices (index.md del proyecto → sub-índices).
  • Externalizar sources gigantes a raw/ y no duplicar en wiki/.

Relaciones