我有一系列模型：
训练管道（关于训练数据）：
Tokenizer -> HashingTF -> IDF -> KMeans
测试管道（对查询数据的预测）：
trained pipeline -> selecting features from training data which are in the same cluster for query data -> BucketedRandomProjectionLSH
它的作用在这里解释了一下。
我很好奇是否可以足够明智地选择BucketedRandomProjectionLSH、KMeans和HashingTF的参数，所以它们有理由。
免责声明：我对所有这些都是新手，所以以下只是我的假设/想法。
例如，下一个参数：
- hashingTF .numFeatures - “特征数量”。在下面，它使用散列以避免在频率计算过程中遇到不同单词的冲突和错误匹配，所以下面的基本原理 - 我可能会遇到的单词数。在我的情况下，我选择了 ~16k，因为它似乎远远超出了纸质语言的字典 + 考虑了一些性能考虑（例如，默认 2^18 导致计算时间长，结果 - 由于连接超时异常，必须调整超时）
- kmeans .k - “要创建的集群数量”。在无监督学习中，我对如何选择这个参数一无所知——只是猜测。将来，它可能是我的话所属的#of主题。可能LDH + 一些手动考虑可能有助于正确设置它。
- bucketedRandomProjectionLSH .bucketLength - “每个哈希桶的长度”。据我了解 - 它代表减少初始词向量的参数（由词出现的频率表示），将其压缩到“长度”，进一步计算距离并将向量（相应地基于“距离”）分配给下一个参数-bucketedRandomProjectionLSH.numHashTables。因此，我认为其价值的基本原理是我更可能想要考虑的词量，以对向量之间的距离进行预测。例如，如果我有一篇文章被进一步分解为单词标记 - 我想考虑多少单词？例如平均 # 的一半。
- bucketedRandomProjectionLSH.numHashTables - “哈希表的数量” - 正如我所看到的 - 我想考虑多少“距离”。换句话说-我有#of clusters（即5个）：它回答了在比较与我的查询相关的内容时，我想进一步拆分集群以获得缩小的结果。将肯定取决于集群中的特征数量和我期望的结果数量。
因此，如果向后考虑 - 如果给定X是：#results 我期望超出预测：
- [ bucketedRandomProjectionLSH.numHashTables ] = [平均文章数 / X]
- [ bucketedRandomProjectionLSH.bucketLength ] = [每篇文章的平均字数/2]
- [ kmeans.k ] = [X * 某个幻数 >= 2]
- [ hashingTF.numFeatures ] = [字典中的单词数]
请您评估我的想法过程并纠正。