Voyage rerank-3-lite は、Voyage の Rerank 3 シリーズの低遅延重視版です。テキストのクエリと候補文書を受け取り、各クエリ・文書の組を一緒に評価し、順位付きの関連性スコアを返します。検索の第 2 段階を担い、埋め込み検索やキーワード検索で候補を見つけた後、Lite がその順序を調整します。結果は、検索や検索拡張生成のワークフローで使うランキングです。
Rerank 3 Lite の変更点 開発元は、rerank-2.5-lite と比べて長文とコードの検索を強化したと強調しています。Rerank 3 の両版は、指示追従と同じ 32K クラスのコンテキストを維持し、Lite は遅延に敏感なアプリケーション向けに設計されています。このため、関連結果をすぐに必要とする、対話的なナレッジベース検索、サポート文書検索、コード検索の実用的な候補になります。小型版ならコンテキストウィンドウも小さいと仮定せず、実際の資料群の品質と応答時間の要件に基づいて選んでください。
クエリで関連性を指示する クエリには、何を関連ありとするかを説明する自然言語の指示を添えられます。質問と関連性の希望は簡潔にし、整合させてください。ソフトウェアのサポート検索なら、「デバイスをリセットする手順を見つけてください。指定したハードウェアリビジョンの手順を優先してください」とします。あいまいな製品名では、無関係な意味が上位にならないよう製品カテゴリを含めます。クエリ内の希望は意味的な採点を導きます。候補一覧を作る前に、資料群の明示的なメタデータを使い、正しい製品、文書版、アクセス範囲を選択してください。
テキスト候補の絞り込み一覧を用意する 入力文書は文字列です。原資料から読めるテキストを抽出し、有用なタイトル、見出し、識別子、周辺の文脈を残してください。各入力位置と元の記録の対応を安定して保持します。トラブルシューティング記事では、切り離された一文だけでなく、症状と関連する手順を含めてください。ソースコード検索では、関数と、似た名前の関数と区別するために必要な周辺情報を含めます。繰り返しのナビゲーションや定型文が有用な文章の場所を圧迫する場合は、取り除いてください。
リランカーが並べ替えられるのは、受け取った文書だけです。最初の検索で関連する記事を取得できなければ、この段階で欠けた候補を復元することはできません。結果がおかしい場合は、候補一覧と最終順位の両方を確認してください。長い文書が多くの話題を扱う場合は、まとまりのある節に分け、親文書への参照を残し、出典を失わずに関連する節を選べるようにします。
コンテキストとリクエストの上限 開発元の現在のガイドは、クエリの最大値を 8,000 トークン、クエリと各文書の合計最大値を 32,000 トークンとしています。候補文書は最大 1,000 件、リクエスト全体の予算は 600,000 トークンで、クエリのトークン数に文書数を掛け、すべての文書のトークン数を加えて計算します。そのため、長いクエリは各組の容量を使い、合計予算に繰り返し加算されます。文字数、語数、トークン数を同じものとみなさず、適切なモデルのトークナイザーで送信テキストを数えてください。
たとえば、500 トークンのクエリと、それぞれ 4,000 トークンの文書 100 件では、その式による入力トークン数は 450,000 です。これは予算計算の例であり、候補一覧の推奨件数や速度の実測結果ではありません。文書化された切り詰めオプションは、デフォルトで有効です。長すぎるテキストは、採点前に短縮される場合があります。照合に必要な文章そのものが切り詰めで失われないよう、重要な節を意識して用意してください。
結果を読み、利用する 結果は、関連性スコアの高い順に並びます。各結果は文書の元の入力位置を示し、アプリケーションが独自のタイトル、記録識別子、出典を添えられます。top_k 設定は返す順位付き候補数を制御し、指定しなければ全候補を返します。開発元の REST インターフェースは、文書テキストも返せます。検索ページに表示したり、回答生成段階へ根拠を渡したりする際は、選んだ結果とともに元の識別子を保持してください。
関連性スコアは、候補がクエリにどれだけ合うかを表し、その候補の記述が正しいことを確定するものではありません。除外条件や文書版の違いも含め、上位項目を利用者の実際の質問と比較してください。すべての候補が無関係でも、最上位の項目は存在します。資料群の代表的なクエリを使い、アプリケーションがその場合をどう扱うかを決めてください。
アップグレードと版の選択 開発元は、rerank-3-lite を、API の意味を変えず、対応する前モデルの分布にスコアを校正した、rerank-2.5-lite のアップグレードと説明しています。既存の記録対応と検索段階を保ち、確立済みのスコア閾値に頼る前に、意味のあるクエリで結果の順序を比較してください。応答時間が重要な検索体験には Lite を使い、難しい候補に対する関連性をより重視する場合は、品質重視の rerank-3 版を比較対象にします。
", "aboutText": "Voyage rerank-3-lite は、Voyage の Rerank 3 シリーズの低遅延重視版です。テキストのクエリと候補文書を受け取り、各クエリ・文書の組を一緒に評価し、順位付きの関連性スコアを返します。検索の第 2 段階を担い、埋め込み検索やキーワード検索で候補を見つけた後、Lite がその順序を調整します。結果は、検索や検索拡張生成のワークフローで使うランキングです。\n\nRerank 3 Lite の変更点\n開発元は、rerank-2.5-lite と比べて長文とコードの検索を強化したと強調しています。Rerank 3 の両版は、指示追従と同じ 32K クラスのコンテキストを維持し、Lite は遅延に敏感なアプリケーション向けに設計されています。このため、関連結果をすぐに必要とする、対話的なナレッジベース検索、サポート文書検索、コード検索の実用的な候補になります。小型版ならコンテキストウィンドウも小さいと仮定せず、実際の資料群の品質と応答時間の要件に基づいて選んでください。\n\nクエリで関連性を指示する\nクエリには、何を関連ありとするかを説明する自然言語の指示を添えられます。質問と関連性の希望は簡潔にし、整合させてください。ソフトウェアのサポート検索なら、「デバイスをリセットする手順を見つけてください。指定したハードウェアリビジョンの手順を優先してください」とします。あいまいな製品名では、無関係な意味が上位にならないよう製品カテゴリを含めます。クエリ内の希望は意味的な採点を導きます。候補一覧を作る前に、資料群の明示的なメタデータを使い、正しい製品、文書版、アクセス範囲を選択してください。\n\nテキスト候補の絞り込み一覧を用意する\n入力文書は文字列です。原資料から読めるテキストを抽出し、有用なタイトル、見出し、識別子、周辺の文脈を残してください。各入力位置と元の記録の対応を安定して保持します。トラブルシューティング記事では、切り離された一文だけでなく、症状と関連する手順を含めてください。ソースコード検索では、関数と、似た名前の関数と区別するために必要な周辺情報を含めます。繰り返しのナビゲーションや定型文が有用な文章の場所を圧迫する場合は、取り除いてください。\n\nリランカーが並べ替えられるのは、受け取った文書だけです。最初の検索で関連する記事を取得できなければ、この段階で欠けた候補を復元することはできません。結果がおかしい場合は、候補一覧と最終順位の両方を確認してください。長い文書が多くの話題を扱う場合は、まとまりのある節に分け、親文書への参照を残し、出典を失わずに関連する節を選べるようにします。\n\nコンテキストとリクエストの上限\n開発元の現在のガイドは、クエリの最大値を 8,000 トークン、クエリと各文書の合計最大値を 32,000 トークンとしています。候補文書は最大 1,000 件、リクエスト全体の予算は 600,000 トークンで、クエリのトークン数に文書数を掛け、すべての文書のトークン数を加えて計算します。そのため、長いクエリは各組の容量を使い、合計予算に繰り返し加算されます。文字数、語数、トークン数を同じものとみなさず、適切なモデルのトークナイザーで送信テキストを数えてください。\n\nたとえば、500 トークンのクエリと、それぞれ 4,000 トークンの文書 100 件では、その式による入力トークン数は 450,000 です。これは予算計算の例であり、候補一覧の推奨件数や速度の実測結果ではありません。文書化された切り詰めオプションは、デフォルトで有効です。長すぎるテキストは、採点前に短縮される場合があります。照合に必要な文章そのものが切り詰めで失われないよう、重要な節を意識して用意してください。\n\n結果を読み、利用する\n結果は、関連性スコアの高い順に並びます。各結果は文書の元の入力位置を示し、アプリケーションが独自のタイトル、記録識別子、出典を添えられます。top_k 設定は返す順位付き候補数を制御し、指定しなければ全候補を返します。開発元の REST インターフェースは、文書テキストも返せます。検索ページに表示したり、回答生成段階へ根拠を渡したりする際は、選んだ結果とともに元の識別子を保持してください。\n\n関連性スコアは、候補がクエリにどれだけ合うかを表し、その候補の記述が正しいことを確定するものではありません。除外条件や文書版の違いも含め、上位項目を利用者の実際の質問と比較してください。すべての候補が無関係でも、最上位の項目は存在します。資料群の代表的なクエリを使い、アプリケーションがその場合をどう扱うかを決めてください。\n\nアップグレードと版の選択\n開発元は、rerank-3-lite を、API の意味を変えず、対応する前モデルの分布にスコアを校正した、rerank-2.5-lite のアップグレードと説明しています。既存の記録対応と検索段階を保ち、確立済みのスコア閾値に頼る前に、意味のあるクエリで結果の順序を比較してください。応答時間が重要な検索体験には Lite を使い、難しい候補に対する関連性をより重視する場合は、品質重視の rerank-3 版を比較対象にします。", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "d6d5b9114b8a3a367146239e69220b3e74f4e1439ef5c0b67dd89478e1f09b0c", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "ja", "methods": [ { "html": "voyageai/rerank-3-liteVoyage rerank-3-lite は、応答性の高い検索を重視し、クエリに対する候補テキスト文書を採点して並べ替えます。関連性の指示と 32,000 トークンのクエリ・文書ウィンドウに対応し、検索や RAG のワークフローで、ベクトル検索やキーワード検索の後に役立ちます。
この説明はモデルの機能を紹介するものです。Ailootで利用できる入力、出力、オプションは、選択したメソッドごとに以下に記載されています。
Voyage rerank-3-lite は、Voyage の Rerank 3 シリーズの低遅延重視版です。テキストのクエリと候補文書を受け取り、各クエリ・文書の組を一緒に評価し、順位付きの関連性スコアを返します。検索の第 2 段階を担い、埋め込み検索やキーワード検索で候補を見つけた後、Lite がその順序を調整します。結果は、検索や検索拡張生成のワークフローで使うランキングです。
Rerank 3 Lite の変更点 開発元は、rerank-2.5-lite と比べて長文とコードの検索を強化したと強調しています。Rerank 3 の両版は、指示追従と同じ 32K クラスのコンテキストを維持し、Lite は遅延に敏感なアプリケーション向けに設計されています。このため、関連結果をすぐに必要とする、対話的なナレッジベース検索、サポート文書検索、コード検索の実用的な候補になります。小型版ならコンテキストウィンドウも小さいと仮定せず、実際の資料群の品質と応答時間の要件に基づいて選んでください。
クエリで関連性を指示する クエリには、何を関連ありとするかを説明する自然言語の指示を添えられます。質問と関連性の希望は簡潔にし、整合させてください。ソフトウェアのサポート検索なら、「デバイスをリセットする手順を見つけてください。指定したハードウェアリビジョンの手順を優先してください」とします。あいまいな製品名では、無関係な意味が上位にならないよう製品カテゴリを含めます。クエリ内の希望は意味的な採点を導きます。候補一覧を作る前に、資料群の明示的なメタデータを使い、正しい製品、文書版、アクセス範囲を選択してください。
テキスト候補の絞り込み一覧を用意する 入力文書は文字列です。原資料から読めるテキストを抽出し、有用なタイトル、見出し、識別子、周辺の文脈を残してください。各入力位置と元の記録の対応を安定して保持します。トラブルシューティング記事では、切り離された一文だけでなく、症状と関連する手順を含めてください。ソースコード検索では、関数と、似た名前の関数と区別するために必要な周辺情報を含めます。繰り返しのナビゲーションや定型文が有用な文章の場所を圧迫する場合は、取り除いてください。
リランカーが並べ替えられるのは、受け取った文書だけです。最初の検索で関連する記事を取得できなければ、この段階で欠けた候補を復元することはできません。結果がおかしい場合は、候補一覧と最終順位の両方を確認してください。長い文書が多くの話題を扱う場合は、まとまりのある節に分け、親文書への参照を残し、出典を失わずに関連する節を選べるようにします。
コンテキストとリクエストの上限 開発元の現在のガイドは、クエリの最大値を 8,000 トークン、クエリと各文書の合計最大値を 32,000 トークンとしています。候補文書は最大 1,000 件、リクエスト全体の予算は 600,000 トークンで、クエリのトークン数に文書数を掛け、すべての文書のトークン数を加えて計算します。そのため、長いクエリは各組の容量を使い、合計予算に繰り返し加算されます。文字数、語数、トークン数を同じものとみなさず、適切なモデルのトークナイザーで送信テキストを数えてください。
たとえば、500 トークンのクエリと、それぞれ 4,000 トークンの文書 100 件では、その式による入力トークン数は 450,000 です。これは予算計算の例であり、候補一覧の推奨件数や速度の実測結果ではありません。文書化された切り詰めオプションは、デフォルトで有効です。長すぎるテキストは、採点前に短縮される場合があります。照合に必要な文章そのものが切り詰めで失われないよう、重要な節を意識して用意してください。
結果を読み、利用する 結果は、関連性スコアの高い順に並びます。各結果は文書の元の入力位置を示し、アプリケーションが独自のタイトル、記録識別子、出典を添えられます。top_k 設定は返す順位付き候補数を制御し、指定しなければ全候補を返します。開発元の REST インターフェースは、文書テキストも返せます。検索ページに表示したり、回答生成段階へ根拠を渡したりする際は、選んだ結果とともに元の識別子を保持してください。
関連性スコアは、候補がクエリにどれだけ合うかを表し、その候補の記述が正しいことを確定するものではありません。除外条件や文書版の違いも含め、上位項目を利用者の実際の質問と比較してください。すべての候補が無関係でも、最上位の項目は存在します。資料群の代表的なクエリを使い、アプリケーションがその場合をどう扱うかを決めてください。
アップグレードと版の選択 開発元は、rerank-3-lite を、API の意味を変えず、対応する前モデルの分布にスコアを校正した、rerank-2.5-lite のアップグレードと説明しています。既存の記録対応と検索段階を保ち、確立済みのスコア閾値に頼る前に、意味のあるクエリで結果の順序を比較してください。応答時間が重要な検索体験には Lite を使い、難しい候補に対する関連性をより重視する場合は、品質重視の rerank-3 版を比較対象にします。
POST /v1/reranktextrerank| フィールド | 種類 | 要件 | 値と制限 | デフォルト |
|---|---|---|---|---|
フィールドdocuments | 種類array | 要件必須 | 値と制限 | デフォルト— |
フィールドmodel | 種類string | 要件必須 | 値と制限 voyageai/rerank-3-lite | デフォルト— |
フィールドprovider | 種類schema | 要件任意 | 値と制限 | デフォルト— |
フィールドquery | 種類string | 要件必須 | 値と制限 | デフォルト— |
フィールドsession_id | 種類string | 要件任意 | 値と制限 | デフォルト— |
フィールドtop_n | 種類integer | 要件任意 | 値と制限 最小値: 1 | デフォルト— |
フィールドtrace | 種類schema | 要件任意 | 値と制限 | デフォルト— |
フィールドuser | 種類string | 要件任意 | 値と制限 | デフォルト— |
フィールドdocuments[].text | 種類string | 要件任意 | 値と制限 | デフォルト— |
フィールドdocuments[].image | 種類string | 要件任意 | 値と制限 | デフォルト— |
text_rerank · 必須: query, documents array with minItems1
| パラメータ | 仕様 |
|---|---|
パラメータcontent_type | 仕様application/json |
パラメータrequired | 仕様model, query, documents |
パラメータmaterial_types | 仕様text |
パラメータoptional_controls | 仕様provider, session_id, top_n, trace, user |
パラメータmultimodal_input_binding | 仕様null |
ライフサイクル: synchronous
正確なモデルIDを送信し、ネイティブのレスポンス全体を保持してください。
料金情報はリクエストの機能を追加しません。対応するパラメーターは選択したメソッドに記載されています。
各料金を表示された条件と照合してください。選択肢となる設定の各組には、いずれか1つの料金を適用します。
| 設定 | 料金表 | 課金単位 | 料金 |
|---|---|---|---|
| 設定基本トークン料金 | 料金表基本料金 | 課金単位— | 料金 入力 · 入力トークン — / 1K トークン 出力 · 出力トークン — / 1K トークン 入力 · キャッシュ読み取り — / 1K トークン 入力 · キャッシュ書き込み — / 1K トークン 入力 · キャッシュ書き込み、1時間 — / 1K トークン |
| 設定Ultra | 料金表— | 課金単位/ 1K トークン | 料金 入力 $0.00004 / 1K トークン |
Ailootはリクエスト前に見積額を確保します。結果の取得後、実測使用量に基づいて最終料金を精算します。ストリーミング時の精算には最終の使用量記録を使用します。金額の確保と精算の仕組み →
{\n "documents": [\n "Paris is the capital of France.",\n "Berlin is the capital of Germany."\n ],\n "model": "voyageai/rerank-3-lite",\n "query": "What is the capital of France?",\n "top_n": 3\n}set -eu\n: "${AILOOT_API_KEY:?Set your Ailoot API key}"\n: "${AILOOT_REQUEST_FILE:?Set your actual JSON request file}"\nexport AILOOT_REQUEST_FILE\npython3 - <<'PY_REQUEST'\nimport json,os\nfrom pathlib import Path\np=json.loads(Path(os.environ['AILOOT_REQUEST_FILE']).read_text(encoding='utf-8'))\nif not isinstance(p,dict): raise SystemExit('Request must be a JSON object')\np['model']='voyageai/rerank-3-lite'\nPath('request.json').write_text(json.dumps(p,ensure_ascii=False),encoding='utf-8')\nPY_REQUEST\ncurl --fail-with-body --silent --show-error https://api.ailoot.ai/v1/rerank \\\n -H "Authorization: Bearer $AILOOT_API_KEY" -H 'Content-Type: application/json' \\\n --data-binary @request.json -D response-headers.txt -o result.json\npython3 - <<'PY_RESULT'\nimport json\nfrom pathlib import Path\nprint(json.dumps(json.loads(Path('result.json').read_text()),ensure_ascii=False,indent=2))\nPY_RESULT\njson
返された完全なレスポンス、ファイル、コンテンツ部分をすべて保存してください。
実際の結果の各インデックス、有限値のrelevance_score、元の文書オブジェクトはすべて保持されます。インデックスは元の文書配列に対応します。元のJSON全体は保存され、精算後にのみ返されます。
元の操作と、完全または部分的な応答を保持してください。POSTを再実行しないでください。
| フィールド | 種類 |
|---|---|
フィールドmodel | 種類string |
フィールドid | 種類string |
フィールドprovider | 種類string |
フィールドresults[].index | 種類integer |
フィールドresults[].relevance_score | 種類number |
フィールドresults[].document.text | 種類string |
フィールドresults[].document.image | 種類string |
フィールドusage.search_units | 種類integer |
フィールドusage.total_tokens | 種類integer |
フィールドusage.cost | 種類number |
| レスポンス | 条件 | 次の手順 |
|---|---|---|
レスポンス400 · invalid_request_error | 条件必須フィールド、表現形式、または値が無効です | 次の手順指摘されたリクエストフィールドを修正してください。 |
Ailoot Ultra voyageai/rerank-3-lite
上記に表示されたメソッドパスを使用してください。