前臨床薬剤開発は本質的に複雑でデータ集約型です。 研究者は、この重要な段階で生成される膨大な量の情報に効率的にアクセスし、 分析するという大きな課題に直面しています。 従来のキーワードベースの検索方法は、しばしば厳格なブール論理に依存しており、 前臨床研究の質問の微妙で複雑な性質に直面すると、しばしば不十分です。

大規模言語モデル（LLM）の出現は、変革的な機会をもたらしました。Retrieval-Augmented Generation（RAG）は、LLMの生成能力と情報検索システムの精度を組み合わせることで、有望な技術として登場しました。 このアプローチは、前臨床データのアクセス方法に革命をもたらす可能性を秘めており、 研究者が自然言語で複雑な質問を投げかけ、独自のデータに基づく正確で文脈豊かな回答を得られるようにします。

この可能性を早期に認識したBayerは、これらの技術が前臨床研究における長年の課題にどのように対処できるかを探求することにコミットしました。

本記事では、その過程を共有します。Bayerの生成AIへの初期投資が、Agentic RAG上に構築されたエージェント型AIシステムであるPRINCEを生み出した経緯についてです。このケーススタディでは、前臨床データ検索を困難な迷路から直感的な会話型体験へと変革する過程における、技術的アーキテクチャ、エンジニアリング上の決定、および学んだ教訓を探求します。

PRINCEの背後にある多くのエンジニアリング上の決定は、現在ではコンテキストエンジニアリングとハーネスエンジニアリングの観点から理解できますが、システムが最初に設計された時点ではこれらの用語は使用していませんでした。コンテキストエンジニアリングは、各モデルがどのような情報を受け取り、何を受け取らないか、そして研究、振り返り、執筆などの専門的なステップ間でコンテキストがどのように移動するかを形成しました。ハーネスエンジニアリングは、モデルの周囲の足場を形成しました。オーケストレーション、ツールの境界、状態の永続化、リトライ、フォールバック、検証、振り返りループ、可観測性、および人間によるレビューです。

本記事は技術的アーキテクチャとエンジニアリング上の課題に焦点を当てていますが、Frontiers in Artificial Intelligenceに掲載された私たちの論文では、製品の進化とビジネスへの影響についてより詳細に取り上げています。

課題：前臨床データの迷路をナビゲートする

Bayerの前臨床研究の状況は、多くの大手製薬組織と同様に、多様で広範なデータ群によって特徴づけられます。これには、さまざまな研究から得られる高度に構造化されたデータセットに加えて、研究報告書、 論文、規制当局への提出物などのテキスト文書に埋め込まれた膨大な非構造化 情報が含まれます。研究者はこの情報に効果的にアクセスし、分析する上で、しばしば大きな障害に直面しました：

  • データサイロ：情報は多数の異なるシステムやリポジトリに断片化・分散しており、特定の化合物や研究に関連する前臨床データの包括的・全体的なビューを得ることが極めて困難でした。
  • 限定的な検索機能：従来のキーワードベースの検索エンジンは、前臨床の専門用語や研究質問の複雑さや多様性に対応できず、しばしば無関係、不完全、または圧倒的な結果をもたらしました。
  • 時間を要する手動分析：複数の文書から特定の洞察を抽出したり情報をまとめるには、かなりの手作業が必要であり、研究者の貴重な時間を中核的な科学活動から奪っていました。

これらの内在的な課題は、前臨床データの検索と分析に対して、より効率的でインテリジェントかつ統合されたアプローチの必要性を明確に示していました。

解決策：PRINCE - 進化するプラットフォーム

これらの課題に対処するため、BayerはPreclinical Information Center（PRINCE）プラットフォームを開発しました。PRINCEは前臨床データへの統一されたゲートウェイとして構想され、最初は以前にサイロ化されていた構造化研究メタデータを統合し、「検索可能」な方法で公開することに焦点を当てました。 この初期段階では、ユーザーは高度なフィルタを適用し、主に構造化研究メタデータから情報を取得できました。

しかし、Bayerの貴重な前臨床知識の大部分は、数十年にわたって蓄積された非構造化PDF研究報告書の中に存在します。長年にわたる多数のシステム移行により、これらの報告書に関連する構造化メタデータは不完全、欠落、または誤った注釈を含む可能性がありました。重要なのは、権威ある「ゴールドスタンダード」情報が、承認済みのPDF研究報告書の中に一貫して存在していたことです。

生成AI、特にRAGの出現は、この非構造化データの宝庫を解き放つ鍵となりました。RAG機能を統合することで、PRINCEはフィルタベースの「検索」ツールから自然言語で「質問」するシステムへとパラダイムをシフトし始め、研究者がこれらの研究報告書の内容を直接クエリできるようにしました。

この進化は、PRINCEが3つの異なる段階を経て進化したことを反映しています：

  1. Search：最初の段階では、数千の非臨床研究報告書への統一されたゲートウェイを作成し、さまざまな前臨床領域の複数の社内データサイロを、主に構造化メタデータを活用して検索可能な形式に統合することに焦点を当てました。
  2. Ask：この段階では、Retrieval Augmented Generation（RAG）を活用したAI搭載の質問応答システムを導入しました。これにより、研究者は自然言語で質問を投げかけることで、過去の報告書のスキャン済みPDFを含む非構造化データから直接洞察を得られるようになりました。
  3. Do：現在の段階では、PRINCEを複雑なタスクを実行できるアクティブなリサーチアシスタントとして位置づけています。これはマルチエージェントシステムの統合を通じて達成されており、プラットフォームが複雑なクエリを処理し、ワークフローをオーケストレーションし、規制文書のドラフト作成などの活動を支援できるようにします。

SearchからAsk、Doへの意図的な進化は、前臨床開発における効率とイノベーションの向上に対する業界のニーズに対する戦略的な対応を表しています。研究者に前臨床データへのアクセス、分析、活用をますます強力なツールを提供することで、PRINCEはより迅速なデータ駆動型の意思決定を可能にし、不必要な実験の必要性を減らし、最終的に、より安全で効果的な治療法の開発を加速させることを目指しています。

システムアーキテクチャ：信頼性の高いエージェント型RAGシステムのエンジニアリング

