WeatherNext 3 invierte el manual predeterminado de construcción de agentes
WeatherNext 3 de DeepMind produce pronósticos meteorológicos que superan los modelos NWP basados en física. Lo hace siendo un especialista estrecho—un modelo de secuencia entrenado en 40 años de datos de reanálisis, optimizado para un trabajo: predecir el estado atmosférico dado el estado anterior. No responde preguntas. No enruta entre herramientas. Pronostica.
La mayoría de los equipos de agentes hacen lo opuesto. Recurrimos a GPT-4o o Claude como tomador de decisiones central, agregamos recuperación (RAG), tal vez ajustamos en ejemplos de dominio, luego lo apuntamos a una API meteorológica mediante llamadas de herramientas. Intercambiamos especialización por generalidad, aceptando que ningún LLM único será mejor en pronósticos, análisis de sentimientos, generación de código y enrutamiento de intención del usuario simultáneamente. Esa arquitectura funciona cuando el trabajo del agente es orquestación. Falla cuando el trabajo del agente incluye predecir series temporales.
La tensión es real. La especialización significa bloqueo de proveedor—si Google posee la API de WeatherNext, estás vinculado al tiempo de actividad de Google, esquema y curva de costos. La generalidad significa aceptar que Claude nunca igualará la precisión de un especialista de dominio en el territorio de ese especialista. La mayoría de los equipos con los que hemos trabajado optan por defecto por generalidad y aceptan el impuesto de precisión. WeatherNext 3 prueba que no siempre es el intercambio correcto.
Por qué los LLM genéricos pierden en series temporales — y seguirán perdiendo
La tokenización destruye la estructura numérica. Cuando alimentas una serie temporal en un LLM, estás convirtiendo números en tokens discretos. Una lectura de temperatura de 23.7°C podría abarcar tres tokens. El modelo no tiene sesgo inductivo de que 23.7 y 23.8 sean vecinos; son solo tokens adyacentes en un vocabulario aprendido. Durante 10,000 puntos de inferencia—un pronóstico de 40 días en intervalos de 6 horas—ese ruido se acumula.
Las ventanas de contexto también importan. WeatherNext ve 40 años de datos históricos. La ventana de 200k tokens de un LLM moderno suena grande hasta que te das cuenta de que 40 años de observaciones diarias son 14,600 puntos. Con sobrecarga de tokenización, estás ajustando tal vez 5,000 puntos históricos en contexto. Los LLM autorregresivos tampoco tienen sesgo inductivo físico para propagación de series temporales—no saben que los gradientes de presión impulsan el viento, que la inercia térmica suaviza las oscilaciones de temperatura. Aprenden correlaciones en datos, no causalidad en física.
El costo y la latencia son restricciones más difíciles. Un único pronóstico de 10,000 puntos de Claude cuesta aproximadamente $10–15 en tokens. Un lote de 1,000 pronósticos es 10–15k. WeatherNext hace el mismo trabajo a una fracción del costo por llamada y latencia subsegundo. La sobrecarga de herramientas de 3–8 segundos de tu agente importa más cuando cada fallback al modelo genérico quema presupuesto.
La bifurcación: arquitectura alrededor del especialista, o enrutamiento hacia él
Tienes dos arquitecturas honestas. Ninguna es incorrecta; ambas tienen costos.
Opción A: Haz del especialista el núcleo. Enruta LLM como orquestador. Le pides a Gemini que entienda la pregunta del usuario, decida si se necesita un pronóstico e invoque al especialista. Si la API especialista tiene un esquema—llámalo POST /forecast/{location}/{lead_time} con claves de idempotencia—defines eso como una herramienta en tu indicación de LLM. El LLM aprende la decisión de enrutamiento. Desventaja: estás bloqueado a la disponibilidad de Google. Si el esquema de la API cambia, reconstruyes tu definición de herramienta y reevalúas. Ventaja: obtienes pronósticos precisos y control de latencia.
Opción B: Mantén el LLM como núcleo. Define el especialista como fallback. Cuando el LLM enruta a meteorología, llama a tu capa de agente, que verifica una regla de enrutamiento de Vercel AI Gateway (o condicional n8n) que dice "si dominio=meteorología, intenta WeatherNext primero, retrocede a Claude si el especialista no está disponible." Ganas portabilidad—puedes intercambiar la API de Google por la de OpenWeather sin tocar el indicador de LLM. Pierdes latencia en arranque en frío y ganas complejidad en lógica de fallback.
La tercera opción—pretender que Claude o GPT-5 eventualmente igualará a un especialista de dominio—es la que hemos acertado mal antes. No apuestes por ello.
Las rutas de fallback son donde realmente vive esta decisión
La bifurcación arquitectónica solo importa si diseñas para la indisponibilidad del especialista. Aquí es donde los diseños ingenuos colapsan.
La API especialista va 5xx. ¿Ahora qué? Tus opciones: degradar a una adivinanza de LLM (más barata, más lenta, menos precisa), devolver un pronóstico en caché de tu última fila Postgres conocida como buena, o fallar completamente y pedir al usuario que reintente. Ninguno es incorrecto; cada uno tiene un costo. Ahora almacenamos cada pronóstico especialista en Postgres con un TTL, mantenemos una capa de caché Redis para las últimas 48 horas de llamadas, y registramos qué ruta se tomó (especialista, caché, fallback de LLM, fallo duro) para cada solicitud.
Las claves de idempotencia son innegociables. Si la API especialista devuelve 200 pero agota el tiempo de espera leyendo la respuesta, no puedes reintentar ciegamente. Envuelve la llamada especialista con una clave de idempotencia derivada de la ubicación y el tiempo de pronóstico. Las colas de letra muerta (vía RabbitMQ o similar) mantienen llamadas fallidas para reintento asincrónico. La lógica de reintento en sí: hemos encontrado que el backoff exponencial (comenzar en 100ms, tope en 5s) supera el fallback inmediato de LLM para fallos transitorios. Pero si el especialista está caído durante 30+ segundos, cae a caché o LLM. Las banderas de confianza importan—registra cuando estés devolviendo un pronóstico de fallback, para que tu canalización de evaluación capture degradación silenciosa.
Evaluando el híbrido: no califiques el LLM en el trabajo del especialista
Una vez que te comprometes con la bifurcación de especialización, tu estrategia de evaluación tiene que cambiar. No puedes ejecutar RMSE en toda la canalización y llamarlo hecho.
Divide tus evaluaciones en capas. Mide MAE/RMSE solo en la ruta especialista—ese es tu techo de precisión. Mide la decisión de enrutamiento (¿identifica correctamente el LLM cuándo se necesita un pronóstico?) como un problema de clasificación: F1 de selección de herramientas. Mide la calidad del fallback por separado: ¿con qué frecuencia el fallback de LLM coincidió con el pronóstico del especialista dentro de una desviación estándar? Ejecuta evaluaciones de bucle cerrado que reproduzcan decisiones de agentes pasadas y capturen deriva de fallback silencioso—un escenario donde tu tasa de acierto de caché cae 20% sin que nadie lo note.
Optimiza para costo por acción exitosa, no costo por token. Una decisión de enrutamiento de 5 tokens que llama al especialista cuesta más en total que un pronóstico de LLM de 500 tokens. Pero el especialista gana en precisión y latencia. Registra ambas rutas, compáralas semanalmente. Si el enrutamiento regresa (la precisión del especialista cae por debajo de tu SLA o el LLM comienza a enrutar incorrectamente más del 5% del tiempo), activa una reconstrucción.
El patrón se generaliza más allá de la meteorología
El pronóstico de series temporales no es único. AlphaFold domina la predicción de estructura de proteínas. Los embeddings dominan la búsqueda semántica (y los modelos especializados superan la clasificación de LLM de cero disparos en búsqueda de código). Textract y Donut superan los modelos de visión general en OCR. XGBoost aún supera la puntuación de fraude basada en LLM en datos de características tabulares. Si tu tarea tiene una tabla de clasificación y el especialista la domina, no le pidas al LLM—arquitectura alrededor del especialista.
Ahora hacemos tres preguntas antes de escribir un indicador de sistema: ¿Existe una tabla de clasificación para esta tarea? Si es sí, ¿quién está en la parte superior? Si no es un LLM, ¿puedes permitirte llamar al especialista, o estás bloqueado en inferencia solo de LLM por razones de latencia/costo? El costo honesto del bloqueo de proveedor—comprometerse con la API de WeatherNext de Google, o Codex de OpenAI, o análisis de documentos de Anthropic—es generalmente más barato que el impuesto de precisión de forzar un modelo generalista en el trabajo de un especialista. La pregunta real no es si el especialista es más barato por llamada; es si la arquitectura que acepta la existencia del especialista hace tu agente más rápido, más preciso y más fácil de operar.
Cerrando el bucle: cuándo reconstruir
Si estás en medio de la arquitectura en un dominio donde existe un modelo especialista—plegamiento de proteínas, pronósticos, análisis de código, puntuación de fraude—la bifurcación que estás haciendo ahora se agravará durante 18 meses. Elegir solo LLM porque se siente más simple al principio significa reconstruir cuando te das cuenta de que la precisión no es aceptable. Elegir especialista primero significa reelaborar tu orquestación de agentes si la API del especialista cambia. El enrutamiento a través de una puerta de enlace de Vercel AI o capa n8n te compra opcionalidad, pero agrega latencia que no siempre puedes absorber.
Si el especialista existe y es bueno, arquitectura alrededor de él hoy. El costo de reconstrucción se agrava rápidamente.