PHAROS: 4 agentes, 60 segundos y 1 señal de seguridad farmacológica no detectada al borde del desastre

Dividí el sistema porque las tareas son lo suficientemente diferentes como para que un solo agente fuera mediocre en todas. Monitorear los picos de volumen no es la misma habilidad que calcular índices estadísticos, y no es lo mismo que redactar documentos regulatorios, ni lo mismo que decidir a quién alertar a las 2 a. m. Cada agente recibe un prompt del sistema ajustado a su tarea específica y ajustes de temperatura que coinciden: ANALYST se ejecuta a 0.0 porque no quieres números PRR creativos. SCRIBE se ejecuta a 0.2 para la generación de texto controlada. SENTINEL a 0.1.

SENTINEL observa el índice de eventos adversos de pharos (pharos-adverse-events) para detectar picos de volumen. Utiliza ES|QL para comparar los últimos 7 días de volumen de reportes con una línea base de 90 días. Si un medicamento muestra un salto de 3x, SENTINEL dispara un flujo de trabajo de Elastic que inicia ANALYST. En la ejecución de CARDIVEX, detectó un pico de 15x.

ANALYST es donde realmente se lleva a cabo la detección. Realiza el cálculo del PRR de la OMS íntegramente en ES|QL en todos los pares de medicamentos y reacciones: STATS para los recuentos, EVAL para los cálculos de la relación y WHERE para los umbrales. Luego, realiza un análisis temporal con BUCKET(report_date, 1 semana) para detectar agrupaciones semanales, una agregación geográfica en geo.country_code y una búsqueda híbrida BM25 + vector denso para encontrar señales históricas similares. La clasificación de gravedad tiene varios niveles: un PRR ≥ 5.0 con 5 o más casos es CRÍTICO, un PRR ≥ 2.0 con 3 o más casos es ALTO, y cualquier valor por encima de 1.5 pasa a MONITOREO. Las señales confirmadas se registran en pharos-signals.

SCRIBE capta señales confirmadas y genera tres tipos de documentos: MedWatch 3500A, PSUR Sección VI y una narrativa de caso. Obtiene hasta 100 reportes de casos de apoyo del índice de eventos adversos y produce los documentos y los indexa en pharos-regulatory-reports.

HERALD es la capa de acción. Las señales CRÍTICAS reciben una alerta de Slack (formato del kit de bloqueo), un boleto de Jira P1 y correos electrónicos al oficial de seguridad y al vicepresidente de seguridad. Las señales ALTAS se envían por Slack, Jira P2 y por correo electrónico al oficial de seguridad. Las señales de MONITOREO se acumulan en un resumen semanal. Un tiempo de espera escalado de 2 horas vuelve a alertar al VP de seguridad si una señal CRÍTICA no se reconoce.

Todas las transferencias entre agentes se realizan a través de flujos de trabajo de Elastic: un total de nueve flujos de trabajo que abarcan la coordinación entre agentes, la ingesta nocturna de FAERS según un cron schedule, el envío a través de Slack/Jira/correo electrónico, los logs de auditoría y el tiempo de espera para la escalada de incidencias.

Tomé la decisión deliberada de mantener el cálculo PRR dentro de ES|QL en lugar de extraer datos a Python. Al entrar, asumí que necesitaría pandas para el trabajo estadístico. Me equivoqué.

La fórmula completa PRR de la OMS, el conteo, los cálculos de proporción, los umbrales y el agrupamiento temporal se ejecutan como consultas ES|QL. Los agentes llaman a las herramientas de ES|QL, razonan sobre los resultados y escriben: sin pandas, sin computación externa y sin cuellos de botella en la transferencia de datos. Las estadísticas escalan con el clúster.

ES|QL es menos flexible que pandas para análisis arbitrarios. Pero para la fórmula de la OMS y las agregaciones semanales de BUCKET (cubeta), maneja el trabajo de manera limpia. Eliminar esa capa intermedia de Python simplificó la arquitectura más de lo que esperaba. Los agentes solo consultan y razonan, y hay un lugar menos donde las cosas pueden fallar.

PHAROS funciona con cuatro índices Serverless de Elasticsearch, y el principal, pharos-adverse-events, es donde pasé más tiempo diseñando.

Cuenta con un analizador clinical_text_analyzerpersonalizado con stemming de tipo snowball para la búsqueda narrativa, un analizador drug_name_analyzer con tokenizador de palabras clave para la coincidencia exacta de medicamentos, campos dense_vector (1536 dimensiones) para las incrustaciones narrativas, geo_point para la agrupación geográfica y mapeos anidados para las reacciones. El diseño del índice admite todas las consultas que necesitan los agentes: búsqueda narrativa difusa, búsqueda exacta de medicamentos, agregación geográfica y similitud semántica. Los otros tres índices son más sencillos: pharos-signals almacena las señales detectadas con puntuaciones PRR y la cadena de razonamiento del analista, pharos-regulatory-reports contiene los reportes generados y pharos-audit-log registra con marca de tiempo cada acción de los agentes.

Conseguir que los LLMs devolvieran JSON estructurado de forma fiable fue la lucha que no esperaba.

Cuando le pides JSON a un LLM, obtienes JSON envuelto en tres párrafos de explicación, o JSON dentro de cercas de código markdown, o un preámbulo conversacional seguido de JSON, seguido de un resumen útil. Los agentes se entregan datos estructurados entre sí, por lo que cada respuesta se debe parsear de forma limpia. No importa lo buena que sea tu detección de señales si SCRIBE no puede leer de forma confiable la salida del ANALYST.

Pasé mucho tiempo ajustando los mensajes del sistema y terminé escribiendo una función de extracción de JSON que maneja JSON sin procesar, cercas de código markdown y JSON enterrado dentro del lenguaje natural. No es un trabajo muy interesante, pero es el tipo de cosa que determina si una canalización de agentes múltiples realmente se ejecuta o si solo se ve bien en las demostraciones.

El cálculo de PRR es actualmente una estimación puntual. Un sistema de farmacovigilancia de producción necesita límites de confianza de chi-cuadrado y puntuación IC bayesiana. El modelo de datos ya tiene un campo ic_score configurado. Está usando una aproximación en lugar del cálculo bayesiano adecuado. Eso es lo primero que cambiaría con más tiempo.

El sistema también trata "visión borrosa" y "pérdida de visión" como eventos separados. El siguiente paso inmediato es agrupar las reacciones teniendo en cuenta la ontología de MedDRA, para que el sistema pueda detectar señales entre términos relacionados en lugar de tratar cada cadena de texto como algo independiente. Después de eso, incorporaría los datos de EudraVigilance junto con FAERS para la correlación intercontinental.

2 millones de reportes de eventos adversos llegan al escritorio de alguien cada año, y la respuesta actual es que más analistas realizan más revisiones manuales. PHAROS es un argumento de que la respuesta son agentes que analizan las estadísticas de la OMS, generan la documentación y escalan la información a la persona adecuada, y todo antes de que el analista prenda su computadora.

PHAROS es open source bajo MIT. Si trabajas en farmacovigilancia o asuntos regulatorios y quieres comparar esto con datos reales, me gustaría saber de ti.