このシステムは、Reactで構築された会話型UIとして機能し、堅牢なバックエンドインフラストラクチャによって支えられています。複雑なクエリを処理し、正確で文脈豊かな回答を提供するために設計されたアーキテクチャは、LangGraphを使用してオーケストレーションされ、FastAPIアプリケーションを介して提供されます。

Figure 1は、UI、バックエンド、データストア、LLMフォールバック、可観測性などのシステムコンテキストを提供し、Figure 2は、システムが専門化されたエージェントをどのように調整するかを詳細に示しています。

system-container-view.png

Figure 1: システムコンテキストとサポートプラットフォーム。

  • ユーザーリクエスト：ユーザーがReactで構築された会話型UIを通じてリクエストを送信すると、プロセスが開始されます。
  • オーケストレーション：ユーザーのリクエストはバックエンドのLangGraphベースのオーケストレーションレイヤーにルーティングされます。このワークフローエンジンは、ユーザーの意図の明確化、思考と計画、研究（RAGとText-to-SQLを使用）、データの完全性の検証、そして最後にWriterエージェントによる応答生成という複数段階のプロセスを調整します。 ワークフローには、続行する前にデータの完全性を確保するための意図的な一時停止ポイントとフィードバックループが含まれます。（このエージェント型ワークフローの詳細は、後ほど専用のセクションで説明します。）
  • データ取得と状態管理：Researcherエージェントは、包括的で分散型のデータエコシステムと相互作用します：
    • すべての研究報告書のベクトル表現はOpenSearchに保存され、情報検索のためのコアナレッジベースを形成します。
    • さまざまなETLおよびハーモナイゼーションプロセスから得られた厳選された構造化データは、Athenaを介してアクセスされます。
    • エージェント実行の状態は meticulous に追跡されます。各論理ステップ（LangGraphノードの実行）後、対応する状態はLangGraph checkpointerを使用してPostgreSQLに永続化されます。
    • より広範なアプリケーションレベルの状態はDynamoDBで管理されます。
  • システムは、OpenAI、Anthropic、Google、およびオープンソースプロバイダーのモデルをホストする内部GenAIプラットフォームを活用します。これらのプラットフォームは、すべてのモデルを統一されたOpenAI互換エンドポイントを介して公開するため、モデルを簡単に切り替えて各タスクに最適なツールを選択できます。また、制御プレーンも管理し、レート制限やその他の安全策を適用して不正使用を防止します。
  • レジリエンスとエラーハンドリング：堅牢性は重要な設計原則であり、複数のフォールバックメカニズムが用意されています：
    • 特定のLLMが失敗した場合、システムはサービス継続性を確保するため、代替モデルまたはプラットフォームにフォールバックする前にリクエストを数回自動的に再試行します。
    • 一時的な障害から迅速に回復するため、リトライは個々のLLM呼び出しレベルと論理ノードレベル（エージェントの計画におけるステップ全体）の両方で実装されます。
    • また、エージェントにはエラーのコンテキストが提供され、応答として異なる軌道や代替の行動計画を立てることができます。
  • 可観測性と評価：システム全体のパフォーマンスと信頼性が監視されます：
    • 一般的なシステムの健全性とメトリクスはCloudwatchを使用して追跡されます。
    • Langfuseは主要な可観測性ツールとして機能し、本番トラフィックの詳細なトレースを提供します。これにより、問題の詳細なデバッグが可能になります。さらに、評価データセットはLangfuse内に保存・管理され、パフォーマンススコアの分析や特定の失敗の診断が容易になります。評価はRAGAS評価フレームワークを使用して行われます。ライブトラフィックの評価は毎日行われ、データセットの評価はコアワークフロー、プロンプト、または基盤となるモデルに重大な変更が加えられた際に実施されます。
  • 最終応答：エージェントがリクエストを処理し、満足のいく応答を生成すると、会話型UIに送り返され、ユーザーに提示されます。

このアーキテクチャを通じて貫かれる設計原則は、コンテキストの規律です。より大きなコンテキストウィンドウがあっても、各エージェントが見る情報を選択的にする必要性はなくなりません。初期の反復では、コンテキストに過剰な情報を入れると、システムの制御や評価が難しくなりました。そのためPRINCEは、プロンプトを利用可能なすべての情報を入れる大きなコンテナとして扱うことを避けます。代わりに、異なるステージが異なるコンテキストを受け取ります：Think & Planのための計画コンテキスト、Researcher Agentのための検索コンテキスト、Reflection Agentのための証拠コンテキスト、Writer Agentのための合成コンテキストです。これによりコンテキストの汚染が低減され、システムのデバッグ、評価、改善が容易になります。

これらのステップにより、洗練されたマルチエージェントアーキテクチャと多様な強力なツールおよびデータソースを活用することで、システムは幅広い複雑なクエリに対して信頼性が高く、文脈的に関連する回答を提供できます。

エージェント型RAGシステム

PRINCEは、複数のステップ、推論、および異なるツールやデータソースとの相互作用を必要とする複雑なユーザーリクエストを処理するため、エージェント型RAGシステム（Figure 2）を組み込んでいます。このセットアップはLangGraphを使用して実装され、全体のワークフローをオーケストレーションし、特定のタスクのためにResearcher Agent、Writer Agent、およびReflection Agentを活用します。システムは堅牢で信頼性が高く、一部のコンポーネントが故障してもシステムが継続して機能できるように、複数のフォールバックメカニズムが用意されています。

new-research-workflow.png

Figure 2: 研究ワークフロー。

ユーザーの意図の明確化

Clarify User Intentステップは、曖昧さに対する最初の防衛線として機能します。毒性学や薬理学などの多様な領域を含むようにシステムが拡大するにつれ、単純なユーザークエリがしばしば曖昧になり、適切なツールを自動的に選択することが困難になりました。すべてのデータソースにわたる高コストの試行錯誤に依存するのではなく、システムは特定の領域やデータタイプを特定するための明確化質問を積極的に行います。

