AI 聊久了就「变傻」？你可能不是模型变笨了，而是上下文塞太满——arXiv 2606.20047 找到了更聪明的「裁剪」办法
- 关联论文：2606.20047
你有没有这种感觉：
用 ChatGPT/Claude/Cursor 聊了一个多小时之后，AI 突然开始「胡言乱语」。 你刚才明明告诉它「我叫小明，住在北京」，它现在却问你「您贵姓？」。 或者你让它查的资料，它说「我看不到这条信息」——明明五分钟前还在对话里。
你以为这是「AI 变笨了」。
其实大概率是：上下文窗口被塞满了，AI 框架悄悄把你的「小明」「北京」这两条信息「裁掉」了——因为位置靠前，太「旧」了。
这是 2026 年所有长跑 AI Agent 都在踩的同一个坑。arXiv:2606.20047（PACMS）给出了一个听起来反直觉但工程上站得住的修法：
把上下文管理从「按时间先后裁最近 N 条」升级成「按问题相关性挑最该留的」——在 LongMemEval 的 100 题样本上，对比 LangChain 的生产级 MMR 算法，证据轮召回率打平、端到端问答准确率领先 8 到 12 个百分点。
这件事为什么重要？因为它把「AI 聊久了就忘」这件事，从「不可避免」升级为「可工程化解决」。
为什么这件事和每个人有关
过去两年，所有做 AI Agent 的公司——客服机器人、编程助手、个人助理、长会话工具——都在烧同一个钱：上下文窗口。
GPT-4 Turbo 128K、Claude 200K、Gemini 1M——这些数字看着很大，但实际可用的永远只有 70-80%，剩下的得留给系统消息、工具输出、未来要生成的回答。
更麻烦的是：AI 真正干活的时候，上下文同时从三个方向涌进来——
- 对话轮次：你问 AI 答的历史 turn
- 持久记忆：从长期存储里召回来的事实、偏好
- 工具输出：文件读取、搜索结果、API 响应——单条就能塞 5000 个 token
一旦总 token 超预算，框架就得做选择。今天几乎所有 Agent 框架（LangChain、LlamaIndex、OpenHands 等）的默认策略是 「按时间顺序只留最近的 N 条」（recency truncation）——也就是把老信息直接裁掉。
这套默认策略在两类场景必然失败：
- 场景 A：你在对话开头告诉 AI「我叫小明」，聊了 30 轮后你问「我叫什么名字」——AI 说不知道。因为「我叫小明」这条信息被裁掉了。
- 场景 B：AI 刚刚搜索了一个 5000 token 的结果，把「我叫什么」「住哪里」「养了只猫」这 3 条关键事实挤掉了。因为工具输出「更新」，更「近」，但话题完全不相关。
这就是「上下文污染」——你以为 AI 记得，其实它把关键信息当垃圾扔了。
2606.20047 的核心洞察：这不是「上下文压缩」能解决的问题，也不是「RAG 召回」能解决的问题——这是「上下文装配」层面的问题，得专门做选择器。
它到底做了什么
一、把「上下文装配」单独拎出来做
传统思路：
对话太长？ → 压缩（LLMLingua、摘要）
找不到老信息？ → RAG 召回（从向量库拉相关文档）
2606.20047 说：这两条路都不对。
- 压缩是 query-blind（不看用户在问什么），还会改写原文，有损；
- RAG 召回管的是「外部文档进 prompt」，不管「已经在 prompt 池里的候选怎么挑」。
PACMS 把「选择」这一步单独拎出来：「留谁」这件事由专门的次模选择器做，不让压缩或召回背锅。
二、用「次模选择」挑最有用的几条
技术上，PACMS 把上下文候选池（所有 memory、对话轮、工具输出）当成一个「候选集合」，把当前用户问题（query）当成「需求」，把 token 预算当成「背包容量」——
这是一个经典的「次模选择 + 背包约束」优化问题：在固定 token 预算下，挑出对当前问题「覆盖最广」的候选集合。
具体目标函数叫 facility-location——直觉上就是「在候选池里挑若干个「设施」，让所有「需求点」（即和当前问题相关的候选）都被覆盖」。
为啥这个目标比传统的「MMR（最大边际相关性）」好？三点差异：
| 维度 | 传统 MMR | PACMS |
|---|---|---|
| 冗余定义 | 看已选集合的最大相似 | 看候选池的全集覆盖 |
| 相关性加权 | 纯相似，relevance-blind | 权重含「和问题相关」，只算覆盖相关区域 |
| 理论保证 | 启发式，无近似界 | monotone submodular，有常数因子近似保证 |
最后一项最关键：有理论保证的选择器，让 QA 系统的延迟/质量预算有了数学依据，而不是「试试看」。
三、实验结果：反直觉但站得住
关键实验数据（LongMemEval 100 题，45% token 预算）：
证据轮召回率（evidence recall）： - top-k cosine：93.3% - PACMS：90.9% - LangChain MMR：89.5% - last-k（按时间裁）：接近 0%
端到端问答准确率（QA accuracy）： - PACMS（GPT-5-mini）：52.0% - top-k：50.0% - LangChain MMR：44.0% - last-k：44.0%
关键反直觉发现：
PACMS 在「证据召回率」上落后 top-k（0.909 vs 0.933），但在「端到端 QA 准确率」上反超（+2 个百分点）；PACMS 在「召回」上略赢 MMR（0.909 vs 0.895），但在「QA 准确率」上大幅领先（+8 到 +12 个百分点）。
为什么？这是 PACMS 最反直觉也最有价值的发现：
- 召回率高 ≠ 答得好。top-k 把「最相似的 10 条」全塞进去，但里面可能全是同一个意思的重复内容（冗余）。AI 看完还是没答案。
- PACMS 的 facility-location 目标保留了「更多样的相关覆盖」——即使个别证据没进 prompt，被覆盖区域里仍有可用线索。AI 自己能推理、能拼、能补。
- MMR 的成对去重保留了「更少但更不相似」——但因为不去覆盖全相关区域，关键线索整片丢失。
含义：衡量上下文选择的指标应该是「QA 准确率」，不是「召回率」。这条结论对所有做 RAG / Agent 记忆的人都重要。
四、强力 reader 上差距放大
实验还发现：底座模型越强，PACMS 的领先优势越大。
- GPT-5.4-mini 上 PACMS 对 MMR 领先 +12；
- GPT-5-mini 上只领先 +8。
解释：强模型能从「覆盖广」中自己拼出答案——它会定位、会合成、会推理；弱模型反而需要 top-k 的「直接命中」。这是选型时的一条工程经验：模型越强，越值得上 PACMS 类覆盖式选择器。
五、优雅降级，工业友好
PACMS 设计成一个可插拔的 Python 服务（FastAPI + Ollama 本地 embedding），暴露两个端点：
/select：生产用，返回挑出来的候选/select_debug：演示用，实时回显「留了哪些 / 丢了哪些 / token 用量」
关键设计：当 PACMS 服务挂了，Agent 框架自动回退到 recency 截断——绝不影响整体可用性。
这条「优雅降级」让 PACMS 可以开关式上线：先开，再观察，再决定要不要全量替换默认。对生产环境极重要。
为什么这篇论文值得大众关注
第一，它给「AI 聊久了就忘」一个真正的修法。
过去两年的默认解释是「上下文窗口不够大」「模型记忆不行」——但 2606.20047 说：多数时候「忘」不是窗口不够，是「裁剪策略」不对。这是个工程层面的认识升级。
第二，它把「召回」和「选择」显式分开。
RAG 召回管「外部文档进入 prompt」，PACMS 管「已经在池里的留谁」——两者不能合并，必须显式分层。这条架构边界值得每个 Agent 框架设计者记住。
第三，它提出了「QA 而不是 recall 作为生产指标」。
传统 RAG 评测看 recall@K，但 2606.20047 实验证明：recall 高 ≠ 答得好。所有 RAG / 记忆系统的离线/在线评估，都应该把 QA 准确率放第一位，recall 退为辅助诊断。
第四，它有理论保证，不是「试试看」。
facility-location 是经典的次模优化问题，贪心算法有 (1 - 1/e) ≈ 63% 的近似比——这是数学保证。MMR 是启发式，没有界。对工业落地，「可证明的近似」比「看起来不错」更值。
它也有做不到的事
1. 100 题样本规模偏小
实验只在 LongMemEval 的 100 题均匀采样上做。原文承认这是 compute budget 限制（约 1600 次 API 调用）。统计功效受限。
2. 仅测了 GPT-5 系 reader
两个底座模型都来自同一家族（GPT-5-mini / GPT-5.4-mini），且都是偏弱推理档。Claude / Gemini / Llama 等其他模型家族上的相对排名未明确。
3. embedding 模型单一
只测了 nomic-embed-text（一个开源 embedding）。换 embedding（如 bge、e5）可能导致 PACMS vs MMR 的胜负反转。embedding 选型本身就是另一个变量。
4. 没测多模态候选
候选都是文本。多模态 Agent（图像、音频）的工具输出没被建模——这条路要走还得另外搭。
5. 数学门槛不低
次模选择、facility-location、CELF 加速——这些概念对纯应用背景的开发者较陡。但结论可以直接用：知道 PACMS 在工程上比 MMR 强、理论上有近似保证，就够了。
一句话总结
2606.20047（PACMS）把 AI Agent 的上下文管理从「按时间裁最近 N 条」升级成「按问题相关性挑最该留的」——基于次模选择 + facility-location 目标，在 LongMemEval 上比 LangChain MMR 端到端准确率领先 8-12 个百分点。
这件事的真正含义不是「某个算法变强了」，而是「AI 聊久了就忘」这件事，第一次有了可工程化、可理论保证的解法——对客服机器人、编程助手、长会话产品都是直接利好。
下次你遇到 AI 「突然变笨」时，可以问一句：
「上下文是被「裁掉」了，还是被「压扁」了？你的选择器是基于相关性还是基于时间？」
📎 论文 ID：2606.20047
三个标题变体
- AI 聊久了就「变傻」？你可能不是模型变笨了，而是上下文塞太满——arXiv 2606.20047 找到了更聪明的「裁剪」办法
- 别再用「保留最近 N 条」管理 AI 上下文了：次模选择 + facility-location 让 QA 准确率提升 12 个百分点
- 召回率高 ≠ 答得好：arXiv 2606.20047 揭示了一个反直觉但站得住的 Agent 上下文管理原则
小红书风格卡片文案（可直接发布）
🤖 AI 聊久了突然「变笨」？真相可能不是它变笨了 🤖
你是不是也遇到过——
用 ChatGPT/Claude/Cursor 聊了 1 小时之后 💬 AI 开始「胡言乱语」 你刚才明明告诉它「我叫小明，住在北京」 🏙️ 它现在却问「您贵姓？」😵
你以为这是 AI 变笨了
其实大概率是 ——
✨ 上下文窗口被塞满了 ✨ AI 框架悄悄把你的「小明」「北京」裁掉了 ✨ 因为位置靠前，太「旧」了
这是 2026 年所有长跑 AI Agent 都在踩的同一个坑 🕳️
几乎所有 Agent 框架的默认策略 LangChain、LlamaIndex、OpenHands 等 都是 「按时间顺序只留最近 N 条」 ⏰
这套策略必然失败的两个场景 👇
❌ 场景 A：开场说「我叫小明」，30 轮后 AI 不记得 ❌ 场景 B：工具输出挤掉关键事实，因为工具更新，但话题不相关
arXiv 2606.20047（PACMS）给了一个反直觉但站得住的修法 🛠️
✅ 把上下文管理从「按时间裁」升级成「按相关性挑」 ✅ 用 facility-location 次模选择，挑「覆盖最广」的候选 ✅ LongMemEval 实验：vs LangChain MMR · 召回率打平 · QA 准确率领先 8-12 个百分点 📈
一个反直觉的发现 🔍 召回率高 ≠ 答得好 top-k 召回率 93.3%，QA 准确率只有 50% PACMS 召回率 90.9%，QA 准确率 52% 该看 QA 而不是 recall
对工业落地最重要的设计 🔧 优雅降级——PACMS 服务挂了 自动回退到「按时间裁」 不影响 Agent 整体可用性 ✨
📎 论文 ID：2606.20047 💬 评论区聊聊：你的 AI 助理有没有突然「失忆」过？你觉得是窗口不够大，还是裁剪策略不对？