Home
Blog
我們如何為 RAG 上下文剪枝和代號儲存建立語意強調模型

我們如何為 RAG 上下文剪枝和代號儲存建立語意強調模型

Engineering

January 19, 2026

Cheney Zhang, Jiang Chen

問題RAG 噪音與代幣浪費

矢量搜尋是RAG 系統 (企業助理、AI 代理、客戶支援機器人等) 的穩固基礎。它能可靠地找到重要的文件。但單靠檢索並不能解決上下文問題。即使是經過良好調校的索引，也只能傳回大致相關的文件塊，而在這些文件塊中，只有一小部分的句子能真正回答查詢。

在生產系統中，這個差距會立即顯示出來。單一查詢可能會帶來數十個文件，每個文件都有數千個文字。只有極少數的句子包含實際的訊號；其餘的都是上下文，這些上下文會增加標記的使用量、減慢推理速度，並經常分散 LLM 的注意力。在代理工作流程中，這個問題變得更加明顯，因為查詢本身就是多步推理的輸出，而且只符合擷取文字的一小部分。

這顯然需要一個模型，能夠識別並強調 有用的句子，而忽略其餘的句子，也就是句子層級的相關性篩選，或許多團隊所說的上下文剪枝。目標很簡單：保留重要的部分，並在雜訊進入 LLM 之前將其剔除。

傳統的基於關鍵字的高亮度處理無法解決這個問題。舉例來說，如果使用者詢問「如何改善 Python 程式碼的執行效率？」，關鍵字高亮器會挑出「Python」和「效率」，但卻會錯過真正回答問題的句子 -「使用 NumPy 向量操作取代循環」，因為它與查詢的關鍵字並不相同。我們需要的是語意理解，而不是字串匹配。

用於 RAG 雜訊過濾與上下文剪枝的語意強調模型

為了讓 RAG 建置者能輕鬆處理這個問題，我們訓練了一個Semantic Highlighting 模型並將其開放源碼，這個模型可以識別並高亮顯示擷取的文件中與查詢在語意上更一致的句子。這個模型目前在英文和中文上都能提供最先進的效能，而且可以直接插入現有的 RAG 管道中。

模型詳細資料

HuggingFace: zilliz/semantic-highlight-bilingual-v1
原始碼授權類型MIT (商業友好)
架構：基於 BGE-M3 Reranker v2 的 0.6B 純編碼器模型
上下文視窗：8192 個字元
支援的語言：英文和中文

語義高亮（Semantic Highlighting）可提供僅選擇長檢索文件中有用部分所需的相關性信號。在實際應用中，此模型能夠

改善了可解釋性，顯示出文件中哪些部分實際上是重要的
只將高亮顯示的句子傳送至 LLM，令牌成本降低 70-80
更高的答案品質，因為模型看到的不相關上下文較少
更容易除錯，因為工程師可以直接檢查句子層級的匹配結果

評估結果：達到 SOTA 效能

我們在多個跨中英文的資料集上，在域內和域外的條件下，評估了我們的語意強調（Semantic Highlighting）模型。

基準套件包括

英文多跨度 QA：multispanqa
英文域外維基百科：wikitext2
中文多跨度 QA：multispanqa_zh
中文域外維基百科：wikitext2_zh

評估的模型包括

開放普羅旺斯系列
Naver的普羅旺斯/XProvence系列
OpenSearch 的語意詞彙查詢器
我們訓練的雙語模型：zilliz/semantic-highlight-bilingual-v1

在所有四個資料集中，我們的模型都獲得了最高排名。更重要的是，它是唯一一個在英文和中文上都持續表現良好的模型。競爭對手的模型要麼只專注於英文，要麼在中文文本上表現明顯下降。

我們如何建立這個語意強調模型

為這項任務訓練一個模型並不是困難的部分；訓練一個能夠處理早期問題，並提供接近 SOTA 效能的好模型，才是真正的工作所在。我們的方法著重於兩點：

模型架構：使用僅編碼器的設計來進行快速推理。
訓練資料：使用具備推理能力的 LLM 來產生高品質的相關性標記，並利用局部推理框架來擴大資料產生的規模。

模型架構

