联系销售

是的。Jina 正在转型成为一个模型品牌。你可以把它想象成 Qwen 之于阿里巴巴、GPT 之于 OpenAI，或者 Kimi 之于 Moonshot。我们将逐步把公司的法律名称从 Jina AI 更改为 Elastic，使 Jina AI 能够专注于搜索底座模型这一品牌。

向量化、重排序器和小型语言模型，助力提升搜索体验。我们的使命尚未完成——我们从未掩饰过我们的目标：成为世界一流的搜索模型提供商。

是的。Reader API、Embedding API 和 Reranker API 将继续开发和维护。我们发布的每个模型都会同步发布到云市场平台。您可以像以前一样继续使用我们的 API 服务。唯一的例外是我们无法为受美国出口管制的实体或国家/地区提供服务。

是的。在 Elastic，Jina 将继续推进搜索底座模型的前沿发展，我们也会继续发布开放权重模型。

除非情况发生变化（这种情况不太可能发生），否则我们将继续以 CC-BY-NC 4.0 协议发布作品。

是的。我们发布的每个模型都会有严谨的论文作为支撑，我们也会继续向 ICLR、EMNLP、SIGIR、NeurIPS 和 ICML 等顶级会议投稿。

只需像以前一样，通过我们的网站或相关的云市场注册并付款即可。

目前，我们的产品尚未纳入 Elastic 的产品库 (SKU)，因此您仍需通过我们的网站付费才能使用这些服务。不久的将来，Jina 模型将可通过 Elastic 推理服务使用。

如果您拥有 Elastic 付费许可证，则很可能已包含我们模型的商业用途。您可以直接开始使用。如果您不确定，请联系您的 Elastic 销售代表或现场销售工程师，他们会与我们协调确认。

由于我们目前正在与 Elastic 进行整合，未来的发展方向很快就会更加清晰。目前，我们尚无法为我们的模型颁发独立的商业许可协议。

我们没有中国法人实体，因此无法开具中文发票。发票由我们位于德国的总部 Jina AI GmbH 开具。

基于合同的协议在 Jina AI 的商业模式中一直只占很小一部分——我们的大多数客户都采用按需付费的自助服务模式。虽然我们正在与 Elastic 进行集成，但目前我们暂不签发新的合同。

请联系您的 Elastic 销售代表，我们可以安排您、Jina AI 团队和 Elastic 进行会面讨论。

阅读器 API 的基本功能免费，只需在 URL 前添加“https://r.jina.ai/”即可。如需更高的速率限制，您可以提供 API 密钥，密钥会根据内容长度收取费用。有关速率限制的详细信息，请参阅问题 16。

读取器 API 使用代理来获取任何 URL，并在浏览器中呈现其内容以提取高质量的主要内容。

是的，读取器 API 是开源的，可以在 Jina AI GitHub 存储库中找到。

读取器 API 通常会在 2 秒内处理 URL 并返回内容，但复杂或动态的页面可能需要更多时间。

抓取可能很复杂且不可靠，尤其是复杂或动态页面。读取器 API 提供简洁、可靠的干净大模型级文本输出。

读取器 API 返回 URL 原始语言的内容。它不提供翻译服务。

如果您遇到阻止问题，请联系我们的支持团队寻求帮助和解决方案。

虽然 读取器 API 主要用于网页，但它可以从 arXiv 等网站上以 HTML 格式查看的 PDF 中提取内容，但它并未针对一般 PDF 提取进行优化。

是的，Reader 可以使用 `x-with-generated-alt` 头部为网页上的图片添加描述性文字。这会为缺少 alt 标签的图片添加描述性文字，使语言学习者能够理解视觉内容。视频摘要功能计划在未来的版本中推出。

不可以，读取器 API 只能处理来自可公开访问的 URL 的内容。

如果您在 5 分钟内请求相同的 URL，读取器 API 将返回缓存的内容。

不幸的是没有。

是的，您可以使用读取器中的原生 PDF 支持（https://r.jina.ai/https://arxiv.org/pdf/2310.19923v4）或使用 arXiv 中的 HTML 版本（https://r.jina.ai/https://arxiv.org/html/2310.19923v4）

Reader 为指定 URL 上的所有图片添加标题，并添加 `Image [idx]: [caption]` 作为 alt 标签（如果最初没有）。这使得下游大模型能够与图片进行推理、总结等交互。

