模型没问题，是token假设出错：长文本分类静默降级根因

模型没问题，是token假设出错：长文本分类静默降级根因 | 前端进阶之旅

Full translation

完整中文译文

问题从来不在模型本身。而这恰恰是它花了三天才定位的原因。我的工单分类服务在把推理链路切换到一个更便宜的端点后，开始对长文本的非英语消息返回兜底标签，直觉让我把所有怀疑都指向了新换的模型。真正的罪魁祸首是一个 token 计数的错配，它在模型真正看到分类指令之前就悄悄截断了 prompt。

这个失败表现得非常稳定，这让它更具迷惑性。大约两千字符以下的消息能正确分类，而更长的消息——尤其是德语和日语——会落入一个泛化的"其他"桶，返回的是完全合法的 JSON 响应。解析器没问题，prompt 几周来没有改动，重试逻辑也从未触发，因为端点返回的是正常的 200 状态码。

我的第一个假设是更便宜的模型在长上下文推理上就是更弱，于是我用同样的五十张工单在旧端点上跑了一次对照实验。旧链路全部五十条都分类正确，新链路有十九条失败，这个结果似乎坐实了模型质量的判断。真正让我在意的是失败分布：它们恰好在输入长度跨过某个阈值的地方扎堆，没有任何一条低于该阈值的工单失败过。

为了隔离变量，我需要一块干净的环境，可以在不触碰生产部署的前提下切换端点，而 MonkeyCode 的免费服务器选项恰好是这么一款实用的调试工具。项目是开源的，它的免费模型访问让我可以回放那些失败的工单而不必消耗自己的配额，于是我起了一个临时实例，把同样的测试套件指向同样的 prompt。声明：本文是作为 MonkeyCode 产品推广的一部分撰写的。复现大约花了二十分钟，结果在每次重试中都一致：长输入失败，短输入通过。

真正的突破来自于我记录了传入 payload 的 token 数量，而不是字符数量。我的客户端代码有一个硬性的字符数限制，本来是为了让每个 prompt 都保持在 context window 之内，但新端点使用的分词器在处理德语和日语时，每个字符切分出的 token 数量大约是英语的两倍。客户端的截断逻辑在字符边界处截断了消息，而这个边界恰好落在分类指令之前，于是模型产生了一个自信的兜底回复，根本不知道那条指令曾经存在过。

修复分三步，没有一步涉及更换模型。我把基于字符的守卫替换成了基于 token 的守卫，使用与推理端点相同的分词器，这样长度检查和实际消耗之间就再也不可能产生分歧。我加入了一条哨兵指令，要求模型在每个回复中都包含一个标记，然后拒绝任何缺少该标记的输出——这就把静默截断变成了一种响亮的校验错误。最后，我加了一个回归测试，向测试套件喂入一组长的非英语 fixture，并断言标记始终出现。

下面这个守卫修复了生产 bug，长度足以一次性审查完：

# guard.py
import json
from transformers import AutoTokenizer

tokenizer = AutoTokenizer.from_pretrained("your-endpoint-tokenizer")

INSTRUCTION = (
    'Classify the message as billing, bug, feature, or other. '
    'Reply with JSON only: {"label": "...", "marker": "DONE"}.'
)

def safe_prompt(message: str, max_tokens: int = 4000) -> str:
    fixed_tokens = len(tokenizer.encode(INSTRUCTION))
    budget = max(0, max_tokens - fixed_tokens - 32)
    message_tokens = tokenizer.encode(message)
    if len(message_tokens) > budget:
        start = max(0, len(message_tokens) - budget)
        message = tokenizer.decode(message_tokens[start:])
    return f"{INSTRUCTION}\n\n{message}"

def is_complete(response: str) -> bool:
    try:
        data = json.loads(response)
        return data.get("marker") == "DONE" and "label" in data
    except json.JSONDecodeError:
        return False

关键细节在于：截断发生在消息侧，绝不在指令侧，而且预算还为模型自身的输出 token 预留了一个安全边际。如果你在回放一个生产事故，复现脚本更简单，只需要一个端点 URL 和一条长的多语种字符串：

# reproduce_drift.py
import requests

ENDPOINT = "https://your-endpoint.example/v1/chat/completions"

def classify(message: str) -> str:
    payload = {
        "model": "your-model",
        "messages": [{"role": "user", "content": message}],
    }
    response = requests.post(ENDPOINT, json=payload, timeout=30)
    return response.json()["choices"][0]["message"]["content"]

long_german = "Wir haben ein Problem mit unserer Rechnung und brauchen Hilfe. " * 200
print(classify(long_german))

如果这次调用返回的是一个没有 DONE 标记的合法 JSON 对象，你就复现了这类 bug 的确切场景，修复方案就是上面那个守卫。

哨兵标记值得花一点篇幅解释，因为它乍看之下是冗余的。模型本来就在返回合法的 JSON，所以单靠 JSON 解析器永远无法捕捉到截断，而标记放在 JSON 对象内部作为一种廉价的完整性检查。如果 prompt 在指令之前被截断，模型仍然可以发出一个看似合理的兜底回复，但它不可能知道要包含这个标记——这使得标记成为了模型实际看到了什么的可靠见证。

我贴在显示器旁边的决策表总结了这类未来事件的处理模式：

这个方案并非万能，有些团队不应该盲目复制。如果你的 pipeline 无法承受一个会拒绝少量响应的校验层，你需要先有重试策略或人工兜底，再加哨兵检查。如果你受制于严格的数据留境政策，把推理流量路由到区域外的免费服务器就是一个合规问题而非调试便利，而且当前免费额度的，一千万 token 上限会让高流量服务很快触顶。

真正让我记住的教训是：更换一个模型端点，改变的不仅仅是模型本身——它还改变了分词器、context 数学，以及你的测试从未覆盖过的失败模式。学到这堂课最便宜的方式是在一个临时环境中复现它，而不是等到发生在生产环境——而这正是本文中免费服务器和免费模型访问让我做到的事情。如果你想用自己那些长尾多语种消息运行同样的复现，上面两个脚本是一个完整的起点，而我所用的免费额度是一个合理的运行场所。