Il existe un mode de défaillance des systèmes à récupération augmentée que personne ne montre en démo. Vous posez une question, le système l'encode, extrait les dix meilleurs fragments, les entasse dans un prompt, et le modèle rédige une réponse fluide bâtie sur les dix fragments qui ont obtenu les meilleurs scores.
Si la réponse avait besoin d'un onzième fragment, vous ne le saurez jamais. Vous obtenez le même paragraphe assuré dans les deux cas.
La solution n'est pas un meilleur encodeur. C'est de laisser quelque chose regarder à nouveau — et c'est précisément ce que fait le RLM.
Deux composants, clairement séparés
Le Sidecar est un agent de flotte. Il s'exécute là où se trouve la puissance de calcul, rapporte ce dont il dispose et sert les requêtes d'inférence. Fantom MCP Server s'enregistre comme l'un des maîtres auxquels un sidecar rend compte.
Le RLM est un modèle de langage de récupération — un modèle dédié dont le rôle n'est pas de rédiger de la prose mais de rassembler. Il appelle itérativement des outils de recherche de code jusqu'à disposer du code exact nécessaire pour répondre, puis restitue les preuves collectées ainsi qu'un bref brouillon. Une étape de synthèse distincte en fait la réponse finale sourcée.
Cette séparation compte. Le modèle de collecte est optimisé pour l'usage d'outils et peut être petit et rapide. Le modèle de synthèse est optimisé pour la rédaction. Demander à un seul modèle de faire les deux, c'est la garantie d'une réponse soit mal documentée, soit mal écrite.
Comment la flotte se signale
C'est le sidecar qui initie la connexion, pas le serveur — ce qui est le bon sens de lecture quand la puissance de calcul réside sur des postes de travail qui apparaissent et disparaissent.
Le protocole de communication est volontairement minimal. Un sidecar ouvre un WebSocket et envoie register avec son adresse, son nom d'hôte et ses conteneurs. Ensuite, il envoie des trames heartbeat transportant les conteneurs, le nombre de requêtes actives et un blob de statut. Le maître répond registered et peut renvoyer des trames command et config. Si le WebSocket est indisponible, le même échange fonctionne via des points d'accès HTTP pour le heartbeat, le poll et le résultat.
Fantom MCP n'émet pas actuellement de commandes de travail sur ce canal — ses appels d'inférence réels passent par HTTP. Ce qu'il fait en revanche, c'est exploiter chaque heartbeat pour en extraire les données de capacité, afin que la couche de routage sache toujours quels rôles sont réellement servis à l'instant présent.
Un détail mérite d'être nommé parce qu'il a été appris à la dure : ce registre est réécrit à chaque heartbeat, en lecture-modification-écriture, dans un fichier de configuration qui contient aussi les paramètres de recherche. Une version antérieure renvoyait un objet vide en cas de lecture tronquée, si bien qu'une seule lecture corrompue pouvait ne persister que la liste des sidecars et effacer tout le reste — sauvegarde comprise. Les lectures récupèrent désormais depuis une sauvegarde voisine et les écritures sont atomiques. Le code de flotte touche à la configuration bien plus souvent qu'on ne l'imagine.
La boucle de collecte
Voici ce qui se passe réellement à l'arrivée d'une question.
Le modèle construit un plan, émet des appels d'outils, et les résultats sont rassemblés avec une concurrence bornée. Les blocs de preuves sont découpés, fusionnés et budgétés par rapport à la fenêtre de contexte — laquelle est lue dynamiquement depuis le point de service plutôt que codée en dur, parce que la même boucle s'exécute sur différents modèles aux limites différentes.
Si ce qui est revenu ne suffit pas, on recommence. C'est là toute la différence avec une récupération en un seul coup : le système a le droit de remarquer qu'il n'en a pas assez.
Une optimisation récente illustre bien où se situe le vrai coût. Plutôt que de ré-encoder à chaque élargissement, la requête est encodée une seule fois et la recherche s'étend aux fragments voisins en parallèle, en sautant le reranker lors de cette passe d'élargissement. La partie coûteuse de « regarder à nouveau » n'a jamais été le regard — c'était de ré-encoder inutilement la même question.
L'échec est un chemin de première classe
Chaque point d'accès de cette chaîne appartient à une machine qui peut être en veille, en cours de redémarrage ou occupée. Aussi, la règle sur tout le chemin du RLM est brutale : toute erreur de point d'accès renvoie null et l'appelant se rabat sur un repli. Ça ne lève jamais d'exception.
Cela semble peu ambitieux. En pratique, c'est ce qui rend la fonctionnalité utilisable sur une vraie flotte, où « l'hôte RLM est hors ligne » doit dégrader la réponse, pas produire une trace d'appels dans l'éditeur d'un automaticien. Le mode de repli par défaut est le tout-local, et l'étape de collecte est une amélioration de la récupération plutôt qu'une dépendance de celle-ci.
De la capacité sans matériel
La dernière pièce relie tout cela au cloud. Un sidecar peut router un rôle vers OpenRouter plutôt que vers son modèle local, et Fantom MCP traite chacun de ces appariements comme un conteneur virtuel — un fournisseur logique distinct, nommé selon le motif <PCName>-OR-<Role>, qui représente une capacité de service réelle sans aucun GPU ni VRAM derrière.
C'est ainsi que l'embedding se répartit simultanément sur les GPU locaux et le cloud, et que le reranking dispose tout simplement d'un backend sur une flotte dont les machines sont occupées à autre chose.
Deux propriétés de cet arrangement méritent d'être dites clairement :
- La découverte passe par HTTP, pas par le heartbeat. Le heartbeat transporte un instantané allégé qui n'inclut pas les données des conteneurs virtuels. Un système qui chercherait à les extraire du heartbeat ne trouverait silencieusement rien, éternellement, tout en ayant l'air de fonctionner.
- La clé d'API ne touche jamais Fantom MCP. C'est le sidecar qui la détient. Fantom ne fait jamais que nommer un fournisseur et un modèle. Rien dans le chemin de découverte ne lit, ne stocke, ne journalise ni ne transporte de clé.
La façon dont ces fournisseurs sont ensuite choisis, filtrés et budgétés fait l'objet du prochain article.
Fantom MCP Server est disponible en source ouverte sur github.com/Project-SandStar/FantomMcpServer.