Reader API 的设计具有高度可扩展性。它根据实时流量自动扩展，最大并发请求数现在约为 4000。我们正在积极维护它，将其作为 Jina AI 的核心产品之一。因此，请放心在生产中使用它。

请在下表中查找最新的速率限制信息。请注意，我们正在积极致力于改进 Reader API 的速率限制和性能，因此该表将进行相应更新。

ReaderLM-v2 是我们最新的小型语言模型 (SLM)，用于将原始 HTML 转换为简洁的 Markdown 或 JSON。与 v1 相比，它的质量提升了 3 倍，并且可以使用 JSON 模式或自然语言指令提取结构化数据。您可以通过 Reader API 直接使用它，只需添加 x-respond-with: readerlm-v2 标头即可，或者也可以从云市场（AWS、Azure、GCP）部署它。

使用带有 JSON 模式定义的 `x-json-schema` 标头，或使用带有自然语言指令的 `x-instruction` 标头。这两个功能都与 ReaderLM-v2 配合使用，可将任何网页中的特定字段（例如价格、标题、日期等）提取为结构化的 JSON 格式。

不。Reader 不会主动绕过任何网站的防御机制、反机器人系统或访问控制。如果网站将我们的服务检测为机器人并阻止了请求，我们会尊重这一结果。我们以标准网络客户端的形式运行，不会采用任何旨在规避检测系统的技术。

不。从免费套餐升级到付费 API 密钥并不会授予您访问其他网站的权限或绕过任何网站限制。不同套餐之间的主要区别在于速率限制和性能优化。付费 API 密钥提供更高的请求吞吐量和更快的处理速度，但并不能让您访问屏蔽我们服务的网站。

有关我们的训练过程、数据来源和评估的详细信息，请参阅我们在 arXiv 上发布的 jina-embeddings-v3 和 jina-embeddings-v4 技术报告。

jina-embeddings-v4 是我们最新的通用多模态模型（38亿参数），支持文本和图像，包含32K上下文信息，支持密集型和延迟交互检索，并在视觉丰富的文档上实现了最先进的性能。jina-clip-v2 是一个更轻量级的模型（8.65亿参数），支持89种语言，图像分辨率为512x512，并采用Matryoshka表示法。这两个模型在文本-文本、文本-图像和图像-图像检索任务中均表现出色。

jina-embeddings-v4 和 jina-embeddings-v3 均支持 89 种语言，并具备强大的多语言性能。排名前 30 的语言包括：阿拉伯语、孟加拉语、中文、丹麦语、荷兰语、英语、芬兰语、法语、格鲁吉亚语、德语、希腊语、印地语、印尼语、意大利语、日语、韩语、拉脱维亚语、挪威语、波兰语、葡萄牙语、罗马尼亚语、俄语、斯洛伐克语、西班牙语、瑞典语、泰语、土耳其语、乌克兰语、乌尔都语和越南语。jina-clip-v2 也支持 89 种语言，可用于多模态任务。

上下文长度因模型而异：jina-embeddings-v4 最多支持 32K 个词元，而 jina-embeddings-v3 和 jina-clip-v2 最多支持 8192 个词元。一个词元可以是一个字符，也可以是一个完整的单词。这种扩展的上下文能够对大量文本数据进行更全面的文档分析，并提高上下文理解的准确性。

每次请求包含的项目数量没有硬性限制。API 会根据令牌数量对输入进行内部分批处理，以优化 GPU 利用率。您可以在单个请求中发送所需的任意数量的文本或图像。

对于 `jina-embeddings-v4`、`jina-clip-v2` 和 `jina-clip-v1`，您可以在 API 请求的 `input` 字段中使用 `url` 或 `bytes`。对于 `url`，请提供您要处理的图像的 URL。对于 `bytes`，请将图像编码为 base64 格式。`jina-embeddings-v4` 还可以通过传递 PDF URL 或 base64 编码的 PDF 字节直接嵌入 PDF 文档。

