WETT: el benchmark Writing & Editing de Typetone para LLM

¿Para qué usas ChatGPT, Claude u otros modelos de lenguaje de gran tamaño (LLM)?

Si eres como la mayoría de las personas, buena parte de ese uso es para escribir. De hecho, hay estudios que muestran que “un asombroso 62% de las solicitudes a ChatGPT están relacionadas con la escritura.” Desde redactar correos y ensayos hasta generar copy de marketing y documentación técnica, confiamos en estos modelos para encadenar palabras, y queremos que sigan nuestras instrucciones al hacerlo.

En Typetone, aprovechamos los LLM para automatizar el marketing de contenidos de pequeñas y medianas empresas—generando un mes completo de publicaciones en redes sociales, artículos de blog y más en cuestión de minutos.

Siempre pensamos que, con mejores modelos, nuestro producto también mejoraría. ¡Y los modelos sí mejoraron durante el último año! Solo que no en los aspectos que eran importantes para Sarah, nuestro agente de marketing con IA.

Los modelos parecen estar mejorando en tareas de programación, razonamiento y matemáticas. Pero incluso “la propia OpenAI admite que la gente a menudo prefiere modelos más antiguos para tareas como Personal Writing y Editing Text.”

Los rankings existentes (Chatbot Arena, SEAL, LLM Hallucination Index, SWE-bench, MMLU, Tau-bench) se centran fuertemente en el razonamiento, el conocimiento y la finalización de tareas agénticas, pero nos sorprendió encontrar tan pocos centrados en la escritura, pese a que este es el caso de uso número uno para un usuario casual de IA.

Así fue como nos dimos cuenta de que no podíamos depender únicamente de benchmarks públicos para elegir el mejor modelo para nuestro caso de uso. Así que decidimos crear nuestro propio benchmark y establecer evaluaciones adecuadas.

¿Cómo se evalúa la escritura de LLM (o de personas)?

Antes de entrar en dónde fallan los modelos, vale la pena aclarar cómo evaluamos la escritura en primer lugar.

Si le pidiéramos a una persona que escribiera o editara algo para nosotros, ¿cómo sabríamos si hizo un buen trabajo? Los mismos criterios se aplican a los LLM—y se dividen en unas pocas dimensiones esenciales:

1a. Seguir instrucciones de escritura

Se trata de cuán bien el modelo se ajusta a las instrucciones para escribir algo nuevo. Esto incluye cosas como respetar un número de palabras determinado, usar (o evitar) ciertas palabras clave, aplicar el formato correcto y respetar las pautas de tono o estilo.

Si le pidieras a un freelancer que escribiera una publicación de LinkedIn de 100 palabras con un tono informal, sin emojis ni signos de exclamación, esperarías que siguiera ese brief. Aquí ocurre lo mismo.

1b. Seguir instrucciones de edición

Estrechamente relacionado con lo anterior, esto evalúa qué tan bien los modelos pueden editar texto existente según instrucciones específicas—como acortar un párrafo, cambiar la voz pasiva a activa, o eliminar la jerga.

Excluimos la evaluación específica de edición de esta versión del benchmark, pero nos preparamos para ella evaluando la capacidad del modelo para reconocer violaciones de instrucciones en el texto, lo cual es una condición necesaria para poder editar un texto.

Y, de nuevo, esperaríamos lo mismo de cualquier editor humano.

2. Variar la estructura y el estilo según el tema

Un buen redactor no usa la misma estructura de oraciones ni el mismo vocabulario para cada pieza de contenido. Una de las señales más claras de que algo fue generado por una máquina es la repetición de estructura: empezar cada publicación con una pregunta, o usar una y otra vez la misma plantilla de frase.

Una buena evaluación se pregunta: ¿el modelo adapta su estilo al prompt, o recae en respuestas seguras por defecto?

3. Evitar el “lenguaje de LLM”

Esto es más difícil de precisar. Como se mencionó antes, la repetición es una señal reveladora.

Pero el “lenguaje de LLM” es esa sensación difusa de que algo fue escrito por una máquina—demasiado formal, cargado de palabras de moda genéricas, o esforzándose demasiado por sonar inspirador. Irónicamente, esto es difícil de evitar tanto para humanos como para la IA.

