聯繫銷售

是的。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 請求、輸入或輸出來訓練我們的 embedding、reranker 或任何其他模型。您的數據始終屬於您。

每個 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 訪問它們。

請檢查您的垃圾郵件文件夾。如果仍然找不到，請使用您提供的電子郵件地址聯繫我們的支持團隊。