信頼性の高いエージェンティックAIシステムの構築：BayerのPRINCEプラットフォームに関するケーススタディ

エグゼクティブサマリー

Bayerは、構造化データベースと非構造化PDFレポートにわたる、断片化された大量の前臨床データを活用するという課題を解決するために、Preclinical Information Center (PRINCE) を開発しました。エージェンティックなRetrieval-Augmented Generation (RAG) システムを実装することで、Bayerは基本的なキーワード検索ツールから、複雑な推論、データ検索、および規制文書のドラフト作成が可能なアクティブなリサーチアシスタントへと移行しました。核心となる教訓は、規制環境における信頼性を確保するために、実用的なエージェンティックAIには、context engineering（モデルが見るものを制御する）とharness engineering（モデルの動作を制御する）の組み合わせが必要であるということです。

PRINCEの進化：検索からアクションへ

PRINCEは、前臨床研究ニーズの増大する複雑さに対応するため、3つの戦略的フェーズを経て進化してきました：

  1. Search: サイロ化された構造化研究メタデータを検索可能な形式に統合する統一ゲートウェイ。
  2. Ask: 非構造化データ、特に過去のPDF研究レポートに対して自然言語クエリを可能にするRAGの統合。
  3. Do: 現在のエージェンティックなフェーズ。マルチエージェントシステムを利用して複雑なワークフローをオーケストレーションし、規制文書をドラフトします。

技術アーキテクチャとオーケストレーション

PRINCEは、React UIを備えたFastAPIアプリケーションとして構築されており、バックエンドのオーケストレーションにはLangGraphを使用しています。システムは、PostgreSQL（エージェントの実行状態用）とDynamoDB（アプリケーションレベルの状態用）を介して状態を管理します。

マルチエージェント・ワークフロー

システムは、「コンテキストの汚染」を防ぎ、制御性を向上させるために、特化したエージェント階層を採用しています：

  • Clarify User Intent: 曖昧さを解消し、検索が始まる前に適切なデータソースを提案する「fail-fast」メカニズムとして機能します。
  • Think & Plan (Process Reflection): システムが自身の軌跡を評価し、拡張し続けるドメイン固有のオプションライブラリから最も適切なツールを選択する、専用の推論スペースです。
  • Researcher Agent: RAG（Amazon OpenSearch経由の非構造化PDF用）とText-to-SQL（Amazon Athena経由の構造化メタデータ用）を組み合わせたハイブリッド・リトリーバーです。
  • Reflection Agent (Data Reflection): 検索されたデータがクエリに答えるのに十分かどうかを評価します。不足がある場合は、Think & Planエージェントに対して追加の質問を生成します。
  • Writer Agent: 最終的な回答を合成し、すべての主張が元のドキュメントとページ番号への詳細な引用を用いてコンテキストに根立っていることを保証します。

信頼性と信頼のためのエンジニアリング

規制された製薬環境において、正確性と検証可能性は譲れない条件です。Bayerは、システムが境界内に留まり、観測可能であることを確実にするために、いくつかの「harness engineering」パターンを実装しました。

Context Discipline

より大きなコンテキストウィンドウが利用可能であるにもかかわらず、PRINCEは厳格なコンテキスト・エンジニアリングを使用しています。異なるエージェントは、異なる情報のサブセットを受け取ります：Think & Planにはプランニング・コンテキスト、Researcherには検索コンテキスト、Reflection Agentにはエビデンス・コンテキスト、そしてWriterには合成コンテキストです。これにより、モデルが制御しにくくなるのを防ぎ、デバッグを簡素化します。

Resilience and Error Recovery

複雑なマルチステップ・タスクの実行中にシステム全体の失敗を防ぐため、アーキテクチャには以下が含まれます：

  • State Persistence: LangGraph checkpointerは状態をPostgresに保存するため、システムは失敗が発生した正確なノードから再開できます。
  • LLM Fallbacks: プライマリ・モデルが数回の試行後に失敗した場合、サービス継続性を維持するために、システムは自動的に代替モデルまたはプロバイダーに切り替え、継続性を維持します。
  • User-Initiated Retries: ユーザーは失敗したクエリを、永続化された状態を介して、以前に成功したステップをスキップして手動で再試行できます。

Verification and Evaluation

信頼は、二重の評価戦略を通じて維持されます：

  • Dataset Evaluations: Langfuseを使用して、精選されたエキスパート・データセットを用いて、Faithfulness、Answer Relevancy、およびContext Relevancyを測定します。
  • Live Traffic Evaluations: ハルシネーション（幻覚）と実世界のパフォーマンスをモニターするために、実際のユーザー・クエリに対して毎日バッチ・ジョブを実行します。

データ品質の向上

過去のメタデータは不完全または不正確であることが多いため、Bayerは**Named Entity Recognition (NER)**を使用したユーティリティ・システムを開発しました。このシステムは、PDFからエンティティ（例：化合物名、用量）を抽出し、Amazon Athenaデータベースを自動的に強化します。整合性を維持するため、各抽出には信頼度スコアが割り当てられます。信頼度の高い更新は自動的に行われ、信頼度の低いものは人間によるレビュー用にフラグが立てられます。

批判的分析とコミュニティの視点

技術アーキテクチャは包括的ですが、コミュニ，ティの議論では、このようなシステムの実際の効力に関するいくつかの論争点についてが指摘されています：

  • Performance Gaps: 関連する研究論文によれば、チャットボットがユーザーのニーズを完全に満たす能力については、平均スコアが低い（3.1/5.0）ことが指摘されており、これは高度なエージェンティック・アーキテクチャであっても、完全な実用性において苦戦していることを示唆しています。
  • Data vs. Agent Tuning: 業界の実務家は、「作業の99%」はエージェントのチューニングよりもデータ・クリーニングにあると主張しており、これは、複雑なエージェント階層よりも、クリーンなデータベースがより大きな影響を与えると示唆しています。
  • Architecture "Vibes": 一部の開発者は、Researcher、Writer、およびReflectionエージェントへの分解が、経験的なエビデンスに基づいているのか、それとも単なる「満足感のあるフローチャート」であり、より単純なプロンプティング戦略よりも複雑さを加えるだけのものなのか疑問を呈しています。

Sources