作者 | Srikanth Daggumalli, Arun Lakshmanan

譯者 | 平川

引 言

想象一下，一位銷售主管用簡單易懂的英語查詢：“這個季度收入最高的前十種產(chǎn)品是什么，并預(yù)測下個月的趨勢”，系統(tǒng)能在數(shù)秒內(nèi)提供全面的洞察，而不用再等待幾天的時間才能獲得 BI 團(tuán)隊出具的分析報告。你還可以詢問系統(tǒng)：“應(yīng)用程序高延遲的根源是什么？”系統(tǒng)不僅會檢索延遲相關(guān)的結(jié)果，還會提供錯誤日志、指標(biāo)數(shù)據(jù)和近期部署情況的綜合分析與關(guān)聯(lián)報告。

下一代代理搜索功能使這種對話式搜索功能成為可能，由 LLM（大型語言模型）驅(qū)動的 AI 代理通過標(biāo)準(zhǔn)化協(xié)議如 MCP 與數(shù)據(jù)系統(tǒng)交互，提供上下文感知的會話式搜索體驗(yàn)。

在本文中，我們將探討 MCP 如何在 AI 代理和 OpenSearch 之間建起一座橋梁從而創(chuàng)建智能搜索應(yīng)用。我們還將探討從關(guān)鍵詞搜索到代理搜索的演變，了解架構(gòu)組件， 并通過實(shí)際的案例演示具體的實(shí)現(xiàn)方法。

OpenSearch& 行業(yè)案例

OpenSearch 是一個開源的搜索和分析套件，用于日志分析、應(yīng)用程序?qū)崟r監(jiān)控和網(wǎng)站搜索場景。自誕生以來，該軟件的下載量已 接近九億，有成千上萬的貢獻(xiàn)者參與，并且有 超過十四個高級成員，包括 亞馬遜云科技、SAP 和 Oracle 等，根據(jù) DB-Engines 的排名，OpenSearch 位列 前五大搜索引擎。

從電子商務(wù)產(chǎn)品搜索到可觀測性平臺，許多行業(yè)垂直領(lǐng)域?qū)?OpenSearch 應(yīng)用于詞匯、語義搜索和日志分析用例。讓我們快速了解一下搜索是如何演變的。

搜索演變：從關(guān)鍵詞到代理

圖 1：搜索的演變

關(guān)鍵詞搜索

關(guān)鍵詞搜索也稱為詞匯搜索，這是一種傳統(tǒng)的搜索方法，即使用特定的單詞或短語（即關(guān)鍵詞）進(jìn)行搜索。OpenSearch 默認(rèn)使用 TF-IDF 或 Okapi BM25F 算法，也就是廣為人知的“Lucene”索引。盡管它快速、確定性強(qiáng)且語言無關(guān)，但關(guān)鍵詞搜索忽略了用戶的上下文和意圖。

例如，對于“黑色男士夾克”的查詢，它會返回包含這些單詞的任何文檔，包括“穿黑色襯衫的男士”或“其他顏色的夾克”。你可以在 Hugging Face 提供的 OpenSearch AI 演示 中選擇“關(guān)鍵詞搜索”試一下。

語義搜索

語義搜索比關(guān)鍵詞搜索高級一些：在查詢執(zhí)行期間考慮了用戶的上下文和意圖。在語義搜索中，數(shù)據(jù)被轉(zhuǎn)換為向量嵌入（即將文本轉(zhuǎn)換為數(shù)值表示）。這些向量嵌入也被稱為 向量存儲（即向量數(shù)據(jù)庫）用例。OpenSearch 提供了 多種預(yù)訓(xùn)練模型 供人選擇，將數(shù)據(jù)從文本轉(zhuǎn)換為向量嵌入或其他嵌入，如圖像、音頻或視頻等。

我們使用和關(guān)鍵詞搜索相同的示例（搜索“男士黑色夾克”），這時你將只看到與“穿黑色夾克的男士”相關(guān)的結(jié)果。你可以在 Hugging Face 提供的 OpenSearch AI 演示中選擇“向量搜索”試一下。

多模態(tài)或混合搜索

