¿Cuándo me conviene un modelo pequeño y específico en vez del mejor modelo del momento?
🟠 Intermedio · Concepto · 7 min de lectura
Tengo una tarea estrecha y repetitiva: clasificar mensajes de soporte en seis
categorías. La resuelvo con el mejor modelo del momento, funciona a la
primera y me olvido. Tres meses después son doscientas mil llamadas al mes y
alguien me pregunta por la factura.
El problema
La pregunta «¿qué modelo es mejor?» casi nunca tiene respuesta útil, porque
falta la segunda mitad: mejor para qué restricción.
Esta semana ha salido el ejemplo más incómodo posible. Un análisis muy
comentado sostiene que una red neuronal convolucional de hace diez años rinde
mejor que los modelos frontier actuales diagnosticando cáncer de piel. Con la
cautela de siempre, porque es un análisis y no un ensayo clínico. Pero la
forma del argumento se sostiene sola: un modelo generalista enorme hace muchas
cosas de forma aceptable, y uno pequeño entrenado durante años para una sola
tarea puede ser mejor justo en esa.
Lo que lo hace difícil de ver es que el modelo grande también funciona.
No falla de manera ruidosa. Simplemente es peor de lo que podría ser, más
lento de lo que necesitas y más caro de lo que hace falta, y nada de eso
aparece en una prueba de concepto.
Cómo se resuelve hoy
En vez de comparar modelos, identifica cuál de estas cuatro restricciones
manda en tu caso. Casi siempre manda una sola, y esa decide.
Manda el coste. Si la tarea se repite miles de veces al día, el precio por
llamada deja de ser un detalle. Y hay una palanca que casi nadie toca: el
vocabulario. Un trabajo publicado esta semana en Hugging Face mide que
especializar el vocabulario de un modelo pequeño recorta el coste de
inferencia un 77% en aplicaciones reales. La idea es sencilla: un modelo
general gasta tokens en representar un universo entero de texto; si tu
dominio son seis categorías de soporte, ese universo te lo estás pagando
entero y no lo usas.
Manda la latencia. Aquí está el ejemplo más claro de la semana. Reva, un
trabajo publicado en arXiv, parte de un hecho conocido: los agentes de
seguridad ya encuentran vulnerabilidades reales razonando como lo haría un
experto, ejecutando herramientas, explorando el código de alrededor, probando
hipótesis y pesando la evidencia. El problema es que ese razonamiento son
muchas llamadas al modelo, así que cada veredicto cuesta minutos de
cómputo. Y como los agentes de programación generan código más rápido de lo
que nadie puede revisarlo, hace falta una primera línea de defensa que mire
cada función nueva en tiempo real. Minutos por función no sirve, por bueno
que sea el veredicto.
Manda la precisión en una tarea estrecha. Es el caso del cáncer de piel.
Cuando existe un modelo especializado con años de datos de esa tarea
concreta, la comparación honesta no es contra otro modelo grande: es contra
ese.
Manda dónde viven los datos. Si no puedes sacar el dato de tu máquina o
de la Unión Europea, la lista de candidatos se reduce antes de hablar de
calidad. Esta restricción no se negocia con dinero.
Y hay una regla transversal que ahorra discusiones: usa el modelo grande
para construir, el pequeño para operar. El grande es insuperable
explorando, prototipando y generando los datos con los que luego entrenas o
ajustas algo específico. Eso no quiere decir que tenga que atender cada una
de las doscientas mil peticiones del mes.
Ejemplo
La cuenta que decide, con números redondos para que se vea el orden de
magnitud. Una clasificación de soporte: 200.000 mensajes al mes, unos 400
tokens de entrada y 20 de salida cada uno.
Modelo grande, a 2 $ y 10 $ por millon de tokens:
entrada: 200.000 x 400 x 2 / 1.000.000 = 160 $
salida: 200.000 x 20 x 10 / 1.000.000 = 40 $
al mes = 200 $
Modelo pequeno especializado, a 0,10 $ y 0,40 $ por millon:
entrada: 200.000 x 400 x 0,10 / 1.000.000 = 8 $
salida: 200.000 x 20 x 0,40 / 1.000.000 = 1,6 $
al mes = 9,60 $
Veinte veces menos. Y ahora la parte que casi nadie calcula: cuánto cuesta
llegar hasta ahí. Preparar y etiquetar los datos, ajustar el modelo,
montar la evaluación y mantenerlo son, tirando por lo bajo, dos o tres días
de trabajo. A eso hay que añadir que el modelo grande sigue haciendo falta
para generar las etiquetas de partida.
ahorro mensual: 190 $
coste de montarlo: ~2-3 dias de tu tiempo
punto de equilibrio: varios meses, y solo si el volumen se mantiene
Esa es la cuenta honesta. A 200.000 mensajes al mes, cambiar sale a cuenta.
A 2.000, no: el modelo grande es más barato que tu tiempo, y optimizarlo es
el error contrario.
El guion que yo seguiría, en este orden:
1. Empieza con el modelo grande. Siempre. Es la via mas rapida a saber
si la tarea se puede resolver.
2. Mide tres cosas durante un mes: llamadas al mes, latencia que notas
y coste real. Sin esos numeros no hay decision, hay opinion.
3. Calcula el punto de equilibrio. Si no llega a varios meses de ahorro,
para aqui: ya has terminado.
4. Si sigue, usa el modelo grande para generar y etiquetar los datos de
entrenamiento. Es para lo que mejor sirve.
5. Antes de ajustar nada, busca si ya existe un modelo especializado
para tu tarea. En vision medica, en vision industrial y en habla
suele existir, y lleva anos de ventaja.
6. Y guarda el conjunto de evaluacion. Es lo unico que te va a decir si
el cambio fue bueno, y es lo primero que se pierde.
Errores habituales
Comparar solo modelos grandes entre sí. Es la trampa del artículo de esta
semana. Si tu tarea tiene un modelo especializado con una década de datos
detrás, la tabla en la que comparas tres modelos frontier no contiene a tu
mejor candidato.
Optimizar el coste antes de tener volumen. Dos días de trabajo para
ahorrar cuatro euros al mes es trabajo tirado, y además te deja atado a algo
que hay que mantener. La optimización prematura también existe en esto.
Olvidar que el modelo pequeño hay que mantenerlo. El grande lo mejora
otro por ti, gratis, cada pocos meses. El tuyo no se mejora solo, y si tu
dominio cambia (categorías nuevas, vocabulario nuevo) hay que volver a
pasar por el proceso entero.
Medir calidad sin medir latencia. Es el caso de Reva: un veredicto
excelente que llega en minutos no vale para revisar código en tiempo real.
Cuando la restricción es el tiempo, un resultado peor que llegue a tiempo
gana, y eso cuesta de aceptar.
Qué vigilar
🟢 La cuenta de arriba se hace hoy con tus propios números, en media hora, y
suele acabar la discusión antes de empezarla.
🟡 La especialización de vocabulario. El 77% que mide el trabajo de Hugging
Face es mucho ahorro para una técnica que casi no se usa. Si se vuelve rutina
en las herramientas, el punto de equilibrio de arriba se mueve mucho.
🟡 Los modelos pequeños que se acercan a los grandes en tareas estrechas. Cada
vez que uno nuevo sale, lo que hay que mirar no es su media en una tabla: es
cómo le va en tu tarea con tu conjunto de evaluación.
🔴 Que los modelos frontier bajen tanto de precio y latencia que esta
discusión desaparezca. Pasa un poco cada año y nunca del todo. Mientras haya
una restricción de tiempo real o de dónde viven los datos, va a seguir
habiendo sitio para lo pequeño y específico.