token 超限别急着改模型：一套自动拆分段续传策略的落地设计

2026年07月30日 AI 工具链

在实际落地长文本 LLM 调用时，token 超限最常见的错误处理就是直接换模型或者粗暴截断。这两种方式要么成本飙升，要么丢上下文。我过去半年在三个项目里迭代出一套自动拆分段续传策略，让一次超限的请求自动分段处理，同时保持语义连贯性，实测在 128k 上下文窗口的模型上处理 300k token 级别的输入，成功率从粗暴截断的 60% 左右提升到 97% 以上。

这套方案的核心是“预估-拆分-续传”三步走，外加一个自适应重叠窗口。不是简单地把文本切碎扔给模型，而是让每一段都带上前后文锚点，模型能感知到自己在处理整个大文本的哪个部分。

预估：别等 API 报错才后悔

大部分开发者等到 API 返回 context_length_exceeded 才开始处理，这已经晚了——浪费了一次完整的请求延迟，而且某些 API 的报错信息里不会告诉你实际用了多少 token。

我用的是预估值而非精确值。tiktoken 的精确计算在长文本上太慢，实测一个 10MB 的文本文件，用 o200k_base 编码器跑一遍需要 4-6 秒。这个延迟对用户体验来说不可接受。

替代方案是根据模型类型选择粗略估算公式。以 GPT-4o 为例，官方给的比例是中文约 1 字符 = 1.5-2 token，英文约 1 字符 = 0.25 token。我直接用了 1 字符 = 2 token 的保守估计，给中文留足余量。代码长这样：

def estimate_tokens(text: str, model: str = "gpt-4o") -> int:
    """
    保守估算 token 数，中文按 1 字符 = 2 token，英文按 1 字符 = 0.3 token
    """
    import re
    chinese_chars = len(re.findall(r'[\u4e00-\u9fff]', text))
    other_chars = len(text) - chinese_chars
    if model.startswith("gpt-4o"):
        return int(chinese_chars * 2.0 + other_chars * 0.3)
    elif model.startswith("gpt-3.5"):
        return int(chinese_chars * 2.0 + other_chars * 0.3)
    else:
        # 回退到 tiktoken 精确计算
        import tiktoken
        enc = tiktoken.encoding_for_model(model)
        return len(enc.encode(text))

这个函数耗时在毫秒级，10MB 文本也能在 0.1 秒内完成。代价是估算值比实际值偏大 10%-20%，但比起超限报错，这点冗余完全值得。

拿到估算值后，我会跟模型的上下文窗口上限比较（注意要扣掉 max_tokens 输出预留）。比如用 gpt-4o，上下文 128k，我设定 max_tokens=4096，那实际可用的输入窗口就是 128000 - 4096 = 123904 token。如果估算值超过这个数，直接走分段逻辑，不发起第一次注定失败的请求。

拆分：句边界对齐加重叠锚点

简单按 token 数切分的问题在于，切口经常落在句子中间，导致模型读到“半个句子”开头，理解严重偏差。

我实现的分段器遵守两个硬约束：第一，切口必须落在句子结束符（。！？\n\n）上；第二，每段之间重叠 200-500 token 的内容作为上下文锚点。

重叠部分的选择不是机械的“取前一段最后 N 个 token”。我会在重叠区里提取一个“锚点句”——通常是前一段的总结性或转折性语句，让后一段的 system prompt 明确告知模型“这是上一段的关键信息”。效果出奇的好，尤其是在处理技术文档时，重叠区的术语定义能有效防止模型在后半段“遗忘”前面的概念。

具体拆分逻辑：

import re
from typing import List, Tuple

