Building Reliable Agentic AI Systems

构建可靠的智能体AI系统

构建生产就绪智能体AI系统的一个案例研究

本文介绍了由拜耳公司（Bayer AG）与Thoughtworks共同开发的Preclinical Information Center（PRINCE），这是一个用于解决药物研发过程中制药行业挑战的云托管平台。PRINCE利用智能体增强检索生成（Agentic Retrieval-Augmented Generation）和文本到SQL（Text-to-SQL）技术，整合数十年的安全研究报告。我们描述了PRINCE从基于关键词的搜索演变为能够回答复杂问题并起草监管文件的智能研究助手的过程。我们通过上下文工程的视角，反思了关键的工程决策——信息是如何在专用智能体之间被塑造和路由的；并通过工程实现的视角，探讨了如何围绕模型构建编排、恢复和可观测性，以保持控制和可靠性。该系统通过透明性、可解释性和人机协作的集成来优先考虑信任。PRINCE展示了人工智能在制药领域的变革潜力，显著提高了数据的可访问性和研究效率，同时确保了治理和合规性。

2026年6月16日

Sarang Sanjay Kulkarni

Sarang Kulkarni是Thoughtworks的高级顾问，致力于软件工程、数据平台和应用人工智能的交汇点。他专注于构建生产级的生成式AI系统，特别是增强检索生成（RAG）和多智能体工作流，并帮助团队将这些系统从早期构想转化为实际应用。Sarang还为Thoughtworks的全球AI服务开发团队做出贡献，并教授一门O’Reilly关于构建生产就绪RAG应用的课程。

目录

• 挑战：穿越临床前数据迷宫

• 解决方案：PRINCE——一个演进的平台

• 系统架构：构建可靠的智能体RAG系统

• 智能体RAG系统：澄清用户意图、思考与规划：过程反思、研究员智能体、反思智能体：数据验证与充分性、撰写智能体：答案合成与格式化

• 在生产级LLM系统中建立信任：透明性与可解释性、评估、监控

• 为弹性而设计：错误处理与恢复

• 提升数据质量：命名实体识别与标注

• 前路漫漫：迭代开发

• 结论

临床前药物发现本质上是复杂且数据密集的。研究人员在这一关键阶段面临着高效访问和分析大量信息的显著挑战。传统的基于关键词的搜索方法，通常依赖于僵硬的布尔逻辑，在面对临床前研究问题的复杂性和细微差别时，常常显得力不从心。

大型语言模型（LLMs）的出现带来了变革性的机遇。通过将LLMs的生成能力与信息检索系统的精确性相结合，增强检索生成（RAG）技术应运而生，成为一种有前景的方法。这种方法有潜力彻底改变临床前数据的访问方式，使研究人员能够用自然语言提出复杂问题，并基于专有数据获得准确且内容丰富的答案。

早期认识到这一潜力，拜耳公司致力于探索这些技术如何解决临床前研究中的长期挑战。

在本文中，我们将分享这段旅程——拜耳早期对生成式人工智能的投资如何催生了PRINCE，一个基于Agentic RAG的智能代理AI系统。本案例研究探讨了技术架构、工程决策以及在将临床前数据检索从一个复杂的迷宫转变为直观对话体验过程中所学到的经验教训。

PRINCE背后的许多工程决策现在可以通过“上下文工程”和“支撑工程”的视角来理解，尽管在系统最初设计时，我们并未使用这些术语。上下文工程决定了每个模型接收到的信息、未接收到的信息，以及上下文如何在诸如研究、反思和撰写等专门步骤之间流动。支撑工程则决定了围绕模型的支撑结构：协调、工具边界、状态持久性、重试、后备方案、验证、反思循环、可观测性以及人工审核。

尽管本文重点介绍技术架构和工程挑战，但我们在《人工智能前沿》期刊上发表的论文则更详细地涵盖了产品演进和商业影响。

挑战：穿越临床前数据迷宫

拜耳的临床前研究环境，与许多大型制药公司一样，其特点是数据种类繁多且范围广泛。这包括来自各种研究的结构化数据集，以及嵌入在研究报告、出版物和监管提交等文本文档中的大量非结构化信息。研究人员在访问和分析这些信息时经常遇到重大障碍：

• 数据孤岛：信息分散在众多不同的系统和存储库中，使得难以获得与特定化合物或研究相关的临床前数据的全面、整体视图。

• 搜索能力有限：传统的基于关键词的搜索引擎难以应对临床前术语和研究问题的复杂性和多样性，通常会返回不相关、不完整或过于繁杂的结果。

