Conception de Systèmes de Connaissances

La plupart des entreprises opèrent avec des vocabulaires multiples, superposés et partiellement incompatibles pour les mêmes concepts. Le même client est enregistré dans des formats différents selon les systèmes ; le même produit est classifié différemment par les ventes et les opérations ; le même risque est décrit dans un langage incompatible par le trading et la conformité. Une ontologie est le modèle explicite et convenu de ces concepts – ce qui constitue une instance, quels attributs sont obligatoires, comment les concepts sont liés – et c'est le substrat sur lequel les systèmes de connaissances en aval dépendent.

Nous concevons les ontologies de manière pragmatique plutôt que philosophique. L'objectif n'est pas une représentation parfaite du monde, mais une représentation utile de la partie du monde sur laquelle le système opère. Nous partons des requêtes auxquelles le système doit répondre et des décisions qu'il doit appuyer, et nous ne modélisons que les concepts et les relations que ces requêtes exigent, avec une marge d'extension explicite à mesure que de nouveaux cas d'usage apparaissent.

Les normes — schema.org, FIBO, SNOMED CT, GS1, modèles de référence spécifiques à l'industrie — sont réutilisées lorsqu'elles conviennent, adaptées lorsqu'elles conviennent presque, et ignorées lorsqu'elles ne conviennent pas. Le risque de partir d'une toile vierge est plus grand que le risque d'hériter d'une complexité accumulée, mais l'inverse est vrai sur le long terme.

• Conception d'ontologies et de taxonomies de domaine
• Réutilisation et adaptation des normes
• Intégration sémantique des données
• Gestion des données de référence
• Stratégie de versionnage et d'évolution
• Outils de gouvernance et de révision

Un graphe de connaissances réalise une ontologie sur la base de données réelles. Les clients, les produits, les fournisseurs, les transactions, les événements et les relations entre eux deviennent une structure connectée et interrogeable sur laquelle les systèmes en aval — recherche, recommandation, détection de fraude, conformité, mise à la terre d'IA générative — peuvent s'appuyer. La valeur ne réside pas dans le graphe lui-même, mais dans les produits qu'il rend possibles.

Nous construisons des graphes de connaissances avec les technologies adaptées à la charge de travail — Neo4j, Amazon Neptune, JanusGraph, AnzoGraph, bases de données RDF natives, ou couches de graphes de propriétés sur des entrepôts relationnels lorsque cela convient mieux. Nous accordons une attention particulière à la résolution d'entités, car un graphe dans lequel la même entité du monde réel apparaît sous plusieurs nœuds est pire que pas de graphe du tout, et nous intégrons des pratiques d'intégration continue afin que le graphe évolue de manière prévisible avec les données et l'ontologie en amont.

Lorsque le cas d'utilisation le justifie, nous étendons le graphe avec des représentations basées sur des plongements (embeddings) qui prennent en charge la recherche de similarité, les recommandations et le type de récupération sémantique qui ancre les applications de modèles de langage à grande échelle sans exiger que ces modèles mémorisent tout. La combinaison d'un graphe structuré et de plongements appris est exceptionnellement puissante et de plus en plus courante.

“Le graphe lui-même est rarement le livrable. Ce sont les produits qu'il rend possibles qui le sont.”

Lorsque les décisions sont régies par des politiques complexes — éligibilité, tarification, classification des risques, conformité réglementaire, parcours cliniques — les modèles statistiques purs sont le mauvais outil. La logique de politique est mieux exprimée en tant que logique de politique : sous forme de règles lisibles, de tables de décision structurées et de moteurs d'inférence capables de déduire des conséquences à partir de faits et d'un corpus de règles. Le résultat est un système dont le comportement est entièrement traçable et qui peut être mis à jour par des experts de domaine sans réentraîner un modèle.

Nous utilisons des plateformes de gestion de décision modernes (Camunda DMN, Drools, outils de Modèle de Décision et Notation) lorsque cela correspond au cas d'utilisation, et des moteurs de règles sur mesure lorsque ce n'est pas le cas. Nous accordons une attention particulière au processus éditorial : qui peut modifier une règle, avec quelle revue, avec quels tests par rapport à des cas historiques, et avec quel déploiement progressif. Sans ce processus, les bases de règles se dégradent rapidement en accrétions illisibles.

Les architectures hybrides combinent le meilleur des deux mondes. Un modèle neuronal gère la perception ou la reconnaissance de formes là où les règles ne peuvent pas être écrites ; un moteur de règles gère la conformité aux politiques et la prise de décision finale là où les règles peuvent l'être. Le composant neuronal fournit des entrées au moteur de règles — entités extraites d'un document, une probabilité calibrée, une classification — et le moteur de règles prend une décision qui peut être défendue face à tout audit. Nous concevons ces architectures de manière explicite, avec une séparation claire entre les composants d'apprentissage et de raisonnement et des interfaces explicites entre eux.

L'explicabilité n'est pas une fonctionnalité que l'on ajoute à un modèle après coup. C'est une propriété de l'architecture dans son ensemble. Les systèmes basés sur les connaissances sont explicables par construction : chaque décision est le produit de faits et de règles qui peuvent être inspectés, et l'explication est une trace directe de la chaîne d'inférence plutôt qu'une reconstruction post-hoc.

Lorsque des composants appris par machine font partie du système, nous les associons à des outils d'explication adaptés à la classe de modèle — attribution de caractéristiques pour les modèles tabulaires, extraction d'attention et de raisonnement pour les modèles de séquence, explication basée sur des prototypes pour les modèles d'image — et nous exposons ces explications à côté de la sortie du système, dans un langage qu'un expert du domaine peut utiliser. L'objectif n'est pas de rendre le modèle interprétable dans l'abstrait ; il est de fournir à l'évaluateur humain les preuves dont il a besoin pour annuler ou accepter la recommandation du système.

Nous travaillons en étroite collaboration avec les fonctions de risque et de conformité pour définir les normes que les explications doivent respecter, et nous testons ces normes par rapport à des cas réels dans le cadre de l'acceptation. Une explication qui satisfait un scientifique des données mais qui déroute un gestionnaire de cas ne passe pas.

Les systèmes de connaissances nécessitent une maintenance continue. Les ontologies évoluent à mesure que l'entreprise change ; les graphes nécessitent une maintenance de résolution d'entités à mesure que de nouvelles sources sont connectées ; les bases de règles nécessitent une élagage, une déduplication et une révision par rapport aux résultats réels. Nous concevons le modèle opérationnel en même temps que la technologie : les rôles éditoriaux, la cadence de révision, le processus de contrôle des modifications, les tableaux de bord de surveillance des performances. Le résultat est un système dont la demi-vie se mesure en années, et non en mois.

Beaucoup de nos déploiements sont associés à des services gérés légers qui prennent en charge cette maintenance continue, en particulier les premières années, avant que les équipes internes du client n'aient assimilé les pratiques. Nous sommes également ravis lorsque les clients prennent immédiatement en charge la gestion opérationnelle ; la conception s'adapte aux deux cas.