これにより、システムは正しいツールをターゲットにするために必要な制約でクエリを強化します。また、UIでのdomain-level selectionの開発により、ユーザーが事前に有効なツールをフィルタリングできるように最適化しています。摩擦をさらに低減するため、システムはAI支援のソース推奨も提供します。ユーザーがデータソースを選択していない場合、または明確な焦点なしに複数のソースを選択した場合、モデルはユーザークエリの背後にある意図を分析し、最も関連性の高いソースを提案します。ユーザーは完全な制御を保持し、推奨を受け入れ、調整、または上書きできるため、ドメインの専門知識が常に最終決定権を持ちます。この「fail-fast」メカニズムは、曖昧なクエリでの無駄な実行を防ぎますが、意図がすでに明確な場合にはシステムが邪魔にならないよう慎重に調整されています。

コンテキストエンジニアリングの観点から、このステップはワークフローにおける最初の組み立て決定です。検索が始まる前に、どのツール、領域、データソースが範囲内にあるかを制約し、後続のエージェントがオープンエンドではなく焦点を絞った問題を受け取ることを保証します。

Think & Plan: プロセスリフレクション

Think & Planステップは、ユーザーのリクエストを満たすための戦略を考案する責任を負います。この重要なコンポーネントは、行動を起こす前に次のステップについて推論するための専用スペースをシステムに提供します。これはAnthropicのThink toolに着想を得た技術です。 重要なのは、このステップがプロセスリフレクションを実行することです。エージェントが最終目標に向かって正しい進捗を遂げ、正しい軌道に乗っているかどうかを評価するものであり、データ自体を評価するものではありません。

多くの逐次的なアクションを伴うマルチステップのエージェント型ワークフローでは、プロセスリフレクションは不可欠です。複雑なタスクを完了するためにシステムが50ステップを実行する必要があるシナリオを考えてみましょう。各局面で、システムは「これらのステップを正しい方法で実行しているか？期待通りの進捗を遂げているか？現在の軌道はユーザーの目標につながっているか？」と自問しなければなりません。Think & Planステップはこのメタ認知能力を提供し、システムが自らのワークフローを振り返り、戦略を適宜調整できるようにします。

この「思考空間」は、複数のツール呼び出しを伴うシナリオで特に価値があることが証明されています。 PRINCEが最初に開発された時点では、RAGベースの検索用ツールとText-to-SQLクエリ用ツールのわずか2つしかありませんでした。しかし、システムの機能を拡張するためにさらにデータソースを統合するにつれ、利用可能なツールの数は大幅に増加しました。このツールの爆発的な増加に伴い、固有の課題が生じました。異なるツール間の懸念事項やドメイン境界の重複です。

たとえば、複数のツールが類似しているが微妙に異なる目的（構造化メタデータのクエリ対非構造化報告書のクエリ、または研究サマリーの取得対詳細な実験データの取得など）を果たす場合があります。類似のドメインに属するが、わずかに異なるデータを扱うツールが提示された場合、LLMは特定のクエリに対して最も適切なツールを選択するのに苦労することがありました。専用の思考ステップを導入することで、システムはどのツールがユーザーの意図に最も合致するかを明示的に推論し、各利用可能なツールの特性を評価し、より情報に基づいた決定を下すことができます。このアプローチにより、ツール選択の精度が劇的に向上しました。

ツール選択を超えて、Think & Planステップはマルチステッププロセスのオーケストレーションにも不可欠です。PRINCEの多くの複雑なクエリでは、一連のツール呼び出しが必要であり、あるツールの出力が次のアクションを決定する前に分析されなければなりません。たとえば、システムはまず構造化メタデータをクエリして関連する研究を特定し、次にそれらの研究IDを使用して非構造化報告書から詳細な情報を取得し、最後に結果を統合するかもしれません。プロセスリフレクションのための専用スペースがなければ、システムは各ステップが目標に近づいているかどうかを評価せずに、これらのステップを線形に実行しようとします。思考ステップを導入することで、システムは一時停止し、ワークフロー内の進捗を評価し、ユーザーのリクエストを完了するために必要な後続のツール呼び出しをインテリジェントに計画できます。

The Researcher Agent

Researcher Agentは、システムの主要な情報収集役として機能します。新しい科学領域をPRINCEにオンボーディングする際、データが構造化と非構造化の2つの主要なカテゴリに分類されることを一貫して観察しています。具体的な実装手法は領域によって異なる場合があります。たとえば、薬理学クエリではText-to-SQLにSnowflake Cortex Analystを活用する一方、毒性学ではよりカスタムな手法を用いるなどですが、これらの検索戦略の基本は一貫しています。

PRINCEが複数の前臨床領域に拡大するにつれ、フラットなツールリストを持つ単一のResearcherエージェントの管理はますます困難になります。多くのツールは「studies」、「findings」、「assays」などの類似の概念で動作しますが、ドメインに応じて異なる基盤データセット、スキーマ、規制解釈を指します。たとえば、ユーザーが「the study」と言う場合、関連するコンテキストは反復投与毒性学研究、心血管安全性薬理パッケージ、または集計された大量データテーブル内の特定のassayである可能性があり、それぞれに独自の信頼できる情報源があります。

1つのモノリシックなエージェントが重複するツールと微妙に異なるデータコントラクトを扱うことを避けるため、Researcher機能をドメイン固有のサブエージェントの階層に進化させています。この提案されたアーキテクチャでは、各ドメインエージェントが独自のツールセット（例：毒性学RAG + toxメタデータSQL、または薬理学RAG + assayレベルSQL）と、そのドメインのデータモデルがどのように機能するか、どのテーブルやインデックスが権威あるものか、主要な概念をどのように解釈するかをエンコードしたカスタマイズされたプロンプト指示を持ちます。これにより、責任が一貫性を保ち、偶発的なクロスドメインの漏洩を減らし、ドメインごとの検索動作を推論・テストしやすくすることが期待されます。

この多様な状況から洞察を効果的に収集するため、Researcher Agentは2つの異なるパターンに焦点を当てたhybrid retrieverアプローチを採用しています：

  • Retrieval-Augmented Generation (RAG)：非構造化データ、主にPDF報告書の処理用。
  • Text-to-SQL：Amazon Athenaに格納された構造化データのクエリ用。

この二重戦略により、システムは物語形式の科学報告書と定量的な実験データの間のギャップを埋めることができます。

