Uno de los aspectos en los que llevo años trabajando en el plano profesional es tener un «segundo cerebro». Una de las formas disrruptivas de moldear y explotar ese «segundo cerebro» es usando la el método Karpathy (o LLM Wiki). Veamos qué he conseguido, o más bien no he conseguido, usando plugins de Obsidian para ello.
Obsidian, mi Segundo Cerebro
Todas mis notas profesionales y personales están en archivos de texto en formato markdown y las gestiono con Obsidiandesde hace más de 6 años. Esas notas están relacionadas entre ellas y funcionan como mi segundo cerebro.
Un Segundo Cerebro (término acuñado por Tiago Forte, especialista en productividad y gestión del conocimiento) es un sistema digital externo diseñado para capturar, organizar, sintetizar y recuperar la enorme cantidad de información, ideas y aprendizajes que consumimos a diario. Su premisa es liberar al cerebro biológico de la pesada carga cognitiva de almacenar datos, devolviéndole su función primaria: pensar, conectar conceptos y crear.
Obsidian no es el Segundo Cerebro en sí mismo, sino el motor de software y la infraestructura perfecta, para mí, para construirlo.
El Método Karpathy
En mi búsqueda de una alternativa superior a las limitaciones del RAG convencional —donde las respuestas suelen ser fragmentadas y carecen de una visión global del conocimiento—, decidí adoptar la filosofía de la LLM Wiki propuesta por Andrej Karpathy. La premisa que me atrajo de este enfoque es tratar a la inteligencia artificial no como un buscador que consulta documentos al vuelo, sino como un compilador activo de conocimiento.
Mi objetivo al implementar esta metodología es construir una enciclopedia técnica viva y coherente en Obsidian. En lugar de acumular notas sueltas que debo relacionar y etiquetar manualmente, este método proporciona un sistema de trabajo para ingerir fuentes primarias, procesar su contenido y sintetizarlo continuamente en dos grandes categorías: conceptos y entidades, todo ello conectado de forma bidireccional, garantizando la trazabilidad exacta de qué documento originó cada fragmento de conocimiento.
Arquitectura Objetivo y Diseño del Gobierno
Para articular este sistema, diseñé un archivo de gobernanza maestro (config.md) que sirve como la especificación técnica completa del entorno. Definí una estructura de carpetas con responsabilidades claramente delimitadas:
00_rawcomo buzón inmutable de entrada de documentos.01_wiki(subdividida en concepts/, entities/ y sources/) como la capa de conocimiento compilado bajo control de la IA.03_archivecomo el destino final de los archivos procesados.
A nivel ontológico, establecí reglas precisas para garantizar la calidad del vault de Obsidian:
- Política de idioma: Redacción de contenidos en español manteniendo la terminología técnica, los títulos de página y las propiedades del ‘frontmatter’ estrictamente en inglés.
- Formatos de nombrado: Exigencia del uso de
Title Casecon espacios (ej. Apache Kafka.md) para facilitar la lectura humana y la navegación intuitiva. - Estructura por plantillas: Formatos condicionales para cada subtipo de nota (como «components», «patterns», «frameworks» o «how_to»), incluyendo tablas y secciones obligatorias.
- Metadatos e interconexión: Delegación de las fechas de creación y actualización al plugin Linter para evitar alucinaciones del modelo, extracción de etiquetas en
snake_casey enlazado mediante Wikilinks con lógica de alias gramaticales.
La idea subyacente de este archivo era la de que se inyectase al modelo de inteligencia artificial (en mi caso, en local, sobre un contenedor docker de Ollama) como contexto para que el modelo de turno hiciese su trabajo tal y como yo quería, sin alucinaciones, sin cabos sueltos.
Evaluación Práctica del Plugin LLM Wiki
Con el esquema de gobernanza completamente definido, procedí a evaluar el plugin Karpathy LLM Wiki de Greener Dalii dentro de Obsidian, con la expectativa de que actuara como el motor de ejecución capaz de interpretar mi propio config.md (que es cargado por el plugin a modo de contexto) e interactuar de forma transparente con mi modelo de lenguaje local.
Hice las pruebas de ingesta depositando documentos técnicos en la carpeta 00_raw. Mi propósito era verificar si el plugin podía leer la fuente, deducir las entidades y conceptos asociados, generar las notas aplicando mis plantillas personalizadas, etiquetar y relacionar esas notas y mantener actualizado el registro cronológico (en un archivo llamado log.md).
Y la respuesta a esa pregunta es sí, pero con fricciones y limitaciones.
Fricciones y Limitaciones
Durante las pruebas, la experiencia se distanció de las directrices establecidas en mi config.md. Aparecieron una serie de comportamientos rígidos en el funcionamiento del plugin que invalidaban las reglas de mi sistema:
- Forzado del nombrado de archivos: A pesar de haber instruido explícitamente el uso de
Title Case(Apache Kafka.md), el plugin renombró sistemáticamente cada archivo generado akebab-case(apache-kafka.md). - Incapacidad de gestión en el sistema de archivos: La instrucción de mover el documento original procesado de
00_rawa03_archivefue ignorada. Comprendí que el LLM genera el texto de las notas, pero la operación física de mover un fichero en el disco requiere un script ejecutable que el plugin no tiene implementado, al menos de momento. - Generación de artefactos no solicitados: El plugin creó y actualizó automáticamente un archivo index.md en la raíz de la wiki, pero no como yo le instruía a hacerlo (que uno por dominio de conocimiento y otro de maestro apuntando a cada índice de dominio). El archivo de log tampoco se atenía al formato que se le establecía, adoptando el que el plugin considera oportuno.
- Inobservancia de plantillas avanzadas: La estructura interna de las secciones definidas en mis plantillas para conceptos y entidades fue reemplazada por la estructura por defecto del plugin.
La causa técnica de estas fricciones radica en que el plugin no envía mi config.md de forma transparente al modelo de lenguaje. En su lugar, el código JavaScript del plugin intercepta la respuesta, aplica sus propias funciones de formateo y las impone por encima de las instrucciones del prompt.
Alternativas: Plugin UI vs. Agente CLI Externo
Esta experiencia me ha llevado a replantear la arquitectura del sistema. Los plugins integrados en la interfaz de usuario de Obsidian están diseñados bajo compromisos de simplicidad y encorsetan la lógica dentro de sus propias funciones de JavaScript. Para un uso convencional pueden ser adecuados, pero para un esquema de gobernanza avanzado representan un cuello de botella.
Como alternativa he decidido pasar a un Agente CLI externo (como OpenCode) o scripts de procesamiento en segundo plano acoplado al LLM. Este enfoque ofrece, creo, ventajas claras:
- Acceso directo al sistema operativo: Un agente ejecuta comandos del sistema y puede mover físicamente archivos tras completar la ingesta.
- Fidelidad absoluta al
config.md: Al no existir una capa de código intermedio que transforme la salida del LLM, las reglas de nombrado, la sintaxis del ‘frontmatter’ y la estructura de las plantillas se respetan sin interferencias. - Desacoplamiento funcional: Se logra una separación limpia donde el Agente actúa como el compilador/procesador de fondo y Obsidian se consolida exclusivamente como el visor interactivo y mapa de conocimiento.
Conclusión
Sigo pensando que la metodología de Karpathy es un marco extraordinario para estructurar y mantener vivo un segundo cerebro. Sin embargo, la herramienta de ejecución debe estar a la altura del nivel de control que el sistema requiere.
El plugin Karpathy LLM Wiki dentro de Obsidian impone convenciones de software rígidas que entran en conflicto con reglas de gobernanza personalizadas. Si se busca un sistema automatizado que respete esas reglas, la solución pasa por desacoplar el procesamiento de la interfaz visual.
Asumir la compilación mediante un agente o script externo con acceso al sistema de archivos es la vía técnica idónea para construir un vault profesional, limpio y verdaderamente gobernado, así que, seguiremos investigando.