VeriLoop E2 输出跑偏时，最容易走错的一步是先怀疑模型能力或去改提示词。更省时间的做法是把两件事拆开验证：送入模型的文本是否完整，以及量化精度差异能否解释看到的现象。这两件事的验证顺序不能颠倒——如果输入已经被截断，再换精度档也只是在残缺文本上对比，得到的结论没有意义；如果各精度档在同一份完整输入上表现一致地跑偏，那把力气花在上下文长度上同样是空转。下面给出的是一套可落地的顺序：先固定样本，再确认 token 与截断位置，再只改精度档重跑，最后用缩短上下文的方式做交叉验证。

排查顺序建议为：先完整落盘一次失败样本的输入输出与生成参数，再从请求日志或框架输出读出实际 token 数与截断位置，然后在输入完全不变的前提下只切换量化精度档重跑。缩短上下文后输出恢复正常，优先按截断或信息丢失处理；各精度档在同一输入上稳定地同样跑偏，则量化多半不是主因。所有判断都需要日志与可复现样本支撑，缺这两样时不宜下结论，也不宜把单次结果当作模型特性。

把一次跑偏的输入输出完整记下来

不可复现的跑偏只能靠猜。建议在发现问题的那一次就落盘，而不是事后凭印象重建。记录项至少要覆盖原始输入、模板渲染后真正送入模型的文本、完整输出、结束原因和全部生成参数。UI 上展示的输出常常已经被折叠或截断，记录时要取接口返回的完整字段，避免把展示层的截断误判成模型截断。

{
  "case_id": "e2-loop-sample-01",
  "model": "VeriLoop E2",
  "quant_profile": "int8",
  "template_version": "tpl-v3",
  "system_prompt_version": "sys-v2",
  "raw_input": "用户原始输入，保留完整原文，不做裁剪",
  "rendered_prompt": "模板渲染后、送入模型前的完整文本",
  "gen_params": {"max_tokens": 512, "temperature": 0, "top_p": 1, "stop": ["\n\n\n"], "seed": 12345},
  "raw_output": "接口返回的完整输出，包含被截断或重复的部分",
  "finish_reason": "length",
  "prompt_tokens": null,
  "completion_tokens": null
}

本次对照组里需要固定的参数：temperature 置 0（或固定 seed）、top_p、max_tokens、stop 序列、系统提示词版本、模板版本、是否开启工具调用、是否拼接检索结果。只有量化档允许变化。如果框架不支持固定 seed，就把同一配置重跑若干次，先确认该配置本身是否稳定输出——不稳定的话，后续逐字对比的意义有限。

确认实际送进模型的文本被截到哪里

上下文超限是最容易被忽略、又最容易被误诊成“模型变笨”的原因。常见来源包括：模板本身插入的长系统提示词、多轮历史累积、检索片段拼接、以及 tokenizer 与线上版本不一致导致的计数偏差。确认方法是双向的——既看请求日志里的实际 token 数，也在本地用同一份 tokenizer 对 rendered_prompt 计数，两者应当接近；差异过大说明线上还有额外拼接。

# 通用骨架，替换为线上实际使用的 tokenizer 与窗口配置
from tokenizers import Tokenizer
tok = Tokenizer.from_file("path/to/tokenizer.json")
ids = tok.encode(rendered_prompt).ids
print("rendered_tokens", len(ids))
print("window", MAX_CTX, "overflow", max(0, len(ids) - MAX_CTX))
# 按窗口截断后反解，看原文实际停在哪一段
print(tok.decode(ids[:MAX_CTX])[-200:])

判定口径建议：finish_reason 为 length 且本地计数超过窗口，基本可归为截断类；反解出的尾部文本若停在句子中间或关键字段之前，说明被截掉的正是回答所需的信息。反过来，如果 token 数远低于窗口、finish_reason 为 stop，就没有理由继续在上下文长度上排查。

保持输入不变，只换量化的数值精度档

这一步的前提是 rendered_prompt 逐字节一致，只改量化配置，例如 quant_profile 从 int8 换到 fp16，或换用不同的量化权重文件。重跑后不要只看“对不对”，而要把差异写具体：输出结构是否崩坏、关键字段是否缺失、数值是否漂移、是否出现重复循环、是否答非所问、长度是否异常收敛。这些描述能帮助判断差异是否落在低精度可以解释的范围内。

这里不写“某档精度准确率更高”之类的结论，因为没有针对你环境的样本就不成立。可以确定的只有方法：两档在同一输入上差异明显，且高精度档更接近预期，量化是需要继续追的方向；两档输出几乎一致地跑偏，则应回到提示词、检索内容或任务定义上找原因。

缩短上下文但保留同一个问题

缩短上下文的目的不是让模型“轻松一点”，而是做一次控制变量的对照：把无关的历史对话、示例、检索片段删掉，但保留问题本身依赖的那段材料，然后重跑同一问句。如果缩短后输出恢复正常，说明原长度下的信息组织或截断丢了东西；如果缩短后依旧跑偏，量化和解码相关的嫌疑上升。

操作时先标出“问题依赖哪一段”：答案所需的事实、约束条件、字段定义。删减只能删外围内容。若问题依赖的材料本身太长、无法在不删关键信息的前提下压缩，那这一组对照就做不干净，应如实记录“未能有效分离”，不要勉强下结论。

给出两类原因的各自复核方式

截断类问题的复核动作：调大上下文窗口或减少历史轮数后，用同一 case_id 重跑；打印 rendered_prompt 的实际 token 数与窗口上限；检查模板与系统提示词是否占用了预期之外的份额；确认 tokenizer 版本与线上一致；对超长输入改为分段送入，并记录每段对应的原文位置。

精度类问题的复核动作：固定 rendered_prompt 与全部生成参数，在同一档位上重复跑若干次，确认该档位自身是否稳定；再切换到相邻精度档重跑同一输入，逐项填写上面的对照表；对差异明显的样本，保留两档完整输出作为回归样例；如果只有个别样本受影响，先扩充同类样本再判断，避免用单例推广。

两类动作的共同要求是留痕：每次重跑都写回 case_id、档位、token 数、finish_reason 和完整输出。做到这一步，下一次遇到 VeriLoop E2 输出跑偏，就能直接用记录判断该往哪个方向查，而不是重新从“是不是模型不行”开始猜。