AWS 上的嵌入與向量資料庫 — AIF-C01 學習筆記

嵌入（embeddings）與向量資料庫是解鎖 AWS 上幾乎所有實用生成式 AI 模式的核心概念組合，從語意搜尋到檢索增強生成（RAG）皆然。嵌入是一個高維數值向量，能捕捉文字、圖片或任何其他輸入的語意含義——意思相近的兩段內容，在向量空間中的距離也會相近。向量資料庫則是專為對數百萬乃至數十億個向量進行索引、過濾和近似最近鄰（ANN）搜尋而設計的資料儲存引擎，且具備低延遲特性。針對 AIF-C01 任務說明 2.1，你必須能夠說明嵌入與向量資料庫是什麼、哪種語意相似度指標適用於哪種情境，以及哪項 AWS 服務提供了哪種向量資料庫能力。本篇涵蓋理論基礎、核心 AWS 選項——Amazon OpenSearch Service、Aurora PostgreSQL with pgvector、Amazon MemoryDB for Redis、Amazon DocumentDB、Amazon Kendra 以及 Amazon Bedrock Knowledge Bases——並以考試陷阱、記憶技巧和 FAQ 作結。

什麼是嵌入與向量資料庫？

嵌入與向量資料庫構成一套兩段式系統。嵌入模型是編碼器，負責將原始輸入——一個句子、一段落、一段商品描述、一份文件區塊，甚至一張圖片——轉換為固定長度的浮點數陣列。這個陣列就是嵌入，存在於一個高維空間中（現代模型通常為 256 到 4096 維），其中幾何距離編碼了語意相似度。向量資料庫是儲存與檢索引擎，保存這些嵌入及其來源後設資料，並快速回答一個基本問題：「給定一個查詢向量，哪些已儲存的向量與它最接近？」

嵌入與向量資料庫對 AIF-C01 考試至關重要，因為 AWS 上的生成式 AI 應用幾乎無一例外地依賴它們。當你建構一個能回答公司內部 wiki 問題的聊天機器人時，Amazon Bedrock Knowledge Bases 會對每個文件區塊呼叫嵌入模型（Amazon Titan Text Embeddings 或 Cohere Embed），將嵌入儲存於向量資料庫（OpenSearch Serverless、Aurora PostgreSQL pgvector、Amazon MemoryDB for Redis 或 Amazon Neptune Analytics），並在查詢時透過近似最近鄰搜尋取回最相關的區塊，再交由基礎模型生成回答。少了嵌入與向量資料庫，基礎模型就無法以你的私有資料為依據產生答案。

為什麼需要嵌入與向量資料庫

在嵌入技術出現之前，語意搜尋是透過關鍵字比對、同義詞擴展和手動調校的相關性函數（例如 BM25）來近似實現的。這些方法在查詢與文件用不同詞彙描述同一概念時就會失效——例如「如何重設密碼？」與「帳號憑證復原程序」。嵌入解決了這種不匹配，因為編碼器從數十億筆文字範例中學習到，這兩個句子應被映射到相近的向量。向量資料庫的存在，則是因為暴力搜尋（brute-force similarity search）無法擴展規模：逐一比對查詢向量與十億個儲存向量，需要花費數分鐘。封裝在專用向量資料庫引擎中的近似最近鄰演算法，以極小的召回率損失換來千倍的速度提升，讓嵌入與向量資料庫在生產規模下真正可行。

本主題在 AIF-C01 藍圖中的位置

AWS AIF-C01 考試指南的任務說明 2.1 要求你解釋生成式 AI 的基本概念。嵌入與向量資料庫被明確列為 Domain 2（生成式 AI 基礎，佔考試 24%）中的基礎概念。這些概念也出現在任務說明 3.1（使用基礎模型的應用程式設計考量）中，因為選擇正確的 AWS 向量資料庫是一項設計決策。預期會有情境題詢問你使用哪種嵌入模型、哪種語意相似度指標適合某個使用案例，以及哪項 AWS 服務是特定限制條件下的正確向量資料庫選擇。

白話文解釋 Embeddings and Vector Databases

如果高維向量空間的數學感覺過於抽象，以下三個類比能以日常語言重新詮釋嵌入與向量資料庫。在考試當天看到情境題時，選一個最好記的類比。

類比一：便利商店的選品邏輯

想像每一項商品都被賦予了一組「口味座標」——不是依架位，而是依照商品的本質特性。飲料區的珍珠奶茶、抹茶拿鐵、芒果果汁，雖然名稱不同，但「甜度、果味、奶香」這三個座標把相近的商品聚在一起。這組座標就是嵌入：一串數字，把意義定位在空間中。當你問便利商店員工「找一個跟珍珠奶茶口味接近的東西」，他不會重新試喝每一樣商品，而是直接看座標地圖找最近的鄰居。向量資料庫就是那張地圖加上讓查找變快的索引。Amazon Titan Text Embeddings 和 Cohere Embed 是替商品建立座標的人；Amazon OpenSearch Service、Aurora PostgreSQL pgvector 和 Amazon MemoryDB for Redis 則是提供不同規格與價格的地圖儲存服務。

類比二：廚房的食材風味卡

把嵌入想成每種食材的風味側寫。主廚不靠食材的名字來比較——「番茄」和「日曬番茄乾」文字看起來相近，但用途差很多——她用風味座標來比較：酸度、甜度、鮮味、辛香、香氣家族。這些座標就是嵌入。向量資料庫是預先整理好的食材卡盒，讓主廚幾秒內就能取出「任何酸中帶草本氣息」的食材，而不用逐一品嚐每張卡。當主廚（基礎模型）要烹飪（生成）某道料理（答案）時，她從卡盒中取出最相近的三張卡並加以組合。Amazon Bedrock Knowledge Bases 是自動化廚房，負責整套流程：替每種食材建立風味側寫（嵌入）、整理卡盒（儲存向量）、按需取用相關食材（檢索），最後擺盤上桌（生成）。Amazon Kendra 則是熟悉整個廚房的資深副主廚，同時利用風味地圖和書面標籤（關鍵字加語意混合搜尋）來找到食材。