• 耗时的手动分析：从多个文档中提取特定见解或汇总信息需要大量手动操作，这使研究人员宝贵的时间远离核心科研活动。

这些固有的挑战凸显出对更高效、智能和集成的临床前数据检索和分析方法的迫切需求。

解决方案：PRINCE——一个演进平台

为了解决这些挑战，拜耳开发了临床前信息中心（PRINCE）平台。PRINCE最初被构想为一个统一的临床前数据入口，重点在于整合之前孤立的结构化研究元数据，并以“可搜索”的方式呈现。这一初始阶段使用户能够使用高级筛选功能，主要从结构化研究元数据中检索信息。

然而，拜耳大量宝贵的临床前知识仍然存在于几十年来积累的非结构化PDF研究报告中。由于多年来经历了多次系统迁移，这些报告的结构化元数据可能不完整、缺失，甚至包含错误的注释。关键的是，权威的“黄金标准”信息始终存在于经过批准的PDF研究报告中。

生成式人工智能的出现，特别是RAG（检索增强生成）技术，为解锁这些非结构化数据的丰富价值提供了关键途径。通过集成RAG功能，PRINCE开始从基于过滤的“搜索”工具转变为基于自然语言的“提问”系统，使研究人员能够直接查询这些研究报告的内容。

这一演变反映了PRINCE经历了三个不同的阶段：

• 搜索：初始阶段的重点是创建一个统一的入口，用于访问数千份非临床研究报告，将来自各种临床前领域的多个内部数据孤岛整合为可搜索的格式，主要依赖结构化元数据。

• 提问：这一阶段引入了基于人工智能的问答系统，利用检索增强生成（RAG）技术。这使得研究人员能够通过自然语言提问，直接从非结构化数据中获取见解，包括来自历史报告的扫描PDF文件。

• 执行：当前阶段将PRINCE定位为一个能够执行复杂任务的主动研究助手。这是通过集成多智能体系统实现的，使平台能够处理复杂的查询、协调工作流程，并支持诸如起草监管文件等活动。

从“搜索”到“提问”再到“执行”的这一有意识的演变，是对行业在临床前开发中对更高效率和创新需求的战略回应。通过为研究人员提供越来越强大的工具，以访问、分析并采取行动于临床前数据，PRINCE旨在实现更快的数据驱动决策，减少不必要的实验需求，最终加快更安全、更有效疗法的开发。

系统架构：构建一个可靠智能的RAG系统

该系统作为一个交互式对话用户界面运行，由一个强大的后端基础设施提供支持。其架构设计用于处理复杂查询并提供准确、内容丰富的答案，通过LangGraph进行协调，并通过FastAPI应用程序进行服务。

图1展示了系统上下文，包括用户界面、后端、数据存储、LLM后备系统和可观测性，而图2则深入展示了系统如何协调其专业智能体。

图1：系统上下文和支撑平台。

• 用户请求：流程从用户通过基于React构建的对话式用户界面提交请求开始。

• 协调：用户的请求被路由到后端基于LangGraph的协调层。这个工作流引擎协调一个多阶段的过程，依次进行明确用户意图、思考和规划、开展研究（使用RAG和Text-to-SQL）、验证数据完整性，最后通过Writer智能体生成响应。工作流中包含有意识的暂停点和反馈循环，以确保数据完整性后再继续。我们将在后面专门的章节中探讨这一智能体工作流的详细内容。

• 数据检索和状态管理：研究员智能体与一个全面且分布式的数据生态系统进行交互：

• 所有研究报告的向量表示存储在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 的合成上下文。这减少了上下文污染，使系统更容易调试、评估和改进。

这些步骤确保系统能够通过利用复杂的多代理架构和多样化的强大工具和数据源，为各种复杂查询提供可靠且上下文相关的答案。

Agentic RAG 系统

PRINCE 集成了一个智能代理的 RAG 系统（图 2），用于处理需要多步骤、推理和与不同工具或数据源交互的复杂用户请求。该设置使用 LangGraph 实现，协调整体工作流程，并利用 Researcher Agent、Writer Agent 和 Reflection Agent 来执行特定任务。该系统设计为稳健可靠，具备多种备用机制，以确保即使某些组件发生故障，系统仍能继续正常运行。

图 2：研究工作流程。

明确用户意图

“明确用户意图”步骤是防止模糊性的第一道防线。随着系统扩展到包括毒理学和药理学等多样化领域，简单的用户查询常常变得模糊，使得自动选择合适的工具变得困难。为了避免在所有数据源上进行昂贵的试错，系统会主动提出澄清性问题，以明确特定领域或数据类型。