這種搜索方法是關(guān)鍵詞搜索和語義搜索的結(jié)合，可以為你提供基于關(guān)鍵詞和語義的結(jié)果。此外，多模態(tài)搜索使用多種模型處理不同類型的數(shù)據(jù)，如文本與圖像等。例如，在演示頁面（Hugging Face 提供的 OpenSearch AI 演示）上，你可能已經(jīng)看到了關(guān)鍵詞搜索和圖像搜索的結(jié)果。

對話式搜索

對話式搜索 使用自然語言查詢 OpenSearch，如利用 LLM 進(jìn)行問答。這些 LLM 是無狀態(tài)的，但它們通過以下兩種方式維護(hù)會話上下文和歷史：

• 現(xiàn)代 LLM 提供商（如 OpenAI ChatGPT、Anthropic Claude 等）提供的內(nèi)置存儲，用于會話級記憶保留。

• 外部記憶存儲系統(tǒng)用于持久的企業(yè)級記憶管理。這些存儲系統(tǒng)包括傳統(tǒng)數(shù)據(jù)庫（如 PostgreSQL、Redis、Cassandra）、向量數(shù)據(jù)庫（如 OpenSearch、Pinecone）或 代理框架（如 LangChain、Strands、LlamaIndex）。

對話式搜索與 RAG 通過連接到外部數(shù)據(jù)源（通常連接到單個數(shù)據(jù)源，如 OpenSearch）來增強(qiáng) LLM 響應(yīng)。通常，用戶說出需要搜索什么，并從 OpenSearch 檢索數(shù)據(jù)。它最適合處理簡單到中等復(fù)雜度的查詢以及直接的信息檢索。

關(guān)鍵區(qū)別在于：存儲（內(nèi)置或外部）通過維護(hù)會話歷史來保持上下文的連續(xù)性。與此同時，RAG 通過從外部數(shù)據(jù)源檢索相關(guān)信息來增強(qiáng) LLM 響應(yīng)，以提供更準(zhǔn)確、更及時的答案。

代理搜索（下一代搜索）

OpenSearch 中的 代理搜索 將幫助你使用自然語言提問，如簡單易懂的英語。

Agentic Search 是對話式搜索的超集。與對話式搜索不同，代理將具備內(nèi)置的記憶能力，并利用大型語言模型（LLM）的推理能力來編排任務(wù)工作流，然后在 OpenSearch 上做出查詢執(zhí)行決策。這些任務(wù)包括搜索、分析、關(guān)聯(lián)和執(zhí)行。代理還將根據(jù)需要自主迭代工作流計劃。

Agentic Search 可以通過編排多個信息檢索和響應(yīng)增強(qiáng)工具來連接到多個數(shù)據(jù)源。有了 Agentic Search，用戶可以保持對話的連貫性，并通過模型上下文協(xié)議（Model Context Protocol）在 OpenSearch 上執(zhí)行 工具（即任務(wù)），這將在本文后面的小節(jié)中進(jìn)行討論。

在深入探討下一代代理搜索架構(gòu)和實(shí)現(xiàn)細(xì)節(jié)之前，讓我們看看代理在代理 AI 應(yīng)用架構(gòu)中扮演的關(guān)鍵角色。

什么是 AI 代理？

AI 代理（專門的 AI 應(yīng)用）是具有角色、任務(wù)和上下文管理能力的大型語言模型。一個典型的 AI 代理集成了一個用于推理的 LLM、用于在交互中保存相關(guān)上下文的存儲、用于擴(kuò)展能力的工縣，以及用于選擇性知識檢索的 RAG，所有這些都旨在通過僅檢索相關(guān)信息和保留關(guān)鍵細(xì)節(jié)來有效管理 LLM 有限的上下文窗口。給定一個任務(wù)，代理會通過迭代推理和可用的工具來實(shí)現(xiàn)目標(biāo)，同時動態(tài)管理哪些信息進(jìn)入上下文窗口，從而優(yōu)化生成的響應(yīng)。

圖 2：AI 代理的核心架構(gòu)

讓我們通過兩個流行的 OpenSearch 用例來了解一下 OpenSearch Agentic Search 將如何提供幫助。

為什么我們需要代理？

LLM：昨日思維問題

