nlp.max_length 不是一个硬性的内部约束，而是一种笨拙的方式来保护用户免受令人困惑的OOM错误的困扰。它是用 "核心" 管道和一个并不特别新的消费级笔记本电脑设置的。如果你的系统实际上并没有内存耗尽，你可以放心地增加它，尤其是对于像分词这样的简单任务。
另一方面，核心管道中的任何组件都不会从非常长的上下文中受益(通常，一个段落或一页就足够了),因此拆分文本通常是最佳方法。非常长的文本可能会占用大量RAM,尤其是对于 parser 或 ner 。
这个日语限制与 nlp.max_length 完全分开，直接来自 sudachipy(我之前实际上没有遇到过)。
他们的错误信息似乎还不错(比带有令人困惑的解析器中间的OOM消息要好得多),所以我不知道是否有必要在 spacy 日本分词器中添加另一个检查，这可能会在未来与上游 sudachipy 约束不同步。
但你是对的，nlp.max_length 不会直接帮助限制字节长度，除非你将其设置得非常低。但再次，较低的限制在实践中可能没问题。
我们会考虑将其添加到文档中！

感谢您的解释，这帮助我消除了困惑，我知道如何为我的用例继续进行。

如果有人偶然遇到这个问题，以下是我使用的字节拆分代码(尽管可能仍然有很多优化潜力)

# splits not after x bytes but ensures that max x bytes are used without destroying the final character 
def __chunk_text_on_bytes(text: str, max_chunk_size: int = 1_000_000):
    factor = len(text) / __utf8len(text)
    increase_by = int(max(min(max_chunk_size*.1,10),1))
    initial_size_guess = int(max(max_chunk_size * factor - 10,1))
    final_list = []
    remaining = text
    while len(remaining):
        part = remaining[:initial_size_guess]
        if __utf8len(part) > max_chunk_size:
            initial_size_guess = max(initial_size_guess - min(max_chunk_size *.001,10),1) 
            continue
        cut_after = initial_size_guess
        while __utf8len(part) < max_chunk_size and part != remaining:
            cut_after = min(len(remaining), cut_after+increase_by)
            part = remaining[:cut_after]
            
        if __utf8len(part) > max_chunk_size:
            cut_after-=increase_by
        final_list.append(remaining[:cut_after])
        remaining = remaining[cut_after:]

    return final_list

现有文档

"""
...
max_length (int): 用于处理的文本的最大允许长度。
...
"""

更新后的文档

"""
...
max_length (int): 用于处理的文本的最大允许长度。max_length的行为可能因不同的语言而有所不同。请参阅针对特定语言的文档以获取更多详细信息。
...

感谢您的建议！我认为这个描述对用户来说有些困惑，因为nlp.max_length本身对所有语言的行为都是相同的。我们需要强调的是，一些单独的分词器或组件，尤其是那些 Package 第三方库的组件，可能有自己的内部长度限制。