類比三：開卷考的小抄

把你的應用程式想像成一個參加開卷考的學生。課本就是你的私有知識庫——公司所有的產品規格、政策文件和客服文章。傳統關鍵字搜尋就像翻課本後面的索引找完全匹配的詞；找不到那個詞，就找不到那一頁。嵌入與向量資料庫就像擁有一個聰明的讀書夥伴，他已把每一頁重新整理成按意義排序的索引卡，而不是按字母排序。考題一來，夥伴讀懂題目的意思，衝向最近的那疊卡片，把前五張遞給你。你（基礎模型）讀完那些卡片，寫出有根據的答案。HNSW 這類近似最近鄰演算法是夥伴的捷徑——他不用逐一翻查每張卡，而是循著多層書籤結構，瞬間跳到正確的區域。Amazon Bedrock Knowledge Bases 幫你雇好了讀書夥伴、備好了索引卡、裝好了書籤。

核心運作原理：嵌入如何建立

嵌入模型是一個神經網路——通常是 Transformer——訓練目標是將輸入映射到一個向量空間，使語意相似度對應到幾何距離的接近程度。現代大多數嵌入模型的訓練目標稱為對比學習（contrastive learning），它將語意相關的配對拉得更近，並將不相關的配對推得更遠，過程橫跨數百萬甚至數十億個範例。

嵌入模型如何訓練

嵌入模型的訓練資料通常來自兩類來源：公開文字中自然出現的配對（問答對、標題與摘要、意義相近的句子、多語言翻譯），以及教導模型哪些內容應不相似的精選負樣本。模型輸出一個向量，損失函數——通常是 InfoNCE 或 triplet loss 的變體——在相似配對距離過遠或不相似配對距離過近時懲罰網路。經過數十億個訓練步驟，向量空間重新組織，使語意含義成為幾何結構。Amazon Titan Text Embeddings V2 和 Cohere Embed 等商業嵌入模型由 AWS 及合作夥伴大規模預訓練；你透過 Amazon Bedrock 使用它們，不需要自行訓練。

嵌入維度與儲存成本

每個嵌入都是固定長度的浮點數陣列。Titan Text Embeddings V2 支援 256、512 和 1024 維；Cohere Embed English v3 產生 1024 維向量；舊版 Titan Embeddings G1 產生 1536 維。更高的維度能捕捉更細緻的差異，但儲存、傳輸和搜尋的成本也更高。以一百萬份文件、1024 維的 float32 嵌入計算，在未計索引開銷的情況下，原始儲存空間約需 4 GB。選擇適當的嵌入維度是每個嵌入與向量資料庫設計都必須解決的成本與召回率取捨。

詞、句子與文件嵌入

嵌入模型有不同的粒度層級。詞嵌入（Word2Vec、GloVe、fastText）代表單一 token，現在大多只具有歷史意義。句子嵌入將整個句子壓縮為單一向量，是語意搜尋的標準做法。文件嵌入對句子嵌入取平均或池化，以代表一個段落、一頁或整份文件。Amazon Bedrock 上的現代嵌入模型產生句子到段落層級的嵌入，並處理多達數千個 token 的輸入，這也是為什麼在建構嵌入與向量資料庫流水線時，切塊（chunking）策略非常重要。

將文件匯入 Amazon Bedrock Knowledge Bases 或任何自訂嵌入流水線時，你選擇的區塊大小決定了檢索精準度的上限。區塊太大，嵌入訊號被無關內容稀釋，導致 cosine similarity 分數趨近，kNN 查詢回傳不相干段落；區塊太小，基礎模型生成連貫答案所需的周邊上下文就會流失。Amazon Bedrock Knowledge Bases 預設使用 300 token 的固定大小區塊搭配 20% 重疊，對一般散文效果不錯，但在語意邊界無法對齊 token 數的高度結構化內容（例如表格、程式碼清單或 FAQ 頁面）上效果會下降。在確定生產環境 Knowledge Base 設定之前，務必在保留查詢集上評估切塊大小對檢索召回率的影響。 Reference: https://docs.aws.amazon.com/bedrock/latest/userguide/kb-chunking-parsing.html

嵌入（embedding）是由神經網路編碼器產生的稠密、固定長度數值向量，能捕捉輸入（文字、圖片或音訊）的語意含義，使相似的輸入在高維空間中映射到相近的向量位置。向量資料庫（vector database）是針對這些向量的索引、過濾和近似最近鄰（ANN）搜尋而優化的資料儲存引擎。在 AWS 上，嵌入由 Amazon Bedrock（Titan Embeddings、Cohere Embed）提供，向量儲存則由 Amazon OpenSearch Service、Amazon Aurora PostgreSQL with pgvector、Amazon MemoryDB for Redis、Amazon DocumentDB、Amazon Neptune Analytics 以及受管的 Amazon Bedrock Knowledge Bases 整合提供。 Reference: https://aws.amazon.com/bedrock/knowledge-bases/

語意相似度指標：向量資料庫如何比較向量

有了嵌入之後，向量資料庫透過計算查詢向量與已儲存向量之間的相似度分數來回應查詢。三種指標佔據主流，每道 AIF-C01 嵌入與向量資料庫情境題都預設你能區分它們。

Cosine Similarity（餘弦相似度）

