Architecture des assistants IA : LLM, mémoire, outils, routage, observabilité

Un assistant IA de production n’est pas « un LLM avec un prompt ». C’est un système qui accepte l’intention, maintient un état, décide quand récupérer des informations ou agir, et expose suffisamment de détails d’exécution pour déboguer les échecs.

Cette vision au niveau système est ce que le cluster Systèmes IA explore lorsque les assistants dépassent l’invocation d’un seul modèle.

OpenAI décrit les agents comme des applications qui planifient, appellent des outils, collaborent et conservent suffisamment d’état pour un travail en plusieurs étapes, tandis qu’Anthropic cadre le même problème comme un harnais géré capable d’exécuter des fichiers, des commandes, l’accès web et du code de manière sécurisée.

L’architecture la plus propre répartit les responsabilités en cinq couches : LLM, Mémoire, Outils, Routage et Observabilité. Cette répartition correspond aux capacités exposées par les principales API de fournisseurs, par MCP, par les runtimes auto-hébergés tels que vLLM et llama.cpp, et par de véritables systèmes d’assistance tels qu’OpenClaw et Hermes.

La mémoire doit être traitée comme plus que « un contexte plus long ». Les systèmes de récupération transforment le connaissances externes en mémoire non paramétrique explicite — le même espace de conception couvert en profondeur par Retrieval-Augmented Generation (RAG) — et à la fois les conseils contextuels d’Anthropic et le papier « Lost in the Middle » mettent en garde contre le fait que bourrer plus de jetons dans le contexte ne garantit pas une récupération fiable.

L’utilisation des outils est une frontière de contrat, pas de la magie. L’appel de fonction OpenAI, l’utilisation d’outils Anthropic et MCP reposent tous sur le même modèle : le modèle émet une requête structurée, un runtime l’exécute, et le résultat s’écoule à nouveau dans la conversation. Si cette frontière est négligente, l’assistant le devient aussi.

Mon biais est simple : commencer par l’ennuyeux. Un orchestrateur, un chemin de mémoire durable, une trace par requête et une politique explicite pour l’exécution des outils. Les graphes multi-agents sont utiles, mais seulement après avoir pu expliquer les cas d’échec de votre agent unique sans deviner.

Ce qu’est un système d’assistant IA

Une définition pratique est celle-ci : un système d’assistant IA est un runtime qui transforme l’intention de l’utilisateur en une réponse ou une action en combinant une interface de modèle, l’assemblage du contexte, l’exécution d’outils, la gestion d’état et la télémétrie. C’est pourquoi la documentation utile ne se limite pas aux fiches modèles. La documentation utile comprend les références API, les contrats d’outils, les guides de récupération, la documentation du routage et les traces. L’API Responses d’OpenAI expose des interactions étatiques, des outils intégrés et l’appel de fonctions. L’API Claude d’Anthropic expose l’accès direct aux Messages ainsi que les Agents Gérés. OpenClaw et Hermes vont un peu plus loin et montrent ce qui se passe lorsque vous placez ces capacités derrière des passerelles persistantes, des canaux, des sessions et une mémoire.

En d’autres termes, un système d’assistant a un contrat plus large qu’une complétion de chat. Un bon contrat interne ressemble à ceci :

AssistantRequest  = intention utilisateur + identité + session + pièces jointes + politique
AssistantResponse = réponse + actions + citations + changements d'état + identifiant de trace

Ce contrat est important car chaque désaccord en production se réduit éventuellement à l’une de ces questions : quel contexte était visible, quel outil a été exécuté, quel modèle a répondu, quelle mémoire a été lue ou écrite, et où la trace indique que le système a passé du temps. OpenTelemetry définit les traces comme le chemin d’une requête à travers une application, ce qui correspond exactement à l’abstraction dont les assistants sérieux ont besoin. LangSmith et OpenLIT spécialisent ensuite cette idée pour les LLM, les outils, les magasins vectoriels et les flux de travail des agents.

Composants principaux et interfaces

La séparation des composants ci-dessous est celle que je trouve la plus durable. C’est aussi celle qui correspond le mieux aux API officielles et aux runtimes open-source que les gens exploitent réellement.

Le tableau ci-dessus est dérivé des interfaces officielles des fournisseurs, de MCP, de la documentation des bases de données vectorielles et de la documentation des runtimes pour vLLM, llama.cpp, OpenClaw et Hermes.

La couche LLM devrait bien faire trois choses : consommer un contexte de travail actuel, émettre soit une réponse finale soit une requête d’action structurée, et retourner suffisamment de métadonnées pour soutenir les tentatives et le traçage. L’API Responses d’OpenAI est explicitement conçue pour les interactions étatiques avec des outils intégrés et l’appel de fonctions. L’API Messages d’Anthropic expose la même boucle principale via les blocs tool_use et les retours tool_result, tandis que les Agents Gérés vous offrent un harnais hébergé si vous ne souhaitez pas construire la boucle vous-même. Les runtimes auto-hébergés tels que vLLM et llama.cpp sont importants car ils préservent des interfaces de style fournisseur familières tout en vous permettant de placer l’inférence à l’intérieur de votre propre environnement.

