You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 

520 lines
17 KiB

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
しかし、 スライドに戻ろう。