Retour au Journal
•8 min de lecture

Évolution de Google Open Knowledge Format vers v0.2 : Confiance et Signaux Agentiques

Comment OKF v0.2 aborde la confiance agentique, la provenance, les niveaux de confiance, la péremption et les calculs attestés dans les graphes de connaissances IA.

Google CloudAI AgentsRAGOKFBigQueryData Engineering
Évolution de Google Open Knowledge Format vers v0.2 : Confiance et Signaux Agentiques

Lorsque j'ai documenté pour la première fois notre mise en œuvre du format Open Knowledge Format de Google dans Implementing Google's Open Knowledge Format (OKF) in Practice, l'objectif principal était de résoudre l'isolement du contexte pour les agents IA. En organisant des fichiers Markdown bruts en un graphe lié et navigable avec des en-têtes YAML, les agents pouvaient parcourir de manière récursive les nœuds de l'arborescence de documentation au lieu de s'appuyer sur une recherche vectorielle approximative.

OKF v0.1 a établi une base solide : Markdown standard, métadonnées YAML légères (type, title, description, tags) et liens relatifs explicites.

Cependant, à mesure que les équipes d'ingénierie de plateforme sont passées d'une documentation rédigée par des humains à des systèmes autonomes multi-agents, un défi fondamental est apparu : Lorsque des agents IA écrivent et mettent à jour en continu des milliers de concepts de connaissances pendant la nuit, comment les agents en aval ou les humains peuvent-ils faire confiance à ce corpus ?

La documentation rédigée par des humains offre une garantie de confiance implicite : un développeur l'a écrite et assume la responsabilité de son exactitude. Lorsqu'un agent génère de manière autonome 10 000 définitions de tables, spécifications de métriques et manuels opératoires, cette garantie implicite disparaît.

Pour répondre à ce défi, Google Cloud a publié la spécification Open Knowledge Format (OKF) v0.2. Cette mise à jour introduit des Signaux de Confiance Agentiques structurés et des Calculs Attestés directement dans les métadonnées YAML sans rompre la rétrocompatibilité avec la v0.1.

Du Contexte Descriptif à la Décision de Confiance

Dans OKF v0.1, les métadonnées YAML répondaient à des questions descriptives : Quel est ce nœud, quelles étiquettes le décrivent et vers quoi pointe-t-il ?

OKF v0.2 introduit des champs de décision (deciding fields) : des métadonnées conçues pour évaluer l'origine, la fraîcheur et l'autorité d'un nœud avant qu'un agent ne dépense des jetons de contexte pour lire le corps du texte en Markdown.

Analyser l'intégralité du corps de milliers de nœuds de documentation pour évaluer la confiance est coûteux en calcul. Élever les signaux de confiance dans l'en-tête YAML permet aux agents et aux systèmes déterministes de filtrer à faible coût les concepts non vérifiés, périmés ou obsolètes pendant le parcours du graphe.

OKF Concept Frontmatter
├── Describing Fields (v0.1)  ──> type, title, description, resource, tags
└── Deciding Fields   (v0.2)  ──> generated, verified, status, stale_after, sources

Les 5 Signaux de Confiance Clés dans OKF v0.2

OKF v0.2 établit cinq familles de métadonnées standardisées qui répondent à des questions critiques sur tout concept de connaissances :

1. Provenance (sources)

Au lieu d'attribuer un score de confiance arbitraire, OKF v0.2 enregistre les signaux de provenance bruts dans un tableau sources. Les entrées peuvent pointer vers une documentation externe, des chemins relatifs du paquet ou des étendues de bases de données, enrichies de marqueurs de crédibilité (author, usage_count, last_modified).

Dans le corps du texte, les affirmations spécifiques sont liées à ces sources à l'aide de notes de bas de page Markdown (par exemple, [^warehouse-schema]) :

