构建可靠的智能体式人工智能系统

临床前药物发现本质上复杂且数据密集。研究人员面临的重大挑战是，在这一关键阶段高效访问和分析海量信息。传统的基于关键词搜索的方法，往往依赖僵化的布尔逻辑，在面对临床前研究问题细腻而复杂的特性时，常常力有未逮。

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

拜耳很早就认识到了这一潜力，并承诺探索这些技术如何解决临床前研究中的长期难题。

在这篇文章中，我们分享这段历程——拜耳对生成式 AI 的早期投入如何孕育出 PRINCE，这是一套建立在 Agentic RAG 之上的智能体 AI 系统。本案例研究将探讨其技术架构、工程决策，以及如何将临床前数据检索从令人头疼的迷宫转变为直观的对话式体验。

如今，PRINCE 背后的许多工程决策都可以从上下文工程和控制架构工程（harness engineering）的视角来理解，尽管在系统最初设计时我们并未使用这些术语。上下文工程决定了每个模型接收哪些信息、不会接收哪些信息，以及上下文如何在研究、反思和写作等专门步骤之间流转。控制架构工程则塑造了模型外部的支撑框架：编排、工具边界、状态持久化、重试、回退、校验、反思循环、可观测性以及人工审查。

虽然本文重点关注技术架构和工程挑战，但我们发表于 Frontiers in Artificial Intelligence 的论文更详细地介绍了产品演进和业务影响。

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

为应对这些挑战，拜耳开发了临床前信息中心（PRINCE）平台。PRINCE 最初被构想为临床前数据的统一入口，起初重点是整合此前分散的结构化研究元数据，并以“可搜索”的方式向用户开放。第一阶段允许用户应用高级筛选条件，主要从结构化研究元数据中检索信息。

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

生成式 AI，尤其是 RAG 的出现，为释放这些非结构化数据的价值提供了关键钥匙。通过集成 RAG 能力，PRINCE 开始将范式从基于筛选的“搜索”工具转变为自然语言“问答”系统，使研究人员能够直接查询这些研究报告的内容。

这一演进体现了 PRINCE 所经历的三个明确阶段：

Search：初始阶段的重点是为成千上万份非临床研究报告构建统一入口，将来自不同临床前领域的多个内部数据孤岛整合为可搜索格式，主要依赖结构化元数据。
Ask：这一阶段引入了基于 AI 的问答系统，采用检索增强生成（RAG）。研究人员因此能够通过自然语言提问，直接从非结构化数据中获取洞见，包括历史报告中扫描版 PDF 的内容。
Do：当前阶段将 PRINCE 定位为可执行复杂任务的主动型研究助手。这是通过集成多智能体系统实现的，使平台能够处理复杂查询、编排工作流，并支持起草法规文件等活动。

从 Search 到 Ask 再到 Do 的有意识演进，体现了行业对临床前研发更高效率与创新能力的需求所作出的战略回应。通过为研究人员提供越来越强大的工具来访问、分析并利用临床前数据，PRINCE 旨在加快数据驱动决策，减少不必要实验的需求，并最终加速更安全、更有效疗法的开发。

系统架构：构建可靠的 Agentic RAG 系统

该系统作为一个交互式对话界面运行，由强大的后端基础设施提供支持。其架构旨在处理复杂查询并提供准确、上下文丰富的答案，由 LangGraph 编排，并通过 FastAPI 应用提供服务。

图 1 展示了系统上下文——用户界面、后端、数据存储、LLM 回退机制以及可观测性——而图 2 则进一步展示了系统如何协调其专门智能体。

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

