Dentro de la Detección de Bots en X: BotMaker, Scarecrow y BDSM

El 13 de agosto de 2026, X publicó una actualización en su repositorio de código abierto x-algorithm que gran parte de la cobertura redujo a un solo titular: los pesos exactos de ranking detrás del feed For You ahora son públicos. Esa es una historia real, pero no es la interesante. Enterrado en la misma actualización está el verdadero pipeline de puntuación de cuentas que X usa para decidir qué cuentas parecen inauténticas: modelos con nombres como agatha, user-cred-v2 y, efectivamente, bdsm. Ese es literalmente el nombre del directorio en el árbol de código fuente, y hace exactamente lo que hacen sus vecinos: leer señales sobre una cuenta y producir una puntuación que luego influye aguas abajo en si tus publicaciones llegan a mostrarse o no.

El error común en la mayoría de las explicaciones de sistemas como este es tratar la “detección de bots” como un solo modelo con un veredicto de sí o no. No lo es, aquí ni casi en ningún otro lugar a esta escala. Lo que X realmente construyó —y acaba de hacer completamente inspeccionable— es un pipeline por capas: modelos independientes que puntúan una cuenta desde distintos ángulos, un motor de reglas que convierte esas puntuaciones en etiquetas y un sistema de filtrado separado que decide, por publicación y por espectador, si mostrarla, ocultarla detrás de un clic de confirmación o descartarla por completo. Esta publicación recorre cómo encajan esas piezas.

Aprenderás:

• Qué cubre realmente el pipeline de puntuación de cuentas de X y por qué son varios modelos independientes en lugar de un solo clasificador
• Cómo agatha, bdsm y user-cred-v2 puntúan cada uno una cuenta a partir de una señal completamente distinta
• Cómo scarecrow y su motor de reglas botmaker convierten puntuaciones brutas de modelos en etiquetas aplicables
• Cómo el filtrado de visibilidad decide, por publicación y por espectador, permitir, intersticial o descartar contenido
• Por qué el ranking y la seguridad se mantienen deliberadamente como dos sistemas separados en esta arquitectura
• Qué sigue honestamente oculto del repositorio público y por qué ese compromiso es defendible

Tabla de contenido

1. Conceptos básicos
2. La arquitectura completa
3. Explicación de las capas centrales
4. Recorrido de extremo a extremo
5. Casos especiales
6. Desafíos de escalado y producción
7. Ejemplos de código
8. Errores comunes
9. Mejores prácticas de producción

Conceptos básicos

Lo que realmente cubre este pipeline

El repositorio x-algorithm de X se divide en dos rutas que funcionan casi totalmente de forma independiente. La Request Path maneja una única solicitud de feed en tiempo real: recupera candidatos, los clasifica, los filtra y devuelve una cronología. La Labeling Path se ejecuta continuamente en segundo plano, completamente separada de la solicitud de cualquier usuario: las cuentas y publicaciones se puntúan y etiquetan día y noche, independientemente de quién esté desplazándose. La detección de bots y de cuentas inauténticas vive casi por completo en la Labeling Path, y esa es la primera cosa que vale la pena entender: el sistema que decide que una cuenta parece un bot no se activa cuando tú cargas tu cronología. Ya se ejecutó, días o semanas antes, y simplemente vuelve a leer una respuesta almacenada cuando se ensambla tu feed.

Dentro de la Labeling Path, la puntuación de cuentas proviene específicamente de tres modelos que trabajan sobre señales totalmente distintas: agatha lee cómo reaccionan otras personas a las publicaciones de una cuenta, bdsm lee el comportamiento de la propia cuenta a lo largo del tiempo y user-cred-v2 lee la posición de la cuenta en el grafo de follows e interacciones. Ninguno de ellos por sí solo es “el detector de bots”. Juntos, alimentan un motor de reglas que decide qué etiqueta, si corresponde alguna, recibe una cuenta o una publicación.

Por qué acertar con esta arquitectura es un problema de alto valor

