Cloudflare lance Clairic, un modèle d'extraction de données sans token en sortie

Cloudflare lance en préversion Clairic, le premier modèle d'une nouvelle classe, System One extraction. Il est disponible sur Workers AI sous le nom @cf/cloudflare/clairic, et la société promet des poids ouverts dans un avenir proche. Clairic extrait des valeurs d'une entrée non structurée, les calcule, les estime et les prévoit. Il le fait en un seul passage parallèle, sans raisonnement et sans token en sortie. La réponse prend généralement moins d'une seconde, alors qu'une LLM qui raisonne sur la même étape y passe plusieurs secondes. Seule l'entrée est facturée.

Un troisième type de modèle dans la famille System One

Le concept de System One (le système rapide et précis au sens de Kahneman, par opposition au système lent, System Two, dont relèvent les LLM) a été présenté un mois plus tôt par TypeSafe avec son modèle Jev. Jev et Clef sont des modèles de décision : on leur fournit un état et une liste de questions, et ils renvoient des probabilités sur des options énumérées à l'avance. Cloudflare a repéré une lacune.

Une énorme part des appels aux LLM de pointe avec sortie structurée se résume aux mêmes questions : quel est le montant de la facture, quand la livraison a-t-elle eu lieu, combien de jours de retard, combien coûtera la réparation, quel sera le trafic dans les prochaines 24 heures. On ne peut pas dresser à l'avance la liste des réponses à ces questions, et un modèle de décision ne convient donc pas ici.

La répartition du travail est la suivante. Clairic transforme l'entrée brute en valeurs typées, Clef et Jev transforment les valeurs en décisions, et la LLM transforme les décisions en mots. L'espace de sortie de Clairic est continu, mais borné par votre schéma : chaque réponse est soit une valeur du type déclaré, soit null.

À quoi ressemble une requête et ce qu'elle renvoie

Une requête se compose d'un state (du texte plus jusqu'à quatre images) et d'une carte de champs typés. Chaque champ reçoit un nom, un type et une instruction facultative en langage courant. Si les champs ne tiennent pas avec l'entrée dans un seul passage, le serveur les répartit lui-même en passages parallèles, chacun voyant l'intégralité de l'entrée, puis recolle les réponses. C'est pourquoi trente champs coûtent à peu près autant que trois.

Types pris en charge :

• text : un fragment de l'entrée avec décalages de caractères (span) • number : un nombre lu ou calculé, en tenant compte des paramètres integer et decimals • date, time, datetime : dates calendaires et heures valides au format ISO • duration : une durée dans l'unité choisie • list : une liste de textes, de nombres ou de dates, dans l'ordre d'apparition dans l'entrée • estimate : une distribution dans vos bornes [min, max] sur une grille donnée, linéaire ou logarithmique • forecast : une estimation pour chaque pas futur de la série, chacune avec son propre intervalle à 80 %

Chaque réponse scalaire arrive avec p_null (la probabilité que la valeur ne figure pas dans l'entrée) et confidence. Les estimations comportent une médiane et un intervalle p10–p90, et les 99 percentiles sont renvoyés sur demande.

Prenons l'exemple du courriel d'une cliente : commande A-88412 livrée le 28 septembre, $649.00 payés plus $52.10 de taxe, courriel écrit le 9 octobre. Clairic additionne elle-même le prix et la taxe pour obtenir 701.10, et calcule à 11 le nombre de jours écoulés depuis la livraison. Les dommages (cracked screen, dented corner) sont renvoyés sous forme de spans exacts, que l'on peut surligner dans le texte source. Le courriel ne contient pas de numéro de suivi : le champ renvoie donc null avec p_null = 1, tandis que le guess ($52.10) indique ce que le modèle aurait choisi s'il n'avait pas le droit de répondre par du vide. Sa confiance n'y est que de 0,416.

Le même mécanisme fonctionne sur la photo d'un ticket de caisse prise sous un angle peu pratique. Le modèle a extrait le numéro de commande 77245, l'heure d'achat 2026-07-01T13:34:00, deux articles à 7.99, un sous-total de 15.98, un pourboire de 2.39 et une taxe nulle. Il a renvoyé la remise comme null, avec un p_null d'environ 0,9994. Sa confiance dans le numéro de commande et dans l'heure est plus faible (0,78 et 0,83) que dans le montant (0,99999). C'est précisément cet écart qu'on propose d'utiliser pour router vers une vérification manuelle.

Où cela change l'économie des pipelines

Un pipeline d'extraction classique reposant sur une LLM s'alourdit de couches successives : parsing, validation du schéma, nouvelles tentatives, contrôle par échantillonnage. Il faut payer le raisonnement et les tokens de sortie pour chaque champ de chaque document. Les erreurs sont en outre sournoises : le JSON peut être invalide, un chiffre peut se déformer pendant la génération, et le fragment trouvé n'est pas rattaché à la source. Clairic ne génère rien, donc aucun chiffre ne peut muter. Elle peut se tromper, mais l'erreur prendra la forme d'une valeur du bon type avec un confidence faible ou un intervalle large, et non celle d'une chaîne cassée.

Avec les estimations, le gain est encore plus net. Une LLM donne un seul nombre, qui ne permet pas de distinguer un $180 sûr d'un $180 incertain. Les tranches d'un modèle de décision sont grossières, et chacune ajoute des tokens d'entrée et de la confusion. Chez Clairic, un intervalle étroit signale la confiance, un intervalle large indique que la valeur mérite une seconde vérification.

En pratique, cela donne : analyse de factures, de tickets de caisse et de demandes au support, estimation du coût d'une réparation ou d'un prix d'après des ventes comparables, prévision de la charge sur les 24 prochaines heures. Pour toutes ces tâches, le seuil d'automatisation peut se fixer par un chiffre, par exemple accepter les valeurs dont le confidence dépasse 0,95 et envoyer le reste à un humain ou à une LLM. Clairic n'est pour l'instant qu'en préversion, mais les poids ouverts permettront de la tester sur vos propres documents et, peut-être, de l'héberger chez soi.