联系销售

会。Jina 正在转型为一个模型品牌，就像 Qwen 之于阿里巴巴、GPT 之于 OpenAI、Kimi 之于月之暗面。我们会逐步把公司的法律主体从 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 进行会面讨论。

Reader API 基础用法免费，只需在 URL 前加上「https://r.jina.ai/」即可。如需更高的速率限制，可提供 API 密钥，届时会按内容长度扣除词元。速率限制详情请参见问题 16。

Reader API 通过代理抓取任意 URL，在浏览器中渲染页面，从而提取出高质量的正文内容。

Reader API 的代码可在 Jina AI 的 GitHub 代码库中找到。请注意，ReaderLM-v2 模型采用 CC-BY-NC 4.0 协议，仅限非商业用途，并非开源许可。

Reader API 通常在 2 秒内处理完 URL 并返回内容，复杂或动态页面可能需要更长时间。

自己抓取既麻烦又不稳定，遇到复杂或动态页面尤其如此。Reader API 直接给出干净、可靠、适合大模型阅读的文本。

Reader API 按 URL 原本的语言返回内容，不提供翻译服务。

遵循。Reader 作为标准网页客户端运行，会遵循网站的访问控制。如果网站拒绝了请求，我们就尊重这一结果。您有责任确保使用 Reader 时符合所访问网站的条款，且不侵犯第三方知识产权。

可以，Reader API 原生支持从 PDF 文件中提取内容。

可以，Reader 支持通过 x-with-generated-alt 请求头为网页图片生成描述。它会给缺少 alt 标签的图片补上描述性文字，让大模型也能理解视觉内容。视频摘要功能计划在后续版本中推出。

不可以，Reader API 只能处理可公开访问的 URL。

如果您在 5 分钟内重复请求同一个 URL，Reader API 会返回缓存内容。

很遗憾，不可以。

可以，您既能用 Reader 的原生 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 schema 或自然语言指令抽取结构化数据。您可以在 Reader API 中加上 x-respond-with: readerlm-v2 请求头直接调用，也可以从云市场（AWS、Azure、GCP）部署。

加上 x-json-schema 请求头并给出 JSON schema 定义，或者加上 x-instruction 请求头并给出自然语言指令。这两种方式都由 ReaderLM-v2 支撑，可以把任意网页中的价格、标题、日期等字段抽取成结构化 JSON。

不会。Reader 不会主动规避或绕过任何网站的防御机制、反爬系统或访问控制。如果网站把我们的服务识别为机器人并拒绝请求，我们就尊重这一结果。我们作为标准网页客户端运行，不使用任何逃避检测的技术。您仍需自行确保使用 Reader 时尊重第三方知识产权和所访问网站的条款。

不会。从免费套餐升级到付费 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，您可以使用 url 或 bytes，填入 API 请求的 input 字段。使用 url 时，填入待处理图片的地址；使用 bytes 时，把图片编码为 base64 格式。jina-embeddings-v4 还支持直接向量化 PDF 文档，传入 PDF 地址或 base64 编码的 PDF 字节即可。

jina-embeddings-v4 是我们最新的旗舰模型，在图文混排文档检索（ViDoRe）和多模态基准测试上均达到业界领先水平。在纯文本任务上，jina-embeddings-v3 于 MTEB 英语和多语言基准上超越 OpenAI 和 Cohere，同时体积更小、效率更高。两个模型都支持 Matryoshka 表示学习（MRL），可在性能损失很小的前提下截断维度（v3 最低可至 32 维，v4 最低可至 128 维）。

迁移非常顺畅，因为我们的 API 端点与 OpenAI text-embedding-3-large 模型的输入和输出 JSON 结构一致。得益于这种兼容性，您在使用 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 个词元。 • 使用 jina-clip-v2 • 图片被切分为 512x512 像素的图块。 • 所需图块总数为 2（横向）x 2（纵向）= 4 个。 • jina-clip-v2 的费用为 4*4000 = 16000 个词元。 • 使用 jina-clip-v1 • 图片被切分为 224x224 像素的图块。 • 所需图块总数为 3（横向）x 3（纵向）= 9 个。 • jina-clip-v1 的费用为 9*1000 = 9000 个词元。

是的，jina-embeddings-v4、jina-clip-v2 和 jina-clip-v1 都可以同时向量化图片和文本。支持更多模态的向量模型即将发布！

如需用特定数据微调我们的模型，请联系我们详谈您的需求。我们乐于探讨如何调整模型来贴合您的场景。

