Résumé technique : SPECHOP – Spéculation continue pour accélérer les agents de récupération multi-sauts

1. Énoncé du problème

Les modèles de langage de grande taille (LLM) reposent de plus en plus sur des outils externes (par exemple, recherche web, récupération de documents) pour résoudre des tâches complexes et riches en informations. Cependant, l'utilisation d'outils sur plusieurs sauts introduit une latence d'exécution substantielle. Dans une trajectoire séquentielle standard, le modèle doit générer une étape de raisonnement, attendre une observation de l'outil, générer l'étape suivante, attendre la prochaine observation, et ainsi de suite. Des analyses récentes indiquent que, dans les agents de recherche approfondie, les appels à des outils externes (en particulier la recherche web) peuvent représenter jusqu'à 91 % de la latence de bout en bout.

Le défi central consiste à accélérer ces trajectoires multi-sauts sans modifier la trajectoire finale que le modèle aurait empruntée sans accélération. Les méthodes de spéculation existantes supposent souvent un seul saut de spéculation ou nécessitent un vérificateur oracle qui connaît la justesse d'une prédiction avant que l'outil cible ne renvoie un résultat. L'objectif est de développer un cadre qui exploite des outils « spéculateurs » plus rapides mais moins fiables pour chevaucher le calcul avec la latence des outils, tout en garantissant une précision sans perte grâce à la vérification.

2. Méthodologie

Cadre théorique

Les auteurs établissent un cadre théorique pour la spéculation sans perte dans des contextes multi-sauts. Ils définissent :

• Outil cible ($T$) : L'outil externe fiable et lent (par exemple, recherche web).
• Spéculateur ($S$) : Un outil approximatif plus rapide qui prédit l'observation avec une probabilité $p > 0$ d'induire le même état suivant que $T$.
• Vérificateur ($V$) : Un mécanisme permettant de déterminer si une observation spéculative est équivalente à l'observation cible pour les besoins de l'état suivant du modèle.

Les auteurs dérivent une borne supérieure du gain de latence en utilisant un cadre de « vérification par oracle », où la justesse est connue immédiatement. Ils montrent que le gain de latence relatif dépend de la probabilité de succès du spéculateur ($p$), de sa latence relative ($\alpha = E[T_{spec}]/E[T_{target}]$), et du rapport entre le temps de décodage et le temps d'exécution de l'outil ($\beta = E[T_{seg}]/E[T_{target}]$).

Algorithme SPECHOP

L'article propose SPECHOP, un cadre de spéculation continue qui maintient plusieurs threads parallèles pour s'approcher de la borne de latence oracle.

• Exécution spéculative continue : Contrairement à la spéculation à fenêtre fixe, SPECHOP maintient $k$ threads actifs tout au long de la trajectoire.
  • Création de thread : Lorsqu'un thread $T_i$ appelle l'outil cible pour une action $a_i$, un nouveau thread $T_{i+1}$ est immédiatement créé. $T_{i+1}$ utilise le spéculateur pour prédire l'observation $\hat{o}_i$, passe à l'état spéculatif, génère l'action suivante $a_{i+1}$, et appelle l'outil cible pour $a_{i+1}$.
  • Vérification asynchrone : À mesure que les résultats de l'outil cible ($o_i$) reviennent, le vérificateur les compare aux observations spéculatives ($\hat{o}_i$) utilisées pour créer les threads subséquents.
  • Validation et annulation :
    • Succès : Si $V(o_i, \hat{o}_i)$ réussit, la branche spéculative est validée. Le système rejette le thread vérifié et continue d'étendre le front avec de nouveaux threads spéculatifs.
    • Échec : Si la vérification échoue, tous les threads spéculatifs en aval sont rejetés. Le système reprend l'exécution depuis le dernier état vérifié en utilisant la sortie réelle de l'outil cible.
• Gestion des threads : Le système gère dynamiquement la taille de la fenêtre $k$. L'analyse théorique (Théorème 4) fournit des bornes sur la probabilité de « famine du pipeline » (où le système manque de threads spéculatifs avant que l'outil cible ne revienne) en fonction de $k$, $\alpha$, $\beta$ et de la volatilité du système.

3. Contributions clés

