Cuándo basta con prompting

Antes de recurrir al fine-tuning, trate el prompting como la hipótesis nula. Los modelos modernos de vanguardia tienen suficiente capacidad latente como para que la mayoría de las tareas sean un problema de recuperación e instrucciones, no un problema de actualización de pesos.

El error costoso que cometen los equipos es iniciar un proceso de entrenamiento cuando un prompt bien estructurado, unos pocos ejemplos y acceso a herramientas habrían cerrado la brecha sin coste marginal de entrenamiento. El fine-tuning solo se justifica cuando el prompting demuestra que ha alcanzado un techo.

• El prompting cambia por solicitud; el fine-tuning cambia el modelo
• El prompting es reversible en segundos; un checkpoint ajustado es un artefacto cuyo compromiso queda establecido
• Empiece con la opción económica y escale solo cuando haya pruebas

Compare los enfoques según tres ejes de coste independientes, no solo según el dinero:

• Coste de iteración - ¿con qué rapidez puede cambiar el comportamiento? Prompting: minutos. Fine-tuning: de horas a días por ciclo.
• Coste de inferencia - el prompting paga por token por las instrucciones largas y los ejemplos en cada llamada; un modelo ajustado puede incorporar ese comportamiento en los pesos y reducir el tamaño del prompt.
• Coste de mantenimiento - un prompt vive en el control de versiones y es auditable; un checkpoint debe volver a ajustarse cada vez que el modelo base queda obsoleto.

El prompting gana en iteración y mantenimiento; el fine-tuning puede ganar en coste de inferencia con un volumen elevado.

El argumento del coste de inferencia a favor del fine-tuning solo se sostiene por encima de un umbral de volumen. Modele explícitamente el punto de cruce: un prompt few-shot largo que añade 2.000 tokens de entrada por llamada implica un coste recurrente; un modelo ajustado amortiza el coste de entrenamiento con el volumen.

Si su tráfico está por debajo del punto de equilibrio, el prompt few-shot resulta estrictamente más barato y flexible.

El argumento más sólido a favor del prompting es la opcionalidad ante la incertidumbre. Los requisitos cambian: aparece un nuevo caso límite, cambia una política o se añade un campo de salida. Con prompting, modifica el texto; con un modelo ajustado, debe volver a recopilar datos y entrenarlo de nuevo.

Cuando la definición de la tarea aún está cambiando —en un producto inicial, con una especificación ambigua o con cambios frecuentes por parte de las partes interesadas—, el prompting casi siempre es la opción correcta. Fije los pesos solo cuando el objetivo haya dejado de cambiar.

Muchos problemas que parecen requerir ajuste se resuelven con técnicas aplicadas al prompt:

• Cumplimiento del formato - salida estructurada y restricciones de esquema JSON, no entrenamiento
• Tono de dominio - un bloque de ejemplos de estilo más una descripción explícita de la voz
• Profundidad del razonamiento - descomposición, chain-of-thought o un paso de planificación
• Lagunas de conocimiento - la recuperación (RAG) incorpora hechos; el fine-tuning incorpora hechos obsoletos

Recurra al fine-tuning únicamente para aquello que el prompting no puede hacer de forma estructural: compresión del prompt cuando la latencia es crítica, formatos profundamente idiosincrásicos o comportamientos a los que el modelo se resiste incluso con instrucciones firmes.

Existe una confusión habitual: los equipos hacen fine-tuning para incorporar conocimiento cuando deberían recuperarlo. El fine-tuning no es una buena forma de enseñar hechos: es una técnica con pérdidas, costosa de actualizar y propensa a interpolar alucinaciones entre los ejemplos de entrenamiento.

Regla práctica: si la diferencia está en lo que el modelo sabe, use recuperación. Si está en cómo se comporta el modelo, considere el fine-tuning. El conocimiento cambia a diario; el comportamiento rara vez.

Antes de declarar que el prompting es insuficiente, recorra toda la escalera. La mayoría de los equipos se rinde en el segundo peldaño:

• Peldaño 1: instrucción clara + rol + contrato explícito de salida
• Peldaño 2: ejemplos few-shot que cubran los casos límite
• Peldaño 3: descomposición en varias llamadas encadenadas
• Peldaño 4: uso de herramientas y recuperación para delegar el conocimiento y el cálculo
• Peldaño 5: pasadas de autocrítica o de verificación

Solo después de agotar los peldaños 1-5 con un conjunto de evaluación reservado se puede justificar el fine-tuning.

Los prompts largos cuestan más que dinero: cuestan tiempo. En muchas arquitecturas de serving, los tokens de entrada dominan el tiempo hasta el primer token. Un prompt de 4.000 tokens con instrucciones y ejemplos tiene una sobrecarga de latencia medible en cada llamada.

Este es el único ámbito en el que el prompting realmente pierde a escala: cuando necesita tanto el comportamiento de un prompt largo como respuestas de menos de 100 ms, destilar ese comportamiento en un modelo pequeño ajustado es la opción correcta. Pero confirme que el presupuesto de latencia es real y no una suposición.

Decida en función del coste total de propiedad durante la vida útil del artefacto, no de la primera factura. Un checkpoint ajustado conlleva costes recurrentes ocultos:

• Volver a hacer fine-tuning cuando el proveedor retira el modelo base (a menudo cada 6-12 meses)
• Un pipeline de datos y un proceso de etiquetado que debe mantener activos
• Infraestructura de evaluación para detectar regresiones después de cada nuevo ajuste
• Complejidad de versionado, reversión y serving A/B

El TCO del prompting consiste principalmente en un archivo de texto y un conjunto de evaluación. Para equipos sin madurez en MLOps, esa asimetría por sí sola mantiene al prompting por delante mucho más tiempo de lo esperado.

El prompting es suficiente cuando puede responder SÍ a la mayoría de estas preguntas:

• ¿La especificación de la tarea sigue cambiando mes a mes?
• ¿El volumen está por debajo del umbral de punto de equilibrio que ha calculado?
• ¿La diferencia está en el conocimiento (que se puede recuperar) y no en el comportamiento?
• ¿Una evaluación con datos reservados demuestra que el prompting alcanza una calidad aceptable después de recorrer la escalera?
• ¿Su presupuesto de latencia admite la longitud del prompt?
• ¿Su equipo carece de un pipeline mantenido de fine-tuning y evaluación?

Tres o más respuestas SÍ significan que debe seguir con prompting y volver a evaluarlo solo cuando las respuestas cambien.

Exprese la decisión como datos, no como impresiones. Una pequeña función de puntuación obliga al equipo a declarar explícitamente sus supuestos (volumen, latencia y estabilidad de la especificación) y hace que la recomendación pueda auditarse más adelante.

El prompting es la opción predeterminada; el fine-tuning es la escalada. Manténgase en prompting mientras la especificación cambie, el volumen esté por debajo del punto de equilibrio y la diferencia corresponda al conocimiento en lugar del comportamiento.

• Compare los costes de iteración, inferencia y mantenimiento, no solo el dinero
• Calcule el punto de equilibrio por volumen antes de suponer que el fine-tuning ahorra dinero
• Recorra toda la escalera de optimización de prompts antes de declarar que el prompting es insuficiente
• Recupere el conocimiento; reserve el fine-tuning para comportamientos persistentes o para la compresión del prompt motivada por la latencia
• Evalúe el TCO durante toda la vida útil, incluida la retirada del modelo base