大模型上下文工程实战：长上下文管理与KV Cache优化

大模型上下文工程（Context Engineering）决定了一个模型在真实业务链路中的上限。上下文窗口越放越大，瓶颈早已不是“装得下”，而是检索不到关键内容、上下文相互污染、推理成本随 token 线性上涨。本文围绕长上下文管理、Lost in the Middle 现象与 KV Cache 优化展开，并给出一个可直接复用的上下文封装示例。

大模型上下文工程的三个环节：检索、组装、压缩

上下文工程可以拆成三个环节：检索决定放什么，组装决定怎么放，压缩决定放不下怎么办。多数项目里暴露出来的问题，最终都能归到这三个环节之一。

检索：从向量库、关键词库或业务数据库中召回与当前问题相关的片段。单路检索命中率通常不稳定，混合召回再叠加相关性过滤更稳。
组装：按系统提示词、历史消息、检索片段、当前问题的顺序拼接上下文。核心约束在系统层和用户层各出现一次，模型提取效率明显更高。
压缩：窗口超限时用滑动窗口或结构化摘要折叠旧内容，把 token 预算留给关键信息。

三个环节里，检索决定信息质量，组装决定模型利用效率，压缩决定成本上限。长上下文场景的调优顺序一般是先修组装，再补检索，最后才考虑压缩策略。

Lost in the Middle：长上下文中段信息利用率下降

多项评测都观察到同一现象：模型对输入头部和尾部信息的命中率明显高于中段，处于中间位置的关键事实容易被遗漏。工程上的缓解手段有几类：

核心指令前移，放在系统提示词头部。
关键事实在系统层与用户层重复出现，重复的成本远低于遗漏的代价。
背景性资料放中段，决定流程走向的内容放尾部附近。

长上下文评测时也要注意：如果把关键信息全放在中段，评测结果会明显低于真实水平，测试集设计本身就会引入偏差。

KV Cache 与 Prefix Caching：长上下文推理成本优化

生成阶段每个新 token 都要与历史全部 token 的 Key-Value 向量做注意力计算，KV Cache 随输入长度线性增长，显存和延迟随之上升。工程上常用的优化路线有三条：

Prefix Caching：对相同的系统提示词与固定前缀做缓存复用，多轮对话和批量请求场景收益最明显。
KV Cache 量化：从 FP16 降到 INT8，显存占用大约下降一半，多数业务场景精度损失可接受。
滑动窗口：无状态场景只保留最近 N 轮对话，更早的历史折叠成摘要，token 成本大幅下降。

多轮对话、报表分析这类长会话场景，Prefix Caching 叠加历史折叠，通常能把单次调用成本压到原来的三分之一以下。

Python 示例：可复用的上下文组装与压缩

class ContextManager:
    def __init__(self, system_prompt, max_tokens=32000):
        self.system_prompt = system_prompt
        self.max_tokens = max_tokens
        self.history = []

    def add_message(self, role, content):
        self.history.append({"role": role, "content": content})

    def _estimate(self, text):
        # 中英文混合的粗略估算，上线前替换为真实 tokenizer 计算
        return int(len(text) * 1.3)

    def _fold(self, messages):
        # 把最旧的一批消息折叠成摘要，防止长会话无限膨胀
        items = [m["content"][:40] for m in messages]
        return {"role": "system", "content": "历史摘要：" + "；".join(items)}

    def build(self, query, retrieved=None):
        parts = [{"role": "system", "content": self.system_prompt}]
        budget = self.max_tokens - self._estimate(query)
        if retrieved:
            budget -= self._estimate(str(retrieved))
            parts.append({"role": "user", "content": "检索片段：\n" + str(retrieved)})
        pending = list(self.history)
        while pending and budget > 0:
            msg = pending.pop()
            cost = self._estimate(msg["content"])
            if cost <= budget:
                parts.insert(1, msg)
                budget -= cost
            else:
                parts.insert(1, self._fold(pending))
                break
        parts.append({"role": "user", "content": query})
        return parts

