WEBVTT 00:01.040 --> 00:08.960 先週は、 コードを60,000倍高速化できるモデルを扱った。 00:08.990 --> 00:13.130 そして、 今週末には、 私が用意したものを見て、 00:13.130 --> 00:17.150 さらに感動してくれることを期待している。 00:17.180 --> 00:20.330 だから、 ボロ雑巾の回収がすべてなんだ。 00:20.330 --> 00:25.850 もちろん、 フロンティア・モデルを使ったコードや、 顔を包み込むようなトランスフォーマーを使ったコードなど、 00:25.880 --> 00:27.200 すでにできることはある。 00:27.200 --> 00:32.660 プロジェクトに適したLLMを選択し、 コードを生成するソリューションを構築しよう。 00:32.690 --> 00:38.480 今日は、 ラグ検索拡張世代の大きなアイデアについて学ぶことにしよう。 00:38.480 --> 00:43.520 その前に、 ボロ雑巾の背後にある小さなアイデア、 実はごく当たり前のことなのだが、 00:43.520 --> 00:48.440 その小さなアイデアについても話しておこうと思う。 00:48.470 --> 00:50.960 実際、 あなた自身もすでに考えているかもしれない。 00:51.230 --> 00:55.520 そして、 小さなアイデアを使ってラグのおもちゃバージョンを実装するんだ。 00:55.520 --> 00:57.410 だから、 どのように機能するのか、 実にいい感触を得ることができる。 00:57.410 --> 01:00.050 来週を前に、 本題に入る。 01:00.080 --> 01:03.610 まず、 ボロ布の背後にある直感の一部を紹介しよう。 01:03.610 --> 01:10.750 プロンプト、 つまりモデルに送る情報を充実させることで、 モデルのパフォーマンスをより強力なものにできることはすでに見てきた。 01:10.750 --> 01:12.310 私たちはいくつかの方法でそれを実現した。 01:12.310 --> 01:18.790 私たちはマルチショット・プロンプトを使って、 一連の質問と回答の例をモデルに送りました。 01:18.790 --> 01:30.250 私たちはツールを使って、 LLMが私たちのコードにコールバックできるようにした。 01:30.250 --> 01:38.200 また、 システム・プロンプトを含め、 LLMに送る内容の一部として追加的なコンテキストを提供する方法は他にもあった。 01:38.290 --> 01:48.100 つまり、 もっと具体的な情報をプロンプトに提供することで、 このアイデアをステップアップさせ、 新たなレベルに引き上げることはできないか、 01:48.370 --> 01:49.840 ということだ。 01:49.840 --> 01:53.470 それは、 今の質問と特に関係がありそうだ。 01:53.500 --> 02:00.760 つまり、 情報をデータベース化できないか、 02:00.760 --> 02:04.240 ということだ。 02:04.540 --> 02:11.950 そして、 ユーザーから質問を受けるたびに、 まずナレッジ・ベースで関連する情報がないかどうかを調べ、 02:11.950 --> 02:15.970 それを引き出す。 02:15.970 --> 02:21.280 もしプロンプトがあれば、 それをプロンプトに詰め込み、 プロンプトをモデルに送信する。 02:21.310 --> 02:22.510 それだけだ。 02:22.540 --> 02:29.020 これは実はとてもシンプルなアイデアで、 おそらく、 以前の練習をやっているときに、 すでに自分で考えたことだろう。 02:30.100 --> 02:36.910 だから、 ボロ布の背後にあるこの小さなアイデアを図で示すだけにしておこう。 後で、 02:36.910 --> 02:41.830 より大きなアイデアにたどり着くことを約束しよう。 02:41.830 --> 02:47.290 しかし、 ちょっとしたアイデアでは、 私たちが言っているのは、 ユーザーが私たちに質問することから始めようということだ。 02:47.290 --> 02:51.220 それは私たちのコードに反映され、 通常はそれをそのままLLMに送ることになる。 02:51.220 --> 02:58.210 しかし今回は、 その前にナレッジベースに問い合わせを行い、 関連する背景情報があるかどうかを確認する。 02:58.210 --> 03:02.890 そうすれば、 その情報を抜き出し、 プロンプトに盛り込む。 03:02.920 --> 03:09.940 LMを送信すると、 もちろんいつものように返事が返ってくる。 03:09.940 --> 03:12.880 そしてそれがユーザーに還元される。 03:13.030 --> 03:17.050 ラグの背後にある小さなアイデアは本当にそれだけだ。 03:17.980 --> 03:23.500 そこで、 これからこれを小さなアイデアの例で実践してみよう。 03:23.680 --> 03:27.670 私たちが保険テックの新興企業に勤めているとしよう。 03:27.670 --> 03:35.080 そして、 それは保険という架空の保険テック・スタートアップになる。 03:35.080 --> 03:40.270 そしてLMの詰め物、 これが私の創造性の限界だと思う。 03:40.630 --> 03:48.250 会社の共有ドライブから取り出したフォルダーの形で、 ナレッジベースを持っています。 03:48.250 --> 03:55.780 それは彼らの共有ドライブの全コンテンツであり、 我々の仕事はAIナレッジワーカーを構築することだ。 03:55.780 --> 04:00.460 このナレッジ・ワーカーという表現は、 企業で働く専門家であり、 04:00.460 --> 04:08.340 企業に関する情報の分析や質疑応答ができる人という意味で使われることもある。 04:08.340 --> 04:12.630 まあ、 それはLLMがあればできることだ。 04:12.630 --> 04:16.920 そして、 知識ベースからの情報でそれを補うことができる。 04:17.430 --> 04:22.110 そこで、 玩具を使った鈍器を使うことにする。 04:22.350 --> 04:28.170 ええと、 基本的には、 これらのファイル、 製品、 従業員の一部を読むことになる。 04:28.170 --> 04:30.780 そして、 それを辞書のように格納する。 04:30.780 --> 04:38.610 そして、 質問が来るたびに、 その質問のどこかに従業員の名前が出てくるかどうかを調べます。 04:38.610 --> 04:42.750 もしそうなら、 その従業員記録をすべてプロンプトに押し込むことになる。 04:42.750 --> 04:48.210 ラグの実装は手作業で力技のようなものだが、 これが舞台裏で実際にどのように機能しているのか、 04:48.210 --> 04:49.950 よく理解できるだろう。 04:49.950 --> 04:52.350 そして、 そこには何の魔法もないことを教えてくれる。 04:52.380 --> 04:55.500 ただ、 すぐにモデルのパフォーマンスが向上する。 04:55.500 --> 04:58.770 それが終わったら、 もっとエキサイティングなことに取り掛かる。 04:58.770 --> 05:03.000 しかし今は、 JupyterLabに行き、 自作のボロ布を作ってみよう。