Cómo DeepSeek y Wordstat convirtieron la recopilación manual de palabras clave en un sistema SEO multiagente

Un autor en Habr demostró cómo la transferencia rutinaria de datos de Wordstat a Excel se convirtió en una herramienta SEO completa con múltiples agentes, votación de modelos y un árbitro separado. Como resultado, el sistema procesa alrededor de 3000 palabras clave en 20–30 minutos, dejando solo alrededor del 5% de consultas disputadas para revisión manual.

Cómo creció el pipeline

Inicialmente, la tarea era directa: dejar de copiar palabras clave manualmente. La primera versión del script simplemente extraía datos de Bukvarix y los guardaba en un archivo. Luego el autor se dio cuenta de que para campañas publicitarias esto no era suficiente: la frecuencia en tales fuentes podía quedar obsoleta en cuestión de meses, lo que significa que las decisiones presupuestarias se basaban en datos antiguos.

Así que el sistema agregó XMLRiver como una fuente de datos más fresca del ecosistema Yandex, junto con esto—frecuencia básica, exacta y refinada. Más tarde, el proyecto se apartó del simple parsing hacia procesamiento semántico completo. Para clustering, el autor conectó SentenceTransformers, pero rápidamente se topó con un problema típico de NLP: las consultas semánticamente similares no siempre deben estar en la misma página.

Para evitar mezclar, por ejemplo, consultas dependientes de la geolocalización como reparaciones en Moscú y Voronezh, encima de los embeddings llegó SERP Veto—una verificación de superposición de URL en los resultados de búsqueda. Antes de eso, la lista se limpiaba de basura con regex y se contraía mediante deduplicación fuzzy, lo que eliminó el 30–40% de duplicados antes de costosas solicitudes SERP.

Por qué un LLM no es suficiente

Una vez que la hoja de cálculo ya podía recopilar, calcular frecuencias y agrupar palabras clave, quedaba la parte más desagradable: filtrar la basura. Esto significa vacantes de empleo, agregadores, consultas con intención informacional y otros casos límite que son difíciles de eliminar con simples palabras negativas. El autor intentó asignar la tarea a un único modelo DeepSeek LLM con un prompt simple, pero rápidamente descubrió que sin contexto el modelo adivina el nicho demasiado libremente.

La palabra "reparación" para él puede significar apartamentos, teléfonos o un motor. Para reducir el caos, apareció un PlannerAgent antes de la clasificación. Recibe una descripción del nicho y genera directrices para el siguiente paso: quién es el cliente objetivo, qué ejemplos considerar relevantes, qué trampas cortar, cómo manejar la geografía.

En paralelo, el autor optimizó el costo: en lugar de devolver filas completas, el modelo comenzó a responder solo con IDs de palabras clave. Esto redujo el volumen de respuesta de aproximadamente 400 a 80 tokens por lote y dio un ahorro del 30–40% en ejecuciones grandes.

Por qué se necesitaba la votación

Incluso después de estas mejoras, el mismo conjunto de 671 palabras clave en tres ejecuciones mostró solo el 37,7% de decisiones completamente estables. La razón resultó no estar en la temperatura, sino en el proceso mismo: el PlannerAgent cada vez cambiaba ligeramente los ejemplos few-shot, y las consultas límite terminaban en categorías diferentes. Entonces el autor creó Ensemble Voting: cada lote de 20 palabras clave se ejecuta tres veces en paralelo, y el resultado se determina por voto mayoritario. Si las tres respuestas no concuerdan, la consulta se envía a la lista "Revisar", y más tarde la analiza un agente de arbitraje separado.

• la estabilidad de la clasificación aumentó del 37,7% a aproximadamente el 85%
• la revisión manual se redujo a aproximadamente el 5% de las consultas
• 3000 palabras clave se procesan en 20–30 minutos en lugar de 3–4 horas
• el costo de una ejecución con tres votos es de aproximadamente $0,30

"Arregla tres líneas en el prompt.

Tres líneas. Y yo pasé una semana construyendo la arquitectura antes de eso."

Esta frase captura bien la conclusión principal del autor. Después de todo el trabajo arquitectónico, resultó que una consulta comercial obvia consistentemente terminaba en la categoría disputada simplemente porque las reglas del prompt no incluían la frase "llave en mano". En otras palabras, el esquema multiagente complejo sí mejoró la calidad, pero no eliminó la necesidad básica de validar el prompt mismo en casos límite antes de adornarlo con ensembles y árbitros.

Qué significa esto

Este caso es útil no solo para especialistas en SEO. Muestra cómo la automatización aplicada impulsada por el dolor real del usuario puede crecer rápidamente en un sistema de agentes si topas con límites de calidad, costo e inestabilidad de salida. Y simultáneamente, nos recuerda una verdad más incómoda: a veces la ganancia principal no viene de un nuevo agente, sino de tres líneas bien escritas en el prompt.