Token 明明降了为什么答案反而更不可信不少团队给 RAG 增加Contextual Compression后第一眼看到的 usually 是成本下降进入生成阶段的片段更短Prompt 更干净首 token 延迟也有改善。⚠️ 真正把链路放到知识库问答、制度检索或内部 Copilot 后问题却开始反着来。模型回答更像“摘要”却不再稳稳引用原始约束版本号、适用范围和例外条件经常在压缩后一起消失。根因通常不是压缩模型太弱而是工程链路把“能删什么”和“绝不能删什么”混在了一起。 当压缩器只追求与 query 的表面相关度时它很容易保留结论句却裁掉支撑结论的限定条件。这样生成阶段看到的是更短的证据却不是更完整的证据。图 1Compression 真正危险的地方不是压得不够短而是把证据边界压没了 真正的问题不是压缩本身而是证据结构没有被分层生产环境里最常见的失真有三类。 第一类是结论保留、条件丢失例如“可开启该开关”被保留但“仅限离线批处理任务”被删掉第二类是表格或列表被压成自然语言后列间约束关系消失第三类是多个相邻 chunk 被分别压缩最后生成阶段拿到的是几段看似相关、实际互相缺前提的碎片。在一组企业制度问答压测里原始Top 6证据直接进入生成阶段时回答准确率约为 78%引用精确率为 81%加上单段独立压缩后Prompt token 降了 34%但准确率跌到 69%引用精确率跌到 63%。✅ 继续改成“先重排再按 query-aware 规则保留条件句和引用锚点”Prompt token 仍能下降 22%准确率则回到 76%。这说明真正值得追求的不是压缩率极限而是压缩后的证据可消费性。方案Prompt Token 变化准确率引用精确率主要问题不压缩直接拼接基线78%81%成本高单段独立压缩-34%69%63%条件和表格丢失重排后保留条件压缩-22%76%79%综合更稳图 2更高的压缩率不等于更好的回答质量证据保真必须一起观察️ 更稳的工程方案是把压缩改成带护栏的证据裁剪更适合生产环境的做法是先把证据拆成“可裁剪信息”和“强约束信息”。️ 版本号、时间窗口、适用人群、例外条件、表格列名和引用锚点应该进入must_keep_spans只有背景解释、重复定义和低价值铺垫才允许压缩器自由裁剪。️ 此外压缩最好放在 rerank 之后执行因为只有排序完成后系统才知道哪些片段真的值得保留。defcompress_evidence(query,ranked_chunks):kept[]forchunkinranked_chunks[:4]:anchorsextract_must_keep_spans(chunk,fields[version,time_range,exception,table_header,citation],)summaryquery_aware_compress(query,chunk,preserveanchors,max_tokens180)kept.append(merge_preserved_spans(summary,anchors))returnkept这段逻辑的重点不是把max_tokens调到多小而是让压缩器先接受边界。 如果一个 chunk 压缩后已经找不到版本、条件或引用落点就应直接回退原文片段而不是继续把不完整摘要送进生成阶段。 这一层 guardrail 往往比继续堆更大的上下文窗口更有效。图 3更稳的 Compression 不是任意摘要而是先提取锚点再裁剪正文 接下来 3 到 6 个月RAG 压缩竞争会转向 Citation 保真接下来更值得观察的不会只是 token 节省比例而是压缩后的回答还能否稳定指回原始证据。 团队至少要持续跟踪citation_precision、anchor_preserve_rate、compression_fallback_ratio和answer_grounded_rate。 这些指标一旦恶化说明系统已经在用“更短的提示词”掩盖“更弱的证据链”。笔者认为未来 Contextual Compression 真正能落地的方向不是把所有检索结果都变成一段摘要而是让压缩器学会尊重证据边界。 对高约束问答、制度检索和运维 Copilot 来说少 200 个 token 从来不是核心收益少丢一个限制条件才是。 你们当前 RAG 链路里更常见的问题是压缩后引用漂移还是条件句被提前裁掉欢迎交流。图 4Compression 上线后真正该盯的是锚点保留率和引用漂移而不是单一省 token