單純依賴語義搜尋或是字詞匹配的 RAG（Retrieval-Augmented Generation）系統，在真實生產環境中往往令人失望。這是因為人類的查詢行為既包含需要精確匹配的專有名詞（產品 SKU、人名、法條編號），也包含需要語意理解的模糊描述（“找一間適合帶小孩的飯店”）。兩者的檢索策略截然不同，單一策略必然在某些場景中失靈。

混合式搜尋（Hybrid Search）——同時執行語義與關鍵字檢索並融合結果——正是為了解決這個根本矛盾。AWS 在 2026 年 4 月發表的最佳實踐文章中，詳細說明了如何透過 Amazon Bedrock 與 Amazon OpenSearch 打造生產級別的混合式 RAG 系統。本文將在此基礎上，從實務角度補充架構演進路徑、效能調校技巧與常見陷阱。

為什麼「純語義搜尋」在生產環境中不夠用？

語義搜尋的三大盲點

向量搜尋（Vector Search）透過將文字編碼為語義向量，可以在語義層面理解查詢意圖。但它有三個結構性的盲點：

1. 專有名詞精確性：查詢 “AWS Lambda Layer 的記憶體限制” 時，關鍵字 “Lambda”、“Layer”、“記憶體限制” 的向量表現可能被語義相近的其他概念稀釋。向量空間中 “Lambda” 可能與 “Function”、“Serverless” 等向量距離相近，導致檢索結果偏離。

2. 數字與代碼搜尋：版本號、錯誤碼、產品型號（如 “EIP-712”、“HTTP 429”、“MBP-2026-001”）在向量化的過程中失去其精確辨識度，轉化為語義更泛化的表示。

3. 冷門實體（Long-tail Entities）：在訓練資料中出現頻率低的實體（如特定技術術語、公司內部專案代號），其嵌入表示品質往往不佳，導致向量搜尋召回率低落。

AWS 提供的內部數據顯示，在複雜的客服問答場景中，純語義搜尋的事實準確性較混合式搜尋低 35%，而"無法回答"的比率高出 60%。

混合式搜尋的理論基礎

混合式搜尋的核心論證是：語義搜尋與關鍵字搜尋的失敗模式互補，因此同時使用兩者可以大幅提高檢索的魯棒性（Robustness）。

Amazon Bedrock + OpenSearch 的雙路徑架構設計

AWS 提出的混合式 RAG 架構有兩種部署路徑，取決於你的控制需求：

路徑 A：Bedrock-Managed Retrieval（快速路徑）

使用 Bedrock Knowledge Bases 直接管理檢索流程，搭配 OpenSearch Serverless 作為向量儲存後端。開發者只需在 RetrieveAndGenerate API 中設定 overrideSearchType: "HYBRID"。

# Bedrock-Managed 混合搜尋 API 呼叫範例
import boto3

client = boto3.client("bedrock-agent-runtime")

response = client.retrieve_and_generate(
    input={"text": "我們的 Kubernetes 叢集在 2025 年遇到了什麼瓶頸？"},
    retrieveAndGenerateConfiguration={
        "type": "KNOWLEDGE_BASE",
        "knowledgeBaseConfiguration": {
            "knowledgeBaseId": "XXXXXXXXXX",
            "modelArn": "arn:aws:bedrock:us-west-2::foundation-model/anthropic.claude-3-5-sonnet-20241022-v2:0",
            "retrievalConfiguration": {
                "vectorSearchConfiguration": {
                    "overrideSearchType": "HYBRID",      # 啟用混合搜尋
                    "numberOfResults": 10
                }
            }
        }
    }
)

適用情境：團隊希望快速上線、系統控制需求不複雜、僅需基礎的 metadata 過濾。

路徑 B：OpenSearch-Managed Retrieval（精細控制路徑）

由 OpenSearch 管理完整的詞彙搜尋 + 向量搜尋 + 分數融合 + 重排序鏈。Bedrock 僅作為模型端點。