这确保了系统能够增强查询，添加必要的约束条件，以定位正确的工具。我们还在通过开发 UI 级别的领域选择功能来优化这一过程，这将允许用户在开始之前预先筛选有效的工具。为了进一步减少摩擦，系统还提供 AI 辅助的来源推荐：当用户尚未选择任何数据源，或者选择了多个但没有明确的重点时，模型会分析用户查询背后的意图，并推荐最相关的来源。用户始终保有完全的控制权，可以接受、调整或覆盖推荐，确保领域专业知识始终拥有最终决定权。这种“快速失败”机制可以防止在模糊查询上浪费执行资源，而精细的调整则确保系统在意图明确时保持不干扰。

从上下文工程的角度来看，这一步是工作流程中的第一个组装决策：它在任何检索开始之前，限制了哪些工具、领域和数据源将被纳入范围，确保后续代理接收到的是一个明确的问题，而不是开放性的问题。

这个“思考空间”在涉及多次工具调用的场景中已被证明特别有价值。当 PRINCE 最初开发时，它只拥有几个工具：一个用于基于 RAG 的检索，另一个用于 Text-to-SQL 查询。然而，随着我们集成更多数据源以扩展系统功能，可用工具的数量显著增加。随着工具数量的激增，也带来了固有的挑战：不同工具之间在关注点和领域边界上存在重叠。

例如，多个工具可能具有类似但细微不同的用途——查询结构化元数据与非结构化报告，或检索研究摘要与详细实验数据。当面对属于相似领域但处理数据略有不同的工具时，LLM 有时会难以选择最适合特定查询的工具。通过引入一个专门的思考步骤，系统可以明确推理出哪个工具最符合用户的意图，评估每个可用工具的特性，并做出更明智的决策。这种方法显著提高了工具选择的准确性。

除了工具选择，Think & Plan 步骤对于协调多步骤流程至关重要。PRINCE 中的许多复杂查询需要一系列工具调用，其中一步的输出必须被分析后才能决定下一步操作。例如，系统可能首先查询结构化元数据以识别相关研究，然后使用这些研究 ID 从非结构化报告中检索详细信息，最后综合这些发现。如果没有专门用于流程反思的空间，系统将试图线性执行这些步骤，而不会评估每一步是否使它更接近目标。有了思考步骤，系统可以暂停，评估其在工作流程中的进展，并智能规划完成用户请求所需的后续工具调用。

研究员代理

研究员代理是系统的主要信息收集者。当我们将新的科学领域引入 PRINCE 时，我们始终观察到数据主要分为两类：结构化和非结构化。虽然不同领域在具体实现技术上可能有所不同——例如，药理学查询使用 Snowflake Cortex Analyst 进行 Text-to-SQL，而毒理学则使用其他更定制的方法——但这些检索策略背后的基本原理保持一致。

随着 PRINCE 涵盖多个临床前领域，一个拥有扁平工具列表的单一研究员代理变得越来越难以管理。许多工具基于类似的概念——“研究”、“发现”、“实验”——但根据领域不同，它们指向不同的底层数据集、模式和监管解释。例如，当用户提到“这项研究”时，相关上下文可能是重复剂量毒理学研究、心血管安全药理学包，或聚合质量数据表中的特定实验，每个都有其首选的权威数据来源。

为了避免一个单一的智能体同时处理重叠的工具和细微不同的数据契约，我们正在积极将 Researcher 能力演进为一个领域特定的子智能体层次结构。在这一架构设想中，每个领域智能体将拥有自己的工具集（例如，毒理学 RAG + 毒理元数据 SQL，或药理学 RAG + 实验级别 SQL），以及专门的提示指令，这些指令编码了该领域数据模型的工作方式、哪些表或索引是权威的，以及如何解释关键概念。我们预计，这种方式将使职责更加清晰，减少跨领域信息泄露的意外发生，并使按领域分析和测试检索行为变得更加容易。

为了有效地从这一多样化的知识图景中提取洞见，Researcher Agent 采用了一种混合检索方法，重点关注两种不同的模式：

• 检索增强生成（RAG）：用于处理非结构化数据，主要是 PDF 报告。

• 文本到 SQL（Text-to-SQL）：用于查询存储在 Amazon Athena 中的结构化数据。

这种双策略使系统能够弥合叙事性科学报告与定量实验数据之间的差距。