jina-embeddings-v4 是我们最新的旗舰模型，在视觉丰富的文档检索 (ViDoRe) 和多模态基准测试中均达到了 SOTA（最先进水平）。对于纯文本任务，jina-embeddings-v3 在 MTEB 英语和多语言基准测试中超越了 OpenAI 和 Cohere，同时体积更小、效率更高。这两个模型都支持 Matryoshka 表示学习 (MRL)，允许在不显著降低性能的情况下进行维度截断（v3 可截断至 32 维，v4 可截断至 128 维）。

迁移过程十分顺畅，因为我们的 API 端点与 OpenAI 的 text-embedding-3-large 模型的输入和输出 JSON 架构相匹配。这种兼容性确保用户在使用 OpenAI 端点时可以轻松地将 OpenAI 模型替换为我们的模型。

词元根据文本长度和图像大小计算。对于请求中的文本，词元按标准方式计算。对于图像，执行以下步骤： 1. 图块大小：每幅图像被划分为图块。对于 jina-embeddings-v4，图块尺寸为 28x28 像素；对于 jina-clip-v2，图块尺寸为 512x512 像素；对于 jina-clip-v1，图块尺寸为 224x224 像素。 2. 覆盖率：计算覆盖输入图像所需的图块数量。即使图像尺寸不能被图块尺寸完全整除，部分图块也计为完整图块。 3. 图块总数：覆盖图像的图块总数决定了成本。例如，一幅 600x600 像素的图像在 jina-embeddings-v4 中会被 22x22 个图块（484 个图块）覆盖，在 jina-clip-v2 中会被 2x2 个图块（4 个图块）覆盖，在 jina-clip-v1 中则会被 3x3 个图块（9 个图块）覆盖。 4. 成本计算：对于 jina-embeddings-v4，每个图块花费 10 个词元；对于 jina-clip-v2，每个图块花费 4000 个词元；而对于 jina-clip-v1，每个图块花费 1000 个词元。 示例： 对于一幅 600x600 像素的图像： • 使用 jina-embeddings-v4 • 图像被分割成 28x28 像素的图块。 • 所需的瓦片总数为 22（水平）x 22（垂直）= 484 个瓦片。 • jina-embeddings-v4 的成本为 484*10 = 4840 个 token。 • 使用 jina-clip-v2 • 图像被分割成 512x512 像素的瓦片。 • 所需的瓦片总数为 2（水平）x 2（垂直）= 4 个瓦片。 • jina-clip-v2 的成本为 4*4000 = 16000 个 token。 • 使用 jina-clip-v1 • 图像被分割成 224x224 像素的瓦片。 • 所需的瓷砖总数为 3（水平）x 3（垂直）= 9 块瓷砖。 • jina-clip-v1 的成本为 9*1000 = 9000 个词元。

是的，jina-clip-v2 和 jina-clip-v1 可以支持图片和文本。更多模态上的向量模型将很快公布！

有关使用特定数据微调我们的模型的疑问，请联系我们讨论您的要求。我们愿意探索如何调整我们的模型来满足您的需求。

是的，我们的服务在 AWS、Azure 和 GCP 市场上可用。如果您有特定要求，请通过 sales AT jina.ai 联系我们。

在jina-embeddings-v3和jina-embeddings-v4中，task参数用于激活特定任务的LoRA适配器，以获得最佳性能。使用retrieval.query进行搜索查询，使用retrieval.passage进行文档搜索，使用text-matching进行语义相似度计算，使用classification进行文本分类，以及使用separation进行聚类任务。

jina-embeddings-v4 通过 output_type 参数支持密集（单向量）和延迟交互（多向量）检索。延迟交互保留了更细粒度的词级信息，从而在复杂查询中实现更高的检索准确率。jina-colbert-v2 是一个专用的延迟交互模型。

延迟分块是一种先使用长上下文模型嵌入整个文档，然后从词元级表示中提取块嵌入的技术。与朴素分块（先分块后嵌入）不同，延迟分块保留了跨块上下文，从而提高了 RAG 应用的检索性能。可以通过 `jina-embeddings-v3` 中的 `late_chunking` 参数启用此功能。

虽然我们的一些嵌入模型在架构上能够处理更长的上下文长度，但由于推理基础架构中 GPU 显存的限制，API 可能会强制执行较低的限制。处理非常长的序列需要大量的内存，我们针对大多数用例优化了服务配置，以平衡吞吐量、延迟和成本。如果您需要更长的上下文长度支持，请联系我们的销售团队，讨论专门的部署方案。

