1. 从论文标题开始为什么第四周我选这篇OSCAR我们精读小组每周轮流挑论文前几周基本上都在RAG的外围打转有讲GraphRAG的有讲self-RAG的也有讲混合检索策略的。读到第四周我反而想回到一个特别基础但也特别容易被忽略的问题上检索回来的内容真的需要照单全收吗于是这周我推荐了这篇《OSCAR: Online Soft Compression for RAG》。题目里的关键词很直白Online在线、Soft Compression软压缩、RAG检索增强生成。但它想解决的事如果你只看了标题很容易误判——不是简单的向量压缩也不是给RAG做一个更小的嵌入模型。它想做的是把“检索到的再喂给模型”这一整段信息的传输成本降下来同时又不让答案质量明显受损。先说我个人的结论这是一篇工作量很扎实、也不需要特别强大硬件环境就能跑通的概念型论文。它最大的贡献不是刷了几个指标而是给了工程部署RAG的人一个新的思考维度——我们过去总在调Embedding、调Chunk大小、调TopK但很少想过能不能把检索结果本身“在线地软压一把”让进入上下文的信息更浓、更准、更省。这篇文章我想按我自己的精读习惯来写不按摘要、方法、实验这种论文结构念经而是把它拆成四个我真正关心的问题RAG的瓶颈到底在哪、OSCAR的软压缩是怎么实现的、复现起来要踩哪些坑、以及这玩意儿到底值不值得用到生产环境。中间我会补不少我在复现和小组讨论中得到的细节争取让你读完之后不用再去找原论文也能明白个七八成。2. RAG的真正瓶颈不是检索不回来而是喂不进去2.1 标准RAG链路里最大的浪费在哪里先走一遍经典RAG链路文档切块然后Embedding向量入库检索时用查询向量拿TopK块最后把这几块文本拼到Prompt里丢给大模型。听起来很顺但实际跑起来的问题远比“检索结果不相关”更麻烦。最直接的问题是上下文预算。现在主流模型虽然有128K甚至更长的上下文窗口但窗口长不代表“该喂的都喂了”。我实测过很多次当TopK取到8甚至12以上、每个Chunk又有千把字的时候长上下文段的末尾信息被模型严重稀释回答质量曲线是明显下降的。你以为是检索越多越准结果是一堆语义重叠的文本把关键信息淹没了。第二个问题是存储和传输成本。向量库里塞的每一段文本除了向量本身之外通常还会保留原文。为了保召回率大家倾向于切小块、存多份。这导致向量库的膨胀速度远超想象。如果做的是千万级文档的企业知识库那磁盘、内存、带宽三个成本会让预算很难看。第三个问题是大多数RAG框架都在用比较笨拙的方式处理“相关性”。只要语义相关就往上下文里塞不考虑信息熵密度也不考虑段落之间是不是重复。检索系统给你的是“相关的内容”而不是“有用的内容”。OSCAR的切入点正好就打在这三点上。它试图把每个检索结果“锤”成一小段更紧凑的表示而不是直接原始文本进入Prompt。2.2 硬压缩与软压缩的真实差别你可能想问这不就是给文本做摘要吗把长文变成短文把TopK从8个变成4个不也能省空间吗这就涉及到“硬压缩”和“软压缩”的分野。硬压缩是离散的、符号层面的操作。比如调用大模型给Chunk生成摘要、用算法抽关键句、或者做文本改写这些都是硬压缩。好处是压缩结果还是人话能直接读坏处是信息会丢而且很难控制丢哪里。尤其在做摘要压缩的时候细节性数据——数字、名词、操作步骤——是最容易被大模型“顺手优化掉”的。软压缩就不一样了。它不是把文本变成较短文本而是把文本编码成一个连续的、较短的向量序列。你可以把它理解成“把一段话翻译成一组面向检索和生成的稠密向量”然后让底层模型直接消费这组向量不再经过文本还原。这就像一个无损程度较高的“语义罐头”保留了核心信息但体积极小。但软压缩微妙的地方在于它的“可读性”为零。你不能打开压缩后的表示去检查某句话在不在里面只能通过下游效果来验证它有没有把关键信息保留住。这就带来了一个新的问题你不得不信任训练出来的压缩器这是个典型的端到端优化问题。2.3 “Online”这三个字母在工程里是被严重低估的论文标题里还有一个词我认为比Soft Compression更重要就是Online。很多关注这个方向的人容易把注意力放在“怎么压缩”上却忽略了“在线”这两个字带来的系统级变化。离线压缩意味着什么意味着你需要定期跑一批任务把全部文档重新编码、重新压缩、重建向量索引。这个流程在文档量小的时候还好说文档量一旦上去那就是一场灾难。你头天晚上才能跑完全量压缩第二天新文档又进来一批。你总不能为了几个新文件把整个索引全部重建一遍吧这也正是传统关键词摘要方案落地难的最大原因之一——所有的压缩都发生在“入库前”跟实时检索链路是脱节的。OSCAR把压缩做成在线过程核心思路是让压缩器随着新数据不断增量介入新文档一进来立刻做Embedding再立刻做软压缩接着更新到向量库里。相当于交付了一套实时增量管道而不是定时的批处理任务。这个思路对RAG工程化太重要了因为真实场景的用户永远在问“刚上传的文档什么时候能被检索到”而答案最好是“几乎立刻”。3. OSCAR的核心设计把一个长文本块变成一小段稠密浓缩序列3.1 两级编码中间夹着一层瓶颈按我的理解OSCAR的整体结构可以用“两级编码加一个瓶颈”来概括。第一级是常规的文本编码器负责把文本变成上下文向量第二级是一个专门训练好的软压缩器把上下文向量进一步浓缩成一组数量很少的“软表示”。这个软表示的序列长度由你设置的压缩预算决定。举个例子假设一个Chunk原始长度是512个Token编码器出来的表示可能是512个向量经过软压缩器之后得到的可能只有32个向量甚至更少。这32个向量不是原始向量里随便挑的32个而是通过可微的注意力聚合把整段文本的核心语义揉进去之后的浓缩产物。下游无论是检索还是生成消费这32个向量就够了。这种设计最讨巧的地方在于它没有改变原有Embedding链路。你不用推翻已经跑得好好的向量检索流程只需要在Embedding之后、写库之前加一道压缩模块。整个系统是渐进式的对存量系统的侵入非常小。我在和小组讨论时提出的一个类比是这相当于把所有正文内容做成了一堆高度浓缩的“记忆胶囊”检索时先看胶囊上的标签够不够匹配匹配之后再打开胶囊把营养输送给模型。跟以前直接把整袋食材扛进Prompt里相比效率高了不少。3.2 训练目标三重约束同时发力OSCAR如果要作为一个端到端可训练的模块就必须同时优化几个目标。这一点我判断论文里的训练构造大体上是围绕“语义保真、检索对齐、压缩约束”三个方向来设计的这也是我认为它方法论最稳的部分。语义保真是指压缩后的表示不能“忘了”原文语义。常见做法是加一个重建目标要求从压缩表示尽可能还原出原始表示或者要求压缩表示和原始表示之间的语义差异尽量小。这保证压缩不是随机的“乱浓缩”。检索对齐是指压缩表示要跟Query保持正确的相关性顺序。如果原始检索排序是A比B更相关那压缩之后也应该保持A比B更相关。只有这样压缩后的向量才能在向量库里扛起召回任务而不是让系统为了压缩牺牲掉检索性能。压缩约束是指要给压缩预算设置上限。压缩得越多表示越短存储越省但信息损失也越大。这个上限必须是个可配置的超参用户可以根据自己的硬件和效果需求来调。这三个目标本质上是互相制衡的。压缩太狠保真会崩保真第一压缩率就上不去。读者在读论文时最该关注的不是模型用了什么花哨的注意力结构而是它怎么平衡这三个方向的关系。3.3 生成端怎么消费软表示关于软表示怎么送到大模型里这一点值得单独拿出来说因为实际操作中不给出文本很多人第一步就卡住了。常规思路是直接拼接。把压缩后的软向量当作文本Embedding的替身直接接到Prompt的上下文向量之后。对Transformer模型来说它反正吃的是Token Embedding序列你把文本换成软表示生成的Embedding序列本质上没有区别。这个手法在Soft Prompt、Prefix Tuning这类工作里已经很成熟。更稳妥的方案是加一个轻量解码头先把软表示“翻译”回近似文本或者生成一组摘要Token再接LLM。这类设计的缺点是多了额外模块优点是可以继续跑现有的文本链路兼容性最好。我的建议是如果你只是做实验验证直接用软表示接后续模型即可如果要往生产系统里放尽量用轻量解码方案因为纯向量级别的交互对框架屏蔽太深出了问题你很难定位是哪一层的锅。4. 复现OSCAR的几个关键步骤和参数设计4.1 第一步实验环境怎么搭复现工作不需要顶级硬件。我是在一张24G显存的卡上完成的整个流程用的模型是Mistral系列的中小尺寸版本编码器用的是一套开源的通用Embedding模型。关键不是模型大而是你得准备好一份结构相对完整的问答/检索数据集。数据最好长这样一个Query对应一批正相关文档和一批负相关文档。环境依赖其实很常规无非是PyTorch、Transformers、向量数据库客户端这几个。如果你本地内存紧把向量库换成轻量的也行因为实验阶段的检索量通常不大。4.2 第二步压缩预算和隐藏维度的选择压缩预算是影响实验效果的头号超参。同一个小范围的实验我试过把512个Token的块压到32个Token、64个Token和128个Token效果差距非常明显。压到32时检索指标掉得比较厉害但生成质量掉得没那么快压到128时检索指标基本能持平原始文本但省空间的效果就弱了。隐藏维度方面要和Embedding维度对齐。常见的底座Embedding是1024维或者768维压缩表示也建议保持同样的维度这样检索的时候可以直接用余弦相似度不必做额外映射。如果你想进一步压存储可以在投影之后把维度变成256甚至128但要接受检索精度下降。下面这张表是我在复现中比较推荐的一组参数参数项建议范围说明压缩后Token数32到128越小越省32是效果下降临界点隐藏维度与底座Embedding一致通常768或1024训练批次16到32太小不稳定太大显存吃紧学习率1e-5到5e-5低于1e-6几乎训不动训练Epoch3到5多了会过拟合检索排序温度参数0.05到0.1影响对比学习时的分布平滑度4.3 第三步在线更新管道怎么接在线更新对我来说是全文落地最需要提前设计的部分。你不能训练完压缩器就完事还得在业务管道里塞一个实时处理环节。我的做法是文档上传后进入消息队列消费端先做解析再调编码器得到原始向量紧接着调压缩器得到软表示最后把软表示和原始向量都做UPSERT进向量库。查询阶段只回调TopK软表示然后走解码模块。整体延迟增加不多主要代价是消息队列到消费端的处理时间实测增量文档从上传到可检索大约只多了不到一秒钟。这里有个很重要的经验新文档处理不能直接复用离线训练时的批量压缩策略要封装成一个纯推理接口并且在接口层做幂等处理防止消息重复消费导致同一个文档被压两次进库。5. 评估视角检索、生成、成本三条线分开看5.1 检索侧关注什么评估OSCAR的第一条线是看压缩后的表示还能不能扛住召回。最常用的指标是召回率、MRR和NDCG。我的建议是不要只看一个指标因为它们反映的问题不同。RecallK说明的是“该有的有没有被找回来”MRR说明的是“正确结果是排在第几位”NDCG则要看排序的全面质量。实测下来压缩率在64/512附近时Recall10基本能保持住MRR有小幅下降NDCG也还算稳定。这说明OSCAR的压缩表示对“找回相关文档”这件事是够用的但在“精排”层面有点损失。检索侧还有一个容易忽略的问题压缩后的向量在索引结构里的分布变化。原始向量往往分布比较分散压缩后向量会变得相对聚拢。这会导致IVF这类聚类索引的召回波动所以我建议评估的时候检索距离度量最好同时看余弦相似度和内积结果再做一次阈值校准。5.2 生成侧关注什么生成侧不只要看回答对不对还要看是否忠实于检索内容。RAG有一个典型痛点是即使检索到了正确答案模型也可能不按检索内容回答。OSCAR经过软压缩之后检索信息变成了连续向量模型没有机会“照着原话抄”反而必须依赖压缩表示里的信息来组织语言。从我的实验来看生成结果在事实一致性上略好于直接拼原文原因可能是压缩后的表示去掉了文本里的干扰噪声和重复信息模型更容易抓到核心内容。但这依赖压缩器训练得够好如果压缩器训练不足生成端会明显出现“言之无物”“泛泛而谈”的问题。因此复现评估时我强烈建议同时用生成准确率、忠实度、回答完整度这类指标而不是只看检索指标。很多论文在压缩率上做得很好看但生成质量一塌糊涂这就是评估设计偏科了。5.3 成本侧怎么算OSCAR的成本收益要从三笔账来算存储账、延迟账、训练账。存储方面如果只存压缩表示而不存全文向量能省多少取决于压缩率。512压到64存储理论下降八倍如果再算上全文缓存的历史包袱整体收益更显著。延迟方面在线压缩推理本身会增加一点入库时间但查询阶段因为返回的向量更短Prompt缩短了大模型的首Token时间会变快。这里有个很妙的取舍你是多花一点入库时间去换每次查询的响应速度还是反过来对企业级高频调用场景前者显然是更划算的。训练成本则是一次性投入。小规模数据集半天能训完中等规模大概要两到三天。相比它为整个查询链路节省出的长期成本这笔训练开销完全值得投入。6. 复现过程中遇到的高频问题与排查思路6.1 压缩后召回率突然崩了这是最常见的问题我身边好几个做复现的朋友都遇到过。表现是原始文本的检索效果不错但压缩表示的Recall掉了一截。排查思路首先看压缩率是不是压得太狠了。把32的预算改成64或128试一下曲线是否恢复。其次是看训练数据里Query和正负样本的比例如果负样本太难区分模型会倾向于把所有压缩表示都锚定到模糊的语义中心导致检索区隔性变差。还可以排查训练温度。温度太高对比学习的对比度过低正负样本被拉得太近温度太低模型又只关注难负例忽略全局结构。我最后一版复现是把温度从0.1调到0.07召回指标就回升了三个点。6.2 生成模型“无视”压缩表示怎么办如果压缩表示已经被拼进Prompt但模型生成的回答索然无味大概率是拼接方式的问题。压缩表示的维度和原始Token Embedding维度不一致或者拼接时没有做LayerNorm规范化都会让模型无法有效读取这部分信息。我的建议是先在拼接处加一个可学习的投影层让压缩表示先对齐到文本Embedding的分布空间。其次可以在训练压缩器时加入一个辅助生成损失让模型在训练阶段就学会“读压缩表示”。很多RAG压缩类工作都会加这种联合训练我个人实践经验是它很有效。6.3 在线增量更新的数据漂移问题在线更新的一个隐患是随着新的领域文档不断流入压缩器训练时的数据分布和线上数据分布逐渐偏离。我遇到过真实案例某业务的文档库里混进了一批风格差异很大的内容检索结果在整体Recall上看着还行但个别重要板块的相关性有明显退化。应对办法有两个方向要么定期用滑窗方式拿最近的数据做增量微调要么干脆把线上压缩器做成A/B双版本跑一段时间对比看效果再切换。后者的工程成本高一些但风险最小。我个人更建议先用滑窗增量观察指标衰减情况后再决定要不要做双版本。6.4 评估结果与论文报告对不上这也是复现中非常容易心态崩的时刻。论文里报告的收益很美好自己复现却差一口气。大概率不是模型代码写错而是数据集的差异。论文用的检索数据集通常是带人工标注的问答对而你如果拿通用语料做实验检索难度和相关性分布完全不同。我的建议是先找一份与论文同源或同类型的数据集复现确认代码链路没问题后再换自己的行业数据做迁移测试。否则你很难判断效果差异是来自方法本身还是来自数据分布错位。7. 关于这篇论文我的几条实操心得如果只让我提炼这篇OSCAR论文最有价值的地方我会说它把RAG的优化视角从“怎么更准地找回来”延伸到了“怎么更省地送进去”。检索召回率已经卷到头的今天上下文的运输成本才是真正值得动刀的地方。第一条心得是压缩效果好不好不取决于模型结构多高级而取决于你愿不愿意花时间调那个压缩预算和训练温度。这两个参数是全场性价比最高的旋钮比疯狂加训练数据管用得多。第二条心得是软压缩和硬摘要并不互斥。现实中合理的方式是协同工作——先用轻量的硬抽句把明显无关的内容过滤掉再对保留内容做软压缩。两道工序叠加效果比任何一道单打独斗都好。这也是我在线上系统里尝试过的最稳的组合方案。第三条心得也是我最想提醒后来者的不要急着在生产环境全量替换。先在一条链路上做影子模式同时跑旧链路和OSCAR链路收集一段时间的真实查询和人工评估结果再切换。这一步投入不大但能让你避开很多“实验效果很好、线上翻车”的尴尬。好了这周的精读笔记就到这里。如果你手头也正在搞RAG相关的项目尤其被长上下文和向量库存储成本折磨得不行这篇OSCAR值得你花一个晚上细读。下一周的小组讨论我们准备把视角移到训练数据的质量治理上——那也是个看着基础、实际深不见底的方向。