用户请求：当用户通过基于 React 构建的对话式 UI 提交请求时，流程开始。
编排：用户请求被路由到后端基于 LangGraph 的编排层。这个工作流引擎协调一个多阶段流程，依次完成澄清用户意图、思考与规划、开展研究（使用 RAG 和 Text-to-SQL）、验证数据完整性，最后通过 Writer 智能体生成回复。该工作流包含刻意设置的暂停点和反馈回路，以确保在继续之前数据已完整。（我们会在后文专门章节中展开这一智能体工作流的细节。）
数据检索与状态管理：Researcher 智能体与一个全面且分布式的数据生态系统交互：
所有研究报告的向量表示存储在 OpenSearch 中，构成信息检索的核心知识库。
经过各种 ETL 和数据协调流程整理后的结构化数据可通过 Athena 访问。
智能体执行状态被细致追踪。每完成一个逻辑步骤（一个 LangGraph 节点执行），相应状态都会通过 LangGraph 检查点保存到 PostgreSQL 中。
更广泛的应用级状态则由 DynamoDB 管理。
系统利用内部 GenAI 平台承载来自 OpenAI、Anthropic、Google 和开源提供商的模型。这些平台通过统一的、与 OpenAI 兼容的端点暴露所有模型，便于切换模型并为每项任务选择最合适的工具。它们还负责控制平面管理，执行速率限制和其他安全措施以防止滥用。
稳健性与错误处理：系统稳健性是核心设计原则，内置了多种回退机制：
如果某个特定 LLM 失败，系统会在回退到替代模型或平台之前自动重试多次，以确保服务连续性。
为了快速恢复瞬时故障，重试机制既部署在单次 LLM 调用层面，也部署在逻辑节点层面（即智能体计划中的一个完整步骤）。
此外，系统还会向智能体提供错误上下文，使其能够据此调整轨迹或制定替代行动方案。
可观测性与评估：整个系统都受到性能和可靠性监控：
使用 Cloudwatch 跟踪整体系统健康状况和指标。
Langfuse 作为主要可观测性工具，提供所有生产流量的详细追踪。这有助于深入排查问题。此外，评估数据集也存储并管理在 Langfuse 中，便于分析性能评分和诊断特定失败。评估使用 RAGAS 评估框架完成。实时流量评估按日进行，而数据集评估则在核心工作流、提示词或底层模型发生重大变化时执行。
最终响应：一旦智能体处理完请求并生成令人满意的回复，结果会返回到对话式 UI，展示给用户。

贯穿这一架构的一项设计原则是上下文纪律。更大的上下文窗口并没有消除对每个智能体应看到哪些信息进行选择的必要。早期迭代中，向上下文中放入过多信息会让系统更难引导，也更难评估。因此，PRINCE 并不把提示词当作容纳所有可用信息的单一大容器。相反，不同阶段接收不同上下文：Think & Plan 需要规划上下文，Researcher Agent 需要检索上下文，Reflection Agent 需要证据上下文，而 Writer Agent 需要综合上下文。这减少了上下文污染，使系统更易于调试、评估和改进。

这些步骤确保系统能够借助复杂的多智能体架构和多样而强大的工具与数据源，为广泛的复杂查询提供可靠且具备上下文相关性的答案。

智能体式 RAG 系统

PRINCE 集成了一个智能体式 RAG 系统（图 2），用于处理需要多步骤、推理以及与不同工具或数据源交互的复杂用户请求。该方案使用 LangGraph 实现，负责编排整体工作流，并借助 Researcher Agent、Writer Agent 和 Reflection Agent 执行各自的专门任务。系统设计强调稳健与可靠，并提供多种回退机制，以确保即使部分组件失效，系统仍能持续运行。

图 2：研究工作流。

澄清用户意图

澄清用户意图 这一步是抵御歧义的第一道防线。随着系统扩展到毒理学、药理学等多个领域，简单的用户请求往往变得含糊不清，使得自动选择合适工具变得困难。系统并不依赖对所有数据源进行代价高昂的试错，而是主动提出澄清问题，以精确锁定特定领域或数据类型。

这确保系统能够在查询中补充必要约束，从而锁定正确工具。我们也在通过在 UI 中开发 领域级选择 来优化这一点，使用户能够预先筛选可用工具。为了进一步降低使用阻力，系统还提供 AI 辅助的来源推荐：当用户尚未选择任何数据源——或者选择了多个但没有明确重点——模型会分析用户查询背后的意图，并推荐最相关的数据来源。用户始终拥有最终控制权，可以接受、调整或覆盖该推荐，确保领域专家始终拥有最终决定权。这种“快速失败”机制可防止在模糊查询上浪费执行成本，而精细调优则确保当意图已经清晰时，系统不会显得突兀。

从上下文工程的角度看，这一步是工作流中的第一个装配决策：在任何检索开始之前，它先约束哪些工具、领域和数据源会被纳入范围，确保后续智能体面对的是一个聚焦的问题，而不是一个开放式难题。

思考与规划：过程反思

