La place des modèles dans une architecture

Le modèle est une dépendance, pas l’architecture

La section 12.1 a décrit un modèle comme une fonction probabiliste accessible par une API. Dans une architecture, c’est un conteneur parmi d’autres, et généralement une petite partie du code. Un assistant de support client comporte un frontend de chat, un stockage des conversations, des intégrations avec les services de commandes et de remboursements, un index de recherche, une gestion des identités, de la journalisation, un transfert vers des agents humains et un pipeline de déploiement ; l’appel au modèle n’est qu’une ligne au milieu. Les questions d’architecture sont donc des questions familières posées à un nouveau type de dépendance : où s’exécute-t-elle, comment est-elle appelée, qu’y a-t-il entre elle et ses appelants, que se passe-t-il quand elle est lente, se trompe ou est indisponible, et qui répond de sa sortie ?

Bien répondre à ces questions compte davantage que de choisir le meilleur modèle du mois. Les modèles sont remplacés tous les quelques mois ; la passerelle, la conception des replis, le jeu d’évaluation et le processus de revue humaine durent des années. Les décisions de cette section sont des décisions significatives et difficiles à inverser au sens du chapitre 1 : elles méritent donc des enregistrements de décision ; le choix d’une version de modèle particulière, lui, doit être facile à changer.

Trois endroits où un modèle peut s’exécuter

API de modèles hébergés. Le fournisseur fait tourner le modèle et vous payez au token. Cela couvre les API propres aux fournisseurs de pointe (OpenAI, Anthropic et Google, entre autres) et les plateformes cloud qui revendent les modèles de plusieurs éditeurs au sein de votre compte cloud existant. C’est le moyen le plus rapide de démarrer, et il donne accès aux modèles les plus performants, sans accélérateurs à acheter ni à exploiter. Les contreparties sont une tarification au token qui augmente avec l’usage, des limites de débit fixées par quelqu’un d’autre, une dépendance à la disponibilité du fournisseur, des modèles retirés selon le calendrier du fournisseur, et des données qui sortent de votre périmètre. Les contrats, les conditions de traitement des données, les options de conservation nulle ou limitée et le traitement régional atténuent ce dernier problème sans le supprimer.

Modèles à poids ouverts auto-hébergés. Un modèle à poids ouverts publie ses poids entraînés : vous pouvez donc le faire tourner sur vos propres accélérateurs ou sur des accélérateurs loués, avec un serveur d’inférence comme vLLM. On peut citer les modèles de Meta (Llama), Mistral, Alibaba (Qwen), DeepSeek, Google (Gemma) et OpenAI (gpt-oss). Vous maîtrisez le chemin des données, la version exacte et le fine-tuning, et à volume élevé et régulier, le coût par token peut descendre bien en dessous des prix des API. En contrepartie, vous prenez en charge la planification de la capacité d’un matériel rare et coûteux, son taux d’utilisation (des accélérateurs inactifs coûtent autant que des accélérateurs occupés), les mises à niveau, les correctifs de sécurité et l’astreinte. Les licences comptent : certains modèles à poids ouverts utilisent des licences permissives comme Apache 2.0, tandis que d’autres utilisent des licences spécifiques assorties de conditions d’usage ou d’échelle, et la plupart ne publient pas leurs données d’entraînement. L’Open Source AI Definition de l’Open Source Initiative (version 1.0, octobre 2024) place la barre plus haut que les seuls poids ouverts. Une voie intermédiaire, utilisée par le chatbot de ce cours, consiste à appeler des modèles à poids ouverts via un fournisseur d’inférence tiers : tarification au token, aucun matériel, et la liberté de déplacer le même modèle ailleurs.

Modèles sur l’appareil. De petits modèles, souvent de quelques milliards de paramètres ou moins et quantifiés à une précision réduite, tournent sur des téléphones, des ordinateurs portables ou dans le navigateur. Ils offrent la confidentialité (les données ne quittent jamais l’appareil), le fonctionnement hors ligne, aucun coût par appel et une latence très faible, au prix de capacités bien moindres, d’une grande disparité de performances entre appareils, de téléchargements d’application plus lourds et de la difficulté de mettre à jour des modèles déjà déployés sur des millions d’appareils. Beaucoup de produits les combinent : un petit modèle sur l’appareil traite les tâches rapides et privées et transmet les plus difficiles au cloud.

Inférence en ligne et scoring par lots

La deuxième question est de savoir si un utilisateur attend. L’inférence en ligne appelle le modèle sur le chemin de la requête, si bien que des objectifs de latence s’appliquent : les utilisateurs remarquent le délai avant les premiers mots visibles, c’est pourquoi les réponses de chat sont diffusées en streaming, et ils abandonnent une requête qui prend de nombreuses secondes. Les appels en ligne ont besoin de délais d’expiration, de limites de concurrence et de capacité pour le pic du soir, exactement comme toute dépendance synchrone du chapitre 6.

