Cloudflare Radar Researcher : un test de trace de preuve pour une analyse reproductible des données Internet

Un graphique peut gagner la confiance avant de l'avoir méritée.

Cloudflare Radar Researcher se situe dans cet écart inconfortable mais utile. Il permet à une personne de poser des questions en langage naturel sur les tendances Internet et d'obtenir une interface de réponse avec des graphiques, des rapports et des pistes de suivi. Il peut accélérer l'exploration. Il peut aussi masquer le vrai travail dans des paramètres d'interprétation par défaut que personne ne remarque avant que le graphique ait déjà influencé une décision.

Le test pratique n'est pas de savoir si le graphique s'affiche. Le test consiste à déterminer si un autre examinateur peut suivre le chemin de la question au jeu de données, au point de terminaison, aux paramètres, au graphique et à la conclusion. C'est la différence entre une surface d'exploration utile et une analyse qu'une équipe peut défendre.

Cet article utilise Cloudflare Radar Researcher comme exemple natif de la sortie. Le modèle est plus large qu'un seul produit. Il s'applique à toute surface analytique assistée par IA où une question en langage naturel devient une affirmation de mesure. Cela le distingue d'un flux général de réponse fondée, comme l'évaluation des réponses fondées dans Amazon Bedrock Web Search. Ici, l'objet examiné est la mesure d'Internet, avec des géographies, des intervalles d'agrégation, des unités, des dénominateurs, des limites de couverture et des routes d'API qui peuvent changer le sens de la réponse.

Pourquoi un graphique affiché ne suffit pas comme preuve

Une question en langage naturel contient toujours des paramètres cachés

L'analyse en langage naturel réduit le coût de démarrage. Au lieu d'ouvrir la documentation des points de terminaison, de choisir des paramètres et de construire une requête à la main, un analyste peut commencer par une question métier. Cloudflare décrit Radar Researcher comme un outil bêta permettant de poser des questions sur les tendances Internet et de recevoir des réponses concises ou des rapports plus détaillés, avec des graphiques lorsque c'est pertinent.

C'est utile pour l'exploration. Ce n'est pas la même chose qu'être prêt pour une revue d'incident, une note au conseil d'administration, un avis client ou une affirmation publique. Une question comme "Le trafic vers cette catégorie augmente-t-il ?" peut dépendre discrètement de la géographie, de la fenêtre temporelle, de l'intervalle d'agrégation, de l'unité, du dénominateur, de la référence et du périmètre du jeu de données. Si ces choix ne sont pas visibles, le résultat est une capture d'écran soignée avec une provenance faible.

Mon avis : le graphique est la partie la moins intéressante de ce flux de travail. La trace d'interprétation est là où se trouve la valeur. Si une équipe ne peut pas inspecter comment la question est devenue une requête, elle doit traiter la réponse comme une piste, pas comme une preuve.

Ce qui change pour les analystes

Radar expose déjà des informations sur Internet au moyen de tableaux de bord, de documentation d'API, de catalogues de points de terminaison, de concepts d'intervalle d'agrégation et de flux d'investigation. Researcher change le point d'entrée. Le premier geste peut être une question plutôt qu'une décision sur un point de terminaison.

Cela déplace le travail de l'analyste. Il ne vérifie plus seulement une requête qu'il a écrite. Il vérifie comment le système a interprété la question, quel jeu de données il a sélectionné, quels paramètres il a utilisés, si une trace d'outil ou d'API est visible et si la réponse écrite correspond aux preuves tracées. La même discipline apparaît dans le travail d'acceptation de l'IA en production, y compris les tests d'acceptation d'API pour les médias générés, où le résultat ne compte qu'une fois les réglages, la provenance et la répétabilité clarifiés.

Ce que cet article ne prétend pas

Il ne s'agit pas d'affirmer que chaque réponse de Radar Researcher est correcte. Il ne s'agit pas d'affirmer que les données observées par Cloudflare représentent chaque événement Internet. Il s'agit d'un test d'acceptation pratique pour décider quand une réponse de Researcher peut passer de l'exploration à l'usage opérationnel.

