Les organisations amassent d’importantes quantités de documents, tels que des tickets d’assistance, des documents juridiques, des flux de nouvelles et des travaux de recherche ; elles doivent comprendre ce qu’ils contiennent avant d’être en mesure de poser les questions pertinentes. Sans libellés ni données d’entraînement, il est impossible de passer en revue manuellement des milliers de documents. La recherche classique n’est d’aucun secours lorsque vous ne savez pas quoi chercher.

Cet article explore une approche native d’Elasticsearch pour le partitionnement de documents sans supervision et le suivi d’histoires temporelles permettant de pallier ce problème de découverte. Au terme de cette lecture, vous pourrez suivre l’évolution de récits de ce type au fil des jours :

Ce que vous découvrirez :

• Pourquoi le recours aux plongements dédiés au clustering (plutôt qu’à la recherche d’information) est crucial pour identifier des thématiques en l’absence de requête explicite.

• Comment la classification centroïde par densité regroupe les documents par sujet en utilisant Elasticsearch k-nearest neighbor (kNN) et par lots msearch.

• Comment significant_text peut étiqueter automatiquement les clusters pour que les thèmes soient lisibles sans avoir à créer de modèle.

• Comment les chaînes d'histoires temporelles relient le clustering quotidien pour montrer comment les thèmes évoluent de jour en jour.

Le pipeline utilise environ 8 500 articles de février 2025 provenant de BBC News et du Guardian comme corpus de test. Le secteur des informations est idéal car il possède une dynamique temporelle explicite, mais ce schéma s’adapte à tout processus de découverte documentaire : audit juridique, contrôle de conformité, synthèse documentaire, triage du support technique.

Pile :

• Jina v5 Plongements de regroupement : des adaptateurs LoRA (Low-Rank Adaptation) spécifiques à la tâche pour le groupement thématique. Jina a rejoint Elastic, et ses modèles sont directement disponibles par le biais du Elastic Inference Service (EIS).

• Elasticsearch : Scalable kNN, étiquetage significant_text et stockage vectoriel.

• DiskBBQ : format d'index vectoriel sur disque combinant une meilleure quantification binaire (BBQ) et un partitionnement hiérarchique par k-means pour l'accélération de l'approximation des plus proches voisins (ANN). Ce partitionnement de l'index est interne à la recherche vectorielle et distinct de l'algorithme de clustering par densité utilisé dans ce billet. bbq_disk stocke les vecteurs quantifiés sur disque et ne conserve que les métadonnées de partition en tas, réduisant considérablement les besoins en ressources par rapport à bbq_hnsw, tout en maintenant un rappel élevé.

• Clustering global + liaison temporelle quotidienne : découverte et évolution des récits.

Ce dont vous aurez besoin :

• Un déploiement Elasticsearch (Elastic Cloud, Elasticsearch Serverless, ou Elastic Self-Managed 8.18+/9.0+) : bbq_disk nécessite une version 8.18 ou plus récente. La partie optionnelle sur le récupérateur de diversité exige la version 9.3+ ou une solution sans serveur.

• Une clé API Jina: Le niveau gratuit comprend 10 millions de jetons, ce qui couvre le pipeline de clustering de noyau (~4,25 millions de jetons). La comparaison facultative entre la récupération et le clustering utilise un second passage de plongement.

• Une clé API Guardian (gratuite).

Configuration

Installez les packs requis :

Facultatif (uniquement si vous exécutez des assistants de scraping depuis ce dépôt) :

Ensuite, configurez les clés API dans un fichier .env à la racine du projet :

Ce bloc-notes appelle load_dotenv(override=True), donc les valeurs locales .env ont la priorité.

Partie 1 : Clustering de découverte — Pourquoi effectuer un clustering de plongements ?

La plupart des recherches vectorielles utilisent des plongements de récupération entraînés pour associer une requête à des documents pertinents. C'est parfait pour les recherches, mais pas pour les découvertes. Lorsque vous souhaitez trouver les sujets qui existent dans un corpus sans aucune requête, vous avez besoin de plongements qui regroupent des documents similaires.

Jina v5 résout ce problème grâce à des adaptateurs LoRA (Low-Rank Adaptation) spécifiques à chaque tâche. Grâce à LoRA, des ajustements de rang réduit sont injectés dans des couches internes spécifiques tandis que le reste du modèle demeure figé, ce qui réaligne ses capacités sur une tâche donnée sans passer par un cycle de réentraînement complet. Le même modèle de base produit des plongements différents selon le paramètre task :

Tâche

Entraîné pour

Cas d'utilisation

retrieval.passage

Correspondance requête-document

Recherche, génération augmentée par récupération (RAG)

clustering

Regroupement de sujets (optimisé pour des clusters serrés)

Découverte, catégorisation

L'adaptateur de clustering est formé pour rapprocher les documents sur le même sujet dans l'espace d'intégration et éloigner les documents sur des sujets différents. La comparaison visuelle ci-dessous montre clairement la différence.

Recherche et clustering : une comparaison visuelle

Pour observer la différence, un échantillon de documents est intégré avec les deux types de tâches. Le clustering est effectué dans l'espace d'intégration original à 1024 dimensions ; l'approximation uniforme et la projection (UMAP) sont utilisées uniquement pour projeter ces intégrations en 2D à des fins de visualisation. L’UMAP conserve la structure de voisinage local, ce qui facilite la comparaison de la segmentation des clusters.

Ci-dessous, le même échantillon de 480 documents est intégré avec les deux types de tâches et projeté en 2D avec UMAP. Cherchez des groupes de couleurs plus serrés et plus séparés dans le panneau de clustering.

Les plongements de recherche (à gauche) répartissent les sujets de manière large ; les plongements de clustering (à droite) produisent des groupes plus serrés et mieux séparés à partir des mêmes documents.

Les plongements de clustering produisent des groupes plus serrés et plus distincts visuellement. Les plongements de recherche répartissent les sujets de manière plus uniforme, ce qui est idéal pour la recherche (similarité à grain fin) ; mais pour la découverte, ce sont les clusters thématiques serrés qui importent.

C’est pourquoi task="clustering" est utilisé pour le reste de cette explication.

Chargement de l'ensemble de données

Le corpus combine deux sources d'actualités pour février 2025 :

• BBC News via l'ensemble de données RealTimeData/bbc_news_alltime de HuggingFace.

• The Guardian via l’API Open Platform de Guardian.

Le fait d'avoir plusieurs sources permet de vérifier que le clustering permet de trouver des sujets plutôt qu'un style spécifique à la source.

Intégration avec la tâche de clustering

L’API de Jina v5 est sollicitée avec le paramètre task="clustering" pour l’ensemble des documents. Les plongements sont mis en cache sur le disque, de sorte que les exécutions ultérieures ignorent complètement l’API.

L'appel d'API est simple. Le paramètre task est la différence clé avec l’utilisation typique de l’intégration :

Le chronométrage ci-dessous correspond à un accès au cache. La première exécution de l'API prend plus de temps, en fonction de la taille du corpus.

Indexation dans un seul index Elasticsearch

Pour le clustering de découverte, le mois entier est placé dans un seul index (docs-clustering-all). Le partitionnement journalier intervient plus tard, pour la liaison temporelle des articles.

Le mappage d'index utilise bbq_disk pour le champ vectoriel :

Un vecteur Float32 de 1024 dimensions représente 4 Ko. bbq_disk utilise des k-moyens hiérarchiques pour partitionner les vecteurs en petits clusters, les quantifier en binaire et stocker les vecteurs en pleine précision sur disque pour les re-noter. Seules les métadonnées des partitions sont conservées en mémoire vive, ce qui permet de maintenir des exigences matérielles minimales, même avec des volumes de données importants. Pour les charges de travail qui peuvent se permettre plus de mémoire, bbq_hnsw construit un graphe Hierarchical Navigable Small World (HNSW) pour des recherches plus rapides à un coût de ressources plus élevé.

Le type de champ dense_vector prend en charge plusieurs stratégies de quantification : bbq_disk et bbq_hnsw sont les meilleurs ajustements pour les plongements de haute dimension comme les vecteurs 1024-dim utilisés ici.

Clustering : classification de centroïdes par sondage de densité

Les algorithmes de partitionnement classiques tels que HDBSCAN partent du principe que l’intégralité de la matrice vectorielle N×d est stockée en mémoire pour exécuter des cycles de mises à jour exhaustifs. Avec 8 495 documents et 1024 dimensions, la charge est supportable (~35 Mo), toutefois la méthode ne peut s’étendre à des millions de documents sans ressources d’infrastructure additionnelles.

Cet algorithme est conceptuellement proche de l’initialisation KMeans++ avec une affectation de Voronoï et un seuil de bruit, mais il utilise la recherche kNN d’Elasticsearch comme primitive de calcul, ce qui permet de réaliser la quasi-totalité du travail côté serveur :

1. Échantillonner 5 % des documents comme sondes de densité (échantillon aléatoire, minimum 50).

2. Densité des sondes par lots via msearch kNN. Chaque sonde lance une requête kNN et enregistre la similarité moyenne de ses voisins. Similarité moyenne élevée = zone dense de l'espace d'intégration. msearch envoie plusieurs requêtes de recherche en un seul appel HTTP, ce qui est crucial ici : le sondage de densité génère des centaines de requêtes kNN, et leur regroupement par lots permet d’éviter la surcharge liée à chaque requête individuelle.

3. Sélection de germes à haute densité avec diversification : les éléments dont la densité est supérieure à la médiane sont classés par ordre décroissant ; ils sont ensuite retenus selon un algorithme glouton, à condition que leur similarité cosinus par rapport aux germes déjà sélectionnés ne dépasse pas un seuil de séparation défini. C’est le seul calcul côté client (~0,01s pour 8k documents).

4. Classez tous les documents par rapport aux centroïdes via msearch kNN: Chaque graine agit comme un centroïd  ; une recherche kNN permet d'extraire les documents proches au-dessus d'un seuil de similarité. Chaque document est affecté au centroïde qui l'a renvoyé avec le score le plus élevé. Les clusters de taille réduite sont dissous pour être classés comme du bruit.

Elasticsearch s'occupe du gros du travail : msearch pour les sondes de densité, msearch pour la classification et significant_text pour l'étiquetage. Pour ce corpus (8 495 documents), l’échantillon de sonde à densité à 5 % lance des requêtes de sonde de 425 kNN, qui msearch se regroupent en neuf appels HTTP (à la taille de lot 50), évitant ainsi une requête par sonde. Combiné à la recherche bbq_disk ANN, cela permet de rendre la phase de clustering rapide et évolutive. Les requêtes kNN utilisent une valeur minimale num_candidates pour la vitesse lors de la passe de clustering ; les requêtes de recherche de production doivent utiliser des valeurs num_candidates plus élevées pour améliorer le rappel au prix de la latence.

Les tailles naturelles des clusters sont déterminées par la densité d'espace intégrée autour de chaque centroïde, et non par une limite k stricte. Les thématiques denses produisent des clusters plus importants ; les thématiques de niche produisent des clusters plus petits.

Pourquoi pas KMeans ou HDBSCAN ?

KMeans suppose des amas sphériques et nécessite la matrice complète N× en mémoire. Pour les corpus qui tiennent dans la mémoire, HDBSCAN est une alternative solide. Il gère des formes de clusters arbitraires et possède une sémantique de densité bien comprise.

L’approche par centroïdes par sondage de densité cible un créneau différent : les corpus pour lesquels vous souhaitez un système unique de stockage, de récupération et de clustering, ou lorsque l’échelle rend les opérations de matrice côté client peu pratiques. Cette approche emploie le kNN d’Elasticsearch en tant que primitive de calcul, prend en charge n’importe quelle taille de cluster et conserve presque tout le traitement côté serveur.

Comprendre le taux de bruit

Le taux de bruit de ~28% est le résultat d'une conception et non d'un mode de défaillance. Les documents qui ne correspondent à aucun cluster dense au similarity_threshold configuré ne sont pas attribués, plutôt que d’être forcés dans une mauvaise correspondance. Cela agit comme un filtre de qualité : les tribunes d’opinion, les articles courts et les articles ponctuels résistent naturellement au clustering, car ils n’ont pas la densité thématique qui définit un groupe cohérent.

Ce seuil peut être modulé : réduire similarity_threshold génère un clustering plus large (plus de documents intégrés, au prix d’une homogénéité moindre), tandis que son augmentation densifie les clusters et rejette davantage d’éléments comme bruit. Pour ce corpus composé de contenus d’actualité variés, un taux de bruit d’environ 30 % constitue un point de fonctionnement raisonnable. Pour les déploiements en production, il convient de régler le seuil selon les exigences de qualité spécifiques au secteur d’activité.

Étiquettes automatiques avec significant_text