jina-embeddings-v4 构建于 Qwen2-VL 基础模型之上，该模型以 Qwen 研究许可发布。此许可仅允许研究和非商业用途，这意味着我们无法将 jina-embeddings-v4 作为商业产品提供。因此，我们通过 API 免费提供该模型的访问权限。jina-embeddings-v4 的速度可能比其他模型慢，原因有二：首先，jina-embeddings-v4 的模型比 jina-embeddings-v3 大得多，因此每次请求所需的计算时间也更长。其次，由于我们无法将此模型商业化，我们有意限制了 API 吞吐量以控制基础设施成本。用户在使用 jina-embeddings-v4 API 时，不应期望获得高吞吐量或生产级别的吞吐量。对于需要更高吞吐量的生产工作负载，我们建议使用 jina-embeddings-v3 或通过 Hugging Face 在您自己的基础架构上部署 jina-embeddings-v4。

速率限制取决于您的 API 密钥类型：

免费版： 100 RPM，100K TPM，2 个并发请求
付费版： 500 RPM，2M TPM，50 个并发请求
高级版： 5,000 RPM，50M TPM，500 个并发请求

此外，为了防止滥用，我们还设置了基于 IP 地址的速率限制，每 60 秒最多 10,000 个请求。如果您需要更高的限制，请联系我们的销售团队。

每个模型对每个输入都有最大上下文长度限制：

jina-embeddings-v4: 32,768 个 token
jina-embeddings-v3: 8,192 个 token
jina-embeddings-v2-*: 8,192 个 token
jina-clip-v1/v2: 8,192 个 token
jina-colbert-v1/v2: 8,192 个 token
jina-code-embeddings-*: 32,768 个 token

除非设置了 truncate: true，否则超出限制的输入将返回错误，设置后会自动截断到最大长度。

最大文件大小为：图片： 5 MB，PDF： 8 MB。超过此限制的文件将被拒绝并显示错误信息。

重排器 API 的定价与我们的向量模型 API 定价结构一致。每个新 API 密钥都会获得 1000 万个免费词元。除了免费词元之外，还可以购买不同的套餐。欲了解更多详情，请访问我们的定价部分。

jina-reranker-v3 是我们最新的旗舰级重排序器，采用新颖的列表式架构，在 131K 上下文长度下实现了最先进的多语言检索。jina-reranker-m0 是我们用于跨语言对视觉文档进行排序的多模态重排序器。jina-reranker-v2-base-multilingual 是一个交叉编码器，支持 100 多种语言，并具备函数调用和代码检索功能。jina-colbert-v2 使用延迟交互技术，支持 89 种语言，并提供用户可控的嵌入大小。

是的，我们所有的重排序工具（jina-reranker-v3、jina-reranker-m0、jina-reranker-v2-base-multilingual 和 jina-colbert-v2）都是开源的，并遵循 CC-BY-NC 4.0 许可协议。您可以自由地使用、分享和改编这些模型，但仅限非商业用途。

是的，我们所有的重排序工具都支持多语言检索。jina-reranker-v3 和 jina-reranker-v2-base-multilingual 支持 100 多种语言。jina-reranker-m0 支持多语言可视化文档排名。jina-colbert-v2 支持 89 种语言。

上下文长度因模型而异：

jina-reranker-v3： 131,072 个词元（查询 + 所有文档的总和），启用自动截断
jina-reranker-m0： 10,000 个词元
jina-reranker-v2-base-multilingual： 1,024 个词元，对较长的文档进行自动分块
jina-reranker-v1-*： 1,024 个词元，启用自动分块
jina-colbert-v2： 8,192 个词元

对于 v1/v2 重排序器，查询会自动截断，长文档会分块，并在块之间进行最大池化。

每次请求的文档数量没有硬性限制。与我们的 Embeddings API 类似，Reranker API 会根据 token 数量对输入进行内部分批处理，以优化 GPU 利用率。您可以在单个请求中发送所需的任意数量的文档。

延迟从 100 毫秒到 7 秒不等，主要取决于文档和查询的长度。例如，使用 64 个词元的查询对 100 个包含 256 个词元的文档进行重排大约需要 150 毫秒。将文档长度增加到 4096 个词元将使时间增加到 3.5 秒。如果查询长度增加到 512 个词元，则时间进一步增加到 7 秒。

