Embedder Collection

🚀 Sentence-Transformers

Sentence-Transformers 是一個用於句子相似度計算、特徵提取等自然語言處理任務的庫。它提供了多種預訓練模型，可用於不同語言和場景，幫助用戶更高效地處理文本數據。

🚀 快速開始

所有模型都在以 LM-Studio 為服務器的 ALLM（AnythingLLM）中進行了測試，所有模型都應該能與 ollama 兼容。下面描述的本地文檔設置幾乎相同，GPT4All 只有一個模型（nomic），而 koboldcpp 目前尚未內置，但正在開發中。

⚠️ 重要提示

有時使用“僅與文檔聊天”選項時，結果會更準確。順便說一下，嵌入器只是一個優秀 RAG 系統的一部分。如果你喜歡，請給我一個 ❤️ 哦 ;)

✨ 主要特性

模型表現

以下模型表現良好：

• nomic-embed-text（上下文長度可達 2048 個標記）
• mxbai-embed-large
• mug-b-1.6
• snowflake-arctic-embed-l-v2.0（上下文長度可達 8192 個標記）
• Ger-RAG-BGE-M3（德語，上下文長度可達 8192 個標記）
• german-roberta
• bge-m3（上下文長度可達 8192 個標記）

其他模型則取決於你的需求。有些模型非常相似，基於 jina 和 qwen 的模型目前還不受 LM 支持。在相同設置下，這些嵌入器能從一本書的 10 個片段中找到 6 - 7 個相同的片段，這意味著只有 3 - 4 個片段不同，但我並未進行廣泛測試。

使用提示

大上下文多命中場景

對於大上下文且預期有多個匹配結果的情況，設置主模型的（最大標記數）上下文長度為 16000 個標記，嵌入器模型的（最大嵌入塊長度）為 1024 個標記，（最大上下文片段數）為 14。在 ALLM 中，還需設置（文本分割與分塊偏好 - 文本塊大小）為 1024 個字符，並將（搜索偏好）設置為“準確性”。

💡 使用建議

• 你可以根據需求進行調整，例如設置 8 個長度為 2048 個標記的片段，或 28 個長度為 512 個標記的片段。但每次更改塊長度時，都需要重新嵌入文檔。
• 不同上下文長度的 VRAM 使用情況如下： - 8000 個標記（約 6000 個單詞），約使用 0.8GB VRAM - 16000 個標記（約 12000 個單詞），約使用 1.5GB VRAM - 32000 個標記（約 24000 個單詞），約使用 3GB VRAM

你可以使用以下工具：

• 標記計算器
• VRAM 計算器

嵌入與搜索原理

假設你有一個包含 90000 個單詞（約 300 頁）的 txt 或 pdf 文件，你詢問模型“在名為 XYZ 的章節中，與人物 ZYX 相關的內容是什麼”。模型會在文檔中搜索關鍵詞或語義相似的術語，如果找到了，例如圍繞“XYZ 和 ZYX”的單詞和含義，會在該單詞“XYZ/ZYX”周圍截取 1024 個標記的文本片段。實際上，這一切都是通過編碼數字完成的，但原理是一樣的。這個文本片段將用於生成答案。

💡 使用建議

• 如果一個文件中“XYZ”這個詞出現了 100 次，並非所有 100 次都會被找到。
• 如果只有一個片段與你的問題匹配，其他不相關的片段可能會對答案產生負面影響，因為它們與主題不匹配（通常 4 到 32 個片段比較合適）。
• 如果預計文檔中有多個搜索結果，可以嘗試設置 16 個或更多的片段；如果預計只有 2 個結果，就不要設置更多。
• 使用約 1024 個標記的塊長度可以獲得更多內容，使用約 256 個標記的塊長度可以獲得更多事實，但塊長度越短，片段越多，處理時間也會越長。
• 對於“文檔摘要”的問題，通常不太有用。如果文檔有引言或摘要，運氣好的話模型會在那裡搜索。
• 如果一本書有目錄或參考文獻，建議刪除這些頁面，因為它們通常包含相關搜索詞，但對回答問題沒有幫助。
• 如果文檔較小，如 10 - 20 頁，最好將整個文本複製到提示中，有些選項稱為“固定”。

主模型的重要性

主模型也非常重要，尤其是在處理上下文長度方面。這裡說的不僅僅是理論上可以設置的數字。有些模型可以處理 128k 或 1M 個標記，但即使輸入為 16k 或 32k 個標記，與其他經過良好開發的模型相比，使用相同片段作為輸入時的響應效果也會更差。

