De Prompt Engineering a Fine-Tuning: El Playbook de Migración

Tienes un prompt de sistema que tomó semanas perfeccionar. Tiene 2,000 tokens de largo, lleno de ejemplos, instrucciones para casos extremos y reglas de formato. Funciona, en su mayoría. Pero es frágil, costoso e inconsistente de maneras que siguen costándote tiempo.

Este es el playbook para migrar ese prompt a un modelo ajustado. No teoría. No un pitch de ventas. Un proceso paso a paso que equipos en agencias y empresas de producto han usado para reducir costos un 60-80% mientras mejoran la consistencia de salida.

Señales de que Has Alcanzado el Techo del Prompt Engineering

Antes de invertir en fine-tuning, asegúrate de que realmente estás en el techo y no simplemente escribiendo malos prompts. Aquí están los indicadores concretos:

Tu prompt excede 2,000 tokens. Un prompt de sistema tan largo significa que estás codificando comportamiento a través de puro volumen de instrucción. Cada token cuesta dinero en tiempo de inferencia, y la atención del modelo a tus instrucciones se degrada a medida que la longitud del prompt aumenta. Si estás gastando $0.01-0.03 por solicitud solo en el prompt de sistema, eso es un problema estructural.

Pequeños cambios en el prompt rompen salidas no relacionadas. Arreglas el manejo del modelo para el caso extremo A, y de repente su formato en la tarea B se degrada. Esto es una señal de que tu prompt es un castillo de naipes: el modelo está interpretando las instrucciones holísticamente, y los cambios en una sección interactúan de forma impredecible con otras.

Las salidas varían entre ejecuciones idénticas. Envías la misma entrada con el mismo prompt, temperatura en 0, y obtienes salidas significativamente diferentes 15-25% del tiempo. El modelo está en una región de su espacio de salida donde pequeñas diferencias numéricas en la atención producen caminos diferentes. Más prompting no puede arreglar esto: el modelo necesita una señal de comportamiento más fuerte.

Estás codificando lógica condicional compleja en lenguaje natural. "Si la entrada contiene una fecha, formatea como ISO 8601 a menos que sea una fecha relativa como 'próximo martes' en cuyo caso convierte a fecha absoluta basada en la fecha actual, pero si la entrada también contiene una zona horaria..." Este tipo de lógica pertenece en código o en comportamiento aprendido, no en un prompt de sistema.

Has alcanzado un plateau de precisión. Dos semanas de iteración de prompts te llevaron del 75% al 82% de precisión. Otras dos semanas te llevaron al 84%. Ahora estás gastando días completos tratando de exprimir un solo punto porcentual. El modelo no tiene suficiente señal para ir más allá.

El Framework de Decisión de Migración

No todo prompt debería convertirse en un modelo ajustado. Aquí está el cálculo de ROI:

Costo mensual de API en la tarea. Si estás gastando más de $200/mes en una sola tarea a través de una API (incluyendo los costos inflados de tokens por prompts de sistema largos), el fine-tuning probablemente se pagará solo en 2-4 semanas. Un modelo 8B ajustado ejecutándose en una sola GPU cuesta aproximadamente $50-150/mes en cómputo, maneja la misma tarea sin prompt de sistema y a menudo produce mejores resultados.

El volumen importa. El fine-tuning tiene un costo fijo inicial: el tiempo para preparar datos y entrenar. A 100 solicitudes/día, esa inversión se amortiza en semanas. A 5 solicitudes/día, podría tomar meses. Por debajo de aproximadamente 50 solicitudes/día, quédate con prompt engineering a menos que la consistencia sea crítica para el negocio.

La estrechez de la tarea importa. El fine-tuning funciona mejor para tareas estrechas y bien definidas. "Clasifica emails de clientes en 12 categorías" es un candidato ideal. "Sé un asistente de propósito general que pueda hacer cualquier cosa" no lo es. Si tu prompt cubre una sola tarea con entradas y salidas claras, estás en territorio de fine-tuning.

El Proceso de Migración: Cinco Pasos

