Milvus
Zilliz
  • Home
  • Blog
  • 我们如何为 RAG 上下文剪枝和标记保存构建语义高亮模型

我们如何为 RAG 上下文剪枝和标记保存构建语义高亮模型

  • Engineering
January 19, 2026
Cheney Zhang, Jiang Chen

问题所在:RAG 噪音和令牌浪费

向量搜索是 RAG 系统(企业助理、人工智能 Agents、客户支持机器人等)的坚实基础。它能可靠地找到重要的文档。但是,仅靠检索并不能解决上下文问题。即使是经过良好调整的索引也会返回具有广泛相关性的语块,而这些语块中只有一小部分句子真正回答了查询。

在生产系统中,这种差距会立即显现出来。一个查询可能会拉入几十个文档,每个文档都有数千个标记。只有少数几个句子包含实际信号;其余的都是上下文,会增加标记的使用,减慢推理速度,并经常分散 LLM 的注意力。在 Agents 工作流程中,问题变得更加明显,因为查询本身就是多步推理的结果,而且只与检索文本的一小部分相匹配。

这就明显需要一种模型,能够识别并突出 有用的句子,忽略其余部分--本质上就是句子级相关性过滤,或者许多团队所说的上下文剪枝。这样做的目的很简单:保留重要的部分,在噪音到达 LLM 之前就将其丢弃。

传统的基于关键字的高亮处理无法解决这个问题。例如,如果用户问 "如何提高 Python 代码的执行效率?",关键字高亮器会挑出 "Python "和 "效率",但会漏掉真正回答问题的句子--"使用 NumPy 向量操作符代替循环"--因为它与查询不共享关键字。我们需要的是语义理解,而不是字符串匹配。

用于 RAG 噪声过滤和上下文剪枝的语义高亮模型

为了让RAG构建者更轻松地完成这项工作,我们训练并开源了一个语义高亮显示(Semantic Highlighting)模型,用于识别和高亮显示检索文档中与查询语义更加一致的句子。目前,该模型在中英文两种语言中都能提供最先进的性能,并可直接插入现有的 RAG 管道中。

模型详情

  • HuggingFace: zilliz/semantic-highlight-bilingual-v1

  • 授权许可MIT (商业友好)

  • 架构:基于 BGE-M3 Reranker v2 的 0.6B 纯编码器模型

  • 语境窗口8192 个 token

  • 支持语言英语和中文

语义高亮(Semantic Highlighting)可提供相关性信号,以便只选择长检索文档中有用的部分。在实践中,该模型可实现以下功能

  • 提高可解释性,显示文档中哪些部分真正重要

  • 只向 LLM 发送突出显示的句子,令牌成本降低 70-80

  • 更高的答案质量,因为模型看到的无关上下文更少

  • 调试更容易,因为工程师可以直接检查句子级别的匹配情况

评估结果:实现 SOTA 性能

我们在多个数据集上对语义高亮显示模型进行了评估,这些数据集涵盖英语和汉语,同时还包括域内和域外条件。

基准套件包括

  • 英语多跨度 QA:multispanqa

  • 英语域外维基百科:wikitext2

  • 中文多跨 QA:multispanqa_zh

  • 中文域外维基百科:wikitext2_zh

评估的模型包括

在所有四个数据集中,我们的模型都名列前茅。更重要的是,它是唯一一个在中英文两个方面都表现出色的模型。同类竞争模型要么只专注于英文,要么在中文文本上表现出明显的性能下降。

我们如何构建这个语义高亮模型

为这项任务训练一个模型并不难;训练一个能处理早期问题并提供接近 SOTA 性能的模型才是真正的工作。我们的方法主要集中在两方面:

  • 模型架构:使用纯编码器设计以实现快速推理。

  • 训练数据:使用具有推理能力的 LLM 生成高质量的相关性标签,并利用本地推理框架扩展数据生成。

模型架构

我们建立的模型是一个轻量级的纯编码器网络,它将上下文剪枝视为标记级相关性评分任务。这一设计灵感来自于 Naver 在 2025 年国际词表大会上推出的上下文剪枝方法Provence,该方法将剪枝从 "选择正确的大块 "重构为 "为每个标记评分"。该方法将剪枝从 "选择正确的语块 "重塑为 "对每个标记进行评分",与语义高亮自然吻合,在语义高亮中,细粒度信号至关重要。

纯编码器模型并不是最新的架构,但在这里仍然非常实用:它们速度快、易于扩展,可以并行地为所有标记位置生成相关性评分。对于生产型 RAG 系统来说,速度优势远比使用更大的解码器模型更重要。

