IBM y Confluent han integrado los modelos Granite Time Series directamente en Confluent Cloud para aplicar predicción y detección de anomalías sobre datos mientras están circulando. La propuesta evita tener que trasladar primero esas series temporales a otra plataforma de aprendizaje automático y permite invocar los modelos desde Apache Flink mediante SQL. La tecnología ya está disponible en Early Access, inicialmente sobre Confluent Cloud en AWS.
Las claves de Granite Time Series en Confluent en 30 segundos
- IBM y Confluent llevan modelos de series temporales directamente al procesamiento de datos en streaming.
- Las funciones
AI_FORECASTyAI_DETECT_ANOMALIESpermiten utilizar los modelos desde Flink SQL. - La primera versión incluye cuatro modelos IBM de entre 1 y 260 millones de parámetros, diseñados para funcionar sin GPU.
- Los resultados pueden regresar a Kafka para alimentar alertas, aplicaciones, lakehouses o agentes de IA.
- Está en Early Access: todavía no debe tratarse como una funcionalidad con las garantías de un servicio plenamente disponible.
El anuncio tiene más interés arquitectónico que el simple hecho de incorporar otros modelos de inteligencia artificial a un servicio cloud. Lo que IBM y Confluent están intentando es acercar la inferencia al lugar donde se procesan los eventos, reduciendo el recorrido habitual entre la generación del dato, su almacenamiento, el análisis y la posterior decisión.
Eso puede ser relevante en sistemas donde unos minutos de retraso cambian la utilidad de una predicción: transacciones financieras, telemetría industrial, inventarios, rendimiento de aplicaciones, tráfico de red o sensores.
Pero conviene rebajar algunas de las afirmaciones que acompañan al anuncio. La integración no significa que cualquier empresa vaya a solucionar automáticamente sus problemas «en segundos», ni demuestra por sí misma que un streamhouse resulte siempre más barato que una arquitectura lakehouse. La novedad concreta es otra: determinadas operaciones de inferencia sobre series temporales pueden ejecutarse directamente dentro del flujo gestionado por Confluent.
De almacenar primero y analizar después a ejecutar IA sobre el flujo
Muchas arquitecturas analíticas siguen un recorrido conocido.
Una aplicación, sensor o sistema empresarial genera eventos. Esos datos se transportan hasta un sistema intermedio, terminan en un data warehouse, data lake o lakehouse y posteriormente otro proceso los utiliza para entrenar modelos, ejecutar inferencia o generar informes.
Ese diseño sigue teniendo sentido para multitud de cargas.
El problema aparece cuando el valor del dato disminuye rápidamente con el tiempo.
Una anomalía en la temperatura de una máquina industrial interesa mientras todavía puede actuarse sobre ella. Una transacción potencialmente fraudulenta resulta mucho más útil si se identifica antes de completarse. Una subida inesperada de latencia debería detectarse mientras está afectando a una aplicación y no cuando aparece en el informe del día siguiente.
La integración de IBM y Confluent pretende reducir esa distancia.
Confluent proporciona el flujo continuo de eventos y Apache Flink realiza el procesamiento. Los modelos Granite Time Series pueden utilizar esos datos para generar predicciones o detectar anomalías sin desplegar previamente un servicio independiente de model serving.
Los resultados tampoco tienen que terminar ahí.
Pueden escribirse nuevamente en topics de Apache Kafka, desde donde otros consumidores pueden utilizarlos: sistemas de alertas, dashboards, aplicaciones, repositorios analíticos o agentes de IA.
Eso convierte la inferencia en una etapa más del pipeline de eventos.
Dos funciones SQL esconden buena parte de la complejidad
Una de las decisiones más interesantes está en la interfaz elegida.
Confluent expone los modelos mediante dos funciones de Flink SQL:
AI_FORECAST para realizar predicciones y AI_DETECT_ANOMALIES para identificar valores que se apartan del comportamiento esperado.
Por ejemplo, una serie con métricas de utilización de CPU puede alimentar AI_FORECAST. La función recibe el valor, su marca temporal y diferentes parámetros de configuración y devuelve varios valores futuros junto con cuantiles que permiten representar la incertidumbre.
La detección de anomalías sigue una lógica similar. AI_DETECT_ANOMALIES compara los valores observados con intervalos de predicción y devuelve información como el valor real, la predicción, límites inferior y superior y un indicador que señala si el dato se considera anómalo.
Esto no convierte el aprendizaje automático en dos comandos mágicos.
Siguen importando la calidad del dato, su frecuencia, el contexto temporal utilizado, los umbrales de confianza y, sobre todo, qué decisión toma posteriormente el sistema.
Una alerta incorrecta puede ser simplemente molesta. Una inferencia utilizada automáticamente para bloquear un pago, modificar un proceso industrial o cambiar un precio necesita controles bastante más estrictos.
La simplificación está en cómo se consume el modelo, no en la desaparición de los problemas propios de trabajar con modelos predictivos.
Cuatro modelos pequeños y sin necesidad de GPU
Otra diferencia respecto a buena parte de la conversación actual sobre IA está en el tamaño.
IBM y Confluent han seleccionado inicialmente cuatro modelos Granite Time Series: PatchTST-FM-r1, FlowState-r1.1, TTM-r3 y TSPulse.
No todos persiguen exactamente el mismo objetivo.
| Modelo | Orientación principal |
|---|---|
| PatchTST-FM-r1 | Predicción probabilística, distribuciones y cuantiles |
| FlowState-r1.1 | Predicción puntual y datos con diferentes frecuencias |
| TTM-r3 | Equilibrio entre eficiencia y rendimiento para muchas series |
| TSPulse | Anomalías, clasificación, similitud y recuperación de huecos |
Los cuatro modelos tienen entre 1 y 260 millones de parámetros y están diseñados para funcionar sin GPU. TTM-r3, por ejemplo, está orientado a procesar numerosas series con un coste contenido utilizando CPU.
Es una aproximación muy diferente a utilizar un gran modelo de lenguaje para analizar cualquier señal.
Una serie temporal tiene características específicas: orden cronológico, periodicidad, tendencia, estacionalidad y relaciones entre observaciones consecutivas. Un modelo especializado y relativamente pequeño puede ser suficiente para determinados problemas sin necesitar miles de millones de parámetros.
Desde la perspectiva de infraestructura esto importa.
La inferencia sobre datos operacionales puede generar un volumen enorme. Si cada sensor, servidor, transacción o producto necesita una predicción continua, el coste por inferencia acaba siendo tan importante como la precisión del modelo.
Evitar GPU también facilita colocar este tipo de análisis dentro de pipelines que procesan grandes cantidades de eventos.
El dato puede permanecer dentro de Confluent Cloud
Hay otra consecuencia técnica que merece atención.
Los modelos utilizados por AI_FORECAST y AI_DETECT_ANOMALIES son gestionados por Confluent y están alojados dentro de Confluent Cloud. La documentación especifica que estas funciones no permiten actualmente utilizar modelos remotos de otros proveedores ni modelos administrados directamente por el cliente.
Esto reduce algunas piezas de infraestructura.
No hace falta enviar cada evento hacia un endpoint externo de inferencia, gestionar credenciales adicionales o desplegar otro servicio para alojar el modelo.
IBM y Confluent sostienen que este planteamiento puede reducir infraestructura dedicada y evitar determinados costes de entrada y salida de datos. También permite que las inferencias sigan las políticas de esquemas, linaje y control de acceso existentes en la plataforma.
Kafka añade además una propiedad interesante para sistemas empresariales: los eventos pueden conservarse y reproducirse.
Una decisión automatizada no tiene por qué quedar convertida en una caja negra imposible de reconstruir.
Si se conserva el flujo correspondiente, una organización puede revisar qué información recibió el sistema, investigar una incidencia, evaluar posteriormente el comportamiento del modelo o volver a ejecutar inferencias sobre datos históricos.
Para usos regulados o decisiones con impacto operativo, esta trazabilidad puede resultar tan importante como la propia predicción.
Del mantenimiento predictivo al rendimiento de servidores
Los ejemplos empresariales son fáciles de imaginar porque prácticamente cualquier infraestructura moderna produce series temporales.
Un entorno industrial genera temperaturas, velocidades, presiones y niveles de producción. Una tienda registra ventas e inventario. Una plataforma financiera observa transacciones. Una aplicación genera continuamente latencias, errores y consumo de recursos.
También hay aplicaciones evidentes para operaciones IT.
CPU, memoria, IOPS, latencia de almacenamiento, tráfico, número de peticiones, tiempos de respuesta, conexiones abiertas o errores HTTP son series temporales.
Un sistema convencional puede generar una alerta cuando la CPU supera el 90 %.
Un modelo temporal podría intentar detectar algo diferente: que el comportamiento actual resulta anormal para esa máquina aunque todavía no haya cruzado ningún umbral fijo.
También podría estimar cuándo se alcanzará determinado nivel de capacidad.
La diferencia entre ambos planteamientos es relevante para observabilidad. Las reglas responden a condiciones previamente definidas. La predicción intenta anticipar qué ocurrirá y la detección de anomalías busca patrones que se apartan de lo esperado.
No significa que deban desaparecer los umbrales tradicionales.
En infraestructura crítica probablemente tenga más sentido combinar reglas deterministas, observabilidad convencional y modelos predictivos que sustituir unas por otros.
Un fraude puede detectarse mientras el pago sigue en tránsito
IBM pone como ejemplo los servicios financieros.
Una transacción puede evaluarse mientras todavía está circulando por el sistema. Si su comportamiento se aparta de los patrones esperados, el resultado de la inferencia puede alimentar inmediatamente la siguiente acción: bloquearla, solicitar una revisión o proporcionar contexto adicional a otro sistema de IA.
Aquí aparece una de las posibilidades más interesantes de combinar streaming e inteligencia artificial.
El resultado del modelo no tiene que ser el final del proceso.
Puede convertirse en otro evento.
Una anomalía detectada puede publicarse en Kafka. Un segundo sistema puede enriquecerla con información del cliente. Un agente puede analizar ese contexto. Otro servicio puede ejecutar finalmente una acción.
La arquitectura empieza así a parecerse menos a «mandar datos a una IA» y más a incorporar inferencia dentro de un sistema distribuido dirigido por eventos.
El lakehouse no desaparece por incorporar IA al streaming
Hay que hacer, sin embargo, una distinción importante respecto a algunos mensajes que han acompañado al anuncio.
Ejecutar inferencia directamente sobre streaming no elimina automáticamente la necesidad de un data lake, un warehouse o un lakehouse.
Son problemas diferentes.
Las organizaciones continúan necesitando almacenamiento histórico para analítica, entrenamiento, cumplimiento, investigación, reporting y multitud de cargas que no requieren respuesta inmediata.
El streaming resulta especialmente valioso cuando importa actuar sobre el evento mientras conserva actualidad.
Ambos modelos pueden convivir.
De hecho, IBM explica que las inferencias generadas pueden distribuirse desde Kafka tanto hacia sistemas operacionales como hacia lakehouses.
Por eso resulta más preciso hablar de acercar inteligencia al flujo de datos que de sustituir completamente una arquitectura analítica por otra.
Todavía es Early Access
La otra precaución importante está en la disponibilidad.
Granite Time Series en Confluent Cloud se encuentra actualmente en Early Access.
La primera disponibilidad corresponde a Confluent Cloud sobre AWS. IBM y Confluent indican que posteriormente está previsto incorporar soporte para Confluent Platform en instalaciones locales y entornos híbridos.
Además, la propia documentación de Confluent especifica que las funciones incluidas en el programa Early Access no disponen de compromiso de nivel de servicio y se consideran funcionalidades de prueba de concepto bajo sus condiciones del servicio.
Esto resulta especialmente importante tratándose de aplicaciones que podrían terminar interviniendo en procesos críticos.
La tecnología puede probarse ya, pero todavía existe distancia entre experimentar con predicciones sobre un stream y convertirlas en una dependencia de producción con requisitos estrictos de disponibilidad.
El anuncio de IBM y Confluent resulta interesante precisamente sin necesidad de convertirlo en una revolución inmediata.
La IA empresarial se ha asociado durante los últimos años sobre todo con modelos de lenguaje, chatbots y agentes. Las series temporales recuerdan que una parte enorme de los datos corporativos tiene otra forma: valores que cambian continuamente con el tiempo.
Servidores, fábricas, redes, tiendas, vehículos, mercados y sistemas financieros generan ese tipo de información sin descanso.
Aplicar modelos pequeños directamente sobre esos flujos puede resultar mucho más útil para determinadas empresas que desplegar otro chatbot.
Y esa es probablemente la parte más relevante del anuncio: la inteligencia artificial empieza a desplazarse desde aplicaciones que esperan una pregunta humana hacia infraestructuras capaces de observar continuamente lo que está ocurriendo y producir una señal antes de que alguien tenga que preguntar.
Preguntas frecuentes
¿Qué ha anunciado IBM con Confluent?
IBM Granite Time Series se integra con Confluent Cloud para realizar predicción y detección de anomalías directamente sobre datos en streaming mediante Apache Flink. La disponibilidad inicial está en Early Access sobre Confluent Cloud en AWS.
¿Qué modelos Granite Time Series estarán disponibles?
La primera cartera incluye PatchTST-FM-r1, FlowState-r1.1, TTM-r3 y TSPulse. Tienen entre 1 y 260 millones de parámetros y han sido diseñados para ejecutar inferencia sin necesidad de GPU.
¿Cómo se utiliza la IA desde Apache Flink?
Confluent proporciona las funciones Flink SQL AI_FORECAST y AI_DETECT_ANOMALIES. Permiten seleccionar modelos y configurar la predicción o detección de anomalías desde consultas SQL sin desplegar por separado la infraestructura que sirve esos modelos.
¿Puede sustituir esta tecnología a un lakehouse?
No necesariamente. El streaming con inferencia permite actuar rápidamente sobre eventos, mientras que los lakehouses y otros repositorios siguen siendo útiles para almacenamiento histórico, analítica y otras cargas. Las propias arquitecturas planteadas por IBM y Confluent contemplan que los resultados del streaming puedan alimentar estos sistemas.
