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

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

insuficiente moderación humana frente al volumen masivo

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

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

Recorrido: tweet tóxico detectado → clasificado → intervención publicada

Flujo
de
intervención

normsy — flujo de intervención

Flujo de procesamiento de intervenciones

Solución de datos — el problema

normsy — arquitectura de infraestructura

Estado inicial

MongoDB Atlas como única fuente
→ 800.000+ registros sin joins ni analítica

Consecuencia

Sin dashboards · sin EDA 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 MongoDB
Evento procesado en < 1 segundo

Airflow — smd_multicollection_etl

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

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

Volumen de intervenciones por trimestre: humanas vs automatizadas

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)

YAML

Configuración
de experimento

→

CLI

run.py
punto de entrada

→

LLM APIs

OpenAI · Google
Anthropic · xAI · Alibaba

→

PostgreSQL

Resultados
y métricas

Reproducible · configuración versionada en Git · resultados persistidos por experimento

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

Plataforma en acción

Dashboards Grafana · pipeline ETL · CDC Kafka · métricas en tiempo real

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

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	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

Hallazgos

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

Prompt binario: 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?

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

Optimización de intervencionesautomatizadas contra discursosde odio en redes sociales