Pourquoi les LLM d’entreprise échouent avant même de calculer, et ce que change l’ingénierie du contexte

Pourquoi les LLM d’entreprise échouent avant même de calculer, et ce que change l’ingénierie du contexte
5 min de lecture

Quand un système d’IA d’entreprise fournit une réponse peu fiable, le diagnostic habituel met en cause le modèle. Pourtant, selon l’article source, un échec plus fréquent et plus difficile à repérer tient ailleurs : un grand modèle de langage (LLM) peut raisonner correctement à partir d’un contexte mal sélectionné.

  • Les LLM d’entreprise échouent souvent à cause d’un contexte mal sélectionné, et non à cause du modèle.
  • Une question ambiguë, comme la définition de « jour » ou le choix de la population, produit une réponse fausse avant tout calcul.
  • Les systèmes conçus autour du modèle surpassent les modèles seuls sur les benchmarks d’entreprise.
  • Le système doit clarifier l’intention, appliquer les règles de l’étude et rendre chaque résultat traçable.

Les remèdes les plus courants sont un modèle plus puissant, un prompt plus long, davantage de documents récupérés ou une fenêtre de contexte plus large, c’est-à-dire la quantité d’informations qu’un modèle peut traiter à la fois. Chacun peut aider, mais aucun ne résout directement ce problème. Dans les systèmes analytiques, le calcul peut être juste et l’explication cohérente, et la réponse rester fausse : le système a choisi de mauvaises preuves, suivi un mauvais lien entre des tableaux ou donné à un terme métier ambigu une définition que l’utilisateur n’avait pas en tête. L’erreur intervient avant tout calcul.

Prenons une question simple : combien d’heures Cam travaille-t-il par jour en moyenne ? Le mot « jour » n’est pas défini. Il peut désigner chaque jour calendaire de la période, une année de travail standardisée, chaque enregistrement de planning ou chaque date où Cam a effectivement travaillé. Diviser le total des heures par les jours calendaires donne une moyenne plus basse que la diviser par les jours réellement travaillés dès que Cam a des jours de repos. Un contrôle classique, qui vérifie que les totaux se recoupent, ne détecte pas nécessairement ce mauvais choix de dénominateur.

Une question métier, un programme d’analyse

La question « Quelle marque a amélioré la confiance ce trimestre ? » ressemble à une simple recherche. Y répondre suppose pourtant de trancher plusieurs points : quelle question du questionnaire mesure la confiance, quelles vagues d’enquête forment « ce trimestre », quel est le périmètre des répondants, si les résultats sont pondérés et ce qui compte comme une amélioration.

L’article prend un cas illustratif. Deux tableaux croisés semblent correspondre à la demande, avec une description qui ne diffère que de quelques mots. Le premier, pondéré, porte sur l’ensemble des répondants et montre une légère hausse. Le second, non pondéré, ne porte que sur les répondants qui connaissent la marque et montre une légère baisse. Un outil de recherche fondé sur la similarité les classerait presque à égalité. Un système qui retient le premier résultat fournit une réponse sourcée et argumentée, qui peut être fausse, sans que le choix effectué apparaisse dans le résultat final. Un système fondé sur un parcours, lui, relève la différence de population et de pondération et demande à l’utilisateur quel périmètre retenir. Le coût de cette question de clarification est, selon l’auteur, bien inférieur à celui d’un chiffre faux qui ressemble au bon.

Des benchmarks qui mesurent des systèmes

Les travaux de recherche vont dans le même sens. Spider 2.0, un benchmark de text-to-SQL d’entreprise composé de 632 problèmes issus de flux de travail réels, a été publié fin 2024. Son système le plus performant, un agent construit sur o1-preview, a résolu environ 17 % des tâches, contre environ 91 % pour les meilleurs systèmes sur le benchmark original Spider. Le classement a depuis évolué : sa piste Snow affiche un score de 96,7 %, soumis par un éditeur, issu d’un système d’agent. Les scores sont envoyés par les équipes elles-mêmes, et l’article note que les meilleurs résultats reposent sur des systèmes conçus autour du modèle plutôt que sur des modèles seuls.

Allonger le contexte ne suffit pas non plus. Une étude de Chroma, intitulée « Context Rot », constate que les modèles deviennent moins fiables à mesure que la longueur de l’entrée augmente, même sur des tâches simples, et que des distracteurs d’apparence semblable aggravent le problème.

Un parcours plutôt qu’un tas

Face à l’incertitude, le réflexe consiste à fournir davantage d’informations au modèle. Or cela peut multiplier les interprétations concurrentes. L’approche décrite consiste à organiser le contexte de façon séquentielle : d’abord l’intention de l’étude, puis la structure du questionnaire, les questions et leurs définitions, les segments, les marchés, les vagues et les règles de pondération, et enfin le tableau croisé qui contient la preuve. Chaque couche hérite des contraintes de celle qui la précède.

Anthropic présente l’ingénierie du contexte comme la suite naturelle de l’ingénierie du prompt, en la définissant comme la gestion de l’ensemble du contexte d’un agent, considéré comme une ressource finie. L’article juge ce cadrage pertinent, mais le place une étape en amont : il s’agit de savoir ce que signifie la question et quelles preuves peuvent y répondre. Pour le cas de la confiance dans la marque, la démarche suit cinq étapes : résoudre l’intention, appliquer les règles de l’étude, identifier les sources, valider le parcours, puis calculer avec un outil autorisé et présenter le résultat avec sa définition, sa base de répondants, sa pondération et sa source.

L’auteur insiste enfin sur la traçabilité. Chaque résultat doit pouvoir être relié à sa table source, à sa définition, à ses filtres, à sa pondération, à sa période et au calcul utilisé.

S’abonner
Notification pour
guest

0 Commentaires
Le plus ancien
Le plus récent Le plus populaire
0
Nous aimerions avoir votre avis, veuillez laisser un commentaire.x