この更新されたビジョンでは、最上位のResearcher Agentは、すべてを知る単一のコンポーネントではなく、コーディネーターとして機能するように設計されています。UIからの明確化されたユーザーの意図と明示的なドメイン選択を考慮して、クエリを適切なドメインサブエージェントにルーティングし、サブエージェントが自身の境界内でRAGとText-to-SQLをどのように組み合わせるかを決定できるようにします。このパターンは、ユーザーの視点からは「1人の研究者」のシンプルさを維持しつつ、内部的には各ドメインがシステムの残りの部分を不安定にすることなく、独自のツール、スキーマ、検索レシピを進化させることを可能にすることを目指しています。

非構造化データのためのRetrieval-Augmented Generation (RAG)

何千もの前臨床研究報告書およびその他の非構造化文書の膨大なリポジトリを考慮すると、LLMの応答をこの特定のナレッジベースにグラウンディングすることで関連する洞察を抽出するためにRAGは不可欠です。RAGパイプラインは、包括的な取り込みプロセスと高度な クエリ時アーキテクチャで構成されます。

取り込みプロセス：主に数十年にわたるPDFで構成され、複雑なテーブルを含むスキャン文書を含むことが多い前臨床研究報告書は、まずS3データレイクに一元化され、このコーパスに最適化された抽出パイプラインに渡されます。抽出されたテキストは構造化JSONに正規化され、検索に効率的でありながら十分な科学的コンテキストを保持する戦略でチャンク化されます。

各チャンクはAmazon Athenaから研究・セクションレベルのメタデータ（研究ID、化合物、種、経路、ページ、親セクションなど）で強化され、後でRAGレイヤーでの精密なメタデータフィルタリングを可能にします。最後に、これらの注釈付きチャンクは埋め込みされ、Amazon OpenSearch Serviceにインデックス化され、歴史的なコーパスと新しいまたは更新された報告書が到着する日次デルタの両方に対して、セマンティックおよびメタデータ対応の検索を支えるベクトルストアを形成します。

クエリ時RAGパイプライン：ユーザーがクエリを送信すると、システムは多段階の検索プロセスを開始します。このパイプラインは、LLMの応答をグラウンディングするために、ベクトルデータベースから最も関連性が高く信頼できる情報を効果的に検索するように設計されています。

“Were any of the following clinical findings observed in study T123456-2: piloerection, ataxia, eyes partially closed, and loose faeces?”

keyword extractor

“piloerection”, “ataxia”, “eyes partially closed”, “loose faeces”

filter extractor

eq(study_id, T123456-2)

query expander

1. Can you provide details on the clinical symptoms
reported in research T123456-2, including any
occurrences of goosebumps, lack of coordination,
semi-closed eyelids, or diarrhea?

2. In the results of experiment T123456-2, were there any
recorded observations of hair standing on end, unsteady
movement, eyes not fully open, or watery stools?

3. What were the clinical observations noted in trial
T123456-2, particularly regarding the presence of hair
bristling, impaired balance, partially shut eyes, or soft
bowel movements?

4. ... 5. ...

weighted hybrid search

retrieves ~20 chunks

0.3

0.7

re-ranker

reranker selects top 7 chunks

final prompt generator

response to user

Responding to a query issued in natural language

An LLM analyzes the query and extracts keywords

Concurrently, the LLM generates a metadata filter to narrow the search space

The LLM generates a query expander to broaden the search space

The retriever uses a weighted hybrid search to retrieve the most relevant information

The reranker refines the results to ensure the most relevant information is brought to the LLM

The final prompt generator generates the final prompt for the LLM

The responder sends the response to the user

このパイプラインを例示するため、クエリ「Were any of the following clinical findings observed in study T123456-2: piloerection, ataxia, eyes partially closed, and loose faeces?」を考えてみましょう。システムは以下のステップでこのクエリを処理します：

  • キーワード抽出：ユーザーの自然言語クエリはまずLLMによって分析されます。慎重なプロンプトエンジニアリングを通じて、モデルは文書コーパス内のキーワード検索に高度に関連するキーワード（例：「piloerection」、「ataxia」、「eyes partially closed」、「loose faeces」）を抽出するよう指示されます。
  • メタデータフィルタ生成：同時に、LLMはクエリに基づいてメタデータフィルタを生成します。たとえば、検索空間を狭めるためにeq(study_id, T123456-2)というフィルタが抽出されます。このフィルタは、モデルにさまざまな順列と組み合わせの例を提供するfew-shotプロンプティングを使用して動的に生成され、多様なフィルタリングリクエストを処理できるようにします。
  • クエリ拡張：包括的な検索を確保し、表現や用語のバリエーションを考慮するため、query expansion（マルチクエリまたはクエリリライト）が、より小さく高速なモデルによって実行されます。これにより、元の質問に基づいてn=5の意味的に類似したクエリが生成されます。例のクエリの場合、「research T123456-2で報告された臨床症状、鳥肌、協調運動障害、半閉じたまぶた、下痢の発生を含む。」などのバリエーションが含まれる場合があります。
  • ハイブリッド検索：ベクトルデータベース（Amazon OpenSearch Service）からの情報検索は、メタデータフィルタリング、セマンティックベクトル類似度検索（kNN）、およびキーワードベースの検索を組み合わせたHybrid Searchアプローチを利用します。このプロセスは以下の通り実行されます：
    • メタデータフィルタリング：前のステップで生成されたメタデータフィルタ（例：eq(study_id, T123456-2)）がベクトルデータベースクエリに直接適用されます。このフィルタは、Amazon Athenaからの取り込みプロセス中にチャンクに付加された構造化メタデータに基づいて検索空間を事前にフィルタリングし、指定された研究ID（またはその他の関連メタデータ）に関連するチャンクのみが考慮されるようにします。これにより、検索空間が数百万のベクトルから数十から数百のより管理しやすい範囲に大幅に削減され、効率と関連性が向上します。
    • 並列ハイブリッド検索実行：n=5の拡張クエリそれぞれに対して、フィルタリングされたAmazon OpenSearch Serviceベクトルデータベースに対して単一のハイブリッド検索クエリが並列に実行されます。このクエリは、セマンティックベクトル類似度検索（kNN）とキーワードベースの検索の両方を組み合わせ、OpenSearchの効率的なマルチベクトルおよびテキスト検索機能を活用します。
    • 重み付け結果スコアリング：並列に実行される各ハイブリッド検索内で、重み付けアプローチが結果に適用されます。コンテキスト理解と正確な用語マッチングのバランスを取るため、セマンティック検索結果に0.7、キーワード検索結果に0.3の重みが与えられます。この重み付けは、データに対する検索効果を最適化するために実験を通じて決定されました。
    • 結果集約と初期ランキング：すべての5つの並列ハイブリッド検索実行からの結果（重み付けスコアを持つ関連チャンクのセット）が集約されます。すべての検索結果から一意のチャンクがまとめられ、並列検索全体での最高の重み付けスコアが初期ランキングを決定するために使用されます。このステップでは、これらの集約および重み付けスコアに基づいて、より大きな潜在的なコンテキストチャンクのセット（k=~20）が最初に検索されます。
  • 再ランキング：検索された初期チャンクのセット（k=~20）は、Rerankステップを使用して洗練されます。クロスエンコーダモデル（bge-reranker-large）が各検索されたチャンクの元の質問に対する関連性を評価し、LLMのコンテキストとして使用される上位k=7の最も関連性の高いチャンクを選択します。この再ランキングステップは、初期のセマンティック類似度やキーワードマッチで最高位でなくても、最も適切な情報が最終応答生成のために優先されることを保証するために重要です。
  • 最終LLMプロンプト生成：洗練されたコンテキスト（k=7チャンク）は、元の質問と組み合わされて最終LLMプロンプトを形成します。このプロンプトは、提供されたコンテキストに基づいてLLMが焦点を絞った正確な応答を生成するよう導くために慎重に構築され、ハルシネーションのリスクを最小限に抑えます。
  • 引用付き応答生成：最先端の推論モデルが最終 プロンプトと提供されたコンテキストを処理し、引用付きの応答を生成します。LLMはコンテキストからの情報を統合して一貫性があり正確な回答を形成します。重要なのは、応答が生成された回答を裏付ける元の文書の特定のチャンクにリンクする引用を自動的に含むことです。
  • モニタリング：初期クエリから最終応答生成までのQuery-Time RAGプロセス全体は、可観測性、パフォーマンス、品質分析のためにLangfuseを使用して継続的に監視されます。

