PHAROS：4つのエージェント、60秒、1つの医薬品安全性シグナルの見逃しが大惨事に

それぞれの業務内容が大きく異なるため、一人の担当者では全ての業務を中途半端にこなすことになると考え、システムを分割しました。ボリュームスパイクを監視するスキルは、統計的比率を計算するスキルとは異なり、規制文書を作成するスキルとも異なり、午前2時に誰に連絡を取るかを決めるスキルとも異なります。各エージェントには、特定のタスクと温度設定に合わせて調整されたシステムプロンプトが設定されます。ANALYSTは0.0で実行されます。これは、PRR数値に創意工夫を求めないためです。SCRIBEは制御されたテキスト生成のために0.2で実行します。SENTINELは0.1で実行します。

SENTINELはpharos-adverse-eventsインデックスのボリューム急増を監視します。ES|QLを使用して過去7日間のレポート量を90日間のベースラインと比較します。ある薬剤のレポート量が3倍に急増した場合、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、1.5を超えるものはすべてMONITORINGの対象となります。確認されたシグナルはpharos-signalsに書き込まれます。

SCRIBEは確認済みのシグナルを検出し、MedWatch 3500A、PSURセクションVI、症例ナラティブの3種類の文書を生成します。有害事象インデックスから最大100件の関連症例レポートを取得し、文書を作成してpharos-regulatory-reportsにインデックス化します。

HERALDはアクションレイヤーです。CRITICALシグナルはSlackアラート（Block Kitフォーマット）、Jira P1チケット、安全担当者と安全担当副社長（VP of Safety）へのメールを受け取ります。HIGHシグナルはSlack、Jira P2、安全担当者へのメールを受け取ります。MONITORINGシグナルは週次ダイジェストに蓄積されます。2時間のエスカレーションタイムアウトにより、CRITICALシグナルが未確認の場合、安全担当副社長（VP of Safety）に再アラートが送信されます。

エージェント間の引き継ぎはすべてElasticワークフローを通じて行われます。合計9つのワークフローがあり、エージェント間の連携、cronスケジュールによる毎晩のFAERSデータの取り込み、Slack/Jira/メールによる配信、監査ログの記録、エスカレーションのタイムアウトなどを網羅しています。

PRRの計算をPythonに取り込むのではなく、ES|QL内で行うという意図的な選択をしました。始めるにあたって、統計処理にはpandasが必要になるだろうと想定していましたが、間違いでした。

完全なWHO PRR式、カウント、比率計算、しきい値、時間的バケット化はすべてES|QLクエリとして実行されます。エージェントはES|QLツールを呼び出し、結果に基づいて推論を行い、結果を書き戻します。pandasも外部コンピューティングもデータ転送のボトルネックも発生しません。統計情報はクラスターに合わせてスケールします。

ES|QLは、任意の分析を行うにはpandasほど柔軟ではありません。しかし、WHOの計算式や週ごとのBUCKET集計に関しては、きちんと処理してくれます。中間層のPythonを削除したことで、予想以上にアーキテクチャが簡素化されました。エージェントはクエリと推論だけを行うため、問題が発生する可能性のある箇所が1つ減りました。

PHAROSは4つのElasticsearch Serverlessインデックスで動作しますが、主要なpharos-adverse-eventsに最も多くの設計時間を費やしました。

ナラティブ検索用のスノーボールステミングを備えたカスタムのclinical_text_analyzer、完全一致の薬物マッチング用のdrug_name_analyzer、ナラティブ埋め込み用のdense_vectorフィールド（1,536次元）、地理的クラスタリング用のgeo_point、リアクション用のnestedマッピングがあります。エージェントが必要とするすべてのクエリ、あいまいなナラティブ検索、完全一致の薬物検索、地理的アグリゲーション、意味的類似性はインデックス設計によってサポートされています。他の3つのインデックスはもっと単純で、pharos-signalsは検出されたシグナルをPRRスコアとアナリストの推論チェーンで格納し、pharos-regulatory-reportsには生成されたレポートが格納され、pharos-audit-logはエージェントのすべてのアクションにタイムスタンプを付けます。

LLMから構造化されたJSONを確実に返させることが想定外の難題となりました。

LLMにJSONを要求すると、3段落の説明に包まれたJSON、マークダウンのコードフェンス内のJSON、または会話の前文に続いてJSONと有用なまとめが返ってきます。エージェントは互いに構造化データを渡し合うため、すべての対応は正しく解析される必要があります。ANALYSTの出力がSCRIBEによって確実に読み取れない場合、シグナル検出の精度がどれほど優れていても意味がありません。

システムプロンプトの調整に多くの時間を費やし、最終的に生のJSON、マークダウンコードフェンス、そして自然言語内に埋め込まれたJSONを処理するJSON抽出関数を書きました。面白い作業ではないですが、マルチエージェントパイプラインが実際に動作するか、それとも単にデモとして見栄えが良いだけかを決定づける類のものです。

PRRの計算は現在、点推定値に基づいています。実際の医薬品安全性監視システムには、カイ二乗信頼区間とベイズICスコアリングが必要です。データモデルにはすでにic_scoreフィールドが設定されていますが、適切なベイズ計算ではなく近似値を使用しています。時間があれば、まずそこを修正したいところです。

このシステムは、「視界のぼやけ」と「視力喪失」を別々の事象として扱います。次のステップは、MedDRAのオントロジーを意識したリアクションのグループ化です。これにより、システムは、各文字列を独立したものとして扱うのではなく、関連する用語間のシグナルをキャッチできます。その後、大陸間の相関関係を調べるために、FAERSのデータに加えてEudraVigilanceのデータも取得します。

毎年200万件の有害事象レポートが誰かの机に届く中、現時点での解決策はより多くのアナリストがより多くの手動レビューを実行することですが、PHAROSは、WHOの統計データを処理し、必要な書類を作成し、適切な担当者に問題をエスカレーションするエージェントが、アナリストがノートパソコンを開く前にすべてを完了させるという解決策を提示します。

PHAROSはMITのオープンソースです。医薬品安全性監視や薬事規制の分野に関わっており、これを実際のデータで検証してみたいという方がいらっしゃいましたら、ぜひご連絡ください。