Tokens por respuesta correcta, no por consulta
El costo por consulta hace que fallar parezca un descuento. Medido por respuesta correcta, el navegador de bosque gasta 0.58x los tokens de una línea base de RAG iterativo, mismo modelo 12B. Aquí está la aritmética.
Todos los dashboards de costos les ponen precio a los sistemas LLM por consulta, y por consulta, fallar parece un descuento. En nuestro benchmark el navegador de bosque gasta 0.58x los tokens de una línea base de RAG iterativo por respuesta correcta, con el mismo modelo 12B. El denominador es toda la historia.
El denominador equivocado
Tokens por consulta responde a la pregunta "¿cuánto cuesta intentar?". Nadie entrega un producto que intenta. Lo que de verdad le compras a un sistema de preguntas y respuestas son respuestas correctas, así que la unidad honesta es tokens por respuesta correcta: el gasto total de la carga de trabajo dividido por las respuestas que realmente pudiste usar.
En cuanto cambias de denominador, los pipelines baratos pero equivocados dejan de verse baratos. Cada consulta fallida igual quemó sus recuperaciones y su relleno de contexto, y encima te compró algo con valor negativo: un reintento, una escalación a un modelo más grande, o una respuesta equivocada y segura de sí misma sobre la que alguien actúa. Fallar barato no es economía.
Un ejemplo resuelto y honesto
Estos números son inventados para la aritmética y así los rotulamos; nuestra razón medida viene después. Toma dos sistemas sobre las mismas 100 preguntas:
- El sistema A gasta 1,000 tokens por consulta y acierta 40. Total 100,000 tokens, es decir 2,500 tokens por respuesta correcta.
- El sistema B gasta 1,500 tokens por consulta y acierta 75. Total 150,000 tokens, es decir 2,000 tokens por respuesta correcta.
B es 50 por ciento más caro por consulta y 20 por ciento más barato por respuesta correcta, además de fallar 35 veces menos. Un dashboard por consulta pone a A primero. Un dashboard por respuesta correcta pone a B primero, y es el único de los dos que empareja tu factura con el valor que recibiste.
Lo que medimos
En las 11 preguntas estrictamente multi-salto (cada una exigiendo al menos tres saltos encadenados), el mismo modelo 12B corrió como bucle de RAG iterativo y como navegador de bosque MonkeyLLM. Contando cada token gastado y dividiendo por respuestas correctas, el navegador queda en 0.58x el costo de la línea base.
También es más rápido donde duele: 8.4 s p95 contra los 17.5 s de la línea base. El cara a cara completo, incluido cómo funciona la línea base, está en RAG agéntico vs navegación con presupuesto.
De dónde sale el 42 por ciento
El RAG iterativo paga renta por el mismo terreno en cada ronda: cada reformulación vuelve a recuperar chunks superpuestos y el modelo los vuelve a leer. El navegador, en cambio, lee pasaportes (un pasaporte es el título, resumen y tags curados del nodo), sigue enlaces y abre un nodo completo solo cuando lo necesita, con cada salto sujeto a presupuesto de tokens sobre MCP.
Esa frugalidad se compra en tiempo de escritura. La ingesta gasta 1.71 s por documento construyendo la curaduría, con el 100% de los resúmenes pasando un contrato de sesenta tokens. Gasta inteligencia en el entorno para gastar menos en el modelo.
La corrección también queda auditable. En la pantalla Ask del Studio cada respuesta llega apoyada en los nodos que la sostienen, así que "correcta" es algo que verificas, no algo que intuyes.
Verifica la aritmética
El corpus, los conjuntos de preguntas y el harness están versionados, y cada tabla se regenera con un comando. Lee el preprint (lo llamamos preprint porque eso es lo que es), vuelve a correr los números desde el repo y encuentra el resto en monkeyllm.com.