向量索引的最佳实践

以下建议可帮助您设计准确、高性能且经济高效的向量索引。

首先选择嵌入模型和维度

您使用的嵌入模型决定了向量的维度数量，您在创建索引时设置 Dimensions。创建后便无法更改维度数量。请在创建索引之前确定嵌入模型，并使用相同的模型生成存储向量和查询向量。较少的维度可以降低搜索、写入和存储成本，但更多维度的模型可以捕获更多的语义细节。选择能够满足您的相关性要求且尽可能少的维度。请参阅生成向量嵌入。

将距离函数与您的嵌入相匹配

在选择距离函数时，应与嵌入模型表示相似性的方式相匹配。COSINE 比较方向并忽略模长，适合大多数文本嵌入模型。EUCLIDEAN 计算绝对距离并区分模长。DOT_PRODUCT 同样区分模长。如果您使用它，请将嵌入标准化为单位长度，使得分数反映方向而不是向量长度。索引在创建之后便无法更改距离函数，因此请先在具有代表性的数据集上验证您的选择。请参阅距离函数如何排名结果。

选择与您的查询模式匹配的分区键

分区键将每次 SearchVectors 调用限制在属于单个分区键值的一部分向量索引。调用不会搜索整个索引。减少搜索的数据量可以降低成本、改善延迟和查全率，并能按分区键值水平扩缩吞吐量。

每次搜索时都必须在 SearchConditionExpression 中提供分区键值。每次搜索的范围都精确地限定于一个分区键值。选择与您应用程序支持的模式匹配的分区键。

例如，如果您按美国各州存储基于位置的数据，则大约有 50 个分区键值。每个州都包含足够数量的向量，以实现良好的查全率。50 个分区最多可提供大约 50 倍的水平吞吐量扩展。当每次搜索都针对单个州时，此方法非常有用。

避免在任一方向上出现极端基数：

要在某个分区内进一步筛选，请使用内联筛选条件属性。

吞吐量示例。以一个 768 维嵌入模型（例如 Cohere Embed v3）为例，其中包含 1 KB 的非向量项目数据，项目总大小约为 4 KB（768 个维度 × 4 字节 + 1 KB）。在此项目大小下，每个分区键的限制换算为：

将数据分散到更多分区键值中可以使倍增这些限制。例如，50 个分区键值最高可提供 50 倍的聚合搜索和写入吞吐量。如果您的工作负载超过这些每个分区键的限制，请联系 AWS Support。

使嵌入内容与源内容保持同步

DynamoDB 不会为您重新计算嵌入。每当您更改嵌入表示的源内容时，都要使用相同的嵌入模型重新生成向量，然后将其写回项目中。否则，索引将继续根据旧的向量返回结果。考虑使用 DynamoDB Streams 捕获内容更改，并使用下游进程重新生成和重新写入受影响的嵌入。

仅投影您需要的属性

SearchVectors 无法返回未投影到向量索引中的属性。投影的属性越多，索引存储和写入成本也会越高。您可以对应用程序直接从搜索结果中读取的属性进行投影，然后在需要其余属性时，通过后续 GetItem 或 BatchGetItem 在基表中检索这些属性。

使用多个索引比较嵌入模型

您可以在单个表上创建最多 5 个向量索引。使用单独的索引，将不同的嵌入模型或模型版本放在一起评估。将各个模型的嵌入存储在不同的向量属性中，并为每个模型创建向量索引。这样您便可以根据相同的基础数据比较不同模型的搜索质量，而无需迁移生产索引。

例如，从一个模型版本升级到另一个模型版本时，使用新模型的维度和距离函数创建第二个索引。用新模型的嵌入内容回填索引，对两个索引运行测试查询并比较相关性。在对结果满意后，将应用程序迁移到新索引并删除旧索引。