“你的語義檢索應用，正在被檢索延遲拖垮?！?/p>

作者 | OpenSearch 團隊

責編 | 唐小引

出品 | CSDN（ID：CSDNnews）

搜索巨頭的戰(zhàn)略轉(zhuǎn)向

2025 年 10 月 9 日，搜索行業(yè)傳來一個震撼性消息：。這不僅僅是一次商業(yè)并購，更是老牌搜索巨頭對未來技術趨勢的戰(zhàn)略性押注。

對于后端工程師來說，Elasticsearch（簡稱 ES）幾乎是必備工具——無論是公司內(nèi)部的日志分析、用戶行為追蹤，還是商品信息檢索，只要涉及“搜索”功能，基本都離不開它。可以說，ES 就是全球無數(shù)公司后臺數(shù)據(jù)的“超級圖書管理員”。而 Jina AI 則是一家專注于搜索基礎模型的創(chuàng)業(yè)公司，以其 Jina Embeddings 系列模型在業(yè)界聞名。

這次收購背后的深層邏輯很明確：搜索技術正在經(jīng)歷從“關鍵詞匹配”向“語義理解”的根本性轉(zhuǎn)變。傳統(tǒng)搜索只能進行字面匹配，而語義檢索能夠理解概念之間的關聯(lián)——當用戶詢問“如何提升銷售業(yè)績”時，系統(tǒng)能夠智能地匹配包含“營收增長策略”的相關文檔。

每個 AI 開發(fā)者都在經(jīng)歷的痛苦

但即使有了最好的語義理解能力，當你開始構(gòu)建真正的 RAG 應用時，現(xiàn)實依然殘酷。

如果你正在開發(fā) RAG 應用，或者負責企業(yè)級 AI 搜索系統(tǒng)，那你肯定遇到過這個場景：產(chǎn)品 Demo 跑得很順，小規(guī)模測試效果不錯，老板也很滿意。但當你開始處理真實業(yè)務數(shù)據(jù)時，問題來了。

檢索延遲高得讓人崩潰。

百萬級文檔時，查詢還算流暢，50-100ms 的響應時間用戶還能接受。但當數(shù)據(jù)規(guī)模到了千萬級，延遲開始飆升到 200-500ms，用戶開始感覺到明顯的卡頓。等到了億級文檔，延遲直接飆到 1-2 秒，用戶開始抱怨。而當你真正面對十億級文檔時，5 秒以上的響應時間讓系統(tǒng)完全不可用。

更要命的是，這還只是單用戶查詢。一旦并發(fā)上來，系統(tǒng)直接崩潰。用戶等不了，老板等不了，業(yè)務等不了。這就是現(xiàn)實：大部分 RAG 應用，都死在了規(guī)?；@道坎上。

為什么傳統(tǒng)方案扛不住大規(guī)模？

你可能試過各種優(yōu)化方案。稠密向量檢索的語義理解能力很強，但計算量巨大。每次查詢都要計算 768 維、1024 維的向量相似度，數(shù)據(jù)量一大，延遲直接爆炸。即使采用了 HNSW 這類近似搜索算法，當數(shù)據(jù)集量級上來后，查詢延時依然居高不下，同時還需要消耗大量內(nèi)存資源。

傳統(tǒng)關鍵詞搜索像 BM25 雖然速度很快，但語義理解能力有限?！捌嚒焙汀败囕v”這樣的同義詞都匹配不上，用戶體驗極差。

你也試過混合檢索，采用兩階段的方式，先用關鍵詞粗排再用向量精排。但這樣做復雜度翻倍，延遲依然很高，問題并沒有得到根本解決。

你陷入了一個經(jīng)典的兩難困境：要么快但不準，要么準但不快。

神經(jīng)稀疏檢索：魚與熊掌兼得

其實，學術界早就有答案了：神經(jīng)稀疏檢索。這項技術巧妙地融合了傳統(tǒng)關鍵詞搜索和現(xiàn)代語義理解的優(yōu)勢，真正實現(xiàn)了“魚與熊掌兼得”。

長期以來，搜索領域面臨著一個經(jīng)典的兩難選擇：要么選擇語義理解能力強但成本高昂的稠密向量檢索，要么選擇高效但“不夠聰明”的傳統(tǒng)關鍵詞檢索。這就像是在“魚”和“熊掌”之間做選擇——開發(fā)者們很難同時擁有兩者的優(yōu)勢。

稠密向量檢索（Dense Retrieval）——語義理解的“熊掌”：

• 將文本編碼為高維向量（如 768 維、1024 維）；

• 語義理解能力強，能處理同義詞、多語言查詢；

• 但需要大量硬件資源，存儲和計算成本高昂。

稀疏關鍵詞檢索（如 BM25）——高效計算的“魚”：