Le scoring par lots traite de nombreux éléments sans que personne n’attende : étiqueter pendant la nuit deux millions de plats de la carte avec leurs allergènes, résumer les conversations de support de la veille, recalculer les embeddings d’une collection de documents. Le travail par lots peut utiliser le modèle suffisant le moins cher, s’exécuter quand la capacité est libre et réessayer sans précipitation. Plusieurs fournisseurs proposent des interfaces de traitement par lots asynchrones qui acceptent un fichier de requêtes et renvoient les résultats en quelques heures, avec une remise substantielle. Entre les deux se situe l’inférence asynchrone : une requête est mise en file d’attente, l’utilisateur est informé que le résultat suivra (une décision de remboursement par e-mail, un résumé de document en quelques minutes), et des workers vident la file à un rythme maîtrisé, en s’appuyant sur les files d’attente et la back pressure du chapitre 9 pour absorber les pics et les limites de débit des fournisseurs. Sortir le travail du chemin en ligne est l’une des décisions les plus efficaces qui soient pour le coût et la fiabilité.

Une AI gateway entre les applications et les modèles

Dès que plus d’une équipe ou d’une fonctionnalité appelle des modèles, une AI gateway dédiée se rentabilise. Elle joue le rôle qu’une API gateway joue pour les microservices, spécialisée pour le trafic vers les modèles. Les applications appellent un seul endpoint interne avec un seul format de requête et leur propre identité ; la passerelle détient les clés des fournisseurs, traduit vers l’API de chaque fournisseur, applique le routage et les replis, fait respecter les quotas et les budgets de dépenses par équipe, applique les limites de débit, enregistre chaque appel (modèle, version, nombre de tokens, latence, coût, résultat) pour le traçage et la répartition des coûts, peut mettre les réponses en cache, et offre un endroit où brancher de manière centralisée des garde-fous d’entrée et de sortie.

Les avantages sont architecturaux : le choix du fournisseur devient une décision de configuration au lieu d’une modification du code de chaque service, les clés ne sont plus dispersées entre les applications, les dépenses sont visibles par fonctionnalité, et une panne de fournisseur est traitée une seule fois. Les coûts sont ceux de tout intermédiaire partagé. C’est une nouvelle dépendance critique qui doit être hautement disponible, elle ajoute un peu de latence, et ses journaux deviennent un stockage concentré de prompts susceptibles de contenir des données à caractère personnel : les règles de caviardage et de conservation (voir protection de la vie privée dès la conception) s’y appliquent donc. Il existe des passerelles open source et des produits gérés, et les plateformes cloud intègrent des fonctions de passerelle ; en construire une légère est raisonnable pour un petit système, mais les quotas, le streaming, les nouvelles tentatives et la comptabilité représentent plus de travail qu’il n’y paraît.

Routage et cascades

Toutes les requêtes n’ont pas besoin du modèle le plus performant. Le routage décide d’emblée quel modèle doit traiter une requête, à l’aide de règles (la fonctionnalité, le niveau d’abonnement du client, la langue) ou d’un petit classifieur rapide. Dans l’assistant de support, où en est ma commande ? peut aller à un petit modèle bon marché qui appelle un seul outil, tandis qu’une réclamation portant sur trois problèmes distincts va à un modèle plus grand. Une cascade de modèles essaie au contraire d’abord un modèle moins cher et ne passe au niveau supérieur que lorsqu’une vérification indique que sa réponse n’est pas assez bonne. FrugalGPT de Chen, Zaharia et Zou (2023) a montré que des cascades bien réglées peuvent approcher la qualité du modèle le plus performant pour une fraction du coût.

Une cascade ne vaut que ce que vaut sa vérification d’escalade. Les vérifications fiables sont déterministes : la sortie échoue à la validation du schéma, une source citée n’existe pas, un champ obligatoire manque, une règle métier rejette la proposition. Un modèle vérificateur qui note la réponse est moins solide mais souvent utile. La déclaration de confiance d’un modèle sur sa propre réponse est le signal le moins fiable et ne doit pas être utilisée seule. Les cascades ont aussi des coûts : les requêtes escaladées paient deux appels et attendent les deux, il y a désormais deux modèles à évaluer et à maintenir en phase, et le plafond de qualité est fixé par la vérification, pas par le modèle performant. Mesurez le taux d’escalade ; si la plupart des requêtes sont escaladées, faites plutôt du routage.

Échelles de repli entre modèles et fournisseurs

Les API de modèles échouent de toutes les manières dont échouent les dépendances distantes, plus quelques-unes qui leur sont propres : des réponses de limite de débit (HTTP 429) quand un quota est épuisé, des erreurs de surcharge aux heures chargées, des réponses lentes qui dépassent un délai d’expiration, des pannes régionales et des modèles retirés à une date d’obsolescence. Les patrons du chapitre 9 s’appliquent directement, organisés en échelle de repli : une liste ordonnée d’échelons, chacun essayé lorsque celui du dessus échoue. Une échelle typique comprend le modèle principal ; le même modèle dans une autre région ou chez un autre hébergeur ; un modèle différent de capacités similaires chez un second fournisseur ; un modèle plus petit et plus rapide ; et enfin une réponse sans IA, comme un message préparé utile, les résultats de recherche du centre d’aide ou un transfert vers une personne.