1. Cadre théorique : L'article caractérise le gain de latence optimal réalisable pour la spéculation multi-sauts sans perte et dérive le temps d'exécution attendu pour des stratégies de spéculation à fenêtre bornée et continue.
2. Cadre SPECHOP : Un algorithme novateur qui maintient une exécution spéculative continue avec plusieurs threads actifs, vérifiant les prédictions de manière asynchrone à l'arrivée des sorties cibles. Cela permet au système de « pousser » la spéculation vers l'avant plutôt que d'attendre passivement.
3. Garantie sans perte : En vérifiant strictement les observations spéculatives par rapport aux sorties de l'outil cible avant validation, SPECHOP préserve la trajectoire exacte et la précision de l'exécution séquentielle standard.
4. Validation empirique : Des expériences approfondies sur des tâches de question-réponse multi-sauts avec récupération augmentée (2WikiMultihopQA, MuSiQue, DeepResearch-9K) démontrent que SPECHOP correspond étroitement aux prédictions théoriques et réalise des réductions de latence significatives.

4. Résultats expérimentaux

Les auteurs ont évalué SPECHOP en utilisant divers modèles générateurs (CoRAG-Llama3.1-8B, GPT-5), des outils cibles (Récupération E5, Recherche Web) et des spéculateurs (Llama 3.1 8B, Qwen 3 8B, GPT-4o mini, GPT-4o, et un récupérateur basé sur cache).

• Réduction de la latence : SPECHOP a réduit la latence réelle jusqu'à 40 % dans des configurations à forte latence d'outil (par exemple, Recherche Web). Par exemple, sur 2WikiMultihopQA avec Recherche Web et GPT-4o comme spéculateur, la latence relative est tombée à 0,60 (une réduction de 40 %), s'approchant étroitement de l'optimal théorique de 0,50.
• Préservation de la précision : Sur tous les jeux de données et configurations, SPECHOP a préservé les scores de Correspondance Exacte (EM) et F1 de la base de référence séquentielle standard. Les écarts étaient marginaux (<1 %), attribués uniquement à des variations bénignes acceptées par le vérificateur. En revanche, la « Spéculation complète » (utilisation uniquement du spéculateur sans vérification) a provoqué une dégradation sévère de la précision (par exemple, l'EM passant de 68,7 à 38,7 sur 2WikiMultihopQA).
• Compromis : Le cadre permet un compromis entre réduction de la latence et coût computationnel via la limite de threads actifs $k$. Restreindre $k$ à de petites valeurs (par exemple, 3–6) produit toujours des gains de latence quasi optimaux tout en contrôlant l'augmentation des appels d'outils/modèles parallèles.
• Spéculation par cache : L'utilisation d'un cache rapide à petit index comme spécificateur (avec 25 % de l'index) a permis d'atteindre des taux de succès élevés (>60 % pour E5, >50 % pour Recherche Web) et des accélérations substantielles, démontrant l'applicabilité de la méthode au-delà des spécificateurs basés sur LLM.

5. Importance et affirmations

L'article affirme que SPECHOP comble efficacement le fossé entre les gains de latence théoriques d'un oracle et la mise en œuvre pratique dans les systèmes d'agents multi-sauts. En passant d'une spéculation à un seul saut à un pipeline continu et multi-threadé, SPECHOP surpasse le goulot d'étranglement « arrêt et attente » inhérent à l'utilisation séquentielle d'outils.

Les auteurs soulignent que leur approche est sans perte : elle ne sacrifie ni la qualité du raisonnement ni la précision de la réponse finale du modèle sous-jacent. Au contraire, elle accélère le processus d'atteinte de cette réponse en chevauchant la latence des outils externes lents avec la génération plus rapide d'étapes spéculatives. Ce travail suggère qu'avec un petit nombre de threads actifs (souvent $k < 10$), les agents peuvent réaliser des accélérations quasi optimales dans des environnements stochastiques réalistes, rendant le raisonnement complexe multi-sauts plus pratique pour des applications sensibles au temps.

L'article conclut que, bien que SPECHOP introduise un coût computationnel plus élevé (en raison de l'exécution parallèle), il s'agit d'une solution hautement pratique pour les scénarios où la minimisation de la latence réelle est critique et où la surcharge computationnelle est un compromis acceptable.