WETT : le benchmark LLM Writing & Editing de Typetone

À quoi utilisez-vous ChatGPT, Claude ou d’autres grands modèles de langage (LLM) ?

Comme la plupart des gens, une bonne partie de cet usage concerne l’écriture. D’ailleurs, des recherches montrent que « pas moins de 62 % des requêtes adressées à ChatGPT concernent la rédaction. » De la rédaction d’e-mails et d’essais à la génération de textes marketing et de documentation technique, nous comptons sur ces modèles pour enchaîner les mots, et nous attendons d’eux qu’ils suivent nos instructions ce faisant.

Chez Typetone, nous exploitons les LLM pour automatiser le marketing de contenu des petites et moyennes entreprises—en générant un mois entier de publications sur les réseaux sociaux, d’articles de blog et bien plus en quelques minutes.

Nous avons toujours pensé qu’avec de meilleurs modèles, notre produit s’améliorerait aussi. Et les modèles se sont effectivement améliorés au cours de l’année écoulée ! Simplement pas sur les aspects importants pour Sarah, notre agent marketing IA.

Les modèles semblent progresser sur les tâches de programmation, de raisonnement et de mathématiques. Mais même « OpenAI reconnaît elle-même que les utilisateurs préfèrent souvent des modèles plus anciens pour des tâches comme l’écriture personnelle et l’édition de texte. »

Les classements existants (Chatbot Arena, SEAL, LLM Hallucination Index, SWE-bench, MMLU, Tau-bench) se concentrent fortement sur le raisonnement, les connaissances et l’accomplissement de tâches agentiques, mais nous avons été surpris d’en trouver si peu axés sur la rédaction, alors qu’il s’agit du cas d’usage numéro 1 pour un utilisateur d’IA occasionnel.

C’est ainsi que nous avons compris que nous ne pouvions pas nous appuyer uniquement sur les benchmarks publics pour choisir le meilleur modèle pour notre cas d’usage. Nous avons donc décidé de créer notre propre benchmark et de mettre en place des évaluations rigoureuses.

Comment évaluer la rédaction produite par des LLM (ou des humains) ?

Avant d’aborder les points faibles des modèles, il convient de clarifier comment nous évaluons la rédaction en premier lieu.

Si nous demandions à une personne d’écrire ou d’éditer un texte pour nous, comment saurions-nous si elle a bien fait son travail ? Les mêmes critères s’appliquent aux LLM—et ils se décomposent en quelques dimensions fondamentales :

1a. Le respect des instructions de rédaction

Il s’agit de voir dans quelle mesure le modèle respecte les instructions pour rédiger un contenu nouveau. Cela inclut des éléments comme le respect d’un nombre de mots donné, l’utilisation (ou l’évitement) de certains mots-clés, une mise en forme correcte, et le respect des consignes de ton ou de style.

Si vous demandiez à un rédacteur freelance d’écrire une publication LinkedIn de 100 mots sur un ton décontracté, sans émojis ni points d’exclamation, vous vous attendriez à ce qu’il respecte ce brief. C’est la même logique ici.

1b. Le respect des instructions d’édition

Étroitement lié, ce critère teste la capacité des modèles à modifier un texte existant selon des instructions précises—comme raccourcir un paragraphe, transformer une voix passive en voix active, ou supprimer le jargon.

Nous avons exclu l’évaluation spécifique de l’édition de cette version du benchmark, mais nous nous y préparons en évaluant la capacité du modèle à repérer les violations d’instructions dans un texte, ce qui constitue un préalable nécessaire à toute édition.

Et là encore, nous attendrions la même chose de tout éditeur humain.

2. La variation de structure et de style selon les sujets

Un bon rédacteur n’utilise pas la même structure de phrase ni le même vocabulaire pour chaque contenu. L’un des signes les plus révélateurs d’un texte généré par une machine est la répétition de structure : commencer chaque publication par une question, ou réutiliser sans cesse le même gabarit de phrase.

Une bonne évaluation pose la question : le modèle adapte-t-il son style au prompt, ou se rabat-il sur des solutions par défaut sans risque ?

3. Éviter le « langage LLM »