Désormais, chaque cluster a besoin d'une étiquette facile à lire. L’agrégation significant_text d’Elasticsearch permet de trouver les termes dont la fréquence est anormalement élevée dans un groupe spécifique (le cluster) comparativement à l’ensemble du corpus.

Techniquement, il emploie une heuristique statistique (le score JLH par défaut) qui pondère les écarts de fréquence absolue et relative, le tout sans « machine learning » ni sollicitation de modèles de langage (LLM). Un groupe sur la politique britannique peut faire apparaître des termes tels que starmer, labour, downing parce que ces termes sont disproportionnellement fréquents dans ce groupe par rapport à l'ensemble du corpus d'actualités.

Pour ce traitement global, le calcul des étiquettes s’effectue directement face à docs-clustering-all ; ainsi, les données de premier plan et de référence sont extraites de la totalité du mois. Dans la partie 2, l’étiquetage utilise le modèle d’index quotidien (docs-clustering-*), un caractère générique (« wildcard ») qui permet aux requêtes de couvrir simultanément tous les index correspondants, afin d’offrir à significant_text un arrière-plan plus large pour un meilleur contraste.

Voici à quoi ressemble une requête minimale :

significant_text sert également de barrière de qualité : les clusters qui ne produisent aucun terme important n'ont pas de vocabulaire distinctif. Il s’agit de regroupements dépourvus de sens qui devraient être réintégrés au bruit de fond au lieu d’être identifiés par un label erroné.

Une étape de nettoyage déterministe légère supprime les termes d’étiquetage parasites (jetons numériques, mots génériques) et se rabat sur un titre représentatif en cas de besoin. Cela permet de conserver les labels Elasticsearch natifs tout en améliorant la lisibilité.

Visualisation des clusters

Les visualisations ci-dessous montrent ce que la passe de clustering global a découvert : une répartition par date des documents regroupés par rapport au bruit, une projection UMAP du mois complet et un graphique de mixité des sources confirmant que les clusters reflètent les sujets plutôt que les sources.

Distribution quotidienne des documents regroupés par rapport aux documents parasites tout au long de février 2025.

Chaque îlot coloré dans l’UMAP représente un cluster : un groupe d’articles sur le même sujet découvert uniquement par similarité d’intégration. Les points gris de bruit correspondent aux articles qui ne s’intègrent pas clairement dans un cluster (souvent des articles courts, des tribunes libres ou des récits isolés).

Le graphique de répartition des sources confirme que les clusters contiennent des articles de BBC News et The Guardian. Le clustering est de trouver des sujets et non des sources, ce qui correspond exactement à ce que la découverte non supervisée devrait produire.

Exploration de l’étendue des clusters avec le récupérateur de diversification

Le kNN simple renvoie les documents les plus similaires au centroïde d'un cluster (le noyau dense). Mais les vrais clusters couvrent des sous-thèmes. Le récupérateur de diversité utilise la pertinence marginale maximale (MMR) pour faire remonter des documents qui sont à la fois pertinents pour le centroïde et différents les uns des autres.

Le paramètre clé est λ (lambda) :

• λ = 1,0 → pertinence pure (identique à la kNN simple).

• λ = 0,0 → diversité pure (résultats à répartition maximale).

• λ = 0,5 → équilibré : cela est pertinent pour le sujet, tout en couvrant différents aspects.

La structure minimale d’une requête de récupérateur se présente comme suit :

Les paramètres type, field, query_vector sont requis au niveau de diversification : field indique à MMR quel champ dense_vector utiliser pour la similarité entre les résultats, et query_vector fournit le point de référence pour le score de pertinence.

Cela vous permet de répondre à la question : « Que couvre réellement ce groupe ? » au lieu de simplement « Quel est son centre ? »

Les résultats simples kNN se regroupent autour d'un angle du sujet : les documents les plus similaires au centroïde et les uns aux autres. Le récupérateur de diversité fait ressortir différentes facettes d’un même cluster : des sous-thématiques, des sources distinctes et des perspectives variées.

La métrique de diversité valide ce point quantitativement : la similarité moyenne entre paires est plus basse avec le récupérateur de diversité, prouvant que les documents obtenus traitent d’un éventail de sujets plus vaste.

C'est utile pour :

• Comprendre ce que recouvre réellement un groupe, pas seulement son centre mais aussi ses bords.

• Générer des résumés. Des documents représentatifs et variés offrent un meilleur matériel pour un LLM.

• Trouver des exemples représentatifs pour l'évaluation humaine ou l'étiquetage en aval.

• Contrôles qualité. Si les divers résultats semblent incohérents, il se peut que le groupe doive être scindé.

Partie 2 : chaînes d’histoires temporelles

Suivi des histoires au fil des jours

La partie 1 a appliqué le clustering à l’ensemble du mois à l’échelle globale pour la découverte de thématiques. En ce qui concerne le flux temporel, le même processus de classification par centroïde avec sondage de densité est appliqué de manière autonome sur les index journaliers, les clusters étant ensuite mis en relation d’un jour à l’autre. Il est important de noter que les clusters journaliers sont distincts des clusters globaux présentés en partie 1 ; chaque jour produit ses propres attributions de groupes et des labels optimisés pour le contenu du jour même.

L'approche de liaison : échantillonnage et requête

Pour chaque cluster le jour A :

1. Prenez quelques exemples de documents représentatifs.

2. Exécutez la recherche kNN sur l'index du jour B.

3. Comptez le nombre de visites par groupe B par jour.

4. Si la fraction de réussite dépasse un seuil (fraction kNN ≥ 0,4), enregistrez un lien.

Cela est rapide (seuls quelques documents par cluster sont interrogés, pas tous) et utilise le kNN natif d'Elasticsearch, aucun outil externe n'est nécessaire.

Une fraction kNN de 100 % signifie que chaque document échantillonné du cluster source s'est retrouvé dans le même cluster cible, ce qui constitue le lien inter-jours le plus fort possible. La plupart des liens ci-dessus concernent le football, ce qui est logique : la couverture de la Premier League est quotidienne et présente une grande cohérence thématique.

Le lien score | operator | gedling → league | striker | season est un exemple de cluster de football local de niche (Gedling étant un club amateur) absorbé par le cluster plus large de la Premier League le jour suivant, un effet naturel du reclustering quotidien à différents niveaux de granularité.

Création de chaînes d’histoires

Une chaîne d'histoires est une séquence de clusters liés sur des jours consécutifs.

Les liens individuels par paires vous indiquent que le cluster « politique britannique » du lundi est relié à celui du mardi. Les chaînes révèlent l’arc complet : une histoire qui commence le lundi, évolue tout au long de la semaine et s’estompe le vendredi.

Les chaînes sont élaborées selon un algorithme glouton à partir de liens présentant une fraction kNN ≥ 0,4 ; ainsi, au moins 40 % des documents du groupe d’origine se retrouvent dans un groupe de destination unique. En partant du cluster le plus ancien, l'algorithme suit toujours le lien sortant le plus fort.

La chaîne la plus longue suit la couverture Ukraine-Russie pendant 19 jours consécutifs, ce qui n'est pas surprenant étant donné l'intensité géopolitique soutenue en février 2025. La deuxième plus longue suit le football de Premier League pendant 19 jours du mois. Des chaînes plus courtes couvrent la saison des récompenses (cinéma/prix, six jours), le rugby du Tournoi des Six Nations (10 jours) et la couverture du leadership politique au Royaume-Uni (sept jours). Chaque chaîne représente un arc narratif que l'algorithme a découvert uniquement à partir de la similarité des indices quotidiens.

Sankey : Visualisation du flux narratif

Un diagramme de Sankey est une visualisation de flux où la largeur des liens représente la force de la connexion. Ici, chaque bande verticale correspond à un jour, chaque nœud à un cluster quotidien (dimensionné selon le nombre de documents), et chaque chemin coloré suit une chaîne narrative au fil du temps. La largeur des liens encode la force du chevauchement kNN : des liens plus épais signifient qu'un plus grand nombre de documents échantillonnés se sont retrouvés dans le cluster cible. Les couleurs sont cohérentes pour chaque chaîne, de sorte qu'un chemin d'une même couleur de gauche à droite se lit comme la progression d'une histoire.

Par exemple, la chaîne Ukraine–Russie (visible comme l’un des parcours les plus longs) s’étend de façon continue du début du mois de février jusqu’à la troisième semaine, avec des liens constamment épais indiquant une forte continuité thématique d’un jour à l’autre.

Des chaînes narratives temporelles se déroulant en février 2025. Chaque chemin coloré est une histoire qui persiste au fil des jours ; la largeur des liens indique la force de chevauchement en kNN.

Ce que cette approche apporte

Cette présentation couvre un pipeline complet de clustering de documents non supervisé construit sur Elasticsearch :

1. Clustering de plongements : les adaptateurs spécifiques aux tâches de Jina v5 produisent des plongements optimisés pour le regroupement thématique, et non seulement pour la correspondance requête-document.

2. Regroupement global par clusters : en traitant le mois entier au sein d’un index unique, on optimise la détection de thèmes transversaux sur l’ensemble de la période.

3. Classification des centroïdes sondés par densité: échantillon 5 %, densité de la sonde via msearch kNN, sélection de diverses graines à haute densité, classification de toutes les substances par rapport aux centroïdes. Elasticsearch gère la puissance de calcul lourde ; seule la sélection des graines s’exécute côté client (~0,01 s).

4. significant_text Étiquetage par pertinence : les tests de signification produisent des étiquettes de clusters pertinentes sans aucun modèle de « machine learning » ni annotation manuelle. Les clusters qui ne produisent aucun terme significatif sont incohérents et sont relégués au rang de bruit : un portail de qualité intégré.

5. Liaison temporelle d'histoires : Les indices quotidiens et l'index croisé kNN par échantillonnage et interrogation retracent l'évolution des articles dans le temps.

Points clés :

• Le type de tâche de plongement est important : les plongements de clustering produisent des groupes thématiques sensiblement plus resserrés.

• Elasticsearch peut servir à la fois de couche de stockage et de moteur de clustering via kNN search.

• La classification par centroïde basée sur la densité conserve presque tous les calculs côté serveur et produit des clusters de tailles naturelles déterminées par la densité de l'espace de plongement.

• significant_text est rapide, interprétable et efficace pour le marquage automatique et le contrôle de la qualité.

Situations dans lesquelles cette approche est utile :

• Vous disposez de texte horodaté et souhaitez effectuer une découverte de thématiques sans données d'entraînement étiquetées.

• Vous voulez une seule pile pour le stockage, la recherche vectorielle, l’étiquetage et la liaison temporelle.

Extensions à explorer :

• Clustering multi-période (cumuls hebdomadaires et mensuels).

• Ingestion en temps réel avec attribution incrémentale de clusters.

• Résumés de cluster générés par LLM en utilisant les termes significant_text comme germes.

• À plus grande échelle, des centroïdes KMeans échantillonnés peuvent servir de points de départ pour le clustering basé sur la densité, réduisant ainsi le coût de la phase de sondage.

Essayez par vous-même

Ajoutez votre propre corpus de documents horodatés ; toute collection de texte contenant des dates fonctionne avec ce pipeline. Le cahier complet et le code de support sont disponibles dans le référentiel associé.

• Démarrez un essai gratuit d’Elastic Cloud: Lancez un cluster géré avec bbq_disk support en quelques minutes.

• Essayez Elasticsearch Serverless : aucune gestion de cluster, une mise à l’échelle automatique et une prise en charge de l’intégralité de ce guide.

Notre objectif était de passer à une approche automatisée et adaptative capable de gérer à la fois l’analyse des logs (extraction de champs) et le partitionnement des logs (identification de la source). Nous avons émis l’hypothèse que les grands modèles de langage (LLM), grâce à leur compréhension inhérente de la syntaxe du code et des modèles sémantiques, pourraient automatiser ces tâches avec une intervention humaine minimale.

Nous sommes heureux d'annoncer que cette fonctionnalité est déjà disponible dans Streams.

Description de l'ensemble de données

Nous avons choisi une Loghubcollection de logs à des fins de PoC. Pour notre enquête, nous avons sélectionné des échantillons représentatifs issus des domaines clés suivants :

• Systèmes distribués : nous avons utilisé le HDFS (Hadoop Distributed File System) et les ensembles de données Spark. Ils contiennent un mélange de messages d'information, de débogage et d'erreur typiques des plateformes de big data.

• Applications serveur et web : les logs des serveurs web Apache et d’OpenSSH ont constitué une source précieuse d’informations sur les accès, les erreurs et les événements liés à la security. Ces éléments sont essentiels pour surveiller le trafic web et détecter les menaces potentielles.

