OKF + RAG : une architecture hybride pour des agents IA fiables

Si vous posez à un agent IA une question portant sur un fait bien connu, il y répond avec fluidité. Cependant, si vous lui demandez la formule exacte de perte de clients de votre entreprise, le schéma d’une API interne ou le guide de gestion en cas de panne de base de données, il peut produire des réponses qui semblent plausibles mais sont entièrement inventées. C’est le problème des hallucinations, qui est l’une des principales raisons pour lesquelles les entreprises hésitent à confier des tâches réelles à ces agents.

La solution standard des deux dernières années est le RAG : on relie le modèle à une base de données vectorielle contenant les documents de l’entreprise, on récupère ce qui semble pertinent et on l’intègre dans la demande. Cela fonctionne bien pour de grandes quantités de texte non structuré. Son défaut réside dans le fait qu’il s’agit d’une méthode probabiliste : il renvoie des passages semantiquement similaires à la question, ce qui n’est pas la même chose que des passages fiables et autoritaires. Lorsque la question concerne la formule officielle de chiffre d’affaires ou les conditions d’un point de terminaison de paiement, la simple similitude n’est pas suffisante.

En juin 2026, Google Cloud a introduit le Open Knowledge Format (OKF), une spécification neutre par rapport aux fournisseurs pour des connaissances sélectionnées stockées sous forme de fichiers Markdown. En combinant ses recherches précises avec la portée étendue de RAG, on obtient une architecture qui mérite d’être envisagée pour des agents qui doivent être à la fois précis et exploratoires.

Deux types de mémoires

Imaginez un nouvel employé le premier jour. Deux éléments lui sont présentés.

Le premier est une wiki interne bien organisée : des définitions canoniques, des documents API, des formules de métriques et des guides d’opération, tous révisés, approuvés et soumis à un contrôle de version. Lorsqu’ils ont besoin de la réponse officielle, ils y cherchent. C’est là que joue le rôle de l’OKF.

Le deuxième est un moteur de recherche qui surpasse tous les autres : des milliers de messages de chat, de threads d’e-mails, de tickets de support et de transcriptions de réunions. Lorsqu’ils veulent savoir ce que les gens ont dit sur un sujet ou fouiller dans des archives non structurées, ils y effectuent des recherches. C’est cela, le RAG.

Aucun de ces deux systèmes ne suffit à lui seul. Ensemble, ils couvrent l’ensemble des connaissances d’une organisation.

Qu’est-ce que OKF ?

OKF est délibérément simple. Un bundle est un répertoire de fichiers Markdown stockés dans Git. Chaque fichier décrit un concept, tel qu’une table, une métrique, un point d’entrée API ou un guide opérationnel, et commence par un bloc de frontmatter YAML contenant des métadonnées lisible par les machines. Les spécifications imposent très peu de contraintes aux créateurs, et des outils tels que Obsidian, Notion ou MkDocs gèrent déjà ce même format de fichier. Le projet est hébergé dans un dépôt public.

Un fichier relatif à une métrique commerciale peut contenir dans son frontmatter un type, un titre, une description, le responsable, des étiquettes et une date et heure. Le corps du fichier présente ensuite la formule officielle, quelques règles (par exemple, exclure les comptes d’essai du dénominateur et ne pas considérer les downgrades de plan comme des abandons), le tableau qui sert de source fiable, ainsi que des liens vers des concepts connexes.

---
type: metric
title: "Monthly Churn Rate"
description: "Official formula for calculating monthly customer churn."
owner: "data-engineering"
tags: [revenue, kpi, board-report]
timestamp: 2026-06-20T10:00:00Z
---

# Monthly Churn Rate

The official churn rate formula used in all board reports and investor decks:

    Churn Rate = (Customers Lost During Month / Customers at Start of Month) × 100

### Rules
- **Do NOT** use trial accounts in the denominator.
- **Do NOT** count plan downgrades as churn.
- Source of truth: `analytics.monthly_churn_summary` table.

### Related
- [Monthly Active Users](mau.md)
- [Revenue Dashboard](revenue_dashboard.md)

Pourquoi se donner cette peine ?

• Aucune mathématique vectorielle. Lorsque l’agent a besoin de la formule de désabonnement, il lit directement ce fichier. Il n’y a ni embedding, ni score de similarité, ni top-k, seulement la réponse approuvée à chaque fois.
• Intégré nativement aux workflows Git. Les modifications passent par des pull requests, des revues et un historique des commits, ce qui permet de disposer d’un suivi des modifications montrant qui a changé la formule, quand et pourquoi.
• Aucune infrastructure requise. Pas de stockage vectoriel, pas de pipeline d’embedding, pas de stratégie de segmentation ni de tâche de réindexation. Les fichiers se trouvent simplement dans un dossier.

Qu’est-ce que RAG ?

RAG relie un modèle à de grandes quantités de données non structurées en six étapes :

