La cortesía sí cambia la precisión de los LLM

Si tú trabajas con LLMs en producción, seguro ya viste algo raro: cambias una palabra en el prompt y el modelo responde distinto. A veces mejora, a veces empeora, y muchas veces no sabes si fue por el contenido, el formato o el tono. El estudio Prompt Politeness Affects LLM Accuracy pone el foco justo ahí: ¿ser cortés o brusco cambia la precisión?

La pregunta importa más de lo que parece. Si tu equipo evalúa calidad, diseña UX conversacional o monitorea agentes, el tono del prompt no es un detalle decorativo. Puede convertirse en una variable más de tu sistema, igual que la temperatura, el modelo o el contexto. Y si no la mides, puedes terminar atribuyendo a la “inteligencia” del modelo algo que en realidad viene del estilo de la instrucción.

Qué intenta medir el estudio

El trabajo parte de una idea simple: el lenguaje humano no solo transmite contenido, también transmite intención social. En prompts, eso se traduce en fórmulas como “por favor”, “gracias”, “podrías” o, al otro extremo, instrucciones secas y directas. El estudio prueba si ese tono cambia la exactitud del modelo en tareas evaluables.

Eso es útil porque mucha gente habla de prompt engineering como si fuera solo ordenar bien las instrucciones. Pero en la práctica, el prompt tiene varias capas: contenido, estructura, ejemplos, restricciones y tono. El paper separa una de esas capas para ver si la cortesía por sí sola mueve la aguja.

La señal que buscan no es anecdótica. Si una diferencia de tono altera la precisión en una fracción visible de casos, entonces el prompt deja de ser solo una interfaz y pasa a ser parte del comportamiento medible del sistema. Para equipos de producto, eso cambia cómo documentas prompts, cómo haces QA y cómo comparas versiones.

Por qué esto importa para producción

En producción, tú no evalúas un prompt en vacío. Lo haces con métricas, tráfico real, usuarios distintos y un costo por error. Si la cortesía afecta la precisión, entonces también afecta tu tasa de acierto, tu tasa de escalamiento humano y, en algunos casos, tu costo operativo.

Piensa en un agente de soporte que responde tickets. Si una versión del prompt usa un tono amable y otra usa instrucciones más secas, no solo cambia el estilo de respuesta. Puede cambiar cuántas respuestas correctas genera en casos de facturación, devoluciones o troubleshooting. En una operación con miles de interacciones al día, una variación pequeña sí suma.

Para un equipo en LatAm, esto además tiene una capa cultural. Tus usuarios no escriben igual en México, Colombia, Perú o Ecuador. Algunos se dirigen al sistema con cortesía explícita; otros van directo al punto. Si el tono del prompt también influye en la salida, entonces la experiencia conversacional puede variar según el tipo de usuario y el mercado.

Qué tipo de efecto encontraron y cómo leerlo

Aquí conviene ser precisos: el estudio no dice que decir “por favor” mágicamente vuelve al modelo más listo. Lo que sugiere es que el tono del prompt puede correlacionarse con cambios en precisión en ciertas tareas y configuraciones. Eso ya es suficiente para que dejes de tratar la cortesía como ruido irrelevante.

La lectura correcta no es “sé más amable y todo mejora”. La lectura correcta es “el tono es una variable experimental que puede alterar resultados”. Si tu benchmark compara dos prompts, uno con cortesía y otro sin ella, no estás midiendo solo estilo. Estás midiendo una mezcla de estilo, estructura y posible sesgo del modelo hacia patrones lingüísticos asociados con instrucciones más elaboradas.

En otras palabras: la cortesía puede funcionar como una señal indirecta de mayor especificidad, mejor organización o simplemente un patrón estadístico que el modelo aprendió durante el entrenamiento. El paper abre esa puerta y te obliga a pensar en diseño experimental, no solo en copy.

Lo que sí puedes inferir

Puedes inferir que el prompt no es neutro. Incluso cuando la semántica central no cambia, el envoltorio lingüístico puede modificar la respuesta. Eso afecta tanto a tareas cerradas como a flujos conversacionales más abiertos.

También puedes inferir que la evaluación de prompts necesita más control. Si comparas prompts, conviene fijar variables como longitud, estructura, ejemplos y tono. De lo contrario, una mejora aparente puede venir de un cambio de cortesía y no de una mejora real en la instrucción.

Y puedes inferir algo práctico para UX: el lenguaje que usas en la interfaz de un agente no solo cambia percepción, también puede cambiar rendimiento. Si tu producto permite que el usuario escriba con tono libre, deberías medir si ese tono impacta la calidad de las respuestas.

Qué significa para equipos de calidad, UX y agentes

Para QA, el hallazgo es una alerta metodológica. Cuando haces pruebas A/B de prompts, no basta con cambiar una frase y asumir que el efecto viene de la lógica. Necesitas controlar el tono porque puede actuar como confusor. Si no lo haces, tus métricas de exactitud, groundedness o task success pueden quedar contaminadas.

