Optimización de intervenciones
automatizadas contra discursos
de odio en redes sociales

Mg. Ing. Joaquín González

Carrera de Especialización en Inteligencia Artificial · CEIA FIUBA

Director: Dr. Juan Manuel Ortiz de Zarate (FCEyN-UBA)

Jurado:
Esp. Lic. Noelia Melina Qualindi (FIUBA) — [email protected]
Esp. Ing. Diego Martín Braga (FIUBA) — [email protected]
Dr. Ing. Facundo Lucianna (FACET-UNT / FIUBA) — [email protected]

Ciudad Autónoma de Buenos Aires, abril de 2026

El problema

millones de publicaciones diarias en X.com

insuficiente moderación humana frente al volumen masivo

El discurso tóxico y polarizante se propaga
sin contranarración efectiva

X.com — intervención Normsy

Intervención generada automáticamente por Normsy en X.com

Normsy

Plataforma de contranarrativas automatizadas en X.com

Iniciativa no partidaria, sin fines de lucro
Desarrollada por Data Voices para Civic Health Project (EE.UU.)
En producción desde enero 2023
Dos modos: human pilot + LLM copilot y full automatizado

Detecta contenido tóxico · genera contranarrativa ·
publica intervención · recolecta métricas de engagement

Este trabajo abarca tres áreas

① Plataforma de analítica de datos

② Framework de evaluación de clasificadores

③ Fine-tuning del clasificador binario

111.000+ intervenciones publicadas en producción

Ene 2023

Normsy en
producción

Ene 2024

Cuentas humanas
operativas

2024–2025

Pipelines de datos
y framework

Q3 2025

Cuentas
automatizadas

2025–2026

Fine-tuning
y evaluación

Abr 2026

Defensa

Normsy en acción

▶

video/normsy_demo.mp4

[ placeholder — reemplazar cuando el video esté grabado ]

Recorrido: tweet tóxico detectado → clasificado → intervención publicada →
evento Kafka → pipeline ETL → métricas en Grafana → framework evaluando → fine-tuning en Vertex AI

Flujo de intervención

Etapas principales:

Obtención de posts monitoreados
Clasificación de toxicidad
OpenAI · Perspective · score máximo
Selección de estrategia de respuesta
Generación de contranarrativa
Revisión humana (si no es cuenta automatizada)
Publicación e intervención en X.com

Dos modos: human pilot con copiloto LLM
y full automatizado

normsy — flujo de intervención

Flujo de procesamiento de intervenciones

Áreas de trabajo del proyecto

normsy — arquitectura de infraestructura

① Solución de datos

MongoDB → PostgreSQL
Airflow ETL · Kafka CDC · Grafana dashboards

② Framework de evaluación

13 modelos · 5 proveedores
Pareto costo–F1 · escala de clasificación

③ Fine-tuning del clasificador

SFT sobre familia Gemini · Vertex AI
4 versiones · +64 % precisión

Solución de datos — el problema

Estado inicial

MongoDB Atlas como única base de datos
→ flexible para escritura, limitada para analítica
→ 800.000+ registros sin joins ni window functions

Consecuencia operacional

Sin historial analítico explotable
Sin dashboards de monitoreo
Sin capacidad de análisis exploratorio sistemático

Decisión de diseño

MongoDB → PostgreSQL

Esquema relacional en Hetzner
Patrón CQRS — lectura y escritura separadas
Grafana + Jupyter sobre PostgreSQL
Sin impacto sobre la base transaccional

Dos estrategias de procesamiento

Batch — Apache Airflow

Sincronización completa programada
17 colecciones MongoDB
Resiliente: recovery automático ante fallos

Real-time — Kafka CDC

Change Data Capture sobre oplog MongoDB
Debezium + Kafka + consumer Python
Evento procesado en < 1 segundo

airflow — arquitectura

Arquitectura Apache Airflow — Scheduler, Workers, Webserver y DAG Directory

Change Data Capture — stack tecnológico

Kafka

Bus de eventos distribuido
Desacopla productores y consumidores

Debezium

Conector CDC open-source
Captura cambios desde el oplog de MongoDB

Kafka Connect

Framework de integración
Orquesta source y sink connectors

kafka — stack tecnológico

Kafka + Debezium + Kafka Connect — captura de cambios en tiempo real desde MongoDB

Change Data Capture — pipeline en Normsy

① Captura
Debezium lee el oplog de MongoDB Atlas en tiempo real

② Transporte
Kafka recibe y distribuye los eventos de cambio

③ Consumo
Consumer Python persiste en PostgreSQL analítico

