嵌入式模型/重排序模型能比較數字嗎？

這是我今天在維也納的 ICML 會議上被問到的一個問題。

在茶歇時間，一位 Jina 使用者向我提出了一個源自 LLM 社群近期討論的問題。他問我們的嵌入模型是否能判斷出 9.11 比 9.9 要小，這是很多 LLM 會判斷錯誤的任務。

「老實說，我不知道，」我回答道。當他詳細說明這個功能對他的應用程式的重要性，並指出分詞可能是問題的根源時，我不禁點頭表示同意——我的腦海已經開始醞釀著一個實驗來揭示答案。

在這篇文章中，我想測試我們的嵌入模型 jina-embeddings-v2-base-en（2023 年 10 月發布）和重排序模型 jina-reranker-v2-multilingual（2024 年 6 月發布）是否能準確比較數字。為了將範圍擴展到 9.11 和 9.9 的簡單比較之外，我設計了一系列實驗，包括各種類型的數字：小整數、大數字、浮點數、負數、貨幣、日期和時間。目標是評估我們的模型在處理不同數字格式時的有效性。

tag實驗設置

完整的實現可以在以下 Colab 中找到：

Google Colab

實驗的設計相當直觀。例如，要檢查嵌入模型是否理解 [1, 100] 之間的數字，步驟如下：

1. 構建文件：為 1 到 100 的每個數字生成「字符串字面量」文件。
2. 發送到嵌入 API：使用 嵌入 API 獲取每個文件的嵌入。
3. 計算餘弦相似度：計算每兩個文件之間的成對餘弦相似度以創建相似度矩陣。
4. 繪製散點圖：使用散點圖可視化結果。相似度矩陣中的每個元素 $(i, j)$ 映射到一個點：X 軸：$(i - j)$；Y 軸：$(i, j)$ 的相似度值

如果 delta $(i - j)$ 為零，即 $i = j$，則語義相似度應該最高。隨著 delta $(i - j)$ 增加，相似度應該降低。理想情況下，相似度應該與 delta 值呈線性關係。如果我們觀察不到這種線性關係，那麼模型可能無法理解數字，並可能產生像 9.11 大於 9.9 這樣的錯誤。

重排序模型採用類似的程序。主要區別在於我們遍歷構建的文件，通過在前面加上提示 "what is the closest item to..." 將每個文件設置為 query，並將其他所有文件作為 documents 進行排名。重排序 API 返回的相關性分數直接用作語義相似度度量。核心實現如下所示。

def rerank_documents(documents):
    reranker_url = "https://api.jina.ai/v1/rerank"
    headers = {
        "Content-Type": "application/json",
        "Authorization": f"Bearer {token}"
    }

    # Initialize similarity matrix
    similarity_matrix = np.zeros((len(documents), len(documents)))

    for idx, d in enumerate(documents):
        payload = {
            "model": "jina-reranker-v2-base-multilingual",
            "query": f"what is the closest item to {d}?",
            "top_n": len(documents),
            "documents": documents
        }
    ...
Copy

tag模型能比較 [1, 2, 3, ..., 100] 之間的數字嗎？

tag如何閱讀這些圖表

在進行更多實驗之前，讓我先解釋如何正確閱讀這些圖表。首先，從上面兩張圖中我觀察到嵌入模型表現良好，而重排序模型表現不太理想。那麼，我們在看什麼，為什麼會這樣呢？

X 軸代表索引 $(i,j)$ 的 delta，即 $i-j$，當我們從我們的文件集合中均勻採樣 $d_i$ 和 $d_j$ 時。這個 delta 範圍從 $[-100, 100]$。由於我們的文件集在構建時是有序的，即 $|i-j|$ 越小，$d_i$ 和 $d_j$ 在語義上越接近；$i$ 和 $j$ 相距越遠，$d_i$ 和 $d_j$ 之間的相似度越低。這就是為什麼你會看到相似度（由 Y 軸表示）在 $X=0$ 處達到峰值，然後向左右線性下降。

理想情況下，這應該會形成一個尖峰或「上箭頭」形狀，像 ^。但情況並非總是如此。如果你固定 X 軸的一個點，比如 $X=25$，沿著 Y 軸看，你會發現相似度值從 0.80 到 0.95 不等。這意味著，儘管它們的 delta 都是 25，$\mathrm{sim}(d_27, d_2)$ 可能是 0.81，而 $\mathrm{sim}(d_42, d_17)$ 可能是 0.91。