def split_text_with_overlap(
    text: str, 
    max_chunk_tokens: int = 100000,
    overlap_tokens: int = 500,
    model: str = "gpt-4o"
) -> List[str]:
    """
    按句边界拆分文本，段间重叠 overlap_tokens 估算值
    返回拆分后的段落列表
    """
    # 按句子分割（保留分隔符在句尾）
    sentences = re.split(r'(?<=[。！？\n])\s*', text)
    chunks = []
    current_chunk = []
    current_tokens = 0
    
    for sent in sentences:
        sent_tokens = estimate_tokens(sent, model)
        
        if current_tokens + sent_tokens > max_chunk_tokens and current_chunk:
            # 当前段满了，保存
            chunks.append(''.join(current_chunk))
            # 计算重叠部分：从当前段末尾往前取 overlap_tokens
            overlap_text = extract_overlap(''.join(current_chunk), overlap_tokens, model)
            current_chunk = [overlap_text, sent]
            current_tokens = estimate_tokens(overlap_text + sent, model)
        else:
            current_chunk.append(sent)
            current_tokens += sent_tokens
    
    if current_chunk:
        chunks.append(''.join(current_chunk))
    
    return chunks

def extract_overlap(text: str, overlap_tokens: int, model: str) -> str:
    """
    从文本末尾提取约 overlap_tokens 的内容，保证句边界完整
    """
    sentences = re.split(r'(?<=[。！？\n])\s*', text)
    overlap = []
    token_count = 0
    for sent in reversed(sentences):
        sent_tokens = estimate_tokens(sent, model)
        if token_count + sent_tokens > overlap_tokens and overlap:
            break
        overlap.insert(0, sent)
        token_count += sent_tokens
    return ''.join(overlap)

这里面有个容易踩坑的点：re.split 的分隔符处理。我用的是 (?<=[。！？\n]) 的正向后顾，保证分隔符留在句尾而不是被丢弃。中文的句号、感叹号、问号都在里面，英文句子则靠换行符兜底。实测中文技术文档的拆分准确率在 95% 以上，偶尔会在列表项上切开，但不影响语义。

续传：system prompt 里注入位置感知

分段只是把文本切好，真正让模型“知道自己在处理长文本的一部分”靠的是 system prompt 的设计。

我在每段请求的 system prompt 里注入三个信息：当前段号/总段数、前一段的锚点摘要（非首段时），以及明确指令“你的输出将被拼接到其他段的输出之后，请保持格式一致”。

关键代码：

def build_segment_prompt(
    chunk: str,
    segment_index: int,
    total_segments: int,
    previous_summary: str = None,
    task_instruction: str = ""
) -> dict:
    """
    构建带位置感知的 messages
    """
    system_content = f"""{task_instruction}

注意：这是长文本的第 {segment_index + 1}/{total_segments} 段。
你的输出将与其他段的输出拼接成完整结果。
请严格按照要求的格式输出，不要添加"这是第X段"之类的标记。"""

    if previous_summary:
        system_content += f"\n\n前一段的关键信息：\n{previous_summary}"

    return {
        "messages": [
            {"role": "system", "content": system_content},
            {"role": "user", "content": chunk}
        ]
    }

previous_summary 不是简单截取前一段的最后几句。我在实际项目里用了一个更轻量的做法：取重叠区的前 2-3 句作为摘要。因为重叠区本身就是前一段末尾 + 后一段开头的交界处，天然包含上下文衔接的关键信息。如果任务是对全文做结构化提取（比如“提取所有合同条款”），我会把前一段的提取结果直接作为 previous_summary 传入，这样模型在提取后续条款时不会重复或遗漏。

自适应重试：动态缩小 chunk 尺寸

固定 chunk 尺寸有一个致命问题：某些段落天然 token 密度极高（比如全是数字表格），预估的 100k token 上限可能仍然超限。

我加了一个自适应机制：如果单段请求仍然触发 token 超限错误，自动将该段的 max_chunk_tokens 缩小 30%，重新拆分这一段，最多重试 3 次。3 次后如果还超限，说明文本本身有问题（比如一整段无句号的乱码），这时候才 fallback 到粗暴截断。

