FastText.wv.save_word2vec_format() 在一行中创建了一些包含两个单词的条目。这是一个问题，因为它破坏了KeyedVectors.load_word2vec_format() 函数，该函数需要一个单词后跟x 浮点数，其中x 是向量中的维数。我无法证明这是一个错误，那么有人遇到过这个问题吗？
我的解决方案是通过删除包含两个空格分隔的单词的行来修剪生成的文件。在我使用的大型数据集中，每个数据集出现 3 到 10 次。我还仔细检查了词汇表中没有单词，数据集中没有单词包含空格。
在每次出现时，两个组成词都有自己的条目作为一个词。这可能是针对特别高的同时出现的对吗？ 这是预期的行为吗？如果是这样，为什么？为什么在加载函数中没有考虑到这一点？
【问题讨论】：
一般来说，如果save_word2vec_format() 似乎在特定的浮点数行前面加上了一个字符串，该字符串包含更多的空格而不仅仅是一个结束空格，那么几乎可以肯定模型中的匹配键包含这样的空格。
特别是，考虑一个具有通常特殊标题行的书面文件（包含更多向量和维度的计数），在其第 10 行（从 1 开始计数，就像使用 cat -n FILENAME）显示了这种症状。在这种情况下，我希望 ft_model.wv.index_to_key[8] 显示具有匹配内部空格的键。
您确定您的事件不是这种情况吗？ （您是如何检查“词汇表中没有单词且数据集中没有单词包含空格”的？您可能错过了一些更奇特的空白字符，在保存时不知何故变成了纯空格？）
如果实际密钥包含空格，则问题在于先前的预处理/训练中的某些内容在模型中留下了此类内部空格标记，解决该问题可能是解决问题的最佳方法。
如果不是，则存在更深层次的问题，找出触发问题的最小方法会很有帮助。检查问题键周围所有键的 ft_model.wv.index_to_key 值可能有助于缩小范围。
【讨论】：
wv 中的键以查找空格，并发现了违规事件。我还搜索了预处理文档中的空格、制表符和换行符。有可能（甚至很可能）在初始预处理中遗漏了奇异的空格，并且在之后的某个地方将它们转换为空格。一旦我弄清楚了，我会在这里检查。感谢您的提示。