さて､ 第2週4日目もお付き合いいただきありがとうございました｡
今日はいいことがたくさんある｡
重要なビジネス価値を生み出すためにLlmsを活用する能力を高める､ 新たなスキルを身につけるためのレベルアップの日だ｡
いつものように､ トランスフォーマーについてすでに説明できることと､ それに関係する用語を簡単にまとめてみた｡
よくご存知でしょう｡
上位3つのフロンティアモデルのAPIを使って自信を持ってコーディングし､ 最近ではチャットボットアシスタント､
対話型UIを含むAIチャットボットを構築している｡
そして､ OpenAIに入るメッセージの構造や､ Gradioのチャット機能の仕組みは､
もうよくご存知でしょう｡
というわけで､ 今日は道具というものについて｡
最後には､ それらを定義し､ そのための一般的な使用事例を持ち､ ツールを使用するAIアシスタントをコーディングできるようになるでしょう｡
さっそく始めよう｡
では､ 道具とは何か？
そのため､ フロンティア・モデルは､ フロンティア・モデルの外部にある機能を持つ外部関数と接続することができる｡
実際､ 道具とはもっと広い意味を持つこともある｡
他のことでもあり得る｡
しかし､ 一般的にツールについて語られるとき､ それはフロンティア・モデルに外部機能へのアクセスを与えるという文脈で語られることが多い｡
LLMの知識を拡張することで､ LLMからのリッチな返信を可能にし､ アプリケーション内で高度なアクションを実行させ､
例えば電卓を持たせることでその能力を高めることができます｡
だから､ 前回の最後に言ったように､ これはとてもミステリアスに聞こえるかもしれない｡
いったい何がどうなっているのか？
電卓のようなもの､ 計算ができる関数のようなものを作ろうと思っているんだ｡
そして､ それをLLMに渡して､ オーケー､ これを使っていいよ､ と言うんだ｡
このソフトを私のコンピューターで何らかの方法で動かすことができる｡
ミステリアスな響きだ｡
ちょっと不気味な感じだね｡
でも､ 残念ながら､ そうではないんだ｡
それほど賢くはない｡
このあたりのワークフローはいたってシンプルだ｡
これがスクープだ｡
まずは､ LM が呼び出すことのできる関数を定義することから始めます｡
そこで､ これらの関数を定義する｡
電卓があるとしよう｡
私たちは計算機を定義する｡
何がインプットで､ どのようなアウトプットがあり､ LMはいつそれを使うべきなのか｡
そして､ そのことをLMに伝える｡
私たちが何かをするために呼びかけるとき､ 私たちはそれに向かってこう言う｡
ところで､ あなたはこのツールにアクセスできる｡
LMから返信があった場合､ ただプロンプトを表示するか､ あるいは､ もし私があなたに返信を返すのであれば､
まず､ あなたが教えてくれたツールを実行し､ これらのインプットを使って実行し､
私にアウトプットを返すようにお願いする必要があります｡
そして､ そのツールを実行し､ LMにレスポンスを返す｡
というわけで､ 私の流れに従えば､ 実は特別すごいわけではないのだ｡
LMに電話をかけると､ LMが応答して､ あなたが持っていると言ったツールに電話をかけてほしい､
と言うんだ｡
そうすれば､ LMにそれをフィードバックし､ LMはよりリッチなレスポンスを返してくれるようになる｡
そして､ もしあなたが本当についてきてくれているのなら､ 前回のラボでやったような､
ただ文字列を探してLMに行くプロンプトに余計なコンテキストを挿入するようなことと大差ないことに気づくだろう｡
分かった｡
とにかく､ 私があなたを混乱させなければいいのだが｡
その前に､ どのような使用例があるのか｡
普通はいつやるんだ？
よく目にするのは4つ｡
例えば､ データベースで何かを調べたり､ 知識を追加したり｡
前回のラボでベルトを使ったのと似たようなものだが､
代わりに道具を使うことができる｡
ミーティングの予約など､ LMが行動を起こすための手段として使うことができる｡
あなたには､ 実際に､ えー､ これらを実行する能力がある｡
そして､ 基本的には､ その返答の中で､ 今言ったように､
ユースケースは電卓である｡
LMSは計算が苦手なことで有名だが､ それは英語のトークンを予測しようとしているからだ｡
ディープ・ニューラル・ネットワークに電卓が組み込まれているわけではないのだ｡
でも､ それをツールとして提供することはできる｡
そして､ GPTの4番は最近､ 計算がとても上手くなっていることにお気づきだろう｡
そして､ 舞台裏で進行していることは､ このようなことなのではないか､ 計算を実行するために独自のツールを用意しているのではないか､
と考えてしまう｡
憶測にすぎないかもしれないが､ 非常に合理的だと思う｡
もうひとつできることは､ UIを変更することだ｡
ユーザー・インターフェースのさまざまな情報を更新する関数を呼び出すことができる｡
これは､ LLMとUIをより緊密に統合させるためのかなりクールなアイデアだ｡
繰り返しになるが､ 2つ目と4つ目のアクションとUIの変更については､
別の方法がある｡
それだけなら､ もっとシンプルな方法かもしれない｡
前にやったことを踏まえて､ 私が何を言いたいのか､ ちょっと立ち止まって考えてみてください｡
答えは､ ええと､ 以前のラボの1つで､ 構造化されたレスポンスで応答するためにモデルにJSONで応答させ､ そのレスポンスにはJSONがあり､
私たちに情報の断片を伝えていたのを覚えていますか？
私たちの場合､ それはリンクとあーに関するもので､ 完全修飾リンクとどのリンクを収集するかについての詳細な情報を与えてくれた｡
同じように､ ミーティングを予約するために必要なアクションをJSONで応答するようにモデルに要求したり､ ユーザーインターフェイスをどのように変更したいかに基づいてJSONで応答したりすることができます｡
だから､ 道具を使う以外の方法もある｡
しかし､ テキストをストリーミングで送り返すだけでなく､ ツールも与えたいのであれば､ これは良い解決策だ｡
それこそ､ LMが行っている他の様々なことと連動しているときこそ､ これを使うベストなタイミングなのだ｡
だから､ これらのツールはその能力をさらに高めているんだ｡
そこで､ 私たちがこれからやろうとしているのは､ 情報に精通した航空会社のカスタマーサポートを作ることだ｡
パリに旅行することを伝えて､ パリまでのチケット代を返信してもらえるようにしたい｡
そういうことだ｡
道具を使ってやるんだ｡ その方法を見つけるためにラボで会おう｡