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 それではまた次回。