Construction d’un système de notation de confiance pour des données de santé assemblées par un LLM à l’aide de Databricks
Par: Praveen Sundaresan Ramesh, Sidhant Guliani, et Amine Jallouli.
Le Défi
Le Databricks Hackathon for Good, organisé en partenariat avec OpenAI, était un défi de 36 heures qui a débuté le premier jour du Data & AI Summit 2026. L’ensemble de données avait été assemblé par Databricks en collaboration avec la Virtue Foundation, un organisme à but non lucratif qui œuvre à offrir des soins de santé de qualité aux populations dans le besoin.
L’ensemble de données et le mandat
Au cœur de la solution se trouvait un seul ensemble de données central: 10 000 dossiers d’établissements de santé provenant de partout en Inde, comprenant 51 colonnes de données à la fois structurées (nom de l’établissement, province, emplacement, spécialités) et non structurées (capacités, procédures et équipement).
Chaque équipe participante a reçu le même ensemble de données brut. Le défi consistait à le transformer en une application Databricks permettant aux utilisateurs non techniques, comme les planificateurs en santé, les coordonnateurs d’ONG et les analystes, de poser des questions et de prendre des décisions éclairées et fondées sur les données.
Les équipes pouvaient choisir l’un des quatre volets suivants:
- Facility Trust Desk: L’établissement peut-il vraiment faire ce qu’il prétend?
- Medical Desert Planner: Où se trouvent les lacunes les plus critiques en matière de soins?
- Referral Copilot: Où un patient devrait-il réellement être dirigé?
- Data Readiness Desk: Qu’est-ce qui doit être corrigé avant que cet ensemble de données puisse être jugé fiable?
La Décision
Après quelques heures à explorer les données, combinées à une conversation avec la personne qui les avait assemblées, nous avons découvert plusieurs incohérences. Le problème le plus frappant était la présence de dossiers fusionnés: un seul enregistrement représentait souvent les données de plusieurs hôpitaux distincts combinées ensemble, avec des emplacements et des capacités contradictoires empruntés à des établissements sans lien entre eux.
Nous avons rapidement compris que les quatre volets partageaient une même dépendance: les données. Toute erreur dans les fondations se répercuterait sur tout ce qui serait bâti par-dessus. Nous avons choisi le volet Data Readiness, car les données constituent la base sur laquelle repose toute autre question. Un centre de confiance, une carte des lacunes et une liste de recommandations de référence ne sont fiables que dans la mesure où les données qui les sous-tendent le sont aussi.
Nous avons bâti le Data Readiness Desk pour répondre à une seule question: quels dossiers sont erronés, à quel point le sont-ils, et lesquels est-il le plus important de corriger en premier? Ce billet présente notre démarche, les outils Databricks que nous avons utilisés et les raisons de nos choix.
La Solution
Un planificateur veut savoir si un hôpital offre réellement des services comme la dialyse, les soins intensifs ou l’oncologie. Pour répondre à ce besoin, nous avons construit un score de confiance pour chaque paire établissement-spécialité, plutôt que de simplement noter l’établissement dans son ensemble. Notre unité de confiance est donc une allégation de type (établissement, spécialité). Par exemple, si l’hôpital Aravind Eye Hospital prétend offrir des services de gynécologie, notre score de confiance évalue la fiabilité de cette allégation précise.
Notre premier réflexe a été de laisser un modèle d’IA juger chaque allégation directement. Mais un verdict sans explication est précisément ce qu’un planificateur ne peut ni faire confiance ni utiliser pour agir. Nous avons plutôt utilisé l’IA pour interpréter le texte non structuré, combinée à un système de notation basé sur des règles transparentes pour rendre le verdict final.
En moyenne, chaque établissement recensait 11 spécialités. Nous avons donc fait éclater l’ensemble de données original de 10 000 établissements en environ 118 000 allégations individuelles. Pour chacune de ces allégations, nous avons calculé un score pondéré selon la formule suivante:
confiance = C × (0,45·E + 0,15·A + 0,15·I + 0,15·S + 0,10·R)- C · Cohérence: Vérifie si un dossier décrit réellement un seul établissement réel, à l’aide d’indicateurs géographiques (code postal, latitude-longitude, adresse) et du nombre de sources distinctes.
- E · Preuve: La spécialité mentionnée est-elle également relevée dans d’autres colonnes, comme les procédures, les capacités ou l’équipement?
- A · Autorité: Évalue la crédibilité des sources sous-jacentes, en accordant plus de poids aux sites officiels et gouvernementaux.
- I · Corroboration indépendante: Les allégations peuvent-elles être confirmées par plusieurs sources indépendantes?
- S · Cohérence spatiale: Le code postal, les coordonnées et l’adresse concordent-ils quant à l’emplacement?
- R · Actualité: À quand remonte la dernière mise à jour de l’information?
Tous les poids sont définis dans un seul fichier de configuration, qui peut être ajusté en collaboration avec des experts du domaine. Le rôle du modèle de langage se limite à interpréter le texte non structuré et à en extraire les preuves. Tout le reste, de la notation à la persistance et à la diffusion des données, s’exécute entièrement sur Databricks, comme le montre le diagramme d’architecture.
Unity Catalog
L’ensemble de données brut provenait du Databricks Marketplace, sous forme de table Delta dans la couche bronze. Un pipeline de notation traite ensuite une version nettoyée de la table et écrit plusieurs tables dans le catalogue: les établissements nettoyés, un profil des colonnes, une file d’attente de révision, les problèmes par établissement, les allégations notées et un tableau de bord de préparation des données. Le fait de conserver les données brutes et les analyses organisées dans un seul catalogue crée une frontière unique pour la gouvernance, la traçabilité et le contrôle des accès. Cela garantit également que Genie (le moteur de traduction du langage naturel en SQL de Databricks) et Lakebase (le service transactionnel OLTP de Databricks) lisent toujours à partir du même ensemble de tables, éliminant ainsi tout risque d’incohérence dans l’application.
AI Query
Le calcul du score de preuve exigeait davantage qu’une simple recherche par mots-clés. Une même spécialité peut être décrite de dizaines de façons différentes dans les champs de procédures, de capacités et d’équipement. Pour bien saisir cette variabilité, nous avons eu recours à AI Query, une fonction d’IA polyvalente offerte sur Databricks. Avec 118 000 allégations à noter, la parallélisation intégrée, les nouvelles tentatives automatiques et les capacités de mise à l’échelle d’AI Query se sont révélées essentielles, sans qu’il soit nécessaire de mettre en place une infrastructure de diffusion de modèles. Une configuration particulièrement utile pour des charges de travail de cette ampleur était la possibilité de désactiver l’arrêt sur erreur. Cela a permis au travail de se terminer avec succès, les lignes en échec étant simplement signalées pour révision plutôt que d’interrompre l’ensemble du pipeline.
Genie
Un réviseur ne devrait pas avoir à écrire de requête SQL pour demander: « Quelles provinces comptent le plus d’établissements signalés? » Nous avons configuré Genie, l’interface en langage naturel de Databricks, sur les cinq tables analytiques et l’avons intégré à l’assistant de l’application. Cela permet aux réviseurs de poser des questions en langage courant et d’obtenir directement des réponses à partir des données. Genie traduit chaque question en requête, l’exécute automatiquement sur un entrepôt SQL et en retourne les résultats. La requête sous-jacente est affichée aux côtés des résultats, de sorte que chaque réponse est transparente et vérifiable, plutôt que de présenter des chiffres sans source traçable.
Agent OpenAI
Genie est l’un des deux outils accessibles à l’assistant d’IA intégré à l’application Web, propulsé par le modèle GPT d’OpenAI. L’assistant dispose d’un outil de recherche Web pour consulter des sources externes, comme des lignes directrices cliniques ou des normes médicales. Pour chaque question posée par le planificateur, l’assistant détermine quel outil utiliser, en combinant au besoin plusieurs recherches en séquence, et affiche sa progression en temps réel dans l’interface de clavardage. Si on lui demande: « Les établissements d’oncologie du Maharashtra sont-ils suffisamment fiables pour des références? », il extrait les scores de confiance pertinents des tables internes, récupère les normes cliniques applicables sur le Web, puis compose une réponse unique, cohérente et référencée.
Lakebase
Le tableau de bord et les files d’attente doivent se charger instantanément, et les décisions des réviseurs doivent être enregistrées de manière fiable dès qu’elles sont prises. Traditionnellement, cela aurait nécessité deux systèmes distincts. Lakebase, la base de données transactionnelle intégrée de Databricks, répond aux deux besoins à la fois. Les six tables analytiques sont automatiquement synchronisées avec les données sous-jacentes pour permettre des lectures rapides, tandis que les décisions des réviseurs sont écrites directement dans une table dédiée sur Lakebase. Nous avons utilisé la mise à l’échelle automatique de Lakebase, qui est l’option par défaut aujourd’hui, avec tous les accès aux données passant par une seule connexion sécurisée utilisant des identifiants à expiration automatique générés à chaque session.
Databricks Apps
Ce qui relie le tout et rend la plateforme intuitive pour le planificateur, c’est une application Web simple et facile à utiliser. Habituellement, cela suppose un serveur de traitement, une application frontale, un système d’authentification et un hébergement Web, tous gérés séparément des données. Databricks Apps élimine complètement cette lourdeur. L’ensemble du produit est déployé sous forme d’une seule application, hébergée directement à côté des données qu’elle consulte, héritant automatiquement des mêmes contrôles de sécurité et d’accès. Les ressources comme l’entrepôt de données, la base de données et les clés API sont déclarées une seule fois et injectées de façon sécurisée au moment de l’exécution. Une seule commande de déploiement suffit pour mettre l’application en ligne à l’intention du planificateur.
Conclusion
La qualité des données n’est rarement le problème le plus stimulant à résoudre, mais c’est presque toujours le plus déterminant. En 36 heures, notre équipe a bâti un système qui ne se contente pas de signaler les données douteuses: il explique pourquoi un dossier n’est pas fiable, quantifie son importance et met la bonne information entre les mains de la bonne personne pour agir. Databricks a rendu cela possible à ce rythme. Le fait de disposer du stockage de données, des fonctions d’IA, de l’analytique gouvernée, de l’interrogation en langage naturel et de l’hébergement d’applications, le tout sur une seule plateforme, nous a permis de consacrer notre temps à résoudre le problème plutôt qu’à gérer l’infrastructure qui l’entoure. Remporter le Databricks Hackathon for Good est le reflet de cette concentration: réparer d’abord les fondations, et tout ce qui est bâti par-dessus devient plus fiable. Pour la Virtue Foundation ainsi que pour les planificateurs en santé, les coordonnateurs d’ONG et les analystes qui utiliseront ultimement ces données, nous espérons que le Data Readiness Desk représente un pas vers des décisions en lesquelles ils peuvent avoir confiance.
Références
Cavallo Technologies
Cavallo Technologies est une firme exclusivement dédiée à Databricks, qui aide les équipes d’entreprise à concevoir et à construire des systèmes d’IA de calibre production sur la plateforme Databricks. Si votre organisation envisage cette avenue, nous serions ravis de discuter de votre architecture et de la façon dont nous pouvons vous aider.