Règles de conception d’une échelle : donnez à chaque échelon son propre délai d’expiration et à l’échelle entière une échéance globale, afin que l’utilisateur n’attende jamais quatre échecs lents d’affilée ; respectez Retry-After et placez un modèle soumis à une limite de débit en période de refroidissement (un simple disjoncteur) au lieu de le bombarder ; ne réessayez pas les erreurs qui échoueront de nouveau, comme une requête trop volumineuse ou rejetée par un filtre de contenu ; validez la sortie à chaque échelon, car un échelon inférieur peut produire des réponses de forme légèrement différente ; évaluez chaque échelon avec le même jeu d’évaluation, car les prompts doivent souvent être ajustés pour chaque modèle ; et enregistrez l’échelon qui a répondu, afin que les tableaux de bord de qualité puissent distinguer une réponse dégradée d’une réponse normale.

Les fonctionnalités d’IA de ce cours en sont un petit exemple réel. Les réponses d’ArchitectBot et la notation des réponses rédigées aux tests sont générées via une échelle de plusieurs modèles à poids ouverts servis par un fournisseur d’inférence, essayés dans un ordre de préférence fixe. Un modèle qui renvoie une réponse de limite de débit est mis au repos pendant la durée demandée par le fournisseur (dans des bornes fixées), une requête qui échoue, dépasse son délai ou renvoie une réponse inutilisable passe à l’échelon suivant, ces échelons partagent un budget de temps global, et un second fournisseur sert de dernier échelon. La conception sacrifie un peu de qualité de réponse sur les échelons inférieurs au profit de la disponibilité : une réponse un peu moins bonne est préférable à pas de réponse du tout.

Les humains dans la boucle

L’expression humain dans la boucle désigne plusieurs conceptions différentes, et il est utile de préciser laquelle on entend. Approbation avant effet : le modèle rédige un brouillon, une personne l’approuve (un remboursement au-delà d’un plafond, une réponse à un régulateur, une modification en production). Revue après effet : les sorties prennent effet immédiatement et des personnes examinent un échantillon ou les cas signalés. Escalade : le modèle traite ce qu’il peut et transmet le reste à une personne, avec la conversation et les éléments de preuve. Retour : des personnes étiquettent ou corrigent les sorties pour constituer des jeux d’évaluation et améliorer les prompts.

Chaque conception a des conséquences architecturales. L’approbation crée une file d’attente qui doit être dimensionnée pour le volume de pointe, comme la file d’examen des fraudes de la section 12.1, et ajoute une latence qui se compte en minutes ou en heures. Les personnes qui approuvent des centaines de bonnes suggestions finissent par approuver sans lire (biais d’automatisation) : l’interface doit donc montrer les éléments de preuve et l’action exacte, mettre en évidence ce qui est inhabituel, et mesurer à quelle fréquence les relecteurs modifient la proposition ; un taux de modification proche de zéro est un signal d’alerte, pas un succès. Les transferts ont besoin du contexte complet pour que le client n’ait pas à se répéter. Le contrôle humain exigé par la réglementation pour certains usages est plus exigeant encore : la personne doit comprendre les limites du système et pouvoir passer outre ses décisions.

Construire ou acheter, et comment choisir un modèle

La question « construire ou acheter » a plus de deux réponses. Vous pouvez acheter une fonctionnalité d’IA complète au sein d’un produit que vous utilisez déjà (l’assistant d’un éditeur de logiciel de support) ; construire sur des API hébergées ; faire du fine-tuning d’un modèle pour votre tâche ; auto-héberger des poids ouverts ; ou, rarement, entraîner votre propre modèle. Utilisez la grille de lecture stratégique de la conception pilotée par le domaine : achetez pour les capacités génériques comme la transcription de réunions, et construisez là où l’IA touche votre domaine cœur et où vos propres données vous donnent un avantage. Quoi que vous construisiez, gardez le code propre à chaque fournisseur derrière un port avec un adaptateur par fournisseur, et évitez de dépendre de fonctionnalités qu’un seul fournisseur propose, sauf si leur valeur justifie la dépendance au fournisseur.

Choisissez les modèles avec votre propre jeu d’évaluation, pas avec les classements publics. Les classements mesurent des tâches générales qui peuvent ne pas ressembler aux vôtres, et certains modèles ont été optimisés pour eux. Définissez les critères et leurs pondérations avant de tester, comme pour toute décision pondérée, puis présélectionnez deux ou trois candidats et mesurez-les sur quelques centaines d’exemples réels. Attendez-vous à ce que la réponse soit une combinaison, par exemple un petit modèle pour le routage et un plus grand pour les cas difficiles, plutôt qu’un seul gagnant.