思考与规划 这一步负责制定满足用户请求的策略。这个关键组件为系统提供了一个专门的空间，在采取行动之前先推理下一步——这一技术受到 Anthropic 的 Think 工具启发。重要的是，这一步执行的是过程反思：评估智能体是否朝着最终目标取得了正确进展，轨迹是否正确，而不是评估数据本身。

在多步骤智能体工作流中，尤其是涉及大量顺序动作时，过程反思至关重要。设想一个场景，系统需要执行 50 步才能完成复杂任务。在每一个节点，系统都必须自问：我现在的步骤方式对吗？我是否在按预期取得进展？当前轨迹是否指向用户目标？思考与规划 这一步提供了这种元认知能力，使系统能够反思自身工作流，并据此调整策略。

这种“思考空间”在涉及多次工具调用的场景中尤其有价值。 PRINCE 最初开发时，只有少量工具：一个用于基于 RAG 的检索，另一个用于 Text-to-SQL 查询。然而，随着我们集成越来越多的数据源以扩展系统能力，可用工具数量显著增长。工具激增带来了一项固有挑战：不同工具之间存在重叠的职责和领域边界。

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

除了工具选择之外，思考与规划 这一步对于协调多步骤流程也至关重要。PRINCE 中许多复杂查询都需要一系列工具调用，其中一个工具的输出必须先经过分析，才能决定下一步动作。例如，系统可能先查询结构化元数据以识别相关研究，再利用这些研究 ID 从非结构化报告中提取详细信息，最后综合这些发现。如果没有专门的过程反思空间，系统就会线性执行这些步骤，而不会评估每一步是否更接近目标。借助思考步骤，系统可以暂停下来，评估工作流进展，并智能规划后续所需的工具调用，以完成用户请求。

Researcher 智能体

Researcher 智能体 是系统的主要信息收集者。随着我们将新的科学领域接入 PRINCE，我们持续观察到数据通常分为两大类：结构化 和 非结构化。虽然不同领域的具体实现技术可能不同——例如，药理学查询可能利用 Snowflake Cortex Analyst 进行 Text-to-SQL，而毒理学则采用其他更定制化的方法——但这些检索策略背后的基本原理保持一致。

随着 PRINCE 跨越多个临床前领域扩展，单个 Researcher 智能体若只维护一个平铺式工具列表，其管理难度会越来越大。许多工具都围绕相似概念运作——“研究”、“发现”、“检测”——但根据领域不同，它们指向的底层数据集、模式和监管解释却不同。例如，当用户提到“这项研究”时，相关上下文可能是一项重复给药毒理学研究、一套心血管安全性药理学资料，或聚合质量数据表中的某个特定检测，每一种情况都有其各自的权威来源。

为避免一个单体智能体同时处理重叠工具和细微不同的数据契约，我们正在积极将 Researcher 能力演进为层级化的、面向领域的子智能体。在这一设想架构中，每个领域智能体都将拥有自己的工具集（例如，毒理学 RAG + tox 元数据 SQL，或药理学 RAG + 检测级 SQL），以及定制化的提示词指令，用于编码该领域的数据模型如何工作、哪些表或索引是权威来源，以及如何解释关键概念。我们预计这将保持职责边界清晰，减少跨领域信息意外泄漏，并使按领域推理和测试检索行为更容易。

为有效从这一多样化的数据环境中提取洞见，Researcher 智能体采用一种混合检索器方法，聚焦两种不同模式：

检索增强生成（RAG）：用于处理非结构化数据，主要是 PDF 报告。
Text-to-SQL：用于查询存放在 Amazon Athena 中的结构化数据。

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

在这一更新后的愿景中，顶层 Researcher 智能体被设计为协调者，而不是一个无所不知的单一组件。在明确用户意图以及 UI 中任何显式领域选择之后，它会将查询路由到合适的领域子智能体，由后者决定如何在自身边界内组合 RAG 与 Text-to-SQL。这一模式旨在从用户视角保留“一个研究员”的简洁体验，同时在内部让每个领域能够各自演进工具、模式和检索方案，而不扰乱系统其他部分。

面向非结构化数据的检索增强生成（RAG）

鉴于系统拥有数千份临床前研究报告和其他非结构化文档的庞大存储库，RAG 对于从这一特定知识库中提取相关洞见、并以此为基础约束 LLM 响应至关重要。RAG 管道包含完整的摄取流程和复杂的查询时架构。

