Comment créer un assistant IA pour l’entreprise

Les Large Language Models (LLMs) comme GPT-4 et PALM sont de puissants moteurs de raisonnement qui constituent la base de la plupart des expériences d’IA générative textuelle que l’on voit aujourd’hui. Posez une question à un LLM, et il fournit généralement une réponse intelligente. Ils sont capables de puiser dans les profondeurs du savoir apporté par les données sur lesquelles ils ont été entraînés – ce que nous appelons la « connaissance du monde ».

Mais qu’en est-il des données propriétaires – par exemple, des informations réservées aux employés de votre entreprise ? Si vous posez à un LLM généraliste une question sur l’état de votre dernier deal client, il vous dira probablement qu’il n’a pas suffisamment de contexte pour répondre. Pire encore, il peut halluciner et inventer une réponse erronée, entraînant la propagation de fausses informations et des conséquences potentiellement graves sur les workflows.  ;

Appliquer des technologies d’IA générative comme ChatGPT aux données d’entreprise est complexe, compte tenu de la difficulté à gérer les permissions de sécurité, à faire évoluer l’infrastructure et à établir un knowledge graph large et de haute qualité. Dans cet article, nous passons en revue plusieurs approches pour faire fonctionner ChatGPT sur des données d’entreprise, leurs écueils, et la manière dont Glean les résout avec Glean Chat.  ;

Les défis du fine-tuning des LLMs sur des données d’entreprise

Dans la génération précédente de modèles de traitement du langage naturel (par ex. BERT, RoBERTa et d’autres), un paradigme populaire était le « fine-tuning » : on partait des poids d’un modèle fondation, puis on l’entraînait pour mieux répondre aux besoins de tâches spécifiques et à un domaine donné.  ;

Mais comment le paradigme du fine-tuning s’en sort-il à l’ère actuelle des LLMs ? Commençons par voir comment un LLM moderne comme ChatGPT est entraîné :

1. D’abord, un « modèle fondation » est entraîné sur des quantités massives de données (des milliers de milliards de tokens), ce qui nécessite une puissance de calcul immense (pour un coût de plusieurs millions de dollars). C’est le prix à payer pour construire les impressionnantes capacités de raisonnement et de génération que vous avez pu observer avec ChatGPT.
2. Ensuite, le modèle passe par une phase de fine-tuning au cours de laquelle il apprend à suivre des instructions en langage naturel et à s’aligner sur des valeurs humaines. Cette étape est essentielle pour garantir un comportement éthique du modèle, en évitant des risques potentiels comme la toxicité, les biais et les violations de la vie privée.

Une manière apparemment naturelle d’injecter des connaissances propriétaires dans un LLM consiste à le faire au stade du fine-tuning. Cependant, l’objectif du fine-tuning est d’améliorer les performances sur des tâches spécifiques, pas d’enseigner au modèle de nouvelles connaissances. Lorsqu’un LLM est fine-tuné sur des connaissances inconnues, cela augmente les hallucinations. En effet, nous apprenons essentiellement au modèle à générer des réponses sur des sujets pour lesquels il ne dispose pas d’une compréhension factuelle solide. C’est pourquoi nous rejoignons OpenAI lorsqu’il affirme que « le fine-tuning est mieux adapté à l’apprentissage de tâches ou de styles spécialisés, et est moins fiable pour le rappel factuel ».

Autrement, on pourrait essayer d’intégrer des données privées de l’entreprise dès la phase de pré-entraînement du modèle fondation via une adaptation au domaine (à l’image de BloombergGPT ou de MedPALM). Si cette approche est efficace pour adapter des LLMs à des domaines larges, elle présente plusieurs limites fondamentales lorsqu’il s’agit de construire un copilot d’enterprise AI :