• 基于詞頻統(tǒng)計，存儲和計算效率極高；

• 但缺乏語義理解，面對“汽車”和“車輛”這樣的同義詞就束手無策。

神經(jīng)稀疏檢索的革命性創(chuàng)新在于，它打破了這個傳統(tǒng)的二選一困境。通過將文本轉(zhuǎn)換為“Token-權(quán)重”的稀疏向量表示，它巧妙地將神經(jīng)網(wǎng)絡的語義理解能力與稀疏表示的計算效率完美結(jié)合。比如“人工智能改變世界”可能被編碼為：

}

這種表示方式的妙處在于真正實現(xiàn)了“魚與熊掌兼得”：

1. 語義理解：神經(jīng)網(wǎng)絡能夠?qū)W習到“人工智能”和“AI”的關聯(lián)，甚至跨語言的語義映射；

2. 兼容傳統(tǒng)索引：可以直接使用 Lucene 等成熟的倒排索引技術，無需重新造輪子；

3. 存儲高效：絕大部分 token 的權(quán)重為 0，只需存儲非零項，存儲成本遠低于稠密向量；

4. 計算友好：無需復雜的向量相似度計算，可以利用傳統(tǒng)的倒排索引快速檢索。

更重要的是，這種“兼得”不是簡單的妥協(xié)，而是在保持語義理解能力的同時，實現(xiàn)了比傳統(tǒng)方法更高的效率。這就為后續(xù) Seismic 算法的突破奠定了堅實的技術基礎。

十億級規(guī)模仍是挑戰(zhàn)

早在 2023 年，開源搜索引擎 OpenSearch 就已支持神經(jīng)稀疏檢索，很多用戶也在用。但當數(shù)據(jù)規(guī)模到了十億級時，新的挑戰(zhàn)出現(xiàn)了。

查詢延遲依然偏高，達到 125ms 以上。在這種規(guī)模下，即使是稀疏向量檢索，也需要處理海量的候選文檔，計算開銷依然不容小覷。

這時候你開始思考：在十億級數(shù)據(jù)面前，是不是還需要更進一步的優(yōu)化策略？

就在此時，OpenSearch 研發(fā)團隊帶來了突破性的解決方案 ——Seismic 算法，專為十億級神經(jīng)稀疏檢索設計的性能引擎，重新定義大規(guī)模檢索。

在最新發(fā)布的 OpenSearch 3.3 版本中，全新的 Seismic 算法將神經(jīng)稀疏檢索的性能推向了新的高度。這不是又一個“理論上很美好”的學術成果，而是經(jīng)過十億級真實數(shù)據(jù)驗證的工程突破：

• 查詢延遲僅 11.77ms —— 比傳統(tǒng)神經(jīng)稀疏檢索快 10 倍以上；

• 保持 90%召回率 —— 檢索質(zhì)量幾乎無損失；

• 吞吐量提升 100% —— 相同硬件配置下處理能力翻倍。

這不是漸進式的優(yōu)化，而是顛覆性的性能突破。

這是什么概念？你的 RAG 應用終于可以在十億級文檔中實現(xiàn)毫秒級響應，同時保持接近完美的語義理解能力。

Seismic 如何做到的？

Seismic 的核心思路是做減法，而不是加法。不是讓計算更快，而是讓無效計算消失。

第一個突破是雙重索引結(jié)構(gòu)。傳統(tǒng)方案只有倒排索引，Seismic 創(chuàng)新性地引入了正向索引，兩者配合實現(xiàn)智能剪枝，大幅減少需要計算的候選文檔數(shù)量。

第二個突破是聚類優(yōu)化。Seismic 對相似文檔進行聚類，每個聚類只維護一個精簡摘要，這樣在查詢時可以快速跳過整個聚類，避免逐一計算每個文檔的相似度。

第三個突破是動態(tài)剪枝策略。根據(jù)查詢特征動態(tài)調(diào)整剪枝閾值，對于簡單查詢使用更激進的剪枝，對于復雜查詢保持更高的精度，最終跳過 99%的無效計算。

為了驗證 Seismic 算法的實際效果，OpenSearch 團隊在 12.9 億文檔的 C4 Dolma 數(shù)據(jù)集上進行了全面的性能測試。這個數(shù)據(jù)集包含了來自互聯(lián)網(wǎng)的大規(guī)模文本數(shù)據(jù)，是檢驗大規(guī)模檢索算法的理想測試平臺。

從數(shù)據(jù)可以看出，Seismic 不僅在延遲方面實現(xiàn)了數(shù)量級的提升，在吞吐量方面也有了顯著的改善，同時還保持了接近完美的召回率。這意味著開發(fā)者可以在不犧牲檢索質(zhì)量的前提下，獲得前所未有的性能體驗。

