上下文窗口越大越好吗

大模型的上下文窗口越来越大。

GPT-4有128K token，Claude有200K token，Gemini有1M token。

你很开心：终于可以把整本书、整个代码库都塞进去了。

但上下文窗口越大，真的越好吗？

不一定。

上下文窗口的三个成本

成本一：计算成本

上下文越长，注意力机制的计算量越大。

自注意力的计算复杂度是O(n²)，n是上下文长度。

上下文从4K增加到128K，计算量增加约1000倍。

这意味着：更长的推理时间、更高的API费用。

成本二：质量下降

研究发现，大模型在超长上下文中的表现不如短上下文。

原因：Lost in the Middle现象。

当你把关键信息放在上下文的中间位置，大模型更容易忽略它。

大模型对上下文开头和结尾的信息更敏感，中间的信息容易被"遗忘"。

所以把100页文档塞进去，大模型可能只有效利用了前20页和后20页，中间60页的信息被浪费了。

成本三：噪声干扰

上下文越长，包含的无关信息越多。

无关信息会干扰大模型的判断，让它"忘记"真正重要的信息。

你把整个代码库塞进去，大模型可能被大量无关代码干扰，反而找不到你真正关心的那几行代码。

什么时候需要长上下文

场景一：长文档问答

用户问"这份合同的第15条是什么"，你需要把整份合同塞进去。

这种场景长上下文是必要的。

场景二：代码库分析

用户问"这个项目的认证逻辑在哪里"，你需要搜索整个代码库。

但更好的做法是：先用检索找到相关文件，只把相关文件塞进去，而不是把整个代码库都塞进去。

场景三：长对话历史

用户和AI聊了100轮，你想让AI记住所有历史。

但更好的做法是：只保留最近20轮对话，更早的对话用摘要代替。

长上下文的正确用法

方法一：RAG + 长上下文结合

不要把所有文档都塞进上下文。

先用向量检索找到最相关的文档，只把相关文档塞进去。

这样既利用了检索的精准性，又利用了长上下文的容量。

方法二：信息前置或后置

根据"Lost in the Middle"现象，把最重要的信息放在上下文的开头或结尾。

比如：把用户的原始问题放在最后，把检索到的关键文档放在最前，中间放补充信息。

方法三：摘要压缩

对于长对话历史，不要把所有历史都塞进去。

把早期对话压缩成摘要，只保留最近几轮的完整对话。

def build_context(conversation_history, max_tokens=4000):  recent = conversation_history[-10:]  # 5轮 = 10条消息    older = conversation_history[:-10]  summary = summarize(older)  # 用大模型生成摘要    context = summary + recent  return context

一个实际对比

某法律问答系统，用户上传一份200页的合同，问"这份合同的违约条款是什么"。

方案一：把200页全部塞进上下文

效果：回答准确率65%，API费用$2/次。

问题：中间页的信息被忽略，费用高。

方案二：先检索相关条款，只把相关条款塞进上下文

效果：回答准确率92%，API费用$0.1/次。

做法：用向量检索找到"违约"相关的5个条款，只把这5个条款塞进上下文。

方案三：检索 + 长上下文结合

效果：回答准确率95%，API费用$0.3/次。

做法：用向量检索找到相关条款，同时把条款前后的上下文（所在章节）也塞进去，让大模型理解条款的完整语境。

总结

上下文窗口不是越大越好。

越大意味着：更高的成本、更多的噪声、更难有效利用。

正确的做法是：用检索筛选信息、用摘要压缩历史、把重要信息放在开头或结尾。

长上下文是一个工具，不是万能药。

用对场景，它是助力。用错场景，它是负担。

TDD、BDD、ATDD都是什么、有什么区别？（上）

了解更多

Python学习杂记

查看原文：上下文窗口越大越好吗

文章来源：

Python学习杂记

扫码关注公众号