[EPIC] Refonte du moteur de recherche

thbar commented 9 months ago

DRAFT - document en cours d'évolution. Very WIP

Besoins en cours sur la description de l'existant:

[ ] Double-passe auprès de l'équipe dév pour vérifier si il manque un élément d'indexation (c'est un peu brouillon en bas, je vais aller détailler ça dans Slack (= creuser en horizontal)
[ ] Mieux détailler le fonctionnement des parties un peu plus riches (= creuser en vertical)

Répartition des informations (Notion vs GitHub)

Je travaille avec @AurelienC là dessus et on répartit les informations à deux endroits, mais sans se marcher sur les pieds:

https://www.notion.so/2023-Evol-recherche-UX-6e6b578968ff448aaa256af4d273714d -> recueil du besoin, idées en mode brainstorming
ici: éléments techniques (description technique de la situation actuelle, liens avec les tickets existants qui sont nombreux, et ensuite suivi de la réalisation quand on en sera là)

Brief général

Le moteur de recherche actuel présente plusieurs inconvénients que j'ai proposé de traiter en faisant d'une pierre deux coups :

recherches trop limitées en terme de fonctionnalité (des choses aussi simples que "pas de recherche par format ou par schéma data gouv", des choses plus compliquées impliquant la donnée géographique réelle des arrêts #2293)
poids opérationnel de plus en plus important (https://github.com/etalab/transport-site/issues/3301) de la pagination, impliquant plusieurs tables et très lentes (ex: 2 secondes), qui va finir par nous mettre dedans opérationnellement (les requêtes étant compliquées à optimiser, et chaque optimisation étant "bloquée" sur une chose précise, on aurait besoin d'autres optimisations ad-hoc après pour d'autres cas etc)

Ce deuxième point est d'autant plus marqué que l'on ne permet la recherche que sur un nombre tout petit d'items (~500 datasets), mais avec un coût de calcul qui est très important par rapport à cette taille ! Et que par ailleurs, ces items changent très peu!

Approche pas du tout adaptée donc, que de recalculer ces éléments lourds à chaque requête de pagination. Et qui bloque aussi la capacité à apporter des recherches plus riches.

J'ai proposé de travailler dessus et on a validé ce point en objectif trimestriel, voilà donc la démarche que je propose.

L'idée générale est de travailler à dégager:

une doc sur le fonctionnement actuel (qu'on va coller ici plus bas)
dégager un "modèle conceptuel d'indexation" actuel (= lister la totalité des champs utilisés, et indiquer dans quelles tables ils sont etc, et comment on les récupère)
définir sur quoi on voudrait requête idéalement
améliorer le "modèle conceptuel d'indexation" graduellement
mettre en place son calcul (en version iso-fonctionnelle, ou version améliorée directement ou petit à petit, à définir progressivement)
convertir le système de requêtage pour aller directement pré-calculer les attributs d'indexation (sorte de payload d'indexation), et aller requêter par rapport à cette payload (sans requête sur N tables)

Cela pourra passer par différents prototypes plus ou moins basiques, pour valider le fonctionnement de façon moins coûteuse qu'une intégration réelle, et pour affiner notre réflexion.

Ainsi:

la pagination sera plus ou moins instantanée (en tout cas bien plus rapide qu'aujourd'hui)
le calcul de l'index pourra être mis sous tests solidement
des ajouts à la payload d'indexation seront aussi plus aisés
on pourra améliorer l'UX de recherche (utilité fonctionnelle)
on fera sauter un problème d'ops à venir

Il faudra évidemment veiller à ce que les payloads d'indexation soient bien maintenues à jour, et bien indexées elles-mêmes.

Voilà pour le brief :smile: la suite à venir !

État général

Aujourd'hui, seuls les datasets sont indexés et recherchables (c'est à dire que le listing obtenu liste des datasets, et non des ressources).

Même si dans les critères de recherche, sont toutefois impliqués des éléments des ressources du dataset.

On peut se poser durant cette refonte, d'ailleurs, la question d'indexer les ressources elle-mêmes. La solution proposée plus haut permettrait de faire cela assez facilement (en créant des payloads d'indexation au niveau de chaque ressource, puis en travaillant en recherche sur une jointure "payload indexation dataset" <-> "payload indexation ressources"), ce qui est un effet volontaire du design.

Champs pris en compte par la recherche actuellement

(WIP - à vérifier et compléter pour ne rien rater)

dataset.type

Extract:

SELECT
    TYPE,
    count(*) AS c
FROM
    dataset
GROUP BY
    TYPE
ORDER BY
    c DESC
LIMIT 5

type	c
public-transit	379
bike-scooter-sharing	48
low-emission-zones	15
bike-parking	12
bike-way	11

Où est-ce à l'écran (NOTE: je vais les regrouper sur un screenshot unique à la fin - c'est temporaire pour me faire gagner du temps pendant le relevé des éléments)

dataset.has_realtime

select has_realtime, count(*) from dataset group by has_realtime

has_realtime	count
f	304
t	191

"Region"

https://transport.data.gouv.fr/datasets/region/12?order_by=most_recent

(À mieux détailler TB)

Loi climat et résilience

https://transport.data.gouv.fr/datasets?loi-climat-resilience=true

select custom_tags from dataset where 'loi-climat-resilience' = any(custom_tags)

select custom_tags from dataset limit 10

custom_tags
{loi-climat-resilience}
{}
{loi-climat-resilience}
{}
{loi-climat-resilience}
{loi-climat-resilience}
{}
{loi-climat-resilience}

{}

Licences

select licence from dataset limit 10

licence
lov2
odc-odbl
lov2
lov2
lov2
lov2
odc-odbl
lov2
odc-odbl
odc-odbl

Recherche "full text"

L'utilisateur tape des mots, et différents points sont pris en compte:

analyse des mots par rapport à la "description des jeux de données"
recherche par entité géographique de rattachement
- région: on retombe sur https://transport.data.gouv.fr/datasets/region/12?order_by=most_recent
- commune: on tombe sur https://transport.data.gouv.fr/datasets/commune/80225
- aom (taper creuse confluence): on tombe sur https://transport.data.gouv.fr/datasets/aom/803

Mais aussi (en mode "verrue" collé dans le "lieu"):

mode de transport (mais qui est "collé" dans les lieux) https://transport.data.gouv.fr/datasets?modes%5B%5D=funicular apporté par resource_metadata.modes
données contenant de l'accessibilité (https://transport.data.gouv.fr/datasets?features%5B%5D=informations+sur+l%27accessibilité+à+vélo), qui est apporté par resource_metadata.features

TODO:

détailler le fonctionnement de "places" / trigger etc.
détailler le fonctionnement actuel du search vector

CleanShot 2023-12-08 at 15 03 13@2x

CleanShot 2023-12-08 at 15 06 18@2x

Possibilités de tri

Il a été rappelé l'importance de pouvoir trier, et ça peut être assez complexe selon sur quel terrain on va, donc je note aussi l'existant ici:

"Quirks" connus ou tickets historiques en lien

Questions et points relevés avec Aurélien

Pourquoi modes d'un côté et type de l'autre, et comment clarifier ça pour l'utilisateur
- https://transport.data.gouv.fr/datasets?type=air-transport
- https://transport.data.gouv.fr/datasets?modes%5B%5D=ferry
- réponse: le mode est extrait des méta-données du GTFS dès lors qu'il est présent (TODO: montrer un échantillon), tandis que le type est globalement défini à la main (uniquement ? à vérifier ? dans le back office)
- question importante par exemple pour le cas des lignes de covoiturage en développement ; est-ce que la donnée sera bien fournie correctement dedans ?
- actuellement, la totalité des ressources GTFS sont reliées à un dataset estampillé "type=public-transit"
- pour Aurélien, une ligne de covoiturage ne rentrera pas dans "public transit" et il faudra qu'elle soit trouvable / filtrable par le moteur de recherche
- les lignes de covoiturage risquent de ne pas être dans le tronc commun de la norme GTFS mais dans une extension "route type" de Google ?

:warning: aujourd'hui, l'essentiel des méta-informations extraites de la donnée ne le sont que pour GTFS et GTFS-RT.

Préoccupation importante (Aurélien autant que Thibaut) que le travail en cours permette de très bien gérer tous les formats du PAN de façon agnostique.

AurelienC commented 3 months ago

A penser : la recherche devrait-elle renvoyer des articles de doc.transport.data.gouv.fr ?

thbar commented 3 months ago

@AurelienC à terme on pourrait avoir ce type d'intégration effectivement (hors périmètre pour le moment), ça pourrait avoir du sens

etalab / transport-site