Support IA : l'architecture hybride dépasse les chatbots

Repenser le support IA avec une architecture hybride

Dans un contexte où les entreprises cherchent à optimiser leur service client, un client a récemment exprimé le besoin d'un chatbot qui soit non seulement sécurisé et précis, mais aussi capable de fournir des réponses en temps quasi réel. Ce type de demande devient de plus en plus courant, car les entreprises reconnaissent que la sécurité des données, la latence et la qualité des réponses ont un impact direct sur leurs résultats financiers. Les systèmes d'IA qui ne parviennent pas à répondre à ces exigences risquent de perdre la confiance des utilisateurs et de coûter cher. Selon un rapport d'IBM, le coût moyen mondial d'une violation de données pourrait atteindre 4,44 millions de dollars d'ici 2025.

Cependant, les chatbots génériques et les modèles de langage de grande taille (LLMs) disponibles sur le marché ne parviennent souvent pas à répondre aux attentes des entreprises. Bien que puissants, ces modèles sont limités par des contraintes telles que les limites de tokens, l'utilisation du contexte et les hallucinations. Ces limitations deviennent particulièrement évidentes lorsque l'on exige des connaissances spécifiques à un domaine et des formats de réponse stricts. La question se pose alors : comment construire une IA qui puisse répondre comme un expert, en s'appuyant sur des données réelles, tout en restant rapide, sécurisée et contrôlable ?

Mon expérience dans le développement de modèles m'a appris que la solution ne réside pas dans un seul modèle ou une seule technique. Il faut adopter une approche architecturale plus large qui sépare ce que le modèle sait de la manière dont il répond, tout en combinant apprentissage et récupération.

Les défis principaux

Limites de contexte efficaces

Les modèles de langage modernes annoncent des fenêtres de contexte allant jusqu'à 128 000 tokens. Cependant, dans la pratique, leur capacité d'attention se dégrade bien avant d'atteindre ces limites. Lorsqu'un grand volume de texte est utilisé comme contexte, les modèles ont tendance à sous-utiliser les informations situées au milieu de l'invite, un phénomène connu sous le nom de biais de primauté-récence.

Augmenter la taille du contexte ne garantit pas de meilleures réponses. Dans les environnements d'entreprise, où les bases de connaissances peuvent s'étendre sur des millions de tokens, cette approche n'est pas viable.

Utilisation faible des informations de longue traîne

Les LLMs peuvent ignorer des informations pertinentes, les mal interpréter ou surpondérer des sections non pertinentes, même lorsque le bon contenu est présent dans l'invite. Des études comme "Lost in the Middle" soutiennent cette théorie, montrant que les entrées à long contexte conduisent souvent à un raisonnement incomplet si elles ne sont pas soigneusement contrôlées. Cela rend les stratégies naïves de "tout déverser dans l'invite" peu fiables pour des systèmes de support complexes et spécifiques à un domaine.

Compromis entre précision et performance dans la récupération

La récupération introduit une latence et des coûts de calcul réels. Si vous récupérez trop, le contexte accru augmente le temps de réponse et dilue l'attention du modèle. Si vous récupérez trop peu, vous augmentez le risque d'hallucinations. Le véritable défi n'est pas la récupération elle-même, mais la récupération précise — garantir le minimum de contexte suffisant requis pour l'exactitude sans submerger le système ou le modèle.

Hallucinations en cas de contexte manquant

Les LLMs s'abstiennent rarement de générer des réponses même lorsque des informations pertinentes manquent. Au lieu de cela, ils répondent avec confiance par des réponses génériques ou fabriquées. Dans un cadre de support, ce comportement est inacceptable. Il impacte directement la confiance, l'exactitude et la conformité.

Une étude approfondie de ces contraintes a clairement montré qu'ajouter plus de contexte n'était pas la solution. Nous avions besoin d'une architecture plus intelligente.

La réponse : une architecture hybride

Notre travail a constamment pointé vers une approche hybride combinant génération augmentée par récupération (RAG) avec des modèles de langage finement ajustés. L'idée clé était que le fine-tuning et la récupération résolvent des problèmes différents. Le fine-tuning apprend au modèle comment répondre, et la récupération fournit quoi répondre. Nous avons constaté que forcer une méthode à faire les deux entraîne inefficacité, instabilité ou coûts élevés. Nous avons donc conçu un système permettant à ces deux composants d'opérer à partir de leurs forces respectives.

Utilisation de RAG pour la précision à travers la récupération