Para UX, el punto es más sutil. Hay productos que enseñan al usuario a “hablarle bien” al modelo con microcopy tipo “sé claro y cortés”. Eso puede ayudar a ordenar la petición, pero también puede introducir una expectativa falsa: que el sistema responde mejor por ser tratado con amabilidad. Si la experiencia se apoya demasiado en eso, luego te cuesta explicar por qué el desempeño cambia entre usuarios.

Para agentes en producción, la implicación es operativa. Tu prompt del sistema, tus templates y tus instrucciones internas deberían versionarse como código. Si cambias el tono, documenta el cambio igual que documentas una regla de negocio. En un agente de soporte, ventas o operaciones, esa diferencia puede mover el porcentaje de respuestas correctas o el número de handoffs a humano.

Señales que deberías monitorear

Si vas a probar este efecto en tu producto, mira estas señales:

1. Exactitud por tipo de prompt: compara prompts directos vs. corteses con la misma tarea.
2. Tasa de rechazo o de evasión: algunos tonos pueden empujar al modelo a responder más conservadoramente.
3. Longitud de respuesta: los tonos más elaborados pueden producir respuestas más largas, lo que no siempre implica mejor calidad.
4. Consistencia entre runs: si la variación sube mucho, el tono quizá está interactuando con la aleatoriedad del modelo.
5. Satisfacción del usuario: si el texto suena mejor pero resuelve peor, tienes un problema de UX, no de estilo.

Cómo probar esto en tu producto

Si tú lideras un equipo de IA, no necesitas montar un paper para empezar. Puedes correr un experimento pequeño y serio con tu propio flujo. La clave es aislar el tono como variable y medir resultados con un set de casos bien definido.

Un diseño básico podría verse así: mismo modelo, misma temperatura, mismo contexto, misma tarea, dos prompts que solo cambian en cortesía. Luego comparas la tasa de acierto en un conjunto de 100 a 500 casos. Si el efecto aparece, ya tienes una pista; si no aparece, también es útil, porque te dice que en tu caso el tono no pesa tanto como otras variables.

Un ejemplo simple de comparación:

Prompt A: Resume el siguiente ticket y devuelve la categoría correcta.
Prompt B: Por favor, resume el siguiente ticket y devuelve la categoría correcta. Gracias.

No te quedes solo con una corrida. Repite varias veces si el modelo es no determinista. Y si trabajas con un agente que usa herramientas, prueba también con y sin cortesía en el prompt del sistema y en el prompt del usuario. A veces el efecto aparece en una capa y no en otra.

Protocolo mínimo de evaluación

Te puede servir este orden:

1. Define una tarea cerrada, por ejemplo clasificación, extracción o respuesta múltiple.
2. Crea dos versiones del prompt que solo cambien el tono.
3. Fija modelo, temperatura, top_p y herramientas.
4. Ejecuta al menos 100 casos por variante.
5. Mide exactitud, tasa de error y longitud de respuesta.
6. Revisa ejemplos donde el tono cambió el resultado.
7. Decide si el cambio vale la pena en producción.

Ese protocolo no reemplaza una evaluación formal, pero sí te evita decisiones a ojo. Y si tu equipo trabaja con tráfico real en Ecuador o en otros mercados de la región, también te ayuda a separar preferencias culturales de rendimiento técnico.

Tabla de ejemplo para tu experimento

La tabla es un ejemplo de cómo presentar resultados, no un resultado del paper. Lo valioso aquí es el método: si el tono cambia y la estructura también, ya no sabes qué causó la mejora. Por eso conviene separar variables.

Límites del hallazgo y qué no deberías sobreinterpretar

El primer límite es obvio: un estudio sobre tono no significa que todos los modelos reaccionen igual. Los LLM cambian según arquitectura, entrenamiento, alineación y versión. Lo que ves en un modelo puede no repetirse en otro, y eso importa si tu stack mezcla proveedores.

El segundo límite es metodológico. La cortesía puede ser un proxy de otras cosas: prompts más largos, instrucciones más cuidadas o mayor formalidad. Si no controlas esos factores, puedes confundir estilo con precisión. Por eso no conviene sacar reglas absolutas tipo “los prompts amables siempre funcionan mejor”.

El tercer límite es de producto. Aunque encuentres una diferencia estadística, todavía tienes que decidir si vale la pena. Si un prompt cortés mejora 1% pero agrega latencia, complejidad o ruido en tu interfaz, quizá no compensa. En producción, la pregunta no es solo qué funciona, sino qué funciona mejor para tu caso.

Fuentes y documentación útil

Si quieres profundizar en cómo documentar y evaluar prompts, estas referencias te ayudan a aterrizar el tema:

• Paper en arXiv: https://arxiv.org/abs/2510.04950
• OpenAI API docs: https://platform.openai.com/docs
• Anthropic docs sobre prompting: https://docs.anthropic.com/

No necesitas copiar estas guías al pie de la letra, pero sí usarlas como base para tu propio estándar interno. Lo más útil es que tu equipo defina una convención estable para prompts, evaluación y versionado.

Tabla resumen

Si tú trabajas con LLMs, este paper te deja una idea clara: el prompt no es solo una instrucción, también es una señal. Y como toda señal, conviene medirla antes de asumir que no importa.