臨床前藥物發現本質上複雜且資料密集。 研究人員在這個關鍵階段面臨的主要挑戰，是如何有效存取並分析大量產生的資訊。 傳統以關鍵字為基礎的搜尋方法，往往仰賴嚴格的布林邏輯，面對臨床前研究問題的細微且複雜本質時，經常無法滿足需求。

大型語言模型（LLM）的出現帶來了轉型契機。透過結合 LLM 的生成能力與資訊檢索系統的精準度，檢索增強生成（RAG）成為一項具前景的技術。 這種方法有潛力徹底改變臨床前資料存取方式，讓研究人員能以自然語言提出複雜問題，並獲得基於專有資料、準確且富含脈絡的答案。

拜耳（Bayer）很早就看見這項潛力，致力探索如何運用這些技術解決臨床前研究長期存在的挑戰。

在本文中，我們分享這段歷程——拜耳早期投資生成式 AI 的成果，打造出基於 Agentic RAG 的代理式 AI 系統 PRINCE。本案例研究探討技術架構、工程決策，以及將臨床前資料檢索從複雜迷宮轉化為直覺對話體驗的經驗學習。

PRINCE 背後的許多工程決策，如今可透過脈絡工程（context engineering）與束具工程（harness engineering）的視角理解，儘管系統最初設計時尚未使用這些術語。脈絡工程決定每個模型接收哪些資訊、不接收哪些資訊，以及脈絡如何在研究、反思與寫作等專門步驟間流動。束具工程則形塑模型周圍的支架：協調、工具邊界、狀態持久化、重試、備援、驗證、反思迴圈、可觀測性，以及人工審查。

雖然本文聚焦於技術架構與工程挑戰，但我們發表於 Frontiers in Artificial Intelligence 的論文，會更詳細說明產品演進與商業影響。

挑戰：穿越臨床前資料迷宮

拜耳的臨床前研究環境與許多大型製藥組織相似，資料種類多元且數量龐大。 這包含來自各項研究的結構化資料集，以及大量嵌入在文字文件（如研究報告、出版品與法規提交文件）中的非結構化資訊。研究人員在有效存取與分析這些資訊時，經常遭遇重大障礙：

  • 資料孤島：資訊分散在眾多獨立的系統與儲存庫中，難以取得特定化合物或研究的完整、整體視圖。
  • 搜尋功能受限：傳統以關鍵字為基礎的搜尋引擎難以處理臨床前術語與研究問題的複雜性與多變性，常常產生不相關、不完整或過多的結果。
  • 耗時的手動分析：從多份文件中提取特定洞見或彙整資訊，需要大量手動工作，耗費研究人員寶貴的時間，無法專注於核心科學活動。

這些固有的挑戰清楚顯示，需要更有效率、更智慧且整合的方法來進行臨床前資料檢索與分析。

解決方案：PRINCE — 一個演化中的平台

為了因應這些挑戰，拜耳開發了臨床前資訊中心（Preclinical Information Center，PRINCE）平台。PRINCE 最初被設計為臨床前資料的統一入口，重點在整合先前各自獨立的結構化研究元資料，並以「可搜尋」的方式呈現。 這個初期階段讓使用者能套用進階篩選器，主要從結構化研究元資料中取得資訊。

然而，拜耳大量有價值的臨床前知識存在於數十年累積的非結構化 PDF 研究報告中。由於多年來的多次系統遷移，這些報告相關的結構化元資料可能不完整、遺漏，甚至包含錯誤標註。重要的是，經過核可的 PDF 研究報告中始終存在具權威性的「黃金標準」資訊。

生成式 AI（特別是 RAG）的出現成為解鎖這些非結構化資料的關鍵。透過整合 RAG 功能，PRINCE 開始從以篩選器為基礎的「搜尋」工具，轉變為以自然語言「提問」的系統，讓研究人員能直接查詢這些研究報告的內容。

這個演進反映 PRINCE 經歷三個不同階段：

  1. 搜尋：初期階段聚焦於建立數千份非臨床研究報告的統一入口，將來自不同臨床前領域的多個內部資料孤島整合為可搜尋格式，主要運用結構化元資料。
  2. 提問：此階段引入以 AI 驅動的問答系統，運用檢索增強生成（RAG）。這讓研究人員能以自然語言提問，直接從非結構化資料（包含歷史報告的掃描 PDF）中獲取洞見。
  3. 執行：目前階段將 PRINCE 定位為能執行複雜任務的主動研究助理。透過整合多代理系統，平台能處理複雜查詢、協調工作流程，並支援起草法規文件等活動。

從「搜尋」到「提問」再到「執行」的刻意演進，代表對產業在臨床前開發中對更高效率與創新需求的一種策略回應。透過提供研究人員日益強大的工具來存取、分析並運用臨床前資料，PRINCE 旨在促進更快速的資料驅動決策，減少不必要的實驗，最終加速更安全、更有效的療法開發。

