本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

向量索引的最佳實務

下列建議可協助您設計準確、高效能且符合成本效益的向量索引。

首先選擇您的內嵌模型和維度

您使用的內嵌模型會決定向量擁有的維度，並在建立索引Dimensions時設定。您無法在建立後變更維度數量。在建立索引之前決定內嵌模型，並使用相同的模型來產生預存向量和查詢向量。較少的維度可減少搜尋、寫入和儲存成本，但較高維度的模型可以擷取更多語意細節。選擇符合您相關性需求的最小維度。請參閱 產生向量內嵌。

將距離函數與您的內嵌相符

選擇符合您內嵌模型代表相似性的方式的距離函數。 會COSINE比較方向並忽略大小，這適用於大多數文字內嵌模型。 會EUCLIDEAN測量絕對距離並對大小敏感。 DOT_PRODUCT也會對大小敏感。如果您使用它，請將內嵌標準化為單位長度，讓分數反映方向而非向量長度。您無法在建立索引後變更距離函數，因此請先針對代表性資料集驗證您的選擇。請參閱 距離函數如何排名結果。

選擇符合您查詢模式的分割區索引鍵

分割區索引鍵會將每個SearchVectors呼叫限制為屬於單一分割區索引鍵值的向量索引部分。呼叫不會搜尋整個索引。搜尋較少的資料可降低成本、改善延遲和召回，並水平擴展跨分割區索引鍵值的輸送量。

您必須在每次搜尋SearchConditionExpression時提供 中的分割區索引鍵值。每個搜尋的範圍僅限於一個分割區索引鍵值。選擇符合您應用程式支援的查詢模式的分割區索引鍵。

例如，如果您依美國狀態存放以位置為基礎的資料，您有大約 50 個分割區索引鍵值。每個狀態都會保留有意義的向量數量，以便良好召回。50 個分割區提供高達約 50 倍的水平輸送量擴展。這會在每個搜尋以單一狀態為目標時運作。

避免任一方向的極端基數：

若要在分割區中進一步篩選，請使用內嵌篩選條件屬性。

輸送量範例。考慮具有 1 KB 非向量項目資料的 768 維內嵌模型 （例如 Cohere Embed v3)，提供大約 4 KB (768 維度 × 4 位元組 + 1 KB) 的總項目大小。使用此項目大小時，per-partition-key限制會轉換為：

將資料分散到更多分割區索引鍵值會乘以這些限制。例如，50 個分割區索引鍵值提供高達 50 倍的彙總搜尋和寫入輸送量。如果您的工作負載超過per-partition-key的限制，請聯絡 AWS Support。

讓內嵌項目與來源內容保持同步

DynamoDB 不會為您重新計算內嵌。每當您變更內嵌所代表的來源內容時，請使用相同的內嵌模型重新產生向量，並將其寫入項目。否則，索引會根據過時向量繼續傳回結果。考慮使用 DynamoDB Streams 擷取內容變更，並使用下游程序來重新產生和重寫受影響的內嵌。

僅投影您需要的屬性

SearchVectors 無法傳回未投影至向量索引的屬性。投影更多屬性會增加索引儲存和寫入成本。投影應用程式直接從搜尋結果讀取的屬性，並在您需要時透過追蹤GetItem或BatchGetItem基礎資料表擷取其餘屬性。

使用多個索引來比較內嵌模型

您可以在單一資料表上建立最多 5 個向量索引。使用不同的索引來並排評估不同的內嵌模型或模型版本。將每個模型的內嵌儲存在不同的向量屬性中，並為每個模型建立向量索引。這可讓您將模型之間的搜尋品質與相同的基礎資料進行比較，而無需遷移生產索引。

例如，從一個模型版本升級至另一個模型版本時，請使用新模型的維度和距離函數建立第二個索引。使用來自新模型的內嵌來回填它，對兩個索引執行測試查詢，並比較相關性。滿足後，將您的應用程式遷移至新索引並刪除舊索引。