在这一更新的构想中，顶层的 Researcher Agent 被设计为一个协调者，而不是一个全能的单一组件。在用户意图明确以及 UI 中明确选择领域的情况下，它将查询路由到相应的领域子智能体，然后该子智能体可以决定如何在其自身范围内结合 RAG 和 Text-to-SQL。这一模式旨在从用户的角度保持“一个研究员”的简洁性，同时在内部允许每个领域独立发展自己的工具、模式和检索方案，而不会影响整个系统的稳定性。

#### 用于非结构化数据的检索增强生成（RAG）

鉴于有成千上万份临床前研究报告和其他非结构化文档的庞大知识库，RAG 对于通过将大语言模型（LLM）的响应扎根于这一特定知识库中来提取相关洞见至关重要。RAG 流程包括一个全面的摄入过程和一个复杂的查询时架构。

摄入过程：临床前研究报告，主要是跨越数十年的 PDF 文档，通常包括带有复杂表格的扫描文档，首先被集中到 S3 数据湖中，并通过为该语料库定制的提取流程进行处理。提取出的文本被标准化为结构化的 JSON 格式，然后使用一种策略进行分块，该策略在保留足够的科学上下文的同时，确保分块对检索高效。

每个分块都会从 Amazon Athena 中添加研究和章节级别的元数据（例如研究 ID、化合物、物种、给药途径、页面和父章节），这些元数据在 RAG 层中稍后可用于精确的元数据过滤。最后，这些注释后的分块被嵌入并索引到 Amazon OpenSearch Service 中，形成一个向量存储库，用于对历史语料库和每日新增或更新的报告进行语义和元数据感知的检索。

查询时的 RAG 流程：当用户提交查询时，系统会启动一个多阶段的检索过程。该流程经过设计，能够有效地从向量数据库中检索出最相关且可信的信息，以支撑大语言模型的响应。

为了说明这一流程，我们以以下示例查询为例：“在研究 T123456-2 中是否观察到以下任何临床发现：竖毛、共济失调、眼睛部分闭合和稀便？”。系统通过以下步骤处理该查询：

• 关键词提取：首先，用户的自然语言查询由一个大语言模型（LLM）进行分析。通过精心设计的提示工程，模型被指导提取与文档语料库中关键词搜索高度相关的关键词（例如：“竖毛”、“共济失调”、“眼睛部分闭合”、“稀便”）。

• 元数据过滤器生成：同时，LLM 根据查询生成一个元数据过滤器。例如，提取一个 eq(study_id, T123456-2) 的过滤器，以缩小搜索范围。该过滤器是通过向模型提供各种排列组合示例，并使用少量样本提示（few-shot prompting）动态生成的，确保其能够处理多样化的过滤请求。

• 查询扩展：为了确保全面检索并考虑到措辞和术语的差异，通过一个更小、更快的模型执行查询扩展（多查询或查询重写）。这会基于原始问题生成 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）随后通过重排序步骤进行优化。一个交叉编码器模型（bge-reranker-large）评估每个检索到的片段与原始问题的相关性，选择最相关的前k=7个片段作为LLM的上下文。这一步重排序对于确保最相关的信息（即使在初始语义相似度或关键词匹配中不是最高）在最终响应生成中被优先考虑至关重要。

• 最终LLM提示生成：优化后的上下文（k=7个片段）随后与原始问题结合，形成最终的LLM提示。该提示经过精心构建，以指导LLM基于提供的上下文生成一个聚焦且准确的响应，从而降低幻觉的风险。

• 带引用的响应生成：一个先进的推理模型随后处理最终的提示和提供的上下文，生成带有引用的响应。LLM从上下文中综合信息，形成连贯且准确的答案。关键的是，响应会自动包含引用，链接到原始文档中支持生成答案的具体片段。

• 监控：整个查询时RAG流程，从初始查询到最终响应生成，使用Langfuse进行持续监控，以实现可观测性、性能和质量分析。

#### 结构化数据的文本到SQL

虽然RAG在处理非结构化数据方面表现出色，但需要对结构化数据点进行精确过滤、聚合或比较的查询更适合使用文本到SQL。例如，“给我50个关于RAT的研究示例”或检索包含剂量组的具体数值实验结果。如图3所示，研究员代理可以智能地决定将此类查询转交给文本到SQL工具。

图3：文本到SQL工具

将自然语言问题转换为可执行的SQL查询并检索结果的过程包括以下几个关键步骤：

• 查询分析与意图识别：分析用户的自然语言查询，以理解用户的意图并识别用户从结构化元数据中请求的具体数据点和过滤条件。

