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.
 
 

181 lines
7.0 KiB

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に行き、 自作のボロ布を作ってみよう。