在 doc2vec 训练过程的每个微小步骤中，它需要一个单词及其在一定长度内的邻居（称为窗口大小）。对邻居进行求和、平均或连接，等等。
我的问题是，如果窗口超出某个文档的边界怎么办，比如 this
那么邻居是如何求和、平均或连接的？或者他们只是被丢弃了？
我正在做一些 nlp 工作，我的数据集中的大多数文档都很短。欢迎提出任何想法。
【问题讨论】：
标签： machine-learning nlp gensim doc2vec
纯 PV-DBOW 模式 (dm=0) 可以快速训练并且通常表现非常好（尤其是在短文档上），它完全没有使用滑动 window。每个文档向量都经过训练，可以直接预测文档的单词——相邻的单词没有任何区别。
仅当您切换到 PV-DM 模式 (dm=1) 或添加交错的 skip-gram 词向量训练 (dm=0, dbow_words=1) 时，window 才相关。然后，窗口的处理方式与 Word2Vec 训练中的相同：如果它超过文本的任一端，它就会被截断以不超过末端，可能会使有效窗口不平衡。
因此，如果您有一个文本“ABCDE”，并且window 为 2，则在预测第一个单词“A”时，只有右侧的“B”和“C”有贡献（因为有零个单词左边）。在预测第二个单词“B”时，左边的“A”和右边的“C”和“D”都有贡献。等等。
另外一个问题是，为了以计算效率更高的方式对附近单词进行更强的加权，用于任何一个目标预测的实际窗口实际上是从 1 到配置的 window 值的随机大小。所以对于window=2，有一半时间实际上只在每侧使用 1 的窗口，而另一半时间使用 2 的完整窗口。（对于window=5，它使用有效值 1 表示 20%预测中，2 代表 20% 的预测，3 代表 20% 的预测，4 代表 20% 的预测，5 代表 20% 的预测。）这实际上给了更近的词更多的影响，而无需完整的计算每次包含所有全窗口单词或任何额外的部分加权计算的成本。
【讨论】：