哈里伯頓利用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等框架的多代理架構，通過專門子代理進一步提高準確性。