系統架構：打造可靠的代理式 RAG 系統

系統作為互動式對話使用者介面，由強健的後端基礎架構驅動。其架構設計用於處理複雜查詢並提供準確且富含脈絡的答案，使用 LangGraph 進行協調，並透過 FastAPI 應用程式提供服務。

圖 1 呈現系統脈絡——使用者介面、後端、資料儲存、LLM 備援與可觀測性——而 圖 2 則深入說明系統如何協調其專門代理。

system-container-view.png

圖 1：系統脈絡與支援平台。

  • 使用者請求：流程從使用者透過以 React 建構的對話式使用者介面提交請求開始。
  • 協調：使用者請求會路由至後端的 LangGraph 協調層。此工作流程引擎協調多階段流程，包含釐清使用者意圖、思考與規劃、進行研究（使用 RAG 與 Text-to-SQL）、驗證資料完整性，最後由 Writer 代理生成回應。工作流程包含刻意的暫停點與回饋迴圈，確保在繼續之前資料已完整。（我們稍後會在專門章節探討這個代理式工作流程的細節。）
  • 資料檢索與狀態管理：Researcher 代理會與全面且分散的資料生態系統互動：
    • 所有研究報告的向量表示儲存在 OpenSearch 中，構成資訊檢索的核心知識庫。
    • 經過策劃的結構化資料（來自各種 ETL 與調和流程）透過 Athena 存取。
    • 代理執行的狀態會被仔細追蹤。每個邏輯步驟（LangGraph 節點執行）後，對應的狀態會使用 LangGraph checkpointer 持久化儲存在 PostgreSQL 中。
    • 更廣泛的應用程式層級狀態則在 DynamoDB 中管理。
  • 系統運用內部 GenAI 平台，託管來自 OpenAI、Anthropic、Google 與開源供應商的模型。這些平台透過統一的 OpenAI 相容端點公開所有模型，讓模型替換與為各任務選擇最佳工具變得容易。它們也管理控制平面，執行速率限制與其他防護機制以防止濫用。
  • 韌性與錯誤處理：強健性是關鍵設計原則，系統內建多重備援機制：
    • 若特定 LLM 失敗，系統會自動重試請求數次，然後切換至替代模型或平台，以確保服務持續性。
    • 為快速從暫時性失敗中恢復，重試機制同時在個別 LLM 呼叫層級與邏輯節點層級（即代理計劃中的整個步驟）實作。
    • 此外，代理會收到錯誤脈絡，以便據以規劃不同軌跡或替代行動方案。
  • 可觀測性與評估：整個系統的效能與可靠性均受到監控：
    • 系統整體健康狀態與指標使用 Cloudwatch 追蹤。
    • Langfuse 作為主要可觀測性工具，提供所有生產流量的詳細追蹤，讓深入除錯成為可能。此外，評估資料集儲存在 Langfuse 中，便於分析效能分數與診斷特定失敗。評估使用 RAGAS 評估框架。實際流量評估每日執行一次，而資料集評估則在核心工作流程、提示或底層模型有重大變更時執行。
  • 最終回應：代理處理完請求並生成令人滿意的回應後，會傳送回對話式使用者介面呈現給使用者。

貫穿此架構的一項設計原則是脈絡紀律。更大的脈絡視窗並未消除對每個代理接收內容進行選擇性篩選的需求。在早期迭代中，將過多資訊放入脈絡會讓系統更難操控與評估。因此 PRINCE 避免將提示視為容納所有可用資訊的大型容器。相反，不同階段會收到不同脈絡：Think & Plan 收到規劃脈絡、Researcher Agent 收到檢索脈絡、Reflection Agent 收到證據脈絡，而 Writer Agent 收到綜合脈絡。這減少脈絡污染，並讓系統更容易除錯、評估與改進。

這些步驟確保系統能透過精密的多代理架構與多樣且強大的工具和資料來源，為各式複雜查詢提供可靠且具脈絡相關性的答案。

代理式 RAG 系統

PRINCE 整合代理式 RAG 系統（圖 2），以處理需要多個步驟、推理，以及與不同工具或資料來源互動的複雜使用者請求。此設定使用 LangGraph 實作，協調整體工作流程，並運用 Researcher Agent、Writer Agent 與 Reflection Agent 執行特定任務。系統設計為強健且可靠，內建多重備援機制，確保即使部分元件失敗，系統仍能繼續運作。

new-research-workflow.png

圖 2：研究工作流程。

釐清使用者意圖

釐清使用者意圖步驟是防範歧義的第一道防線。隨著系統擴展至毒理學與藥理學等多元領域，簡單的使用者查詢往往變得模稜兩可，難以自動選擇正確工具。系統不會依賴在所有資料來源上進行昂貴的試誤，而是主動提出澄清問題，以精準定位特定領域或資料類型。

