Pipeline de inteligencia de noticias
20.000 noticias al día, embebidas, agrupadas en historias y enriquecidas con LLMs — por el 15% de lo que costaba antes.
- Rol
- Ingeniero senior — diseño, implementación y operación
- Stack
- Python 3.12 Airflow 3 Kubernetes pgvector PostgreSQL MongoDB LLMs AWS
Problema
Los clientes enterprise necesitan saber qué noticias les afectan de verdad. El flujo bruto son unas veinte mil al día y con muchísima duplicación: la misma historia reescrita por quince medios, sin que ninguno aporte nada. El volumen era el mayor lastre del producto — más entrada significaba más ruido, y pasar un LLM por cada noticia significaba pagar quince veces por una sola historia.
Enfoque
Un pipeline por etapas en Airflow 3 sobre Kubernetes, ordenado para que el trabajo barato y determinista ocurra antes que el caro y probabilístico. Cada titular se convierte en un vector de 1536 dimensiones almacenado en Postgres con pgvector; los artículos se agrupan por distancia coseno bajo un umbral ajustado, y cada cluster elige un representante según la importancia de la fuente. Solo entonces corren las etapas de insights con LLM — sobre historias, no sobre artículos. Una segunda pasada de clustering fusiona historias entre días, para que un tema que dura una semana siga siendo un hilo y no siete. Las decisiones de modelo y prompt se toman evaluando contra los valores que valida el equipo de analistas, con el coste en la columna de al lado de la precisión.
Resultado
Veinte mil noticias al día pasan sin supervisión y el gasto anual en LLMs del pipeline bajó un 85%: de una cifra de seis dígitos a una de cinco. El clustering es lo que hizo la mayor parte: pagar una vez por historia en vez de una vez por artículo, y después dejar que la evaluación moviera etapas a modelos más pequeños allí donde los números decían que la calidad aguantaba.
Lo barato antes que lo caro
La decisión que pagó todo lo demás fue ordenar las etapas por coste. Embeber un titular cuesta céntimos por millar; clasificar un artículo con un modelo grande no. Colapsar quince artículos casi idénticos en una historia antes de la etapa con LLM hace que el paso caro corra sobre una fracción de la entrada — y además mejora el resultado, porque al analista le importa la historia, no qué medio la publicó primero.
El clustering, en concreto
Se embeben los titulares y no los cuerpos completos: un vector de 1536 dimensiones por artículo, escrito en lotes para que la base de datos no sea el cuello de botella, y consultado con el operador de distancia coseno de pgvector bajo un umbral ajustado para quedar entre “parte una historia en dos” y “fusiona dos historias en una”. El artículo representativo de un cluster se elige por importancia de la fuente, así que la historia que emerge es la del medio que importa.
Después la misma maquinaria corre una segunda vez sobre una ventana de varios días. El clustering diario responde a “qué ha pasado hoy”; la pasada multi-día responde a “¿sigue siendo la misma historia que ayer?”, que es la pregunta que tiene de verdad un cliente siguiendo una regulación.
Evaluación, no intuición
Elegir modelo es la decisión menos interesante de un pipeline con LLMs. Lo que hace una etapa desplegable es poder responder “¿esto es mejor que lo que teníamos?” antes de que lo vea un cliente — y eso significa un conjunto etiquetado a partir de decisiones que el equipo de analistas ya validó, y una puntuación por candidato. Cuando eso existe, mover una etapa a un modelo más pequeño es un experimento de una línea con un número detrás, y de ahí salió la mayor parte de ese 85%.
Qué puedo y qué no puedo enseñar
Bajo NDA: forma y resultado, nunca datos de clientes, prompts ni diagramas internos.