一句话定义：长上下文税（Long-Context Tax）是指把大量信息——尤其是无关或弱相关信息——一股脑塞进模型的AI 词典：上下文窗口">上下文窗口（Context Window）时，除了多付词元（token）费用，还要承担注意力被稀释、推理变慢、答案质量下降等隐性代价。
打个比方：这像让新同事回答一个问题，却先把公司十年的邮件、会议记录和群聊打印出来堆在他桌上。纸要钱，桌子会乱，他可能翻半天找不到关键那页，甚至被过时信息带偏。更好的做法是：先问清楚要找哪份合同，只把相关的三页递给他。
原理不复杂。模型读上下文不是“看过就记住”，而是靠注意力机制在词元之间建立关联。上下文越长，计算和缓存开销越大；同时，真正有用的信息会被大量噪声稀释。有研究观察到，关键信息放在长上下文中段时，模型反而更容易忽略，这就是常说的“中间遗忘”（Lost in the Middle）。如果塞进去的内容还互相矛盾，模型就更难判断该信谁。
它和相邻概念容易混：
| 概念 | 关注点 | 一句话区别 |
|---|---|---|
| 上下文窗口 | 能装多少 | 容量上限，不等于有效容量 |
| 长上下文税 | 装太多后的代价 | 成本、延迟、注意力一起恶化 |
| 检索增强生成（RAG） | 该装什么 | 先检索再精选，不是不用上下文 |
| 微调（Fine-tuning） | 改模型参数 | 把稳定知识写进模型，而非每次塞入 |
| 提示词工程（Prompt Engineering） | 怎么说 | 结构化、删减、排序，降低上下文税 |
对从业者，有三点实际意义。第一，把上下文当预算管理：先检索、去重、摘要、排序，只放最相关片段，并给关键信息明确标签和位置。第二，做对照实验：同一问题分别用“全量塞入”和“精选上下文”，比较词元用量、延迟和答案质量，别默认越长越好。第三，分层设计：系统指令、用户问题、证据、对话历史各归其位；历史记录定期压缩，只保留决策和未完成事项。
对普通人，最简单的做法是：别把整本手册、整段聊天记录直接丢给聊天机器人。先给一句背景摘要，再说具体问题，附上最相关的两三段材料。长对话聊久了，主动总结一次，或开个新会话，往往比继续堆历史更清楚。
长上下文是一种能力，不是一种策略。上下文像办公桌，不是仓库。具体模型的价格与窗口能力，以官方页面为准。