Comment DeepSeek et Wordstat ont transformé la collecte manuelle de mots-clés en un système SEO multi-agents

Un auteur sur Habr a démontré comment le transfert routinier de données de Wordstat vers Excel s'est transformé en un outil SEO complet avec plusieurs agents, vote de modèles et un arbitre séparé. En conséquence, le système traite environ 3000 mots-clés en 20–30 minutes, ne laissant qu'environ 5% des requêtes contestées pour examen manuel.

Comment le pipeline a grandi

Initialement, la tâche était directe : arrêter de copier manuellement les mots-clés. La première version du script extrayait simplement les données de Bukvarix et les sauvegardait dans un fichier. Ensuite, l'auteur a réalisé que pour les campagnes publicitaires, ce n'était pas suffisant : la fréquence dans de telles sources pouvait devenir obsolète en mois, ce qui signifiait que les décisions budgétaires étaient basées sur des données anciennes.

Ainsi, le système a ajouté XMLRiver comme une source de données plus fraîche de l'écosystème Yandex, ainsi que—la fréquence basique, exacte et raffinée. Plus tard, le projet s'est éloigné du simple parsing vers un traitement sémantique complet. Pour le clustering, l'auteur a connecté SentenceTransformers, mais a rapidement heurté un problème typique de NLP : les requêtes sémantiquement similaires ne devraient pas toujours être sur la même page.

Pour éviter de mélanger, par exemple, des requêtes dépendantes de la géolocalisation comme les réparations à Moscou et Voronezh, au-dessus des embeddings est venu SERP Veto—une vérification de chevauchement d'URL dans les résultats de recherche. Avant cela, la liste était encore nettoyée des ordures avec regex et effondrée via déduplication floue, ce qui a supprimé 30–40% des doublons avant les coûteuses requêtes SERP.

Pourquoi un seul LLM ne suffit pas

Une fois que le tableur pouvait déjà collecter, fréquencer et regrouper les mots-clés, la partie la plus désagréable restait : filtrer les ordures. Cela signifie les offres d'emploi, les agrégateurs, les requêtes avec intention informationnelle et autres cas limites difficiles à supprimer avec de simples mots négatifs. L'auteur a essayé de confier la tâche à un seul modèle DeepSeek LLM avec un prompt simple, mais a rapidement découvert que sans contexte le modèle devinait la niche trop librement.

Le mot « réparation » pour lui peut signifier des appartements, des téléphones ou un moteur. Pour réduire le chaos, un PlannerAgent est apparu avant la classification. Il reçoit une description de la niche et génère des lignes directrices pour l'étape suivante : qui est le client cible, quels exemples considérer comme pertinents, quels pièges couper, comment gérer la géographie.

En parallèle, l'auteur a optimisé le coût : au lieu de retourner des lignes complètes, le modèle a commencé à répondre uniquement avec les IDs des mots-clés. Cela a réduit le volume de réponse d'environ 400 à 80 tokens par lot et a donné une économie de 30–40% sur les grandes exécutions.

Pourquoi le vote était nécessaire

Même après ces améliorations, le même ensemble de 671 mots-clés sur trois exécutions a montré seulement 37,7% de décisions complètement stables. La raison s'est avérée ne pas être dans la température, mais dans le processus lui-même : le PlannerAgent changeait à chaque fois légèrement les exemples few-shot, et les requêtes limites se retrouvaient dans des catégories différentes. L'auteur a alors créé Ensemble Voting : chaque lot de 20 mots-clés s'exécute trois fois en parallèle, et le résultat est déterminé par vote majoritaire. Si les trois réponses divergent, la requête est envoyée à la liste « À examiner », et elle est ensuite analysée par un agent d'arbitrage séparé.

• la stabilité de la classification est passée de 37,7% à environ 85%
• l'examen manuel a été réduit à environ 5% des requêtes
• 3000 mots-clés sont traités en 20–30 minutes au lieu de 3–4 heures
• le coût d'une exécution avec trois votes est d'environ $0,30

« Corrigez trois lignes dans le prompt.

Trois lignes. Et j'ai passé une semaine à construire l'architecture avant cela. »

Cette phrase capture bien la conclusion principale de l'auteur. Après tout le travail architectural, il s'est avéré qu'une requête commerciale évidente aboutissait systématiquement à la catégorie contestée simplement parce que les règles du prompt n'incluaient pas la phrase « clé en main ». En d'autres termes, le schéma multi-agent complexe a bien amélioré la qualité, mais n'a pas éliminé le besoin fondamental de valider le prompt lui-même sur les cas limites avant de le décorer avec des ensembles et des arbitres.

Ce que cela signifie

Ce cas est utile non seulement pour les spécialistes SEO. Il montre comment l'automatisation appliquée basée sur la vraie douleur de l'utilisateur peut rapidement grandir en un système d'agents si vous heurtez les limites de qualité, de coût et d'instabilité de sortie. Et simultanément, il nous rappelle une vérité plus inconfortable : parfois le gain principal ne vient pas d'un nouvel agent, mais de trois lignes bien écrites dans le prompt.