Trois façons de construire un chat de groupe IA : Pourquoi nous avons choisi la voie difficile

La question qui a tout déclenché

"Pourquoi chaque personnage ne peut-il pas avoir sa propre bulle de message, comme les autres apps ?"

Nous recevons souvent cette question. Et honnêtement, c'est une excellente question. La plupart des applications de chat affichent les messages sous forme de bulles séparées - une par personne. Alors pourquoi notre chat de groupe combine-t-il plusieurs réponses de personnages en un seul message ?

La réponse n'est ni la paresse ni la négligence. C'est un choix d'ingénierie délibéré né de mois d'expérimentation avec trois approches fondamentalement différentes des conversations de groupe IA.

Les trois architectures

Lors de la construction de conversations IA multi-personnages, chaque plateforme fait face à la même décision. Il y a exactement trois façons de le faire, chacune avec des implications profondes sur le coût, la qualité et l'expérience utilisateur.

1. Sortie structurée (Tableaux JSON)

L'approche la plus courante dans l'industrie. Vous demandez à l'IA de retourner un tableau JSON où chaque élément représente la réponse d'un personnage :

[
  {
    "speaker": "Sherlock",
    "emotion": "intrigué",
    "content": "Fascinant. Le motif de la boue suggère..."
  },
  {
    "speaker": "Watson",
    "emotion": "confus",
    "content": "Holmes, que voulez-vous dire ?"
  }
]

L'attrait :

• Un seul appel API, une seule consommation de crédits
• Facile à parser et à afficher en bulles de message séparées
• Peut inclure des métadonnées riches (émotions, actions, descriptions de scène)
• Parfait pour générer des suggestions de réponse utilisateur

La réalité :

• Seuls les modèles premium coûteux (Claude, GPT-4) supportent la sortie structurée de manière fiable - la plupart des modèles abordables peinent avec le formatage JSON cohérent
• Les erreurs de format cassent toute la réponse
• Les instructions JSON consomment des tokens, réduisant l'espace créatif
• Les modèles se sentent "contraints" - la créativité en souffre souvent
• Les restrictions de contenu deviennent plus strictes : le mode de sortie structurée déclenche souvent un filtrage de contenu plus agressif, rendant les scénarios de jeu de rôle matures ou audacieux plus susceptibles d'échouer
• Pollution du contexte : votre historique de conversation se remplit de structures JSON
• Complexité de gestion des erreurs : que se passe-t-il quand le parsing échoue en plein streaming ?

La plupart des plateformes de personnages tierces utilisent cette approche. Ça fonctionne, mais les contraintes sont réelles.

2. Appel d'outils (Mode Agent)

L'approche la plus "intelligente". L'IA décide quel personnage doit parler ensuite, appelle un outil pour l'indiquer, puis génère la réponse de ce personnage. Répéter jusqu'à ce que la scène soit complète.

L'IA pense : "Watson devrait réagir à cette révélation"
→ appelle l'outil : next_speaker("Watson")
→ génère la réponse de Watson
→ L'IA pense : "Maintenant Sherlock interviendrait"
→ appelle l'outil : next_speaker("Sherlock")
→ génère la réponse de Sherlock
...

L'attrait :

• Flux de conversation le plus naturel
• L'IA a un contrôle créatif total sur le rythme de la scène
• Chaque réponse de personnage obtient une qualité de génération dédiée
• Produit naturellement des messages séparés par personnage

La réalité :

• Plusieurs appels API = plusieurs frais de crédits
• La latence s'accumule : N personnages = N allers-retours
• Seuls les modèles haut de gamme (Claude, GPT-4) gèrent les appels d'outils de manière fiable - les modèles moins chers échouent souvent ou hallucinent des appels d'outils
• Gestion d'état complexe entre les appels
• Risque de boucles infinies ou de terminaison inattendue
• Cauchemars de débogage : les problèmes sont difficiles à reproduire

C'est "l'architecture de rêve" qui paraît magnifique sur le papier mais crée des maux de tête opérationnels à grande échelle.

3. Sortie texte libre (Notre choix actuel)

L'approche la plus simple. Demandez à l'IA d'écrire la scène naturellement, en la laissant décider comment présenter plusieurs personnages dans une prose fluide :

Sherlock se pencha en avant, les yeux perçants. "Fascinant. Le
motif de la boue suggère que notre suspect est venu du côté est."

Watson fronça les sourcils. "Holmes, que voulez-vous dire ? Ce n'est que de la boue."

"Que de la boue ?" Sherlock sourit. "Mon cher Watson, il n'y a
pas de 'que' quoi que ce soit."

L'attrait :

• Fonctionne avec tous les modèles IA, aucune fonctionnalité spéciale requise
• Liberté créative maximale - l'IA écrit naturellement
• Contexte propre : l'historique de conversation se lit comme un roman
• Excellente expérience de streaming
• Un seul appel, coûts prévisibles
• Le plus simple à implémenter et maintenir

La réalité :