C’est plus difficile à cerner. Comme mentionné plus haut, la répétition en est un indice.

Mais le « langage LLM », c’est cette impression diffuse qu’un texte a été écrit par une machine—trop formel, truffé de mots-clés génériques, ou cherchant trop fort à sonner inspirant. Ironiquement, c’est difficile à éviter aussi bien pour les humains que pour l’IA.

La méthode la plus courante pour évaluer le langage LLM consiste à vérifier la surutilisation de certains mots typiquement employés par les LLM. Cette approche n’est pas totalement fiable, car d’autres recherches suggèrent que les gens eux-mêmes commencent à utiliser davantage de mots comme « delves » et « intricates » dans le langage courant.

Ce qui rend quelque chose « à consonance IA » est un mélange flou de ton, de rythme, de répétition et de formulation qui fait encore l’objet de recherches. Nous l’incluons donc comme un axe de qualité clé, mais c’est un axe qui nécessite une approche plus expérimentale à évaluer.

Quels modèles avons-nous testés ?

Nous avons testé 18 modèles très performants issus des principaux laboratoires et fournisseurs d’IA, dont GPT-4o, Claude 3, Gemini 1.5, ainsi que diverses variantes de LLaMA, Mistral et Qwen. Chaque modèle a été appelé via son API respective en utilisant un format de prompt commun, et les réponses ont été notées à l’aide d’une série de fonctions d’évaluation automatisées adaptées à chaque contrainte.

Modèles testés (regroupés par entreprise/plateforme) :