Cosine similarity 測量兩個向量之間的夾角，忽略其長度（magnitude）。分數範圍從 -1（方向相反）到 +1（方向完全相同），0 表示正交（無關）。Cosine similarity 是幾乎所有現代文字嵌入模型的預設指標，包括 Amazon Titan Text Embeddings 和 Cohere Embed，因為這些模型的訓練使方向編碼了語意，而不論向量本身有多「長」。如果情境題說「對文字進行語意搜尋」而沒有其他提示，cosine similarity 是最安全的預設答案。

Dot Product（內積）

Dot product（inner product）將對應分量相乘後求和。與 cosine similarity 不同，dot product 對向量長度敏感。當嵌入被 L2 正規化為單位長度時——Titan 和 Cohere 模型預設如此——cosine similarity 與 dot product 產生相同的排名，但 dot product 計算速度略快。某些向量資料庫偏好 dot product 以提升效能；若嵌入未經正規化，dot product 可能過度加權「熱門」或較長的文件，這在推薦系統中偶爾是所求，但在純語意搜尋中通常不是。

Euclidean Distance（歐氏距離，L2）

Euclidean distance 測量向量空間中兩點之間的直線距離。距離越小表示越相似。歐氏距離在圖片嵌入和聚類（clustering）類工作負載中較為常見，但在文字嵌入中較少使用——因為方向通常比長度更重要。大多數 AWS 向量資料庫引擎——OpenSearch k-NN、pgvector、MemoryDB——支援全部三種指標，並讓你在建立索引時選擇。

嵌入與向量資料庫設計中最常見的錯誤，就是選擇了與嵌入模型優化目標不符的語意相似度指標。Amazon Titan Text Embeddings 和 Cohere Embed 以 cosine similarity 為訓練目標；對它們使用 Euclidean distance 會降低召回率。請務必查閱模型文件，並使向量索引指標與預設值保持一致。在 Amazon OpenSearch Service k-NN 中，將 space_type 設為 cosinesimil；在 Aurora pgvector 中，使用 vector_cosine_ops 運算子類別；在 Amazon MemoryDB for Redis 中使用 COSINE 距離指標。嵌入模型與語意相似度指標之間的一致性是不可妥協的。 Reference: https://docs.aws.amazon.com/bedrock/latest/userguide/titan-embedding-models.html

為什麼需要向量資料庫？規模化的近似最近鄰搜尋

暴力語意搜尋會計算查詢向量與每個已儲存向量之間的距離。對一千份文件來說沒問題；對十億份文件來說，就是基礎設施災難。向量資料庫使用近似最近鄰（ANN）演算法，以極小的召回率損失換來顯著的速度與成本提升。AIF-C01 不要求深入理解這些演算法的數學原理，但確實要求你能認出它們的名稱，並知道向量資料庫使用它們的原因。

HNSW — Hierarchical Navigable Small World

HNSW 是現代向量資料庫中使用最廣泛的 ANN 演算法。它建立一個多層圖，較高層包含較少、較遠程的連結，較低層包含較多、較短程的連結。搜尋時從頂層遍歷找到粗略的鄰域，再下降到各層精煉匹配結果。HNSW 以適中的記憶體成本提供優異的召回率與延遲，是 Amazon OpenSearch Service（faiss 引擎）、Amazon Aurora PostgreSQL pgvector（pgvector 0.5.0 起支援 HNSW 索引）和 Amazon MemoryDB for Redis（Redis 7.2 向量搜尋）的預設引擎選擇。

IVF — Inverted File Index（反向檔案索引）

IVF 使用 k-means 將向量空間劃分為多個叢集。查詢時只掃描最近的幾個叢集，跳過大多數向量。IVF 通常比 HNSW 使用更少記憶體，但在相同延遲下召回率略低。Amazon OpenSearch Service 透過 faiss 和 nmslib 引擎支援 IVF。

Lucene 引擎

Amazon OpenSearch Service 還支援原生的 Lucene k-NN 引擎，這是唯一能在基於段落（segments）的 Lucene 索引中與全文字欄位並存的選項。Lucene 是在同一個分片（shard）中結合 BM25 關鍵字比對與向量語意相似度的混合查詢的正確選擇，這是企業搜尋的常見模式。

精確搜尋作為基準

大多數向量資料庫也提供精確（暴力）搜尋，用於評估和小型資料集。精確搜尋提供 100% 召回率，但搜尋時間隨語料庫大小線性增長。在調整 ANN 參數時用它作為基準真值（ground truth），不要在超過幾千個向量的生產環境中使用。

每種近似最近鄰演算法——HNSW、IVF、Lucene k-NN——都暴露了可在召回率、延遲和成本之間取捨的參數。在 HNSW 中，m 控制圖的連通性，ef_construction/ef_search 控制圖的遍歷深度。在 IVF 中，nlist 設定叢集數量，nprobe 設定查詢時掃描的叢集數。從 Amazon OpenSearch Service、Aurora pgvector 或 Amazon MemoryDB for Redis 文件中的預設值開始，在保留的查詢集上對比精確搜尋來衡量 recall@10，再進行調整。嵌入與向量資料庫的效能是連續的調整空間，不是固定規格。 Reference: https://docs.aws.amazon.com/opensearch-service/latest/developerguide/knn.html

AWS 向量資料庫選項——完整產品組合

AWS 提供的向量資料庫選項比任何單一考題所能涵蓋的都多，但 AIF-C01 藍圖聚焦在你必須能按名稱和主要使用案例識別的核心選項。以下各節按照你在情境題中最可能看到的順序逐一說明。

Amazon OpenSearch Service — k-NN Plugin with faiss, nmslib, and Lucene

