Source de vérité dans les systèmes d’IA : d’où provient réellement une connaissance fiable

Une source de vérité dans un système d'IA est la source faisant autorité qui est habilitée à définir si un fait, un état ou une règle spécifique doit être considéré comme vrai pour une portée, une version et un moment donnés. Ce n'est pas automatiquement le modèle de langage, la base de données vectorielle, le document récupéré le mieux classé, la mémoire de l'agent ou le dernier message dans le contexte. Une architecture d'IA fiable doit préserver quelle source a autorité pour quelle affirmation, puis maintenir la provenance, la récupération et la validation connectées à cette autorité.

Ce que « source de vérité » signifie vraiment

L'expression est souvent mal comprise comme « l'unique base de données qui contient tout ». Cela peut être vrai dans un système restreint, mais c'est généralement trop simpliste pour l'IA. Une véritable application d'IA peut combiner des bases de données opérationnelles, des documents, des API, des index vectoriels, des saisies utilisateur, la mémoire du modèle, des sources web externes et des résumés générés.

Ces sources n'ont pas une autorité égale. Un manuel de support client peut définir une politique mais pas le solde actuel d'un client. Un CRM peut définir le propriétaire actuel d'un compte mais pas la signification juridique d'une réglementation. Un dépôt de code source peut définir le comportement implémenté tandis qu'une spécification produit définit le comportement attendu. L'architecture doit donc répondre à une question plus précise : quelle source fait autorité pour cette affirmation spécifique ?

Cela fait de la source de vérité une relation entre une affirmation et une autorité, et non simplement une propriété d'une technologie de stockage.

L'exemple le plus simple

Un utilisateur demande à un assistant IA : « Quel est mon forfait d'abonnement actuel ? » L'assistant dispose de trois entrées possibles : la transcription du support du mois dernier, un document indexé du centre d'aide décrivant les types de forfaits, et la base de données de facturation en direct.

La transcription du support peut mentionner que l'utilisateur avait un forfait Pro. Le document du centre d'aide explique ce que signifie Pro. Mais l'enregistrement de facturation en direct est la source faisant autorité pour l'état d'abonnement actuel de l'utilisateur.

Un moteur de recherche sémantique pourrait classer la transcription du support au-dessus de l'enregistrement de facturation parce qu'elle contient un langage plus proche de la question. Ce classement ne rendrait toujours pas la transcription faisant autorité. Pertinence et autorité sont des dimensions différentes.

Où l'exemple simple s'arrête

Tous les domaines n'ont pas une autorité incontestée. La recherche historique peut contenir des sources primaires contradictoires. Les affirmations scientifiques peuvent évoluer à mesure que de nouvelles études apparaissent. L'interprétation juridique peut dépendre de la juridiction, de la date et de l'autorité judiciaire. Le comportement d'un produit peut différer entre la documentation et le code déployé.

Dans ces cas, l'architecture correcte n'est pas d'inventer un seul gagnant. Il s'agit de préserver les sources concurrentes, leur provenance, leur classe d'autorité, leur portée applicable et la contradiction non résolue. Un système fiable de source de vérité doit pouvoir représenter l'incertitude et le désaccord.

L'autorité est délimitée par la revendication, la version et le temps

Le mot « vérité » peut donc être trompeur si sa limite n'est pas énoncée. En architecture, la Source de Vérité est généralement mieux comprise comme la source autorisée à déterminer une proposition spécifique dans des conditions définies.

Ce qu'une Source de Vérité n'est pas

Source de Vérité vs système d'enregistrement

Un système d'enregistrement est généralement le système opérationnel faisant autorité pour une classe d'enregistrements : par exemple, un grand livre de facturation, un dossier maître RH ou une base de données de commandes. C'est une mise en œuvre courante de l'autorité de la Source de Vérité.

Mais la Source de Vérité est plus large. Un contrat PDF signé, une norme officielle, un artefact de déploiement ou un document d'archives primaire peuvent faire autorité sans être un système d'enregistrement transactionnel.

Source de Vérité vs provenance

La provenance répond à des questions telles que : D'où viennent ces données ? Qui ou quoi les a produites ? Quelle transformation a créé ce dérivé ? Quelle entité antérieure a été utilisée ? Le modèle W3C PROV modélise les entités, activités, agents et dérivations afin que l'origine et la responsabilité puissent être représentées.

La provenance n'établit pas à elle seule l'autorité. Savoir qu'une valeur provient d'un tableur rédigé par un employé spécifique aide à l'évaluer, mais l'application a toujours besoin d'une règle indiquant si ce tableur fait autorité pour la revendication.

Source de Vérité vs preuve

Une preuve soutient ou contredit une revendication. Une Source de Vérité définit quelle source a l'autorité pour trancher ou fortement contraindre cette revendication dans le contexte applicatif actuel.

