Données contextuelles : Pourquoi l’AI ne se limite pas au volume

Les deux dernières années de l’AI d’entreprise ont été consacrées à l’expérimentation, et il a été facile d’y rester. Les modèles ont continué de changer, les délais de production ont donc baissé, et chaque amélioration a révélé de nouvelles capacités que les équipes voulaient intégrer, ce qui signifie plus de portée, plus de tests, plus de retard. Un cercle vicieux, où le modèle progresse comme la raison pour laquelle rien n’a été expédié. Ce cycle est en plein essor et les entreprises sont prêtes à passer de l’expérimentation à l’AI qui leur apporte réellement de la valeur ajoutée. Ce qui compte le plus dans ce changement, ce n’est pas le modèle que vous choisissez, ni même la quantité de données dont vous disposez, mais le fait que vos données contiennent le contexte qu’un modèle doit être exact.

Le choix des modèles est moins important maintenant, car les meilleurs modèles de poids ouvert et de frontière ont convergé. Kimi K3 et Claude Fable 5 sont déjà suffisamment proches pour que, pour la plupart des tâches d’entreprise, vous ayez du mal à les distinguer, le modèle ouvert coûte une fraction du prix, et la prochaine version ne fera qu’obtenir un gain incrémentiel, et non pas des bonds comme les années précédentes. L’effort d’ingénierie a été transféré vers le faisceau : outils, mémoire, évals et garde-corps enroulés autour du modèle, où le problème difficile s’est déplacé pour maintenir les charges de travail agents en fonctionnement pendant des heures avec un minimum de surveillance humaine. Gagner consiste désormais à créer une flexibilité invisible pour l’utilisateur, où le flux de travail exécuté hier s’exécute de la même manière aujourd’hui, tandis que le faisceau change de modèle en dessous pour optimiser le coût, les performances ou tout autre KPI important. Le modèle devient un détail de mise en œuvre.

Cette flexibilité repose sur la couche la plus importante que les entreprises peuvent exploiter : les données en dessous. N’oubliez pas que le plus ancien adage informatique s’applique toujours ici : déchets entrants, déchets sortants. Le meilleur harnais au monde s’appuie sur ce que vous lui donnez, et les données les plus importantes que vous pouvez lui fournir sont les vôtres. Elle a toujours été le différenciateur de l’AI dans l’entreprise, et maintenant que tout le monde exécute essentiellement les mêmes modèles, il ne reste plus qu’un seul. Toutes les entreprises se reposent sur le volume, des dizaines de tables, de documents et de tickets, mais le volume seul aggrave un modèle, pas l’améliore. Ce qui rend un modèle précis, c’est de savoir quel tableau est canonique, quel document est à jour et comment le client d’un système se rapporte au client d’un autre.

La qualité des données est la clé du succès de AI

Dans une enquête IDC menée auprès de chefs d’entreprise sur ce qui détermine la réussite de l’AI, 94 % ont déclaré que la qualité des données était décisive. L’étude est rarement si proche de l’unanimité. Le rapport nomme également les principales causes de mauvaise qualité, et ce sont les suspects habituels : données redondantes, données cloisonnées et données obsolètes. Je noterai que la capacité du modèle n’apparaît pas dans cette liste, et qu’elle ne s’applique pas non plus. Aujourd’hui, les problèmes qui nuisent à l’AI d’entreprise sont les mêmes que ceux qui ébranlent l’analytique au cours des 20 dernières années. Ce qui a changé, c’est leur apparence, car chacun de ces trois problèmes de données aggrave les réponses d’un modèle à sa manière.

Les données obsolètes produisent des réponses qui ressemblent à des hallucinations, mais qui ne le sont pas. Le pipeline de récupération répond à la politique de retour de l’année dernière, l’agent le cite à un client avec aisance et confiance, et l’entreprise est désormais sur le point d’obtenir des conditions de remboursement qu’elle a retirées il y a plusieurs mois. Les ingénieurs qui examinent l’incident le consignent comme une hallucination, mais le modèle a fait son travail correctement. Ce sont les données qui ont été erronées.

