為什么用Qwen3 embedding和rerank
排名是真的挺好，開源閉源現在都是第一了，這個事embeddiing的，rerank應該也是第一，甚至4B的基本也除了8B以外就是它第一。
它和普通的比如原來的我們常用的BGE之類的有啥區別？
傳統的embedding都是基于bert來弄模型，一般也就encoder only，bert原來也就是干分類器的，給一句話到它，它給你進行embedding了，這里考慮到有些同學可以不理解整套流程，我就稍微說細點一般來講用3層法就很好理解：
第一層：詞元嵌入（Token Embedding）——“查字典”階段
“一個token一個token地進行embedding”，這是最基礎的，也是第一步。
- 分詞（Tokenization）：模型拿到一句話，例如 "The cat sat on the mat"，會先把它切分為一個個“詞元”（Token）：["the", "cat", "sat", "on", "the", "mat"]
- 查字典（Token Embedding）：模型內部有一個龐大的“字典”（Embedding Layer），存著每個詞元對應的初始向量。模型會根據分詞的結果，依次查出每個token的初始向量。舉例："the" -> [0.1, 0.5, 0.2, ...]"cat" -> [0.8, 0.1, 0.9, ...]……這一層得到的向量是上下文無關的。舉個經典例子，無論“bank”出現在“river bank”（河岸）還是“investment bank”（投資銀行）里，在這一層查出的向量都是一樣的。兩個bank在這個向量化的時候沒啥區別，但是我們知道語義完全是兩個東西
第二層：上下文感知（Contextualization）——Transformer就上了
傳統模型（比如Word2Vec）和現代的Transformer模型（比如BERT、Qwen）就在這里拉開了差距。
在拿到第一步得到的所有初始向量后，模型不會直接用它們，而是把這一串向量送入Transformer核心結構（多層自注意力機制，搞一遍QKV），進行“深加工”。
你可以把它想象成：這些獨立的單詞向量都進入了一個“會議室”。在這里，“cat”這個向量會和“sat”“mat”等其他向量充分“溝通和討論”（自注意力機制）。經過多輪（多層）討論，每個單詞向量都吸收了整句話的上下文信息，最終全部更新（這塊看不懂可以看我以前的transformer算法文章）。
在這一步之后，比如“bank”在“river bank”和在“investment bank”中的最終向量就不再相同，而是根據上下文有了不同的含義。但要注意：此時我們依然得到了一個詞元序列對應一個向量，即一句話還是對應一串向量，每個詞元一個。
第三層：句子嵌入（Sentence Embedding）——從“一串”到“一個”
接下來，有些任務（比如語義搜索、相似度比對等）需要用一個向量來代表整個句子，而不是一串向量。這時就需要一個聚合或池化（Pooling） 的策略，把第二層產出的那一串上下文感知向量，濃縮成一個能夠代表整句話的整體向量。
這塊BGE代表的bert派和qwen3代表的LLM派就有區別了
這正是 [CLS] 和 [EOS] 發揮作用的地方！
傳統BERT模型（[CLS]策略）
BERT會在輸入的最前面加一個特殊的 [CLS]（Classification）標記。在經過Transformer的“深加工”后，BERT會特別訓練模型，使得這一最終的 [CLS] 標記向量能夠代表整句話的含義。
因此，我們只需要從最后一層輸出中，把 [CLS] 對應的向量單獨拿出來，就可以用作整句話的句子嵌入。其他詞元的向量在這個任務中可以忽略。這個CLS可以掛在整個句子的最前面
[CLS] 句子A [SEP] 句子B [SEP]
bert pooling完了的結果是由這個CLS位為代表，最終的句子（任意長的chunk）得到的一個定長的向量，也就是???[CLS]???標記最終的隱藏狀態向量。這個定長的向量就是該文本塊的嵌入表示，也正是我們存入向量庫用于后續檢索的那個向量。
Qwen3模型（[EOS]策略）
Qwen3的原理與BERT類似，不過由于其結構是單向的，因為LLM是casul LLM，它看不到你前面的東西啊，所以它選擇在輸入序列的末尾加一個 [EOS]（End of Sequence）標記。
也就這么點區別，因為看不見前面，所以選擇最后整個語義被壓縮到最后一個speical token，這里用的是EOS，然后最后這個EOS token所代表的hidden state 等駕于CLS
當然同樣，Qwen3也會特別訓練模型，確保 [EOS] 標記的最終向量能夠代表整句話的含義。
因此，我們只需取 [EOS] 的那個向量，就得到了所需的句子嵌入。
看起來似乎沒那么特別大的差別嗎？那它為什么效果能好出來10幾個百分點呢？
1- 模型夠大，只要你把BGE做的dimension變大，它其實也能變好的，因為維度大了，隱空間可表示的表征自然就豐富，難訓，但是訓好了，泛化性和能力都要更好
2- 基礎模型太強，Qwen3的語音本身的理解那不是bert能比的了的（在我看這才是核心），早它之前其實也有那拿mistral來訓類似的套路的，效果也不錯，可是mistral和qwen系列還是沒法比的
3- 訓練方法
前兩個階段都是對比學習，3階段加一個slerp
1）合成數劇上用qwen32來刷的，刷了很多，有邏輯的數據，那以前BGE上的只能上社區搜，這塊差了不少，無論質量還是數量。他們總共創造了約1.5億對用于弱監督訓練的文本對，有人說LLM的語義能力應該可以啊，嗨搞什么弱監督pretrain啊，這不是你的最終任務是這種成對的嗎，所以拿這個刷一刷，原始pretrain數據集里對這種的任務沒有特定的針對datasets，相當于補充一下
2）多樣性，研發人員在生成數據時，精確地定義和控制各種維度，例如任務類型、語言、文本長度和難度等?。論文的附錄中詳細介紹了一個精巧的兩階段生成流程，在生成檢索數據時，會先為文檔配置一個“角色（Character）”，然后從這個角色的視角出發生成查詢，極大地提升了數據的多樣性和真實感?????????。
3） 合成加人工在FT，這階段還有包含約700萬對人工標注數據和1200萬對高質量合成數據來刷FT
4- Slerp這個基本不太會有人特別用，但是論文說用Slerp來融合多個step的checkpoint面對不同的下游任務效果都很好，我覺得看看就可以了，這個不用太當真。
剛才說它底子好，數據又多是主要原因，其實還有一個原因也很重要，但是估計大多數人不一定用，比如我粘這張圖的MTEB的bench leadboard就沒考慮進來，全是zero shot的，也就是我們普通玩的雙塔
問題--> embedding 得向量和 docuemnt embedding得向量一比，哪幾個topk更好，就選出他們index對英的chunk
這是普通玩法，當然qwen3這個普通玩法我們看著在天梯上就很能打
可是它其實是有新玩法的，就是instruct
它示例代碼是這樣的：
from sentence_transformers import SentenceTransformer
# Load the model
model = SentenceTransformer("Qwen/Qwen3-Embedding-0.6B")
queries = [
"What is the capital of China?",
"Explain gravity",
]
documents = [
"The capital of China is Beijing.",
"Gravity is a force that attracts two bodies towards each other...",
]
# Encode the queries and documents. Note that queries benefit from using a prompt
query_embeddings = model.encode(queries, prompt_name="query")
document_embeddings = model.encode(documents)先看一個用sentence-transformer引導的簡單的案例，就是比2個query和2個document的距離么
這個看著特別容易，但是其實有點玄機，玄機在這
??query_embeddings = model.encode(queries, prompt_name="query")??
正常我們認為encode一個問題的時候就是把query給encode了，對吧，但是它這個多來一個尾巴，就是這個 prompt_name="query"
這個是什么呢？
這個就是instruct，玩LLM的對這個就沒什么可陌生的了，最早的chatGPT就有3個輸入對吧！
system的
instruct的
user的
system的對應全局role的或者什么其他的設定，instruct對應本次的，user就是正常說話的，只不過現在被改的基本也就偶爾用用system，instruct基本消失于江湖了，全是user的
但是qwen3把這個撿了起來。
它是做什么的呢？
首先如果默認寫了prompt_name='query'如上一段代碼，那么背后的意義就是相當于開個默認的instruct=‘Given a web search query, retrieve relevant passages that answer the query’
而每次跟著用戶的問題一起進入雙塔中的問題塔進行encoder的除了用戶的問題，還有這個instruct，相當于給你的查詢加了控制
有人說看這個instruct也沒什么意義啊，基本不都是為了query嗎？那系統本身帶的默認的卻是就是給retrive用的
可是還很多場景，你可以給它改了，比如我舉幾個能想到又好理解的例子：
例子一：FAQ知識庫中的“相似問題”匹配
場景：假設你有一個包含1000個標準問答對（FAQ）的知識庫。用戶提出了一個口語化的問題，你不希望直接從那些冗長的答案中查找，而是希望先找到與用戶問題最相似的“標準問題”，再把相應的標準答案返回給用戶。
挑戰：這里的關鍵任務不再是“問題→答案”的檢索，而是“問題→問題”的相似度匹配。
自定義指令：Instruct: For the given user question, find the most similar question from the FAQ list.
中文示例：“為以下用戶問題，在FAQ列表中匹配最相似的標準問法。”
這個指令告訴模型，無需關注答案內容，而是聚焦于兩個問題在語義上的等價性。相比通用的retrieve指令，這樣更精準，能有效避免用戶問題因為某個關鍵詞（如“價格”）而誤匹配到不相關的答案。
例子二：“相關推薦”或“發現更多”功能
場景：用戶正在閱讀一篇新聞報道或瀏覽一個商品詳情頁，你希望在頁面下方為其推薦“相似文章”或“相似商品”。
挑戰：“相似”有多種維度：是主題相似？風格或調性相似？還是同樣提到了某個人物或產品？
自定義指令與示例
主題推薦：Instruct: Find other articles with a similar topic.
中文示例：“尋找主題相似的其他文章。”
風格推薦：Instruct: Find other documents written in a similar narrative style.
中文示例：“尋找寫作風格相似的其他文檔。”
意義：你可以用同一套文檔向量，通過在查詢時動態傳入不同指令，為用戶提供多維度的推薦。比如讓用戶自己選擇“更關心主題”還是“喜歡這個作者的風格”，實現更個性化的推薦功能。
例子三：代碼庫中的功能性搜索（論文提到的強項）
場景：開發者希望在代碼庫中尋找能夠“異步寫入文件”的函數。
挑戰：代碼搜索和自然語言搜索不同。直搜“異步寫入文件”未必有效，因為不同開發者可能用不同的變量名或注釋。
自定義指令：Instruct: Find code snippets that perform a similar function.
中文示例：“尋找能夠實現相似功能的代碼片段。”
這個指令能引導模型超越表面詞匯差異，理解代碼的實際邏輯和功能。這也是Qwen3 Embedding在代碼檢索表現突出的原因之一。開發者還可以更具體地定制指令，比如："Find usage examples for the 'torch.nn.Module' class"。
例子四：細粒度的評論分析
場景：身為產品經理，你希望從大量用戶評論中，找到所有提到“電池續航差”的負面評價。
挑戰：直接搜“電池”會返回所有正負評論，普通語義搜索也難區分評論的情感傾向。
自定義指令：Instruct: From the product reviews, retrieve passages that express a negative sentiment about battery life.
中文示例：“從產品評論中，檢索關于‘電池續航’的負面評價段落。”
這不就少挨幾句罵么。。。
綜上，這個我認為是有用，但是現有大部分rag系統本身不支持這個（我自己玩的BY_RAG也為了這個能力再改），所以還是有一定工作量和產品設計怎么能根據具體的任務來靈活的設置instruct，新玩法出來了，但是老工具還是需要改進來fit它的能力。
最后花少許時間講講qwen-rerank它這個也和傳統的rerank不一樣，傳統的單塔rerank一般是最后一層liner輸出個logit，但是它是用system prompt來讓rerank模型生成yes|no，然后輸出yes的概率得分，（score = P("yes") / (P("yes") + P("no"))包括為了兼容這塊你最好還要做padding的左移，總之現有的代碼你想用，是要進行變更的
除了對rerank分數的判定不一樣，傳統rerank是使用簡單的??[CLS]Query[SEP]Document??拼接方式，然后進里面去查相關性，它不是，它的套路是template
Qwen3 Reranker 的設計采用了結構化、類似對話的上下文輸入方式，最大程度發揮了大語言模型的理解和推理能力。
根據論文，輸入格式遵循類聊天模板，主要包含以下幾個部分：
第1部分
- 系統指令（System Prompt）
首先，系統級指令為模型設定角色和任務規則。這個指令會告訴模型："根據提供的查詢和指令來判斷文檔是否滿足要求"，并明確規定“答案只能是‘yes’或‘no’”。這樣，排序任務就被直接轉化為一個二元分類問題。 - 用戶信息（User Block）
在 user 塊中，結構化地提供三項核心信息：
- ?
?<Instruct>??: 用戶自定義、用于指導模型排序的具體指令 - ?
?<Query>??: 用戶原始查詢 - ?
?<Document>??: 待判斷相關性的候選文檔
- 助手提示（Assistant Prompt）
最后，輸入以一個 assistant 提示結尾，讓模型去“思考”并生成最終的判斷。
看起來這樣
<|im_start|>system
Judge whether the Document meets the requirements based on the Query and the
Instruct provided. Note that the answer can only be "yes" or "no".<|im_end|>
<|im_start|>user
<Instruct>: {用戶自定義的指令}
<Query>: {用戶的查詢}
<Document>: {候選文檔}<|im_end|>
<|im_start|>assistant第2部分：進入Qwen3模型（“判官”審閱案卷）
這個精心構建、結構化好的“案卷”文本會被完整送入Qwen3基礎模型。
Qwen3本身就是一個強大的大語言模型（雖然小，但是應付embedding夠用），擁有0.6B、4B、8B等多種規模，具備強大的文本理解能力、長上下文處理（32K序列長度）、以及出色的指令跟隨能力。
與傳統模型類似，Qwen3會對指令、查詢和文檔中的所有詞元進行深度、端到端的自注意力計算，實現信息的充分交互。
第3部分：輸出判決（計算“yes”的概率）
Qwen3 Reranker在輸出機制上和傳統模型有著顯著區別。它不依賴額外的分類頭輸出抽象分數，而是直接通過預測答案“yes”或“no”的概率，作為相關性判斷的依據。
具體做法是：模型的主要任務是預測 assistant 后最可能出現的詞元，即“yes”或“no”，并計算它們各自的概率。最終的相關性分數通過如下公式歸一化得到：
score = P("yes") / (P("yes") + P("no"))
該分數的取值范圍在0到1之間，直觀代表了文檔與查詢在當前指令下的相關程度。分數越高，說明“yes”的置信度越高，即文檔越符合用戶需求。
Qwen3 Reranker通過將排序任務“LLM化”或“對話化”，充分釋放了其強大基礎模型的潛力，使其不再是一個簡單的打分工具，而是一個能夠理解復雜指令、進行深度推理的智能“判官”，這就是完全兩個故事了，所以性能和純rank打分器也不一樣
訓練就不說了，沒啥特殊的，刷數據
我自己的RAG肯定是率先都支持了，現在在做和DR集成，做好了，就開源，做不好我也不著急發。
本文轉載自???熵減AI???，作者：周博洋
