Comment nous choisissons l'IA pour chaque fonction
Quand on conçoit une fonction fondée sur l'intelligence artificielle, la question « quel modèle utiliser » semble devoir trouver sa réponse une fois pour toutes, au départ. Dans la pratique de NovLore, cela ne s'est pas passé ainsi : avec le temps, nous avons constaté que différentes tâches du produit avaient des besoins si différents qu'un seul fournisseur, aussi bon soit-il, ne pouvait pas toutes bien les servir. Cet article raconte pourquoi, et comment est fait aujourd'hui le système qui en est né.
Le problème qui a motivé le choix
Au début, Scintilla — l'assistant d'écriture de NovLore — regroupait deux tâches différentes dans un seul canal : la conversation avec l'utilisateur et la génération du tableau de bord de l'œuvre (personnages, lieux, intrigue) à partir de cette conversation. Elles semblaient liées, mais avaient des besoins opposés : la conversation a besoin de répondre vite, alors que générer des données structurées cohérentes a besoin de prendre le temps de raisonner. Un seul fournisseur, optimisé pour l'un des deux besoins, pénalisait systématiquement l'autre.
La solution n'a pas été de chercher un fournisseur qui ferait bien les deux choses. Ç'a été d'arrêter de les traiter comme la même tâche.
Six domaines, pas un seul
Aujourd'hui, chaque fonction d'IA de NovLore déclare son propre domaine — correction, réécriture, chat, structure, chapitre, transcription — et chaque domaine peut avoir un fournisseur différent en premier choix. Le chat de Scintilla, par exemple, utilise un modèle choisi pour la rapidité de réponse ; la génération d'un chapitre entier, que l'utilisateur lance en sachant qu'il devra attendre, utilise au contraire un modèle choisi pour la qualité de la prose sur un texte long.
| Domaine | Ce qu'il fait | Ce qui compte le plus |
|---|---|---|
| Chat | conversation avec l'assistant | rapidité de réponse |
| Correction | coquilles et cohérence grammaticale | précision, coût bas |
| Réécriture | modification d'un texte sélectionné | qualité stylistique |
| Structure | données structurées sur personnages/intrigue | fiabilité du format |
| Chapitre | génération d'un chapitre entier | qualité sur texte long |
| Transcription | prévu, pas encore actif | — |
Aucun de ces choix n'est définitif : un panneau d'administration permet de changer le fournisseur et la réserve pour chaque domaine sans toucher au code, parce que le coût et la qualité relative des modèles changent dans le temps plus vite que le logiciel.
Pourquoi sept fournisseurs et pas un seul « assez bon »
Avec un seul fournisseur, chacune de ses interruptions de service — et cela arrive à tout le monde, même aux meilleurs — devient une interruption de tout le produit. La solution la plus courante est d'avoir une réserve ; la moins évidente, mais la plus solide, est que la réserve ne doit pas passer par le même canal que le premier choix. Si le premier choix et la réserve sont deux routages différents vers le même fournisseur en amont, une indisponibilité de ce fournisseur fait tomber les deux ensemble.
C'est pourquoi, quand le premier choix d'un domaine est un agrégateur qui donne accès à plusieurs modèles avec une seule clé, la réserve va délibérément vers un fournisseur direct et indépendant. C'est une vraie redondance, pas seulement sur le papier.
Ce que voit l'utilisateur quand la réserve se déclenche
Rien, si le système fonctionne comme il doit. Si le fournisseur en premier choix pour un domaine ne répond pas, le passage à la réserve est transparent : la requête aboutit quand même, et seule une donnée technique interne enregistre que c'est le second choix qui a répondu. Sur le streaming — les réponses qui apparaissent mot par mot, comme dans le chat — la réserve ne peut se déclencher qu'avant l'arrivée du premier morceau de texte : une fois la réponse commencée, changer de fournisseur en cours de route produirait un texte cousu de deux styles différents, pire que d'attendre quelques secondes de plus.
La transparence de la réserve n'est pas un détail technique pour passionnés d'infrastructure : c'est la différence entre un utilisateur qui remarque un ralentissement occasionnel et un utilisateur qui voit une erreur en train d'écrire son roman.
Le routeur comme unique point de passage
Pour que ce système tienne dans le temps, chaque fonction d'IA du produit — y compris celles à sortie structurée et celles en streaming — passe par un routeur interne unique, jamais directement par les fournisseurs. C'est un choix qui coûte en discipline (aucun raccourci, même pas pour une fonction « temporaire ») mais qui paie d'une manière précise : quand un fournisseur change ses conditions, ou qu'il en arrive un nouveau qui vaut la peine d'être ajouté, le changement se fait à un seul endroit, pas dans dix points d'accès écrits à des moments différents.
Questions fréquentes
Pourquoi ne pas toujours utiliser le modèle le plus puissant disponible ?
Parce que « plus puissant » n'est pas la même chose que « plus adapté à la tâche ». Un modèle excellent sur du texte long et créatif peut être lent et coûteux pour un chat qui doit répondre en une seconde ; l'utiliser partout ferait paraître lente même la partie du produit censée être instantanée.
L'utilisateur peut-il choisir quelle IA utiliser ?
Pas directement sur chaque message : le choix se fait par domaine et il est géré par qui administre le produit, en fonction de la qualité et de la fiabilité observées dans le temps. C'est un choix délibéré — le laisser à l'utilisateur reporterait sur lui une décision technique qui exige de surveiller en continu sept fournisseurs différents.
Que se passe-t-il si la réserve elle aussi ne répond pas ?
L'opération échoue avec une erreur explicite, et dans le cas d'une action à crédits, le débit est annulé automatiquement sur le même lot d'où il avait été pris : l'utilisateur ne paie pas pour une requête restée sans réponse.
Ce système ralentit-il le développement de nouvelles fonctions d'IA ?
À court terme oui, légèrement : ajouter une fonction demande de passer par le routeur au lieu d'appeler directement une API. À moyen terme c'est l'inverse, parce que chaque nouvelle fonction hérite gratuitement de la gestion des erreurs, de la réserve et du suivi des coûts déjà construits une fois pour toutes.