Ajuste fino, RAG o un prompt mejor: arreglan problemas distintos

Un cliente quería ajustar un modelo porque el asistente no conocía su catálogo de producto. Era la herramienta equivocada, elegida con aplomo, y habría costado un trimestre descubrirlo.

El ajuste fino no enseña hechos de forma fiable. Enseña comportamiento: cómo responder, en qué formato, con qué voz, siguiendo qué reglas implícitas. Los hechos que cambian pertenecen a la recuperación, porque un hecho ajustado queda congelado en el momento del entrenamiento y actualizarlo significa entrenar otra vez.

La pregunta de diagnóstico, por tanto, no es "¿deberíamos ajustar?" sino "¿qué tipo de cosa falta?".

Empareja el fallo con la técnica

El modelo no sabe algo. No puede responder sobre tus documentos, tus clientes, tu catálogo, ni sobre nada que ocurriera después del fin de sus datos de entrenamiento. Esto es recuperación. Las cuatro decisiones que importan están en RAG en tu propia nube, y ningún ajuste fino arregla un hueco de conocimiento que cambia cada semana.

El modelo sabe pero responde mal. Ignora tu formato, es demasiado verboso, no sigue de forma consistente un procedimiento de nueve pasos, usa el registro equivocado o se niega a cosas que debería atender. Esto es prompt primero, y ajuste fino si el prompt deja de escalar.

El modelo no puede hacer la tarea en absoluto. Falla en una clasificación especializada, una extracción específica de dominio, una lengua poco frecuente o una notación que apenas ha visto. Esto sí es territorio de ajuste fino, y es más raro de lo que se supone.

La salida está bien formada y es incorrecta. Calidad inconsistente, detalles alucinados, disparates ocasionales dichos con aplomo. Esto es un problema de evaluación y fundamentación, no de entrenamiento, y el enfoque está en evaluar una funcionalidad con LLM.

Agota el prompt primero, porque es casi gratis

El orden no es una postura moral, es económica. Un cambio de prompt se despliega en minutos y no cuesta nada. Un ajuste fino es un proyecto de datos.

Cosas que funcionan y se saltan con frecuencia: poner la estructura de la instrucción antes del contenido, dar entre cinco y diez ejemplos resueltos en el prompt, pedir un esquema de salida especificado y validarlo, partir una tarea compleja en dos llamadas en vez de una, y darle al modelo una forma explícita de decir que no lo sabe.

El uso de ejemplos en el prompt en particular cubre buena parte de aquello para lo que los equipos intentan ajustar. Si diez ejemplos en el prompt producen el comportamiento que quieres, ya tienes tu respuesta, y el único argumento a favor del ajuste es el coste de esos tokens en cada llamada.

Prueba también un modelo mejor antes de entrenar uno peor. La distancia entre niveles de modelo suele ser mayor que la que cerraría el ajuste fino, y cambiar es un cambio de configuración.

Qué compra de verdad el ajuste fino

Cuando el prompt ha llegado genuinamente a su techo, el ajuste fino compra tres cosas.

Consistencia. Un comportamiento que el prompt produce ocho de cada diez veces pasa a ser casi fiable. Para un flujo con un paso automático aguas abajo, esa diferencia es el producto.

Coste en tokens y latencia. Un comportamiento incorporado en los pesos no necesita un bloque de instrucciones de dos mil tokens en cada llamada. A volumen alto este es el argumento comercial más fuerte, y se compone con la aritmética de lo que cuesta de verdad una automatización por ejecución.

Capacidad de modelo pequeño. El patrón más valioso disponible: usa un modelo grande para producir salidas de alta calidad y después ajusta uno mucho más pequeño sobre ellas para la tarea estrecha. El modelo pequeño puede igualar al grande en esa tarea a una fracción del coste y la latencia. Esto es destilación, y para una tarea bien definida y de alto volumen suele ser la mejor decisión disponible.

Los métodos eficientes en parámetros lo hacen accesible. En vez de actualizar todos los pesos, entrenas un conjunto pequeño de pesos adaptadores, lo que recorta drásticamente el coste de entrenamiento y la memoria, produce artefactos de megabytes en vez de gigabytes, y te permite servir varios adaptadores sobre un mismo modelo base. Para casi cualquier caso de negocio esta es la forma correcta de ajuste fino.