青色趨勢線顯示了每個 X 值的平均相似度及其標準差。另外，請注意相似度應該線性下降，因為我們的文件集是均勻分佈的，確保了連續文件之間的間隔相等。

請注意，嵌入圖表總是對稱的，在 $X=0$ 處 Y 值最大為 1.0。這是因為 $d_i$ 和 $d_j$ 的餘弦相似度是對稱的，且 $\cos(0)=1$。

相反，重排序圖表總是不對稱的，這是由於查詢和文件在重排序模型中扮演不同的角色。最大值可能不是 1.0，因為 $X=0$ 意味著我們使用重排序器來計算 "what is the closest item to 4" 與 "4" 的相關性分數。如果你仔細思考，$X=0$ 並不能保證會導致 Y 值最大。

tag模型能比較 [-100, -99, -98, ..., -1] 之間的負數嗎？

tag模型能比較更大間隔的數字 [1000, 2000, 3000, ..., 100000] 嗎？

tag模型能否比較任意範圍內的數字，例如 [376, 377, 378, ..., 476]？

tag模型能否比較大數字 [4294967296, 4294967297, 4294967298, ..., 4294967396]？

tag模型能否比較浮點數 [0.0001, 0.0002, 0.0003, ...,0.1]？（不固定位數）

tag模型能否比較貨幣數字 [$1,$2, $3, ...,$100]？

tag模型能否比較日期 [2024-07-24, 2024-07-25, 2024-07-26, ..., 2024-10-31]？

tag模型能否比較時間 [19:00:07, 19:00:08, 19:00:09,..., 20:39:07]？

tag觀察結果

以下是對上述圖表的一些觀察：

tag重排序模型

• 重排序模型在比較數字方面表現不佳。即使是在最簡單的 [1, 100] 範圍內比較數字的情況下，其表現也不理想。
• 值得注意的是，我們在使用重排序器時採用了特殊的查詢提示結構，即 what is the closest item to x，這可能也會影響結果。

tag嵌入模型

• 嵌入模型在比較 [1, 100] 範圍內的小整數或 [-100, 1] 範圍內的負數時表現尚可。但當將這個範圍移動到其他值、增加更多區間，或處理更大或更小的浮點數時，其表現會顯著下降。
• 在某些固定間隔（通常是每 10 步）可以觀察到規律性的突波。這種行為可能與分詞器處理字符串的方式有關，可能是將字符串分詞為 "10" 或 "1" 和 "0"。

tag日期和時間理解

• 有趣的是，嵌入模型似乎對日期和時間有很好的理解，大多數情況下都能正確比較。在日期圖中，每 30/31 步就出現突波，這對應於一個月的天數。在時間圖中，每 60 步出現突波，這對應於一小時的分鐘數。
• 重排序模型似乎也在某種程度上捕捉到了這種理解。

tag可視化與"零"的相似度

Google Colab

另一個可能更直觀的實驗是直接可視化任何數字與零（即原點）之間的相似度或相關性分數。通過將參考點固定為零的嵌入，我們想看看隨著數字變大，語義相似度是否線性降低。對於重排序器，我們可以將查詢固定為 "0" 或 "What is the closest number to number zero?"，並對所有數字進行排名，以查看它們的相關性分數是否隨著數字增加而降低。結果如下所示：

tag結論

本文展示了我們目前的嵌入和重排序模型如何處理數字比較。儘管實驗設置相對簡單，但它揭示了當前模型中的一些基本缺陷，並為我們下一代嵌入和重排序器的開發提供了寶貴的見解。

決定模型是否能準確比較數字的兩個關鍵因素：

首先是分詞：如果詞彙表只包含數字 0-9，那麼 11 可能被分詞為獨立的標記 1 和 1，或作為單個標記 11。這種選擇會影響模型對數值的理解。

其次是訓練數據：訓練語料庫顯著影響模型的數值推理能力。例如，如果訓練數據主要包含軟體文檔或 GitHub 倉庫，其中語義版本控制很常見，模型可能會理解 9.11 大於 9.9，因為 9.11 是緊隨 9.9 之後的次要版本。

密集檢索模型（如嵌入和重排序器）的算術能力對於涉及 RAG 和高級檢索與推理的任務至關重要。強大的數值推理能力可以顯著提高搜索質量，特別是在處理像 JSON 這樣的結構化數據時。