適用情境：需要精細調整檢索權重、已深度使用 OpenSearch、對檢索品質有嚴格要求。

# OpenSearch 混合搜尋查詢 DSL 範例
{
  "size": 10,
  "query": {
    "hybrid": {
      "queries": [
        {
          "match": {
            "content": {
              "query": "Kubernetes 叢集瓶頸"
            }
          }
        },
        {
          "knn": {
            "content_vector": {
              "vector": [0.123, -0.456, ... /* 省略 1024 維 */],
              "k": 10
            }
          }
        }
      ]
    }
  },
  "rank": {
    "rrf": {
      "window_size": 100,
      "rank_constant": 60
    }
  }
}

分數融合策略的選擇

混合搜尋的精髓在於如何融合兩組結果。AWS 的架構支援四種方法：

嵌入策略、分塊策略與實務參數

嵌入模型的選擇

Amazon Bedrock 預設提供 Titan Text Embeddings v2（1536 維），但 AWS 也支援自訂嵌入模型。選擇嵌入模型時需要考慮：

分塊策略（Chunking Strategy）

分塊策略是影響 RAG 效果最關鍵但最容易被低估的因素。AWS 推薦的策略如下：

實務建議：

• 預設從遞迴分塊開始，以段落邊界（double newline）作為主要分割點，設定每個 chunk 256-512 tokens，重疊 50 tokens
• 對於程式碼或技術文件，使用自訂分割器確保函數或類別定義不被切割
• 對於長文件（如專利、論文），先使用 LLM 生成摘要，再對摘要建立向量索引

生產部署的 5 個常見陷阱與緩解策略

以下流程圖展示了一個完整的 RAG 評估管線，將檢索品質與生成品質分開衡量：

陷阱一：缺乏獨立的檢索評估管道

許多團隊直接根據最終回答的品質來評估 RAG 系統，這會讓問題變得難以診斷。如果是檢索失敗，即使 LLM 能力再強也無法產生正確答案。

解決方案：建立獨立的檢索評估管道，使用專門的檢索指標：

• Recall@K：檢索到的前 K 個文檔中有多少是相關的
• MRR（Mean Reciprocal Rank）：第一個相關文檔的排名位置
• NDCG@K：考慮排序位置的加權相關性分數

陷阱二：忽略資料新鮮度

向量索引是離線建立的，當底層文件更新時，向量索引需要重新建立或增量更新。若忽略此步驟，系統會一直檢索到過時資訊。

解決方案：設定新鮮度 SLA，例如「95% 的變更在 15 分鐘內可檢索」。使用 Amazon OpenSearch 的 Ingestion Pipeline 搭配 S3 Event Notification 實現自動化。

陷阱三：僅使用純語義查詢

這是最常見的陷阱。當系統中有大量專有名詞時，純語義檢索的效果極差。即使在 RetrieveAndGenerate API 中未指定 overrideSearchType: "HYBRID"，AWS 預設也是語義搜尋。

解決方案：在 Knowledge Base 建立時就設定預設搜尋類型為 HYBRID。

陷阱四：未正確處理 metadata

混合搜尋的效率可以透過合理的 metadata 過濾大幅提升。例如，如果查詢包含了產品類別、日期範圍等資訊，應在檢索前先過濾 metadata。

解決方案：讓 Bedrock AgentCore 的 LLM 先從查詢中抽取結構化過濾條件，再執行檢索。

陷阱五：沒有 provenance 追蹤

當檢索結果品質下降時，如果沒有記錄每個結果是來自哪個索引、哪個時間點建立的，根本無法除錯。

解決方案：為每個向量新增 provenance metadata，包含：文件來源、建立時間、嵌入模型版本、分塊策略標籤。

三種架構的比較與適用場景

數據來源：AWS 內部測試與 BitsLovers 生產環境數據。

FAQ 常見問題

