💬 NLP

Routesplain: Towards Faithful and Intervenable Routing for Software-related Tasks

Routesplain est le premier routeur de LLM interprétable pour les tâches liées au logiciel qui extrait des concepts compréhensibles par l'humain à partir des requêtes pour prendre des décisions de routage fidèles, surpassant à la fois les modèles individuels et les bases de référence de type boîte noire en termes de précision et de coût tout en permettant des interventions au niveau des concepts.

Auteurs originaux : Adam Štorek, Vikas Upadhyay, Marianne Menglin Liu, Daniel W. Peterson, Anshul Mittal, Sujeeth Bharadwaj, Fahad Shah, Sujith Ravi, Dan Roth

Publié 2026-08-11

📖 7 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Adam Štorek, Vikas Upadhyay, Marianne Menglin Liu, Daniel W. Peterson, Anshul Mittal, Sujeeth Bharadwaj, Fahad Shah, Sujith Ravi, Dan Roth

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous pénétrez dans une immense bibliothèque futuriste où des milliers de robots différents attendent de répondre à vos questions. Certains robots sont des génies brillants capables de résoudre des problèmes mathématiques complexes mais coûtent une fortune à embaucher. D'autres sont des travailleurs rapides et bon marché, excellents pour écrire des histoires simples, mais qui pourraient être confus face à des énigmes difficiles. Dans le monde de l'intelligence artificielle, ces robots sont appelés « Large Language Models » (LLM - Grands Modèles de Langage). Ils sont les moteurs derrière les chatbots et les assistants de code que nous utilisons aujourd'hui. Mais voici le piège : tous les robots ne sont pas bons pour tous les jobs. Parfois, vous n'avez pas besoin d'un génie ; vous avez juste besoin d'un travailleur rapide et abordable. La grande question que se posent les scientifiques est la suivante : comment savoir quel robot choisir pour le travail spécifique que vous avez, sans gaspiller d'argent ou obtenir une mauvaise réponse ?

C'est là qu'intervient l'idée du « routage ». Pensez au routage comme à un bibliothécaire intelligent qui écoute votre question, détermine exactement quel type d'aide vous avez besoin, puis vous oriente vers le robot parfait dans la bibliothèque. Pendant longtemps, ces bibliothécaires étaient des « boîtes noires ». Ils prenaient des décisions basées sur des mathématiques secrètes et compliquées que personne ne pouvait voir ou comprendre. Si le bibliothécaire vous envoyait vers le mauvais robot, vous n'aviez aucune idée de la raison, et vous ne pouviez pas vraiment le corriger. Ce nouveau papier présente un nouveau type de bibliothécaire qui est différent : il ne se contente pas de deviner ; il explique son raisonnement en langage clair avant de faire un choix.

Rencontrez Routesplain : Le Bibliothécaire qui Explique ses Choix

Les auteurs de ce papier, travaillant avec des chercheurs de l'Université de Columbia et d'Oracle AI, ont construit un nouveau système appelé Routesplain. Leur objectif était de résoudre un problème très spécifique : comment router les questions liées au logiciel (comme « corrige ce code cassé » ou « écris un programme en Python ») vers le meilleur modèle d'IA, tout en économisant de l'argent et en s'assurant que la réponse est réellement correcte.

Au lieu d'utiliser une boîte noire mystérieuse pour décider quelle IA utiliser, Routesplain agit comme un détective qui décompose chaque question en indices simples et compréhensibles. Ils appellent ces indices des « concepts ». Lorsque vous posez une question, Routesplain ne se contente pas de regarder les mots ; il se pose quelques questions spécifiques :

