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

Milvus 3.0推出词法+语义高亮能力，精准解决Agent搜索噪音，降低上下文成本，提升检索效率。
核心内容：
1. RAG与Agent面临的搜索噪音问题及影响（上下文成本高、噪音分散注意力）
2. Milvus 3.0的Highlight能力：词法+语义高亮解决方案
3. 词法高亮的具体实现（BM25/TextMatch匹配，Token级高亮）

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,)

结果可能包含：

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

如果希望展示更完整的上下文，可以通过 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。03 使用须知需要注意的是，语法高亮与语义高亮均为基于搜索结果的后处理能力，不参与召回与排序，不影响结果顺序与分数，也不能完整解释相关性分数的计算过程。此外，当前 Milvus 实现中的语义高亮依赖配置好的外部高亮服务或模型部署，不是通用的本地离线能力。具体可用性取决于产品、部署方式和版本，应以目标环境文档为准。本文作者： 岳志澄，Senior Software Engineer at Zilliz

阅读推荐官宣开源｜Milvus 3.0 正式发布Milvus 3.0 开源解读之backfill｜亿级 AI 数据，如何做高效特征回填Milvus 3.0 开源解读｜从Kafka、Pulsar到Woodpecker，数据库如何低延迟、低成本的写入Milvus 3.0 开源解读之Manifest｜AI 数据管理，应该彻底放弃文件中心架构Milvus 3.0 开源解读之，数据库原生聚合排序如何取代应用侧Pandas胶水代码Milvus 3.0开源解读之Regex |从=~到NGRAM，如何选择最优性价比的正则过滤Milvus 3.0 开源解读之Snapshot|无需复制embedding数据的Milvus Collection视图Milvus 3.0 开源解读｜自定义词典如何优化BM25 与Text Match 的专业词理解能力Milvus 3.0 开源解读｜如何借助原生 TEXT 类型和 LOB 高效管理原始文本

登录查看剩余 70% 内容