如果你做过 RAG，大概率遇到过两个诡异的场景：回答问题需要的信息明明都在知识库里，检索也命中了，模型就是答错；prompt 里写得清清楚楚的规则，模型偶尔就是不听。多数人的第一反应是模型不够聪明，或者上下文不够长。这周在技术圈重新刷屏的一份实验报告，结论恰恰相反。
18 个大模型，全都会"越喂越笨"
2025 年 7 月，ChromaDB 背后的公司 Chroma 发布了一份技术报告，测了当时包括 GPT-4.1、Claude 4、Gemini 2.5、Qwen3 在内的 18 个主流大模型。结论只有一句话：所有模型都会随着输入变长而变蠢，一个不漏。知乎注意，这不是上下文窗口超限导致的报错，而是窗口远没满的时候，模型就已经开始犯糊涂，他们把这种现象命名为 Context Rot——上下文退化。
有人会说，主流模型在"大海捞针"（Needle in a Haystack）这类长文本测试上不都是接近满分吗？Chroma 指出这个测试有个致命问题：它只考"字面匹配"。知乎问题问"神奇的数字是多少"，文本里恰好写着"神奇的数字是 42"，靠关键词匹配就能拿满分。可真实业务里，用户问"这个方案有什么风险"，文档里写的可能是"潜在的不确定因素包括……"，语义对得上，字面对不上。所以 Chroma 换了个测法：让任务难度保持不变，只改变输入长度，任务再简单不过，如果性能还在下降，那就只能归因于长度本身。
三个反常识的实验结论
第一个结论：用户的提问和文档的措辞越不像，长上下文退化得越快。报告用 5 个 embedding 模型计算问答对的语义相似度再分组对比，相似度越低，掉得越狠。真实用户提问很少照着文档原文说，这一条几乎命中所有真实场景。
第二个结论：干扰项是毒药，无关内容反而不是。离正确答案很远的无关内容，模型一开始就不会分配注意力，影响有限；真正可怕的是"相似但不对"的内容，它们在语义空间里离正确答案很近，会抢走模型的注意力。检索系统召回的相关文档越多，干扰项越多，模型反而越糊涂。知乎换句话说，“召回率高"不等于"答得对”，往知识库里堆满话题相近但内容不同的文档，等于给模型埋雷。
第三个结论最反直觉：把文档打乱，模型表现反而更好。直觉上结构清晰的文章应该更好处理，实验结果反过来：打乱版的上下文，模型表现更好，而且这个结论在全部 18 个模型、所有测试组合上都一致。知乎一个可能的解释是：有逻辑结构的文本会"吸走"模型的注意力，让它顺着论证思路走，把注意力预算花在理解上下文上；打乱的文本没有强势主线，模型反而更专注于找答案。报告里还有一个更简单的实验：给模型一串重复的单词让它原样复述，零推理的"抄写"任务，输入越长照样抄得越差——说明这是模型处理长输入的结构性缺陷，不是推理能力问题。
ChromaDB 用户该改的五件事
这份报告值得在 ChromaDB 的兴趣圈里聊，是因为每条结论都能直接映射到你每天都在做的操作。
一，top-k 别越大越好。不少教程默认检索 10 条、20 条全塞进 prompt，召回越多，混进"相似但不对"干扰项的概率越大。宁可召回少一点，再配一个 rerank 精排模型，也别靠堆数量赌运气。
二，元数据过滤不只是筛分类，是用来排干扰的。检索前先用时间、来源、文档类型这些 metadata 把范围圈小，让"相似但不对"的内容压根进不了候选池，比检索之后再补救有效得多。
三，chunk 按信息密度切，别按固定长度切。报告里"答案被埋在高相似上下文里最难找"的结论提醒我们：结论和它必要的上下文尽量放进同一个 chunk，别让答案孤零零地漂在一堆语义相近的段落中间。
四，中文场景别用默认 embedding。有人通过源码跟踪确认，ChromaDB 的默认 embedding 是 all-MiniLM-L6-v2。知乎这是个英文为主的小模型，中文语义相似度判断偏弱，而且不少 AI 编程助手连这个模型名都会报错。中文文档请显式指定 bge-m3 这类模型——你召回的"问答相似度"准不准，全看 embedding 的水平。
五，检索结果进 prompt 之前，先做一轮裁剪。只保留直接支撑回答的段落，别把整个检索结果原样灌进去。
Chroma 自己在做什么
看 Chroma 今年的动作，方向已经很明确：它不想只当一家"存向量的数据库公司"。今年 3 月底，Chroma 发布了 Context-1，一个专为代理搜索任务设计的开源权重模型，拥有 200 亿参数。哔哩哔哩更值得注意的是它的定位：不是又一个 embedding 模型，而是把 RAG 的检索层做成了会拆问题、会连续搜索、会主动清理上下文的搜索子代理。哔哩哔哩说白了，Chroma 在把 Context Rot 的教训产品化：既然塞得多就变蠢，那就做一个会"少而精"检索、主动给上下文做减法的东西。向量数据库公司的重心，正在从"怎么存"转向"怎么检"。
再看这周的 Agent 记忆赛道就更清楚了：Mem0 融了 B 轮，腾讯开源了 Agent Memory，MemOS 提出"记忆操作系统"，深圳的 MemoraX 四个月连融三轮。知乎这些记忆系统的存储底座，大多还是 ChromaDB 这类向量数据库。
而下一轮竞争的胜负手，其实早就写在 Chroma 的报告里：LongMemEval 长对话记忆测试对比了"只注入聚焦召回的内容"和"注入全部长上下文"两种做法，前者的准确率大幅领先。绝大多数记忆系统都在解决"记住"，真正难的是"该想起什么"。知乎本周有一篇实践文章的做法值得参考：记忆不是「全记得」，是「该记得的时候记得、不该记的时候别捣乱」。知乎稳定事实常驻注入，长流程只放标题索引、按需拉全文，经验型记忆命中才注入。如果你正准备用 ChromaDB 给 Agent 做记忆，可以直接按这个架构来；另外提一句，记忆只有几十上百条的时候，向量库属于杀鸡用牛刀，关键词匹配加小模型提词反而更稳。
接下来看什么
两个建议。第一，在自己的管线上实测。Context Rot 报告测的是 2025 年中的旗舰模型，新模型对长上下文的耐受度可能有所改善，但只要注意力机制还是有限预算的分摊，退化就是结构性的——与其等新模型解决，不如拿自己业务里的一组问题，短上下文和长上下文各跑一遍对比。第二，盯住两件事：一是 Chroma 会不会把 Context-1 接进 ChromaDB 的查询链路，官方检索层已经在往代理化走；二是 LongMemEval 这类记忆评测集的表现，这会是接下来记忆产品比拼的主战场。
最后一句话：百万上下文只说明"塞得进去"，跟"用得好"是两码事。你的 RAG 上限，不取决于往 ChromaDB 里塞了多少文档，而取决于你能让模型只看见它该看的部分。