def adaptive_segment_retry(
    text: str,
    model: str,
    task_instruction: str,
    initial_max_tokens: int = 100000,
    overlap_tokens: int = 500,
    max_retries: int = 3
) -> List[str]:
    """
    带自适应重试的分段处理
    """
    max_chunk = initial_max_tokens
    chunks = split_text_with_overlap(text, max_chunk, overlap_tokens, model)
    results = []
    
    for i, chunk in enumerate(chunks):
        previous_summary = None
        if results:
            previous_summary = extract_summary_from_result(results[-1])
        
        prompt = build_segment_prompt(
            chunk, i, len(chunks), previous_summary, task_instruction
        )
        
        retry_count = 0
        while retry_count <= max_retries:
            try:
                response = call_llm_api(prompt, model, max_tokens=4096)
                results.append(response)
                break
            except TokenLimitExceeded:
                retry_count += 1
                if retry_count > max_retries:
                    # 最终 fallback：粗暴截断
                    truncated = truncate_text(chunk, max_chunk, model)
                    prompt = build_segment_prompt(
                        truncated, i, len(chunks), previous_summary, task_instruction
                    )
                    response = call_llm_api(prompt, model, max_tokens=4096)
                    results.append(response)
                else:
                    # 缩小 30% 重新拆分这一段
                    max_chunk = int(max_chunk * 0.7)
                    sub_chunks = split_text_with_overlap(
                        chunk, max_chunk, overlap_tokens, model
                    )
                    # 处理子分段（递归）
                    sub_results = process_sub_chunks(
                        sub_chunks, i, len(chunks), previous_summary, 
                        task_instruction, model
                    )
                    results.extend(sub_results)
                    break
    return results

这套自适应机制在实际场景里触发率很低（约 3% 的请求），但存在感极强——那 3% 的用户如果没有这个机制就会直接看到报错，而不是一个虽然慢一点但最终成功的响应。

实际部署时的两个关键参数

整个方案里有三个参数对效果影响最大，我把调优结论直接列出来：

  1. overlap_tokens = 500（中文场景）。测试过 200、500、1000、2000 四个值，500 在语义连贯性和 token 浪费之间最平衡。200 时偶尔出现上下文断裂（模型输出与前一段重复或矛盾），1000 时 token 浪费约 8%，但连贯性没有进一步提升。

  2. max_chunk_tokens = 模型窗口的 80%。给输出和 prompt 开销留 20% 余量。比如 128k 窗口，max_chunk 设在 100k 左右。如果余量太小（比如 95%），自适应重试的触发率会从 3% 飙升到 15%。

  3. 初始估算公式的保守系数。中文 1 字符 = 2 token 的设定在 99% 的情况下不会低估。唯一一次翻车是一段纯生僻字的人名列表（GBK 以外的字符），实际 token 数达到了 3.5 token/字符。后来在系统里加了一个特殊字符检测：如果文本中非 ASCII 且非 CJK 基本区的字符占比超过 5%，自动切换到 tiktoken 精确计算。

常见问题

这套方案会增加多少延迟？

首 token 延迟基本不变，因为预估和拆分的耗时在 0.1-0.5 秒内完成。总延迟取决于分段数——每多一段就多一次完整的 API 调用。以 gpt-4o 为例，处理 300k token 的文档通常拆成 3 段，总延迟是单次调用的 3 倍左右。但并行调用各段可以降到接近单次延迟，代价是丢失前后文依赖（我没用并行，因为续传效果明显更好）。

重叠窗口会不会导致模型重复输出相同内容？

如果 system prompt 不写清楚，确实会。模型看到重叠部分的内容，有时会在两段的输出里重复处理同一段信息。解决方法是在 system prompt 里加一句：“前一段已经处理过的内容（见前一段关键信息），请勿重复处理，只需补充本段新增的信息。”这个提示词在 2024 年 8 月后的 gpt-4o 版本上效果显著，重复率从约 12% 降到 2% 以下。

这个方案能用到其他模型上吗？

可以，但需要调整估算公式。Claude 3.5 Sonnet 的中文 token 比例更接近 1 字符 = 1.2 token（比 GPT-4o 省 token），Gemini 1.5 Pro 则接近 1 字符 = 2.5 token（更费 token）。建议先用 100 条真实数据跑一次精确的 tiktoken 对比，得出自己业务场景下的比例系数。另外 Claude 的 API 对重叠段落的处理比 GPT-4o 更敏感，overlap_tokens 建议降到 300。

#LLM token超限 #长文本分段