Résumé technique : FusionFactory : Fusionner les capacités des LLM avec des données de logs multi-LLM

Problématique

La diversification rapide des modèles de langage (LLM) a conduit à un paysage où différents modèles excellent dans des tâches distinctes (par exemple, la génération de code versus la récupération factuelle). Par conséquent, les praticiens emploient de plus en plus de multiples LLM dans leurs flux de travail, générant ainsi des données de logs multi-LLM précieuses. Ces données consistent en des enregistrements de service structurés contenant des paires requête-réponse alignées provenant de plusieurs modèles, accompagnées de métadonnées telles que l'identité du modèle, le mode de réponse (direct ou augmenté par le raisonnement), le coût d'inférence et le retour sur la qualité.

Malgré la disponibilité de ces données, les méthodes existantes pour intégrer plusieurs LLM ne traitent généralement qu'une seule étape du pipeline de manière isolée :

1. Au niveau de la requête (Query-level) : Les méthodes de routage sélectionnent le meilleur modèle pour une requête spécifique, mais ne fusionnent pas les capacités au-delà de la sélection.
2. Au niveau de la pensée (Thought-level) : Les stratégies de prompting agrègent le raisonnement, mais manquent souvent d'une évaluation systématique par rapport aux autres étapes de fusion.
3. Au niveau du modèle (Model-level) : La distillation et la fusion de modèles transfèrent les connaissances dans un seul modèle, mais ignorent souvent les contraintes spécifiques du service basé sur des API ou les nuances des données de logs.

Un fossé critique existe dans la compréhension de la manière dont les mêmes données de logs multi-LLM structurées peuvent être exploitées à travers différents points d'intervention (routage, prompting et entraînement) pour répondre à des besoins variés, particulièrement dans les scénarios où les poids des modèles sont inaccessibles (service basé sur des API).

Méthodologie

Les auteurs proposent FusionFactory, un cadre systématique pour fusionner les capacités des LLM, soutenu par LLMFusionBench, un benchmark à grande échelle conçu pour évaluer les stratégies de fusion à travers trois étapes distinctes.

1. Construction de LLMFusionBench

Pour permettre une comparaison inter-étapes, les auteurs ont construit un benchmark comprenant :

• Portée : 14 tâches à travers 6 domaines (Mathématiques, Code, Raisonnement de sens commun, Connaissance du monde, Compréhension de lecture, Connaissance populaire).
• Données : Réponses de 20 LLM open-source allant de 8B à 671B de paramètres, totalisant 103M de tokens.
• Structure : Contrairement aux jeux de données standards, chaque entrée est un tuple de log structuré $(q, t, m, s, r, c, y, j)$, capturant la requête, la tâche, l'identité du modèle, le mode de réponse, la réponse générée, le coût d'inférence, la performance spécifique à la tâche et un score d'un juge LLM.
• Modes doubles : Pour chaque requête, les modèles génèrent à la fois des réponses directes et des réponses augmentées par le raisonnement (Chain-of-Thought) afin de capturer divers schémas de raisonnement.

2. Le cadre FusionFactory

FusionFactory opère à trois niveaux, correspondant aux étapes de fusion précoce, intermédiaire et tardive dans le pipeline du LLM :

A. Fusion au niveau de la requête (Fusion précoce)

• Objectif : Sélectionner le LLM et le mode de réponse optimaux pour une requête spécifique avant la génération.
• Mécanisme : Un routeur apprend une politique $f_\phi$ pour mapper $(requête, tâche)$ vers une action $a = (modèle, mode)$.
• Objectif : Maximiser une fonction de récompense équilibrant la performance ($P$), le coût ($C$) et la qualité du juge LLM ($J$) :
  $$Récompense = \alpha \cdot P - \beta \cdot C + \gamma \cdot J$$
• Implémentation : Évalué à l'aide de divers algorithmes de routage (KNN, SVM, MLP, BERT, GraphRouter) sous différents scénarios de pondération de la récompense (Priorité à la performance, Équilibre, Priorité au coût, Juge LLM).

B. Fusion au niveau de la pensée (Fusion intermédiaire)

• Objectif : Améliorer la génération en injectant des schémas de raisonnement réutilisables sans modifier les poids du modèle.
• Mécanisme :
  1. Extraction de templates : Un résumeur LLM distille des "templates de pensée" abstraits à partir des $k$ meilleures réponses des requêtes historiques (classées par performance ou score de juge).
  2. Récupération : Pour une nouvelle requête, des requêtes historiques similaires sont récupérées via la similitude d'embedding.
  3. Prompting : Les templates de pensée correspondants sont utilisés comme démonstrations "few-shot" pour guider le LLM cible.
• Stratégie : Évalué à l'aide de stratégies de sélection basées sur la Performance, sur le Juge LLM, et une stratégie Hybride pour les $k$ meilleures réponses.

C. Fusion au niveau du modèle (Fusion tardive)