大型語言模型是在大量數(shù)據(jù)上訓(xùn)練的，但沒有實(shí)時數(shù)據(jù)的信息。因此，僅使用 LLM 就像使用昨天的大腦。RAG 通過將 LLM 連接到外部數(shù)據(jù)源（如 OpenSearch 或 RDBMS 等）來解決這個問題。

例如，如果 DevOps 工程師詢問實(shí)時應(yīng)用程序性能指標(biāo)或?qū)ιa(chǎn)應(yīng)用程序的洞察，那么 LLM 就無法單獨(dú)提供信息。為提供實(shí)時洞察，它需要使用 OpenSearch 等現(xiàn)有的數(shù)據(jù)存儲來增強(qiáng)響應(yīng)。

傳統(tǒng)的 RAG 要求用戶指定確切的查詢并從單一來源一步完成檢索。AI 代理增強(qiáng)了 RAG，它會自主推理問題，通過 MCP（如 OpenSearch、GitHub、CloudWatch）編排多個數(shù)據(jù)源，關(guān)聯(lián)發(fā)現(xiàn)，并迭代直到找到解決方案。

對話記憶

大型語言模型（LLM）本身不存儲用戶對話歷史。LLM 獨(dú)立處理每個提示，不保留之前的交互信息。代理可以通過各種記憶機(jī)制（如 短期和長期記憶）來保持對話歷史。

因此，需要使用外部數(shù)據(jù)庫進(jìn)行記憶設(shè)置，并使用 RAG 技術(shù)以跟上對話。從 OpenSearch 3.3 開始，代理記憶 作為內(nèi)置功能提供?，F(xiàn)代 AI 代理 框架帶有內(nèi)置記憶，不需要維護(hù)單獨(dú)的數(shù)據(jù)庫。

知識庫

LLM 沒有你公司的專有數(shù)據(jù)。你可以將你公司的數(shù)據(jù)作為知識庫提供給 LLM。LLM 使用這個知識庫通過 RAG 技術(shù)增強(qiáng)響應(yīng)。

工具

每個代理都會利用 LLM 的推理和規(guī)劃能力并通過某些工具來執(zhí)行任務(wù)。舉例來說，OpenSearch 提供一組用于搜索、分析、關(guān)聯(lián)和執(zhí)行等任務(wù)的 工具。你也可以使用代理框架實(shí)現(xiàn)自己的代理工具。

AI 代理開發(fā)面臨的挑戰(zhàn)

構(gòu)建 AI 代理是一項(xiàng)簡單的任務(wù)，但將其與現(xiàn)有系統(tǒng)如數(shù)據(jù)庫和 Web 服務(wù)集成比較復(fù)雜。每個用例都需要實(shí)現(xiàn)特定的 API 或另一種與相應(yīng)服務(wù)集成的方式。例如，數(shù)據(jù)庫使用 JDBC 連接，Web 服務(wù)基于 REST API 調(diào)用。

如前幾節(jié)所討論的，為了進(jìn)行全面分析，銷售助手代理使用不同的連接器連接到不同的數(shù)據(jù)源。

圖 3：銷售助手代理使用每個數(shù)據(jù)源的自定義連接器

模型上下文協(xié)議（MCP）將通過提供一種簡化的通用連接方式來幫助克服這種復(fù)雜性。

模型上下文協(xié)議（MCP）：通用連接器

MCP 提供統(tǒng)一的 API 連接到不同的服務(wù)，使 AI 代理集成變得簡單順暢。MCP 設(shè)置有兩個組件。

• 模型上下文協(xié)議：一個開源、標(biāo)準(zhǔn)化且安全的協(xié)議（基于 JSON-RPC 2.0），管理 MCP 客戶端和 MCP 服務(wù)器之間的通信。可以將其看作是一個通用的電源適配器或旅行電源適配器，你可以在不同國家使用不同的插座，適配器可以簡化輸入電源并提供所需的連接和輸出。有關(guān) MCP 的更多信息可查閱 這篇文章。

• MCP 服務(wù)器：MCP 服務(wù)器是一個特殊的程序，充當(dāng) AI 模型和外部數(shù)據(jù)源之間的安全橋梁。它提供在相應(yīng)服務(wù)上執(zhí)行任務(wù)的工具。

圖 4：銷售助手代理使用 MCP

OpenSearch 代理搜索是如何工作的？

