Au cours des cinq dernières années, nous avons patiemment construit Glean pour en faire la solution de recherche d’entreprise leader du marché. Contrairement à toute autre solution de gestion des connaissances, Glean est capable de fournir des résultats de recherche et de chat à jour, toujours adaptés aux permissions et personnalisés — tout en se mettant à l’échelle de manière fluide et en indexant des corpus comptant des milliards de documents.
Mais arriver à ce niveau a été un parcours semé de défis déroutants. Contrairement à ce que certains pensent, une solution ad hoc consistant à « poser » une IA de chatbot sur des fichiers d’entreprise ne donnera pas les résultats attendus. Une meilleure approche consiste à construire une solution de recherche qui alimente le modèle avec les bonnes réponses, à chaque fois — mais bâtir les fondations d’une recherche prête pour l’entreprise est un véritable défi d’ingénierie, qui exige des années de travail et une expertise de pointe en machine learning, en recherche et en infrastructure de données scalable. ;
Si vous vous intéressez récemment à la création d’un ChatGPT interne et que vous cherchez à indexer l’ensemble de vos informations d’entreprise via la recherche vectorielle et les embeddings, j’aimerais partager quelques éléments qui vous aideront à avancer. Dans cet article, je vais parler plus précisément du crawler — le composant fondamental qui maintient des résultats de recherche et des réponses de chat constamment à jour, adaptées aux permissions et correctes. ;
Rapide, et pourtant résilient
Votre crawler interagit-il avec des systèmes tiers ? Alors l’infrastructure doit être tolérante aux pannes face aux nombreuses subtilités propres à chaque source de données. Lorsque nous avons conçu le nôtre, nous avons dû prendre en compte : ;
- Comment définir une erreur transitoire de manière uniforme dans le système, dans le contexte de chaque source de données ? ;
- Comment s’assurer que nous réessayons correctement, que l’erreur transitoire provienne de l’API ou du système ? ;
- Lorsque des tentatives de reprise ont lieu, comment savoir ce qui a déjà été effectué et n’exécuter à nouveau que ce qui doit l’être ?
Nous avons conclu qu’il nous fallait un système nous permettant de définir facilement une unité unique d’exécution réessayable, ainsi que toutes les étapes associées du début à la fin.
Par exemple, pour chaque invocation d’API, nous devons suivre :
À chaque étape, le système doit pouvoir indiquer comment gérer les erreurs. Si l’étape 3 réussit mais que l’étape 4 échoue, il doit persister d’une manière ou d’une autre cet état de complétion partielle et s’assurer que seule l’étape 4 est retentée. Cela implique que l’étape 4 doit être définie comme une unité distincte d’exécution réessayable quelque part dans le système. Sans ces précautions, des contenus manqueraient dans les résultats — et la complétion partielle pourrait être gérée de façon incorrecte. Par exemple, si nous avons toutes les données d’un document mais qu’il nous manque certaines de ses permissions, nous ne devrions pas l’afficher dans les résultats.
Nous avons également différents types de travail (comme les mises à jour incrémentales, 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é complète dans tous les modes de travail il est donc important d’utiliser plusieurs types distincts pour obtenir une vision complète. Un crawl complet ou un webhook peut identifier des documents supprimés — un crawl incrémental ne le peut pas. ;
Prioriser ces types de travail tout en respectant un quota d’API unique est également essentiel pour éviter de surcharger le système de la source de données à cause des limites de débit. Votre système doit être capable d’attribuer des poids entre ces charges de travail et d’appliquer les limites de quota avant le démarrage de chaque unité de travail. En cas d’erreurs, il doit le signaler à la couche d’application afin d’être plus stricte dans la contrainte de l’ensemble des charges de travail, en plus des mécanismes de reprise habituels pour cette unité d’exécution (p. ex. backoff exponentiel). ;
Il est également essentiel que votre système soit suffisamment flexible pour gérer différentes politiques de limitation de débit des API, car elles varient selon chaque application. 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/le jour 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 en permanence des alertes d’erreurs de crawl. Certaines sources de données vous pénalisent même en cas de dépassement — vous finirez donc par ralentir fortement, même pour les infractions les plus mineures. Dans le pire des cas, la source de données bloquera purement et simplement votre crawl. ;
Des crawlers flexibles et résilients, capables de s’adapter à ces exigences diverses, constituent les fondations d’une expérience fluide et sans incident sur laquelle les utilisateurs peuvent compter. ;
Prévenir l’obsolescence
Il est également important de s’assurer qu’aucune donnée obsolète ne reste dans le système. Si le système reçoit des mises à jour limitées sur les contenus supprimés, comment garantir que toutes les données stockées sont à jour ? C’est plus difficile qu’il n’y paraît. ;
Il est incroyablement difficile pour un système de savoir immédiatement quand un contenu est supprimé, mais c’est indispensable pour garantir la sécurité des données et la pertinence des informations. Certaines sources de données exposent les documents supprimés via des appels 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 endpoints d’API peuvent être peu fiables — souvent envoyés « au mieux », et généralement ni retentés ni récupérés si quelque chose tourne mal de leur côté ou du nôtre. Cela peut faire remonter de la documentation obsolète — potentiellement catastrophique ! Vous avez supprimé un document sensible qui n’aurait jamais dû être importé, ou qui a été partagé trop largement par erreur ? Il pourrait continuer à être servi à tout le monde. Vous avez ajouté un nouveau document important que les employés doivent consulter 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. Prenons par exemple le cas où un utilisateur supprime un document par erreur, puis le restaure à la hâte depuis la corbeille. Pourtant, les informations reçues lors du crawl peuvent être mélangées ou traitées dans le désordre. Le document est-il dans la corbeille ? Ne l’est-il pas ? Ces complications risquent d’amener les plateformes à fournir des réponses obsolètes et dépassées — et, au final, un système auquel les collaborateurs hésitent à faire confiance. ;
Pour créer des crawlers robustes qui luttent contre l’obsolescence, il nous faut une couche supplémentaire pour aider à purger les données périmées. Pour cela, nous effectuons des crawls réguliers de l’ensemble du corpus, puis supprimons les données que nous n’avons pas observées une fois le crawl terminé. Pour éviter toute suppression erronée, notre crawler s’assure également que ces crawls complets se sont bien déroulés avant de supprimer les données non vues, et signale aussi les suppressions qui semblent légitimes mais impactent un volume sensiblement important du corpus. ;
En traitant l’obsolescence de manière exhaustive et sûre, nous sommes en mesure de garantir que les résultats de chaque recherche ou requête ne renvoient jamais une réponse provenant de contenus obsolètes ou qui n’existent plus. ;
Une scalabilité adaptée à tout corpus
Surtout, le crawler doit fonctionner correctement à une échelle immense. L’optimisation et la synchronisation sont clés, et tout doit tenir, qu’il s’agisse de corpus contenant quelques milliers de documents ou des centaines de millions. Pour y parvenir, vous devez sans cesse chercher des moyens de réduire le travail redondant, de prioriser les tâches de crawl les plus importantes — et de penser autrement. ;
Par exemple, comment extraire un maximum d’informations et de métadonnées depuis certaines plateformes dont les quotas sont particulièrement restrictifs ? Sans des modèles sophistiqués et mûrement réfléchis qui éliminent la redondance, privilégient le travail intelligent et se synchronisent avec soin, les crawls risquent de prendre des mois au lieu de jours, ou d’indexer et d’afficher des informations erronées. ;
Il est aussi important de se rappeler que les crawlers doivent pouvoir scaler horizontalement. Au-delà de la vitesse et de l’efficacité, ils doivent être capables de traiter des informations provenant d’une grande variété de sources de données, qui peuvent toutes avoir des schémas d’autorisations complexes à prendre en compte et à résoudre de notre côté. Cela inclut d’autres cas limites délicats, comme des lacunes d’API qu’il faut contourner (certaines sources de données peuvent ne pas offrir de méthodes simples et non redondantes pour crawler tous les documents d’un corpus), ainsi qu’un réglage fin des priorités nécessaire pour chaque source de données. ;
{{richtext-banner-component}}
D’excellents résultats exigent un excellent crawler
Construire un index centralisé en crawlant et en indexant l’ensemble des sources est la meilleure façon d’alimenter la connaissance 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 exact !) est un défi d’ingénierie complexe qui demandera des années de développement et de réglages.
Un ChatGPT pour le travail est essentiel pour libérer tout le potentiel et la productivité des collaborateurs, mais en développer un soi-même peut s’avérer plus compliqué que vous ne l’imaginez. Ces complications peuvent entraîner un délai plus long avant d’obtenir de la valeur, des difficultés d’alignement en interne, ainsi que des coûts considérables à terme pour le développer, le maintenir et l’entraîner par vos propres moyens. Si vous cherchez un raccourci pour savoir sur quoi vous concentrer lors de la mise en place de l’infrastructure d’un excellent crawler pour votre solution d’IA générative et de recherche, consultez notre webinar à la demande. ;
Si vous préférez démarrer dès aujourd’hui — et non demain — avec une IA générative réellement prête pour l’entreprise, inscrivez-vous pour une démo Glean !