• 模式理解与相关模式选择：为了准确生成SQL查询，LLM需要理解相关的数据库模式。对于大而复杂的模式，仅将与用户查询相关的必要模式组件动态注入到LLM的上下文中。这减少了模型的复杂性，并提高了生成SQL的准确性。

• 动态少样本提示用于 SQL 生成：将复杂的自然语言查询转换为精确的 SQL 方言（在我们的情况下是 Athena）对 LLM 来说可能具有挑战性。为了解决这个问题，我们采用动态少样本提示。一组经过精心挑选的示例，代表各种复杂的查询模式及其对应的 Athena 方言的正确 SQL 翻译，存储在我们向量数据库中的一个独立集合中。根据用户的查询，使用向量相似性搜索从这个“语义层”中检索相关示例，并将其包含在 LLM 的提示中。这为 LLM 提供了上下文学习的示例，引导其生成符合正确方言的准确 SQL 查询。随着时间的推移，基于遇到的挑战不断添加新的示例，进一步提高了系统的性能。

• SQL 查询生成与验证：一个具有强大代码生成能力的模型，在相关模式信息和动态少样本示例的条件下，生成对应的 SQL 查询。为了确保 LLM 能够准确处理结果并识别后续合成所需的正确行，某些关键列（如研究 ID 和研究标题）始终包含在生成的 SELECT 查询中。生成的查询随后会被验证，以确保其符合允许的操作（例如，仅允许 SELECT 查询；DELETE、INSERT 或 UPDATE 查询会被明确阻止，以维护数据完整性和安全性）。值得注意的是，此流程的早期版本包括一个 LLM 审查生成 SQL 查询的步骤；然而，后来这个步骤被移除了，因为发现审查的 LLM 有时会错误地将有效的查询标记为错误，这在没有相应准确度提升的情况下降低了效率。

• 查询执行与结果限制：经过验证的 SQL 查询在 Amazon Athena 的结构化元数据数据库中执行。为了防止数据泛滥并管理响应大小，系统强制实施一个限制，每次最多获取 50 条记录。

• 错误处理与迭代：如果 SQL 查询执行成功，检索到的结果（最多为指定限制）将被返回并整合到整体响应生成过程中。如果查询由于语法错误、模式问题或其他执行错误而失败，数据库的错误信息、生成的查询和原始上下文将被传递回同一模型。LLM 分析错误和上下文以生成更正后的 SQL 查询。此生成和执行 SQL 查询的迭代过程最多尝试 3 次，如果工具失败并报告失败，可能表明查询无法解决或模型处理特定请求的能力存在限制。

反思代理：数据验证与充分性

虽然 Think & Plan 步骤提供了流程反思，但反思代理执行的是互补但不同的反思类型：数据反思。这个关键组件评估从各种工具中检索到的数据是否足够且相关，以回答用户的问题——这是一个与工作流程本身是否正确推进截然不同的关注点。

在多步骤的智能体工作流程中，这两种类型的反思具有不同但同样重要的作用。过程反思（Think & Plan）确保智能体采取了正确的步骤，并朝着目标取得适当的进展。数据反思（Reflection Agent）确保通过这些步骤收集到的信息足以满足用户的请求。两者都至关重要：一个智能体可能执行了一个完全有效的流程（良好的过程），但仍可能获取到不足以回答问题的数据；反之，它可能拥有足够的数据，但无法有效地推进流程。

如研究工作流程图（图2）所示，在初始信息检索和“Think & Plan”循环之后，当“Think & Plan”步骤认为流程已经进展得足够好并准备评估数据时，就会调用Reflection Agent。“Reflection Agent”通过将检索到的上下文与用户的原始查询进行比较，评估所收集数据的充分性和相关性，并识别潜在的差距或缺失信息。如果认为收集到的信息不足以提供完整的回答，Reflection Agent将生成特定的后续问题，以获取必要的缺失信息。这些后续问题随后会被送回“Think & Plan”步骤，该步骤将启动进一步的检索步骤以获取更全面的结果。由Reflection Agent生成的问题驱动的数据验证和后续信息检索的迭代过程，展示了系统根据初始结果优化搜索策略的能力。如果信息足够，工作流程将进入下一步。

Writer Agent：答案合成与格式化

一旦Researcher Agent从RAG和Text-to-SQL中收集了相关证据，Writer Agent就负责将这些原始材料转化为最终展示给用户答案。它的职责不是“发现”新信息，而是合成检索到的上下文，遵守用户的指令，并在生成过程中执行PRINCE的质量约束。