這確保系統能為查詢加入必要限制，以針對正確的工具。我們也正在透過在使用者介面開發領域層級選擇功能進行最佳化，讓使用者能事先預先篩選有效工具。為進一步降低摩擦，系統也提供 AI 輔助來源推薦：當使用者未選擇任何資料來源——或選擇多個但無明確焦點——時，模型會分析使用者查詢背後的意圖，並建議最相關的來源。使用者保有完整控制權，可接受、調整或覆寫建議，確保領域專業知識始終擁有最終決定權。這種「快速失敗」機制可避免在模糊查詢上浪費執行資源，同時透過謹慎調整確保當意圖已明確時系統不會過於干擾。

從脈絡工程的角度來看，此步驟是工作流程中的第一個組裝決策：在任何檢索開始前，即限制哪些工具、領域與資料來源在範圍內，確保後續代理收到的是聚焦而非開放式問題。

思考與規劃：流程反思

思考與規劃步驟負責為滿足使用者請求制定策略。這個關鍵元件為系統提供專屬空間，在採取行動前推理下一步——這項技術靈感來自 Anthropic 的 Think tool。 重要的是，此步驟執行流程反思：評估代理是否正朝向最終目標正確前進並在正確軌道上，而非評估資料本身。

在涉及許多順序動作的多步驟代理式工作流程中，流程反思至關重要。考慮系統需要執行 50 個步驟才能完成複雜任務的情境。在每個關鍵點，系統必須自問：我是否以正確的方式執行這些步驟？我是否正按照應有的進度前進？目前的軌道是否正朝向使用者目標前進？思考與規劃步驟提供這種後設認知能力，讓系統能反思自身工作流程並據以調整策略。

這個「思考空間」在涉及多個工具呼叫的情境中特別有價值。 PRINCE 最初開發時只有少數工具：一個用於基於 RAG 的檢索，另一個用於 Text-to-SQL 查詢。然而，隨著我們整合更多資料來源以擴展系統能力，可用工具數量大幅增加。伴隨工具爆炸而來的固有挑戰是：不同工具間的重疊關切與領域邊界。

例如，多個工具可能服務相似但細微不同的目的——查詢結構化元資料 versus 非結構化報告，或是檢索研究摘要 versus 詳細實驗資料。 當面對屬於相似領域但處理略有不同資料的工具時，LLM 有時會難以為特定查詢選擇最合適的工具。透過引入專用的思考步驟，系統能明確推理哪個工具最符合使用者意圖，評估每個可用工具的特徵，並做出更明智的決策。這種方法讓工具選擇的準確度大幅提升。

除了工具選擇外，思考與規劃步驟對於協調多步驟流程也至關重要。PRINCE 中的許多複雜查詢需要一系列工具呼叫，其中一個工具的輸出必須先分析，才能決定下一步行動。例如，系統可能先查詢結構化元資料以識別相關研究，然後使用這些研究 ID 從非結構化報告中檢索詳細資訊，最後綜合發現。若無專用空間進行流程反思，系統會嘗試線性地執行這些步驟，而不評估每個步驟是否正更接近目標。有了思考步驟，系統能暫停、評估工作流程中的進度，並智慧規劃完成使用者請求所需的後續工具呼叫。

Researcher Agent

Researcher Agent 擔任系統的主要資訊蒐集者。隨著我們將新科學領域納入 PRINCE，我們持續觀察到資料分為兩大類：結構化與非結構化。雖然不同領域的具體實作技術可能有所不同——例如藥理學查詢使用 Snowflake Cortex Analyst 進行 Text-to-SQL，而毒理學則使用其他更自訂的方法——但這些檢索策略背後的基本原理保持一致。

隨著 PRINCE 跨多個臨床前領域擴展，單一 Researcher 代理搭配扁平工具列表變得越來越難以管理。許多工具運作在相似概念上——「研究」、「發現」、「分析」——但根據領域指向不同的底層資料集、結構描述與法規詮釋。例如，當使用者提到「該研究」時，相關脈絡可能是重複劑量毒理學研究、心血管安全性藥理學套件，或是彙總大量資料表中的特定分析，每個都有自己偏好的真實來源。

為避免單一單體代理同時處理重疊工具與細微不同的資料契約，我們正積極將 Researcher 能力演進為領域特定子代理的階層結構。在此提議的架構中，每個領域代理將擁有自己的工具集（例如毒理學 RAG + 毒理學元資料 SQL，或藥理學 RAG + 分析層級 SQL），以及編碼該領域資料模型運作方式、哪些表格或索引具權威性，以及如何詮釋關鍵概念的客製化提示指令。我們預期這將保持職責一致，減少意外的跨領域洩漏，並讓每個領域的檢索行為更容易推理與測試。

為有效從這個多元環境中獲取洞見，Researcher Agent 採用聚焦於兩種不同模式的混合檢索器方法：

  • 檢索增強生成（RAG）：用於處理非結構化資料，主要為 PDF 報告。
  • Text-to-SQL：用於查詢儲存在 Amazon Athena 中的結構化資料。

