decision-cascade enseña a un modelo local a calcular el coste del error antes de llamar a un LLM externo

Una historia conocida: construyes un sistema con un modelo local pequeño y uno externo grande. El esquema de enrutamiento simple es este: si el modelo local no está seguro, se envía la petición a la nube. El umbral suele sacarse de la manga, digamos 0.6. Un mes después de la primera publicación, el autor del proyecto decision-cascade se hizo una pregunta incómoda: ¿por qué exactamente 0.6?

Por qué el umbral de confianza es un mal criterio

La confianza del modelo y el beneficio de escalar son cosas distintas. Se puede dudar de una respuesta en la que el error no cuesta nada: por ejemplo, elegir una de dos opciones equivalentes. Pagar una llamada externa ahí no tiene sentido. O se puede tener una confianza de 0.8 y equivocarse justo donde el fallo sale caro. Un umbral no distingue estos casos.

Por eso el proyecto incorporó la escalada benefit-aware. El motor compara la utilidad esperada de la respuesta local y de la escalada, teniendo en cuenta el coste del error y el coste de llamar al modelo externo. Si el beneficio de afinar es menor que el coste de la llamada, la cascada se queda en local. Si es mayor, sale al exterior. La decisión no la toma un modelo que evalúa si tiene razón, sino un sistema que calcula si merece la pena pagar por afinar.

Para un product manager es un lenguaje claro: el error tiene un precio en dinero, tiempo o reputación, y la llamada al LLM también lo tiene. La escalada pasa a ser una partida del presupuesto y no un efecto secundario del ajuste de un umbral.

Qué mostraron las demos y los benchmarks

El autor probó el enfoque en dos juegos locales donde las decisiones tienen consecuencias. En ajedrez contra Stockfish, el 19% de escaladas cierra la mitad de la brecha hasta el modo «pensar siempre a fondo» y cuesta el 38% del cálculo completo. En un laberinto al estilo Pac-Man, una política cauta obtiene el 94% de los puntos con un 33% de escaladas, el doble que la estrategia voraz. Nadie pretende convertir el motor en un gran maestro. El sentido es otro: la economía de la escalada funciona donde la decisión tiene un precio.

Aparte hay una comparación con dos modelos «reales», Clef-Flash (9,4B) y Laya (421M), en conjuntos públicos. Condiciones: n=200 y una sola GPU de 16 GB.

• AG News, precisión: 87,3% en decision-cascade (124M), 85,5% en Clef-Flash, 66,2% en Laya.
• AG News, latencia mediana: 10 ms frente a 130 ms de Clef-Flash y 16 ms de Laya.
• RouterBench, precisión: 54,2% frente a 44,2% de Clef-Flash y 31,2% de Laya.
• RouterBench, latencia mediana: 21 ms frente a 170 ms de Clef-Flash.

La conclusión del autor: un modelo pequeño con cabezas entrenadas supera a un competidor de 9B en tareas de toma de decisiones y funciona unas 10 veces más rápido. En generación libre, como él mismo reconoce, ganará el modelo grande. El script eval/competitors/reproduce_real.sh y los JSON sin procesar están en las releases, así que las cifras pueden verificarse.

Integración y dónde está la trampa

Para quienes consideran el proyecto como dependencia, el cambio principal es este: la versión 1.x tiene ahora un contrato estable. El formato de los packs y las variables DECISION_* no se romperán sin una versión major y una ventana de deprecación. El proyecto está en PyPI y el inicio rápido con un codificador hash lleva un par de minutos, sin GPU y sin descargar modelos.

Ahora, las limitaciones, que el propio autor enumera con honestidad. Por defecto las cabezas son aleatorias; una calidad con sentido exige SFT/RLCD o un pack de pesos ya preparado. El modelo de riesgo solo resulta útil tras acumular ejemplos. La calibración de dominio para tu escenario tendrás que hacerla tú. Y no hay que olvidar la escala de las mediciones: n=200, y los benchmarks los montó el propio autor, así que no es una evaluación independiente.

Qué hacer con esto

Aunque no instales decision-cascade, la idea se traslada a cualquier combinación de «modelo barato más modelo caro». Deja de enrutar solo por confianza. Establece al menos una estimación aproximada del coste del error por tipo de petición y compárala con el coste de la llamada. En tareas de clasificación, elección de opciones y valoración, esto puede recortar mucho el gasto en API externas con poca pérdida de calidad. Entre los planes del proyecto figuran un transformer codificador con attention-mask de estados y una integración profunda en agentes de chat. El autor pide que le envíen casos en los que la cascada escala donde no debe, y es la forma más útil de probar el enfoque en la práctica.