Tu loop de RAG agéntico responde más lento y gasta más por respuesta correcta. Lo medimos.
Los loops de RAG iterativo esconden su costo en el denominador equivocado. Medido por respuesta correcta: 0.58x los tokens y 8.4 s p95 frente a 17.5 s, con el mismo modelo 12B.
Cuando el RAG top-k falla en preguntas multi-hop, el arreglo estándar es un loop: recuperar, razonar, reformular, recuperar de nuevo. Sí ayuda. También es caro de una forma que se esconde bien, porque solemos medir el costo por consulta en vez del costo por respuesta correcta.
Construimos MonkeyLLM alrededor de otra idea (navegación en vez de recuperación) y medimos ambas. Aquí va el frente a frente, arquitectura contra arquitectura.
El montaje
El benchmark: 11 preguntas estrictamente multi-hop, cada una exige al menos 3 saltos encadenados entre documentos. Sí, 11 preguntas es un benchmark pequeño, y lo decimos en el paper. Ambos lados usan el mismo modelo local de 12B cuantizado en una sola RTX 3060 de 12 GB. Sin llamadas a la nube.
Los números
- Tokens por respuesta correcta: 0.58x frente a la línea base de RAG iterativo.
- Latencia: 8.4 s p95 frente a los 17.5 s de la línea base.
- Para contexto de exactitud: ese mismo modelo obtuvo 0/11 como lector top-k clásico y 11/11 como navegador de bosque.
La línea a la que siempre volvemos: fallar barato no es economía. Un loop que quema menos tokens en una respuesta equivocada igual te compró una respuesta equivocada.
Por qué el loop paga más
Un loop iterativo vuelve a consultar una pila indiferenciada de chunks, y cada ronda vuelve a llenar la ventana de contexto con evidencia superpuesta que el modelo debe releer.
MonkeyLLM estructura el corpus como un bosque de nodos, cada uno con un pasaporte curado (título, resumen, etiquetas: una ficha de bibliotecario). El agente, el mono, entra por búsqueda y camina: lee la ficha, sigue un enlace, abre solo lo que necesita. Diez herramientas tipadas sobre MCP, cada salto barato y con presupuesto de tokens.
La 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 los campos curados cerró por completo la brecha de recall frente a la búsqueda híbrida.
El costo se movió, no desapareció. La ingesta corre a 1.71 s por documento (medido 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.
Lo que no funcionó
Nuestro criterio de convergencia del aprendizaje de senderos no se cumplió: los saltos cayeron cerca de la mitad del umbral que fijamos. Publicamos el fallo en vez de descartarlo. Un benchmark imposible de reprobar no es un benchmark.
Reprodúcelo
Corpus, sets de preguntas y harness están versionados en el repo, y cada tabla se regenera con un comando. El paper es un preprint, y lo decimos.
Dale una estrella al repo, lee el preprint o vuelve a correr todo con tu propio corpus: