Capítulo 3: Elige el modelo que necesita la tarea

Visión general#

Los equipos suelen elegir un modelo capaz para la primera funcionalidad y usarlo después en todas partes. Meses más tarde, ese modelo está clasificando tickets, resumiendo conversaciones, extrayendo campos e investigando incidentes de producción.

La configuración es fácil de entender, pero algunas operaciones acaban pagando por capacidades que no necesitan.

Un clasificador de tickets de cinco categorías y un agente que depura un fallo de pago intermitente son problemas distintos, y rara vez necesitan el mismo modelo y la misma configuración. Para cada operación, pon precio a todo el camino hasta un resultado aceptado, incluidas la validación, los reintentos y el escalado, antes de elegir un modelo por su precio por token.

Práctica#

Agrupa el trabajo según lo que requiere: clasificación acotada, extracción, resumen, preguntas y respuestas con fuentes, razonamiento sobre varios documentos y agentes que usan herramientas. Para cada grupo, registra los criterios de aceptación y las restricciones innegociables: latencia, tamaño del contexto, formato de salida, idioma, disponibilidad y tratamiento de los datos.

Después, haz una lista corta de modelos que puedan cumplir esos requisitos, incluidos candidatos de pesos abiertos cuando proceda. Una clasificación general de benchmarks no te dice si un modelo encaja con la tarea.

Para averiguarlo, construye un pequeño conjunto de evaluación con casos reales de esa operación, que incluya tareas que se aceptaron y tareas que se rechazaron. Ejecuta cada candidato contra él antes de cambiar, y otra vez después de cualquier cambio de prompt o de modelo. Esas ejecuciones cuestan tokens y tiempo de revisión, así que cuéntalas como parte de la decisión. Mira los resultados por tipo de caso y por modo de fallo además de la puntuación global, porque un modelo puede igualar la media y fallar en los casos que más importan.

Una comparación hipotética de dos enfoques para la misma operación de extracción:

Las dos columnas incluyen validación porque cualquiera de los dos modelos puede devolver una respuesta incorrecta. La comparación también supone tasas de aceptación iguales; si difieren, compara el coste por tarea aceptada. Que la columna más barata se sostenga depende de con qué fiabilidad la comprobación detecta los fallos, algo que trata Enrutamiento, cascadas y presupuestos de razonamiento.

Antes de añadir otro modelo, comprueba si el código normal puede hacer el trabajo. Dar formato a campos conocidos, comparar marcas de tiempo y la aritmética no suelen necesitar inferencia generativa.

Ledgerline. Ledgerline construyó un conjunto de evaluación de 300 facturas reales, 200 aceptadas y 100 rechazadas anteriormente, y ejecutó dos candidatos contra él. Cada ejecución del conjunto cuesta unos 9 $. Un modelo más pequeño con un 15 % de escalado al grande igualó la aceptación del modelo grande en el conjunto y dejó la extracción en 0,018 $ por factura aceptada: 40.000 × 0,018 $ = 720 $ al mes, frente a 1.200 $.

En profundidad#

Compara el uso de tokens facturables además de los precios unitarios publicados. Dos modelos pueden tokenizar la misma entrada de forma distinta, necesitar distinto nivel de detalle en el prompt, producir salidas de distinta longitud y consumir presupuestos de razonamiento distintos.

Una ventana de contexto más grande no garantiza un mejor uso de un documento largo; la calidad de la recuperación y la estructura del prompt pueden importar más que el límite anunciado. Cada modelo adicional también añade mantenimiento: configuraciones de proveedor, variantes de prompt, comportamiento de respaldo y monitorización.

El fine-tuning o la destilación son otra palanca. En una tarea acotada y estable, como un esquema de extracción que rara vez cambia, un modelo más pequeño entrenado con tus salidas aceptadas o con las respuestas de un modelo más grande puede sustituir a uno grande y generalista. Trae sus propios costes: preparar los datos de entrenamiento, las ejecuciones de entrenamiento, la evaluación, el alojamiento y el reentrenamiento cuando cambian las entradas o los requisitos. Las licencias de los modelos implicados también deben permitirlo, algo que trata Qué cambian de verdad los modelos de pesos abiertos. Reparte esos costes entre el volumen que esperas antes del siguiente reentrenamiento y súmalos a la comparación.

Mantén pequeño el número de modelos, y añade uno para una carga de trabajo distinta solo cuando el beneficio justifique ese mantenimiento.

Referencias: Licencia y destilación de DeepSeek-R1, Términos de uso de Gemma (derivados del modelo).