OpenSearch把向量檢索延遲壓到3毫秒

去年夏天，AWS內部有個數據沒對外講：用OpenSearch做向量相似度搜索，延遲中位數壓到了3毫秒。這個數字放在RAG（檢索增強生成）場景里，意味著大模型還沒開始"思考"，答案已經候場了。

但Bedrock團隊沒按常理出牌。他們新推的Agentic助手架構，把語義搜索和文本搜索捆在一起用——不是二選一，是讓兩者互相拆臺又互相補位。

為什么"混合檢索"成了必選項

純向量檢索有個經典翻車現場：用戶搜"Apple"，系統返回一堆水果營養學的文檔，把蘋果公司財報埋在第47位。語義理解再強，也猜不透用戶此刻到底想啃的是iPhone還是紅富士。

Bedrock的解法粗暴但有效。查詢進來先走兩條 pipeline：一條把問題轉成向量，去向量庫里找"意思相近"的；另一條保留原始關鍵詞，去倒排索引里找"字面匹配"的。最后把兩撥結果扔給一個重排序模型，讓它決定誰該上浮、誰該沉底。

這套架構的隱性成本在于：你得維護兩套索引，付兩份存儲錢，調兩個召回策略。AWS的底氣是OpenSearch Serverless能自動擴縮容，但中小企業的賬單可能沒那么好看。

Bedrock AgentCore 的隱藏設計

這次發布里有個被低估的組件：AgentCore。它不像Agents for Amazon Bedrock那樣包辦對話管理，而是專注做"工具調用"的編排層——什么時候查數據庫、什么時候調API、什么時候把結果喂給模型，它用一套聲明式配置串起來。

舉個例子。酒店預訂場景里，用戶說"下周三去北京，要離國貿近的"。AgentCore會先把這句話拆成結構化意圖：日期=下周三、城市=北京、區域=國貿。然后觸發兩條并行檢索：向量庫查"商務出行偏好"的歷史畫像，關系庫查實時房態。兩條結果合并后，才進LLM生成最終回復。

關鍵細節：AgentCore允許開發者在"讓LLM自己決定"和"硬編碼流程"之間滑動調節。信任模型就多給自主權，怕幻覺就收緊權限——這個滑動條的位置，往往比模型選型更能決定用戶體驗。

Strands Agents 的入場時機

AWS這次把Strands Agents也塞進了技術棧，位置有點微妙。它負責的是多輪對話中的"記憶管理"：用戶三分鐘前提過的"不要高層房間"，現在還能被準確召回。

但Strands的真正價值可能是"兜底"。當AgentCore的工具調用鏈斷裂——比如API超時、數據庫返回空——Strands能切換對話策略，把硬失敗包裝成軟回復："這部分信息暫時查不到，我先給您推薦幾家評分穩定的？"

這種分層架構的本質，是把"智能"拆成可替換的模塊。今天用Claude 3.5，明天換自研模型，只要向量維度和API契約不變，底層檢索層不用動。

向量數據庫的軍備競賽，OpenSearch卡在哪

OpenSearch的向量引擎去年加了磁盤原生索引（disk-native index），能把十億級向量的存儲成本壓到內存方案的1/10。代價是查詢延遲從亞毫秒爬到毫秒級——對推薦系統無傷大雅，對實時RAG卻是生死線。

Bedrock團隊的應對是"預過濾"。在向量搜索前，先用元數據過濾（比如"只查過去30天的文檔"）縮小候選集，把有效計算量砍掉90%。這招依賴業務場景有可用的結構化標簽，不是所有數據集都能照搬。

更隱蔽的瓶頸在嵌入模型。Bedrock默認用Amazon Titan做文本向量化，但技術文檔里留了鉤子：可以替換成自定義模型。這個設計暗示AWS自己也清楚，通用嵌入在垂直領域經常被微調模型碾壓。

一個待驗證的假設

AWS這次沒公布混合檢索的端到端延遲數據。3毫秒的向量檢索是單點成績，加上關鍵詞檢索、重排序、LLM首token生成，完整鏈路可能奔著500毫秒去。

他們押注的是：用戶寧愿多等半秒，也要答案準一點。但這個權衡在客服場景（用戶急著解決問題）和內容創作場景（用戶愿意多輪打磨）里，可能是相反的。

Bedrock的文檔里埋了句話，可能是整個架構的注腳：「檢索策略的選擇，應該由查詢的意圖置信度動態決定。」翻譯成人話：系統自己也不知道該信向量還是信關鍵詞，所以干脆全跑一遍。

這種"暴力美學"能撐多久？當查詢量從千級飆到百萬級，成本曲線會不會突然變陡？AWS沒給答案，但把調參的開關都擺在了控制臺里。