摄取流程： 临床前研究报告大多是跨越数十年的 PDF，其中经常包含扫描件和复杂表格。它们首先集中存储到 S3 数据湖中，并经过针对该语料库优化的提取流水线处理。提取出的文本会被规范化为结构化 JSON，然后通过一种既保留足够科学上下文、又便于检索的切分策略进行分块。

每个块都会附加来自 Amazon Athena 的研究级和章节级元数据（例如研究 ID、化合物、物种、给药途径、页码和父章节），这随后支持 RAG 层中的精确元数据过滤。最后，这些带注释的块被嵌入并索引到 Amazon OpenSearch Service，形成支撑语义检索与元数据感知检索的向量存储，覆盖历史语料库和新到或更新报告带来的每日增量。

查询时 RAG 流程： 当用户提交查询时，系统会启动一个多阶段检索流程。该流程经过精心设计，旨在从向量数据库中有效检索最相关且最可信的信息，以为 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）随后通过重排序步骤进一步精炼。一个交叉编码器模型（bge-reranker-large）会评估每个检索块相对于原始问题的相关性，选出最相关的前 k=7 个块作为 LLM 的上下文。这个重排序步骤至关重要，即使某些信息在初始语义相似度或关键词匹配中并非最高，也能确保最关键的信息被优先用于最终响应生成。
最终 LLM 提示词生成：精炼后的上下文（k=7 个块）与原始问题相结合，形成最终的 LLM 提示词。该提示词经过精心构造，引导 LLM 基于提供的上下文生成聚焦且准确的回答，将幻觉风险降至最低。
带引文的响应生成：最先进的推理模型随后处理最终提示词和提供的上下文，生成带引文的回答。LLM 综合上下文中的信息，形成连贯且准确的答案。至关重要的是，响应会自动附带引文，链接回原始文档中支持生成答案的具体块。
监控：整个查询时 RAG 流程，从初始查询到最终响应生成，都会使用 Langfuse 持续监控，以进行可观测性、性能与质量分析。

面向结构化数据的 Text-to-SQL

虽然 RAG 擅长处理非结构化数据，但需要精确筛选、聚合或比较结构化数据点的查询更适合 Text-to-SQL。例如，“给我 50 个在大鼠上完成的研究样例”或检索包含剂量组的特定数值检测结果。正如 Researcher Agent 所示，这类查询可由系统智能地决定交由 Text-to-SQL 工具处理。

图 3：Text-to-SQL 工具

将自然语言问题转换为可执行的 SQL 查询并检索结果的过程包含若干关键步骤：

查询分析与意图识别：分析用户的自然语言查询，以理解用户意图，并识别需要从结构化元数据中请求的具体数据点和筛选条件。
模式理解与相关模式选择：为了准确生成 SQL 查询，LLM 需要理解相关数据库模式。对于大型且复杂的模式，只会将与用户查询相关的必要模式组件动态注入到 LLM 的上下文中。这降低了模型复杂度，并提高了生成 SQL 的准确性。
用于 SQL 生成的动态少样本提示：将复杂自然语言查询转换为精确的 SQL 方言（在我们的场景中为 Athena）对 LLM 而言具有挑战。为此，我们采用动态少样本提示。我们在向量数据库的单独集合中存储了一组精心挑选的示例，这些示例代表各种复杂查询模式及其在 Athena 方言中的正确 SQL 翻译。根据用户查询，通过向量相似度搜索从这一“语义层”中检索相关示例，并将其纳入提示词中提供给 LLM。这为 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 则执行一种互补但不同的反思：数据反思。这一关键组件评估从各种工具检索到的数据是否足以且相关地回答用户问题——这与工作流本身是否正确推进是根本不同的关注点。

在多步骤智能体工作流中，这两类反思服务于不同但同样重要的目的。过程反思（Think & Plan）确保智能体朝着正确方向采取合适步骤并取得进展。数据反思（Reflection Agent）确保通过这些步骤收集到的信息足以满足用户请求。两者都不可或缺：智能体可能执行了完全有效的工作流（过程良好），却仍检索到不足以回答问题的数据；反之，也可能拥有充足数据，却无法有效推进工作流。