Writer Agent遵循一些不可协商的规则。它必须将每一个主张都基于提供的上下文，并准确地引用回底层的块和研究ID，因为在受监管的环境中，可验证性至关重要。它还负责遵守用户级别的格式要求（例如表格、项目符号或特定的章节结构），并符合临床前科学家使用的领域特定答案标准。

对于更复杂的回答，如多部分摘要或部分填充的监管模板，架构支持通过一个简短的内部审查循环来扩展Writer Agent。在这种模式下，Writer首先会起草一个答案，然后审查步骤会检查是否有缺失的章节、不一致的表格或相对于原始问题的差距，并可能将有针对性的指令发送回Writer以修订特定部分。这种设计实现了一种轻量级的反思形式，专注于答案的完整性和呈现，补充了工作流程早期Reflection Agent对数据充分性的关注。重要的是，这些监管起草工作流程的所有输出都是供专家审查的；最终提交由合格人员撰写并批准。

这为 PRINCE 提供了三个互补的反思循环。流程反思用于检查工作流程是否在正确的轨道上，并有助于发现不良的轨迹、错误的工具选择或较差的顺序安排。数据反思用于检查收集到的证据是否充分，并有助于发现证据不足、上下文缺失或覆盖范围的空白。草稿反思用于检查生成的输出是否完整，并有助于发现遗漏的部分、表格不完整或综合分析的空白。

这些代理共同形成了一种实用的上下文工程模式。系统并不是简单地不断向提示中添加更多信息，而是在合适的时间将合适的上下文路由到合适的功能模块：规划上下文用于“思考与规划”，检索上下文用于研究员，证据上下文用于反思代理，综合上下文用于撰写代理。这种机制在系统中的具体决策中体现出来：文本到 SQL 的步骤仅注入与当前查询相关的模式组件，而不是完整的数据库模式；反思代理接收到原始问题和收集到的证据，用于评估缺失的部分，而不是完整的流程历史；撰写代理接收到经过筛选的片段和引用约束，而不是原始的检索结果。从一个单一的代理转向这种结构化的流程，意味着每个代理都可以独立地进行评估、调试和改进。

在生产级 LLM 系统中建立信任

建立和维护用户信任对于任何 AI 系统的成功采用至关重要，特别是在像临床前药物发现这样关键的环境中，其中的决策具有重大影响。对于一个生产级的 LLM 应用，信任不仅仅是关于准确性，还涉及可靠性、透明度以及用户验证所提供信息的能力。PRINCE 集成了多种机制以实现这一点：

透明度与可解释性

确保透明度和可解释性是 PRINCE 设计中的关键方面，有助于建立用户信任并使生成的响应可以被验证。系统采用多种机制来实现这一点：

• 中间步骤与透明度：鉴于工作流程的迭代性质以及生成最终答案可能需要的时间，保持透明度至关重要。在查询处理、信息检索和反思过程中，系统执行的中间步骤（包括制定的查询和使用的工具）会显示给用户。这为用户提供了系统推理过程的可见性，并允许用户跟踪系统采取的步骤以得出最终答案。此外，当识别出相关上下文（片段）时，系统会将这些来源材料的链接显示在屏幕上，使用户能够清楚地看到哪些信息被精选并用于形成最终响应。

• 通过引用进行事实核查：该系统通过强大的引用机制，使用户能够验证事实的准确性。生成的答案始终伴随着引用，这些引用指向原始来源文档和结构化元数据。这些引用直接链接到显示给用户的上下文，使用户能够轻松验证响应中所作声明的准确性，并追溯信息的来源。用户可以将鼠标悬停在生成响应中的任何句子上，查看对应的引用，该引用提供了链接到PRINCE以及源文档的链接，包括页面编号和用于支持该部分答案的报告中的确切引用。这种粒度级别的引用显著提高了系统输出的可信度和可靠性，并简化了人工审查过程。

评估

严格的评估是构建和维护可靠的大型语言模型（LLM）应用的基础。PRINCE的性能和可靠性通过两种类型的评估进行评估：数据集评估和实时流量评估。

• 数据集评估：每当对核心工作流程、提示或底层模型进行重大更改时，都会进行这些评估。这些评估使用精心策划的数据集，其中包含预定义的参考答案，这些答案由领域专家仔细准备并存储在Langfuse中。一个自定义的评估脚本处理每个问题，并将生成的响应与参考答案进行比较，从而产生诸如“可信度”（答案在多大程度上由上下文支持）、“答案相关性”（答案在多大程度上解决了查询）、“上下文相关性”（检索到的片段的相关性）、“答案准确性”（与真实情况的比较）以及“与参考答案的语义相似性”（与参考答案的语义相似性）等定量指标。鉴于系统的代理性质，在不同工作流程阶段应用适当的评估指标（类似于测试金字塔）至关重要，这除了评估整体端到端性能外，还对系统的各个阶段进行评估。