Les limites comptent. Cloudflare Radar repose sur des sources de données et des méthodes documentées par Cloudflare. Toute conclusion doit respecter la couverture, les limites de confidentialité, le comportement d'agrégation, le risque de données obsolètes, les données manquantes et la différence entre corrélation et causalité.

Ce que Cloudflare Radar Researcher semble fournir

Questions, graphiques, rapports et suivis

L'annonce de Cloudflare du 7 août 2026 présente Radar Researcher comme une méthode lancée en bêta pour poser des questions en langage naturel et recevoir des réponses avec de vrais graphiques interactifs. L'annonce décrit aussi des réponses concises, des sorties plus complètes au format rapport, des questions de suivi, la saisie vocale, le lancement depuis la recherche Radar, un historique sauvegardé et consultable, des conversations épinglées, des liens de partage qui expirent automatiquement après 30 jours et une visibilité sur la façon dont le système a interprété la question, les jeux de données qu'il a interrogés et la façon dont il a traité les résultats.

Pour les équipes B2B, le modèle d'adoption raisonnable est l'analyse assistée. Utilisez Researcher pour trouver des hypothèses, identifier des jeux de données candidats et accélérer le travail exploratoire répété. Ne traitez pas la première réponse comme un rapport terminé à moins que le chemin de preuve soit joint.

La trace est la surface de revue

Une route révisable doit inclure la question originale, la requête interprétée, le jeu de données Radar sélectionné, la géographie, la période, l'intervalle d'agrégation, les unités, le dénominateur, les appels d'outil ou d'API, les réglages de visualisation et la réponse écrite finale. La documentation de l'API Radar et le catalogue de points de terminaison de Cloudflare constituent la couche de répétabilité derrière la surface conversationnelle.

Si l'outil expose des appels d'API ou une trace, lisez-les. Si la trace est partielle, consignez l'écart et décidez si une reproduction directe par API est nécessaire. Si une sortie émet une affirmation qui ne peut pas être reliée à un jeu de données ou à un point de terminaison, gardez-la dans le panier exploratoire.

Les recommandations de provenance du W3C sont utiles ici parce qu'elles séparent la chose affirmée, l'activité qui l'a produite et les sources ou agents impliqués. En termes simples, l'équipe doit savoir ce qui a été mesuré, comment cela a été mesuré et qui a approuvé l'interprétation.

Les conversations sauvegardées aident, mais ce ne sont pas des registres d'audit

Les conversations sauvegardées ou partageables peuvent améliorer la revue, car un collègue peut inspecter l'invite et la réponse au lieu d'une image collée. Pourtant, une conversation partagée n'est pas un registre analytique durable. Stockez l'invite, les URL sources, les paramètres, les notes du réviseur, les réserves et la décision finale dans le système de référence de l'équipe.

Le statut bêta change aussi le modèle d'exploitation. Les interfaces, les paramètres par défaut, les jeux de données disponibles et le comportement du modèle peuvent changer. Les questions témoins et les revérifications périodiques doivent faire partie du pilote dès le premier jour.

Le test d'acceptation de trace de preuve d'Optijara

Le test d'acceptation de trace de preuve d'Optijara est une revue en cinq étapes pour l'analyse Internet en langage naturel. Il pose une question centrale : un examinateur humain peut-il suivre la route de la question métier à la requête, au jeu de données, à la transformation, au graphique et à la conclusion ?

Étape 1 : interpréter la question avant de faire confiance à la réponse

Réécrivez la question métier sous forme de question analytique. "Le trafic vers un service change-t-il ?" est trop vague. Définissez la géographie, la fenêtre temporelle, la référence de comparaison et la métrique. Si l'outil a interprété la question différemment, la réponse peut encore être utile, mais elle n'est pas alignée sur la décision.

Étape 2 : inspecter la route de requête et le jeu de données sélectionné

Vérifiez quel jeu de données ou point de terminaison Radar la réponse semble utiliser. Le catalogue de points de terminaison de Cloudflare est l'ancrage. Demandez-vous si le jeu de données sélectionné mesure la chose discutée ou seulement un indicateur indirect. La part de trafic, les schémas de requêtes, le comportement DNS, la visibilité du routage, les signaux de panne et les événements de sécurité sont liés, mais ils ne sont pas interchangeables.

