PHAROS : 4 agents, 60 secondes, 1 signal de sécurité des médicaments manqué à un pas de la catastrophe

J’ai divisé le système parce que les tâches sont trop différentes pour qu’un seul agent soit médiocre dans toutes. Surveiller les pics de volume n’est pas la même compétence que de calculer des ratios statistiques, ce qui n’est pas la même chose que de rédiger des documents réglementaires, ni que de décider qui appeler à 2 h du matin. Chaque agent reçoit une invite système ajustée à sa tâche spécifique et des paramètres de température qui correspondent : ANALYST fonctionne à 0,0 car il faut éviter que les valeurs PRR soient fantaisistes. SCRIBE fonctionne à 0,2 pour la génération de texte contrôlée. SENTINEL à 0,1.

SENTINEL surveille l’index pharos-adverse-events concernant les pics de volume. Il utilise ES|QL pour comparer les volumes de rapport des 7 derniers jours à une base de référence de 90 jours. Si un médicament affiche une augmentation de 3 fois, SENTINEL déclenche un workflow Elastic qui lance ANALYST. Lors de l’exécution CARDIVEX, il a détecté un pic de 15 fois.

ANALYST est l’outil qui permet la détection réelle. Il exécute le calcul du WHO PRR de l’OMS entièrement dans ES|QL — STATS pour les comptages, EVAL pour les calculs de ratio et WHERE pour les seuils — sur les paires médicament-réaction. Ensuite, il effectue une analyse temporelle avec BUCKET(report_date, 1 week) pour détecter les regroupements hebdomadaires, l’agrégation géographique sur geo.country_code, et une recherche hybride BM25 + vecteur dense pour trouver des signaux historiques similaires. La classification de la gravité se fait par niveaux : PRR ≥ 5,0 avec plus de 5 cas est critique, PRR ≥ 2,0 avec plus de 3 cas est haut, et tout ce qui est supérieur à 1,5 passe à la surveillance. Les signaux confirmés sont écrits dans pharos-signals.

SCRIBE capte les signaux confirmés et génère trois types de documents : MedWatch 3500A, PSUR Section VI et un rapport de cas. Il extrait jusqu’à 100 rapports de cas justificatifs de l’index des événements indésirables, produit les documents et les indexe dans pharos-regulatory-reports.

HERALD est la couche d’action. Les signaux critiques reçoivent une alerte Slack (formatage Block Kit), un ticket Jira P1 et des e-mails sont envoyés au responsable de la sécurité et au vice-président de la sécurité. Les signaux importants reçoivent une alerte Slack, un ticket Jira P2 et un e-mail sont envoyés au responsable de la sécurité. Les signaux de surveillance sont regroupés dans un résumé hebdomadaire. Un délai d’escalade de 2 heures relance le vice-président de la sécurité si un signal critique n’est pas pris en compte.

Les transferts entre agents passent tous par des workflows Elastic : neuf workflows au total couvrant la coordination agent à agent, l’ingestion FAERS nocturne selon une planification cron, l’envoi de messages Slack/Jira/e-mail, le logging d’audit et le délai d’escalade.

J’ai délibérément choisi de conserver le calcul du PRR dans ES|QL plutôt que d’extraire les données dans Python. Au départ, j’ai supposé que j’aurais besoin de pandas pour le travail statistique. J’avais tort.

La formule complète WHO PRR, le comptage, les calculs de ratio, les seuils et les buckets temporels sont tous exécutés sous forme de requêtes ES|QL. Les agents appellent les outils ES|QL, raisonnent sur les résultats et écrivent en retour : pas de pandas, pas de calcul externe et pas de ralentissement du transfert de données. Les statistiques évoluent en fonction du cluster.

ES|QL est moins flexible que pandas pour les analyses complexes. Cependant, pour la formule de l’OMS et les agrégations hebdomadaires BUCKET, il fonctionne parfaitement. La suppression de la couche Python intermédiaire a simplifié l’architecture plus que prévu : les agents se contentent d’interroger et de raisonner, et le risque de dysfonctionnement est réduit d’un point.

PHAROS fonctionne sur quatre indices Serverless Elasticsearch, et c’est sur le principal, pharos-adverse-events, que j’ai passé le plus de temps de conception.

Il dispose d’un clinical_text_analyzer personnalisé avec un stemming boule de neige pour la recherche narrative, d’un analyseur de nom de médicament avec un générateur de tokens de mot-clé pour la correspondance exacte des médicaments, de champs dense_vector (1 536 dimensions) pour les enchâssements narratifs, de geo_point pour le clustering géographique et de mappings imbriqués pour les réactions. Toutes les requêtes dont les agents ont besoin, recherche narrative approximative, recherche exacte de médicaments, agrégation géographique, similarité sémantique, sont prises en charge par la conception de l’index. Les trois autres index sont plus simples : pharos-signals stocke les signaux détectés avec les scores PRR et la chaîne de raisonnement de l’analyste, pharos-regulatory-reports contient les rapports générés, et pharos-audit-log horodate chaque action de l’agent.

Obtenir que les LLM renvoient du JSON structuré de manière fiable a été un combat auquel je ne m’attendais pas.

Vous demandez du JSON à un LLM, vous obtenez du JSON enveloppé dans trois paragraphes d’explication, du JSON à l’intérieur de balises de code markdown, ou un préambule conversationnel suivi de JSON et d’un résumé utile. Les agents se transmettent des données structurées, de sorte que chaque réponse doit être analysée correctement. Peu importe la qualité de votre détection de signal si la sortie de l’ANALYST ne peut pas être lue de manière fiable par SCRIBE.

J’ai passé beaucoup de temps à ajuster les invites système et j’ai fini par écrire une fonction d’extraction JSON qui gère le JSON brut, les clôtures de code markdown et le JSON enfoui dans le langage naturel. Ce n’est pas un travail intéressant, mais c’est le genre de chose qui détermine si un pipeline multi-agents fonctionne réellement ou s’il fait simplement de bonnes démonstrations.

Le calcul du PRR est actuellement une estimation ponctuelle. Un système de pharmacovigilance de production a besoin de limites de confiance du khi-deux et de notation IC bayésienne. Le modèle de données a déjà un champ ic_score, mais il utilise une approximation au lieu du calcul bayésien correct. C’est la première chose que je modifierais si j’avais plus de temps.

Le système considère également la « vision floue » et la « perte de vision » comme des événements distincts. L’étape suivante consiste à regrouper les réactions en fonction de l’ontologie MedDRA, de manière à ce que le système puisse détecter les signaux liés à des termes connexes au lieu de traiter chaque chaîne de manière indépendante. Ensuite, j’ajouterais les données d’EudraVigilance à celles de FAERS pour obtenir une corrélation intercontinentale.

Deux millions de rapports d’événements indésirables atterrissent sur le bureau de quelqu’un chaque année, et la réponse actuelle consiste à augmenter le nombre d’analystes effectuant des examens manuels. PHAROS démontre que la solution réside dans des agents qui analysent les statistiques de l’OMS, génèrent des documents et s’adressent à la bonne personne, le tout avant que l’analyste n’ait ouvert son ordinateur portable.

PHAROS est open source sous MIT. Si vous travaillez dans le domaine de la pharmacovigilance ou des questions réglementaires et que vous souhaitez comparer ces données à des données réelles, n’hésitez pas à me contactez.