在本節(jié)中，為了簡化設(shè)置，我們選擇了本地部署模型。為了獲得更好的安全性和可擴(kuò)展性，生產(chǎn)部署應(yīng)使用托管的混合云或云原生選項(xiàng)。

圖 5：OpenSearch 代理搜索——MCP 設(shè)置和流程

架構(gòu)概述

• 代理層

Claude Desktop 既充當(dāng)對話界面（即代理 AI 應(yīng)用程序），也充當(dāng) MCP 客戶端，可以 下載 到你的本地計算機(jī)上。如上圖所示，它通過互聯(lián)網(wǎng)與 Claude Sonnet 4.5 大型語言模型進(jìn)行推理交互，并指示 MCP 從 OpenSearch 中檢索信息。

• 協(xié)議層（MCP 客戶端和服務(wù)器）

MCP 客戶端通過'claude_desktop_config.json'配置。它會保存連接到 OpenSearch 的配置，并通過 MCP 協(xié)議啟動與 MCP 服務(wù)器的通信。MCP 服務(wù)器作為一個獨(dú)立的服務(wù)運(yùn)行，將 MCP 協(xié)議橋接到 OpenSearch。它將 OpenSearch 操作暴露為 MCP 工具，將協(xié)議消息轉(zhuǎn)換為 REST API 調(diào)用，并格式化結(jié)果供 LLM 消費(fèi)。

• 數(shù)據(jù)層

OpenSearch 存儲和索引數(shù)據(jù)，通過 MCP 服務(wù)器暴露操作。

OpenSearch MCP 服務(wù)器設(shè)置

從 3.0 及以上版本開始，OpenSearch 默認(rèn)提供 MCP 服務(wù)器。你可以下載并安裝 OpenSearch MCP 服務(wù)器 到你的本地計算機(jī)，或者也可以按照本文提供的實(shí)施指南進(jìn)行操作。MCP 服務(wù)器的關(guān)鍵作用體現(xiàn)在幾個方面：將 MCP 工具查詢轉(zhuǎn)換為 OpenSearch 原生 REST HTTP API 調(diào)用；提交轉(zhuǎn)換后的查詢到 OpenSearch；處理結(jié)果并將其格式化為與 LLM 兼容的響應(yīng)。

該服務(wù)器還將 OpenSearch 操作（如搜索、分析等）作為 MCP 工具對外提供。默認(rèn)情況下，它將提供在 OpenSearch 上執(zhí)行任務(wù)的工具。默認(rèn)可用的工具包括：

• ListIndexTool 列出 OpenSearch 中的所有索引及其完整信息，包括 docs.count、docs.deleted 和 store.size。

• IndexMappingTool 在 OpenSearch 中檢索索引的索引映射和設(shè)置信息。

• SearchIndexTool 使用 OpenSearch 提供的領(lǐng)域特定查詢語言（DSL）來編寫查詢并搜索索引。

• GetShardsTool 檢索 OpenSearch 中關(guān)于分片的信息。

• HealthTool 返回有關(guān)集群健康狀況的基本信息。

• CountTool 返回匹配查詢的文檔數(shù)量。

• ExplainTool 返回有關(guān)特定文檔為何匹配（或不匹配）查詢的信息。

• MsearchTool 允許在一次請求中執(zhí)行多個搜索操作。

MCP 服務(wù)器部署模式

通常，MCP 服務(wù)器安裝過程會提供以下部署選項(xiàng)。

• 本地部署

MCP 服務(wù)器可以與 Claude 桌面一起在個人工作站上運(yùn)行。這種部署適合開發(fā)和測試。

• 遠(yuǎn)程部署

外部服務(wù)提供商（如 Salesforce、SAP 等）通常出于安全和治理原因，通過 MCP 服務(wù)器公開他們的系統(tǒng)。

• 托管混合（本地 / 云）部署

組織在本地或云環(huán)境中部署集中式的“MCP Hub”，并通過它提供一種標(biāo)準(zhǔn)化、可擴(kuò)展、受控的方式，用于訪問多個數(shù)據(jù)源。

• 云原生部署

亞馬遜云科技、GCP 和 Azure 等主要云提供商自己提供的 MCP 服務(wù)。