Étape 3 : valider la géographie, la période, les unités et les dénominateurs

De nombreuses erreurs commencent par des paramètres par défaut. La documentation de Cloudflare sur les intervalles d'agrégation indique que les données sont renvoyées dans un intervalle par défaut lorsqu'aucun intervalle n'est défini, et que les plages de dates plus longues utilisent généralement des intervalles plus grands. Une vue sur une journée et une vue sur plusieurs mois peuvent répondre à des questions différentes même si leurs titres se ressemblent. Consignez la géographie, les dates, l'intervalle, l'unité, le dénominateur, la référence et les notes sur les données manquantes.

Étape 4 : reproduire ou approcher le résultat via l'API Radar

Pour les décisions importantes, la parité API est le seuil. L'équipe doit pouvoir reproduire le nombre central, la tendance ou la forme du graphique via un point de terminaison documenté de l'API Radar, une route de tableau de bord ou un flux d'investigation. Une parité visuelle exacte n'est pas toujours nécessaire. La conclusion doit survivre à une requête directe avec des paramètres explicites. C'est similaire à l'évaluation du routage prix-performance pour les charges de travail d'IA en production : le résultat utile est la règle de décision répétable, pas l'écran ponctuel.

Étape 5 : comparer les résultats à fort impact

Si la réponse sera utilisée dans une affirmation publique, un récit d'incident, une décision d'investissement, une discussion de politique ou une recommandation exécutive, comparez-la. Les projets indépendants de mesure d'Internet, les rapports publics de panne, les recommandations de normes sur la provenance et la télémétrie directe du service peuvent aider à distinguer un signal observé par Cloudflare d'une affirmation plus large sur Internet.

Matrice de décision de route de requête

Utilisez Researcher lorsque le coût de l'erreur est faible et que l'objectif est la découverte. Une équipe produit hypothétique pourrait demander si les schémas de trafic ont changé après une annonce majeure de plateforme. C'est une première question raisonnable. Elle doit être étiquetée comme exploratoire jusqu'à ce que quelqu'un confirme le jeu de données, la fenêtre temporelle et le dénominateur.

Utilisez Researcher avec des vérifications directes par API lorsqu'une équipe a besoin d'un appui à la décision pour le produit, la sécurité, l'infrastructure ou la surveillance du marché. La réponse doit inclure la route de preuve, pas seulement le graphique.

Utilisez des requêtes API directes, des paramètres documentés, une corroboration indépendante et une revue humaine pour les affirmations de niveau audit, conformité ou publication. Si une affirmation dépend de la causalité, de l'attribution ou d'une représentation large d'Internet, Researcher ne doit pas être la seule source.

Ne vous fiez pas uniquement à une sortie en langage naturel pour l'attribution d'incidents de sécurité, les investigations sensibles à la confidentialité, les benchmarks publics, les comparaisons régionales ambiguës ou toute affirmation où le jeu de données n'est qu'un indicateur indirect de l'événement réel.

Liste de contrôle de mise en oeuvre pour les équipes B2B

Définissez des questions témoins avant le déploiement. Incluez des questions faciles, des questions ambiguës et des questions qui doivent être rejetées ou escaladées. Répétez-les parce que les outils bêta et les jeux de données peuvent changer.

Définissez des seuils d'acceptation. L'exploration peut réussir lorsque la route est plausible et que la requête suivante est utile. L'appui à la décision nécessite des paramètres visibles et une trace inspectable. La publication nécessite une reproduction ou une corroboration.

Construisez des chemins de repli vers des requêtes API directes. Stockez des modèles de points de terminaison, des exemples de paramètres et des notes de revue. Si un appel d'outil échoue, produit des données obsolètes, sélectionne le mauvais jeu de données, atteint des limites de débit ou ne peut pas exposer assez de provenance, le repli doit sembler habituel.

