スキーマは「データの見た目」マニュアルとして理解できます。 細かい部分には責任を負いませんが、構造、フィールド、型、階層、制約を定義します。 モデルを自由に再生させたいけれど、正直なところ特定のフォーマットで出力したいなら、スキーマが重要な役割を果たします。 だからJSON、構造化出力、関数呼び出し、ツール呼び出しについて話すときは必ず持ち出すのです。
具体的に何を制限しているのでしょうか?
| 制約 | スキーマは何を言っているのか? |
|---|---|
| フィールド | そこにどんな鍵があるはずなのか、名前は何だ |
| 種類 | 文字列、数字、ブール、配列、またはオブジェクトですか |
| レベル | どの畑が一緒に包まれ、誰が誰の子孫なのか |
| ルール | 必須のもの、空のもの、特定の値でしか取れないもの |
なぜJSONとツールコールの両方に現れるのでしょうか?
なぜなら、この2つのタイプのシナリオは「まとも」であることを望むのではなく、「プログラムを直接受け取れる」ことを望んでいるからです。 モデルが自然言語を出力した場合、人はそれを理解できるかもしれませんが、プログラムがそれを捉えられない場合もあります。 スキーマでは、モデルは単に回答を書くだけでなく、定義されたコンテナに値を埋め込むだけです。 ツールコールは特にこれに依存しており、パラメータ名、パラメータタイプ、必要な関係が誤っているとエラーを報告することがあります。
それがプロンプトとどう関係しているのですか?
プロンプトはモデルに「あなたは何をするつもりですか」と伝えます。 スキーマはモデルに「あなたが生成するデータがどのような形でなければならないか」を伝えるようなものです。 この二つはしばしば一緒に使われますが、動作は異なります。 プロンプトのみに頼るモデルは連絡先情報の出力を知っているかもしれませんが、name、phone、emailなどの固定キーを安定的に与えないこともあります。 スキーマを加えることで、出力はプログラムが期待するものにより近くなります。
よくある誤解
- 神話1:スキーマがあれば結果は信頼できる。 実際、フォーマットを抑制するのが得意であり、事実そのものが正確であることを保証する責任はありません。
- 誤解2:スキーマは開発者だけのもの。 実際、固定テーブル抽出、バッチ分類、自動化ワークフローを行っている限り、すでに影響を受けています。
- 誤解3:これは単にJSONの別の言い方に過ぎない。 より正確に言うと、JSONがキャリアであり、スキーマがルールです。
したがって、スキーマの本当の価値は出力を「きれいに見せる」ことではなく、モデルの結果がプログラムやテーブル、ツールチェーンに取り込まれやすくすることにあります。 それは、AIが情報を引き出す理由、ある人は文章を手に入れ、また別の人はデータベースに直接保存できるデータを手に入れるという一般的な現象を説明しています。