La couche Mémoire devrait être divisée mentalement en trois catégories : mémoire de travail, mémoire symbolique durable et mémoire sémantique recherchable. Les embeddings OpenAI retournent des vecteurs qui peuvent être indexés et recherchés ; OpenAI Retrieval et File Search superposent ensuite la recherche sémantique et par mots-clés sur les magasins vectoriels. Pinecone, Weaviate, pgvector et Milvus représentent quatre formes de stockage courantes : entièrement géré, natif vectoriel open-source, natif Postgres et base de données vectorielle distribuée. Hermes et OpenClaw ajoutent un rappel utile : toute la mémoire n’appartient pas à un magasin vectoriel : les notes basées sur des fichiers, les promotions révisées et les instantanés limités à la session sont souvent une conception plus honnête. Systèmes de mémoire dans les assistants IA cartographie le modèle inter-framework ; Système de mémoire de l’agent Hermes détaille la mémoire centrale limitée et les instantanés de session gelés dans un produit.

La couche Outils est l’endroit où un assistant cesse d’être un résumeuse et commence à être un logiciel. L’appel de fonction OpenAI traite les outils comme une fonctionnalité définie par schéma que le modèle peut décider d’invoquer. Anthropic dit la même chose plus explicitement : l’utilisation d’outils est un contrat entre votre application et le modèle, et le modèle n’exécute jamais rien seul. MCP généralise ce contrat en un protocole client-serveur où les hôtes se connectent à un ou plusieurs serveurs qui exposent des outils, des prompts et des ressources — la même frontière décrite étape par étape dans Serveur MCP en Go. LangChain et LlamaIndex s’y installent confortablement en tant que bibliothèques d’orchestration : LangChain se concentre sur une architecture d’agent préconstruite et des intégrations, tandis que LlamaIndex se concentre sur l’accès aux données augmentées de contexte, les moteurs de requête et les flux de travail.

La couche Routage existe parce que « quel modèle ? » n’est jamais la seule question. Vous avez aussi besoin de « quel chemin de fournisseur, quel locataire, quel budget, quelle classe de latence et quel basculement ? ». LiteLLM est utile car sa documentation officielle est rafraîchissante de concrétude : le choix pondéré, le moins occupé, le routage basé sur la latence, le routage basé sur le coût et les basculements limités sont tous des modèles de premier plan. OpenClaw étend le routage vers le haut dans l’isolation des canaux et des agents, tandis que Hermes l’étend vers le bas dans les slots de modèles pour le travail principal et auxiliaire tel que la compression, la résumé et le routage des outils MCP. C’est le bon modèle mental : le routeur choisit plus qu’un modèle, il choisit une voie d’exécution.

La couche Observabilité est ce qui empêche l’architecture de se transformer en folklore. OpenTelemetry vous donne l’abstraction de trace. LangSmith vous donne une visibilité de bout en bout sur les étapes des applications LLM et prend en charge les formes de déploiement cloud, hybrides et auto-hébergées. OpenLIT vous donne une observabilité IA native OpenTelemetry avec des options d’instrumentation sans code et manuelle, y compris le support pour les LLM, les frameworks d’agents, les bases de données vectorielles et les GPU. Pour les métriques de production, les traces et les modèles SLO à travers les workflows d’inférence et d’agents, voir Observabilité pour les systèmes LLM. Si votre assistant n’a aucune trace par requête, aucun span par appel de modèle et aucun historique d’événements pour l’exécution des outils, vous n’avez pas vraiment une architecture. Vous avez des vibes.

Capturer, enrichir, répondre

La séquence qui continue d’apparaître dans les systèmes réels est capturer -> enrichir -> répondre -> enregistrer. Les différents frameworks l’emballent différemment, mais le flux est suffisamment stable pour être traité comme la colonne vertébrale.

L’étape de capture est souvent plus importante qu’elle n’y paraît. OpenClaw et Hermes placent tous deux une passerelle persistante devant l’assistant car l’ingress n’est pas seulement une entrée de texte. Il inclut les métadonnées de canal, les identités, l’autorisation, les limites de session, les messages directs, les groupes, les ticks cron et les sémantiques de livraison. Si vous sautez cette couche et vous fiez à une abstraction de widget de chat brut, vous finirez par la réinstaller comme middleware ad hoc de toute façon.