可以，我们的服务已上架 AWS、Azure 和 GCP 市场。如有特殊需求，请通过 sales AT jina.ai 联系我们。

task 参数可在 jina-embeddings-v3 和 jina-embeddings-v4 中激活任务专属的 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 词元
jina-embeddings-v3: 8,192 词元
jina-embeddings-v2-*: 8,192 词元
jina-clip-v1/v2: 8,192 词元
jina-colbert-v1/v2: 8,192 词元
jina-code-embeddings-*: 32,768 词元

超出上限的输入会返回错误，除非设置 truncate: true，届时会自动截断到最大长度。

文件大小上限为：图片：5 MB，PDF：8 MB。超过上限的文件会被拒绝并返回错误。

Reranker 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 重排模型，查询会自动截断，长文档会分块，并在块之间进行最大池化。

单次请求的文档数量没有硬性上限。与向量模型 API 一样，Reranker API 会按词元数在内部自动分批，以充分利用 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 次请求。向量模型 API 和 Reranker API 适用同一套速率限制。

可以，同一个 API 密钥适用于 Jina AI 的所有搜索基础产品，包括 Reader、向量模型、重排、分类和微调 API，词元额度在各项服务之间共享。

可以，在“API 密钥与计费”标签页输入您的 API 密钥，即可查看近期用量记录和剩余词元。如果您已登录 API 控制面板，也可以在“管理 API 密钥”标签页查看这些信息。

如果您弄丢了已充值的密钥并希望找回，请用注册邮箱联系 support AT jina.ai。建议登录账户，这样 API 密钥可以安全保存、随时取用。

不会，我们的 API 密钥没有有效期。但如果您怀疑密钥已泄露并希望停用，请联系我们的支持团队。您也可以在 API 密钥控制面板中自行销毁密钥。

可以，您能把词元从一个高级密钥转到另一个密钥。在 API 密钥控制面板登录账户后，进入待转出密钥的设置页，即可转移全部剩余的付费词元。

可以，如果您认为密钥已泄露，可以销毁它。销毁后，所有保存该密钥的用户都会立即无法使用，剩余额度和关联属性也将永久失效。如果是高级密钥，您可以在销毁前把剩余的付费额度转移到另一个密钥。请注意，此操作无法撤销。要销毁密钥，请前往 API 密钥控制面板中的密钥设置。

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

不会。我们绝不会用您的 API 请求、输入或输出来训练向量模型、重排模型或任何其他模型。您的数据始终属于您。

速率限制按 API 密钥计算：

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

此外还有基于 IP 的速率限制，每 60 秒 10,000 个请求。以上限制适用于所有 Jina API（Embeddings、Reranker、Reader 等）。

Embeddings 和 Reranker API 都没有批量大小限制，每次请求可以发送任意数量的条目或文档。两个 API 都会在内部按词元数对输入分批，以充分利用 GPU。

我们按处理的词元总数计费，您可以把这些词元灵活分配到任意数量的句子上，用更低的成本满足各种文本分析需求。

我们为新用户提供免费试用：系统自动生成的 API 密钥内含一千万词元，可用于我们的任何模型。免费额度用完后，您可以在“充值”标签页为密钥购买更多词元。

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

付款通过 Stripe 处理，支持信用卡、Google Pay、PayPal 等多种方式，方便您选择。

可以，充值后发票会发送到与您 Stripe 账户关联的邮箱。

DeepSearch 是一个大模型 API，它会反复搜索、读取和推理，直到找到准确答案或用完词元预算。

与 OpenAI 和 Gemini 不同，DeepSearch 专注于通过迭代给出准确答案，而不是生成长篇文章。它面向深度网页搜索下的快速、精准回答做了优化，目标不是撰写详尽的研究报告。

您需要一个 Jina API 密钥。新建的 API 密钥可获赠 1000 万免费词元。

它会基于已积累的全部知识生成最终答案，而不是直接放弃或返回残缺的回答。

不能。虽然它用迭代搜索来提升准确性，但评估显示其在测试题上的通过率为 75%，明显优于 0% 的基线（gemini-2.0-flash），但并不完美。

差异很大。根据评估数据，一次查询可能需要 1 到 42 步，平均 4 步，约合 20 秒。简单查询很快就能解决，复杂的研究型问题则可能经过多轮迭代，最长需要 120 秒。