• Lo que está en juego va en ambos sentidos. Un falso positivo silencia una cuenta real; un falso negativo permite que una red coordinada manipule lo que ven cientos de millones de personas. Ninguno de los dos modos de fallo es aceptable a esta escala, y precisamente por eso ningún modelo individual carga con toda la decisión.
• Este es ahora el sistema de este tipo más inspeccionable de la industria. Meta, TikTok y YouTube han publicado artículos y descripciones de alto nivel de sus sistemas de ranking; ninguno ha puesto en GitHub una base de código funcional y compilable que cubra tanto ranking como seguridad. Eso cambia lo que significa “confía en nosotros” para una plataforma de este tamaño.
• Las decisiones de diseño aquí son una referencia genuinamente útil, independientemente de X en sí, para cualquiera que construya sistemas de trust-and-safety: cómo combinar múltiples señales débiles, dónde trazar la línea entre el procesamiento en tiempo real y en segundo plano, y cuánta lógica de detección hacer pública sin entregar a los atacantes un manual.

La arquitectura completa

LABELING PATH (continuous, background)
Content Understanding (agatha, bdsm, user-cred-v2, grox, ...)
      │
      ▼
Labeling Rules (scarecrow + botmaker, abuse-enforcement-service)
      │
      ▼
Storage
      │
      ▼
REQUEST PATH (per feed request)
Candidate Sources → Scoring/Ranking → Visibility Filtering (reads Storage) → Post-Selection Filters
      │
      ▼
Ranked For You Timeline

El principio rector, expresado explícitamente en las propias notas de diseño de X: ranking y visibilidad son sistemas separados, que leen entradas separadas y toman decisiones separadas. El ranking decide el orden en que aparecen las publicaciones; el filtrado de visibilidad decide si una publicación puede aparecer en absoluto. Confundir ambos —permitir que una puntuación de relevancia haga también de puntuación de seguridad— es exactamente el modo de fallo que esta arquitectura está diseñada para evitar.

Explicación de las capas centrales

1. agatha — Puntuar una cuenta según cómo reaccionan los demás

Qué es: Un proceso batch offline que etiqueta una cuenta basándose en cómo otras personas responden a sus publicaciones —bloqueos, reportes y reportes de spam, medidos en relación con los favoritos— además de etiquetas derivadas para riesgo de suspensión por spam y contenido para adultos.

Por qué importa: Esta es una señal basada en la reacción: observa cómo responden las personas reales que se encuentran con el contenido de una cuenta, no lo que hace la cuenta. Una publicación que de manera consistente genera bloqueos y reportes en proporción a los favoritos es una señal fuerte, procedente de humanos, independiente de cualquier cosa que el modelo pueda inferir solo a partir del contenido.

Consejo de producción: Las señales basadas en reacción necesitan exposición real y respuestas humanas reales antes de que emerja un patrón, lo que significa que agatha por sí solo no puede atrapar una cuenta problemática en su primera publicación.

2. bdsm — Puntuar una cuenta por su propio comportamiento a lo largo del tiempo

Qué es: Un modelo que lee la secuencia de acciones que una cuenta realiza a lo largo del tiempo —no una sola acción de forma aislada— para identificar señales de comportamiento inauténtico o abusivo.

Por qué importa: Esto captura lo que las señales basadas en reacción y en contenido estructuralmente no pueden. Una sola publicación, tomada de forma aislada, puede parecer completamente normal. Una secuencia de acciones —cadencia de publicación, patrones de tiempo, el ritmo de follows e interacciones— puede no parecerse en nada a cómo una persona usa la plataforma, incluso cuando cada acción individual supera una verificación de contenido. Esa es exactamente la razón por la que este es su propio sistema separado en lugar de estar integrado en un clasificador por publicación: los modelos por publicación son ciegos al patrón, y el patrón suele ser la señal más fuerte que deja una cuenta automatizada.

Consejo de producción: Como esto trata del ritmo y del patrón, no del contenido, puede marcar una cuenta antes de que publique algo que individualmente infrinja las reglas; eso es valioso, pero significa que el umbral debe tratarse con cuidado, porque los usuarios avanzados legítimos también pueden tener un uso inusualmente frecuente y con patrones marcados.

3. user-cred-v2 — Puntuar una cuenta por su posición en el grafo

Qué es: Ejecuta PageRank sobre el grafo de follows y las aristas de interacción, convirtiendo la masa resultante en una puntuación de credibilidad por cuenta.

Por qué importa: Esta es una señal estructural, independiente de lo que publica una cuenta o de cómo se comporta momento a momento. Una cuenta realmente integrada en relaciones reales y con interacción mutua acumula credibilidad basada en el grafo que es costosa de falsificar: automatizar publicaciones es fácil, pero fabricar una posición convincente dentro de un grafo social real es mucho más difícil de falsificar a escala.