1. Actualité – On peut fine-tuner des modèles sur un instantané des données de l’entreprise, mais que se passe-t-il lorsque ces données changent d’heure en heure ? Les utilisateurs veulent disposer des données les plus récentes et les plus pertinentes, mais entraîner continuellement le modèle pour y parvenir est coûteux et difficile à maintenir.
2. Permissions – Tous les employés n’ont pas accès à l’ensemble des données de leur entreprise. Des conversations sensibles peuvent avoir lieu entre le CEO et le CFO, des entretiens d’évaluation peuvent être réservés aux managers, et les ingénieurs peuvent ne pas avoir accès à Salesforce. Injecter « toutes » les données dans un LLM conduit à des réponses générées qui laissent fuiter des informations sensibles.
3. Explicabilité – Lorsque vos employés s’appuient sur un assistant pour les aider dans leur travail, vous voulez des réponses non seulement correctes, mais aussi vérifiables. Si un agent du support recommande une solution pour un ticket via un assistant, il doit pouvoir vérifier quel document a servi de source à la recommandation. Existe-t-il seulement un document source ? Le modèle en a-t-il halluciné un ? Le document fait-il autorité, ou a-t-il été mis à jour pour la dernière fois il y a 10 ans ? Y a-t-il un contexte supplémentaire dans le document qu’il faudrait connaître ? Tout cela est impossible à traiter si l’on fait confiance aveuglément aux générations du LLM.
4. Oubli catastrophique – La quantité de données propriétaires dans votre entreprise est de plusieurs ordres de grandeur inférieure à l’immense volume de données utilisé pour entraîner un LLM de base. Par conséquent, le fine-tuning du modèle comporte le risque qu’il oublie une grande partie de la connaissance générale du monde acquise initialement, ou qu’il n’apprenne pas les nuances de vos données propriétaires.

En conclusion, si le fine-tuning / l’entraînement des LLMs est séduisant pour améliorer les performances sur des tâches spécifiques, cette approche comporte trop de limites et de risques pour des assistants IA en environnement de travail.

Retrieval Augmented Generation : la recherche vectorielle ne suffit pas

Pour dissocier la capacité des LLMs à générer des réponses cohérentes et bien raisonnées de leur capacité (ou incapacité) à retrouver de manière fiable des connaissances factuelles, le système peut être conçu sous forme de pipeline. Nous récupérons d’abord les connaissances via un système de recherche séparé, puis ensuite nous les donnons au LLM à lire afin d’ancrer son raisonnement et sa synthèse. Cette approche est largement connue sous le nom de Retrieval Augmented Generation (RAG).  ;

• Les connaissances sont toujours aussi récentes et pertinentes que possible, puisque l’index de recherche, régulièrement mis à jour, est injecté dans le LLM au moment de la requête.  ;
• Le LLM n’accédera jamais à quelque chose auquel un utilisateur n’a pas accès.  ;
• Les utilisateurs peuvent consulter le sous-ensemble de documents qui ont été fournis au LLM et vérifier que la réponse générée est étayée par des informations exactes.
• L’oubli catastrophique ne se produit pas, car le système récupère les connaissances pertinentes au moment de la requête au lieu d’essayer de conserver toutes les connaissances dans le modèle.

Au cœur du RAG se trouve le composant de retrieval (récupération) — qui sous-tend la sécurité des données de votre entreprise et la pertinence des réponses générées dont vos équipes ont besoin pour réussir. Nous allons voir pourquoi il s’agit essentiellement d’un problème de recherche, ainsi que certaines exigences techniques liées à son implémentation en environnement entreprise.

Données : indexation scalable, tenant compte des autorisations

Lors de la construction de la couche data d’une solution de recherche d’entreprise, il existe plusieurs approches à considérer.  ;

La recherche fédérée via les API de chaque application est l’une de ces approches, mais elle s’accompagne d’inconvénients majeurs. L’API de recherche de chaque application a ses spécificités, ses exigences et ses limites de débit, ce qui la rend largement non scalable. La recherche fédérée aboutit également à des algorithmes de classement sous-optimaux (puisqu’ils ne comprennent que les données de cette application unique, et que les fonctionnalités de recherche dans les SaaS sont généralement sous-investies), ce qui se traduit au final par une mauvaise expérience de recherche.

Une meilleure solution consiste à construire un index centralisé en crawlant et en indexant les données provenant de toutes les sources. Cependant, concevoir un crawler scalable, tenant compte des autorisations, ainsi qu’une plateforme de recherche est un défi d’ingénierie qui peut prendre des années — qu’il s’agisse de monter à l’échelle jusqu’à des corpus de plusieurs milliards de documents, ou de créer un modèle de document unifié capable de gérer une grande variété de sources de données.  ;

Glean propose plus de 100 connecteurs préconfigurés qui se branchent sur des applications comme Google Drive, Slack, Jira, Salesforce, et bien d’autres — permettant aux utilisateurs de commencer à indexer leurs données rapidement et de gagner des années de développement. Pour les clients enterprise avec des centaines de milliers d’employés, des milliards de documents et des centaines de téraoctets de données, l’infrastructure de Glean (développée sur près de cinq ans) gère remarquablement bien ces volumes.