請注意，你還可以根據(jù)需要實(shí)現(xiàn)自己的 MCP 服務(wù)器工具。

實(shí)施指南

本節(jié)演示如何配置 Claude 桌面和 OpenSearch MCP 服務(wù)器，以實(shí)現(xiàn)代理搜索能力。我們將分步說明如何安裝、配置和使用兩個樣例數(shù)據(jù)集查詢示例：電子商務(wù)訂單和可觀測性數(shù)據(jù)。GitHub 上提供了完整的源代碼和設(shè)置步驟說明。

代理搜索——用戶和 MCP 交互流程

以下是用戶和 MCP 交互的高級流程，展示了當(dāng)用戶發(fā)出查詢時，它是如何被翻譯的，以及 MCP 如何從 OpenSearch 獲取并呈現(xiàn)數(shù)據(jù)給用戶。

圖 6：用戶和 MCP 交互流程

現(xiàn)在，讓我們看看整個架構(gòu)在實(shí)踐中是如何工作的。

演示：代理搜索實(shí)踐

以下示例通過 Claude 桌面連接到 OpenSearch 演示了支持 MCP 的代理搜索。

演示環(huán)境

對于這個演示，我們使用的是 OpenSearch 作為安裝包提供的兩個默認(rèn)數(shù)據(jù)集。要了解更多詳細(xì)信息，請參閱實(shí)施指南或 OpenSearch Dashboards 快速入門指南。

• 電子商務(wù)訂單樣例：用于客戶行為分析的零售交易數(shù)據(jù)

• 觀測日志、追蹤記錄和指標(biāo)樣例：用于系統(tǒng)監(jiān)控查詢的日志、追蹤記錄和指標(biāo)

請注意，我們在此文章 / 演示中使用了簡單的英文數(shù)據(jù)。但你也可以在 OpenSearch 上針對向量數(shù)據(jù)完成同樣的工作。

通用查詢

讓我們來看一些使用此設(shè)置的通用自然語言查詢。首次使用時，你可能需要發(fā)出類似“使用 MCP 連接到我的 OpenSearch”這樣的查詢，以便初始化 MCP 連接。

MCP 工具查詢：“列出工具”

這個查詢將為你提供 MCP 配置中可用于 OpenSearch 的工具列表。

索引查詢：“列出銷售數(shù)據(jù)和可觀測性數(shù)據(jù)的索引或索引列表”

這是 NLP 查詢，其中，LLM 會理解我們的查詢上下文，并瀏覽所有可用的工具，然后選擇 ListIndexTool 作為合適的工具，列出 OpenSearch 中所有可用的索引。

集群管理查詢：“集群是否健康？”

這是一個平臺操作查詢，用于檢查 OpenSearch 集群的健康狀況。對于此查詢，LLM 使用 ClusterHealthTool 向用戶提供響應(yīng)。

圖 7：MCP 通用查詢

現(xiàn)在，深入研究一些基于銷售數(shù)據(jù)的分析洞察。

銷售分析師演示：針對業(yè)務(wù)洞察的對話式代理搜索

銷售分析師 - 熱門產(chǎn)品類別查詢：

“你能找出上個季度人們訂購的最熱門產(chǎn)品類別嗎？”

此查詢匯總并提供上季度最受歡迎類別中的產(chǎn)品訂單結(jié)果。

銷售分析師 -AI 洞察查詢：

“基于銷售數(shù)據(jù)，對你來說有什么有趣的地方嗎？”

在此查詢中，我們利用純粹的 AI 分析洞察來處理銷售數(shù)據(jù)。

圖 8：銷售分析師 - 業(yè)務(wù)洞察查詢

銷售分析師 - 執(zhí)行董事會 BI 查詢

“你能基于銷售數(shù)據(jù)為執(zhí)行董事會創(chuàng)建一個圖表嗎？”

對于高管來說，這是一個非常有用的場景，他們能使用英語通過自然語言查詢即時生成包含所需條款的報告，而不需要依賴或等待 BI 團(tuán)隊提供銷售績效報告。

圖 9：銷售分析師 - 執(zhí)行董事會 BI 查詢

注意：Claude 桌面可以創(chuàng)建能轉(zhuǎn)換為儀表板的 React.js 代碼。