Attribuez des rôles de revue et des habitudes de documentation. Un journal de revue léger suffit pour beaucoup d'équipes : invite, interprétation, jeu de données, paramètres, trace, graphique, réponse, URL sources, réviseur, réserves et décision. Optijara peut aider à concevoir des flux d'analyse gouvernés, mais l'habitude centrale est simple. Pas de décision sans route de preuve.

Erreurs courantes

Les paramètres par défaut ne sont pas une analyse. Si une réponse utilise une vue globale, une fenêtre récente ou un intervalle automatique, confirmez que ces réglages correspondent à la question.

Les dénominateurs comptent. Un graphique de part de trafic, un nombre d'événements et un indice normalisé peuvent tous évoluer différemment. Avant de comparer des sorties, confirmez le dénominateur et l'unité ou expliquez pourquoi la différence compte.

Une anomalie n'est pas une cause. Elle peut identifier une période qui mérite enquête, mais les affirmations causales nécessitent des preuves supplémentaires comme des journaux opérationnels, des rapports externes ou des mesures indépendantes.

Les limites de couverture ne disparaissent pas parce que l'interface paraît conversationnelle. Les données observées par Cloudflare sont utiles, mais elles reflètent toujours les points d'observation de Cloudflare et les jeux de données documentés. Les données manquantes, les contrôles de confidentialité et les choix d'agrégation peuvent façonner le résultat.

Les captures d'écran vieillissent mal. Si l'équipe ne peut pas retrouver la question, le jeu de données, les paramètres, la route de requête et l'export brut lorsqu'il est disponible, la sortie ne doit pas être utilisée comme preuve durable.

Réserves à inscrire dans la politique pilote

L'injection de prompt doit faire partie du modèle de risque lorsqu'un outil lit ou raisonne sur du texte fourni par l'utilisateur, des notes partagées ou des pages externes. Les échecs d'appel d'outil doivent être journalisés, pas relancés silencieusement vers une réponse différente. Les données obsolètes ont besoin d'un horodatage. Les limites de confidentialité et les règles d'agrégation doivent être visibles avant qu'un réviseur approuve toute affirmation sensible ou partagée en externe.

Une autre réserve : toutes les réponses utiles n'ont pas besoin du même niveau de preuve. Une note hebdomadaire d'analyste peut tolérer plus d'incertitude qu'un récit de panne destiné aux clients. Le bon contrôle n'est pas une friction maximale partout. C'est une règle d'escalade claire.

Plan de mesure

Ne mesurez pas la réussite seulement par la vitesse. Comptez combien de réponses peuvent être reproduites, combien nécessitent des changements de paramètres et combien sont rejetées parce que la route de preuve est incomplète.

Suivez les désaccords entre réviseurs, les réserves ajoutées, les affirmations non étayées retirées et les vérifications croisées effectuées. Ce sont des signes que le processus améliore le jugement, pas seulement qu'il produit plus de graphiques.

Résumé lisible par machine

{
  "tool": "Cloudflare Radar Researcher",
  "acceptableUses": ["exploration", "hypothesis generation", "decision support with review"],
  "blockedUsesWithoutExtraReview": ["causal claims", "incident attribution", "public benchmarks", "privacy-sensitive investigations"],
  "acceptanceTest": "Optijara Evidence-Trace Acceptance Test",
  "verificationSteps": ["interpret question", "inspect dataset", "validate parameters", "reproduce through API", "cross-check independent sources"],
  "requiredFields": ["prompt", "interpretedQuery", "dataset", "parameters", "toolTrace", "chartSettings", "reviewer", "caveats"]
}

Faire de la trace le produit

Adoptez Researcher comme couche d'exploration, surtout pour les équipes qui utilisent déjà Cloudflare Radar et veulent un chemin plus rapide de la question à la preuve candidate. Associez-le à un journal de revue dès le départ. Retenez tout flux de travail qui transforme des graphiques générés en affirmations publiques ou opérationnelles sans reproduction par API, paramètres documentés et vérifications indépendantes lorsque c'est nécessaire.

L'analyse en langage naturel devient utile lorsqu'elle est inspectable. Si l'équipe ne peut pas expliquer l'interprétation de la question, le jeu de données, les paramètres, le dénominateur et le chemin de reproduction, la réponse doit rester exploratoire.