LLM 上下文 Token 的配置思路

上下文是什么？

LLM（大语言模型）的上下文（Context）通常指的是模型在生成文本时，能够考虑的前文信息范围。对于 LLM 来说，上下文就像它的「记忆」，它能够根据之前看到或生成的内容来决定下一步的行动。上下文可以是单个句子、段落、文档，甚至是多个文档的集合，这取决于模型的架构和设计。
上下文对于语言模型来说至关重要，因为它帮助模型理解当前的任务，并基于之前的信息生成连贯、相关的回答。例如，在一个对话中，上下文可能包括对话到目前为止的所有交流，这样模型就能生成符合对话主题和情感的回答。
然而，由于计算资源和内存的限制，语言模型通常有一个固定的上下文长度。当前主流模型的上下文长度大约在 128K ~ 1M Tokens 之间。随着未来 LLM 的发展，支持更长的上下文将是普遍趋势。但从Tokens 成本、LLM 回复质量、响应时间等商业场景角度出发，更加准确和有效的上下文管理是非常有必要的。

一个 Token 可以是单词、标点符号或任何其他语言单元。

上下文配置思路

既然我们知道了上下文是 LLM 能「单次处理的信息量」，那么如何为这个有限的信息空间分配资源，就成为了 Agent 设计的关键。GPTBots 将 LLM 上下文定义为：长期记忆、短期记忆、身份提示、用户问题、Tools数据、和知识数据，在一次 LLM 交互中可能包含所有的上下文类型，不同类型的上下文也有着不同的优先级。

类型	优先级序号	描述
用户问题	1	用户与 Agent 对话时的最新输入内容，「系统识别」模式下通过附件上传文档的识别内容作为用户问题
身份提示	2	Agent LLM 所设定的身份信息，即：system message 或 developer message
短期记忆	3	最近 X 轮对话记录信息，X支持在 Agent-记忆中自定义数值
知识数据	4	基于用户输入内容，到 Agent 知识库内执行向量检索后所召回的知识数据
Tools数据	5	向 LLM 提交的 Tools 数据，以及 Tool 的调用返回结果数据
长期记忆	6	基于用户输入内容，在 Agent 所有对话记录中执行向量检索后所召回的对话记录信息
LLM 输出	7	LLM 输出结果数据，系统已提供 LLM 响应 token 长度选项，该部分不受以上输入部分长度的影响

注意：若在一次与 LLM 的交互中，所有类型的上下文总长度超过了 LLM 上限，GPTBots会根据优先级，从最低优先级的上下文类型进行截断处理，从而保证 LLM 调用的成功率。

用户问题

用户与 Agent 对话时的最新输入内容，包含用户通过信息输入框所发送的各类消息，包含：

手动输入的文本-Text消息
音频录制的音频-Audio消息
通过附件上传的图片-Image消息、视频-Video消息、文档-Docment消息、音频-Audio消息和文件-File消息

注意：
当「Agent-配置-输入-附件」选项选择系统识别时，GPTBots会将上传的所有附件识别为文本内容，作为用户问题。
File类型的消息，GPTBots会将文件转换为URL链接，作为用户问题。

身份提示

GPTBots Agent 中为 LLM 所设定的身份信息是指导 AI Agent 工作的重要原则，GPTBots 会跟模型版本的不同，自动适配为 system message 或 developer message。

身份提示业务场景应用中非常重要，值得您为其撰写清晰、完善的身份提示，从而指引 AI 的工作和响应。
通常不必担心身份提示的长度问题，相较于长度问题，身份提示的质量更加重要和值得投入更多tokens。
撰写身体时，清晰的表达、正确的逻辑和精准的指令至关重要。一个好的身份提示应该能够清晰地表达出你的目标、原则、技能和工作逻辑，同时避免出现模棱两可的指令。

短期记忆