構造化データのためのText-to-SQL

RAGは非構造化データに優れていますが、構造化データポイントの精密なフィルタリング、集計、または比較を必要とするクエリはText-to-SQLの方が適しています。例としては、「RATで実施された50の研究例を教えてください」や、投与群を含む特定の数値アッセイ結果の取得が挙げられます。Researcher Agentは、このようなクエリをText-to-SQLツールに引き渡すかどうかをインテリジェントに判断できます。

text-to-sql.png

Figure 3: Text-to-SQLツール

自然言語の質問を実行可能なSQLクエリに変換し、結果を取得するプロセスには、いくつかの重要なステップが含まれます：

  • クエリ分析と意図認識：ユーザーの自然言語クエリが分析され、ユーザーの意図を理解し、構造化メタデータから要求されている特定のデータポイントとフィルタを特定します。
  • スキーマ理解と関連スキーマ選択：正確なSQLクエリを生成するために、LLMは関連するデータベーススキーマを理解する必要があります。大規模で複雑なスキーマの場合、ユーザーのクエリに関連する必要なスキーマコンポーネントのみがLLMのコンテキストに動的に注入されます。これにより、モデルの複雑さが低減され、生成されるSQLの精度が向上します。
  • 動的few-shotプロンプティングによるSQL生成：複雑な自然言語クエリを正確なSQL方言（本ケースではAthena）に変換することは、LLMにとって困難な場合があります。これに対処するため、動的few-shotプロンプティングを採用しています。さまざまな複雑なクエリパターンとAthena方言での対応する正しいSQL翻訳を表す、慎重に手作業で選ばれた例のコレクションが、ベクトルデータベース内の別コレクションに保存されます。ユーザーのクエリに基づいて、関連する例が「セマンティックレイヤー」からベクトル類似度検索を使用して検索され、LLMへのプロンプトに含まれます。これにより、LLMにインコンテキスト学習の例が提供され、正しい方言で正確なSQLクエリを生成するよう導きます。遭遇した課題に基づいて新しい例を継続的に追加することで、システムのパフォーマンスは時間とともに向上します。
  • SQLクエリ生成と検証：関連するスキーマ情報と動的few-shot例に基づいて条件付けされた、強力なコード生成能力を持つモデルが、対応するSQLクエリを生成します。LLMが結果を正確に処理し、後続の統合のために正しい行を特定できるようにするため、研究IDや研究タイトルなどの特定の必須カラムは、生成されるSELECTクエリに常に含まれます。生成されたクエリは、許可された操作に準拠していることを確認するために検証されます（例：SELECTクエリのみが許可され、DELETE、INSERT、UPDATEクエリはデータ整合性とセキュリティのために明示的にブロックされます）。なお、このプロセスの初期反復では、生成されたSQLクエリのLLMレビューステップが含まれていましたが、レビューを行うLLMが有効なクエリを誤ってエラーとフラグ付けすることがあり、精度の向上に見合わない効率の低下を招いたため、このステップは後に削除されました。
  • クエリ実行と結果制限：検証されたSQLクエリは、Amazon Athenaの構造化メタデータデータベースに対して実行されます。データフラッディングを防ぎ、応答サイズを管理するため、システムは一度に50レコードを超えない制限を適用します。
  • エラーハンドリングと反復：SQLクエリの実行が成功した場合、取得された結果（指定された制限まで）が返され、全体の応答生成プロセスに統合されます。クエリが構文エラー、スキーマの問題、またはその他の実行エラーにより失敗した場合、データベースからのエラーメッセージ、生成されたクエリ、および元のコンテキストが同じモデルに返されます。 LLMはエラーとコンテキストを分析して修正されたSQLクエリを生成します。 SQLクエリを生成・実行するこの反復プロセスは、ツールが諦めて失敗を報告する（特定の要求を処理できない可能性を示す）まで、最大3回試行されます。

