← Todos los insights

Análisis de tendenciaEnfoque: España y Latinoamérica4 min de lectura

Una respuesta tipada puede ser errónea. Snowflake y Cloudflare crean modelos rápidos para decidir y extraer

Snowflake Decision Fast y Cloudflare Clairic devuelven decisiones tipadas y valores extraídos. Qué arreglan las salidas tipadas y por qué la confianza aún necesita calibración.

Escuche este artículo · 6 min

Narración completa del artículo, generada con IA.

Huevos blancos en los huecos de una huevera azul, en duotono La Madre, junto a las palabras Válido y erróneo
Foto: congerdesign (Wikimedia Commons, CC0)

Un modelo de lenguaje de propósito general que enruta mal un ticket de soporte suele fallar de una forma que usted puede ver: responde con una frase cuando usted pidió una etiqueta, inventa una categoría o envuelve la respuesta en texto que su parser rechaza. Un modelo construido para devolver una decisión tipada falla de otra manera. Devuelve una categoría válida, con una probabilidad adjunta, y la categoría es incorrecta.

Ese es el trade-off que dos anuncios del 19 de octubre hacen explícito. Ambos merecen tomarse en serio, y ambos desplazan el trabajo de confiar en la salida de la IA a un lugar que muchos equipos todavía no han construido.

Dos modelos que no escriben

Snowflake Decision Fast es una variante de menor latencia del modelo Snowflake Decision presentado dos semanas antes para clasificación, puntuación, filtrado y enrutamiento. Devuelve opciones categóricas con una probabilidad por opción, puntuaciones numéricas y decisiones de sí o no, en lugar de texto libre. Está en private preview, disponible bajo solicitud a través del equipo de cuentas de Snowflake, y es accesible en SQL mediante AI_COMPLETE o desde aplicaciones y agentes mediante una API REST en Cortex AI Gateway. Snowflake dice que los viajes de ida y vuelta al endpoint en su demostración en vivo se mantuvieron de forma consistente por debajo de 300 milisegundos, sin describir cómo se midió. El precio no está publicado.

Cloudflare Clairic, en preview en Workers AI, hace para la extracción lo que los modelos de decisión hacen para las elecciones. Responde en una sola pasada, sin generar tokens de razonamiento ni de salida, y solo cobra por los tokens de entrada. Devuelve fragmentos extraídos con desplazamientos de caracteres y una puntuación de confianza, valores calculados como un total a partir de un precio más impuestos, estimaciones como una mediana con un intervalo del 80% y pronósticos simples. Cuando falta un valor, devuelve null, con la probabilidad de que sea null y una mejor conjetura. En uno de los ejemplos de Cloudflare, un pipeline de reclamaciones por daños se ejecutó en 19,3 segundos frente a 61,7 segundos de un pipeline totalmente basado en LLM, con $6,032 frente a $11,740 por millón de reclamaciones. Está previsto publicar los pesos abiertos.

Cubrimos la primera ola de esta idea cuando Cloudflare argumentó que un agente no debería preguntar a un modelo de frontera cada pequeña cuestión, y cuando OpenAI empezó a poner precio a la capa de decisión por separado. El nuevo paso es la amplitud: el mismo diseño ahora cubre decisiones acotadas dentro de un data warehouse y extracción estructurada en el borde de la red.

Qué arreglan de verdad las salidas tipadas

Eliminan una clase de fallo que consume una parte sorprendente del tiempo de ingeniería en producción: la salida mal formada. No hay reintentos por JSON inválido, ni cláusulas de prompt que imploren al modelo responder con una sola palabra, ni categorías que no existan aguas abajo. También hacen predecible la latencia, lo que importa cuando una decisión está dentro de un pago, una comprobación de fraude o la selección de herramientas de un agente.

Y hacen que el costo de la clasificación y extracción de alto volumen parezca infraestructura en lugar de una factura de chat.

Qué le dejan a usted por construir

Corrección. Los autores de Cloudflare lo dicen sin rodeos: las salidas están bien formadas, pero no necesariamente son correctas. Una categoría válida es una garantía de formato, no una garantía de exactitud. Cada tipo de decisión sigue necesitando un conjunto de evaluación extraído de sus propios casos, con tasas de error por clase.

Calibración. Ambos productos exponen un número de confianza, y ambos le invitan a actuar sobre él. Snowflake describe sus probabilidades como una señal sobre la que se puede fijar un umbral y cita 0,99 como muy confiable; no afirma en qué medida esas probabilidades coinciden con resultados reales. Cloudflare dice que los intervalos de Clairic están diseñados para estar calibrados y que pueden ser demasiado estrechos con datos desconocidos. Un umbral solo es un control cuando alguien ha comprobado, con sus datos, que “0,95” acierta aproximadamente el 95% de las veces. Hasta entonces, es un número con una coma decimal.

Aritmética. Clairic calcula dentro de la pasada única del modelo. Cloudflare informa que los cálculos de uno y dos pasos parecen fiables, mientras que los cálculos dependientes más largos y la agregación entre muchas filas son débiles, y recomienda dejar que el código haga los cálculos más largos. Ese consejo se generaliza: extraiga con el modelo, calcule con código y nunca deje que una estimación del modelo ocupe el lugar de un cálculo determinista cuando este sea posible.

Enrutar los casos inciertos. El verdadero objeto de diseño es la política que envía las decisiones de baja confianza, los valores null y los intervalos amplios a una persona o a un modelo más grande. Ahí es donde los errores de un modelo barato se detectan o se escapan, que es el costo que más importa, como argumentamos en poner precio a los modelos según dónde caen sus errores.

La comparación que vale la pena hacer antes de adoptar cualquiera de los dos productos no es el costo por llamada. Es el costo por decisión correcta, con la calibración medida, sobre unos cuantos miles de sus propios registros.

¿Tiene un caso de uso de IA detenido entre el prototipo y la producción?

Cuéntenos qué quiere poner en marcha. Le respondemos con próximos pasos honestos.

Conversemos sobre un caso de uso