L’étape d’enrichissement est là où les systèmes matures divergent des démos jouets. OpenAI Retrieval et File Search rendent la récupération explicite à travers les magasins vectoriels et les appels de recherche. LlamaIndex formalise le même modèle à travers des connecteurs de données, des index, des moteurs de requête et des flux de travail. Hermes va plus loin en divisant le parc de modèles en slots principaux et auxiliaires, déchargeant des travaux tels que la compression, la résumé et le routage vers des modèles plus petits ou plus spécialisés. C’est un modèle de conception à voler : ne dépensez pas les jetons de votre modèle le plus coûteux pour des corvées.

L’étape de réponse n’est pas « générer du texte ». C’est « fermer la boucle actuelle ». Si le modèle peut répondre directement, il le fait. S’il a besoin d’un outil, il émet une requête structurée. Le contrat d’utilisation d’outils d’Anthropic et le guide d’appel de fonction d’OpenAI rendent cela explicite. La raison pour laquelle cela est important architecturalement est que les sorties incluent maintenant à la fois le langage et le flux de contrôle. Votre objet réponse est partiellement en prose et partiellement un plan d’exécution.

L’étape d’enregistrement est là où les sémantiques de cohérence apparaissent. Pinecone sépare les chemins d’écriture et de lecture et traite les écritures après une acknowledgement durable. La mémoire Hermes est injectée comme un instantané gelé par session pour qu’elle puisse préserver les performances de cache de préfixe, ce qui signifie que les nouvelles écritures n’apparaissent pas automatiquement dans le prompt de la session actuelle. Le système Dreaming d’OpenClaw ne promeut que les candidats révisés et fondés dans MEMORY.md, et il est opt-in plutôt que toujours actif. La leçon pratique est que la mémoire est rarement véritablement lecture-après-écriture à travers chaque couche. Vous devez concevoir pour une visibilité échelonnée.

OpenClaw et Hermes comme systèmes de référence

OpenClaw et Hermes sont des cas de référence utiles car ce ne sont pas simplement des enveloppes autour d’une API de fournisseur. Les deux présentent un assistant comme un système longue durée avec des passerelles, des sessions, des outils, une mémoire et plusieurs backends de modèles.

Ce mapping est ancré dans la documentation et les dépôts officiels d’OpenClaw et Hermes. OpenClaw documente une architecture de passerelle, le routage multi-agent, le support de fournisseurs personnalisés et auto-hébergés y compris vLLM et Ollama, une mémoire active optionnelle et une promotion basée sur Dreaming. Hermes documente une passerelle de messagerie, une boucle AIAgent centrale, des slots de modèles principaux et auxiliaires, une mémoire intégrée et une intégration MCP native.

Ma lecture légèrement opinionnée est que les deux systèmes font le même argument architectural dans des accents différents. OpenClaw est fortement gateway-first. Hermes est fortement agent-loop-first. Mais les deux rejettent l’idée superficielle qu’un assistant est juste « prompt plus modèle ». Ils modélisent les canaux, les identités, les sémantiques de mémoire, les surfaces d’outils et l’hétérogénéité des backends comme des préoccupations de premier plan. C’est exactement ce qu’une architecture de production devrait faire.

Une pile hybride pratique inspirée par les deux systèmes ressemble à ceci :

edge:
  gateway: hermes ou openclaw

routing:
  proxy: litellm
  policy: conscient de la latence et du budget
  tenancy: scoped à la session et au canal

llm:
  primary: openai responses ou anthropic messages
  local_fallback: vllm
  local_dev: ollama ou llama.cpp

memory:
  session: sqlite ou postgres
  semantic: pgvector ou weaviate
  embeddings: openai embeddings ou ollama embeddings

tools:
  contract: outils json schema plus mcp
  examples: filesystem, browser, web search, internal APIs

observability:
  traces: opentelemetry
  ai_dashboards: openlit ou langsmith
  evals: openai evals plus ensembles de régression spécifiques à l'application

Cette pile est un modèle de déploiement raisonné plutôt qu’un plan prescrit par un vendeur. Elle fonctionne car les interfaces officielles s’alignent : OpenAI et Anthropic exposent des API orientées outils, vLLM et llama.cpp émulent des points de terminaison de style fournisseur, Ollama gère les modèles et embeddings locaux, MCP standardise les outils externes, LiteLLM gère le routage et le basculement, et les plateformes compatibles OpenTelemetry peuvent tracer tout le chemin.

Modèles, tableaux et compromis

Il y a quelques modèles d’assistant répétables qu’il vaut la peine de nommer. Un assistant géré conserve la majeure partie du runtime à l’intérieur des API de fournisseur. Un assistant centré sur la récupération traite la mémoire et la recherche comme le principal différentiateur. Un assistant centré sur les outils se comporte plus comme un opérateur que comme un chatbot. Un assistant de passerelle priorise l’accès toujours actif à travers les surfaces de messagerie. Un maillage de spécialistes décompose le travail en plusieurs agents ou routes. La documentation officielle à travers OpenAI, Anthropic, LlamaIndex, LiteLLM, OpenClaw et Hermes soutient toutes des versions de ces modèles, même s’ils les nomment différemment.