Une source peut être une preuve précieuse sans faire autorité. Cinq courriels de clients peuvent être une preuve que les utilisateurs n'aiment pas un flux de travail, mais ils ne constituent pas le système d'enregistrement de la configuration actuelle du produit.

Source de Vérité vs RAG

Le RAG est un modèle de récupération. Il trouve des informations et fournit un contenu sélectionné au modèle. Le RAG ne sait pas automatiquement quelle source mérite l'autorité.

Un pipeline RAG peut récupérer un document obsolète, un résumé secondaire ou une source très similaire mais non faisant autorité. L'autorité de la source doit être encodée via la conception du corpus, les métadonnées, les filtres, la politique de classement, la validation ou les contrôles post-récupération.

Source de Vérité vs base de données vectorielle

Une base de données vectorielle stocke ou indexe des représentations utilisées pour la récupération sémantique. C'est une couche d'accès, pas automatiquement une couche de vérité.

Le même document faisant autorité peut être découpé, intégré, copié et réindexé de nombreuses fois. L'enregistrement vectoriel devrait conserver une référence à la source faisant autorité et à sa version plutôt que de devenir une nouvelle autorité intraçable.

Source de vérité vs mémoire

La mémoire d'un agent ou d'une application stocke des informations qui peuvent être utiles ultérieurement. La mémoire peut conserver une décision, une préférence ou une observation antérieure, mais elle peut devenir obsolète.

Pour un état volatil ou critique, un agent fiable devrait normalement relire la source actuelle faisant autorité plutôt que de supposer que l'état mémorisé est toujours vrai.

Source de vérité vs contexte

Le contexte est ce que le modèle reçoit lors de l'inférence en cours. Des informations faisant autorité peuvent être absentes du contexte, tandis que des informations non faisant pas autorité peuvent y être présentes.

La construction du contexte nécessite donc une politique sensible à l'autorité : récupérer ou lire la source autorisée à définir l'affirmation, puis conserver suffisamment de métadonnées pour que le modèle ou le validateur puisse comprendre sa portée.

Source de vérité vs vérité terrain d'évaluation

La vérité terrain d'évaluation est la réponse de référence, l'étiquette ou le résultat par rapport auquel un système est évalué. Elle peut être dérivée de sources faisant autorité, d'une adjudication d'experts ou de données de test organisées.

La vérité terrain est donc une construction d'évaluation. Une source de vérité est une construction d'autorité applicative/domaine. Elles peuvent se chevaucher, mais elles ne sont pas interchangeables.

Source de vérité vs qualité des données

Une source faisant autorité peut encore contenir des erreurs. L'autorité indique quelle source régit officiellement le fait ; la qualité des données demande si cette source est exacte, complète, opportune, cohérente et adaptée à l'usage prévu.

Lorsqu'un système faisant autorité est connu comme erroné, l'architecture devrait enregistrer le défaut, le processus de correction ou l'exception au lieu de substituer silencieusement une source non officielle et de masquer la divergence.

Un modèle d'architecture pratique de source de vérité

L'autorité doit être explicite, non déduite de la similarité

Un modèle d'implémentation robuste est un registre d'autorité ou une couche de politique équivalente qui associe les classes d'affirmations aux classes de sources faisant autorité. L'implémentation peut être du code, des métadonnées, de la configuration ou des règles de domaine ; la propriété importante est que l'autorité soit délibérée.

La récupération doit utiliser l'autorité comme contrainte de classement

La pertinence sémantique répond à la question « Quel candidat semble lié à cette requête ? » L'autorité répond à la question « Quel candidat est autorisé à établir ce fait ? » Un système de récupération en production a souvent besoin des deux.

Une séquence utile consiste à d'abord contraindre l'espace des candidats par identité, locataire, classe de source, statut, version ou date, puis à classer les preuves pertinentes dans l'espace autorisé. Si la pertinence est calculée avant les filtres critiques d'autorisation ou d'autorité, le pipeline peut renvoyer un résultat convaincant mais invalide.

La fraîcheur fait partie de l'autorité

De nombreux échecs de source de vérité sont en réalité des échecs temporels. La source correcte était connue, mais le système a utilisé un ancien instantané, un embedding obsolète, une réponse d'API en cache ou un document remplacé.

Une règle d'autorité doit donc inclure des sémantiques d'invalidation ou de rafraîchissement lorsque le fait peut changer. « Le CRM fait autorité » est incomplet lorsque l'application lit un export répliqué vieux d'une semaine.

Les valeurs dérivées nécessitent une traçabilité vers les entrées faisant autorité

Certains faits importants ne sont pas stockés directement. Ils sont calculés à partir d'entrées faisant autorité : un score de risque, un total de compte, un statut d'éligibilité ou une métrique agrégée.

