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
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É. Tu décides quand (ou si) tes données de validation intègrent la matrice globale.

Quand l'utiliser

  • Tu veux prouver (pour TON équipe / TES URLs) quelles théories GEO fonctionnent réellement.
  • Tu veux valider empiriquement les signaux de niveau B de l'Engine Capability Matrix avant de construire des décisions de roadmap dessus.
  • Tu effectues des runs de validation réguliers (planification par défaut : le 17 de chaque mois à 04h00) et les utilises comme signal d'audit pour ta 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, tu vois 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) — Mets 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 ton é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

Dernière mise à jour :

Cookies : Nous utilisons uniquement des cookies strictement nécessaires (session et sécurité), ainsi qu'une analyse anonyme et sans cookies via notre propre logiciel de statistiques (Matomo, infrastructure propre) — aucun traceur marketing. Détails