亚马逊AWS官方博客
·
从自建 Elasticsearch 迁移到 Amazon OpenSearch Service 实践（二）：向量索引迁移与 Amazon Bedrock 集成
内容提要
本文介绍了从自建Elasticsearch迁移到Amazon OpenSearch Service的实践，重点在于向量索引的迁移与Amazon Bedrock集成。讨论了两条迁移路线：保留原有Embedding模型的搬运和更换模型的全量重建。详细阐述了如何在OpenSearch中集成Amazon Bedrock Titan V2，包括应用端调用和Neural Search两种方式，并评估了迁移后的向量搜索精度。
关键要点
-
本文介绍了从自建Elasticsearch迁移到Amazon OpenSearch Service的实践，重点在于向量索引的迁移与Amazon Bedrock集成。
-
迁移路线分为两条：保留原有Embedding模型的搬运和更换模型的全量重建。
-
路线A适用于继续使用原有Embedding模型，向量数据原样搬运，保持向量搜索行为不变。
-
路线B适用于借迁移机会升级Embedding模型，或更换模型厂商，进行全量重建向量索引。
-
在AOS上集成Amazon Bedrock Titan V2的方式包括应用端调用和Neural Search两种方式。
-
迁移后的向量搜索精度评估显示，向量数据原样搬运后，k-NN搜索的Top-K结果可能出现微小排列差异。
-
建议在迁移过程中根据业务真实数据评估Top-K对业务指标的实际影响，并可调整AOS的ef_search参数以提高一致性。
延伸解读
迁移路线选择的影响
在迁移过程中，选择保留原有Embedding模型（路线A）或更换模型（路线B）将直接影响后续的向量搜索精度和性能。路线A适合对现有模型满意且希望快速迁移的场景，而路线B则适合希望借机升级模型以提升搜索质量的用户。选择不当可能导致后续的业务调整和性能优化成本增加。
向量索引的写入压力
向量索引的写入过程相比普通索引更为复杂，涉及HNSW图的构建和维护，写入时需考虑内存占用和计算开销。建议在迁移时，目标集群的规格应比普通索引场景增加50%至100%，以应对向量数据的写入压力，确保系统的稳定性和性能。
精度评估的重要性
迁移后，向量搜索的精度可能会受到HNSW图重建的影响，导致Top-K结果出现微小差异。建议在迁移过程中，使用真实业务数据进行精度评估，以了解对业务指标的实际影响，并根据需要调整AOS的ef_search参数，以提高搜索结果的一致性。
延伸问答
从自建Elasticsearch迁移到Amazon OpenSearch Service的主要挑战是什么？
主要挑战包括数据迁移与同步、向量索引迁移以及与Amazon Bedrock的集成。
迁移向量索引时有哪些选择？
有两条选择：路线A是保留原有Embedding模型并原样搬运向量数据，路线B是更换Embedding模型并进行全量重建。
如何在Amazon OpenSearch Service中集成Amazon Bedrock Titan V2？
可以通过应用端调用Bedrock API或使用Neural Search进行集成。
迁移后的向量搜索精度如何评估？
评估显示，向量数据原样搬运后，k-NN搜索的Top-K结果可能出现微小排列差异，建议根据真实数据评估影响。
选择路线A和路线B的场景分别是什么？
路线A适用于向量数据量大且模型效果满意的情况，路线B适用于希望升级模型或更换厂商的情况。
在迁移过程中如何提高向量搜索的一致性？
可以调整AOS的ef_search参数以提高一致性，但这可能会增加查询延迟。
