推荐语
告别机械高亮，语义高亮让信息检索更精准高效，解决RAG和Agent场景中的核心痛点。核心内容： 1. 传统关键词高亮的局限性与应用场景中的不足 2. 语义高亮技术的市场现状与挑战 3. 自研双语语义高亮模型的创新解决方案
杨芳贤
53AI创始人/腾讯云(TVP)最具价值专家
文：张晨
今天聊一聊怎么在RAG、Agent场景中实现语义高亮（Semantic Highlight）。
在AI落地的过程中，我们不管是用电商搜东西、用RAG查文档，还是靠AI Agent做信息挖掘，大家做检索最核心的需求其实就一个：快速找到有用的信息。而高亮功能，就是帮我们快速定位信息的关键。
但传统基于关键词匹配的传统高亮，无法根据语义信息做内容定位，市面上已有的Semantic Highlight方案，又各有各的问题。
那么有什么办法解决以上问题？接下来，我们就从传统高亮的问题说起，聊聊语义高亮方案的市场现状，并带来我们自研的双语语义高亮模型，看看它是怎么做到跨语言、高精度找到关键语义信息的。
01
传统Highlight有什么问题
在讲语义高亮的话题之前，我们需要先理解一个概念，什么是传统的Highlight？
我们可以从一个熟悉的场景说起：打开淘宝搜索"雨衣"，返回的商品标题里，"雨衣"这个词会用高亮标出来，以提示命中的查询词。这就是传统的搜索高亮（Highlight）。
它背后的技术很简单：数据库（比如Elasticsearch等）在返回结果时，找到查询词出现的位置，用特殊标签（通常是<em>标签）包起来，前端解析后再渲染成高亮颜色。
这种高亮的核心逻辑是关键词匹配。你搜什么词，系统就标出什么词。就像小学生用荧光笔划重点，哪里出现关键词就划哪里。
但在实际落地过程中，如果只做基于关键词匹配的高亮，往往是不够的。
比如，在 电商搜索场景，用户搜"iPhone性能怎么样"，系统只能高亮"iPhone"和"性能"这两个词。但如果商品详情页写的是："搭载A15仿生芯片，跑分突破100万，日常使用流畅无卡顿"——这明明是在回答性能问题，但因为没有出现"性能"这个词，一个字都不会高亮。
用户得自己读完整段文字，才能判断这是不是他想要的信息。
到了RAG检索场景，这个问题就变得更明显了。
用户问："如何提高Python代码的执行效率？"，系统从向量数据库检索回来一篇技术文档。传统高亮只能标出"Python"、"代码"、"执行"、"效率"这几个词。但真正有用的内容可能是："使用numpy向量化操作替代循环"、"避免在循环中反复创建对象"。这些句子语义上完全在回答问题，但一个查询词都不包含，传统高亮完全标不出来。用户看着检索回来的长文档，还得自己一句句读，找哪里是答案。体验很差。
而在AI Agent场景，问题又会变得更加棘手。
Agent的搜索查询往往不是用户的原始问题，而是经过推理分解后的复杂指令。比如用户问"帮我分析一下最近的市场趋势"，Agent可能生成的查询是："检索2024年第四季度消费电子行业销售数据、同比增长率、主要竞争对手市场份额变化以及供应链成本波动情况"。这样的长查询包含多个维度的信息需求，语义关系错综复杂。
传统高亮只能机械地标出"2024年"、"销售数据"、"增长率"这些字面匹配的词。但真正有价值的分析结论——"iPhone 15系列带动了整体市场复苏"、"芯片供应紧张导致成本上升15%"——可能一个关键词都匹配不上。
Agent需要从海量检索结果中快速定位真正有用的信息，传统高亮完全无法胜任。
总而言之，传统Highlight的核心问题是只看字面，不看语义。从传统的搜索，到AI时代的RAG，AI Agent的复杂场景，这个问题正变得越来越严重。
也是因此， Semantic Highlight语义高亮开始逐渐成为搜索到AI落地场景中的核心高亮方案。
02
市面上已有的Semantic Highlight方案有什么痛点
Semantic Highlight（语义高亮）的本质，是基于语义理解，做关键内容的高亮显示。用户问"iPhone性能怎么样"，即使文本里没有"性能"这个词，只要语义上在回答这个问题（比如提到芯片、跑分、流畅度），也会被高亮出来。
在AI时代下，这种需求实际上是相对容易实现的，但长期以来，无法落地，主要是考虑到成本和效率的问题。
因为，高亮是高频操作，用户每搜一次就要标注一次，如果调用大模型，延迟高、成本大，根本不现实。也是因此，我们需要一个几百MB大小、推理速度在毫秒级、能部署在搜索服务器上实时计算的专门的轻量级AI模型。
但问题是，市面上现有的Semantic Highlight模型，各有各的问题：
（1）OpenSearch的模型：窗口太小，泛化不足
OpenSearch今年发布了一个专门semantic highlight任务的模型：opensearch-semantic-highlighter-v1。
但它有两个致命问题。
第一是上下文窗口太小。这个模型基于BERT架构，最大只能处理512个token。换算成中文大约300-400字，英文大约400-500词。实际场景中，一篇商品详情页、一段技术文档，动辄上千字。模型只能看到前面一小段，后面的内容直接截断。这就像让一个人只读文章的前两段就判断全文重点，根本不现实。
第二是out-of-domain（域外泛化）能力差。什么是out-of-domain？简单说就是模型在训练时没见过的数据类型。比如模型在新闻数据上训练，拿去标注电商评论，效果就会明显下降。我们在实验中发现，OpenSearch模型在in-domain数据上F1能到0.72，但在out-of-domain数据上直接掉到0.46。这种不稳定性在实际应用中很危险。更关键的是，它不支持中文。
（2）Provence/XProvence：差强人意，协议限制
Naver发布的Provence系列是另一个选择，他是专门为Context Pruning（上下文剪枝）训练的模型，模型原理可以参考我们的上一篇文章。
虽然它是处理Context Pruning任务的模型，但是，Context Pruning和Semantic Highlight的技术路线完全相同，都是基于语义匹配，找出最相关的部分，排除掉不相关的部分。所以，Provence系列也可以用于Semantic Highlight任务。Provence本身是英文模型，效果确实不错。XProvence是它的多语言版本，支持中文、日文、韩文等十几种语言。如果为了满足我们的中英双语需求，貌似可以考虑XProvence。
但Provence/XProvence也有几个问题：
第一，XProvence在英文上不如Provence，多语言模型很难在所有语言上都做到极致。从评测数据来看，XProvence在英文数据集上的表现比Provence弱一些。对我们来说，英文场景同样重要。
第二，中文水平表现差强人意。XProvence支持十几种语言，中文只是其中之一。多语言训练时，每个语言分到的数据量都不会特别大。这就像一锅粥，加的料越多，每种料的味道就越淡。
第三，Pruning任务和Highlight任务有微妙的差别。Provence系列是为Context Pruning训练的。剪枝的策略是宁可多留，不要漏掉，因为漏了关键信息，LLM就答不上来了。但Semantic Highlight更强调精准，我们要高亮的是最核心的句子，不是把半篇文章都标黄。
第四，协议问题。Provence和XProvence使用的是CC BY-NC 4.0协议，这个协议不允许商业使用。
（3）Open Provence：缺少中文支持
我们发现了一个宝藏项目：Open Provence，这个项目把Provence的训练代码完整复现了出来。不仅有训练脚本，还有数据处理、评测工具，甚至还提供了不同规模的预训练模型。更重要的是，它是完全开源的，MIT协议，可以放心用在商业项目中。但问题是：Open Provence只支持英文和日文，没有中文。
03
官宣：我们自研了Semantic Highlight双语模型
综合来看，市面上没有一个模型能同时满足这些要求：
既然市面上没有合适的模型，那就自己训练一个。
我们的核心思路是：用LLM标注高质量数据集，基于开源框架快速训练。
关键在于数据构造。我们让LLM（Qwen3 8B）在标注时输出完整的思考过程，标注流程大致如下：
这样做有三个好处：
1. 标注质量更高：模型先思考再回答，相当于自我检查
2. 可观测可调试：能看到推理过程，发现问题及时调整
3. 数据可复用：有了思考过程，将来重新标注时有参考
最终我们构造了1M+（百万级）双语训练样本，中英文各占一半。
基于BGE-M3 Reranker v2（0.6B参数，8192 tokens窗口）作为基础模型，使用Open Provence的训练框架，在8张A100上训练3个epoch，约5小时完成。
关于训练的更多技术细节（为什么用思考模式、如何选择基础模型、数据集构造流程等），我们会在下一篇文章中详细展开。
04
实测展示
我们在多个数据集上对比了不同模型的表现，包括：
英文多跨度问答数据集（multispanqa）
维基百科out-of-domain数据集（wikitext2）
中文多跨度问答数据集（multispanqa_zh）
维基百科out-of-domain数据集中文版（wikitext2_zh）
评测模型包括Open Provence系列、Naver的Provence/XProvence系列、OpenSearch的semantic-highlighter，以及我们训练的双语模型。
英文数据集
中文数据集
可以看到，在双语评测中，我们的模型平均F1均达到了SOTA水平，击败了之前所有的模型和方案，而且在中文测试评估上，大幅超过了同样能够处理中文的XProvence系列模型。
更重要的是，我们的模型在中英文上达到了平衡，这是其他模型难以做到的：
Open Provence只支持英文
XProvence在英文上不如Provence
OpenSearch不支持中文且泛化能力差
除了评测跑分之外，我们来看一个更有意思的例子，来直观感受一下我们的模型在实际应用中的表现。
问题："谁写了《杀死一只神圣的鹿》"
文本（共5个句子）：
1. 《杀死一只神圣的鹿》是一部2017年的心理恐怖片，由约尔戈斯·兰西莫斯执导， 剧本由兰西莫斯和埃夫西米斯·菲利波编写。2. 影片主演包括科林·法瑞尔、妮可·基德曼、巴里·基奥汉、拉菲·卡西迪、 桑尼·苏尔吉奇、艾丽西亚·西尔维斯通和比尔·坎普。3. 故事基于古希腊剧作家欧里庇得斯的剧本《在奥利斯的伊菲革尼亚》。4. 影片讲述了一位心脏外科医生（法瑞尔）秘密与一个与他过去有联系的 少年（基奥汉）交朋友的故事。5. 他把这个男孩介绍给他的家人，后者开始神秘生病。
正确答案：第1句（明确说明"剧本由兰西莫斯和埃夫西米斯·菲利波编写"）
这个例子有个陷阱：第3句提到了"欧里庇得斯"写了原作剧本。但问题问的是"谁写了电影《杀死一只神圣的鹿》"，答案应该是电影编剧，而不是几千年前的希腊剧作家。
各模型表现：
关键句子得分对比：
XProvence的问题：
我们模型的表现：
给正确答案（第1句）打了0.915的高分，明确识别出"电影编剧"
也给第3句打了一定的分数（0.719），因为它确实提到了"剧本"的相关信息
但区分度非常清晰：0.915 vs 0.719，差距接近0.2
这个例子展示了我们模型的核心优势：能够跳出简单的关键词匹配桎梏，理解问题的真实意图。
"谁写了《杀死一只神圣的鹿》"这个问题，在电影百科的语境下，明显是在问电影的编剧。虽然文本中同时出现了"电影编剧"和"原作剧本"两个信息，但我们的模型能准确理解用户真正想要的是哪一个。
更详细的评测报告和案例分析，我们会在后续发布。
尾声
我们目前已经在huggingface上开源我们的模型预览版的权重，让大家可以抢先用起来我们的模型。地址如下：
https://huggingface.co/zilliz/semantic-highlight-bilingual-pre
大家可以先试用起来，有问题欢迎随时反馈。
另外，我们正在将模型推理服务化，集成部署到Milvus上，做成Semantic Highlight接口，这也会很快就会和大家见面。
不久后，我们就能实现，在RAG系统里提问时，Milvus检索回来5个文档，每个文档几百字，我们不用再一个个读，系统直接把最相关的句子高亮出来，一眼就能看到答案在哪里。这不仅提升了用户体验，也让开发者更容易调试和优化，直接看到检索质量如何，哪些句子真正有用。
我们相信，Semantic Highlight会成为下一代搜索和RAG系统的标配功能。如果你对双语Semantic Highlight模型有什么想法和建议？欢迎在评论区聊聊，一起探讨！
相关链接：
Open Provence项目：https://github.com/hotchpotch/open_provence
Provence论文：https://arxiv.org/abs/2501.16214
XProvence模型：https://huggingface.co/naver/xprovence-reranker-bgem3-v1
OpenSearch Semantic Highlighter：https://huggingface.co/opensearch-project/opensearch-semantic-highlighter-v1
Milvus：https://milvus.io
张晨
Zilliz Algorithm Engineer
粤ICP备14082021号
免费POC，
零成本试错