• 实时流量评估：这些评估每天作为批处理作业在实时环境中进行，使用来自真实用户的查询（没有预定义的参考答案）。这些评估提供了对实际性能的宝贵见解。仍然可以评估诸如“可信度”和“答案相关性”等指标。实时流量评估对于监控系统行为、识别生产环境中的潜在问题（如幻觉）以及了解在各种实时查询上的表现至关重要。

监控

在生产环境中，持续监控系统的性能和输出对于主动识别和解决问题是至关重要的。使用诸如Langfuse等平台，我们持续监控PRINCE，以识别潜在的偏见、错误或改进领域，确保系统响应的可靠性和安全性。

为弹性而设计：错误处理与恢复

鉴于PRINCE中固有的多步骤工作流程的复杂性，强大的错误处理和恢复机制对于确保系统的可靠性并提供无缝的用户体验至关重要。该系统被设计为能够从各个阶段的故障中优雅地恢复，而无需整个工作流程的完全重启。

我们错误处理和恢复方法的关键方面包括：

• 状态持久化：整个工作流图的状态被持久化存储，使系统能够直接从失败的节点恢复执行。这是通过将 Agent State（表示代理在工作流中的进度）存储在 Postgres 中实现的。应用程序状态的其他方面，如日志、中间步骤和引用信息，则存储在 DynamoDB 中。这种状态的分离和持久化对于实现有状态代理系统的健壮性至关重要。

• 内置重试机制：系统在工作流的多个步骤中配置了内置的重试机制。如果某个步骤遇到短暂性失败，系统会自动尝试重新执行该步骤预定义的次数，然后再发出更持久性错误的信号。

• 用户发起的重试：除了自动重试之外，用户还可以通过界面手动重试失败的查询。当用户发起重试时，系统会利用持久化状态，直接从失败点继续执行工作流，并智能地跳过上一次尝试中已成功完成的步骤。这显著提升了用户体验，并节省了计算资源。

• 框架级支持：错误恢复机制得到了底层框架 LangGraph 的显著支持，该框架提供了强大的内置功能，用于管理工作流状态并在图结构中处理错误。这为构建健壮的代理工作流提供了坚实的基础。

• LLM 备用机制：为了提高可靠性并缓解与模型可用性或性能相关的问题，系统集成了自定义的 LLM 备用处理机制。如果对主要 LLM 提供商或特定模型的调用在几次重试后仍失败，系统会自动切换到来自不同提供商的备用 LLM。这种机制对于维护系统的可用性和响应性至关重要，尤其是在外部服务的平台停机时间超出我们直接控制范围的情况下。

这种全面的错误处理和恢复方法最大限度地减少了短暂性故障的影响，减少了用户需要从头开始重新启动复杂查询的需要，并通过避免重复执行已成功完成的步骤和 LLM 调用，节省了成本和延迟，所有这些都是构建生产就绪系统所必需的。

这些机制是实际工程中的“控制装置”。LangGraph 工作流充当代理的控制层：它定义了哪些组件可以执行操作，可以使用哪些工具，工作流可以在哪些位置暂停，如何重试失败，如何持久化状态，以及系统何时应从研究阶段过渡到反思阶段，再过渡到写作阶段。这种控制装置使系统比无约束的自主代理更加透明和可靠。它为系统的恢复、检查、评估和人工干预提供了明确的控制点。

提高数据质量：命名实体识别和标注

Amazon Athena 中结构化元数据的准确性和完整性对于 Text-to-SQL 组件的性能以及 PRINCE 内部整体数据的可发现性至关重要。由于拜耳长期运营历史中存在历史数据迁移以及不同实验室和系统之间标注实践的差异，元数据有时可能不完整、缺失或错误。

为了解决这一挑战并持续提升结构化元数据的质量，我们开发了一个实用系统，该系统利用命名实体识别（Named Entity Recognition, NER）直接从研究PDF中提取并创建准确的注释。该系统旨在读取临床前报告的文本内容，并识别应包含在结构化元数据中的关键实体和相关信息。

该过程包括以下步骤：

• 处理研究PDF，提取文本并识别相关实体（例如，研究ID、化合物名称、物种、给药途径、剂量信息、临床发现等）。

