La capa de conocimiento para IA: 127 páginas, cero bases de datos vectoriales y lo que entendimos mal

Andrej Karpathy publicó un gist en abril de 2026 describiendo un patrón para construir bases de conocimiento personales con LLMs. Acumuló 99.000 bookmarks en una semana. Varias implementaciones pasaron a ser open source en días. graphify se publicó en 48 horas y sumó 27.000 más. El patrón resonó porque puso nombre a un problema que todo usuario de IA ya sentía: tus agentes no tienen memoria. Cada conversación empieza desde cero. Vuelves a explicar tu negocio, tus objetivos, tu tono, tu contexto, y la respuesta llega genérica porque la entrada no tenía nada con qué trabajar.

En webvise ejecutamos una capa de conocimiento que impulsa nuestra investigación interna, la documentación de clientes y el pipeline de contenidos que produce este blog. Esto es lo que aprendimos.

El problema no es el prompt. Es la amnesia.

El flujo de trabajo estándar con IA es stateless. Abres un chat, explicas lo que necesitas, obtienes una respuesta, cierras el chat. En la siguiente sesión, la misma explicación de nuevo. El contexto que construiste ha desaparecido. La mayoría compensa escribiendo prompts más largos, copiando documentos de fondo o subiendo archivos al inicio de cada sesión. Funciona, pero no escala. En algún momento la ventana de contexto se llena, la calidad cae y pasas más tiempo preparando el prompt que haciendo el trabajo.

La capa de conocimiento resuelve esto a nivel de infraestructura. En lugar de meter contexto en cada prompt, le das al agente acceso a una base de conocimiento persistente y estructurada que lee antes de hacer cualquier cosa. El agente ya conoce tu negocio, tu voz, tus proyectos, tu historial. Te saltas la re-explicación y vas directo al trabajo.

Tres capas, sin base de datos vectorial

La arquitectura tiene tres partes:

• Fuentes en bruto. Una carpeta de documentos inmutables: artículos, notas, transcripciones, PDFs, grabaciones de reuniones, investigación. El agente los lee pero nunca los modifica. Son tu fuente de verdad.

• El wiki. Un directorio de archivos markdown generados por el LLM con referencias cruzadas. Páginas de entidades, páginas de conceptos, síntesis, comparativas, playbooks. El agente es el propietario de esta capa. Crea páginas, las actualiza cuando llegan nuevas fuentes, mantiene las referencias cruzadas y preserva la coherencia. Tú lo lees. El agente lo escribe.

• El esquema. Un documento de configuración (CLAUDE.md, AGENTS.md o equivalente) que le dice al agente cómo está estructurado el wiki, qué convenciones seguir y qué flujos de trabajo ejecutar. Esto es lo que convierte un LLM genérico en un mantenedor de wiki disciplinado.

El wiki es un artefacto compilado. El agente no re-deriva el conocimiento en cada consulta. Compila una vez, crea referencias cruzadas y se mantiene actualizado. Cuando añades una nueva fuente, el agente la integra en el wiki existente y actualiza cada página relevante. Cuando haces una pregunta, el agente lee páginas pre-compiladas en lugar de buscar entre documentos en bruto.

Por qué supera a RAG en la mayoría de casos

RAG re-deriva respuestas en el momento de la consulta fragmentando documentos y buscando fragmentos relevantes. El enfoque del wiki compilado se salta ese paso por completo. graphify midió 71,5 veces menos tokens por consulta comparado con buscar en archivos en bruto. Nuestras propias mediciones muestran aproximadamente 1.000 tokens de contenido del vault por consulta, frente a los 3.000 o más tokens que inyecta un pipeline RAG típico.

Escribimos una comparativa técnica completa de RAG frente a recuperación basada en índices. La versión corta: para bases de conocimiento de menos de 1.000 documentos, el wiki compilado supera a RAG en precisión, coste y complejidad. Sin base de datos vectorial, sin modelo de embeddings, sin estrategia de chunking, sin job de re-indexación. Cinco comandos de shell y un archivo de índice mantenido.

