哈里伯顿利用Amazon Bedrock和生成式AI增强地震工作流创建

地震数据分析是能源勘探的关键组成部分，但传统上配置复杂的处理工作流既耗时又容易出错。哈里伯顿的Seismic Engine是一款用于地震数据处理的云原生应用，此前需要手动配置约100种专用工具来创建工作流，这一过程不仅耗时，还需要深厚的专业知识，可能限制了软件的易用性和效率。

为了解决这一问题，哈里伯顿与AWS生成式AI创新中心合作，为Seismic Engine开发了一个AI驱动的助手。该方案利用Amazon Bedrock、Amazon Bedrock知识库、Amazon Nova和Amazon DynamoDB，将复杂的工作流创建转变为对话形式。地质科学家和数据科学家现在可以通过自然语言交互来配置处理工具，而无需手动配置。

在本文中，我们将探讨如何构建一个概念验证，将自然语言查询转换为可执行的地震工作流，同时为Seismic Engine工具和文档提供问答能力。我们将涵盖方案的技术细节，分享显示工作流加速高达95%的评估结果，并讨论关键经验教训，以帮助其他组织利用生成式AI增强其复杂技术工作流。

方案概述

本项目旨在实现两个关键目标：将自然语言查询转换为可执行的地震工作流，并为Seismic Engine文档提供智能问答系统。为此，我们开发了一个基于Amazon Bedrock的方案，使地质科学家能够通过自然对话与复杂地震工具互动。

系统后端是一个部署在AWS App Runner上的FastAPI应用，通过流式接口处理用户查询。用户提交查询后，由Amazon Nova Lite驱动的意图路由器分析请求，判断是寻求工作流生成还是技术信息。对于问答请求，系统使用基于Amazon Bedrock知识库和Amazon OpenSearch Serverless的检索增强生成（RAG）管道提供相关答案。对于工作流请求，一个使用Anthropic Claude模型的生成代理通过选择82个可用的Seismic Engine工具来创建YAML工作流。

为了维护上下文并支持多轮对话，我们集成了Amazon DynamoDB用于聊天历史和交互日志记录。系统支持问答和工作流生成的流式响应，在处理请求时向用户提供即时反馈。这种架构允许通过自然对话创建和修改复杂技术工作流，同时保持地震数据处理所需的精确控制。

查询路由与意图分类

用户查询提交后，意图路由器通过Amazon Bedrock API调用Amazon Nova Lite对查询进行意图标签分类。大语言模型（LLM）根据提示生成三种意图标签之一："Workflow_Generation"、"QnA"或"General_Question"。

"Workflow_Generation"标签用于与工作流生成相关的查询，包括读取/加载数据集、数据处理操作以及涉及操作特定数据集的各种请求。"QnA"意图标签用于关于特定工具的问题、请求示例工作流或关于Seismic Engine文档的问题。"General_Question"标签用于与Seismic Engine操作或工作流无关的查询。在我们的实现中，Amazon Nova Lite高效地完成了路由任务，在准确性和延迟之间取得了良好平衡。

问答实现

问答组件处理与Seismic Engine相关的查询，使用Amazon Bedrock知识库——一种完全托管的端到端检索增强生成（RAG）工作流服务。我们选择Bedrock知识库是因为它减轻了管理向量数据库、分块策略和嵌入管线的运营负担。作为一种完全托管服务，它自动处理基础设施扩展、安全性和维护，使我们的团队能够专注于方案开发而非RAG基础设施运营。该服务原生支持多种分块策略，包括层次分块，通过维护父子关系在细粒度检索和更广泛的文档上下文之间取得平衡。

数据源包括S3中存储的工具文档markdown文件和Seismic Engine手册。我们保持工具文档文件不分块，因为它们相对较短，从而保留单个工具的完整上下文。对于较长的文档（如Seismic Engine手册），我们使用默认设置的层次分块。我们使用Amazon Titan Text Embeddings V2进行嵌入生成，使用OpenSearch Serverless作为向量数据库。系统还存储每个索引项的元数据，如文件名、URL和文档类型，供下游使用。

