OKF vs RAG : pourquoi structurer le contexte avant de le retrouver

La confusion fréquente : OKF ne remplace pas le RAG

La confusion vient du fait que les deux sujets parlent de contexte. Le RAG ajoute des informations externes dans la réponse d'un modèle. OKF organise ces informations avant qu'elles soient recherchées, injectées ou utilisées par un agent.

OKF n'est pas un vector store, pas un moteur d'embeddings, pas une API de file search et pas un framework de retrieval. C'est un format de représentation: fichiers Markdown, frontmatter YAML, concepts, liens, citations et conventions de bundle.

La bonne comparaison n'est donc pas `OKF ou RAG`. La bonne question est: dans quel état se trouve le corpus que mon RAG va interroger ? S'il est dispersé, ambigu, non sourcé ou contradictoire, le retrieval risque de remonter des passages plausibles mais fragiles.

Ce que fait vraiment le RAG

Le RAG, pour Retrieval-Augmented Generation, consiste à récupérer des informations pertinentes dans une base de connaissances, puis à les fournir au modèle comme contexte avant génération.

Dans une implémentation classique, les documents sont importés, découpés en chunks, indexés avec embeddings et parfois recherche keyword, puis interrogés au moment de la question. Des outils comme File Search automatisent une partie de ce pipeline.

Le RAG est très utile pour donner à un agent accès à une base documentaire plus large que son contexte immédiat. Il permet de citer des sources, de retrouver des passages précis et de réduire la dépendance à la connaissance interne du modèle.

Ce que le RAG ne règle pas tout seul

Le RAG ne transforme pas automatiquement un corpus désordonné en connaissance fiable. Si la documentation contient trois définitions différentes d'une métrique, le retrieval peut remonter la mauvaise. Si les sources ne sont pas datées, il peut citer un passage obsolète.

Un chunk proche sémantiquement n'est pas forcément le bon contexte métier. Un document très bien classé peut être périmé, incomplet ou hors périmètre. Une réponse peut alors sembler sourcée tout en reposant sur une mauvaise source de vérité.

Le problème est particulièrement visible en entreprise: règles métier orales, décisions éparpillées, dashboards contradictoires, tickets anciens, pages Notion non maintenues, exports Drive, code comments, fichiers API et mémoire des experts.

Ce qu'OKF apporte en amont du retrieval

OKF agit avant l'indexation. Il propose de transformer la connaissance utile en concepts nommés, typés, reliés et citables. Au lieu d'envoyer un vrac documentaire dans un moteur de recherche, l'entreprise prépare une matière première plus claire.

Un concept OKF peut dire: voici la définition officielle, voici la source de vérité, voici les exclusions, voici les tables concernées, voici la décision qui explique ce choix, voici les citations. Le retrieval travaille alors sur des documents plus courts, plus structurés et plus explicites.

OKF améliore aussi la maintenance. Un bundle peut être relu, versionné, audité, enrichi par des agents et corrigé progressivement. La qualité du retrieval dépend alors moins d'un grand corpus opaque et plus d'un contexte assumé comme actif opérationnel.

Pipeline concret : document brut, bundle OKF, index, réponse

Le pipeline le plus simple ressemble à ceci: vous partez de documents bruts, vous en extrayez ou écrivez des concepts OKF, vous indexez ces fichiers dans un système de retrieval, puis l'agent utilise les passages retrouvés pour répondre.

L'intérêt n'est pas de supprimer les documents bruts. Ils restent utiles comme sources. Mais OKF ajoute une couche de préparation: concepts, types, liens, citations, owners et historique. Cette couche sert de guide pour les humains et de matière plus propre pour les machines.

Exemple précis : une métrique revenue mal définie

Prenons une métrique revenue. Dans beaucoup d'entreprises, la définition existe sous plusieurs formes: un message Slack, une note Notion, un dashboard BI, une requête SQL et une explication orale. Un RAG peut retrouver l'un de ces morceaux, mais il ne sait pas forcément lequel fait foi.

En OKF, on crée un concept `Metric`. Il rassemble la définition, la formule, le grain, les exclusions, les tables concernées, la décision pricing et la citation vers le dashboard de référence. Le RAG peut ensuite chercher dans un corpus qui porte déjà la bonne structure.

OKF + RAG : les deux couches complémentaires

OKF répond à la question: comment représenter et maintenir la connaissance pour qu'elle reste lisible, portable et exploitable ? Le RAG répond à une autre question: comment retrouver les bons passages au bon moment pour une demande donnée ?

Les deux couches se renforcent. OKF rend le corpus plus propre avant indexation. Le RAG rend ce corpus accessible dynamiquement pendant l'exécution. L'agent bénéficie alors d'un contexte mieux nommé, plus sourcé et plus facile à vérifier.

Cette complémentarité est particulièrement utile pour les agents qui doivent agir: créer un ticket, analyser une métrique, répondre à un client, déclencher une procédure ou expliquer une décision. Le retrieval donne l'information pertinente; OKF donne la structure et les garde-fous.

Et le Graph RAG dans tout ça ?

Le Graph RAG consiste à exploiter des relations structurées entre entités ou documents pour améliorer le retrieval. OKF n'est pas un système Graph RAG complet, mais il peut fournir une base utile: liens Markdown, concepts, citations et backlinks calculables.

Un bundle OKF peut donc alimenter des approches de recherche plus avancées. Les liens entre concepts donnent des indices de proximité. Les types aident à filtrer. Les citations aident à vérifier. Les index aident à naviguer sans tout charger.

La prudence reste importante: OKF ne crée pas automatiquement une ontologie formelle. Il crée un graphe pragmatique et lisible, qui peut ensuite être consommé par des visualizers, moteurs de recherche ou systèmes RAG plus sophistiqués.

Quand utiliser RAG seul, OKF seul, ou les deux ?

Il n'y a pas une seule bonne architecture. Si vous avez un corpus simple et peu critique, RAG seul peut suffire. Si vous avez surtout besoin de clarifier et maintenir quelques connaissances métier, OKF seul peut déjà créer de la valeur.

Dès que l'agent doit travailler avec des règles métier, métriques, décisions, sources et procédures qui évoluent, l'association OKF + RAG devient beaucoup plus intéressante. Elle sépare la gouvernance du contexte et la recherche au moment de l'usage.

Erreurs fréquentes à éviter

La première erreur est de croire qu'un meilleur modèle ou un meilleur embedding compensera toujours un corpus désordonné. Le retrieval peut améliorer l'accès, mais il ne remplace pas la clarification des sources de vérité.

La deuxième erreur est de vouloir convertir toute l'entreprise en OKF avant de tester. Commencez par un périmètre où les erreurs de contexte coûtent cher: métriques critiques, playbooks support, décisions produit, procédures ops.

La troisième erreur est d'opposer RAG et OKF. En pratique, les meilleures architectures auront souvent les deux: une couche de contexte structurée, puis une couche de recherche capable de récupérer ce contexte au bon moment.

Lire ensuite

Après avoir clarifié le lien entre OKF et RAG, la suite logique est de comparer OKF avec les outils existants: Notion, Obsidian, Git, data catalogs, wikis et fichiers d'instructions agents.

Sources officielles et lectures utiles