La evolución ocurrió en tres fases: RAG one-shot de 2020 a 2023, RAG agéntico con recuperación multi-hop de 2023 a 2024, y context engineering desde 2025, donde el agente construye su propio contexto a partir de múltiples fuentes. La capa de conocimiento es la infraestructura para esa tercera fase. La mayoría de equipos todavía están construyendo para la primera.

Lo que aprendimos ejecutando la nuestra

Nuestro wiki interno tiene actualmente 127 páginas estructuradas en siete categorías: personas, empresas, conceptos, playbooks, colecciones, síntesis y herramientas. Cada página sigue una plantilla estándar con frontmatter YAML, referencias cruzadas mediante wikilinks de Obsidian y atribución de fuentes. El agente ejecuta seis operaciones definidas: ingest, actualización conversacional, consulta, lint, enriquecimiento y reorganización.

• El archivo de esquema lo es todo. Todo lo demás se deriva de él. Un esquema bien escrito produce un wiki disciplinado con convenciones consistentes. Un esquema vago produce alucinaciones y dispersión. La versión actual tiene unas 200 líneas y cubre estructura de directorios, formato de páginas, las seis operaciones, convenciones de nombres y gestión de contradicciones. Tardamos varias iteraciones en afinarla.

• Dedup primero evita la proliferación de páginas. Nuestra regla: antes de crear cualquier página nueva, busca en el wiki existente contenido solapado. Si una página existente cubre el 60% o más del mismo terreno, enriquece esa página en lugar de crear una nueva. Sin esta regla, el wiki se llena de páginas redundantes que fragmentan el conocimiento en piezas inútiles.

• Las consultas se acumulan en la base de conocimiento. Cuando haces una buena pregunta y obtienes una respuesta útil, esa respuesta se archiva como una nueva página del wiki. La próxima vez que alguien haga una pregunta relacionada, el agente ya tiene una síntesis pre-compilada de la que partir. Este es el efecto compuesto que mejora el sistema con el tiempo, no solo lo hace más grande.

• La calidad del ingest depende completamente de la disciplina. Soltar un artículo en bruto y decir "ingest esto" produce un resumen superficial. Revisar la fuente con el agente, discutir los puntos clave y dirigir qué enfatizar produce páginas que siguen siendo útiles a medida que el wiki crece. Aplicamos un flujo de trabajo estricto: limpiar el archivo en bruto, discutir los puntos clave, esperar aprobación y luego extraer de forma completa.

• El archivo de índice es el sistema de recuperación. Nuestro índice raíz tiene 22 líneas. Cada subdirectorio tiene su propio índice que lista cada página con una descripción de una línea. El agente lee el índice raíz con aproximadamente 400 tokens, identifica el subdirectorio correcto, lee ese índice y luego accede a las páginas específicas que necesita. La mayoría de consultas terminan con tres lecturas y unos 1.000 tokens de contenido del vault.

El esquema es el archivo más importante que vas a escribir

Karpathy lo llama el esquema. Nosotros lo llamamos CLAUDE.md. Algunos frameworks lo dividen en una Knowledge Base Layer y una Brand Foundation. El nombre no importa. Lo que importa es que este único archivo controla cómo se comporta el agente en cada sesión.

Un buen esquema define:

• Estructura de directorios. Dónde van las fuentes en bruto, dónde van las páginas del wiki, cómo se organizan en categorías.

• Formato de página. Campos de frontmatter, estructura de secciones, reglas de atribución de fuentes, convenciones de referencias cruzadas.

• Operaciones. Flujos de trabajo paso a paso para ingerir fuentes, responder consultas, ejecutar comprobaciones de salud y mantener el wiki a lo largo del tiempo.

• Controles de calidad. Qué hace que una página esté completa. Cuándo marcar incertidumbre. Cómo gestionar fuentes contradictorias. La regla de que cada afirmación debe tener una fuente rastreable.