Consejo de producción: La confianza basada en grafo es excelente para detectar redes que principalmente interactúan entre sí y se mantienen desconectadas de clústeres genuinos, pero se actualiza lentamente para una cuenta legítima completamente nueva. Precisamente por eso es una señal entre tres, no toda la historia.

4. scarecrow y botmaker — Convertir puntuaciones en etiquetas en tiempo real

Qué es: scarecrow reacciona a los eventos a medida que ocurren, usando botmaker como su motor de reglas integrado: un lenguaje, compilador y runtime creados específicamente para reglas con la forma: ante este evento, si se cumplen estas condiciones, aplica esta etiqueta. Las propias reglas viven en un directorio separado botmaker-rules que scarecrow carga.

Por qué importa: Esta es la capa que conecta la salida del modelo con la consecuencia. agatha, bdsm y user-cred-v2 producen cada uno puntuaciones; scarecrow observa eventos en vivo y decide, usando reglas escritas contra esas puntuaciones, si realmente debe aplicarse una etiqueta en ese momento.

Consejo de producción: Un lenguaje de reglas dedicado, en lugar de condicionales codificados de forma rígida, significa que los cambios de reglas no requieren un redeploy completo, una ventaja real cuando las reglas necesitan adaptarse rápidamente a nuevos patrones de evasión.

5. abuse-enforcement-service — Actuar sobre puntuaciones directamente

Qué es: Un sistema separado que lee puntuaciones de modelos sobre una cuenta —no eventos en vivo— y etiqueta la cuenta o sus publicaciones, emite un challenge o la suspende.

Por qué importa: Esto se ejecuta en paralelo a scarecrow, sobre las mismas salidas de modelos, pero mediante un mecanismo diferente: impulsado por puntuaciones en lugar de por eventos. Dos rutas independientes que actúan sobre las mismas señales son redundancia por diseño: una brecha en la cobertura de un sistema no se convierte automáticamente en una brecha en la aplicación de medidas.

6. Filtrado de visibilidad — La puerta real

Qué es: Para cada combinación de publicación y espectador, visibility-filtering devuelve una de tres respuestas: ALLOW, INTERSTITIAL (un clic de confirmación, usado para medios para adultos o gráficos) o DROP. Lee las etiquetas producidas por todo lo anterior, además de los bloqueos, silenciamientos y configuraciones del propio espectador.

Por qué importa: Este es el único sistema que decide si una publicación existe en un feed en absoluto. Aquí se ejecutan dos conjuntos de reglas: reglas generales para todos y un segundo conjunto que solo se aplica cuando una publicación se recomienda a alguien que no sigue al autor; esas reglas de solo fuera de red solo pueden descartar, ajustadas para alta exhaustividad precisamente porque la misma publicación sigue siendo visible para un seguidor real.

Consejo de producción: La evaluación se detiene en la primera regla que devuelve drop; conviene ordenar primero las condiciones de mayor confianza, tanto por corrección como para evitar malgastar cómputo en reglas a las que nunca se llega.

7. Bajo el capó — Cerrar el ciclo con transparencia

Qué es: Una herramienta de reporte por cuenta, emparejada con esta publicación, que agrega a lo largo del tiempo las etiquetas que afectan la visibilidad aplicadas a la propia cuenta y publicaciones de una persona.

Por qué importa: Publicar código responde a “¿cómo funciona este sistema en general?”, no a “¿le hizo algo a mi cuenta?”. Under the Hood cierra esa brecha: una persona puede ver qué etiquetas recayeron sobre su cuenta y, dado que el código de etiquetado es público, rastrear una etiqueta hasta aproximadamente qué sistema la produjo.

Recorrido de extremo a extremo

Sigue una sola cuenta a través del pipeline completo a lo largo del tiempo:

