interference-search : recherche parallèle pour les LLM

Ce que propose réellement interference-search

Ce qui m'intéresse ici n'est pas une couche supplémentaire autour d'un LLM, mais un changement de l'unité même de recherche. interference-search propose de raisonner sur des états explicites plutôt que sur une transcription textuelle séquentielle : plusieurs branches se développent en parallèle, les états identiques fusionnent et les directions sans issue sont écartées.

Le point de départ de cette information est le dépôt interference-search de Bad Theory Labs sur GitHub. Les résultats de recherche accessibles ne présentent ni README officiel, ni documentation d'API, ni exemples de code, ni rapport de benchmarks ; l'architecture ne peut donc être décrite qu'au niveau des affirmations publiées. Des agrégateurs tiers mentionnent également un évaluateur entraîné qui décide quelles branches continuent.

La logique technique est claire. Si deux branches atteignent le même état, il n'y a aucune raison de payer deux fois la même suite de calculs. Si l'évaluateur repère assez tôt un chemin peu prometteur, le budget global de recherche peut être redirigé vers de meilleurs candidats.

Mais entre un schéma séduisant et un système de production se trouvent des détails difficiles : le coût de l'évaluateur lui-même, la qualité de la déduplication des états, la synchronisation des branches parallèles et le risque de supprimer trop tôt le bon chemin. Les descriptions disponibles ne permettent pas de savoir lequel de ces composants devient le goulot d'étranglement.

Au 26 septembre 2026, les documents rassemblés ne précisent pas la date de lancement du projet. Un agrégateur affichait environ 89 étoiles lors de sa capture, mais c'est un signal d'intérêt précoce, non une preuve de maturité ou d'efficacité.

Où l'idée est utile, et où commence l'hypothèse

La valeur pratique n'existe que si la réduction du travail répétitif est mesurable. Cette approche pourrait convenir à des tâches présentant de nombreuses trajectoires de raisonnement qui se recouvrent, avec un état pouvant être normalisé de manière fiable.

La limite essentielle de cette formulation est que la description disponible porte sur des branches concurrentes au sein d'une même recherche. Elle ne prouve pas que le projet optimise des requêtes parallèles arbitraires d'utilisateurs, ni qu'il résout déjà les interférences de ressources dans une infrastructure LLM déployée.

Je regarderais d'abord la latence par rapport à une recherche séquentielle, le nombre d'états fusionnés, la part de branches éliminées à tort et la surcharge de l'évaluateur. Sans ces mesures, la promesse d'une latence plus faible reste une hypothèse techniquement plausible.

L'idée ne ressemble pas à un simple effet de mode : les états explicites offrent réellement davantage de contrôle qu'un dialogue linéaire. Pour l'instant, la question n'est pas l'élégance de la méthode, mais de savoir si les économies sur les branches compensent leur coût de gestion.

Nous avons déjà expliqué comment des agents Claude Code parallèles peuvent examiner des pull requests et révéler des conditions de course dans les processus de développement. Cette même approche d'exécution parallèle fournit un contexte utile pour interference-search et sa conception de l'inférence LLM.