我們建立的模型是一個輕量級的純編碼器網路，將上下文剪枝視為標記層級的相關性評分任務。這個設計的靈感來自 Naver 在 2025 年 ICLR 上推出的上下文剪枝方法Provence，該方法將剪枝從「選擇正確的大塊」轉變為「為每個標記評分」。這一框架與語義高亮自然地結合，在語義高亮中，細粒度信號是不可或缺的。

純編碼器模型並不是最新的架構，但在此仍然非常實用：它們速度快、易於擴展，而且可以並行產生所有標記位置的相關性評分。對於生產型 RAG 系統來說，速度上的優勢遠比使用較大的解碼器模型來得重要。

當我們計算出標記層級的相關性分數後，我們會將它們彙總成句子層級的分數。此步驟將嘈雜的標記訊號轉換成穩定、可解釋的相關度量。高於可設定臨界值的句子會被高亮顯示；其他的都會被濾除。這樣就產生了一個簡單可靠的機制，可以選擇對查詢真正重要的句子。

推理過程

在執行時，我們的語意高亮度模型遵循一個簡單的管道：

輸入 -此流程從使用者查詢開始。擷取的文件會被視為相關性評估的候選上下文。
模型處理 -將查詢和上下文串連成單一序列：[BOS] + 查詢 + 上下文
標記評分（Token Scoring）-上下文中的每個標記都會被分配一個 0 到 1 之間的相關性分數，以反映其與查詢的相關程度。
句子彙整 -在句子層級彙整記號分數，通常是以平均方式彙整，以產生每個句子的相關性分數。
閾值篩選 -分數高於可設定閾值的句子會高亮顯示並被保留，而低分數的句子則會在傳送到下游 LLM 之前被篩選出來。

基本模型：BGE-M3 Reranker v2

我們選擇 BGE-M3 Reranker v2 作為基礎模型有幾個原因：

它採用適用於標記和句子評分的編碼器架構
支援多國語言，並針對英文和中文進行最佳化
提供適合較長 RAG 文件的 8192 個標記上下文視窗
可維持 0.6B 參數-足夠強而不重的計算量
確保基本模型有足夠的世界知識
針對重新排序進行訓練，這與相關性判斷任務密切吻合

訓練資料：LLM 註解與推理

一旦我們敲定了模型架構，下一個挑戰就是建立一個可以實際訓練可靠模型的資料集。我們先看看 Open Provence 如何處理這個問題。他們的方法使用公共 QA 資料集和小型 LLM 來標示哪些句子是相關的。它的擴充性很好，而且很容易自動化，因此對我們來說是一個很好的基準。

但我們很快就遇到他們所描述的相同問題：如果您要求 LLM 直接輸出句子層級的標籤，結果並不總是穩定的。有些標籤是正確的，有些則有問題，而且事後很難清理。完全手動註釋也不是一種選擇，我們需要的資料遠遠超過手動標籤的數量。

為了在不犧牲可擴展性的前提下提高穩定性，我們做了一個改變：LLM 必須為它輸出的每個標記提供一個簡短的推理片段。每個訓練範例都包括查詢、文件、句子跨度，以及簡短解釋為何某個句子相關或不相關。這個小小的調整使得註解更為一致，也讓我們在驗證或除錯資料集時有具體的參考。

包含推理結果的價值令人驚訝：

更高的注釋品質：寫出理由可作為自我檢查，減少隨機或不一致的標籤。
更好的可觀察性：我們可以看到為什麼要選擇某個句子，而不是把標籤當成黑箱。
更容易除錯：當某些地方看起來不對勁時，推理可以讓我們很容易發現問題是出在提示、領域還是註解邏輯上。
可重複使用的資料：即使我們將來改用不同的標籤模型，推理軌跡對於重新標籤或稽核仍然有用。

註解工作流程如下

用於注釋的 Qwen3 8B

在註解方面，我們選擇 Qwen3 8B，因為它原生支援透過輸出的「思考模式」，讓我們更容易擷取一致的推理軌跡。較小的模型無法提供我們穩定的標籤，而較大的模型對於此類管道來說，速度較慢，而且不必要地昂貴。Qwen3 8B 在品質、速度和成本之間取得了適當的平衡。