• 基于识别出的实体及其在文本中的关系，生成结构化注释。

我们正在积极将这一实用系统集成到我们的数据管道中，以自动纠正和丰富Amazon Athena数据库中的数据。该系统在生成准确注释方面的性能已通过精选数据集进行评估，结果令人鼓舞。为了管理这些注释向生产数据库的集成，我们正在开发一个评估系统，为每个提取字段提供一个置信度评分。置信度较高的字段将自动用于更新Amazon Athena中的相应条目。置信度较低的字段将被隔离并标记，以供人工审核和干预，从而在利用自动化的同时确保数据的准确性。这种方法旨在持续提升结构化元数据的质量，使其成为PRINCE及其他下游应用更加可靠的信息来源。

持续前行：迭代开发

自2024年初以来，PRINCE已向终端用户开放使用，而代理集成功能则是在同年后期引入的。这一过程对于收集真实世界的反馈并推动迭代开发至关重要。我们开发过程中遵循的一个关键原则是：构建一个生产就绪的大型语言模型（LLM）应用是一个迭代过程；我们不会等到功能绝对完美后再寻求用户反馈。相反，我们优先尽早交付价值，并根据实际使用情况持续优化系统。

在初期阶段，我们的重点是实现核心功能所需的准确性和性能，即使这意味着要承担更高的成本。我们认识到，过早优化成本可能会损害系统的有效性并阻碍用户采用。只有在达到预期的准确性和性能水平后，我们才开始关注成本优化，确保效率提升不会对用户体验或结果质量产生负面影响。

PRINCE的开发遵循持续的迭代过程。用户反馈、持续的监控数据以及专家科学家的见解不断反馈到开发周期中，从而对架构、检索技术、代理行为和用户界面进行优化，以提升性能、可用性，最终增强科学影响力。

结论

在像临床前药物发现这样复杂的企业环境中构建一个生产就绪的大型语言模型（LLM）应用，是一段充满重大技术和工程挑战的旅程。PRINCE案例研究表明，通过结合强大的数据基础设施、先进的信息检索技术（如RAG和Text-to-SQL）以及智能的多代理协调系统，可以从中提取出宝贵的信息，这些信息此前一直难以访问。

我们的经验强调了专注于工程可靠性的重要性，包括强大的错误处理、状态持久化和LLM的回退机制。此外，建立用户信任至关重要，这可以通过工作流程的透明性、通过细粒度引用实现的清晰可解释性，以及对系统性能的持续评估和监控来实现。

PRINCE已经在拜耳公司提升了数据可访问性和研究效率方面展现出令人鼓舞的成果，改变了科学家与临床前信息的互动方式。这并不是旅程的终点，而是朝着创建真正智能的研究助手迈出的重要一步。

PRINCE带来的更广泛教训是，生产就绪的代理AI不仅仅是更好的模型或更好的提示。可靠性来自于对模型所看到的上下文和模型所执行的控制机制的工程设计。上下文工程确保了每个模型在工作流程的适当阶段拥有正确的信息，且仅拥有正确的信息。控制机制工程确保了工作流程保持有界、可观察、可恢复，并且适合于受监管的研究环境。

随着模型能力的提升，今天控制机制的一些部分可能会变得更薄或融入模型的原生能力中。但在企业研究系统中，特别是在信任、可追溯性和可审查性至关重要的地方，对上下文、工作流程状态、恢复、反思和验证的显式控制仍然是必不可少的。

我们希望此次概述能够为在受监管且数据丰富的领域构建和生产化LLM应用所需的实践考量和技术深度提供有价值的见解。

致谢

作者衷心感谢拜耳团队的Adam Zalewski、Annika Kreuchwig、Carlos Henrique Vieira-Vieira、Jobst Löffler和Jonas Münch所做出的宝贵贡献。

作者也感谢Thoughtworks团队的Bala Hari、Balu Saravanan、Bernice Mercy Sharon M、Deril X、Jigar Jani、Manibalan Baskaran、Nafis Aslam、Priyalakshmi R、Rohit Bansal、Sai Prabhanj Turaga、Saksham Srivastava、Shivam Sehgal、Sowmya Adimoulame和Subhashini Rajamani对本工作的贡献。

作者在撰写本文时使用了AI辅助。AI工具用于头脑风暴、创建大纲以及审阅草稿，以润色语言并提高清晰度。

免责声明

文中所述所有活动均符合拜耳的信息分类、数据治理和外部沟通政策，不构成对监管决策或产品性能的声明。

重大修订

2026年6月16日：发布