大模型中的BOS（Beginning of Sequence）和EOS（End of Sequence）分别是序列起始和结束的标记符号，它们如同对话的“开关”，明确告知模型何时开始生成内容以及何时停止输出，是确保文本生成准确性和逻辑完整性的核心技术机制。
在大型语言模型（LLM）的底层逻辑中，文本并非简单的字符堆砌，而是被转化为一系列数字令牌（Tokens），为了让模型能够像人类一样理解对话的边界，开发者引入了特殊的控制标记，BOS和EOS就是其中最重要的两个“边界守卫”，如果没有它们，模型就像是在没有红绿灯的十字路口盲目行驶，要么不知道从何说起,要么永远停不下来。
深入解析BOS与EOS的核心定义
理解这两个概念，首先要打破“文本即连续流”的直觉认知，在计算机眼中,每一段输入和输出都被切分为独立的片段。
BOS：序列起始标记的作用机制
BOS，全称为Beginning of Sequence，意为序列开始标记,它通常位于整个输入文本或输出文本的最前端。
- 上下文锚点：BOS告诉模型，“新的对话回合开始了”或者“新的任务指令已就绪”，在多轮对话场景中，BOS帮助模型重置注意力机制，聚焦于当前轮次的指令,而不是被上一轮的历史信息过度干扰。
- 概率初始化：从数学角度看，BOS标记设定了生成第一个Token的概率分布基准，它相当于给模型一个初始状态，确保生成的第一个词符合语言模型的语法习惯，在中文语境下，BOS后紧跟的往往是标点符号或符合语境的实词,而非毫无逻辑的乱码。
EOS：序列结束标记的控制逻辑
EOS，全称为End of Sequence，意为序列结束标记，它出现在生成文本的末尾,标志着当前生成任务的完成。
- 停止生成指令
：这是EOS最直接的功能，当模型预测到下一个Token是EOS时，它会立即停止生成，不再输出任何后续字符，这有效防止了模型陷入“无限循环”或产生冗余的废话。
- 语义完整性确认：EOS不仅是一个停止信号，也是一个语义完成的信号，它暗示模型：“当前的逻辑链条已经闭环，不需要再继续补充。”在代码生成或数学解题场景中,EOS的出现往往意味着代码块闭合或解题步骤结束。
BOS与EOS在实际应用场景中的差异
不同的大模型架构对BOS和EOS的处理方式存在显著差异,这种差异直接影响了用户体验和开发者的调试难度。
指令微调模型中的特殊表现
在基于Transformer架构的开源模型（如Llama系列、Qwen系列）中,BOS和EOS的使用策略各不相同。
- Llama模型：通常使用
<|begin_of_text|>作为BOS，使用<|end_of_text|>作为EOS，在输入Prompt时，开发者需要显式地添加这些标记,否则模型可能无法正确识别对话边界。 - Qwen模型：部分版本默认在输入中自动添加BOS，而EOS则由模型在生成过程中动态判断，这种设计简化了前端开发的复杂度,但要求开发者理解模型的停止条件。
闭源API模型中的透明化处理
对于使用百度文心一言、阿里云通义千问等闭源API服务的开发者而言，BOS和EOS通常是“黑盒”操作。
- 自动封装：API接口会自动处理序列标记，开发者只需传入用户问题和系统提示词，后端服务会在发送前自动添加必要的BOS标记,并在检测到EOS后截断输出。
- 参数控制：虽然用户看不到标记，但可以通过
max_tokens或stop_sequences参数间接控制EOS的行为，设置stop_sequences=["nn"]
，模型在遇到两个换行符时可能会提前触发类似EOS的停止逻辑,但这并非标准的EOS标记。
技术实现中的常见问题与解决方案
在实际部署大模型应用时，BOS和EOS的处理不当会导致多种故障,以下是业内常见的痛点及应对策略。
模型“停不下来”的调试技巧
当模型持续输出无意义字符或重复内容时,往往是EOS机制失效或未被正确识别。
- 检查温度参数（Temperature）：过高的温度会导致模型概率分布过于平滑，难以生成高概率的EOS标记，建议将温度降低至0.1-0.3之间,以增强EOS生成的确定性。
- 验证停止词列表：确保后端代码正确监听了EOS Token ID，不同模型的EOS ID不同，例如GPT系列的EOS ID通常为50256，而Llama系列可能不同,使用错误的ID会导致截断失败。
- 强制截断机制：作为兜底方案，设置最大生成长度（max_new_tokens），即使EOS未触发，达到上限后也应强制停止,防止资源耗尽。
BOS缺失导致的上下文混乱
如果BOS未被正确添加，模型可能会将上一轮对话的结尾误认为是当前对话的开始,导致逻辑跳跃。
- 显式分隔符：在Prompt工程中，使用清晰的符号（如或）分隔不同轮次,辅助模型识别边界。
- 系统提示词优化：在系统提示词中明确指令，如“你是一个助手，请根据以下用户输入回答问题”,帮助模型建立新的上下文锚点。
未来趋势：BOS与EOS的演进方向
随着大模型向多模态和Agent化发展,BOS和EOS的定义也在不断扩展。
多模态场景下的扩展标记
在图像、音频等多模态任务中，单一的BOS/EOS已不足以描述复杂的输入结构。
-
分段标记
：引入IMG_BOS、IMG_EOS等标记,分别表示图像块的开始和结束。 - 层级结构：构建更复杂的树状标记体系,以支持视频帧序列或长音频片段的精准定位。
Agent自主决策中的动态边界
在智能体（Agent）应用中,模型需要自主决定何时结束当前任务并调用工具。
- 隐式EOS：模型不再依赖固定的EOS标记,而是通过内部状态判断任务完成度。
- 工具调用标记：引入TOOL_CALL_BOS和TOOL_CALL_EOS，明确标识工具调用的起止,便于系统解析和执行。
Q&A：关于大模型BOS和EOS的常见疑问
大模型的BOS和EOS在代码生成中有什么特殊作用？
在代码生成场景中，BOS和EOS用于界定代码块的完整结构，BOS确保模型从正确的语言语法开始生成，而EOS则保证代码块闭合，避免生成未完成的函数或类，在生成Python代码时，EOS通常对应于代码缩进回归或文件结束符,确保生成的代码可以直接运行而不报错。
如何判断大模型是否忽略了BOS标记？
如果模型输出的第一个Token不符合语言习惯，或者在连续对话中表现出对上一轮内容的过度依赖，可能意味着BOS未被正确识别，开发者可以通过检查输入数据的预处理日志，确认BOS标记是否被正确添加，使用调试工具可视化Token概率分布，观察第一个Token的概率峰值是否合理,也是有效的诊断方法。
BOS和EOS标记会被训练数据污染吗？
BOS和EOS是人工设计的控制标记，不属于自然语言词汇，因此不会被训练数据中的语义信息“污染”，如果训练数据中大量包含错误的标记使用（如缺失EOS），模型可能会学习到错误的生成习惯，高质量的指令微调数据至关重要,需确保标记使用的规范性和一致性。
首发原创文章，作者：王坚，如若转载，请注明出处：https://test.idctop.com/article/408283.html