如研究工作流图（图 2）所示，在初始信息检索和“思考与规划”循环之后，当 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 就具备了三种相辅相成的反思循环。过程反思检查工作流是否走在正确路径上，有助于发现轨迹错误、工具选错或步骤顺序不当。数据反思检查收集到的证据是否充分，有助于发现证据不足、上下文缺失或覆盖空白。草稿反思检查生成输出是否完整，有助于发现缺失章节、不完整表格或综合漏洞。

这些智能体共同构成了一种实用的上下文工程模式。系统并不是简单地不断向提示词中添加更多信息，而是在恰当的时间把正确的上下文路由给正确的能力：Think & Plan 获取规划上下文，Researcher 获取检索上下文，Reflection Agent 获取证据上下文，Writer 获取综合上下文。这体现在系统中的具体决策上：Text-to-SQL 步骤只注入与当前查询相关的模式组件，而不是完整数据库模式；Reflection Agent 接收原始问题和已收集证据来评估缺口，而不是整个工作流历史；Writer Agent 接收经过筛选且带有引文约束的块，而不是原始检索输出。从单体智能体转向这种结构化工作流，意味着每个智能体都可以被单独评估、调试和改进。

在生产环境的 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 中整体数据可发现性至关重要。由于拜耳漫长运营历史中，不同实验室和系统经历了历史数据迁移并采用了不同的标注实践，元数据有时可能不完整、缺失或错误。

为应对这一挑战并持续提升结构化元数据质量，我们开发了一套实用系统，利用命名实体识别（NER）直接从研究 PDF 中提取并创建准确标注。该系统旨在读取临床前报告的文本内容，识别应体现在结构化元数据中的关键实体及其关联信息。

该流程包括：

处理研究 PDF，以提取文本并识别相关实体（例如研究 ID、化合物名称、物种、给药途径、剂量信息、临床发现等）。
基于识别出的实体及其在文本中的关系生成结构化标注。

我们正在积极将这一实用系统集成到数据流水线中，以自动修正并丰富 Amazon Athena 数据库中的数据。该系统在生成准确标注方面的表现已经在整理数据集上得到评估，结果令人鼓舞。为管理这些标注进入生产数据库的集成，我们正在开发一套评估系统，为每个提取字段提供置信度评分。置信度高的字段将自动用于更新 Amazon Athena 中相应条目；置信度较低的字段则会被隔离并标记，交由人工审查和干预，从而在利用自动化的同时确保数据准确性。此方法旨在持续提升结构化元数据质量，使其成为 PRINCE 及其他下游应用更可靠的信息来源。

旅程仍在继续：迭代式开发

PRINCE 自 2024 年初起已向终端用户开放，智能体集成则在同年稍晚时候引入。这对于收集真实世界反馈并推动迭代开发至关重要。指导我们开发的一项核心原则是：构建生产级 LLM 应用是一个迭代过程；我们不会等到功能绝对完美才去收集用户反馈。相反，我们优先尽早交付价值，并基于真实使用情况持续优化系统。

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

PRINCE 的开发遵循持续、迭代的流程。用户反馈、持续监控数据以及专家科学家的洞见会不断回流到开发循环中，推动架构、检索技术、智能体行为和用户界面的改进，从而提升性能、可用性，并最终提升科学影响力。

结论

在临床前药物发现这类复杂企业环境中构建生产就绪的 LLM 应用，是一段伴随着重大技术与工程挑战的旅程。PRINCE 案例研究表明，通过将稳健的数据基础设施、RAG 和 Text-to-SQL 等先进信息检索技术，以及智能的多智能体编排系统结合起来，可以从庞大且此前难以触及的数据仓库中释放出宝贵洞见。

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

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

PRINCE 带来的更广泛启示是：生产就绪的智能体 AI 不仅仅关乎更好的模型或更好的提示词。可靠性来自于对模型所见上下文和模型所处控制架构两方面的工程设计。上下文工程帮助确保每个模型在工作流的正确阶段只获得正确的信息。控制架构工程则帮助确保工作流保持受限、可观测、可恢复，并适用于受监管的研究环境。

随着模型能力不断提升，今天控制架构中的某些部分可能会变得更轻量，或转移到模型原生能力中。但在企业研究系统中，尤其是当信任、可追溯性和可审阅性至关重要时，对上下文、工作流状态、恢复、反思和验证的显式控制仍然不可或缺。

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