计算标记级相关性得分后,我们将其汇总为句子级得分。这一步将嘈杂的标记信号转化为稳定、可解释的相关性指标。高于可配置阈值的句子会被突出显示,其他句子则会被过滤掉。这样就形成了一种简单可靠的机制,用于选择与查询真正相关的句子。

推理过程

在运行时,我们的语义高亮模型遵循一个简单的流程:

  1. 输入--流程从用户查询开始。检索到的文档被视为相关性评估的候选上下文。

  2. 模型处理--查询和上下文被串联成一个序列:[BOS] + 查询 + 上下文

  3. 标记评分--上下文中的每个标记都会被赋予 0 到 1 之间的相关性分数,以反映其与查询的相关程度。

  4. 句子聚合--在句子层面聚合标记得分,通常是通过平均的方式,为每个句子得出相关性得分。

  5. 阈值过滤--得分高于可配置阈值的句子会被突出显示并保留下来,而得分低的句子则会被过滤掉,然后再传给下游 LLM。

基础模型:BGE-M3 Reranker v2

我们选择 BGE-M3 Reranker v2 作为基础模型有几个原因:

  1. 它采用适合标记和句子评分的编码器架构

  2. 支持多种语言,对英文和中文都进行了优化

  3. 提供适合较长 RAG 文档的 8192 个标记上下文窗口

  4. 维持 0.6B 参数--足够强大,但计算量不大

  5. 确保基础模型具有足够的世界知识

  6. 针对 Rerankers 进行训练,这与相关性判断任务密切相关

训练数据:带有推理的 LLM 注释

一旦我们确定了模型的架构,下一个挑战就是建立一个能真正训练出可靠模型的数据集。我们首先研究了 Open Provence 是如何处理这个问题的。他们的方法使用公共 QA 数据集和小型 LLM 来标注相关句子。这种方法的扩展性很好,而且易于自动化,因此对我们来说是一个很好的基准。

但我们很快就遇到了他们描述的同样问题:如果要求 LLM 直接输出句子级标签,结果并不总是稳定的。有些标签是正确的,其他的则有问题,而且事后很难清理。全手工标注也不是一种选择--我们需要的数据量远远超出了手工标注的范围。

为了在不牺牲可扩展性的前提下提高稳定性,我们做出了一项改变:LLM 必须为其输出的每个标签提供一个简短的推理片段。每个训练示例都包括查询、文档、句子跨度以及对句子相关或不相关原因的简要解释。这一小小的调整使注释更加一致,并为我们在验证或调试数据集时提供了具体的参考。

事实证明,加入理由说明具有惊人的价值:

  • 提高注释质量:写出理由可以起到自我检查的作用,从而减少随意或不一致的标注。

  • 更好的可观察性:我们可以看到为什么会选择某个句子,而不是把标签当作黑箱。

  • 更容易调试:当出现问题时,推理可以让我们很容易地发现问题出在提示、领域还是注释逻辑上。

  • 可重复使用的数据:即使我们将来改用不同的标注模型,推理轨迹仍可用于重新标注或审核。

注释工作流程如下

用于注释的 Qwen3 8B

我们选择 Qwen3 8B 进行标注,是因为它通过输出原生支持 "思考模式",从而更容易提取一致的推理轨迹。较小的模型无法为我们提供稳定的标签,而较大的模型对于这种管道来说速度较慢,而且成本过高。Qwen3 8B 在质量、速度和成本之间取得了恰当的平衡。

我们使用本地 vLLM 服务而不是云 API 运行所有注释。这为我们带来了高吞吐量、可预测的性能和更低的成本--实际上是用 GPU 时间换取 API 令牌费用,这在生成数百万个样本时是更划算的交易。

数据集规模

我们总共创建了500 多万个双语训练样本,其中英文和中文样本各占一半。

  • 英文数据源:MS MARCO、Natural Questions、GooAQ

  • 中文来源DuReader, 中文维基百科, mmarco_chinese

部分数据集来自于对开放普罗旺斯等项目使用的现有数据的重新标注。其余数据集来自原始语料库,首先创建查询-上下文对,然后使用我们基于推理的管道对其进行标注。

所有标注的训练数据也可在 HuggingFace 上获取,供社区开发和训练参考:Zilliz 数据集

训练方法

模型架构和数据集准备就绪后,我们在8× A100 GPU上对模型进行了三个历元的训练,端到端大约耗时9 小时

注:训练只针对负责语义高亮任务的剪枝头。我们没有对Rerankers Head 进行训练,因为只专注于剪枝目标会为句子级相关性评分带来更好的结果。

真实世界案例研究

基准测试只能说明问题的一部分,下面是一个真实的案例,展示了模型在常见边缘情况下的表现:当检索到的文本既包含正确答案,又包含非常诱人的干扰项时。