Latencia end-to-end: < 1 segundo
Sin impacto sobre la base transaccional

CDC — pipeline Normsy

MongoDB oplog → Debezium → Kafka → Consumer → PostgreSQL

Dashboard Platform Insights

grafana — Platform Insights

KPIs en tiempo real: intervenciones totales · impresiones · Normsy Impact Ratio · evolución temporal

Análisis exploratorio — cuentas automatizadas

111.000+ intervenciones totales en la plataforma

78 % del volumen total: cuentas automatizadas

Mediana impresiones/intervención:
Humana: 8 · Automatizada: 5
Calidad individual comparable — el escalado no degrada el alcance por publicación

EDA — volumen trimestral

Cuentas automatizadas desplegadas en Q3 2025 superaron
el volumen acumulado por cuentas humanas desde 2024

EDA — distribución de impresiones

Histograma de impresiones por tipo de cuenta

Distribución de impresiones comparable entre cuentas humanas y automatizadas
→ el escalado no degrada la calidad individual

EDA — impacto de respuestas

Distribución de respuestas recibidas por intervención
→ las intervenciones generan interacción real

Clasificador de toxicidad — el problema

Falsos positivos

Post no tóxico clasificado como tóxico
→ intervención innecesaria publicada en X.com
→ fricción pública, erosión de credibilidad

Impacto operacional

Recursos de inferencia desperdiciados
Generación de respuestas contraproducentes
Riesgo reputacional para la plataforma

Precisión — baseline producción (escala 0–10)

0,396

≈ 1 de cada 2,5 intervenciones
se activa sobre contenido no tóxico

Framework de evaluación de clasificadores

13 modelos de 5 proveedores
Escalas: 0–10, 0–3 y binaria
Métricas: F1, precisión, recall, costo USD, latencia
Dataset golden: 400 posts (100 por clase)
Persistencia en PostgreSQL
Reproducible: YAML versionado en Git

OpenAI Google Anthropic xAI Alibaba Cloud

13 modelos evaluados

3 escalas de
clasificación

framework — arquitectura

CLI como punto de entrada único — coordina clasificación, persistencia y métricas

Framework — configuración de experimentos

Un YAML define un experimento

Dataset, modelos, prompts y escala
en un único archivo versionado en Git

Ejecución

El CLI recorre cada combinación
modelo × prompt automáticamente

Reproducibilidad

Mismo YAML → mismos resultados
Persistidos en PostgreSQL con timestamp

params_03.yml — 13 modelos × 3 prompts = 39 evaluaciones

test:
  name: "Multi-Provider Toxicity Classification"

  dataset:
    name: "ground_truth"

  models:
    - name: "gemini-2.5-flash"        # Google
    - name: "gpt-4.1-2025-04-14"      # OpenAI
    - name: "grok-4-fast-non-reasoning" # xAI
    - name: "claude-haiku-4-5"        # Anthropic
    - name: "qwen-flash"              # Alibaba
      ... (13 modelos total)

  prompts:
    - name: "toxicity_3_prod.jinja2"
    - name: "toxicity_3_alternative.jinja2"
    - name: "basic_tox_notox_0_3.jinja2"

  settings:
    retry_attempts: 3
    prompt_scale: [0, 3]

① CLI

Lee YAML

② Dataset

Carga golden

③ Clasificación

modelo × prompt

④ Métricas

F1, precisión, recall

⑤ Persistencia

PostgreSQL

Evolución de la escala de clasificación

Escala 0–10 (producción inicial)

Alta ambigüedad entre niveles intermedios
Ruido subjetivo en la anotación manual
Alta dispersión inter-clase para los modelos

Escala 0–3 (propuesta)

Menor ambigüedad de anotación
Más ejemplos por clase
Misma resolución analítica útil

+16,6 % mejora en F1 en todos los modelos evaluados

evaluate.py — F1 por escala

Colapso 0–10 → 0–3: mejora consistente en F1 binario

Selección de modelo — frontera de Pareto

Modelos sobre la frontera:

grok-4-fast-non-reasoning
gemini-2.0-flash
gemini-2.5-flash-lite
qwen-flash

Ninguna combinación con escala 0–10 alcanza la frontera
→ confirma superioridad de escala 0–3

Eje X: costo total (USD)
Eje Y: F1 binario
Color: tiempo de procesamiento

evaluate.py — Pareto costo vs F1

Frontera de Pareto — costo vs F1 binario

El problema: precisión baja en modelos base

Baseline de producción (0–10)

0,396 precisión binaria

Costo asimétrico:
intervenir sobre contenido no tóxico
es más costoso que omitir uno tóxico