Sin esto, el agente improvisa. Crea páginas en ubicaciones aleatorias, usa formatos inconsistentes, duplica contenido entre páginas y se desvía de tus convenciones en cada sesión. El esquema previene la deriva. Lo tratamos como código de producción: cada cambio es deliberado y se prueba contra ingest real.

Cómo construir una en 20 minutos

No necesitas 17 archivos, un grafo de skills de contenido ni un pipeline de embeddings personalizado. Necesitas cuatro cosas:

• Un vault de Obsidian con dos carpetas. `raw/` para documentos fuente y `wiki/` para páginas generadas por el agente. Ábrelo en Obsidian para la vista de grafo y la navegación.

• Un archivo de esquema. Empieza con el gist de Karpathy. Personaliza la estructura de directorios y el formato de página para tu dominio. Mantenlo bajo 200 líneas para empezar.

• Un agente LLM con acceso a archivos. Claude Code, OpenAI Codex o cualquier agente que pueda leer y escribir archivos markdown. Apúntalo al vault. Lee el esquema al arrancar.

• Tu primera fuente. Suelta un artículo, un conjunto de notas o un documento en `raw/`. Dile al agente que lo ingeste. Mira cómo crea páginas del wiki, construye referencias cruzadas y actualiza el índice.

Ese es el bucle completo. El sistema mejora cada día porque cada fuente que añades y cada pregunta que haces enriquece el wiki. El primer ingest requiere 10 minutos de atención activa. Para el vigésimo, el agente conoce tu dominio lo suficientemente bien como para extraer y crear referencias cruzadas con una guía mínima.

Herramientas opcionales a medida que escala: qmd de Tobi Lutke para búsqueda híbrida local con BM25 y recuperación vectorial cuando superas las 300 páginas. La extensión Obsidian Web Clipper para llevar artículos web a tu carpeta raw rápidamente. Dataview para ejecutar consultas sobre el frontmatter de páginas. Git para el historial de versiones. Nada de esto es necesario para empezar.

Lo que no importa

La mayor parte de la complejidad que la gente asocia con los sistemas de conocimiento para IA es overhead para problemas que todavía no tienen. Una base de datos vectorial para 200 documentos. Un modelo de embeddings personalizado cuando un índice mantenido resuelve la recuperación. Un pipeline de re-indexación cuando añadir un documento significa escribir un archivo. Una estrategia de chunking cuando la página es la unidad. Nada de eso es necesario a la escala en que opera la mayoría de negocios.

El patrón funciona porque markdown es simple y los LLMs son buenos leyéndolo y escribiéndolo. El coste de infraestructura es cero. El coste de mantenimiento es casi cero porque el LLM hace las tareas administrativas. El único coste real es la disciplina para mantener el esquema honesto y la calidad del ingest alta. Eso es un problema humano, no tecnológico.

Qué significa esto para los negocios

La misma arquitectura funciona a escala empresarial. Sustituye las notas personales por documentación de clientes, playbooks de ventas, guías de onboarding y SOPs internos. Sustituye el agente de una persona por el agente de cada miembro del equipo leyendo desde una base de conocimiento compartida.

El patrón es idéntico: las fuentes en bruto entran, el agente compila páginas estructuradas, las referencias cruzadas se construyen automáticamente, los humanos validan. La diferencia es que una capa de conocimiento compartida hace que los nuevos miembros del equipo sean productivos de inmediato. Su agente ya conoce el historial del cliente, las convenciones internas y el contexto del proyecto. Sin seis semanas de rampa. Sin conocimiento tribal encerrado en la cabeza de alguien.

Karpathy lo llama LLM wiki. Eric Osiu lo llama shared brain. Cody Schneider lo llama data warehouse. El nombre sigue cambiando. El patrón no: los agentes necesitan conocimiento compilado y estructurado para hacer trabajo útil. Todo lo demás es prompting en el vacío.

En webvise, construimos capas de conocimiento para negocios que quieren que sus agentes de IA sepan realmente de lo que hablan. Si pasas más tiempo explicando contexto a tus herramientas que obteniendo valor de ellas, este es el problema que esto resuelve. Contacta con nosotros.