De expedientes de la FCC a unos $77M de gasto publicitario rastreado

El reto

El gasto en publicidad política de TV es información pública, y casi nadie puede leerlo. Cada estación presenta sus contratos de publicidad política como PDF en los Public Inspection Files de la FCC, con formatos que difieren de estación en estación y cambian sin aviso. El anunciante que aparece en el contrato rara vez es la entidad política que realmente paga: los PAC, los comités y los brazos de campaña compran cada uno bajo su propio nombre.

Así que una pregunta tan básica como “cuánto gastó cada coalición en este mercado la semana pasada” no tenía respuesta salvo que una persona abriera los expedientes de a uno. Nuestro cliente necesitaba ese número cada semana, y necesitaba poder defender cada dólar de vuelta hasta el documento del que salió.

El enfoque

Elegimos extracción con LLM por encima del análisis por plantillas, y esa decisión le dio forma a todo lo demás. Las reglas de formato son baratas de escribir y se rompen la primera vez que una estación cambia el formato de su contrato, cosa que estas estaciones hacen sin avisar. Un modelo multimodal que lee el documento como lo leería una persona no depende del formato.

De ahí salieron tres principios:

• Un modelo por etapa, una sola puerta de entrada. Las etapas quieren modelos distintos, así que clasificación, extracción y resolución de entidades rutean cada una al modelo que le conviene. Todo pasa por un único cliente de puerta de entrada, así que ningún SDK de proveedor llega a la lógica de negocio y cambiar un modelo es un cambio de configuración.
• Umbrales de confianza en vez de confianza silenciosa. Una extracción con poca confianza, o una coincidencia de entidad con poca confianza, va a una cola de revisión humana. Ni se acepta en silencio ni se descarta en silencio, que son los dos modos de falla que vuelven poco confiable un producto de inteligencia.
• Cada cifra conserva su procedencia. Cada registro de gasto lleva la URL del expediente del que salió, hasta la API de consulta.

La solución

Construimos un proceso de cuatro etapas, cada una consumiendo la salida persistida de la anterior.

1. Adquisición. Sondea la API de Public Files de la FCC por estación, deduplica por URL y por hash de contenido, guarda los PDF y registra cada intento de rastreo para auditoría.
2. Procesamiento de documentos. Clasifica cada expediente según su relevancia política, extrae los renglones del contrato de forma literal (anunciante, monto bruto, fechas de pauta, cantidad de spots) con un modelo multimodal, y luego valida el resultado contra reglas de negocio.
3. Inteligencia. Resuelve el nombre crudo del anunciante hacia una entidad política canónica, y luego atribuye el gasto al candidato beneficiario a través de las relaciones entre PAC y candidato.
4. API de consulta. Endpoints REST para gasto semanal por coalición, tendencias de varias semanas, desglose por entidad y detalle a nivel de registro.

Vale la pena nombrar dos piezas. La resolución de entidades revisa un caché normalizado de alias antes de gastar una llamada al modelo, y cada decisión de revisión humana se escribe de vuelta en ese caché, así que un anunciante repetido no cuesta nada: la resolución baja de unos 3 segundos a menos de 100 milisegundos cuando pega en el caché. Y la consola interna de administración habla solo con la API REST, nunca con la base de datos, lo que convierte a la consola en una prueba de integración viva de la misma superficie de API de la que depende el cliente.

Resultados

La plataforma corrió en producción contra la API real de la FCC, no contra un conjunto de muestra.

• Unos $77M en gasto de publicidad política de TV rastreados y atribuidos entre dos coaliciones.
• 1.664 documentos con clasificación y extracción completas, con una tasa de éxito de 98,8% y 20 fallas.
• 44 estaciones de TV sondeadas. 5.321 documentos descubiertos, 4.961 deduplicados correctamente al volver a sondear, y cero fallas de sondeo.
• El criterio de aceptación de la prueba de concepto era de 75% o mejor de precisión de extracción. Una ventana de validación de dos semanas dio 80% o mejor, así que el criterio se cumplió.

Detrás de esas cifras hay 52.768 registros de gasto materializados. Publicamos los unos $77M como una aproximación y no como un total exacto a propósito, porque parte de ese conjunto de registros todavía estaba esperando la reparación descrita abajo cuando se leyeron estos números.

Qué lo hizo difícil

El problema más difícil era uno que nadie había notado: reprocesar un documento publicaba una segunda extracción sin retirar los registros de gasto derivados de la primera. Una auditoría encontró que 25.086 de 52.768 registros en producción, el 47,5%, venían de extracciones superadas, y que 410 documentos se estaban contando en dos generaciones a la vez. Los totales en dólares estaban inflados y nada en el sistema lo decía.

El arreglo tentador era una migración destructiva. En vez de eso publicamos la cuidadosa: publicación atómica de extracciones con un marcador de generación vigente, reconciliación del gasto en cada republicación, y un script de reparación opcional, idempotente y por lotes para los registros históricos. Una reparación idempotente se puede correr, detener y volver a correr contra datos vivos. Una migración destructiva tiene un solo intento.

El segundo problema difícil fue la consistencia sin transacciones. El cliente de base de datos no ofrecía transacciones del lado del cliente, así que toda operación de varios pasos crítica para la consistencia se movió a procedimientos almacenados que toman un bloqueo de fila y vuelven a verificar sus precondiciones bajo ese bloqueo. El borrado de entidades vuelve a contar referencias mientras sostiene el bloqueo, así que una inserción concurrente de alias sobrevive o falla de forma visible. La revisión de resolución reclama primero el renglón, así que un revisor concurrente que pierde no escribe nada en lugar de sobrescribir una decisión que nunca vio.

En el camino también encontramos y arreglamos un error de atribución que reportaba en silencio como gasto directo una consulta de relación fallida, y un error de elegibilidad por lotes que dejaba de funcionar en silencio pasados 1.000 renglones procesados. Los dos eran de la misma especie que el de doble conteo: no una caída, solo un número equivocado sin ninguna alarma asociada.