Parte de: Tool-Calling: Cuándo un Modelo Chico Gana al LLM Grande
Qué Modelo de Decisión Usar Según tu Proceso y tus Recursos
El reporte anterior mostró cuándo conviene un modelo chico en vez del LLM grande. Este profundiza en la parte técnica: qué tipo de tecnología corresponde a cada proceso, cómo se calibra su confianza con RLCD para que un umbral tenga sentido, y con qué hardware corre cada opción.
Qué Tecnología Corresponde a Cada Proceso
No hay una respuesta única: depende de qué tan cerrado es el espacio de opciones de la decisión y de qué hardware tienes disponible para correrla. La tabla cruza ambas variables.
| Si tu proceso es… | Y tienes… | Usa esto |
|---|---|---|
| Clasificar, enrutar, puntuar o verificar sobre un catálogo cerrado de opciones | Solo CPU, entrada corta (la nota, sin el contexto completo) | Decisor chico local, tipo System 1: responde en 30–500 ms |
| Lo mismo, pero con contexto largo (miles de tokens) | GPU de 8 GB o más | Decisor chico local en GPU: el mismo trabajo baja de segundos a décimas de segundo |
| Elegir qué tool llamar y completar sus argumentos desde el texto | Catálogo acotado (5 o menos tools sin recuperador) | Decoder chico con gramática: cada argumento debe estar evidenciado en el texto |
| Cualquiera de los anteriores, pero sin infraestructura propia que mantener | Presupuesto por token, sin instalar nada | Servicio hospedado de decisión: mismo contrato, sin pesos que administrar |
| Razonar en varios pasos, comparar fechas, redactar, resolver ambigüedad real | Cualquiera | LLM grande, tipo System 2: es justo lo que resuelve, ningún decisor chico lo reemplaza |
La primera columna es la misma variable del reporte anterior, espacio de decisión acotado, aplicada más allá de tool-calling: a clasificar, enrutar y verificar en general.
System 1 Decide en una Pasada, no Razona en Cadena
Un LLM generativo produce texto token por token y de ahí se extrae una respuesta. Un modelo de decisión invierte el orden: lee el estado y las opciones una vez y devuelve directamente una distribución de probabilidad sobre esas opciones, sin generar prosa.
Es la arquitectura de dos velocidades de Kahneman aplicada a un pipeline de agentes: System 1 es rápido e intuitivo, clasifica, enruta, verifica, puntúa; System 2 es lento y deliberado, razona en varios pasos, redacta, resuelve ambigüedad real. La categoría ya tiene su propio catálogo independiente en systemonemodels.org, que sigue a Jev, Laya y sus variantes; es una señal de que "System 1" se está consolidando como nombre de categoría, no solo como término de marketing de un proveedor.
| Rasgo | System 1 | System 2 |
|---|---|---|
| Cómo decide | Una pasada, como un reflejo | Cadena de razonamiento, token a token |
| Tiempo medido | 30–500 ms en nuestro banco propio | Segundos, a veces minutos |
| Salida | Opción cerrada más probabilidad | Texto libre, código, explicaciones |
| Costo por decisión | Casi nulo | Por token, alto |
| Fuerte en | Clasificar, enrutar, verificar, extraer campos, puntuar | Aritmética, fechas, varios saltos, redactar, explicar |
Un ejemplo real: un guard de entrada
En corifeo, nuestro propio buscador con fallback de IA, el guard es la primera etapa: decide si un mensaje es legítimo, ambiguo o un intento de manipular al sistema. Es exactamente este tipo de decisión, un catálogo cerrado de categorías, alto volumen, sin necesidad de redactar nada. Hoy la resuelve un SLM o modelo de NLP con razonamiento apagado, no un LLM grande generando prosa; el resto del pipeline, donde hay que ejecutar la tarea del usuario con reglas largas en lenguaje natural, sí usa un LLM grande razonando. No es una elección de marca: es la misma variable de la tabla anterior aplicada a nuestro propio producto.
Por qué importa la calibración
System 1 solo es seguro si sabe cuándo no sabe. Una probabilidad calibrada es la señal para escalar el caso dudoso a System 2: un umbral de "actuar, confirmar o rechazar" solo tiene sentido si el 0,8 que devuelve el modelo acierta cerca del 80 % de las veces. De eso trata la siguiente sección.
RLCD: la Recompensa que Hace Honesta la Probabilidad
Reinforcement Learning for Calibrated Decisions, RLCD, es el nombre con que TypeSafe describe cómo entrena la calibración de Jev. Es un término acuñado por ese proveedor, sin paper revisado por pares ni reward function publicada, pero ya aparece en glosarios independientes y se compara de forma habitual contra RLHF y RLVR: un término en camino a consolidarse como categoría, aunque siga siendo, por ahora, la descripción de un método propio. RLHF optimiza por la preferencia de un evaluador humano, lo que tiende a premiar un tono seguro en la prosa; RLVR premia una salida que un script puede verificar como estrictamente verdadera o falsa, útil en código o matemáticas, pero no dice cuánta certeza debería tener el modelo sobre un juicio semántico general. RLCD abandona la preferencia de estilo por completo: recompensa que la probabilidad reportada coincida con el resultado real, medido en muchas decisiones. Otras implementaciones abiertas publican recetas propias que persiguen el mismo objetivo sin usar ese nombre. La idea común es recompensar al modelo con una regla de puntuación estrictamente propia: una fórmula cuya recompensa esperada es máxima solo cuando el modelo reporta la probabilidad verdadera. Al modelo le conviene ser honesto, no sonar seguro.
La sigla RLCD está sobrecargada: también nombra una técnica anterior y no relacionada en la literatura académica, Reinforcement Learning from Contrastive Distillation, de Yang, Klein, Celikyilmaz, Peng y Tian, ICLR 2024. Esa RLCD alinea LLMs para seguir principios en lenguaje natural generando pares de preferencia sintéticos a partir de un prompt positivo y uno negativo, sin feedback humano; resuelve alineamiento, no calibración de probabilidad de un modelo de decisión. Son dos técnicas distintas que comparten sigla por coincidencia; en este reporte, RLCD se refiere siempre a la de TypeSafe/Jev.
Prueba los controles: mueve la probabilidad real y la reportada, y compara contra ser honesto, sobreconfiar o quedarte indeciso.
Las tres reglas son matemáticamente propias: log score (p·ln q + (1−p)·ln(1−q)), esférica y Brier como recompensa negativa. Sobreconfiar o decir "no sé" siempre rinde menos que reportar la verdad.
| Paso | Qué hace |
|---|---|
| 1 · Logits | Una puntuación por opción, salida del modelo antes de normalizar. |
| 2 · Exploración | Varias muestras ruidosas de esos logits, con el ruido bajando a medida que avanza el entrenamiento. |
| 3 · Recompensa | Log score más un componente esférico; se resta el ranked probability score cuando las opciones están ordenadas (una escala, no categorías sueltas). |
| 4 · Ventaja y pérdida | Las muestras con mejor recompensa que el promedio del grupo refuerzan el gradiente; se suma una pérdida supervisada contra la respuesta correcta. |
| 5 · Calibración posterior | Sobre un tramo de datos nunca entrenado, se ajusta una temperatura por tipo de pregunta con LBFGS. La probabilidad final es softmax(z / T). |
Con calibración por temperatura, la tarjeta de una de las implementaciones abiertas de este método reporta un error de calibración, ECE, de 0,017 sobre 1.500 ejemplos: un 0,8 de confianza acertó cerca del 80 % de las veces. Es una cifra publicada por ese proyecto, no medida por nosotros; distinta del banco de pruebas de corifeo de la sección de evidencia, más abajo.
El punto ciego del afinado local
No todas las tecnologías de decisor chico calibran igual: en algunas, el afinado con tus propios datos, un LoRA local, entrena el modelo pero no entrena la cabeza de confianza: el resultado es una categoría sin probabilidad, y sin probabilidad no hay umbral. Antes de adoptar una, confirma si tu ruta de afinado incluye la calibración o solo el afinado del modelo.
Ficha de las Tecnologías Abiertas Disponibles Hoy
Cuatro implementaciones concretas del mismo patrón, evaluadas en nuestro banco propio. Es material de referencia, no la conclusión del reporte; la decisión que importa es la de la primera sección: qué tipo de tecnología corresponde a tu proceso.
| Tecnología | Mecanismo | Pesos y licencia | Dónde corre |
|---|---|---|---|
| JevTypeSafe · servicio hospedado | Arquitectura propia no publicada. Es System 1: responde en una sola pasada con probabilidad calibrada. Según TypeSafe, entrenado con RLCD, el nombre que ellos usan para el entrenamiento con reglas de puntuación propias, sin pesos ni paper que lo verifiquen de forma independiente. | Cerrado, sin ajuste por cliente | Hospedado, cobro por token de entrada |
| Jev-Stylereproducción abierta independiente | LLM chico de 0,8 a 2B parámetros que lee el logit de un token fijo al final de cada opción, en una sola pasada, sin generar ni decodificar. | Apache-2.0; parte de los datos de entrenamiento tiene licencias restrictivas a revisar antes de uso comercial | Local: 0,5–2 GB en disco según cuantización |
| LayaConvai Innovations | Encoder ModernBERT-large de 421M de parámetros, no autoregresivo, con cabeza de decisión tipada: responde choice, score y sí/no (noul) sobre un texto en una sola pasada, con probabilidad calibrada en vez de texto generado. Hay un segundo checkpoint mmBERT-base de 322M para multilingüe; un router elige según idioma. Igual que las demás tecnologías de esta ficha, el checkpoint base rinde 0,34–0,36 de accuracy en su propio benchmark, bajo en tareas nuevas; el mismo checkpoint afinado con 2.000 decisiones de dominio sube a 0,77 en sus cuatro flujos de ejemplo: otro caso a favor de afinar con datos propios antes de promover cualquier modelo. | Apache-2.0 | Local, CPU o GPU, ~650–850 MB |
| NeedleCactus Compute | Decoder chico con entrenamiento en escalera: de 29 a 121M de parámetros según la profundidad que cortes, con gramática compilada desde tu schema y una cabeza de confianza calibrada. El ~26M de nuestros reportes anteriores es la configuración específica que evaluamos en banco propio, dentro de este mismo rango. | Apache-2.0; formato propio de cuantización de 2 bits | Local en casi cualquier plataforma, desde 35 MB |
Ninguna de las cuatro está afiliada entre sí. Los números de velocidad y precisión que publica cada fabricante son de su propio banco, no una medición independiente: evalúalas en tu caso antes de dimensionar sobre ellos.
Cómo un Decoder de 29M de Parámetros Rinde Como Uno Más Grande
Detalle interno de Needle, una de las tecnologías de la ficha, para quien quiera evaluar si su enfoque de eficiencia aplica a otro caso. No es necesario para decidir qué tipo de tecnología usar: esa decisión ya está en la primera sección.
| Pieza | Reemplaza | Para qué sirve |
|---|---|---|
| FFN factorizada (producto de Kronecker) | La capa feed-forward densa de un transformer normal | Factoriza una matriz N×N en dos matrices de orden √N: misma transformación, muchos menos parámetros y multiplicaciones. |
| Atención agrupada + convolución causal corta | Atención completa por cabeza | Mezcla cada consulta con las dos anteriores antes de la atención, así el modelo ve contexto local sin que la atención sola tenga que aprenderlo; menos caché que guardar. |
| Memoria de n-gramas (tabla con hash) | Parte del trabajo que en un modelo grande haría más atención | Una lectura de tabla, un gather, es barata aunque la tabla sea grande: memoria de patrones frecuentes, no cómputo; por eso un modelo chico rinde como uno de más parámetros. |
| Residual multicarril | El residual único de un transformer normal | Varios carriles paralelos que cada capa puede leer y escribir por separado, en vez de forzar a todas las capas a compartir el mismo canal. |
| Entrenamiento en escalera | Entrenar un modelo distinto por cada tamaño de despliegue | Las primeras N capas del mismo checkpoint, para cualquier N dentro de un rango, ya forman un modelo coherente por sí solas: se corta a la profundidad que aguante el dispositivo, sin reentrenar. |
Un formato de cuantización de 2 bits, en la práctica
Una técnica usada en este espacio agrupa los pesos de a 128, rota cada grupo con una matriz de Hadamard antes de codificar, y guarda por separado el largo del grupo, un valor de referencia, y su dirección, cuantizada contra un codebook. El resultado son unos 2,1 bits por peso en vez de los 16 o 32 de un modelo sin cuantizar, con un overhead fijo y pequeño por grupo, no por peso individual.
Qué tan probado está esto: ya existen en la literatura de eficiencia de transformers técnicas individuales como la factorización tipo Monarch, la atención agrupada y las hiper-conexiones; lo específico de esta implementación es combinarlas con memoria de n-gramas y entrenamiento en escalera. No hay pesos publicados por pieza para verificar el aporte de cada una por separado.
Resultados en el Banco de Pruebas de Corifeo
Batería de 38 casos reales, anonimizados localmente (mensajes legítimos, ambiguos, intentos de inyección de instrucciones y de abuso), 3 corridas, evaluando alternativas para el guard de entrada de corifeo, nuestro propio buscador con fallback de IA. Los modelos locales son deterministas.
| Tecnología | Aciertos / 114 | Mediana de tiempo | Entrada leída |
|---|---|---|---|
| Servicio hospedado (prompt completo) | 111 | 242 ms | Contexto completo |
| Decoder chico, afinado (solo nota) | 78 | 218 ms | Solo la nota, sin contexto estructural |
| Encoder afinado con datos propios del guard (solo nota) | 35/38 · 92 % | ~180 ms | Solo la nota, 4 épocas en una GPU de 8 GB |
| Encoder afinado, checkpoint específico (solo nota) | 54 | 404 ms | Solo la nota |
| Encoder afinado, checkpoint multilingüe (solo nota) | 30 | 144 ms | Solo la nota |
| Decoder chico, sin afinar (solo nota) | 12 | 237 ms | Solo la nota, primera prueba |
La fila del encoder afinado con datos propios usa una denominación distinta, 35/38 y no /114: es una batería nueva de 38 casos, corrida una vez porque la clasificación del modelo ya es determinista, sin repetir las 3 corridas de la batería original. Sobre un conjunto retenido más chico y nunca visto en el afinado, 12 casos, el mismo checkpoint bajó a 8/12; sobre 5 casos largos y más complejos, acertó los 5. Es exactamente el riesgo del checklist más abajo: el número de la batería principal no basta para promover un modelo sin mirar también su desempeño en un conjunto ciego.
La brecha entre 12 y 78 aciertos con el mismo decoder chico es afinado, no arquitectura: sin datos de dominio, un decisor chico sin afinar clasifica peor que uno grande sin afinar. El checkpoint multilingüe rindió peor que el especializado en un idioma en esta muestra: un caso a favor de afinar en el idioma real de tu tráfico antes de promover cualquier modelo. Afinar con datos propios del dominio, no solo con el dataset por defecto de un tercero, es lo que separa el 54/114 del encoder de checkpoint específico del 35/38 del encoder afinado con datos propios del guard.
Dónde se Rompe Este Patrón
- Licencia de los datos de entrenamiento: un checkpoint abierto puede declarar una licencia permisiva mientras parte de sus datos de entrenamiento tiene términos restrictivos (uso solo de investigación, u origen en salidas de otro modelo). Revisar antes de un uso comercial.
- No tratar el estado como hostil: varios de estos modelos no están diseñados contra instrucciones inyectadas dentro del texto que evalúan. Un decisor chico no reemplaza una capa de sanitización de entrada.
- Ecosistema joven: varias de estas implementaciones cambian de método cada pocas semanas. Fijar versión y probar paridad antes de exportar cuantizado.
- Nunca pegar una credencial en un prompt o chat: tratar cualquier API key como un secreto en todo momento, incluso en un playground de prueba, y rotarla de inmediato si eso ocurre.
- Sin conjunto ciego, no hay promoción: un modelo nuevo corre en sombra, en paralelo al vigente, y se compara con evidencia sobre datos que nunca vio antes de reemplazar nada en producción.
- Sin GPU, la lectura de contexto largo es lenta: del orden de milisegundos por token en CPU: si tu proceso necesita leer contexto extenso y responder rápido, hace falta GPU o acotar la entrada.
Antes de Adoptar un Decisor Rápido
El Tipo de Decisión Elige la Tecnología, no al Revés
Un catálogo cerrado con volumen alto es candidato a un decisor chico calibrado; algo que razona en varios pasos o redacta necesita el LLM grande. La calibración es lo que hace confiable el umbral entre ambos; sin ella, la probabilidad que devuelve el modelo chico es solo un número.
¿Estás evaluando qué tecnología usar para una decisión rápida en tu pipeline de agentes?
Contenido relacionado
Tool-Calling: Cuándo un Modelo Chico Gana al LLM Grande
El reporte del que se desprende este: por qué un tool-call es una clasificación de espacio acotado, no una redacción abierta.
Leer el reporte - 4 Variables de DecisiónQué API de IA Usar en tu Proyecto: la Arquitectura Correcta, no la Más Cara
Las cuatro variables para elegir el tamaño de modelo correcto por proceso: el mismo criterio de este reporte, aplicado a la elección de API.
Leer diagnóstico - 4 Variables para Elegir APIModelo de Lenguaje Propio para tu Empresa
El servicio que aterriza esta arquitectura: diseño e implementación de tu stack de decisión rápida y modelo de lenguaje propio.
Ver la solución - Modelo de Lenguaje Propio