Quel est la tâche ? (Est-ce écrire du code, corriger un bug, ou répondre à une question scientifique ?)
Quel langage est impliqué ? (Est-ce du Python, du Rust, ou peut-être une langue naturelle spécifique comme l'espagnol ?)
Quelle est la difficulté ? (Est-ce une requête simple ou un puzzle super complexe ?)
Quel est le domaine ? (Est-ce lié aux réseaux, au temps, ou aux mathématiques générales ?)

Une fois que Routesplain a identifié ces concepts, il utilise une seconde étape pour décider quel modèle d'IA est le plus adapté. C'est comme dire : « Oh, c'est un problème de programmation Rust complexe, nous devrions donc l'envoyer au robot spécialiste du Rust, et non au généraliste bon marché. »

Pourquoi cela compte : Le problème de la « Boîte Noire »
Avant ce papier, la plupart des systèmes qui choisissaient des modèles d'IA étaient comme une boule de cristal magique. Vous posiez une question, et il donnait une réponse, mais vous ne pouviez pas voir la logique. Les auteurs soutiennent que cela est problématique car si le système fait une erreur, vous ne pouvez pas la corriger. Routesplain est différent car il est interprétable. Il vous montre les concepts qu'il a utilisés pour prendre sa décision. Si vous pensez que le système a mal compris la difficulté de la tâche, vous pouvez réellement intervenir et dire : « Attendez, ce n'est pas difficile, c'est facile », et le système changera instantanément d'avis et choisira un autre robot, moins cher. C'est ce qu'on appelle l'intervention, et c'est un changement radical car cela remet l'humain aux commandes.

Le Grand Test : 16 Robots, 8 Tâches
Pour voir si leur idée fonctionnait, les chercheurs ont mis en place un test massif. Ils ont rassemblé 16 des modèles d'IA les plus avancés disponibles (incluant des noms importants comme GPT-4.1, o3 et Llama 4) et les ont testés sur 8 types différents de tâches logicielles. Ces tâches allaient de l'écriture de code et la correction de programmes cassés à la réponse à des questions d'informatique dans 29 langues différentes.

Ils ont découvert quelque chose de surprenant : les différents modèles sont radicalement différents selon les tâches.

Certains modèles étaient incroyables pour corriger le code mais médiocres pour l'écrire.
Certains modèles étaient excellents en anglais mais peinaient avec des langues comme le hindi ou le wolof.
Certains modèles étaient super coûteux mais seulement légèrement meilleurs que les modèles bon marché pour des tâches simples.

À cause de ces différences, choisir simplement le modèle le plus « intelligent » pour tout était un gaspillage d'argent. Parfois, un modèle bon marché était en réalité le meilleur choix.

Les Résultats : Plus Intelligent et Moins Cher
Lorsqu'ils ont mis Routesplain à l'épreuve, il a fait quelque chose d'incroyable. Il a obtenu des performances égales aux systèmes de « boîte noire » les plus avancés (qui sont difficiles à comprendre), mais il était bien meilleur pour économiser de l'argent.

Précision : Routesplain a égalé la performance des meilleurs routeurs de type boîte noire.
Coût : En routant les questions vers le bon modèle, il a permis d'économiser beaucoup d'argent. Par exemple, il pouvait obtenir des réponses 8,5 points de pourcentage plus précises qu'en utilisant un seul modèle, tout en dépensant 39 % de moins.
Le Goulot d'Étranglement : Les chercheurs ont également utilisé leur système « explicable » pour découvrir où les choses coinçaient. Ils ont découvert que la plus grande erreur du système était de deviner la complexité d'une tâche. Si le système pensait qu'une tâche était facile alors qu'elle était en fait difficile, il choisissait un modèle bon marché et obtenait une mauvaise réponse. Cela indique aux futurs ingénieurs exactement ce qu'il faut corriger : rendre le « détecteur de complexité » plus intelligent.

La Conclusion
Le papier suggère que nous n'avons pas besoin de compter sur une IA mystérieuse et inexpliquable pour prendre des décisions. En décomposant les questions en concepts simples et lisibles par l'homme comme la « langue », le « domaine » et la « difficulté », nous pouvons construire des systèmes de routage qui sont non seulement précis, mais aussi équitables, transparents et modifiables.

Les auteurs démontent que nous pouvons avoir le beurre et l'argent du beurre : nous pouvons obtenir la haute performance des modèles d'IA les plus intelligents tout en payant le faible coût des modèles moins chers, le tout en sachant exactement pourquoi une décision a été prise. C'est comme avoir un bibliothécaire qui ne se contente pas de vous pointer un livre, mais qui vous dit : « Je vous ai choisi celui-ci parce que vous avez demandé un roman policier, et c'est le meilleur roman policier de la bibliothèque », et si vous dites : « Non, je veux en fait une romance », le bibliothécaire change instantanément le livre sans que vous ayez à quitter la pièce.

Résumé Technique : Routesplain

Problématique

Les modèles de langage de grande taille (LLM) sont de plus en plus déployés pour des tâches liées au logiciel, notamment la génération de code, la réparation, la prédiction d'entrées/sorties et le questionnement en informatique. Cependant, les performances varient considérablement selon les tâches, en fonction du modèle spécifique, du langage de programmation, du domaine et de la complexité de la requête. Bien que des travaux antérieurs aient exploré le routage pour les LLM polyvalents ou la complétion de code simple, les approches existantes reposent généralement sur des modèles « boîte noire » qui manquent d'interprétabilité. Cette opacité empêche les utilisateurs de comprendre pourquoi un modèle spécifique a été choisi ou d'intervenir dans la décision de routage. De plus, le potentiel d'optimisation de la précision et du coût via un routage granulaire à travers le paysage diversifié des requêtes logicielles reste sous-exploré.

Méthodologie : Routesplain

Les auteurs proposent Routesplain, un routeur de LLM interprétable conçu spécifiquement pour les tâches liées au logiciel. Contrairement aux routeurs boîte noire qui mappent directement les plongements (embeddings) de requêtes vers des sélections de modèles, Routesplain décompose la décision de routage en deux étapes entraînées indépendamment, basées sur des concepts interprétables par l'humain :

Extraction de Concepts : Un classificateur de concepts prend un plongement de requête contextualisé et le projette dans un espace de concepts. Les concepts sont des caractéristiques de haut niveau compréhensibles par l'humain, dérivées des métadonnées de benchmarks et des taux d'échec des modèles, incluant :
- Type de Tâche : (ex: complétion de code, réparation, QA).
- Domaine : (ex: calcul, réseau, système).
- Langage de Programmation : (ex: Python, Rust, Java).
- Langue Naturelle : La langue de la requête.
- Bibliothèques : Bibliothèques requises.
- Complexité : Trois mesures représentant la fraction de modèles (raisonnement, non-raisonnement et total) ayant échoué sur une entrée donnée.
Sélection de Modèle : Un classificateur de modèle distinct prend le vecteur de concepts prédit en entrée et produit des probabilités d'adéquation pour un ensemble de modèles candidats. Cette étape est entraînée avec un objectif de régularisation par le coût pour équilibrer la précision et le coût en tokens.

Caractéristiques Architecturales Clés :

Fidélité (Faithfulness) : Le raisonnement du routage est l'ensemble des concepts extraits, qui sont les caractches exactes utilisées pour la décision, évitant ainsi les explications post-hoc qui pourraient ne pas refléter le raisonnement réel.
Intervention : Parce que les concepts sont discrets et lisibles par l'humain, les utilisateurs peuvent modifier les valeurs des concepts au moment de l'inférence (ex: changer le langage de programmation prédit) pour observer les changements de routage sans réentraînement.
Transparence Diagnostique : En remplaçant les concepts prédits par des étiquettes de vérité terrain (ground-truth), le système peut isoler quels concepts constituent des goulots d'étrangle de performance.

Configuration de l'Évaluation

Les auteurs ont évalué Routesplain sur un ensemble de données de 38 685 exemples couvrant huit tâches liées au logiciel :

Datasets : BigCodeBench (Complete, Instruct, Repair, Repair+Info), CRUXEval (Input/Output), MMLU-ProX/Computer Science, et MultiPL-E.
Modèles : 16 LLM de pointe issus de familles incluant GPT-4.1/4o, Grok 3/4, la série o (o1, o3, o4), et Llama 3/4.
Baselines : Modèles individuels, un routeur MLP boîte noire, un routeur KNN, et EmbedLLM.

Résultats Clés

1. Performance et Efficacité des Coûts

Supériorité sur les Modèles Individuels : Routesplain surpasse systématiquement les 16 modèles individuels. Par exemple, à un coût 39,34 % inférieur à celui de GPT-4.1, Routesplain (avec une régularisation de coût $\lambda=0,1$ ) atteint une précision supérieure de 8,52 points de pourcentage (pp).
Comparaison avec les Baselines Boîte Noire : Routesplain égale ou surpasse la plus forte baseline boîte noire (routeur MLP) sur la plupart des niveaux de sensibilité au coût. Il y parvient tout en utilisant 15,54 % de paramètres en moins (462K contre 547K) et en fournissant une interprétabilité totale.
Compromis Coût-Précision : En ajustant le régularisateur de coût ( $\lambda$ ), Routesplain navigue efficacement sur la frontière de Pareto, déplaçant les affectations des modèles coûteux (ex: o3) vers des modèles de milieu de gamme (ex: GPT-4.1 mini) et des modèles à faible coût (ex: GPT-4.1 nano) à mesure que la sensibilité au coût augmente.

2. Analyse de Concepts et Ablation

Importance des Concepts : L'importance des concepts varie avec la sensibilité au coût. À une haute sensibilité au coût ( $\lambda=4,0$ ), les concepts de complexité ont l'impact le plus important sur les décisions de routage. Les distinctions de langage de programmation restent significatives à tous les niveaux de coût, reflétant des spécialisations distinctes des modèles.
Résultats d'Ablation : Le retrait des concepts de « complexité » durant l'entraînement provoque la baisse de précision la plus importante (jusqu'à -5,55 pp à haute sensibilité au coût), indiquant que distinguer les requêtes faciles des requêtes difficiles est critique pour un routage rentable.

3. Intervention et Identification des Goulots d'Étranglement

La Complexité comme Principal Goulot d'Étranglement : Les expériences contrefactuelles ont révélé que la prédiction de la complexité est le principal goulot d'étranglement pour la précision du routage. Remplacer les étiquettes de complexité prédites par des étiquettes oracle de vérité terrain a amélioré la précision du routage de 3,04 à 4,05 pp à tous les niveaux de coût.
Robustesse aux Autres Erreurs : Les erreurs de prédiction d'autres concepts (ex: langage de programmation, bibliothèques) n'ont pas dégradé significativement la performance lorsque les étiquettes de vérité terrain étaient substituées, suggérant que le classificateur de la seconde étape peut absorber ces erreurs.
Contrôlabilité : Modifier un seul concept (ex: langage de programmation) dans le vecteur d'entrée déplace de manière prévisible les probabilités de routage. Par exemple, changer le concept de langage pour PHP a augmenté la probabilité de sélection des meilleurs modèles PHP (série Llama) de 37,03 pp, validant la contrôlabilité du système.

Signification et Revendications

L'article affirme que Routesplain démontre que les décisions de routage pour les tâches logicielles peuvent être entièrement décomposées en concepts interprétables par l'humain sans sacrifier la performance par rapport aux alternatives boîte noire.

Rationales Fidèles : Il fournit des raisons intelligibles pour les décisions de routage (les concepts eux-mêmes) plutôt que des probabilités opaques.
Intervenable : Il permet des analyses « et si » (what-if) et la correction manuelle des décisions de routage lors de l'inférence.
Utilité Diagnostique : Il permet d'identifier des goulots d'étranglement de performance spécifiques (notamment la difficulté de prédire la complexité des requêtes) qui sont impossibles à isoler dans les routeurs boîte noire.
Variations Systématiques : Le travail souligne que la performance des LLM varie systématiquement non seulement selon les tâches, mais aussi au sein des tâches selon des caractéristiques de haut niveau comme le langage de programmation, la langue naturelle et le domaine, justifiant ainsi le besoin d'un routage basé sur les concepts.

Les auteurs concluent que, bien que l'approche nécessite des étiquettes de concepts pour l'entraînement et un réentraînement lorsque les pools de modèles changent, le coût de réentraînement est négligeable (environ une minute sur un seul GPU), rendant les avantages d'interprétabilité et de contrôle hautement pratiques pour les flux de travail de l'ingénierie logicielle.