以下是一些表現較好的英文和德文模型：

• granit3.2 - 8b（也有 2b 版本） - 鏈接
• Chocolatine - 2 - 14B（其他版本也適用） - 鏈接
• QwQ - LCoT - （7/14b） - 鏈接

系統提示示例

系統提示會對問題產生一定的影響。你可以輕鬆地測試一次不使用系統提示或使用無意義的系統提示的情況。

示例 1：

你是一個樂於助人的助手，會從……的角度對……進行概述。你會使用附件中的摘錄來生成答案！請按順序對每個摘錄進行加權，最重要的摘錄放在頂部，不太重要的放在下面。不要過分強調整篇文章的上下文。回答用戶的問題！回答後，簡要解釋為什麼在回答中包含了摘錄（1 到 X），並簡要說明為什麼認為某些摘錄不重要！

（可根據需求進行修改，當我查閱一本關於人物和相關術語的書籍時，這個示例效果很好，解釋部分只是我自己的測試）

示例 2：

你是一個富有想象力的故事講述者，能夠創作有深度、有創意且連貫的引人入勝的故事。你的目標是根據給定的提示，創作出豐富、吸引人的故事，忠實於主題、語氣和風格。你會使用附件中的摘錄來生成答案！在創作故事時，確保人物、背景和情節發展的連貫性。發揮創意，引入富有想象力的轉折和獨特的視角。

示例 3：

你是一個熱情友好的夥伴，喜歡談論烹飪、食譜和美食的樂趣。你的目標是以個人化、友好且專業的方式分享美味的食譜、烹飪技巧和不同文化背後的故事。

順便說一下，Jinja 模板非常新穎……普通模型使用普通模板就可以，但合併模型有很大的優化潛力（但別問我，我不是程序員）。

DOC/PDF 轉 TXT

你需要自己準備文檔，因為輸入質量會影響輸出質量。在大多數情況下，如何將文檔提供給嵌入器並不直觀。幾乎在所有情況下，圖像、表格、頁碼、章節和段落格式的處理都不太完善。一個簡單的開始方法是使用基於 Python 的 PDF 解析器（有很多選擇）。

僅用於簡單的 txt/表格轉換的選項：

• pdfplumber
• fitz/PyMuPDF
• Camelot

總的來說，你可以對代碼進行很多調整，還可以手動添加 OCR。我推薦的選項：鏈接

未來的綜合解決方案：

• docling - （在 GitHub 上開源），它提供了一些現成的示例，已經相當不錯，大約 10 - 20 行代碼。示例鏈接，它還會自動下載一些 OCR 模型。目前我還沒找到的功能（可能不存在）是讀取字體類型，例如 fitz 在這方面表現很好。

大型的可用於多種類型（基於 UI）的選項：

• Parsemy PDF - 鏈接

僅索引選項

如果你想對大量（數萬）PDF 文件進行快速搜索（這只是索引，不是嵌入），可以使用以下工具作為簡單的方法來找到前 5 - 10 篇文章或書籍，然後將它們提供給大語言模型。

• Jabref - 鏈接，構建鏈接
• docfetcher - 鏈接（雖然舊，但非常有用）

可用模型列表

• avemio/German - RAG - BGE - M3 - MERGED - x - SNOWFLAKE - ARCTIC - HESSIAN - AI（德語、英語）
• maidalun1020/bce - embedding - base_v1（英語和中文）
• maidalun1020/bce - reranker - base_v1（英語、中文、日語和韓語）
• BAAI/bge - reranker - v2 - m3（英語和中文）
• BAAI/bge - reranker - v2 - gemma（英語和中文）
• BAAI/bge - m3（英語和中文）
• avsolatorio/GIST - large - Embedding - v0（英語）
• ibm - granite/granite - embedding - 278m - multilingual（英語、德語、西班牙語、法語、日語、葡萄牙語、阿拉伯語、捷克語、意大利語、韓語、荷蘭語和中文）
• ibm - granite/granite - embedding - 125m - english
• Labib11/MUG - B - 1.6（未知）
• mixedbread - ai/mxbai - embed - large - v1（多語言）
• nomic - ai/nomic - embed - text - v1.5（英語、多語言）
• Snowflake/snowflake - arctic - embed - l - v2.0（英語、多語言）
• intfloat/multilingual - e5 - large - instruct（100 種語言）
• T - Systems - onsite/german - roberta - sentence - transformer - v2
• mixedbread - ai/mxbai - embed - 2d - large - v1
• jinaai/jina - embeddings - v2 - base - en

許可證說明

所有許可證和使用條款歸原作者所有。