Kev-4B は、与えられた状態に関する型付きの質問に答えるためのコンパクトな意思決定モデルです。状態とは評価対象の文書や記録であり、各質問はモデルがスコアリングできる選択肢を定義します。結果は確率分布と型付きの意思決定記録であり、文書分類、ルーティング、トリアージ、抽出対象の選択、明示された基準に照らしたチェックに役立ちます。
このモデルは、凍結した Qwen3.5-4B-Base バックボーンに LoRA アダプターとポインターヘッドを組み合わせています。バックボーンは 32 層で、24 層の Gated DeltaNet 層と 8 層のフルアテンション層で構成されます。アダプターはアテンション、MLP、DeltaNet の射影を対象とし、ポインターヘッドは与えた選択肢をスコアリングして、そのスコアを確率に変換します。これはプリフィルのみで完結する意思決定ワークフローであり、選択肢が回答空間を構成します。
同じリクエスト内に 3 種類の質問タイプを含めることができます。選択式の質問は、必要に応じて説明を付けた 1～255 個の名前付き選択肢を受け付け、最も可能性の高い選択肢、別個の信頼度の値、各選択肢の確率を返します。メーカーのフォーマットで noul と呼ばれるはい/いいえの質問は、「はい」の確率を返します。数値が高ければ常にアプリケーションにとって好ましい結果を意味すると決めつけず、「はい」の意味を質問の中で定義します。
順序付きスコアの質問は、1～255 個のレベルを受け付け、各レベルの確率とその期待インデックスを返します。レベルのインデックスはゼロから始まります。メーカーの結果フォーマットには、レベルの凡例と別個の信頼度の値も含まれます。期待インデックスは小数になることがあります。これは新しいテキストラベルを選ぶのではなく、順序付きレベル全体の分布を要約したものです。評価を一貫して解釈できるよう、レベルの順序と凡例を結果とともに保持します。
質問は同じ状態を共有しますが、それぞれ独立して評価されます。ある質問が別の質問の回答を読むことはできず、状態は 1 回だけ計算されて再利用されます。後の意思決定が前の意思決定の結果に依存する場合は、1 つのリクエスト内の質問が連鎖することを期待せず、その依存関係を次の状態の中で明示します。このため、状態を共有するワークフローは、同じ文書に対する複数の独立したチェックに適しています。
状態には、質問が実際に必要とする根拠を用意します。状態はプレーンテキストでも、ラベル付きテキストとしてレンダリングされた JSON オブジェクトや配列でもかまいません。フィールド名、単位、ポリシーの条件、関連する元の文章を明確に保ちます。質問ごとに具体的な指示を書き、記録から判別できる意味を選択肢に持たせます。サポート振り分けタスクの独自の例では、状態にリクエストとそのコンテキストを含め、選択肢では配送、アクセス、製品サポートのカテゴリを短い説明とともに定義できます。
2 つ目の質問で緊急度を評価し、順序付きの質問でそのリクエストにどの程度のフォローアップが必要かを評価できます。これらは異なる業務上の問いに答えるものなので、それぞれ別に定義します。選択タスクに必要であれば、レビュー用や根拠不足用の適切な選択肢を加え、複数のカテゴリがあり得る場合は分布の全体を保持します。結果をどう振り分け、どうレビューするかはアプリケーションが決め、モデルはスコアリング済みの記録を提供します。
Kev-4B は、数千トークン規模の文書に対する型付きの意思決定を想定しています。メーカーのサービング設定では最大 65,536 トークンの状態を受け付け、質問ごとに追加の領域を確保しますが、このチェックポイントで検証済みのコンテキスト長は 8192 トークンです。これらは異なる境界です。より長い状態を受け付けることは、あらゆる長さで同等に信頼できる意思決定を保証するものではありません。長い記録を分類用に準備する際は、決め手となる文章を簡潔に保ち、そのラベルを維持します。
リリースされたプロファイルは英語向けです。有用なタスクは、自由形式のチャット、要約、幅広い知識に基づく回答ではなく、与えられた状態内の根拠と定義された選択肢に依存します。日単位の日付計算は特有の制約であり、メーカーは計算済みの期間を提供する日付事実用の前処理ツールを別途用意しています。期限のチェックでは、関連する日付と計算済みの日数を、それらを使うルールとともに状態に含めます。
このチェックポイントには調整済みの確率キャリブレーションが付属していますが、信頼度は文書の分野や質問の設計によって変わり得ます。メーカーはまた、公開チェックポイントをタスク固有のラベルでファインチューニングし、確率キャリブレーションをそのワークロードに合わせて調整する方法も文書化しています。これは、与えた状態をスコアリングすることとは別のカスタマイズのワークフローです。意思決定のしきい値は実際のワークロードのラベル付き例を使って選び、不確かなケースはレビューできるよう見える状態にしておきます。メーカーは、人によるレビューを伴わない、人に関する重大な意思決定の完全自動化を対象外としています。選択肢の順序も回答に影響し得るため、結果を比較する際は順序を一定に保ちます。選ばれたラベル、別個の信頼度フィールド、確率分布は、ワークフローでそれぞれが果たす役割に応じて評価します。
メーカーが説明している現行の Kev-4B リリースは Kev 1.0 に属し、Qwen3.5 ベースを使用しています。以前の Qwen3 ベースのリリースや、文書段階のみのリリースは、別個のバージョンとして区別されます。タスク固有のワークフローを開発する際は、異なるプロファイルの結果を混在させず、選んだエディションと質問の定義を出力と結び付けて保持します。
有用な最終成果物は、元の質問、選択肢の定義、分布、順序付きレベルの凡例（ある場合）を備えた、名前付きの意思決定記録の集合です。回答品質のチェックでは、状態に提案された回答、根拠、検証する基準を含めます。ポリシーのトリアージでは、適用されるルールと関連する事実を含めます。その入力を結果と並べて保持しておけば、レビューの際に意思決定が妥当だった理由や、補うべき不足した事実を明らかにできます。
", "aboutText": "Kev-4B は、与えられた状態に関する型付きの質問に答えるためのコンパクトな意思決定モデルです。状態とは評価対象の文書や記録であり、各質問はモデルがスコアリングできる選択肢を定義します。結果は確率分布と型付きの意思決定記録であり、文書分類、ルーティング、トリアージ、抽出対象の選択、明示された基準に照らしたチェックに役立ちます。\n\nこのモデルは、凍結した Qwen3.5-4B-Base バックボーンに LoRA アダプターとポインターヘッドを組み合わせています。バックボーンは 32 層で、24 層の Gated DeltaNet 層と 8 層のフルアテンション層で構成されます。アダプターはアテンション、MLP、DeltaNet の射影を対象とし、ポインターヘッドは与えた選択肢をスコアリングして、そのスコアを確率に変換します。これはプリフィルのみで完結する意思決定ワークフローであり、選択肢が回答空間を構成します。\n\n同じリクエスト内に 3 種類の質問タイプを含めることができます。選択式の質問は、必要に応じて説明を付けた 1～255 個の名前付き選択肢を受け付け、最も可能性の高い選択肢、別個の信頼度の値、各選択肢の確率を返します。メーカーのフォーマットで noul と呼ばれるはい/いいえの質問は、「はい」の確率を返します。数値が高ければ常にアプリケーションにとって好ましい結果を意味すると決めつけず、「はい」の意味を質問の中で定義します。\n\n順序付きスコアの質問は、1～255 個のレベルを受け付け、各レベルの確率とその期待インデックスを返します。レベルのインデックスはゼロから始まります。メーカーの結果フォーマットには、レベルの凡例と別個の信頼度の値も含まれます。期待インデックスは小数になることがあります。これは新しいテキストラベルを選ぶのではなく、順序付きレベル全体の分布を要約したものです。評価を一貫して解釈できるよう、レベルの順序と凡例を結果とともに保持します。\n\n質問は同じ状態を共有しますが、それぞれ独立して評価されます。ある質問が別の質問の回答を読むことはできず、状態は 1 回だけ計算されて再利用されます。後の意思決定が前の意思決定の結果に依存する場合は、1 つのリクエスト内の質問が連鎖することを期待せず、その依存関係を次の状態の中で明示します。このため、状態を共有するワークフローは、同じ文書に対する複数の独立したチェックに適しています。\n\n状態には、質問が実際に必要とする根拠を用意します。状態はプレーンテキストでも、ラベル付きテキストとしてレンダリングされた JSON オブジェクトや配列でもかまいません。フィールド名、単位、ポリシーの条件、関連する元の文章を明確に保ちます。質問ごとに具体的な指示を書き、記録から判別できる意味を選択肢に持たせます。サポート振り分けタスクの独自の例では、状態にリクエストとそのコンテキストを含め、選択肢では配送、アクセス、製品サポートのカテゴリを短い説明とともに定義できます。\n\n2 つ目の質問で緊急度を評価し、順序付きの質問でそのリクエストにどの程度のフォローアップが必要かを評価できます。これらは異なる業務上の問いに答えるものなので、それぞれ別に定義します。選択タスクに必要であれば、レビュー用や根拠不足用の適切な選択肢を加え、複数のカテゴリがあり得る場合は分布の全体を保持します。結果をどう振り分け、どうレビューするかはアプリケーションが決め、モデルはスコアリング済みの記録を提供します。\n\nKev-4B は、数千トークン規模の文書に対する型付きの意思決定を想定しています。メーカーのサービング設定では最大 65,536 トークンの状態を受け付け、質問ごとに追加の領域を確保しますが、このチェックポイントで検証済みのコンテキスト長は 8192 トークンです。これらは異なる境界です。より長い状態を受け付けることは、あらゆる長さで同等に信頼できる意思決定を保証するものではありません。長い記録を分類用に準備する際は、決め手となる文章を簡潔に保ち、そのラベルを維持します。\n\nリリースされたプロファイルは英語向けです。有用なタスクは、自由形式のチャット、要約、幅広い知識に基づく回答ではなく、与えられた状態内の根拠と定義された選択肢に依存します。日単位の日付計算は特有の制約であり、メーカーは計算済みの期間を提供する日付事実用の前処理ツールを別途用意しています。期限のチェックでは、関連する日付と計算済みの日数を、それらを使うルールとともに状態に含めます。\n\nこのチェックポイントには調整済みの確率キャリブレーションが付属していますが、信頼度は文書の分野や質問の設計によって変わり得ます。メーカーはまた、公開チェックポイントをタスク固有のラベルでファインチューニングし、確率キャリブレーションをそのワークロードに合わせて調整する方法も文書化しています。これは、与えた状態をスコアリングすることとは別のカスタマイズのワークフローです。意思決定のしきい値は実際のワークロードのラベル付き例を使って選び、不確かなケースはレビューできるよう見える状態にしておきます。メーカーは、人によるレビューを伴わない、人に関する重大な意思決定の完全自動化を対象外としています。選択肢の順序も回答に影響し得るため、結果を比較する際は順序を一定に保ちます。選ばれたラベル、別個の信頼度フィールド、確率分布は、ワークフローでそれぞれが果たす役割に応じて評価します。\n\nメーカーが説明している現行の Kev-4B リリースは Kev 1.0 に属し、Qwen3.5 ベースを使用しています。以前の Qwen3 ベースのリリースや、文書段階のみのリリースは、別個のバージョンとして区別されます。タスク固有のワークフローを開発する際は、異なるプロファイルの結果を混在させず、選んだエディションと質問の定義を出力と結び付けて保持します。\n\n有用な最終成果物は、元の質問、選択肢の定義、分布、順序付きレベルの凡例（ある場合）を備えた、名前付きの意思決定記録の集合です。回答品質のチェックでは、状態に提案された回答、根拠、検証する基準を含めます。ポリシーのトリアージでは、適用されるルールと関連する事実を含めます。その入力を結果と並べて保持しておけば、レビューの際に意思決定が妥当だった理由や、補うべき不足した事実を明らかにできます。", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "53e8a897b1d6a7b7ef189ae720670848765c01f47b2ce062715cd25e47d80d08", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "ja", "methods": [ { "html": "jaredpalmer/kev-4bKev-4B は、与えられた英語の文書に関する型付きの質問をスコアリングし、定義した選択肢に対するキャリブレーション済みの確率を返します。はい/いいえ、選択式、順序付きスコアの質問を使って、生成された文章ではなく構造化された意思決定が必要な分類、ルーティング、トリアージ、チェックを行えます。
この説明はモデルの機能を紹介するものです。Ailootで利用できる入力、出力、オプションは、選択したメソッドごとに以下に記載されています。
Kev-4B は、与えられた状態に関する型付きの質問に答えるためのコンパクトな意思決定モデルです。状態とは評価対象の文書や記録であり、各質問はモデルがスコアリングできる選択肢を定義します。結果は確率分布と型付きの意思決定記録であり、文書分類、ルーティング、トリアージ、抽出対象の選択、明示された基準に照らしたチェックに役立ちます。
このモデルは、凍結した Qwen3.5-4B-Base バックボーンに LoRA アダプターとポインターヘッドを組み合わせています。バックボーンは 32 層で、24 層の Gated DeltaNet 層と 8 層のフルアテンション層で構成されます。アダプターはアテンション、MLP、DeltaNet の射影を対象とし、ポインターヘッドは与えた選択肢をスコアリングして、そのスコアを確率に変換します。これはプリフィルのみで完結する意思決定ワークフローであり、選択肢が回答空間を構成します。
同じリクエスト内に 3 種類の質問タイプを含めることができます。選択式の質問は、必要に応じて説明を付けた 1～255 個の名前付き選択肢を受け付け、最も可能性の高い選択肢、別個の信頼度の値、各選択肢の確率を返します。メーカーのフォーマットで noul と呼ばれるはい/いいえの質問は、「はい」の確率を返します。数値が高ければ常にアプリケーションにとって好ましい結果を意味すると決めつけず、「はい」の意味を質問の中で定義します。
順序付きスコアの質問は、1～255 個のレベルを受け付け、各レベルの確率とその期待インデックスを返します。レベルのインデックスはゼロから始まります。メーカーの結果フォーマットには、レベルの凡例と別個の信頼度の値も含まれます。期待インデックスは小数になることがあります。これは新しいテキストラベルを選ぶのではなく、順序付きレベル全体の分布を要約したものです。評価を一貫して解釈できるよう、レベルの順序と凡例を結果とともに保持します。
質問は同じ状態を共有しますが、それぞれ独立して評価されます。ある質問が別の質問の回答を読むことはできず、状態は 1 回だけ計算されて再利用されます。後の意思決定が前の意思決定の結果に依存する場合は、1 つのリクエスト内の質問が連鎖することを期待せず、その依存関係を次の状態の中で明示します。このため、状態を共有するワークフローは、同じ文書に対する複数の独立したチェックに適しています。
状態には、質問が実際に必要とする根拠を用意します。状態はプレーンテキストでも、ラベル付きテキストとしてレンダリングされた JSON オブジェクトや配列でもかまいません。フィールド名、単位、ポリシーの条件、関連する元の文章を明確に保ちます。質問ごとに具体的な指示を書き、記録から判別できる意味を選択肢に持たせます。サポート振り分けタスクの独自の例では、状態にリクエストとそのコンテキストを含め、選択肢では配送、アクセス、製品サポートのカテゴリを短い説明とともに定義できます。
2 つ目の質問で緊急度を評価し、順序付きの質問でそのリクエストにどの程度のフォローアップが必要かを評価できます。これらは異なる業務上の問いに答えるものなので、それぞれ別に定義します。選択タスクに必要であれば、レビュー用や根拠不足用の適切な選択肢を加え、複数のカテゴリがあり得る場合は分布の全体を保持します。結果をどう振り分け、どうレビューするかはアプリケーションが決め、モデルはスコアリング済みの記録を提供します。
Kev-4B は、数千トークン規模の文書に対する型付きの意思決定を想定しています。メーカーのサービング設定では最大 65,536 トークンの状態を受け付け、質問ごとに追加の領域を確保しますが、このチェックポイントで検証済みのコンテキスト長は 8192 トークンです。これらは異なる境界です。より長い状態を受け付けることは、あらゆる長さで同等に信頼できる意思決定を保証するものではありません。長い記録を分類用に準備する際は、決め手となる文章を簡潔に保ち、そのラベルを維持します。
リリースされたプロファイルは英語向けです。有用なタスクは、自由形式のチャット、要約、幅広い知識に基づく回答ではなく、与えられた状態内の根拠と定義された選択肢に依存します。日単位の日付計算は特有の制約であり、メーカーは計算済みの期間を提供する日付事実用の前処理ツールを別途用意しています。期限のチェックでは、関連する日付と計算済みの日数を、それらを使うルールとともに状態に含めます。
このチェックポイントには調整済みの確率キャリブレーションが付属していますが、信頼度は文書の分野や質問の設計によって変わり得ます。メーカーはまた、公開チェックポイントをタスク固有のラベルでファインチューニングし、確率キャリブレーションをそのワークロードに合わせて調整する方法も文書化しています。これは、与えた状態をスコアリングすることとは別のカスタマイズのワークフローです。意思決定のしきい値は実際のワークロードのラベル付き例を使って選び、不確かなケースはレビューできるよう見える状態にしておきます。メーカーは、人によるレビューを伴わない、人に関する重大な意思決定の完全自動化を対象外としています。選択肢の順序も回答に影響し得るため、結果を比較する際は順序を一定に保ちます。選ばれたラベル、別個の信頼度フィールド、確率分布は、ワークフローでそれぞれが果たす役割に応じて評価します。
メーカーが説明している現行の Kev-4B リリースは Kev 1.0 に属し、Qwen3.5 ベースを使用しています。以前の Qwen3 ベースのリリースや、文書段階のみのリリースは、別個のバージョンとして区別されます。タスク固有のワークフローを開発する際は、異なるプロファイルの結果を混在させず、選んだエディションと質問の定義を出力と結び付けて保持します。
有用な最終成果物は、元の質問、選択肢の定義、分布、順序付きレベルの凡例（ある場合）を備えた、名前付きの意思決定記録の集合です。回答品質のチェックでは、状態に提案された回答、根拠、検証する基準を含めます。ポリシーのトリアージでは、適用されるルールと関連する事実を含めます。その入力を結果と並べて保持しておけば、レビューの際に意思決定が妥当だった理由や、補うべき不足した事実を明らかにできます。
POST /v1/systemonetextdecisions| フィールド | 種類 | 要件 | 値と制限 | デフォルト |
|---|---|---|---|---|
フィールドmodel | 種類string | 要件必須 | 値と制限 jaredpalmer/kev-4b | デフォルト— |
フィールドprovider | 種類schema | 要件任意 | 値と制限 | デフォルト— |
フィールドquestions | 種類object | 要件必須 | 値と制限 | デフォルト— |
フィールドsession_id | 種類string | 要件任意 | 値と制限 | デフォルト— |
フィールドstate | 種類schema | 要件必須 | 値と制限 | デフォルト— |
フィールドtrace | 種類schema | 要件任意 | 値と制限 | デフォルト— |
フィールドuser | 種類string | 要件任意 | 値と制限 | デフォルト— |
フィールドquestions.<id>.type | 種類string | 要件必須 | 値と制限 noul, choice, score | デフォルト— |
フィールドquestions.<id>.instructions | 種類string|object|array | 要件必須 | 値と制限 | デフォルト— |
フィールドquestions.<id>.criteria | 種類object|array | 要件任意 | 値と制限 条件: choice/score：必須；noul：任意。choiceのcriteriaはオブジェクト、scoreはminItems1の配列です。 | デフォルト— |
フィールドquestions.<id>.criteria.true | 種類string|object|array | 要件必須 | 値と制限 適用条件: noul の条件オブジェクトが指定されている | デフォルト— |
フィールドquestions.<id>.criteria.false | 種類string|object|array | 要件必須 | 値と制限 適用条件: noul の条件オブジェクトが指定されている | デフォルト— |
noul · 必須: state, questions.<id>.type=noul, questions.<id>.instructions
choice · 必須: state, questions.<id>.type=choice, questions.<id>.instructions, criteria object
score · 必須: state, questions.<id>.type=score, questions.<id>.instructions, criteria array with minItems1
| パラメータ | 仕様 |
|---|---|
パラメータcontent_type | 仕様application/json |
パラメータrequired | 仕様model, state, questions |
パラメータmaterial_types | 仕様text |
パラメータoptional_controls | 仕様provider, session_id, trace, user |
パラメータmultimodal_input_binding | 仕様null |
ライフサイクル: synchronous
正確なモデルIDを送信し、ネイティブのレスポンス全体を保持してください。
料金情報はリクエストの機能を追加しません。対応するパラメーターは選択したメソッドに記載されています。
各料金を表示された条件と照合してください。選択肢となる設定の各組には、いずれか1つの料金を適用します。
| 設定 | 料金表 | コンテキストトークン数が次の値を超える場合 | コンテキストトークン数が次の値以下の場合 | 料金 |
|---|---|---|---|---|
| 設定トークンの基本単価 | 料金表基本料金 | コンテキストトークン数が次の値を超える場合— | コンテキストトークン数が次の値以下の場合上限なし | 料金 入力 · 入力トークン $0.000084 / 1K トークン 出力 · 出力トークン $0 / 1K トークン 入力 · キャッシュ読み取り — / 1K トークン 入力 · キャッシュ書き込み — / 1K トークン 入力 · キャッシュ書き込み、1時間 — / 1K トークン |
| 設定リクエスト長に応じた料金区分 1 | 料金表— | コンテキストトークン数が次の値を超える場合0 | コンテキストトークン数が次の値以下の場合上限なし | 料金 入力 · 入力トークン $0.000084 / 1K トークン 出力 · 出力トークン $0 / 1K トークン 入力 · キャッシュ読み取り — / 1K トークン 入力 · キャッシュ書き込み — / 1K トークン 入力 · キャッシュ書き込み、1時間 — / 1K トークン |
Ailootはリクエスト前に見積額を確保します。結果の取得後、実測使用量に基づいて最終料金を精算します。ストリーミング時の精算には最終の使用量記録を使用します。金額の確保と精算の仕組み →
{\n "model": "jaredpalmer/kev-4b",\n "questions": {\n "is_bug": {\n "criteria": {\n "false": "The customer is asking a question or requesting a feature.",\n "true": "The customer describes broken or unexpected product behavior."\n },\n "instructions": "Is the customer reporting a software defect?",\n "type": "noul"\n },\n "team": {\n "criteria": {\n "account": "Login, permissions, or profile issues.",\n "frontend": "Rendering, layout, or browser compatibility issues.",\n "payments": "Checkout, billing, or payment processing issues."\n },\n "instructions": "Which team should own this ticket?",\n "type": "choice"\n },\n "urgency": {\n "criteria": [\n "Can wait for the next release",\n "Should be fixed this week",\n "Blocking revenue right now"\n ],\n "instructions": "How urgent is this ticket?",\n "type": "score"\n }\n },\n "state": {\n "customer_tier": "enterprise",\n "ticket": "My checkout page shows a blank screen after I click Pay. I have tried two browsers."\n }\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']='jaredpalmer/kev-4b'\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/systemone \\\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
返された完全なレスポンス、ファイル、コンテンツ部分をすべて保存してください。
指定された各質問IDに対する回答は、正確な型、noul/choice/scoreの値、信頼度、確率、凡例とともにすべて保持されます。元のJSON全体は保存され、精算後にのみ返されます。
元の操作と、完全または部分的な応答を保持してください。POSTを再実行しないでください。
| フィールド | 種類 |
|---|---|
フィールドmodel | 種類string |
フィールドid | 種類string |
フィールドprovider | 種類string |
フィールドanswers.<id>.type | 種類string |
フィールドanswers.<id>.noul | 種類number |
フィールドanswers.<id>.choice | 種類string |
フィールドanswers.<id>.score | 種類number |
フィールドanswers.<id>.confidence | 種類number |
フィールドanswers.<id>.probabilities | 種類object |
フィールドanswers.<id>.legend | 種類object |
フィールドusage.input_tokens | 種類integer |
フィールドusage.output_tokens | 種類integer |
フィールドusage.cost | 種類number |
| レスポンス | 条件 | 次の手順 |
|---|---|---|
レスポンス400 · invalid_request_error | 条件必須フィールド、表現形式、または値が無効です | 次の手順指摘されたリクエストフィールドを修正してください。 |
Ailoot Ultra jaredpalmer/kev-4b
上記に表示されたメソッドパスを使用してください。