是的，这是一个已知且故意的行为。如果你想使用原始整数作为文档标签，它们应该从0开始并且是连续的，这样它们就可以被索引到一个紧凑的numpy数组中。
这是一个优化，让能够使用这些ID的用户节省大量内存，与非连续ID(如任意字符串或稀疏整数索引)需要额外MapID到紧凑索引的替代方案相比。
你有没有建议更好地记录这种行为，或者在导致内存问题时提供更好的错误？

我认为是“unique”这个词让我困惑，所以你可能只是明确地称之为最大标签ID。当标签数量大大超过文档数量时，可能会显示警告，尽管我理解可以使用多个标签，所以不需要1-1对应，但2-1以上的可能是一个警告，而100-1实际上会抛出一个错误。无论如何，我非常感谢你们所有人所做的工作——虽然这个问题花了几个小时才找到，但你们帮我节省了几周的工作！谢谢！

我已经使用了现有的文档ID,如tags和model.build_vocab(train_corpus),完成这个任务花了将近25分钟。在纪录片中的建议会很有帮助👍
我遵循了Doc2Vec Model Tutorial。
代码示例：

import gensim
import logging
logging.basicConfig(format='%(asctime)s : %(levelname)s : %(message)s', level=logging.INFO)

patent1 = {
    'abstract': """Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam""",
    'id': 8759248}
patent2 = {
    'abstract': """Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut""",
    'id': 8134146}
patent3 = {
    'abstract': """Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam""",
    'id': 6497987}
patent4 = {
    'abstract': """Lorem ipsum dolor sit amet,""",
    'id': 9322041}
patent5 = {
    'abstract': """Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At""",
    'id': 7361757}
patents = [patent1, patent2, patent3, patent4, patent5]

train_corpus = []

for patent in patents:
    td = gensim.models.doc2vec.TaggedDocument(patent['abstract'].lower().split(), [patent['id']])
    train_corpus.append(td)

model = gensim.models.doc2vec.Doc2Vec(vector_size=50, min_count=2, epochs=5)

def build_vocabulary():
    logging.info('start build_vocab')
    model.build_vocab(train_corpus)
    logging.info('build_vocab finished')

build_vocabulary()

@mkunib ,我不确定你在问什么。
但是，根据上面的讨论，即使你只有5个文档，因为你使用了高达9322041的普通整数ID,模型将为每个50维的522042个文档向量分配足够的空间。这需要大约1.9GB的空间，而不是如果使用(1)整数ID [0, 1, 2, 3, 4];或者(2)使用5个字符串ID - 甚至，你的5个整数的字符串。
当你这样过度分配时，日志中应该会有错误。
(即使有这样的过度分配，如果这个步骤花了25分钟，我还是会有点惊讶，除非还有其他问题，比如触发了交换。但也请注意即将发布的4.0.0版本对真正大型模型中的随机初始化进行了加速。)

类似于“当标签数量大大超过文档数量时，可能会显示警告”的代码片段对我帮助很大，因为我之前没有意识到这一点。或者在文档中给出建议：“如果你使用整数作为标签ID,请小心：它们应该从0开始且是连续的”，这对像我这样的初学者来说非常有用。
也许我在日志中错过了错误( level=logging.DEBUG )?错误应该在这里吗？

2020-12-11 13:54:36,042 : INFO : start build_vocab
2020-12-11 13:54:36,043 : INFO : collecting all words and their counts
2020-12-11 13:54:36,043 : INFO : PROGRESS: at example #0, processed 0 words (0/s), 0 word types, 0 tags
2020-12-11 13:54:36,044 : INFO : collected 23 word types and 9322042 unique tags from a corpus of 5 examples and 75 words
2020-12-11 13:54:36,044 : INFO : Loading a fresh vocabulary
2020-12-11 13:54:36,045 : INFO : effective_min_count=2 retains 20 unique words (86% of original 23, drops 3)
2020-12-11 13:54:36,045 : INFO : effective_min_count=2 leaves 72 word corpus (96% of original 75, drops 3)
2020-12-11 13:54:36,047 : INFO : deleting the raw counts dictionary of 23 items
2020-12-11 13:54:36,047 : INFO : sample=0.001 downsamples 20 most-common words
2020-12-11 13:54:36,048 : INFO : downsampling leaves estimated 11 word corpus (15.9% of prior 72)
2020-12-11 13:54:36,049 : INFO : estimated required memory for 20 words and 50 dimensions: 1864426400 bytes
2020-12-11 13:54:36,049 : INFO : resetting layer weights

是的，我原以为在"collected"行周围会出现一个现有的警告，当'unique tags'大于'examples'时-但似乎没有。(在即将发布的4.0.0版本中会有。)
如果25分钟的延迟发生在resetting layer weights行之后，那也是4.0.0版本中会更快的一个步骤(即使模型确实有数GB的doc-vecs,而不是仅仅因为错误而变得那么大)。