En casi todos los proyectos de inteligencia artificial llega un momento en el que alguien plantea la disyuntiva: ¿escribimos mejores instrucciones o entrenamos el modelo con nuestros datos? Es el dilema de ingeniería de prompts vs fine tuning, y se decide mal muy a menudo, casi siempre en la misma dirección: se elige entrenar cuando no hacía ninguna falta.
Este artículo no repite la explicación conceptual de cada técnica, sino que ofrece lo que suele faltar en la mesa: un marco para decidir. Seis preguntas, un orden de magnitud de coste y plazo para cada camino, y una advertencia sobre lo que cada opción te obliga a mantener durante años.
Las dos opciones, en una frase cada una
La ingeniería de prompts consiste en obtener el comportamiento que quieres del modelo mediante instrucciones, contexto, ejemplos y estructura, sin tocar el modelo. El fine tuning consiste en ajustar los pesos del modelo con un conjunto de ejemplos propios para que aprenda un patrón que no reproduce bien solo con instrucciones.
La diferencia práctica no está en la calidad, que en la mayoría de tareas empresariales es comparable. Está en el ciclo de vida. Un prompt se cambia en minutos y el efecto es inmediato. Un modelo ajustado se cambia reentrenando, con su preparación de datos, su validación y su despliegue. Esa asimetría es la que debería mandar en la decisión.
Seis preguntas para decidir antes de gastar
1. ¿Has agotado de verdad la ingeniería de prompts?
En la mayoría de casos en los que se pide fine tuning, el prompt de partida es una instrucción de tres líneas sin ejemplos, sin formato de salida definido y sin criterios de error. Antes de plantear entrenamiento, el listón mínimo es un prompt estructurado con rol, contexto, reglas explícitas, ejemplos representativos y un formato de salida verificable. Si eso no está hecho, la comparación no es honesta.
2. ¿El problema es de conocimiento o de comportamiento?
Si el modelo falla porque no conoce tus productos, tu normativa interna o tu histórico de casos, el fine tuning no es la solución: lo que necesitas es darle acceso a esa información en el momento de responder. Si falla porque no adopta un formato, un tono o una lógica de clasificación muy específica por más que se lo expliques, entonces sí estamos ante un problema de comportamiento, que es el terreno del ajuste.
3. ¿Tienes ejemplos suficientes y de calidad?
El fine tuning se alimenta de pares entrada-salida correctos. No de documentos sueltos. Para tareas de clasificación o extracción, el orden de magnitud razonable arranca en varios cientos de ejemplos bien etiquetados; para estilo y formato, a veces bastan menos, pero deben ser consistentes entre sí. Si tus ejemplos históricos son contradictorios —porque cada persona del equipo lo hacía a su manera—, el modelo aprenderá esa incoherencia.
4. ¿Con qué frecuencia cambian las reglas?
Este es el criterio que más veces zanja la discusión. Si tu catálogo, tus tarifas o tu normativa cambian cada trimestre, un modelo ajustado queda desactualizado y reentrenar se convierte en una tarea recurrente. Con prompts y acceso a datos, la actualización es editar una fuente.
5. ¿Cuánto volumen vas a procesar?
Un modelo ajustado más pequeño puede salir más barato por operación que un modelo grande con un prompt largo. Esa economía solo compensa a partir de volúmenes altos y sostenidos. Con unos miles de operaciones al mes, el ahorro por token no paga el proyecto de entrenamiento.
6. ¿Quién lo va a mantener dentro de dos años?
Si la respuesta es "una persona del equipo interno sin perfil técnico", los prompts y las bases de conocimiento son mantenibles y un pipeline de reentrenamiento no lo es.
¿Cuándo compensa realmente el fine tuning?
Compensa en un conjunto de escenarios bastante identificable. El primero es cuando necesitas un comportamiento muy específico y estable que el modelo base no reproduce por instrucciones: un formato propietario complejo, una taxonomía interna con cientos de categorías o un estilo de redacción muy marcado que debe salir idéntico miles de veces. El segundo es cuando el volumen es tan alto que el ahorro por operación al usar un modelo más pequeño y ajustado justifica el coste del entrenamiento y su mantenimiento. El tercero es cuando existen restricciones de latencia o de despliegue en infraestructura propia que obligan a trabajar con modelos compactos que, sin ajuste, no alcanzarían la calidad requerida. Fuera de esos tres escenarios, la experiencia dice que un buen trabajo de instrucciones combinado con acceso a los datos de la empresa llega igual de lejos, en semanas en lugar de meses.
¿Cuánto cuesta y cuánto tarda cada opción?
Los órdenes de magnitud, a modo orientativo y sin sustituir a un presupuesto real, son muy distintos. Un trabajo serio de ingeniería de prompts para un caso de uso concreto —diseño, batería de pruebas, iteración con casos reales y documentación— se mide en días o pocas semanas y en un coste de proyecto de miles de euros. Un fine tuning se mide en meses, porque el grueso del esfuerzo no es entrenar sino preparar y etiquetar el conjunto de datos, validar que el modelo ajustado no ha empeorado en casos que antes resolvía bien y montar el despliegue; el coste se sitúa fácilmente un orden de magnitud por encima. A eso hay que sumar el mantenimiento: los prompts se retocan sobre la marcha, el modelo ajustado exige reentrenamientos periódicos con su propio presupuesto anual.
La opción que resuelve la mayoría de casos: contexto, no entrenamiento
Cuando el problema es de conocimiento, la respuesta correcta no es ninguna de las dos del título, sino conectar el modelo a tus datos en el momento de responder: documentos, catálogo, histórico de casos, ERP o CRM. El modelo consulta la fuente y contesta con información actualizada, sin que nadie tenga que reentrenar nada cuando cambia un precio.
Esta arquitectura tiene tres ventajas que pesan mucho en un entorno empresarial. La información se actualiza editando el documento de origen. Las respuestas pueden citar la fuente, lo que permite auditarlas. Y la gestión de permisos se mantiene donde debe estar: en los sistemas que ya controlan quién ve qué.
Cómo se combinan en un proyecto real
Los proyectos que salen bien no eligen un bando, sino que aplican las técnicas en orden de coste creciente. Primero, ingeniería de prompts con una batería de casos de prueba que permita medir la calidad de forma objetiva. Después, acceso a datos propios para cubrir el conocimiento que falta. A continuación, refuerzo con ejemplos dentro del propio prompt para afinar los casos límite. Y solo si tras todo eso persiste un error sistemático medible se plantea el fine tuning, ya con un conjunto de datos que probablemente se ha ido construyendo durante las fases anteriores.
Ese orden tiene una virtud añadida: cada etapa deja algo utilizable en producción. La alternativa —empezar por el entrenamiento— tarda meses en dar la primera respuesta útil.
Cómo evitar la decisión mal tomada
Una señal de alarma clara en cualquier propuesta comercial: si un proveedor plantea entrenar un modelo con tus datos antes de haber medido el rendimiento del enfoque simple sobre casos reales de tu empresa, no está decidiendo con criterio técnico. La pregunta que conviene hacerle es concreta: qué tasa de acierto se obtiene hoy con instrucciones bien diseñadas y qué mejora esperada justifica el salto.
En MG Solutions arrancamos siempre por el camino más barato que resuelva el problema y solo escalamos en complejidad cuando los números lo piden. Si estás valorando un proyecto de IA y no tienes claro qué enfoque necesitas, escríbenos y lo analizamos con tus casos reales antes de que comprometas presupuesto.