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

はい。Jina はモデルブランドへと移行しつつあります。Alibaba にとっての Qwen、OpenAI にとっての GPT、Moonshot にとっての Kimi のようなものです。当社は法人としてのアイデンティティを「Jina AI」から Elastic へ徐々に移行し、Jina AI がブランドとして Search Foundation モデルに専念できるようにしていきます。

検索をより良くするための Embeddings、Reranker、そして小規模言語モデルです。私たちの使命はまだ達成されていません。私たちは目標を隠したことはありません。検索モデルの主要なプロバイダーになることです。

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

はい。Elastic においても、Jina は Search Foundation モデルの最前線を押し広げ続け、オープンウェイトモデルのリリースを継続します。

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

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

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

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

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 を取得し、そのコンテンツをブラウザーでレンダリングして、高品質のプライマリ コンテンツを抽出します。

Reader APIのコードは、Jina AIのGitHubリポジトリにあります。ReaderLM-v2モデルは、オープンソースライセンスではなく、CC-BY-NC 4.0非営利ライセンスでライセンスされていることにご注意ください。

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

スクレイピングは、特に複雑なページや動的なページの場合、複雑で信頼性に欠けることがあります。Reader API は、クリーンで LLM にすぐ使えるテキストを、簡潔かつ確実に出力します。

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

はい。Readerは標準的なウェブクライアントとして動作し、ウェブサイトのアクセス制御に従います。ウェブサイトがリクエストをブロックした場合、Readerはその結果を尊重します。Readerの使用が、アクセスするウェブサイトの利用規約に準拠し、第三者の知的財産権を侵害しないことを確認するのは、お客様の責任です。

はい、Reader API は PDF ファイルからコンテンツをネイティブに抽出できます。

はい、Reader は x-with-generated-alt ヘッダーを使用して、Web ページ上の画像にキャプションを付けられます。これにより、alt タグのない画像に説明的な alt タグが追加され、LLM が視覚的なコンテンツを理解できるようになります。動画の要約は今後のリリースで予定されています。

いいえ、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 にあるすべての画像にキャプションを付け、元々 alt タグがない場合は `Image [idx]: [caption]` を alt タグとして追加します。これにより、下流の LLM が推論や要約などで画像を活用できるようになります。

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

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

ReaderLM-v2 は、生の HTML をクリーンな Markdown または JSON に変換するための最新の小規模言語モデル (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 のコンテキスト長、密（dense）検索と遅延インタラクション（late-interaction）検索に対応し、視覚的にリッチなドキュメントで SOTA のパフォーマンスを実現します。jina-clip-v2 はより軽量な選択肢（8億6500万パラメータ）で、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トークンをサポートします。1 トークンは 1 文字から単語 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 Representation Learning（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の場合、タイル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-embeddings-v4、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 は、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 以上の言語をサポートし、function calling とコード検索に対応したクロスエンコーダーです。jina-colbert-v2 は late interaction を用いて 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 VRAM の制約により、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 のすべての Search Foundation 製品で有効です。これには Reader、Embedding、Reranker、Classifier、Fine-tuning の各 API が含まれ、すべてのサービス間でトークンが共有されます。

はい、[API Key & Billing] タブに API キーを入力すると、トークンの使用状況を確認でき、最近の使用履歴と残りのトークンを表示できます。API ダッシュボードにログインしている場合は、[Manage API Key] タブでもこれらの詳細を確認できます。

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

いいえ、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 API と Reranker API のいずれにもバッチサイズの制限はありません。必要に応じて、リクエストごとに任意の数のアイテムまたはドキュメントを送信できます。どちらの API も、GPU を最適に利用するために、トークン数に基づいて入力を内部的にバッチ処理します。

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

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

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

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

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

DeepSearch は、クエリに対する正確な回答が見つかるか、トークン予算の上限に達するまで、反復的な検索、読み取り、推論を実行する LLM 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 にある公式の DeepSearch API は、モデル名として「jina-deepsearch-v1」を使用し、OpenAI API スキーマと完全に互換性があります。そのため、OpenAI から DeepSearch に切り替えて、ローカルクライアントまたは任意の OpenAI 互換クライアントで使用するのは非常に簡単です。シームレスな体験のために Chatwise を強くお勧めします。

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

DeepSearch は、思考ステップを XML タグ ... で囲み、その後に最終的な回答を提供します。OpenAI のストリーミング形式に従いつつ、思考の連鎖を表すこれらの特別なマーカーを使用します。

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

はい、複雑なクエリにおける DeepSearch のトークン使用量は、確かに多く、基本的な LLM 応答の 500 トークンと比較して、平均 70,000 トークンです。これは調査の深さを示していますが、コストにも影響します。

このシステムは、ステップ数ではなく、主にトークン予算によって制御されます。トークン予算を超えると、システムは Beast Mode に入り、最終的な回答を生成します。詳細については、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 キーがない場合は、20 RPM のレート制限で Segmenter API にアクセスできます。

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

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

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

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

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

チャンキング機能は、共通の構造的な手がかりに基づいて長いドキュメントを小さなチャンクに分割し、テキストを意味のあるチャンクへ正確に分割します。本質的には、文末、段落区切り、句読点、特定の接続詞など、意味的な境界としばしば一致する構文上の特徴に基づいてテキストを分割する（巨大な!）正規表現パターンです。セマンティックチャンキングではありません。この（巨大な）正規表現は、正規表現の制約の中で可能な限り強力であり、複雑さとパフォーマンスのバランスを取っています。正規表現では真の意味理解はできませんが、共通の構造的な手がかりによってコンテキストをうまく近似します。

入力に特殊トークンが含まれている場合、Segmenter API はそれらを 'special_tokens' フィールドに格納します。これにより、それらを簡単に識別し、下流のタスクに応じて適切に処理できます。たとえば、テキストを LLM に入力する前に削除してインジェクション攻撃を防ぐことができます。

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

この機能は現在ベータ版で、ファインチューニング済みモデル 1 つにつき 100 万トークンかかります。Embedding/Reranker API の既存の API キーに十分なトークンがあればそれを使用できます。また、1,000 万個の無料トークンが含まれる新しい API キーを作成することもできます。

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

約30分。

ファインチューニング済みモデルと合成データは、Hugging Face のモデルハブで公開状態で保存されます。

システムは Reader API を使用して URL からコンテンツを取得します。次に、そのコンテンツを分析してトーンとドメインを要約し、合成データを生成するためのガイドラインとして使用します。したがって、URL は公開されており、ターゲットドメインを代表するものである必要があります。

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

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

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

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

現在はできません。この機能はまだベータ版であることにご注意ください。ファインチューニング済みモデルと合成データを Hugging Face のモデルハブで公開状態で保存することは、当社とコミュニティがトレーニングの品質を評価するのに役立ちます。将来的には、プライベートストレージのオプションを提供する予定です。

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

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