Pour les valeurs dérivées, l'architecture de source de vérité doit préserver les autorités d'entrée, la version de transformation ou de calcul et l'heure d'exécution. La distinction de W3C PROV entre entités, activités et dérivations est utile ici car elle modélise comment une entité a été produite à partir d'autres.

Que se passe-t-il lorsque des sources faisant autorité sont en désaccord ?

Les conflits ne sont pas des cas limites dans les systèmes de connaissance sérieux. Un contrat signé peut être en désaccord avec un champ CRM. Le comportement en production peut être en désaccord avec la documentation. Deux sources historiques primaires peuvent se contredire. Une politique actuelle peut entrer en conflit avec une copie locale obsolète.

Le système a besoin d'une politique de résolution appropriée au domaine. Parfois, une autorité surclasse clairement l'autre. Parfois, la version plus récente remplace l'ancienne. Parfois, un expert ou un propriétaire métier doit arbitrer. Et parfois, le résultat correct est simplement : les preuves ne sont pas résolues.

La recherche web est une découverte, pas automatiquement une preuve

Les moteurs de recherche sont d'excellents systèmes de découverte. Les extraits de recherche, le classement des résultats et les résumés générés ne sont pas automatiquement des preuves primaires.

Pour les affirmations qui exigent une autorité, le résultat de recherche doit mener à la publication originale, au document officiel, au document source, au jeu de données ou à tout autre artefact approprié. La page de résultats aide à localiser la source ; elle n'hérite pas de l'autorité de la source.

Le modèle de langage ne doit pas décider de l'autorité par lui-même

Un modèle peut aider à classer une question, extraire des affirmations ou comparer des preuves, mais l'autorité ne doit pas dépendre uniquement de la préférence du modèle. Les modèles optimisent la génération à partir du contexte ; ils ne possèdent pas de registre garanti spécifique à un domaine indiquant quelle base de données, quel document ou quelle organisation détient chaque fait.

C'est pourquoi l'architecture applicative devrait encoder les règles d'autorité critiques de manière déterministe lorsque c'est pratique. Le modèle peut raisonner à l'intérieur de la frontière, mais la frontière elle-même ne devrait pas être recréée à partir de zéro pour chaque invite.

L'autorité doit survivre à la trace d'exécution

Si une réponse de production est suffisamment importante pour être auditée, la trace devrait permettre de reconstituer quelles sources ont été consultées, quelle version a été utilisée, quel passage ou enregistrement a soutenu l'affirmation, quelles transformations ont eu lieu et si des preuves contradictoires étaient disponibles.

Cela s'aligne sur le principe plus large de provenance dans W3C PROV et sur les directives du NIST AI RMF Playbook pour documenter les sources, les origines, les transformations, les dépendances, les contraintes et les métadonnées.

Preuve de mise en œuvre originale : Source of Truth Research Engine

Le moteur est conçu autour d'un pipeline traçable plutôt que d'une synthèse directe par IA : tâche de recherche → recherche → source originale ou artefact numérique → instantané local → SHA-256 → ID de source → affirmation → classe de preuve → relation ou contradiction → interprétation → conclusion.

Son noyau de preuves partagé stocke les Sources, les Artefacts, la provenance, les Affirmations, les Relations, les Contradictions, un Modèle de Référence et une piste d'audit. Différents modes de recherche peuvent partager ce noyau tout en appliquant différentes méthodologies de domaine.

L'architecture sépare délibérément la découverte des preuves. Les extraits de recherche ne sont pas traités comme des preuves, les noms de fichiers ne sont pas traités comme du contenu, les résumés IA ne sont pas traités comme des sources primaires, et la similarité sémantique n'est qu'un signal de découverte jusqu'à ce qu'un résultat soit retracé à une source concrète et à un localisateur.

Les fichiers originaux sont préservés et les octets locaux reçoivent des identifiants SHA-256. Les contradictions et les hypothèses rejetées ne sont pas supprimées silencieusement. De nouvelles preuves sont autorisées à modifier le modèle de référence actuel tandis que le chemin de preuve antérieur reste auditable.

Aaasaasa Document & Knowledge Engine : appliquer la même frontière aux documents d'entreprise

Le concept Aaasaasa Document & Knowledge Engine étend le même principe de conception à la documentation d'entreprise : les utilisateurs devraient pouvoir rechercher des documents, poser des questions fondées sur les sources et examiner des collections selon des critères explicites tout en préservant la distinction entre ce qu'un document déclare et ce que le système infère.

