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

许可证说明

所有许可证和使用条款归原作者所有。