• Systèmes d'exploitation : nous avons inclus les logs de Linux et Windows. Ces ensembles de données représentent les événements communs et semi-structurés au niveau du système auxquels les équipes d’opérations sont confrontés quotidiennement.

• Systèmes mobiles : pour garantir que notre modèle puisse gérer les logs provenant d'environnements mobiles, nous avons inclus l'ensemble de données Android. Ces logs sont souvent volumineux et capturent un large éventail d'activités au niveau de l'application et du système sur les appareils mobiles.

• Superordinateurs : pour tester les performances sur des environnements de calcul haute performance (HPC), nous avons intégré l'ensemble de données BGL (Blue Gene/L), qui présente des logs très structurés avec une terminologie de domaine spécifique.

L'un des principaux avantages de la collection Loghub est que les logs sont en grande partie non nettoyés et non étiquetés, reflétant un environnement de production en direct bruyant avec une architecture de microservices.

Exemples de logs :

De plus, nous avons créé un cluster Kubernetes avec une application web typique et une base de données pour extraire des logs supplémentaires dans le domaine le plus courant.

Exemple de champs de log communs : horodatage, niveau de log (INFO, AVERTISSEMENT, ERREUR), source, message.

Analyse de logs en few-shot avec un LLM

Notre premier ensemble d'expériences s'est concentré sur une question fondamentale : Un LLM peut-il identifier de manière fiable les champs clés et générer des règles de parsing cohérentes pour les extraire ?

Nous avons demandé à un modèle d'analyser des échantillons de journaux bruts et de générer des règles d'analyse de journaux sous forme d'expressions régulières (regex) et de formats Grok. Nos résultats ont montré que cette approche présente beaucoup de potentiel, mais aussi des défis importants dans sa mise en œuvre.

Confiance élevée et conscience du contexte

Les premiers résultats étaient prometteurs. Le LLM a démontré une forte capacité à générer des règles d'analyse qui correspondaient aux exemples fournis avec une grande confiance. Outre la simple correspondance de modèles, le modèle a démontré une capacité de compréhension des logs — il pouvait identifier et nommer correctement la source du log (par exemple, application de suivi de santé, application web Nginx, base de données Mongo).

Le dilemme des échantillons d'entrée « Boucles d'or »

Nos expériences ont rapidement mis en évidence un manque important de robustesse en raison d'une sensibilité extrême à l'échantillon d'entrée. Les performances du modèle fluctuent considérablement en fonction des exemples de logs spécifiques inclus dans l'invite. Nous avons observé un problème de similitude des logs, dans lequel l'échantillon de log devait inclure juste assez de logs diversifiés  :

• Trop homogène (surapprentissage) : si les logs d'entrée sont trop similaires, le LLM a tendance à surspécifier. Il traite les données variables — telles que des noms spécifiques de classes Java dans une trace de pile — comme des parties statiques du modèle. Il en résulte des règles fragiles qui ne couvrent qu'une infime partie des logs et extraient des champs inutilisables.

• Trop hétérogène (confusion) : à l'inverse, si l'échantillon contient une variance de formatage significative, ou pire, des « logs poubelles » comme des barres de progression, des tableaux de mémoire ou de l'art ASCII, le modèle peine à trouver un dénominateur commun. Il en vient souvent à générer des regex complexes et cassés ou à généraliser paresseusement toute la ligne en un seul champ de bloc de message.

La contrainte de la fenêtre contextuelle

Nous avons également rencontré un goulot d'étranglement au niveau de la fenêtre contextuelle. Lorsque les logs d'entrée étaient longs, hétérogènes, ou riches en champs extractibles, la sortie du modèle se détériorait souvent, devenant « désordonnée » ou trop longue pour s'intégrer dans la fenêtre de contexte de sortie. Bien entendu, le découpage aide dans ce cas. En divisant les logs à l'aide de délimiteurs basés sur les caractères et sur les entités, nous pourrions aider le modèle à se concentrer sur l'extraction des champs principaux sans être submergé par le bruit.

L'écart de cohérence et de standardisation

Même lorsque le modèle a généré des règles avec succès, nous avons noté de légères incohérences :

• Variantes de dénomination des services : le modèle propose différents noms pour une même entité (par exemple, en étiquetant la source « Spark », « Apache Spark » et « Spark Log Analytics » dans différentes exécutions).

• Variations dans la dénomination des champs : les noms des champs n'étaient pas normalisés (par exemple, id vs. service.id vs. device.id). Nous avons normalisé les noms en utilisant une nomenclature de champ Elastic standardisée.

• Variance de résolution : la résolution de l'extraction de champ variait en fonction de la similarité des logs d'entrée les uns avec les autres.

Empreinte de format de log

Pour relever le défi de la similarité des logs, nous introduisons une heuristique haute performance : l'empreinte de format de log (LFF).

Au lieu d'introduire des logs bruts et bruyants directement dans un LLM, nous appliquons d'abord une transformation déterministe pour révéler la structure sous-jacente de chaque message. Cette étape de pré-traitement rend abstraites les données variables, générant une « empreinte » simplifiée qui nous permet de regrouper les logs connexes.

La logique de mapping est simple pour garantir la vitesse et la cohérence :

1. Abstraction des chiffres : toute séquence de chiffres (0-9) est remplacée par un simple ‘0’.

2. Abstraction du texte : toute séquence de caractères alphabétiques avec des espaces blancs est remplacée par un seul « a ».

3. Normalisation des espaces blancs : toutes les séquences d'espaces blancs (espaces, tabulations, nouvelles lignes) sont regroupées en un seul espace.

4. La préservation des symboles : la ponctuation et les caractères spéciaux (par exemple, :, [, ], /) sont préservés, car ils sont souvent les indicateurs les plus forts de la structure des logs.

Nous introduisons l'approche de mapping des logs. Les modèles de mapping de base comprennent les éléments suivants :

• Chiffres 0 à 9, quelle que soit leur longueur, de > à « 0 ».

• Texte (caractères alphabétiques avec espaces) de n'importe quelle longueur -> à 'a'.

• Espaces blancs, onglets et nouvelles lignes : > pour un seul espace.

Examinons un exemple de la manière dont ce mapping nous permet de transformer les logs.

Par conséquent, nous obtenons les masques de log suivants :

Remarquez les empreintes digitales des deux premiers logs. Malgré des horodatages, des classes de sources et un contenu de message différents, leurs préfixes (0/0/0 0:0:0 a a.a:) sont identiques. Cet alignement structurel nous permet de regrouper automatiquement ces logs dans le même cluster.

Le troisième log, cependant, produit une empreinte digitale complètement divergente (0-0-0...). Cela nous permet de le séparer algorithmiquement du premier groupe avant même d' invoquer un LLM.

Partie bonus : implémentation instantanée avec ES|QL

C'est aussi simple que de passer cette requête dans Discover.

Décomposition de la requête :

FROM loghub : cible notre index contenant les données de journal brut.

EVAL pattern = ... : la logique du mapping de base. Nous enchaînons les fonctions REPLACE pour effectuer l'abstraction (par exemple, les chiffres en '0', le texte en 'a', etc.) et enregistrons le résultat dans un champ "pattern".

STATS [column1 =] expression1, … BY SUBSTRING(pattern, 0, 15) :

Ceci est une étape du clustering. Nous regroupons les logs qui partagent les 15 premiers caractères de leur schéma et créons des champs agrégés tels que le nombre total de logs par groupe, la liste des sources de données des logs, le préfixe du schéma, 3 exemples de logs

SORT total_count DESC | LIMIT 100 : affiche les 100 schémas de log les plus fréquents

Les résultats de la requête sur LogHub sont affichés ci-dessous :

Comme démontré dans la visualisation, cette approche « sans LLM » partitionne les logs avec une grande précision. Elle a réussi à clusterer complètement 10 sources de données sur 16 (basées sur les étiquettes LogHub) (>90 %) et a atteint un clustering majoritaire dans 13 sources sur 16 (>60 %) — le tout sans nécessiter de nettoyage, de prétraitement ou de réglage fin supplémentaire.

L'empreinte digitale du format du log offre une alternative pragmatique et à fort impact, ainsi qu'un complément aux solutions de ML sophistiquées telles que l'analyse du modèle de log. Il offre des informations immédiates sur les relations entre les logs et gère efficacement les grands ensembles de logs.

• Polyvalence en tant que primitif

Grâce à la mise en œuvre d'ES|QL, LFF sert à la fois d'outil autonome pour des diagnostics/visualisations rapides des données, et d'élément de base dans les pipelines d'analyse des journaux pour les cas d'utilisation à grand volume.

• Flexibilité

LFF est facile à personnaliser et à étendre pour capturer des modèles spécifiques, c'est-à-dire des nombres hexadécimaux et des adresses IP.

• Stabilité déterministe

Contrairement aux algorithmes de clustering basés sur le ML, la logique LFF est simple et déterministe. Les nouveaux logs entrants n'affectent pas rétroactivement les clusters de logs existants.

• Performance et mémoire

Il nécessite peu de mémoire, pas de formation ni de GPU, ce qui le rend idéal pour les environnements à haut débit et en temps réel.

Combiner une empreinte digitale au format log avec un LLM

Pour valider l'architecture hybride proposée, chaque expérience contenait un sous-ensemble aléatoire de 20 % des logs de chaque source de données. Cette contrainte simule un environnement de production réel où les logs sont traités par lots plutôt que comme un bloc monolithique de données historiques.

L’objectif était de démontrer que le LFF agit comme une couche de compression efficace. Nous avons cherché à prouver que des règles d’analyse à haute couverture pouvaient être générées à partir de petits échantillons sélectionnés et généralisées avec succès à l’ensemble de l’ensemble de données.

Pipeline d'exécution

Nous avons mis en œuvre un pipeline à plusieurs étapes qui filtre, regroupe et applique un échantillonnage stratifié aux données avant qu'elles n'atteignent le LLM.

1. clustering hiérarchique en deux étapes

• Sous-classes (correspondance exacte) : les logs sont agrégés par empreintes identiques. Tous les logs d'une sous-classe partagent exactement la même structure de format.

• Nettoyage des aberrations. Nous écartons toutes les sous-classes qui représentent moins de 5 % du volume total des logs. Cela garantit que le LLM se concentre sur le signal dominant et ne sera pas distrait par le bruit ou les logs malformés.

• Métaclasses (correspondance avec le préfixe) : les sous-classes restantes sont regroupées en métaclasses en fonction des N premiers caractères de l'empreinte digitale du format. Nous avons choisi N=5 pour le Log parsing et N=15 pour le Log partitioning lorsque les sources de données sont inconnues.

2. Échantillonnage stratifié. Une fois l'arbre hiérarchique établit, nous construisons l'échantillon de log pour le LLM. L'objectif stratégique est de maximiser la couverture de variance tout en minimisant l'utilisation des jetons.

• Nous sélectionnons des logs représentatifs de chaque sous-classe valide au sein de la métaclasse plus large.

• Pour gérer un cas limite de sous-classes trop nombreuses, nous appliquons un échantillonnage aléatoire pour s'adapter à la taille de la fenêtre cible.

3. Génération de règles Finally, nous demandons au LLM de générer une règle d'analyse regex qui convient à tous les logs dans l'échantillon fourni pour chaque Métaclasse. Pour notre PoC, nous avons utilisé le mini-modèle GPT-4o.

Résultats expérimentaux et observations

Nous avons atteint une précision de parsing de 94 % et une précision de partitionnement de 91 % sur l'ensemble de données Loghub.

La matrice de confusion ci-dessus illustre les résultats du partitionnement des logs. L’axe vertical représente les sources de données réelles, et l’axe horizontal représente les sources de données prédites. L'intensité de la carte thermique correspond au volume de logs, les vignettes plus claires indiquant un nombre plus élevé. L'alignement diagonal démontre la haute fidélité du modèle dans l'attribution des sources, avec un minimum de dispersion.

Nos informations sur les benchmarks de performance :

• Base optimale : une fenêtre contextuelle de 30 à 40 échantillons de logs par catégorie s'est avérée être le « point idéal », produisant régulièrement une analyse syntaxique robuste avec des motifs Regex et Grok.

• Minimisation de l'entrée : nous avons réduit la taille de l'entrée à 10 logs par catégorie pour les motifs Regex et n'avons observé qu'une baisse de 2 % des performances d'analyse, ce qui confirme que l'échantillonnage basé sur la diversité est plus critique que le volume brut.

Filtres vs facettes

Avant de commencer, définissons ce que sont les filtres et les facettes. Les filtres sont des attributs prédéfinis utilisés pour restreindre un ensemble de résultats. Sur une place de marché, par exemple, des filtres sont disponibles avant même qu'une recherche ne soit effectuée. L'utilisateur peut sélectionner une catégorie, telle que "Jeux vidéo", avant de rechercher "PS5", ce qui permet d'affiner la recherche à un sous-ensemble plus spécifique plutôt qu'à l'ensemble de la base de données. Cela augmente considérablement les chances d'obtenir des résultats plus pertinents.