Amazon OpenSearch Service 是針對同時需要全文搜尋、日誌分析或關鍵字加語意混合查詢的團隊的旗艦 AWS 向量資料庫選項。OpenSearch k-NN 外掛程式內建於每個叢集，支援三種底層引擎：faiss（Facebook AI Similarity Search）、nmslib（Non-Metric Space Library）和 Lucene。OpenSearch 支援 HNSW 和 IVF 索引類型、全部三種語意相似度指標（cosine、dot product、Euclidean），並提供 Provisioned 叢集（OpenSearch Service）和無伺服器（OpenSearch Serverless）兩種部署模式。OpenSearch Serverless 是 Amazon Bedrock Knowledge Bases 在你未自帶向量儲存時自動建立的預設向量儲存。

選擇 Amazon OpenSearch Service 的時機：

需要跨數百萬到數十億個嵌入的大規模向量搜尋。
需要在同一查詢中結合 BM25 關鍵字相關性與向量語意相似度的混合搜尋。
需要在向量搜尋的同時對結構化後設資料進行豐富篩選。
要將 Amazon Bedrock Knowledge Bases 作為受管向量儲存進行整合。

Amazon Aurora PostgreSQL with pgvector

Amazon Aurora PostgreSQL 支援 pgvector 擴充套件，它為關聯式引擎新增了 vector 欄位類型和索引類型（ivfflat 以及 pgvector 0.5.0 起的 HNSW）。pgvector 讓 Aurora 成為一流的向量資料庫，同時保留完整的 SQL——意味著你可以將嵌入與現有關聯式資料表進行 JOIN、在向量與業務實體之間強制執行外鍵，並執行交易式寫入。

選擇 Amazon Aurora PostgreSQL with pgvector 的時機：

需要向量與現有關聯式資料（客戶資料表、產品目錄、訂單）緊密耦合。
需要一個同時處理 OLTP 和向量搜尋的單一資料庫，以降低運維複雜度。
熟悉 PostgreSQL 工具、驅動程式和備份/還原工作流程。
嵌入與向量資料庫的資料規模不足以支撐一個專用叢集的成本。

Aurora PostgreSQL with pgvector 對於向量數量在數百萬以內、特別是向量與關聯式資料並存的工作負載是絕佳選擇。超過這個規模後，專為分散式 ANN 索引設計的 OpenSearch Service，在延遲和成本上通常都優於 pgvector——因為 Aurora 的運算能力在單一主要執行個體上垂直擴展，而 OpenSearch 則橫向跨多個分片擴展。預設「Aurora pgvector 永遠最便宜」的考生，在情境題指定數十億個嵌入或在高查詢並發下要求 100 ms 以下延遲時，往往會答錯。 Reference: https://aws.amazon.com/rds/aurora/ai-ml/

Amazon MemoryDB for Redis — Redis 7.2 上的向量搜尋

Amazon MemoryDB for Redis 在 Redis 7.2 上新增了向量搜尋能力，為 Redis API 帶來個位數毫秒延遲的記憶體內 ANN 搜尋。MemoryDB 使用 HNSW 進行索引，支援 cosine、dot product 和 Euclidean 指標。由於 MemoryDB 是持久化的主要資料庫（不只是快取），其向量索引透過與標準 MemoryDB 鍵值資料相同的分散式交易日誌，在可用區之間持久化保存。

選擇 Amazon MemoryDB for Redis 的時機：

需要嵌入與向量資料庫中盡可能低的查詢延遲——即使在高吞吐量下也能達到 10 ms 以下。
需要一個同時作為主要應用程式資料儲存的持久化記憶體向量儲存。
堆疊中已有相容 Redis 的工具和客戶端。
即時推薦、LLM 回應的語意快取或即時個人化應用。

Amazon ElastiCache for Redis（Redis OSS 7.2 和 ValKey 7.2）也支援向量搜尋，適合需要相同低延遲向量搜尋但使用案例屬於純快取而非持久化主儲存的情境。

Amazon DocumentDB 5.0 — JSON 文件的向量搜尋

Amazon DocumentDB（MongoDB 相容）在 5.0 版本中新增了原生向量搜尋，使用類似 pgvector 精神的 HNSW 風格索引。你可以直接在 MongoDB 風格的文件中儲存嵌入及其來源 JSON，並透過熟悉的 $vectorSearch 聚合管道進行查詢。對於應用程式已使用 MongoDB 並以 JSON 文件格式儲存內容的團隊，DocumentDB 向量搜尋消除了對獨立向量資料庫層的需求。

選擇 Amazon DocumentDB 的時機：

需要 MongoDB 相容 API，並在同一叢集中嵌入向量搜尋。
內容天生是文件形態的（產品目錄、文章、使用者個人資料）。
需要受管的替代方案，以取代在自管基礎設施上執行 MongoDB Atlas Vector Search。

Amazon Neptune Analytics — 圖加向量搜尋

Amazon Neptune Analytics 是一個圖分析引擎，將圖遍歷與向量語意相似度搜尋結合。當你的資料模型本質上是圖形關聯（知識圖譜、詐騙網絡、推薦網絡），且你想要檢索「透過關係相連的相似實體」而非「相似文件」時，它是正確的 AWS 向量資料庫選擇。Neptune Analytics 也是 Amazon Bedrock Knowledge Bases 支援的向量儲存選項之一。

Amazon RDS for PostgreSQL with pgvector

如果你不需要 Amazon Aurora 的自我修復儲存，Amazon RDS for PostgreSQL 從 PostgreSQL 15 起也支援 pgvector 擴充套件。與 Aurora pgvector 的功能幾乎相同，RDS for PostgreSQL 與 Aurora PostgreSQL 之間的選擇通常取決於更廣泛的資料庫規格與可用性需求，而非嵌入與向量資料庫功能本身。

Amazon Kendra — 受管語意搜尋（非純向量資料庫）