是的，我们的服务在 AWS、Azure 和 GCP 市场上可用。如果您有特定要求，请通过 sales AT jina.ai 联系我们。

如果您对针对特定域数据量身定制的微调重排器感兴趣，请联系我们的销售团队。我们的团队将及时回复您的询问。

jina-reranker-m0 模型可接受的最小图像尺寸为 28x28 像素。

jina-reranker-v3 采用了一种新颖的列表式架构，在一次前向传递中对所有文档进行评分，从而实现跨文档比较。传统的逐点重排序器（例如 v2）则独立地对每个文档与查询进行评分。列表式重排序通过理解整个候选集中文档的相对相关性，实现了更高的准确率。

虽然我们的一些重排序模型在架构上能够处理更长的上下文长度，但由于推理基础架构中 GPU 显存的限制，API 可能会强制执行较低的限制。处理非常长的序列需要大量的内存，我们针对大多数使用场景优化了服务配置，以平衡吞吐量、延迟和成本。如果您需要更长的上下文长度支持，请联系我们的销售团队，讨论专门的部署方案。

速率限制取决于您的 API 密钥类型：

免费版： 100 RPM，100K TPM，2 个并发请求
付费版： 500 RPM，2M TPM，50 个并发请求
高级版： 5,000 RPM，50M TPM，500 个并发请求

此外，还有基于 IP 的速率限制，每 60 秒 10,000 个请求。这些速率限制同样适用于 Embeddings API 和 Reranker API。

是的，同一个 API 密钥适用于 Jina AI 的所有搜索基础产品。这包括读取器、向量模型、重排器、分类器和微调模型 API，所有服务之间共享词元。

是的，您可以在“密钥和计费”选项卡中输入您的 API 密钥来查看最近的使用记录和剩余额度。如果您已登录 API 密钥控制面板，也可以在“管理 API 密钥”选项卡中查看这些详细信息。

如果您遗失了充值密钥并希望找回，请使用您的注册电子邮件联系 support AT jina.ai 寻求帮助。建议登录以便于安全保存和便捷访问您的 API 密钥。

不，我们的 API 密钥没有到期日期。但是，如果您怀疑您的密钥已被泄露并希望停用它，请联系我们的支持团队寻求帮助。您还可以在API 密钥控制面板中自助销毁您的密钥。

是的，您可以将剩余的付费额度从一个高级密钥转移到另一个密钥。在API 密钥控制面板上登录您的帐户后，在该密钥的设置界面来转移所有剩余的付费额度。

是的，如果您认为您的 API 密钥已被泄露，您可以销毁该密钥。销毁密钥将立即为所有存储该密钥的用户禁用该密钥，并且所有剩余额度和关联资产将永久不可用。如果您拥有高级密钥，您可以选择在销毁之前将剩余的已付款额度转移到另一个密钥。请注意，此操作无法撤消。要销毁密钥，请前往API 密钥控制面板中的密钥设置。

这是因为我们的无服务器架构在使用率较低时会卸载某些模型。初始请求会激活或“预热”模型，这可能需要几秒钟。初始激活后，后续请求的处理速度会快得多。

不。我们绝不会使用您的 API 请求、输入或输出来训练我们的嵌入模型、重排序模型或任何其他模型。您的数据始终归您所有。我们符合 SOC 2 I 型和 II 型标准。

每个 API 密钥均有速率限制：

免费版： 100 RPM，100K TPM，2 个并发请求
付费版： 500 RPM，2M TPM，50 个并发请求
高级版： 5,000 RPM，50M TPM，500 个并发请求

此外，还有基于 IP 的速率限制，每 60 秒 10,000 个请求。这些限制适用于所有 Jina API（嵌入式 API、重排序 API、读取器 API 等）。

Embeddings API 和 Reranker API 均无批次大小限制。您可以根据需要每次请求发送任意数量的项目或文档。这两个 API 都会根据 token 数量对输入进行内部批处理，以实现最佳的 GPU 利用率。

我们的定价模型基于处理的词元总数，允许用户灵活地在任意数量的句子中分配这些词元，为不同的文本分析需求提供经济高效的解决方案。