這種雙重策略讓系統能橋接敘述性科學報告與量化實驗資料之間的差距。

在這個更新後的願景中，頂層 Researcher Agent 被設計為協調者，而非單一全知元件。根據釐清的使用者意圖以及使用者介面中的任何明確領域選擇，它會將查詢路由至適當的領域子代理，該子代理可在自身邊界內決定如何結合 RAG 與 Text-to-SQL。這個模式旨在從使用者視角保留「單一研究者」的簡潔性，同時在內部讓每個領域能演進自己的工具、結構描述與檢索方法，而不影響系統其他部分。

非結構化資料的檢索增強生成（RAG）

面對數千份臨床前研究報告與其他非結構化文件的龐大儲存庫，RAG 對於透過將 LLM 回應奠基在這個特定知識庫上來提取相關洞見至關重要。RAG 管線包含完整的擷取流程與精密的查詢時架構。

擷取流程：臨床前研究報告多為 PDF，橫跨數十年且常包含帶有複雜表格的掃描文件，首先會集中到 S3 資料湖，然後通過針對此語料庫調整的擷取管線。擷取的文字會被正規化為結構化 JSON，然後使用既能保留足夠科學脈絡又能保持檢索效率的策略進行分塊。

每個分塊會從 Amazon Athena 加入研究層級與章節層級的元資料（例如研究 ID、化合物、物種、給藥途徑、頁碼與父章節），這後續能在 RAG 層進行精確的元資料篩選。最後，這些已標註的分塊會被嵌入並索引到 Amazon OpenSearch Service 中，形成向量儲存，支援對歷史語料庫與每日新增或更新報告的語意與元資料感知檢索。

查詢時 RAG 管線：當使用者提交查詢時，系統會啟動多階段檢索流程。此管線經過設計，能有效從向量資料庫中檢索最相關且可信的資訊，以奠基 LLM 的回應。

「在研究 T123456-2 中是否觀察到以下任何臨床發現：豎毛、共濟失調、眼睛半閉，以及稀便？」

關鍵字擷取器

「豎毛」、「共濟失調」、「眼睛半閉」、「稀便」

篩選器擷取器

eq(study_id, T123456-2)

查詢擴展器

1. 您能否提供研究 T123456-2 中報告的臨床症狀細節，包括任何鵝皮、協調障礙、半閉眼瞼或腹瀉的發生？

2. 在實驗 T123456-2 的結果中，是否有記錄到毛髮豎立、步態不穩、眼睛未完全張開或水樣便的觀察？

3. 在試驗 T123456-2 中注意到哪些臨床觀察，特別是有關毛髮豎立、平衡障礙、部分閉眼或軟便的存在？

4. ... 5. ...

加權混合搜尋

檢索約 20 個分塊

0.3

0.7

重新排序器

重新排序器選取前 7 個分塊

最終提示生成器

回應使用者

回應以自然語言提出的查詢

LLM 分析查詢並擷取關鍵字

同時，LLM 生成元資料篩選器以縮小搜尋空間

LLM 生成查詢擴展器以擴大搜尋空間

檢索器使用加權混合搜尋檢索最相關資訊

重新排序器精煉結果，確保最相關資訊提供給 LLM

最終提示生成器為 LLM 生成最終提示

回應者將回應傳送給使用者

為說明此管線，請考慮範例查詢：「在研究 T123456-2 中是否觀察到以下任何臨床發現：豎毛、共濟失調、眼睛半閉，以及稀便？」。系統會透過以下步驟處理此查詢：

  • 關鍵字擷取：使用者的自然語言查詢首先由 LLM 分析。透過謹慎的提示工程，模型會被指示擷取對我們文件語料庫中的關鍵字搜尋高度相關的關鍵字（例如「豎毛」、「共濟失調」、「眼睛半閉」、「稀便」）。
  • 元資料篩選器生成：同時，LLM 會根據查詢生成元資料篩選器。例如，篩選器 eq(study_id, T123456-2) 會被擷取以縮小搜尋空間。此篩選器使用少樣本提示，搭配提供給模型的各種排列組合範例動態生成，確保它能處理多樣的篩選請求。
  • 查詢擴展：為確保全面檢索並考量措辭與術語的變化，查詢擴展（多查詢或查詢重寫）由較小、較快的模型執行。這會根據原始問題生成 n=5 個語意相似的查詢。對於範例查詢，這可能包含以下變體：
    • 「研究 T123456-2 中報告的臨床症狀，包括鵝皮、協調障礙、半閉眼瞼或腹瀉。」
    • 「實驗 T123456-2 中關於毛髮豎立、步態不穩、眼睛未完全張開或水樣便的記錄觀察。」
    • 「試驗 T123456-2 中注意到的臨床觀察，特別是有關毛髮豎立、平衡障礙、部分閉眼或軟便的存在。」
  • 混合檢索器：從向量資料庫（Amazon OpenSearch Service）的資訊檢索採用混合搜尋方法，結合元資料篩選、語意向量相似度搜尋（kNN）與基於關鍵字的檢索。此流程執行方式如下：
    • 元資料篩選：前一步驟生成的元資料篩選器（例如 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）會評估每個檢索分塊與原始問題的相關性，選取前 k=7 個最相關的分塊作為 LLM 的脈絡。這個重新排序步驟對於確保最相關資訊（即使不是初始語意相似度或關鍵字匹配最高者）優先用於最終回應生成至關重要。
  • 最終 LLM 提示生成：精煉後的脈絡（k=7 個分塊）接著會與原始問題結合，形成最終 LLM 提示。此提示經過謹慎建構，以引導 LLM 根據提供的脈絡生成聚焦且準確的回應，同時最小化幻覺風險。
  • 帶引用的回應生成：最先進的推理模型接著會處理最終提示與提供的脈絡，生成帶引用的回應。LLM 會綜合脈絡中的資訊以形成連貫且準確的答案。重要的是，回應會自動包含引用，連結回原始文件中支援生成答案的特定分塊。
  • 監控：整個查詢時 RAG 流程，從初始查詢到最終回應生成，會持續使用 Langfuse 進行監控，以進行可觀測性、效能與品質分析。