调用方只需维护一个 ContextManager 实例，多轮对话中反复调用 build 即可拿到裁剪后的上下文。接入真实业务时，把 _estimate 替换为官方 tokenizer 的长度计算，_fold 改为摘要模型调用，就能直接上线。

用评测集验证上下文工程收益

上线前固定一组评测集：多轮任务的关键信息命中率、首 token 延迟、单次 token 成本。改造前后各跑一遍，对比结果，上下文工程的收益就一目了然。目标是用最少的 token 拿到最高的任务完成率，而不是把窗口塞满。

原创文章，作者：小编，如若转载，请注明出处：https://www.yunthe.com/da-mo-xing-shang-xia-wen-gong-cheng-shi-zhan-zhang-shang/

上下文工程为什么比Prompt工程更值得关注

大模型开发中，上下文工程（Context Engineering）正在成为比Prompt工程更高维度的技术方向。当模型支持的上下文窗口从4K扩展到128K乃至百万Token级别，核心挑战不再是”怎么写提示词”，而是”在有限窗口内放什么内容、按什么顺序放、如何压缩冗余信息”。上下文工程直接决定大模型的推理质量、成本和延迟，尤其在AI工具链和智能对话系统场景中，无效Token的累积会显著拉低响应准确率。

上下文窗口的Token管理涉及三个层面：输入侧的上下文裁剪与优先级排序、处理过程中的上下文压缩与摘要、输出侧的上下文窗口溢出处理。实际工程中，很多团队只关注Prompt模板设计，却忽略了系统消息、对话历史、工具调用结果、检索增强内容叠加后的Token总量控制。

Token预算分配与上下文优先级模型

在智能对话系统中，一个完整的上下文由多个部分组成：系统指令、用户画像、对话历史、检索文档、工具调用结果。每个部分对模型推理的贡献度不同，需要建立Token预算分配机制。

以下是一个上下文Token预算分配的Python实现：

import tiktoken

class ContextManager:
    def __init__(self, model_name, max_tokens=128000):
        self.encoder = tiktoken.encoding_for_model(model_name)
        self.max_tokens = max_tokens
        self.budget = {
            'system': 2000,
            'profile': 1000,
            'history': 8000,
            'retrieval': 60000,
            'tools': 3000,
            'response': 15000,
            'buffer': 5000
        }

    def count_tokens(self, text):
        return len(self.encoder.encode(text))

    def allocate(self, context_parts):
        # 按优先级分配Token预算，超出部分截断
        priority = ['system', 'profile', 'tools', 'history', 'retrieval']
        allocated = {}
        remaining = self.max_tokens - self.budget['response'] - self.budget['buffer']

        for key in priority:
            budget = min(self.budget[key], remaining)
            text = context_parts.get(key, '')
            token_count = self.count_tokens(text)

            if token_count <= budget:
                allocated[key] = text
                remaining -= token_count
            else:
                if key == 'history':
                    allocated[key] = self._truncate_history(text, budget)
                elif key == 'retrieval':
                    allocated[key] = self._truncate_retrieval(text, budget)
                else:
                    allocated[key] = self._truncate_tail(text, budget)
                remaining -= budget

        return allocated

    def _truncate_history(self, text, budget):
        # 对话历史截断：保留最近的对话轮次
        messages = text.split('\n---\n')
        result = []
        token_sum = 0
        for msg in reversed(messages):
            tokens = self.count_tokens(msg)
            if token_sum + tokens > budget:
                break
            result.insert(0, msg)
            token_sum += tokens
        return '\n---\n'.join(result)

    def _truncate_retrieval(self, text, budget):
        # 检索文档截断：按相关性分数保留高分片段
        chunks = text.split('\n[CHUNK]\n')
        result = []
        token_sum = 0
        for chunk in chunks:
            tokens = self.count_tokens(chunk)
            if token_sum + tokens > budget:
                break
            result.append(chunk)
            token_sum += tokens
        return '\n[CHUNK]\n'.join(result)

    def _truncate_tail(self, text, budget):
        # 尾部截断：保留前N个Token
        tokens = self.encoder.encode(text)
        truncated = tokens[:budget]
        return self.encoder.decode(truncated)

