我收集文本文档（在Node.js中），其中一个文档i表示为单词列表。考虑到新文档是作为一种文档流出现的，计算这些文档之间相似性的有效方法是什么？
我目前在每个文档中的单词的标准化频率上使用cos相似性。由于可扩展性问题，我不使用TF-IDF（术语频率，反向文档频率），因为我收到的文档越来越多。
我的第一个版本是从当前可用的文档开始，计算一个大的Term-Document矩阵A，然后计算S = A^T x A，以便S(i, j)（经norm(doc(i))和norm(doc(j))标准化后）i和j文字之间的cos相似性分别是doc(i)和doc(j)。
当我得到一份新文件doc(k)时该怎么办？好吧，我必须计算这个文档与之前所有文档的相似性，这不需要构建一个完整的矩阵。我可以把doc(k) dot doc(j)的内部产品用于所有以前的j，这导致S(k, j)，这很棒。
S真的很长。实际上太长了！所以我决定创建一个C ++模块，它可以更快地完成整个过程。它确实如此！但我不能等待它，我应该能够使用中间结果。而我所说的“不等待它”就是两者
一个。等待计算完成，但也
湾等待矩阵A建立（这是一个很大的）。S(k, j)可以利用这样一个事实：文档比所有给定单词的集合（我用来构建整个矩阵A）的单词少。因此，在Node.js中执行它看起来更快，避免了大量额外资源来访问数据。但有没有更好的方法呢？
注意：我开始计算S的原因是我可以在Node.js中轻松构建A，我可以访问所有数据，然后在C ++中进行矩阵乘法并将其恢复到Node.js中，从而加速整个事物很多。但是现在计算S变得不切实际，它看起来毫无用处。
注2：是的，我不必计算整个S，我可以计算右上角的元素（或左下角的元素），但这不是问题。时间计算问题不是那个顺序。
如果今天必须解决它，只需使用来自fasttext或word2vec的预训练的单词向量