Q1: 混合式 RAG 是否一定比純語義或純關鍵字搜尋好？

在絕大多數場景中是的。混合式搜尋的召回率是兩者的聯集，因此理論上不會低於任一種。但代價是：更複雜的架構、更高的延遲（約 50-100ms 的額外開銷）、以及需要調校融合權重。如果你的查詢都是高度的語義問題（如創意寫作、一般知識問答）且不含專有名詞，純語義搜尋可能已足夠。

Q2: 如何決定 BM25 與向量搜尋的權重比例？

這需要根據你的資料與查詢分布進行實驗。一組常見的起始點是：

• 一般知識庫：BM25 0.3 / Vector 0.7
• 技術文件（含大量專有名詞）：BM25 0.5 / Vector 0.5
• 法律/法規文件：BM25 0.6 / Vector 0.4 建議先設定 0.3/0.7 並建立測試集，以 Recall@K 為指標進行 A/B 測試。

Q3: OpenSearch Serverless 與 Managed Cluster 該如何選擇？

Serverless 適合流量波動大、不需跨可用區域分散部署的場景；Managed Cluster 適合可以預估流量、需要自訂叢集配置（如 instance type、分區策略）的場景。Serverless 的 Auto-scaling OCU 設計對非穩態工作負載更經濟。

Q4: Bedrock AgentCore 與傳統的 LangChain RAG 有何不同？

AgentCore 是 AWS 受管的代理框架，內建於 Bedrock 之中。它自動處理了意圖分析、工具選擇、來源評估等邏輯。LangChain 則提供更高的自由度與客製化能力。選擇取決於：是否需要快速上線（選 AgentCore）或需要深度自訂（選 LangChain）。

Q5: 混合式 RAG 的向量儲存是否需要較多磁碟空間？

是的。混合式架構需要同時儲存原始文件、倒排索引與向量索引。使用 OpenSearch Serverless 的 disk-native 索引可將儲存成本降至記憶體內方案的約 1/10。此外，使用 binary embeddings（將 float32 向量量化為 binary）可再減少 90% 的向量儲存空間，但可能損失 1-2% 的檢索精確度。

結論：混合式 RAG 是生產環境的必要基礎建設

從 AWS 2026 年的發展方向來看，混合式 RAG 已從「進階功能」轉變為「預設配置」。Amazon Bedrock Knowledge Bases 在 2026 年的更新中直接內建了混合搜尋支援，這說明 AWS 認為混合式架構是企業級 RAG 系統的必要元件。

對於 ML 工程師與後端開發者，我的建議是：

1. 盡快將現有知識庫升級為混合搜尋。很多團隊踩過的坑告訴我們，純語義搜尋的瓶頸在規模化時會愈來愈明顯。
2. 建立檢索評估管線而非僅評估最終回答。沒有好的檢索，就沒有好的 RAG。
3. 注意資料新鮮度 SLA。一個部署六個月後因為索引過期而開始胡說八道的 RAG 系統，比沒有 RAG 還糟糕。

混合式 RAG 不是銀彈，但它提供了一個穩固的基礎。在此基礎上疊加 Cross-encoder Reranker 與 Agentic Retrieval 策略，才能逐步逼近「真正理解使用者意圖」的理想 AI 搜尋體驗。

參考資料

1. Building Intelligent Search with Amazon Bedrock and Amazon OpenSearch - AWS Machine Learning Blog
2. Hybrid RAG on AWS: Amazon Bedrock and OpenSearch That Hold Up in Production - BitsLovers
3. OpenSearch 把向量檢索延遲壓到 3 毫秒 - 163.com
4. Bedrock RAG: Reranker & Hybrid Search - Business Compass LLC
5. Embedding Store as a Platform on AWS - DZone
6. Building an Automated AWS Security Advisor: RAG with AWS Bedrock - AWSTIP.com
7. Intelligent Hybrid Search with Amazon Bedrock & OpenSearch - Richly AI