Cascadas y preguntas en paralelo
La motivación detrás de ambos patrones es simple: una llamada a un modelo grande es cara, y la mayoría de las peticiones son fáciles. Una llamada de decisión cuesta uno o dos órdenes de magnitud menos que una generación, así que «pregunta primero al barato, escala cuando no estés seguro» es la forma obvia.
Cascadas: decide solo donde estás seguro
Una evaluación comparativa directa sobre detección de alucinaciones médicas da un número limpio:
Deja que el modelo de decisión resuelva el 37% de los casos en los que tiene al menos un 90% de confianza, y conserva la precisión propia de cada modelo grande mientras elimina el 37% de las llamadas al modelo grande.
Vale la pena citarlo porque dice en qué consiste realmente el ahorro de una cascada: la proporción de tráfico que cae dentro de tu región de alta confianza, no un porcentaje fijo. Una confianza más ajustada significa más ahorro — siempre que esa confianza sea real, lo que nos devuelve a la calibración.
Dos detalles son fáciles de pasar por alto:
① Después del escalado, el modelo grande no debería tener libertad ilimitada. Una implementación que entrega las filas inciertas a un LLM obliga a ese LLM a elegir del mismo conjunto de etiquetas. Sin eso, el «no estoy seguro» del modelo pequeño se convierte en una salida que tu pipeline no puede consumir.
② Una vez tomada una elección, mantenla. Un enrutador de modelos conserva su selección durante toda la sesión para preservar la continuidad de la caché de prompt. Volver a elegir en cada turno cambia el prefijo y tira la caché — el dinero que ahorraste en la llamada más barata se va de vuelta por la caché.
Preguntas en paralelo: lo que ahorras es entrada
Los modelos de decisión te permiten poner muchas preguntas en una sola petición; los ejemplos oficiales piden decenas a la vez.
Un benchmark sobre 2,976 llamadas midió lo que eso aporta:
| Elemento | Resultado |
|---|---|
| 8 preguntas en paralelo frente a una a una | 76–86% de ahorro mediano en tokens de entrada |
| Sobrecarga fija por petición | unos 261 tokens de entrada |
Así que el ahorro no es que «el modelo calcule más rápido», sino que el mismo estado se envía una sola vez. Cuantas más preguntas, más se diluye esa sobrecarga fija. Con una o dos preguntas, la diferencia entre paralelo y secuencial es del mismo orden que el ruido entre ejecuciones, y no merece un cambio de arquitectura.
Contraejemplo: agrupar puede romper el ranking
Este es el hallazgo más contraintuitivo de esta página:
Una extensión de DuckDB agrupa 40 filas por defecto. El benchmark encontró que la ruta agrupada falla su puerta de calidad de ranking, mientras que una fila por petición la pasa.
La razón es reconstruible: meter 40 filas en una sola petición le pide al modelo producir 40 ordenaciones relativas a la vez, lo cual es más difícil que comparar unos pocos candidatos por vez. El coste y la fidelidad están en conflicto aquí — y el lado del coste es visible (la factura), mientras que el lado de la fidelidad es invisible a menos que hayas construido una puerta para medirlo.
La regla general: las preguntas en paralelo sirven para preguntas independientes (clasificación, scoring, juicio) y no para preguntas que requieren comparar unos elementos con otros.
Una precondición más: los errores tienen que ser aleatorios
Las cascadas funcionan por una suposición implícita: los errores del modelo pequeño son ruido aleatorio, así que el modelo grande puede corregirlos.
Pruebas independientes de calibración fuera de distribución contradicen eso. Choice y
Score son sistemáticamente demasiado confiados; Boolean es sistemáticamente poco
confiado. Un sesgo sistemático no es ruido: hace que el modelo pequeño reporte alta
confianza en toda una clase de entradas, de modo que esa clase nunca se escala y se
responde mal cada vez.
El riesgo, entonces, no es una «precisión ligeramente menor», sino que todo un tipo de entrada se descarte de forma consistente, de manera invisible en el agregado. Encontrarlo exige mirar la precisión por subclase, no en conjunto.
En una frase
Una cascada ahorra en proporción a cuánto tráfico se sitúa en su región de alta confianza; las preguntas en paralelo ahorran amortizando una sobrecarga fija. Ambas tienen un precio: la primera apuesta a que los errores del modelo más pequeño son aleatorios, la segunda perjudica a las tareas que necesitan comparación cruzada.