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.
 
 

478 lines
16 KiB

WEBVTT
00:00.890 --> 00:04.400
そしてついに、 ボロの活躍を見る時が来た。
00:04.430 --> 00:07.460
このような話の後、 我々はここにいる。
00:07.460 --> 00:10.730
私たちはもちろん、 JupyterLabの第5週目のフォルダにいる。
00:10.730 --> 00:16.760
私たちは4日目のノートを見ているが、 もちろん3日目と同じ内容で、 さらに追加されている。
00:16.760 --> 00:22.970
私たちは、 血清中の架空の保険技術会社のために、 知識労働者という同じ問題を今も解決しているのだから。
00:23.330 --> 00:27.620
ええと、 これまでと同じように輸入品から始めよう。
00:28.070 --> 00:35.570
そして今、 ラング・チェーン用のインポートがいくつかある。 ラング・チェーンのメモリーから2つの新しいインポートをこっそり追加した。
00:35.600 --> 00:38.570
会話バッファーのメモリーをインポートしている。
00:38.600 --> 00:43.010
そしてラング・チェーン・チェーンから会話型検索チェーンを導入する。
00:43.010 --> 00:46.850
そして、 この2つは前に述べた抽象的なものだ。
00:46.880 --> 00:52.310
さて、 勘のいい方はお気づきだろうが、 ここには3つ目の抽象化も潜んでいる。
00:52.310 --> 00:57.920
ただ、 以前の講義で言及せずにすでに輸入していたのだが、 ここに紹介しよう。
00:57.920 --> 01:02.180
チャットOpenAIはすでにラングチェーンの一部としてインポートされている。
01:02.180 --> 01:10.990
OpenAIは、 これまでOpenAIのエンベッディングしか使っていませんでしたが、 今回はチャットのOpenAIをミックスします。
01:11.050 --> 01:14.410
それじゃ、 インポートをしたほうがいいね。
01:15.010 --> 01:17.020
そうでなければ、 私たちは遠くへ行くことはできない。
01:17.620 --> 01:19.720
そこで、 いくつかの定数を設定する。
01:19.720 --> 01:21.850
環境変数をロードする。
01:21.850 --> 01:23.800
そして今、 あなたはこのことをよく知っている。
01:23.800 --> 01:30.580
しかし、 私たちはナレッジ・ベース・ディレクトリからドキュメントを持ってくる。
01:30.580 --> 01:35.350
では、 テキスト・チャンクを取り込んで、 その数を見てみよう。
01:35.350 --> 01:36.730
でも、 123だと信じている。
01:36.760 --> 01:39.040
そう、 123のテキストチャンクだ。
01:39.040 --> 01:44.200
そしてそれらは従業員であり、 製品会社であり、 契約である。
01:44.590 --> 01:50.020
そして今度は、 それらを再びベクター・データベースに入れる。
01:50.020 --> 01:52.300
ベクターデータベースを削除し、 再作成する。
01:52.390 --> 01:57.640
各ベクトルは1536次元であることがわかる。
01:57.640 --> 02:00.580
視覚化するのは難しいが、 2Dなら対応できる。
02:00.580 --> 02:01.930
だから、 そうするんだ。
02:01.930 --> 02:03.220
そして、 彼らはそこにいる。
02:03.220 --> 02:07.450
そして、 3Dでも見ましょうと言うこともできる。
02:07.480 --> 02:08.810
これはちょっとありがた迷惑だ。
02:08.810 --> 02:12.650
でも、 こういう図を見るのは好きだよ。
02:12.680 --> 02:16.820
よし、 じゃあここで、 私は嘘をついていない。
02:16.820 --> 02:19.790
この4行のコードと同じくらい簡単だ。
02:19.820 --> 02:24.050
まず、 新しいLM抽象化を作成する。
02:24.080 --> 02:25.250
チャットのOpenAI。
02:25.280 --> 02:27.950
しばらく輸入していたものを置くつもりだ。
02:27.950 --> 02:29.570
ついにそれを使うことになる。
02:29.960 --> 02:34.760
そして、 温度とモデル名、 メモリーを指定する。
02:34.820 --> 02:42.230
前にも書いたように、 キーを渡して、 リストの形で返してほしいと言って、 カンバセーショナル・バッファ・メモリを作る。
02:42.560 --> 02:52.580
クロマ・ベクター・ストアをリトリーバーと呼び、 ラング・チェーンに必要な抽象化されたリトリーバーで包みます。
02:52.580 --> 02:58.370
そして、 会話による検索チェーンを構築することになる。
02:58.370 --> 03:03.200
そして私たちは、 LM、 レトリーバー、 そして記憶を受け継ぐだけなのだ。
03:03.740 --> 03:04.700
それだけだ。
03:04.820 --> 03:05.780
それを実行しよう。
03:07.040 --> 03:07.640
オーケー。
03:07.640 --> 03:08.960
だから私たちはそれを実行した。
03:09.140 --> 03:10.430
少し拍子抜けしたかもしれない。
03:10.430 --> 03:15.490
突然ボロが目の前に現れるとでも思っていたのか。
03:15.700 --> 03:16.960
実際に電話しなければならない。
03:16.990 --> 03:19.270
それを生かすために何かをしなければならない。
03:19.300 --> 03:25.690
だから、 これから言うのは、 うーん、 うーん、 クエリーコールだ。
03:26.770 --> 03:38.230
簡単なところから始めましょう。
03:38.320 --> 03:38.620
分かった。
03:38.650 --> 03:39.370
そして、 あなたはこう言う。
03:39.370 --> 03:41.800
あなたは結果が会話の連鎖だと言う。
03:41.800 --> 03:46.510
今作ったものをメソッドinvokeと呼ぶ。
03:46.600 --> 03:52.600
そして、 invokeはquestionをキーとする辞書を取る。
03:52.690 --> 03:53.620
スペルは正しかったかな?
03:53.650 --> 03:53.830
そうだ。
03:53.830 --> 03:54.850
質問だ。
03:55.150 --> 03:58.780
そして、 メッセージクエリーを入れなければならない。
04:00.010 --> 04:01.420
そうだ。
04:01.420 --> 04:04.810
そして結果を印刷する。
04:06.430 --> 04:09.610
これは、 その結果の答えのキーの下にあるものでなければならない。
04:09.610 --> 04:15.640
これが、 ラグ・パイプラインを利用するための最後のコードだ。
04:15.680 --> 04:16.970
では、 どうなると思う?
04:16.970 --> 04:18.620
その問い合わせが必要だ。
04:18.620 --> 04:21.110
それをベクトルに変えるんだ。
04:21.110 --> 04:24.230
クロームのデータストアでそれを検索する。
04:24.260 --> 04:27.440
関連するチャンクを見つけるだろう。
04:27.440 --> 04:29.780
チャンクは複数形だ。
04:29.780 --> 04:31.250
そして、 またその話に戻るつもりだ。
04:31.580 --> 04:33.320
だから、 関連するチャンクを見つけることができる。
04:33.320 --> 04:38.930
そしてそれをプロンプトにドロップし、 OpenAIに送る。
04:39.020 --> 04:43.130
GPT4ミニに送られます。
04:43.130 --> 04:48.170
そして、 戻ってきたものをパッケージして、 それを解答用紙に入れる。
04:48.200 --> 04:49.940
うまくいくかどうか見てみよう。
04:52.400 --> 04:53.480
これでよし。
04:53.510 --> 04:54.560
これでよし。
04:54.560 --> 04:59.240
ショアハムで初めてのラグ・パイプラインをフロントからバックまで走らせたところだ。
04:59.270 --> 05:06.230
エイブリー・ランカスターによって設立された革新的な保険技術会社である。
05:06.230 --> 05:07.940
それに断片的な情報もある。
05:07.940 --> 05:12.980
いろいろな文書から、 おそらく会社のセクションのアバウトなものから、
05:12.980 --> 05:18.530
それを取り出しているのがわかるだろう。
05:18.530 --> 05:24.910
ええと、 でも、 いろいろな情報のかたまりからそれを取り出していることがわかるといいんだけど。
05:25.960 --> 05:26.860
分かった。
05:26.860 --> 05:28.750
まあ、 いいんじゃない?
05:29.230 --> 05:30.310
これがどこに向かっているのかわかるかい?
05:30.340 --> 05:37.480
それを美しいユーザーインターフェイスにパッケージして、 チャットUIで実際に使えるようになればいいと思いませんか?
05:37.480 --> 05:41.290
そしてもちろん、 Gradioはそれを超シンプルにしてくれる。
05:41.290 --> 05:47.890
この時点で私たちがしなければならないことは、 Gradioが期待するフォーマットでチャット関数を作成することだとわかっている。
05:47.890 --> 05:50.170
それにはメッセージと歴史が必要だ。
05:50.170 --> 05:58.480
だから、 さっき書いたセリフをそのままここに書いて、 僕らが期待しているものをそのまま返しているんだ。
05:58.510 --> 06:04.540
さて、 何か不思議なものが見えるかもしれない。 少し時間をおいて、 何か、 何か奇妙に感じるものがないか見てみよう。
06:06.070 --> 06:12.430
さて、 奇妙に思われるかもしれないが、 このヒストリー・パラメーターでは実際には何もしない。
06:12.520 --> 06:14.440
ああ、 完全に無視している。
06:14.440 --> 06:19.570
そして、 私たちがそれを無視するのは、 もちろん、 ラング・チェインがすでに私たちのために歴史を扱っているからだ。
06:19.570 --> 06:26.820
GradioのチャットUIは、 ユーザー・インターフェースの履歴を保持し、
06:26.820 --> 06:30.570
チャット履歴を毎回コールバックする。
06:30.600 --> 06:38.430
なぜなら、 ラングがすでに私たちにこの記憶力を与えてくれていて、 これまでの会話を記録してくれているからだ。
06:38.460 --> 06:41.730
それが知る必要があるのは、 新しいメッセージと新しい答えだけだ。
06:42.570 --> 06:45.180
だからとにかく、 ここでセルを再運転しているんだ。
06:45.210 --> 06:47.970
実はすでに再実行したんだけど、 メモリを一掃するために再実行しているんだ。
06:47.970 --> 06:50.190
だから、 まったく新しいスタートを切る。
06:50.220 --> 06:55.230
この話を持ち出したら、 あとはおしゃべりするだけだ。
06:55.500 --> 06:56.340
こんにちは。
06:57.780 --> 06:58.380
こんにちは。
06:58.380 --> 06:59.700
本日はどのようなご用件でしょうか?
07:00.060 --> 07:02.520
保険とは何か?
07:02.640 --> 07:03.090
うーん。
07:08.490 --> 07:09.150
これでよし。
07:09.180 --> 07:10.560
驚きはない。
07:10.680 --> 07:13.230
そして今、 私たちは卑劣なことをすることができる。
07:13.260 --> 07:14.970
私たちは次のように言うことができる。
07:15.030 --> 07:19.470
エイブリーは以前何をしていたのですか?
07:20.100 --> 07:26.490
なぜこのような話をしたかというと、 このような質問にはいくつか表面化させたいことがあるんだ。
07:26.490 --> 07:34.030
つまり、 まず明白なことを言うと、 私たちのおもちゃのラグ・バージョンの前のブルートフォース・ソリューションは、 ランカスターを名字として見て、
07:34.030 --> 07:38.860
ドキュメントからそれを検索することができたが、 これはかなり絶望的だった。
07:38.860 --> 07:41.560
そして、 鳥小屋という言葉を使おうとしたら、 それは私たちの失敗だった。
07:41.560 --> 07:45.160
だから、 ここで試してみるのはもちろん面白い。
07:45.190 --> 07:50.470
第二に、 aviaryをわざと小文字のaにした。 aviaryはスペルが違うので、
07:50.470 --> 07:56.770
テキスト検索をするものが間違ってしまうからだ。
07:56.770 --> 08:02.620
だから、 僕らが正しいケースを使っていないという事実を扱えるかどうか、 興味深いところだね。
08:02.620 --> 08:08.380
そして第三に、 私はこの記憶のアイデアを利用しているんだ。
08:08.410 --> 08:11.920
つまり、 エルムで創業する前は何をしていたのか、 ということだ。
08:11.920 --> 08:18.220
そして、 このモデルが、 鳥小屋に関する関連情報を検索し、 以前彼女が何をしたかという文脈を保つことができるほど、
08:18.220 --> 08:22.780
何が起こっているのかを十分に理解しているかどうかを見ることになる。
08:22.810 --> 08:25.000
それは彼女の従業員記録から得る必要がある。
08:25.120 --> 08:29.350
それと、 質問に首尾一貫して答えてください。
08:29.350 --> 08:30.310
見てみよう。
08:33.420 --> 08:38.670
エイブリー・ランカスターはショーハムで創業する以前、 イノベート・インシュアランス・ソリューションズでシニア・プロダクト・マネージャーとして働き、
08:38.670 --> 08:40.620
画期的な保険を開発していた。
08:40.980 --> 08:43.830
それ以前は、 市場動向に焦点を当てたビジネスアナリスト。
08:43.860 --> 08:49.860
だから、 彼女の従業員記録をチェックし、 それが本当に正しく発見され、
08:49.860 --> 09:01.200
エイブリーの正しい経歴が得られるかどうか、 納得してもらうための練習として、 ええと、 試してみる楽しみとして残しておこう。
09:01.320 --> 09:05.850
そしてもちろん、 他の難しい質問にも挑戦する。
09:06.000 --> 09:10.200
ええと、 どういうこと?
09:12.960 --> 09:13.140
ええと。
09:13.140 --> 09:13.860
見てみよう。
09:13.890 --> 09:20.730
落ち着いて......あれは車だよ。
09:21.210 --> 09:21.390
うーん。
09:21.420 --> 09:24.420
あるいは、 うーん、 別の聞き方はどうだろう。
09:24.420 --> 09:35.650
保険は自動車保険の分野で車内に何か商品を提供しているとしよう。
09:36.550 --> 09:38.770
トリッキーな質問をしよう。
09:39.040 --> 09:40.570
さあ、 行こう。
09:40.600 --> 09:40.960
そうだ。
09:40.990 --> 09:44.530
保険は、 自動車保険会社のポータルサイトであるCalmを提供している。
09:44.530 --> 09:53.020
だから、 私がcalmという単語を使わなくても、 carという単語を使わなくても、 関連する文書、 関連するチャンクを見つけ、
09:53.020 --> 09:58.060
質問に正確に答えることができた。
09:58.540 --> 10:03.160
これがラグを使った最初の実験だね。
10:03.190 --> 10:04.930
ぜひ試してほしい。
10:04.930 --> 10:10.450
調査し、 難しい質問をし、 それを破ることができるか、 間違った情報を与えるように仕向けることができるか、
10:10.450 --> 10:15.190
あるいはレールから外れて限界まで引き伸ばすことができるか、 見極めてほしい。
10:15.220 --> 10:21.340
次回は、 このようなプロンプトが表示される場合によくある問題や、
10:21.340 --> 10:28.180
デバッグの方法についてお話しします。
10:28.210 --> 10:37.540
しかし、 ショアハムにある架空の保険技術会社のために作られた初のエンド・トゥ・エンドのラグ・パイプラインを楽しんでいただけたなら幸いだ。
10:37.600 --> 10:38.620
それではまた次回。