通过人类对齐设计用于药物发现代理AI的健壮LLM评估系统

# 设计用于药物发现中智能体AI的稳健LLM评估系统——基于人类对齐视角  
来源：https://arxiv.org/html/2608.21057  
Emma GranqvistOrcID:0009-0000-6436-4178 (https://orcid.org/0009-0000-6436-4178)  
附属机构：分子AI，发现科学部，研发部，阿斯利康，瑞典哥德堡  
附属机构：计算机科学与工程系，数据科学与AI分部，查尔姆斯理工大学与哥德堡大学，瑞典哥德堡  
Rocío MercadoOrcID:0000-0002-6170-6088 (https://orcid.org/0000-0002-6170-6088)  
附属机构：计算机科学与工程系，数据科学与AI分部，查尔姆斯理工大学与哥德堡大学，瑞典哥德堡  
附属机构：生命科学实验室（SciLifeLab），瑞典哥德堡  
Samuel GenhedenOrcID:0000-0002-7624-7363 (https://orcid.org/0000-0002-7624-7363)  
附属机构：分子AI，发现科学部，研发部，阿斯利康，瑞典哥德堡  

#### 摘要  
智能体大语言模型（LLM）系统正在重塑化学和药物发现领域的科学工作流程，但评估其开放式、工具增强的输出仍是一个根本瓶颈。基于参考的指标如BLEU和ROUGE无法捕捉语义正确性，而专家人类评估又无法适应这些系统所需的迭代速度。LLM-as-a-Judge范式作为一种可扩展的替代方案应运而生，但现有的药物发现基准测试在部署LLM裁判时并未验证其与人类专家的一致性。本文针对阿斯利康部署的智能体药物发现助手ChatInvent，提出了一种LLM-as-a-Judge评估框架，并做出四项贡献：首先，我们定义了四个输出质量评估维度——完整性、相关性、结构清晰度和范围遵循度——以及确定性的工具调用正确性检查；其次，通过与五名专家标注员的人类一致性研究验证了裁判模型，比较了Gemini 3.1 Pro、Claude Opus 4.7、GPT-5和Llama 3.1 70B作为候选裁判的表现；第三，通过使用人类标注示例的少样本演示优化了最佳裁判模型，将其与人类多数投票的一致性从0.80提升至0.86；第四，将优化后的裁判应用于70个保留问题后，我们发现了具体局限性，并发现非正式的提问方式并不会系统性降低输出质量，相反让LLM在查询智能体前重写原始问题反而有益。本框架为科学领域智能体系统的人类对齐评估提供了可复用的模板。  

#### 关键词：LLM-as-a-Judge 裁判对齐 智能体AI AI助手 自动评估 智能体 药物发现  

## 1 引言  
大语言模型（LLM）的出现因其卓越的泛化、适应和迁移能力，已改变了广泛的领域[17]。在化学和药物发现应用中，基于LLM的智能体系统通过集成外部领域特定工具和数据库，已成为强大的协调者[7,15,8,16,5,22]。这种工具增强设计使LLM智能体能够利用数十年的计算化学软件和科学基础设施，同时缓解了LLM在需要精确计算、符号推理或获取最新知识的任务上的局限性。诸如AI co-scientist[7]、ChemCrow[15]、CACTUS[16]、SciToolAgent[5]、MolClaw[22]和ChatInvent[8]等智能体系统展示了这一范式：它们能够规划实验、调用专用计算工具并协调多步骤科学工作流程，证明了LLM结合专家工具如何支持端到端的科学规划与执行。  
LLM驱动框架的发展也带来了评估的紧迫挑战。由于其强大的生成能力，这些系统通常产生开放式且依赖上下文的输出，使得传统的将预测与单一标准答案进行比较的指标不足以全面评估其可靠性、实用性和稳健性。相反，人类标注可被视为“标准答案”，因为它们能提供对模型性能更深入的理解。然而，从专家那里收集人类反馈通常耗时且资源密集，使得大规模评估成为一项挑战。因此，LLM越来越多地通过根据任务上下文和标准调整其评估而被用作评估者。LLM-as-a-Judge方法实现了可扩展和自主的评估，同时也引发了关于可靠性、偏差和可重复性的担忧，强调了对评估者本身质量进行评估的必要性。  
本文展示了如何设计和使用LLM-as-a-Judge，以对ChatInvent这一智能体药物发现系统进行可靠、自动化和可扩展的评估。我们的贡献包括：  
- • 对药物发现系统LLM-as-a-Judge设计的分析，  
- • 多组件LLM裁判人类一致性的研究，  
- • 不同底层LLM裁判模型的性能比较，  
- • 以及对ChatInvent不同功能智能体输出质量的评估。  
我们聚焦于特定智能体ChatInvent，而非尝试比较不同智能体，并专注于介绍我们认为在设计化学智能体LLM-as-a-Judge系统时重要的概念，因为任何智能体系统的能力和范围都在不断变化。  

## 2 相关工作  
传统的基于参考的指标如BLEU[18]和ROUGE[12]无法捕捉现代生成模型输出的语义细微差别、任务多样性和开放式特性。人类偏好被广泛认为是评估LLM系统的金标准，但专家评估无法适应现代智能体开发的迭代速度，为快速原型制作和批量评估设置了瓶颈。LLM-as-a-Judge范式由Zheng等人[23]提出，通过使用强大的LLM大规模评估模型输出，同时保持与人类判断的高度一致性来解决此问题。强大的LLM裁判在一般任务上可达到与人类评估者超过80%的一致性[23,9]，匹配或超越个体人类标注员之间的一致性，且时间成本仅为一小部分。然而，LLM裁判表现出若干系统性偏差，包括模型自我偏好、格式和冗长偏差以及位置偏差[23]，强调了通过人类标注验证裁判本身的重要性，而不是将其输出视为标准答案。  
近期研究将基于LLM的评估和提示优化视为构建可扩展评估系统的互补工具。DSPy[10]提供了一种编程模型，其中评估标准被表达为可通过演示优化的类型化签名，我们将其采纳为裁判的实现基础。与我们场景最直接相关的是，Ríos-García和Jablonka[19]使用了LLM-as-judge和LLM-as-optimizer框架进行有机化学数据提取，证明通过针对专家标注的轻量级提示优化可以显著提高领域特定的评估质量。  
针对智能体药物发现系统，已有两项综合评估工作被描述。SciToolEval被开发用于评估SciToolAgent[5]（一个单智能体协调器），使用LLM生成的测试问题覆盖单工具和多工具工作流程；LLM裁判对最终答案和工具调用序列进行评分，该基准已被用于比较SciToolAgent与ChemCrow[15]和CACTUS[16]。MolClaw[22]引入了MolBench（基于ChemCoTBench），这是一个多维度基准，涵盖多样化学任务，并从工具调用序列和科学有效性等维度评估其与独立LLM和其他智能体框架的性能。与这些工作不同，SciToolEval和MolBench均未通过人类标注验证其LLM裁判，这是一个关键的对齐缺口，本文正是要解决此问题。  

## 3 ChatInvent：智能体药物发现系统  
ChatInvent[8,11]是一个智能体药物发现助手，已集成到阿斯利康的发现流程中，以引导设计-制造-测试-分析（DMTA）周期的不同阶段。最近，发布了一个完全基于开源代码而非阿斯利康内部服务的开源版本。ChatInvent使用多种计算工具，如ReInvent[14]、AiZynthFinder[20]和PrecedentFinder[2]，完整工具列表见表1。随着新工具的实现，ChatInvent的范围不断扩大。该系统是一个多智能体框架，包括一个监督智能体和四个特定任务子智能体：设计、合成、分析和实用工具智能体。监督智能体通过将用户请求定向到相应的子智能体来管理对话。子智能体为任务做出适当的工具调用，监督智能体则将最终响应传递给用户。  

表1：ChatInvent中可用工具的概要，包括其各自功能和负责的子智能体。  

## 4 评估框架  

### 4.1 LLM-as-a-Judge  
He等人[8]在工具调用正确性、错误率和令牌消耗方面评估了ChatInvent。这些指标关注系统的内部运作，因此能很好地近似其性能。然而，这些指标并未评估用户实际收到的智能体输出的质量。本文提出扩展评估范围，聚焦于评估给定用户问题及其上下文的智能体输出，使用LLM-as-a-Judge，工作流程概览见图1。  

图1：首先，用户请求传递给ChatInvent并产生输出。其次，智能体输出与用户问题、工具调用及问题相关上下文一起传递给LLM裁判。最后，LLM裁判为每个评估维度提供分数及理由。  

考虑了五个评估维度：工具调用正确性（通过直接比较计算）和四个LLM裁判标准：完整性、相关性、结构清晰度和范围遵循度。完整评估维度列表包括描述和允许的分数标签，见表2。每个分数标签可映射到数值分数（0、0.5、1），其中0表示智能体输出未满足预期要求，0.5表示部分满足，1表示完全满足。例外的是范围遵循度，在对齐分析中，“低于目标”和“高于目标”被视为单独标签，而在后续分析中，两者均映射为0，“符合目标”映射为1以进行更清晰的分析。  

表2：评估维度包括描述和允许的分数标签。*注意工具调用正确性通过确定性检查单独评估，而其他四个指标通过LLM裁判计算。  

LLM裁判使用DSPy签名[10]实现，指导LLM如何评判问题-答案对。每个指标由描述和允许的分数标签定义；完整摘要包括描述的简短版本见表2。裁判的输入包括：用户问题、智能体输出、评估上下文，以及ChatInvent做出的预期、可接受和实际工具调用。可接受的工具调用序列是不完整的工具调用序列，但仍能为用户提供一些有价值信息[8]。裁判为每个维度返回评分，评分严格属于预定义分数标签，并附有简短理由文本。  
我们比较了四种LLM作为裁判：Google的Gemini 3.1 Pro[4]、Anthropic的Claude Opus 4.7[1]、OpenAI的GPT-5[21]和Meta的开源权重模型Llama 3.1 70B[13]，均使用默认设置。这些LLM在研究项目进行时是最先进的，并涵盖了基于API和开源权重的模型。然而，考虑到模型发布速度之快，未来可能会出现性能更优的模型。由于本文旨在引入新概念，具体模型选择及其带来的确切结果并非至关重要。  

### 4.2 测试问题  
第一步，手工整理了20个测试问题，以覆盖ChatInvent的预期功能。其中，分子名称、SMILES、反应和属性约束最初作为变量包含在内。测试问题涵盖了每个单独工具的使用（标记为Tool）和多个工具的组合（标记为Workflow）。问题被分为不同类别，以描述所提问题的意图；见表3。随后，使用LLM（Gemini 2.5 Pro）为每个测试问题生成了四个额外变体，该LLM被指示生成不同正式程度的变体，从1（最正式）到4（最非正式）；原始手写问题标记为变体0，示例见表A1。最后，为每个100个问题随机抽样变量以完善问题。这四个变体加上中性参考问题，总共构成100个主要问题。  

表3：不同问题类型和类别的数量，以及包含的工具。括号表示该工具在该类别的部分但非所有问题中预期出现。