Résumé Technique : Opti-Q : Un cadre d'optimisation basé sur des contraintes pour la planification de questions multi-LLM

1. Énoncé du Problème

Le déploiement des modèles de langage de grande taille (LLM) pour le Question Answering (QA) fait face à des défis importants concernant le non-déterminisme, l'hétérogénéité des profils de ressources (coût financier, latence, énergie) et la variation des performances selon les types de questions. Bien que des travaux récents suggèrent qu'une collaboration multi-LLM coordonnée peut surpasser les modèles uniques « optimaux », les stratégies d'exécution naïves (par exemple, interroger systématiquement tous les modèles ou utiliser des cascades fixes) entraînent souvent une utilisation inefficace des ressources, des coûts plus élevés et une qualité de réponse sous-optimale.

Les cadres d'orchestration actuels (ex. : LangChain, DSPy) reposent souvent sur des flux de travail scriptés par les développeurs ou sur des décisions dynamiques et myopes prises au moment de l'exécution sans considérer les conséquences en aval. Il manque des systèmes qui traitent l'orchestration multi-LLM comme un problème de planification de requêtes basé sur les coûts et multi-objectifs, où le plan d'exécution optimal (séquentiel, parallèle ou hybride) est sélectionné avant l'exécution en fonction des contraintes spécifiées par l'utilisateur (budget, latence, énergie) et de la qualité de réponse souhaitée (QoA).

2. Méthodologie : Le Cadre OPTI-Q

OPTI-Q est un optimiseur basé sur les coûts, inspiré des bases de données, qui implémente un paradigme de « planification avant exécution » pour le QA multi-LLM. Il modélise le problème comme une tâche d'optimisation multi-objectif (MOO) où le but est de trouver des plans Pareto-optimaux équilibrant la QoA par rapport au coût financier, à la latence et à l'énergie.

A. Modélisation et Formalisation

• Modèle de Question : Une question $Q$ est définie par un prompt, un sujet et des contraintes utilisateur ($F_{max}, L_{max}, E_{max}, QoA_{min}$) ainsi qu'un vecteur de poids $W$ pour la hiérarchisation des objectifs.
• Modèle de Plan : Les plans sont représentés par des graphes acycliques dirigés (DAG) où les nœuds sont des invocations de LLM (opérateurs physiques) et les arêtes représentent le flux de données.
  • Opérateurs Séquentiels : Transmettent les réponses intermédiaires comme contexte aux modèles suivants.
  • Opérateurs Parallèles : Exécutent plusieurs modèles simultanément.
  • Opérateurs de Mélange (Blending) : Fusionnent les sorties de branches parallèles en utilisant un modèle « mélangeur » dédié.
• Objectif d'Optimisation : Maximiser $[QoA(\pi), -Financier(\pi), -Latence(\pi), -Énergie(\pi)]$ sous réserve des contraintes de l'utilisateur.

B. Composants Clés

1. PERFDB (Catalogue de Statistiques) :

   • Une base de données de performance peuplée hors ligne et de manière incrémentielle à partir de benchmarks et de traces d'exécution.
   • Stocke les statistiques (QoA, coût, latence, énergie) pour les LLM individuels et les sous-plans composés, indexées par contexte d'exécution (sujet, type d'opérateur, modèle).
   • Permet une estimation pré-exécution des métriques du plan sans exécuter le plan. Il gère la stochasticité en stockant les estimations de variance et les intervalles de confiance.

2. Estimation Coût-Bénéfice :

   • Estimation des Tokens : Prédit le nombre de tokens d'entrée/sortie basé sur les tokeniseurs spécifiques aux modèles et sur les longueurs de sortie historiques pour estimer les coûts.
   • Estimation de la QoA : Utilise une recherche conditionnée par le sujet dans PERFDB. Pour les plans composés, il applique des facteurs d'effet relatif multiplicatifs (pour les étapes séquentielles) et des facteurs de changement relatif moyen (pour le mélange) dérivés des traces historiques afin d'estimer la qualité du plan complet.
   • Estimation des Ressources : Calcule le coût financier (fixe + variable par token), l'énergie (proportionnelle aux tokens) et la latence (linéaire avec le volume de tokens, les branches parallèles prenant le temps maximum).

