Runtime d'orchestration de conversation

Pourquoi ce papier existe

Les applications IA modernes ne sont plus des enveloppes autour d'un seul LLM. La vraie intelligence émerge de la couche d'orchestration qui coordonne modèles, outils, mémoire, retrieval, boucles de raisonnement, garde-fous et systèmes de rendu. Les équipes qui livrent de l'IA fiable en production ne sont pas celles qui ont les meilleurs prompts — ce sont celles qui ont construit le runtime autour du prompt. Ce papier expose l'architecture que nous utilisons.

Philosophie

Le runtime reste agnostique au modèle, agnostique au client et piloté par plugins. Les modèles deviennent des moteurs de raisonnement interchangeables. Les clients (web, terminal, API, SMS, courriel, voix, embarqué) déclarent leurs capacités et le runtime adapte la forme de sortie. Les plugins étendent retrieval, outils, garde-fous et rendu sans toucher au noyau. C'est ce qui permet à un runtime de survivre à la prochaine génération de modèles.

• Agnostique au modèle — changer de fournisseur sans réécrire
• Agnostique au client — un cerveau, plusieurs surfaces
• Piloté par plugins — extension sans changer le noyau
• Trace d'abord — chaque étape émet des données structurées

Flux d'exécution — dix étapes

Chaque tour traverse un pipeline en couches. L'ingestion d'entrée normalise le contenu entrant selon le client actif. Le prétraitement léger détecte sentiment, urgence et langue avec un modèle rapide et bon marché. L'extraction intention-et-entités fait deux choses à la fois : elle classifie le verbe de la requête (ce que l'utilisateur veut faire) et extrait les entités structurées sur lesquelles la requête opère — le sujet principal, plus le temps, la géographie, la portée et tout autre slot typé que la requête remplit. L'enrichissement de contexte assemble l'état de prompt optimal — retrieval, compression, sélection de mémoire, classement sémantique, fraîcheur, budget de jetons. L'assemblage retrieval-et-mémoire fusionne sources vectorielles, mots-clés, graphes et structurées avec la mémoire de travail. L'orchestration d'outils invoque APIs, code, requêtes, graphiques, fichiers ou agents externes via des connexions gouvernées. La boucle principale de raisonnement est itérative — planifier, appeler, réfléchir, réessayer — avec une profondeur ajustée à la complexité et au budget. La réflexion et validation notent la sortie pour hallucination, citations, politique et qualité. Le formatage de sortie rend dans le médium préféré du client. Les garde-fous et la livraison imposent les dernières vérifications avant que la réponse ne quitte le runtime.

• 1. Ingestion d'entrée
• 2. Prétraitement léger
• 3. Intention & entités
• 4. Enrichissement de contexte
• 5. Assemblage retrieval et mémoire
• 6. Orchestration d'outils
• 7. Boucle principale de raisonnement
• 8. Réflexion et validation
• 9. Formatage de sortie
• 10. Garde-fous et livraison

Intention et entités — ce qu'est la requête, et sur quoi elle opère

Les runtimes plus anciens traitent la classification d'intention comme une étape de routage unique. En pratique, chaque requête porte une intention et un ensemble d'entités typées — et le runtime a besoin des deux pour faire quoi que ce soit d'utile. « Donne-moi les revenus de Ring pour aujourd'hui au Canada » a une intention (une requête de revenu quotidien) et trois entités : { game: 'Ring' } comme sujet principal, { period: 'today' } comme portée temporelle, et { region: 'CA' } comme portée géographique. « Donne-moi les revenus de Concierge pour le trimestre dernier en EMEA » est la même intention avec un ensemble d'entités différent. Les traiter comme une décision de routage unique fusionne ce qui doit rester séparé ; les traiter comme deux tâches d'extraction — un classificateur pour le verbe, un extracteur structuré pour les slots — rend les deux réutilisables sur des centaines de variantes. L'intention choisit le workflow, l'outil ou le mode de raisonnement spécialisé ; les entités — façon schema.org, chacune avec un type, des champs identifiants et un rôle — pilotent la portée du retrieval, la liaison des arguments d'outils, la résolution des permissions et la tranche de mémoire qui survit à la compression de contexte. Les entités sont plurielles par conception : une seule requête peut nommer un jeu, un pays, une fenêtre temporelle, un segment client et une cohorte de comparaison à la fois, et chacune nourrit les étapes suivantes.

• Intention : le verbe · classifiée vers un workflow ou mode de raisonnement
• Entités : slots typés · sujet principal, temps, géographie, portée, comparateurs
• Chaque entité porte un rôle — schema.org { type, name, role, identifiers }
• Même intention + entités différentes = même chemin de code, liaison différente
• Même sujet + intentions différentes = une session qui « suit » cette entité
• Les entités pilotent retrieval, arguments d'outils, permissions et mémoire

