Wiki-brain — Segundo cerebro con LLM Wiki Pattern e ingester periódico

Por qué

Sin un wiki persistente, dos problemas se acumulan en cualquier proyecto de cierta envergadura:

1. Decisiones olvidadas — por qué se eligió esta arquitectura, qué alternativas se descartaron, qué tradeoffs se aceptaron. Viven en historiales de chat que se pierden cuando la conversación se cierra.
2. Conocimiento desactualizado — papers, posts, discusiones. El LLM responde con lo que sabía al final de su entrenamiento; el conocimiento nuevo que el humano encuentra se queda en su cabeza o en pestañas del navegador.

Wiki-brain ataca los dos. El primero, con el LLM Wiki Pattern de Karpathy: el LLM escribe en un vault persistente, el humano lee y corrige, las decisiones sobreviven a las sesiones. El segundo, con un ingester periódico que trae conocimiento nuevo al vault automáticamente.

Por qué los resultados son más exactos

El problema típico de “preguntar a un LLM sobre un tema técnico” es que el LLM responde con plausibilidad, no con verdad. Si el paper se publicó hace dos meses, el LLM no lo sabe. Si la documentación cambió, no se enteró. La respuesta tiene “buena pinta” y puede ser incorrecta en el detalle que más importa.

Wiki-brain lo ataca por dos vías simultáneas:

1. El contexto siempre refleja el estado actual del vault. Cuando un asistente AI hace query_wiki("¿cómo se hace grounding en el agente?"), el servidor busca en el índice FTS5 (búsqueda full-text nativa de SQLite) del vault, recupera las páginas relevantes (con [[wikilinks]] hacia páginas relacionadas), y se las pasa al LLM como contexto. El LLM responde con citas — la respuesta lleva al wikilink exacto de donde salió cada afirmación. Si la página dice “grounding sin LLM en <1ms”, la respuesta dice “grounding sin LLM en <1ms ([[concepts/agent-validation]])” y el humano puede ir a la página y verificar.

El resultado es muy distinto al de un LLM solo: la tasa de “alucinación coherente” cae drásticamente porque el LLM no está improvisando, está citando. Y cuando improvisa, el lector lo ve (no hay cita) y puede corregirlo.

2. El ingester periódico evita la obsolescencia. El LLM base del LLM-as-judge del relevance classifier responde con su conocimiento; pero el vault contiene el paper o el análisis publicado la semana pasada. El LLM que usa wiki-brain para responder tiene siempre el vault actualizado como contexto, así que cuando el ingester mete un paper nuevo, la próxima respuesta ya puede citarlo.

En la práctica esto significa que la respuesta de query_wiki coincide con la realidad: o la página del wiki dice lo mismo que la realidad (y entonces el LLM la cita correctamente), o la página está desactualizada (y entonces el ingester debería actualizarla pronto, o el humano debería editarla). En cualquier caso, hay una fuente rastreable de la afirmación.

El ingester periódico

El ingester es la pieza que mantiene el vault vivo sin intervención humana. Corre en un timer diario que dispara sobre las 06:00 (con un pequeño offset aleatorio para no coincidir exactamente con otros timers del sistema).

El scheduler es el módulo que ejecuta el pipeline en el horario programado. También se puede invocar a mano para forzar una ejecución o procesar una fuente concreta fuera de banda.

Source registry: qué se ingesta y cuándo

El SourceRegistry es la pieza que decide qué se procesa en cada ejecución. Tiene storage híbrido:

• Canónico: una página wiki (la source registry) con bloques YAML estructurados por categoría (academic, corporate, medium, reddit).
• Caché: una tabla SQLite sources para queries programáticas rápidas (deadline, last_ingested, total_ingested).

La wiki page es la fuente de verdad. El SQLite se reconstruye desde la wiki en cada init. Esto permite editar la lista de fuentes directamente desde Obsidian, sin tocar la base de datos.

Cada fuente declara un schedule:

Schedule	Umbral para “due”
daily	22 horas desde last_ingested
weekly	6 días desde last_ingested
monthly	27 días desde last_ingested

Una query para listar las fuentes “due” las recorre todas, filtra por enabled y por la categoría solicitada, y devuelve las que han pasado el umbral (o todas si se fuerza). Una fuente que nunca se ha ingestado cuenta como “due” inmediatamente.

Pipeline: 5 etapas por fuente

El IngestionPipeline ejecuta el mismo flujo de 5 etapas para cada fuente que el scheduler le pasa:

1. Fetch — el fetcher específico del source_type (arxiv / rss / medium / reddit) descarga los items. Si no hay items, se marca la fuente como ingestada y termina.
2. Dedup — cada item lleva un url_hash. Se cruza con la tabla SQLite ingested_urls. Los que ya están procesados se saltan. Esto garantiza que un paper que aparece en dos fuentes distintas no se procesa dos veces.
3. Classify — el RelevanceClassifier recibe los items nuevos. Los procesa en batches de 15 con un LLM vía OpenRouter, pero con caché de decisiones: cada url_hash se persiste en relevance_decisions con el routing decidido. Los reintentos de la misma URL son idempotentes y no consumen tokens.
4. Dispatch — el IngestDispatcher ejecuta la decisión de routing de forma determinista (sin LLM):
   • create — crea una página nueva con el contenido procesado.
   • merge — añade el item a una página existente (búsqueda por similitud de slug/tema).
   • stub — crea un placeholder mínimo (relevance baja, el humano decide).
   • queue — guarda en una cola para revisión manual.