Les facettes fonctionnent de la même manière que les filtres, mais elles ne sont disponibles qu'une fois la recherche effectuée. En d'autres termes, la recherche renvoie des résultats et, sur la base de ceux-ci, une nouvelle liste d'options d'affinage est générée. Par exemple, lors de la recherche d'une console PS5, des aspects tels que la capacité de stockage, les frais d'expédition et la couleur peuvent être affichés pour aider les utilisateurs à choisir le produit idéal.

Maintenant que nous avons défini les filtres et les facettes, examinons l'impact de l'approche classique et de l'approche basée sur l'apprentissage automatique sur leur mise en œuvre et leur utilisation. Chaque méthode présente des avantages et des inconvénients qui influencent l'efficacité de la recherche.

Approche classique des filtres et des facettes

Dans cette approche, les filtres et les facettes sont définis manuellement sur la base de règles prédéfinies. Cela signifie que les attributs disponibles pour affiner la recherche sont fixés et planifiés à l'avance, en tenant compte de la structure du catalogue et des besoins de l'utilisateur.

Par exemple, sur une place de marché, les catégories telles que "Électronique" ou "Mode" peuvent avoir des filtres spécifiques tels que la marque, le format et la fourchette de prix. Ces règles sont créées de manière statique, ce qui garantit la cohérence de l'expérience de recherche, mais nécessite des ajustements manuels lorsque de nouveaux produits ou de nouvelles catégories apparaissent.

Bien que cette approche permette de prévoir et de contrôler les filtres et les facettes affichés, elle peut s'avérer limitée lorsque de nouvelles tendances apparaissent et exigent un affinement dynamique.

Pour :

• Prévisibilité et contrôle : Les filtres et les facettes étant définis manuellement, la gestion devient plus facile.

• Faible complexité : Il n'est pas nécessaire de former des modèles.

• Facilité de maintenance : Les règles étant prédéfinies, les ajustements et les corrections peuvent être effectués rapidement.

Cons :

• Réindexation nécessaire pour les nouveaux filtres : Chaque fois qu'un nouvel attribut doit être utilisé comme filtre, l'ensemble du jeu de données doit être réindexé pour s'assurer que les documents contiennent cette information.

• Absence d'adaptation dynamique : Les filtres sont statiques et ne s'adaptent pas automatiquement aux changements de comportement des utilisateurs.

Mise en œuvre des filtres/facettes - Approche classique

Dans Dev Tools, Kibana, nous allons créer une démonstration de filtres/facettes en utilisant l'approche classique.

Tout d'abord, nous définissons la correspondance pour structurer l'index :

Les champs marque et stockage sont définis comme des mots-clés, ce qui permet de les utiliser directement dans les agrégations(facettes). Le champ prix est de type flottant, ce qui permet de créer des fourchettes de prix.

L'étape suivante consiste à indexer les données relatives aux produits :

Retrouvons maintenant des facettes classiques en regroupant les résultats par marque, rangement et gamme de prix. Dans la requête, la taille:0 a été définie. Dans ce scénario, l'objectif est de récupérer uniquement les résultats de l'agrégation sans inclure les documents correspondant à la requête.

La réponse comprendra des comptes pour la marque, le stockage et le prix, ce qui permettra de créer des filtres et des facettes.

Approche basée sur le Machine Learning et l’IA pour les filtres et les facettes

Dans cette approche, les modèles d'apprentissage automatique (ML), y compris les techniques d'intelligence artificielle (IA), analysent les attributs des données pour générer des filtres et des facettes pertinents. Au lieu de s'appuyer sur des règles prédéfinies, la ML/AI exploite les caractéristiques des données indexées. Cela permet la découverte dynamique de nouvelles facettes et de nouveaux filtres.

Pour :

• Mises à jour automatiques : Les nouveaux filtres et facettes sont générés automatiquement, sans qu'il soit nécessaire de procéder à des ajustements manuels.

• Découverte de nouveaux attributs : Il peut identifier des caractéristiques de données précédemment non prises en compte en tant que filtres, enrichissant ainsi l'expérience de recherche.

• Réduction des efforts manuels : L'équipe n'a pas besoin de définir et de mettre à jour en permanence les règles de filtrage, car l'IA apprend à partir des données disponibles.

Cons :

• Complexité de la maintenance : L'utilisation de modèles peut nécessiter une prévalidation pour garantir la cohérence des filtres générés.

• Nécessite une expertise en ML et en IA : La solution exige des professionnels qualifiés pour affiner et surveiller les performances du modèle.

• Risque de filtres non pertinents : Si le modèle n'est pas bien calibré, il peut générer des facettes qui ne sont pas utiles aux utilisateurs.

• Coût : L'utilisation de la ML et de l'IA peut nécessiter des services tiers, ce qui augmente les coûts opérationnels.

Il convient de noter que même avec un modèle bien calibré et une invite bien rédigée, les facettes générées doivent toujours passer par une étape de révision. Cette validation peut être manuelle ou basée sur des règles de modération, garantissant que le contenu est approprié et sûr. Bien qu'il ne s'agisse pas nécessairement d'un inconvénient, il est important de s'assurer de la qualité et de l'adéquation des facettes avant de les mettre à la disposition des utilisateurs.

Mise en œuvre de filtres/façades - Approche IA

Dans cette démonstration, nous utiliserons un modèle d'intelligence artificielle pour analyser automatiquement les caractéristiques des produits et suggérer des attributs pertinents. Avec une invite bien structurée, nous extrayons des informations du catalogue et les transformons en filtres et facettes. Nous présentons ci-dessous chaque étape du processus.

Dans un premier temps, nous utiliserons l'API Inference pour enregistrer un point de terminaison en vue d'une intégration avec un service de ML. Vous trouverez ci-dessous un exemple d'intégration avec le service OpenAI.

Nous définissons maintenant le pipeline permettant d'exécuter l'invite et d'obtenir les nouveaux filtres générés par le modèle.

Lancer une simulation de ce pipeline pour le produit "PlayStation 5", avec la description suivante :

Des jeux époustouflants : Admirez des graphismes époustouflants et découvrez les fonctionnalités de la nouvelle PS5.

Une immersion à couper le souffle : Découvrez une expérience de jeu plus profonde grâce à la prise en charge du retour haptique, des déclencheurs adaptatifs et de la technologie audio 3D.

Un design élancé : Avec la PS5 Digital Edition, les joueurs bénéficient d'une technologie de jeu puissante dans un design élégant et compact.

1 To de stockage : Vos jeux préférés sont prêts à être joués grâce à 1 To de stockage SSD intégré.

Rétrocompatibilité et boost de jeux : La console PS5 peut lire plus de 4 000 jeux PS4. Avec Game Boost, vous pouvez même profiter de taux de rafraîchissement plus rapides et plus fluides dans certains des meilleurs jeux de la console PS4.

Observons la sortie rapide générée par cette simulation.

Un nouveau champ, dynamic_facets, sera ajouté au nouvel index pour stocker les facettes générées par l'IA.

En utilisant l'API Reindex, nous allons réindexer l'index videogames en videogames_1, en appliquant le pipeline generate_filter_ai pendant le processus. Ce pipeline génère automatiquement des facettes dynamiques lors de l'indexation.

Nous allons maintenant lancer une recherche et obtenir les nouveaux filtres :

Résultats :

Pour illustrer la mise en œuvre des facettes, nous présentons ci-dessous une interface simple :

Le code de l'interface utilisateur présenté est ici.

Conclusion

Les deux approches de la création de filtres et de facettes ont leurs avantages et leurs inconvénients. L'approche classique, basée sur des règles manuelles, permet de contrôler et de réduire les coûts, mais elle nécessite des mises à jour constantes et ne s'adapte pas de manière dynamique aux nouveaux produits ou aux nouvelles fonctionnalités.

D'autre part, l'approche basée sur l'IA et l'apprentissage automatique automatise l'extraction des facettes, ce qui rend la recherche plus flexible et permet de découvrir de nouveaux attributs sans intervention manuelle. Toutefois, cette approche peut être plus complexe à mettre en œuvre et à maintenir, et nécessite un étalonnage pour garantir des résultats cohérents.

Le choix entre l'approche classique et l'approche basée sur l'IA dépend des besoins et de la complexité de l'entreprise. Pour les scénarios plus simples, où les attributs des données sont stables et prévisibles, l'approche classique peut être plus efficace et plus facile à maintenir, en évitant les coûts inutiles liés à l'infrastructure et aux modèles d'IA. D'autre part, l'utilisation de la ML/AI pour extraire les facettes peut apporter une valeur ajoutée significative, en améliorant l'expérience de recherche et en rendant le filtrage plus intelligent.

L'important est d'évaluer si l'automatisation justifie l'investissement ou si une solution plus traditionnelle répond déjà efficacement aux besoins de l'entreprise.

Comprendre le benchmark BEIR dans l'évaluation de la pertinence des recherches

Pour améliorer un système, il faut pouvoir en mesurer l'efficacité. Dans le contexte de la recherche, BEIR (ou, de manière équivalente, la section Récupération du classement MTEB) est considéré comme le "Saint Graal" de la communauté de recherche d'informations, et cela n'a rien d'étonnant. C'est un indice de référence très bien structuré avec des ensembles de données variés couvrant différentes tâches. Plus précisément, les domaines suivants sont abordés :

• Récupération d'arguments (ArguAna, Touche2020)

• QA en domaine ouvert (HotpotQA, Natural Questions, FiQA)

• Récupération par passes (MSMARCO)

• Récupération des questions en double (Quora, CQADupstack)

• Vérification des faits (FEVER, Climate-FEVER, Scifact)

• Récupération d’informations biomédicales (TREC-COVID, NFCorpus, BioASQ)

• Récupération d'entités (DBPedia)

• Prédiction de citation (SCIDOCS)

Cet benchmark fournit une statistique unique, nDCG@10, qui indique dans quelle mesure un système fait correspondre les documents les plus pertinents pour chaque exemple de tâche dans les premiers résultats qu'il renvoie. Pour un système de recherche avec lequel un humain interagit, la pertinence des résultats en haut de liste est essentielle. Cependant, l'évaluation d'une recherche comporte de nombreuses nuances qu'une simple statistique récapitulative ne permet pas de saisir.

Structure d'un ensemble de données BEIR

Chaque benchmark comporte trois artefacts :

• le corpus ou les documents à récupérer

• les requêtes

• les jugements de pertinence pour les requêtes (alias qrels).

Les jugements de pertinence sont fournis sous forme de score égal ou supérieur à zéro. Les scores non nuls indiquent que le document est partiellement pertinent par rapport à la requête.

Ensemble de données

Taille du corpus

Nb. de requêtes dans l'ensemble de test

#qrels étiquetés positivement

#qrels égal à zéro

#Doublons dans le corpus

Arguana

8 674

1 406

1 406

0

96

Climate-FEVER

5 416 593

1 535

4 681

0

0

DBPedia

4 635 922

400

15 286

28 229

0

FEVER

5 416 568

6 666

7 937

0

0

FiQA-2018

57 638

648

1 706

0

0

HotpotQA

5 233 329

7 405

14 810

0

0

Questions naturelles

2 681 468

3 452

4 021

0

16 781

NFCorpus

3 633

323

12 334

0

80

Quora

522 931

10 000

15 675

0

1 092

SCIDOCS

25 657

1 000

4 928

25 000

2

SciFact

5 183

300

339

0

0

Touche2020

382 545

49

932

1 982

5 357

TREC-COVID

171 332

50

24 763

41 663

0

MSMARCO

8 841 823

6 980

7 437

0

324

CQADupstack (somme)

457 199

13 145

23 703

0

0

Tableau 1 : Statistiques de l'ensemble de données. Les chiffres ont été calculés sur la partie test des ensembles de données (dev pour MSMARCO).

Le tableau 1 présente quelques statistiques issues des ensembles de données qui composent le benchmark BEIR, telles que le nombre de documents dans le corpus, le nombre de requêtes dans l'ensemble de données de test et le nombre de paires positives/négatives (requête, document) dans le fichier qrels. Un simple coup d'œil aux données nous permet de déduire immédiatement ce qui suit :

• La plupart des ensembles de données ne contiennent aucune relation négative dans le fichier qrels, c'est-à-dire des scores nuls, ce qui indiquerait explicitement que les documents ne sont pas pertinents pour la requête donnée.