Amazon Kendra 是一個智慧企業搜尋服務，在底層使用嵌入，但提供的 API 層級遠高於向量資料庫。你不需要管理嵌入、向量索引、切塊或檢索參數——你連接資料來源（Amazon S3、SharePoint、Confluence、Salesforce、Jira、資料庫），定義存取控制，Kendra 就會回傳帶有重點標示答案的語意相關段落排名結果。Kendra 也原生支援語意加關鍵字的混合相關性搜尋。

選擇 Amazon Kendra 的時機：

需要具備許多內容來源連接器的企業搜尋，開箱即用。
不想管理嵌入、向量索引或檢索的任何基礎設施。
需要與身份識別提供者整合的使用者層級存取控制。
需要在文件上進行問答，而不想自行建構 RAG 堆疊。

這是 AIF-C01 嵌入與向量資料庫陷阱中頻率最高的一個。Amazon Kendra 在內部使用嵌入，但它是受管搜尋產品，而非原始向量儲存。你無法帶入自己的嵌入、選擇 ANN 演算法或更換語意相似度指標。若情境題說「儲存並搜尋 5000 萬個由 Amazon Titan 產生的嵌入」，Kendra 是錯誤答案——應選 Amazon OpenSearch Service、Aurora pgvector 或 Amazon MemoryDB for Redis。反過來，若情境題說「具備 SharePoint 連接器且不需要建構嵌入流水線的受管企業搜尋」，Kendra 才是正確答案，優先於原始向量資料庫。關鍵判斷詞是：題目聚焦在「向量」（OpenSearch/pgvector/MemoryDB）還是「受管搜尋」（Kendra）。 Reference: https://aws.amazon.com/kendra/

Amazon Bedrock Knowledge Bases — 含向量儲存的全受管 RAG

Amazon Bedrock Knowledge Bases 是 AWS 上的端到端受管 RAG 服務。你將它指向 S3 儲存桶、Confluence 空間、SharePoint 站台、Salesforce 組織或網路爬蟲來源，Bedrock Knowledge Bases 就會自動切塊內容、呼叫嵌入模型（預設為 Amazon Titan Text Embeddings V2，也可選 Cohere Embed）、將向量儲存於你選擇的向量儲存，並提供單一 API（RetrieveAndGenerate）來處理檢索、提示詞組裝和基礎模型呼叫。支援的向量儲存包括 Amazon OpenSearch Serverless（預設）、Amazon Aurora PostgreSQL with pgvector、Amazon MemoryDB for Redis、Amazon Neptune Analytics、Pinecone、Redis Enterprise Cloud 和 MongoDB Atlas。

選擇 Amazon Bedrock Knowledge Bases 的時機：

需要生產環境 RAG 流水線，但不想撰寫切塊、嵌入、索引或檢索程式碼。
需要受管的向量儲存生命週期（建立、更新、刪除與來源資料同步）。
需要與 Amazon Bedrock 基礎模型和 Amazon Bedrock Agents 原生整合。
想要從「文件在 S3 中」到「聊天機器人能依此回答」的最快路徑。

Amazon Bedrock 上的嵌入模型

AWS 透過 Amazon Bedrock 提供兩個主要的嵌入模型家族，AIF-C01 要求你能識別兩者。

Amazon Titan Text Embeddings

Amazon Titan Text Embeddings 是 AWS 第一方嵌入家族。Titan Text Embeddings V2（amazon.titan-embed-text-v2:0）支援可設定的輸出維度 256、512 或 1024，接受最多 8192 個輸入 token，並以 cosine similarity 為優化目標。它支援超過 100 種語言，是 Amazon Bedrock Knowledge Bases 的預設嵌入模型。Titan Multimodal Embeddings（amazon.titan-embed-image-v1）還能將圖片編碼到與文字相同的 1024 維空間，實現跨模態檢索。

Cohere Embed

Cohere Embed English v3（cohere.embed-english-v3）和 Multilingual v3（cohere.embed-multilingual-v3）是透過 Amazon Bedrock 模型目錄提供的第三方嵌入模型。Cohere Embed 支援 input_type 參數（search_document、search_query、classification、clustering），能針對特定下游任務調整嵌入——這個功能與單一用途的編碼器相比，通常能提升檢索召回率。

Titan 與 Cohere Embed 的選擇

在沒有強烈偏好的情況下，Titan Text Embeddings 是保守的預設選擇：AWS 原生、維度靈活、語言覆蓋廣，與 Bedrock Knowledge Bases 第一類整合。Cohere Embed 在以下情況勝出：需要任務特定嵌入（input_type 調整）、已在你的領域資料上對 Cohere 進行基準測試並得到更優結果，或需要多語言變體在特定低資源語言上的準確度。在 AIF-C01 考試中，兩者都是可接受的答案，除非題目明確提到只有其中一個支援的功能。

痛點對應：哪種 AWS 向量資料庫適合哪種情境

AIF-C01 社群回報，向量資料庫選擇是較棘手的情境題模式之一。以下對應將研究整理的痛點轉換為考試即用的判斷線索。

痛點：「Bedrock Knowledge Base 要選哪個向量儲存？」

預設答案：Amazon OpenSearch Serverless，因為這是 Bedrock Knowledge Bases 在你未自帶向量儲存時自動建立的選項。若情境強調與關聯式資料共置，切換至 Aurora PostgreSQL pgvector。若情境要求最低查詢延遲，切換至 Amazon MemoryDB for Redis。若情境涉及圖形資料，切換至 Amazon Neptune Analytics。

痛點：「向量資料庫還是 Kendra？」

