Elastic Blog

PHAROS：4个智能代理，60秒，一个药物安全信号差之毫厘

7.5内容质量
PHAROS：4个智能代理，60秒，一个药物安全信号差之毫厘

TL;DR · AI 摘要

PHAROS系统通过4个智能代理在60秒内检测药物安全信号，显著提高了药物安全性监控效率。

核心要点

  • PHAROS系统利用4个智能代理实现了药物安全信号的快速检测。
  • 该系统能够在60秒内完成药物安全信号的识别过程。
  • PHAROS有助于减少药物安全事件的发生，提高医疗行业的安全性。

结构提纲

按章节快速跳转。

  1. §引言

    介绍PHAROS系统的背景和目的。

  2. ·智能代理概述

    解释什么是智能代理及其作用。

  3. ·PHAROS系统架构

    描述PHAROS系统的组成和工作流程。

  4. ·应用场景

    说明PHAROS系统如何应用于药物安全监控。

  5. ·效果评估

    展示PHAROS系统的性能和实际应用效果。

思维导图

用一张图看清主题之间的关系。

查看大纲文本（无障碍 / 无 JS 友好）
  • PHAROS系统
    • 智能代理
      • 系统架构
      • 应用场景
    • 药物安全监控

金句 / Highlights

值得收藏与分享的关键句。

#药物安全#智能代理#实时监控
打开原文

PHAROS：4个代理，60秒，一个错过的药物安全性信号远离灾难 | Elastic 博客

跳至主要内容

新发布

Forrester 波特图领导者，2025年第二季度

访问报告

关于我们合作伙伴支持|EN登录