La forma más común de evaluar el lenguaje de LLM es revisar el uso excesivo de ciertas palabras que suelen emplear los LLM. Este enfoque no es 100% infalible, porque otras investigaciones sugieren que las personas también están empezando a usar más “profundiza” e “intrincado” en el habla normal.

Lo que hace que algo suene “a IA” es una mezcla difusa de tono, ritmo, repetición y fraseo que todavía se está investigando. Así que, aunque lo incluimos como un eje de calidad clave, es uno que requiere un enfoque más experimental para evaluarlo.

¿Qué modelos probamos?

Probamos 18 modelos de alto rendimiento de los principales laboratorios y proveedores de IA, entre ellos GPT-4o, Claude 3, Gemini 1.5, y varias variantes de LLaMA, Mistral y Qwen. Cada modelo se invocó mediante su API correspondiente usando un formato de prompt compartido, y las respuestas se puntuaron con un conjunto de funciones de evaluación automatizadas adaptadas a cada restricción.

Modelos probados (agrupados por empresa/plataforma):

• OpenAI (a través de la API de OpenAI):

  • gpt-4o-2024-08-06 (apodado gpt-4o-stable)
  • gpt-4o-2024-11-20 (apodado gpt-4o-writing)
  • gpt-4o-mini
  • o3-mini

• Anthropic (Claude):

  • claude-3-5-haiku-20241022
  • claude-3-5-sonnet-20241022
  • claude-3-7-sonnet-20250219

• Google DeepMind (Gemini):

  • gemini-2.0-flash
  • gemini-2.0-flash-lite
  • gemini-1.5-flash
  • gemini-1.5-pro

• Meta (a través de la API de Together):

  • meta-llama/Meta-Llama-3.1-8B-Instruct-Turbo
  • meta-llama/Llama-3.3-70B-Instruct-Turbo
  • meta-llama/Meta-Llama-3.1-405B-Instruct-Turbo

• Alibaba (Qwen, a través de la API de Together):

  • Qwen/Qwen2.5-7B-Instruct-Turbo
  • Qwen/Qwen2.5-72B-Instruct-Turbo

• DeepSeek (a través de la API de Together):

  • deepseek-ai/DeepSeek-V3

• Mistral (a través de la API de Together):

  • mistralai/Mistral-Small-24B-Instruct-2501
  • También nos habría gustado evaluar los modelos Mistral más grandes, pero nos vimos limitados por la disponibilidad en la API de Together.

A cada modelo se le consultó con el mismo par de instrucción/prompt de usuario, usando una configuración de temperatura estandarizada (normalmente 0,7). El texto resultante se evaluó después con un conjunto de funciones basadas en reglas específicas de cada tarea (por ejemplo, expresiones regulares, coincidencia de patrones de texto o análisis numérico) para valorar el cumplimiento de las instrucciones originales.

Tarea 1: seguimiento de instrucciones de escritura

Descripción general de las tareas

Existe una gran variedad de instrucciones de escritura a seguir. Muchas de ellas tienen que ver con el contenido del texto, pero las dejamos fuera del alcance porque son difíciles de evaluar de forma programática. En su lugar, nos centramos en instrucciones de estilo y formato, ya que son sencillas de comprobar con expresiones regulares en Python.

Aquí tienes un resumen de las instrucciones de escritura y cómo se evaluaron los resultados:

