Research Assistant：AstraZeneca的研发智能体系统

# 研究助手：阿斯利康的研发智能体系统
来源：https://arxiv.org/html/2608.12395
Piotr Grabowski通讯作者：piotr\.grabowski1@astrazeneca\.comAstraZeneca, RDIT, Biological Insights Knowledge GraphJorge BretonesAstraZeneca, RDIT, Biological Insights Knowledge GraphSabina CardellAstraZeneca, RDIT, Biological Insights Knowledge GraphMiguel CarmonaAstraZeneca, RDIT, Biological Insights Knowledge GraphGavin EdwardsAstraZeneca, RDIT, Biological Insights Knowledge GraphBen GraingerAstraZeneca, RDIT, Biological Insights Knowledge GraphSameh HassanAstraZeneca, RDIT, Biological Insights Knowledge GraphErik JanssonAstraZeneca, RDIT, Biological Insights Knowledge GraphArtur KuziakhmetovAstraZeneca, RDIT, Biological Insights Knowledge GraphAlbert MaristanyAstraZeneca, RDIT, Biological Insights Knowledge GraphHebatallah MohamedAstraZeneca, RDIT, Biological Insights Knowledge GraphAndriy NikolovAstraZeneca, RDIT, Biological Insights Knowledge GraphSebastian NilssonAstraZeneca, RDIT, Biological Insights Knowledge GraphMark O’DonoghueAstraZeneca, RDIT, Biological Insights Knowledge GraphJames PacileoAstraZeneca, RDIT, Biological Insights Knowledge GraphAshiq SultanAstraZeneca, RDIT, Biological Insights Knowledge GraphAlex VoegeleAstraZeneca, RDIT, Biological Insights Knowledge GraphMichaël UghettoAstraZeneca, RDIT, Biological Insights Knowledge Graph

###### 摘要

我们描述了 Research Assistant——一个在阿斯利康内部开发的基于 LLM 的系统，旨在帮助科学家和临床研究人员跨广泛的数据源探索生物医学问题。该系统提供聊天式界面，汇集了来自科学文献、知识图谱、化学、临床试验、安全性资源、表达数据以及内部实验系统的证据。它同时支持用于直接回答问题的快速模式和面向更复杂研究任务的多步骤模式。回复以检索到的证据为依据，并链接回原始来源，使用户能够审阅并进一步探索底层数据。在这篇技术说明中，我们概述了系统架构、产品背后的主要设计选择，以及在大规模部署以支持阿斯利康日常研发工作流过程中获得的经验教训。

## 1 引言