可以。官方 DeepSearch API（deepsearch.jina.ai/v1/chat/completions）与 OpenAI API schema 完全兼容，模型名填 “jina-deepsearch-v1” 即可。因此从 OpenAI 切换到 DeepSearch 非常简单，可搭配本地客户端或任何兼容 OpenAI 的客户端使用。我们非常推荐 Chatwise，体验更顺畅。

速率限制随 API 密钥等级而异，从 10 RPM 到 30 RPM 不等。查询量大的应用需要重点考虑这一点。

DeepSearch 会把思考步骤包在 XML 标签 ... 中，随后再给出最终答案。整体遵循 OpenAI 流式输出格式，只是额外用这些标记标示思维链。

是的。网页搜索和读取由 Jina Reader 完成，使系统能高效访问和处理网页内容。

确实，DeepSearch 在复杂查询上的词元消耗相当高，平均约 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 编码图片。

零样本支持 256 个类别，分类器数量不限；少样本最多 16 个类别和 16 个分类器。两者都支持每次请求 1,024 条输入，每条输入 8,192 词元。

少样本模式可通过 /train 端点持续更新，以适应变化的数据模式。数据分布改变时，您可以增量添加新样本或新类别，无需重建整个分类器。

该 API 采用单遍在线学习：训练样本会更新分类器权重，但不会被留存。这意味着您无法回溯历史训练数据，但也因此保障了隐私、节省了资源。

需要即时结果、以及需要用语义标签做灵活分类时，先用零样本。当您已有 200-400 条样本、需要更高准确率，或要处理特定领域/时效性强的数据时，再切换到少样本。

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

Segmenter API 免费使用。提供 API 密钥即可获得更高的速率限制，且不会扣除您密钥中的词元。

不提供 API 密钥时，Segmenter API 的速率限制为 20 RPM。

提供 API 密钥时，Segmenter API 的速率限制为 200 RPM；高级付费用户为 1000 RPM。

不会，您的 API 密钥仅用于提升速率限制。

支持，Segmenter API 支持 100 多种语言。

GET 请求仅用于统计文本中的词元数，方便您直接作为计数器集成到应用中。POST 请求支持更多参数和功能，例如返回前 N 个或后 N 个词元。

单次请求最多可发送 64k 个字符。

分块功能依据常见的结构线索把长文档切成较小的分块，确保切出的每一块都语义完整。它本质上是一个（超大的！）正则表达式，按照通常与语义边界重合的句法特征来切分文本，例如句末、段落分隔、标点和某些连词。它不是语义分块。这个正则已经把正则表达式的能力发挥到了极限，在复杂度与性能之间取得平衡。正则无法真正理解语义，但借助常见的结构线索，它能很好地逼近上下文边界。

如果输入中包含特殊词元，Segmenter API 会把它们放入 special_tokens 字段。这样您可以轻松识别并按下游任务的需要处理，例如在把文本送入大模型前先删除它们，以防注入攻击。

除西方语言外，分块在中文、日语和韩语上同样表现良好。

此功能目前处于 Beta 阶段，每微调一个模型消耗 100 万词元。如果您在 Embedding/Reranker API 上的 API 密钥词元充足，可直接使用；也可以新建一个 API 密钥，新密钥包含 1000 万免费词元。

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

大约 30 分钟。

微调后的模型和合成数据会公开存放在 Hugging Face 模型库中。

系统会用 Reader API 抓取该 URL 的内容，再分析内容以归纳其语气和领域，并据此指导合成数据的生成。因此该 URL 应可公开访问，且能代表目标领域。

可以，您能针对非英语语言微调模型。系统会自动识别领域指令所用的语言，并据此生成合成数据。我们还建议为目标语言挑选合适的底座模型，例如面向德语领域时，应选择 “jina-embeddings-v2-base-de” 作为底座模型。

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

微调结束时，系统会用留出的测试集评估模型并给出性能指标。您会收到一封邮件，说明该测试集上微调前后的表现对比。我们也建议您在自己的测试集上评估模型，以确认质量。

系统将您提供的目标领域指令与大模型智能体的推理相结合，生成合成数据，产出高难度负例三元组，这对训练高质量向量模型至关重要。更多细节请参阅我们即将发布在 Arxiv 上的研究论文。

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

所有微调模型都会上传到 Hugging Face，只需指定模型名称即可通过 SentenceTransformers 调用。

请先查看垃圾邮件文件夹。如果仍未找到，请用您填写的邮箱地址联系我们的支持团队。