La règle d'architecture importante est qu'un noyau de récupération universel ne rend pas chaque collection également autoritaire. Les documents contractuels, les dossiers de maintenance, les documents financiers et le matériel de recherche nécessitent différentes règles d'autorité, de validation et de couverture même lorsqu'ils partagent une infrastructure d'ingestion et de recherche.

Modes de défaillance courants de Source-of-Truth

Un cadre décisionnel pratique pour la source de vérité

Liste de contrôle de l'architecture de la source de vérité

Idées fausses courantes

Cas limites

Certaines questions sont interprétatives plutôt que factuelles. « Quelle architecture est la meilleure ? » n'a pas de source de vérité unique. Le système peut récupérer des contraintes et des preuves faisant autorité, mais le jugement final est une inférence qui doit exposer les hypothèses et les compromis.

Certains domaines utilisent une autorité distribuée. Une conclusion scientifique peut dépendre de plusieurs études, jeux de données et réplications. Une conclusion historique peut dépendre de preuves primaires et secondaires contradictoires. L'architecture doit représenter la structure des preuves plutôt que d'inventer une base de données centrale qui posséderait soi-disant la vérité.

Un utilisateur peut aussi être l'autorité pour des informations personnelles subjectives : préférences, objectifs, paramètres choisis ou instructions explicites. Même dans ce cas, une entrée explicite plus récente peut remplacer une mémoire plus ancienne.

Des événements externes peuvent invalider des données auparavant faisant autorité. Un flux de prix, un système d'inventaire ou une politique de sécurité peuvent avoir été corrects au moment de la capture mais ne plus être valides. La provenance de l'instantané préserve ce qui était vrai alors ; elle ne rend pas l'instantané actuel pour toujours.

Limites

L'architecture de la source de vérité ne peut pas garantir qu'une source faisant autorité est factuellement correcte. Elle fournit la responsabilité, la provenance et des limites de propriété déterministes ; les processus de qualité des données et de vérification du domaine restent nécessaires.

L'autorité peut aussi être contestée. Différentes institutions peuvent légitimement revendiquer l'autorité dans différentes juridictions ou méthodologies. Dans ces situations, le système doit exposer le modèle d'autorité et le désaccord plutôt que de les cacher derrière un « score de vérité » universel.

Enfin, les règles d'autorité nécessitent une maintenance. Les systèmes, propriétaires, politiques, versions et réglementations changent. Un registre d'autorité obsolète peut être aussi dangereux que pas de registre du tout.

Qu'est-ce qui changerait cette réponse ?

La cartographie spécifique des autorités change selon le domaine. La banque, la santé, la livraison de logiciels, la recherche scientifique et l'analyse historique ont différents systèmes d'enregistrement, règles de preuve et obligations réglementaires.

La mise en œuvre change également avec l'architecture. Une petite application peut encoder l'autorité directement dans les appels de service. Une plateforme plus grande peut avoir besoin de registres, de métadonnées de source, de moteurs de politiques, de systèmes de traçabilité ou de contrats de données. Le principe fondamental reste le même : ne pas laisser l'ordre de récupération ou la préférence du modèle décider silencieusement ce qui est considéré comme faisant autorité.

Connaissances canoniques associées

L'architecture de source de vérité est un prérequis pour les concepts ultérieurs de récupération et de gouvernance, car la qualité de la récupération seule ne peut pas déterminer si une preuve est autorisée à définir la réponse.

La mémoire est un autre concept adjacent. Un agent fiable sépare les informations mémorisées de l'état applicatif actuel faisant autorité.

L'autorité est également directement liée à la validité des réponses. Même une source faisant autorité ne soutient que les affirmations comprises dans sa version, sa date, sa portée et sa limite de preuve.

Questions fréquentes

Glossaire

Conclusion

Une IA fiable ne vient pas du fait de donner plus d'informations au modèle. Elle vient du fait de savoir quelles informations sont autorisées à définir l'affirmation, de préserver l'origine de ces informations, de récupérer la bonne version et de maintenir la réponse finale dans la portée de la source.

C'est pourquoi la source de vérité, la provenance, la récupération, la mémoire et le contexte doivent rester des concepts distincts. La source de vérité définit l'autorité. La provenance explique l'origine. La récupération trouve des candidats. La mémoire préserve les informations passées sélectionnées. Le contexte est ce que le modèle voit. La génération transforme ces entrées en une sortie.

Lorsque ces couches restent explicites, un système d'IA peut faire plus que sembler plausible : les affirmations importantes peuvent être retracées jusqu'à la source qui avait réellement le droit de les établir.

Sources primaires et preuves de mise en œuvre

Les sources externes ci-dessous soutiennent les affirmations sur la provenance et la gestion des risques liés à l'IA. La section Source of Truth Research Engine est une preuve de mise en œuvre originale et est explicitement présentée comme un modèle de mise en œuvre plutôt que comme une norme universelle.