1. Ingérer des documents tels que des PDF, des e-mails, des pages wiki et des messages de chat.
2. Les diviser en segments plus petits.
3. Embedder chaque segment en vecteur à l’aide d’un modèle d’embedding.
4. Stocker les vecteurs dans une base de données comme Pinecone, Weaviate ou pgvector.

Lors de la requête, intégrez la question dans le même espace et récupérez les fragments les plus similaires.

Ajoutez ces fragments à l’instruction afin que le modèle puisse répondre en tenant compte du contexte.

La force du RAG réside dans sa portée : il peut mettre en évidence du matériel pertinent parmi des milliers de documents que personne ne pourrait organiser manuellement. Sa faiblesse, c’est la précision. Comme c’est la similarité qui guide la récupération, il peut retourner du texte pertinent sans pour autant être fiable. Si trois approches différentes définissent légèrement le phénomène de désabonnement, le RAG risque de choisir la mauvaise.

La conception hybride

L’architecture combinée place un routeur devant les deux types de mémoires. Ce routeur examine chaque requête entrante et décide où elle doit être envoyée : vers le ensemble de documents sélectionnés lorsque la question concerne une définition officielle, ou vers la recherche vectorielle lorsqu’elle est ouverte et exploratoire.

Une version simplifiée en Python de ce routeur effectue quatre tâches. Il charge tous les fichiers Markdown du paquet et les indexe en fonction du titre présent dans le frontmatter. Il tente une correspondance déterministe des mots-clés de la requête avec ces titres. Si un concept est trouvé, le contenu est transmis en étant indiqué comme provenant de la base de connaissances officielle. Sinon, il recourt à une recherche vectorielle, étiquetée comme recherche de documents, puis envoie le contexte sélectionné au modèle avec l’instruction de ne répondre qu’à partir de ce qui lui a été fourni. L’étiquetage de la source dans l’instruction est important, car il indique au modèle, et par la suite au lecteur, le degré d’importance que doit avoir ce contexte.

from openai import OpenAI
import os
import glob
import yaml

client = OpenAI()

# 1. Load the OKF knowledge bundle from the local directory
def load_okf_bundle(bundle_path: str) -> dict:
    """Reads all Markdown files in the OKF directory into a searchable dict."""
    knowledge = {}
    for filepath in glob.glob(f"{bundle_path}/**/*.md", recursive=True):
        with open(filepath) as f:
            content = f.read()
            # Extract the title from YAML frontmatter
            if content.startswith("---"):
                _, frontmatter, body = content.split("---", 2)
                meta = yaml.safe_load(frontmatter)
                title = meta.get("title", os.path.basename(filepath))
                knowledge[title.lower()] = body.strip()
    return knowledge

# 2. Search OKF (deterministic, keyword-based)
def search_okf(query: str, okf_knowledge: dict) -> str | None:
    """Simple keyword match against OKF titles."""
    for title, content in okf_knowledge.items():
        if title in query.lower():
            return content
    return None

# 3. Search RAG (probabilistic, vector-based)
def search_rag(query: str) -> str:
    """Placeholder for your vector DB search (Pinecone, Weaviate, etc.)."""
    # results = vector_db.similarity_search(query, top_k=5)
    return "RAG context: [retrieved chunks would appear here]"

# 4. The Intelligent Router
def answer_query(query: str, okf_bundle_path: str) -> str:
    okf_knowledge = load_okf_bundle(okf_bundle_path)

    # Try OKF first (deterministic path)
    okf_result = search_okf(query, okf_knowledge)

    if okf_result:
        context = f"[SOURCE: Official Knowledge Base (OKF)]\n{okf_result}"
    else:
        # Fall back to RAG (probabilistic path)
        context = f"[SOURCE: Document Search (RAG)]\n{search_rag(query)}"

    # Send to LLM with the retrieved context
    response = client.chat.completions.create(
        model="gpt-4o",
        messages=[
            {"role": "system", "content": "Answer using ONLY the provided context."},
            {"role": "user", "content": f"Context:\n{context}\n\nQuestion: {query}"}
        ]
    )
    return response.choices[0].message.content

La correspondance ici est délibérément rudimentaire, basée sur une recherche de titre, afin de garder l’idée visible. Un système de production utiliserait un routage plus performant, comme un classificateur ou un filtre de métadonnées, et gérerait le cas où les deux sources renvoient des informations pertinentes.

En résumé

Pour les agents d’entreprise, il ne s’agit pas de choisir entre OKF et RAG. La meilleure approche consiste à utiliser les deux. Une base de connaissances déterministe, contrôlée par Git, protège les faits qui ne doivent jamais être erronés : les KPI, les contrats API et les manuels opérationnels. Une recherche vectorielle probabiliste couvre l’important volume d’archives non structurées que personne ne peut mettre en ordre. Le résultat est un agent précis lorsque la précision est essentielle, et exploratoire lorsque la découverte l’est.