Erreurs de recherche Elasticsearch : anti-patterns

Erreurs critiques de conception de la recherche Elasticsearch (et comment les éviter)

Dans les projets de recherche Elasticsearch, les équipes d’ingénierie commettent systématiquement les mêmes erreurs fondamentales. Ces problèmes se propagent d’un système à l’autre — indépendamment de l’expérience des équipes. Cet article les analyse comme des anti-patterns : des approches éprouvées qui garantissent une dégradation des performances, de la pertinence et du coût opérationnel.

Les identifier tôt est essentiel pour les ingénieurs confirmés et seniors. Bien que les exemples portent sur Elasticsearch, les principes s’appliquent universellement — à Solr, OpenSearch ou à toute pile de recherche personnalisée.

Ignorer la qualité des données

La recherche commence par le contenu — pas par les algorithmes. Les données sales constituent la première cause d’échec des systèmes de recherche. Doublons, textes non structurés et formats incohérents sapent directement la pertinence.

Problèmes courants :

• Aucune normalisation des noms de produits (ex. « iPhone 14 » vs. « Apple iPhone14 »).
• Descriptions non nettoyées, truffées de fautes de frappe et de caractères parasites.
• Enregistrements dupliqués sans déduplication.

Améliorer la qualité des données a plus d’impact que l’ajustement du classement. Ce travail incombe souvent aux juniors — mais exige une démarche systémique : pipelines ETL robustes, validation au moment de l’ingestion et surveillance continue de la qualité des index.

Sans données propres, ni BM25 ni les réordonnanceurs neuronaux ne vous sauveront. Dans les projets réels, 70 à 80 % des efforts vont à la qualité des données — pas à la logique de requête.

Omettre les exigences fonctionnelles et les indicateurs de performance

« Faites-le fonctionner comme Yandex » est une consigne vague classique. Sans exigences documentées et mesurables, la recherche devient subjective — et les équipes omettent de définir les objectifs métiers : pertinence dans les K premiers résultats, taux de recherche sans résultat, ou taux de clics.

Indicateurs clés d’évaluation :

• Précision@K — % de documents pertinents parmi les K premiers résultats.
• Rappel@K — % de tous les documents pertinents récupérés dans les K premiers résultats.
• NDCG — score de pertinence tenant compte de la position, avec notation graduée.
• CTR et taux de conversion, mesurés par session de recherche.
• Latence et QPS, sous charge réaliste.

L’évaluation manuelle des requêtes fréquentes ne remplace pas les tests A/B ni les métriques hors ligne. Sans elles, les régressions passent inaperçues : le classement se dégrade progressivement, les utilisateurs abandonnent silencieusement la recherche.

La « requête-roi » : monolithe contre évolutivité

Une requête monolithique gérant filtrage, agrégations, classement et pagination est un anti-pattern très répandu. Son attrait semble évident : cohérence, moins d’appels réseau. Mais son coût est élevé.

Inconvénients du monolithe :

• Temps d’exécution > 1 s sur des requêtes complexes.
• Maintenance cauchemardesque : ajouter une seule fonctionnalité oblige à refondre entièrement la requête.
• Le partitionnement (sharding) et la réplication deviennent inefficaces en raison de la taille de la requête et de la pression sur les ressources.

| Approche | Latence | Maintenabilité | Cohérence |

|----------|---------|----------------|-----------|

| Requête-roi | 1–3 s | Faible | Élevée |

| Micro-requêtes + cache | 50–200 ms | Élevée | Moyenne (avec cache) |

Décomposez la recherche en étapes : correspondance + filtrage → enrichissement → réordonnancement. Utilisez ESQL ou les pipelines d’ingestion pour optimiser.

La recherche floue comme solution universelle

Compter sur le paramètre fuzziness pour corriger automatiquement les fautes de frappe est un mythe Elasticsearch. Pour une requête comme « apliphone », Elasticsearch génère des centaines de variantes — « applesiphone », « aplfone », etc.

Conséquences :

• Le rappel augmente, mais la précision chute vertigineusement.
• La pertinence se dégrade : du bruit envahit les premiers résultats.
• Le coût de la requête est multiplié par 10 à 50.

Ajuster les paramètres ne résout pas la cause profonde :

{
  "query": {
    "multi_match": {
      "query": "apliphone",
      "fuzziness": "AUTO",
      "prefix_length": 2,
      "max_expansions": 50
    }
  }
}

prefix_length=2 réduit le bruit — mais ne règle pas le problème sous-jacent. Des solutions meilleures : correcteur orthographique côté frontend (Hunspell / Yandex.Speller) et graphes de synonymes appliqués à l’ingestion.

Objets imbriqués et jointures dans l’index

Le e-commerce exige des relations : produit → prix → stock → avis. La normalisation via des jointures parent-enfant semble logique — mais tue les performances.

Problèmes avec has_child/parent :

• La pagination profonde échoue totalement.
• Le scoring ne parvient pas à agréger correctement les scores à travers les relations.
• Tout changement de schéma déclenche un réindexage complet.

Recommandations :

• Dénormalisez : intégrez directement le prix et le stock dans le document produit.
• Utilisez des index séparés (ex. goods, prices) et effectuez les jointures côté client.
• Réservez les champs nested uniquement aux données fortement couplées et à faible cardinalité.

Points clés à retenir

• Données > Algorithmes : 80 % de la qualité de la recherche provient de la qualité des données.
• Les indicateurs sont obligatoires : Précision, Rappel et NDCG doivent être suivis pour chaque cas d’usage.
• Décomposez les requêtes : la requête-roi garantit une latence > 2 s.
• Utilisez la recherche floue avec parcimonie : uniquement pour les termes rares — et toujours couplée à un correcteur orthographique.
• Dénormalisez massivement : les jointures dans Elasticsearch sont un anti-pattern en production.

— Editorial Team