Détecter les erreurs invisibles : comment j’ai créé un agent de détection des doublons pour le programme anti-VIH du Kenya

J’ai développé un système multi-agents sur Elasticsearch 8.11 (Serverless) en utilisant Elastic Agent Builder avec Claude Sonnet 3.7 comme modèle de raisonnement. Plutôt que d’avoir un agent monolithique qui essaie de tout faire, j’ai divisé le travail en trois agents : l’agent de détection, l’évaluateur de risque et l’agent de recommandation d’actions. Chacun a un périmètre restreint, des entrées spécifiques et un format de sortie défini.

L’agent de détection exécute des requêtes ES|QL sur l’index des patients, recherchant des doublons à travers trois critères : la correspondance de modèles inter-établissements (même patient apparaissant dans plusieurs établissements), l’analyse démographique (par exemple, variations de nom, identifiants de sexe incohérents et correspondances partielles d’ID), et la détection des anomalies temporelles (tests le même jour dans des établissements éloignés). C’est la couche de recherche. Elle met en évidence les candidats, elle ne porte pas de jugements.

L’évaluateur de risques prend ces candidats et leur attribue une note de 0 à 100 à l’aide de signaux pondérés :

• Visites interétablissements : jusqu’à 40 points
• Incohérences démographiques : jusqu’à 30 points
• Impossibilités géographiques : jusqu’à 20 points
• Anomalies temporelles : jusqu’à 10 points

Les cas se classent dans l’un des quatre niveaux : CRITIQUE, ÉLEVÉ, MOYEN ou FAIBLE. J’expliquerai dans un instant pourquoi je n’ai pas utilisé la classification binaire.

L’agent de recommandation d’actions traduit les scores en étapes spécifiques calibrées pour le contexte des soins de santé au Kenya : examen immédiat par l’agent M&E pour les cas CRITIQUES, signalement pour la prochaine visite de l’établissement pour les cas MOYENS, et recommandations de formation du personnel pour les établissements présentant des schémas systémiques. Cet agent existe parce qu’un score de risque seul n’est pas utile à un agent de santé. Il doit savoir quoi en faire.

Au début du développement, j’ai essayé une approche plus simple : doublon ou ou non doublon. Il n’a pas survécu au contact des vraies données.

Le problème est que les tests de suivi légitimes ressemblent beaucoup à un doublon. Un patient sous traitement antirétroviral est censé se présenter au même établissement tous les deux mois. Un nourrisson doit être testé à plusieurs reprises. La classification binaire signale trop de visites légitimes (et les agents de santé apprennent à ignorer tous les signaux) ou ne tient pas compte des cas subtils où une personne effectue des tests dans deux établissements différents le même jour sous des noms légèrement différents.

L’approche par paliers permet aux professionnels de la santé d’établir des priorités. Un cas critique avec un score de risque de 87 (tests effectués le même jour, dans des établissements différents et avec des identifiants de sexe incohérents) reçoit une attention immédiate. Un cas de faible priorité avec un score de 22 (même établissement et intervalle de suivi prévu) est archivé. L’agent M&E prend la décision finale, mais il se base sur des preuves plutôt que sur une impression.

L’étalonnage de la pondération a nécessité de nombreuses itérations par rapport à des données réelles. Je ne suis toujours pas totalement convaincu qu’ils soient optimaux. Mais la structure est correcte, et la pondération peut être ajustée au fur et à mesure que nous collectons plus de données de champ.

Au départ, j’ai consacré plus de temps à la conception des indices qu’à toute autre partie du système, et c’est le meilleur investissement que j’ai fait.

Les correspondances d’index incluent des champs dérivés calculés lors de l’indexation : cross_facility_flag, total_tests, et facility_count par patient. Les principaux champs démographiques comportent des sous-champsde type mot-clé (correspondance exacte) et texte (analyse, recherche floue), permettant ainsi à l’agent de détection de basculer entre une correspondance stricte et une correspondance floue selon le signal recherché : correspondance stricte pour les identifiants d’échantillons et correspondance floue pour les noms de patients, où « Wanjiku » et « Wanjiku Mary » peuvent désigner la même personne.

J’ai également beaucoup compté sur les agrégations Elasticsearch pour le préfiltrage des candidats. Le système regroupe les enregistrements par établissement, par type de test et par date avant d’effectuer des comparaisons par paire. C’est ce qui rend la détection gérable sur de plus grands ensembles de données. Vous n’avez pas besoin de comparer chaque dossier à tous les autres si vous pouvez d’abord réduire l’espace des candidats.

ES|QL était nouveau pour moi. Je l’ai appris pendant le hackathon, et c’est impressionnant pour les analyses en temps réel à grande échelle. L’architecture qui a le mieux fonctionné pour moi est l’association d’ES|QL pour la détection de modèles et les agrégations, avec Python gérant la logique de l’application. Étant donné que j’étais nouveau dans ce domaine, cette séparation a rendu tout mon système plus facile à comprendre.