随着 OpenAI 于 2022 年下半年推出 ChatGPT，一种与信息系统交互的新方式被开启。将这种交互重构为一系列自然语言查询和响应，使这些系统对非技术用户更加友好。在 ChatGPT 发布之前，我们阿斯利康团队构建并维护了一套数据服务，用于消费我们的知识图谱 [3](https://arxiv.org/html/2608.12395#bib.bib2) 和 NLP 流水线，以支持多个药物发现项目。然而，这些资源需要一定程度的软件工程经验才能使用，例如需要编写 REST API 查询，或使用 Cypher 查询语言查询图数据库。ChatGPT 的出现促使我们重新思考如何让阿斯利康的科学和临床专家访问这些资源，目标是降低技术门槛。我们开发了 Research Assistant，使内部生物医学数据资源对领域专家更加可及。它提供面向生物医学问题的聊天式界面，并返回以多种数据源为依据、附带引文链接的答案。Research Assistant 在一年内从小型试点发展为拥有 15,000 名内部独立用户。在此我们描述该系统，并分享一路走来获得的经验。

Research Assistant 是一个面向生物医学领域的基于 LLM 的多智能体系统，工作流如下：

1. 1\. 根据用户问题，找到最合适的数据源和事实。
2. 2\. 使答案基于检索到的证据。
3. 3\. 将用户链接到原始来源，供其手动评估和进一步探索。

## 2 架构

### 2\.1 应用——高层概览

Research Assistant 的后端使用 Python 编写，并大量使用 asyncio 包。提供 API 端点的层使用 FastAPI 开发。应用核心使用的框架是 Apache Burr (https://burr\.apache\.org/)。Apache Burr 是一个轻量级状态机框架，允许构建包含循环、应用图部分条件执行的完整助手式应用，并提供开箱即用的遥测支持，且不绑定任何特定供应商。在 Apache Burr 中，应用被定义为图，其中每个节点是一个 Action，每条边是 Action 之间的转换。Action 本质上是一个 Python 函数，在其中对应用的状态（State）进行修改。前端使用 TypeScript 和 React 编写。在状态机执行期间，后端使用服务器发送事件（server-sent events）异步地向前端流式传输带有状态更新的消息，实时更新各种 UI 元素，并告知用户其查询的状态。示例截图见图1 (https://arxiv.org/html/2608.12395#S2.F1)。

在 Research Assistant 中，对系统性能的主要贡献者是数据服务。我们认为底层数据服务和 API 的质量在很大程度上促进了内部采用。保持 LLM 指令精简，同时引导系统只依赖获取到的外部信息，这一设计旨在减少幻觉——在缺乏数据支撑的系统中，幻觉更为常见。系统采用并行架构，用户查询会同时触发多个轻量级工具调用。随后由一个更大的 LLM 执行最终的综合步骤。这种方法也有助于保持每次查询的低成本。按照 Google Cloud Platform 当前（2026 年 7 月）的按 Token 定价，Research Assistant 每次查询的平均成本仅为 16 美分（包括所有输入和输出 Token，使用 Gemini 3 Flash 和 Gemini 3.1 Pro 模型）。这种重检索、高 Token 效率设计的另一个优势是更低的延迟。虽然无法与普通 LLM 查询相比，但响应通常在 10 到 30 秒内生成，这使得 Research Assistant 既能作为一个交互式系统，也能通过其 REST API 和模型上下文协议（MCP）端点作为其他应用的信息源。

参见图1：Research Assistant 用户界面（UI）截图。上方面板显示用户提交查询的初始屏幕。下方面板显示使用 Scientific Mode 回答“What causes Sturge-Weber Syndrome?” 的示例答案。右侧打开的面板包含系统用于生成答案的引文。文本回复中自动高亮的实体链接到基因、疾病和化学方面的其他资源。参见图2：Research Assistant 两种主要模式的简化应用图。Scientific Mode 是用于检索各种生物医学主题信息的单次检索与综合工作流。Deep Research Mode 更为复杂，用于需要多轮 Scientific Mode 工作流的问题，由研究计划执行智能体编排。
### 2\.2 应用模式

用户每次与 Research Assistant 交互的入口都是一个用户问题。用户可以使用两种模式：“Scientific Mode” 和 “Deep Research Mode”（图2 (https://arxiv.org/html/2608.12395#S2.F2)）。Scientific Mode 通过执行单次前馈过程来平衡答案的复杂性和深度与速度，将用户查询映射到相关的工具智能体（每个智能体专门处理不同主题和数据），并根据发现的数据回答问题。相比之下，Deep Research Mode 提供多步骤的规划与执行工作流。它以研究计划的概念为核心，研究计划被建模为问题的有向无环图（DAG）(Figure3 (https://arxiv.org/html/2608.12395#S2.F3))，模拟真实研究人员处理更复杂问题的方式。

参见图3：针对用户查询 “What genes are associated with idiopathic pulmonary fibrosis?” 创建的简单自动研究计划示例。应用首先创建并修订计划，直到评判智能体接受该计划（为避免过长的规划循环，设有最大修订次数）。随后，被接受的 DAG 问题图会进行拓扑排序，使得独立的初始问题可以先被回答，然后依赖性问题会在前序问题处理完后尽快被提出并回答。在该研究 DAG 中处理的每个问题本身都是应用向自身提出的问题，但使用 Scientific Mode 来执行。在执行研究 DAG 过程中，依赖性问题会利用先前步骤中获得的信息进行重写。例如，后面关于某种药物的查询可能会使用前一个答案中识别出的同义词。此外，这种深度研究型系统的表述方式带来了灵活性。用户甚至可以要求对多个不同实体（如基因、药物或临床试验）重复某些分析，灵活的计划器会将该请求转换为迭代式研究计划。用户甚至可以向应用提供非常具体的研究计划和问题流程，以覆盖自动计划生成步骤。重要的是，这种方法对执行的复杂性和时间提供了更多控制，因为研究计划的大小在开始时是固定的。这对于必须在特定时间和预算内完成的研究运行可能很重要。

### 2\.3 工具智能体

工具智能体（见表 1）是 Research Assistant 回答各种问题并发现相关数据的核心能力。工具智能体由两部分组成：工具 API 和提示词（类似于 Skills 的概念）。工具 API 是一个简单接口，将关键词、登录号、ID 和各种过滤设置转换为函数调用，这些调用可访问阿斯利康内部资源或外部 API。提示词的作用是向 LLM 解释如何最好地将自由文本用户查询映射为结构化的工具 API 查询、每个工具有哪些限制，以及返回数据的格式。工具智能体 LLM 调用与众多工具 API 之间的粘合层是 Instructor 包 (https://github\.com/567\-labs/instructor/)。Instructor 帮助 LLM 创建和验证结构化 Pydantic 模型，并在验证错误时处理重试。使用 Instructor 包，再加上 LLM 在结构化输出生成方面的近期改进（例如 JSON 格式），意味着查询很少因模型模式验证错误或格式错误的 JSON 对象而失败。

每个智能体都会将数据封装到同一个 Pydantic 类实例（Observation）中返回，其中包含：

- •Observation 的 ID（一个标签，稍后用于注入 LLM 响应，以支撑 LLM 生成的每个陈述）
- •数据来源的 URL，允许用户手动查看来源
- •包含支撑数据的灵活容器，其中可包含句子、表格数据、知识图谱三元组等
- •前端用来向用户显示的引文字符串

例如，针对查询 “Is NRF2 pathway linked to inflammatory bowel disease?”，Literature Agent 返回的一条命中结果：

Observation\(

id=’lit\-5’,

link=’https://doi\.org/10\.1186/s12935\-022\-02660\-5’,

data=\{

’excerpt’:\[

’Ininflammatoryboweldisease,Nrf2/HO\-1expressiondecreasedMMP\-9andMMP\-7,finallyhelpingtoreduceinflammation;TheskindamagecausedbyUVirradiationismoresevereinNrf2knockoutmicethaninWTmice,andMMP\-9andMIP\-2\(macrophageinflammatoryprotein\-2isacrucialmodulatorofneutrophilrecruitment\)levelsaremuchhigher\[150,151\]\.’

\],

’document\_title’:’TheMolecularBiologyAndTherapeuticPotentialOfNrf2InLeukemia’,

’document\_source’:’CancerCellInternational’,

’date’:’2022\-07\-29’,

’document\_authors’:\[

’AtefehKhodakarami’,

\.\.\.

’FarhadJadidi\-Niaragh’

\],

’number\_of\_citations’:27,

’impact\_factor’:6\.91

\},

citation=’AtefehKhodakaramietal\.\-2022\-07\-29\-TheMolecularBiologyAndTherapeuticPotentialOfNrf2InLeukemia\-Publishedin:CancerCellInternational\-Citations:27,ImpactFactor:6\.91’

\)

表1：工具智能体摘要。主题用于工具选择例程，该例程在用户查询中发现主题。查询中出现这些主题中的任何一个，都会将该工具智能体添加到运行列表中以处理该查询。智能体名称用例主题Literature Agent科学文献检索、电子实验室笔记本、专利/会议查询。生物关系、化学信息、药物安全性、一般生物医学知识、内部实验数据Compound Agent化合物ID查询、SMILES解析、生物活性、理化性质。化学信息、实体同义词Knowledge Graph Agent成对实体关系（基因–疾病、化合物–靶点、化合物–疾病）。生物关系Clinical Trial Agent按药物/适应症/状态/申办方进行试验检索；特定NCT查询、入排标准。临床终点、临床试验Web Search Agent实时网络搜索；近期组织活动和新闻。一般生物医学知识、近期事件OFF-X Agent按药物名称或基因靶点查询药品不良事件和安全警报。药物安全性Discover Agent新的基因–疾病–化合物关联的排名预测。发现与排序Mapping Agent化合物、基因、疾病的跨数据库ID和同义词映射。实体同义词Clinical Endpoints Agent临床疗效终点提取（OS、PFS、ORR、CR），并生成LLM摘要。临床终点Human Protein Atlas Agent组织和细胞类型基因表达水平（大致模式或具体TPM/CPM值）。基因表达Glossary Agent阿斯利康特有的缩写和简称定义。阿斯利康术语In Vivo Agent阿斯利康内部体内研究数据：毒性研究、动物模型、化合物测试、给药。内部实验数据、临床前研究#### 2\.3\.1Literature Agent

Literature Agent 是 Research Assistant 中最重要的工具智能体。它将系统与同一团队内部创建和维护的 NLP 流水线连接起来。该 NLP 流水线依赖斯坦福 NLP 的 CoreNLP[10](https://arxiv.org/html/2608.12395#bib.bib16) (https://github\.com/stanfordnlp)。简要来说，NLP 流水线处理超过 38 亿个句子，这些句子来自超过 6700 万篇文档，涵盖 PubMed、EuropePMC、Embase、bioRxiv、medRxiv、Wiley、Springer Nature、Dailymed、Insightmeme 以及阿斯利康内部电子实验室笔记本（ELN）系统等来源。该流水线由三个主要步骤组成：

1. 1\. 使用 KAZU 流水线[17](https://arxiv.org/html/2608.12395#bib.bib5) 进行基于深度学习的生物医学命名实体识别（NER）
2. 2\. 基于深度学习的语法和句法结构提取
3. 3\. 基于规则的 relation extraction（关系抽取，RelEx）

处理后的句子随后被索引，以使用 Elasticsearch 引擎进行快速检索。为了处理实体间的拼写和命名差异，我们采用了双重方法。首先，我们对句子中包含的单词进行词元化版本索引。这样，不同句子中的 “gene” 和 “genes” 等词会表示为词元化形式 “gene”。当工具智能体创建用于搜索的关键词集合时，它会使用查询关键词的词元化版本。其次，由于 NLP 索引中的句子已经带有命名实体注释（例如基因的 Ensembl ID 或疾病的 MONDO ID），我们采用自动翻译方法，将工具