La capa de conocimiento para IA: 127 páginas estructuradas, sin bases de datos vectoriales y lo que aprendí en el proceso

Andrej Karpathy publicó un gist en abril de 2026 con un patrón para construir bases de conocimiento personal con LLMs. Consiguió 99.000 marcadores en una semana. Varias implementaciones quedaron en código abierto en cuestión de días. graphify se lanzó en 48 horas y sumó 27.000 marcadores más. El patrón resonó porque dio nombre a un problema conocido: la mayoría de los agentes no tienen memoria persistente entre sesiones. Cada conversación comienza desde cero. Se vuelve a explicar el negocio, los objetivos, el estilo, el contexto, y el resultado llega genérico porque la entrada no tenía nada con qué trabajar.

En webvise se utiliza una capa de conocimiento para investigación y documentación de proyectos. Esto es lo que se aprendió en el proceso.

Los agentes olvidan entre sesiones.

El flujo de trabajo estándar con IA es sin estado. Se abre un chat, se explica lo que se necesita, se obtiene una respuesta y se cierra. En la siguiente sesión, la misma explicación. El contexto acumulado desaparece. La mayoría de las personas compensan esto escribiendo prompts más largos, copiando documentos de contexto o subiendo archivos al inicio de cada sesión. Funciona, pero no escala. Llega un punto en que la ventana de contexto se llena, la calidad cae y se dedica más tiempo a preparar el prompt que a hacer el trabajo.

La capa de conocimiento resuelve esto en el nivel de infraestructura. En lugar de rellenar el contexto en cada prompt, se le da al agente acceso a una base de conocimiento persistente y estructurada que lee antes de hacer cualquier cosa. El agente ya conoce el negocio, el estilo, los proyectos y el historial. Se omite la re-explicación y se va directamente al trabajo.

Tres capas, sin base de datos vectorial

La arquitectura tiene tres partes:

• Fuentes brutas. Una carpeta de documentos inmutables: artículos, notas, transcripciones, PDFs, grabaciones de reuniones, investigación. El agente los lee, pero nunca los modifica. Son la fuente de verdad.
• La wiki. Un directorio de archivos markdown generados por el LLM con referencias cruzadas. Páginas de entidades, páginas de conceptos, síntesis, comparaciones, playbooks. El agente es el propietario de esta capa por completo: crea páginas, las actualiza cuando llegan nuevas fuentes, mantiene las referencias cruzadas y garantiza la coherencia. Usted la lee. El agente la escribe.
• El esquema. Un documento de configuración (CLAUDE.md, AGENTS.md o equivalente) que indica al agente cómo está estructurada la wiki, qué convenciones seguir y qué flujos de trabajo ejecutar. Esto es lo que convierte a un LLM genérico en un mantenedor de wiki disciplinado.

La wiki es un artefacto compilado. El agente no vuelve a derivar el conocimiento en cada consulta: compila una vez, establece referencias cruzadas y se mantiene actualizado. Cuando se añade una nueva fuente, el agente la integra en la wiki existente y actualiza cada página relevante. Ante una pregunta, el agente lee páginas precompiladas en lugar de buscar entre documentos brutos.

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

RAG vuelve a derivar las respuestas en el momento de la consulta dividiendo los documentos en fragmentos y buscando los relevantes. El enfoque de wiki compilada prescinde de eso por completo. El benchmark de graphify midió 71,5 veces menos tokens por consulta en su comparación publicada; los resultados dependen de las características del corpus y la distribución de las consultas. Las mediciones propias muestran alrededor de 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.

Existe una comparación técnica completa de RAG frente a la recuperación basada en índices. La versión corta: en las cargas de trabajo analizadas, el enfoque de wiki compilada superó a RAG en precisión, coste y complejidad operativa. Sin base de datos vectorial, sin modelo de embeddings, sin estrategia de fragmentación, sin trabajo de reindexación. Cinco comandos de shell y un archivo de índice mantenido.

La evolución ocurrió en tres fases: RAG de una sola pasada de 2020 a 2023, RAG agentivo con recuperación multi-salto de 2023 a 2024, e ingeniería de contexto 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 los equipos todavía construyen para la primera.

Lo que se aprende al operar la propia wiki

La wiki interna cuenta actualmente con 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: ingerir, actualizar conversacionalmente, consultar, validar, enriquecer y reorganizar.