En indexant les données de toutes les sources dans une plateforme unique, Glean est en mesure de construire un graphe de connaissances inter-applications qui comprend en profondeur l’ensemble du contenu, du contexte et des collaborateurs au sein de l’organisation. En appliquant ensuite des algorithmes de ranking avancés pour faire remonter les résultats les plus pertinents, Glean offre une expérience de recherche nettement supérieure à celle des systèmes qui s’appuient sur les API des applications individuelles.

Pour toute entreprise qui cherche à libérer la valeur de ses données, une plateforme d’indexation scalable avec des connecteurs préconfigurés est préférable à la recherche fédérée. Glean fournit un accès clé en main à la recherche d’entreprise grâce à une solution d’indexation conçue pour le lieu de travail moderne, propulsé par les SaaS.  ;

Pertinence thématique : recherche hybride avec reranking

Avec un corpus indexé et scalable, le défi suivant consiste à récupérer les connaissances les plus pertinentes pour une requête donnée. Parmi les milliards de documents du corpus de votre entreprise, comment trouver ceux qui contiennent l’information la plus utile, la plus exacte et la plus à jour ?  ;

Pour aller chercher ces documents « pertinents » à injecter dans le LLM, la recherche vectorielle s’est imposée comme un excellent candidat. Le système « encode » chaque morceau de texte sous forme de vecteur de nombres, puis le stocke dans une base de données vectorielle. Lorsqu’une requête arrive, elle est encodée de la même manière. Le fichier le plus proche de la requête dans l’espace vectoriel est alors sélectionné comme l’information la plus pertinente.  ;

Les fournisseurs de bases de données comme Pinecone ou Weaviate ont beaucoup fait parler d’eux récemment. Ce dont on parle moins, en revanche, c’est que la qualité des embeddings vectoriels constitue souvent un goulot d’étranglement plus important que le fait de disposer d’une base de données pour héberger ces embeddings.  ;

Nous avons montré précédemment que si vous fine-tunez des encodeurs d’embeddings sur des données spécifiques à l’entreprise, vous pouvez obtenir une qualité d’appariement bien supérieure à celle de la plupart des modèles d’embeddings « génériques », open source (MPNet, E5, Instructor) ou closed source (OpenAI, Cohere). Cela nécessite évidemment une expertise pour entraîner ces modèles, ainsi que l’infrastructure nécessaire pour le faire en continu. Glean construit et affine progressivement ces capacités depuis plusieurs années.

Mais même si les embeddings sont puissants, les méthodes traditionnelles basées sur les mots-clés sont loin d’être obsolètes. En pratique, ce qui fonctionne bien, ce sont les méthodes « hybrides », qui combinent le meilleur des techniques classiques de recherche d’information et des embedders sémantiques modernes basés sur des réseaux de neurones (Thakur et al. (2021)). Ajuster un système hybride de retrieval et de reranking est une tâche extrêmement complexe : il faut entraîner des modèles à combiner des dizaines de signaux de ranking différents (dont la similarité sémantique, la correspondance de mots-clés, la fraîcheur des documents, des fonctionnalités de personnalisation, etc.) afin de produire un score final de pertinence. Nos modèles de recherche apprennent et s’améliorent en continu à partir de chaque requête pour proposer les résultats les plus pertinents à chaque employé.

{{richtext-banner-component}}

Personnalisation : graphe de connaissances étendu

Même avec un système de recherche textuelle parfait, les documents liés textuellement à la requête ne contiennent pas toujours les bonnes informations pour répondre à la question d’un utilisateur. Par exemple, un ingénieur peut demander où se trouvent les dernières spécifications de design. Or, les résultats de recherche peuvent contenir des centaines de documents / pull requests / messages sur le sujet. C’est aussi pourquoi nous pensons que l’utilisation d’une fenêtre de contexte beaucoup plus grande (jusqu’à 1 million de tokens) n’éliminerait pas le besoin de pertinence de recherche, car fournir des informations erronées ou obsolètes amènerait le modèle de langage à donner une réponse incorrecte.

Les méthodes à vecteurs denses sont spécifiquement conçues pour traiter le texte, alors qu’en réalité, d’autres types de données entrent en jeu. Pour rendre la recherche personnalisée pour chaque utilisateur, Glean construit en continu un graphe de connaissances de toutes les informations créées au sein de votre entreprise. Les nœuds de ce graphe de connaissances incluent :