結構化資料的 Text-to-SQL

雖然 RAG 擅長處理非結構化資料，但需要精確篩選、彙總或比較結構化資料點的查詢更適合 Text-to-SQL。範例包含「給我 50 個在 RAT 上進行的研究範例」，或檢索包含劑量組的特定數值分析結果。如 Researcher Agent 所示，系統能智慧決定將此類查詢交給 Text-to-SQL 工具。

text-to-sql.png

圖 3：Text-to-SQL 工具

將自然語言問題轉換為可執行 SQL 查詢並檢索結果的流程包含數個關鍵步驟：

  • 查詢分析與意圖辨識：使用者的自然語言查詢會被分析，以理解使用者意圖並從結構化元資料中識別被請求的特定資料點與篩選器。
  • 結構描述理解與相關結構描述選擇：為準確生成 SQL 查詢，LLM 需要理解相關資料庫結構描述。對於大型且複雜的結構描述，只有與使用者查詢相關的必要結構描述元件會動態注入 LLM 的脈絡。這會降低模型複雜度並提升生成 SQL 的準確性。
  • 動態少樣本提示用於 SQL 生成：將複雜自然語言查詢轉換為精確的 SQL 方言（在本案例中為 Athena）對 LLM 而言可能具有挑戰性。為了解決這個問題，我們採用動態少樣本提示。一系列經過謹慎手工挑選的範例（代表各種複雜查詢模式及其在 Athena 方言中的正確 SQL 翻譯）會儲存在向量資料庫中的獨立集合中。根據使用者查詢，相關範例會從這個「語意層」使用向量相似度搜尋檢索並包含在提示中。這為 LLM 提供脈絡學習範例，引導它生成正確方言的準確 SQL 查詢。根據遇到的挑戰持續加入新範例，會進一步提升系統效能。
  • SQL 查詢生成與驗證：具備強大程式碼生成能力的模型，在相關結構描述資訊與動態少樣本範例的條件下，生成對應的 SQL 查詢。為確保 LLM 能準確處理結果並識別後續綜合所需的正確列，某些必要欄位（如研究 ID 與研究標題）會始終包含在生成的 SELECT 查詢中。生成的查詢接著會被驗證，以確保其遵循允許的操作（例如：僅允許 SELECT 查詢；DELETE、INSERT 或 UPDATE 查詢會被明確封鎖，以維護資料完整性與安全性）。值得注意的是，此流程的早期迭代包含對生成 SQL 查詢的 LLM 審查步驟；然而，此步驟後來被移除，因為發現審查 LLM 有時會錯誤地將有效查詢標記為錯誤，阻礙效率且未帶來相應的準確性提升。
  • 查詢執行與結果限制：已驗證的 SQL 查詢會在 Amazon Athena 中的結構化元資料資料庫上執行。為防止資料氾濫並管理回應大小，系統會強制限制，每次最多擷取 50 筆記錄。
  • 錯誤處理與迭代：若 SQL 查詢執行成功，檢索的結果（最多指定限制）會被返回並整合到整體回應生成流程中。若查詢因語法錯誤、結構描述問題或其他執行錯誤而失敗，來自資料庫的錯誤訊息連同生成的查詢與原始脈絡會被傳回給同一個模型。LLM 會分析錯誤與脈絡以生成修正後的 SQL 查詢。這個生成與執行 SQL 查詢的迭代流程最多嘗試 3 次，之後工具會放棄並回報失敗，可能表示無法解決的查詢或模型處理特定請求的能力受限。

