IBM en colaboración con Confluent han integrato los modelos Granite Time Series directamente en Confluent Cloud para permitir predicciones y detección de anomalías en datos en movimiento. Esta propuesta evita la necesidad de trasladar las series temporales a otra plataforma de aprendizaje automático y habilita la invocación de modelos desde Apache Flink mediante SQL. Actualmente, la funcionalidad está en Early Access, comenzando en Confluent Cloud en AWS.
Resumen rápido de Granite Time Series en Confluent en 30 segundos
- IBM y Confluent llevan modelos de series temporales al procesamiento en streaming de datos.
- Las funciones
AI_FORECASTyAI_DETECT_ANOMALIESfacilitan el uso de estos modelos desde Flink SQL. - La primera versión incluye cuatro modelos de IBM con entre 1 y 260 millones de parámetros, diseñados para funcionar sin GPU.
- Los resultados pueden enviarse de vuelta a Kafka para alimentar alertas, aplicaciones, lakehouses o agentes de IA.
- Está en Early Access: aún no garantiza plena disponibilidad ni soporte completo.
Este anuncio tiene una visión más arquitectónica que la simple incorporación de otros modelos de IA en un servicio cloud. IBM y Confluent buscan acercar la inferencia al lugar donde se generan los eventos, reduciendo así el recorrido habitual entre generación, almacenamiento, análisis y decisión.
Esto puede ser especialmente relevante en sistemas donde unos minutos marcan la diferencia: transacciones financieras, telemetría industrial, inventarios, rendimiento de aplicaciones, tráfico de red o sensores.
Sin embargo, es importante matizar algunas afirmaciones del anuncio. La integración no garantiza que cualquier empresa solucione automáticamente sus problemas “en segundos”, ni implica que un streamhouse sea siempre más barato que un lakehouse. La novedad concreta radica en que ciertas operaciones de inferencia en series temporales pueden ejecutarse directamente dentro del flujo gestionado por Confluent.
De almacenar y analizar después a ejecutar IA sobre el flujo en tiempo real
Muchas arquitecturas analíticas siguen un patrón conocido:
Un sistema, sensor o aplicación genera eventos. Estos datos se transportan a un sistema intermedio que los almacena en un data warehouse, data lake o lakehouse. Posteriormente, otro proceso los usa para entrenar modelos, realizar inferencias o generar informes.
Este enfoque sigue siendo válido para muchas cargas.
El problema surge cuando el valor de los datos disminuye rápidamente con el tiempo.
Una anomalía en la temperatura de una máquina industrial es más útil si se detecta antes de que ocurra un daño. Una transacción fraudulenta resulta más valiosa si se identifica antes de finalizar. Una subida inesperada de latencia debería detectarse mientras afecta a la aplicación y no cuando ya es un dato para el informe del día siguiente.
La integración entre IBM y Confluent busca reducir esa distancia.
Confluent proporciona el flujo continuo de eventos, mientras Apache Flink realiza el procesamiento en tiempo real. Los modelos Granite Time Series pueden usarse para generar predicciones o detectar anomalías sin necesidad de desplegar un servicio independiente de model serving.
Y estos resultados no tienen que limitarse a ser utilizados solo allí.
Pueden volverse a escribir en topics de Apache Kafka, desde donde otros sistemas —como alertas, dashboards, aplicaciones, repositorios analíticos o agentes de IA— pueden acceder a ellos.
Así, la inferencia pasa a ser una etapa más del pipeline de eventos.
Funciones SQL que simplifican la complejidad
Una de las decisiones clave es la interfaz elegida para interactuar con estos modelos.
Confluent expone los modelos mediante dos funciones en Flink SQL:
AI_FORECAST para hacer predicciones y AI_DETECT_ANOMALIES para identificar valores fuera de lo esperado.
Por ejemplo, una serie con métricas de uso de CPU puede alimentar AI_FORECAST. La función recibe el valor actual, su marca temporal y diversos parámetros de configuración, y devuelve múltiples valores futuros junto con cuantiles que representan la incertidumbre.
La detección de anomalías funciona de forma similar. AI_DETECT_ANOMALIES compara los valores observados con intervalos de predicción y devuelve datos como el valor real, la predicción, límites inferior y superior y un indicador de si el dato se considera anómalo.
Este proceso no convierte el aprendizaje automático en comandos mágicos.
La calidad del dato, la frecuencia, el contexto temporal, los umbrales de confianza y la decisión final del sistema siguen siendo fundamentales.
Una alerta falsa puede ser solo molesta, pero una inferencia que automatice bloqueos, decisiones o acciones industriales requiere controles mucho más rigurosos.
La simplificación radica en cómo se consume el modelo, no en eliminar los desafíos de trabajar con predicciones.
Cuatro modelos compactos y sin necesidad de GPU
Otra diferencia respecto a muchas conversaciones actuales sobre IA es el tamaño de los modelos.
IBM y Confluent han seleccionado inicialmente cuatro modelos Granite Time Series: PatchTST-FM-r1, FlowState-r1.1, TTM-r3 y TSPulse.
No todos tienen exactamente el mismo objetivo.
| Modelo | Principal orientación |
|---|---|
| PatchTST-FM-r1 | Predicción probabilística, distribuciones y cuantiles |
| FlowState-r1.1 | Predicción puntual y datos con distintas frecuencias |
| TTM-r3 | Balance entre eficiencia y rendimiento para muchas series |
| TSPulse | Detección de anomalías, clasificación, búsqueda de semejanzas y recuperación de huecos |
Estos cuatro modelos tienen entre 1 y 260 millones de parámetros y están diseñados para operar sin GPU. Por ejemplo, TTM-r3 está enfocado en procesar numerosas series de forma eficiente con CPU.
Es un enfoque muy diferente a usar un gran modelo de lenguaje para analizar cualquier señal.
Las series temporales tienen características específicas: orden cronológico, periodicidad, tendencia, estacionalidad y relaciones entre observaciones consecutivas. Un modelo especializado y compacto puede ser suficiente para ciertos problemas, sin necesidad de miles de millones de parámetros.
Desde el punto de vista de infraestructura, esto importa mucho.
La inferencia en datos operacionales puede generar un volumen enorme. Si cada sensor, servidor, transacción o producto requiere predicciones continuas, el costo por inferencia puede ser tan relevante como la precisión del modelo.
Evitar GPU también facilita integrar estos análisis en pipelines que manejan grandes volúmenes de eventos.
El dato puede quedarse en Confluent Cloud
Existe otra implicación técnica importante.
Los modelos utilizados por AI_FORECAST y AI_DETECT_ANOMALIES son gestionados por Confluent y alojados dentro de Confluent Cloud. La documentación aclara que, por ahora, no es posible usar modelos remotos de otros proveedores ni modelos personalizados gestionados por el cliente.
Esto reduce partes de la infraestructura necesaria.
No hace falta enviar cada evento a un endpoint externo para inferencia, gestionar credenciales adicionales o desplegar otro servicio para alojar los modelos.
IBM y Confluent afirman que este enfoque puede disminuir la infraestructura dedicada y reducir costes de entrada y salida de datos, además de mantener las inferencias dentro de las políticas de esquemas, linaje y control de acceso existentes en la plataforma.
Kafka también permite que los eventos se conserven y reproduzcan.
Una decisión automatizada no tiene que ser una caja negra irrecuperable.
Si se mantiene el flujo, una organización puede revisar qué información recibió, investigar incidentes, evaluar el comportamiento del modelo o ejecutar inferencias sobre datos históricos.
Para aplicaciones reguladas o decisiones críticas, esta trazabilidad puede ser tan importante como la predicción misma.
Desde mantenimiento predictivo hasta rendimiento del servidor
Muchos ejemplos empresariales son fáciles de imaginar, ya que prácticamente cualquier infraestructura moderna genera series temporales.
Un entorno industrial mide temperaturas, velocidades, presiones y niveles de producción. Una tienda registra ventas e inventarios. Una plataforma financiera monitoriza transacciones. Una aplicación genera latencias, errores y uso de recursos de forma continua.
También hay aplicaciones claras para operaciones IT:
CPU, memoria, IOPS, latencia de almacenamiento, tráfico, peticiones, tiempos de respuesta, conexiones abiertas o errores HTTP son series temporales.
Un sistema tradicional puede activar alertas cuando la CPU supera el 90 %.
Un modelo temporal puede intentar detectar comportamientos anómalos antes de que el umbral se cruce, por ejemplo, que el comportamiento actual no sea típico para esa máquina incluso si no ha llegado a un límite fijo.
También puede estimar cuándo se alcanzará cierta capacidad.
La diferencia está en que las reglas respondan a condiciones predefinidas, mientras las predicciones intentan anticiparse y las detecciones buscan patrones fuera de lo normal.
No es necesario eliminar los umbrales tradicionales, sino combinarlos con modelos predictivos y técnicas de observabilidad para una mejor monitoreo.
Detectar fraude en tiempo real durante la transacción
IBM ilustra con ejemplo los servicios financieros:
Una transacción puede analizarse mientras aún circula. Si detecta comportamientos anómalos, el sistema puede actuar inmediatamente: bloquear, solicitar revisión o alertar a otros sistemas de IA.
Aquí surge una de las ventajas más interesantes de combinar streaming con IA.
El resultado del modelo no tiene por qué ser el final del proceso, sino que puede convertirse en otro evento.
Por ejemplo, una anomalía puede publicarse en Kafka, enriquecerse con información adicional, ser analizada por otro sistema y finalmente desencadenar una acción automática.
Así, la arquitectura se asemeja más a integrar inferencia en un sistema distribuido reactivo, en lugar de solo enviar datos a una IA.
El lakehouse persiste incluso con IA en streaming
Es importante aclarar que, aunque se integre inferencia en streaming, esto no elimina la necesidad de un data lake, warehouse o lakehouse.
Son problemas diferentes: el almacenamiento histórico sigue siendo necesario para análisis, entrenamiento, cumplimiento, investigación y reporting.
El streaming resulta especialmente útil para actuar en tiempo real preservando la actualidad del evento.
Los dos enfoques pueden coexistir y, de hecho, IBM indica que los resultados de las inferencias pueden distribuirse a sistemas operativos y lakehouses desde Kafka.
Por eso, es más correcto hablar de “acercar la inteligencia al flujo de datos” que de eliminar completamente una arquitectura analítica.
Actualmente en Early Access
Una consideración importante es la disponibilidad.
Granite Time Series en Confluent Cloud está en Early Access.
Por ahora, la primera versión está en Confluent Cloud sobre AWS. IBM y Confluent planean posteriormente ampliar soporte a instalaciones locales y entornos híbridos.
La documentación aclara que estas funciones en Early Access no garantizan un nivel de servicio y se consideran funcionalidades de prueba de concepto.
Esta precaución es esencial cuando las aplicaciones impactan en procesos críticos.
Se puede experimentar ya, pero aún no se trata de una solución lista para producción con requisitos de alta disponibilidad.
El anuncio de IBM y Confluent es una interesante visión del futuro, sin necesidad de que sea una revolución inmediata.
Mientras en el discurso público la IA empresarial suele centrarse en modelos de lenguaje, chatbots y agentes conversacionales, estas series temporales muestran que una proporción enorme de datos corporativos tiene otra forma: valores que cambian constantemente con el tiempo.
Servidores, fábricas, redes, tiendas, vehículos y sistemas financieros generan esta información sin descanso.
Aplicar modelos pequeños en estos flujos puede ser mucho más útil que un chatbot en ciertos contextos.
Tal vez, la aportación más relevante de este anuncio es que la inteligencia artificial empieza a moverse desde facilitar respuestas humanas hacia infraestructuras que observan continuamente y predicen antes de que alguien pregunte.
Preguntas frecuentes
¿Qué ha anunciado IBM con Confluent?
IBM Granite Time Series se integra en Confluent Cloud para realizar predicciones y detectar anomalías en datos en streaming mediante Apache Flink. La disponibilidad inicial está en Early Access en Confluent Cloud en AWS.
¿Qué modelos Granite Time Series estarán disponibles?
La primera selección incluye PatchTST-FM-r1, FlowState-r1.1, TTM-r3 y TSPulse. Tienen entre 1 y 260 millones de parámetros y operan sin GPU.
¿Cómo se usa la IA desde Apache Flink?
Confluent proporciona las funciones en Flink SQL AI_FORECAST y AI_DETECT_ANOMALIES. Permiten usar los modelos y hacer inferencias sin desplegar infraestructura adicional ni gestionar modelos externamente.
¿Es esta tecnología una sustitución de un lakehouse?
No necesariamente. La inferencia en streaming permite actuar rápidamente en eventos, mientras que los lakehouses siguen siendo necesarios para almacenamiento de largo plazo, análisis histórico y entrenamiento. Los resultados se pueden integrar en ambas arquitecturas para coordinar mejor ambos enfoques.