Alta tasa de falsos positivos
en todos los modelos evaluados
→ motiva el fine-tuning orientado a precisión

El framework permitió detectar esta debilidad
y evaluar sistemáticamente alternativas
→ sin el framework, la baja precisión no era visible

evaluate.py — binary_0_3_precision · baseline

Precisión binaria — modelos baseline escala 0–3

¿Puede el fine-tuning
mejorar la precisión?

El framework detectó que todos los modelos base tienen baja precisión.
Hipótesis: ajustar un modelo con datos del dominio puede reducir
los falsos positivos y mejorar el rendimiento general.

Fine-tuning — Vertex AI

Dataset

1.514 posts curados por Civic Health Project
1.289 entrenamiento · 225 validación
400 evaluación (golden — sin exposición al SFT)

Versión	Modelo base	Escala
v1	gemini-2.5-flash	0–3
v2	gemini-2.5-flash-lite	0–3
v3	gemini-2.0-flash-001	0–3
v4	gemini-2.5-flash	Binaria

Técnica: LoRA (Low-Rank Adaptation)
Cada versión: endpoint dedicado en Vertex AI

Vertex AI — SFT v2 · gemini-2.5-flash-lite

Curvas de entrenamiento v2 — accuracy y loss (Vertex AI)

v4: 1.300 ejemplos insuficientes para superar el conocimiento previo del modelo base
→ escalar el dataset es el paso natural

La solución: fine-tuning mejora la precisión

SFT v3 — gemini-2.0-flash

0,649 +64,1 % vs baseline

Los modelos SFT superan
consistentemente al baseline
de producción en precisión

Menos intervenciones incorrectas
mayor confianza operacional

evaluate.py — binary_0_3_filtered · SFT vs baseline

Precisión — modelos SFT vs. baseline de producción

Resultados comparativos

Configuración	Mejor modelo	F1	Precisión	Recall
0–10 (baseline producción)	gemini-2.5-flash	0,529	0,409	0,749
0–3 (sin SFT)	gemini-2.5-flash-lite	0,611	0,465	0,891
0–3 SFT v3	sft_gemini-2.0-flash:v3	0,604	0,649	0,565
Binaria (prompt base, sin SFT)	gemini-2.5-flash	0,714	0,654	0,785

0,396 precisión baseline

→

0,649 SFT v3 (+64 %)

→

0,668 prompt binario (+68,9 %)

Dataset golden: 400 posts balanceados (100 por clase), sin exposición al entrenamiento
La mejora de precisión del SFT implica reducción en recall — equilibrio aceptable dado el costo asimétrico

Hallazgo inesperado

Prompt binario sobre modelo base

Precisión: 0,668 · F1: 0,714

Sin ningún entrenamiento adicional

SFT v4 (entrenado en escala binaria)

Precisión: 0,654 · F1: 0,714

Con 1.300 ejemplos de entrenamiento

El modelo base ya contiene conocimiento relevante sobre toxicidad en el dominio político-partidario

1.300 ejemplos insuficientes para superar ese conocimiento previo en tarea directamente binaria

El prompt binario sobre modelo base constituye una alternativa de menor costo operacional con rendimiento comparable al SFT actual

Impacto en producción

Resultados presentados en tres instancias al equipo de Civic Health Project — decisiones concretas adoptadas:

① Cambio de escala

Migración de clasificación 0–10 → 0–3 en producción

② Selección de modelo

Familia Gemini adoptada como clasificador de producción

③ Escalado automatizado

Despliegue de cuentas automatizadas → 111.000+ intervenciones publicadas

Primera explotación sistemática de los datos históricos de Normsy desde su puesta en producción en enero de 2023

Conclusiones

Pipeline analítico habilita por primera vez análisis histórico sistemático.
Cuentas automatizadas escalan volumen sin degradar calidad individual.
Escala 0–10 → 0–3: mejora consistente en todos los modelos.
SFT mejora precisión en +64 % vs baseline.
Prompt binario: alternativa competitiva sin entrenamiento.

Próximos pasos

① Dataset — escalar el conjunto de ajuste para convergencia del SFT.

② DPO — Direct Preference Optimization para balance precisión/recall más controlado.

③ Embeddings multimodales — LLM → embeddings → SVM/XGBoost, elimina costo de inferencia por post.

Muchas gracias

¿Preguntas?

111.000+ intervenciones

+64 % precisión SFT

0,714 F1 score

Mg. Ing. Joaquín González · CEIA FIUBA · Abril 2026

Optimización de intervencionesautomatizadas contra discursosde odio en redes sociales