Explorez Wikipédia, des données scientifiques et des séries statistiques. Filtrez par source et consultez les identifiants, les valeurs et la provenance des échantillons réellement indexés.
Amorçage sur l’informatique, puis découverte d’articles modifiés en français jusqu’au plafond. Seules les introductions sont indexées, avec une limite de 12 000 caractères. Rafraîchissement toutes les 15 secondes.
Échantillons bornés, relus chaque jour ; aucune copie intégrale de ces bases. Les notices bibliographiques n’incluent pas les PDF. Les graphes sont des sélections de fiches et de relations, avec un instantané RDF distinct dans le laboratoire SPARQL.
| Source | Périmètre | Dernier lot complet | État | Rechercher |
|---|
Une erreur d’une source ne bloque pas les autres. Les compteurs décrivent le dernier lot entièrement synchronisé ; un lot interrompu peut être partiellement visible. La date de collecte diffère de la date de mise à jour de la source.
T = BM25(title), B = BM25(body). Les scores appartiennent à chaque formule : ne comparez pas leurs valeurs absolues. Le mode brut garde la même recherche lexicale sans score, dans un ordre interne non garanti. Le corpus vivant peut changer entre les appels. Le recouvrement et les différences de rang ne mesurent pas la pertinence.
Un même adaptateur de recherche dessert le navigateur et les agents. Suivez les parcours de lecture et d’indexation, puis découvrez les raisons et les limites de chaque choix.
Choisissez un parcours, puis un composant, ou avancez avec les boutons de navigation.
Objectif, compromis et évolution de chaque composant.
Vespa indexe les titres et les textes. Un mode brut fournit les correspondances sans classement. Six profils comparent les poids titre/texte, la saturation des scores, la couverture et la proximité ; la référence conserve le poids 2 pour le titre. Ce choix fournit une référence simple avant d’évaluer des méthodes vectorielles ou hybrides sur des requêtes annotées.
Une recherche accepte jusqu’à 256 caractères et 10 résultats. L’adaptateur limite la concurrence à huit recherches par processus. Le délai Vespa est de 2 secondes ; le client HTTP applique un délai de 5 secondes.
Chaque résultat contient un identifiant stable et une référence ; la réponse indique la version du corpus. Les dix fiches sont originales. Les introductions Wikipédia sont collectées séparément : identifiant de page stable, révision, lien vers la version source et attribution CC BY-SA 4.0 accompagnent les résultats.
Ouvrez une décision pour lire le raisonnement et les compromis.
Objectif. Utiliser un moteur qui prend en charge l’indexation, les requêtes YQL et le classement, avec une trajectoire possible vers la recherche vectorielle et hybride. Le service Python reste responsable du contrat d’accès ; il ne réimplémente pas un index inversé.
Compromis. Pour dix fiches, SQLite FTS ou un index embarqué suffiraient avec une empreinte plus faible. Vespa est choisi pour explorer l’exploitation d’un moteur de recherche et ses paramètres, en cohérence avec le poste visé. Ce POC ne prouve aucune supériorité sur Elasticsearch ou OpenSearch.
À l’échelle. Mesurer d’abord le débit d’indexation, la taille des index et les latences sous charge mixte. Déterminer ensuite le partitionnement et la réplication à partir du volume, des objectifs de disponibilité et du temps de reconstruction acceptable.
Objectif. Disposer d’une référence lexicale simple. BM25 utilise notamment la fréquence des termes, leur rareté dans le corpus et la longueur des documents. La référence est 2 × BM25(title) + BM25(body). Les variantes font varier le poids du titre, saturent les contributions, ou ajoutent des signaux de couverture et de proximité. Les deux derniers profils reclassent les 50 meilleurs candidats BM25 par nœud en seconde phase.
Traitement du français. La langue est fixée à fr à l’indexation et dans les requêtes pour appliquer le même traitement linguistique aux titres, aux textes et aux recherches courtes.
Compromis. Le facteur 2 est une heuristique du prototype, pas le résultat d’une optimisation. La recherche lexicale peut manquer un synonyme ou une reformulation. Le score sert à classer une liste ; il n’est ni une probabilité ni une mesure comparable entre toutes les requêtes.
À l’échelle. Constituer des requêtes annotées, mesurer nDCG@10 et le rappel, puis comparer lexical, vectoriel et hybride avec le même corpus. Publier aussi leur coût mémoire, CPU et latence : un meilleur classement peut coûter plus cher à servir.
Objectif. Centraliser la validation utile à la recherche, les limites, les appels à Vespa et la forme des résultats. FastAPI sert le navigateur ; le SDK MCP officiel expose les mêmes capacités aux agents. Modifier la recherche ne nécessite pas deux implémentations parallèles.
Compromis. Le client HTTP vers Vespa est synchrone et les recherches sont bornées par processus. Ce choix garde le code court pour le faible trafic attendu ; il impose de maîtriser le nombre de workers et de threads. Le SDK MCP transforme les erreurs d’outil dans son propre protocole, tandis que l’API utilise des statuts HTTP.
À l’échelle. Séparer le contrat métier des transports, conserver des tests de parité et dimensionner les connexions sortantes. Une évolution asynchrone peut aider pour de nombreuses attentes réseau ; elle ne supprime pas le besoin de contrôler le travail admis.
Objectif. Éviter qu’un afflux de requêtes transforme la saturation de Vespa en une file d’attente sans fin. Le sémaphore autorise huit recherches simultanées ; les suivantes échouent rapidement. Les requêtes sont limitées à 256 caractères et dix résultats.
Compromis. Cette limite est locale à un processus. Deux workers autoriseraient jusqu’à seize recherches, ce qui changerait le budget global. Le délai Vespa de 2 s et les délais du client HTTP réduisent l’attente, mais ne constituent pas une garantie absolue de latence de bout en bout. La lecture d’une fiche utilise le pool de connexions sans sémaphore distinct.
À l’échelle. Définir un objectif de latence et de disponibilité, puis introduire quotas par usage, files bornées, délais de bout en bout et reprises avec temporisation. Éviter les reprises immédiates et illimitées qui aggravent la surcharge.
Objectif. Le flux SSE Wikimedia signale les modifications. Le collecteur filtre les articles français, enregistre leur titre dans une file SQLite persistante, puis récupère l’introduction actuelle auprès de MediaWiki. Un seul worker écrit dans Vespa, au maximum une requête source toutes les deux secondes.
Reprise. L’identifiant de reprise du flux et l’ajout à la file sont validés dans la même transaction. Une tâche est retirée après l’écriture réussie dans Vespa. Une panne entre ces deux opérations rejoue la même écriture sous le même identifiant de page : la livraison est au moins une fois, avec des remplacements idempotents. Un événement arrivé pendant l’écriture reste en attente.
Mises à jour et suppressions. Le collecteur relit l’état actuel plutôt que d’appliquer aveuglément un ancien événement. Il refuse une révision inférieure à celle connue. Une page disparue ou sortie de l’espace des articles est retirée de l’index. Une vérification périodique corrige aussi les événements manqués : une page toutes les 30 secondes, soit environ 17 heures pour 2 000 pages sans retards.
Compromis. La file est plafonnée à 1 000 titres et le registre à 2 000 identifiants de pages, y compris les pages supprimées. Le filtrage du flux public est local. Le serveur conserve les événements pendant une durée limitée ; une reprise expirée repart du flux courant et s’appuie sur la réconciliation. Le corpus n’est pas un instantané immuable. Les délais affichés mesurent l’attente depuis la mise en file, pas un engagement de fraîcheur de la source.
Provenance. Les introductions sont limitées à 12 000 caractères, sans HTML. Chaque document contient sa révision, un lien vers la source et son historique. Les noms des contributeurs reçus dans le flux ne sont pas stockés. Licence CC BY-SA 4.0 ↗
Objectif. Rendre la démo facile à reproduire sur une VM de 4 Go. Compose décrit les services et leurs dépendances. Les conteneurs peuvent être recréés ; les volumes conservent l’index Vespa et les compteurs analytics.
Compromis. Un seul hôte reste un point de défaillance unique. Le profil plafonne Vespa à 2 560 Mio, l’API à 384 Mio, l’initialisation à 256 Mio, le proxy, les analytics et le collecteur à 128 Mio chacun. Le mode mémoire réduite et les tas JVM bornés conviennent à ce minuscule corpus ; ils ne représentent pas une recommandation de production.
À l’échelle. Définir les domaines de panne, les sauvegardes et leurs tests de restauration avant de multiplier les nœuds. Ne pas confondre persistance, sauvegarde et réplication. Kubernetes devient utile si les besoins d’exploitation justifient son coût ; il ne remplace pas ces décisions.
Objectif. Déployer le commit qui vient de passer les tests. Le workflow contrôle les contrats API/MCP, démarre Vespa avec le profil mémoire, puis utilise une clé SSH dédiée et une identité serveur connue pour transférer le code sur la VM.
Compromis. Les contrôles locaux ne suffisent pas : le workflow teste aussi l’URL depuis GitHub pour détecter les problèmes de proxy ou de réseau. La reconstruction et le remplacement des services peuvent provoquer une interruption. Une modification de schéma ou de données ne s’annule pas simplement en réinstallant l’ancien code.
À l’échelle. Épingler les images par digest, verrouiller les dépendances transitives, versionner les migrations et définir une stratégie de retour arrière. Tester la restauration et les déploiements progressifs avant de promettre une disponibilité élevée.
Objectif. Suivre l’usage du POC avec peu de ressources et sans prestataire externe. La base ne contient que la date UTC, la section, la campagne, le type d’événement et son compteur. Les incréments sont transactionnels ; le mode WAL facilite la coexistence de lectures et d’écritures.
Compromis. Les événements viennent du navigateur et peuvent être dupliqués ou artificiels. Un tag de campagne décrit le lien partagé, pas l’identité du visiteur. Les jours hors de la fenêtre de 30 jours sont purgés lors des accès. Le tableau de bord écoute sur un service séparé, publié uniquement sur la boucle locale de la VM, accessible par tunnel SSH.
À l’échelle. Définir les métriques nécessaires avant d’ajouter des données. Séparer télémétrie produit et mesures de fiabilité ; instrumenter les histogrammes de latence, la saturation et les erreurs sans enregistrer les requêtes ou les identités des visiteurs.
Objectif. Dix connecteurs produisent des fiches et observations bornées : entités Wikidata, protéines UniProt, matériaux Materials Project, notices OpenAlex et OpenAIRE, séries Eurostat, Banque mondiale, FMI et OCDE, catalogue data.gouv.fr. La recherche commune reste lexicale ; une observation statistique conserve ses dimensions, sa période, son unité et sa valeur dans un JSON consultable.
Reprise. Un lot normalisé est enregistré dans SQLite avant toute écriture. Les identifiants natifs déterminent des IDs stables propres à chaque source. Après interruption, le même lot est rejoué avant toute nouvelle collecte. Les anciennes fiches de l’échantillon sont retirées seulement après l’écriture complète du nouveau lot. Il n’y a pas de transaction atomique couvrant SQLite et Vespa : une génération partielle peut être visible pendant sa reprise.
Ressources et erreurs. Réponses limitées à 4 Mo, maximum de 50 documents par source et collectes séquentielles. Les collectes réussies sont espacées de 24 h ; les erreurs ont une temporisation exponentielle plafonnée à une heure. Materials Project reste signalé « clé requise » tant que la clé n’est pas configurée. Un échec ne supprime pas la dernière copie réussie et ne bloque pas les autres sources.
Limites. Les graphes complets ne sont pas hébergés, les fichiers des portails et les textes intégraux ne sont pas collectés, un petit graphe RDF versionné complète ces fiches dans le laboratoire SPARQL. Les champs textuels restent analysés en français : les titres et noms scientifiques en anglais peuvent nécessiter des requêtes dans leur langue d’origine. Les séries statistiques décrivent le millésime récupéré, qui peut comporter estimations et révisions.
Objectif. Le laboratoire de requêtes propose sept scénarios réels : recherche et agrégation sur Vespa, jointures et parcours sur un petit instantané RDF Wikidata. Les outils MCP query_index et query_graph utilisent les mêmes contrats que HTTP.
Admission. Le serveur reconstruit chaque requête depuis des paramètres validés. Le texte soumis doit correspondre exactement au modèle. Les écritures, la fédération externe et les parcours non bornés sont absents des modèles acceptés. Ce mécanisme ne valide pas toutes les requêtes YQL ou SPARQL possibles.
Exécution. Deux exécutions simultanées au maximum ; Vespa reçoit un délai de 2 secondes. Chaque requête SPARQL utilise un processus jetable arrêté après 3 secondes, sur un graphe de moins de 2 000 triplets. Les réponses affichent le texte, la durée et la provenance. Le SHA-256 et les révisions Wikidata identifient le graphe ; celui-ci est distinct du corpus vivant et renouvelé explicitement par un commit.
Limites. Les temps SPARQL incluent le démarrage du processus et le chargement du graphe. Les modèles fixes et le petit corpus rendent la démonstration reproductible ; ils ne prouvent pas le fonctionnement à grande échelle ni une isolation de requêtes arbitraires.
| Paramètre | Configuration | Pourquoi / limite |
|---|---|---|
| Champs recherchés | title et body : index | summary | Index inversé pour retrouver les termes ; summary pour restituer les textes. Pas d’attribut dupliquant tout le texte en mémoire. |
| Filtrage et métadonnées | corpus : attribute | summary. ID, source et provenance : summary. | L’attribut sert au filtre par source et au contrôle d’initialisation ; il consomme de la mémoire. L’ID est lu via Document API et n’a pas besoin d’un attribut supplémentaire. |
| Traitement linguistique | Français fixé avant le traitement des champs et à la requête. | Analyse cohérente pour les recherches courtes en français ; corpus multilingue non couvert. |
| Classement inspectable | k1 = 1,2, b = 0,75 ; six formules inspectables, dont deux avec une seconde phase limitée à 50 candidats. | Valeurs de référence rendues explicites. Les contributions BM25 et les signaux utilisés sont restitués via summary-features. Les signaux positionnels sont réservés au reclassement borné et aux résultats affichés. Aucun profil n’est présenté comme meilleur sans évaluation annotée. |
| Mémoire | Conteneur Vespa : 2 560 Mio ; JVM query : 256 Mio maximum. | Le tas Java n’est qu’une partie de l’empreinte : Proton, les structures natives, les index et caches utilisent aussi de la mémoire. Les limites cgroup ne constituent pas un réglage de pertinence. |
| Protection des écritures | Seuils de blocage Vespa conservés à leurs valeurs par défaut. | Observer le feed-block et l’usage mémoire/disque avant de modifier les seuils. Les augmenter pour masquer une saturation risque de supprimer la marge nécessaire au moteur. |
| Topologie | Un conteneur de requêtes et un nœud de contenu, colocalisés ; une seule copie. | La répartition des documents et les copies inter-nœuds nécessitent un cluster distinct pour être expérimentées. Pas de haute disponibilité sur cette VM. |
La comparaison des profils doit utiliser le même jeu de requêtes et un corpus stable. Les mesures de latence sur le corpus vivant restent exploratoires ; elles ne permettent pas de conclure sur la pertinence.
| Question | Mesure nécessaire | Décision éclairée |
|---|---|---|
| Le moteur est-il assez pertinent ? | Requêtes annotées, nDCG@10, rappel et analyse des erreurs. | Choix lexical/vectoriel/hybride et réglage du classement. |
| Quelle charge peut-il absorber ? | Débit, concurrence, p50/p95/p99 et erreurs, à chaud et à froid. | Budget de concurrence, nombre de nœuds et marge de capacité. |
| Combien de mémoire et de disque ? | Empreinte de l’index, taille des documents, croissance et coût des réindexations. | Répartition mémoire/disque, stockage et stratégie de reconstruction. |
| Comment survivre à une panne ? | Perte admissible de données, temps de reprise et restauration effectivement testée. | Réplication, sauvegardes, placement et procédures d’exploitation. |
Ces mesures décrivent le travail à mener. Le POC ne publie pas encore de benchmark de pertinence ou de charge.
| Domaine | Implémentation actuelle | Limite à connaître |
|---|---|---|
| Ingestion | File persistante, reprise SSE, remplacements idempotents, suppressions et réconciliation périodique des pages suivies. | 2 000 pages suivies ; introductions uniquement. Pas de garantie de fraîcheur ni de couverture exhaustive de Wikipédia. |
| Disponibilité | La sonde de disponibilité interroge Vespa ; la sonde de vie vérifie le processus API. | Un seul nœud Vespa : aucune garantie de haute disponibilité ni de bascule sur réplique. |
| Ressources | Le profil VM limite la mémoire des conteneurs et réduit les tas JVM pour ce petit corpus. | Configuration sous la recommandation mémoire habituelle de Vespa ; ce n’est pas un dimensionnement de production. |
| Observabilité | Compteurs de recherches, d’erreurs et de durée cumulée ; tableau privé des événements de navigation agrégés. | Pas d’histogramme de latence, de traces distribuées ni de comptage des personnes uniques. |
| Déploiement | GitHub Actions vérifie le commit, contrôle l’identité SSH du serveur et teste ensuite le service public. | Pas de retour arrière automatique ; les volumes de données sont conservés. |
| Accès aux données | Les visiteurs recherchent et lisent les documents via HTTP ou MCP. | L’indexation reste interne. YQL et SPARQL sont accessibles via des modèles bornés dans le laboratoire ; les requêtes libres restent refusées. |
Des contrats simples et des réponses vérifiables.
GET /api/search?q=index&limit=5 GET /api/documents/index
/tools/mcp search_documents(query, limit) get_document(document_id) query_index(scenario, query, source, limit) query_graph(scenario, entity, limit)
SDK Python officiel · Streamable HTTP · transport sans session persistante.
GET /healthz GET /readyz GET /metrics GET /api/ingestion GET /api/sources