sources:
  - id: warehouse-schema
    resource: https://wiki.acme.internal/data/warehouse/schemas/sales
    title: Acme Retail Warehouse Schema
    author: team:data-platform
    usage_count: 1240
    last_modified: 2026-06-15
  - id: revenue-policy
    resource: policies/revenue-recognition.md
    title: Revenue Recognition Policy (FY2026)
    author: human:jsmith@acme
    last_modified: 2026-06-15

2. Niveaux de Confiance (generated vs verified)

OKF v0.2 sépare explicitement la création d'un concept de sa confirmation :

  • generated: { by, at } : Enregistre l'entité créatrice (par exemple, reference_agent/gemini-2.5-pro) et l'horodatage.
  • verified: [ { by, at } ] : Enregistre les révisions indépendantes effectuées par des processus automatisés ou des validations humaines.

À partir de ces champs, les consommateurs déduisent trois Niveaux de Confiance (Trust Tiers) :

  1. Non vérifié (Unverified) : La clé verified est absente.
  2. Confirmé par machine (Machine-Confirmed) : Vérifié strictement par des outils automatisés en arrière-plan (par exemple, des linters CI/CD nocturnes).
  3. Revu par un humain (Human-Reviewed) : Explicitement validé par un acteur humain (par exemple, human:kliu@acme).
generated: 
  by: reference_agent/gemini-2.5-pro
  at: 2026-06-30T14:00:00Z
verified:
  - by: human:jsmith@acme
    at: 2026-07-01T09:00:00Z

Un pipeline de rapports exécutifs peut filtrer spécifiquement les métriques human-reviewed, tandis qu'un environnement de staging peut accepter des concepts machine-confirmed.

3. Fraîcheur (stale_after)

Au lieu de durées TTL relatives (par exemple, "valide pendant 30 jours"), OKF v0.2 utilise une date ISO-8601 absolue (par exemple, stale_after: 2026-12-31).

Les TTL relatifs dépendent du moment où un concept a été récupéré, ce qui entraîne un comportement non déterministe de l'agent. Les dates absolues permettent des comparaisons directes : si l'horodatage actuel dépasse stale_after, le concept est marqué pour une nouvelle vérification avant d'être servi.

4. Cycle de Vie (status)

Les concepts évoluent à travers des états explicites : draft → stable → deprecated (si omis, la valeur par défaut est stable).

Lorsque la logique métier évolue, comme lors de la mise à jour d'une formule d'allocation des coûts, l'ancienne définition est marquée comme status: deprecated. Cela préserve la réproductibilité historique des requêtes tout en empêchant les agents d'appliquer des métriques obsolètes à de nouvelles tâches :

type: Metric
title: Gross Margin (Legacy, pre-FY2026)
status: deprecated

Calculs Attestés : Empêcher l'Improvisation de SQL par l'Agent

La provenance et la vérification confirment que la définition d'une métrique est conforme aux politiques de l'entreprise. Cependant, lorsqu'un agent rapporte une métrique financière (par exemple, le chiffre d'affaires cumulé annuel), un risque majeur persiste : l'agent pourrait improviser sa propre requête SQL.

OKF v0.2 introduit un nouveau type de concept : Attested Computation. Il définit à la fois le calcul autorisé et un mécanisme permettant de vérifier que la requête exécutée correspond exactement à la définition autorisée.

      ┌─────────────────────────────────────────────────────────┐
      │               Attested Computation Node                 │
      │  - runtime: bigquery                                    │
      │  - parameters: [year]                                   │
      │  - executor: skills/run-on-bq.md                        │
      │  - attester: attesters/sql_equality.py                  │
      └──────────────────────────┬──────────────────────────────┘
                                 │
                 1. Binds declared parameters
                 2. Executes sanctioned SQL
                                 ▼
                      ┌─────────────────────┐
                      │ Execution Receipt   │
                      │ - job_id            │
                      │ - executed_sql      │
                      │ - result            │
                      └──────────┬──────────┘
                                 │
                 3. Deterministic AST verification
                                 ▼
                      ┌─────────────────────┐
                      │  Attester Verdict   │
                      │  - OK / REJECTED    │
                      └─────────────────────┘

