あなたがこのコースで頑張り､ 大きく前進しているのは素晴らしいことだ｡
8週目の今日のトピックについて､ 本当に重要な専門知識を構築する最後の数日間に入った｡
日目は､ 引き続き強化し､ スキルアップを図り､ もうひとつスキルを身につける｡
だから今日は新しいものを見てみよう｡
構造化出力というのは､ 実はかなり最近の革新的なもので､ フロンティアモデルに特定の仕様に従って反応させたいことを伝えることができる方法だ｡
だから､ 今日はそうするつもりだ｡
また､ フロンティア・モデルを使ったワークエクスペリエンスをさらに行い､
過去に行ったようなインターネット上でのスクラップを行い､
フロンティア・モデルを使ってデータを統合する｡
私たちが昔､ サマライザーAを書いたのを覚えているだろう｡
インターネットのリーダーズ・ダイジェストが私たちの週だった｡
ある日､ 即座に満足した｡
まあ､ 我々はそれをさらに2段階ほど進めている｡
ええと､ それが今日のプランなんだ｡
そしてその多くは､ やはり修正と構築､ そして実験になるだろう｡
そこで､ 構造化されたアウトプットについて少し言わせてほしい｡
つまり､ 構造化されたアウトプットだ｡
過去にJSON生成を使っていたのを覚えているだろうか｡
モデルにJSONの出力フォーマットで応答させたいと言いました｡
そして､ プロンプトの中で､ そのJSONがどのように見えるべきかを正確に記述する｡
それに100％信頼できるものでもない｡
実際､ とてもいいんだ｡
JSONで応答することが多いんだ｡
しかし､ それがおかしくなり始めるのは､
本当に複雑なオブジェクトに反応させる必要がある場合だ｡
つまり､ 構造化出力のアイデアは､ モデルがどのように反応すべきかを正確に指定することをより指示的にすることだった｡
Pythonのクラスを使ってレスポンスを定義するのですが､ 実はこのクラスはPydanticのbase
modelというもののサブクラスになります｡
そうでなければ､ お見せしましょう｡
ベースモデルのサブクラスを作り､ そのサブクラスを使って､ 探しているものを正確に記述するんだ｡
そして､ OpenAIを呼び出すときにそのクラスを指定すると､ OpenAIはそのクラスのインスタンスを作成してあなたに送り返します｡
つまり､ 必要な構造のデータを正確に生成するのに便利なんだ｡
これは､ 別のアプローチと比較する必要がある｡
この2つは､ モデルからの反応に特定の､ ええと､ ええと､ 構造のタイプが戻ってくるようにするための､
よく似たテクニックなんだ｡
そして､ そのどちらにも長所と短所がある｡
一般的に言えば､ モデルをアプリケーションコードに直接接続し､ 特定のメソッドシグネチャを持つ必要がある関数を呼び出すのであれば､
関数呼び出しとツールを使うことをお勧めします｡
なぜなら､ 関数を呼び出すための適切なパラメータを定義したJSON構造に従って､
絶対に応答してくれるからだ｡
もし､ 下流で使用するために特定のフォーマットでデータを生成しようとするのであれば､
構造化されたアウトプットが適している｡
長所と短所を挙げればきりがないし､ しばらく試してみて､
どちらが優れているかがわかるようになるものだ｡
それではJupyterLabに向かいましょう｡
自分たちで試してみるつもりだ｡