我们为新用户提供免费试用，自动生成的 API 密钥包含一千万个可用于我们任何模型的词元。免费额度用完后，用户可以通过"充值"标签页轻松购买额外的额度。

不，失败的请求不会扣除词元。

付款通过 Stripe 处理，支持多种付款方式，包括信用卡、Google Pay 和 PayPal，为您提供方便。

是的，充值后发票将发送到与您的 Stripe 帐户关联的电子邮件地址。

深度搜索是一个大模型API，它执行迭代搜索、读取和推理，直到找到查询的准确答案或达到其词元预算限制。

与 OpenAI 和 Gemini 不同，深度搜索专注于通过迭代提供准确的答案，而不是生成长篇文章。它针对深度网络搜索的快速、精确答案进行了优化，而不是创建全面的报告。

您需要 Jina API 密钥。我们为新 API 密钥提供 1000 万个免费词元。

它根据所有积累的知识生成最终答案，而不是仅仅放弃或返回不完整的答案。

不是。虽然它使用迭代搜索过程来提高准确性，但评估显示它在测试题目上的通过率达到了 75％，明显优于 0％ 的基线（gemini-2.0-flash），但并不完美。

它差别很大 - 根据评估数据，查询可能需要 1 到 42 步，平均需要 4 步。也就是 20 秒。简单的查询可能很快得到解决，而复杂的研究问题可能涉及多次迭代，最多需要 120 秒。

是的，deepsearch.jina.ai/v1/chat/completions 上的官方深度搜索API 与 OpenAI API 架构完全兼容，使用“jina-deepsearch-v1”作为模型名称。因此，从 OpenAI 切换到深度搜索并与本地客户端或任何兼容 OpenAI 的客户端一起使用非常容易。我们强烈推荐 Chatwise 以获得无缝体验。

速率限制因 API 密钥层而异，范围从 10 RPM 到 30 RPM。对于查询量大的应用程序来说，这一点很重要。

深度搜索将思考步骤包装在 XML 标签 ... 中，然后提供最终答案，遵循 OpenAI 流格式，但使用这些特殊标记来表示思路链。

是的。Jina Reader 用于网页搜索和读取，为系统提供高效访问和处理网页内容的能力。

是的，深度搜索在复杂查询中的词元使用量可以说很高 - 平均为 70,000 个词元，而基本大模型响应为 500 个词元。这显示了研究的深度，但也影响了成本。

该系统主要由词元预算而非步数控制。一旦超出词元预算，系统就会进入 Beast 模式以生成最终答案。查看 reasoning_effort 了解更多详情。

参考文献非常重要，如果一个答案被认为是明确的，但缺乏参考文献，系统会继续搜索而不是接受该答案。

是的，但需要进行大量的研究。“谁将在 2028 年成为总统”的例子表明，它可以通过多次研究迭代来处理推测性问题，尽管这种预测的准确性无法得到保证。

零样本分类需要语义标签，训练时不需要，而少样本分类则需要训练时需要标签，但分类时不需要。这意味着零样本分类更适合灵活、即时的分类需求，而少样本分类更适合固定的、特定领域的类别，这些类别可以随时间而演变。

num_iters 控制训练强度 - 较高的值会强化重要示例，而较低的值会最大限度地减少不太可靠数据的影响。它可用于通过为近期示例提供更高的迭代次数来实现时间感知学习，这使其对于不断发展的数据模式很有价值。

任何拥有 classifier_id 的人都可以使用公共分类器，并消耗自己的词元配额。用户无法访问训练数据或配置，也无法查看其他人的分类请求，从而实现安全的分类器共享。

少量样本需要 200-400 个训练样本才能超越零样本分类。虽然它最终会实现更高的准确率，但需要这段预热期才能发挥作用。零样本无需训练数据即可立即提供一致的性能。

是的 - API 支持使用 jina-embeddings-v3 进行多语言查询，以及使用 jina-clip-v2 或 jina-embeddings-v4 进行多模态（文本/图像）分类，并支持在同一请求中使用 URL 或 base64 编码的图像。

Zero-shot 支持 256 个类别，没有分类器限制，而 few-shot 则限制为 16 个类别和 16 个分类器。两者均支持每个请求 1,024 个输入和每个输入 8,192 个词元。