5 分鐘上手：讓你的 RAG 應用飛起來

別光看數(shù)據(jù)，自己試試才知道效果。OpenSearch 3.3 已經(jīng)集成了 Seismic，5 分鐘就能體驗 Seismic 算法。

第 1 步：設置集群配置

首先，設置集群配置，使模型能夠在本地集群上運行。

}

第 2 步：部署稀疏編碼模型

目前，Opensearch 已經(jīng)開源了 10 個稀疏向量編碼模型，相關注冊信息都可以在官方文檔[1]中獲取。我們以

amazon/neural-sparse/opensearch-neural-sparse-encoding-doc-v3-gte

}

在集群的返回中，可以看到 task_id：

}

用 task_id 來得到詳細的注冊信息：

GET /_plugins/_ml/tasks/

在 API 返回中，我們可以拿到具體的 model_id:

}

第 3 步：創(chuàng)建 Seismic 索引

}

第 4 步：設置預處理器

在導入文檔之前，每個文檔中需要編碼的文本字段都要轉(zhuǎn)換成稀疏向量。在 OpenSearch 中，這一過程是通過預處理器來自動實現(xiàn)的。你可以使用以下 API 來創(chuàng)建離線索引時的處理器管線：

}

第 5 步：使用預處理器導入文檔并搜索

在設置索引之后，用戶可以導入文檔。用戶提供文本字段，預處理器會自動將文本內(nèi)容轉(zhuǎn)換為稀疏向量，并根據(jù)預處理器中的字段映射 field_map 將其放入 sparse_vector 字段：

}

在索引中進行稀疏語義搜索的接口如下，將 替換為第二步中注冊的 model_id：

}

當你導入百萬量級以上的數(shù)據(jù)后，你就能感受到毫秒級的延遲，這種性能提升是立竿見影的。

這意味著什么？RAG 應用的新時代

Seismic 不只是性能優(yōu)化，它重新定義了 RAG 應用的可能性。

對于企業(yè)級應用來說，你終于可以在全量歷史數(shù)據(jù)上做實時問答，不用再為了性能犧牲數(shù)據(jù)完整性。用戶可以在包含十年業(yè)務數(shù)據(jù)的知識庫中秒級找到答案，這種體驗提升是質(zhì)的飛躍。

對于 AI 產(chǎn)品開發(fā)者來說，你可以支持更大規(guī)模的知識庫，實時性要求不再是瓶頸。你有更多精力 focus 在業(yè)務邏輯和用戶體驗上，而不是被底層的性能問題困擾。

對于技術團隊來說，你不用再在“快”和“準”之間糾結(jié)，可以在更大規(guī)模數(shù)據(jù)上驗證想法，有機會構(gòu)建真正的十億級 AI 應用。

展望未來：智能檢索的下一個十年

從 BM25 到稠密向量，再到今天的 Seismic 稀疏向量檢索，我們見證了搜索技術的每一次躍進。但這只是開始。

當十億級實時檢索成為標配，當語義理解變得如此高效，我們有理由相信更多激動人心的應用將成為現(xiàn)實。多模態(tài)檢索將不再是夢想，文本、圖像、音頻可以統(tǒng)一檢索。個性化語義理解將普及，每個用戶都可以擁有專屬的語義模型。實時知識更新將實現(xiàn)，新信息可以秒級同步到檢索系統(tǒng)。

下一代的 AI 應用，將建立在這樣的技術基礎之上。而 Seismic，正是通往這個未來的第一步。

技術的進步從來不會停止，AI 領域更是日新月異。Seismic 算法的出現(xiàn)，讓我們看到了大規(guī)模智能檢索的新可能。它不是終點，而是一個新的起點。

OpenSearch 3.3 已經(jīng)發(fā)布，Seismic 算法等待著你的探索。也許，下一個改變行業(yè)的 RAG 應用，就誕生在你的鍵盤下。

未來已來，只是尚未流行。

相關資源：

[1] OpenSearch 官方文檔：https://docs.opensearch.org/latest/ml-commons-plugin/pretrained-models/

[2] Seismic 算法論文：https://dl.acm.org/doi/10.1145/3626772.3657769

[3] GitHub 項目地址：https://github.com/opensearch-project/neural-search

作者簡介：

OpenSearch 是亞馬遜云科技（AWS）旗下的搜索引擎。本文作者朱煜燁、秀麗蘊、宋梓睿、楊揚來自上海 OpenSearch 團隊，這是 AWS 在中國唯一的核心研發(fā)團隊，致力于將機器學習與現(xiàn)代搜索應用深度融合，專注于大模型應用、神經(jīng)稀疏搜索、檢索增強生成（RAG）及搜索性能優(yōu)化等前沿技術。