Clustering de documents non supervisé avec Elasticsearch + Jina embeddings

La recherche vectorielle s’appuie sur une requête, mais qu’en est-il si vous n’en avez aucune ?

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 :

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.