若題目聚焦於建構對嵌入、切塊或檢索參數有控制權的自訂 RAG 流水線，選向量資料庫（OpenSearch、pgvector、MemoryDB）。若題目聚焦於具備預建連接器且不需要運維 ML 流水線的受管企業搜尋，選 Amazon Kendra。關鍵轉折詞是「受管企業搜尋」（Kendra）對比「儲存嵌入」（向量資料庫）。

痛點：「OpenSearch vs Aurora pgvector vs MemoryDB 處理向量工作負載」

大型語料庫（數千萬到數十億）、混合搜尋、專用向量層 → Amazon OpenSearch Service。
中型語料庫（數千到數千萬）、向量與關聯式資料並存、只需一個資料庫來運維 → Amazon Aurora PostgreSQL pgvector。
低延遲關鍵路徑、即時個人化、LLM 回應語意快取 → Amazon MemoryDB for Redis（或快取風格時用 ElastiCache for Redis）。

痛點：「選哪種語意相似度指標？」

文字嵌入預設使用 cosine similarity。當嵌入模型文件說嵌入已正規化且推薦使用 dot product 時，改用 dot product。圖片嵌入或長度（magnitude）有意義的聚類工作負載使用 Euclidean distance。

痛點：「Titan 還是 Cohere Embed？」

預設使用 Amazon Titan Text Embeddings V2。當情境提到 input_type 任務調整，或強調特定低資源語言的多語言準確度時，切換至 Cohere Embed。

嵌入 = 捕捉語意的稠密向量。向量資料庫 = 儲存加 ANN 索引。指標 = 文字用 cosine，圖片用 Euclidean。演算法 = 預設 HNSW，省記憶體用 IVF，混合全文加向量用 Lucene。AWS 選項：Amazon OpenSearch Service（k-NN 外掛程式，Bedrock KB 預設）、Amazon Aurora PostgreSQL pgvector（SQL 原生）、Amazon MemoryDB for Redis（最低延遲）、Amazon DocumentDB 5.0（MongoDB 相容）、Amazon Neptune Analytics（圖加向量）、Amazon Kendra（受管企業搜尋，不是原始向量資料庫）、Amazon Bedrock Knowledge Bases（端到端受管 RAG）。Bedrock 上的嵌入模型：Amazon Titan Text Embeddings V2 和 Cohere Embed v3。 Reference: https://aws.amazon.com/bedrock/knowledge-bases/

嵌入與向量資料庫的常見考試陷阱

AIF-C01 題庫穩定命中以下幾個易錯點。考試前請逐一複習。

陷阱一：Amazon Kendra 不是向量資料庫

Amazon Kendra 在內部使用嵌入，但它是受管搜尋產品，而非原始向量儲存。題目說「儲存 5000 萬個 Titan 嵌入」是在問向量資料庫（OpenSearch、pgvector、MemoryDB），不是 Kendra。

陷阱二：OpenSearch 不只用於日誌

Amazon OpenSearch Service 起源於日誌分析引擎，這讓考生誤以為它不適合嵌入與向量資料庫。事實上，OpenSearch 是 Amazon Bedrock Knowledge Bases 的預設向量儲存，也是大規模語意搜尋最常用的 AWS 向量資料庫。

陷阱三：RAG 不會重新訓練模型

嵌入與向量資料庫驅動了檢索增強生成（RAG），但 RAG 不會更新模型權重。基礎模型仍然從其凍結的參數加上已檢索並注入的上下文來生成回答。若情境題問如何在不重新訓練的情況下讓模型學習新的領域知識，RAG（因此也是嵌入與向量資料庫）就是答案。

陷阱四：更高維度不總是更好

較大的嵌入維度儲存和搜尋成本更高，而在語意搜尋中，超過 1024 維後的準確度提升通常是邊際的。若情境以大規模下的成本優化為目標，選擇 256 維或 512 維的 Titan Text Embeddings V2 往往是正確答案。

陷阱五：語意相似度指標必須與嵌入模型相符

對以 cosine similarity 訓練的嵌入模型使用 Euclidean distance 會降低召回率。請務必將向量索引指標與嵌入模型文件的預設值保持一致。

陷阱六：Amazon Bedrock Knowledge Bases 隱藏了向量資料庫，但你仍需選擇一個

考生有時認為 Bedrock Knowledge Bases 完全消除了向量資料庫決策。事實並非如此——Knowledge Bases 仍然需要向量儲存，而你需要從 Amazon OpenSearch Serverless（預設）、Aurora PostgreSQL pgvector、Amazon MemoryDB for Redis、Amazon Neptune Analytics 及幾個第三方選項中做選擇。即使在受管 RAG 服務內部，嵌入與向量資料庫的選擇仍是設計問題。

陷阱七：Amazon DocumentDB 需要 5.0 版才支援向量搜尋

Amazon DocumentDB 的向量搜尋是 5.0 以上版本的功能。舊版 DocumentDB 不支援 $vectorSearch。在 DocumentDB 能作為向量資料庫使用之前，需要先進行遷移或版本升級。

嵌入與向量資料庫 vs 相鄰 AWS 能力

考生有時會將嵌入與向量資料庫與三個相鄰 AWS 功能混淆。了解邊界的區分能換來幾分考題分數。

嵌入 vs Token

Token 是基礎模型在推論時逐一讀取的子詞單元。嵌入是由獨立的嵌入模型產生的稠密語意向量，由檢索系統使用，而不是直接由生成模型使用。一個 token 在序列中有位置；一個嵌入在空間中有座標。這兩個概念位於流水線的不同階段。

嵌入與向量資料庫 vs 微調（Fine-Tuning）

嵌入與向量資料庫在查詢時將相關上下文傳遞給凍結的基礎模型。微調則在領域資料上更新基礎模型的權重。兩者是互補的客製化策略——RAG（嵌入與向量資料庫）成本更低且資料更新鮮；微調將領域行為烘焙到模型本身中。AIF-C01 情境題常要求你在兩者之間做選擇：資料頻繁更新的情境偏向 RAG；風格一致性和專業詞彙偏向微調。