这个实现的核心思路是给不同上下文来源设定Token预算上限，按优先级分配。系统指令和用户画像优先级最高，因为它们影响全局行为；检索文档预算最大但优先级最低，因为可以被裁剪而不影响基础对话能力。

对话历史压缩：滑动窗口与摘要链

长对话场景中，对话历史会持续增长。简单的滑动窗口截断会丢失早期关键信息。更有效的方案是摘要链（Summary Chain）：将超出窗口的历史对话压缩为摘要，再将摘要纳入上下文。

class HistoryCompressor:
    def __init__(self, llm_client, max_turns=10, summary_threshold=5):
        self.llm = llm_client
        self.max_turns = max_turns
        self.summary_threshold = summary_threshold

    def compress(self, messages):
        # 将旧对话轮次压缩为摘要
        if len(messages) <= self.max_turns:
            return messages

        recent = messages[-self.max_turns:]
        old = messages[:-self.max_turns]

        summaries = []
        batch_size = self.summary_threshold
        for i in range(0, len(old), batch_size):
            batch = old[i:i+batch_size]
            summary = self._summarize_batch(batch)
            summaries.append(summary)

        compressed = [
            {'role': 'system', 'content': '以下是之前对话的摘要：\n' + '\n'.join(summaries)},
        ] + recent
        return compressed

    def _summarize_batch(self, batch):
        # 调用模型生成对话摘要
        transcript = '\n'.join([f'{m["role"]}: {m["content"]}' for m in batch])
        prompt = f'请用2-3句话概括以下对话的关键信息，保留重要的事实和决策：\n{transcript}'
        return self.llm.complete(prompt)

摘要链的代价是额外的LLM调用开销。工程上需要权衡：对话轮次较少时用滑动窗口即可，超过20轮的长对话场景才有必要引入摘要压缩。一个实践经验是将摘要阈值设定在对话历史Token占用超过总预算30%时触发。

检索增强生成中的上下文注入策略

RAG场景下，检索返回的文档片段如何注入上下文直接影响模型回答质量。常见做法是将所有片段拼接后放在系统提示中，但更精细的做法是按片段相关性分数动态调整注入位置和数量。

def build_rag_context(query, retriever, max_chunks=5, min_score=0.65):
    # 构建RAG上下文，按分数过滤和排序
    results = retriever.search(query, top_k=max_chunks * 2)

    filtered = [r for r in results if r['score'] >= min_score]
    selected = filtered[:max_chunks]

    context_parts = []
    for idx, chunk in enumerate(selected):
        context_parts.append(
            f'[片段{idx+1} | 相关度: {chunk["score"]:.2f}]\n{chunk["text"]}'
        )

    return '\n\n'.join(context_parts)

片段间的分隔符和编号不是装饰，而是帮助模型区分不同信息来源。实测中，使用明确分隔标记的上下文注入方式，比纯文本拼接的回答准确率提升约15%。

上下文溢出的降级处理

当所有压缩策略都无法将Token降到窗口限制以内时，需要设计降级策略。优先保留系统指令和当前用户输入，逐步丢弃历史对话和检索文档，确保模型至少能基于当前输入给出基本响应。在生产环境中，应该对上下文Token总量做实时监控，超过80%阈值时触发告警，避免因窗口溢出导致服务异常。Prompt工程中常用的思维链（CoT）也会占用上下文空间，在设计时需要将推理链长度纳入Token预算考量。自然语言处理领域的最新研究也表明，上下文中信息的排列顺序对模型理解效果有显著影响，将最相关的信息放在上下文的开头和结尾位置（”中间遗忘”效应），可以进一步提升模型对关键信息的利用率。