[](https://www.elastic.co/)

  • Elasticsearch

##### Elasticsearch 用于...

##### Elasticsearch 组件

##### 部署选项

  • 解决方案

##### 搜索

概览

##### 可观察性

概览

##### 安全性

概览

  • 企业

##### 为什么选择Elastic？

知识中心

##### 行业

金融服务制造业公共部门零售电信查看所有行业

##### 更好的组合

##### 荣誉

##### 客户案例

查看所有客户故事

[搜索 Docusign 使用Elasticsearch每日处理数百万次e签名搜索](https://www.elastic.co/customers/docusign)

[安全 UOL 使用Elastic Security将事件解决时间缩短80%](https://www.elastic.co/customers/uol)

[可观测性 Pepsi 使用Elastic Observability提高效率并降低MTTR 30%](https://www.elastic.co/customers/pepsico)

  • 资源

##### 启动

##### 学习

##### 连接

##### 获取帮助

定价文档

搜索

立即试用联系销售

博客

公司

* 解决方案

FDA 每年收到大约两百万份不良药物事件报告。制药公司必须在收到严重报告后的 15 个日历日内检测出安全信号。实际上，药物流行病学分析师需要手动审查散落在 FDA 不良事件报告系统（FAERS）、EudraVigilance、电子健康记录（EHRs）和社会媒体上的文件。检测过程通常需要数周到数月的时间，而每个信号就需要分析师花费 40 多小时。

延迟的成本并非虚无缥缈。默克未能从万络（Vioxx）中捕捉到心脏信号，导致了高达 48.5 亿美元的和解费用。（来源：Merck's failure to catch cardiac signals from Vioxx cost $4.85 billion in settlements.）单个未检测到的信号可能会触发罚款，金额在 10 亿至 100 亿美元之间。但真正的成本在于患者在没有人足够快地注意到的情况下继续服用本应被标记的药物。

我是独立开发者 Prajwal Sutar，在过去一年中一直在推动真实数据通过基于大型语言模型（LLM）的数据管道进行采集、异步编排和多代理协调。我没有找到任何单一工具能够将信号检测、报告生成和升级整合在一个自动化管道中，因此我在 Elasticsearch Agent Builder 黑客松期间构建了一个这样的工具。

PHAROS

#### 观看 PHAROS 的演示

PHAROS 从 FDA FAERS API 中提取不良事件报告，运行 WHO 标准统计分析以发现安全信号，生成实际的监管文书工作，并将警报推送到 Slack、Jira 和电子邮件——从数据采集到发出警报，整个过程不到 60 秒。

观看演示视频

PHAROS 做什么

PHAROS（药物流行病学自主推理和监督系统）从 FDA FAERS API 中提取不良事件报告，运行 WHO 标准统计分析以发现安全信号，生成实际的监管文书工作（例如，MedWatch 3500A 表格、PSUR 部分和案例叙述），并将警报推送到 Slack、Jira 和电子邮件。

从数据采集到发出警报，整个过程不到 60 秒。

这是一个端到端的过程。假设有一种虚构的药物 CARDIVEX，其 50 份不良事件报告均显示在日本、韩国和印度突然视力丧失的情况。这些报告会被索引。在一分钟内，系统检测到了 CARDIVEX/视力丧失的上报比例（PRR）为 18.94，并识别出了日韩印地理集群，生成了一份 MedWatch 3500A 表格和 PSUR 部分，发送了一条 Slack 警报到 #safety-critical，创建了一个 Jira P1 任务，并向安全官员发送了电子邮件。所有操作都会记录在 pharos-audit-log 中——因为在制药行业，如果没有记录下来，那就没有发生过。

四个代理共同处理这一任务，每个代理都有不同的职责。

我将系统拆分，因为这些任务足够不同，单个代理在所有任务上都只能做到一般般。监控数据峰值的技能不同于计算统计比率，后者又不同于编写监管文件，再者，凌晨两点决定谁需要被叫醒的技能也完全不同。每个代理都会获得一个针对其特定任务调整过的系统提示，并且温度设置也相应匹配：ANALYST以0.0运行，因为你不需要创意性的PRR数字；SCRIBE以0.2运行，用于受控文本生成；SENTINEL则以0.1运行。

监视者

SENTINEL 监控 pharos-adverse-events 索引中的数据峰值。它使用 ES|QL 将过去7天的报告数量与90天的基线进行比较。如果某种药物的数据量出现三倍的增长，SENTINEL 将触发一个Elastic工作流，启动ANALYST进行进一步分析。在CARDIVEX运行中，它捕捉到了15倍的数据峰值。

检测者

ANALYST 是真正的检测发生的地方。WHO PRR计算完全在ES|QL中进行——STATS用于计数，EVAL用于比率计算，WHERE用于阈值设定——跨越药物-反应对。然后，它使用BUCKET(report_date, 1 week)进行时间序列分析，以捕捉每周聚类现象，基于geo.country_code进行地理聚合，并采用BM25与密集向量搜索相结合的方法来查找相似的历史信号。严重性分类如下：PRR ≥ 5.0且病例数≥5为CRITICAL，PRR ≥ 2.0且病例数≥3为HIGH，其余情况归入MONITORING。确认的信号会被写入pharos-signals。

编写者

SCRIBE 接收确认的信号并生成三种类型的文档：MedWatch 3500A、PSUR Section VI 和案例叙述。它从不良事件索引中提取最多100份支持案例报告，并生成文档并将它们索引到pharos-regulatory-reports中。

行动者

HERALD 是行动层。CRITICAL信号会触发Slack告警（使用Block Kit格式化）、Jira P1票务以及发送给安全官员和安全副总裁的电子邮件。HIGH信号会触发Slack告警、Jira P2票务以及发送给安全官员的电子邮件。MONITORING信号会累积成每周摘要。如果CRITICAL信号未得到响应，2小时的升级超时机制会重新提醒安全副总裁。

代理之间的交接全部通过Elastic工作流进行——总共九个工作流涵盖了代理间的协调、cron定时的FAERS数据摄入、Slack/Jira/邮件派发、审计日志记录以及升级超时机制。

让统计保持在Elasticsearch内部

我故意选择了在ES|QL中进行PRR计算，而不是将数据拉入Python。一开始我以为需要使用pandas来进行统计工作。但实际上并非如此。

完整的WHO PRR公式、计数、比率计算、阈值设定以及时间序列分桶都在ES|QL查询中完成。代理调用ES|QL工具，处理结果并写回——没有使用pandas，也没有外部计算或数据传输瓶颈，统计结果会随着集群扩展而扩展。

ES|QL在任意分析方面不如pandas灵活，但对于WHO公式和每周的时间序列分桶，它处理得非常干净利落。去掉那层中间的Python层比我预期的要简化得多——代理只需要查询和推理，而且出错的可能性也减少了。

使流程运转的索引设计

PHAROS运行在四个Elasticsearch Serverless索引上，而主要的pharos-adverse-events索引是我花费最多设计时间的一个。

该索引包含了一个自定义的临床文本分析器，带有snowball词干提取功能，用于叙事搜索；一个基于关键词分词器的drug_name分析器，用于精确匹配药物名称；1,536维的密集向量字段，用于叙事嵌入；地理坐标点用于地理聚类；以及嵌套映射用于反应。每个代理所需的查询，包括模糊叙事搜索、精确药物查找、地理聚合和语义相似性，都由索引设计支持。其他三个索引更为简单：pharos-signals存储了带有PRR评分和分析师推理链的检测信号，pharos-regulatory-reports保存了生成的文档，而pharos-audit-log记录了每个代理操作的时间戳。

几乎打破流程的平凡问题

让LLMs可靠地返回结构化的JSON数据是我未曾预料到的挑战。

你请求LLM返回JSON，它却用三段解释文字包裹着JSON，或者在markdown代码框内返回JSON，或者先是一段对话式的前言，随后才是JSON，最后附带一段有用的总结。代理之间传递的是结构化数据，因此每个响应都需要清晰解析。无论你的信号检测有多好，如果ANALYST的输出无法可靠地被SCRIBE读取，那都是无用功。

我花费了很多时间调整系统提示，并最终编写了一个能够处理原始JSON、markdown代码框以及嵌入在自然语言中的JSON的提取函数。这并不是有趣的工作，但它决定了一个多代理流程是否能够真正运行，还是仅仅演示效果良好。

首先修复的问题

目前的PRR计算是一个点估计。一个生产型的药物流行病学监测系统需要χ²置信区间和贝叶斯IC评分。现有的数据模型已经准备好了ic_score字段，只是使用了近似值而非正确的贝叶斯计算。如果有更多时间，我会首先改变这一点。

系统还把“视力模糊”和“视力丧失”视为单独的事件。下一步是引入MedDRA本体意识的反应分组，以便系统可以跨相关术语捕捉信号，而不是将每个字符串视为独立个体。之后，我会将EudraVigilance数据与FAERS数据结合，进行跨大陆的相关性分析。

更广泛的观点

每年有200万份不良事件报告落到某人的办公桌上，当前的答案是更多的分析师进行更多的手动审查。PHAROS的论点是答案应该是代理执行WHO统计、生成文书工作并在分析师打开笔记本电脑之前将其升级给正确的人。

PHAROS 是基于 MIT 许可证的开源项目。如果你从事药物警戒或监管事务，并希望将其应用于真实数据，请与我们联系。

[帕杰夫·苏塔尔](https://www.elastic.co/blog/author/prajwal-sutar)

独立开发者，

帕杰夫·苏塔尔是一名专注于人工智能系统和大规模数据管道的独立开发者。

GitHub_·_演示_·_LinkedIn

_本博客中描述的任何功能或特性的发布和时间安排完全由 Elastic 单独决定。目前不可用的功能可能无法按时或全部推出._

_在本文中，我们可能使用或引用了第三方生成式 AI 工具，这些工具归其各自的所有者所有并运营。Elastic 对这些第三方工具没有控制权，也不对其内容、操作或使用负责，也不对因使用此类工具而可能产生的任何损失或损害承担责任。请谨慎使用 AI 工具处理个人、敏感或机密信息。您提交的数据可能会用于 AI 训练或其他用途。无法保证您提供的信息会得到安全或保密处理。在使用之前，您应熟悉任何生成式 AI 工具的隐私政策和服务条款._

_Elastic、Elasticsearch 及相关标志是 elastic B.V. 在美国和其他国家的商标、标志或注册商标._

分享

免费试用 Elastic Cloud

选择您喜欢的云提供商快速启动一个完整的部署。作为 Elasticsearch 的幕后公司，我们将我们的功能和支持带给您的云端 Elastic 集群。

开始免费试用

图像 28: Elastic 搜索 AI 公司
图像 28: Elastic 搜索 AI 公司

关注我们

投资者关系

关于我们

加入我们

合作伙伴

信任与安全

投资者关系

杰出奖

© 2026. elasticsearch B.V. 保留所有权利

本网站及其所有相关的内容、软件、讨论论坛、产品和服务仅用于专业用途。不打算或引导消费者使用本网站或其内容。

Elastic、Elasticsearch 及其他相关标志是 elasticsearch B.V. 在美国和其他国家的商标、徽标或注册商标。

Apache、Apache Lucene、Apache Hadoop、Hadoop 和 HDFS 以及黄色大象标志是 Apache Software Foundation 在美国和其他国家的商标。

其他品牌名称、产品名称或商标归其各自的所有者所有。

数据收集通知 | 您的隐私选择

![Image 34: 加利福尼亚州消费者隐私法(CCPA)退出图标](blob:http://localhost/ef7e8ea9ad85f0635b74ccfdf73c32f1)

Image 39
Image 39