嵌入與向量資料庫 vs Prompt Caching

Amazon Bedrock 上的 prompt caching 為重複提示詞前綴儲存鍵值注意力快取，使後續呼叫可跳過重新計算。這是推論層的延遲與成本優化，而非檢索機制。嵌入與向量資料庫回答「哪些上下文是相關的？」；prompt caching 回答「如何避免對相同上下文重複處理兩次？」兩者相互組合，而非競爭。

實際場景：在 AWS 上建構嵌入與向量資料庫流水線

一個現實的嵌入與向量資料庫生產流水線結合了多項 AWS 服務：

Amazon S3 — 存放文件、PDF、FAQ、產品手冊的來源儲存桶。
Amazon Bedrock（Titan Text Embeddings V2 或 Cohere Embed v3）— 每個區塊都呼叫的嵌入模型。
Amazon OpenSearch Serverless — 以 cosine similarity 和 faiss 引擎的 HNSW 索引設定的向量儲存。
Amazon Bedrock Knowledge Bases — 協調器，負責切塊 S3 內容、呼叫嵌入模型、將向量寫入 OpenSearch Serverless，並暴露 RetrieveAndGenerate。
Anthropic Claude（在 Amazon Bedrock 上）— 以前 K 個已檢索區塊作為上下文呼叫的生成模型。
Amazon CloudWatch 和 AWS CloudTrail — 對 Knowledge Base 同步任務和呼叫模式的可觀察性。
AWS Identity and Access Management — 將 bedrock:InvokeModel 和 aoss:APIAccessAll 範圍限定到 Knowledge Base 執行角色的 IAM 角色。

AIF-C01 不要求你設計這整個流水線，但確實要求你能識別每個元件，並知道嵌入與向量資料庫為什麼是讓整個系統運作的那一層。

嵌入與向量資料庫的安全性、可觀察性和成本

每個 AWS 向量資料庫都與平台的安全性和可觀察性基礎設施整合。AWS KMS 的靜態加密適用於 Amazon OpenSearch Service、Aurora PostgreSQL pgvector、Amazon MemoryDB for Redis、Amazon DocumentDB 和 Amazon Bedrock Knowledge Bases 儲存。所有 API 介面都強制執行 TLS 傳輸中加密。IAM 和資源型政策控制誰能讀寫向量。CloudWatch 指標暴露查詢延遲、索引大小和錯誤率。CloudTrail 記錄 API 活動以供稽核。

嵌入與向量資料庫的成本調節槓桿：

嵌入模型呼叫成本（Amazon Bedrock 每 1K 輸入 token 計費）。
向量儲存的運算和儲存（OpenSearch 容量單位、Aurora 執行個體時數、MemoryDB 節點時數、DocumentDB 執行個體時數）。
當來源內容變更或嵌入模型升級時重新嵌入的成本。
若向量儲存與 Bedrock 所在區域不同時的跨區資料傳輸費用。

Amazon Titan Text Embeddings V2 讓你選擇 256、512 或 1024 維。大多數語意搜尋工作負載從 512 維開始，對你的查詢集衡量 recall@10，若召回率可接受就降至 256 維——你大約能節省一半的向量儲存並按比例降低查詢 CPU 消耗。對於十億向量語料庫，從 1024 維降至 512 維，在 Amazon OpenSearch Service、Aurora pgvector 或 Amazon MemoryDB for Redis 上每年可節省數萬美元。嵌入與向量資料庫的成本快速累積；維度選擇是最高槓桿的調節點。 Reference: https://docs.aws.amazon.com/bedrock/latest/userguide/titan-embedding-models.html

任務 2.1 嵌入與向量資料庫的練習題關鍵字

在 AIF-C01 考試中看到以下關鍵字時，立即對應到正確的嵌入與向量資料庫服務或概念：

「語意搜尋」、「找相似文件」、「基於意義的檢索」 → 嵌入加向量資料庫。
「Amazon Bedrock Knowledge Bases 的預設向量儲存」 → Amazon OpenSearch Serverless。
「向量與關聯式資料並存」、「SQL 原生向量搜尋」 → Amazon Aurora PostgreSQL pgvector。
「盡可能低的查詢延遲」、「即時語意快取」、「記憶體內向量搜尋」 → Amazon MemoryDB for Redis。
「MongoDB 相容文件儲存加向量搜尋」 → Amazon DocumentDB 5.0。
「具備 SharePoint/Confluence 連接器的受管企業搜尋」 → Amazon Kendra（不是原始向量資料庫）。
「無需撰寫檢索程式碼的端到端受管 RAG 流水線」 → Amazon Bedrock Knowledge Bases。
「具有可設定維度的 AWS 第一方嵌入模型」 → Amazon Titan Text Embeddings V2。
「具有任務特定 input_type 調整的第三方嵌入模型」 → Cohere Embed v3。
「向量之間忽略長度的夾角」 → cosine similarity。
「向量空間中的直線距離」 → Euclidean distance。
「對長度敏感的內積」 → dot product。
「分層圖 ANN 索引」 → HNSW。
「叢集式 ANN 索引」 → IVF。
「同一個分片中的關鍵字加向量混合搜尋」 → Amazon OpenSearch Service Lucene k-NN 引擎。

關鍵數字與必記事實