Les données redondantes sont aléatoires. Lorsqu’il existe six copies quasi identiques d’une table et que deux d’entre elles ne sont pas d’accord, il existe deux manières d’y remédier. Si la récupération ne concerne qu’une seule copie, la copie reçue par le modèle est une question de hasard, c’est-à-dire que la qualité de la réponse porte désormais une variable aléatoire. Si la récupération fait surface, le modèle doit détecter la contradiction, mais dans une mer de contexte, il peut se concentrer sur une copie et ignorer complètement l’autre. Dans tous les cas, la même question posée deux jours différents peut renvoyer deux réponses différentes, et ni l’utilisateur ni l’ingénieur ne peuvent expliquer pourquoi sans suivre la récupération.

Les données cloisonnées transforment les connaissances partagées en connaissances locales. Un silo est rarement une restriction délibérée. Plus souvent, la manière dont un système a été mis en œuvre signifie que les données ne doivent être visibles que par quelques équipes. Par conséquent, une question générale sur les connaissances de l’entreprise renvoie des réponses disparates en fonction de la tranche de données que le modèle peut voir. Deux employés peuvent poser la même question, recevoir deux réponses différentes, mais les deux réponses sont fidèles aux données partielles qui les sous-tendent. Le problème se complique à mesure que de plus en plus d’outils d’AI s’appuient sur les données de l’entreprise. Un outil qu’une équipe s’appuie sur sa tranche obtiendra des réponses différentes, et finalement des décisions différentes, des outils que les autres équipes s’appuient sur les leurs, et ce qui commence lorsque deux employés reçoivent des réponses incohérentes se termine lorsque des systèmes automatisés agissent sur des informations contradictoires, l’entreprise supportant le coût de ce conflit.

Cette combinaison entraîne un diagnostic erroné prévisible. Lorsqu’un modèle capable s’exécute sur des données médiocres, les ingénieurs voient les mauvaises réponses et concluent que le modèle est en faute, les équipes réagissent en évaluant un remplacement et le cycle d’expérimentation recommence. Le remplacement du modèle ne change rien, car les données en dessous restent les mêmes.

Les données ne sont pas du contexte

Si les mauvaises données aggravent les réponses d’un modèle, il faut savoir quelles données pertinentes fournissent qu’un modèle capable n’a pas déjà. La réponse est le contexte, et je peux expliquer la différence entre les données et le contexte avec une analogie avec la vie quotidienne. Imaginons qu’un ami vous envoie une photo de ses vacances : Il est sur un bateau, sur un lac et le soleil est au soleil. Vous disposez désormais de données, et vous pouvez décrire la scène avec précision à n’importe qui : une personne, un bateau, un lac, à peu près à midi.

Vous l’appelez ensuite, et vous obtenez le contexte. Ce jour-là, le vent explosait 20 nœuds, suffisamment fort pour rendre toute la traversée rugueuse. Le moteur est mort à mi-chemin et la famille a fui pendant une heure. Ses enfants ont décidé que la dérive était la meilleure partie du voyage, et c’est l’histoire qu’ils raconteront à Thanksgiving pour la prochaine décennie. C’est la même scène, mais vous connaissez maintenant des choses très différentes. La photo vous indique ce qui est visible, tandis que l’ami vous dit ce qui s’est passé, pourquoi cela a été important et à quoi il est lié.

La mise en correspondance avec l’entreprise est directe : Vos données sont la photo, et vos employés sont l’ami. Dans votre organisation, un analyste sait que, parmi deux tableaux de revenus qui semblent interchangeables, un seul porte les chiffres corrigés Q3. Quelqu’un dans le service financier sait que le terme « client » dans le système de facturation désigne l’entité juridique, tandis que le terme « client » dans le système de produit désigne l’utilisateur final, et que la configuration des deux a généré un numéro de désabonnement suffisamment erroné pour qu’il doive être corrigé devant le PDG. C’est là que viennent réellement les connaissances des entreprises : des personnes qui peuvent vous dire pourquoi cet ensemble de données est le bon pour l’analyse et non l’autre ensemble de données qui capture superficiellement les mêmes informations. Le modèle ne voit rien de tout cela, il ne voit que la photo.

Les données contextuelles sont la manière dont vous obtenez le compte de l’ami sous une forme qu’une machine peut utiliser. Il comporte deux composants principaux. Les graphiques de connaissances codent les relations et la provenance : ce tableau remplace celui-ci, cette mesure provient de ces trois sources, ce compte dans le système de vente est la même entité que ce compte dans la facturation. Les couches sémantiques s’appuient sur les définitions de vos employés de manière informelle et les rendent explicites et gouvernées : ce que signifie « chiffre d’affaires », quel domaine client est canonique et quel pipeline l’équipe financière a réellement confiance.

