Au cours des cinq dernières années, nous avons patiemment fait de Glean la solution de recherche d'entreprise leader du marché. Comme aucune autre solution de gestion des connaissances sur le marché, Glean est capable de fournir des résultats de recherche et de chat à jour, qui tiennent toujours compte des autorisations et sont personnalisés, tout en s'adaptant et en indexant en toute fluidité des corpus de plusieurs milliards de documents.
Cependant, parvenir à ce stade a été un parcours semé de défis déroutants. Contrairement à ce que certains pensent, une solution improvisée consistant à superposer un chatbot IA à des fichiers d'entreprise ne leur donnera pas les résultats escomptés. Une meilleure approche consiste à bâtir une solution de recherche qui alimente le modèle avec les bonnes réponses, à chaque fois — mais construire les fondations d'une recherche prête pour l'entreprise est un véritable défi d'ingénierie qui requiert des années de travail et une expertise de pointe en machine learning, en recherche et en infrastructure de données évolutive.
Si vous vous êtes récemment intéressé à la création d'un ChatGPT interne et que vous cherchez à indexer toutes vos informations d'entreprise grâce à la recherche vectorielle et aux embeddings, j'aimerais partager quelques éléments qui vous aideront dans votre démarche. Dans cet article, je parlerai plus particulièrement du crawler — le composant fondamental qui maintient les résultats de recherche et les réponses de chat constamment à jour, conformes aux autorisations et exacts.
Rapide, mais résilient
Votre crawler interagit-il avec des systèmes tiers ? Dans ce cas, l'infrastructure doit tolérer les pannes face à une variété de nuances propres à chaque source de données. Lorsque nous avons construit le nôtre, nous avons dû prendre en compte :
- Comment définir une erreur transitoire de façon uniforme au sein du système, dans le contexte de chaque source de données ?
- Comment nous assurer de réessayer de manière appropriée, que ce soit l'API ou le système qui rencontre ces erreurs transitoires ?
- Lorsque des tentatives se produisent, comment savoir ce qui a déjà été effectué et n'exécuter que ce qui doit être relancé ?
Nous en avons conclu qu'il nous fallait un système permettant de définir facilement une unité unique d'exécution réessayable, ainsi que toutes les étapes associées, du début à l'achèvement.
Par exemple, pour chaque invocation d'API, nous devons suivre :
À chaque étape, le système doit être capable de signaler comment gérer les erreurs. Si l'étape 3 réussit mais que l'étape 4 échoue, il doit conserver cet achèvement partiel d'une manière ou d'une autre et s'assurer que seule l'étape 4 est relancée. Cela implique que l'étape 4 doit être définie comme une unité d'exécution réessayable distincte quelque part dans le système. Sans ces précautions, les résultats présenteraient un contenu manquant — et l'achèvement partiel pourrait être mal géré. Par exemple, si nous disposons de toutes les données d'un document mais qu'il nous manque certaines de ses autorisations, nous ne devrions pas le faire apparaître dans les résultats.
Nous disposons également de différents types de tâches (comme les mises à jour incrémentielles, les crawls complets et le traitement des webhooks) qui aident à éviter l'obsolescence de nos résultats. Toutes les sources de données ne peuvent pas offrir une fidélité totale dans tous les modes de travail, il est donc important d'utiliser plusieurs types distincts pour obtenir une image complète. Un crawl complet ou un webhook peut identifier les documents supprimés — un crawl incrémentiel ne le peut pas.
Prioriser ces types de tâches par rapport à un quota d'API unique est également essentiel pour éviter de surcharger le système de la source de données au-delà de ses limites de débit. Votre système doit être capable d'attribuer des pondérations entre ces charges de travail et d'appliquer les limites de quota avant que chaque unité de travail ne commence à s'exécuter. S'il rencontre des erreurs, il doit signaler à la couche d'application qu'elle doit être plus stricte dans la limitation de toutes les charges de travail, en complément des mécanismes de reprise courants pour cette unité d'exécution particulière (par exemple, le backoff exponentiel).
Il est également essentiel que votre système soit suffisamment flexible pour gérer différentes politiques de limitation de débit d'API, car elles varient d'une application à l'autre. Les limites de débit peuvent être déterminées dynamiquement par le serveur, être globales pour l'ensemble du tenant, différentes pour chaque API, limitées par utilisateur, varier selon l'heure du jour ou de la semaine, ou toute combinaison de ces facteurs. Si votre système est incapable de gérer une variété de politiques, vous recevrez constamment des alertes concernant des erreurs de crawl. Certaines sources de données vous pénalisent même en cas de dépassement — vous finirez donc par ralentir considérablement, même pour les infractions les plus mineures. Dans le pire des cas, la source de données bloquera tout simplement votre crawl.
Des crawlers flexibles et résilients, capables de répondre à ces exigences diverses, constituent les fondations d'une expérience fluide et sans faille sur laquelle les utilisateurs peuvent compter.
Prévenir l'obsolescence
Il est également important de veiller à ce qu'aucune donnée obsolète ne subsiste dans le système. Si le système reçoit des mises à jour limitées sur le contenu supprimé, comment garantir que toutes les données stockées sont à jour ? C'est plus difficile qu'il n'y paraît.
Il est extrêmement difficile pour n'importe quel système de savoir immédiatement quand un contenu est supprimé, mais c'est essentiel pour garantir la sécurité des données et la pertinence des informations. Certaines sources de données font apparaître les documents supprimés dans les appels d'API ou envoient des événements webhook lors d'une suppression, mais cela n'offre pas toujours une couverture à 100 %.
- Les événements webhook et les points de terminaison d'API peuvent être peu fiables — souvent envoyés « au mieux », et généralement ni retentés ni récupérés en cas de problème de leur côté ou du nôtre. Cela peut faire apparaître de la documentation obsolète — ce qui peut être catastrophique ! Vous avez supprimé un document sensible qui n'aurait jamais dû être téléchargé, ou qui a été partagé par erreur ? Il pourrait continuer à être présenté à tout le monde. Vous avez ajouté un nouveau document important que les employés doivent consulter dès aujourd'hui ? Il pourrait ne pas apparaître avant des heures, voire des jours.
- Gérer les conditions de concurrence du crawler et tenter de modéliser ce qui se passe sur la source de données à partir de bribes d'information est délicat. Imaginons par exemple qu'un utilisateur supprime un document par erreur, puis le restaure hâtivement depuis la corbeille. Cependant, les informations reçues lors du crawl peuvent s'embrouiller ou être traitées dans le désordre. Le document est-il dans la corbeille ? Ou non ? Ces complications risquent de faire que les plateformes fournissent des réponses obsolètes et dépassées — aboutissant à un système auquel les collaborateurs hésitent à faire confiance.
Pour concevoir des crawlers robustes qui luttent contre l'obsolescence des données, il nous faut une couche supplémentaire pour purger les données périmées. Nous procédons ainsi en réalisant des crawls réguliers de l'ensemble du corpus, puis en supprimant les données que nous n'avons pas rencontrées une fois le crawl terminé. Toutefois, pour éviter les suppressions erronées, notre crawler s'assure également que ces crawls complets aboutissent avant de supprimer les données non détectées, et signale aussi les suppressions qui semblent légitimes mais qui affectent un volume notablement important du corpus.
En traitant l'obsolescence de manière exhaustive et sécurisée de cette façon, nous garantissons que les résultats de chaque recherche ou requête ne renvoient jamais une réponse issue d'un contenu obsolète ou qui n'existe plus.
Une évolutivité adaptée à tout corpus
Plus important encore, le crawler doit fonctionner correctement face à une échelle immense. L'optimisation et la synchronisation sont essentielles, et tout doit tenir ensemble, qu'il s'agisse de traiter des corpus de quelques milliers de documents ou de plusieurs centaines de millions. À cette fin, vous devez constamment chercher des moyens de réduire le travail redondant, de prioriser les tâches de crawl les plus importantes – et de sortir des sentiers battus.
Par exemple, comment extraire le maximum d'informations et de métadonnées de certaines plateformes aux quotas particulièrement restrictifs ? Sans modèles sophistiqués et mûrement réfléchis, qui éliminent la redondance, priorisent le travail intelligent et synchronisent avec soin, les crawls peuvent finir par prendre des mois au lieu de quelques jours, ou potentiellement indexer et afficher les mauvaises informations.
Il est également important de se rappeler que les crawlers doivent pouvoir évoluer horizontalement. Au-delà de la seule rapidité et efficacité, les crawlers doivent être capables de traiter les informations provenant d'une grande variété de sources de données, qui peuvent toutes comporter des schémas d'autorisations complexes dont il faut tenir compte et que nous devons résoudre de notre côté. Cela inclut d'autres cas limites délicats, comme les lacunes des API à contourner (les sources de données ne disposent pas toujours de moyens simples et non redondants pour crawler tous les documents d'un corpus), ainsi que les réglages de priorisation spécifiques requis pour chaque source de données unique.
{{richtext-banner-component}}
De grands résultats exigent un grand crawler
Construire un index centralisé en crawlant et indexant toutes les sources est le meilleur moyen d'alimenter les connaissances dont votre modèle a besoin pour fournir les bonnes réponses à vos requêtes. Cependant, concevoir le bon crawler (rapide, résilient, flexible, à jour et précis !) est une prouesse d'ingénierie complexe qui demandera des années de développement et d'optimisation.
Un ChatGPT pour le travail est essentiel pour libérer tout le potentiel et la productivité des collaborateurs, mais en construire un par vous-même peut s'avérer plus compliqué que prévu. Les complications peuvent entraîner un retard dans la création de valeur, des difficultés d'alignement en interne, ainsi que des coûts considérables à terme lorsqu'il s'agit de le développer, de le maintenir et de l'entraîner par vos propres moyens. Si vous souhaitez une approche accélérée sur les points à privilégier pour construire l'infrastructure d'un excellent crawler pour votre solution d'IA générative et de recherche, découvrez notre webinaire à la demande.
Si vous êtes plutôt intéressé par le lancement d'une IA générative véritablement prête pour l'entreprise dès aujourd'hui – et non demain – inscrivez-vous à une démo Glean !