Reflection Agent：資料驗證與充分性

雖然 思考與規劃步驟提供流程反思，Reflection Agent 則執行互補但不同類型的反思：資料反思。這個關鍵元件評估從各種工具檢索的資料是否充分且相關，足以回答使用者問題——這與工作流程本身是否正確前進的考量有根本性差異。

在多步驟代理式工作流程中，這兩種反思類型服務於不同但同樣重要的目的。流程反思（思考與規劃）確保代理正採取正確步驟並朝目標適當前進。資料反思（Reflection Agent）確保透過這些步驟蒐集的資訊足以滿足使用者請求。兩者都至關重要：代理可能執行完全有效的工作流程（良好流程）但仍檢索到不足以回答問題的資料，反之亦然，代理可能有足夠資料但無法有效通過工作流程前進。

如研究工作流程圖（圖 2）所示，在初始資訊檢索與「思考與規劃」迴圈後，當思考與規劃步驟認為流程已充分進展且準備評估資料時，會呼叫 Reflection Agent。 「Reflection Agent」會透過將檢索的脈絡與使用者原始查詢比較，並識別潛在缺口或遺漏資訊，來評估蒐集資料的充分性與相關性。若判斷蒐集的資訊不足以提供完整回應，Reflection Agent 會生成特定後續問題，旨在獲取必要的遺漏資訊。這些後續問題接著會交回 思考與規劃步驟，啟動進一步的檢索步驟以獲得更全面的結果。這個由 Reflection Agent 生成的問題驅動的資料驗證與後續資訊檢索的迭代流程，展示了系統根據初始結果精煉搜尋策略的能力。若資訊充分，工作流程會繼續下一步。

Writer Agent：答案綜合與格式化

一旦 Researcher Agent 從 RAG 與 Text-to-SQL 蒐集到相關證據，Writer Agent 負責將這些原始材料轉化為呈現給使用者的最終答案。它的任務不是「發現」新資訊，而是綜合檢索的脈絡、尊重使用者指示，並在生成過程中執行 PRINCE 的品質限制。

Writer Agent 運作時遵循一些不可妥協的規則。它必須將每個主張奠基在提供的脈絡上，並將準確引用附加回底層分塊與研究 ID，因為在受管制的環境中可驗證性至關重要。它也負責遵守使用者層級的格式要求（例如表格、項目符號或特定章節結構），並符合臨床前科學家使用的領域特定答案標準。

對於更複雜的回應——如多章節摘要或部分填寫的法規範本——架構支援透過短內部審查迴圈擴展 Writer Agent。在此模式中，Writer 會先起草答案，然後審查步驟會檢查遺漏的章節、不一致的表格，或相對於原始問題的缺口，並可能發送針對性指示回 Writer 以修改特定部分。這個設計啟用一種輕量形式的反思，聚焦於答案完整性與呈現，補充 Reflection Agent 早期對資料充分性的聚焦。重要的是，所有來自這些法規起草工作流程的輸出都旨在供專家審查；最終提交由合格人員撰寫並核可。

這讓 PRINCE 擁有三個互補的反思迴圈。流程反思檢查工作流程是否在正確軌道上，並幫助捕捉不良軌跡、錯誤工具選擇或不良排序。資料反思檢查蒐集的證據是否充分，並幫助捕捉薄弱證據、遺漏脈絡或覆蓋缺口。草稿反思檢查生成的輸出是否完整，並幫助捕捉遺漏章節、不完整的表格或綜合缺口。

這些代理共同形成實用的脈絡工程模式。系統不會簡單地在提示中加入更多資訊。它會在正確時間將正確的脈絡路由到正確的能力：規劃脈絡給 Think & Plan、檢索脈絡給 Researcher、證據脈絡給 Reflection Agent，以及綜合脈絡給 Writer。這在系統的具體決策中體現：Text-to-SQL 步驟只注入與目前查詢相關的結構描述元件，而非完整資料庫結構描述；Reflection Agent 接收原始問題與蒐集的證據以評估缺口，而非完整工作流程歷史；Writer Agent 接收帶引用限制的策劃分塊，而非原始檢索輸出。從單體代理轉向這個結構化工作流程，意味著每個代理都能被獨立評估、除錯與改進。

在生產 LLM 系統中建立信任

建立並維護使用者信任對於任何 AI 系統的成功採用至關重要，特別是在臨床前藥物發現這種關鍵環境中，決策具有重大影響。對於生產 LLM 應用程式而言，信任不僅關乎準確性，也關乎可靠性、透明度，以及使用者驗證所提供資訊的能力。PRINCE 整合了多項機制來達成此目標：

透明度與可解釋性