Les données sensibles au contexte sont également à l’origine de la transition du vocabulaire du secteur de l’ingénierie rapide à l’ingénierie contextuelle. L’ingénierie rapide consistait à bien formuler la question. L’ingénierie contextuelle consiste à déterminer ce que le modèle peut voir au moment où il répond, et c’est un problème d’architecture et non une compétence d’écriture.

Figure : pile à deux couches. Couche supérieure : Modèles interchangeables, échange libre. Couche inférieure : La couche contextuelle durable (graphique de connaissances + couche sémantique) alimente chaque modèle avec les mêmes connaissances institutionnelles. 

Le modèle suivant ne corrigera pas les mauvaises données

Les lecteurs qui travaillent à proximité de la couche de modèle soulèvent généralement la même objection à ce stade. Si les fenêtres contextuelles ont dépassé un million de jetons et que le raisonnement s’améliore à chaque version, pourquoi ne pas évoluer pour compenser les données désordonnées ? C’est une question assez posée, et l’évolutivité est utile. Une fenêtre plus longue signifie moins de coupes arbitraires à ce que le modèle peut voir, et un meilleur raisonnement détecte plus de contradictions qu’auparavant. Ce que l’on ne peut pas faire, c’est réparer les entrées incorrectes.

Un document obsolète dans une fenêtre de millions de jetons est toujours obsolète, vous payez simplement plus pour le traiter. Un meilleur raisonnement appliqué aux tables contradictoires ne résout pas la contradiction ; il produit une défense plus claire de la copie choisie par le modèle. L’adage mentionné plus haut dans cet article a survécu à une croissance exponentielle du calcul pendant six décennies, et il survivra également à celle-ci.

La qualité de l’AI est un problème d’intelligence des données

Lorsque la qualité de la réponse est décevante, l’instinct d’un leader de l’AI techniquement profond est de travailler sur la couche modèle (affiner le corpus de l’entreprise, distiller, évaluer plus dur) ou sur la couche harnais (ajouter des tentatives, serrer les barrières). Aucun des deux ne fonctionne, car aucun ne touche les données. Le réglage précis des données redondantes obsolètes déplace le problème dans les poids du modèle, où il n’apparaît plus dans aucun journal de récupération qu’un ingénieur peut auditer. Un faisceau plus solide ne résout pas non plus le problème, car il ne fait qu’entraîner une défaillance plus gracieuse de l’agent.

La couche de contexte est l’endroit où cet effort doit aller. Les modèles sont remplacés et les faisceaux reconstruits, mais la couche contextuelle reste, et tout ce que vous y ajoutez s’appuie sur ce qui existe déjà. Chaque relation que vous codez, chaque définition que vous donnez explicite, et chaque élément de connaissances institutionnelles que vous déplacez de la tête d’un analyste vers un graphique améliore chaque modèle qui s’exécute sur celui-ci, celui que vous déployez aujourd’hui et celui que vous échangez au prochain trimestre. 

Un modèle commence à perdre de la valeur le jour de son expédition, car un modèle plus performant est déjà en route. À l’heure où je rédige ce rapport, trois points séparent le modèle frontière principal de son challenger open source sur l’indice d’intelligence artificielle et l’ordre changera dans quelques semaines. La couche de contexte se déplace dans la direction opposée. Il gagne de la valeur grâce à tout ce que vous y ajoutez, et chaque modèle que vous exécutez hérite de cette valeur.

Construire cette couche est un problème d’intelligence des données, pas un problème de modèle. Le catalogage, la lignée, la résolution des entités et la sémantique gouvernée sont des machines qui capturent ce que vos collaborateurs savent et le placent là où le modèle peut l’utiliser. Je ne ferai pas semblant de résoudre ce problème, le codage des connaissances humaines tacites à l’échelle de l’entreprise est vraiment difficile. Mais c’est le problème difficile sur lequel il faut travailler, car c’est la seule partie de la pile qui ne se banalise pas.

Les modèles conserveront les places boursières en tête, et ce n’est pas grave, car un harnais flexible vous permet de les échanger en un après-midi. Ce que vous ne pouvez pas échanger, c’est ce que votre organisation sait. N’importe quel modèle peut regarder la photo, mais seule votre couche de contexte sait ce qui s’est passé ce jour-là sur le lac.