1. Se crea una cuenta y empieza a publicar e interactuar con normalidad, sin llamar especialmente la atención.
2. Content Understanding se ejecuta continuamente en segundo plano, fuera de la request path. bdsm empieza a construir una lectura de la secuencia de acciones de la cuenta, user-cred-v2 recalcula su puntuación basada en grafo a medida que se acumulan aristas, y los trabajos batch de agatha rastrean cómo responde la gente a sus publicaciones.
3. La cadencia de publicación empieza a parecer automatizada: rápida, repetitiva, con patrones de una forma que el uso de una persona normalmente no tiene. La lectura secuencial de bdsm cruza al territorio de comportamiento inauténtico.
4. scarecrow, observando eventos en vivo, hace match con una regla de botmaker que hace referencia a esa puntuación en aumento y aplica una etiqueta.
5. En paralelo, abuse-enforcement-service, leyendo la misma puntuación del modelo en lugar del evento desencadenante, cruza de forma independiente su propio umbral y emite un challenge o una suspensión.
6. Las etiquetas resultantes se escriben en storage.
7. La próxima vez que se ensambla el feed de cualquier espectador, visibility-filtering lee esas etiquetas y evalúa sus reglas en orden: el primer drop termina la evaluación, y la publicación nunca llega a los candidatos de ese espectador.
8. El ranking ya ocurrió independientemente de esta decisión. La publicación puede haber obtenido una buena puntuación de relevancia; el filtrado de visibilidad la veta de todos modos, porque los dos sistemas responden preguntas distintas a partir de entradas distintas.
9. Si la cuenta cree que esto fue un error, Under the Hood muestra exactamente qué etiquetas están aplicadas y, como el código de etiquetado es público, cualquiera puede rastrear una etiqueta hasta aproximadamente qué sistema la produjo.

Casos especiales

Reglas de descarte solo fuera de red. Algunas reglas se aplican solo a publicaciones recomendadas a un espectador que no sigue al autor: una red deliberadamente ajustada para alta exhaustividad lanzada sobre la superficie de descubrimiento, donde un falso positivo le cuesta a un extraño una publicación perdida en lugar de silenciar una cuenta para su audiencia real. La publicación idéntica llega intacta a los seguidores.

Reglas intencionalmente omitidas del repositorio público. X ha sido directa al respecto: algunas reglas de botmaker, y los prompts específicos de LLM usados por grox, no se publican para reducir el riesgo de que el código se use como guía para eludir el sistema. La transparencia total y la aplicación eficaz tiran en direcciones opuestas en los márgenes, y este es el punto donde X trazó la línea.

Intersticial frente a descarte desde el mismo pipeline. La misma maquinaria de etiquetado alimenta ambos resultados; la diferencia está en qué regla se activa y a qué categoría está vinculada. El contenido para adultos o gráfico tiende hacia interstitial; las etiquetas de comportamiento inauténtico tienden hacia drop.

Desafíos de escalado y producción

Mantener el análisis costoso fuera de la request path. El modelado secuencial, el PageRank sobre grafos y el análisis batch de reacciones son operaciones genuinamente costosas; ejecutar las tres sobre cada cuenta para cada solicitud de feed sería inviable a esta escala. Hacerlo continuamente en segundo plano y leer un resultado almacenado en caché en el momento de la solicitud es lo que hace viables las cuentas económicas; los informes sugieren que solo el conjunto de candidatos se reduce desde varios cientos de millones de publicaciones diarias hasta aproximadamente unos pocos miles por usuario antes incluso de que empiece el ranking.

El aislamiento de candidatos mantiene las puntuaciones cacheables. Una decisión deliberada de la capa de ranking garantiza que la puntuación de un candidato no dependa de qué otros candidatos están en el mismo lote; el mismo principio se aplica a las etiquetas de cuenta, que deben significar lo mismo independientemente de qué solicitud las vuelva a leer.

Dos rutas de aplicación independientes sobre las mismas señales. Ejecutar scarecrow (impulsado por eventos) y abuse-enforcement-service (impulsado por puntuaciones) en paralelo, a partir de las mismas salidas de modelos, cuesta complejidad real de ingeniería; pero significa que una brecha en la temporización de una ruta no se convierte silenciosamente en una brecha en la aplicación general de medidas.

Equilibrar la exhaustividad de forma diferente según la superficie. Reglas más estrictas y de mayor exhaustividad se aplican solo a recomendaciones fuera de red, mientras que la entrega dentro de la red a seguidores queda intacta, concentrando el filtrado más agresivo en la superficie donde una plataforma introduce activamente el contenido de un extraño, en lugar de aplicarlo uniformemente en todas partes.

Ejemplos de código

Lo siguiente son reconstrucciones ilustrativas de los conceptos descritos arriba, no código fuente literal del repositorio; parte de la lógica real de reglas está deliberadamente sin publicar, como se señaló anteriormente.

Una ilustración simplificada de lo que un puntuador de cuentas basado en secuencias evalúa conceptualmente:

def score_action_sequence(actions: list[dict], window_hours: int = 24) -> float:
    recent = [a for a in actions if a["hours_ago"] <= window_hours]
    if len(recent) < 5:
        return 0.0
    intervals = [b["ts"] - a["ts"] for a, b in zip(recent, recent[1:])]
    regularity = 1.0 - (stdev(intervals) / (mean(intervals) + 1e-6))
    return min(regularity * len(recent) / 100, 1.0)

Una regla conceptual de estilo botmaker, expresada como pseudocódigo en lugar del lenguaje de reglas real:

ON post_published
IF account.bdsm_score > 0.85 AND account.user_cred_score < 0.2
THEN apply_label(account, "likely_inauthentic")

Una ilustración simplificada del orden de evaluación donde gana el primer drop en el filtrado de visibilidad:

def evaluate_visibility(post, viewer, rules: list[callable]) -> str:
    for rule in rules:
        result = rule(post, viewer)
        if result == "DROP":
            return "DROP"
    return "ALLOW"

Errores comunes

Error: tratar la detección de bots como un solo modelo con una sola puntuación. Un único clasificador que capture a la vez patrones de reacción, secuencias de comportamiento y posición en el grafo difumina señales que son genuinamente independientes. Solución: puntúa cada dimensión por separado y combínalas aguas abajo en la capa de reglas, no aguas arriba en el modelo.

Error: dejar que una puntuación de relevancia haga doble función como puntuación de seguridad. Es tentador condensar “¿es este buen contenido?” y “¿es este un mal actor?” en un solo número. Solución: mantén ranking y visibilidad como sistemas genuinamente separados que leen entradas separadas.

Error: ejecutar análisis costoso a nivel de cuenta en la request path. Esta es la forma más rápida de hacer que un sistema de detección sea demasiado lento para desplegarse a escala. Solución: realiza el análisis pesado continuamente en segundo plano y mantén barata la lectura en tiempo de solicitud.

Error: publicar cada regla para maximizar la transparencia. Suena confiable, pero también entrega a cualquiera con motivación un mapa preciso de qué debe evitar activar. Solución: sé explícito sobre qué se omite y por qué, en lugar de insinuar una completitud que no tienes.

Error: tratar cualquier acción individual marcada como evidencia suficiente. Una publicación inusual, por sí sola, es una evidencia débil de cualquier cosa. Solución: construye para el patrón a lo largo del tiempo; esa es toda la razón de que exista un modelo basado en secuencias como sistema propio.

Mejores prácticas de producción

• Separa tus señales antes de combinarlas. Las señales basadas en reacción, comportamiento y grafo detectan modos de fallo distintos; colapsarlas demasiado pronto pierde información que una capa de reglas aguas abajo podría usar.
• Mantén seguridad y ranking como sistemas distintos. Responden preguntas distintas y se les debe permitir discrepar: una publicación muy relevante puede seguir siendo una que decidas no mostrar.
• Haz la puntuación costosa de forma continua, no en la request path. El cómputo en segundo plano más una lectura barata en caché es lo que mantiene viable a escala un sistema de detección por capas.
• Construye rutas de aplicación redundantes cuando lo que está en juego es alto. Sistemas independientes que actúan sobre las mismas señales, mediante mecanismos diferentes, capturan los puntos ciegos unos de otros.
• Sé honesto sobre lo que ocultas y por qué. Un esfuerzo creíble de transparencia nombra sus límites explícitamente en lugar de insinuar una completitud que no tiene.

Para cerrar

El enfoque del titular —“X publicó sus pesos de ranking”— se queda corto frente a lo que realmente se entregó aquí. La parte genuinamente notable es un pipeline completo e inspeccionable de puntuación de cuentas y aplicación de medidas: modelos independientes que leen reacciones, secuencias de comportamiento y posición en el grafo, un motor de reglas creado específicamente para convertir esas puntuaciones en etiquetas y una capa de visibilidad que mantiene la decisión de seguridad totalmente separada de la decisión de relevancia. Independientemente de lo que pienses de la plataforma para la que fue construido, la arquitectura en sí es una referencia genuinamente útil para cualquiera que esté construyendo sus propios sistemas de trust-and-safety.

Si has revisado tú mismo el repositorio real, ¿qué parte del pipeline te sorprendió más: los modelos a nivel de cuenta o cuánto de la lógica de reglas se deja deliberadamente fuera?