Dentro del benchmark de 11 preguntas
Once preguntas, cada una exigiendo al menos tres saltos encadenados. El mismo modelo 12B anota 0/11 como lector de RAG top-k y 11/11 como navegador de bosque. Así se construyó el benchmark y así se vuelve a correr.
El mismo modelo local 12B rindió el mismo examen de 11 preguntas dos veces. Como lector de RAG top-k clásico anotó 0/11. Conectado a un bosque MonkeyLLM como navegador anotó 11/11, y todo lo que necesitas para verificar esa afirmación está versionado en el repo.
Qué significa estrictamente multi-salto
Una pregunta es multi-salto cuando necesitas la respuesta a una subpregunta antes de poder siquiera formular la siguiente. La llamamos estrictamente multi-salto cuando se requieren al menos tres saltos encadenados, y cada una de las 11 preguntas del benchmark supera esa vara. La forma es esta: para responder la pregunta final primero necesitas el dato A, el dato A te da los términos para buscar el dato B, y solo el dato B te dice dónde vive la respuesta.
Esta es exactamente la forma que rompe la recuperación de un solo disparo, porque las palabras clave del salto final no coocurren con las del primero. La recuperación top-k es un salto por construcción, un punto que desarmamos en por qué el multi-salto rompe el RAG.
Cómo se construyeron las preguntas
El corpus es el mismo conjunto de 100 documentos heterogéneos del mundo real usado en nuestra medición de ingesta. La construcción de preguntas fue sustractiva: redactar una candidata, trazar la cadena mínima de evidencia necesaria para responderla y descartarla si un solo documento podía resolverla, o si una coincidencia afortunada de palabras clave podía acortar la cadena. Lo que sobrevive es un conjunto donde los términos de consulta del salto dos solo existen una vez respondido el salto uno.
Ese filtro es brutal, y es una de las razones de que el conjunto sea pequeño. Once preguntas es un benchmark pequeño y lo decimos en el informe. Preferimos defender once preguntas que podemos trazar salto a salto antes que mil que no podemos auditar.
El harness y las dos corridas
Ambas condiciones usan el mismo modelo 12B cuantizado en la misma RTX 3060 con 12 GB. La condición uno es el pipeline por defecto: trocear, indexar, recuperar top-k, entregarle los chunks al modelo, calificar la respuesta. La condición dos le entrega al mismo modelo diez herramientas tipadas sobre MCP y lo deja caminar el bosque (un bosque es un grafo de notas curadas, cada una con un pasaporte: título, resumen, tags). Entra por búsqueda, lee etiquetas, sigue enlaces, abre solo lo que necesita, y cada salto tiene presupuesto de tokens. Navega, no recuperes (Navigate, don't retrieve).
0/11 a 11/11 no es una afirmación de que el modelo se volvió más listo. Los pesos nunca cambiaron. Cambió el entorno, y los puntajes emparejados miden exactamente esa brecha y nada más.
Qué está versionado, incluida la falla
El corpus, los conjuntos de preguntas y el harness están todos versionados, y cada tabla del informe se regenera con un comando. El paper es un preprint y lo decimos.
El informe también conserva un criterio que fallamos: el criterio de convergencia del aprendizaje de senderos no se cumplió, los saltos cayeron aproximadamente la mitad del umbral que fijamos. Está escrito, no borrado, porque un benchmark que solo se puede aprobar no es un benchmark. El razonamiento detrás de esa decisión tiene su propio post.
También puedes interrogar el corpus directamente. La pantalla Data del Studio te da SQL de solo lectura sobre los nodos de dataset, que es la vía más rápida para convencerte de que ninguna fila individual resuelve ninguna de las once preguntas.
Regenéralo tú mismo
El escepticismo es la respuesta correcta ante un puntaje perfecto, así que hicimos que verificar fuera barato. Clona el repo, sigue el quickstart y vuelve a correr cada tabla con un solo comando. Si tus números no coinciden con los nuestros, abre un issue: para eso existe el harness. El resto de la historia vive en monkeyllm.com.