推荐系统：将 UUID 转换为推荐库的 32 位整数答案

【问题标题】：recommender systems: Convert UUIDs to 32 bit ints for recommender libraries推荐系统：将 UUID 转换为推荐库的 32 位整数
【发布时间】：2018-01-02 21:33:11
【问题描述】：

LightFM 和其他库要求 32 位整数 id，例如用户。但是，我们的用户 id 是一个 UUID，例如0003374a-a35c-46ed-96d2-0ea32b753199。我想知道在这种情况下你会推荐什么。我想出的是：

在内存或数据库中创建双向字典以保持 UUID Int 映射。例如https://github.com/jab/bidict
使用非加密哈希函数，例如 MurmurHash3 或 xxHash。例如对于 1000 万个 UUID，我使用 xxhash 得到了大约 11,521 或 0.1% 的冲突。这对于推荐系统来说可以忽略不计吗？

我也很好奇这将如何应用于在线预测场景，在给定 UUID、用户交互和模型的情况下，我必须预测需要 32 位整数的模型的建议。如果我使用内存中的 bidict 方法，那么在这种情况下这将不起作用，因此我可能不得不在最坏的情况下创建一个持久的键值存储。

【问题讨论】：

使用 UUID 的目的是什么？也许用户 id 可以使用顺序 guid？否则你会想要检查碰撞，但听起来你无论如何都需要这样做......
@BurnsBA。这是我们在开始考虑推荐系统之前做出的跨设备分析系统的生产决策。很遗憾，现在无法更改。

标签： hash hashtable recommendation-engine

【解决方案1】：

这肯定行得通，并且可能是绝大多数用户会选择的解决方案。当然，缺点在于必须维护映射。
散列函数也可以工作。事实上，有一些方法使用散列到reduce the dimensionality 所需的嵌入层。值得记住的一件事是生成的哈希范围应该相对紧凑：大多数实现将为所有可能的值分配参数，因此可以哈希到非常大的值的哈希函数将需要大量内存。通过模函数进行散列可以很好地工作；然后在保存所有参数所需的内存和碰撞概率之间进行权衡。

在 LightFM 以及大多数其他实现中，只能为训练期间出现的用户和项目（或至少为用户和项目特征）提出建议。然后映射将成为模型本身的一部分，并有效地冻结，直到训练新模型。

【讨论】：

最新的 lightfm 文档似乎表明用户和项目 ID 不再需要是 32 位整数。 lyst.github.io/lightfm/docs/lightfm.data.html 它说：“要创建数据集：- 创建 Dataset 类的实例。- 调用 fit（或 fit_partial），提供要在模型中使用的用户/项目 ID 和特征名称。这将创建内部将 id 和特征名称转换为 LightFM 模型使用的内部索引的映射”这是否意味着我们可以使用字符串用户/项目 id，它们将被转换为内部 int id？