Amazon Titan Text Embeddings V2 支援輸出維度 256、512 或 1024，最多接受 8192 個輸入 token。
Amazon Bedrock 上的 Cohere Embed v3 產生 1024 維向量，支援 input_type 任務調整。
Amazon OpenSearch Service k-NN 外掛程式支援三種引擎：faiss、nmslib、Lucene。
Amazon Bedrock Knowledge Bases 預設向量儲存是 Amazon OpenSearch Serverless。
Amazon MemoryDB for Redis 向量搜尋需要 Redis 7.2 或更新版本。
Amazon DocumentDB 向量搜尋需要 5.0 或更新版本。
Aurora PostgreSQL 上的 pgvector 從 0.5.0 版起支援 HNSW，更早版本支援 IVFFlat。
Cosine similarity 範圍從 -1 到 +1；數值越高表示越相似。
Euclidean distance 越小表示越相似；cosine 和 dot product 越大表示越相似。
HNSW 是大多數 AWS 向量資料庫引擎的預設 ANN 演算法。
L2 正規化的向量，cosine similarity 與 dot product 相等——選引擎中速度較快的那個。

FAQ — 嵌入與向量資料庫熱門問題

1. 嵌入與向量資料庫有什麼差別？

嵌入是編碼器模型的輸出——一個代表輸入語意的稠密數值向量。向量資料庫是儲存引擎，負責索引大量嵌入並快速回答最近鄰查詢。兩者協同工作：光靠嵌入無法做語意搜尋，因為暴力語意相似度掃描無法擴展規模；而向量資料庫少了要儲存的嵌入也毫無用武之地。在 AWS 上，嵌入端由 Amazon Bedrock（Titan Text Embeddings、Cohere Embed）提供，向量資料庫端則由 Amazon OpenSearch Service、Aurora PostgreSQL pgvector、Amazon MemoryDB for Redis、Amazon DocumentDB、Amazon Neptune Analytics 或受管的 Amazon Bedrock Knowledge Bases 整合提供。

2. 什麼時候應該用 Amazon Kendra 而非向量資料庫？

當你需要具備 S3、SharePoint、Confluence、Salesforce 或 Jira 預建連接器的受管企業搜尋，且不想運維嵌入流水線時，使用 Amazon Kendra。當你需要控制嵌入模型、切塊策略、語意相似度指標或 ANN 參數，或情境明確說「儲存嵌入」或「向量搜尋」時，使用原始向量資料庫（Amazon OpenSearch Service、Aurora pgvector、Amazon MemoryDB for Redis）。Kendra 在內部使用嵌入，但不將其作為向量 API 暴露，這也是它為什麼是 AIF-C01 純向量儲存問題中常見陷阱答案的原因。

3. 在 Amazon Bedrock 上對文字嵌入應該選哪種語意相似度指標？

對於 Amazon Titan Text Embeddings 和 Cohere Embed v3，cosine similarity 是正確的預設選擇。這兩個模型的訓練使向量之間的角距離編碼語意相似度，且嵌入已 L2 正規化，因此 cosine 與 dot product 產生相同的排名。Euclidean distance 不推薦用於文字嵌入——將其留給圖片嵌入或長度（magnitude）有意義的聚類工作負載。

4. Amazon Bedrock Knowledge Bases 的預設 AWS 向量資料庫是哪個？

Amazon OpenSearch Serverless 是 Amazon Bedrock Knowledge Bases 在你未自帶向量儲存時自動建立的預設向量儲存。你可以切換至 Amazon Aurora PostgreSQL with pgvector（與關聯式資料共置）、Amazon MemoryDB for Redis（最低延遲）、Amazon Neptune Analytics（圖形資料）、Pinecone、Redis Enterprise Cloud 或 MongoDB Atlas。選擇會影響成本、延遲、運維複雜度和功能集，但不影響你的應用程式使用的 Knowledge Base API 合約。

5. HNSW 和 IVF 作為 ANN 演算法有什麼差別？

HNSW（Hierarchical Navigable Small World）建立多層圖索引，是大多數現代向量資料庫的預設選擇，包括 Amazon OpenSearch Service、Aurora pgvector 0.5.0+ 和 Amazon MemoryDB for Redis。HNSW 以適中的記憶體成本提供優異的召回率和延遲。IVF（Inverted File）透過 k-means 將向量空間劃分為叢集，查詢時只掃描最近的叢集，以略低的召回率換取更低的記憶體使用量。OpenSearch Service 兩者都支援。對於 AIF-C01，請記住兩者都是向量資料庫內部用於擴展嵌入搜尋規模的近似最近鄰演算法，而 HNSW 是典型的預設值。

6. 在 Amazon Bedrock 上應該用 Amazon Titan Text Embeddings 還是 Cohere Embed？

Amazon Titan Text Embeddings V2 是安全的預設選擇——它是 AWS 原生、提供可設定的輸出維度（256、512、1024）用於成本控制、支援超過 100 種語言，並與 Amazon Bedrock Knowledge Bases 第一類整合。在以下情況選擇 Cohere Embed v3：需要 input_type 參數將嵌入調整用於 search_query、search_document、classification 或 clustering 任務，或在你的特定領域或語言上的基準測試偏向 Cohere。除非情境點名了某一方獨有的功能，否則兩者對 AIF-C01 來說都是有效答案。

7. Amazon Bedrock Knowledge Bases 與嵌入及向量資料庫有什麼關係？

Amazon Bedrock Knowledge Bases 是嵌入與向量資料庫之上的受管層。它自動化了完整的 RAG 流水線：從 Amazon S3 或連接器來源切塊文件、對每個區塊呼叫嵌入模型（Titan 或 Cohere）、將向量寫入設定的向量儲存（預設 OpenSearch Serverless）、在查詢時檢索相關區塊、組裝提示詞，並呼叫基礎模型。你仍需選擇向量儲存和嵌入模型，但不再需要自行撰寫切塊、嵌入迴圈、索引建立或檢索邏輯。它是 AWS 上從「文件在 S3 中」到「有依據的 AI 回答」的最快路徑。