Llama 3 : l'écart se resserre sur les tâches structurées

Sur l'extraction, la classification et la reformulation, un modèle ouvert de taille moyenne fait désormais aussi bien qu'un modèle propriétaire ; sur le raisonnement long, l'écart demeure net. Cette dissociation est la donnée utile.

Les tâches structurées ont une caractéristique commune : la réponse attendue est courte, contrainte, vérifiable. Extraire une date, classer une demande dans l'une de six catégories, reformuler un paragraphe dans un registre donné. Il n'y a pas beaucoup de manières d'y répondre correctement.

Le raisonnement long est l'inverse : plusieurs étapes, des contraintes qui interagissent, un résultat difficile à vérifier automatiquement. C'est là que la différence de capacité se manifeste, et elle reste substantielle.

Les tâches structurées représentent l'essentiel du volume d'appels, et le raisonnement long l'essentiel de la valeur perçue. Les deux ne se traitent donc pas de la même façon, ni au même endroit.

Dans les systèmes que j'exploite, la répartition est stable : environ quatre-vingts pour cent des appels sont structurés, filtrage, classification, extraction, préparation, et vingt pour cent relèvent de l'analyse. Ces vingt pour cent portent la valeur visible, ces quatre-vingts portent la facture.

Basculer les tâches structurées sur un modèle ouvert hébergé ou sur une API à bas coût divise la facture sans que personne ne le remarque, précisément parce que ces appels sont invisibles pour l'utilisateur. C'est le levier décrit dans Mistral 7B et l'arbitrage par le routage, amplifié par la qualité désormais atteinte.

Un classement général ne dit rien de la performance sur votre tâche, et il est souvent optimisé par les fournisseurs eux-mêmes. C'est la raison pour laquelle le jeu de tests maison reste irremplaçable.

Deux problèmes se cumulent. D'une part, les jeux d'évaluation publics finissent par fuiter dans les données d'entraînement, ce qui gonfle mécaniquement les scores sans amélioration réelle. D'autre part, un score moyen sur des tâches variées ne prédit pas le comportement sur une tâche précise, dans un domaine précis, en français.

J'ai vu à plusieurs reprises un modèle mieux classé donner de moins bons résultats qu'un modèle moins bien classé sur un cas réel, typiquement parce que le premier était plus verbeux et respectait moins bien un format de sortie contraint.

La parade est toujours la même et elle coûte une demi-journée : trente cas réels par type de tâche, la réponse attendue, et la comparaison mesurée.

Le rattrapage sur les tâches structurées rend enfin crédible une architecture entièrement interne pour les données sensibles. C'est la conséquence la plus importante pour la santé, la défense et le secteur public.

Jusqu'ici, traiter en interne signifiait accepter une qualité nettement inférieure, ce qui condamnait la plupart des projets. Ce n'est plus le cas pour l'extraction documentaire, la classification de demandes ou l'anonymisation, qui constituent l'essentiel des besoins dans ces secteurs.

Le réglage recommandé reste mixte : traitement interne pour tout ce qui touche aux données protégées, recours à une API pour l'analyse complexe sur des contenus non sensibles ou préalablement anonymisés. Cette architecture demande une couche d'abstraction et une règle claire sur ce qui a le droit de sortir, mais elle est désormais réaliste, ce qu'elle n'était pas dix-huit mois plus tôt.

Reste une condition que la technique ne règle pas : quelqu'un doit exploiter le modèle interne au quotidien, surveiller sa disponibilité, appliquer les montées de version, diagnostiquer les ralentissements. Cette charge est réelle et permanente. Une organisation qui ne l'a pas provisionnée obtiendra un modèle hébergé pendant trois mois, puis un service dégradé que plus personne ne maintient.

Meta, Introducing Llama 3 · Meta, Llama 3 model card · Hugging Face, Open LLM Leaderboard