WEBVTT 00:01.070 --> 00:04.640 JupyterLabは僕のお気に入りの場所だ。 00:04.640 --> 00:07.790 そして今、 我々はもちろん5週目のフォルダにいる。 00:07.790 --> 00:14.000 日目のJupyterノートブックは、 00:14.000 --> 00:22.610 今日のホームグラウンドになる。 00:22.700 --> 00:29.870 ではまず、 ショアハムにある私たちの会社、 保険技術会社についてお話ししましょう。 00:29.990 --> 00:41.690 我々は彼らの会社の共有フォルダにアクセスすることができ、 それはナレッジ・ベースと呼ばれています。 00:41.690 --> 00:48.260 それを開いてみると、 4つの異なるUM部門、 あるいは会社の4つの異なる分野を代表する4つのフォルダー会社の契約書、 00:48.260 --> 00:53.660 従業員、 製品が含まれていることがわかる。 00:54.020 --> 01:00.050 ええと、 ひとつだけ言っておくと、 おそらくお察しの通り、 ここにはかなりの量の企業データが掲載されているが、 01:00.050 --> 01:03.450 これらはすべて完全に架空のものである。 01:03.660 --> 01:07.440 これはもちろん、 LLMによって作られたものだ。 01:07.470 --> 01:14.940 私は数週間前の練習で、 データジェネレーターを作成し、 それを使っていくつかのデータを作成し、 01:14.940 --> 01:19.020 いくつかの文書間の関係などを保持した。 01:19.050 --> 01:28.530 私自身、 あちこちに手を加えたが、 そのほとんどすべてがGPT4かクロードによって生み出されたものだ。 01:29.370 --> 01:34.470 そこで、 この会社についてちょっと覗いてみよう。 01:34.470 --> 01:39.180 マークダウン形式の文書であれば、 かなり短い文書だと思う。 01:39.180 --> 01:46.440 だから、 もしこのような形でオープンすることができれば、 保険会社エルムについての素敵な、 うーん、 記事を見ることができる。 01:46.440 --> 01:50.880 2015年にエイブリー・ランカスターによって設立されたようだ。 01:50.880 --> 01:52.230 エイブリーの名前を覚えておいてほしい。 01:52.260 --> 01:53.910 彼女とは何度か会うことになるだろう。 01:54.240 --> 01:57.030 もちろん、 原本を見たいのであればね。 01:57.030 --> 02:00.210 私たちがよく知っているマークダウンに似ている。 02:00.210 --> 02:03.850 では、 契約のナレッジ・ベースに戻るとしよう。 02:03.850 --> 02:10.540 契約に関するより本質的な情報を入手した。 契約条件の更新や、 02:10.570 --> 02:15.130 その契約に含まれる機能などだ。 02:15.130 --> 02:16.960 だから、 それを覚えておいてほしい。 02:17.260 --> 02:19.150 他にもいろいろあるんだ。 02:19.510 --> 02:26.770 もう一度ナレッジ・ベースに戻って従業員を見てみると、 これはさまざまな従業員の人事記録だ。 02:26.770 --> 02:32.440 そして、 CEOのエイブリー・ランカスター自身にも、 ここにあるような人事記録がある。 02:32.770 --> 02:41.050 そして、 エルム保険会社から提供されるさまざまな商品(自動車保険のエルム、 02:41.050 --> 02:50.530 住宅保険のエルムなど)が紹介されている。 02:50.530 --> 02:55.600 これらの文書に目を通すことはできるが、 そのリアルさが素晴らしい。 02:55.630 --> 02:59.800 もちろん、 すべてフロンティア・モデルズの提供だ。 02:59.920 --> 03:03.480 ロードマップまである素晴らしい製品概要だ。 03:03.480 --> 03:04.500 大好きだ。 03:04.980 --> 03:06.360 ああ、 わかった。 03:06.390 --> 03:08.940 初日に戻る。 03:08.940 --> 03:10.800 それでどうするんだ? 03:10.830 --> 03:20.700 これから、 この会社についての質問を書くのだが、 人為的に調べて文脈をプロンプトに挿入する。 03:20.700 --> 03:22.110 だから輸入もする。 03:22.110 --> 03:25.470 今回はGPTフォーミニを使う。 03:25.530 --> 03:31.170 ええと、 それで......ジュースの話なんだけど。 03:31.170 --> 03:40.560 つまり、 これはPythonの関数で、 このフォルダーの中身をすべて取り出し、 03:40.560 --> 03:43.350 リストにまとめる。 03:43.350 --> 03:44.100 従業員 03:44.100 --> 03:51.600 つまり、 employeesはナレッジ・ベース内のファイル名のリストとなり、 スラッシュemployeesとなる。 03:51.600 --> 03:59.400 そのひとつひとつに、 ただハックしただけの奇妙なコードがあって、 基本的にファイル名(実際には従業員のフロイドの名前)を取り、 03:59.640 --> 04:06.490 その姓を取る。 04:06.520 --> 04:17.080 姓を分割してそのファイルを開き、 キーが従業員名、 ドキュメントがドキュメントである辞書に入れるだけです。 04:17.080 --> 04:20.020 では、 これを見てみよう。 04:20.020 --> 04:22.090 だから辞書に期待している。 04:23.080 --> 04:24.760 ああ、 申し訳ない。 04:25.210 --> 04:28.570 ええと......文脈というか辞書というか。 04:28.570 --> 04:31.180 すべてのキーを文脈に沿って見てみよう。 04:31.390 --> 04:33.130 その鍵はここにある。 04:33.130 --> 04:38.410 キーは予想通り、 従業員の姓である。 04:38.410 --> 04:42.040 その一人がランカスターで、 我々のCEOだ。 04:42.040 --> 04:44.560 では、 ランカスターを簡単に見てみよう。 04:44.560 --> 04:48.520 だから、 ランカスターの辞書を引けばいいのだ。 04:48.520 --> 04:53.620 そして、 彼女の人事記録からマークダウンされた文書をバンバン見るべきだ。 04:53.650 --> 04:58.990 ファイルを読んだり、 辞書に押し込んだりするようなマジックは、 ここではまったく行われていない。 04:58.990 --> 05:00.670 それだけだ。 05:01.480 --> 05:09.200 では、 これを拡張して、 商品についてもまったく同じことをやってみましょう。 05:09.230 --> 05:18.800 productsフォルダを探し、 それぞれのファイルを繰り返し見て、 名前を抜き出し、 それを同じコンテキスト辞書に突っ込む。 05:18.800 --> 05:22.520 だから今、 もし私が最初にそれを実行したら、 それを忘れないようにする。 05:22.520 --> 05:23.180 これでよし。 05:23.180 --> 05:24.650 そして、 次はキーを見てください。 05:24.650 --> 05:28.580 従業員の姓と製品名の組み合わせが表示されるはずだ。 05:28.940 --> 05:32.570 以下は姓とその市場である。 05:32.750 --> 05:33.620 ただいま 05:33.620 --> 05:34.910 私は落ち着いている。 05:35.030 --> 05:38.150 商品名は大丈夫ですか? 05:38.810 --> 05:40.130 準備はできている。 05:40.160 --> 05:41.780 システムメッセージが出ます 05:41.780 --> 05:47.180 あなたは、 私が保険技術会社であることを保証するための正確な質問に答える専門家です。 05:47.210 --> 05:49.100 簡潔で正確な回答をすること。 05:49.100 --> 05:51.590 答えがわからなければ、 そう言ってください。 05:51.590 --> 05:52.820 何も作るな。 05:52.820 --> 05:55.550 関連する文脈が提供されていないのであれば。 05:56.060 --> 06:02.570 このような非常に権威的な指示をシステムのプロンプトに表示させ、 モデルに捏造をしないように指示することが、 06:02.570 --> 06:08.790 幻覚を見るのを止めさせ、 精度を高く保つのに効果的であることがわかった。 06:08.970 --> 06:13.500 正確さが要求される場合には、 06:13.530 --> 06:20.550 このようなプロンプトが役に立つからだ。 06:20.940 --> 06:32.610 そこで、 関連するコンテキストの取得という関数を作り、 それをgetに追加することにしよう。 06:32.610 --> 06:35.490 だから、 この関数が何をするのか、 これはとても重要なことだ。 06:35.490 --> 06:45.090 どんなメッセージでもいい。 06:45.450 --> 06:55.020 そして、 コンテキストの各項目からタイトルと詳細を取り出しながら、 コンテキストの中を反復していく。 06:55.020 --> 07:07.370 そして、 役職、 従業員の姓名、 製品名(製品であれば)がメッセージのどこかに存在するかどうかを確認する。 07:07.370 --> 07:14.030 ランカスターという単語のようなテキストがメッセージのどこかにあれば、 それを関連する文脈のリストに押し込んで、 07:14.030 --> 07:18.920 最後にそのリストを返すだけだ。 07:18.950 --> 07:21.110 では、 それが何を意味するのか、 具体的にお見せしよう。 07:21.140 --> 07:34.670 だから、 関連する文脈を得ると言っているのに、 猫のようにまったく関係ないものを渡してしまったら、 何も返ってこない。 07:34.700 --> 07:38.870 猫は確保に関する質問とは関係ない。 07:38.900 --> 07:46.160 そして、 エイブリー・ランカスターが誰なのかを書けば、 万々歳だ! 07:46.190 --> 07:53.690 私たちが期待するような、 しっかりとした答えが返ってくるだろう。 07:53.840 --> 08:04.310 エイブリー・ランカスターとは誰なのか、 そして何が落ち着いているのか。 08:04.370 --> 08:09.030 それを含む2つのリストが返ってくるので見てほしい。 08:09.060 --> 08:10.800 そう、 2つ目が始まっているのがわかるだろう。 08:10.800 --> 08:12.600 それはコラムだ。 08:12.600 --> 08:17.940 エイブリーのドキュメントとカラムのドキュメントを含むリストが返ってくる。 08:18.450 --> 08:21.030 うーん、 でももちろん、 これは非常にもろい。 08:21.030 --> 08:32.220 エイブリーの姓を入れない場合は、 エイブリーとだけ言い、 大文字のCを使わずに綴る。 08:32.220 --> 08:34.950 何も返ってこないことに気づくだろう。 08:34.950 --> 08:36.360 これは脆い。 08:36.360 --> 08:39.780 それは基本的な場合にしか使えない。 08:40.620 --> 08:47.970 よし、 ではこれをもう一歩進めて、 メッセージを受け取るコンテキストの追加関数を作ってみよう。 08:48.120 --> 08:53.190 ええと、 つまり、 これは単純に関連する文脈を取得するということです。 08:53.190 --> 08:56.370 そして、 もし何か見つかれば、 それをメッセージに追加する。 08:56.370 --> 09:01.290 この質問に答えるには、 次のような追加的な文脈が関係するかもしれないと言うことだ。 09:01.290 --> 09:04.320 だから、 通過したものは何であれ、 その上に積み上げていくようなものなんだ。 09:04.320 --> 09:07.900 では、 例を挙げよう。 09:07.960 --> 09:12.880 ええと、 でも、 エイブリー・ランカスターは誰なのか、 ポジティブな例から始めましょう。 09:12.880 --> 09:17.170 エイブリー・ランカスターとは誰なのか? 09:19.270 --> 09:23.410 エイブリー・ランカスターって誰? 09:23.410 --> 09:24.700 何が見えるのか? 09:24.940 --> 09:25.840 そうだね。 09:25.840 --> 09:26.830 さあ、 始めよう。 09:26.830 --> 09:29.650 エイブリー・ランカスターって誰? 09:29.680 --> 09:32.620 この質問に答えるには、 次のような追加的な背景が関係するかもしれない。 09:32.620 --> 09:34.540 そしてディテールだ。 09:34.750 --> 09:37.870 ええと、 それなら反対の例を挙げよう。 09:37.870 --> 09:39.340 別の種類の問題だ。 09:39.340 --> 09:44.290 アレックス・ランカスターは誰ですかと言うと、 ランカスターと表示される。 09:44.290 --> 09:47.530 そしてもちろん、 ここに関連した文脈があると言うことに変わりはない。 09:47.740 --> 09:50.380 うーん、 それはもちろんトリックを外している。 09:50.380 --> 09:53.320 だから、 ラフで準備ができている。 09:53.440 --> 09:56.470 ええと、 本当に文字列のルックアップをしているだけです。 09:56.470 --> 10:01.570 しかし、 もちろん、 お気に入りのチャット機能を書くのに必要なのはそれだけだ。 10:01.570 --> 10:04.510 覚えているだろうか、 これがグラディオが期待する関数なのだ。 10:04.510 --> 10:12.200 クイック・ユーザー・インターフェースを構築するのであれば、 現在のメッセージとメッセージの履歴が必要です。 10:12.230 --> 10:20.510 その履歴を、 OpenAIが期待するフォーマット、 つまり特定の構造のディクトのリストに変換する。 10:20.510 --> 10:23.660 そして、 この素敵な電話をかける。 10:23.660 --> 10:28.880 私たちはメッセージに特別なコンテキストを追加し、 それをOpenAIに送信する。 10:28.880 --> 10:38.150 そして、 このOpenAIのチャットの完了は、 あなたにとって第二の天性であり、 私たちは応答をストリームバックします。 10:38.150 --> 10:40.190 では、 これを試してみよう。 10:40.280 --> 10:46.430 そして今、 私たちは最後のステップが、 グラディオにこれをもたらすワンライナーであることを知っている。 10:46.760 --> 10:47.510 さあ、 始めよう。 10:47.540 --> 10:49.370 どう見えるか見てみよう。 10:54.230 --> 10:56.000 じゃあ、 えーと。 10:56.060 --> 10:56.780 こんにちは。 10:59.510 --> 11:00.050 こんにちは。 11:00.050 --> 11:01.460 本日はどのようなご用件でしょうか? 11:01.490 --> 11:06.410 では、 エイブリー・ランカスターとは誰なのか? 11:08.620 --> 11:09.190 その通りだ。 11:09.190 --> 11:09.460 そうだね。 11:09.490 --> 11:10.570 ランカスター 11:11.950 --> 11:24.940 もちろん、 エブリー・ランカスターの情報がプロンプトに押し込まれ、 OpenAIに送信されたことは十分承知しているからだ。 11:25.300 --> 11:30.040 そして今、 私たちは何が冷静なのかも言える。 11:32.350 --> 11:34.870 そして革新的な自動車保険商品。 11:34.900 --> 11:35.770 さあ、 行こう。 11:35.770 --> 11:41.830 それは、 その製品を中心としたコンテキストの大きな塊から要約された、 1トンの情報を持っている。 11:41.950 --> 11:45.370 そして、 継続的改善のためのロードマップにまで言及している。 11:45.400 --> 11:46.390 素敵だ。 11:46.990 --> 11:50.110 ええと、 だからボロ雑巾だってわかるでしょ。 11:50.110 --> 11:54.130 単純なことだけど、 これがすべてなんだ。 11:54.220 --> 11:56.440 ちょっと休憩しよう。 11:56.440 --> 11:57.760 私が何をするかは想像がつくだろう。 11:57.790 --> 12:02.380 エイブリーって誰? 12:02.410 --> 12:09.950 まあ、 実際に過去からの会話があるのかもしれない。 12:10.040 --> 12:11.570 新鮮なチャットを持ち出す。 12:11.600 --> 12:15.470 そうでなければ、 エイブリーが誰なのかがわかってしまう。 12:15.470 --> 12:22.880 だから、 フレッシュな新しいユーザーインターフェースを立ち上げて、 ゼロから試してみよう。 12:22.910 --> 12:24.320 エイブリーとは? 12:25.760 --> 12:30.170 申し訳ないが、 エイブリーに関する確実な情報は持っていない。 12:30.470 --> 12:32.540 だから、 もろいのがわかるだろう。 12:32.540 --> 12:34.430 姓を名乗らなければならない。 12:34.430 --> 12:48.200 苗字のスペルを間違えても、 ランカスターが大文字の "L "でなくても、 壊れてしまう。 12:48.200 --> 12:51.620 これは、 プロンプトに補足情報を加える効果的な方法である。 12:51.650 --> 12:57.140 より正確な答えが返ってくるが、 もろく、 正確なテキストマッチングを必要とする。 12:57.140 --> 13:01.550 特に柔軟性があるわけでもなく、 拡張性の高いソリューションでもない。 13:01.670 --> 13:03.140 もっといい方法がある。 13:03.140 --> 13:06.710 そして、 それが次の日に私たちがやることだ。 13:06.710 --> 13:09.350 しかし、 スライドに戻ろう。