Pyspark LSH结合余弦相似度的参数设置与实现方法咨询

一、bucketLength与numHashTables核心参数调优建议 #

两个参数共同决定LSH的召回率（相似对被找到的比例）和计算开销，不存在全局最优值，需要结合业务的相似度阈值要求、可接受的计算成本调整，参考调优逻辑如下：

• bucketLength：控制单个哈希桶的宽度，是影响效果的第一优先级参数。
  取值越小，单个桶容纳的用户越少，计算开销越低，但高相似用户被分到不同桶的概率越高，召回率越低；取值越大，单桶用户越多，召回率越高，但计算开销会快速上涨，极端情况会退化为接近全量两两计算的水平。
  调优时先固定numHashTables为3_{5的初始值，从你业务要求的最低余弦相似度阈值出发做小样本测试：比如业务需要保留余弦相似度≥0.9的用户对，就从1.0的初始值开始逐步调大，直到采样集里满足阈值的相似对召回率达到业务要求，同时控制单桶平均用户数在总用户量的0.1%}1%区间即可。生产环境针对余弦相似度场景，这个值很少设置超过2.0，否则单桶数据倾斜、规模膨胀的问题会非常明显，失去LSH降本的价值。
• numHashTables：控制独立哈希表的数量，核心作用是降低单哈希表的随机误差。
  单个随机投影哈希函数存在概率偏差，两个高相似用户有小概率在单张哈希表里被分到不同桶；多建独立哈希表时，只要两个用户在任意一张表里落到同个桶，就会被纳入候选集。取值越大，召回率越高，但哈希存储、候选对生成的开销会线性增长。
  常规场景初始值设为3_{10即可：如果对召回率要求极高（比如风控场景不能漏过相似作弊账号），可以调到10}20；如果优先考虑计算效率、允许少量漏检，设为3~5就足够。注意两个参数要配合调整：调大bucketLength时可以适当降低numHashTables控制总开销，调小bucketLength时要增加numHashTables补足召回率。

二、多哈希表场景下的桶匹配逻辑 #

你“直接按hashes列整列值分组、仅在组内计算两两相似度”的理解是错误的，正确逻辑如下：

• hashes列返回的数组长度和numHashTables参数值相等，数组第i个元素对应当前用户在第i张独立哈希表中的桶ID。多哈希表采用的是OR匹配规则：两个用户只要在任意一张哈希表中被分到同一个桶，就会被判定为候选对，进入后续的精确余弦相似度计算环节。
• 标准的候选对生成流程：
  1. 对transform输出的数据集做列展开：把每个用户的hashes数组按哈希表序号拆分为多行，每行记录「哈希表序号、该表下的桶ID、用户ID、用户特征向量」
  2. 按「哈希表序号 + 桶ID」字段做分组，每个分组对应某一张哈希表里落在同一个桶的所有用户
  3. 对每个分组内的用户生成两两候选对，做全局去重——高相似用户可能同时在多个哈希表里被分到同桶，会生成重复候选对，去重后再统一计算精确余弦相似度，过滤掉不满足阈值的结果即可。
• 实际生产中不需要手动实现上述流程：PySpark的BucketedRandomProjectionLSHModel自带approxSimilarityJoin方法，已经封装了多表OR匹配、候选对去重、相似度计算的全流程，直接传入数据集和相似度阈值就能输出结果，手动写分组逻辑很容易因为漏做跨表匹配、没去重导致召回不足或者计算量虚高。
  回到你给出的测试示例：id=1、4、5三个用户在3张哈希表里的桶ID都完全一致，会在3张表中都被分到同组，去重后只需要计算一次两两相似度即可，和三个向量高度相似的实际情况完全匹配。

内容的提问来源于stack exchange，提问作者B_Miner