• Objectif : Consolider les capacités complémentaires dans un seul modèle de base via un entraînement supervisé (SFT).
• Mécanisme : Les réponses de haute qualité issues des logs multi-LLM (sélectionnées par performance ou score de juge) servent de données d'entraînement pour un modèle de base.
• Stratégie : Comparaison du Top-$K$ SFT (utilisant les réponses multi-LLM sélectionnées) contre le Top-$K$ Label-only SFT (utilisant uniquement les vérités de terrain/ground truths) pour isoler le bénéfice de la connaissance multi-LLM.

Résultats Clés

Les expériences ont été menées sur l'ensemble de test complet de LLMFusionBench, comparant les trois niveaux de fusion contre le meilleur LLM individuel et les lignes de base zero-shot.

1. La fusion au niveau de la pensée offre la meilleure performance :

   • La fusion au niveau de la pensée (spécifiquement la stratégie Hybride avec des modèles à pleine échelle) a atteint la performance moyenne la plus élevée (0,615), surpassant le meilleur LLM individuel (0,600) et les autres bases de comparaison de fusion comme LLM-Blender (0,603) et FuseLLM-adapté (0,557).
   • Les gains ont été plus prononcés dans les tâches intensives en raisonnement (Mathématiques et Code), où la récupération de traces de raisonnement diverses a apporté une valeur significative.
   • Les gains de performance étaient robustes même en contrôlant la récupération de doublons quasi-identiques, suggérant que le bénéfice provient de schémas de raisonnement réutilisables plutôt que d'une simple superposition de données.

2. La fusion au niveau de la requête offre la meilleure efficacité de coût :

   • La fusion au niveau de la requête (via GraphRouter) a fourni un compromis favorable entre performance et coût.
   • Sous un routage conscient du coût, elle a atteint une performance comparable au meilleur LLM unique, mais avec un coût d'inférence environ 10 fois inférieur (0,0184 contre 0,1850 en unités normalisées).
   • Cela confirme son utilité pour le service basé sur des API où la minimisation de l'utilisation des tokens est critique.

3. La fusion au niveau du modèle montre une généralisation limitée :

   • La fusion au niveau du modèle (SFT) a produit des gains modestes et, dans certains domaines (Code et Connaissance du monde), a été moins performante que les lignes de base zero-shot.
   • Les auteurs attribuent cela à un surapprentissage (overfitting) sur les styles de réponse spécifiques des données journalisées et à la difficulté d'abstraire des comportements de tâches hétérogènes en un seul ensemble de paramètres.
   • Notamment, le SFT multi-LLM a surpassé le SFT Label-only, confirmant que les logs multi-LLM contiennent des connaissances précieuses au-delà des vérités de terrain, mais que le processus de consolidation introduit des défis de généralisation.

4. Variations spécifiques aux domaines :

   • La fusion a apporté des améliorations marginales dans les domaines de la Connaissance du monde et des Mathématiques, qui reposent fortement sur la précision factuelle stricte et la cohérence logique, suggérant que ces domaines sont moins propices aux heuristiques de fusion actuelles.
   • Les tâches lourdes en raisonnement (Mathématiques, Code) ont le plus bénéficié de la fusion au niveau de la pensée, tandis que les tâches intensives en connaissances ont montré des résultats mitigés.

Signification et Revendications

L'article affirme que FusionFactory et LLMFusionBench fournissent une perspective unifiée et sensible aux étapes de fusion qui faisait défaut jusqu'à présent.

• Au-delà de la compatibilité API : Alors que les travaux antérieurs se concentraient sur le routage uniquement via API, ce travail démontre que les mêmes données de logs multi-LLM structurées peuvent être systématiquement évaluées à travers les étapes de routage, de prompting et d'entraînement.
• Cadre de décision : La "matrice des étapes de fusion" révèle qu'il n'existe pas de stratégie de fusion optimale unique ; le choix dépend des contraintes de déploiement (ex: coût vs précision) et des exigences de la tâche (ex: raisonnement vs rappel).
  • Utilisez le niveau de la requête pour les scénarios sensibles au coût et à haut débit.
  • Utilisez le niveau de la pensée pour maximiser les capacités de raisonnement sans réentraînement du modèle.
  • Utilisez le niveau du modèle uniquement lorsqu'un seul modèle déployable est strictement requis et que l'entraînement hors ligne est réalisable, en reconnaissant ses limites de généralisation.
• Fondation pratique : Ce travail valide les données de logs multi-LLM comme une source de supervision pratique et évolutive pour fusionner les diverses capacités des LLM, offrant un blueprint pour les futurs systèmes devant opérer dans des environnements de service hétérogènes et réels.

Les auteurs concluent que, bien que la fusion au niveau de la pensée offre actuellement les gains de performance les plus forts, la comparaison systématique permise par leur cadre est essentielle pour comprendre les compromis entre flexibilité, coût et généralisation dans les systèmes multi-LLM.