The Reflection Agent: データ検証と十分性

Think & Planステップがプロセスリフレクションを提供する一方で、Reflection Agentは補完的ですが異なるタイプのリフレクション、データリフレクションを実行します。この重要なコンポーネントは、さまざまなツールから取得されたデータがユーザーの質問に答えるために十分で関連性があるかどうかを評価します。これは、ワークフロー自体が正しく進行しているかどうかという懸念とは根本的に異なります。

マルチステップのエージェント型ワークフローでは、これらの2種類のリフレクションは、異なりますが等しく重要な目的を果たします。プロセスリフレクション（Think & Plan）は、エージェントが正しいステップを踏み、目標に向かって適切な進捗を遂げていることを保証します。データリフレクション（Reflection Agent）は、それらのステップを通じて収集された情報がユーザーのリクエストを満たすのに十分であることを保証します。両方とも不可欠です。エージェントが完全に妥当なワークフローを実行（良いプロセス）しても、質問に答えるためのデータが不十分である場合や、逆に十分なデータにアクセスできてもワークフローを効果的に進行できない場合があります。

研究ワークフローダイアグラム（Figure 2）に示されているように、初期の情報検索と'think & plan'ループの後、Think & Planステップがプロセスが十分に進捗し、データを評価する準備ができていると判断した時点でReflection Agentが呼び出されます。 'Reflection Agent'は、取得されたコンテキストをユーザーの元のクエリと比較し、潜在的なギャップや欠落情報を特定することで、収集されたデータの十分性と関連性を評価します。収集された情報が完全な応答を提供するのに不十分であると判断された場合、Reflection Agentは必要な欠落情報を取得するための具体的なフォローアップ質問を生成します。これらのフォローアップ質問はThink & Planステップに返され、さらなる検索ステップを開始してより包括的な結果を得ます。このReflection Agentが生成した質問によって駆動されるデータ検証とその後の情報検索の反復プロセスは、システムが初期結果に基づいて検索戦略を洗練する能力を示しています。情報が十分である場合、ワークフローは次のステップに進みます。

The Writer Agent: 回答の合成とフォーマット

Researcher AgentがRAGとText-to-SQLから関連する証拠を収集すると、Writer Agentは生の素材をユーザーに表示される最終回答に変換する責任を負います。その仕事は新しい情報を「発見」することではなく、取得されたコンテキストを統合し、ユーザーの指示を尊重し、生成中にPRINCEの品質制約を適用することです。

Writer Agentは、いくつかの譲れないルールのもとで動作します。すべての主張を提供されたコンテキストにグラウンディングし、根底にあるチャンクと研究IDに正確な引用を付ける必要があります。規制された環境では検証可能性が重要だからです。また、ユーザーレベルのフォーマット要件（テーブル、箇点、特定のセクション構造など）を尊重し、前臨床科学者によって使用されるドメイン固有の回答基準に合わせる責任もあります。

より複雑な応答（複数セクションの要約や部分的に記入された規制テンプレートなど）の場合、アーキテクチャはWriter Agentを短い内部レビュー ループで拡張することをサポートします。このパターンでは、Writerがまず回答の下書きを作成し、次にレビュー ステップが欠落セクション、不整合なテーブル、または元の質問に対するギャップをチェックし、特定の部分を修正するためのターゲット指示をWriterに送り返す場合があります。この設計により、回答の完全性と提示に焦点を当てた軽量なリフレクション形式が可能になり、ワークフローの早い段階でデータ十分性に焦点を当てるReflection Agentを補完します。重要なのは、これらの規制ドラフティングワークフローのすべての出力は専門家によるレビューを意図していることです。最終提出物は、資格のある担当者によって作成・承認されます。

これにより、PRINCEには3つの補完的なリフレクションループが備わります。プロセスリフレクションは、ワークフローが正しい道筋にあるかどうかをチェックし、悪い軌道、誤ったツール選択、または不適切なシーケンシングをキャッチするのに役立ちます。データリフレクションは、収集された証拠が十分かどうかをチェックし、薄い証拠、欠落したコンテキスト、またはカバレッジのギャップをキャッチするのに役立ちます。ドラフトリフレクションは、生成された出力が完全かどうかをチェックし、欠落セクション、不完全なテーブル、または合成のギャップをキャッチするのに役立ちます。

これらのエージェントは、実用的なコンテキストエンジニアリングパターンを形成します。システムは単にプロンプトにさらに情報を追加し続けるわけではありません。適切なコンテキストを適切な能力に適切なタイミングでルーティングします：Think & Planのための計画コンテキスト、Researcherのための検索コンテキスト、Reflection Agentのための証拠コンテキスト、Writerのための合成コンテキスト。これはシステム全体の具体的な決定に反映されています。Text-to-SQLステップは、現在のクエリに関連するスキーマコンポーネントのみを注入し、完全なデータベーススキーマを注入しない。Reflection Agentは、ギャップを評価するために収集された証拠とともに元の質問を受け取り、完全なワークフロー履歴を受け取らない。Writer Agentは、引用制約付きの厳選されたチャンクを受け取り、生の検索出力を受け取らない。モノリシックなエージェントからこの構造化されたワークフローに移行したことで、各エージェントを分離して評価、デバッグ、改善できるようになりました。

本番LLMシステムにおける信頼の構築

ユーザーの信頼を構築・維持することは、あらゆるAIシステムの成功した採用にとって最も重要です。特に、決定が重大な影響を持つ前臨床薬剤開発のような重要な環境ではなおさらです。本番LLMアプリケーションにとって、信頼は正確性だけでなく、信頼性、透明性、およびユーザーが提供された情報を検証する能力にも関わります。PRINCEにはこれを実現するためのいくつかのメカニズムが統合されています：

透明性と説明可能性

