Optimisation de la recherche Elasticsearch

[vicpsl]

Lettres, moteur de recherche

Sommaire :

A. État courant de l'application
  I. Logique d'indexation et fonctionnement actuel de la recherche
  1. Filtres
  2. Recherche plein texte
  3. Combinaison de Filtres / Recherche plein texte
  4. Notes importantes concernant la recherche (Mise à jour index, Recherche approximative, Pagination, Cache)
  II. Précisions liées au fonctionnement de l'application
  1. Gestion des droits
  2. Quantification des Personnes, Lieux et Collections les plus présents dans un résultat de recherche

B. Objet de l'issue : optimisation du moteur de recherche
  I. Évaluation de l'existant
  1. Réaliser un audit succinct de l'existant afin de :
  2. résoudre les points suivants (voir B.II.) et
  3. implémenter les solutions (ou assistance à l'implémentation en fonction du temps utile disponible)
  II. Points à traiter
  1. Amélioration du temps de réponse
  2. Prévoir le dépassement de 10K documents dans les résultats de recherche

---

A. État courant de l'application :

Le moteur de recherche de l'application déployé dans l'application est basé sur Elasticsearch, version "6.8.22".
Le moteur de recherche doit permettre de rechercher des documents.

I. Logique d'indexation et fonctionnement actuel de la recherche :

L'implémentation actuelle répond aux besoins suivants :

1. FILTRER les documents à partir de leurs métadonnées, plutôt qu’en fonction d’un motif de recherche plein texte :

Le formulaire de recherche avancé, basé sur les métadonnées des documents, est accessible depuis la page /search de l'application ("Afficher les filtres").

Objectif : Filtrer et lister tous les documents correspondants aux critères de recherche sur la base de leurs métadonnées, par exemple :

Lettres mentionnant une/des personne(s) ET un/des lieu(x) pour une période définie.

Les filtres sont actuellement définis par :

• 1 formulaire de 4 critères éditables (filtres ci-dessous) et
• 1 calculé (périmètre d'accès aux documents limité selon le statut de connection des users)

FILTRES	Illustrations
Dates de temps : un slider doit permettre de sélectionner l’intervalle entre 2 années. Cf modèle ENCPOS (slider + 2 inputs pour spécifier une date). Ce champs est inclus dans l'index _documents : creation. Personnes : Input avec autocomplétion pour sélectionner 1 ou + personne(s), avec sélection possible de son(leurs) statut(s) : expéditeur, destinataire ou sujet. La sélection active est affichée sous la forme d’un tag-filtre activé. Ces champs sont respectivement inclus dans l'index _documents : senders, recipients, person-inlined. Lieux : Input avec autocomplétion pour sélectionner 1 ou + lieu(x), avec sélection possible de son(leurs) statut(s) : lieu d’expédition, lieu de réception ou sujet. La sélection active est affichée sous la forme d’un tag-filtre activé. Ces champs sont respectivement inclus dans l'index _documents : location-date-from, location-date-to, location-inlined. Collections : non inclus à l'index. Input avec autocomplétion pour sélectionner une(des) collection(s) / sous-collection(s). La sélection active est affichée sous la forme d’un tag-filtre activé.

⚠️ On ne prend PAS en charge l’opérateur 'OU' ; la combinatoire est difficile à appréhender avec autant de filtres. "Lister les lettres en lien avec Henri IV ET Catherine de Médicis" : la collection des lettres où il est question des 2 personnages (et non pas de l’un OU de l’autre).

Exemples de requêtes :

• Lister les lettres en lien avec Henri IV
• Lister les lettres en lien avec Henri IV ET Catherine de Médicis
• Lister les lettres datées (expédiées) entre 1562 et 1593, en lien avec Henri IV ET Catherine de Médicis ET Senlis ET Lille

2. Effectuer une RECHERCHE PLEIN TEXTE :

La recherche plein texte est accessible depuis une barre de recherche en tête de page (accessible depuis /home et /search).

Implémentée avec Elasticsearch "Highlighting" elle permet d'obtenir dans la réponse les concordances ("highlighted snippets") :

Objectif : lister tous les documents mentionnant une/des personne(s) ET un/des lieu(x) ET contenant une expression, pour une période définie.

Input pour saisir une chaîne de caractères, recherchée dans : Transcription, inclus à l'index _documents transcription. Titre, inclus à l'index _documents title. Analyse, inclus à l'index _documents argument.

Exemples de requêtes :

• Lister les lettres dont la transcription contient le terme réformés
• Lister les lettres dont la transcription contient le terme réformés, en lien avec Catherine de Médicis
• Lister les lettres dont la transcription contient le terme réformés, entre 1572 et 1573, en lien avec Catherine de Médicis ET Gaspard de Coligny ET Paris ET Blois

3. COMBINER Recherche Plein Texte et Filtres :

Recherche plein texte sur "eschevins" (169 résultats)	Plein texte ("eschevins") et Filtre personne = Catherine de Médicis (28 résultats)

4. Notes importantes concernant la recherche :

Mise à jour des index :

Pour la configuration actuelle : voir lettres-app/elasticsearch/ _settings.conf.json, documents.conf.json, persons.conf.json, placenames.conf.json
La mise à jour des index est gérée par abstract_facade.py ou via le cli.py.

Recherche Plein Texte Approximative (date d'implémentation à déterminer) :

• La recherche Plein Texte doit également permettre de faire varier l'exactitude du motif à rechercher.

Pagination : chaque recherche (et l'application de filtres) doit permettre d'obtenir deux types d'informations :

• d'une part, fournir aux utilisateurs le total des résultats et les résultats de recherche paginés comportant les métadonnées nécessaires à l'affichage (voir les métadonnées des différentes vues au point suivant et les highlights en cas de recherche plein texte (ex : "Bellièvre" ci-dessous) et voir également A.I.2.)
• d'autre part, produire la liste des Personnes, Lieux, Collections liées à la recherche en cours (éventuellement filtrée) ainsi que leurs comptages : les filtres de sélection de Personnes, Lieux, Collections ainsi que les suggestions (ex : listes et effectifs des personnes associées à un résultat de recherche) doivent être recalculés sur l'ensemble des résultats de chaque nouvelle recherche et l'application de filtres (il ne s'agit pas de filtres portant uniquement sur les résultats paginés en cours d'affichage)

Utilisation du cache utilisateur dans le navigateur :

Lorsque l'on navigue d'une liste de résultats de recherche vers un document, on doit pouvoir retourner à la recherche en cours en reculant dans l'historique du navigateur.

Affichage des résultats en 2 vues :

Les résultats de la recherche peuvent être visualisés en mode "Tableau" ou "Déplié", ce qui induit de prédisposer de l'ensemble des métadonnées nécessaires à ces deux affichages :

"Tableau" (Id, Date, Titre, Expéditeur, Destinataires)	"Déplié" (Id, Date, Titre, Expéditeur, Destinataires, Lieux d'Expédition et de Destination)

II. Précisions liées au fonctionnement de l'application :

1. Gestion des droits :

Le périmètre de la recherche et donc ses résultats varie selon le statut de l'utilisateur : les users connectés recherchent parmi TOUTES les collections et TOUS les documents, les visiteurs non connectés n'accèdent qu'aux documents PUBLIES et les collections qui leurs sont associées.

2. Quantification des Personnes, Lieux et Collections les plus présents dans un résultat de recherche (date d'implémentation à déterminer):

• En parallèle des résultats et de leur effectif, nous souhaitons produire des suggestions de recherche / rebonds. Par exemple présentation des 5 personnes et 5 lieux les plus associés aux documents dans l'ensemble des résultats d'une recherche :

B. Objet de l'issue : Optimisation du moteur de recherche

⚠️ La plupart des composants d'affichage des résultats sont implémentés, ils ne nécessiteront éventuellement que des évolutions marginales, concernant surtout la mise à disposition des données sous-jacentes.

I. Évaluation de l'existant :

1. Réaliser un audit succinct de l'existant afin de :

2. résoudre les points suivants (voir II. ci-dessous) et

3. implémenter les solutions (ou assistance à l'implémentation en fonction du temps utile disponible)

II. Points à traiter :

1. Amélioration du temps de réponse :

Notamment le pré-chargement des filtres (inputs à autocomplétion), qui nécessite d'obtenir les ensembles dédoublonnés des personnes, lieux, collections associées à la recherche en cours mais également leur décompte (ex: afficher les 5 personnes les plus fréquentes (et le comptage) pour une recherche donnée, voir A.II.2) par :

• soit une révision du modèle d'indexation ES : révisions des index et/ou des mappings (voir lettres-app/elasticsearch/ _settings.conf.json, documents.conf.json, persons.conf.json, placenames.conf.json et s'agissant de la réindexation manuelle : le cli.py)
• et/ou optimiser les performances de la recherche GroupBy en apportant des modifications aux fichiers search.py et route_registrar.py.
  Exemple de requête : [GET http://localhost:5004/lettres/api/1.0/search?query=(((collections.id:1) OR (collections.id:2) ...) AND (Bellievre)) AND (location-date-from.id:(15) AND senders.id:(1))&range[creation]=gte:1348,lt:1595&groupby[doc-type]=person&groupby[field]=senders.id&without-relationships]
  Cette requête illustre l'utilisation de GroupBy pour effectuer un regroupement par un identifiant 'expéditeur' dans les résultats d'une recherche plein texte filtrée.
• personnaliser les réponses d’ES en modifiant les fichiers search.py et route_registrar.py. L'objectif est de fournir uniquement les données nécessaires à chaque composant, en évitant les informations superflues.

2. Prévoir le dépassement de 10K documents dans les résultats de recherche :

La base de donnée est destinée à couvrir plus de 10 000 documents, il conviendra d'implémenter l'API scroll d'ES ou équivalent (rappel ES version "6.8.22") pour pouvoir gérer de tels volumes.

[vicpsl]

Bonjour Vincent,

voici l'issue sur l'amélioration de la recherche ES à passer en revue.

Merci