L'ingénierie de contexte comme différenciateur

L'étape qui sépare un runtime compétent d'un excellent est l'ingénierie de contexte. L'état du prompt n'est pas un gabarit statique — il est assemblé dynamiquement par retrieval, classement sémantique, fraîcheur, pertinence, sélection mémoire et un budget de jetons qui doit s'accommoder du modèle choisi. Le runtime négocie : quelles mémoires survivent, quels fragments méritent leurs jetons, quels tours précédents sont résumés plutôt que conservés intégralement. La qualité de chaque étape avale est plafonnée par celle-ci.

RAG hybride

Le RAG moderne est hybride. La recherche vectorielle seule rate les chaînes exactes ; la recherche par mots-clés rate les voisins sémantiques ; la recherche par graphe fait remonter des relations qu'aucune n'attrape. Combinez retrieval sémantique, symbolique, par graphe et structuré avec reranking et scoring temporel. Le runtime possède la politique de retrieval — quelles sources pour quelles intentions, avec quelle fraîcheur, sous quelles permissions — pas le code applicatif.

Outils et exécution MCP

L'orchestration d'outils est l'endroit où le runtime rencontre le monde réel. APIs, exécution de code, retrieval de documents, requêtes de base de données, génération de graphiques, manipulation de fichiers, appels d'agents externes — tout routé via un registre qui impose permissions, portée, retries, timeouts et traces d'exécution. Le Model Context Protocol (MCP) est le standard ouvert que nous utilisons pour déclarer des outils avec schémas typés ; le registre est ce qui rend ces outils sûrs à exposer.

Raisonnement adaptatif

La boucle principale est le moteur cognitif. Elle soutient l'exécution itérative avec planification, usage d'outils, réflexion et retries — mais la profondeur est adaptative. Une FAQ simple n'a pas besoin d'un planificateur ; une triage d'incident avec cinq appels d'outils si. Coût et latence forment la profondeur de la boucle. Le runtime décide ; le modèle exécute.

Réflexion et validation

Les runtimes de production exécutent de plus en plus une étape d'auto-évaluation après génération : détection d'hallucination, vérification de citations, contrôles de politique, scoring de confiance, notation de qualité. Ce n'est pas une sécurité ajoutée — c'est l'étape qui transforme une génération unique peu fiable en une sortie défendable. Les validations échouées routent vers retry, escalade ou refus avec explication.

Rendu multi-client

Un cerveau, plusieurs surfaces. Le même résultat d'orchestration s'affiche en texte brut dans un terminal, en markdown dans un chat, en widgets HTML dans une app web, en JSON pour un consommateur d'API, en courriel non-streaming, en carte multimédia avec graphiques, en voix avec SSML par téléphone. Le runtime négocie les capacités avec chaque client au démarrage ; la couche de rendu s'adapte.

Garde-fous à chaque couche

Les garde-fous ne sont pas un filtre final. Ils opèrent à cinq étapes : pré-entrée (bloquer prompts interdits), retrieval (filtrer sources non autorisées), exécution d'outils (contrôles de portée et permissions), génération (décodage conscient des politiques) et livraison finale (classificateurs de sortie). Les politiques varient par rôle utilisateur, classe d'intention, plateforme client, règles d'entreprise et contraintes réglementaires — le runtime est le lieu unique où elles vivent.

Architectures mémoire

Les runtimes modernes maintiennent une mémoire en couches : court terme conversationnelle (le tour actuel), épisodique (tours précédents), sémantique long terme (faits appris entre sessions), profil utilisateur (préférences, rôle, historique), espace de travail (entités pertinentes), exécution (appels d'outils en cours et résultats partiels). Chaque couche a sa rétention, sa politique de retrieval et sa frontière d'accès.

Tendances émergentes

Ce que nous regardons : runtimes agentiques composant des collaborations multi-agents ; routage dynamique de modèles ; architectures streaming-first où l'utilisateur voit penser ; graphes de retrieval auto-structurants ; workflows machine-d'état contraignant le raisonnement libre à des chemins prouvablement corrects ; exécution spéculative ; pipelines auto-guérissants ; profondeur de raisonnement adaptative ; cognition native aux outils.

Conclusion

L'avenir de l'IA conversationnelle n'est pas des modèles plus gros. C'est des runtimes plus capables. La couche d'orchestration — contexte, retrieval, outils, raisonnement, réflexion, mémoire, rendu, garde-fous — est le système d'exploitation de l'IA. Le modèle est un composant interchangeable à l'intérieur.