Comparaison Des Bases De Données Vectorielles - Weaviate, Milvus Et Qdrant
Le succès du système RAG dépend en grande partie de sa capacité à acquérir et traiter efficacement une masse d’informations. Les bases de données vectorielles jouent un rôle irremplaçable dans ce processus et constituent le cœur du système RAG. Les bases de données vectorielles sont spécialement conçues pour stocker et gérer des données vectorielles de haute dimension. Elles peuvent convertir et stocker des textes, images, audio et même vidéos en vecteurs (ce point sera détaillé plus loin). L’efficacité finale du système RAG dépend donc des performances de ces bases de données vectorielles sous-jacentes.
Parmi les nombreuses bases de données vectorielles et bibliothèques de vecteurs, chacune a ses propres caractéristiques, et choisir celle qui convient à son application nécessite une évaluation. Cet article explore en profondeur les facteurs clés à considérer lors du choix d’une base de données vectorielle pour le RAG, notamment la disponibilité open source, le support CRUD (création, lecture, mise à jour, suppression), l’architecture distribuée, le support des répliques, l’évolutivité, les performances et la maintenance continue.
Actuellement, des bases de données conçues spécifiquement pour les vecteurs comme Weaviate, Milvus, Qdrant, Vespa et Pinecone attirent beaucoup d’attention dans l’industrie. En outre, certaines bibliothèques de vecteurs plus anciennes possèdent également ces fonctionnalités. Cet article compare également diverses bibliothèques de vecteurs telles que FAISS, HNSWLib, ANNOY, ainsi que des bases de données SQL prenant en charge les vecteurs, comme pgvector et Supabase.
Recherche sémantique d'images réalisée avec Milvus1 Bibliothèques de vecteurs (FAISS, HNSWLib, ANNOY)
La différence entre les bases de données vectorielles et les bibliothèques de vecteurs réside dans le fait que les bibliothèques de vecteurs sont principalement utilisées pour stocker des données statiques, où les données d’index sont immuables. Cela est dû au fait que les bibliothèques de vecteurs ne stockent que les embeddings vectoriels et ne stockent pas les objets associés qui génèrent ces embeddings vectoriels. Par conséquent, contrairement aux bases de données vectorielles, les bibliothèques de vecteurs ne prennent pas en charge les opérations CRUD. Cela signifie qu’il peut être difficile d’ajouter de nouveaux documents à un index existant dans des bibliothèques de vecteurs comme FAISS ou ANNOY. HNSWLib est une exception, car elle dispose de fonctionnalités CRUD et prend en charge de manière unique les opérations de lecture et d’écriture concurrentes. Cependant, elle ne peut échapper aux limitations d’une bibliothèque de vecteurs, à savoir l’absence de capacité de déploiement d’écosystème, de réplication d’instances et de tolérance aux pannes.
2 Bases de données de recherche en texte intégral (ElasticSearch, OpenSearch)
Les bases de données de recherche en texte intégral (par exemple, ElasticSearch et OpenSearch) peuvent prendre en charge des fonctions de recherche textuelle et d’analyse avancée relativement complètes. Cependant, lorsqu’il s’agit d’exécuter des recherches de similarité vectorielle et de traiter des données de haute dimension, elles ne sont pas aussi puissantes que les bases de données vectorielles spécialisées. Ces bases de données nécessitent souvent l’utilisation d’autres outils pour réaliser des recherches sémantiques, car elles reposent principalement sur des index inversés plutôt que sur des index vectoriels. Selon les résultats des tests de Qdrant, ElasticSearch est à la traîne par rapport à des bases de données vectorielles comme Weaviate, Milvus et Qdrant en termes de performances.
3 Bases de données SQL prenant en charge les vecteurs (pgvector, Supabase, StarRocks)
Les bases de données SQL comme pgvector, grâce à leurs extensions de support vectoriel, offrent un moyen d’intégrer les données vectorielles dans les systèmes de stockage de données existants, mais elles présentent également certains inconvénients évidents par rapport aux bases de données vectorielles spécialisées.
Le défaut le plus évident est le décalage entre le modèle relationnel des bases de données SQL traditionnelles et la nature des données vectorielles non structurées. Ce décalage entraîne une inefficacité des opérations impliquant des recherches de similarité vectorielle, et ces bases de données ne sont pas idéales pour la construction d’index et le traitement de grandes quantités de données vectorielles, comme le montre le test ANN. De plus, la limite de dimension des vecteurs supportée par pgvector (2000 dimensions) est relativement faible par rapport à des bases de données vectorielles spécialisées comme Weaviate, qui peut traiter des données vectorielles allant jusqu’à 65535 dimensions. En termes d’évolutivité et d’efficacité, les bases de données vectorielles spécialisées ont également un avantage. Les extensions de bases de données SQL prenant en charge les vecteurs, telles que pgvector, conviennent mieux aux scénarios où le volume de données vectorielles est faible (moins de 100 000 vecteurs) et où les données vectorielles ne sont qu’une fonction complémentaire de l’application. En revanche, si les données vectorielles sont au cœur de l’application ou si des exigences élevées en matière d’évolutivité sont nécessaires, les bases de données vectorielles spécialisées sont un choix plus approprié.
Quant à StarRocks, c’est un autre système fonctionnant sur un cadre SQL, optimisé pour les scénarios de traitement analytique en ligne (OLAP) et de traitement transactionnel en ligne (OLTP), mais il n’est pas spécialement optimisé pour les recherches de similarité vectorielle.
4 Bases de données NoSQL prenant en charge les vecteurs (Redis, MongoDB)
Les fonctionnalités de support vectoriel nouvellement ajoutées dans les bases de données NoSQL sont encore à un stade précoce et n’ont pas encore été suffisamment testées et vérifiées. Prenons l’exemple de la recherche de similarité vectorielle (VSS) de Redis, cette fonctionnalité a été publiée en avril 2022, il y a moins de deux ans. Bien que Redis VSS puisse servir de base de données multifonctionnelle, elle n’est pas optimisée et conçue spécifiquement pour la recherche de similarité vectorielle.
5 Bases de données vectorielles spécialisées (Pinecone, Milvus, Weaviate, Qdrant, Vald, Chroma, Vespa, Vearch)
Les bases de données vectorielles spécialisées prennent en charge nativement diverses opérations vectorielles, telles que le produit scalaire, la similarité cosinus, etc. Ces bases de données sont conçues pour traiter des données de haute dimension, capables de gérer un grand nombre de requêtes et de réaliser rapidement des recherches de similarité entre vecteurs. Pour atteindre ces objectifs, elles adoptent diverses stratégies d’indexation, souvent basées sur des algorithmes de plus proche voisin approximatif (ANN). Ces algorithmes nécessitent de faire des compromis entre efficacité, occupation de l’espace de stockage et précision de la recherche. Par exemple, l’index FLAT est un index vectoriel qui n’utilise aucune technique d’optimisation ou d’approximation, ce qui signifie qu’il peut atteindre un taux de rappel et une précision de 100 %, mais il est également plus lent et moins efficace que d’autres types d’index vectoriels ; en revanche, l’index IVF_FLAT sacrifie une certaine précision pour obtenir une vitesse de recherche plus rapide ; l’index HNSW offre un compromis entre précision et vitesse de recherche.
Pinecone est une base de données vectorielle à code source fermé, maintenue par une équipe professionnelle, dont la version gratuite offre des fonctionnalités limitées en termes d’évolutivité. Chroma est un système spécialement conçu pour les données audio, mais il n’a pas été particulièrement optimisé pour le traitement des données textuelles. Par rapport à d’autres bases de données vectorielles grand public, Chroma manque de documentation sur les tests de performance globale. Étant donné que Chroma utilise SQLite comme méthode de stockage de documents dans sa version 0.4, il peut ne pas être aussi évolutif et efficace que d’autres solutions de stockage conçues spécifiquement pour les données vectorielles.
Vearch et Vald présentent des lacunes en matière d’intégration avec Langchain, ce qui est défavorable au développement et à l’utilisation. Par rapport à des concurrents comme Milvus, leur communauté de développeurs est plus petite et la maintenance de la communauté open source n’est pas très active.
Par conséquent, pour le RAG, Weaviate, Milvus, Qdrant et Vespa pourraient être les meilleurs choix. En théorie, le choix du système le plus approprié devrait être basé sur les tests de performance et d’évolutivité (voir ci-dessous les benchmarks ANN) mais il y a aussi des caractéristiques de conception du système et des fonctionnalités à comparer. Le tableau ci-dessous présente une comparaison visuelle de ces aspects.
Base de données | Qdrant | Weaviate | Milvus |
---|---|---|---|
Open source et auto-hébergeable | ✅ | ✅ | ✅ |
Licence open source | Apache-2.0 | BSD | Apache-2.0 |
Langage de développement | Rust | Go | Go, C++ |
Étoiles GitHub | 17k | 9.2k | 26.2k |
Date de première publication | 2021 | 2019 | 2019 |
SDK | Python, JS, Go, Java, .Net, Rust | Python, JS, Java, Go | Python, Java, JS, Go |
Service cloud hébergé | ✅ | ✅ | ✅ |
Intégration de texte intégrée | ✅FastEmbed | ✅ | ❌ |
Recherche hybride | ❌ | ✅RRF*+RSF* | ✅Recherche multi-vecteurs dans la table |
Filtrage des métadonnées | ✅ | ✅ | ✅ |
Support BM25 | ❌ | ✅ | ✅ |
Recherche de texte | ✅ | ✅ | ❌ |
Multi-vecteurs par point | ✅ | ✅ | |
Recherche Tensor | ❌ | ❌ | ❌ |
Intégration Langchain | ✅ | ✅ | ✅ |
Intégration de l’index Llama | ✅ | ✅ | ✅ |
Recherche d’informations géographiques | ✅ | ✅ | ❌ |
Support multi-locataires | ✅ via collections/métadonnées | ✅ | |
Limite de taille des métadonnées et des documents | Illimitée | ||
Dimension maximale | Illimitée | 65535 | 32768 |
Types d’index | HNSW | HNSW | ANNOY, FAISS, HNSW, ScANN … |
Indexation en flux | ❌ | ||
Support des vecteurs clairsemés | ❌ | ❌ | ❌ |
Support des index temporaires (sans serveur) | ✅ | ❌ | |
Sharding | |||
Prix | |||
Facettes (agrégation avec comptage) | ❌ | ✅ | |
Intégration d’images intégrée | ✅ | ||
API de recommandation | ✅ | ||
Personnalisation | |||
Événements utilisateur | |||
Utilisation de LLM intégré pour le RAG | ✅Recherche générative |
Base de données | Qdrant | Weaviate | Milvus |
---|---|---|---|
Avantages subjectifs | 1. Peut stocker plusieurs types de vecteurs (images, texte, etc.) dans une collection 2. Consommation de ressources très faible |
1. Performances relativement bonnes 2. Supporte l’intégration intégrée 3. Supporte la recherche de texte 4. API GraphQL 5. Supporte la sauvegarde S3 |
1. Interface d’opération visuelle supportée officiellement 2. Précision de recherche élevée 3. SDK riche 4. Accélération GPU |
En résumé, Qdrant a des coûts particulièrement faibles, Weaviate supporte la combinaison de la recherche vectorielle, du stockage d’objets et de l’index inversé, Milvus a les performances les plus fortes et le plus de fonctionnalités.
6 Comparaison des méthodes de recherche des bases de données vectorielles
Milvus | Weaviate | Qdrant | |
---|---|---|---|
Méthode de recherche unique | Recherche multi-vecteurs | Recherche par mots-clés BM25 + recherche hybride | Filtrage par mots-clés appliqué à la recherche vectorielle |
6.1 Milvus
Milvus supporte deux types de recherche, selon le nombre de champs vectoriels dans la collection : recherche mono-vecteur et recherche multi-vecteurs.
La recherche mono-vecteur utilise la méthode search(), compare le vecteur de requête avec les vecteurs existants dans la collection, et renvoie l’ID des entités les plus similaires et la distance entre elles. Il est également possible de renvoyer les valeurs vectorielles et les métadonnées des résultats de manière optionnelle.
La recherche multi-vecteurs est adaptée aux collections ayant deux champs vectoriels ou plus, et est exécutée via la méthode hybrid_search(), qui exécute plusieurs requêtes de recherche de plus proche voisin approximatif (ANN) et combine les résultats pour renvoyer les correspondances les plus pertinentes. (La dernière version 2.4.x supporte jusqu’à 10 vecteurs pour la recherche)
La recherche multi-vecteurs est particulièrement adaptée aux situations complexes nécessitant une haute précision, notamment lorsque la même entité peut être représentée par plusieurs vecteurs différents. Cela s’applique aux mêmes données (comme une phrase) traitées par différents modèles d’intégration, ou lorsque des informations multimodales (comme des images, empreintes digitales et empreintes vocales d’une personne) sont converties en divers formats vectoriels. Grâce au “rappel multi-chemins” à l’échelle de la table et à l’attribution de poids à ces vecteurs, leur action combinée peut augmenter considérablement la capacité de rappel et améliorer l’efficacité des résultats de recherche.
Autres opérations de recherche de base :
- La recherche de base comprend la recherche mono-vecteur, la recherche par lots de vecteurs, la recherche par partition et la recherche avec des champs de sortie spécifiés.
- La recherche par filtrage affine les résultats de recherche en fonction des conditions de filtrage des champs scalaires.
- La recherche par plage trouve les vecteurs situés dans une plage de distance spécifique par rapport au vecteur de requête.
- La recherche par regroupement regroupe les résultats de recherche en fonction d’un champ spécifique pour assurer la diversité des résultats.
6.2 Weaviate
- Recherche de similarité vectorielle : couvre une gamme de méthodes de recherche approximative, cette recherche cherche les objets les plus similaires à la représentation vectorielle de la requête.
- Recherche d’images : utilise des images comme entrée pour la recherche de similarité.
- Recherche par mots-clés : une recherche par mots-clés utilisant l’algorithme BM25F pour classer les résultats.
- Recherche hybride : combine BM25 et la recherche de similarité pour classer les résultats.
- Recherche générative : utilise les résultats de recherche comme prompts pour les LLM.
- Réorganisation : réorganise les résultats de recherche récupérés à l’aide d’un module de réorganisation.
- Agrégation : agrège les données à partir de l’ensemble des résultats.
- Filtres : applique des filtres conditionnels à la recherche.
6.3 Qdrant
Opérations de recherche de base supportées :
- Filtrage par score de pertinence
- Chargement de plusieurs opérations de recherche dans une seule requête
- API de recommandation
- Opérations de regroupement
Autres méthodes de recherche supportées par Qdrant :
Qdrant supporte-t-il une recherche en texte intégral ou une recherche hybride ?
Qdrant est avant tout un moteur de recherche vectorielle, nous ne mettons en œuvre un support complet du texte que si cela n’affecte pas les cas d’utilisation de la recherche vectorielle. Cela inclut l’interface et les performances.
Ce que Qdrant peut faire :
- Recherche avec des filtres de texte intégral
- Appliquer des filtres de texte intégral à la recherche vectorielle (c’est-à-dire effectuer une recherche vectorielle dans les enregistrements contenant un mot ou une phrase spécifique)
- Faire des recherches par préfixe et des recherches sémantiques instantanées
Fonctionnalités que Qdrant prévoit d’introduire à l’avenir :
- Support des vecteurs clairsemés, comme ceux utilisés dans SPLADE ou des modèles similaires
Fonctionnalités que Qdrant ne prévoit pas de supporter :
- BM25 ou d’autres fonctions de récupération ou de classement non basées sur les vecteurs
- Ontologie intégrée ou graphe de connaissances
- Analyseur de requêtes et autres outils NLP
- Score de pertinence :
- Une simple recherche par mots-clés est généralement basée sur la fréquence des mots : si un mot apparaît dans un document, alors ce document est considéré comme pertinent. Cette méthode peut simplement compter le nombre d’occurrences des mots-clés, et tous les mots-clés sont considérés comme également importants.
- BM25 utilise un algorithme plus complexe qui prend en compte non seulement la fréquence des mots, mais aussi la longueur du document et la fréquence inverse des documents (c’est-à-dire la rareté du mot dans l’ensemble des documents). Cela signifie que BM25 peut fournir un score de pertinence plus finement ajusté, reflétant mieux la correspondance entre la requête et le document.
- Traitement de la longueur du document :
- Une simple recherche par mots-clés peut ne pas tenir compte de la longueur du document. Cela peut conduire à une préférence excessive pour les documents plus longs (contenant plus de mots) simplement parce qu’ils ont plus de chances de contenir les mots-clés.
- BM25 prend en compte la longueur du document par un processus de normalisation interne à son algorithme, évitant ainsi ce biais et assurant une équité dans le score de pertinence entre les documents longs et courts.
- Importance des mots de la requête :
- Dans une simple recherche par mots-clés, tous les mots-clés peuvent être traités de manière égale, indépendamment de leur universalité.
- BM25 utilise la fréquence inverse des documents (IDF) pour ajuster l’importance de chaque mot de la requête. Cela signifie que les mots apparaissant dans moins de documents (plus uniques) auront un impact plus important sur le score de pertinence du document.
- Réglage des paramètres :
- Une simple recherche par mots-clés n’offre généralement pas beaucoup de paramètres configurables pour optimiser les résultats de recherche.
- BM25 fournit des paramètres (comme k1 et b) permettant un ajustement fin de la sensibilité de l’algorithme pour s’adapter à différents types de textes et besoins de recherche.
Comparé à une simple recherche par mots-clés, BM25 offre une méthode plus complexe et raffinée pour évaluer la pertinence entre les documents et les requêtes, pouvant produire des résultats de recherche plus précis et mieux alignés avec les attentes des utilisateurs.
Actuellement, la question qui se pose est de savoir s’il existe une solution qui permette à la fois de bénéficier des caractéristiques de recherche sémantique des bases de données vectorielles et de la précision de la recherche par mots-clés traditionnelle.
7 Annexe
7.1 Benchmarks ANN
Les benchmarks peuvent être perturbés par divers facteurs influençant les performances des bases de données, tels que le type de recherche (recherche filtrée ou recherche régulière), les paramètres de configuration, l’algorithme d’indexation, l’intégration des données, le matériel, etc. Outre les performances des benchmarks, le choix d’une bibliothèque de vecteurs doit également prendre en compte la capacité de distribution, le support des répliques en mémoire et du cache, l’algorithme d’indexation utilisé, la capacité de recherche de similarité vectorielle (y compris la recherche hybride, le filtrage et les mesures de similarité multiples), le mécanisme de sharding, la méthode de clustering, le potentiel d’évolutivité, la cohérence des données et la disponibilité globale du système.
ANN-Benchmarks est la principale plateforme de benchmark pour évaluer les performances de recherche des algorithmes de plus proche voisin approximatif. Dans la recherche de texte, les performances des bases de données vectorielles sur les mesures angulaires sont souvent plus importantes que leurs performances sur les mesures euclidiennes. En effet, les mesures angulaires sont plus sensibles à la similarité sémantique des documents textuels, tandis que les mesures euclidiennes sont plus sensibles à la longueur et à l’échelle des documents. Par conséquent, lors de l’évaluation du contexte généré par la recherche, il est plus important de se concentrer sur l’évaluation des performances des bases de données vectorielles sur des ensembles de données angulaires couvrant différentes dimensions.
7.1.1 glove-100-angular
Il est évident que Milvus a le débit le plus élevé lorsque la valeur de rappel est inférieure à 0,95. Lorsque la valeur de rappel dépasse 0,95, l'écart de débit se réduit. Vespa a le temps de construction le plus long. Weaviate et Milvus ont des temps de construction similaires, mais Milvus est légèrement plus long. En termes de taille d'index, Weaviate a l'index le plus petit. Bien que l'index de Milvus soit le plus grand, il est également inférieur à 1,5 Go (ensemble de données contenant 1,2 million de vecteurs, chaque vecteur ayant 100 dimensions).7.1.2 nytimes-256-angular
Les résultats sur cet ensemble de données sont similaires à ceux de l'ensemble de données glove-100-angular. Weaviate a le temps de construction le plus long et l'index le plus petit sur cet ensemble de données. L'index de Milvus est le plus grand, mais il ne fait que 440 Mo (ensemble de données contenant 290 000 vecteurs, chaque vecteur ayant 256 dimensions).7.2 Indicateurs de similarité vectorielle
Indicateur | Description | Bases de données supportées |
---|---|---|
Distance cosinus | Mesure la valeur du cosinus de l’angle entre deux vecteurs | pgvector, Pinecone, Weaviate, Qdrant, Milvus, Vespa |
Distance euclidienne (L2) | Calcule la distance en ligne droite entre deux vecteurs dans un espace multidimensionnel | pgvector, Pinecone, Qdrant, Milvus, Vespa |
Produit scalaire (produit point) | Calcule la somme des produits des composantes correspondantes des vecteurs | pgvector, Pinecone, Weaviate, Qdrant, Milvus |
Distance L2 au carré | Carré de la distance euclidienne entre deux vecteurs | Weaviate |
Distance de Hamming | Mesure le nombre de différences entre les vecteurs sur chaque dimension | Weaviate, Milvus, Vespa |
Distance de Manhattan | Mesure la distance entre les dimensions des vecteurs le long des axes orthogonaux | Weaviate |
Voici une présentation détaillée de chaque indicateur, y compris leurs avantages et inconvénients relatifs, ainsi que les scénarios d’utilisation adaptés.
7.2.1 Distance cosinus
La distance cosinus mesure la valeur du cosinus de l’angle entre deux vecteurs, souvent utilisée pour traiter des ensembles normalisés ou convexes.
- Avantages : Prend principalement en compte la direction des vecteurs, ce qui la rend très adaptée aux espaces de haute dimension, comme la comparaison de textes, car dans ce contexte, la longueur des documents est moins importante.
- Inconvénients : Pas adaptée aux scénarios nécessitant une correspondance des dimensions des vecteurs, par exemple lors de la comparaison des embeddings d’images basés sur la densité des pixels. Si les données ne forment pas un ensemble convexe, elle peut ne pas fournir une mesure de similarité précise.
La distance cosinus est adaptée à la classification de documents, à la recherche sémantique, aux systèmes de recommandation et à toute autre tâche impliquant des données de haute dimension et normalisées. Dans la recherche d’informations, la distance cosinus est souvent utilisée pour mesurer la similarité entre le contenu de la requête et les vecteurs de documents, en ignorant leur longueur mais en se concentrant sur la signification sémantique.
7.2.2 Distance euclidienne L2
La distance euclidienne calcule la distance en ligne droite entre deux vecteurs dans un espace multidimensionnel, également appelée norme-2.
- Avantages : Intuitive, facile à calculer, sensible à la fois à la taille et à la direction des vecteurs.
- Inconvénients : Peut ne pas bien fonctionner dans les espaces de haute dimension en raison de la “malédiction de la dimensionnalité”.
Adaptée aux scénarios de reconnaissance d’images, de reconnaissance vocale, d’analyse d’écriture manuscrite, etc.
7.2.3 Produit scalaire
Le produit scalaire calcule la somme des produits des composantes correspondantes des vecteurs, également appelé norme-n.
- Avantages : Calcul rapide, peut refléter la taille et la direction des vecteurs.
- Inconvénients : Sensible à la fois à la direction et à la taille des vecteurs.
L’application la plus classique du produit scalaire se trouve dans le domaine des systèmes de recommandation. Dans les systèmes de recommandation, le produit scalaire peut être utilisé pour déterminer la similarité entre les vecteurs utilisateur et les vecteurs d’articles, aidant à prédire l’intérêt d’un utilisateur pour un article. Le produit scalaire est adapté aux systèmes de recommandation, au filtrage collaboratif, à la décomposition matricielle.
7.2.4 Distance L2 au carré
Carré de la distance euclidienne entre deux vecteurs.
- Avantages : Pénalise les grandes différences entre les éléments des vecteurs, ce qui peut être utile dans certains cas.
- Inconvénients : L’opération de mise au carré peut fausser les distances et est sensible aux valeurs aberrantes.
La distance L2 au carré est particulièrement adaptée aux problèmes de différence d’éléments individuels, par exemple dans le traitement d’images, pour comparer les différences entre deux images.
7.2.5 Distance de Hamming
Mesure le nombre de différences entre les vecteurs sur chaque dimension.
- Avantages : Adaptée à la comparaison de données binaires ou catégorielles.
- Inconvénients : Pas adaptée aux données continues ou numériques.
Les scénarios d’application sont également assez spécifiques, par exemple la détection et la correction d’erreurs (données catégorielles) ; mesure de la distance génétique entre deux chaînes d’ADN.
7.2.6 Distance de Manhattan L1
Mesure la distance entre les dimensions des vecteurs le long des axes orthogonaux, également appelée norme-1.
- Avantages : Plus résistante aux valeurs aberrantes que la distance euclidienne.
- Inconvénients : Moins intuitive en termes de signification géométrique que la distance euclidienne.
Adaptée au calcul de la distance sur un échiquier, aux problèmes de planification logistique des chemins les plus courts.