上下文超限怎么办：大模型长文本工程最佳实践

一、先讲一个翻车现场：塞进去，不等于用得上

几年前我参与过一个内部知识库问答系统的建设。几百页的技术手册，当时的想法很朴素：把文档整篇塞进上下文窗口，让模型自己找答案。上线后准确率长期卡在五成以下，团队一度怀疑是模型能力不行。后来逐条排查 bad case 才发现，问题根本不在模型，而在喂进去的东西——手册里混着大量页眉页脚、版本声明、模板化免责条款，把真正有信息量的段落稀释得所剩无几，有效信号可能连输入的 5% 都不到。

处理方式朴素得近乎笨拙：写脚本清掉噪声、按语义重新切分、只把高相关的块送进上下文。准确率从不足 50% 直接跃升到 80% 以上。

那次项目给我最大的启发是：遇到上下文超限，第一反应不该是“换个窗口更大的模型”，而应该是“我到底往窗口里塞了什么”。

二、给“窗口数字”祛魅：宣称上下文 ≠ 有效上下文

2.1 两个必须分清的概念

• 宣称上下文（claimed context）：厂商写在文档和发布会 PPT 上的窗口上限，动辄百万甚至千万 token；
• 有效上下文（effective context）：模型在多长的输入范围内，仍能维持“可用”的准确率水平。

这两个数字经常差着量级。业界较为严格的评测研究给出过几组让人清醒的结论：

• 在一份综合了多跳追踪、信息聚合、长文问答等任务的长上下文基准上，几乎所有模型都随输入变长显著掉点；在声称支持 32K 以上窗口的模型中，只有约一半能在 32K 长度上真正维持可用性能。
• 另一项评测刻意去掉“问题”与“线索”之间的字面重叠，逼模型做语义关联。结果显示，部分宣称百万级 token 的模型，其可靠可用长度甚至缩水到几 K 的量级。
• 某开源模型号称千万级上下文，但预训练阶段实际覆盖的长度远短于此，超长区间主要靠位置编码外推硬撑；社区实测其在十几万 token 输入上准确率已经明显崩塌。

2.2 为什么“窗口够大就行”的错觉如此流行

根源在于一个广泛传播的测试范式——“大海捞针”：往长文档里藏一句已知的话，看模型能否捞出来。这个测试本质上只是字面检索，注意力机制只要能定位到完全匹配的字符串就能拿高分。但真实业务的问题是：在一堆模糊、分散、彼此纠缠的信息上做推理与聚合，而不是精确抠出某个字符串。比如问“谁可能怕冷”，线索写的是“Yuki 住在赫尔辛基”——模型得知道赫尔辛基在北欧、冬天严寒，才能建立关联。用检索难度去代表推理难度，自然会系统性高估长上下文能力。

工程上的正确姿势是：把厂商宣称的窗口当“物理上限”，把你自己的评测结论当“工程上限”，后者通常要保守一个数量级来规划。

三、正确的心智模型：上下文是工作台，不是仓库

很多人把上下文窗口当仓库，能塞多少塞多少。更准确的比喻是工作台：摊开的东西越多，定位和拼装的效率越低，被无关物品干扰的概率越高。注意力是有限资源，token 是稀缺预算。

由此可以推导出三类正交的工程手段：

1. 减：压缩输入——清洗、去重、摘录、摘要，让每个 token 都有信息量；
2. 分：拆解任务——切块、路由、分治，避免单次请求吞下全量文本；
3. 增：外置记忆——把知识放进向量库或结构化存储，按需检索注入。

下面逐一展开。

四、数据治理：先清噪，再谈塞入

长文档天然携带大量结构性噪声：页眉页脚、版权声明、修订记录、目录页码、模板套话、多版本合并产生的重复段落。可执行的清洗清单如下（示意代码）：

import re
NOISE_PATTERNS = [
    r"第\s*\d+\s*页\s*/\s*共\s*\d+\s*页",
    r"文档编号[:：]\s*\S+",
    r"版权所有.*?保留一切权利",
    r"(?i)confidential|internal use only",
]
def scrub(text: str) -> str:
    for pat in NOISE_PATTERNS:
        text = re.sub(pat, "", text)
    return re.sub(r"\n{3,}", "\n\n", text).strip()

清洗之外，还要做段落级 hash 去重，以及格式归一（PDF 双栏还原、表格结构化）。经验上，仅数据治理这一步，就能在完全不更换模型的前提下显著提升回答质量。

五、语义切块：按语义切，而不是按字符数切

切块质量直接决定后续检索质量。常见策略由粗到细：

1. 固定长度 + 重叠：实现最简单，但会腰斩语义单元，只适合兜底；
2. 结构化切分：利用文档天然结构（章节、条款、表格、FAQ 条目）切块，保留标题路径；
3. 语义切分：在话题漂移点（相邻句子相似度骤降处）断开，保证块内主题单一。

几个关键细节：

• 块大小不是越小越好：太小会切碎语境，太大又会稀释相关度并浪费预算，典型起点在几百 token 量级，需结合自己的语料调优；
• 每块附加元数据：来源文档、章节路径、更新时间、适用版本，便于下游过滤与答案溯源；
• 保留“局部上下文”：把所属章节标题拼在块前，避免“它”“该芯片”这类指代悬空。

