Amazon Bedrockが全Claudeで構造化出力に対応

構造化出力は、トークン生成の段階でJSONスキーマを強制する制約付きデコーディングを使う。スキーマに違反するトークンはモデルが出力しないため、出力形式が確率的なものから決定的なものに変わるという。提供される仕組みは二つで、応答構造を制御するJSON Schema出力形式と、ツール引数をスキーマで検証するstrict tool useである。どちらも両エンドポイントで使える。 応答は常に有効なJSONとなり、JSON.parse()のエラーは起きない。フィールドの型と必須項目も守られる。スキーマで定義したフィールドだけに応答が絞られるため、出力トークン数が減り、大量処理では推論コストの低下につながり得るとしている。バッチ推論に対応し、bedrock-runtimeではクロスリージョン推論も追加設定なしで使える。ストリーミングでは型付きイベントとして受け取れる。 処理の流れは、スキーマ検証、文法アーティファクトのコンパイル、キャッシュ、制約付き生成の順である。新しいスキーマの最初のリクエストはコンパイルのためやや遅くなる。コンパイル済みの文法はアカウント単位で24時間キャッシュされる。スキーマの構造を変えるとキャッシュは無効になるが、nameやdescriptionだけの変更なら維持される。 記事ではInvokeModel APIでoutput_config.formatにスキーマを渡し、顧客メールからリード情報を抽出する例を示している。bedrock-mantleでは`strict: true`を指定したツール定義の例があり、引数がinput_schemaに厳密に一致する。チケット分類の例ではenumでラベルを固定し、escalateの値で振り分けている。主な用途はデータ抽出、信頼性の高いエージェントのツール呼び出し、大規模な分類である。 利用上の条件として、すべてのオブジェクトに`additionalProperties: false`を指定する必要があり、指定がないとスキーマは受理されない。拒否応答とmax_tokens到達の場合は準拠しない応答になり得るため、stop reasonの確認が推奨されている。再帰スキーマ、外部$ref、minimumやmaxLengthなどの数値・文字列制約は、受理されても生成時には強制されないので、アプリケーション側での検証が必要である。

AWS Machine Learning Blogより

推移を表示するための継続的な観測データがまだ足りません。