建立可靠的代理式 AI 系統：拜耳 (Bayer) PRINCE 平台的案例研究

執行摘要

拜耳開發了臨床前資訊中心 (PRINCE)，旨在解決如何存取分散在結構化資料庫與非結構化 PDF 報告中、高容量且碎片化的臨床前數據之挑戰。透過實施代理式檢索增強生成 (RAG) 系統，拜耳已從基本的關鍵字搜尋工具轉型為具備複雜推理、數據檢索與法規草擬能力的積極研究助手。核心啟示在於，要開發用於生產環境的代理式 AI，需要結合上下文工程 (context engineering)（控制模型所見內容）與框架工程 (harness engineering)（控制模型行為方式）以確保在受監管環境中的可靠性。

PRINCE 的演進：從搜尋到行動

PRINCE 經歷了三個戰略階段，以滿足日益複雜的臨床前研究需求：

  1. 搜尋 (Search)： 一個統一的入口，將孤立的結構化研究元數據 (metadata) 整合為可搜尋的格式。
  2. 詢問 (Ask)： 整合 RAG 以允許對非結構化數據（特別是歷史 PDF 研究報告）進行自然語言查詢。
  3. 執行 (Do)： 目前的代理階段，利用多代理系統來編排複雜的工作流並草擬法規文件。

技術架構與編排

PRINCE 是以 FastAPI 應用程式搭配 React UI 構建，並使用 LangGraph 進行後端編排。系統透過 PostgreSQL（用於代理執行狀態）與 DynamoDB（用於應用層級狀態）來管理狀態。

多代理工作流

系統採用專門的代理層級結構，以防止「上下文污染」並提高可控性：

  • 釐清使用者意圖 (Clarify User Intent)： 作為「快速失敗」機制，在檢索開始前解決歧義並建議相關數據源。
  • 思考與規劃 (Think & Plan (Process Reflection))： 一個專用的推理空間，系統在此評估其路徑並從不斷擴展的領域特定選項庫中選擇最合適的工具。
  • 研究員代理 (Researcher Agent)： 一種混合檢索器，結合了 RAG（透過 Amazon OpenSearch 檢索非結構化 PDF）與 Text-to-SQL（透過 Amazon Athena 檢索結構化元數據）。
  • 反思代理 (Reflection Agent (Data Reflection))： 評估檢索到的數據是否足以回答查詢。如果發現缺口，它會為 Think & Plan 代理生成後續問題。
  • 寫作者代理 (Writer Agent)： 綜合最終答案，確保每一項主張都基於上下文，並提供指向原始文件與頁碼的細粒度引用。

為可靠性與信任進行工程設計

在受監管的製藥環境中，準確性與可驗證性是不可妥協的。拜耳實施了幾種「框架工程」模式，以確保系統保持在邊界內且具備可觀察性。

上下文紀律

儘管目前已有更大的上下文窗口，PRINCE 仍使用嚴格的上下文工程。不同的代理接收不同的資訊子集：用於 Think & Plan 的規劃上下文、用於 Researcher 的檢索上下文、用於 Reflection Agent 的證據上下文，以及用於 Writer 的綜合上下文。這能防止模型變得難以控制，並簡化除錯過程。

韌性與錯誤恢復

為了防止在複雜的多步驟任務中發生系統性故障，架構包含：

  • 狀態持久化 (State Persistence)： LangGraph checkpointers 將狀態儲存在 Postgres 中，允許系統從發生故障的確切節點恢復。
  • LLM Fallbacks： 如果主要模型在多次重試後仍失敗，系統會自動切換到替代模型或供應商，以維持服務連續性。
  • 使用者啟動的重試 (User-Initiated Retries)： 使用者可以手動重試失敗的查詢，系統會透過持久化狀態跳過先前已成功的步驟。

驗證與評估

信任是透過雙重評估策略來維持的：

  • 數據集評估 (Dataset Evaluations)： 使用 Langfuse 中精心策劃的專家數據集來衡量忠實度 (Faithfulness)、答案相關性 (Answer Relevancy) 與上下文相關性 (Context Relevancy)。
  • 即時流量評估 (Live Traffic Evaluations)： 對真實使用者查詢進行每日批次作業，以監控幻覺 (hallucinations) 與實際表現。

數據品質提升

由於歷史元數據通常不完整或不正確，拜耳開發了一套使用 Named Entity Recognition (NER) 的工具系統。該系統從 PDF 中提取實體（例如：化合物名稱、劑量），以自動豐富 Amazon Athena 資料庫。為了維持完整性，每次提取都會分配一個置信度分數；高置信度的更新會自動執行，而低置信度的更新則會標記供人工審核。

關鍵分析與社群觀點

雖然技術架構相當全面，但社群討論突顯了幾點關於此類系統實際效能的爭議點：

  • 效能差距： 一些批評者指出相關研究論文，提到聊天機器人的能力在完全滿足使用者需求方面獲得了較低的平均分數 (3.1/5.0)，這顯示即使是複雜的代理式架構也難以達到完全的實用性。
  • 數據 vs. 代理調優： 行業從業者認為「99% 的工作」通常在於數據清洗，而非代理調優，這顯示一個乾淨的資料庫比複雜的代理層級結構更具影響力。
  • 架構「感覺」 (Architecture "Vibes")： 一些開發者質疑將代理分解為 Researcher、Writer 與 Reflection 代理是否基於實證證據，或者這僅僅是一個「令人滿意的流程圖」而增加了相對於簡單提示策略 (prompting strategies) 的不必要複雜度。

Sources