LightOn 在 10 月 19 日公開 SlideOn 與 mSlideOn，把既有檢索模型學到的語意能力，轉成能用倒排索引搜尋的稀疏向量。其中，多語版 mSlideOn 從逐詞比對的 mLateOn 出發，將一份文件濃縮成一組稀疏特徵，讓搜尋系統多一條兼顧語意與索引成本的路。
如果知識庫已能找到相關內容，索引卻愈來愈大，是否只能換模型？mSlideOn 提供另一個選擇：查詢與文件各自決定留下多少特徵，分別控制要查的清單與要存的索引。對建置中英文知識庫的台灣團隊，這讓成本調整不必每次都重新訓練。
語意搜尋也能走倒排索引
一般的向量嵌入會把文字轉成數字表示。逐詞比對的檢索模型則保留多個詞元向量，讓問題中的不同部分，分別找到文件裡對得上的內容；代價是要儲存、比較更多向量。這也是 Multi-Vector 檢索常見的取捨。
mSlideOn 沿用這類模型已學到的知識，再經過稀疏自編碼器預訓練與檢索微調，改用少量有效特徵表示整份文件。它仍然在做語意比對，只是搜尋時不再逐一比較文件裡所有詞元向量。
倒排索引可以理解成按特徵編排的目錄：每個特徵底下，記錄哪些文件含有它、各自權重是多少。問題進來後，系統沿著問題啟用的特徵查目錄，累加共同特徵的分數。沒有共同特徵的文件，就不必投入同樣的比對工作。
這與傳統關鍵字索引有個重要差別：這些特徵由模型學得，不直接對應原文詞彙。因此，特徵編號不能直接翻譯成「保固」或「退貨」。如果原有搜尋還負責精確找訂單編號或產品代碼，這部分仍應保留字串比對。
兩款模型的分工也很清楚。英文版 SlideOn有 1.74 億參數，從 DenseOn 出發；多語版 mSlideOn有 3.39 億參數，面向多語、長文件與程式碼。兩者採 Apache 2.0 授權，可下載權重自行部署；台灣團隊若要處理中英文資料，應先看後者。
查詢與文件各有一個設定
mSlideOn 模型卡提供一個具體例子：查詢最多保留 128 個特徵，文件最多保留 1,024 個特徵。向量仍有 32,768 個位置，但其餘位置歸零，索引只需要處理保留下來的有效特徵。
查詢端少留一些特徵，會減少搜尋要讀取的清單；文件端少留一些，則會減少索引中的文件權重記錄。兩者都影響搜尋工作量，但不必同步縮減。訓練時已納入不同保留數量的組合，讓較強的特徵承載較多檢索資訊。
官方程式庫使用 SparseEncoder 載入模型，再分別呼叫 encode_query() 與 encode_document()，各自設定 max_active_dims。只做推論可使用已發布的最終模型；名稱帶有 SAE 的版本則是訓練起點，兩者用途不同。
原有 RAG 系統若卡在索引容量，文件端保留數量便是可比較的選項；若索引放得下、搜尋卻太慢，則可調整查詢端。這比只看模型參數量更貼近檢索系統的成本來源，因為模型大小相同，也可能產生不同規模的索引。
不過，官方公布的檢索運算量是共同特徵數的估算，儲存成本則以非零特徵數表示，並非實測毫秒或索引位元組數。Sentence Transformers 文件也提醒，排行榜分數由模型作者回報，沒有呈現完整的稀疏程度與搜尋成本。
我的判斷是，mSlideOn 值得放進知識庫檢索的比較名單，尤其適合已有語意搜尋需求、又開始受到索引規模限制的團隊。真正要比較的是同一批問題能否找回正確段落，以及為此付出的儲存與查詢時間。本文未載入權重實測，因此不把官方多語分數解讀成繁中資料已獲驗證，也不宣稱它一定比既有系統快。
常見問題
中英文文件應選哪一款？
可先看 mSlideOn。它面向多語、長文件與程式碼，參數量為 3.39 億；SlideOn 則面向英文。兩者均可下載權重自行部署。
調整特徵數需要重新訓練嗎？
使用已發布模型時不需要。查詢與文件可分別設定最多保留多少個有效特徵，藉此改變檢索與索引工作量，模型參數量維持不變。
官方榜單使用哪種保留設定？
模型卡的主要榜單使用未剪裁向量。若改成查詢保留 128 個、文件保留 1,024 個特徵，便是另一種設定，不能直接沿用原本分數。