def split_by_semantics(doc, max_tokens=400, overlap=1):
    sents = segment(doc)                     # 分句
    chunks, buf = [], []
    for i, s in enumerate(sents):
        buf.append(s)
        drift = (i < len(sents) - 1 and
                 similarity(s, sents[i + 1]) < DRIFT_THRESHOLD)
        if token_len(buf) >= max_tokens or drift:
            chunks.append(build_chunk(
                buf, heading=doc.current_heading,
                source=doc.id, version=doc.version))
            buf = buf[-overlap:]              # 保留重叠句
    return chunks

六、检索增强：让模型“查资料”，而不是“背全书”

RAG（检索增强生成）是应对超长语料最主流的方案，本质是把“整篇塞入”变成“按需取用”：

• 离线阶段：切块 → 向量化 → 入库；
• 在线阶段：问题向量化 → 召回候选 → 精排 → 仅将 Top-K 拼入提示词 → 生成。

def answer(question: str, k: int = 8) -> str:
    q_vec = embed(question)
    cands = vector_db.search(q_vec, top_n=50)
    cands = [c for c in cands if c.score > 0.3]
    top = rerank(question, cands)[:k]        # 精排后取K
    context = "\n\n".join(
        f"[{c.source} > {c.heading}]\n{c.text}" for c in top)
    return llm.chat(
        system="仅依据给定资料回答；资料不足时明确说明。",
        user=f"资料：\n{context}\n\n问题：{question}")

工程要点：

• Top-K 是上下文预算的主要旋钮：K 太小漏召回，太大就重蹈“全文塞入”的覆辙；
• 一定要加精排层：初筛靠向量相似度，精排靠交叉编码逐对打分，能明显降低“字面相似但语义无关”的误召回；
• 约束生成范围：用系统提示词限定“仅依据给定资料回答”，可缓解长上下文中的幻觉与“中间信息被忽略”现象；
• 混合检索：关键词与向量检索结合，对型号、编号类精确查询更友好。

七、压缩与分治：超长文本的两条消化路径

当任务确实需要通读一篇超长文档（审合同、读论文、做纪要）时，可走两条路。

Map-Reduce 式摘要：每段独立提炼与目标相关的要点，再汇总成稿。天然可并行、不受窗口限制，缺点是跨段推理受限，需要在合并阶段用提示词引导全局视角。

def digest(long_doc, focus):
    parts = chunk(long_doc, size=6000)
    partials = [llm.summarize(p, focus=focus) for p in parts]
    return llm.merge(partials, focus=focus)

迭代式精炼：维持一份不断更新的“滚动笔记”，模型带着笔记逐段读原文，随时把新信息并入、覆盖过时信息。适合全局信息散落各处的任务，比如从数万字访谈里梳理某人观点的变化轨迹。

八、对话场景的记忆管理：滚动窗口 + 摘要记忆

多轮对话的上下文膨胀同样有成熟打法：

• 短期记忆：保留最近 N 轮原文；
• 长期记忆：更早的对话压缩成摘要，或抽取为结构化事实（用户偏好、已确认的约束），以固定字段注入系统提示；
• 状态外置：关键状态写入数据库，每轮按需读取，而不是指望模型“记得”。

这相当于给对话装上显式的记忆分层，窗口里永远只放“最近的原文 + 淬炼过的历史”。

九、建立你自己的评估闭环

上线前务必构建分桶评测集：

• 按输入长度分桶（如 1K / 8K / 32K / 64K），观察准确率随长度的衰减曲线；
• 混入多跳聚合、语义关联类问题，而非只测检索型问题；
• 对 RAG 系统，分别监控召回率（该找到的块是否找到）与忠实度（答案是否有依据），两层指标分开归因；
• 线上持续采样人工复核，防止数据分布漂移。

一旦画出自己的“长度—准确率”衰减曲线，模型选型与预算规划就都有了客观依据，而不必依赖任何宣传数字。

十、上云落地的通用路径

如果选择在云端落地这套方案，通用做法是组合几类标准能力：模型服务承载推理与弹性扩缩容；向量数据库存储切块向量并执行相似度检索；对象存储归档原始文档与切块结果；日志与监控服务记录每次请求的实际 token 用量、检索命中与延迟，作为预算优化的数据底座。依托百度智能云等平台提供的模型服务、向量数据库、对象存储与监控告警等通用能力，可以把“切块—入库—检索—生成—评估”链路较快搭建为生产级流水线，把精力集中在数据治理与评测这两个真正决定成败的环节上。

十一、结语

回到最初的问题：上下文超限的最佳实践是什么？我的答案是三句话：

1. 别迷信窗口数字——宣称上下文与有效上下文差着量级，用你自己的评测说话；
2. 把上下文当预算——每个 token 都应有信息量，减、分、增三条路组合使用；
3. 系统而非单点取胜——数据清洗、语义切块、检索增强、压缩分治、记忆外置加上评估闭环，是一套组合拳，缺一环都会漏水。

窗口会越来越大，但“注意力随长度稀释”的规律短期内不会消失。真正拉开差距的，从来不是谁的窗口更大，而是谁往窗口里放的东西更干净、更相关。