如何突破AWS Personalize及OpenSearch插件的推荐数量限制？

针对AWS Personalize API（getRecommendations/getPersonalizedRanking）和OpenSearch Personalize插件的500条结果上限问题，结合3000+商品库的场景，以下是可落地的最佳实践：

一、多轮查询+结果去重合并 #

• 拆分策略：基于商品的固有属性（分类、价格区间、品牌标签等）拆分过滤条件，确保每个条件组覆盖不重叠的商品子集，且所有子集总和覆盖全量商品。比如按一级分类拆分，每次调用API时指定filter参数过滤对应分类的商品。
• 合并排序：将多轮返回的结果合并后，以AWS Personalize返回的score字段为核心重新排序，同时基于商品ID去重（实时场景下可维护用户近期推荐缓存，进一步排除重复）。
• 注意点：拆分维度必须严谨，避免出现商品遗漏；若商品属性有动态变更，需同步更新过滤条件的拆分逻辑。

二、OpenSearch全量检索+分批调用Personalize重排（突破插件限制） #

OpenSearch插件的500条重排限制可通过“先检索全量，再分批个性化打分”的方式规避：

1. 全量商品检索：通过OpenSearch获取所有符合业务条件的商品ID列表（无过滤时返回3000+条）。
2. 分批调用API：将商品ID列表按500条/批拆分，并行调用getPersonalizedRanking接口，获取每批商品的个性化score。
3. 整合排序：将所有批次的score映射到全量商品列表，按照score从高到低排序，得到完整的个性化排序结果。

• 优化技巧：用异步并行请求处理多批次API调用，减少总耗时；若商品有实时更新，检索时加入时间戳或版本过滤，确保获取最新商品集合。

三、批量任务+实时请求互补（非强实时场景） #

如果场景对实时性要求不高，可结合批量推荐任务扩展结果量：

• 定期（如每日）通过AWS Personalize批量推荐任务为用户生成1000条推荐，存储到后端数据库。
• 实时访问时，调用API获取500条实时推荐，与批量生成的结果合并去重，可给实时推荐的score增加权重（如乘以1.2）后再排序，兼顾个性化的新鲜度和结果量。

内容的提问来源于stack exchange，提问作者K.Madden