Ce tableau de modèles est une synthèse de la documentation des fournisseurs, des frameworks et des systèmes de référence plutôt qu’une affirmation d’un seul vendeur.

Notes du tableau : La recherche de fichiers hébergée d’OpenAI est un outil géré, Anthropic offre un harnais géré, Pinecone est un service vectoriel géré, tandis que vLLM, llama.cpp, Ollama, pgvector, Weaviate, Milvus, LangSmith auto-hébergé et OpenLIT prennent tous en charge une opération auto-gérée ou hybride dans des degrés variés.

Notes du tableau : Pinecone documente un plan de contrôle géré et des plans de données régionaux. Weaviate documente des vecteurs et des index inversés avec plusieurs types d’index vectoriels. pgvector ajoute la recherche exacte et approximative du plus proche voisin à Postgres. Milvus se positionne comme une base de données vectorielle open-source haute performance et évolutive, avec Zilliz Cloud comme option gérée.

Notes du tableau : OpenAI documente Responses comme son interface avancée pour les réponses étatiques et les outils intégrés. Anthropic documente l’API Messages et le contrat d’utilisation d’outils séparément des Agents Gérés. vLLM expose un serveur compatible OpenAI plus le support de l’API Messages Anthropic. Ollama documente les workflows d’embedding et de modèle locaux. llama.cpp documente les routes de chat, de réponses et d’embeddings compatibles OpenAI, plus les complétions de chat compatibles Anthropic.

Cette matrice de compromis est une inférence architecturale de la documentation officielle, pas un benchmark vendeur. La ligne de cohérence est plus importante que beaucoup de posts de blog ne l’admettent : Pinecone sépare les chemins d’écriture et de lecture, Hermes gèle la mémoire dans les prompts de démarrage de session, et OpenClaw promeut la mémoire durable à travers une révision échelonnée. Cela signifie que « mémoire mise à jour » et « mémoire visible pour la réponse actuelle » sont souvent des vérités différentes.

Modes de défaillance et atténuations

La plupart des assistants ne échouent pas parce que le modèle de base est « mauvais ». Ils échouent parce que le système environnant ment au modèle, l’ prive du bon contexte, laisse les outils dériver ou rend le débogage impossible.

La base de preuves pour ce tableau est large mais cohérente. La documentation des outils d’Anthropic rend clair que l’utilisation d’outils est une frontière de contrat. OpenAI Guardrails inclut la détection d’hallucination contre une base de connaissances de référence via File Search. SelfCheckGPT montre que la cohérence auto à travers les échantillons peut aider à détecter les affirmations non soutenues. Les résultats « Lost in the Middle » et les conseils contextuels d’Anthropic renforcent tous deux la même leçon opérationnelle : plus de jetons n’enlèvent pas le besoin de curation de contexte.

La pile d’atténuation préférée pourrait être ennuyeuse et répétitive : tracer chaque requête, versionner les prompts, évaluer la récupération indépendamment, garder les outils idempotents et exécuter des évaluations de régression avant de changer les routes ou la politique de mémoire. La documentation et le dépôt d’Evals d’OpenAI sont brutaux sur le pourquoi : sans évaluations, il est difficile et chronophage de comprendre comment les changements de modèle ou de prompt affectent votre cas d’utilisation. Cela s’applique tout autant aux routeurs et à la récupération qu’aux prompts.

Lecture supplémentaire

Si vous voulez approfondir, voici les sources primaires les plus utiles à garder ouvertes pendant la conception ou la révision d’une architecture d’assistant.

• OpenAI : Aperçu des Responses, Appel de Fonction, Utilisation d’Outils, Récupération, File Search, Evals et MCP pour les serveurs d’outils distants.

• Anthropic : Aperçu de l’API, Utilisation d’Outils, le contrat d’utilisation d’outils, Agents Gérés, Fenêtres Contextuelles et le connecteur MCP.

• MCP lui-même : l’Aperçu de l’Architecture et la Spécification valent le coup d’être lus directement, car ils expliquent proprement les hôtes, clients, serveurs, outils, prompts, ressources, transports et négociation de capacités.

• Frameworks et routage : Aperçu LangChain, documentation d’augmentation de contexte LlamaIndex, documentation de routage LiteLLM, documentation d’observabilité LangSmith.

• Runtimes auto-hébergés et systèmes d’assistance : vLLM, serveur llama.cpp, embeddings Ollama, documentation et dépôt OpenClaw, documentation et dépôt Hermes.

• Stockage et observabilité : Pinecone, Weaviate, pgvector, Milvus, OpenTelemetry, OpenLIT.

• Papiers de recherche : Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, Lost in the Middle et SelfCheckGPT.