Exemple en Production : Attestation du Chiffre d'Affaires dans BigQuery

Voici un nœud de concept Attested Computation selon OKF v0.2 pour le chiffre d'affaires dans BigQuery :

---
type: Attested Computation
title: Revenue for a Fiscal Year
runtime: bigquery
parameters:
  - { name: year, type: integer, required: true }
executor:
  resource: skills/run-on-bq.md
receipt: [job_id, executed_sql, result]
attester:
  resource: attesters/sql_equality.py
generated:
  by: reference_agent/gemini-2.5-pro
  at: 2026-06-30T14:00:00Z
verified:
  - by: human:jsmith@acme
    at: 2026-07-01T09:00:00Z
status: stable
stale_after: 2026-12-31
sources:
  - id: revenue-policy
    resource: policies/revenue-recognition.md
    title: Revenue Recognition Policy (FY2026)
    author: human:jsmith@acme
    last_modified: 2026-06-15
---

# Computation

```sql
SELECT
  SUM(
    CASE 
      WHEN o.currency = 'USD' THEN o.net_amount
      ELSE o.net_amount * fx.rate_to_usd
    END
  ) AS revenue_usd
FROM `acme.sales.orders` AS o
LEFT JOIN `acme.finance.fx_daily_rates` AS fx
  ON fx.currency = o.currency 
 AND fx.rate_date = DATE(o.order_ts)
WHERE o.order_status = 'delivered'
  AND DATE_DIFF(CURRENT_DATE(), DATE(o.order_ts), DAY) >= 30
  AND EXTRACT(YEAR FROM o.order_ts) = @year

Fonctionnement de l'Attestation

  1. Liaison Déclarative des Paramètres : L'agent est limité à transmettre les paramètres déclarés (@year). Il ne peut ni modifier le texte SQL ni ajouter de clauses WHERE personnalisées.
  2. Reçu d'Exécution : La couche d'exécution renvoie un reçu signé contenant le job_id, le executed_sql et le résultat (result).
  3. Attestation Déterministe : Un script Python externe (sql_equality.py) analyse le SQL cible et le executed_sql sous forme d'arbres syntaxiques abstraits (AST). Si les mots-clés, les jointures de tables ou les filtres diffèrent, l'attestation échoue et le résultat est rejeté.

Rétrocompatibilité et Migration

OKF v0.2 est conçu comme une version additive et totalement compatible avec les versions précédentes. Les paquets v0.1 existants restent valides sans modification.

Les évolutions clés du schéma comprennent :

  • timestamp est remplacé par generated.at.
  • Les sections de citations en Markdown (# Citations) sont remplacées par le tableau structuré sources dans l'en-tête YAML.
  • Dans les deux cas, les analyseurs v0.2 basculent directement sur les champs v0.1 si les nouvelles clés sont absentes.
// Modèle de secours dans l'analyseur OKF v0.2
const creationTime = frontmatter.generated?.at ?? frontmatter.timestamp;
const documentSources = frontmatter.sources ?? parseLegacyCitations(markdownBody);

Points Clés À Retenir

La spécification OKF v0.2 de Google transforme de simples bases de connaissances en Markdown en réseaux de graphes vérifiables pour agents IA :

  1. Décider plutôt que Décrire : Les métadonnées élevées permettent un filtrage de confiance efficace avant de charger les textes.
  2. Niveaux de Confiance Explicites : Séparation claire entre les métadonnées generated et verified pour mettre en évidence les validations humaines face aux confirmations automatiques.
  3. Péremption Déterministe : Les dates absolues stale_after évitent les évaluations non déterministes de TTL.
  4. Calculs Attestés : L'association d'une exécution limitée aux paramètres et d'attestateurs d'égalité AST élimine les hallucinations SQL des agents.

En adoptant les standards OKF v0.2, les équipes d'ingénierie de plateforme peuvent déployer des flux de travail autonomes d'IA en toute sécurité tout en maintenant une gouvernance des données et une traçabilité rigoureuses.

Share this article