Une exigence essentielle pour transformer l'IA générative d'un simple outil de découverte de connaissances en un véritable assistant de travail réside dans la disponibilité d'informations fiables et complètes. Une IA générative pour le travail prête pour l'entreprise ne vaut que par les données d'entreprise qui y sont connectées. Plus le nombre de sources de données du corpus d'une entreprise connectées à l'IA est élevé, plus les réponses générées par l'IA sont pertinentes et complètes. Les utilisateurs peuvent ainsi faire confiance aux réponses sans se demander si l'IA avait accès à toutes les informations pertinentes au moment de les générer.
Pour y parvenir, il faut un modèle de document unifié robuste. L'information d'entreprise n'est pas simplement un ensemble de textes propres et uniformes : il s'agit d'un ensemble diversifié de données qui nécessite une conception de schéma réfléchie afin d'être traité et intégré à un modèle pour obtenir des résultats optimaux.
Dans ce blog, nous explorerons pourquoi un modèle de document unifié est si essentiel pour une IA générative robuste destinée au travail, et ce que vous devez savoir lorsque vous envisagez d'en créer un ou d'en adopter un.
Des sources de données à profusion
Ce que nous appelons « documents » lorsque nous parlons d'un « modèle de document unifié » est en réalité un schéma nuancé qui représente toutes les sortes de données auxquelles une entreprise accorde de l'importance :
- Documents collaboratifs comme Google Docs
- Ressources wiki publiées comme les pages Confluence
- Paires question-réponse comme StackOverflow
- Tickets ou cas dans des outils comme Jira, Zendesk ou Salesforce
- Gestion des changements et code source comme GitHub
- Messagerie et conversations comme Slack ou Teams
- Profils de candidats dans des systèmes de suivi des candidatures comme Greenhouse
- Fichiers de conception dans des outils comme Figma
- E-mails
- Données sur les personnes dans des outils comme BambooHR
- Ressources multimédias dans des outils comme Docebo ou Gong
- Événements de calendrier
Pour offrir une expérience de recherche ou d'IA générative complète qui fournit exactement l'information recherchée par un utilisateur, cet ensemble diversifié de données doit être correctement structuré et documenté – un processus qui implique des complexités considérables :
- Identités des utilisateurs
- Permissions et contrôle d'accès
- Stockage de texte non structuré et d'attributs structurés présents dans les documents
- Relations entre les utilisateurs et les documents
- Compréhension des différentes manières dont les utilisateurs interagissent avec le contenu
- Exploration et gestion des mises à jour de tout ce qui précède
- Compréhension du contexte dans lequel les documents sont partagés au sein de l'entreprise
- Compréhension des documents
- Indexation
- Scoring
- Choix de présentation pour la page de résultats de recherche
- Duplication des données
- Dépréciation des documents
Pour compliquer encore les choses, chaque nouvelle source de données présente un type de problème nouveau et unique à résoudre.
Prenons par exemple le problème de la capture des relations entre les utilisateurs et les documents. Un Google Doc peut avoir un créateur, ainsi que plusieurs éditeurs et commentateurs. De nombreux autres utilisateurs peuvent être mentionnés (@) dans le corps ou les commentaires du document. Un ticket Jira peut avoir un créateur et un assigné, tandis que d'autres utilisateurs y sont en copie, participent en tant que commentateurs ou sont mentionnés (@) dans les commentaires. Une PR GitHub peut avoir un auteur, éventuellement plusieurs relecteurs et commentateurs, ainsi que plusieurs autres utilisateurs mentionnés (@) dans les commentaires.
Toutes les sources de données ne partagent pas l'ensemble des rôles mentionnés – mais un modèle de classement qui doit offrir une expérience utilisateur à travers toutes ces sources de données doit effectivement comprendre tous ces types de relations dans le contexte de la source de données. Il doit pondérer une relation de co-édition sur un Google Doc par rapport à une relation de mention (@) sur un ticket Jira. C'est là qu'un modèle unifié bien conçu pour capturer les relations utilisateur-document commence à avoir de l'importance : il devient le fondement sur lequel des modèles de classement comme ceux mentionnés ci-dessus sont exprimés et mis en œuvre.
Toutes ces relations doivent non seulement être capturées et mémorisées par le système, mais différentes parties du système peuvent vouloir les exploiter à leur avantage de diverses manières. Par exemple, un modèle de classement pour un système de recherche peut vouloir augmenter le rang d'un document particulier si l'utilisateur qui effectue la requête y a récemment été mentionné (@). Ou encore, mettre en avant un document en particulier si l'utilisateur qui effectue la requête a posé une question sur ce document par le passé, à laquelle un autre utilisateur a récemment répondu.
{{richtext-banner-component}}
Points communs et particularités
Les documents issus de ces sources de données disparates présentent une grande variété. Prenons les fils de discussion sur Slack par rapport aux pages wiki sur Confluence par rapport aux enregistrements vidéo sur Gong. Les manières dont chaque document est rédigé ou créé diffèrent – tout comme leurs objectifs, leur contenu, leurs attributs et les façons dont les utilisateurs les stockent et les recherchent. Même au sein du paradigme de la messagerie et des commentaires, les fils de messages Slack varient par leur nature par rapport aux fils de commentaires sur les Google Docs, les PR GitHub, les tickets Jira et les chaînes d'e-mails.
Alors, comment résoudre la grande variété de problèmes posés par cette grande variété de sources de données ? La bonne conception commence par la prise en compte de ce qui rend ces sources de données identiques et de ce qui les distingue. C'est la partie du processus de modélisation où une bonne dose d'intuition et de jugement entre en jeu – et parvenir à un modèle parfaitement calibré porte ses fruits sur le long terme. C'est le moment critique où une conception innovante n'est pas seulement avantageuse, mais nécessaire pour construire un produit durable, évolutif et fonctionnel.
Une approche idéale consiste à disposer d'un modèle de document qui traite les parties communes des sources de données de manière unifiée, tout en ayant la flexibilité de gérer leurs particularités. Ce n'est pas seulement un atout appréciable, mais une nécessité pour un bon système de recherche et d'IA générative. Cela permet l'évolutivité et maîtrise non seulement la complexité du logiciel, mais aussi la complexité du modèle (au sens de l'IA / ML), ce qui se traduit par une meilleure expérience utilisateur.
Cela permet également de résoudre le problème de recherche de manière complète et cohérente. Lorsque les utilisateurs envisagent un assistant de travail d'IA générative, ils ne cherchent pas à répondre à leurs besoins d'information une source de données à la fois. Au contraire, ils ont besoin d'une solution rapide et immédiate capable de leur fournir la réponse, quel que soit l'endroit où résident les données. Il est donc important que le système soit capable de mettre toutes les différentes sources de données sur un pied d'égalité et d'effectuer son apprentissage de manière exhaustive à travers toutes les sources de données. Disposer d'un modèle de données unifié exceptionnel s'avère déterminant pour y parvenir.
Une IA utile nécessite un modèle unifié
Construire un excellent modèle capable de soutenir une IA générative véritablement utile à l'entreprise exige un soin méticuleux. Vous devrez réfléchir à la manière de modéliser des champs susceptibles d'être partagés entre toutes les sources de données, tout en permettant une extensibilité maîtrisée. Si le modèle unifié n'est pas conçu avec soin, chaque nouvelle connexion de source de données nécessitera une refonte, ce qui compromet votre capacité à vous adapter aux dizaines de sources de données dans lesquelles le savoir de votre entreprise est fragmenté.
Au-delà du contenu principal d'une source de données, vous devrez également comprendre comment exploiter les métadonnées (étiquettes, structure, personnes associées) – faute de quoi, des lacunes béantes apparaîtront dans les signaux nécessaires pour offrir aux utilisateurs ce qu'ils attendent. Il s'agit d'un processus long et coûteux, qui laisse une grande marge d'erreur et de dérive du périmètre.
Envie d'en savoir plus ? Vous souhaitez vous lancer dès aujourd'hui – et non demain – avec une IA générative véritablement prête pour l'entreprise ? Inscrivez-vous à une démo Glean !
