Diseño de ejemplos eficaces

En los prompts few-shot, sus demostraciones son el conjunto de entrenamiento, aunque se proporcionen durante la inferencia. Todas las propiedades relevantes de los datos para fine-tuning también se aplican aquí: representatividad, cobertura, exactitud de las etiquetas, diversidad y ausencia de filtraciones.

Los ejemplos deficientes enseñan un comportamiento deficiente. El modelo imitará fielmente las expresiones de cautela, la verbosidad, el formato incoherente y los errores sutiles de razonamiento presentes en sus demostraciones.

Elija demostraciones cuya distribución de entradas coincida con el tráfico de producción. Un conjunto de demostraciones impecables, cortas y fáciles fallará ante las entradas desordenadas, largas y ambiguas que realmente envían sus usuarios.

Muestree registros reales, agrúpelos en clústeres y seleccione un ejemplo representativo por clúster. Así cubrirá mucho mejor los modos de su distribución que seleccionando manualmente ejemplos llamativos pero atípicos.

Además de las entradas típicas, incluya deliberadamente casos límite en los que el modelo se equivoque: negaciones, entradas multietiqueta, sarcasmo, unidades y respuestas nulas. Una sola demostración que muestre el tratamiento correcto de un rechazo explícito o de un resultado vacío enseña un comportamiento que las instrucciones en prosa rara vez consiguen asegurar.

Mantenga un conjunto actualizado de casos fallidos recopilados en producción e incorpore periódicamente al prompt los más instructivos.

Todas las demostraciones deben utilizar un formato idéntico: los mismos delimitadores, el mismo orden de las claves, el mismo uso de mayúsculas y minúsculas, los mismos espacios en blanco y el mismo estilo de razonamiento. El modelo presta atención a las regularidades superficiales; cualquier incoherencia se convierte en ruido que podría reproducir de forma impredecible.

Pase un linter a sus ejemplos de forma programática. Si las salidas son JSON, valide cada una con el esquema antes de incorporarla a un prompt.

Las demostraciones redundantes desperdician contexto y amplifican cualquier sesgo que compartan. Maximice la información por token seleccionando un subconjunto diverso, por ejemplo mediante Maximal Marginal Relevance, que equilibra la relevancia con la disimilitud respecto a los ejemplos ya seleccionados.

La diversidad debe abarcar las dimensiones relevantes para su tarea, no solo la forma léxica superficial.

En las tareas de razonamiento, la salida de la demostración debe modelar la trayectoria exacta de pensamiento que desea: concisa, correcta y con la misma estructura en todo momento. Si una demostración razona en tres pasos y otra en siete, el modelo no aprende una política estable.

Prefiera un razonamiento conciso y verificable a una explicación prolija; las justificaciones largas de las demostraciones aumentan el coste y pueden enseñar divagaciones.

Las demostraciones pueden filtrar señales espurias. Si todos los ejemplos positivos resultan ser largos y todos los negativos, cortos, el modelo aprende la longitud, no el sentimiento. Audite sus demostraciones para detectar correlaciones accidentales entre características superficiales y etiquetas.

Evite también filtrar la respuesta mediante la formulación de la entrada (por ejemplo, una demostración cuya entrada ya contenga la etiqueta objetivo como palabra).

Combine distintos niveles de dificultad para que el modelo vea correspondencias fáciles y difíciles, pero controle la longitud de los ejemplos. Las demostraciones muy largas desplazan la consulta actual y pueden provocar el efecto lost-in-the-middle, en el que se presta menos atención al contexto central.

Agrupe las demostraciones por longitud y procure formar un conjunto equilibrado y compacto que cubra al mismo tiempo todo el rango de dificultad.

Para definir los límites, incluya demostraciones de lo que el modelo no debe hacer, emparejadas con la respuesta correcta. Muestre una solicitud que deba rechazarse o una entrada fuera de alcance que produzca una respuesta nula adecuada.

Estas demostraciones negativas suelen ser los ejemplos con mayor impacto para la seguridad, el control del alcance y la gestión estructurada de valores nulos.

Los conjuntos de demostraciones son artefactos que deben tener control de versiones y someterse a pruebas de regresión. Cuando sustituya un ejemplo, vuelva a ejecutar el marco de evaluación; un solo ejemplo incorrecto puede reducir la precisión varios puntos o cambiar el formato de salida.

Etiquete cada implementación de prompt con el hash de su conjunto de demostraciones para poder atribuir los cambios de calidad y revertirlos con precisión.

En conjunto, el proceso consiste en recopilar entradas reales, etiquetarlas cuidadosamente, agruparlas para cubrir la distribución, aplicar MMR para obtener diversidad, equilibrar la longitud, verificar el formato con un linter, auditar los atajos y, por último, validar el resultado en un conjunto reservado antes de ponerlo en producción.

Este proceso convierte el diseño de ejemplos, que antes dependía de la intuición, en un procedimiento de ingeniería reproducible.

Aplique los principios de diseño de ejemplos a un modo de fallo sutil.

Conclusiones principales:

• Las demostraciones son datos de entrenamiento durante la inferencia; selecciónelas con el rigor propio de un conjunto de datos.
• Haga coincidir la distribución de entradas de producción mediante la agrupación y cubra deliberadamente los casos límite difíciles.
• Exija una estricta coherencia de formato y analice las salidas con un linter según un esquema.
• Maximice la diversidad por token mediante MMR y equilibre la dificultad y la longitud.
• Audite los atajos espurios y las filtraciones, incluya demostraciones negativas y de rechazo, y versionе cada conjunto de demostraciones.