Claude 桌面還可以發(fā)布公共儀表板。例如，這里是 上述儀表板 的快速參考。

現(xiàn)在，讓我們看看 DevOps 角色如何利用整個 MCP 設(shè)置以及 OpenSearch。

DevOps 演示：基于可觀測性數(shù)據(jù)的對話式洞察

一名 DevOps 工程師為了排查生產(chǎn)問題花費(fèi)了大量的時間，他要在不同的儀表板和工具之間來回切換并使用自定義腳本，這增加了 平均檢測時間（MTTD）和平均恢復(fù)時間（MTTR）。

這種調(diào)查過程可能需要幾個小時到幾天的時間，具體取決于問題的復(fù)雜性。有了 OpenSearch Agentic Search 和 MCP，這些工作流程變成了對話式的。工程師只需要用簡單的英語提出操作性問題，而不需要編寫完整的特定領(lǐng)域語言（DSL）查詢或在不同的數(shù)據(jù)集和系統(tǒng)之間導(dǎo)航。

DevOps 工程師 - 應(yīng)用性能調(diào)查查詢

“是什么導(dǎo)致了我的應(yīng)用程序延遲高？”

這個查詢將掃描所有 OpenSearch 索引中可用的可觀測性數(shù)據(jù)，并自動識別相關(guān)字段，生成延遲問題的總結(jié)性解釋。

DevOps 工程師 - 監(jiān)控和可觀測性查詢

“顯示 CPU 使用率高的節(jié)點(diǎn)及其正在運(yùn)行的任務(wù)”

與延遲查詢相同，這個查詢會選擇正確的可觀測性字段，并針對高 CPU 占用率節(jié)點(diǎn)返回一個清晰的匯總信息。

圖 10：DevOps 工程師 - 應(yīng)用性能和可觀測性查詢

DevOps 工程師 - 可觀測性 - 相關(guān)性分析查詢

“給我提供一個 CPU 與延遲的相關(guān)性分析儀表板”

正如你在下面的演示截圖中看到的那樣，不需要在兩個屏幕或儀表板之間切換或手動關(guān)聯(lián)。CPU 和延遲指標(biāo)已經(jīng)關(guān)聯(lián)，代理搜索提供了一個全面的相關(guān)性分析洞察視圖。

圖 11：DevOps 工程師 -CPU 與延遲相關(guān)性查詢和儀表板

有關(guān)上述儀表板的快速參考，請參閱 已發(fā)布的分析儀表板。

DevOps 工程師 - 可觀測性 - 異常檢測查詢

“你能在這份可觀測性數(shù)據(jù)中檢測出任何異常并創(chuàng)建一個儀表板嗎？”

傳統(tǒng)的可觀測性平臺需要設(shè)置并在你的數(shù)據(jù)上訓(xùn)練異常檢測模型，而大型語言模型（LLM）可以自動理解你的可觀測性信號，并使用簡單的英語查詢識別異常。

圖 12：DevOps 工程師 - 異常檢測查詢和儀表板

對于上述儀表板的快速參考，請查看 已發(fā)布的異常檢測儀表板。

小 結(jié)

從關(guān)鍵詞搜索到代理搜索的演變體現(xiàn)了組織與數(shù)據(jù)交互方式的根本轉(zhuǎn)變。雖然語義搜索理解用戶查詢的意圖和上下文，但有了 MCP 和大型語言模型與 OpenSearch 的結(jié)合，我們正在進(jìn)入一個新的時代，搜索感覺更像是對話而不是查詢。

MCP 標(biāo)準(zhǔn)化協(xié)議消除了集成復(fù)雜性，使 AI 代理能夠連接到不同的數(shù)據(jù)源，并考慮上下文，甚至根據(jù)它們發(fā)現(xiàn)的內(nèi)容進(jìn)行推理。隨著 AI 的不斷發(fā)展，像 MCP 這樣的標(biāo)準(zhǔn)化協(xié)議與 OpenSearch 這樣的強(qiáng)大搜索引擎的結(jié)合，將使每個組織都具備上下文感知的智能數(shù)據(jù)訪問能力。

https://www.infoq.com/articles/nextgen-search-ai-opensearch-mcp/

聲明：本文為 InfoQ 翻譯，未經(jīng)許可禁止轉(zhuǎn)載。