Nanbeige4.1-3B基础教程input_ids长度计算与context overflow预防机制1. 引言为什么需要关注输入长度如果你用过像ChatGPT这样的对话模型可能会发现一个问题聊着聊着模型好像“失忆”了不记得你之前说过什么。或者更糟当你输入一段很长的文本时模型直接报错告诉你“输入太长了”。这背后的核心原因就是输入长度超出了模型的“记忆容量”。对于Nanbeige4.1-3B这样的模型来说这个容量就是它的上下文窗口官方支持8K tokens约等于6000个汉字。今天这篇文章我就来手把手教你两件事怎么精确计算你的输入到底占用了多少“容量”input_ids的长度怎么提前预防“容量”超限避免程序崩溃context overflow预防无论你是想用Nanbeige4.1-3B来写长篇小说、分析长文档还是构建一个能记住超长对话历史的智能体掌握这两个技巧都至关重要。我们直接从代码入手用最实际的方式把问题讲清楚。2. 环境准备与快速回顾在深入细节之前我们先确保环境是就绪的。如果你已经按照官方指南部署好了Nanbeige4.1-3B可以跳过这一步。如果还没部署下面是最简短的回顾。2.1 基础环境检查你需要一个Python环境建议3.8以上和基本的深度学习库。打开你的终端或命令行运行以下命令来安装核心依赖pip install torch transformers accelerate2.2 加载模型与分词器这是与Nanbeige4.1-3B交互的第一步。下面的代码展示了如何正确加载模型和分词器特别注意trust_remote_codeTrue这个参数对于某些自定义架构的模型是必须的。import torch from transformers import AutoModelForCausalLM, AutoTokenizer # 指定你的模型存放路径 model_path /root/ai-models/nanbeige/Nanbeige4___1-3B print(正在加载分词器...) tokenizer AutoTokenizer.from_pretrained( model_path, trust_remote_codeTrue # 关键参数允许运行模型自定义的代码 ) print(正在加载模型...) model AutoModelForCausalLM.from_pretrained( model_path, torch_dtypetorch.bfloat16, # 使用bfloat16精度节省显存 device_mapauto, # 自动分配模型层到可用的GPU/CPU trust_remote_codeTrue ) print(模型加载完成)运行这段代码如果没有报错恭喜你环境准备就绪。接下来我们进入正题。3. 核心概念Token、input_ids与长度计算很多人容易混淆“字数”和模型的“token数”。理解这个区别是掌握长度管理的第一步。3.1 什么是Token你可以把Token理解为模型看到的“基本单位”。对于英文一个单词可能被拆成多个token例如“playing” - “play”, “ing”。对于中文一个字通常就是一个token但复杂的词或标点也可能被特殊处理。关键点你输入的文本会被tokenizer分词器转换成一串数字这串数字就是input_ids。input_ids的长度就是模型视角下你输入的“长度”。3.2 如何计算input_ids的长度计算长度非常简单直接用分词器的encode方法。我们来看几个例子# 示例1计算一句中文的长度 text_zh 今天天气真好我们一起去公园散步吧。 input_ids_zh tokenizer.encode(text_zh) print(f中文文本: {text_zh}) print(f对应的input_ids: {input_ids_zh}) print(finput_ids长度 (token数): {len(input_ids_zh)}) print(- * 30) # 示例2计算一句英文的长度 text_en The quick brown fox jumps over the lazy dog. input_ids_en tokenizer.encode(text_en) print(f英文文本: {text_en}) print(f对应的input_ids: {input_ids_en}) print(finput_ids长度 (token数): {len(input_ids_en)}) print(- * 30) # 示例3计算混合文本的长度 text_mix Hello 世界This is a test. 这是一个测试。 input_ids_mix tokenizer.encode(text_mix) print(f混合文本: {text_mix}) print(finput_ids长度 (token数): {len(input_ids_mix)})运行这段代码你会看到类似下面的输出。注意中文的token数通常接近或等于字数而英文的token数往往多于单词数。中文文本: 今天天气真好我们一起去公园散步吧。 对应的input_ids: [1, 100, 200, 300, ...] # 这里是一串数字ID input_ids长度 (token数): 15 ------------------------------ 英文文本: The quick brown fox jumps over the lazy dog. 对应的input_ids: [1, 200, 400, ...] input_ids长度 (token数): 12 ------------------------------ 混合文本: Hello 世界This is a test. 这是一个测试。 inputids长度 (token数): 20重要提示你看到的input_ids列表开头可能有一个特殊的数字如1这代表了bos句子开始token它也会占用一个长度。在计算总长度时必须把它算进去。4. 实战对话场景下的长度计算与溢出预防在实际的对话应用中我们的输入不是单一的一句话而是一组消息messages。Nanbeige4.1-3B使用apply_chat_template方法来处理这种格式。这是最容易发生长度计算错误的地方。4.1 计算对话历史的token长度假设我们有这样一段对话历史messages [ {role: system, content: 你是一个乐于助人的AI助手。}, {role: user, content: 你好请介绍一下Python语言的优点。}, {role: assistant, content: Python是一种高级编程语言以其简洁明了的语法、强大的标准库和丰富的第三方生态而闻名。它非常适合初学者入门同时也被广泛应用于Web开发、数据分析、人工智能和科学计算等领域。}, {role: user, content: 那么它有什么缺点呢} ]我们想知道把这整个对话历史喂给模型之前它到底有多长。# 错误做法直接拼接文本再编码 # 这忽略了对话模板添加的特殊token如角色标识符会导致长度计算严重偏小 full_text for msg in messages: full_text msg[content] incorrect_length len(tokenizer.encode(full_text)) print(f错误计算的长度: {incorrect_length} tokens) # 正确做法使用apply_chat_template生成input_ids再计算长度 print(\n正在使用apply_chat_template处理对话历史...) input_ids tokenizer.apply_chat_template( messages, return_tensorspt # 返回PyTorch张量 ) correct_length input_ids.shape[1] # 形状为 (1, sequence_length) print(f正确计算的长度: {correct_length} tokens) print(f模型看到的完整input_ids (前20个): {input_ids[0, :20]})你会发现正确计算的长度远大于错误计算的长度。这是因为apply_chat_template会在每条消息前后添加特定的token来标识角色如|im_start|user这些“模板token”会显著增加总长度。忽略它们是导致后续“溢出”错误的常见原因。4.2 实现Context Overflow预防机制知道了真实长度我们就可以在调用model.generate()之前进行预防。思路很简单如果当前对话历史长度 我们期望模型生成的最大长度 模型最大上下文长度那么就进行截断。Nanbeige4.1-3B的最大上下文长度是262,144 tokens即256K。但在实际对话中我们通常使用其支持的8K8192上下文窗口。我们以此为例来构建预防逻辑。def safe_generate_with_context_check(model, tokenizer, messages, max_new_tokens512, context_window8192): 安全的文本生成函数自动预防上下文溢出。 参数: model: 加载好的模型 tokenizer: 加载好的分词器 messages: 对话历史列表 max_new_tokens: 期望模型生成的最大token数 context_window: 模型使用的上下文窗口大小Nanbeige4.1-3B对话常用8192 返回: response: 模型生成的回复文本 input_ids_trimmed: 处理后的输入ID用于调试 # 1. 将对话历史转换为input_ids input_ids tokenizer.apply_chat_template( messages, return_tensorspt ).to(model.device) current_length input_ids.shape[1] print(f当前对话历史占用: {current_length} tokens) print(f计划生成: {max_new_tokens} tokens) print(f上下文窗口限制: {context_window} tokens) # 2. 检查是否会溢出 if current_length max_new_tokens context_window: print(警告输入长度将超出上下文窗口正在进行截断...) # 计算需要保留多少token # 我们优先保留最新的对话因为模型对最近的上下文更敏感 tokens_to_keep context_window - max_new_tokens - 50 # 留50个token作为缓冲 if tokens_to_keep 100: # 如果保留的太少连一条消息都放不下则调整生成长度 print(保留空间过小将减少生成长度。) max_new_tokens context_window - current_length - 10 tokens_to_keep current_length else: # 截断input_ids保留最后tokens_to_keep个token input_ids input_ids[:, -tokens_to_keep:] print(f截断后输入长度: {input_ids.shape[1]} tokens) print(f调整后生成长度: {max_new_tokens} tokens) else: print(长度检查通过无需截断。) # 3. 调用模型生成 with torch.no_grad(): outputs model.generate( input_ids, max_new_tokensmax_new_tokens, temperature0.6, top_p0.95, do_sampleTrue, pad_token_idtokenizer.eos_token_id # 设置填充token ) # 4. 解码输出只取新生成的部分 # 注意outputs包含了输入输出我们需要跳过输入部分 new_tokens outputs[0][current_length:] if current_length outputs.shape[1] else outputs[0] response tokenizer.decode(new_tokens, skip_special_tokensTrue) return response, input_ids # 使用我们的安全函数进行生成 response, processed_input_ids safe_generate_with_context_check(model, tokenizer, messages, max_new_tokens200) print(\n *50) print(模型回复) print(response) print(*50)这个safe_generate_with_context_check函数是一个健壮的生成工具。它做了以下几件事精确计算用正确的方法计算当前对话的token长度。提前预警在生成前就判断是否会超限。智能截断如果会超限它自动截断历史对话优先保留最新的部分因为最近的对话通常最重要并确保给模型生成留出空间。动态调整在极端情况下历史太长它会自动减少生成长度而不是直接报错。5. 处理超长文本分段与总结策略对于需要处理整本书、长篇论文或超长日志的场景8K的上下文窗口可能也不够用。这时我们需要更高级的策略。5.1 策略一滑动窗口问答对于问答任务我们可以采用“滑动窗口”的方式每次只将相关段落送入模型。def qa_with_sliding_window(long_text, question, window_size2000, stride1000): 使用滑动窗口在长文本中寻找答案。 原理将长文本切成重叠的片段分别提问最后综合答案。 # 1. 将长文本token化 long_text_ids tokenizer.encode(long_text) text_length len(long_text_ids) print(f长文本总长度: {text_length} tokens) answers [] start 0 # 2. 创建滑动窗口 while start text_length: end min(start window_size, text_length) window_ids long_text_ids[start:end] window_text tokenizer.decode(window_ids, skip_special_tokensTrue) # 3. 为每个窗口构建问答 window_messages [ {role: system, content: 请根据以下文本片段回答问题。如果文本中没有明确答案请说‘根据提供的文本无法回答’。}, {role: user, content: f文本{window_text}\n\n问题{question}} ] # 使用之前的安全生成函数 answer, _ safe_generate_with_context_check(model, tokenizer, window_messages, max_new_tokens150) answers.append((start, end, answer)) print(f处理窗口 [{start}:{end}] 获得答案摘要: {answer[:50]}...) # 4. 移动窗口 if end text_length: break start stride # 5. 简单综合答案这里可以做得更复杂比如投票或基于置信度选择 # 本例中我们返回最后一个非“无法回答”的答案或所有答案供人工判断 valid_answers [ans for _, _, ans in answers if 无法回答 not in ans] if valid_answers: final_answer valid_answers[-1] # 取最后一个有效答案 else: final_answer 在所有文本片段中均未找到明确答案。 print(所有窗口答案, answers) return final_answer, answers # 假设我们有一个很长的文档 very_long_document # question 文档中提到的核心创新点是什么 # final_answer, all_window_answers qa_with_sliding_window(very_long_document, question) # print(f最终答案{final_answer})5.2 策略二递归总结对于需要理解全文主旨的任务我们可以让模型自己边读边总结。def recursive_summarization(long_text, chunk_size3000, summary_length200): 递归总结长文本。 原理将文本分成块总结每一块然后将总结汇总起来再总结直到满足长度要求。 # 1. 分块 long_text_ids tokenizer.encode(long_text) chunks [long_text_ids[i:ichunk_size] for i in range(0, len(long_text_ids), chunk_size)] chunk_texts [tokenizer.decode(chunk, skip_special_tokensTrue) for chunk in chunks] print(f将文本分成了 {len(chunks)} 块。) summaries [] for i, chunk_text in enumerate(chunk_texts): # 2. 总结单个块 messages [ {role: system, content: 请用简洁的语言总结以下文本的核心内容。}, {role: user, content: f文本{chunk_text}} ] summary, _ safe_generate_with_context_check(model, tokenizer, messages, max_new_tokenssummary_length) summaries.append(summary) print(f已总结第 {i1}/{len(chunks)} 块。) # 3. 如果总结还是太长就递归总结 combined_summary \n.join(summaries) if len(tokenizer.encode(combined_summary)) chunk_size: print(初步总结仍然过长进行递归总结...) return recursive_summarization(combined_summary, chunk_size, summary_length) else: return combined_summary # 使用递归总结 # long_document ... # 你的超长文本 # final_summary recursive_summarization(long_document) # print(f最终总结\n{final_summary})6. 总结与最佳实践通过上面的讲解和代码你应该已经掌握了管理Nanbeige4.1-3B输入长度的核心技能。让我们最后总结一下关键点和最佳实践6.1 关键要点回顾长度单位是Token不是字数始终使用tokenizer.encode()或apply_chat_template()后的input_ids.shape[1]来获取精确长度。对话历史会显著增加长度apply_chat_template添加的角色标识符等模板token会占用大量空间计算时绝不能忽略。预防优于处理在调用generate()之前使用类似safe_generate_with_context_check的函数进行长度检查和智能截断。超长文本有策略对于超出上下文窗口的文本采用“滑动窗口问答”或“递归总结”等分治策略。6.2 最佳实践清单始终进行长度检查在构建生产级应用时将长度检查逻辑封装成必走的流程。设置合理的缓冲在计算(当前长度 生成长度) 上下文限制时预留50-100个token的缓冲避免边缘情况出错。优先截断早期历史进行截断时优先丢弃最早的对话轮次保留最新的对话因为模型对近期的上下文记忆更有效。监控长度使用在日志中记录每次请求的输入/输出token数这有助于优化提示词和发现潜在问题。了解模型真实上限虽然Nanbeige4.1-3B支持256K上下文但在8K窗口下进行对话通常能获得最佳的性能和成本平衡。对于更长文本的处理明确使用5.1和5.2节的分段策略。管理好上下文长度是构建稳定、可靠的大模型应用的基础。希望这篇教程能帮助你充分利用Nanbeige4.1-3B强大的长文本能力而不再受困于“上下文溢出”的错误。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。
Nanbeige4.1-3B基础教程：input_ids长度计算与context overflow预防机制
Nanbeige4.1-3B基础教程input_ids长度计算与context overflow预防机制1. 引言为什么需要关注输入长度如果你用过像ChatGPT这样的对话模型可能会发现一个问题聊着聊着模型好像“失忆”了不记得你之前说过什么。或者更糟当你输入一段很长的文本时模型直接报错告诉你“输入太长了”。这背后的核心原因就是输入长度超出了模型的“记忆容量”。对于Nanbeige4.1-3B这样的模型来说这个容量就是它的上下文窗口官方支持8K tokens约等于6000个汉字。今天这篇文章我就来手把手教你两件事怎么精确计算你的输入到底占用了多少“容量”input_ids的长度怎么提前预防“容量”超限避免程序崩溃context overflow预防无论你是想用Nanbeige4.1-3B来写长篇小说、分析长文档还是构建一个能记住超长对话历史的智能体掌握这两个技巧都至关重要。我们直接从代码入手用最实际的方式把问题讲清楚。2. 环境准备与快速回顾在深入细节之前我们先确保环境是就绪的。如果你已经按照官方指南部署好了Nanbeige4.1-3B可以跳过这一步。如果还没部署下面是最简短的回顾。2.1 基础环境检查你需要一个Python环境建议3.8以上和基本的深度学习库。打开你的终端或命令行运行以下命令来安装核心依赖pip install torch transformers accelerate2.2 加载模型与分词器这是与Nanbeige4.1-3B交互的第一步。下面的代码展示了如何正确加载模型和分词器特别注意trust_remote_codeTrue这个参数对于某些自定义架构的模型是必须的。import torch from transformers import AutoModelForCausalLM, AutoTokenizer # 指定你的模型存放路径 model_path /root/ai-models/nanbeige/Nanbeige4___1-3B print(正在加载分词器...) tokenizer AutoTokenizer.from_pretrained( model_path, trust_remote_codeTrue # 关键参数允许运行模型自定义的代码 ) print(正在加载模型...) model AutoModelForCausalLM.from_pretrained( model_path, torch_dtypetorch.bfloat16, # 使用bfloat16精度节省显存 device_mapauto, # 自动分配模型层到可用的GPU/CPU trust_remote_codeTrue ) print(模型加载完成)运行这段代码如果没有报错恭喜你环境准备就绪。接下来我们进入正题。3. 核心概念Token、input_ids与长度计算很多人容易混淆“字数”和模型的“token数”。理解这个区别是掌握长度管理的第一步。3.1 什么是Token你可以把Token理解为模型看到的“基本单位”。对于英文一个单词可能被拆成多个token例如“playing” - “play”, “ing”。对于中文一个字通常就是一个token但复杂的词或标点也可能被特殊处理。关键点你输入的文本会被tokenizer分词器转换成一串数字这串数字就是input_ids。input_ids的长度就是模型视角下你输入的“长度”。3.2 如何计算input_ids的长度计算长度非常简单直接用分词器的encode方法。我们来看几个例子# 示例1计算一句中文的长度 text_zh 今天天气真好我们一起去公园散步吧。 input_ids_zh tokenizer.encode(text_zh) print(f中文文本: {text_zh}) print(f对应的input_ids: {input_ids_zh}) print(finput_ids长度 (token数): {len(input_ids_zh)}) print(- * 30) # 示例2计算一句英文的长度 text_en The quick brown fox jumps over the lazy dog. input_ids_en tokenizer.encode(text_en) print(f英文文本: {text_en}) print(f对应的input_ids: {input_ids_en}) print(finput_ids长度 (token数): {len(input_ids_en)}) print(- * 30) # 示例3计算混合文本的长度 text_mix Hello 世界This is a test. 这是一个测试。 input_ids_mix tokenizer.encode(text_mix) print(f混合文本: {text_mix}) print(finput_ids长度 (token数): {len(input_ids_mix)})运行这段代码你会看到类似下面的输出。注意中文的token数通常接近或等于字数而英文的token数往往多于单词数。中文文本: 今天天气真好我们一起去公园散步吧。 对应的input_ids: [1, 100, 200, 300, ...] # 这里是一串数字ID input_ids长度 (token数): 15 ------------------------------ 英文文本: The quick brown fox jumps over the lazy dog. 对应的input_ids: [1, 200, 400, ...] input_ids长度 (token数): 12 ------------------------------ 混合文本: Hello 世界This is a test. 这是一个测试。 inputids长度 (token数): 20重要提示你看到的input_ids列表开头可能有一个特殊的数字如1这代表了bos句子开始token它也会占用一个长度。在计算总长度时必须把它算进去。4. 实战对话场景下的长度计算与溢出预防在实际的对话应用中我们的输入不是单一的一句话而是一组消息messages。Nanbeige4.1-3B使用apply_chat_template方法来处理这种格式。这是最容易发生长度计算错误的地方。4.1 计算对话历史的token长度假设我们有这样一段对话历史messages [ {role: system, content: 你是一个乐于助人的AI助手。}, {role: user, content: 你好请介绍一下Python语言的优点。}, {role: assistant, content: Python是一种高级编程语言以其简洁明了的语法、强大的标准库和丰富的第三方生态而闻名。它非常适合初学者入门同时也被广泛应用于Web开发、数据分析、人工智能和科学计算等领域。}, {role: user, content: 那么它有什么缺点呢} ]我们想知道把这整个对话历史喂给模型之前它到底有多长。# 错误做法直接拼接文本再编码 # 这忽略了对话模板添加的特殊token如角色标识符会导致长度计算严重偏小 full_text for msg in messages: full_text msg[content] incorrect_length len(tokenizer.encode(full_text)) print(f错误计算的长度: {incorrect_length} tokens) # 正确做法使用apply_chat_template生成input_ids再计算长度 print(\n正在使用apply_chat_template处理对话历史...) input_ids tokenizer.apply_chat_template( messages, return_tensorspt # 返回PyTorch张量 ) correct_length input_ids.shape[1] # 形状为 (1, sequence_length) print(f正确计算的长度: {correct_length} tokens) print(f模型看到的完整input_ids (前20个): {input_ids[0, :20]})你会发现正确计算的长度远大于错误计算的长度。这是因为apply_chat_template会在每条消息前后添加特定的token来标识角色如|im_start|user这些“模板token”会显著增加总长度。忽略它们是导致后续“溢出”错误的常见原因。4.2 实现Context Overflow预防机制知道了真实长度我们就可以在调用model.generate()之前进行预防。思路很简单如果当前对话历史长度 我们期望模型生成的最大长度 模型最大上下文长度那么就进行截断。Nanbeige4.1-3B的最大上下文长度是262,144 tokens即256K。但在实际对话中我们通常使用其支持的8K8192上下文窗口。我们以此为例来构建预防逻辑。def safe_generate_with_context_check(model, tokenizer, messages, max_new_tokens512, context_window8192): 安全的文本生成函数自动预防上下文溢出。 参数: model: 加载好的模型 tokenizer: 加载好的分词器 messages: 对话历史列表 max_new_tokens: 期望模型生成的最大token数 context_window: 模型使用的上下文窗口大小Nanbeige4.1-3B对话常用8192 返回: response: 模型生成的回复文本 input_ids_trimmed: 处理后的输入ID用于调试 # 1. 将对话历史转换为input_ids input_ids tokenizer.apply_chat_template( messages, return_tensorspt ).to(model.device) current_length input_ids.shape[1] print(f当前对话历史占用: {current_length} tokens) print(f计划生成: {max_new_tokens} tokens) print(f上下文窗口限制: {context_window} tokens) # 2. 检查是否会溢出 if current_length max_new_tokens context_window: print(警告输入长度将超出上下文窗口正在进行截断...) # 计算需要保留多少token # 我们优先保留最新的对话因为模型对最近的上下文更敏感 tokens_to_keep context_window - max_new_tokens - 50 # 留50个token作为缓冲 if tokens_to_keep 100: # 如果保留的太少连一条消息都放不下则调整生成长度 print(保留空间过小将减少生成长度。) max_new_tokens context_window - current_length - 10 tokens_to_keep current_length else: # 截断input_ids保留最后tokens_to_keep个token input_ids input_ids[:, -tokens_to_keep:] print(f截断后输入长度: {input_ids.shape[1]} tokens) print(f调整后生成长度: {max_new_tokens} tokens) else: print(长度检查通过无需截断。) # 3. 调用模型生成 with torch.no_grad(): outputs model.generate( input_ids, max_new_tokensmax_new_tokens, temperature0.6, top_p0.95, do_sampleTrue, pad_token_idtokenizer.eos_token_id # 设置填充token ) # 4. 解码输出只取新生成的部分 # 注意outputs包含了输入输出我们需要跳过输入部分 new_tokens outputs[0][current_length:] if current_length outputs.shape[1] else outputs[0] response tokenizer.decode(new_tokens, skip_special_tokensTrue) return response, input_ids # 使用我们的安全函数进行生成 response, processed_input_ids safe_generate_with_context_check(model, tokenizer, messages, max_new_tokens200) print(\n *50) print(模型回复) print(response) print(*50)这个safe_generate_with_context_check函数是一个健壮的生成工具。它做了以下几件事精确计算用正确的方法计算当前对话的token长度。提前预警在生成前就判断是否会超限。智能截断如果会超限它自动截断历史对话优先保留最新的部分因为最近的对话通常最重要并确保给模型生成留出空间。动态调整在极端情况下历史太长它会自动减少生成长度而不是直接报错。5. 处理超长文本分段与总结策略对于需要处理整本书、长篇论文或超长日志的场景8K的上下文窗口可能也不够用。这时我们需要更高级的策略。5.1 策略一滑动窗口问答对于问答任务我们可以采用“滑动窗口”的方式每次只将相关段落送入模型。def qa_with_sliding_window(long_text, question, window_size2000, stride1000): 使用滑动窗口在长文本中寻找答案。 原理将长文本切成重叠的片段分别提问最后综合答案。 # 1. 将长文本token化 long_text_ids tokenizer.encode(long_text) text_length len(long_text_ids) print(f长文本总长度: {text_length} tokens) answers [] start 0 # 2. 创建滑动窗口 while start text_length: end min(start window_size, text_length) window_ids long_text_ids[start:end] window_text tokenizer.decode(window_ids, skip_special_tokensTrue) # 3. 为每个窗口构建问答 window_messages [ {role: system, content: 请根据以下文本片段回答问题。如果文本中没有明确答案请说‘根据提供的文本无法回答’。}, {role: user, content: f文本{window_text}\n\n问题{question}} ] # 使用之前的安全生成函数 answer, _ safe_generate_with_context_check(model, tokenizer, window_messages, max_new_tokens150) answers.append((start, end, answer)) print(f处理窗口 [{start}:{end}] 获得答案摘要: {answer[:50]}...) # 4. 移动窗口 if end text_length: break start stride # 5. 简单综合答案这里可以做得更复杂比如投票或基于置信度选择 # 本例中我们返回最后一个非“无法回答”的答案或所有答案供人工判断 valid_answers [ans for _, _, ans in answers if 无法回答 not in ans] if valid_answers: final_answer valid_answers[-1] # 取最后一个有效答案 else: final_answer 在所有文本片段中均未找到明确答案。 print(所有窗口答案, answers) return final_answer, answers # 假设我们有一个很长的文档 very_long_document # question 文档中提到的核心创新点是什么 # final_answer, all_window_answers qa_with_sliding_window(very_long_document, question) # print(f最终答案{final_answer})5.2 策略二递归总结对于需要理解全文主旨的任务我们可以让模型自己边读边总结。def recursive_summarization(long_text, chunk_size3000, summary_length200): 递归总结长文本。 原理将文本分成块总结每一块然后将总结汇总起来再总结直到满足长度要求。 # 1. 分块 long_text_ids tokenizer.encode(long_text) chunks [long_text_ids[i:ichunk_size] for i in range(0, len(long_text_ids), chunk_size)] chunk_texts [tokenizer.decode(chunk, skip_special_tokensTrue) for chunk in chunks] print(f将文本分成了 {len(chunks)} 块。) summaries [] for i, chunk_text in enumerate(chunk_texts): # 2. 总结单个块 messages [ {role: system, content: 请用简洁的语言总结以下文本的核心内容。}, {role: user, content: f文本{chunk_text}} ] summary, _ safe_generate_with_context_check(model, tokenizer, messages, max_new_tokenssummary_length) summaries.append(summary) print(f已总结第 {i1}/{len(chunks)} 块。) # 3. 如果总结还是太长就递归总结 combined_summary \n.join(summaries) if len(tokenizer.encode(combined_summary)) chunk_size: print(初步总结仍然过长进行递归总结...) return recursive_summarization(combined_summary, chunk_size, summary_length) else: return combined_summary # 使用递归总结 # long_document ... # 你的超长文本 # final_summary recursive_summarization(long_document) # print(f最终总结\n{final_summary})6. 总结与最佳实践通过上面的讲解和代码你应该已经掌握了管理Nanbeige4.1-3B输入长度的核心技能。让我们最后总结一下关键点和最佳实践6.1 关键要点回顾长度单位是Token不是字数始终使用tokenizer.encode()或apply_chat_template()后的input_ids.shape[1]来获取精确长度。对话历史会显著增加长度apply_chat_template添加的角色标识符等模板token会占用大量空间计算时绝不能忽略。预防优于处理在调用generate()之前使用类似safe_generate_with_context_check的函数进行长度检查和智能截断。超长文本有策略对于超出上下文窗口的文本采用“滑动窗口问答”或“递归总结”等分治策略。6.2 最佳实践清单始终进行长度检查在构建生产级应用时将长度检查逻辑封装成必走的流程。设置合理的缓冲在计算(当前长度 生成长度) 上下文限制时预留50-100个token的缓冲避免边缘情况出错。优先截断早期历史进行截断时优先丢弃最早的对话轮次保留最新的对话因为模型对近期的上下文记忆更有效。监控长度使用在日志中记录每次请求的输入/输出token数这有助于优化提示词和发现潜在问题。了解模型真实上限虽然Nanbeige4.1-3B支持256K上下文但在8K窗口下进行对话通常能获得最佳的性能和成本平衡。对于更长文本的处理明确使用5.1和5.2节的分段策略。管理好上下文长度是构建稳定、可靠的大模型应用的基础。希望这篇教程能帮助你充分利用Nanbeige4.1-3B强大的长文本能力而不再受困于“上下文溢出”的错误。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。