查询: 谁写了《杀死一只圣鹿》?

上下文(5 句):

1\. The Killing of a Sacred Deer is a 2017 psychological horror film directed by Yorgos Lanthimos,

with a screenplay by Lanthimos and Efthymis Filippou.

2. The film stars Colin Farrell, Nicole Kidman, Barry Keoghan, Raffey Cassidy,

Sunny Suljic, Alicia Silverstone, and Bill Camp.

3. The story is based on the ancient Greek playwright Euripides’ play Iphigenia in Aulis.

4. The film tells the story of a cardiac surgeon (Farrell) who secretly

befriends a teenager (Keoghan) connected to his past.

5. He introduces the boy to his family, who then mysteriously fall ill.

正确答案:第 1 句(明确指出 "编剧是兰斯莫斯和 Efthymis Filippou")。

这个例子有一个陷阱:第 3 句提到 "欧里庇得斯 "写了原剧。但问题问的是 "电影《杀死一只圣鹿》是谁写的",答案应该是电影的编剧,而不是几千年前的希腊剧作家。

模型结果

模型找到正确答案?预测
我们的模型所选句子 1(正确)和 3
XProvence v1只选择了句子 3,错过了正确答案
XProvence v2只选择了句子 3,错过了正确答案

关键句得分比较:

句子我们的模型XProvence v1XProvence v2
句子 1(电影剧本,正确答案)0.9150.1330.081
句子 3(原创剧本,干扰项)0.7190.9470.802

XProvence 模型:

  • 强烈被 "欧里庇得斯 "和 "戏剧 "吸引,给句子 3 打出接近满分的分数(0.947 和 0.802)

  • 完全忽略实际答案(句子 1),得分极低(0.133 和 0.081)

  • 即使将阈值从 0.5 降到 0.2,它仍然无法找到正确答案

我们的模型

  • 正确给予句子 1 最高分 (0.915)

  • 由于句子 3 与背景相关,因此仍赋予其一定的相关性 (0.719)

  • 以 ~0.2 的差值将两个句子明确分开

这个例子显示了模型的核心优势:理解查询意图,而不仅仅是匹配表面关键字。在这种情况下,"《杀死一只圣鹿》是谁写的 "指的是电影,而不是古希腊戏剧。我们的模型能够捕捉到这一点,而其他模型则会被强烈的词汇线索所干扰。

试用并告诉我们您的想法

我们的zilliz/semantic-highlight-bilingual-v1模型现已在 MIT 许可下完全开源,可供生产使用。您可以将其插入到您的 RAG 管道中,根据自己的领域对其进行微调,或在其基础上构建新的工具。我们也欢迎来自社区的贡献和反馈。

Milvus和Zilliz Cloud中提供的语义高亮功能

语义高亮也直接内置于MilvusZilliz Cloud(全面管理的Milvus)中,让用户清楚地了解每份文档被检索的原因。您无需扫描整个文档块,而是可以立即看到与您的查询相关的具体句子--即使措辞并不完全匹配。这使得检索更容易理解,调试速度也更快。对于 RAG 管道而言,它还明确了下游 LLM 应关注的内容,这有助于进行及时的设计和质量检查。

免费试用完全托管的Zilliz Cloud中的语义高亮(Semantic Highlighting)功能

我们很乐意听听您的使用情况--错误报告、改进意见或您在将其集成到工作流程中时发现的任何问题。

如果您想了解更多详情,请随时加入我们的Discord 频道或预约 20 分钟的Milvus Office Hours会议。我们很乐意与其他建设者聊天并交换意见。

鸣谢

这项工作建立在许多伟大的想法和开源贡献的基础之上,我们希望强调那些使这一模型成为可能的项目。

  • Provence使用轻量级编码器模型为上下文剪枝引入了一个简洁实用的框架。

  • 开放式普罗旺斯提供了坚实、精心设计的代码库--训练管道、数据处理和模型头--采用许可授权。这为我们的实验提供了一个坚实的起点。

在此基础上,我们又做出了一些自己的贡献:

  • 使用LLM 推理生成更高质量的相关性标签

  • 创建近 500 万个与真实 RAG 工作负载相一致的双语训练样本

  • 选择更适合长语境相关性评分的基础模型(BGE-M3 Reranker v2)

  • 只训练剪枝头,使模型专门用于语义加亮

我们非常感谢 Provence 和 Open Provence 团队公开发布他们的工作成果。他们的贡献大大加快了我们的开发速度,使本项目成为可能。

    Try Managed Milvus for Free

    Zilliz Cloud is hassle-free, powered by Milvus and 10x faster.

    Get Started

    Like the article? Spread the word

    扩展阅读