• Tous les personnages dans un seul bloc de message
• Impossible de régénérer facilement la réponse d'un seul personnage
• La flexibilité de l'UI est limitée
• Les utilisateurs s'attendant à des bulles style chat peuvent être confus

Nous l'avons appris à la dure

Voici quelque chose que nous n'avons pas partagé publiquement avant : notre première version du chat de groupe utilisait l'appel d'outils.

Nous croyions en "l'architecture de rêve". L'IA décidant qui parle ensuite, chaque personnage obtenant une génération dédiée, de belles bulles de message séparées. C'était élégant. C'était intelligent. C'était aussi un désastre en production.

Les utilisateurs ont connu des coûts imprévisibles - parfois 3x ce qu'ils attendaient pour la même conversation. Les temps de réponse variaient énormément selon le nombre de personnages que l'IA décidait d'impliquer. Les modèles moins chers hallucinaient des appels d'outils ou se retrouvaient coincés dans des boucles. Nos logs d'erreurs se sont remplis de cas limites que nous n'avions jamais anticipés.

Après des mois de correctifs et de solutions de contournement, nous avons pris la décision difficile de reconstruire à zéro avec une sortie texte libre. Ça ressemblait à un pas en arrière. Mais parfois la solution "moins intelligente" est le choix le plus judicieux.

Pourquoi nous avons fait ce choix

Après avoir testé les trois approches de manière extensive - et en avoir déployé une en production - nous avons choisi la sortie texte libre pour le chat de groupe. Voici pourquoi :

La stabilité avant les fonctionnalités - La sortie structurée échoue de manière imprévisible. Quand votre chat de groupe plante en pleine conversation, les utilisateurs ne se soucient plus des bulles séparées - ils veulent juste que ça fonctionne. Le texte libre n'échoue jamais à cause de problèmes de format.

La qualité avant la quantité - Les formats contraints réduisent subtilement la créativité de l'IA. Quand nous avons comparé les sorties, le texte libre a constamment produit des interactions de personnages plus vivantes et naturelles. L'IA pouvait se concentrer sur la narration au lieu de la syntaxe JSON.

La prévisibilité des coûts - Le mode agent facture par personnage par réponse. Une scène à cinq personnages pourrait coûter 5-10x plus que prévu. Les utilisateurs méritent des prix prévisibles.

La compatibilité universelle - Nous supportons plusieurs modèles IA. Tous ne supportent pas la sortie structurée ou l'appel d'outils aussi bien. Le texte libre fonctionne partout, donnant aux utilisateurs plus de choix de modèles.

Le compromis que nous acceptons

Oui, nous sacrifions l'expérience "une bulle par personnage". Mais nous gagnons :

• Une fiabilité à toute épreuve
• Une meilleure qualité créative
• Des coûts prévisibles
• Un support de modèles plus large
• Un historique de conversation plus propre

Pour le jeu de rôle en groupe, où l'immersion compte le plus, nous croyons que ce compromis en vaut la peine.

Ce qui arrive : Mode Histoire

Voici quelque chose d'excitant : nous construisons un nouveau Mode Histoire qui utilise la sortie structurée.

Pourquoi l'approche différente ? Le Mode Histoire a des priorités différentes :

• Le contrôle précis de la scène compte plus que la créativité libre
• Les métadonnées riches (angles de caméra, signaux musicaux, sauts de chapitre) ajoutent de la valeur
• Le format est plus prévisible (structure claire de chapitres/scènes)
• Les utilisateurs s'attendent à une expérience plus "produite"

Différents cas d'utilisation méritent différentes architectures. Nous ne sommes pas dogmatiques sur une seule approche - nous choisissons ce qui sert le mieux les utilisateurs.

La vérité honnête

Il n'y a pas de solution parfaite pour les conversations IA multi-personnages. Chaque approche échange quelque chose de précieux contre autre chose.

D'autres plateformes qui montrent des bulles séparées ? Elles utilisent probablement la sortie structurée et acceptent ses limitations. Des plateformes avec un contrôle de scène plus "intelligent" ? Probablement l'appel d'outils avec des coûts et une latence plus élevés.

Nous avons choisi la voie qui priorise ce que nos utilisateurs valorisent le plus : un jeu de rôle en groupe fiable, créatif et économique.

L'expérience des bulles séparées est agréable. Mais pas au prix de tout le reste.

Ce que nous explorons

Nous expérimentons des approches hybrides :

• Parsing post-traitement : Utiliser des modèles légers pour diviser le texte libre en segments de personnages après la génération
• Mode structuré optionnel : Permettre aux utilisateurs avancés de choisir la sortie structurée quand ils ont besoin d'un contrôle précis
• Détection intelligente de scène : Identifier automatiquement les points de rupture naturels pour une meilleure présentation UI

L'objectif n'est pas de trouver la "bonne" réponse. C'est de continuer à améliorer l'expérience tout en préservant ce qui fonctionne.

---

Vous avez des idées sur comment le chat de groupe devrait fonctionner ? Nous serions ravis de vous entendre.