• El archivo de esquema lo es todo. Todo lo demás se deriva de él. Un esquema bien escrito produce una wiki disciplinada con convenciones coherentes. 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ágina, las seis operaciones, convenciones de nomenclatura y gestión de contradicciones. Llevó varias iteraciones conseguirlo.
• Deduplicar primero evita la proliferación de páginas. La regla: antes de crear cualquier página nueva, buscar en la wiki contenido que se solape. Si una página existente cubre el 60% o más del mismo terreno, se enriquece esa página en lugar de crear una nueva. Sin esta regla, la wiki se llena de páginas redundantes que fragmentan el conocimiento en piezas inutilizables.
• Las consultas se acumulan en la base de conocimiento. Cuando se formula una buena pregunta y se obtiene una respuesta útil, esa respuesta se archiva como nueva página de la wiki. La próxima vez que alguien haga una pregunta relacionada, el agente ya tiene una síntesis precompilada de la que partir. Este es el efecto acumulativo que hace el sistema cada vez mejor, no solo más grande.
• La calidad del ingreso depende por completo de la disciplina. Volcar un artículo bruto y decir "ingerir esto" produce un resumen superficial. Recorrer la fuente con el agente, analizar las conclusiones y dirigir qué enfatizar produce páginas que siguen siendo útiles a medida que la wiki crece. Se aplica un flujo estricto: limpiar el archivo bruto, analizar las conclusiones clave, esperar aprobación y luego extraer completamente.
• El archivo de índice es el sistema de recuperación. El índice raíz tiene 22 líneas. Cada subdirectorio tiene su propio índice con todas las páginas y una descripción de una línea. El agente lee el índice raíz con unos 400 tokens, identifica el subdirectorio correcto, lee ese índice y luego accede a las páginas específicas que necesita. La mayoría de las consultas se resuelven con tres lecturas y alrededor de 1.000 tokens de contenido del vault.

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

Karpathy lo llama el esquema. En este contexto se llama CLAUDE.md. Algunos frameworks lo dividen en una capa de base de conocimiento y una fundación de marca. El nombre es secundario. El hecho operativo 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 brutas, dónde van las páginas de la wiki y cómo se organizan en categorías.
• Formato de página. Campos del frontmatter, estructura de secciones, reglas de atribución de fuentes y convenciones de referencias cruzadas.
• Operaciones. Flujos de trabajo paso a paso para ingerir fuentes, responder consultas, ejecutar comprobaciones de salud y mantener la wiki a lo largo del tiempo.
• Criterios 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 rastrearse hasta una fuente.

Sin estas definiciones, el agente improvisa. Crea páginas en ubicaciones aleatorias, usa formatos inconsistentes, duplica contenido y se desvía de las convenciones con cada sesión. El esquema previene esa deriva. Se trata como código de producción: cada cambio es deliberado y se prueba con un ingreso real.

Cómo construir una en 20 minutos

No hacen falta 17 archivos, un grafo de habilidades de contenido ni un pipeline de embeddings personalizado. Solo cuatro elementos:

• Un vault de Obsidian con dos carpetas. `raw/` para documentos fuente y `wiki/` para páginas generadas por el agente. Ábralo en Obsidian para la vista de grafo y la navegación.
• Un archivo de esquema. Comience con el gist de Karpathy. Personalice la estructura de directorios y el formato de página para su dominio. Manténgalo en menos de 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úntelo al vault. Lee el esquema al iniciarse.
• Su primera fuente. Deposite un artículo, un conjunto de notas o un documento en `raw/`. Indíquele al agente que lo ingiera. Observará cómo crea páginas de wiki, construye referencias cruzadas y actualiza el índice.

Ese es el ciclo completo. El sistema mejora cada día porque cada fuente añadida y cada pregunta formulada enriquece la wiki. El primer ingreso requiere 10 minutos de atención activa. Hacia el vigésimo, el agente conoce el dominio lo suficientemente bien como para extraer y establecer referencias cruzadas con una guía mínima.

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

Lo que no importa

Gran parte de la complejidad que la gente asocia con los sistemas de conocimiento para IA es sobrecarga para problemas que todavía no existen. Una base de datos vectorial para 200 documentos, un modelo de embeddings personalizado cuando un índice mantenido hace la recuperación, un pipeline de reindexación cuando añadir un documento significa escribir un archivo, una estrategia de fragmentación cuando la página es la unidad. Nada de esto es necesario a la escala en que opera la mayoría de los negocios.

El patrón funciona porque markdown es sencillo y los LLMs son buenos leyéndolo y escribiéndolo. El coste de infraestructura es cero. El coste de mantenimiento es bajo porque el LLM gestiona las actualizaciones del índice; aun así, se recomienda una revisión humana periódica para garantizar la precisión. El único coste real es la disciplina para mantener el esquema honesto y la calidad del ingreso alta. Ese es un problema humano, no tecnológico.

Casos de uso empresariales

La misma arquitectura funciona a escala de empresa. Se reemplazan las notas personales por documentación de clientes, playbooks de ventas, guías de incorporación y SOPs internos. Se reemplaza 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 brutas entran, el agente compila páginas estructuradas, las referencias cruzadas se construyen automáticamente y las personas 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 incorporaciones de seis semanas. Sin conocimiento tribal bloqueado en la cabeza de alguien.

Karpathy lo llama una wiki LLM. Eric Osiu lo llama un cerebro compartido. Cody Schneider lo llama un almacén de datos. El nombre sigue cambiando. El patrón no: los agentes necesitan conocimiento compilado y estructurado para hacer trabajo útil. Sin contexto persistente, los prompts operan sin el conocimiento institucional que necesitan.

webvise construye capas de conocimiento para empresas que quieren que sus agentes de IA realmente sepan de qué están hablando. Si usted dedica más tiempo a explicar contexto a sus herramientas que a obtener valor de ellas, este es el problema que se resuelve. Póngase en contacto.