Saltar a contenido

LLM Wiki vs Semantic Search RAG

Tabla comparativa entre el método de Karpathy y un pipeline clásico de RAG con embeddings. Reproducida y traducida de la tabla generada por entities/claude-code dentro del vault del autor del video.

Tabla

Dimensión LLM Wiki Semantic Search RAG
Recuperación Lee index.md y sigue wikilinks (relaciones explícitas) Similarity search sobre embeddings de chunks
Representación Markdown + wikilinks = grafo de conocimiento humano-legible Vectores densos en un índice ANN
Infraestructura Sólo archivos. Cero servicios Embedding model + vector DB + chunking pipeline
Costo operativo Tokens del LLM al consultar Cómputo para embeddings + storage del vector DB + tokens del LLM
Mantenimiento "Lint" conversacional al agente Re-embed cuando cambia el corpus
Profundidad de relaciones Rica — las relaciones son links que el humano/agente crearon Aproximada — depende de cuán parecidos sean los chunks
Explicabilidad Alta: puedes seguir el path de wikilinks Baja: ¿por qué esos chunks matchearon?
Setup inicial Minutos (copiar un prompt, crear un vault) Horas-días (elegir embedding, tunear chunking, deployar DB)
Sweet spot Decenas–cientos de páginas de un solo usuario Cientos de miles–millones de documentos en enterprise

Por qué la comparación es justa pero no simétrica

  • RAG es una solución de recuperación general; el LLM Wiki es una solución de organización que hace la recuperación trivial. La pregunta "¿cuál usar?" es realmente "¿a qué escala estoy operando?".
  • La calidad del LLM Wiki depende de la calidad del trabajo de ingest — si el agente hace un mal trabajo de extracción, los wikilinks son ruido.
  • RAG degrada elegantemente en escala; el LLM Wiki degrada catastróficamente más allá del context window del modelo.

¿Mata el LLM Wiki al RAG?

Según el video: "no, but kind of yes". Para uso personal/equipos pequeños, sí lo reemplaza. Para enterprise con millones de docs, RAG sigue siendo necesario. Ver analysis/scaling-limits.

Relaciones