少量样本模式允许通过 /train 端点进行持续更新，以适应不断变化的数据模式。当数据分布发生变化时，您可以逐步添加新的示例或类别，而无需重建整个分类器。

该 API 使用一次性在线学习 - 训练示例会更新分类器权重，但之后不会存储。这意味着您无法检索历史训练数据，但它可以确保隐私和资源效率。

当您需要使用语义标签进行灵活分类时，请从零样本开始，以获得即时结果。当您有 200-400 个示例、需要更高的准确度或需要处理特定领域/时间敏感的数据时，请切换到少样本。

是的，您可以选择用于文本分类的 jina-embeddings-v3（尤其适用于多语言），用于多模态分类的 jina-clip-v2（支持 89 种语言），或者用于通用多模态多语言分类的 jina-embeddings-v4。

切分器可免费使用。通过提供您的 API 密钥，您可以访问更高的速率限制，并且不会向您的密钥收费。

如果没有 API 密钥，您可以以 20 RPM 的速率限制访问切分器。

使用 API 密钥，您可以以 200 RPM 的速率限制访问切分器。对于高级付费用户，速率限制为 1000 RPM。

不可以，您的 API 密钥仅用于访问更高的速率限制。

是的，切分器是多语言的，支持超过 100 种语言。

GET 请求仅用于计算文本中的词元数，可让您轻松将其作为计数器集成到应用程序中。POST 请求支持更多参数和功能，例如返回第一个/最后一个 N 个词元。

每个请求最多可以发送 64k 个字符。

切块功能可根据常见的结构线索将长文档分割成较小的块，从而确保将文本准确地分割成有意义的块。本质上，它是一个（大！）正则表达式模式，可根据某些通常与语义边界一致的句法特征（例如句子结尾、段落分隔符、标点符号和某些连词）对文本进行分割。它不是语义切块。这个（大）正则表达式在正则表达式的限制范围内尽可能强大。它平衡了复杂性和性能。虽然正则表达式无法实现真正的语义理解，但它可以通过常见的结构线索很好地近似上下文。

如果输入包含特殊词元，我们的切分器会将它们放入`special_tokens`字段中。这样您就可以轻松识别它们并根据下游任务进行相应的处理，例如在将文本输入大模型之前将其删除以防止注入攻击。

除了西方语言外，分块技术还适用于中文、日语和韩语。

此功能目前处于测试阶段，每个微调模型需要花费 100 万个词元。如果 Embedding/Reranker API 中有足够的词元，您可以使用现有的 API 密钥，也可以创建一个新的 API 密钥，其中包含 1000 万个免费词元。

您无需提供任何训练数据。只需用自然语言描述您的目标域（您希望优化微调向量模型的域），或使用 URL 作为参考，我们的系统就会生成合成数据来训练模型。

大约 30 分钟。

经过微调的模型和合成数据公开存储在 Hugging Face 模型中心。

系统使用 Reader API 从 URL 中获取内容。然后分析内容以总结语气和领域，并以此作为生成合成数据的指导方针。因此，URL 应该是公开可访问的，并且代表目标域。

是的，您可以针对非英语语言微调模型。系统会自动检测域指令的语言并相应地生成合成数据。我们还建议为目标语言选择合适的底座模型。例如，如果针对德语域，则应选择“jina-embeddings-v2-base-de”作为底座模型。

不，我们的微调 API 仅支持 Jina v2 模型。

在微调过程结束时，系统会使用保留的测试集评估模型并报告性能指标。您将收到一封电子邮件，详细说明此测试集的前后性能。我们还鼓励您在自己的测试集上评估模型以确保其质量。

该系统通过将您提供的目标域指令与大模型智能体的推理相结合来生成合成数据。它会产生具有挑战的三元组，这对于训练高质量的向量模型模型至关重要。有关更多详细信息，请参阅我们即将在 Arxiv 上发表的研究论文。

目前没有。请注意，此功能仍处于测试阶段。将微调后的模型和合成数据公开存储在 Hugging Face 模型中心有助于我们和社区评估训练的质量。未来，我们计划提供私人存储选项。

由于所有微调模型都已上传至 Hugging Face，因此您只需指定模型名称即可通过 SentenceTransformers 访问它们。

请检查您的垃圾邮件文件夹。如果仍然找不到，请使用您提供的电子邮件地址联系我们的支持团队。