5. Cleanup — reconstruye el índice FTS5 (búsqueda full-text de SQLite), marca la fuente como ingestada, escribe al ingestion_log (registro de ingestas) en SQLite.

Cada run devuelve un result con items_fetched, items_new, items_ingested, skipped_dedup, errors, y un routing_summary con el conteo por acción. El scheduler agrega los resultados de todas las fuentes y, cuando se configura para actualizar el playbook, dispara una pasada de síntesis que consolida los hallazgos recientes en las páginas de playbook del agente.

Tipos de fuente soportados

Categoría	source_type	Ejemplo
academic	arxiv	arXiv cs.CL, cs.AI, cs.LG
corporate	rss	Engineering blogs (Anthropic, OpenAI, Netflix, AWS)
medium	medium	Tags de Medium con filtro de calidad
reddit	reddit	Subreddits técnicos (r/MachineLearning, r/LocalLLaMA)

El sistema es extensible: añadir una fuente nueva es una entrada YAML en la wiki page del registry, con su category, source_type, config (URL, query, subreddit, etc.) y schedule.

Herramientas MCP

El servidor expone 9 herramientas vía MCP (Model Context Protocol, el protocolo estándar que los asistentes AI usan para llamar herramientas externas) sobre stdio (entrada/salida estándar del proceso, no red). Cualquier cliente compatible (OpenCode, Claude Desktop, Cursor) puede consumirlas directamente:

Tool	Función
search_wiki	Búsqueda por keywords, tags, tipo o status
read_page	Lee una página completa con metadata, wikilinks y backlinks
list_pages	Lista páginas con filtros (type, tag, status, tier)
query_wiki	Pregunta en lenguaje natural → respuesta sintetizada con citas [[wikilinks]]
compile_wiki	Síntesis cross-page de un tema completo
crystallize	Fusiona páginas relacionadas en una página “wisdom”
lint_wiki	Health check semántico: contradicciones, huérfanos, enlaces rotos
rebuild_index	Reconstruye el índice FTS5 (búsqueda full-text de SQLite) desde las páginas del vault
ingest_knowledge	Inyecta conocimiento: busca → enriquece o crea página nueva

Las 4 primeras (search/read/list/query) son de lectura y se usan en cada sesión del asistente. compile_wiki y crystallize son de consolidación y se usan tras acumulación de páginas. lint_wiki y rebuild_index son de mantenimiento. ingest_knowledge es la interfaz programática al ingester, para inserts ad-hoc durante una sesión.

Resultado: de la base de Karpathy a un sistema que funciona en producción

El LLM Wiki Pattern de Karpathy es la base conceptual: el LLM escribe en un vault persistente, el humano lee, y las decisiones sobreviven a las sesiones. El patrón es elegante pero se queda en el umbral de “sistema”: no dice cómo se estructura el vault, cómo entra el conocimiento, ni cómo un asistente AI accede realmente a él.

Wiki-brain toma esa base y la convierte en un sistema que corre desatendido. Las decisiones de ingeniería que lo hacen funcionar:

• Storage híbrido con la wiki como canónica. El SourceRegistry se guarda como página wiki (la source registry) con bloques YAML estructurados. SQLite mantiene una caché programática que se reconstruye desde la wiki en cada init. Editar la lista de fuentes es abrir Obsidian y editar markdown — sin base de datos, sin migración, sin llamada a API. La registry es un documento vivo, no un fichero de configuración.
• Deduplicación por hash de URL, no por título. Un paper que aparece en dos fuentes distintas (por ejemplo, un listado de arXiv y un RSS resumen de la misma semana) se reconoce como el mismo item mediante un hash criptográfico de su URL, no una coincidencia difusa de título. El hash es el identificador; los títulos pueden variar, las URLs no mienten.
• Caché de decisiones en el relevance classifier. Cuando el LLM-as-judge clasifica un item, la decisión de routing (create / merge / stub / queue) se persiste por url_hash en relevance_decisions. Un reintento de la misma URL nunca gasta tokens. El ingester se mantiene económicamente viable a escala — el coste marginal de reprocesar una fuente es cero.
• Dispatch determinista, sin LLM en el camino caliente. El IngestDispatcher ejecuta la decisión de routing en código puro: create crea página nueva, merge añade a una página existente similar, stub hace un placeholder, queue lo aparca para revisión. El LLM decide qué hacer; código determinista decide cómo y dónde. Resultado: fiable, auditable e idempotente.
• MCP como superficie de integración. Las 9 herramientas no son una UI o API para humanos — son herramientas que el asistente AI llama durante el trabajo normal. La wiki es una dependencia del asistente, no una app separada que el humano recuerda abrir.

El resultado de estas decisiones es un sistema que corre en producción sin humano en el bucle de ingestión. El vault crece cada día. El asistente tiene una segunda fuente de conocimiento — la wiki curada, deduplicada, citada y actualizada — sobre la que puede consultar, citar y razonar, junto a sus datos de entrenamiento. Wiki-brain es lo que convierte el LLM Wiki Pattern de idea útil en infraestructura.