Un classificateur de services basé sur un LLM passe de 73 % à 94 %, mais une chaîne de trois nœuds ne donne toujours que 75 %

Toute équipe ayant déployé un LLM en production connaît cette déception. Sur le jeu de test, le modèle affiche 98 %, et sur les données réelles, 73 %. L'auteur de l'analyse publiée sur Habr estime qu'en production, on atteint rarement une qualité de l'ensemble du système supérieure à 90 %. C'est donc ce chiffre qu'il faut viser. Certains projets, en raison du coût élevé de l'erreur, ne tiendront tout simplement pas.

La tâche : 50 classes et un référentiel

L'exemple est tiré d'un travail réel. À partir du nom d'un service, il faut choisir le code du formulaire 402. La classification est plate, avec 50 classes, et chaque type de service correspond à exactement un code. Par exemple, « 842 — Développement et installation de logiciels » ou « 7123 — Transport routier de marchandises ». La tâche semble simple, mais elle montre bien le comportement d'un seul nœud.

Le premier réflexe est d'ajouter des exceptions au prompt. Celui-ci gonfle, et trois problèmes apparaissent. Premièrement, le modèle peut « perdre » une partie d'un long contexte : l'information est dans l'entrée, mais pas dans la réponse. Deuxièmement, si un même prompt contient des dizaines de tâches différentes (par exemple, l'extraction de 50 attributs, avec un paragraphe entier de règles rien que pour le montant), une partie des règles est ignorée. Troisièmement, on obtient un équivalent du surapprentissage : on ajuste le prompt au même benchmark, et il apprend les exemples au lieu de la règle générale. L'équipe s'est arrêtée à 8 exemples et a obtenu 81 %.

Ce qui a réellement amélioré la qualité du nœud

L'auteur rejette la division naïve du référentiel en deux. On obtiendrait deux candidats, et il faudrait une troisième étape pour choisir un seul code. C'est une nouvelle source d'erreurs.

Ce qui a aidé, c'est l'analyse des logs et la discussion avec le métier. Il s'est avéré qu'un même document peut contenir plusieurs services. Le nœud précédent les enregistrait sur une seule ligne, et le LLM choisissait un seul code, tandis que les autres services étaient perdus. La correction : extraire les services sous forme de liste, soumettre chacun séparément avec le contexte nécessaire du document, puis rassembler le résultat avec un code pour chacun. La qualité est montée à 89 %. Le problème venait de la formulation de la tâche, pas du modèle.

L'étape suivante : les exemples dynamiques. À partir du benchmark annoté, on construit une table « vecteur du nom du service — classe ». Pour un nouveau service, on cherche les cas similaires et on les insère dans le prompt avec les bons codes. Résultat : 94 %. Impossible d'atteindre 100 % : la table est incomplète, et les vecteurs convergent parfois à tort, ce qui fait entrer des exemples inadaptés dans le prompt.

Les chaînes : la qualité se multiplie

L'idée principale de la seconde moitié de l'article : pour une chaîne d'appels, la qualité finale est le produit de la qualité des étapes. Exemple d'un centre de contact. La reformulation de la question fonctionne à 95 %, la recherche RAG dans la base de connaissances à 80 %, la réponse finale à 99 %. Total : 0,95 × 0,80 × 0,99 = 75 %. Le calcul n'est valable que sur un seul jeu de données fixe : on ne peut pas mesurer chaque maillon sur son propre jeu puis multiplier.

La tentation est compréhensible : ajouter une orchestration avec une liste d'exclusion des questions problématiques. Elle écarte effectivement une partie des cas, et le RAG fonctionne mieux sur le reste, disons à 89 %. Mais l'orchestrateur se trompe lui aussi, disons dans 5 % des cas. Résultat : 95 % × 95 % × 89 % × 99 % ≈ 79,5 %. Il y a un gain, mais modeste, et le système est devenu plus complexe. Il n'est pas devenu parfait : la chaîne a gagné une étape supplémentaire avec sa propre erreur.

Que faire en pratique

• Mesurez la qualité sur des données réalistes, et pas seulement sur le benchmark interne. Un écart entre 98 % et 73 % est un scénario typique.
• Avant de compliquer le prompt, examinez les logs et parlez au métier. Une part des « erreurs du modèle » se révélera être des erreurs de formulation de la tâche ou de l'étape précédente.
• Découpez la tâche selon le sens (un service, un appel), et non de façon mécanique.
• Calculez la chaîne à l'avance : trois étapes à 90 % donnent environ 73 %.
• Si le coût de l'erreur est élevé, intégrez un humain dans la boucle. Il ne faut pas attendre 100 % d'un système à base de LLM.

Limites

Les chiffres proviennent d'un seul cas de l'auteur, dans lequel il a modifié les données d'entrée en conservant le sens général. Il n'y a pas de vérification indépendante, et l'ampleur du gain de chaque technique dépend des données. Mais la logique est universelle : la qualité du système est déterminée par le maillon le plus faible et par le nombre d'étapes, et mieux vaut adopter d'emblée le repère de 90 %.