Filtrer Wikipedia en direct avec un agent local en deux étapes

Face au flux continu des modifications de Wikipedia, une architecture locale propose de filtrer massivement en Python avant de mobiliser un modèle via Ollama. L'approche, pensée pour le « streaming » d'entrée et de sortie, évite l'épuisement des ressources et fonctionne sans cloud ni authentification.

Filtrer d'abord, raisonner ensuite avec seuils et quotas

Le dispositif repose sur un entonnoir en deux étapes. D'abord, des calculs simples en Python sont exécutés à chaque événement, dont le volume de bytes supprimés et le nombre d'éditions récentes par utilisateur. La majorité des modifications sont écartées à ce stade car jugées non pertinentes. Ensuite, le LLM local n'est sollicité que pour la fraction d'événements qui franchit des seuils. Ce principe emprunte aux systèmes de surveillance, où l'on privilégie des filtres peu coûteux en amont avant de réserver un raisonnement plus cher aux cas retenus. Pour suivre le rythme, EditVelocityTracker maintient par utilisateur une fenêtre glissante de timestamps, en purgeant les plus anciens et en évincant les entrées pour limiter la mémoire quand le nombre d'utilisateurs suivis dépasse un plafond. Stage1Filter ignore les bots, calcule le nombre d'éditions récentes et les bytes retirés, puis émet un signal uniquement si un seuil de bytes supprimés ou de vélocité d'édition est dépassé, en documentant la raison. La plupart des événements ne progressent pas au-delà de l'étape 1 ; seuls les survivants sont soumis au raisonneur local, où un schéma strict et le streaming de tokens entrent en jeu.

Un flux SSE public, sans authentification, traité en continu

Les éditions de Wikipedia sont diffusées au format SSE sur HTTP via un point public. L'ingestion ne demande ni clé ni poignée de main autre qu'une requête GET maintenue ouverte. Dans cette construction, la seule connexion sortante vise ce service public, qui ne requiert pas d'authentification. Le consommateur asynchrone ouvre un client HTTP, lit les lignes SSE de l'URL de flux configurée et applique un filtrage par ensembles de wikis suivis avant de convertir et d'émettre des événements internes. En cas d'erreur HTTP, une temporisation de 5 secondes est observée avant une nouvelle tentative, l'ensemble étant pensé pour se reconnecter en boucle afin d'assurer un fonctionnement réellement continu.

Détection d'anonymat et normalisation des événements d'édition

Wikipedia attribue les modifications anonymes à l'adresse IP de l'éditeur, utilisée comme nom d'utilisateur. La détection d'anonymat s'effectue donc en vérifiant si la chaîne ressemble à une IPv4 ou une IPv6 via des expressions régulières. Le parseur SSE extrait les charges utiles JSON après le préfixe « data: » et ignore les éléments non conformes, tandis qu'une seconde fonction écarte les événements qui ne sont pas de type « edit » avant de construire un objet interne avec les champs nécessaires, des valeurs par défaut en l'absence de données (comme « unknown ») et les méta-informations telles que le statut bot, l'horodatage et le commentaire. Ces fonctions, écrites sans dépendance réseau, facilitent les tests unitaires, ce qui a permis d'attraper un bug antérieur sur la détection d'anonymat. Les événements ainsi normalisés s'appuient sur un modèle Pydantic qui fournit aussi une méthode pour calculer les bytes effectivement retirés.

Prérequis et pile locale sans cloud ni clés

L'environnement s'appuie sur Python 3.11+, des dépendances comme fastapi, uvicorn, httpx, pydantic, ollama et sse-starlette, et un modèle Ollama téléchargé localement, par exemple via « ollama pull llama3.1:8b », dès lors qu'il prend en charge une sortie JSON structurée. Aucun compte cloud ni clé API n'est requis et aucun coût n'est annoncé au-delà de l'électricité de la machine. L'arborescence du projet isole chaque étape du pipeline en fichiers dédiés, une organisation pensée pour rendre chaque composant plus simple à comprendre et à tester de manière indépendante.

Deux acceptions du « streaming » et cadre d'agent ambiant

Ici, « streaming » recouvre à la fois l'ingestion d'événements en direct et la diffusion token par token de la sortie, deux problématiques que la construction aborde simultanément. L'approche s'inscrit dans la définition d'un agent ambiant, qui se déclenche à l'arrivée d'événements plutôt qu'à la réception d'un message humain, telle que décrite par LangChain et par le kit d'agents de Google du point de vue de l'infrastructure. Le cas d'usage est concret : surveiller en local le flux public des éditions de Wikipedia, sans clé API, pour raisonner sur des modifications susceptibles d'être du vandalisme, le tout fonctionnant sur la machine via Ollama. Cette organisation par filtres et seuils est motivée par le caractère soutenu du flux, qui peut compter plusieurs modifications par seconde, et par les risques d'épuisement des ressources et de dérive temporelle si chaque événement était envoyé au modèle.