El dato es el proyecto

Subestimar esto es el fallo estándar. El cómputo es la parte barata.

Necesitas ejemplos del comportamiento que quieres, en el formato que quieres, con la calidad que esperas. Normalmente de cientos a pocos miles para una tarea estrecha con métodos eficientes en parámetros. Tienen que ser consistentes, porque el modelo aprende tus inconsistencias con fidelidad, y un conjunto donde dos anotadores formatearon de manera distinta le enseña al modelo a ser arbitrario.

De dónde salen: registros de producción existentes con correcciones humanas, que es la mejor fuente; anotación experta, que es lenta y cara; o generación sintética desde un modelo mayor, que es rápida y exige revisión humana o estarás entrenando sobre los errores del modelo mayor.

Aparta un conjunto de prueba antes de empezar. Comprueba las condiciones del proveedor sobre usar salidas de modelo para entrenar, porque varían. Y si hay datos personales en los ejemplos, el conjunto de entrenamiento es dato personal con obligaciones de conservación y supresión asociadas, y es mucho más difícil borrar de los pesos de un modelo que de una base de datos, que es el punto donde el RGPD como controles de ingeniería se vuelve arquitectónico.

El coste de mantenimiento que nadie cotiza

Un modelo ajustado es una bifurcación de la que eres dueño para siempre.

Cuando el modelo base se retira o aparece uno mejor, tu versión ajustada no viaja con él. Reentrenas, reevalúas y vuelves a desplegar, y la mejora que perseguías puede estar ya en el modelo base nuevo gratis.

Cuando cambian tus requisitos, un prompt es una edición y un ajuste es otro ciclo de entrenamiento.

Y cada ajuste necesita su propio conjunto de evaluación y sus pruebas de regresión, porque ya no puedes apoyarte en las señales de calidad general del proveedor.

Presupuéstalo como ingeniería continua, no como un coste único. Para una tarea estable, estrecha y de alto volumen el intercambio merece claramente la pena. Para una funcionalidad que todavía busca su forma, es un compromiso adquirido demasiado pronto.

Un orden de decisión que aguanta

1. Mejor prompt, con ejemplos y un esquema de salida validado.
2. Un modelo más potente, medido en vez de supuesto.
3. Recuperación, si el hueco es de conocimiento. Y después mejorar la recuperación, porque la mayoría de los problemas de calidad de un RAG son fragmentación y reordenamiento.
4. Caché de prompts y un modelo más pequeño para el subconjunto fácil, si el problema es el coste.
5. Ajuste fino, idealmente como destilación a un modelo pequeño en una tarea estrecha.
6. Entrenar desde cero, que para casi cualquier empresa es nunca.

Párate en cuanto los números sean suficientemente buenos. El paso que te saltas es gratis.

Lo que se olvida

• El ajuste fino no elimina la necesidad de recuperación. Comportamiento ajustado más hechos recuperados es la forma habitual en producción.
• Puede empeorar el modelo en otras cosas. El entrenamiento estrecho degrada la capacidad general. Evalúa más allá de la tarea objetivo.
• El alojamiento de modelos propios difiere entre proveedores. Comprueba disponibilidad, región y precio antes de diseñar sobre ello, sobre todo si importa la residencia del dato.
• Versiónalo todo. Modelo base, adaptador, conjunto de entrenamiento y conjunto de evaluación son una sola entrega, y reproducir un resultado seis meses después necesita los cuatro.
• Mide antes y después sobre el mismo conjunto. Si no, no puedes saber si la mejora vino del ajuste o del prompt que también cambiaste.

Qué hacer esta semana

Coge el fallo que ibas a eliminar con ajuste fino y escribe diez ejemplos de la salida correcta dentro del prompt. Ejecuta tu conjunto de evaluación. Si lo arregla, te has ahorrado un trimestre. Si no, ya tienes las diez primeras filas del conjunto de entrenamiento que sí necesitabas. Recorremos este orden en un proyecto de IA aplicada.