对于检索和响应生成，我们使用Amazon Bedrock知识库的retrieve_and_generate API，模型为Claude 3.5 Haiku。系统通过维护会话上下文支持多轮对话，响应格式包含内联引用以增强可追溯性。

注意：本方案使用Claude 3.5 Sonnet V2和Claude 3.5 Haiku进行开发和评估。此后，这些模型已被Claude Sonnet 4.5及最新的Claude Sonnet 4.6，以及Claude Haiku 4.5所取代，均可通过Amazon Bedrock使用。方案架构支持无需代码更改即可升级模型，因此用户可以使用最新的模型能力。

这种方法使我们的系统能够针对Seismic Engine工具和工作流的用户查询提供上下文感知的相关答案。

工作流生成

对于分类为"Workflow_Generation"的查询，我们的方案使用LLM代理将自然语言转换为可执行的YAML工作流。代理绑定Seismic Engine上的82个工具。基于用户查询和定义输入、参数和输出的工具规范，代理选择合适的工具，确定其正确执行顺序，并生成满足用户需求的YAML工作流。

我们在实现中使用了Claude 3.5 Sonnet V2和Claude 3.5 Haiku，通过LangChain框架进行代理管理和工具绑定。模型获得详细的工具描述和规范，从而理解每个工具的能力和需求。在生成工作流时，系统不仅考虑用户查询中的显式需求，还在未提供具体值时包含必要的默认参数。

工作流生成过程支持多轮对话，使用户能够通过自然语言请求修改先前生成的工作流。通过使用存储在Amazon DynamoDB中的对话历史，LLM可以根据用户当前查询生成新工作流或修改现有工作流。

评估

为了评估方案的有效性，我们创建了一个综合的查询-工作流对测试数据集，包括低复杂度和中等复杂度的工作流。这些数据集源自真实的历史工作流，并由领域专家验证，以确保它们准确代表典型用户请求。

工作流生成结果

| 模型 | 复杂度 | 成功率 | 平均生成时间（秒） | 中位生成时间（秒） | |------|--------|--------|--------------------|--------------------| | Claude Haiku 3.5 | 简单 | 84% | 8.3 | 5.9 | | Claude Haiku 3.5 | 中等 | 90% | 12.4 | 9.1 | | Claude Sonnet 3.5 V2 | 简单 | 86% | 11.2 | 11.5 | | Claude Sonnet 3.5 V2 | 中等 | 97% | 15.8 | 16.6 |

两种模型均表现出色，其中Claude Sonnet 3.5 V2在成功率上更优，尤其对于中等复杂度工作流。系统通过流式传输响应，在生成工作流时向用户提供即时反馈，完整工作流在5.9-16.6秒内交付。Claude Haiku 3.5提供更快的生成时间，在速度和准确性之间提供了权衡选项。

与基线性能对比

| 用户类型 | 成功率 | 失败率 | 构建简单流程时间（分钟） | 构建复杂流程时间（分钟） | |----------|--------|--------|--------------------------|--------------------------| | 新用户 | 70% | 20% | 4 | 20 | | 经验用户 | 85% | 10% | 2 | 5 | | 我们的方案 | 84-97% | 3-16% | 0.13-0.26 | 0.21-0.28 |

我们的生成式AI方案展现了以下改进：

• 84-97%的成功率超越了新用户和经验用户。
• 工作流创建时间从分钟级缩短至秒级，减少了超过95%的时间。

这些结果表明，各经验水平的用户均能将生产力提升95%以上，同时保持或超越手动工作流创建的准确性。

结论

在本文中，我们展示了如何使用Amazon Bedrock将复杂技术流程转化为自然对话。通过实施具有集成问答能力的AI驱动助手，我们实现了84-97%的工作流生成成功率，同时与手动流程相比创建时间减少了超过95%。系统处理低复杂度和中等复杂度工作流的能力，结合其对Seismic Engine工具的上下文理解，证明了生成式AI如何在不牺牲准确性的前提下提高工业软件易用性。

这种方法也适用于其他需要专业工具知识和配置的复杂多步骤代理工作流领域。作为下一步，可考虑使用Strands Agents SDK与Amazon Bedrock AgentCore等框架的多代理架构，通过专门子代理进一步提高准确性。