営業担当者に問い合わせる

はい。Jinaはモデルブランドへと変貌を遂げています。AlibabaにとってのQwen、OpenAIにとってのGPT、MoonshotにとってのKimiのように。Jina AIは、検索エンジンプラットフォームのモデルブランドに注力できるよう、徐々に社名をJina AIからElasticに変更していきます。

ベクトル化、並べ替え、そして小規模言語モデルは、検索エクスペリエンスの向上に貢献します。私たちの使命はまだ終わっていません。世界クラスの検索モデルプロバイダーになるという目標を、私たちは決して隠していません。

はい。Reader API、Embedding API、Reranker APIは引き続き開発・保守されます。リリースする各モデルは、クラウドマーケットプレイスプラットフォームにも同時にリリースされます。APIサービスはこれまで通りご利用いただけます。唯一の例外は、米国の輸出規制の対象となる組織または国にはサービスを提供できないことです。

はい。Elasticでは、Jinaは検索基盤モデルの限界を押し広げ続け、オープンな重み付けモデルをリリースし続けます。

状況が変わらない限り（可能性は低いですが）、私たちは引き続き CC-BY-NC 4.0 ライセンスのもとで作品を公開していきます。

はい。私たちがリリースするすべてのモデルは厳密な研究論文によって裏付けられており、ICLR、EMNLP、SIGIR、NeurIPS、ICMLなどの主要なカンファレンスに論文を提出し続けます。

これまでと同じように、当社の Web サイトまたは関連するクラウド マーケットプレイスを通じて登録して支払うだけです。

現在、当社の製品はElasticの製品ライブラリ（SKU）にまだ含まれていないため、これらのサービスをご利用いただくには、引き続き当社のウェブサイトからお支払いいただく必要があります。近い将来、JinaモデルはElastic Inference Servicesを通じてご利用いただける予定です。

Elasticの有料ライセンスをお持ちの場合は、モデルに商用利用に関する情報が既に含まれており、すぐにご利用いただけます。ご不明な点がございましたら、Elasticの営業担当者またはフィールドセールスエンジニアまでお問い合わせください。担当者が確認いたします。

現在Elasticとの統合を進めており、今後の方向性はまもなく明確になります。現時点では、モデルごとに個別の商用ライセンスを発行することはできません。

当社は中国に法人を有していないため、中国語での請求書発行はできません。請求書はドイツ本社であるJina AI GmbHより発行されます。

契約ベースの契約は、Jina AIのビジネスモデルにおいて常にごく一部を占めるに過ぎません。ほとんどのお客様は従量課金制のセルフサービスモデルを採用しています。Elasticとの統合を進めていますが、現時点では新たな契約は発行しておりません。

この件について話し合うために、お客様と Jina AI チーム、Elastic の間で会議を設定できるよう、Elastic の営業担当者にご連絡ください。

リーダーAPIの基本機能は無料です。URLの先頭に「https://r.jina.ai/」を追加するだけです。より高いレート制限をご希望の場合は、APIキーをご提供ください。APIキーはコンテンツの長さに応じて課金されます。レート制限の詳細については、質問16をご覧ください。

Reader API は、プロキシを使用して URL を取得し、そのコンテンツをブラウザーでレンダリングして、高品質のプライマリ コンテンツを抽出します。

はい、リーダー API はオープンソースであり、Jina AI GitHub リポジトリにあります。

Reader API は通常、URL を処理して 2 秒以内にコンテンツを返しますが、複雑なページや動的なページの場合はさらに時間がかかる場合があります。

特に複雑なページや動的なページの場合、スクレイピングは複雑で信頼性が低くなる可能性があります。リーダー API は、簡潔で信頼性が高く、簡潔な、クリーンで大規模なモデル レベルのテキスト出力を提供します。

Reader API は、URL のコンテンツを元の言語で返します。翻訳サービスは提供しておりません。

ブロックの問題が発生した場合は、サポート チームに問い合わせて解決策を求めてください。

Reader API は主に Web ページを対象としており、arXiv などのサイトで HTML で表示される PDF からコンテンツを抽出できますが、一般的な PDF 抽出には最適化されていません。