確保透明度與可解釋性是 PRINCE 設計的關鍵面向，有助於培養使用者信任並驗證生成回應。系統包含多項機制來達成此目標：

  • 中間步驟與透明度：鑑於工作流程的迭代性質以及生成最終答案可能需要的時間，維持透明度至關重要。系統在查詢處理、資訊檢索與反思期間執行的中間步驟（包含制定的查詢與使用的工具）會顯示給使用者。這讓使用者能看到系統的推理過程，並追蹤得出最終答案的步驟。此外，當識別出相關脈絡（分塊）時，這些來源材料的連結會顯示在畫面上，讓使用者能精確看到哪些資訊被選入並用於制定最終回應。
  • 透過引用的真實性驗證：系統透過強健的引用機制促進使用者對真實性的驗證。生成的答案始終附帶引用，參照原始來源文件與結構化元資料。這些引用會直接連結到顯示給使用者的脈絡，讓使用者能輕鬆驗證回應中主張的準確性，並追溯資訊的來源。使用者可以將滑鼠懸停在生成回應的任何句子上，以查看對應的引用，該引用會提供指向 PRINCE 與來源文件的連結，包括頁碼與用於支援答案部分的報告中的確切引文。這種細粒度的引用層級大幅提升系統輸出的可信度與可信賴性，並簡化人工審查流程。

評估

嚴謹的評估是建立並維護可靠 LLM 應用程式的基礎。PRINCE 的效能與可靠性透過兩種評估類型的組合進行評估：資料集評估與實際流量評估。

  • 資料集評估：每當核心工作流程、提示或底層模型有重大變更時執行，這些評估使用由主題專家 meticulously 準備並儲存在 Langfuse 中的策劃資料集（帶有預定義參考答案）。自訂評估腳本會處理每個問題，並將生成回應與參考答案比較，產生量化指標，例如忠實度（答案受脈絡支援的程度）、答案相關性（答案回答查詢的程度）、脈絡相關性（檢索分塊的相關性）、答案準確性（與真實答案的比較），以及與參考的語意相似度（與參考答案的語意相似度）。鑑於系統的代理式性質，在不同工作流程階段套用適當評估指標（類似測試金字塔）與評估整體端到端效能同樣重要。
  • 實際流量評估：每日作為批次作業在實際環境中的真實使用者查詢上執行（無預定義參考答案），這些評估提供對真實世界效能的寶貴洞見。忠實度與答案相關性等指標仍可評估。實際流量評估對於監控系統行為、識別生產環境中的潛在問題（如幻覺），以及了解在多樣實際查詢上的效能至關重要。

監控

持續監控系統效能與輸出對於在生產環境中主動識別與解決問題至關重要。使用 Langfuse 等平台，我們持續監控 PRINCE 以識別潛在偏誤、錯誤或改進空間，確保系統回應的可靠性與安全性。

為韌性而設計的工程：錯誤處理與恢復

鑑於 PRINCE 內建多步驟工作流程的複雜性，強健的錯誤處理與恢復機制對於確保系統可靠性與提供無縫使用者體驗至關重要。系統經過設計，能從各階段的失敗中優雅恢復，而無需完全重新啟動整個工作流程。

我們錯誤處理與恢復方法的主要面向包含：

  • 狀態持久化：整個工作流程圖的狀態會被持久化儲存，讓系統能直接從失敗的節點恢復執行。這透過將代表代理在工作流程中進度的 Agent State 儲存在 Postgres 中達成。應用程式狀態的其他面向（如日誌、中間步驟與引用）則儲存在 DynamoDB 中。這種狀態的分離與持久化對於在有狀態代理式系統中達成強健性至關重要。
  • 內建重試：系統在工作流程的各個步驟中配置內建重試。若特定步驟遇到暫時性失敗，系統會自動嘗試重新執行預定義次數，然後才發出更永久的錯誤訊號。
  • 使用者啟動的重試：除了自動重試外，使用者也可透過介面手動重試失敗的查詢。當使用者啟動重試時，系統會運用持久化狀態直接從失敗點繼續工作流程，智慧地跳過先前嘗試中已成功完成的步驟。這大幅改善使用者體驗並節省運算資源。
  • 框架層級支援：錯誤恢復機制獲得底層框架 LangGraph 的顯著支援，該框架在圖結構中提供管理工作流程狀態與處理錯誤的穩固內建能力。這為建構韌性代理式工作流程提供穩健基礎。
  • LLM 備援：為提升可靠性並緩解與模型可用性或效能相關的問題，系統整合自訂 LLM 備援處理。若對主要 LLM 供應商或特定模型的呼叫在數次重試後失敗，系統會自動切換至不同供應商的替代 LLM。此機制對於維持系統可用性與回應性至關重要，特別是外部服務的平台停機不在我們的直接控制範圍內。

這種全面的錯誤處理與恢復方法能將暫時性失敗的影響降到最低，減少使用者從頭重新啟動複雜查詢的需求，並透過避免重複執行成功步驟與 LLM 呼叫來貢獻成本與延遲節省，所有這些對於生產就緒系統而言都至關重要。