• Contenus – Documents individuels, messages, tickets, entités, etc.  ;
• Personnes – Identités et rôles, équipes, départements, groupes, etc.  ;
• Activité – Signaux clés et comportement des utilisateurs, tendances de partage et d’utilisation

Les arêtes du graphe décrivent la manière dont toutes ces entités interagissent entre elles :

• Liens entre documents – Les documents reliés depuis d’autres documents, ou mentionnés par d’autres utilisateurs, ont davantage de chances d’être pertinents (PageRank – l’article à l’origine de Google)
• Interactions utilisateur-utilisateur – Les documents d’auteurs qui sont dans la même équipe, avec lesquels j’ai interagi par le passé, avec qui j’ai une réunion à venir, … ont davantage de chances d’être pertinents pour moi.
• Interactions utilisateur-document – Les documents que j’ai (ou qu’un membre de mon équipe a) créés/modifiés/partagés/commentés/… ont davantage de chances d’être pertinents pour moi

Intégrer les LLMs : améliorer la recherche elle-même

Les LLMs ne servent pas seulement à résumer et à synthétiser les résultats de recherche : ils peuvent aussi améliorer l’expérience de recherche dans son ensemble.  ;Par exemple, les LLMs permettent au copilote d’IA en entreprise d’effectuer une planification de requêtes avancée, en autorisant les systèmes à interpréter des commandes en langage naturel et à les traduire en un ensemble de requêtes de recherche qui produisent les résultats attendus. Une commande comme :  ;

"Passe en revue nos changements de code Glean Chat du mois dernier. Donne-moi une liste des améliorations que nous apportons à la fonctionnalité. Tu peux aussi consulter notre canal #project-glean-chat pour plus de discussions."  ;

…pourrait être traduite en deux requêtes de recherche, puis les résultats seraient synthétisés :

• Pull requests GitHub du mois dernier qui mentionnent « Glean Chat »
• Messages du canal Slack #project-glean-chat qui parlent de l’avancement du projet

Les LLMs peuvent également aider à amorcer des encodeurs spécifiques à un domaine pour les nouveaux clients en augmentant des données réelles rares avec des exemples générés par la machine (Promptagator, InPars). Comme les données de chaque client sont utilisées exclusivement pour entraîner ses propres encodeurs, les données synthétiques permettent de compenser l’absence de grands jeux de données in-domain tout en préservant le langage et la terminologie propres au client. On obtient ainsi des encodeurs adaptés à l’entreprise, personnalisés et qui généralisent mieux aux données de chaque client.

‍

Libérez dès aujourd’hui tout le potentiel de l’IA générative — pas demain

Construire un système ChatGPT prêt pour l’entreprise est loin d’être trivial. L’application des LLMs aux données d’entreprise s’accompagne d’exigences importantes en matière de fraîcheur des données, de permissions, d’explicabilité et d’oubli catastrophique. Si la recherche vectorielle et les embeddings ont suscité beaucoup d’intérêt récemment, développer des embeddings de haute qualité et l’infrastructure nécessaire pour les prendre en charge à grande échelle représente un défi d’ingénierie à part entière. Pour la plupart des entreprises, développer une solution interne afin de libérer la puissance des LLMs dans les données de travail nécessitera des années de travail et une expertise en machine learning, en recherche et en infrastructure de données scalable.  ;

Plutôt que de partir de zéro, Glean propose une solution clé en main de recherche d’entreprise et de gestion des connaissances, propulsée par les dernières technologies d’IA générative. La plateforme sous-jacente de Glean vous permet également de créer facilement des solutions ponctuelles sur mesure via nos APIs pour de nombreux workflows d’entreprise. Résultat : une implémentation en entreprise qui capte les bénéfices de l’IA générative à une fraction du coût et de la complexité d’une solution interne.  ;

Avec Glean, les entreprises peuvent rester concentrées sur des objectifs de plus haut niveau, comme générer de nouveaux revenus et innover, tout en accélérant leur réussite grâce aux dernières avancées en IA générative, sans attendre. Pour découvrir comment Glean aide les entreprises de référence à libérer la valeur de leurs données, demandez une démo dès aujourd’hui. Vous serez sur la voie d’une transformation de la manière dont votre organisation mobilise les connaissances, grâce à une recherche d’entreprise leader du marché et à une assistance conversationnelle propulsée par l’IA — sans les contraintes de la construire vous-même.