上周我复盘手头的检索增强问答系统发现一个很典型的怪相检索器明明把最相关的文档都捞回来了拼给模型之后回答质量反而往下掉。后来我统计了一下拼接进上下文的token分布10篇文档平均8000多token真正对最终回答有用的信息量大概不到三成剩下全是背景介绍、页面导航文案、重复口径、无关评论这类“长尾噪声”。也是从这时候开始我集中翻RAG上下文压缩方向的论文这周精读的OSCAR就是其中一篇标题全称是OSCAR: Online Soft Compression for RAG。这篇文章名很有意思三个关键词每个都值得拆开琢磨Online在线、Soft Compression软压缩、RAG检索增强生成。我这篇精读笔记不想做成那种“标题摘要复述”的水文而是想把它放在一个完整的问题链路里看RAG为什么要做压缩现有的硬压缩方案到底差在哪OSCAR这个方案里的Online、Soft、Compression分别解决什么问题如果要自己动手复现代码上每一步怎么走、评测怎么做、最容易翻车的地方在哪儿最后再聊聊这类思路落地到业务时哪些场景是真香、哪些场景千万别硬上。1. 先聊清楚RAG上下文里到底藏了多少“无效token”在讨论压缩方案之前得先把问题本身量化清楚。RAG的流程不复杂query进来检索器从知识库里取回一批文档拼到prompt里交给大模型统一阅读并生成答案。听起来顺畅但工程落地时这条链路有四个叠加在一起的问题。第一是上下文窗口的预算问题。模型窗口虽然越来越大但窗口大不等于可以随意挥霍因为输入长度直接影响计算量和成本尤其是按token计费的生产环境。对大多数团队来说单次请求的token预算通常是有限额的检索结果一旦把预算吃光后面想塞历史对话、想塞few-shot示例都没有空间了。第二是检索结果里的信息密度极低。真实知识库里的文档不是论文它往往是产品介绍、FAQ、新闻稿、论坛帖子的混合体。我查“某设备保修政策是多少年”检索器最可能返回的是含关键词最多的长页面里面有公司介绍、产品卖点、用户评价真正回答保修期限的句子可能就一两句而被一起拼进上下文的无关内容可能有上千token。信息密度这么低大模型阅读起来既慢又容易跑偏。第三是所谓的“Lost in the Middle”效应。大模型对长上下文中间位置的内容注意力最弱而检索结果拼接时中间往往塞满了次要内容真正关键的证据链被淹没在中间地带。检索做不好是召回问题检索做好了上下文排布不当照样答不好。第四是时序和一致性问题。多轮对话场景里每一轮都带着同样的背景文档反复拼接token消耗成倍叠加几轮之后上下文里充斥着重复内容模型既没有记住之前说过什么又因为重复信息分散了注意力。这几个问题合在一起指向同一个矛盾我们需要包含足够证据的上下文又不能毫无节制地把原始文档全塞进去。解决办法自然是压缩——在把检索结果喂给生成模型之前先做一轮“取舍”。2. 硬压缩的三种常用做法以及它们各自付出的代价我见过很多RAG系统在做上下文瘦身时直接使用简化的启发式方案。最粗糙的是截断文档取头部或尾部N个token或者按检索得分从高到低只取前几篇。截断的问题很明显答案出现在“恰好被截掉的那一段”是家常便饭尤其是很多文档的关键结论写在结尾部分头部全是铺垫。稍微讲究一点的是抽取式摘要用句子重要性打分把文档里的句子挑出top-k。这比无脑截断好不少但它破坏了跨句子的指代关系和逻辑衔接。比如文档先说“该设备提供三年标准保修”后面句子用“这项政策”指代前文抽取式摘要很可能会丢掉前一句留下孤零零的“这项政策”模型看完一头雾水。更高成本的做法是生成式摘要让一个摘要模型先把文档改写压缩一遍再送去给下游阅读理解。这个方案信息压缩率高但有两个硬伤第一是额外增加了一次生成过程端到端延迟翻倍甚至更多第二个也是更致命的摘要模型压缩时容易产生幻觉会脑补原文没有的细节而下游大模型无法分辨哪些是原文真实信息哪些是摘要器脑补出来的最后可能把幻觉当事实输出。我发现上面这三种方案有个共同特征它们做的都是二值化决策——保留或丢弃没有中间状态。token或者句子要么完整进入上下文要么直接消失不存在“这部分内容不太确定有没有用我给它一个中等权重保留下来”的可能。这个“非黑即白”的取舍就是硬压缩和软压缩最本质的分界点。3. OSCAR三个词拆开看Online、Soft、Compression各解决什么3.1 Online压缩发生在什么时间点OSCAR标题里的Online我先从字面理解压缩是“在线”发生的。这里要对比一个常见的做法——离线预压缩。很多团队会把知识库里的文档提前做一遍摘要把摘要向量化建索引线上检索时直接检摘要文档原文根本不出场。这种做法的优势是线上零额外开销但有一个绕不开的问题压缩目标与用户query无关。不管用户问的是保修期、安装方法还是退换货政策同一篇文档永远只有一份摘要。一份摘要很难同时满足多个角度的查询为了“通用”它最终会写成四平八稳的概述而概述对具体问题往往信息量不足。OSCAR走的是另一条路检索已经拿到top-k文档之后压缩器带着用户原始query对每篇文档重新计算“哪些内容对这个具体问题重要”然后进行压缩。这样压缩是面向问题的方向明确不是把文档压缩成“好摘要”而是压缩成“能回答当前这个问题的上下文”。在线当然有代价最直接的就是压缩步骤插在了检索和生成之间变成了端到端时延的一部分。所以OSCAR这类方案在工程上有个隐含约束压缩器模型本身必须足够轻量否则节省下来的token成本会被额外延迟吃回去。这个约束我后面会专门讲工程踩坑时细说。3.2 Soft软压缩的“软”到底是怎么个软法Soft是我觉得最值得展开的词它对应的是前文说的二值化取舍问题的解法。硬压缩的“硬”在于决策是离散的每个句子或者每个token只有保留和丢弃两种状态。而软压缩的思路是让压缩器给上下文里的每个token或者每个语义单元输出一个0到1之间的连续重要度分数在拼接阶段按分数加权甚至采用“有一定概率被保留但保留下来的证据会得到相应加权”的方式。为什么这样设计有价值核心是可微性。在训练阶段如果我们能用下游生成任务的loss来反向传播压缩器的打分网络就能被优化成“生成效果好就强化这个打分模式生成效果差就调整打分方向”。这就是“为了让答案更好而保留内容”而不是“因为内容长得像摘要所以保留”。另一个隐蔽的好处是软压缩天然带容错能力。硬压缩一旦误删了关键证据信息就永久丢失了软压缩给的是概率化的保留重要度不高的内容只是被削弱不是被彻底抹掉。对需要多段证据综合推断的问题这种“柔和”的保留方式容错空间明显更大。3.3 Compression压缩不是一个距离度量而是一个任务目标Compression这个词看似直白但在RAG场景里“压缩成什么样子才叫好”其实是个容易跑偏的问题。如果只追求压缩率那最优解是什么都不保留如果只追求信息保全那又把问题绕回了原始全文拼接。关键不是压缩率本身而是在给定压缩率的前提下最大程度保留“下游回答所需的信息”。我觉得理解压缩目标最好的一个思维实验是“干扰敏感性分析”把原始文档中的某一段内容删掉喂给模型观察回答质量的变化。如果删掉这一段模型回答得分掉得特别厉害说明这段是回答问题所必需的关键证据压缩器必须优先保留它如果删掉之后回答得分几乎没有变化说明这段在这个问题语境下就是冗余的可以被软化掉。按这个标准训练出来的压缩器不是在学“文档哪些句子写得好”而是在学“文档哪些内容与回答当前问题强相关”。这个视角也解释了为什么不能用“压缩结果与原文的语义相似度”来做评价——一段全是客套话的文字和原文语义相似度可能很高但删掉它对回答质量毫无影响留着它纯属浪费token。压缩得好不好的最终标尺只有一个下游回答的质量是否保住了。3.4 我推测的OSCAR整体工作流程下面这部分是我从标题和RAG压缩领域常见技术路线做的合理推测拆解如果你手上拿到了论文原文或者公开代码以原作者给出的方案为准我这里主要提供一种“如果我也要这么设计会怎么搭骨架”的思路。整体流程文字描述是这样query进来检索器先取回一排候选文档压缩器作为一个轻量模块接收“query 单篇文档”逐token输出重要度分数随后压缩模块根据分数与预算约束对上下文做软加权拼接最终拼好的紧凑上下文交给大模型生成答案。压缩器内部大致分四步第一步用一个小体量的编码模型把query和文档拼在一起做交叉编码。为什么用交叉编码而不是双编码因为“某个词重不重要”往往取决于它与query的交互单独看文档词频是看不出重要性的交叉编码能捕捉query和文档词之间的细粒度attention。第二步在编码结果上接一个打分头输出每个token的重要性分数。打分头的设计可以用线性层加sigmoid也可以套用token-level的分类头加温度系数。第三步按照压缩预算约束筛选token。比如预算要求压缩率30%也就是原始1000个token最后只能保留300个那么压缩器就在全局分数约束下做选择。如果采样保留那就让保留概率与分数成正比被保留的token还可以按其重要性度做一个加权这就是“软”的体现。第四步训练时用下游生成loss端到端回传同时加一个压缩率正则项保证模型不会为了追求效果而无节制地保留token。这套设计最大的优势在于压缩器不是一个独立训练的摘要模型而是与下游生成能力绑定的一个组件。这也是它在概念上区别于生成式摘要方案的关键——生成式摘要的优化目标是“摘要与原文接近”OSCAR的优化目标是“最终答案答对”这两种目标在数学上完全不是一回事。4. 从标题到代码一份可执行的OSCAR复现路线光聊概念不过瘾我把自己在模拟项目X上复现软压缩思路的路线整理出来这条路线不一定与论文实现细节一致但每一步都是可落地、可验证的。4.1 环境选型以及为什么我不推荐上来就上大模型先说选型逻辑。在线压缩器要承受线上实时延迟压力所以不能选大参数模型同时它又要做token级语义交互不能太弱。我的选择是压缩器用一个小体量的开源编码模型也就是一般被称为“轻量级Encoder”的那一类参数量在几十M到一两百M之间阅读器用开源基座模型参数量级按团队现有推理能力决定。如果想先快速验证效果甚至可以直接用对话模型做reader先把链路跑通。软件依赖不需要很多我用的核心组件大概是这些torch2.0 transformers4.40 datasets2.10 faiss-cpu # 检索用小语料CPU版够用 einops accelerate需要提醒的是与其纠结压路机版本不如先把评测集定好。因为没有稳定的评测后面做的所有优化都无法判断是好是坏。4.2 数据集与评测指标先定义“什么才算压得好”我构造了一个“长文档答案”型评测集每个样本给一个问题附带一大篇混合文档。文档里故意掺入几段与问题无关的干扰文本保证数据难度是真实的RAG场景难度。评测维度我固定死四个评测维度测量方式说明答案准确率模型生成答案与标准答案的F1核心指标必须看压缩率压缩后token数 / 原始token数越低代表节省越多预算端到端延迟从query发出到拿到答案的p50耗时直接决定生产可接受度关键信息保留率文档中预设的关键实体/论证点是否出现在压缩结果中辅助诊断用这四张表一起看才能把“压得多”和“压得好”分开。如果只看压缩率容易做出一个把所有内容都删光的模型如果只看答案准确率又容易得到“压了个寂寞”的结果。4.3 训练流程我用两阶段法先让压缩器学会“看重点”端到端直接训练压缩器和reader是可行的但工程上我强烈建议先做两阶段。第一阶段先离线收集“关键段敏感性”软标签对训练集里的每个文档片段依次做删减实验把删除后回答得分下降幅度超过阈值的片段标记为高重要性。用这些软标签先去训练压缩器的打分网络让压缩器先学会“哪些内容与问题相关”。第二阶段再端到端微调把压缩器接到reader上同时优化生成loss和压缩率正则。我用的训练目标大致长这样# 伪代码核心思路是生成loss 压缩率正则项 loss generation_loss lambda * max(0, current_compression_rate - target_rate) # 打分网络输出token级重要性分数 importance_scores torch.sigmoid(scoring_head(last_hidden_state)) # 在压缩预算约束下对token基于分数软筛选 source_mask sample_by_importance(importance_scores, budget_ratio0.3)lambda参数需要反复调。我的经验是从0.01量级起步每个实验翻倍观察压缩率和生成loss的变化找到一个“压缩率达标但生成质量下降不超过1-2个点”的平衡值。温度系数初始设1.0如果训练初期打分分布过于集中可以适当降温度促使分数平滑化。4.4 先跑通一个“插拔式”基线再谈优化如果时间紧我建议不要一上来就搞端到端训练先把压缩器做成“可插拔”模块评估三种基线截断、抽取式句子摘要、生成式摘要然后才对比OSCAR思路的软压缩。我在模拟项目X上的初期对比结果如下下表数值是展示对比逻辑用的示例不是论文复现数据方法压缩率答案F1端到端延迟(p50)硬截断top-k0.500.511.8s抽取式句子摘要0.350.582.1s生成式摘要0.250.623.9s软压缩OSCAR思路0.300.662.3s这个表的信息量很大生成式摘要指标看着不错但延迟是硬伤软压缩在压缩率与F1之间取得了比硬截断好得多的平衡点。延迟比抽取式摘要只高一点点但F1提升明显。5. 复现OSCAR时最容易翻车的几个环节如果只看论文标题想当然地写代码大概率会被下面这几个坑反复折腾。我把自己的排查记录列出来能少走不少弯路。第一个坑是压缩器训练不稳定具体表现是模型打了半天分数最后输出的sigmoid分数全都集中在0.5附近。这不是模型没学到东西是打分头缺乏区分度。我试过把温度系数调低、给打分头加一个熵正则强制分数分布不要过度集中于中段。亲测有效的方法是先冻结reader单独用软标签训练压缩器几百步等损失降下去再解冻做端到端。上来就端到端两个模型互相干扰训练曲线通常很妖。第二个坑是前文提过的在线时延陷阱。软压缩器再小也是“插入”了额外的一跳推理。读者可能觉得压缩完少喂了几千token生成更快了时延应该降下来但实际不是。生成少几千token省下的时间很可能被压缩器的推理时间抵消掉。解决思路有几种压缩器参数量压到极致先做句子级粗筛筛掉明显无关的句子后再做token级细选把精细编码用在刀刃上对高频query的检索结果加缓存省掉重复压缩。我在系统里就是把压缩器限定在轻量级Encoder级别实测对p50延迟的影响在可接受范围。第三个坑是信息损失不好量化。我遇到过压缩结果看着挺通顺但模型回答里的关键实体却对不上的情况。后来逐段排查发现软加权会把一些规范化表达的词削弱比如“保修期36个月”里的“36”被弱化模型就认成了“几个月”。对这类“强保护词”我的做法是维护一个小规则库数字、否定词、专有名词在软压缩时不参与降权直接强制保留。同时定期做人工抽样评估每批抽20条检查关键实体和论据有没有漏。第四个坑是评测指标作弊。单一事实型问答做评测集压缩器只需要学会“保留命名实体”就能拿高分表面F1好看但遇到需要跨段落推理的多跳问题立刻露馅。我在评测集里专门混合了几类问题单点事实、多跳推理、否定问答、对比异同。只保留实体不保留推理链的压缩器在多跳问题上的F1会掉得非常快。不要只盯着总分把不同题型的分数分开看才能暴露压缩器的真实能力。6. 落到业务里软压缩适合哪种RAG不适合哪种论文里的方案看着先进落地时也得挑场景。我在团队内部做过好几轮适配评估总结下来大概是这么个边界。适合的场景有三个明显特征文档长、数据噪声大、对token成本敏感。比如企业知识库问答一篇文章动不动几千字问的就是其中一两处细节再比如多轮对话场景每一轮都要重复塞背景文档软压缩能把每一轮的上下文做得更精炼多轮之下累积节省的token非常可观。软压缩器输出的重要度分数本身也有价值我实际测试下来把它当作检索结果的重排信号能够把真正包含答案的文档往前提这算是方案带来的额外甜点。不适合的场景也很明确。如果检索出来的文档本身只有一两百token压缩的收益微乎其微纯粹增加时延那还不如原样拼接。对需要逐字引用的法务条款、合同原文、审计记录这类场景任何压缩都意味着风险软压缩也不例外改走“不压缩引用标注”路线更稳妥。再就是交互延迟要求极高的在线服务如果产品不允许在检索和生成之间再多一次模型调用那当前阶段更现实的方案还是离线预压缩或者优化检索器本身。工程上要真用起来我给三个建议。第一把软压缩器和缓存搭配起来高频知识库条的压缩结果可以缓存复用把在线成本摊薄第二检索时可以先多取一些候选文档比如从top-10扩到top-30交给压缩器按重要度分数筛到预算内这往往比让检索器直接硬截断效果更好第三压缩器打分结果建议做成可观测数据压掉的内容单独存一份日志方便出问题时回溯。这周精读OSCAR我最实际的收获倒不是具体网络结构而是把“压缩”这件事从“减少token数量”重新定义成“面向下游任务的软性信息选择”。一开始我也是条件反射地想到截断、摘要这些老路子真正被软压缩打动是在一次对比实验里同样的压缩率硬截断把关键证据一刀切没了软压缩反而靠着重要性加权保住了推理链答案质量直接拉开了差距。这篇笔记写到这儿我自己的下一步计划是把手头问答系统里的硬截断换掉先用两阶段法训练一版压缩器在模拟项目X上把压缩率、F1、延迟三个数都盯住跑够一个评测周期后再决定是否进生产。如果你也在做RAG落地建议别只看标题和摘要拿这个思路去你自己的知识库上跑一轮评测数据会告诉你它到底值不值得用。