Ir al contenido
benchmarktransparencyopen-source

Nuestro benchmark tiene una sección de fallas. A propósito.

El criterio de convergencia del trail learning no se cumplió, y está en el reporte de todos modos. Un benchmark imposible de reprobar no es un benchmark.

Equipo MonkeyLLM3 min de lectura

Hace poco publicamos el preprint de MonkeyLLM, un "bosque de conocimiento" open source y self-hosted que los agentes de IA navegan sobre MCP, en vez de una base de datos vectorial que consultan. En palabras simples: el corpus es un grafo de nodos, cada uno con un pasaporte curado (título, resumen, etiquetas), y el agente entra por búsqueda y camina, leyendo fichas, siguiendo enlaces, abriendo solo lo que necesita.

Este post no va de las victorias. Va de por qué el reporte también contiene una sección que pudimos haber borrado en silencio.

Los números que un marketero amaría

En 11 preguntas estrictamente multi-hop, donde cada pregunta necesita al menos 3 saltos encadenados, el mismo modelo local de 12B obtuvo 0/11 como lector RAG top-k clásico y 11/11 como navegador de bosque.

Lo hizo con 0.58x los tokens por respuesta correcta de una línea base de RAG iterativo, a 8.4 s p95 frente a los 17.5 s de la línea base. Por respuesta correcta es la unidad que importa: fallar barato no es economía.

La búsqueda de entrada es BM25 sobre SQLite: recall@5 = 1.00 a 1.3 ms p95, sin embeddings, sin base vectorial, sin GPU. Ponderar el ranking hacia campos curados (título, alias) cerró por completo la brecha de recall frente a la búsqueda híbrida.

La ingesta corre a 1.71 s por documento en 100 documentos reales y heterogéneos, con 100% de los resúmenes generados pasando un contrato de sesenta tokens y cero enlaces rotos después. Pagas una vez al escribir, en vez de en cada consulta para siempre.

Los números que un marketero escondería

Son tres.

Primero, 11 preguntas es un benchmark pequeño. Las preguntas estrictamente multi-hop son caras de redactar y verificar, pero pequeño es pequeño, y lo decimos.

Segundo, el paper es un preprint. Sin revisión por pares. También lo decimos.

Tercero, el que duele. Las cacerías exitosas depositan rastros de feromona que acuñan enlaces atajo, así que los caminos que funcionan deberían volverse más fáciles de encontrar y el número de saltos debería caer con el tiempo. Fijamos un criterio de convergencia para ese efecto antes de correr el experimento. El criterio no se cumplió: los saltos cayeron cerca de la mitad del umbral que fijamos. La sección está en el reporte, escrita como cualquier otro resultado.

Por qué publicar el fallo

Porque un benchmark imposible de reprobar no es un benchmark. Si el reporte tuviera solo victorias, las victorias valdrían menos. La sección de fallas es lo que hace creíble el 11/11.

Y porque el punto entero de la infraestructura self-hosted es que nunca tienes que creerle a un proveedor bajo palabra. Así que quitamos el paso de confianza: el corpus, los sets de preguntas y el harness están versionados en el repo, y cada tabla del paper se regenera con un comando. El equipo es una sola RTX 3060 de 12 GB.

Demuéstranos que estamos equivocados

No es retórica, es el pedido. Clona el repo, corre el harness con tu propio corpus y, si un número no se reproduce, abre un issue con la tabla adjunta. Falsable le gana a impresionante.

Repo: https://github.com/JimmyWesley/MonkeyLLM Sitio y preprint: https://monkeyllm.com

¿Quieres la versión larga?

El paper trae la arquitectura completa, las tablas del benchmark y los hallazgos que no cumplieron sus criterios.