Milvus 3.0 开源解读｜词法+语义高亮，如何解决Agent的搜索噪音？

发布日期：2026-08-18 21:18:46 浏览次数： 1686

作者：Zilliz

微信搜一搜，关注“Zilliz”

RAG与Agent用到深水区，一定会遇到这个问题：明明检索结果没什么问题，但模型输出结果似乎总是差点意思，上下文成本也一直居高不下。

根本原因在于，为了将所有相关的内容完整召回，经常一次query，可以打捞出三五段，甚至十段文档给LLM。

如果每篇文档几千字，一个query就要消耗几万个token。但问题是，这10篇文档里，真正有用的句子可能只有几十句，而剩下的，全是噪音。

大量的噪音灌入，不仅浪费token，也分散了LLM注意力。

对人类用户来说同样如此，电商、客服RAG中，经常会有几千字的技术文档、几十页的合同或很长的客服记录，阅读者打开文档，再逐段寻找“重点”，不仅搜寻麻烦，还要多一个文档下载过程。

为了解决这一问题，在Milvus 3.0中，我们引入了最新的Highlight能力，可以对与查询相关的文本进行词法（BM25 搜索文本或显式的TextMatch查询匹配 token）或者语义层面的高亮：短文本直接展示匹配内容，长文本截取重点及附近上下文，从而降低大模型的上下文长度，也让电商、知识库等场景的检索变得更加高效、直观。

以下为本次高亮能力升级的具体解读。

01 词法高亮：通过Token匹配高亮

作为基础、最常用的方案，词法高亮的逻辑和 BM25、Text Match 搜索一脉相承，复用同一套分词规则（analyzer）来处理查询和结果文本；匹配到命中的词汇后，直接按照它们在原文中的位置插入高亮标记，保证搜索命中的词项和结果展示的边界完全一致，不会出现错位偏差。

查询与结果文本 → analyzer → token 匹配 → 原文位置 → 高亮结果

使用上它有两种灵活的配置方式。

如果是配合 BM25 搜索使用，只需开启highlight_search_text=True，系统就会直接用当前的搜索关键词生成高亮。比如搜索 “BM25 混合搜索”，返回的标题 “BM25 与混合搜索的配置方法” 会自动标注出匹配的关键词，让用户一眼看到命中点。

from pymilvus import LexicalHighlighter, MilvusClientclient = MilvusClient(uri="http://localhost:19530")highlighter = LexicalHighlighter(    pre_tags=[""],    post_tags=[""],    highlight_search_text=True,)results = client.search(    collection_name="document_titles",    data=["BM25 混合搜索"],    anns_field="title_sparse",    search_params={"metric_type": "BM25"},    limit=10,    output_fields=["title"],    highlighter=highlighter,)

如果需要自定义匹配规则，或是给向量搜索结果补充关键词匹配证据，也可以通过highlight_query显式指定 TextMatch 条件，灵活设置目标字段和匹配文本。

highlighter = LexicalHighlighter(    highlight_search_text=False,    highlight_query=[{        "type": "TextMatch",        "field": "title",        "text": "BM25 混合搜索",    }],    pre_tags=[""],    post_tags=[""],)

当前显式词法高亮查询支持 TextMatch。它只在已经返回的结果中查找并标记匹配 token，不扩大候选集，也不重新排序。它也可以用于向量搜索结果，为结果补充指定关键词的匹配证据。

当目标字段变成长正文时，词法高亮不会返回完整文本，而是以片段的形式输出匹配内容。

词法高亮的结果以 fragment 组织。默认 fragment_size 为 100 个字符，num_of_fragments 为 5。因此，对于超过 100 个字符的文本，高亮结果通常不会覆盖全文，而是自动返回匹配位置附近的 fragment。

如果多个匹配落在同一个 fragment 范围内，它们会合并到同一个片段；如果匹配分布在文本的不同位置，则会按原文顺序生成多个 fragment，直到达到 num_of_fragments 的限制。

例如，搜索“BM25 调优”后，一篇文档可能分别在“索引配置”“查询参数”和“性能排查”章节中出现相关内容。可以进一步调整 fragment 参数，控制上下文范围和返回数量：

highlighter = LexicalHighlighter(    pre_tags=[""],    post_tags=[""],    highlight_search_text=True,    fragment_offset=30,    fragment_size=160,    num_of_fragments=3,)

结果可能包含：

[    "...创建稀疏索引时，mark>BM25mark> 的参数会影响...",    "...查询阶段可以通过这些配置完成 mark>BM25mark> mark>调优mark>...",    "...排查延迟时，需要同时检查 mark>BM25mark> 查询参数...",]

如果希望展示更完整的上下文，可以通过 fragment_offset 和 fragment_size 调整片段范围；num_of_fragments 用于控制最多返回多少段。fragment 按匹配内容在原文中的先后顺序返回，不会按照 BM25 分数重新排序。

这些片段会随每个搜索结果的 highlight 字段返回。即使正文没有作为普通输出字段返回，Milvus 也可以取得高亮所需的文本并生成片段，避免为了展示少量重点而返回完整正文。

02 语义高亮：对文本进行单独解读

词法高亮的匹配前提是查询和文档共享相同的词汇，但这也构成了它的能力边界。

当二者语义相关但表述完全不同时 —— 比如用户搜 “账号登不上怎么恢复”，文档里写的是 “连续验证失败后可由管理员解除账户锁定”—— 词法匹配就很难精准定位重点，这时候就需要语义高亮发挥作用。

语义高亮是可以搜索结果返回后，通过独立的语义模型对文本做二次解读，独立判断查询与各文本片段的语义关联度，筛选出最相关的内容进行标记。这样，哪怕查询和文档没有重合的关键词，只要语义相通，就都能被准确识别出来。

但是在构建语义高亮能力的过程中，我们发现，市面上各种已有的语义高亮模型，要么只支持英文，要么上下文窗口太小（512 token），要么协议不友好（不允许商业使用）。没有一个能同时满足：中英文都强、窗口够大、泛化能力好、协议友好。

所以，我们构建并开源了内部最新的Semantic Highlight（语义高亮）模型并将其作为Milvus 3.0能力的一环。

详情参考官宣，Milvus开源语义高亮模型：告别饱和检索，帮RAG、agent剪枝80%上下文

它不仅支持中英文双语处理，帮助用户更好的理解高亮核心内容。同时，由于Semantic Highlight 和 Context Pruning 上下文剪枝本质是同一技术的一体两面。这个能力也可以用于 Context Pruning 场景，在 Agent 应用中对上下文做精准裁剪，降低大模型的 token 成本。

使用时，只要通过 SemanticHighlighter 传入查询语句、待分析的文本字段和对应的模型部署 ID，返回结果就会包含带高亮标记的片段，以及对应的语义相关性分数。

from pymilvus import SemanticHighlighterhighlighter = SemanticHighlighter(    queries=["怎样恢复无法登录的账号"],    input_fields=["content"],    pre_tags=[""],    post_tags=[""],    model_deployment_id="your-model-deployment",)results = client.search(    collection_name="support_articles",    data=[query_embedding],    anns_field="embedding",    search_params={"metric_type": "COSINE"},    limit=10,    output_fields=["title"],    highlighter=highlighter,)

其中，queries 提供需要理解的问题，input_fields 指定需要分析的文本字段。返回结果中除了相关片段，还可以包含对应的片段分数。

场景上，语义高亮适合长文档问答、RAG 引用、客服知识库和查询改写较多的场景。它寻找的是语义关联，而不是要求查询和文档共享相同 token。