はい、Reader は `x-with-generated-alt` ヘッダーを使用して、ウェブページ上の画像に説明テキストを追加できます。これにより、alt タグのない画像にも説明テキストが追加され、言語学習者が視覚的なコンテンツを理解できるようになります。動画の要約機能は、今後のリリースで予定されています。

いいえ、Reader API は、公的にアクセス可能な URL からのコンテンツのみを処理できます。

5 分以内に同じ URL をリクエストすると、Reader API はキャッシュされたコンテンツを返します。

残念だけど違う。

はい、リーダーでネイティブ PDF サポート (https://r.jina.ai/https://arxiv.org/pdf/2310.19923v4) を使用するか、arXiv で HTML バージョン (https:// r. jina.ai/https://arxiv.org/html/2310.19923v4)

リーダーは指定された URL にあるすべての画像にキャプションを追加し、最初に何もなかった場合は `Image [idx]: [caption]` を alt タグとして追加します。これにより、大規模な下流モデルが推論や要約などのために画像と対話できるようになります。

Reader API は、高度に拡張できるように設計されています。リアルタイムのトラフィックに基づいて自動的に拡張され、同時リクエストの最大数は約 4,000 になりました。当社は、Jina AI のコア製品の 1 つとして積極的に維持しています。したがって、本番環境で自由に使用してください。

最新のレート制限情報は以下の表で確認してください。私たちは Reader API のレート制限とパフォーマンスの改善に積極的に取り組んでおり、それに応じてこの表も更新されることに注意してください。

`ReaderLM-v2` は、生の HTML を簡潔な Markdown または JSON に変換するための最新の Small Language Model (SLM) です。v1 と比較して品質が 3 倍向上し、JSON スキーマまたは自然言語命令を使用して構造化データを抽出できます。`x-respond-with: readerlm-v2` ヘッダーを追加することで Reader API から直接使用することも、クラウド マーケットプレイス (AWS、Azure、GCP) からデプロイすることもできます。

JSONスキーマ定義には`x-json-schema`ヘッダー、自然言語命令には`x-instruction`ヘッダーを使用します。これらの機能はどちらもReaderLM-v2と連携し、任意のWebページから特定のフィールド（価格、タイトル、日付など）を構造化されたJSON形式に抽出します。

いいえ。Readerは、ウェブサイトの防御、アンチボットシステム、アクセス制御を積極的に回避することはありません。ウェブサイトが当社のサービスをボットとして検出し、リクエストをブロックした場合、当社はその結果を尊重します。Readerは標準的なウェブクライアントとして動作し、検出システムを回避するための技術は一切使用していません。

いいえ。無料プランから有料APIキーにアップグレードしても、他のウェブサイトへのアクセスやウェブサイトの制限の回避は許可されません。各プランの主な違いは、レート制限とパフォーマンス最適化です。有料APIキーでは、リクエストスループットと処理速度が向上しますが、当社のサービスをブロックするウェブサイトへのアクセスは許可されません。

トレーニング プロセス、データ ソース、評価の詳細については、arXiv で公開されている技術レポート jina-embeddings-v3 と jina-embeddings-v4 を参照してください。

`jina-embeddings-v4` は、当社の最新の汎用マルチモーダルモデル（38億パラメータ）です。テキストと画像の両方をサポートし、32K のコンテキスト情報を含み、集中的および遅延インタラクティブ検索をサポートし、視覚的にリッチなドキュメントで最先端のパフォーマンスを実現します。`jina-clip-v2` はより軽量なモデル（8億6500万パラメータ）で、89 の言語をサポートし、画像解像度は 512x512 で、マトリョーシカ記法を採用しています。どちらのモデルも、テキストからテキスト、テキストから画像、画像から画像の検索タスクにおいて非常に優れたパフォーマンスを発揮します。

`jina-embeddings-v4`と`jina-embeddings-v3`はどちらも89言語をサポートし、強力な多言語機能を誇ります。サポートされている上位30言語は、アラビア語、ベンガル語、中国語、デンマーク語、オランダ語、英語、フィンランド語、フランス語、グルジア語、ドイツ語、ギリシャ語、ヒンディー語、インドネシア語、イタリア語、日本語、韓国語、ラトビア語、ノルウェー語、ポーランド語、ポルトガル語、ルーマニア語、ロシア語、スロバキア語、スペイン語、スウェーデン語、タイ語、トルコ語、ウクライナ語、ウルドゥー語、ベトナム語です。`jina-clip-v2`も89言語をサポートしており、マルチモーダルタスクに使用できます。

コンテキストの長さはモデルによって異なります。`jina-embeddings-v4` は最大32Kトークンをサポートし、`jina-embeddings-v3` と `jina-clip-v2` は最大8192トークンをサポートします。トークンは1文字または完全な単語です。この拡張コンテキストにより、大量のテキストデータに対するより包括的なドキュメント分析が可能になり、コンテキスト理解の精度が向上します。

各リクエストに含めることができるアイテムの数に厳密な制限はありません。APIはGPU利用率を最適化するため、トークンの数に基づいて入力を内部的にバッチ処理します。1回のリクエストで任意の数のテキストまたは画像を送信できます。

`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-embeddings と互換性があるため、移行プロセスはスムーズでした。 -3-large モデルの入力 JSON スキーマと出力 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の場合、タイル1つあたりのコストは10トークン、jina-clip-v2の場合、タイル1つあたりのコストは4000トークン、jina-clip-v1の場合、タイル1つあたりのコストは1000トークンです。 例： 600x600ピクセルの画像の場合： • jina-embeddings-v4 を使用する場合 • 画像は28x28ピクセルのタイルに分割されます。 • 必要なタイルの総数は、22 (横) x 22 (縦) = 484 タイルです。 • jina-embeddings-v4 のコストは、484 * 10 = 4840 トークンです。 • jina-clip-v2 を使用します。 • 画像は 512 x 512 ピクセルのタイルに分割されます。 • 必要なタイルの総数は、2 (横) x 2 (縦) = 4 タイルです。 • jina-clip-v2 のコストは、4 * 4000 = 16000 トークンです。 • jina-clip-v1 を使用します。 • 画像は 224 x 224 ピクセルのタイルに分割されます。 • 必要なタイルの総数は、3（横）×3（縦）＝9枚です。 • jina-clip-v1のコストは、9×1000＝9000トークンです。

はい、jina-clip-v2 と jina-clip-v1 は画像とテキストをサポートできます。より多くのモダリティのベクトル モデルが近日中に発表される予定です。

特定のデータを使用したモデルの微調整についてご質問がある場合は、要件についてお問い合わせください。私たちのモデルをお客様のニーズに合わせてどのように適応できるかを検討したいと考えています。

はい、当社のサービスは AWS、Azure、GCP マーケットプレイスで利用できます。特定の要件がある場合は、セールス 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` API は、Qwen Research License に基づいてリリースされている Qwen2-VL ベースモデル上に構築されています。このライセンスは研究および非商用利用のみを許可しているため、`jina-embeddings-v4` を商用製品として提供することはできません。そのため、このモデルへのアクセスは API 経由で無料で提供しています。`jina-embeddings-v4` は、他のモデルよりも遅くなる可能性がありますが、これには 2 つの理由があります。1 つ目は、`jina-embeddings-v4` モデルは `jina-embeddings-v3` モデルよりも大幅に大きいため、リクエストあたりの計算時間が長くなることです。2 つ目は、このモデルを商用化できないため、インフラストラクチャコストを抑えるために 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 の価格は、Embedding API の価格体系と一致しています。新しい API キーごとに 1,000 万個の無料トークンが付属します。無料トークンに加えて、さまざまなパッケージを購入することもできます。詳細については、料金セクションをご覧ください。

`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はトークン数に基づいて入力を内部的にバッチ処理し、GPU利用率を最適化します。必要な数のドキュメントを1回のリクエストで送信できます。

待ち時間は、ドキュメントとクエリの長​​さに応じて、100 ミリ秒から 7 秒の範囲です。たとえば、64 語のクエリを使用して 256 個のトークンを持つ 100 個のドキュメントを並べ替えるには、約 150 ミリ秒かかります。ドキュメントの長さを 4096 トークンに増やすと、時間は 3.5 秒に増加します。クエリの長​​さが 512 トークンに増加すると、時間はさらに 7 秒に増加します。

はい、当社のサービスは AWS、Azure、GCP マーケットプレイスで利用できます。特定の要件がある場合は、セールス 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 のすべての検索ベース製品で機能します。これには、Reader、Embedding、Reranger、Classifier、Fine-Tune Model API が含まれており、すべてのサービス間でトークンが共有されます。

はい、[キーと請求] タブに API キーを入力すると、最近のトークン使用量と残りのトークン残高を表示できます。 API キー コントロール パネルにサインインしている場合は、[API キーの管理] タブでこれらの詳細を表示することもできます。

リチャージ キーを紛失し、再取得したい場合は、登録した電子メールを使用してサポート AT jina.ai までご連絡ください。安全に保管し、API キーに簡単にアクセスできるように、ログインすることをお勧めします。

いいえ、API キーには有効期限がありません。ただし、キーが侵害された疑いがあり、キーを非アクティブ化したい場合は、弊社のサポート チームにご連絡ください。 API キー コントロール パネルでキーを自己破壊することもできます。

はい、残りの有料トークン残高をあるプレミアム キーから別のプレミアム キーに移すことができます。 API キー コントロール パネルでアカウントにログインした後、キー転送の設定インターフェースに移動します。残りのすべての支払い済みトークン残高。

はい、API キーが侵害されたと思われる場合は、破棄できます。キーを破棄すると、そのキーを保存しているすべてのユーザーに対してキーが即座に無効になり、残りのトークン残高と関連資産はすべて永久に利用できなくなります。プレミアム キーをお持ちの場合は、それを書き込む前に、残りの支払い済みトークンの残高を別のキーに転送することを選択できます。この操作は元に戻すことができないことに注意してください。キーを破棄するには、API キー ダッシュボードのキー設定に移動します。

これは、使用率が低い場合、サーバーレス アーキテクチャが特定のモデルをオフロードするためです。最初のリクエストではモデルがアクティブ化または「ウォームアップ」されますが、これには数秒かかる場合があります。最初のアクティベーションの後、後続のリクエストははるかに高速に処理されます。

いいえ。埋め込みモデル、並べ替えモデル、その他のモデルの学習に、お客様のAPIリクエスト、入力、出力を使用することは一切ありません。お客様のデータは常にお客様の所有物です。当社はSOC 2 Type IおよびType 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も、GPUを最適に利用するために、トークン数に基づいて入力を内部的にバッチ処理します。

当社の価格モデルは処理されるトークンの総数に基づいており、ユーザーはこれらのトークンを任意の数の文に柔軟に割り当てることができ、さまざまなテキスト分析ニーズに費用対効果の高いソリューションを提供します。

新規ユーザーには無料トライアルを提供しており、これには自動生成された API キーを介して引き換えられる、当社のどのモデルでも使用できる 1,000 万トークンが含まれています。無料トークンを使い切ったら、ユーザーは「トークンを購入」タブから API キーで使用するための追加トークンを簡単に購入できます。

いいえ、失敗したリクエストに対してトークンは差し引かれません。

支払いは Stripe を通じて処理され、クレジット カード、Google Pay、PayPal などの複数の支払い方法がサポートされているため、便利です。

はい、トークンを購入すると、Stripe アカウントに関連付けられた電子メール アドレスに請求書が送信されます。

Deep Search は、クエリに対する正確な回答が見つかるか、トークン予算の制限に達するまで、反復的な検索、読み取り、推論を実行する大規模なモデル API です。

OpenAI や Gemini とは異なり、DeepSearch は長い記事を生成するのではなく、反復を通じて正確な回答を提供することに重点を置いています。これは、包括的なレポートを作成するためではなく、ディープ ウェブ検索に対する高速で正確な回答を得るために最適化されています。

Jina API キーが必要です。新しい API キーには 1,000 万個の無料トークンを提供します。

単に諦めたり不完全な答えを返すのではなく、蓄積されたすべての知識に基づいて最終的な答えを生成します。

いいえ。精度を向上させるために反復検索プロセスを使用していますが、評価ではテスト問題の合格率が 75% に達しており、0% のベースライン (gemini-2.0-flash) より大幅に向上していますが、完璧ではありません。

評価データによると、クエリには 1 ～ 42 ステップかかることがあり、平均は 4 ステップです。それは20秒です。単純なクエリはすぐに解決できますが、複雑な調査の質問には複数の反復が必要になり、最大 120 秒かかる場合があります。

はい、deepsearch.jina.ai/v1/chat/completions にある公式の Deep Search API は、モデル名として「jina-deepsearch-v1」を使用して、OpenAI API アーキテクチャと完全に互換性があります。したがって、OpenAI から Deep Search に切り替えて、ローカル クライアントまたは任意の OpenAI 互換クライアントで使用するのは非常に簡単です。シームレスな体験のために Chatwise を強くお勧めします。

レート制限は API キー層によって異なり、10 RPM から 30 RPM の範囲になります。これはクエリを多用するアプリケーションにとって重要です。

ディープ サーチは、思考ステップを XML タグ ... で囲み、OpenAI フロー形式に従いながら、思考の連鎖を表すためにこれらの特別なタグを使用して最終的な答えを提供します。

はい。 Jina Reader は Web ページの検索と読み取りに使用され、システムに Web ページのコンテンツに効率的にアクセスして処理する機能を提供します。

はい、複雑なクエリにおける Deep Search のトークン使用量は、おそらく高く、基本的な大規模モデル応答の 500 トークンと比較して、平均 70,000 トークンです。これは研究の深さを示していますが、コストにも影響します。

このシステムは、ステップ数ではなく、主に単語予算によって制御されます。単語単位の予算を超えると、システムはビースト モードに入り、最終的な回答を生成します。詳細については、reasoning_effort を参照してください。

参照は非常に重要であり、回答が明確であるにもかかわらず参照がない場合、システムは回答を受け入れずに検索を続行します。

はい、しかし多くの調査が必要です。 「2028 年に大統領になるのは誰か」という例は、そのような予測の正確さは保証できないものの、複数の研究の反復を通じて推測的な質問に対処することが可能であることを示しています。

ゼロショット分類にはセマンティック ラベルが必要ですが、トレーニング中には必要ありません。一方、少数ショット分類には、トレーニング中にラベルが必要ですが、分類中には必要ありません。これは、柔軟で即時の分類ニーズにはゼロショット分類の方が適しているのに対し、時間の経過とともに進化する可能性がある固定のドメイン固有のカテゴリには少数ショット分類の方が適していることを意味します。

num_iters はトレーニング強度を制御します。値が大きいほど重要な例が強調され、値が小さいほど信頼性の低いデータの影響が最小限に抑えられます。これを使用すると、最近の例をより多くの反復回数で供給することで、時間認識学習を実現でき、進化するデータ パターンにとって価値があります。

classifier_id を持つユーザーは誰でもパブリック分類子を使用し、独自のトークン クォータを消費できます。ユーザーはトレーニング データや設定にアクセスしたり、他の人の分類リクエストを表示したりできないため、安全な分類子の共有が可能になります。

サンプル数が少ない場合、ゼロショット分類を超えるには 200 ～ 400 のトレーニング サンプルが必要です。最終的にはより高い精度が達成されますが、効果的にするにはこのウォームアップ期間が必要です。 Zero-shot は、トレーニング データを必要とせずに、すぐに安定したパフォーマンスを提供します。

はい - 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 から選択できます。

スライサーは無料でご利用いただけます。 API キーを提供すると、より高いレート制限にアクセスでき、キーは請求されません。

API キーを使用しない場合は、20 RPM のレート制限でスライサーにアクセスできます。

API キーを使用すると、200 RPM のレート制限でスライサーにアクセスできます。プレミアム有料ユーザーの場合、レート制限は 1000 RPM です。

いいえ、API キーはより高いレート制限にアクセスするためにのみ使用されます。

はい、スライサーは多言語対応で、100 以上の言語をサポートしています。

GET リクエストはテキスト内のトークンの数をカウントするためにのみ使用されるため、これをカウンターとしてアプリケーションに簡単に統合できます。 POST リクエストは、最初と最後の N 個のトークンを返すなど、より多くのパラメーターと機能をサポートします。

リクエストごとに最大 64,000 文字を送信できます。

タイル機能は、共通の構造上の手がかりに基づいて長い文書を小さなチャンクに分割し、テキストが意味のあるチャンクに正確に分割されるようにします。基本的に、これは、意味上の境界 (文末、段落区切り文字、句読点、および特定の接続詞など) と一般に一致する特定の構文上の特徴に基づいてテキストを分割する (大きな!) 正規表現パターンです。それは意味論的な分割ではありません。この (大きな) 正規表現は、正規表現の制限内で可能な限り強力です。複雑さとパフォーマンスのバランスをとります。正規表現は真の意味の理解を達成することはできませんが、共通の構造上の手がかりを通じてコン​​テキストの適切な近似を提供できます。

入力に特殊なトークンが含まれている場合、トークナイザーはそれらを「special_tokens」フィールドに格納します。これにより、それらを簡単に識別し、下流のタスクで適切に処理することができます。例えば、テキストを大規模なモデルに入力する前に特殊なトークンを削除することで、インジェクション攻撃を防止できます。

チャンキング技術は、西洋言語に加えて、中国語、日本語、韓国語でも機能します。

この機能は現在ベータ版であり、微調整されたモデルごとに 100 万トークンかかります。 Embedding/Reranker API に十分なトークンがある場合は、既存の API キーを使用することも、1,000 万個の無料トークンを含む新しい API キーを作成することもできます。

トレーニング データを提供する必要はありません。ターゲット ドメイン (微調整されたベクトル モデルを最適化するドメイン) を自然言語で記述するか、URL を参照として使用するだけで、システムがモデルをトレーニングするための合成データを生成します。

約30分。

微調整されたモデルと合成データは、Hugging Face Model Center に公的に保存されます。

システムは Reader API を使用して URL からコンテンツを取得します。次に、コンテンツを分析してトーンとドメインを要約し、合成データを生成するためのガイドラインとして使用しました。したがって、URL はパブリックにアクセス可能であり、ターゲット ドメインを表す必要があります。

はい、英語以外の言語向けにモデルを微調整できます。システムはドメイン命令の言語を自動的に検出し、それに応じて合成データを生成します。また、ターゲット言語に適切な基本モデルを選択することをお勧めします。たとえば、ドイツ語ドメインをターゲットとする場合は、「jina-embeddings-v2-base-de」をベース モデルとして選択する必要があります。

いいえ、微調整 API は Jina v2 モデルのみをサポートしています。

微調整プロセスの最後に、保持されたテスト セットを使用してモデルが評価され、パフォーマンス メトリックが報告されます。このテスト セットの前後のパフォーマンスの詳細を記載した電子メールが届きます。また、品質を保証するために、独自のテスト セットでモデルを評価することをお勧めします。

システムは、ユーザーが提供するターゲット ドメインの指示と大規模なモデル エージェントからの推論を組み合わせて、合成データを生成します。高品質のベクトルベースのモデルをトレーニングするために不可欠な、難しいトリプレットを生成します。詳細については、Arxiv で公開予定の研究論文をご覧ください。

今は何もありません。この機能はまだベータ版であることに注意してください。微調整されたモデルと合成データを Hugging Face Model Center に公開して保存することは、私たちとコミュニティがトレーニングの品質を評価するのに役立ちます。将来的には、プライベート ストレージ オプションも提供する予定です。

すべての微調整されたモデルはすでに Hugging Face にアップロードされているため、SentenceTransformers を通じてモデル名を指定するだけでモデルにアクセスできます。

スパムフォルダを確認してください。それでも見つからない場合は、指定した電子メール アドレスを使用してサポート チームにお問い合わせください。