Cloudflare lanza Clairic: un modelo de extracción de datos sin tokens de salida

Cloudflare ha lanzado en preview Clairic, el primer modelo de una nueva clase, System One extraction. Está disponible en Workers AI como @cf/cloudflare/clairic, y la compañía promete publicar los pesos abiertos en un futuro próximo. Clairic extrae valores de una entrada no estructurada, los calcula, los estima y los pronostica. Lo hace en una única pasada paralela, sin razonamiento y sin tokens de salida. La respuesta suele tardar menos de un segundo, mientras que una LLM que razona sobre el mismo paso emplea varios segundos. Solo se paga por la entrada.

Un tercer tipo de modelo en la familia System One

El concepto System One (un modelo rápido y preciso, en los términos de Kahneman, frente a la lenta System Two, como las LLM) lo presentó un mes antes TypeSafe con su modelo Jev. Jev y Clef son modelos de decisión: reciben un estado y una lista de preguntas, y devuelven probabilidades para opciones enumeradas de antemano. Cloudflare detectó un hueco.

Una enorme proporción de las llamadas a LLM de frontera con salida estructurada se reduce a las mismas preguntas: cuál es el importe de la factura, cuándo se entregó el pedido, cuántos días de retraso hubo, cuánto costará la reparación, cuánto tráfico habrá en las próximas 24 horas. La lista de respuestas a este tipo de preguntas no se puede elaborar de antemano, así que un modelo de decisión no sirve aquí.

El reparto de tareas queda así. Clairic convierte la entrada en bruto en valores tipados, Clef y Jev convierten los valores en decisiones, y la LLM convierte las decisiones en palabras. El espacio de salida de Clairic es continuo, pero queda acotado por tu esquema, y cada respuesta es o bien un valor del tipo declarado o bien null.

Cómo es una solicitud y qué devuelve

La solicitud consta de un state (texto más hasta cuatro imágenes) y un mapa de campos tipados. Para cada campo se indican el nombre, el tipo y una instrucción opcional en lenguaje llano. Si los campos no caben junto a la entrada en una sola pasada, el servidor los divide por su cuenta en pasadas paralelas, en cada una de las cuales ve la entrada completa, y después une las respuestas. Por eso treinta campos cuestan aproximadamente lo mismo que tres.

Se admiten estos tipos:

• text: un fragmento de la entrada con desplazamientos de caracteres (span) • number: un número leído o calculado, con soporte de integer y decimals • date, time, datetime: fechas de calendario y horas válidas en formato ISO • duration: una duración en la unidad elegida • list: una lista de textos, números o fechas en el orden en que aparecen en la entrada • estimate: una distribución dentro de tu [min, max] sobre una rejilla dada, lineal o logarítmica • forecast: una estimación por cada paso futuro de la serie, cada una con su propio intervalo del 80%

Cada respuesta escalar llega con p_null (la probabilidad de que el valor no esté en la entrada) y confidence. Las estimaciones incluyen la mediana y el intervalo p10–p90, y bajo petición se devuelven los 99 percentiles.

El ejemplo es el correo de una clienta: el pedido A-88412 se entregó el 28 de septiembre, se pagaron $649.00 más $52.10 de impuestos y el correo se escribió el 9 de octubre. Clairic suma por sí sola el precio y los impuestos y devuelve 701.10, y calcula que han pasado 11 días desde la entrega. Los daños (cracked screen, dented corner) se devuelven como spans exactos, que se pueden resaltar en el texto original. El correo no incluye número de seguimiento, así que el campo devuelve null con p_null = 1, y el guess ($52.10) muestra qué elegiría el modelo si no se le permitiera dejar la respuesta vacía. Su confianza en ese valor es de solo 0,416.

El mismo mecanismo funciona con la foto de un recibo tomada desde un ángulo incómodo. El modelo extrajo el número de pedido 77245, la hora de compra 2026-07-01T13:34:00, dos artículos a 7.99, un subtotal de 15.98, una propina de 2.39 y un impuesto de cero. El descuento lo devolvió, con honestidad, como null con p_null de aproximadamente 0,9994. La confianza en el número de pedido y en la hora es menor (0,78 y 0,83) que en el importe (0,99999), y es precisamente esa diferencia la que se propone usar para derivar casos a revisión manual.

Dónde cambia la economía de los pipelines

Un pipeline de extracción típico basado en LLM acumula capas: parseo, validación del esquema, reintentos y controles por muestreo. Hay que pagar por el razonamiento y por los tokens de salida de cada campo de cada documento. Además, los errores son traicioneros. El JSON puede resultar inválido, una cifra puede distorsionarse durante la generación y el fragmento encontrado no queda vinculado al original. Clairic no genera texto, así que tampoco hay cifras alteradas. Puede equivocarse, pero el error será un valor del tipo correcto con baja confidence o un intervalo amplio, no una cadena rota.

Con las estimaciones, la ventaja es aún más clara. Una LLM da un único número, y a partir de él no se distingue unos $180 seguros de unos $180 inseguros. Las categorías de un modelo de decisión son toscas, y cada una añade tokens de entrada y confusión. Un intervalo estrecho en Clairic indica confianza; uno amplio indica que el valor conviene enviarlo a una segunda revisión.

En la práctica, esto se aplica al procesamiento de facturas, recibos y solicitudes de soporte, a la estimación del coste de una reparación o de un precio a partir de ventas comparables, y al pronóstico de carga para las próximas 24 horas. En todas estas tareas, el umbral de automatización se puede fijar con una cifra, por ejemplo aceptar los valores con confidence superior a 0,95 y enviar el resto a una persona o a una LLM. Por ahora, Clairic está en preview, pero los pesos abiertos permitirán probarla con documentos propios y, posiblemente, alojarla en infraestructura propia.