透明性と説明可能性を確保することは、PRINCEの設計の重要な側面であり、ユーザーの信頼を育み、生成された応答の検証を可能にします。システムにはこれを達成するためのいくつかのメカニズムが組み込まれています：

  • 中間ステップと透明性：ワークフローの反復的な性質と最終回答を生成するのに必要な潜在的な時間を考慮すると、透明性を維持することは重要です。クエリ処理、情報検索、振り返り中にシステムによって実行される中間ステップ（定式化されたクエリや利用されたツールを含む）がユーザーに表示されます。これにより、システムの推論プロセスを可視化し、ユーザーが最終回答に至るまでのステップを追うことができます。また、関連するコンテキスト（チャンク）が特定された場合、これらのソース資料へのリンクが画面に表示され、ユーザーは最終応答を形成するためにどの情報が絞り込まれ、使用されたかを正確に確認できます。
  • 引用を通じた事実性の検証：システムは、堅牢な引用メカニズムを通じて事実性の検証を容易にします。生成された回答には、元のソース文書および構造化メタデータを参照する引用が一貫して付随します。これらの引用は、ユーザーに表示されるコンテキストに直接リンクされており、応答で述べられた主張の正確性を容易に検証し、情報の出所を追跡できます。ユーザーは生成された応答の任意の文にマウスをホバーすることで、対応する引用を表示でき、PRINCEおよびその部分の回答を裏付けるために使用された報告書のページ番号と正確な引用へのリンクが提供されます。この詳細なレベルの引用は、システムの出力の信頼性と信頼性を大幅に高め、人間によるレビュープロセスを簡素化します。

評価

厳密な評価は、信頼性の高いLLMアプリケーションを構築・維持するための基本です。PRINCEのパフォーマンスと信頼性は、データセット評価とライブトラフィック評価の2種類の評価の組み合わせを通じて評価されます。

  • データセット評価：コアワークフロー、プロンプト、または基盤となるモデルに重大な変更が加えられた際に実施され、事前に定義された参照回答を持つ厳選されたデータセットを使用します。これらのデータセットは、主題専門家によって meticulous に準備され、Langfuseに保存されています。カスタム評価スクリプトが各質問を処理し、生成された応答を参照回答と比較して、Faithfulness（回答がコンテキストによってどの程度裏付けられているか）、Answer Relevancy（回答がクエリにどの程度対応しているか）、Context Relevancy（検索されたチャンクの関連性）、Answer Accuracy（グラウンドトゥルースとの比較）、Semantic Similarity with Reference（参照回答との意味的類似度）などの定量的なメトリクスを生成します。エージェント型の性質を考慮すると、エンドツーエンドのパフォーマンスを評価することに加えて、テストピラミッドに類似した、ワークフローの異なる段階で適切な評価メトリクスを適用することが重要です。
  • ライブトラフィック評価：本番環境からの実際のユーザークエリに対して、事前に定義された参照回答なしで毎日バッチジョブとして実行され、実世界のパフォーマンスに関する貴重な洞察を提供します。FaithfulnessやAnswer Relevancyなどのメトリクスは依然として評価可能です。ライブトラフィック評価は、システムの動作を監視し、本番環境でのハルシネーションなどの潜在的な問題を特定し、多様なライブクエリでのパフォーマンスを理解するために不可欠です。

モニタリング

本番環境での問題の積極的な特定と解決のためには、システムのパフォーマンスと出力の継続的なモニタリングが不可欠です。Langfuseのようなプラットフォームを使用して、PRINCEを継続的に監視し、潜在的なバイアス、エラー、改善点を特定し、システムの応答の信頼性と安全性を確保します。

レジリエンスのためのエンジニアリング：エラーハンドリングと回復

PRINCEに内在するマルチステップワークフローの複雑さを考慮すると、さまざまな段階での失敗からシステムが優雅に回復し、シームレスなユーザー体験を提供できるように、堅牢なエラーハンドリングと回復メカニズムが重要です。システムは、完全なワークフローの再起動を必要とせずに、さまざまな段階での失敗から優雅に回復するように設計されています。

エラーハンドリングと回復アプローチの主要な側面は以下の通りです：

  • 状態の永続化：ワークフローグラフ全体の状態が永続的に保存され、システムが失敗したノードから直接実行を再開できるようにします。これは、ワークフローを通じたエージェントの進捗を表すAgent StateをPostgresに保存することで達成されます。ログ、中間ステップ、引用などのアプリケーション状態のその他の側面はDynamoDBに保存されます。この状態の分離と永続化は、ステートフルなエージェント型システムにおける堅牢性を実現するために重要です。
  • 組み込みリトライ：システムは、ワークフローのさまざまなステップに組み込みのリトライが設定されています。特定のステップで一時的な失敗が発生した場合、システムはより永続的なエラーを通知する前に、事前に定義された回数だけ自動的に再実行を試みます。
  • ユーザー主導のリトライ：自動リトライに加えて、ユーザーはインターフェースを通じて失敗したクエリを手動で再試行するオプションがあります。ユーザーが再試行を開始すると、システムは永続化された状態を活用して、失敗したポイントから直接ワークフローを継続し、以前の試行で正常に完了したステップをインテリジェントにスキップします。これにより、ユーザー体験が大幅に向上し、計算リソースを節約できます。
  • フレームワークレベルのサポート：エラー回復メカニズムは、ワークフロー状態の管理とグラフ構造内でのエラーハンドリングのための堅牢な組み込み機能を提供する基盤フレームワークであるLangGraphによって大幅にサポートされています。これにより、レジリエントなエージェント型ワークフローを構築するための堅牢な基盤が提供されます。
  • LLMフォールバック：モデル可用性やパフォーマンスに関連する問題の信頼性を高め、軽減するため、システムはカスタムLLMフォールバックハンドリングを組み込んでいます。プライマリLLMプロバイダーまたは特定のモデルへの呼び出しが数回の再試行後に失敗した場合、システムは自動的に別のプロバイダーの代替LLMにフォールバックします。このメカニズムは、特に外部サービスのプラットフォームダウンタイムが当社の直接制御外である場合に、システムの可用性と応答性を維持するために重要です。

このエラーハンドリングと回復に対する包括的なアプローチは、一時的な失敗の影響を最小限に抑え、ユーザーが複雑なクエリを最初から再起動する必要性を減らし、成功したステップやLLM呼び出しの冗長な実行を避けることでコストとレイテンシの節約に貢献します。これらはすべて、本番対応システムに不可欠です。