Paso 1: Documenta Tu Prompt Actual y el Comportamiento Esperado

Antes de cambiar nada, congela tu sistema actual. Documenta:

• El prompt de sistema exacto (versionalo en git)
• 50-100 entradas representativas con sus salidas reales
• Qué salidas consideras correctas, parcialmente correctas e incorrectas
• Los modos de falla específicos que estás tratando de arreglar

Esto se convierte en tu benchmark de evaluación. Compararás el modelo ajustado contra esta línea base, y necesitas datos honestos sobre cuán bien funciona realmente el sistema actual. La mayoría de equipos sobreestiman el rendimiento de su prompt hasta que lo miden.

Paso 2: Extrae Datos de Entrenamiento de Tu Prompt

Cada ejemplo en tu prompt de sistema es un ejemplo de entrenamiento esperando ser extraído. Un prompt de 2,000 tokens con 5 ejemplos few-shot ya contiene tus primeros 5 pares de entrenamiento. Pero la verdadera perspicacia es que tu prompt también contiene datos de entrenamiento implícitos:

• Cada instrucción ("siempre usa viñetas para listas") implica docenas de pares entrada-salida donde la salida usa viñetas
• Cada regla de caso extremo implica ejemplos de entrenamiento que ejercitan esa regla
• Cada requisito de formato implica ejemplos que demuestran el formato correcto

Recorre tu prompt línea por línea. Para cada instrucción, crea 10-20 pares entrada-salida que demuestren la instrucción siendo seguida correctamente. Si tu prompt tiene 15 instrucciones distintas, eso te da 150-300 ejemplos de entrenamiento solo decodificando el prompt.

Paso 3: Genera 1,000-2,000 Ejemplos Adicionales

Tus ejemplos extraídos del prompt son un comienzo, pero necesitas volumen. Aquí está el enfoque práctico:

1. Toma tu combinación existente de prompt + API que está funcionando actualmente
2. Genera 3,000-5,000 salidas a través de entradas diversas
3. Filtra agresivamente: quédate solo con las salidas que cumplen tu barra de calidad
4. Apunta a 1,000-2,000 pares de entrenamiento de alta calidad

Este paso típicamente toma unas horas de llamadas API y cuesta $20-50 dependiendo de la tarea. La clave es filtrar. No incluyas salidas mediocres en tus datos de entrenamiento. Si el sistema actual produce salida correcta el 80% del tiempo, filtra a ese 80% y descarta el resto.

Consejo profesional: Incluye entradas que cubran tus modos de falla conocidos. Si el sistema basado en prompt falla en formato de fechas el 30% del tiempo, genera muchos ejemplos de formato de fechas y corrige manualmente las salidas que la API obtuvo mal. Aquí es donde el modelo ajustado superará más claramente al prompt.

Paso 4: Ajusta un Modelo Más Pequeño

Con tus datos de entrenamiento en mano, el fine-tuning real es directo:

• Modelo base: Llama 3.1 8B o Qwen 2.5 7B son buenos puntos de partida para la mayoría de tareas. Son lo suficientemente pequeños para entrenar en una sola GPU y lo suficientemente poderosos para tareas estrechas.
• Método: LoRA con rank 16-32 para la mayoría de tareas. El fine-tuning completo raramente es necesario y aumenta el riesgo de sobreajuste.
• Entrenamiento: 2-4 epochs sobre tu dataset. Más epochs arriesga sobreajuste, especialmente con datasets más pequeños.
• Validación: Separa 10-15% de tus datos para validación. Monitorea curvas de pérdida para sobreajuste.

En Ertas Studio, todo este proceso toma 30-90 minutos dependiendo del tamaño del dataset y disponibilidad de GPU. Subes tus datos, seleccionas un modelo base, configuras parámetros de LoRA y entrenas. Sin setup de infraestructura, sin depuración de drivers CUDA.

Paso 5: Compara Calidad Rigurosamente

Ejecuta tu benchmark de evaluación del Paso 1 contra el modelo ajustado. Compara:

• Precisión: El modelo ajustado iguala o supera al sistema basado en prompt? En la mayoría de casos, lo superará por 5-15 puntos porcentuales porque ha visto 100x más ejemplos que los que caben en el prompt.
• Consistencia: Ejecuta cada entrada de prueba 5 veces. El modelo ajustado debería producir salidas casi idénticas. Los prompts a menudo varían; el comportamiento ajustado es más estable.
• Latencia: Sin un prompt de sistema de 2,000 tokens, el modelo ajustado procesa solicitudes más rápido. Espera 30-50% de reducción de latencia en un modelo más pequeño.
• Costo: Calcula el costo por solicitud. Un modelo 8B auto-alojado típicamente cuesta 1/10 a 1/50 de las llamadas API con prompts largos a un modelo frontera.

Si el modelo ajustado tiene bajo rendimiento en áreas específicas, agrega más ejemplos de entrenamiento apuntando a esas áreas y reentrena. El fine-tuning es iterativo, igual que el prompt engineering, pero las iteraciones se acumulan en vez de luchar entre sí.

Errores Comunes de Migración

Intentar ajustar un modelo general en vez de uno estrecho. Si tu prompt hace cinco tareas diferentes, no ajustes un solo modelo para las cinco. Entrena cinco adaptadores LoRA separados. Cada adaptador se mantiene pequeño, entrena rápido y sobresale en su tarea específica. En Ertas, puedes intercambiar adaptadores en tiempo de inferencia sin overhead.

No probar exhaustivamente antes de cambiar tráfico de producción. Ejecuta el modelo ajustado en modo sombra por al menos una semana: procesa entradas reales y compara salidas con el sistema actual sin servir los resultados a los usuarios. Detecta fallas antes que tus usuarios.

Saltarse el paso de calidad de datos. 500 ejemplos de entrenamiento de alta calidad superan a 5,000 mediocres. Dedica tiempo al filtrado y corrección. Si un ejemplo en tus datos de entrenamiento tiene un error de formato, el modelo aprenderá ese error.

Usar un rank de LoRA demasiado alto. Rank 64 o 128 suena mejor que rank 16, pero para tareas estrechas generalmente solo sobreajusta. Empieza bajo, evalúa y aumenta rank solo si el subajuste es el problema.

Comparación de Costos: Antes y Después

Aquí hay un escenario real de una agencia que migró una tarea de extracción de cláusulas de contrato:

El modelo ajustado costó $40 en cómputo para entrenar y se pagó solo en menos de dos días.

Cómo Ertas Hace de Esto un Proyecto de una Tarde

El playbook de migración anterior tiene cinco pasos. En Ertas Studio, la fricción de infraestructura se reduce a casi cero:

1. Sube tus datos de entrenamiento como JSONL — Ertas valida formato y señala problemas de calidad
2. Selecciona un modelo base del hub de modelos — Llama, Qwen, Mistral y otros están precargados
3. Configura y entrena — valores predeterminados sensatos para rank de LoRA, tasa de aprendizaje y epochs, con control total si lo deseas
4. Evalúa — evaluación incorporada contra tu conjunto de prueba con métricas de precisión, consistencia y latencia
5. Despliega — despliegue con un clic a Ertas Deploy, o exporta el adaptador para auto-alojamiento

Todo el proceso desde "tengo un prompt que quiero reemplazar" hasta "tengo un modelo ajustado desplegado" toma 2-4 horas para una tarea típica. El entrenamiento del modelo en sí son 30-90 minutos. El resto es preparación de datos, que es igual sin importar qué herramientas uses.

La parte difícil nunca fue la infraestructura. Fue saber cuándo hacer el cambio y cómo preparar los datos. Para eso es este playbook.

---

Lecturas relacionadas:

• Prompt Engineering Has a Ceiling. Here's What Comes After. — una mirada más profunda a por qué los prompts dejan de mejorar
• How to Fine-Tune an LLM: The Complete Guide — los detalles técnicos del proceso de fine-tuning
• Fine-Tune AI Without Code — usando la interfaz no-code de Ertas Studio para la migración