用户与 Agent 的最近 X 轮对话的信息，每次请求 LLM 时都会携带。若短期记忆功能处于关闭状态，或对话是新创建的，则该部分内容为空。
在配置时，需要考虑：

若 Agent 业务场景不需要上下文或上下文会影响 AI 回复效果，则可以关闭短期记忆，以节省 Tokens 和提升 Agent 效果。
若 Agent 对上下文的依赖非常强（例如，需要依赖上下文来回答问题），您需要设置的尽可能大的记忆轮数。

知识数据

基于用户的输入内容，Agent 会根据配置在对应的知识库内执行向量检索，所召回的知识切片数据。当 Agent 没有知识库内容，或检索不到结果时，该部分为空。
在配置时，需要考虑：

若 Agent 不涉及知识库查询，可配置为不启用知识检索，以节省 Tokens。
若 Agent 对知识库查询的结果非常依赖（例如文档问答等场景），您需要在「知识库」设置的最大知识召回数、相关性得分等参数，以保证 RAG 的数量和质量。

长期记忆

基于用户的输入内容，在 Agent 所有对话记录中执行向量检索，所召回的历史对话记录信息将被携带。若长期记忆功能处于关闭状态，或对话是新创建的，则该部分为空。
在配置时，需要考虑：

若 Agent 业务场景依赖于对历史对话内容（如：虚拟角色），您需要启用长期记忆功能。
若 Agent 的场景不涉及需要使用历史对话内容，则可以关闭，以节省 Tokens。

Tools 数据

系统向 LLM 提交请求数据时，会携带该 Agent 所选择的 Tools 数据，以帮助 LLM 正确选择所需调用的Tool。当成功调用 Tool 后，API 服务所返回的结果数据需再次提交至 LLM 。若 Agent 禁用 Tools 功能则这部分为空。
在配置时，需要考虑：

若 Agent 的场景不涉及使用 Tool，则可以不为 Agent 添加 Tool，以节省 Tokens。
当一个 Tool 包含多个 API 时，可以在 Tool 配置中禁用某些不需要的 API ，被禁用的 API 不会被提交至 LLM 从而节省 Tokens。

LLM 输出

LLM 输出结果数据的 Tokens 长度在向 LLM 请求时已确定数值并已预留，GPTBots 已支持 LLM 响应 token 长度自定义选项，该部分不受以上输入部分长度的影响。

案例分析

让我们通过一个具体的例子来说明上下文 Token 的分配。假设我们使用的是一个上下文限制为 8K tokens 的 LLM 模型：

场景：客服助手

一个在线客服助手 Agent，需要：

记住用户最近的对话内容
查询产品知识库
调用订单查询接口
保持专业的客服形象

Token 处理方案

上下文类型	优先级	说明
用户问题	1	预留足够空间处理用户可能的长问题，作为最高优先级确保用户输入被完整处理
身份提示	2	包含客服礼仪、话术规范等重要指导，与用户问题同优先级保证角色定位
短期记忆	3	保留最近 3-5 轮对话记录，在资源受限时可适当压缩
知识数据	4	产品信息、常见问题等知识库内容，作为回答的重要依据需要较高优先级
Tools数据	5	订单查询接口的信息和返回结果，可根据实际调用需求动态调整
长期记忆	6	当前会话的关键信息摘要，在必要时可被优先截断

优化建议

动态调整
- 当用户问题较短时，可将节省的 tokens 自动分配给知识数据
- 未使用 Tools 时，将预留空间自动分配给短期记忆
优先级执行
- 当总 tokens 超出限制时，按优先级截断：
- 保留：用户问题、短期记忆、身份提示、知识数据、Tools数据
- 压缩/删减：长期记忆
效果保证
- 在 tokens 不足时，保证核心功能（如订单查询）的完整性
- 可以牺牲长期记忆来确保回复质量
  通过这样的规划，可以在有限的 token 空间内实现客服助手的核心功能，同时保持对话的连贯性和专业性。