是的，我提到了当LLMs的上下文大小相对较小时，以及训练文档通常相对较大(与上下文大小相比),这是一个容易使用的限制。Llama 2模型也具有限制您可以给它的文本数量的上下文大小。因此，您必须非常小心，不要为文档引入太多标记。
话虽如此，在这里打开一个参数是没有问题的。实际上，我更倾向于有一个与底层分词器相关的截断参数，但不幸的是，在不引入许多依赖项的情况下，这是不容易实现的。您认为使用基于字符的截断参数是否足够？

是的，我也在考虑这个问题。在使用TextGeneration时，用户是否应该拥有他们想要使用的文本生成模型的分词器？如果是这样的话，依赖关系就在于用户而不是BERTopic和TextGeneration,后者只需要请求它。
tiktoken有很多依赖项吗？这涵盖了OpenAI,但我不确定cohere使用了什么。
如果不是字符，单词会更好吗？因为人们从单词估计标记比从字符更容易。例如，对于OpenAI 100个标记大约有75个单词。将其添加到文档中也可能会很有用，说明标准提示(如OpenAI)的数量。这样，您可以为较短的上下文长度生成模型设置一个默认值，比如50个单词而不是255个字符。

是的，我也在考虑这个问题。在使用TextGeneration时，用户是否应该为他们想要使用的文本生成模型拥有分词器？如果是这样的话，依赖关系就在于用户而不是BERTopic和TextGeneration,后者只需要请求它。

tiktoken有很多依赖项吗？这涵盖了OpenAI,但我不确定cohere使用了什么。

我认为这比仅仅有依赖项要困难一些。每个LLM使用不同的分词器，对于每个LLM,应该使用特定的分词器。它们通常在各自的类(TextGeneration 、 OpenAI 、 Cohere)中工作相同，但这并不总是情况，特别是如果一个人使用了更广泛的实现，如LangChain。所以我不确定所有的分词器是否可以轻松访问。

如果不是字符，单词会更好吗？因为人们从单词估计标记比从字符更容易。例如，对于OpenAI,100个标记大约是75个单词。将其添加到文档中也可能会很有用，说明标准提示(例如OpenAI)的数量。这样，您就可以有一个默认值，比如50个单词，而不是255个字符，用于较短的上下文长度生成模型。

将单词拆分为单词只有在它们之间用空格分隔时才可能，而这对于许多非西方语言来说并不适用。

我明白了。LangChain和非英语语言是我还没有深入研究的内容。这确实是一个挑战。我的建议是提供更多的选项并处理不同的情况，例如：

truncate_at: int = 255,
split_on: str = ['char', 'whitespace', 'token'],
tokenizer = None,

但这可能需要很多工作和处理不同情况。如果字符是目前唯一的选择，那仍然是一个很好的改进！

我认为这会在参数空间中产生一些膨胀。我希望尽可能地保持紧凑，以优化直观的界面/体验。也许只需要保留 char 和 token ,跳过 whitespace ?我们还可以让它让用户选择要分割的内容。所以不再是 'whitespace' ,而是 ' ' 。

是的，那会讲得通。

@zilch42 我刚刚创建了一个拉取请求，实现了这两个功能，使用两个变量 doc_length 和 tokenizer 在 #1539 中。如果你有时间尝试一下，请告诉我你的想法！