Nous avons délibérément évité de submerger le modèle avec de grands volumes de documents bruts. À la place, nous avons construit une base de connaissances recherchable et curatée à partir de nos paires de questions-réponses internes, manuels de produits, documentation technique et matériaux de référence sur les politiques et configurations. Au moment de l'inférence, le récupérateur sélectionne uniquement les morceaux de contenu les plus pertinents et les insère dans l'invite. Cela garantit que les réponses sont ancrées dans des données réelles vérifiées.

Nous avons constaté que cette approche réduisait considérablement les taux d'hallucination, améliorait l'exactitude factuelle et augmentait la vitesse de réponse en maintenant les fenêtres de contexte petites et spécifiques aux requêtes. Cependant, s'appuyer uniquement sur RAG s'est avéré insuffisant. Même lorsque la précision de la récupération était très élevée, les sorties présentaient une grande variabilité en termes de ton, de structure, de formatage et de niveau de détail procédural inclus. Ces sorties indiquaient que, bien que factuellement précises, les réponses n'étaient ni structurées de manière cohérente ni formatées de manière fiable.

Dans un cas d'utilisation de chatbot spécifiquement conçu pour améliorer la convergence des demandes, l'évaluation a montré que même si le petit modèle de langage avait accès à près de 100 % de contexte correct, la précision des sorties n'était que d'environ 70 %. Le modèle était incapable d'extraire du sens des entrées à long contexte et échouait à maintenir le ton conversationnel nécessaire pour guider les utilisateurs vers des discussions techniques plus approfondies ou des réunions de suivi.

Cela a révélé une limitation fondamentale de la récupération : RAG fournit des informations, mais ne peut pas instruire un modèle sur la manière de raisonner ou de communiquer dans un domaine spécifique.

Fine-Tuning de Qwen : enseigner au modèle comment répondre

Pour améliorer la cohérence, le ton et le raisonnement, nous avons affiné le modèle Qwen sur environ 1 000 paires de questions-réponses d'experts soigneusement sélectionnées pour s'aligner sur le domaine cible du modèle. L'objectif n'était pas d'enseigner au modèle des faits. Nous voulions qu'il apprenne à appliquer un langage spécifique au domaine, à maintenir la voix et le style de communication de l'entreprise, à suivre un format de réponse cohérent, à raisonner de manière procédurale et à gérer les cas particuliers qui se présentent dans les flux de travail de support.

Le fine-tuning ajuste le comportement d'un modèle, pas ce qu'il sait — et cette distinction est importante. Affiner l'ensemble du modèle peut entraîner un oubli catastrophique et des coûts de calcul excessifs. Pour limiter ces risques, nous avons utilisé des adaptateurs de faible rang (LoRA). Les adaptateurs LoRA permettent le fine-tuning d'un petit ensemble de matrices d'adaptateurs tout en préservant la majorité des connaissances générales du modèle de base. Ils réduisent également la mémoire GPU requise pour le fine-tuning et produisent des performances presque équivalentes à celles d'un fine-tuning complet du modèle.

Les résultats étaient clairs. Le modèle est devenu substantiellement plus cohérent et nuancé. Pour des questions stables et procédurales, il produisait des réponses correctes de nombreuses fois sans nécessiter de récupération. Cependant, comme prévu, le modèle avait des difficultés avec les questions sur les nouvelles fonctionnalités, les politiques mises à jour et les requêtes factuelles de longue traîne.

Dans le même exemple de chatbot, le fine-tuning a amélioré l'alignement du ton à environ 90 %, mais a diminué l'exactitude factuelle à environ 50 %. La leçon a encore une fois été renforcée : le fine-tuning ne remplace pas la récupération.

Pourquoi ni RAG ni le fine-tuning à eux seuls n'étaient suffisants

Ces expériences nous ont donné une clarté sur les compromis impliqués :

• Les systèmes uniquement RAG offrent un meilleur ancrage factuel et une actualité, mais souffrent d'une cohérence de ton médiocre et d'une latence plus élevée.

• Les systèmes uniquement fine-tunés offrent une cohérence de voix et de structure supérieure, mais échouent lorsque les connaissances changent ou que des faits de longue traîne sont nécessaires.

Choisir une seule approche signifiait accepter les faiblesses de l'autre. Combiner un modèle fine-tuné avec RAG a produit de meilleurs résultats que chaque méthode seule. La précision du ton s'est améliorée à environ 75 % — mieux que RAG, qui n'avait aucun contrôle de ton fiable, bien que légèrement en dessous des 90 % du modèle fine-tuné. L'exactitude factuelle s'est améliorée à environ 73 %, dépassant à la fois le modèle fine-tuné seul (environ 50 %) et RAG seul (environ 70 %). La compréhension par le modèle fine-tuné du contexte du domaine et du format de sortie attendu lui a permis de mieux utiliser et appliquer le contexte récupéré qu'un modèle de base ne le pourrait.