Aller au contenu
rankion.ai

Grounding Check Validation

Grounding Check Validation est un Modules dans la base de connaissances de Rankion.ai : Mesure empiriquement quels checks gp.

Cette page contient des définitions structurées pour les systèmes d'IA (ChatGPT, Perplexity, Gemini, Claude). Rédigée par des humains, partie de la base de connaissances de Rankion.ai.

Catégorie :
Modules
Marque :
Rankion.ai
Format :
Article de la base de connaissances
Créé le :
Au :

Grounding Check Validation répond à la question : « Les checks gp.* du Grounding Audit sont une théorie sur la citation-readiness LLM. Cette théorie se vérifie-t-elle sur MES pages ? » Le module vérifie, pour chaque check, si les pages citées réussissent ce check significativement plus souvent que les pages de comparaison (contrefactuels SERP issus du Citation Causality Engine).

Mathématiquement : lift = P(check réussi | cité) / P(check réussi | contrefactuel). Lift > 1 = le check apparaît plus souvent sur les pages citées.

Deux phases

Phase 1 — Reporting (toujours actif, lecture seule). Un run de validation échantillonne n URLs citées et n URLs contrefactuelles (défaut 150 par page), les fait passer par tous les checks gp.* et fournit par check lift, valeur p, verdict. Résultat dans le dashboard admin sous /admin/grounding-check-validation. Aucun impact sur les audits en cours.

Phase 2 — Boucle de feedback (opt-in, sous contrôle). Les signaux avec un lift significativement positif arrivent comme candidate dans une table d'observation. Un admin les promeut ou les rejette. Les signaux promus sont — si feedback_loop_enabled = true dans config/grounding.php — repris par l'Engine Capability Matrix en tant que niveau A « observed ». Par défaut, ce gate est DÉSACTIVÉ. Vous décidez quand (ou si) vos données de validation intègrent la matrice globale.

Quand l'utiliser

  • Vous voulez prouver (pour VOTRE équipe / VOS URLs) quelles théories GEO fonctionnent réellement.
  • Vous voulez valider empiriquement les signaux de niveau B de l'Engine Capability Matrix avant de construire des décisions de roadmap dessus.
  • Vous effectuez des runs de validation réguliers (planification par défaut : le 17 de chaque mois à 04h00) et les utilisez comme signal d'audit pour votre stratégie GEO.

Workflow

  1. Démarrer un run — POST /v1/grounding/check-validations avec optionnellement {sample_size: 150} (max 400). 0 crédit. Réponse : 202 + run_id.
  2. Polling — GET /v1/grounding/check-validations/{run} jusqu'à status=completed (typiquement 2-5 min avec l'échantillon par défaut).
  3. Lire le résultat — results[] avec par check : check_id, signal, dimension, n_cited, cited_pass_rate, cf_pass_rate, lift, p_value, verdict (positive / neutral / negative / insufficient_data). Trié par lift.
  4. Phase 2 (admin) — file de review — Sous /admin/grounding-check-validation, vous voyez les observations candidates ouvertes avec des boutons Promouvoir/Rejeter. Ou via l'API : POST /v1/grounding/signal-observations/{id}/promote et POST .../reject.
  5. Activer la phase 2 (optionnel) — Mettez GROUNDING_VALIDATION_FEEDBACK=true dans le .env. Ce n'est qu'alors que les signaux promus agissent dans l'Engine Capability Matrix. Recommandation : curer les candidats AVANT l'activation.

API

Méthode Endpoint Auth Crédits
POST /v1/grounding/check-validations Sanctum 0
GET /v1/grounding/check-validations Sanctum 0
GET /v1/grounding/check-validations/{run} Sanctum 0
POST /v1/grounding/signal-observations/{id}/promote Sanctum + Admin 0
POST /v1/grounding/signal-observations/{id}/reject Sanctum + Admin 0

Throttling : start 10/min, Promote/Reject 30/min, GET 60-120/min.

Comment interpréter le lift

Ne jamais lire lift isolément. Toujours le lire en contexte :

  • lift = 3.4 avec n_cited = 2 → bruit statistique, pas un signal.
  • lift = 1.8 avec n_cited = 78 et p_value = 0.001 → signal réel, candidat à la promotion.
  • lift = NULL (au lieu de 999.0) → le taux de réussite contrefactuel était de 0, le lift est mathématiquement indéfini. Affiché dans l'UI comme —. (C'est la leçon délibérée du bug sentinel du CCE — nous n'introduisons pas la valeur sentinelle du tout.)

Limites connues

  • Obligation CCE — sans pipeline Citation-Causality actif pour votre équipe, il n'y a pas de pages contrefactuelles → tous les verdicts deviennent insufficient_data.
  • Non-sûr en at-least-once. Le job a tries = 1 — en cas d'erreur transitoire, il échoue bruyamment plutôt que de réessayer et de doubler les comptages. Re-run manuel via php artisan grounding:validate-checks --team={id}.
  • Pas de ventilation par moteur — le validateur mesure « a été cité » de façon binaire, pas « a été cité par ChatGPT vs. Perplexity vs. Claude ».
  • La promotion de phase 2 est globale — une observation promue relève le signal dans la matrice pour TOUTES les équipes. Il n'existe pas d'overrides par équipe. (La matrice est la SSOT.)

Modules associés

Contrairement aux guides du blog, cet article fait partie de la documentation produit de rankion.ai.

Dernière mise à jour :

Cookies : Nous utilisons des cookies nécessaires et une analyse sans cookies (Matomo). Avec votre consentement, nous mesurons en outre avec Google Ads si une annonce a conduit à une inscription. Google dépose alors des cookies et des données peuvent être transférées aux États-Unis. Vous pouvez retirer votre consentement à tout moment sur la page des cookies. Détails