3. Génération et Recherche de Plans :

   • Encodage : Les plans sont encodés de manière compacte comme une carte de connectivité (matrice d'adjacence) et un vecteur d'assignation de modèles.
   • Espace de Recherche : L'espace des plans possibles est combinatoire et NP-difficile à optimiser de manière exhaustive.
   • Moteurs d'Optimisation : OPTI-Q supporte un moteur « pluggable » avec trois stratégies :
     • Programmation Dynamique (DP) : Solveur exact pour les petites instances ; utilise l'élagage pour gérer l'explosion de l'espace d'états.
     • Hill Climbing (HC) : Heuristique de recherche locale légère et gourmande.
     • NSGA-II : Un algorithme évolutionnaire multi-objectif utilisé par défaut pour les grands espaces de plans afin d'approcher la frontière de Pareto.
   • Sélection : L'optimiseur génère un ensemble de plans réalisables non-dominés. Le plan final est sélectionné en fonction des poids de l'utilisateur $W$ appliqués aux objectifs normalisés.

C. Implémentation

• Système : Cadre modulaire intégrant un optimiseur avec un moteur d'exécution.
• Modèles : Testé avec cinq modèles open-source (Gemma-3:27B, LLaMA3-ChatQA, Qwen2.5, Phi-4, Mistral) tournant localement via Ollama.
• Mélange (Blending) : Utilise Gemma-3:27B comme le mélangeur désigné, surpassant les composants spécialisés comme GenFuser lors de la validation.
• Prompting : Emploie le Zero-Shot prompting avec des prompts de contexte et de mélange spécifiques pour guider le comportement des modèles.

3. Principales Contributions

1. Formalisation Coût/Bénéfice : Une formalisation de la planification de QA multi-LLM comme un problème d'optimisation multi-objectif contraint, équilibrant explicitement la QoA, le coût, la latence et l'énergie.
2. Optimiseur piloté par les Statistiques : Un système qui énumère et élague les flux de travail séquentiels/parallèles/hybrides, estimant la qualité et les coûts de ressources avant l'exécution grâce à un catalogue de statistiques historique (PERFDB).
3. Système Intégré : Un prototype fonctionnel qui route dynamiquement les questions à travers des LLM open-source, sélectionnant des graphes d'exécution optimaux en temps réel.

4. Résultats Expérimentaux

Le cadre a été évalué sur les benchmarks MMLU-Pro (choix multiples) et SimpleQA (questions ouvertes) contre quatre bases de référence de pointe (ThriftLLM, LLM-Ensemble, FrugalGPT, LLM-Blender).

• Gains de Performance : Sous des budgets spécifiés par l'utilisateur, OPTI-Q a amélioré la QoA moyenne d'environ 58 % sur SimpleQA et d'environ 41 % sur MMLU-Pro par rapport aux bases de référence les plus fortes à coût égal par question.
• Scalabilité : NSGA-II a fourni le meilleur compromis scalabilité-qualité, maintenant une qualité proche de la frontière de Pareto de référence avec des temps de planification de l'ordre de quelques dizaines de secondes (ex. : 21s pour $k=5$ opérations).
• Robustesse à la Rareté des Données : Dans les scénarios de « démarrage à froid » (couverture PERFDB de niveau 0), OPTI-Q a tout de même surpassé les bases de référence. À mesure que les données historiques augmentaient (niveaux 1 à 4), la QoA s'est considérablement améliorée (ex. : +66,7 % sur MMLU-Pro) et les erreurs d'estimation des ressources ont chuté drastiquement.
• Respect du Budget : Le système a maintenu un respect élevé du budget (88–96 %), les dépassements étant principalement dus au coût plutôt qu'à la latence.
• Comparaison avec les API Commerciales : OPTI-Q a obtenu une QoA supérieure aux modèles commerciaux (ex. : Claude Opus 4.6, GPT 5.4) sur SimpleQA tout en coûtant nettement moins cher (37,8× et 14,5× moins respectivement, en tenant compte des coûts de serveurs externes). Sur MMLU-Pro, il a obtenu une qualité compétitive (0,82 contre 0,871 pour Gemini 3.5 Flash) pour une fraction du coût.

5. Signification et Revendications

L'article affirme que la planification de type base de données produit de meilleurs compromis qualité-ressources pour le QA multi-LLM par rapport à une orchestration dynamique/myope ou des ensembles fixes.

• Changement de Paradigme : Il démontre que traiter l'orchestration de LLM comme un problème de planification déclarative, plutôt que comme une tâche de script procédural, permet une adaptation dynamique spécifique à chaque question qui maximise l'utilité sous contraintes.
• Viabilité Pratique : Les résultats suggèrent qu'une planification structurée, pilotée par les statistiques, fournit une base pratique pour l'orchestration adaptative de LLM, permettant de équilibrer performance et efficacité sans dépendre d'API commerciales coûteuses et hautement capables.
• Potentiel Futur : Les auteurs postulent que cette abstraction de « planification avant exécution » peut s'étendre au-delà du QA vers des flux de travail de génération augmentée par récupération (RAG) et d'agents plus riches, à condition que de nouveaux opérateurs puissent être caractérisés avec des profils coût-bénéfice similaires dans le catalogue de statistiques.