L'IA est aussi intelligente que les données qu'on lui donne

Dans l'article précédent, nous avons expliqué pourquoi un RAG naïf ne suffit pas pour construire une IA d'entreprise fiable. La question suivante est logique : si le problème n'est pas le modèle, qu'est-ce qui fait la différence ?

 La réponse est la même sur chacun de nos projets chez Sparkle : ce sont les données. Leur qualité, leur structure, la manière dont elles sont préparées et reliées entre elles. C'est le levier n°1, et de loin le plus sous-estimé.

Garbage in, garbage out

Il y a un adage en informatique qu'on répète depuis des décennies : garbage in, garbage out. Si vous donnez de mauvaises données à un système, vous obtiendrez de mauvaises réponses. Avec l'IA, c'est encore plus vrai qu'avant.

Une IA se nourrit de texte. Et plus ce texte est pur, structuré et bien organisé, meilleures seront les réponses. Le problème, c'est que les documents d'entreprise ne sont pas conçus pour être lus par une IA. Ils sont conçus pour des humains : des PDF avec des mises en page complexes, des tableaux Excel, des présentations PowerPoint, des procès-verbaux.

Donner tout cela tel quel à une IA revient à espérer qu'elle saura spontanément s'y retrouver. En pratique, elle ne le peut pas.

• Un travail de transformation est nécessaire : convertir les documents pensés pour des humains en données structurées pensées pour l'IA. C'est un investissement, mais c'est celui qui a le plus d'impact sur la qualité finale.

Chez Sparkle, c'est la première étape de chaque projet. Avant même de choisir un modèle ou de configurer un agent, nous analysons et transformons les données du client. Plus on investit d'énergie dans cette phase, meilleurs seront les résultats en sortie.

Le piège du découpage aveugle

Un modèle d'IA ne peut pas lire l'intégralité d'une base documentaire en une fois. Les modèles ont une capacité de lecture limitée, ce qu'on appelle la *fenêtre de contexte*. La solution standard consiste à découper les documents en petits morceaux et à ne servir à l'IA que les morceaux pertinents au moment de répondre.

Le problème, c'est que dans la plupart des implémentations naïves, ce découpage est fait mécaniquement : tous les X mots, on coupe, sans se soucier du sens.

Le résultat : l'IA reçoit des morceaux d'information sortis de leur contexte. Elle ne sait pas que le paragraphe A est lié au paragraphe B, que le tableau C illustre le texte D, ou que la conclusion E fait référence à l'introduction F. Elle travaille avec des fragments isolés, et ses réponses reflètent cette fragmentation.

Créer des liens : le knowledge graph

Pour dépasser ce découpage aveugle, on crée ce qu'on appelle un knowledge graph, un graphe de connaissances. L'idée : on ne se contente pas de stocker des morceaux de texte, on les relie aux concepts de l'entreprise.

Prenons un exemple concret. Une entreprise a une politique de télétravail. Cette politique est mentionnée dans le règlement intérieur, dans un email de la direction, dans un compte-rendu de CE, et dans une FAQ RH. Quatre documents différents, quatre contextes différents, mais un seul concept.

Avec un knowledge graph, quand un utilisateur pose une question sur le télétravail, l'IA ne cherche pas simplement les morceaux de texte qui "ressemblent" à la question. Elle identifie le concept et va chercher toutes les informations qui y sont reliées, dans tous les documents concernés.

• L'agent ne récupère plus du contexte sur base de ce qui ressemble à la question, mais sur toutes les informations en lien avec les concepts de la question.

La différence de qualité dans les réponses est considérable.

La question du temps

Un autre piège fréquent : la temporalité. Imaginons deux documents qui parlent du même sujet, mais écrits à six mois d'intervalle. Entre-temps, la politique a changé. Si l'IA ne sait pas lequel est le plus récent, elle risque de donner une réponse basée sur des informations obsolètes, ou pire, de mélanger les deux.

C'est pour cela qu'on ajoute des métadonnées temporelles à chaque information : quand elle a été produite, si elle est toujours d'actualité, si elle a été remplacée. La plupart des implémentations naïves ignorent complètement cette dimension. Pour certains de nos clients, elle est pourtant indispensable.

La recherche hybride

Tous ces éléments convergent vers ce qu'on appelle la recherche hybride. Au lieu de chercher uniquement par similarité sémantique ("quel bout de texte ressemble le plus à la question ?"), on combine deux approches :

• ‍La recherche sémantique : trouver les informations dont le sens est proche de la question posée.
• ‍Le filtrage par métadonnées : affiner les résultats par date, catégorie, concept, ou tout autre critère structuré.

Les deux ensemble, c'est ce qui fait la différence entre une réponse approximative et une réponse fiable. C'est aussi ce qui permet aux agents de disposer d'outils de recherche réellement efficaces, capables de récupérer l'ensemble du spectre des informations pertinentes.

Le modèle n'est pas le héros de l'histoire

C'est le point central de cet article, et celui que nous constatons systématiquement chez Sparkle :

• Un excellent modèle qui répond avec des informations partielles restera moins bon qu'un modèle plus léger qui répond avec exactement le bon contexte.

Une fois que l'information est bien préparée (structurée, reliée, datée, accessible via des outils de recherche hybride), le choix du modèle devient secondaire. On peut même parfois utiliser un modèle moins coûteux sans perte de qualité, parce que le vrai travail a été fait en amont, sur les données.

À l'inverse, investir dans le modèle le plus puissant du marché sans préparer les données, c'est optimiser le mauvais levier.

Avant de courir après le dernier modèle qui fait le buzz, investissez dans vos données. C'est moins visible, mais c'est ce qui conditionne tout le reste. Si vous vous demandez par où commencer, [parlons-en](https://www.sparkle.tech/contact).

‍

Article suivant : Coût, vitesse, qualité : les choix stratégiques derrière chaque projet IA
Article précédent : Méfiez-vous des IA naïves