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