OpenKB: la wiki que tu LLM compila solo, y sin base de datos vectorial

El 2 de abril, Andrej Karpathy publicó un tuit largo describiendo cómo había dejado de usar los LLM para manipular código y había empezado a usarlos para manipular conocimiento: indexar papers y artículos en un directorio raw/, hacer que un modelo compilase incrementalmente una wiki de ficheros Markdown con resúmenes, conceptos y backlinks, y consultar esa wiki en lugar de montar un RAG. El tuit acumula 21,8 millones de visualizaciones y termina con una frase que era casi una convocatoria: creo que aquí hay sitio para un producto increíble en vez de una colección chapucera de scripts.

Dos días después apareció el primer commit de OpenKB. Hoy va por 3.577 estrellas y 380 forks.

Qué es OpenKB

OpenKB es una herramienta de línea de comandos en Python, con licencia Apache 2.0, publicada por VectifyAI. Compila documentos en bruto —PDF, Word, Markdown, PowerPoint, Excel, CSV, HTML o una URL— en una wiki estructurada de ficheros .md interconectados que el propio modelo mantiene al día.

El ciclo completo cabe en cinco comandos:

pip install openkb

mkdir mi-kb && cd mi-kb
openkb init                                     # configura modelo e idioma
openkb add paper.pdf                            # también ~/papers/ o una URL
openkb query "¿Cuáles son los hallazgos principales?"
openkb chat                                     # sesión interactiva, con --resume

Cuando añades un documento, el modelo genera una página de resumen, lee las páginas de conceptos y entidades que ya existen, crea o actualiza los conceptos con síntesis entre documentos, extrae entidades —personas, organizaciones, lugares, productos— y actualiza el índice y el registro de cambios. Según el README, una sola fuente puede tocar entre 10 y 15 páginas de la wiki.

Ese es el punto entero del proyecto: el conocimiento se acumula en vez de redescubrirse. Un RAG convencional vuelve a empezar en cada consulta; aquí las referencias cruzadas ya están escritas, las contradicciones quedan señaladas y la síntesis refleja todo lo que has ingerido hasta ahora.

La parte técnica interesante: recuperación sin vectores

El titular que circula en X es «sin base de datos vectorial», y conviene entender por qué no es una boutade.

Los documentos cortos los lee el modelo enteros, previa conversión a Markdown con markitdown. Los PDF largos —el umbral por defecto son 20 páginas, configurable— pasan por PageIndex, el otro proyecto de la casa: 35.128 estrellas, licencia MIT y commits de esta misma semana. PageIndex no trocea ni embebe; construye un índice en árbol jerárquico del documento, con la estructura de secciones y sus resúmenes, y deja que el modelo razone sobre ese árbol para decidir a qué rama bajar.

La diferencia práctica frente a la búsqueda por similitud es la que cualquiera que haya montado un RAG sobre documentación densa reconocerá: el chunk que más se parece a la pregunta no siempre es el que la responde, sobre todo cuando la respuesta depende de en qué apartado del documento estás. Razonar sobre un índice se parece más a cómo un humano usa un libro técnico: mira el sumario, decide el capítulo, entra. A cambio, cada consulta gasta tokens de razonamiento donde un vector store solo gastaba una comparación de distancias.

PageIndex corre en local por defecto, sin dependencias externas. La versión de nube, opcional y de pago, añade OCR para PDF escaneados y generación de estructura más rápida: ahí está el modelo de negocio de VectifyAI, y conviene saberlo al valorar el proyecto, aunque el núcleo abierto funcione sin ella.

Lo que han añadido sobre la idea original

El propio README incluye una tabla comparándose con el flujo de Karpathy, que es un gesto honesto y además el mejor resumen de qué aporta el proyecto: manejo de documentos largos donde el original chocaba con los límites de contexto, ingesta de formatos más allá del clipper web, extracción automática de entidades donde antes era manual, y dos salidas nuevas.

La primera es la Skill Factory. openkb skill new destila la wiki en una skill de agente portable que Claude Code, Codex y Gemini CLI instalan de forma nativa, con validate, eval para comprobar que se activa con los prompts correctos, historial y rollback. Metes un libro entero de papers y sale un especialista al que otros agentes pueden llamar. Es la misma tendencia de convenciones compartidas entre CLIs que ya vimos con las skills del ADK de Google, aplicada al conocimiento en vez de al comportamiento.

La segunda son los generadores: openkb visualize produce un grafo de conocimiento interactivo en un HTML autocontenido, y openkb deck new genera presentaciones de un solo fichero, con un pase de crítica de calidad opcional. También hay una interfaz web empaquetada, el Knowledge Workbench, que se sirve en 127.0.0.1:7566.

Y como la wiki no es más que Markdown con [[wikilinks]], se abre directamente como bóveda de Obsidian, con vista de grafo incluida. Esa es la decisión de diseño que más envejece bien: si mañana abandonas el proyecto, lo que queda en disco son ficheros de texto que sirven igual, en lugar de un índice binario atado a una versión concreta de una librería. El mismo argumento que hace útil convertir cualquier página web a Markdown para dársela a un LLM.

Dónde están los límites

El proyecto es joven —cuatro meses— y no disimula lo que le falta. Su hoja de ruta reconoce cuatro huecos abiertos: el tratamiento de documentos largos solo funciona para PDF, no hay soporte de carpetas anidadas para colecciones grandes, falta indexación jerárquica de conceptos para wikis masivas y el almacenamiento aún no tiene motor de base de datos detrás. Traducido: funciona bien para el caso de Karpathy —un investigador con unos cientos de documentos sobre un tema— y está sin probar como base de conocimiento corporativa.

Hay dos cosas más que conviene tener en cuenta antes de lanzarlo contra tu carpeta de papers.

El coste cambia de sitio, no desaparece. Compilar es caro: cada documento nuevo implica que el modelo lea las páginas existentes, sintetice y reescriba entre diez y quince ficheros. Lo que ahorras es en consulta. Si vas a preguntar mucho sobre el mismo corpus, sale a cuenta; si vas a hacer dos preguntas y olvidarte, un RAG normal es más barato. Y openkb recompile reescribe las páginas de conceptos, así que las ediciones manuales se pierden: la wiki es territorio del modelo, exactamente como la planteaba Karpathy.

El Workbench viene sin autenticación. Está pensado como herramienta local y por eso la autenticación está desactivada por defecto; hay que fijar OPENKB_API_TOKEN antes de exponer el servidor en cualquier red. Es coherente con el diseño, pero es justo el tipo de valor por defecto que acaba en una instancia abierta a internet con la documentación interna de alguien dentro.

Por qué merece la pena mirarlo

Más allá de la herramienta concreta, OpenKB es la señal de que el RAG por similitud ha dejado de ser la respuesta automática. Durante tres años, «tengo documentos y quiero preguntarles cosas» se resolvía con chunking y embeddings casi por inercia. Aquí la propuesta es distinta: gastar cómputo en estructurar el conocimiento una vez, escribirlo en un formato que un humano también puede leer, y dejar que el modelo navegue esa estructura razonando.

Encaja además con algo que ya hemos comentado en otras piezas: cuando el estado de tu trabajo con agentes vive en texto plano en tu disco, no en el servidor de nadie, la portabilidad deja de ser un favor del proveedor. Una wiki de Markdown es el formato más aburrido posible, y por eso mismo el más difícil de secuestrar.

Repositorio en github.com/VectifyAI/OpenKB, y el tuit de Oliver Prompts que lo puso a circular esta semana.