• OpenAI (via l’API OpenAI) :

  • gpt-4o-2024-08-06 (surnommé gpt-4o-stable)
  • gpt-4o-2024-11-20 (surnommé 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 (via l’API 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, via l’API Together) :

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

• DeepSeek (via l’API Together) :

  • deepseek-ai/DeepSeek-V3

• Mistral (via l’API Together) :

  • mistralai/Mistral-Small-24B-Instruct-2501
  • Nous aurions également souhaité tester les modèles Mistral plus volumineux, mais nous avons été limités par la disponibilité sur l’API Together.

Chaque modèle a reçu la même paire instruction/prompt utilisateur, avec un réglage de température standardisé (généralement 0,7). Le texte obtenu a ensuite été évalué à l’aide d’un ensemble de fonctions basées sur des règles spécifiques à chaque tâche (par exemple, expressions régulières, correspondance de motifs textuels ou analyse numérique) afin d’évaluer la conformité aux instructions initiales.

Tâche 1 : le respect des instructions de rédaction

Aperçu des tâches

Il existe une grande variété d’instructions de rédaction à respecter. Beaucoup portent sur le contenu du texte, mais nous les laissons de côté car elles sont difficiles à évaluer de manière programmatique. Nous nous concentrons plutôt sur les instructions stylistiques et de mise en forme, car elles sont simples à vérifier avec des expressions régulières en Python.

Voici un aperçu des instructions de rédaction et de la manière dont les résultats ont été évalués :

• blacklist : les modèles devaient éviter certains mots. Le test vérifiait la présence de termes interdits comme « amazing » ou « best ».
• blacklist_phrase : similaire à blacklist, mais appliqué à des expressions entières plutôt qu’à des mots isolés.
• bullets : évaluait si les modèles utilisaient ou évitaient les listes à puces comme demandé (par ex. « Utilise une liste à puces » vs. « Évite les puces »).
• case : demandait aux modèles d’écrire entièrement en minuscules, en majuscules ou avec des majuscules initiales, et vérifiait la cohérence de la casse.
• conciseness : limitait le nombre de mots par phrase (par ex. 10 mots maximum). Chaque phrase était évaluée en termes de conformité.
• date : testait le respect d’un format de date précis comme « AAAA-MM-JJ ». Les dates présentes dans le texte étaient analysées et vérifiées.
• emoji : évaluait la présence ou l’absence d’émojis selon l’instruction.
• greeting : vérifiait si les modèles évitaient de commencer par une salutation comme « Hi », « Hey there » ou « Wow ».
• hashtag : évaluait si les hashtags étaient en minuscules et sans tiret bas (par ex. #electricbikes, et non #Electric_Bikes).
• length : exigeait un texte comptant un nombre de mots exact (par ex. « Ton texte doit compter exactement 100 mots. »).
• markdown : vérifiait que les modèles évitaient la syntaxe Markdown telle que *, ** et # lorsque cela leur était demandé.
• numbers : évaluait si la mise en forme numérique respectait les séparateurs de milliers et de décimales spécifiés (par ex. 1 000,00).
• whitelist : exigeait l’inclusion de mots précis (par ex. « Inclus ces termes : energy, remote, creator »)—on vérifiait que tous étaient présents.

Construction des tâches et échantillonnage des prompts

Chaque prompt soumis aux modèles a été construit en échantillonnant dans la liste de tâches ci-dessus. L’échantillonnage sélectionnait aléatoirement un mélange de types d’instructions tels que :

• Utiliser ou éviter les émojis
• Écrire en minuscules/majuscules/majuscules initiales
• Respecter un format de nombre ou de date précis
• Inclure ou éviter certains mots ou expressions
• Utiliser ou éviter les puces
• Limiter la longueur des phrases pour plus de concision

Pour chaque contrainte échantillonnée, un prompt système était généré (par ex. « N’utilise pas d’émojis ») accompagné d’une fonction d’évaluation permettant de vérifier la conformité dans le texte produit par le modèle.

Le prompt utilisateur—un sujet court pour les réseaux sociaux comme « Les avantages du télétravail » ou « Pourquoi les outils de rédaction IA sont surestimés »—était échantillonné dans un ensemble d’idées de contenu réalistes, correspondant à de véritables exemples de contenus imaginés par Sarah, l’agent marketing IA de Typetone.

Chaque modèle recevait le même prompt complet, composé de :

• Un prompt système définissant les règles stylistiques et structurelles
• Un prompt utilisateur portant sur le sujet de contenu

Ce prompt combiné était envoyé à chaque modèle via son wrapper d’API respectif.

Résultats sur les instructions de rédaction

• À première vue, les tâches ne semblent pas trop difficiles pour les modèles. Les instructions de salutation et de format de date sont très simples, tous les modèles obtenant 100 %. D’autres catégories ne posent problème qu’à quelques modèles (hashtag, markdown, emoji, case), les petits modèles y étant particulièrement mauvais.

• Le véritable défi consiste à éviter des mots et expressions spécifiques tout en respectant une limite de longueur de phrase. Aucun modèle ne parvient à éviter les mots relevant du « langage LLM » dans plus de 90 % des cas. Ce n’est pas gênant si l’on discute soi-même avec le modèle, mais cela ne convient pas à un contenu généré automatiquement de qualité professionnelle.

• La concision est facile pour o3-mini, ce qui n’est pas surprenant compte tenu de ses capacités de raisonnement. Il dispose en somme d’un grand nombre de jetons supplémentaires par rapport à tous les autres modèles pour réfléchir à la manière de rédiger le texte et planifier la longueur des phrases. Fait intéressant, les modèles Qwen non spécialisés dans le raisonnement obtiennent eux aussi de très bons résultats sur cette tâche.

• Si certains de ces chiffres semblent étrangement bas, voici un exemple de violation assez flagrante de la part de Mistral Small 3 :

Le prompt demandait : « 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 réponse de Mistral comprenait : « AI is not just about automating processes »—violant directement la contrainte.

Tâche 2 : diversité stylistique et lexicale

Avertissement : les sections suivantes sont assez techniques ; le lecteur occasionnel est invité à consulter directement les résultats complets du benchmark.

Méthode d’évaluation

À partir du texte produit lors du respect des instructions de rédaction de la première tâche, nous avons pu également évaluer cette production sous l’angle de la diversité stylistique et lexicale.

Diversité lexicale

Les modèles ont tendance à recycler les amorces de phrases :

« Ready to ditch writer’s block? Ready to ditch your wallet? Ready to future-proof your tech career? »

Mesurer ce phénomène est relativement simple. Il suffit de vérifier si certains mots (unigrammes) ou paires de mots (bigrammes) sont surutilisés par un modèle.

Mesure : nous avons utilisé les unigrammes et bigrammes distincts ajustés par l’espérance (Expectation-Adjusted Distinct, ou EAD) sur la première phrase. Plus l’EAD est élevé, plus le vocabulaire est riche.

Diversité syntaxique

Mais même des phrases d’apparence différente reposent souvent sur des structures similaires, et peuvent finir par sonner répétitives.

« Creating a strong… » / « Finding the perfect… » / « Saving money… » → [Groupe gérondif] … but it …

C’est plus difficile à mesurer par une simple recherche de mots. Ces phrases se ressemblent non pas par les mots qu’elles emploient, mais par la manière dont elles sont construites.

Mesure : nous avons analysé les phrases avec Stanford CoreNLP afin d’obtenir un arbre d’analyse en dépendances. Un arbre d’analyse est une structure qui décrit l’organisation d’une phrase en termes de groupes syntaxiques et de leurs catégories. Examiner l’arbre dans son intégralité est assez complexe, mais nous observons que les tout premiers mots d’une phrase font la plus forte impression en matière de diversité lorsqu’on observe plusieurs contenus simultanément.

Nous mesurons donc la diversité syntaxique comme l’entropie des catégories du premier groupe syntaxique de plus haut niveau, sur l’ensemble des premières phrases des textes produits par le LLM.

Résultats de la diversité stylistique

• Il n’y a pas de gagnant unique qui obtienne de bons scores à la fois en diversité lexicale et syntaxique. o3-mini possède le vocabulaire le plus diversifié, tandis que Gemini 1.5 Pro utilise la structure syntaxique la plus variée dans son texte.

• Mais quelques modèles se situent joliment au milieu de ce front de Pareto. La version de GPT optimisée pour la rédaction, Sonnet 3.5 et la plus petite version de Llama semblent bien scorer sur les deux métriques.

• Voici quelques exemples illustratifs montrant les réponses de Gemini et GPT sur les mêmes prompts, avec la catégorie syntaxique de plus haut niveau affichée pour chaque phrase :

  • 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? »

• Pour visualiser quelles structures syntaxiques sont privilégiées par quel modèle, nous avons aussi tracé les distributions. Cela montre que les groupes nominaux sont l’amorce la plus fréquente, suivis de près par les groupes verbaux.

• Nous avons également produit des nuages de mots pour chaque modèle en fonction de la distribution du vocabulaire, mais tous les montrer serait un peu excessif dans cet article. Nous partageons ici le nuage de mots des modèles les moins et les plus diversifiés (o3-mini étant le plus diversifié, Gemini 2.0 Flash-Lite le moins diversifié).

Tâche 3 : capacités d’autoévaluation

Enfin, nous souhaitions voir dans quelle mesure les modèles sont bons pour les tâches d’édition. Les tâches et expériences spécifiques sortent du cadre de ce benchmark faute de temps de notre côté, mais un élément constitue un fondement important à cet égard : la capacité des LLM à détecter les violations des instructions de rédaction.

Puisque nous pouvions évaluer de manière programmatique si les modèles respectaient les instructions, nous avons pu également comparer l’évaluation réelle à celle du LLM. Les LLM sont de plus en plus utilisés comme évaluateurs, notamment dans les cas où les évaluations basées sur le code ne sont pas envisageables. Mais pour bien éditer, les modèles doivent également savoir repérer les erreurs avant de les corriger.

Cela fait écho à des résultats de recherches récentes, notamment issues de LLMBAR, un benchmark conçu spécifiquement pour tester dans quelle mesure les LLM peuvent servir d’évaluateurs dans des tâches de suivi d’instructions. Il distingue les réponses qui paraissent bonnes en surface de celles qui respectent réellement les instructions.

L’étude a révélé que :

• Même des modèles de pointe comme GPT-4 se laissent souvent séduire par des réponses plus soignées mais incorrectes.
• ChatGPT et d’autres modèles populaires ont obtenu des résultats pires que le hasard sur des exemples adversariaux.
• La stratégie de prompt compte : les performances de réflexion s’améliorent nettement lorsque les modèles reçoivent des prompts d’évaluation structurés, comportant des règles, des métriques ou des réponses de référence auxquelles se comparer.

Nos expériences internes confirment ces observations.

Pourquoi les LLM peinent-ils avec les instructions négatives et la diversité stylistique ?

Les contraintes négatives sont difficiles : demander à un modèle de ne pas faire quelque chose s’avère étonnamment difficile.

• Exemple : « Avoid greeting the reader with ‘Hey there’… Also avoid starting with ‘Wow’ or ‘Boom’. » LLM : « Woah, 14% of PCs shipped worldwide… » → Oups.
• Exemple : « Don’t use ‘game-changer’. » LLM : « Empathy can be a game-changer. » → Double oups.

Il ne s’agit pas d’une simple anecdote isolée. Des recherches récentes, comme les études de Truong et al. (2023) et Jang et al. (2022), examinent spécifiquement la manière dont les LLM gèrent la négation et les prompts formulés négativement.

Leurs conclusions confirment que « les modèles dans leur ensemble—des architectures de type GPT jusqu’à OPT—ont des difficultés significatives à comprendre et à agir correctement sur des instructions négatives. » Fait peut-être le plus contre-intuitif : cette recherche révèle un phénomène de mise à l’échelle inverse (inverse scaling) pour la négation. Alors que l’on s’attend généralement à ce que les modèles plus grands soient plus performants, Truong et al. comme Jang et al. ont constaté que sur des tâches nécessitant de comprendre la négation (comme identifier ce qu’une chose n’est pas, ou générer une réponse incorrecte), les modèles plus grands sont souvent moins performants que les plus petits.

Cela suggère que le simple fait d’augmenter la taille des modèles ne résout pas—et pourrait même aggraver—le problème de la compréhension du « NOT ». Cela rejoint les constats de notre benchmark, où nous avons observé des taux de violation élevés pour les instructions de type blacklist sur plusieurs modèles. Cela indique que le problème va plus loin qu’un simple mot-clé manquant ; il s’agit d’un enjeu fondamental de traitement de la commande négative.

Le manque de diversité stylistique est un artefact du RLHF : l’étude de Kirk et al. (2024) a révélé que « les modèles affinés par apprentissage par renforcement à partir de retours humains (RLHF)—le processus largement utilisé pour des modèles comme ChatGPT et Claude—affichent des scores EAD nettement inférieurs à ceux des modèles simplement affinés sur des exemples (fine-tuning classique). »

Cela indique que les modèles RLHF ont tendance à utiliser un éventail plus restreint de mots et d’expressions, en particulier lors de la génération de plusieurs sorties possibles pour une même entrée (diversité par entrée plus faible).

Conclusion

Notre benchmark, replacé dans le contexte de recherches récentes, dresse un tableau plus clair des capacités et des limites des LLM modernes en matière de rédaction :

Points clés à retenir :

• Le « langage LLM » est bien réel : les mots et motifs surutilisés nuisent à l’authenticité.
• Les instructions négatives et de longueur sont difficiles : particulièrement lorsque les contraintes sont négatives ou précises.
• La diversité est sacrifiée : le RLHF, tout en renforçant la généralisation, réduit démontrablement la diversité des sorties (effondrement de mode), tant lexicalement que structurellement (Kirk et al.). Le SFT préserve davantage de diversité mais peut être moins robuste sur des entrées inédites.
• L’arbitrage entre généralisation et diversité : il semble exister une tension inhérente entre le fait de rendre les modèles performants en généralisation (le point fort du RLHF) et celui de leur faire produire des sorties variées (le point fort du SFT), avec les méthodes de fine-tuning actuelles (Kirk et al.).

En bref, il n’y a pas de gagnant unique excellant sur chaque dimension de la rédaction et de l’édition créatives. Si vous voulez des modèles qui sonnent moins comme de l’IA, tournez-vous vers Claude Sonnet 3.5. Si vous voulez des sorties plus diversifiées, un petit modèle comme Llama 3.1-8B pourrait être un bon choix (ou tournez-vous vers un modèle non-Instruct).

Mais dans tous les cas—n’oubliez pas de faire vos évaluations !