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%内容