Scaffolding de agentes frente a fine-tuning

El scaffolding es todo lo que se construye alrededor de un modelo para que sea útil en una tarea concreta: las herramientas que puede llamar, el contexto que se le da antes de responder, la evaluación que puntúa su salida, los guardrails que frenan acciones incorrectas y las rutas de reintento o escalado cuando falla. El fine-tuning es distinto: ajusta los pesos internos del propio modelo usando ejemplos de la tarea, así que cambia el modelo en sí, no lo que lo rodea.

Qué cambia realmente cada uno

El scaffolding nunca toca el modelo. Cambia lo que el modelo puede ver y hacer. Darle a un agente acceso de lectura al historial de pedidos de un cliente, una herramienta para consultar el estado de un envío y una regla que marque cualquier reembolso superior a 200 € para revisión humana es scaffolding. Nada de eso requiere reentrenar nada; se puede cambiar en minutos editando un prompt, añadiendo una herramienta o ajustando un guardrail.

El fine-tuning cambia los pesos del modelo para que se comporte de forma distinta ante entradas que no ha visto formuladas de esa manera antes. Necesita un conjunto de datos etiquetado, una tanda de entrenamiento y un nuevo artefacto de modelo que desplegar. Iterar es más lento y auditarlo es más difícil, porque el comportamiento resultante queda incrustado en los pesos en lugar de ser visible en un prompt.

Por qué el scaffolding gana en la mayoría del trabajo operativo

El fallo típico en los sistemas agénticos no es que al modelo le falte capacidad de razonamiento para hacer la tarea. Es que le falta el contexto correcto o la herramienta correcta en el momento en que la necesita: no conoce el nivel de inventario actual, no puede ver el historial de gasto de la cuenta o no tiene forma de comprobar su propia respuesta antes de devolverla. Hacer fine-tuning a un modelo para que “sepa” hechos que cambian a diario no soluciona eso; los hechos volverán a estar desactualizados en una semana. Un mejor contexto y una herramienta de consulta en vivo lo solucionan de inmediato y siguen funcionando a medida que cambian los datos subyacentes.

Por eso la evaluación importa más que la elección del modelo en la práctica. Una regla de decisión con un umbral, una rúbrica clara de qué es una salida correcta y una ruta de reintento cuando el primer intento falla detectan y corrigen más errores que cambiar a un modelo marginalmente más capaz. El scaffolding también es más barato de probar: puedes correr una prueba A/B sobre una herramienta o un guardrail nuevo en un día, frente a semanas para un ciclo de fine-tuning.

Una regla de decisión para saber cuándo el fine-tuning es acertado

El fine-tuning justifica su coste cuando una tarea es acotada, estable y de alto volumen, con un formato de salida fijo y suficientes ejemplos etiquetados para entrenar, del orden de unos pocos miles como mínimo para lograr un cambio significativo de comportamiento. Un ejemplo: clasificar creatividades publicitarias entrantes en una de 12 categorías fijas, ejecutado millones de veces al mes, donde la taxonomía de categorías no ha cambiado en un año y ya existen miles de ejemplos etiquetados por humanos. Eso es acotado, estable, de alto volumen y bien etiquetado, las cuatro condiciones a la vez.

Compáralo con una tarea como optimizar el gasto en Meta Ads en cuentas con distintos objetivos, catálogos y estacionalidad. La tarea no es acotada, la respuesta correcta cambia a medida que cambian la cuenta y la plataforma, y no hay un formato de salida fijo, solo un juicio que depende del contexto en vivo. Hacer fine-tuning de un modelo con las decisiones del trimestre pasado incrustaría suposiciones que ya estarían desactualizadas cuando terminase el entrenamiento.

Cuando el fine-tuning es la salida cara

Si un equipo recurre al fine-tuning porque los prompts se sienten poco fiables o el modelo “no entiende nuestro negocio”, eso suele ser una carencia de scaffolding, no de capacidad: falta contexto, faltan herramientas o no hay un bucle de evaluación que detecte y corrija salidas incorrectas. Hacer fine-tuning sin solucionar esa carencia añade coste y rigidez sin abordar el fallo real. La prueba más barata primero: dale al modelo el contexto o la herramienta que le falta, añade una comprobación sobre su salida y comprueba si el fallo desaparece antes de entrenar nada.

Para el argumento completo de por qué esta disyuntiva sigue apareciendo a medida que maduran los sistemas agénticos, ver fine-tuning vs. scaffolding.