これらのメカニズムは、ハーネスエンジニアリングの実践です。LangGraphワークフローはエージェントの周囲の制御レイヤーとして機能します。どのコンポーネントが行動できるか、どのツールを使用できるか、ワークフローがどこで一時停止できるか、失敗がどのように再試行されるか、状態がどのように永続化されるか、システムがいつ研究から振り返り、執筆に移行すべきかを定義します。このハーネスにより、制約のない自律エージェントよりもシステムの不透明さが低減され、信頼性が向上します。アプリケーションに回復、検査、評価、および人間の介入のための明確な制御ポイントを提供します。

データ品質の向上：固有表現認識と注釈付け

Amazon Athena内の構造化メタデータの正確性と完全性は、Text-to-SQLコンポーネントのパフォーマンスとPRINCE内での全体的なデータ発見可能性にとって重要です。歴史的なデータ移行と、Bayerの広範な運用履歴にわたるさまざまな研究所やシステムでの多様な注釈付け慣行により、メタデータは不完全、欠落、または不正確になることがあります。

この課題に対処し、構造化メタデータの品質を継続的に向上させるため、研究PDFから直接正確な注釈を抽出・作成するためにNamed Entity Recognition (NER)を採用したユーティリティシステムを開発しました。このシステムは、前臨床報告書のテキストコンテンツを読み取り、構造化メタデータで表現されるべき主要なエンティティと関連情報を特定するように設計されています。

プロセスには以下が含まれます：

  • 研究PDFを処理してテキストを抽出し、関連するエンティティ（研究ID、化合物名、種、投与経路、投与量情報、臨床所見など）を特定します。
  • テキスト内の特定されたエンティティとその関係に基づいて構造化注釈を生成します。

このユーティリティシステムをデータパイプラインに統合し、Amazon Athenaデータベース内のデータを自動的に修正・強化する作業を積極的に進めています。生成される注釈の正確性におけるシステムのパフォーマンスは、厳選されたデータセットに対して評価され、有望な結果を示しています。これらの注釈の本番データベースへの統合を管理するため、各抽出フィールドに信頼度スコアを提供する評価システムを開発しています。信頼度スコアが高いフィールドは、Amazon Athenaの対応するエントリを更新するために自動的に使用されます。信頼度スコアが低いフィールドは隔離され、人間によるレビューと介入のためにフラグが立てられ、自動化を活用しつつデータの正確性を確保します。このアプローチは、構造化メタデータの品質を継続的に向上させ、PRINCEおよびその他のダウンストリームアプリケーションにとってより信頼性の高い情報源にすることを目指しています。

旅は続く：反復的な開発

PRINCEは2024年初頭からエンドユーザーに利用可能となっており、エージェント型統合はその年の後半に導入されました。 これは、実世界のフィードバックを収集し、反復的な開発を推進するために不可欠です。開発を導く主要な原則は、本番対応LLMアプリケーションの構築は反復的なプロセスであるという理解です。機能が完全に完成するのを待つのではなく、早期に価値を提供し、実世界の使用に基づいてシステムを継続的に洗練することを優先します。

初期段階では、中核機能の望ましい精度とパフォーマンスを達成することに焦点を当てていました。そのためにコストが高くなることを意味してもです。コストの最適化を時期尚早に行うと、システムの有効性が損なわれ、ユーザーの採用が妨げられる可能性があることを認識していました。望ましいレベルの精度とパフォーマンスを達成した後、初めてコスト最適化に焦点を当て、効率向上の結果がユーザー体験や結果の品質に悪影響を及ぼさないようにしました。

PRINCEの開発は、継続的で反復的なプロセスに従っています。ユーザーフィードバック、継続的な監視データ、および専門家の科学者からの洞察は、開発サイクルに継続的にフィードバックされ、アーキテクチャ、検索技術、エージェントの動作、およびユーザーインターフェースの洗練につながり、パフォーマンス、使いやすさ、そして最終的に科学的な影響を高めています。

結論

前臨床薬剤開発のような複雑なエンタープライズ環境で本番対応LLMアプリケーションを構築することは、重大な技術的およびエンジニアリング上の課題を伴う旅です。PRINCEのケーススタディは、堅牢なデータインフラストラクチャ、RAGやText-to-SQLのような洗練された情報検索技術、そしてインテリジェントなマルチエージェントオーケストレーションシステムを組み合わせることで、以前はアクセスできなかった膨大なデータリポジトリから貴重な洞察を解き放つことが可能であることを示しています。

私たちの経験は、堅牢なエラーハンドリング、状態の永続化、LLMフォールバックなど、信頼性のためのエンジニアリングに焦点を当てることの重要性を強調しています。さらに、ユーザーの信頼を構築することは最も重要であり、ワークフローの透明性、詳細な引用を通じた明確な説明可能性、およびシステムのパフォーマンスの継続的な評価と監視を通じて達成されます。

PRINCEはすでにBayerにおけるデータアクセシビリティと研究効率の向上に有望な結果を示しており、科学者が前臨床情報とどのように関わるかを変革しています。これは旅の終わりではなく、真にインテリジェントなリサーチアシスタントを作成するための重要な一歩です。

PRINCEから得られるより広い教訓は、本番対応のエージェント型AIは、より優れたモデルやより優れたプロンプトだけではないということです。信頼性は、モデルが見るコンテキストと、モデルが行動するハーネスの両方をエンジニアリングすることから生まれます。コンテキストエンジニアリングは、各モデルがワークフローの適切な段階で、適切な情報のみを受け取ることを保証するのに役立ちました。ハーネスエンジニアリングは、ワークフローが境界付けられ、可観測性があり、回復可能であり、規制された研究環境に適したものに留まることを保証するのに役立ちました。

モデルの能力が向上するにつれ、今日のハーネスの一部はより薄くなったり、ネイティブなモデル機能に移行したりする可能性があります。しかし、エンタープライズ研究システム、特に信頼性、トレーサビリティ、レビュー可能性が重要である場合には、コンテキスト、ワークフローの状態、回復、リフレクション、および検証に対する明示的な制御は依然として不可欠です。

この概要が、規制されデータ豊富なドメインでLLMアプリケーションを構築・本番化するために必要な実践的な考慮事項と技術的な深さについて、価値ある洞察を提供することを願っています。