• Le nombre moyen de relations entre documents par requête (#qrels / #queries) varie de 1,0 dans le cas de ArguAna à 493,5 (TREC-COVID), mais avec une valeur de <5 dans la majorité des cas.

• Certains ensembles de données comportent des documents en double dans le corpus, ce qui, dans certains cas, peut conduire à une évaluation incorrecte, c'est-à-dire lorsqu'un document est considéré comme pertinent par rapport à une requête, alors que son doublon ne l'est pas. Par exemple, dans ArguAna, nous avons identifié 96 cas de paires de documents en double, avec un seul document par paire marqué comme pertinent pour une requête. En agrandissant la liste initiale des qrels pour inclure également les doublons, nous avons observé une augmentation relative d'environ 1 % du score nDCG@10 en moyenne.

Exemple de paires dupliquées dans ArguAna. Dans le fichier qrels, seul la première semble pertinente (en tant que contre-argument) par rapport à la requête ("test-economy-epiasghbf-pro02a")

Lors de la comparaison des modèles sur le classement MTEB, il est tentant de se concentrer sur la qualité moyenne de la récupération. Il s'agit d'un bon indicateur de la qualité globale du modèle, mais cela ne prédit pas nécessairement ses performances dans votre cas d'utilisation. Comme les résultats sont présentés par ensemble de données, il est important de comprendre le degré de pertinence des différents ensembles de données par rapport à votre tâche de recherche et de réévaluer les modèles en ne retenant que les plus pertinents. Pour une analyse plus approfondie, vous pouvez également vérifier le chevauchement thématique entre les différents corpus. Répartir les mesures de qualité par thème permet une évaluation beaucoup plus fine de leurs forces et faiblesses particulières.

Une remarque importante ici est que lorsqu'un document n'est pas marqué dans le fichier qrels, considéré par défaut comme non pertinent pour la requête. Nous approfondissons un peu plus ce domaine et recueillons des éléments de preuve pour éclairer davantage la question suivante : "À quelle fréquence un évaluateur est-il confronté à des paires (requête, document) pour lesquelles il n'existe aucune information de référence ?" Ceci est important, car lorsque seul un balisage superficiel est disponible (et que tous les documents pertinents ne sont donc pas étiquetés comme tels), un système de recherche d'informations peut être considéré comme pire qu'un autre simplement parce qu'il "choisit" de faire apparaître différents documents pertinents (mais non marqués). Il s'agit d'un piège courant dans la création d'ensembles de données d'évaluation de haute qualité, en particulier pour les grands ensembles de données. Pour être réalisable, l'étiquetage manuel se concentre généralement sur les meilleurs résultats renvoyés par le système actuel, ce qui peut entraîner l'omission de documents pertinents situés dans ses angles morts. Il est donc généralement préférable de consacrer davantage de ressources à un balisage plus complet d'un nombre restreint de requêtes plutôt qu'à un balisage superficiel et général.

Utilisation du benchmark BEIR pour l'évaluation de la pertinence des recherches

Pour initier notre analyse, nous mettons en œuvre le scénario suivant (voir le notebook) :

1. Tout d'abord, nous chargeons le corpus de chaque ensemble de données dans un index Elasticsearch.

2. Pour chaque requête dans l'ensemble de test, nous récupérons les 100 meilleurs documents avec BM25.

3. Nous reclassons les documents récupérés à l'aide de divers modèles de reclassement SOTA.

4. Enfin, nous rapportons le "taux de jugement" pour les 10 meilleurs documents provenant des étapes 2 (après récupération) et 3 (après reclassement). En d'autres termes, nous calculons le pourcentage moyen des 10 meilleurs documents qui ont un score dans le fichier qrels.

Voici la liste des modèles de reclassement que nous avons utilisés :

• Cohere rerank-english-v2.0 et rerank-english-v3.0

• BGE-base

• mxbai-rerank-xsmall-v1

• MiniLM-L-6-v2

Récupération

Reranking

Ensemble de données

BM25 (%)

Cohere Rerank v2 (%)

Cohere Rerank v3 (%)

BGE-base (%)

mxbai-rerank-xsmall-v1 (%)

MiniLM-L-6-v2 (%)

Arguana

7,54

4,87

7,87

4,52

4,53

6,84

Climate-FEVER

5,75

6,24

8,15

9,36

7,79

7,58

DBPedia

61,18

60,78

64,15

63,9

63,5

67,62

FEVER

8,89

9,97

10,08

10,19

9,88

9,88

FiQa-2018

7,02

11,02

10,77

8,43

9,1

9,44

HotpotQA

12,59

14,5

14,76

15.1

14,02

14,42

Questions naturelles

5,94

8.84

8,71

8,37

8,14

8,34

NFCorpus

31,67

32,9

33,91

30,63

32,77

32,45

Quora

12,2

10,46

13,04

11,26

12,58

12,78

SCIDOCS

8,62

9,41

9,71

8,04

8,79

8,52

SciFact

9,07

9,57

9,77

9,3

9,1

9,17

Touche2020

38,78

30,41

32,24

33,06

37,96

33,67

TREC-COVID

92,4

98,4

98,2

93,8

99,6

97,4

MSMARCO

3,97

6,00

6,03

6,07

5,47

6,11

CQADupstack (moy.)

5,47

6,32

6,87

5,89

6,22

6,16

Tableau 2 : Taux de jugement par paires (ensemble de données, reranker) calculé sur les 10 premiers documents récupérés/reclassés

D'après le tableau 2, à l'exception de TREC-COVID (>90 % de couverture), DBPedia (~65 %), Touche2020 et nfcorpus (~35%), nous constatons que la majorité des ensembles de données ont un taux d'étiquetage compris entre 5 % et un peu plus de 10 % après l'extraction ou le reclassement. Cela ne veut pas dire que tous ces documents banalisés sont pertinents, mais il se peut qu'un sous-ensemble d'entre eux, en particulier ceux placés en tête de liste, soit positif.

L'avènement des modèles de langage réglés pour les instructions générales nous offre un nouvel outil puissant capable d'automatiser potentiellement l'évaluation de la pertinence. Ces méthodes sont généralement beaucoup trop gourmandes en ressources de calcul pour être utilisées en ligne dans le cadre de la recherche, mais nous nous intéressons ici à l'évaluation hors ligne. Nous utilisons ces méthodes dans ce qui suit pour examiner les indices montrant que certains ensembles de données BEIR souffrent d'un balisage superficiel.

Afin d'approfondir cette hypothèse, nous avons décidé de nous concentrer sur MSMARCO et de sélectionner un sous-ensemble de 100 requêtes, ainsi que les 5 documents les mieux reclassés (avec Cohere v2) qui ne sont actuellement pas marqués comme pertinents. Nous avons suivi deux voies d'évaluation différentes : premièrement, nous avons utilisé un prompt soigneusement ajusté (nous y reviendrons dans un article ultérieur) pour préparer le modèle Phi-3-mini-4k récemment publié afin de prédire la pertinence (ou non) d'un document par rapport à la requête. En parallèle, ces cas ont également été étiquetés manuellement afin d'évaluer également le taux d'accord entre la sortie du LLM et le jugement humain. Dans l'ensemble, nous pouvons tirer les deux conclusions suivantes :

• Le taux de concordance entre les réponses LLM et les jugements humains était proche de 80 %, ce qui semble suffisant comme point de départ dans cette direction.

• Dans 57,6 % des cas (sur la base du jugement humain), les documents renvoyés se sont avérés réellement pertinents par rapport à la requête. Autrement dit : pour 100 requêtes, 107 documents ont été jugés pertinents, mais au moins 0,576 × 5 × 100 = 288 documents supplémentaires sont réellement pertinents !

Voici quelques exemples issus de l'ensemble de données MSMARCO/dev qui contiennent la requête, le document positif annoté (de qrels) et un faux négatif dû à un balisage incomplet :

1{^>er <^}exemple :

2{^>e <^}exemple :

L'évaluation manuelle de requêtes spécifiques comme celle-ci est une technique généralement utile pour comprendre la qualité de la recherche qui complète les mesures quantitatives comme le nDCG@10. Si vous disposez d'un ensemble représentatif de requêtes que vous exécutez systématiquement lorsque vous modifiez la recherche, cela vous fournit des informations qualitatives importantes sur l'évolution des performances, informations invisibles dans les statistiques. Par exemple, cela vous donne beaucoup plus d'informations sur les faux résultats renvoyés par la recherche : cela peut vous aider à repérer les erreurs évidentes dans les résultats obtenus, les classes d'erreurs connexes, telles que la mauvaise interprétation de la terminologie spécifique au domaine, etc.

Notre résultat est en accord avec les recherches pertinentes concernant l'évaluation de MSMARCO. Par exemple, Arabzadeh et al. suivent une procédure similaire où ils emploient des travailleurs du crowdsourcing pour effectuer des jugements de préférences : entre autres, ils montrent que, dans de nombreux cas, les documents retournés par les modules de reclassement sont préférés à ceux du fichier MSMARCO qrels. Un autre élément de preuve est fourni par les auteurs de l'outil de reclassement RocketQA, qui indiquent que plus de 70 % des documents reclassés ont été jugés pertinents après inspection manuelle.

Mise à jour – 9 septembre : Après une réévaluation minutieuse de l'ensemble de données, nous avons identifié 15 autres cas de documents pertinents, portant leur nombre total de 273 à 288

Principaux points à retenir et prochaines étapes

• La quête d'une meilleure référence est sans fin, car elle est cruciale pour le benchmarking et la comparaison de modèles. Les LLM peuvent aider dans certains domaines d'évaluation s'ils sont utilisés avec prudence et réglés avec des instructions appropriées.

• Plus généralement, étant donné que les critères de référence ne seront jamais parfaits, il peut être préférable de passer d'une simple comparaison de scores à des techniques plus robustes permettant de saisir les différences statistiquement significatives. Les travaux de Arabzadeh et al. fournit un bon exemple de cette méthode où, d'après leurs résultats, ils construisent des intervalles de confiance à 95 % indiquant des différences significatives (ou non) entre les différentes exécutions. Dans le notebook joint, nous proposons une implémentation des intervalles de confiance en utilisant le bootstrapping.

• Du point de vue de l’utilisateur final, il est utile de réfléchir à l'alignement des tâches lors de la lecture des résultats de benchmark. Par exemple, pour un ingénieur en IA qui conçoit un pipeline RAG et sait que le cas d'utilisation le plus courant consiste à assembler de multiples informations provenant de différentes sources, il serait plus pertinent d'évaluer les performances de son modèle de recherche sur des ensembles de données QA multisauts comme HotpotQA plutôt que sur la moyenne globale du benchmark BEIR.

Dans l'article de blog suivant, nous approfondirons l'utilisation de Phi-3 en tant que juge LLM et le processus de réglage pour prédire la pertinence.

Bien que HNSW soit un moyen puissant et flexible de stocker et de rechercher des vecteurs, il nécessite une quantité importante de mémoire pour fonctionner rapidement. Par exemple, l'interrogation de 1MM float32 vectors de 768 dimensions nécessite environ de ram. Dès que vous commencez à rechercher un nombre important de vecteurs, cela devient coûteux. La quantification des octets est un moyen d'utiliser environ moins de mémoire. Lucene et, par conséquent, Elasticsearch prennent en charge l'indexation des vecteurs d' depuis un certain temps, mais la construction de ces vecteurs relève de la responsabilité de l'utilisateur. Cela est sur le point de changer, car nous avons introduit la quantification scalaire dans Lucene.

Quantification scalaire 101

Toutes les techniques de quantification sont considérées comme des transformations avec perte des données brutes. Cela signifie que certaines informations sont perdues pour des raisons d'espace. Pour une explication approfondie de la quantification scalaire, voir : Quantification scalaire 101. À un niveau élevé, la quantification scalaire est une technique de compression avec perte. Un simple calcul permet de réaliser des économies d'espace significatives avec très peu d'impact sur le rappel.

Explorer l'architecture

Les personnes habituées à travailler avec Elasticsearch sont peut-être déjà familiarisées avec ces concepts, mais voici un aperçu rapide de la distribution des documents pour la recherche.

Chaque index Elasticsearch est composé de plusieurs tiroirs (shards). Bien que chaque nuage ne puisse être affecté qu'à un seul nœud, plusieurs nuages par index permettent un parallélisme de calcul entre les nœuds.

Chaque tesson est composé d'un seul index Lucene. Un index Lucene se compose de plusieurs segments en lecture seule. Pendant l'indexation, les documents sont mis en mémoire tampon et périodiquement vidés dans un segment en lecture seule. Lorsque certaines conditions sont remplies, ces segments peuvent être fusionnés en arrière-plan en un segment plus large. Tout cela est configurable et comporte son lot de complexités. Mais lorsque nous parlons de segments et de fusion, nous parlons de segments Lucene en lecture seule et de la fusion périodique automatique de ces segments. Voici une analyse plus approfondie de la fusion des segments et des décisions en matière de conception.

Quantification par segment dans Lucene

Chaque segment dans Lucene stocke les éléments suivants : les vecteurs individuels, les indices du graphe HNSW, les vecteurs quantifiés et les quantiles calculés. Par souci de concision, nous nous concentrerons sur la manière dont Lucene stocke les vecteurs quantifiés et bruts. Pour chaque segment, nous conservons la trace des bruts dans le fichier vec, des vecteurs quantifiés et d'un seul multiplicateur correctif dans le ainsi que les métadonnées relatives à la quantification fichier vemq.

Figure 1 : Présentation simplifiée d'un fichier de stockage de vecteurs bruts. Occupe la de l'espace disque puisque les valeurs sont de 4 octets. Étant donné que nous quantifions, ces données ne seront pas chargées lors de la recherche HNSW. Ils ne sont utilisés que sur demande expresse (par ex. secondaire par force brute via le rescore), ou pour la re-quantification lors de la fusion de segments.

Figure 2 : Présentation simplifiée du fichier fichier. Occupe un espace de et sera chargé en mémoire lors de la recherche. Les octets sont destinés à prendre en compte le multiplicateur de correction, utilisé pour ajuster la notation afin d'améliorer la précision et la mémorisation.

Figure 3 : Présentation simplifiée du fichier de métadonnées. C'est ici que nous gardons trace de la quantification et de la configuration du vecteur, ainsi que des quantiles calculés pour ce segment.

Ainsi, pour chaque segment, nous stockons non seulement les vecteurs quantifiés, mais aussi les quantiles utilisés pour créer ces vecteurs quantifiés et les vecteurs bruts originaux. Mais pourquoi conserver les vecteurs bruts ?

Une quantification qui évolue avec vous

Étant donné que Lucene se concentre périodiquement sur les segments en lecture seule, chaque segment n'a qu'une vue partielle de l'ensemble des données. Cela signifie que les quantiles calculés ne s'appliquent directement qu'à cet échantillon de l'ensemble de vos données. Ce n'est pas très grave si votre échantillon représente correctement l'ensemble de votre corpus. Mais Lucene vous permet de trier votre index de différentes manières. Ainsi, vous pourriez indexer des données triées d'une manière qui ajoute un biais pour les calculs de quantile par segment. De plus, vous pouvez effacer les données quand vous le souhaitez ! Votre échantillon peut être minuscule, ne serait-ce qu'un seul vecteur. Un autre avantage est que vous avez le contrôle sur le moment où les fusions ont lieu. Bien qu'Elasticsearch ait configuré des valeurs par défaut et une fusion périodique, vous pouvez demander une fusion quand vous le souhaitez via l'API _force_merge. Alors, comment permettre cette flexibilité tout en assurant une bonne quantification et un bon rappel ?

La quantification vectorielle de Lucene s'adaptera automatiquement au fil du temps. Lucene étant conçu avec une architecture de segments en lecture seule, nous avons la garantie que les données de chaque segment n'ont pas changé et des démarcations claires dans le code pour savoir quand les choses peuvent être mises à jour. Cela signifie que lors de la fusion des segments, nous pouvons ajuster les quantiles si nécessaire et éventuellement ré-équantifier les vecteurs.

Figure 4 : Trois exemples de segments avec différents quantiles.

Mais la requantification n'est-elle pas coûteuse ? Il y a un certain surcoût, mais Lucene gère les quantiles intelligemment et ne les quantifie complètement que lorsque c'est nécessaire. Prenons l'exemple des segments de la figure 4. Donnons aux segments et documents chacun et au segment seulement documents. Lucene prend une moyenne pondérée des quantiles et si le quantile fusionné qui en résulte est suffisamment proche des quantiles originaux du segment, nous n'avons pas besoin de quantifier à nouveau ce segment et nous utiliserons les quantiles nouvellement fusionnés.

Figure 5 : Exemple de quantiles fusionnés lorsque les segments et ont documents et que le segment n'en a que .

Dans la situation représentée à la figure 5, nous pouvons voir que les quantiles fusionnés qui en résultent sont très similaires aux quantiles originaux en et Ils ne justifient donc pas la quantification des vecteurs. Le segment semble s'écarter trop de la réalité. Par conséquent, les vecteurs de seront quantifiés à nouveau avec les valeurs de quantile nouvellement fusionnées.

Il existe en effet des cas extrêmes où les quantiles fusionnés diffèrent considérablement des quantiles initiaux. Dans ce cas, nous prendrons un échantillon de chaque segment et recalculerons entièrement les quantiles.

Performance de quantification & numbers

Est-il rapide et offre-t-il toujours un bon rappel ? Les chiffres suivants ont été recueillis lors de l'exécution de l'expérience sur une instance GCP c3-standard-8. Pour garantir une comparaison équitable avec , nous avons utilisé une instance suffisamment grande pour contenir des vecteurs bruts en mémoire. Nous avons indexé vecteurs Cohere Wiki en utilisant le produit intérieur maximal.

Figure 6 : Rappel@10 pour les vecteurs quantifiés par rapport aux vecteurs bruts. La performance de recherche des vecteurs quantifiés est nettement plus rapide que celle des vecteurs bruts, et le rappel est rapidement récupérable en rassemblant seulement 5 vecteurs supplémentaires ; visible par .

La figure 6 illustre l'histoire. Bien qu'il y ait une différence de rappel, comme on peut s'y attendre, elle n'est pas significative. Et la différence de rappel disparaît en rassemblant seulement 5 vecteurs supplémentaires. Tout cela avec des fusions de segments rapides et 1/4 de la mémoire des vecteurs .

Conclusion

Lucene apporte une solution unique à un problème difficile. La quantification ne nécessite aucune étape de "formation" ou d'"optimisation". Dans Lucene, cela fonctionnera simplement. Il n'y a pas d'inquiétude à avoir quant à la nécessité de "ré-entraîner" votre index vectoriel si vos données changent. Lucene détectera les changements significatifs et s'en chargera automatiquement pendant toute la durée de vie de vos données. Nous attendons avec impatience le moment où nous intégrerons cette fonctionnalité dans Elasticsearch !

Que fait sysgrok ?

sysgrok peut faire des choses comme :

• Prendre les fonctions et processus les plus coûteux identifiés par un profileur, expliquer la fonctionnalité de chacun et suggérer des optimisations.

• À partir d'un hôte et d'une description d'un problème rencontré par cet hôte, il est possible de déboguer automatiquement le problème et de proposer des solutions et des actions supplémentaires.

• Prendre un code source qui a été annoté par un profileur, expliquer les chemins chauds et suggérer des moyens d'améliorer les performances du code.

Les fonctionnalités de sysgrok s'adressent à trois grandes catégories de solutions :

1. En tant que moteur d'analyse des performances, de la fiabilité et d'autres données relatives aux systèmes. Dans ce mode, le LLM est alimenté par la sortie d'un autre outil utilisé par l'ingénieur (par exemple, un outil de ligne de commande Linux, un profileur ou une plate-forme Observability). L'objectif de sysgrok est d'interpréter, de résumer et de formuler des hypothèses sur l'état du système à l'aide d'un LLM. Il peut également suggérer des optimisations ou des remédiations.

2. En tant que solution ciblée et automatisée à des tâches spécifiques liées à la performance et à la fiabilité. Certaines tâches reviennent régulièrement dans les travaux d'ingénierie des performances et de SRE. Pour ces derniers, nous pouvons construire des assistants automatisés et ciblés qui peuvent être utilisés directement par l'ingénieur ou par sysgrok lui-même pour résoudre d'autres problèmes. Par exemple, dans le domaine de l'ingénierie des performances, il est courant de répondre à la question suivante : "Existe-t-il une version plus rapide de cette bibliothèque avec des fonctionnalités équivalentes ?". sysgrok prend cela en charge directement.

3. Outil d'analyse automatisée des causes profondes des problèmes de performance et de fiabilité. Les deux premières catégories de solutions sont un mélange d'analyse, d'interprétation, de recherche et de synthèse de données. Surtout, ils sont appliqués de manière ciblée aux données que l'ingénieur a lui-même recueillies. Dans sysgrok, nous étudions également une troisième approche de la résolution de problèmes avec les LLM, dans laquelle le LLM est combiné avec d'autres outils pour effectuer de manière autonome l'analyse des causes profondes et la résolution d'un problème donné. Dans cette approche, le LLM reçoit une description du problème (par exemple, "Le serveur web connaît une latence élevée") et est informé des capacités dont il dispose (par exemple, "ssh à un hôte," " exécuter des outils de ligne de commande Linux arbitraires"). Il est ensuite demandé au mécanisme d'apprentissage à long terme d'indiquer les mesures à prendre, en utilisant les capacités dont il dispose, pour trier le problème. Ces actions sont exécutées par sysgrok, et il est demandé au LLM d'analyser les résultats, de trier le problème, de suggérer des remèdes et de recommander les prochaines étapes.

sysgrok en est encore à ses débuts, mais nous le publions car il est déjà utile pour une variété de tâches - nous espérons qu'il sera une base pratique pour d'autres personnes afin de réaliser des expériences similaires. N'hésitez pas à nous envoyer des PR ou à ouvrir des problèmes sur GitHub si vous avez des idées !

Analyse des problèmes de performance avec les LLM

Les LLM, tels que les modèles GPT d'OpenAI, ont vu leur popularité exploser au cours des derniers mois, fournissant une interface en langage naturel et un moteur au cœur de toutes sortes de produits, qu'il s'agisse de robots d'assistance à la clientèle, d'assistants de manipulation de données ou d'assistants de codage. Un aspect intéressant de cette tendance est que la plupart de ces applications utilisent des modèles génériques qui n'ont pas été spécifiquement formés ou affinés pour la tâche à accomplir. Au contraire, ils ont été formés sur de larges pans de l'internet dans son ensemble et sont donc applicables à un large éventail de tâches.

Pouvons-nous donc utiliser ces modèles pour faciliter l'analyse des performances, le débogage et l'optimisation ? Il existe plusieurs méthodes pour étudier les problèmes de performance, déterminer les causes profondes et proposer des optimisations. Au fond, tout travail d'analyse des performances consiste à examiner les résultats de divers outils, tels que les outils de ligne de commande Linux ou une plate-forme d'observabilité, et à interpréter ces résultats afin de formuler une hypothèse sur l'état du système. Parmi le matériel sur lequel les modèles GPT ont été formés, on trouve des sources qui couvrent l'ingénierie logicielle, le débogage, l'analyse de l'infrastructure, les internes du système d'exploitation, Kubernetes, les commandes Linux et leur utilisation, ainsi que les méthodologies d'analyse de la performance. Par conséquent, les modèles peuvent être utilisés pour résumer, interpréter et émettre des hypothèses sur les données et les problèmes que les ingénieurs de performance rencontrent au quotidien, ce qui peut accélérer le rythme auquel un ingénieur progresse dans son analyse.

Nous pouvons aller plus loin et dépasser l'utilisation du LLM uniquement pour l'analyse des données et la réponse aux questions dans le contexte du processus d'investigation de l'ingénieur. Comme nous le montrerons plus loin dans ce billet, le LLM lui-même peut être utilisé pour piloter le processus dans certains scénarios, le LLM décidant des commandes à exécuter ou des sources de données à consulter pour déboguer un problème.

Démonstrations

Pour connaître l'ensemble des fonctionnalités prises en charge par sysgrok, consultez le dépôt GitHub. D'une manière générale, il soutient trois approches de la résolution de problèmes :

Approche 1 : moteur d'analyse des performances, de la fiabilité et d'autres données relatives aux systèmes

Dans ce mode, le LLM est alimenté par la sortie d'un autre outil utilisé par l'ingénieur, tel qu'un outil de ligne de commande Linux, un profileur ou une plate-forme d'observabilité. L'objectif de sysgrok est d'interpréter, de résumer et de suggérer des remèdes.

Par exemple, la sous-commande topn prend les fonctions les plus coûteuses telles que rapportées par un profiler, explique le résultat et suggère ensuite des moyens d'optimiser le système.

Cette vidéo montre également la fonctionnalité de chat fournie par sysgrok. Lorsque l'argument -chat est fourni, sysgrok entre dans une session de chat après chaque réponse du LLM.

Cette capacité peut également être appliquée de manière générique à la sortie des outils de ligne de commande Linux. Par exemple, dans l'article Linux Performance Analysis in 60 seconds, Brendan Gregg présente 10 commandes qu'un SRE doit exécuter lorsqu'il se connecte pour la première fois à un hôte qui présente un problème de performance ou de stabilité. La sous-commande analyzecmd prend en entrée un hôte auquel se connecter et une commande à exécuter, puis analyse et résume la sortie de la commande pour l'utilisateur. Nous pouvons l'utiliser pour automatiser le processus décrit par Gregg et donner à l'utilisateur un résumé d'un paragraphe de toutes les données générées par les 10 commandes, lui évitant ainsi d'avoir à parcourir la sortie de chaque commande une par une.

Approche 2 : Solution automatisée et ciblée pour des tâches spécifiques liées à la performance et à la fiabilité

Certaines tâches reviennent régulièrement dans les travaux d'ingénierie des performances et de SRE. Pour ces derniers, nous pouvons construire des assistants automatisés et ciblés qui peuvent être utilisés soit directement par l'ingénieur, soit par sysgrok lui-même pour résoudre d'autres problèmes.

Par exemple, la sous-commande findfaster prend en entrée le nom d'une bibliothèque ou d'un programme et utilise le LLM pour trouver un remplacement équivalent plus rapide. Il s'agit d'une tâche très courante dans le domaine de l'ingénierie de la performance.

Un autre exemple de cette approche dans sysgrok est la sous-commande explainfunction. Cette sous-commande prend le nom d'une bibliothèque et d'une fonction au sein de cette bibliothèque. Il explique ce que fait la bibliothèque et ses cas d'utilisation courants, puis il explique la fonction. Enfin, il suggère des optimisations possibles si cette bibliothèque et cette fonction consomment une quantité importante de ressources de l'unité centrale.

Approche 3 : En tant qu'outil d'analyse automatisée des causes profondes des problèmes de performance et de fiabilité

L'utilisation des LLM ne se limite pas à la réponse à des questions ciblées, à l'élaboration de résumés et à des tâches similaires. Elle ne se limite pas non plus à une utilisation ponctuelle, où une seule question isolée leur est posée. La sous-commande sysgrok debughost démontre comment un LLM peut être utilisé comme le cerveau "" dans un agent dans le but de résoudre des problèmes de manière automatisée. Dans ce mode, le LLM est intégré à un processus qui l'utilise pour décider de la manière de déboguer un problème particulier et lui donne la possibilité de se connecter à des hôtes, d'exécuter des commandes et d'accéder à d'autres sources de données.

La commande debughost est probablement la partie la plus expérimentale de sysgrok pour le moment. Il s'agit d'une étape sur la voie des agents automatisés pour l'analyse des performances, mais il faut encore beaucoup de R&D pour y parvenir.

Conclusion

Dans ce billet, j'ai présenté sysgrok, un nouvel assistant IA open-source pour l'analyse, la compréhension et l'optimisation des systèmes. Nous avons également abordé les trois grandes catégories d'approches mises en œuvre par sysgrok :

1. Moteur d'analyse des performances, de la fiabilité et d'autres données relatives aux systèmes : Voir les sous-commandes topn, stacktrace, analyzecmd et code.

2. Solutions ciblées et automatisées à des tâches spécifiques liées à la performance et à la fiabilité : Voir les sous-commandes explainprocess, explainfunction et findfaster.

3. Analyse automatisée des causes profondes des problèmes de performance et de fiabilité : Voir la sous-commande debughost.

Vous pouvez trouver le projet sysgrok sur GitHub. N'hésitez pas à créer des relations publiques et des questions, ou à me contacter directement via sean.heelan@elastic.co si vous souhaitez discuter du projet ou des applications des LLM en général.

Où nous avons commencé

La première version d'Elasticsearch a été publiée en 2010 en tant que moteur de recherche évolutif distribué permettant aux utilisateurs de rechercher rapidement des informations critiques et de les faire remonter à la surface. Douze ans et plus de 65 000 modifications plus tard, Elasticsearch continue de fournir aux utilisateurs des solutions éprouvées à une grande variété de problèmes de recherche. Grâce aux efforts de plus de 1 500 contributeurs, dont des centaines d'employés d'Elastic à temps plein, Elasticsearch a constamment évolué pour relever les nouveaux défis qui se présentent dans le domaine de la recherche.

Au début de la vie d'Elasticsearch, lorsque des problèmes de perte de données ont été soulevés, l'équipe d'Elastic a entrepris un effort pluriannuel pour réécrire le système de coordination des clusters afin de garantir que les données reconnues sont stockées en toute sécurité. Lorsqu'il est apparu clairement que la gestion des index dans les grands clusters était un problème, l'équipe a travaillé à la mise en œuvre d'une solution ILM complète pour automatiser ce travail en permettant aux utilisateurs de prédéfinir des modèles d'index et des actions de cycle de vie. Les utilisateurs ayant constaté la nécessité de stocker des quantités importantes de données métriques et de séries chronologiques, diverses fonctionnalités telles qu'une meilleure compression ont été ajoutées afin de réduire la taille des données. Comme le coût de stockage pour la recherche de grandes quantités de données froides augmentait, nous avons investi dans la création d'instantanés consultables (Searchable Snapshots ) comme moyen de rechercher des données d'utilisateur directement sur des magasins d'objets à faible coût.

Ces investissements jettent les bases de la prochaine évolution d'Elasticsearch. Avec la croissance des services cloud-native et des nouveaux systèmes d'orchestration, nous avons décidé qu'il était temps de faire évoluer Elasticsearch pour améliorer l'expérience de travail avec les systèmes cloud-native. Nous pensons que ces changements offrent des possibilités d'amélioration des opérations, des performances et des coûts lors de l'exécution d'Elasticsearch sur Elastic Cloud.

Où nous allons - Adopter une architecture sans état

L'une des principales difficultés rencontrées lors de l'exploitation ou de l'orchestration d'Elasticsearch réside dans le fait qu'il dépend de nombreux éléments d'état persistants, et qu'il s'agit donc d'un système avec état. Les trois éléments principaux sont le translog, le magasin d'index et les métadonnées de la grappe. Cet état signifie que le stockage doit être persistant et ne peut être perdu lors du redémarrage ou du remplacement d'un nœud.

L'architecture Elasticsearch existante sur Elastic Cloud doit dupliquer l'indexation sur plusieurs zones de disponibilité pour assurer la redondance en cas de panne. Nous avons l'intention de transférer la persistance de ces données des disques locaux vers un magasin d'objets, comme AWS S3. En nous appuyant sur des services externes pour le stockage de ces données, nous supprimerons le besoin de réplication de l'indexation, ce qui réduira considérablement le matériel associé à l'ingestion. Cette architecture offre également des garanties de durabilité très élevées grâce à la manière dont les magasins d'objets en nuage tels que AWS S3, GCP Cloud Storage et Azure Blob Storage répliquent les données à travers les zones de disponibilité.

Le fait de décharger le stockage de l'index dans un service externe nous permettra également de réarchitecturer Elasticsearch en séparant les responsabilités d'indexation et de recherche. Au lieu d'avoir des instances primaires et répliquées gérant les deux charges de travail, nous avons l'intention d'avoir un niveau d'indexation et un niveau de recherche. La séparation de ces charges de travail permettra de les dimensionner indépendamment et de mieux cibler le choix du matériel en fonction des cas d'utilisation respectifs. Il permet également de résoudre un problème de longue date, à savoir que la charge de recherche et la charge d'indexation peuvent avoir un impact l'une sur l'autre.

Après une phase expérimentale de plusieurs mois, nous sommes convaincus que ces services de stockage d'objets répondent aux exigences que nous envisageons pour le stockage des index et des métadonnées des grappes. Nos tests et benchmarks indiquent que ces services de stockage peuvent répondre aux besoins d'indexation élevés des plus grands clusters que nous avons vus dans Elastic Cloud. En outre, la sauvegarde des données dans le magasin d'objets réduit les coûts d'indexation et permet de régler facilement les performances de la recherche. Pour rechercher des données, Elasticsearch utilisera le modèle Searchable Snapshots, qui a fait ses preuves, dans lequel les données sont conservées en permanence dans le magasin d'objets natif du nuage et les disques locaux sont utilisés comme caches pour les données auxquelles on accède fréquemment.

Pour faciliter la différenciation, nous décrivons notre modèle existant comme étant la réplication "de nœud à nœud". Dans l'étage chaud de ce modèle, l'étage primaire et l'étage réplique effectuent tous deux les mêmes tâches lourdes pour gérer l'ingestion et répondre aux demandes de recherche. Ces nœuds sont "stateful" en ce sens qu'ils s'appuient sur leurs disques locaux pour conserver en toute sécurité les données des ensembles qu'ils hébergent. En outre, les cartes primaires et les cartes répliques communiquent en permanence pour rester synchronisées. Pour ce faire, ils répliquent les opérations effectuées sur le groupe primaire vers le groupe réplique, ce qui signifie que le coût de ces opérations (CPU, principalement) est supporté pour chaque réplique spécifiée. Les mêmes unités de stockage et nœuds qui effectuent ce travail pour l'ingestion servent également à répondre aux demandes de recherche, de sorte que le dimensionnement et la mise à l'échelle doivent être effectués en tenant compte des deux charges de travail.

Au-delà de la recherche et de l'acquisition de données, les unités dans le modèle de réplication nœud à nœud gèrent d'autres responsabilités intensives, telles que la fusion de segments Lucene. Bien que cette conception ait ses mérites, nous avons vu beaucoup d'opportunités basées sur ce que nous avons appris avec nos clients au fil des ans et sur l'évolution de l'écosystème plus large de l'informatique dématérialisée.

La nouvelle architecture permet de nombreuses améliorations immédiates et futures :

1. Il est possible d'augmenter considérablement le débit d'ingestion sur le même matériel ou, pour voir les choses autrement, d'améliorer considérablement l'efficacité pour la même charge de travail d'ingestion. Cette augmentation provient de la suppression de la duplication des opérations d'indexation pour chaque réplique. Les opérations d'indexation gourmandes en ressources humaines n'ont lieu qu'une seule fois au niveau de l'indexation, qui achemine ensuite les segments résultants vers un magasin d'objets. À partir de là, les données sont prêtes à être consommées telles quelles par le niveau de recherche.

2. Vous pouvez séparer le calcul du stockage pour simplifier la topologie de votre cluster. Aujourd'hui, Elasticsearch dispose de plusieurs niveaux de données (contenu, chaud, tiède, froid et gelé) pour faire correspondre les données au profil du matériel. Le niveau "chaud" est destiné à la recherche en temps quasi réel et le niveau "gelé" est destiné aux données moins fréquemment recherchées. Bien que ces niveaux apportent de la valeur, ils augmentent également la complexité. Dans la nouvelle architecture, les niveaux de données ne seront plus nécessaires, ce qui simplifiera la configuration et le fonctionnement d'Elasticsearch. Nous séparons également l'indexation de la recherche, ce qui réduit encore la complexité et nous permet de faire évoluer les deux charges de travail de manière indépendante.

3. Vous pouvez réduire les coûts de stockage au niveau de l'indexation en diminuant la quantité de données qui doivent être stockées sur un disque local. Actuellement, Elasticsearch doit stocker une copie complète du shard sur les nœuds chauds (à la fois primaires et répliqués) à des fins d'indexation. Avec l'approche sans état qui consiste à indexer directement le magasin d'objets, seule une partie de ces données locales est nécessaire. Pour les cas d'utilisation de type append only, seules certaines métadonnées devront être stockées pour l'indexation. Cela permettra de réduire considérablement le stockage local nécessaire à l'indexation.

4. Vous pouvez réduire les coûts de stockage associés aux requêtes de recherche. En faisant du modèle des instantanés consultables le mode natif de recherche des données, le coût de stockage associé aux requêtes de recherche diminuera de manière significative. En fonction des besoins des utilisateurs en matière de latence de recherche, Elasticsearch permettra des ajustements pour augmenter la mise en cache locale des données fréquemment demandées.

Analyse comparative - 75% amélioration du débit d'indexation

Afin de valider cette approche, nous avons mis en œuvre une vaste démonstration de faisabilité dans laquelle les données n'étaient indexées que sur un seul nœud et la réplication était assurée par des magasins d'objets dans le nuage. Nous avons constaté que nous pouvions améliorer le débit d'indexation de 75% en supprimant la nécessité de dédier du matériel à la réplication de l'indexation. En outre, le coût de l'unité centrale associé à la simple extraction des données du magasin d'objets était bien inférieur à l'indexation des données et à leur écriture locale, comme c'est le cas aujourd'hui pour la couche chaude. Cela signifie que les nœuds de recherche pourront consacrer entièrement leur CPU à la recherche.

Ces tests de performance ont été réalisés sur un cluster de deux nœuds avec les trois principaux fournisseurs de clouds publics (AWS, GCP et Azure). Nous avons l'intention de continuer à développer des benchmarks plus importants au fur et à mesure de la mise en place d'une implémentation sans état de la production.

Débit d'indexation

Utilisation de l'unité centrale

Apatrides pour nous, économies pour vous

L'architecture sans état d'Elastic Cloud vous permettra de réduire la surcharge d'indexation, de faire évoluer indépendamment l'ingestion et la recherche, de simplifier la gestion des niveaux de données et d'accélérer les opérations, telles que la mise à l'échelle ou la mise à niveau. Il s'agit de la première étape vers une modernisation substantielle de la plateforme Elastic Cloud.

Participez à notre vision d'Elasticsearch sans état d'âme

Vous souhaitez tester cette solution avant tout le monde ? Vous pouvez nous contacter sur discuss ou sur le canal slack de notre communauté. Nous serions ravis de recevoir vos commentaires pour nous aider à définir l'orientation de notre nouvelle architecture.

Arrière-plan

Lors du développement d'Elasticsearch, nous rencontrons parfois un problème important pour lequel il n'existe pas d'approche simple ou établie. Il est naturel de se demander s'il existe un document universitaire traitant de cette question. D'autres fois, le travail universitaire est une source d'inspiration. Nous tombons sur un article proposant un nouvel algorithme ou une nouvelle structure de données et nous nous disons "ce serait tellement utile !". Voici quelques exemples de la façon dont Elasticsearch et Apache Lucene intègrent des travaux universitaires :

• HyperLogLog++ pour les agrégations de cardinalité

• Algorithme C3 pour la sélection adaptative des répliques

• Graphes hiérarchiques navigables du petit monde (HNSW) pour la recherche du vecteur le plus proche dans Lucene

• Statistique MIC pour améliorer la classification par apprentissage automatique

• Block-max WAND pour une recherche plus rapide des meilleurs résultats dans Lucene

• ... et bien d' autres encore

Les articles universitaires constituent une ressource inestimable pour les ingénieurs qui développent des systèmes à forte intensité de données. Mais leur mise en œuvre peut être intimidante et sujette à des erreurs - les descriptions d'algorithmes sont souvent complexes et des détails pratiques importants sont omis. Les tests constituent un véritable défi : par exemple, comment tester de manière approfondie un algorithme d'apprentissage automatique dont le résultat dépend étroitement de l'ensemble de données ?

Évaluez le document comme vous le feriez pour une dépendance logicielle.

L'ajout d'une nouvelle dépendance logicielle nécessite une évaluation minutieuse : si l'autre paquet est incorrect, lent ou peu sûr, notre projet pourrait l'être aussi. Avant d'intégrer une dépendance, les développeurs veillent à en évaluer la qualité.

Il en va de même pour les travaux universitaires que vous envisagez de mettre en œuvre. On peut penser que parce qu'un algorithme a été publié dans un article, il doit être correct et performant. Mais même s'il a été soumis à un processus d'examen, un document universitaire peut présenter des problèmes. Peut-être que la preuve d'exactitude repose sur des hypothèses qui ne sont pas réalistes. Il se peut aussi que la section "expériences" montre des performances nettement supérieures à celles de la ligne de base, mais que cela ne soit valable que pour un ensemble de données spécifique. Même si le document est de grande qualité, son approche peut ne pas convenir à votre projet.

Lorsque l'on se demande si l'on doit accepter une "dépendance" à l'égard d'un document universitaire, il est utile de se poser les mêmes questions que celles que l'on se poserait à l'égard d'un logiciel :

• La bibliothèque est-elle largement utilisée et "testée au combat" ? → D'autres paquets ont-ils mis en œuvre ce document, et cela a-t-il bien fonctionné pour eux ?

• Existe-t-il des critères de performance ? Ces données vous semblent-elles exactes et équitables ? → L'article comporte-t-il des expériences réalistes ? Sont-ils bien conçus ?

• L'amélioration des performances est-elle suffisamment importante pour justifier la complexité ? → Le document est-il comparable à une approche de référence solide ? Dans quelle mesure la performance est-elle supérieure à celle de la base de référence ?

• L'approche s'intégrera-t-elle bien à notre système ? → Les hypothèses et les compromis de l'algorithme sont-ils adaptés à notre cas d'utilisation ?

D'une manière ou d'une autre, lorsqu'un logiciel publie une comparaison de ses performances avec celles de ses concurrents, c'est toujours le logiciel qui est le plus rapide ! Si une tierce partie a conçu les critères de référence, ils peuvent être plus équilibrés. Le même phénomène s'applique aux travaux universitaires. Si un algorithme donne de bons résultats non seulement dans l'article original, mais apparaît également dans d'autres articles comme une référence solide, il est très probable qu'il soit solide.

Soyez créatifs avec les tests

Les algorithmes tirés d'articles universitaires ont souvent un comportement plus sophistiqué que les types d'algorithmes que nous rencontrons couramment. Il s'agit peut-être d'un algorithme d'approximation qui troque la précision contre une plus grande rapidité. Il peut aussi s'agir d'une méthode d'apprentissage automatique qui prend en compte un vaste ensemble de données et produit des résultats (parfois inattendus). Comment pouvons-nous écrire des tests pour ces algorithmes si nous ne pouvons pas caractériser leur comportement de manière simple ?

Focus sur les invariants

Lors de la conception des tests unitaires, il est courant de penser en termes d'exemples : si nous donnons à l'algorithme cet exemple d'entrée, il devrait produire cette sortie. Malheureusement, pour la plupart des algorithmes mathématiques, les tests basés sur des exemples ne couvrent pas suffisamment leur comportement.

Considérons l'algorithme C3, qu'Elasticsearch utilise pour déterminer quel nœud doit traiter une requête de recherche. Il classe chaque nœud à l'aide d'une formule nuancée qui incorpore le service précédent et les temps de réponse du nœud, ainsi que la taille de sa file d'attente. Tester quelques exemples ne permet pas vraiment de vérifier que nous avons compris la formule correctement. Il est utile de prendre du recul et de réfléchir au test des invariants : si le temps de service augmente, le rang du nœud diminue-t-il ? Si la taille de la file d'attente est de 0, le rang est-il déterminé par le temps de réponse, comme le prétend le document ?

Se concentrer sur les invariants peut s'avérer utile dans un certain nombre de cas courants :

• La méthode est-elle censée ne pas tenir compte de l'ordre ? Si c'est le cas, le fait de passer les données d'entrée dans un ordre différent devrait produire le même résultat.

• Certaines étapes de l'algorithme produisent-elles des probabilités de classe ? Si c'est le cas, la somme de ces probabilités doit être égale à 1.

• La fonction est-elle symétrique par rapport à l'origine ? Si c'est le cas, l'inversion du signe de l'entrée devrait simplement inverser le signe de la sortie.

Lorsque nous avons mis en œuvre C3 pour la première fois, nous avons eu un problème dans la formule où nous avons accidentellement utilisé l'inverse du temps de réponse à la place du temps de réponse. Cela signifie que les nœuds les plus lents peuvent être mieux classés ! Lors de la correction du problème, nous avons veillé à ajouter des vérifications invariantes afin d'éviter de nouvelles erreurs.

Comparer avec une implémentation de référence

Parallèlement à l'article, les auteurs ont publié une mise en œuvre de l'algorithme. (Cela est particulièrement probable si l'article contient des expériences, car de nombreuses revues exigent que les auteurs publient le code permettant de reproduire les résultats). Vous pouvez tester votre approche par rapport à cette implémentation de référence pour vous assurer que vous n'avez pas oublié des détails importants de l'algorithme.

Lors du développement de l'implémentation HNSW de Lucene pour la recherche du plus proche voisin, nous avons testé une bibliothèque de référence créée par les auteurs de l'article. Nous avons testé Lucene et la bibliothèque sur le même ensemble de données, en comparant la précision de leurs résultats et le nombre de calculs qu'ils ont effectués. Lorsque ces nombres correspondent étroitement, nous savons que Lucene met fidèlement en œuvre l'algorithme.

Lors de l'intégration d'un algorithme dans un système, il est souvent nécessaire de procéder à des modifications ou à des extensions, comme l'adaptation à plusieurs cœurs ou l'ajout d'heuristiques pour améliorer les performances. Il est préférable de commencer par mettre en œuvre une version "vanilla", de la tester par rapport à la référence, puis d'y apporter des modifications incrémentielles. Vous pouvez ainsi être sûr d'avoir capturé tous les éléments clés avant de procéder à des personnalisations.

Duel contre un algorithme existant

La dernière section propose une autre idée d'invariant de test : comparer le résultat de l'algorithme à celui d'un algorithme plus simple et mieux compris. Prenons l'exemple de l'algorithme WAND block-max de Lucene, qui accélère la recherche de documents en ignorant ceux qui ne peuvent pas figurer dans les premiers résultats. Il est difficile de décrire exactement le comportement de l'outil WAND block-max dans tous les cas, mais nous savons que son application ne devrait pas modifier les premiers résultats ! Nos tests peuvent donc générer plusieurs requêtes de recherche aléatoires, puis les exécuter avec et sans l'optimisation WAND et vérifier que les résultats correspondent toujours.

Un aspect important de ces tests est qu'ils génèrent des entrées aléatoires sur lesquelles la comparaison est effectuée. Cela peut permettre de mettre en œuvre des cas auxquels vous n'auriez pas pensé et de mettre en évidence des problèmes inattendus. Par exemple, le test de comparaison aléatoire de Lucene pour la notation BM25F a permis de détecter des bogues dans des cas subtils. L'idée d'alimenter un algorithme avec des entrées aléatoires est étroitement liée au concept de fuzzing, une technique de test courante dans le domaine de la sécurité informatique.

Elasticsearch et Lucene utilisent fréquemment cette approche de test. Si vous voyez un test qui mentionne un duel "" entre deux algorithmes (TestDuelingAnalyzers, testDuelTermsQuery...), vous savez que cette stratégie est en action.

Utiliser la terminologie du document

Lorsqu'un autre développeur travaillera avec votre code, il devra consulter le document pour en suivre les détails. Le commentaire sur l'implémentation HyperLogLog++ d'Elasticsearch le dit bien : "Essayer de comprendre ce que fait cette classe sans avoir lu le document est considéré comme aventureux." Ce commentaire de méthode constitue également un bon exemple. Elle comprend un lien vers l'article universitaire et met en évidence les modifications apportées à l'algorithme tel qu'il a été décrit à l'origine.

Étant donné que les développeurs fonderont leur compréhension du code sur le document, il est utile d'utiliser exactement la même terminologie. La notation mathématique étant laconique, il peut en résulter des noms qui ne seraient pas habituellement considérés comme "de bon style", mais qui sont très clairs dans le contexte de l'article. Les formules tirées d'articles universitaires sont l'une des rares occasions où vous rencontrerez des noms de variables cryptiques dans Elasticsearch, comme rS et muBarSInverse.

La façon recommandée par l'auteur pour lire un article : avec un grand café.

Vous pouvez envoyer un courriel à l'auteur

Lorsque vous travaillez sur un document difficile, vous pouvez passer des heures à réfléchir à une formule, sans savoir si vous avez mal compris ou s'il s'agit simplement d'une erreur de frappe. S'il s'agissait d'un projet open source, vous pourriez poser une question sur GitHub ou StackOverflow. Mais à qui s'adresser pour obtenir un travail universitaire ? Les auteurs semblent occupés et pourraient être ennuyés par vos courriels.

Au contraire, de nombreux universitaires aiment entendre que leurs idées sont mises en pratique et sont heureux de répondre à des questions par courrier électronique. Si vous travaillez sur un produit qu'ils connaissent bien, il se peut même qu'ils listent l'application sur leur site web !

Les universitaires ont également de plus en plus tendance à discuter de leurs articles en public, en utilisant les mêmes outils que ceux utilisés pour le développement de logiciels. Si un article est accompagné d'un logiciel, vous pouvez trouver des réponses aux questions les plus courantes sur Github. Les communautés Stack Exchange telles que "Theoretical Computer Science" et "Cross Validated" contiennent également des discussions détaillées sur les articles les plus populaires. Certaines conférences ont commencé à publier en ligne tous les comptes rendus d'articles. Ces revues contiennent des discussions avec les auteurs qui peuvent apporter des informations utiles sur l'approche.

A suivre

Cet article se concentre sur les bases du choix d'un document académique et sur la manière de le choisir.

L'algorithme doit être mis en œuvre correctement, mais il ne couvre pas tous les aspects du déploiement réel de l'algorithme. Par exemple, si l'algorithme n'est qu'un élément d'un système complexe, comment s'assurer que les modifications apportées à cet élément conduisent à des améliorations de bout en bout ? Et que se passe-t-il si l'intégration de l'algorithme nécessite des modifications ou des extensions substantielles que l'article original ne couvre pas ? Il s'agit là de sujets importants sur lesquels nous espérons revenir dans de prochains articles.