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