问题是什么？
聊天API在上下文限制超过时会无警告地截断对话。这种行为可能导致下游应用程序中的重大问题。例如，如果为摘要提供文档，静默删除文档的一部分可能导致摘要不完整或不准确。同样，对于其他任务，关键指令如果不在初始提示中出现，可能会被遗忘。
理想的API应该用清晰的错误信息拒绝不符合上下文窗口要求的请求。例如，如果上下文限制超过，OpenAI API会提供以下错误：
这使得下游应用程序能够通知用户关于此问题，让他们决定是扩展上下文、截断文档还是根据截断的提示接受响应。
当前的行为和文档
如果这是API的预期行为，那么它目前还没有文档，可以认为是不友好的。这种行为似乎可能来自llama.cpp。
示例
可以通过以下示例来演示这个问题：
CONTENT=$(python -c 'print("In language modeling, the context window refers to a predefined number of tokens that the model takes into account while predicting the next token within a text sequence. " * 68)')
curl http://localhost:11434/api/chat -d "{ \"model\": \"gemma:2b\", \"messages\": [ { \"role\": \"user\", \"content\": \"$CONTENT\" } ]}"带有68次重复的序列，提示包含1041个令牌，由prompt_eval_count确定。然而，带有67次重复时，提示包含2027个令牌。
类似的问题
4条答案
按热度按时间yptwkmov1#
既然
llama.cpp和Ollama都能处理上下文窗口调整，那么解决方案是否是拥有动态上下文大小，这个大小显著小于基于VRAM的“硬限制”？qyuhtwio2#
所有LLMs都有明确或隐含的上下文限制。一些LLMs使用位置嵌入，防止将上下文扩展到训练限制之外。最近的LLMs采用灵活的位置嵌入，但随着上下文的增加，性能会下降。对上下文的约束始终是必要的。
问题出现在
llama.cpp和ollama上，当超过上下文限制时，会截断对话。虽然我没有深入研究这个问题，但ollama通过将后半部分的消息与初始消息拼接在一起来形成新的上下文(例如，类似于messages = [initial_message, ...messages[n/2:]])来解决这个问题。这种方法对于需要精确上下文管理的应用程序来说是不最优的。在聊天环境中，初始消息通常包括系统详细信息，如日期、时间和客户端提供的用户信息。后续消息由用户提供。当达到上下文限制时，一些消息将从第二条开始被删除。如果这些消息包含对对话完整性至关重要的信息，LLM将出现故障。
当前API缺乏足够的控制，以便客户端能够智能地处理上下文。一个简单的解决方法是在超出上下文时触发错误。这与OpenAI的方法类似，使客户端能够选择性地删除消息并重试。
增强API可以包括包括用于计数令牌的路由。各种模型使用不同的分词器(例如，Mistral使用
SentencePiece,OpenAI使用tiktoken等)。模型还有不同的模型文件和提示模板。对于ollama来说，管理令牌计数有助于避免客户端需要为每个模型维护一个分词器，这可能会变得繁琐。尽管这种增强需要更多的资源供ollama实现，但它将使表现良好的客户端能够确保具有正确上下文的成功请求，从而消除重试的需求。2ekbmq323#
@flu0r1ne 这里有两个问题：
Q1: 是否有方法可以“破解”令牌上下文以增加其大小(可能是RoPE和CoPE)?
Q2: 对于PrunaAI和类似的项目，如果上下文窗口过大且可能没有“中间损失”，会有什么影响？
6fe3ivhb4#
我相信有办法在牺牲计算资源的情况下增加大多数
ollama模型的上下文大小。不过，我认为这与这个问题无关。如果你想进一步讨论，请给我发邮件。你可以在我的个人资料附带的网站上找到我的电子邮件地址。