Por qué este blog tiene una wiki al lado
Los artículos con fecha y las notas que se corrigen solas resuelven problemas distintos. Aquí conviven, y la wiki sigue el estándar OKF v0.1 de Google.
Llevo años tomando notas sobre inteligencia artificial y perdiéndolas. No literalmente: las notas siguen ahí, en carpetas, en marcadores, en capturas. Lo que se pierde es la relación entre ellas.
Un blog no arregla eso. Un blog es un registro cronológico: escribes algo un martes, lo publicas, y ese texto queda congelado. Es un formato honesto —dice lo que pensabas ese día— pero es pésimo como base de conocimiento. Si seis meses después cambias de opinión, el artículo viejo sigue ahí, igual de indexado, contradiciéndote.
Dos formatos, dos trabajos
Por eso este sitio tiene dos mitades:
- El blog es cronológico y no se reescribe. Envejece a propósito.
- La wiki es un documento por concepto, sin fecha de publicación, que se corrige continuamente. Cuando cambio de opinión, cambio la página.
La distinción no es mía. Es más o menos lo que Andrej Karpathy describió en abril de 2026 al contar cómo mantenía su base de conocimiento personal: un archivo markdown por concepto, escrito y mantenido por un LLM, con referencias cruzadas y trazabilidad de las fuentes. La idea que lo hace funcionar es que cada documento tenga un solo tema y que los enlaces entre documentos sean la estructura, no un adorno.
Y por qué OKF
El patrón de Karpathy es una buena idea sin especificación: cada uno lo implementaba a su manera y los resultados no eran intercambiables.
En junio de 2026 Google Cloud publicó el Open Knowledge Format (OKF) v0.1
bajo Apache 2.0, que es justamente esa idea formalizada: un directorio de
archivos markdown con frontmatter YAML y un puñado de convenciones acordadas.
La spec es deliberadamente pequeña — sólo exige que cada documento tenga un
campo type no vacío:
---
type: concepto
title: Transformer
description: La arquitectura de red neuronal detrás de los LLM modernos.
tags: [IA, arquitecturas]
timestamp: 2026-08-15
---Eso es todo lo obligatorio. title, description, resource y tags son
recomendados; timestamp es opcional. No hay SDK, ni runtime, ni formato
binario. Son archivos de texto.
Lo que me convenció no es que sea de Google, es lo que no pide. No hay nada que se pueda romper en una migración: si mañana OKF desaparece, me quedo con un directorio de markdown perfectamente legible. El coste de adoptarlo es prácticamente cero, y a cambio la wiki es consumible por cualquier agente que entienda la convención.
De la idea a la wiki
Escribí lo anterior con la wiki casi vacía: dos páginas y unas convenciones. Al día siguiente le pasé por encima los doce artículos de este blog siguiendo el flujo que describe Karpathy. Vale la pena contar qué hace ese flujo, porque es lo que convierte un montón de textos en algo consultable.
Son tres operaciones, y ninguna es “resumir”:
- Ingesta. El modelo lee una fuente entera, extrae las entidades que aparecen y, para cada una, decide si crea una página o amplía una que ya existe. Esa segunda mitad es la importante: una fuente nueva no añade un documento al final, toca diez que ya estaban. Por eso el conocimiento se acumula en vez de apilarse.
- Consulta. Se pregunta a la wiki, no al material en bruto. El índice dice de qué va cada página, así que se leen tres y no treinta.
- Lint. Una pasada de mantenimiento que busca lo que se pudre solo: enlaces rotos, páginas huérfanas que nadie enlaza, conceptos mencionados una y otra vez que no tienen página propia, contradicciones entre documentos.
El lint de esa primera ingesta encontró cinco páginas casi aisladas y dos demasiado cortas para sostenerse. Se arreglan en el momento. Eso es lo que distingue esto de un archivo de notas: el desorden se mide y se corrige, en vez de acumularse hasta que dejas de entrar.
El error que cometí primero
La primera versión salió con una página por concepto: treinta y tres términos, uno por documento. Cumplía la regla de “un tema por página” al pie de la letra y aun así estaba mal. Lo que producía era un diccionario, y un diccionario no te dice nada que no supieras ya al buscar la palabra.
El gist no describe eso. Describe resúmenes de fuentes, páginas temáticas, comparaciones y una síntesis. La diferencia es dónde ocurre la fusión: una página sobre “MCP” repite lo que decía el artículo de MCP; una página sobre capacidades de los agentes tiene que decidir cómo encajan el MCP, los Agent Skills y la divulgación progresiva, que salieron de artículos distintos con seis meses de diferencia. Eso último es conocimiento nuevo. Lo primero es un índice con más pasos.
Así que la wiki tiene ahora tres capas:
fuentes/— una página por artículo: qué dice, qué datos aporta y a qué temas alimenta. Es la trazabilidad.temas/— nueve páginas que fusionan varios artículos cada una. Aquí es donde el corpus dice cosas que ningún artículo dijo por separado.sintesis.md— la tesis que atraviesa los doce, en tres movimientos.
Una página temática buena tiene una propiedad que se nota enseguida: contiene al menos una frase que no está en ninguna de sus fuentes.
Por qué queda ordenado y se puede consultar
Tres decisiones hacen el trabajo, y las tres vienen de la idea original:
Un documento, un tema — donde “tema” es un asunto sobre el que varias fuentes discuten, no una palabra del glosario. Es la distinción que me costó la primera versión entera.
Los enlaces son la estructura, no la decoración. En OKF un enlace afirma una relación. Como están escritos dentro de la prosa, cada página termina sabiendo quién la cita: al pie hay una lista de backlinks que no mantengo yo, sale de los propios enlaces. A seguridad y gobernanza se llega desde el artículo de los MCP, desde el de Antigravity o desde el de Nested Learning, según por dónde entres — y ese cruce es precisamente lo que ninguno de los tres decía por su cuenta.
Cada afirmación arrastra su fuente. Al final de cada página hay una sección
# Citations con el artículo del que salió. Si dentro de un año una página me
parece equivocada, sé de dónde vino y puedo corregirla sin tocar el artículo
original, que sigue diciendo lo que pensaba ese día.
Y consultarla es de dos formas: a mano, con el buscador y los backlinks; o dándole el directorio a un agente, que es para lo que existe el formato.
Cómo está montado
Astro, compilado a HTML estático. El buscador es Pagefind, que genera un índice al compilar: las búsquedas ocurren en tu navegador y no hay servidor detrás. Sin rastreadores y sin analítica.
El código de la wiki valida la conformidad con OKF en cada build. Si algún
documento se queda sin type, la compilación falla antes de publicar.
Un detalle que no me esperaba: los enlaces entre conceptos son rutas al
bundle (/concepto.md), no rutas de este sitio. Es lo correcto según la
spec —el paquete tiene que poder leerse fuera de aquí— pero significa que
llegan literales al HTML y dan 404 en el navegador. Se resuelve reescribiéndolos
a /wiki/concepto al compilar, dejando el markdown de origen intacto. Es un
ejemplo pequeño de la tensión de fondo: el formato sirve al agente, la web
sirve a la persona, y el sitio tiene que darle a cada uno lo suyo sin
estropear el otro.
Si te lo quieres montar
El patrón no tiene nada de específico de este blog: funciona igual con transcripciones de reuniones, un curso, informes o notas sueltas. En la wiki están las dos Agent Skills que automatizan el flujo —una ingiere y mantiene, la otra consulta— listas para descargar y soltar en tu agente. Generan bóvedas de Obsidian en vez de bundles OKF: mismo patrón, distinto formato de salida.