聯絡銷售

會。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 呼叫。

請先檢視垃圾郵件資料夾。如果仍未找到，請用您填寫的郵箱地址聯絡我們的支援團隊。