這些機制是束具工程的實踐。LangGraph 工作流程作為代理周圍的控制層：它定義哪個元件可以行動、可以使用哪些工具、工作流程可以在哪裡暫停、失敗如何重試、狀態如何持久化，以及系統何時應從研究移動到反思再到寫作。這個束具讓系統比無約束的自主代理更不透明且更可靠。它為應用程式提供清晰的恢復、檢查、評估與人工介入控制點。

提升資料品質：命名實體識別與標註

Amazon Athena 中結構化元資料的準確性與完整性對於 Text-to-SQL 元件效能以及 PRINCE 內整體資料可發現性至關重要。由於歷史資料遷移以及拜耳長期營運歷史中不同實驗室與系統的標註做法差異，元資料有時可能不完整、遺漏或不正確。

為了解決這個挑戰並持續提升結構化元資料品質，我們開發了一個使用命名實體識別（NER）從研究 PDF 中直接提取並建立準確標註的公用系統。此系統設計用於讀取臨床前報告的文字內容，並識別應在結構化元資料中表示的關鍵實體與相關資訊。

此流程包含：

  • 處理研究 PDF 以提取文字並識別相關實體（例如研究 ID、化合物名稱、物種、給藥途徑、劑量資訊、臨床發現等）。
  • 根據識別的實體及其在文字中的關係生成結構化標註。

我們正積極將此公用系統整合到資料管線中，以自動更正並豐富 Amazon Athena 資料庫中的資料。系統在生成準確標註方面的效能已針對策劃資料集進行評估，顯示出有前景的結果。為管理這些標註整合到生產資料庫，我們正在開發一個評估系統，為每個提取的欄位提供信心分數。具有高信心分數的欄位會自動用於更新 Amazon Athena 中的對應條目。信心分數較低的欄位會被隔離並標記供人工審查與介入，確保資料準確性的同時運用自動化。這個方法旨在持續提升結構化元資料品質，使其成為 PRINCE 與其他下游應用程式更可靠的資訊來源。

旅程持續：迭代開發

PRINCE 自 2024 年初起已提供給最終使用者使用，代理式整合則在同年稍後引入。 這對於蒐集真實世界回饋與推動迭代開發至關重要。指導我們開發的一項關鍵原則是理解建構生產就緒 LLM 應用程式是一個迭代過程；我們不會等待功能絕對完美才尋求使用者回饋。相反，我們優先及早交付價值，並根據真實世界使用情況持續精煉系統。

在初期階段，我們的焦點 squarely 在於為核心功能達成所需的準確性與效能，即使這意味著承擔更高成本。我們認知到過早最佳化成本可能會損害系統效能並阻礙使用者採用。只有在達成所需的準確性與效能水準後，我們才開始關注成本最佳化，確保效率提升不會對使用者體驗或結果品質產生負面影響。

PRINCE 的開發遵循持續迭代過程。使用者回饋、持續監控資料，以及來自專家科學家的洞見會持續回饋到開發週期，導致架構、檢索技術、代理行為與使用者介面的精煉，以提升效能、可用性，並最終提升科學影響。

結論

在臨床前藥物發現這種複雜企業環境中建構生產就緒 LLM 應用程式，是一段充滿重大技術與工程挑戰的旅程。PRINCE 案例研究證明，透過結合強健的資料基礎架構、RAG 與 Text-to-SQL 等精密資訊檢索技術，以及智慧多代理協調系統，有可能從大量先前無法存取的資料儲存庫中解鎖有價值的洞見。

我們的經驗強調工程化可靠性的關鍵重要性，包括強健的錯誤處理、狀態持久化與 LLM 備援。此外，建立使用者信任至關重要，透過工作流程的透明度、透過細粒度引用的清晰可解釋性，以及系統效能的持續評估與監控來達成。

PRINCE 已在提升拜耳的資料可及性與研究效率方面展現有前景的結果，改變科學家與臨床前資訊互動的方式。這不是旅程的終點，而是朝向打造真正智慧研究助理邁出的重要一步。

從 PRINCE 得到的更廣泛教訓是，生產就緒代理式 AI 不僅關乎更好的模型或更好的提示。可靠性來自同時工程化模型看到的脈絡以及模型行動的束具。脈絡工程幫助確保每個模型在工作流程的正確階段擁有正確的資訊，且只有正確的資訊。束具工程幫助確保工作流程保持有界、可觀測、可恢復，並適合受管制的研究環境。

隨著模型能力提升，今天束具的某些部分可能變得更薄，或轉移到原生模型能力中。但在企業研究系統中，特別是信任、可追溯性與可審查性重要的地方，對脈絡、工作流程狀態、恢復、反思與驗證的明確控制仍然至關重要。

我們希望這個概覽能為在受管制且資料豐富的領域中建構與生產化 LLM 應用程式所需的實際考量與技術深度提供有價值的洞見。