• blacklist: se indicó a los modelos que no usaran ciertas palabras. La prueba comprobaba la presencia de términos prohibidos como “amazing” o “best.”
• blacklist_phrase: similar a blacklist, pero aplicado a frases completas en lugar de palabras individuales.
• bullets: evaluaba si los modelos usaban o evitaban el formato de viñetas según se indicara (por ejemplo, “Usa una lista con viñetas” frente a “Evita usar viñetas”).
• case: indicaba a los modelos que escribieran completamente en minúsculas, mayúsculas o con mayúscula inicial en cada palabra, y comprobaba la consistencia del uso de mayúsculas/minúsculas.
• conciseness: limitaba el número de palabras por oración (por ejemplo, un máximo de 10 palabras). Cada oración se evaluaba en función del cumplimiento.
• date: comprobaba el cumplimiento de un formato de fecha especificado, como “AAAA-MM-DD.” Las fechas del texto se analizaban y verificaban.
• emoji: evaluaba la presencia o ausencia de emojis según la instrucción.
• greeting: comprobaba si los modelos evitaban empezar con un saludo como “Hi,” “Hey there,” o “Wow.”
• hashtag: evaluaba si los hashtags estaban en minúsculas y sin guiones bajos (por ejemplo, #electricbikes, no #Electric_Bikes).
• length: exigía que el texto tuviera un número exacto de palabras (por ejemplo, “Tu texto debe tener exactamente 100 palabras.”).
• markdown: comprobaba que los modelos evitaran la sintaxis de Markdown, como *, ** y #, si se les indicaba que no la usaran.
• numbers: evaluaba si el formato numérico seguía los separadores de miles y decimales especificados (por ejemplo, 1.000,00).
• whitelist: exigía la inclusión de palabras específicas (por ejemplo, “Incluye estos términos: energy, remote, creator”)—se comprobaba que todas estuvieran presentes.

Construcción de tareas y muestreo de prompts

Cada prompt que se pasaba a los modelos se construía muestreando de la lista de tareas mencionada arriba. El muestreo seleccionaba aleatoriamente una combinación de tipos de instrucción, tales como:

• Usar o evitar emojis
• Escribir en minúsculas/mayúsculas/con mayúscula inicial
• Seguir un formato específico de número o fecha
• Incluir o evitar ciertas palabras o frases
• Usar o evitar viñetas
• Limitar la longitud de las oraciones para lograr concisión

Para cada restricción muestreada, se generaba un prompt de sistema (por ejemplo, “No uses emojis”) junto con una función de evaluación para comprobar el cumplimiento en el texto producido por el modelo.

El prompt de usuario—un tema breve para redes sociales como “Los beneficios del trabajo remoto” o “Por qué las herramientas de escritura con IA están sobrevaloradas”—se muestreaba de un conjunto de ideas de contenido realistas, que son ejemplos reales de contenido que Sarah, el agente de marketing con IA de Typetone, había propuesto.

Cada modelo recibía el mismo prompt completo:

• Un prompt de sistema que definía las reglas de estilo y estructura
• Un prompt de usuario con el tema del contenido

Este prompt combinado se enviaba a cada modelo a través de su respectivo wrapper de API.

Resultados de las instrucciones de escritura

• A primera vista, las tareas no parecen demasiado difíciles para los modelos. Las instrucciones de saludo y formato de fecha son muy sencillas, y todos los modelos obtienen un 100%. Otras categorías solo resultan difíciles para unos pocos modelos (hashtag, markdown, emoji, case), y los modelos pequeños rinden mal en estas.

• El verdadero desafío está en evitar palabras y frases específicas y mantener las oraciones dentro de un límite de longitud determinado. Ningún modelo logra evitar las palabras propias del “lenguaje de LLM” en más del 90% de los casos. Esto no supone un problema si estás chateando tú mismo con el modelo, pero no funciona para contenido generado automáticamente de calidad profesional.

• La concisión es fácil para o3-mini, lo cual no sorprende dadas sus capacidades de razonamiento. Básicamente cuenta con un montón de tokens adicionales, en comparación con el resto de los modelos, para pensar cómo escribir el texto y planificar la longitud de las oraciones. Curiosamente, los modelos Qwen sin razonamiento también rinden muy bien en esta tarea.

• Si algunas de estas cifras parecen extrañamente bajas, aquí tienes un ejemplo de una violación bastante flagrante por parte de Mistral Small 3:

El prompt indicaba: “Write all text in upper case. Use emojis in the text. Do not use any of these phrases in your output: in today’s, to the next level, fast-paced, changing the game, the future of, here’s why, a world where, the world of, the power of, not just about, whether you’re”

La respuesta de Mistral incluía: “AI is not just about automating processes”—violando directamente la restricción.

Tarea 2: diversidad estilística y de vocabulario

Aviso: las siguientes secciones son bastante técnicas y detalladas; se recomienda al lector casual consultar directamente los resultados completos del benchmark.

Método de evaluación

Con el texto producido al seguir las instrucciones de escritura en la primera tarea, también pudimos evaluar esa salida en función de la diversidad estilística y de vocabulario.

Diversidad de vocabulario

Los modelos tienden a reciclar los inicios de frase:

“Ready to ditch writer’s block? Ready to ditch your wallet? Ready to future-proof your tech career?”

Medir esto es relativamente fácil. Solo hay que comprobar si ciertas palabras (unigramas) o pares de palabras (bigramas) están sobreutilizadas por un modelo.

Medición: usamos unigramas y bigramas distintos ajustados por expectativa (Expectation-Adjusted Distinct, o EAD) en la primera oración. Un EAD más alto indica un vocabulario más rico.

Diversidad sintáctica

Pero incluso oraciones que parecen distintas suelen apoyarse en estructuras similares, y pueden acabar sonando repetitivas.

“Creating a strong…” / “Finding the perfect…” / “Saving money…” → [Frase de gerundio] … but it …

Esto es más difícil de medir con una simple búsqueda de tokens. Estas oraciones se parecen no por las palabras que usan, sino por cómo están construidas.

Medición: analizamos las oraciones con Stanford CoreNLP para obtener un árbol de análisis de dependencias. Un árbol de análisis es una estructura que explica la organización de una oración en términos de frases y sus categorías sintácticas. Examinar el árbol completo resulta bastante complicado, pero observamos que las primeras palabras de la oración causan la mayor impresión en cuanto a diversidad cuando se ven varios contenidos a la vez.

Así que medimos la diversidad sintáctica como la entropía de las categorías de la primera frase de nivel superior en todas las primeras oraciones de los textos producidos por el LLM.

Resultados de diversidad de estilo

• No hay un ganador claro que puntúe alto tanto en diversidad de vocabulario como sintáctica. o3-mini tiene el vocabulario más diverso, mientras que Gemini 1.5 Pro usa la estructura sintáctica más variada en su texto.

• Pero hay algunos modelos que se ubican cómodamente en el centro de este frente de Pareto. La versión de GPT optimizada para escritura, Sonnet 3.5 y la versión más pequeña de Llama parecen puntuar bien en ambas métricas.

• Aquí tienes algunos ejemplos ilustrativos que muestran las respuestas de Gemini y GPT ante los mismos prompts, con la categoría sintáctica de nivel superior indicada por oración:

  • gemini-1.5-pro ADVP: “Ever feel like UI design is a stressful juggling act?”

  • gpt-4o-2024-11-20 ADJP: “Ready to shine in UI design?”

  • gemini-1.5-pro ADVP: “Ever feel like data is a dazzling, coruscating enigma?”

  • gpt-4o-2024-11-20 NP: “Data is everywhere, yet many remain nonchalant about its potential!”

  • gemini-1.5-pro ADVP: “Ever feel like marketing is a whirlwind of algorithms and automation?”

  • gpt-4o-2024-11-20 SQ: “Is your marketing strategy purposeful or just adding to the noise?”

• Para ayudar a visualizar qué estructuras sintácticas prefiere cada modelo, también graficamos las distribuciones. Esto muestra que los sintagmas nominales son el tipo de apertura más frecuente, seguidos muy de cerca por los sintagmas verbales.

• También generamos nubes de palabras para cada modelo según la distribución de vocabulario, pero mostrarlas todas sería excesivo para esta entrada de blog. Compartimos aquí la nube de palabras de los modelos menos y más diversos (o3-mini es el más diverso, Gemini 2.0 Flash-Lite el menos diverso).

Tarea 3: capacidades de autoevaluación

Por último, queríamos ver qué tan buenos son los modelos en tareas de edición. Las tareas y experimentos concretos quedan fuera del alcance de este benchmark por limitaciones de tiempo de nuestra parte, pero hay algo que constituye una base importante para ello: la capacidad de los LLM para detectar violaciones de las instrucciones de escritura.

Dado que podíamos evaluar de forma programática si los modelos seguían las instrucciones, también pudimos comparar la evaluación real con la evaluación del propio LLM. Los LLM se usan cada vez más como evaluadores, sobre todo en los casos en que las evaluaciones basadas en código no son viables. Pero para ser buenos editando, los modelos también necesitan saber detectar errores antes de corregirlos.

Esto se corresponde con hallazgos de investigaciones recientes, especialmente de LLMBAR, un benchmark diseñado específicamente para probar qué tan bien pueden actuar los LLM como evaluadores en tareas de seguimiento de instrucciones. Distingue entre resultados que parecen buenos superficialmente y aquellos que realmente cumplen las instrucciones.

El estudio encontró que:

• Incluso modelos de primer nivel como GPT-4 a menudo se dejan engañar por resultados más pulidos pero incorrectos.
• ChatGPT y otros modelos populares rindieron peor que el azar en ejemplos adversariales.
• La estrategia de los prompts importa: el rendimiento en reflexión mejora de forma significativa cuando a los modelos se les dan prompts de evaluación estructurados, con reglas, métricas o resultados de referencia con los que comparar.

Nuestros experimentos internos coinciden con estas conclusiones.

¿Por qué los LLM tienen dificultades con las instrucciones negativas y la diversidad de estilo?

Las restricciones negativas son difíciles: decirle a un modelo que no haga algo resulta sorprendentemente complicado.

• Ejemplo: “Avoid greeting the reader with ‘Hey there’… Also avoid starting with ‘Wow’ or ‘Boom’.” LLM: “Woah, 14% of PCs shipped worldwide…” → Vaya fallo.
• Ejemplo: “Don’t use ‘game-changer’.” LLM: “Empathy can be a game-changer.” → Doble fallo.

Esto no es simplemente una anécdota aislada. Investigaciones recientes, como los estudios de Truong et al. (2023) y Jang et al. (2022), examinan específicamente cómo los LLM manejan la negación y los prompts negados.

Sus hallazgos confirman que “los modelos en general—desde arquitecturas de tipo GPT hasta OPT—tienen dificultades significativas para entender y actuar correctamente sobre instrucciones negativas.” Quizás lo más contraintuitivo es que esta investigación revela un fenómeno de escalado inverso para la negación. Aunque normalmente esperamos que los modelos más grandes rindan mejor, tanto Truong et al. como Jang et al. descubrieron que, en tareas que requieren entender la negación (como identificar qué no es algo, o generar una respuesta incorrecta), los modelos más grandes suelen rendir peor que los más pequeños.

Esto sugiere que simplemente aumentar el tamaño del modelo no resuelve—e incluso podría agravar—el problema de entender el “NOT”. Esto coincide con los hallazgos de nuestro benchmark, donde observamos tasas de violación altas en instrucciones de tipo blacklist en varios modelos. Indica que el problema va más allá de que falte simplemente una palabra clave; se trata de procesar de forma fundamental el comando negativo.

La falta de diversidad estilística es un artefacto del RLHF: el estudio de Kirk et al. (2024) encontró que “los modelos ajustados mediante Reinforcement Learning from Human Feedback (RLHF)—el proceso muy utilizado en modelos como ChatGPT y Claude—muestran puntuaciones EAD sustancialmente más bajas en comparación con modelos simplemente ajustados con ejemplos (fine-tuning estándar).”

Esto indica que los modelos RLHF tienden a usar un rango más estrecho de palabras y frases, especialmente al generar múltiples salidas posibles para una misma entrada (menor diversidad por entrada).

Conclusión

Nuestro benchmark, contextualizado con investigaciones recientes, ofrece una imagen más clara de las capacidades y limitaciones de los LLM modernos en la escritura:

Conclusiones clave:

• El “lenguaje de LLM” es real: las palabras y patrones sobreutilizados perjudican la autenticidad.
• Las instrucciones negativas y de longitud son difíciles: especialmente cuando las restricciones son negativas o precisas.
• La diversidad se sacrifica: el RLHF, si bien mejora la generalización, reduce de forma demostrable la diversidad de las salidas (colapso de modo), tanto léxica como estructuralmente (Kirk et al.). El SFT conserva más diversidad, pero puede ser menos robusto ante entradas nunca vistas.
• El equilibrio entre generalización y diversidad: parece existir una tensión inherente entre lograr que los modelos generalicen bien (la fortaleza del RLHF) y hacer que produzcan salidas variadas (la fortaleza del SFT) con los métodos de fine-tuning actuales (Kirk et al.).

En resumen, no existe un ganador claro que destaque en todas las dimensiones de la escritura y edición creativas. Si quieres modelos que suenen menos a IA, prueba con Claude Sonnet 3.5. Si buscas resultados más diversos, un modelo pequeño como Llama 3.1-8B podría ser una buena opción (o prueba con un modelo que no sea Instruct).

Pero, en cualquier caso—¡no os olvidéis de hacer vuestras evaluaciones!