He notado un cambio en cómo consumo mis cuotas de tokens. Ya no gasto tanto en pedirle a un modelo que escupa código, sino en manipular conocimiento. Más concretamente: usar LLMs para construir y mantener bases de conocimiento personales sobre temas en los que me estoy formando e investigando.
Los modelos recientes son sorprendentemente buenos en esto. Tratan el texto, el markdown y las imágenes como si fueran piezas de un mecano.
El concepto básico: Del RAG al LLM como bibliotecario
Cuando en la industria se habla de "chatear con tus documentos", normalmente te están vendiendo una arquitectura RAG (Retrieval-Augmented Generation). Esto suele implicar trocear PDFs, calcular embeddings, meterlos en una base de datos vectorial y cruzar los dedos para que la búsqueda semántica devuelva los fragmentos adecuados al modelo.
Aquí propongo algo más crudo, pero que controlo al cien por cien. En lugar de esconder el conocimiento en vectores ilegibles para un humano, obligo al LLM a leer documentos brutos y escribir una wiki en texto plano (archivos .md). El modelo actúa como un bibliotecario incansable que lee, resume, cataloga y enlaza conceptos en una estructura de carpetas visible. Yo solo consumo el resultado final.
La cadena de montaje
El proceso arranca con una ingesta de datos bastante básica. Tiro documentos fuente en un directorio raw/. Hablamos de artículos, papers, repositorios, datasets e imágenes. Para capturar lecturas de la web uso la extensión Obsidian Web Clipper y un atajo de teclado para descargar las imágenes al disco local. Así el modelo tiene acceso rápido a las referencias visuales.
A partir de ahí, un script le pide al LLM que "compile" la wiki de forma incremental. El agente lee el directorio raw/, genera resúmenes, extrae conceptos clave y escribe nuevos artículos .md enlazados entre sí. También actualiza índices y gestiona los enlaces inversos (backlinks).
El LLM escribe y mantiene todos los datos. Yo rara vez toco la wiki directamente.
Obsidian como IDE
Necesitas un frontend para ver y manejar todo este sistema de archivos. Obsidian cumple esa función perfectamente. Es mi IDE de conocimiento. Desde ahí veo los datos brutos, la wiki ya compilada y cualquier visualización derivada.
A veces juego con plugins adicionales, como Marp, para renderizar algunos de esos archivos markdown como diapositivas directamente en el editor.
Preguntas, respuestas y mantenimiento
Aquí viene la parte divertida. Cuando la wiki crece (la mía tiene unos 100 artículos y 400.000 palabras en un proyecto reciente), le lanzo preguntas complejas al agente. Se va, lee, investiga las respuestas y vuelve.
Pensé que necesitaría un RAG sofisticado para esto. Me equivoqué. El LLM es capaz de auto-mantener archivos de índice y resúmenes breves de todos los documentos. Lee los datos importantes con bastante facilidad a esta escala, que todavía considero manejable con ventanas de contexto largas.
En lugar de que me escupa texto en una terminal, le pido que el resultado sea un nuevo archivo markdown, una presentación o un gráfico generado con matplotlib. Todo esto acaba de nuevo en Obsidian. Y a menudo, termino inyectando esas respuestas de vuelta en la wiki. Cada consulta suma y engorda la base de datos.
Linting sobre la wiki
A veces ejecuto scripts de "control de salud" sobre el repositorio. Le paso el LLM a los archivos para buscar datos inconsistentes, rellenar huecos (usando búsqueda web) o descubrir conexiones extrañas que podrían convertirse en nuevos artículos. Es un proceso de limpieza continua. Los modelos son muy buenos sugiriendo qué más deberíamos estar preguntándonos sobre nuestro propio trabajo.
Un motor de búsqueda artesanal
Para poder navegar por todo esto cuando el LLM no está activo, he programado por instinto un pequeño motor de búsqueda sobre la wiki. A veces lo uso desde una interfaz web sencilla, pero lo normal es pasárselo al LLM por línea de comandos para que lo use como herramienta en consultas más grandes.
Ejemplo práctico: Compilando un concepto
La teoría suena bien. Vamos al barro. Imagina que en raw/ he dejado un artículo denso sobre la arquitectura de un nuevo modelo de lenguaje. Mi script invoca al LLM con un comando parecido a este:
python wiki_compiler.py --input raw/nuevo-modelo.md --output wiki/
Bajo el capó, el LLM lee nuevo-modelo.md y, basándose en sus instrucciones de sistema, genera un resumen y extrae conceptos, creando algo como esto en wiki/conceptos/mecanismo-de-atencion.md:
# Mecanismo de Atención
Origen de los datos: [[nuevo-modelo]]
Fecha de compilación: 2026-03-07
El mecanismo de atención descrito difiere del tradicional en que...
Luego, actualiza silenciosamente el archivo wiki/indice.md para incluir el nuevo enlace.
El siguiente paso
A medida que el repositorio crece, la inercia pide dar un paso más: usar esos datos para generar información sintética y hacer finetuning de un modelo. La idea es que la red neuronal lleve el conocimiento incrustado en sus pesos, no solo dependiendo del texto que le pases.
Hay margen aquí para crear un producto serio. Ahora mismo, mi configuración no deja de ser una colección extraña de scripts.