我們使用本地 vLLM 服務而非雲端 API 來執行所有註解。這為我們提供了高吞吐量、可預測的效能，以及更低的成本 - 實質上是以 GPU 時間換取 API 代幣費用，在產生數百萬個樣本時，這是更划算的交易。

資料集規模

我們總共建立了超過 5 百萬個雙語訓練樣本，大致平均分為英文和中文。

英文來源：MS MARCO、Natural Questions、GooAQ
中文來源：DuReader, 中文維基百科, mmarco_chinese

部分資料集來自重新註釋 Open Provence 等專案所使用的現有資料。其餘的資料則來自原始語料，方法是先建立查詢-上下文對，然後用我們基於推理的管道標籤它們。

所有註釋的訓練資料也可在 HuggingFace 上取得，供社群發展和訓練參考：Zilliz 資料集

訓練方法

一旦模型架構和資料集準備就緒，我們就在8× A100 GPU上訓練模型，共進行了三個 epoch，從頭到尾大概花了9 個小時。

注意：訓練只針對負責語義高亮工作的剪枝頭 (Pruning Head)。我們沒有訓練Rerank 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 句 (明確指出「編劇：Lanthimos 和 Efthymis Filippou」)

此範例有一個陷阱：第 3 句提到「Euripides」寫了原著劇本。但問題問的是「誰寫了電影 The Killing of a Sacred Deer」，答案應該是電影的編劇，而不是幾千年前的希臘劇作家。

模型結果

模型	找到正確答案？	預測
我們的模型	✓	選取的句子 1 (正確) 和 3
XProvence v1	✗	只選擇了句子 3，錯過了正確答案
XProvence v2	✗	只選擇了句子 3，錯過了正確答案

關鍵句得分比較：

句子	我們的模型	XProvence v1	XProvence v2
句子 1 (電影劇本，正確答案)	0.915	0.133	0.081
句子 3 (原著劇本，分散注意力)	0.719	0.947	0.802

XProvence 模型：

強烈被 "Euripides 「和」play "所吸引，給予句子 3 接近完美的評分 (0.947 和 0.802)
完全忽略實際答案 (句子 1)，給予極低的評分 (0.133 和 0.081)
即使將門檻從 0.5 降到 0.2，仍找不到正確答案

我們的模型：

正確給予句子 1 最高分 (0.915)
由於句子 3 與背景相關，因此仍然給予句子 3 一些相關度 (0.719)
以 ~0.2 的差值將兩個句子清楚地分開

這個範例顯示了模型的核心優勢：了解查詢意圖，而不只是匹配表面層級的關鍵字。在此上下文中，「The Killing of a Sacred Deer是誰寫的」指的是電影，而不是古希臘戲劇。我們的模型能夠捕捉到這一點，而其他模型則會被強烈的詞彙提示所干擾。

試試看，告訴我們您的想法

我們的zilliz/semantic-highlight-bilingual-v1模型已在 MIT 授權下完全開放原始碼，並可供生產使用。您可以將它插入您的 RAG 管道、針對您自己的領域微調它，或是在它的基礎上建立新的工具。我們也歡迎社群的貢獻與回饋。

從 HuggingFace 下載：zilliz/semantic-highlight-bilingual-v1
所有註解的訓練資料 ：https://huggingface.co/zilliz/datasets

在 Milvus 和 Zilliz Cloud 中提供語意強調功能

語意高亮功能也直接內建於Milvus與Zilliz Cloud(完全管理的 Milvus)，可讓使用者清楚瞭解擷取每份文件的原因。您不需要掃描整個文件塊，而是立即看到與您的查詢相關的特定句子 - 即使措辭並不完全相符。這讓擷取更容易理解，調試也更快速。對於 RAG 管道來說，它也釐清了下游 LLM 應該著重在哪些方面，這有助於快速設計和品質檢查。

免費試用全面管理的 Zilliz Cloud 中的 Semantic Highlighting 功能

我們很樂意聽取您的使用心得，包括錯誤報告、改善構想，或是您在將其整合至工作流程時所發現的任何問題。

如果您想詳細討論任何問題，歡迎加入我們的Discord 頻道或預約 20 分鐘的Milvus Office Hours 課程。我們很樂意與其他建置者聊天並交換筆記。