J’ai testé le système sur 1 010 dossiers patients réels anonymisés provenant de 59 établissements de santé kenyans. L’analyse s’est terminée en moins de 10 secondes.

Elle a identifié 131 patients en double, dont cinq cas de tests effectués le même jour dans plusieurs établissements et quatre patients dont les identifiants de sexe étaient intentionnellement incohérents d'un établissement à l'autre.

Ce sont les dossiers traités le jour même qui m’ont surpris. L’examen manuel finit par détecter les doublons de noms si quelqu’un est assez patient. Mais repérer qu’un patient a été testé dans deux établissements le même jour, géographiquement éloignés et avec des caractéristiques démographiques légèrement différentes, est le genre de schéma qui vit dans les données de manière invisible jusqu’à ce que vous le recherchiez spécifiquement. Les agents du M&E m’ont dit qu’il aurait fallu des semaines pour faire remonter ces cas manuellement, si tant est qu’ils aient été repérés.

Les premiers prototypes ont renvoyé un score de risque et une recommandation. Je les ai montrés aux agents M&E, mais ils n’ont pas fait confiance aux résultats.

Il ne s’agit pas d’une défaillance technique : les scores sont exacts. Mais un professionnel de santé qui examine un patient signalé doit comprendre pourquoi il l’a été avant d’agir. S’agit-il d’une erreur de nom ? Une impossibilité géographique ? Une incohérence temporelle ? Sans ce contexte, le système est une boîte noire, et les boîtes noires sont ignorées dans les environnements cliniques où l’enjeu est le traitement du patient.

Développer l’agent de recommandation d’actions pour produire des explications spécifiques et citées avec des preuves a transformé le prototype en quelque chose que les personnes pourraient utiliser réellement. L’agent M&E à qui j’ai fait la démontration à Nairobi a dit : « Cela m’aurait fait gagner trois jours le mois dernier. »

Cette leçon n'est pas spécifique aux soins de santé. Si les recommandations de votre système d'IA nécessitent une action humaine, l'explication est autant le produit que la recommandation.

Chaque agent a été intégré à Elastic Agent Builder avec des instructions personnalisées définissant son expertise dans le domaine, ses étapes de raisonnement et son format de sortie. J’ai sous-estimé l’importance de la qualité de ces instructions.

Les premières versions avec des instructions vagues produisaient des résultats incohérents. L’agent de détection expliquait parfois son raisonnement, parfois non. L’évaluateur des risques sautait occasionnellement un facteur de notation. Pour obtenir des sorties fiables et fondées sur des preuves, il était nécessaire d’être précis quant aux champs de preuves requis, et explicite quant à la chaîne de raisonnement que l’agent devait suivre. Traitez les instructions personnalisées comme du code : soyez précis, testez les cas limites et procédez par itérations.

Il ne s’agit pas d’une démo de hackathon archivée. Le plan prévoit un projet pilote dans cinq établissements du comté de Nairobi au cours des deux ou trois prochains mois, la formation des agents du M&E et la collecte de données sur les performances réelles afin d’affiner les pondérations des risques.

Ensuite, la roadmap inclut l’intégration de la correspondance biométrique et de la correspondance approximative des noms swahilis sur la base de la phonétique, ce qui représente une véritable lacune dans les approches actuelles (« Wanjiku » par rapport à « Wanjiku », c’est facile. « Njeri » par rapport à « Njery » nécessite une connaissance phonétique que la correspondance approximative standard ne gère pas bien). À terme, je souhaite que le système fonctionne en temps réel lors de l’enregistrement des patients dans le HMIS, en détectant les doublons avant qu’ils n’entrent dans le système plutôt qu’après.

À plus long terme, je souhaite me connecter au système d’échange d’informations de santé du Kenya et l’étendre à l’ensemble des 47 comtés. L’évolutivité horizontale d’Elasticsearch et la conception modulaire des agents permettent d’éviter toute refonte du système central : il a juste besoin d’extensions. L’impact projeté à l’échelle nationale : 195 000 $ d’économies annuelles et une réduction de 70 % des tests en double. Plus important encore, les cliniciens peuvent se fier aux dossiers qu’ils consultent lorsqu’ils prennent des décisions thérapeutiques.

Si vous travaillez dans un domaine où la qualité des données est un problème peu visible, coûteux et nécessitant un travail humain, Elastic Agent Builder vous permet de développer quelque chose qui explique le problème plutôt que de simplement l’interroger avec des outils tels que ES|QL pour la détection de modèles, l’orchestration multi-agents pour l’analyse en couches, et des instructions personnalisées pour un raisonnement spécifique au domaine. Le résultat a été obtenu plus rapidement que je ne l’avais prévu.

La partie la plus satisfaisante de ce développement n’a pas été le placement. C’est d’avoir vu une personne qui fait ce travail tous les jours reconnaître en une dizaine de secondes que l’outil avait compris son problème.