Ajuste fino, recuperación o un mejor prompt: cómo elegir

Un modelo no hace lo que se necesita. Hay tres técnicas sobre la mesa, y la decisión suele tomarse al revés: alguien elige primero el enfoque y después construye una justificación. El ajuste fino parece la opción más contundente, por lo que es la que se propone con mayor frecuencia y la que menos suele funcionar.

El orden fiable es el contrario. Diagnostique el fallo, y el propio fallo indicará la técnica.

Tres fallos, tres herramientas

Casi todas las quejas sobre el comportamiento de un modelo responden a una de estas tres causas.

Una carencia de conocimiento. El modelo desconoce algo: su catálogo de productos, el cambio de política de la semana pasada, el historial de pedidos de este cliente. No puede saberlo porque esa información no estaba en los datos de entrenamiento ni figura en el prompt.

Una carencia de comportamiento. El modelo sabe lo suficiente, pero responde de forma inadecuada: se extiende demasiado, emplea un tono incorrecto, omite una sección obligatoria, utiliza términos ajenos al sector o responde cuando debería negarse a hacerlo.

Una carencia de habilidad. El modelo ejecuta mal una tarea especializada incluso cuando dispone de la información adecuada y de instrucciones claras: una clasificación de dominio con límites sutiles, una notación formal poco común o un juicio que depende de convenciones escasamente representadas en la web pública.

Por qué el ajuste fino no resuelve las carencias de conocimiento

Este es el malentendido más trascendental en este ámbito, por lo que conviene ser precisos.

El ajuste fino modifica los pesos a partir de pares de ejemplos. Los datos contenidos en esos ejemplos adquieren, efectivamente, una mayor probabilidad de aparecer en la salida. Sin embargo, de ello no se desprende ninguna de las propiedades que se necesitan en un sistema de conocimiento:

• No se puede enumerar lo aprendido. No existe una consulta que devuelva qué datos se incorporaron.
• No se puede actualizar un solo dato. Corregir un único precio exige preparar un nuevo conjunto de datos y repetir el entrenamiento.
• El modelo no puede citar fuentes. Ofrece el dato sin una fuente rastreable, lo que resulta inservible en cualquier contexto regulado o auditable.
• No se pueden aplicar permisos. Un modelo entrenado con los datos de todos los clientes responderá sobre todos ellos a cualquier persona.
• Los errores expresados con seguridad empeoran, no mejoran. El ajuste fino con datos factuales tiende a aumentar la fluidez y la seguridad del modelo al hablar de un ámbito sin elevar proporcionalmente la precisión, la combinación menos útil posible.

La recuperación presenta el perfil inverso en todos estos aspectos. Si se cambia el documento, la siguiente respuesta cambia. Cada pasaje tiene un identificador. Los permisos se aplican como filtro antes de que el modelo vea información alguna.

Por qué se subestima el prompting

Los equipos suelen considerar el prompting una opción para principiantes que los sistemas serios terminan dejando atrás. En la práctica, una gran parte de los problemas de comportamiento se resuelve con él, porque la mayoría de los prompts deficientes fallan de las mismas tres maneras.

Sin ejemplos. Dos o tres demostraciones de la estructura de salida deseada valen más que varios párrafos dedicados a describirla. Muéstrela, no se limite a especificarla.

Sin estructura. Las instrucciones ocultas entre párrafos se siguen de manera irregular. Las secciones, las restricciones numeradas y un formato de salida explícito se respetan con mucha mayor fiabilidad.

Sin permiso para negarse a responder. Un prompt que nunca indica qué hacer cuando se desconoce la respuesta exige implícitamente que se dé una. Una sola frase —«si los documentos no contienen la respuesta, indíquelo y deténgase»— elimina toda una categoría de invenciones.

El prompting también posee una propiedad de la que carecen las otras dos opciones: es reversible en segundos. Mientras los requisitos sigan cambiando, eso vale más que cualquier mejora de eficiencia.

Su limitación real está en el coste y la consistencia. Un prompt de sistema de 2.000 tokens se factura en cada solicitud, y los conjuntos de instrucciones muy extensos se siguen de forma irregular. Cuando el comportamiento ya está definido y el volumen es elevado, trasladarlo a los pesos constituye la optimización correcta; pero se trata de una decisión de eficiencia que se toma una vez conocido el comportamiento, no de una forma de descubrir cuál debería ser.

Para qué sirve realmente el ajuste fino

Hay tres casos que lo justifican con claridad.

Consistencia de formato y estilo a gran escala. Cuando todas las respuestas deben seguir una estructura editorial y el prompting alcanza un 95 % de cumplimiento, entrenar con unos cientos de ejemplos coherentes puede elevar mucho esa cifra y, al mismo tiempo, eliminar los tokens de instrucciones de cada solicitud.

Adquisición de una habilidad específica. Una clasificación con límites de dominio sutiles, una notación interna o una convención editorial que no está representada en la web pública. Esta es la única de las tres técnicas que modifica lo que el modelo puede hacer, en lugar de lo que se le pide que haga.

Conseguir que un modelo pequeño sea suficiente. Este es el caso más interesante desde el punto de vista económico. Un modelo pequeño sometido a ajuste fino que iguale a un modelo de frontera en una tarea específica puede reducir considerablemente el coste y la latencia, y a menudo es el mecanismo que hace viable un despliegue con infraestructura propia.

Los métodos eficientes en el uso de parámetros —entrenar un adaptador pequeño en lugar de toda la red— han abaratado enormemente los tres casos, lo que altera el cálculo, pero no el diagnóstico. Una solución barata para el problema equivocado sigue siendo la solución equivocada.

Los costes que las estimaciones omiten

Preparación del conjunto de datos. Se necesitan desde varios cientos hasta unos pocos miles de ejemplos coherentes y correctos, lo que normalmente implica tareas de etiquetado. Los ejemplos contradictorios son peores que la ausencia de ejemplos: enseñan al modelo a ser incoherente.

Evaluación. Se necesita un conjunto de datos reservado y una forma de comparar el antes y el después; de lo contrario, no hay manera de saber si el modelo ajustado es mejor. Este es el paso que se omite con mayor frecuencia y el que permite detectar la diferencia.

La carrera continua del modelo base. Cada actualización del modelo base vuelve a plantear la cuestión: ¿se repite el entrenamiento con el nuevo modelo base o se conserva el anterior y se renuncia a la mejora? Este dilema reaparece indefinidamente y no existe con el prompting: basta con que llegue un modelo base mejor.

Riesgo de regresión. Entrenar para obtener un comportamiento puede deteriorar otros. Sin un conjunto amplio de evaluaciones, serán los usuarios quienes lo descubran.

El orden que funciona

1. Describa el fallo en una frase y clasifíquelo: conocimiento, comportamiento o habilidad.
2. Cree primero el conjunto de evaluación a partir de casos reales de fallo. Sin él, no se puede valorar ninguna de las tres opciones.
3. Corrija el prompt. Añada ejemplos, estructura y una forma explícita de negarse a responder. Mida los resultados.
4. Añada recuperación si el fallo es factual. Verifique la recuperación por separado de la generación.
5. Aplique ajuste fino solo si el comportamiento ya está definido y resulta caro incluirlo en el prompt, o si persiste una verdadera carencia de habilidad tras los pasos 3 y 4.

La mayoría de los equipos que siguen este orden se detienen en el paso 3 o 4. Eso no denota falta de ambición: es el resultado correcto, y los meses que no se dedican a construir un proceso de entrenamiento son el rédito de haber realizado primero el diagnóstico.