你有没有遇到过这种情况：把一段中文长文本喂给某个AI工具做摘要压缩，结果压缩完的内容读起来支离破碎，甚至完全变了意思，可你用同样的工具处理英文文本时，效果却好得多。
如果你有过这种感觉，那不是错觉。
2026年发表的一篇研究论文，用一场横跨十种语言、超过25万次调用的大规模测试，把这个隐藏已久的问题彻底摆到了台面上。研究者是立陶宛考纳斯理工大学与Hostinger公司的Mantas Lukauskas，他做了一件此前没人系统做过的事：给市面上主流的"提示词压缩"技术做一次跨语言体检。体检结果不算乐观。某些压缩工具在中文上的表现，用论文里的原话说，是"本质上等于零"。
**核心问题：省钱的技术，却让非英语用户多花钱**
先说说这项技术为什么存在。
现在用大模型的人都知道，输入的文字越多，调用成本越高。如果你在做一个检索增强生成（RAG）系统，每次都要把一大段检索到的文档塞进提示词里，账单会很快膨胀。于是有一类技术应运而生，叫做提示词压缩。
提示词压缩：用一个小模型判断哪些词或句子信息量低，把它们删掉，剩下的文字依然是普通文本，可以直接喂给任何大模型使用。
这类技术里最有代表性的是微软的LLMLingua系列，尤其是LLMLingua-2，它在英语基准测试上的表现相当亮眼，业内经常拿它当标杆。
但这里有一个容易被忽略的背景事实：不同语言在被大模型"读"的时候，成本天然就不平等。
这涉及到分词器的概念。
分词器：大模型在处理文字前，会先把文字切成一个个"token"（词元），再按token数量计费和计算。分词器的词表主要是根据英语语料训练出来的。
由于分词器的词表大部分资源都倾斜给了英语，同样一段内容，换成其他语言，需要切出的token数量会明显更多。论文测算发现，在他们收集的平行语料（也就是完全相同内容的十种语言翻译版本）上，非英语语言比英语平均要多付出1.3到1.8倍的token，某些语言在特定分词器下甚至要多付4.5倍，比如印地语在Qwen2.5的分词器下。
这就好比在一个只认可某种货币面额的自动售货机前，你的货币汇率天然就比别人差，买同样一瓶水，你要多投几个硬币。
这个背景让研究者产生了一个直觉上很自然、但此前几乎没人验证过的疑问：既然非英语语言本来就要多付token钱，那么压缩技术是不是至少能帮它们省回来一点？还是说，压缩这件事本身，也在悄悄地对非英语更不友好，让这个差距雪上加霜？
论文的答案是：差距不仅没有缩小，反而在压缩比例变大的时候急剧扩大，某些语言压缩到最后基本被"压没了"。
**发现一：压缩力度越大，语言鸿沟越明显**
研究团队搭建了一套相当严谨的测试体系。他们选取了十种语言：英语、波兰语、芬兰语、爱沙尼亚语、拉脱维亚语、立陶宛语、乌克兰语、简体中文、现代标准阿拉伯语和印地语，覆盖五种文字系统（拉丁文、西里尔文、汉字、阿拉伯文、天城文）。所有测试材料都是完全平行的，也就是同一份内容的十种语言版本，这样才能保证比较的公平性，排除"内容本身难度不同"这个干扰因素。
他们用了Belebele阅读理解数据集做主测试，每种语言300道平行题目，并在gpt-5.4-mini和claude-haiku-4-5这两个主力模型上做了全量测试，还在另外九个来自不同厂商的模型上做了复现验证，包括Gemini、Llama 4、Mistral、DeepSeek、Kimi、MiniMax、Qwen等。
测试设计了一个关键指标，叫做归一化上下文利用率。
归一化上下文利用率：把某种压缩条件下模型答题的准确率，减去完全不给上下文时的准确率，再除以给完整上下文和不给上下文的准确率之差。这个数值等于1，代表压缩后的效果和给完整内容一样好；等于0，代表压缩后和什么都不给差不多；如果是负数，说明压缩后的内容甚至比不给还糟糕，帮了倒忙。
结果非常清晰。在轻度压缩（保留75%内容）的情况下，各语言之间差距不大，英语和其他语言表现接近。可一旦压缩力度加大到只保留33%的内容，情况急转直下：英语依然能保留57%到62%的上下文价值，立陶宛语只剩10%到24%，而中文，直接跌到负值，也就是说压缩后的中文文本，比完全不给上下文效果还差。
更讽刺的是，中文在分词器层面吃的token亏是十种语言里最小的（只多付28%），却是压缩伤害最惨重的语言。这说明一件事：token计价的不公平，和压缩安全性的不公平，是两个完全独立的问题，前者小不代表后者也小。
这就像一家搬家公司，报价的时候按房间数收费本来就不太公平，大房子多收钱天经地义。但真正让人无法接受的是，等到东西真正被打包运输时，那些按大房子价格多收了钱的客户，家具反而被摔得最碎。收费不公平是一回事，服务质量的不公平是另一回事，两者叠加在一起，才是真正的双重惩罚。
论文用一个很实际的说法总结了这一发现：所谓"安全压缩预算"，也就是压缩到多深还能保证效果不明显下降的临界点，对英语来说大约是压缩到一半（2倍压缩），而对其他九种语言，大约只能压缩到77%左右（1.3倍压缩），再往下压，效果就开始明显打折。
**发现二：问题出在训练数据，不在模型架构**
这是整篇论文里最关键、也最有洞察力的一部分。
如果只看到"压缩效果因语言而异"，很容易以为这是模型架构本身的局限，比如某种编码器天生处理不好某种文字。但研究者做了一系列对照实验，逐步排除了这种可能性。
第一层对照：确定性方法（不需要训练、靠规则运作的压缩方式，比如按TF-IDF挑句子、直接截断、随机删词、按词形还原去停用词）会不会也有类似的语言鸿沟？
答案是不会。这些方法在同样的压缩预算下，跨语言差距很小，甚至没有统计学意义上的显著差异。这说明鸿沟不是"压缩"这件事本身带来的，而是某种特定压缩方式独有的问题。
第二层对照：会不会是某个特定的编码器骨干网络（比如XLM-R）有问题？研究者换了另一个用mBERT做骨干的LLMLingua-2版本重新测了一遍，结果鸿沟模式几乎原样复现，两个不同骨干网络在各语言上的表现差距高度相关。这说明问题不在于用了哪种神经网络结构。
第三层对照：他们又测试了一个完全独立的商业化压缩系统Kompress-v2（Headroom生产环境用的压缩层），它用的是ModernBERT架构，训练数据横跨17个文本领域。结果依然是同样的模式：在实现压缩比0.5左右时，8个可测试的非英语语言全部出现显著性能差距。
三种不同架构、不同训练细节的压缩器，表现出几乎一致的失效模式。这时候答案已经呼之欲出：它们唯一的共同点，是训练监督数据都主要来自英语。LLMLingua-2的训练数据是对英语会议记录数据集MeetingBank做GPT-4蒸馏得到的判断标签，Kompress-v2的训练数据虽然覆盖了17个领域，但依然是英语主导。
真正的证据来自第四个压缩器，XProvence。
这是一个专门为多语言场景设计的查询感知型压缩器，建立在多语言重排序模型BGE-M3之上，用16种语言的银标签数据训练而成。
查询感知型压缩：这种压缩方式会参考用户提出的具体问题，只保留和这个问题相关的内容，而不是像前面提到的压缩器那样，不管问题是什么，一律用统一标准判断哪些内容重要。
XProvence的v1版本，在同样的测试条件下，跨语言的表现差距几乎完全消失，没有一种语言出现统计显著的鸿沟。这个对照实验相当有说服力：换成多语言训练数据后，鸿沟就不见了，这基本坐实了问题根源在训练数据的语言构成，而不是模型架构本身。
这个发现的意义不小。这意味着这不是一个无解的技术天花板，而是一个可以通过改变训练数据来源解决的工程问题。
不过，故事到这里还有一个转折，而且是个挺讽刺的转折。
XProvence后来发布了v2版本，训练数据换成了翻译版的MS MARCO，而不是v1那种原生多语言标注数据。结果在保守设置下v2依然保持了跨语言的公平性，但一旦调到激进压缩阈值，中文再次出现严重问题：92%的中文测试样本被压缩成了空文本，什么内容都没剩下，而且系统没有给出任何警告或报错提示。
深挖原因发现，这背后还有个技术细节：XProvence配套的多语言分句工具，把整段中文当成一个不可分割的单位处理，而其他语言平均能被切分成3到4个句子片段。这意味着中文的压缩只有"全保留"和"全删除"两种极端选择，没有中间地带。这是一个典型的工程细节被忽略导致系统性失败的例子，就像一把设计给右手使用的剪刀，硬塞给左撇子用，看起来功能没问题，实际操作起来完全不对劲。
这也提醒我们，用翻译数据替代原生多语言数据训练，看似省事，但翻译数据可能在语义置信度分布上和原生数据不同，一旦这种偏差撞上某个语言在工程实现上的薄弱环节（比如中文缺乏空格分词），后果可能比完全没做多语言适配还严重。
**发现三：长文本场景下，压缩后的非英语内容比不给还糟**
如果说前面的实验还只是"表现打折扣"，那接下来的长文本压力测试，展示的就是彻底的失效。
研究者设计了一个更贴近真实使用场景的测试：把目标段落埋在7个同语言的干扰段落中间，模拟真实检索增强生成里"信息藏在一堆文档里"的情况，总长度大约2000到3000个token。
在这种设定下，用GPT模型测试发现，压缩后的立陶宛语、拉脱维亚语和波兰语上下文，表现全都跌到了"不给任何上下文"的水平线以下。也就是说，用户花了token的钱，压缩后的内容却没有提供任何实际价值，甚至可能比什么都不给还误导模型。
这就好比你花钱雇了个搬家工人，结果他把你最重要的一箱东西弄丢了，还顺带把家里搞得更乱，你最后不仅没享受到服务，处境比自己一个人搬家还糟。
有意思的是，这个鸿沟并不是所有任务类型都存在。研究者还测试了一个法律文档主题分类任务（MultiEURLEX），发现在这类"只需要抓住表面关键词、不依赖细致语法结构理解答案"的任务上，压缩几乎是免费的，甚至只用文档标题（相当于只保留5%的内容）就能匹配甚至超过完整文档的效果，在所有测试语言上都是如此。
这说明语言鸿沟这件事，本质上是任务依赖的：如果答案分散在文本的语法结构和上下文关联里（比如阅读理解），压缩就危险；如果答案就是几个关键词能不能被抓到（比如主题分类），压缩基本无害。
**为什么会这样：语法信息藏在容易被删掉的地方**
论文后面做了一个很有意思的机制分析，试图搞清楚压缩器到底删错了什么。
研究者发现，在压缩到33%的情况下，立陶宛语、拉脱维亚语、波兰语里那些带数字的词，被保留的概率反而比英语更高（分别是0.70、0.78、0.70，英语是0.61）。但即便如此，这些语言的效果下降得比英语严重得多。
这说明压缩器并不是简单粗暴地把事实性内容删掉，它删掉的更像是维系语法结构的"胶水"部分。
对于立陶宛语、拉脱维亚语、波兰语这类语言，句子里谁是施事者谁是受事者，很大程度上不是靠词序决定的，而是靠词尾的格变化（也就是名词根据在句中扮演的角色改变词尾形式）来标记的。英语训练出来的压缩器，学到的经验是"这些看起来次要的功能性词尾信息量低，可以删"，可这些词尾恰恰是判断"谁对谁做了什么"的关键线索。删掉它们，句子的骨架就散了，就算保留了所有名词和数字，模型也读不懂谁是主语谁是宾语了。
研究者为此专门设计了一个针对立陶宛语的格标记探测实验，用最小对立句子对（内容几乎一样，只有语法角色分配不同）来验证这个机制。初步结果显示，完整文本下两种语言都能做到满分，但压缩到33%之后，英语依然保持98.7%的正确率，立陶宛语却掉到82.7%，而且模型的错误全都表现为"回答不确定"，而不是把施事者和受事者搞反，这和"压缩破坏了判断依据但没有编造错误答案"的解释相吻合。
对于中文，机制则完全不同。中文是孤立语，没有格变化，大部分词由多个汉字组成。压缩器如果按字符级别删除，很容易把一个完整的词拆成不完整或者根本不存在的词。而且中文里"把""被""了""的"这类高频虚词，恰恰是英语训练出来的分类器最容易判断为"低信息量、可以删"的对象，可这些虚词在中文语法里承担着标记宾语、被动语态、时态、修饰关系的重要功能。
这就好比拆一台机器时，把那些看起来不起眼的螺丝钉全部当废料扔掉，因为它们体积小、看起来没什么技术含量，可实际上正是这些螺丝钉把关键部件固定在一起。少了它们，机器零件都还在，但已经没法正常运转了。
**一个意外的解法：先翻译再压缩**
论文还测试了一个挺实用的替代方案：把非英语内容先用翻译模型（NLLB-200）翻译成英语，再用英语压缩器压缩，最后再让模型基于压缩后的英语内容回答问题。
结果显示，这套"先翻译后压缩"的流程，在立陶宛语、芬兰语、爱沙尼亚语这三种语言上，用大约18%的token成本，效果反而超过了直接用原生语言压缩到33%的效果，最多领先10个百分点。
这个结果算是间接印证了前面的判断：既然压缩鸿沟主要跟着"表层语言"走而不是跟着"语义内容"走，那把语言先换成压缩器最擅长的英语，再进行压缩，自然能规避那个鸿沟。
不过论文也很坦诚地指出了这个方案的局限：他们用的测试语料本身是从英语翻译过来的平行语料，这意味着这些"非英语"文本原本就带有一些英语句法痕迹，可能让翻译流程显得比实际情况更有利；另外翻译本身也要花时间，对于需要即时响应的交互场景可能不太划算。
**写在后面**
读完这篇论文，最触动我的一点是，中文明明在分词层面吃的亏最小，却在压缩层面摔得最惨。如果只看token计价的数字，你会觉得中文用户在这套体系里算是相对"占便宜"的一方，但真正跑起完整流程，中文却是那个被压缩到"消失"的语言。这提醒我，衡量一个系统对不同语言是否公平，不能只看某一个环节的数字，得把整条链路串起来看，有可能前面省下的钱，后面加倍还回去了。
另一个让我意外的细节是，Kompress-v2这种商业化生产系统，处理中文时几乎是原样返回，改动比例只有4%到9%，等于完全没起作用。而这个问题早在论文正式发表之前，就已经被开源社区里一个专门给Headroom做中文适配的第三方分支（headroom-zh）独立发现并解决了。也就是说，实际用户比学术界更早察觉到了这个坑，只是没人系统性地量化过它到底有多深、影响多广。这种"民间先发现问题，学术研究后来补上系统证据"的顺序，挺值得琢磨的。
还有一个问题论文没有完全回答：如果一家公司现在就要上线一个面向全球用户的产品，又不想承担翻译流程的延迟成本，又拿不到XProvence这种非商业授权模型的商用许可，那除了退回到最朴素的TF-IDF或者截断方法，还有没有更聪明的折中方案？这大概是接下来最值得追问的问题。
Q&A
Q1：LLMLingua-2压缩工具对中文的压缩效果为什么特别差？
A：论文发现在压缩到只保留33%内容时，中文的归一化上下文利用率跌到负值，也就是压缩后的效果比完全不给上下文还差。原因不是中文分词代价高（中文分词代价反而是十种语言里最低的），而是压缩器的训练数据几乎全是英语，删除了中文里承担关键语法功能的虚词和字符组合，导致句子语义结构被破坏。
Q2：为什么确定性压缩方法（比如TF-IDF、截断）没有出现跨语言鸿沟，而学习型压缩器有？
A：论文通过对照实验发现，跨语言鸿沟的根源是训练监督数据的语言构成，而不是压缩技术本身。确定性方法不依赖语言相关的训练数据，靠固定规则运作，所以各语言表现接近。而学习型压缩器如果只用英语数据训练，就会学到偏向英语语法特征的删除策略，用到其他语言上就会误删关键信息。
Q3：有没有办法解决非英语文本压缩效果差的问题？
A：论文测试了两种思路。一是使用原生多语言训练数据训练的压缩器，比如XProvence v1版本，跨语言差距基本消失。二是采用先翻译成英语再压缩的流程，在立陶宛语、芬兰语等语言上，用约18%的token成本就能达到甚至超过原生语言压缩33%的效果。
