长上下文应用如何避免塞入无关历史

长上下文应用最容易踩的坑，不是模型窗口不够大，而是把“可能有用”的历史全部塞进请求。这样做既增加 token 成本，也会让旧的闲聊、重复检索片段和过期工具回执挤掉当前问题真正需要的内容。

官方地址：https://huggingface.co/docs/transformers/

更稳妥的做法是把上下文拆成近期消息、滚动摘要和按需检索三层，再给每层设预算。当前问题、系统约束和未完成任务优先保留；远期历史只有在摘要或检索证明相关时才进入最终 prompt。

先把历史分成三层，而不是整段拼接

可以把一次请求看成一个有限的上下文预算。第一层是最近几轮消息，保留当前指代、用户刚刚确认的约束和未完成任务；第二层是滚动摘要，只保留稳定事实、决定和待办；第三层是按需检索的候选片段，只在当前问题确实需要时加入。

三层的职责不能混在一起：摘要不是全文备份，检索结果也不是永久记忆。每次摘要更新都应标出“已确认事实、用户偏好、未解决问题和来源”，把闲聊、重复错误和已完成任务排除掉。

用 token 预算决定哪些历史能进入请求

不要用“保留最近 N 个字符”代替 token 预算。Hugging Face Transformers 的 chat template 会把带有 role 和 content 的消息转换成模型需要的 token 序列；不同模型的控制 token 和分词结果可能不同，所以计数应尽量使用实际要调用的 tokenizer。

from transformers import AutoTokenizer

# 用目标模型的 tokenizer 计数，避免把字符数当成 token 数。
tokenizer = AutoTokenizer.from_pretrained("你的模型目录")

def fit_context(system_prompt, question, recent, summary, retrieved, budget):
    # 固定项优先：系统约束和当前问题不能被历史挤掉。
    selected = [{"role": "system", "content": system_prompt}]
    selected.append({"role": "user", "content": question})

    # 摘要和近期消息按优先级补入，检索片段只取当前问题需要的部分。
    candidates = [summary] + list(reversed(recent)) + retrieved
    for item in candidates:
        trial = selected + [{"role": "context", "content": item}]
        token_ids = tokenizer.apply_chat_template(
            trial, tokenize=True, add_generation_prompt=True
        )
        # 超预算就跳过这一项，继续尝试更小的候选。
        if len(token_ids) 

示例的重点不是把所有候选都放入，而是在每次加入前重新计算完整消息序列。实际项目还要为模型输出预留空间，例如把窗口预算拆成“输入上限”和“输出上限”，避免输入刚好填满后没有生成余量。

检索前去重，避免摘要和原文互相占位

检索可以补充长期知识，但不应把相同事实以三种形式重复送入模型。一个实用顺序是：先用当前问题生成查询，再过滤低相关候选；随后用文档 ID、时间范围或文本指纹去重；最后检查候选是否已经被滚动摘要覆盖。只有能回答当前问题、解释冲突或补足缺口的片段才值得消耗预算。

如果使用 Transformers 的 RAG 相关能力，文档通常可以按标题和正文内容组织后传给模板。工程上仍需自己决定召回数量、相关性阈值和冲突处理方式：相似度高不等于事实一定正确，最新来源也不必然适合当前任务。

把压缩过程当成可追踪的产品能力

上下文压缩不是一次性的清理脚本，而是用户体验的一部分。建议为每次请求记录四类结果：保留了哪些近期消息、摘要覆盖了哪些事实、加入了哪些检索片段、哪些内容因预算被舍弃。日志里不要保存不必要的敏感原文，可以只存消息 ID、来源、分数、token 数和淘汰原因。

还要防止把不可信文本当成系统指令。检索内容、历史消息和工具回执都应带来源边界，明确告诉模型哪些是资料、哪些是用户要求、哪些只是待核实信息。这样做不能替代权限控制，却能减少旧消息或外部文档改变当前任务边界的机会。

常见问题

上下文窗口越大，是否就不需要摘要？

不需要。窗口变大只提高容量，不会自动提高相关性；无关历史仍然会增加成本、干扰注意力并放大冲突信息。

摘要应该多久更新一次？

以事件和预算触发更稳妥：完成一个阶段、用户确认新约束，或历史占到预算阈值时更新，而不是机械地每轮都摘要。

检索结果要保留多少条？

没有固定数字。先按问题类型设置小上限，再用相关性、来源可信度、时效性和剩余 token 共同筛选，并观察被淘汰原因。