- Events
「Deep Research」を成り立たせるものとは？AIエージェントへの深掘り
トレーニング
「Deep Research」を成り立たせるものとは？AIエージェントへの深掘り
Join the Webinar
Loading...
このウェビナーについて:
よほど世間に疎くない限り、2025年2月2日にOpenAIがDeep Researchをリリースしたことは耳にしているでしょう。この新製品は、多種多様な大量の情報を統合する必要がある質問への回答方法を革新すると期待されています。しかし、この技術はどのように機能し、なぜDeep Researchはこれまでの試みと比べて明らかな改善となっているのでしょうか？このウェビナーでは、基本的なクローンであるDeep Searcherを例に、現代のエージェントを支える概念を検討します。
deepsearcher_architecture_088c7066d1 (1).png
取り上げるトピック:
- ツールの使用
- 構造化出力
- リフレクション
- 推論モデル
- 計画
- エージェント的メモリの種類
WEBVTT
1 00:00:03.565 --> 00:00:05.555 本日は、今日のセッションをご紹介できてうれしく思います。
2 00:00:05.825 --> 00:00:08.955 「Deep researchをAIエージェントへの深掘りにするもの」
3 00:00:09.175 --> 00:00:10.875 そしてゲストスピーカーのStefan Webbです。
4 00:00:11.415 --> 00:00:15.275 StefanはVIIsのデベロッパーアドボケイトで、そこで
5 00:00:15.275 --> 00:00:17.355 オープンソースのベクトルデータベース、no listを推進しています。
6 00:00:17.805 --> 00:00:20.475 それ以前は、業界で3年間、
7 00:00:20.475 --> 00:00:23.275 Twitterとmetaの応用ML研究者として
8 00:00:23.335 --> 00:00:25.715 プロダクトチームと協力し、
9 00:00:25.775 --> 00:00:27.755 最も複雑な課題に取り組んでいました。
10 00:00:28.305 --> 00:00:31.195 StephanはUniversity of OxfordでPhDを取得しており、
11 00:00:31.455 --> 00:00:33.035 論文を発表しています
12 00:00:33.255 --> 00:00:36.835 また、主要な、ええと、主要な機械学習カンファレンスで、
13 00:00:36.835 --> 00:00:39.195 nres、ICLR、ICMLなどです。
14 00:00:39.655 --> 00:00:41.635 彼は生成AIに情熱を持っており、
15 00:00:41.815 --> 00:00:44.435 自身の深い技術的専門知識を活用して
16 00:00:44.495 --> 00:00:46.435 オープンソースコミュニティに貢献したいと強く思っています。
17 00:00:46.775 --> 00:00:47.915 ええ、ようこそ、Stefan。
18 00:00:48.455 --> 00:00:50.755 どうもありがとう、Sachi。親切なご紹介をありがとうございます。
19 00:00:51.135 --> 00:00:53.955 その通りで、私は生成AIに非常に情熱を持っています
20 00:00:54.455 --> 00:00:56.835 そして開発者を支援することにも情熱を持っています。
21 00:00:57.455 --> 00:01:02.155 ですので、ええ、こうしたウェビナーを行うのが本当に好きで、ええ、
22 00:01:02.155 --> 00:01:03.395 私たちのユーザーの一部に会ったり
23 00:01:03.655 --> 00:01:06.035 そして、つまり、単に、ええ、
24 00:01:06.035 --> 00:01:07.515 データベースやve aiに関心のある人々と会ったりしています。
25 00:01:08.615 --> 00:01:10.435 では、ええと、始める前に私自身について
26 00:01:10.435 --> 00:01:11.635 ほんの少しだけお話しします。
27 00:01:12.255 --> 00:01:17.075 私は、zilleの、ええ、デベロッパーアドボケイトと呼ばれる役割です。
28 00:01:17.575 --> 00:01:19.795 同社は主要なオープンソース
29 00:01:20.335 --> 00:01:22.355 ベクトルデータベース、ええ、vissを手がける会社です。
30 00:01:23.055 --> 00:01:26.155 そしてデベロッパーアドボケイトとして、サービスは、
31 00:01:26.155 --> 00:01:30.475 開発者と、ええと、その、そのユーザー、
32 00:01:30.815 --> 00:01:33.915 vissのユーザーと、ええと、その、ええと、開発者の間の橋渡しのようなものです。
33 00:01:33.935 --> 00:01:38.515 ですので、ユーザーに技術サポートを提供し、ええと、
34 00:01:38.585 --> 00:01:43.515 ユーザーを、ええと、エンジニアとつなぎ、ええと、
35 00:01:43.615 --> 00:01:44.955 つまり、より深い技術サポートを行うのを助けています。
36 00:01:45.705 --> 00:01:48.755 また、多くの、ええと、イベントも運営しています
37 00:01:49.385 --> 00:01:50.955 たとえば、ええ、こうしたウェビナーです。
38 00:01:51.095 --> 00:01:55.195 私たちは毎月、ええ、Bay Areaでミートアップを行っています。ええと、
39 00:01:55.855 --> 00:01:58.435 そして、ええと、つまり、いくつか、たとえば、
40 00:01:58.665 --> 00:02:00.075 文章コンテンツも制作しています。
41 00:02:01.495 --> 00:02:03.915 それで、ええと、LinkedInをそこに載せておきました。
42 00:02:04.135 --> 00:02:07.155 ええ、私はいつも、ええ、
43 00:02:07.225 --> 00:02:08.515 ええと、新しい方々とつながるのが大好きです。
44 00:02:09.315 --> 00:02:10.875 皆さんが生成AIで何を作っているのか、
45 00:02:10.875 --> 00:02:13.795 そして、皆さんのある種の
46 00:02:13.795 --> 00:02:14.875 課題が何なのか、
47 00:02:15.015 --> 00:02:18.235 そして皆さんの、皆さんの、ええと、皆さんのビジョンが何なのかを聞くのが大好きです。
48 00:02:18.895 --> 00:02:20.235 それが、いわば私の本業です。
49 00:02:20.455 --> 00:02:23.395 ですので、ええ、ぜひ、ええ、LinkedInでつながってください。
50 00:02:23.475 --> 00:02:24.835 ぜひ皆さんのお話を聞きたいです。
51 00:02:25.015 --> 00:02:27.355 そして、ええと、つまり、もし、
52 00:02:27.735 --> 00:02:28.955 もしragのようなものを構築しているなら
53 00:02:29.055 --> 00:02:31.875 あるいは、あなたの、あなたのスタートアップのエージェントシステム
54 00:02:31.935 --> 00:02:35.035 またはあなたの会社において、非常に良い機会があると思います
55 00:02:35.215 --> 00:02:39.515 ええと、Zelのような会社のdeveloper advocateにとって
56 00:02:39.695 --> 00:02:40.755 ある種の支援をし
57 00:02:40.815 --> 00:02:45.395 そして、ええと、いくらかの、いくらかの、ええと、コンサルテーションを提供するための。
58 00:02:46.175 --> 00:02:50.195 それでは、ウェビナーを始めましょう。
59 00:02:51.255 --> 00:02:55.555 今日の、今日のトピックは、ディープリサーチを成り立たせるもの、
60 00:02:56.375 --> 00:02:59.075 そして副題として、AIエージェントへの掘り下げ、としています。
61 00:02:59.745 --> 00:03:02.565 ですので、リサーチエージェントについて話していきます
62 00:03:03.205 --> 00:03:04.725 特に、ええと、
63 00:03:04.745 --> 00:03:06.845 ただ、この多くはある意味で
64 00:03:07.465 --> 00:03:09.925 一般的な生成AIエージェントにも関係すると思います。
65 00:03:12.065 --> 00:03:15.165 まず最初に、ええと、ほんの少しだけ
66 00:03:15.165 --> 00:03:19.845 OpenAIのdeep researchリリースの背景を、ええと、お話しします
67 00:03:20.785 --> 00:03:24.485 それから、あるリサーチエージェントを紹介します
68 00:03:24.755 --> 00:03:29.365 それはそれに触発されたオープンソースのもので、ええと、
69 00:03:30.085 --> 00:03:32.685 Zillowsのエンジニアによって作られ、完全にオープンソース化されています。
70 00:03:33.745 --> 00:03:37.285 それで、ええと、ええ、デモと言っていますが、どちらかというと、
71 00:03:37.285 --> 00:03:38.405 コードウォークスルーのようなものです。
72 00:03:38.875 --> 00:03:40.965 どのように組み立てられたのかを説明していきます。
73 00:03:42.475 --> 00:03:45.845 その後、いくつかの考え方について少し話します
74 00:03:46.505 --> 00:03:50.765 一般的なエージェントの背後にある、ええと、考え方、またリサーチエージェントについて
75 00:03:51.305 --> 00:03:52.685 そして何が新しいのか
76 00:03:52.865 --> 00:03:56.005 そしてなぜdeep researchが
77 00:03:56.005 --> 00:03:58.485 これほど最近、ええと、登場してきたのか。
78 00:03:59.465 --> 00:04:02.325 そして、その、その、ええと、そうですね、その議論によって、
79 00:04:02.865 --> 00:04:05.125 いくつかの、いくつかの課題が何なのか、
80 00:04:05.125 --> 00:04:09.645 そして、ええと、はい、
81 00:04:09.805 --> 00:04:11.765 つまり、より広い採用に向けた課題や障害が、
82 00:04:11.945 --> 00:04:13.165 明確になるはずです。
83 00:04:13.345 --> 00:04:15.285 ですので、それらのいくつかと
84 00:04:15.985 --> 00:04:17.645 潜在的な解決策について話します。
85 00:04:17.705 --> 00:04:21.565 つまり、皆さんに、ええと、感覚を、感覚をお伝えするような形です
86 00:04:22.015 --> 00:04:25.125 短期的に物事がどこへ向かっているのか、
87 00:04:25.195 --> 00:04:27.085 今後6か月、6か月から12か月、などについて。
88 00:04:27.945 --> 00:04:29.045 それでは
89 00:04:29.045 --> 00:04:33.925 始めましょう。
90 00:04:34.105 --> 00:04:38.005 それから、ええと、ちなみに、ええと、質問があれば遠慮なく
91 00:04:38.705 --> 00:04:41.085 チャットで、その都度してください。
92 00:04:42.065 --> 00:04:44.165 そして、ええと、私はその都度、私は、私は止まります
93 00:04:44.365 --> 00:04:46.325 質問が来たらいつでも、ええと、または、
94 00:04:46.325 --> 00:04:48.605 そうできるよう最善を尽くして、来た順に取り上げます。
95 00:04:49.625 --> 00:04:51.725 それでは、ええと、わかりました。
96 00:04:52.385 --> 00:04:56.125 では、ええと、ええ、ここにいる皆さんはきっと
97 00:04:56.835 --> 00:05:00.925 OpenAIについて、ええと、彼らの新製品リリースの一つ、ええと、
98 00:05:00.955 --> 00:05:05.325 deep researchについて聞いたことがあると思います。これは非常に、ええと、
99 00:05:05.665 --> 00:05:09.365 または、ええと、先月2月の初め頃にリリースされました。
100 00:05:10.465 --> 00:05:13.085 そしてこれは、ええと、少し異なる製品です
101 00:05:13.465 --> 00:05:18.245 彼らのいわゆる、ええと、通常のチャットボットとは、つまり、
102 00:05:18.865 --> 00:05:23.365 ええと、ええ、これは外に出て、ええと、できるという点で、
103 00:05:23.425 --> 00:05:26.925 ウェブを検索したり、ほかのことをしたり、ほかの種類のツールを使ったりして
104 00:05:27.465 --> 00:05:31.965 あなたの質問に対して、ええと、本当に詳細なレポートを作成します。
105 00:05:32.905 --> 00:05:33.965 そして、それを与えることができます。
106 00:05:34.225 --> 00:05:36.125 それで、ええと、ここでスクリーンショットを撮っただけです。
107 00:05:37.225 --> 00:05:39.205 ええと、それで、ええと、これは一例です。
108 00:05:39.865 --> 00:05:44.645 この場合の質問は、ええと、あの、
109 00:05:44.705 --> 00:05:48.365 調べてください、ええと、中級者のライダーに適したフリースタイルスノーボードを
110 00:05:49.105 --> 00:05:50.685 というものだったかもしれません、
111 00:05:51.225 --> 00:05:55.965 そしてユーザーが、あの、いくつかの詳細、自分の身長、
112 00:05:55.965 --> 00:05:57.645 体重、靴のサイズなどを与えています。
113 00:05:58.705 --> 00:06:03.245 それで、ええと、するとこの、あの、このエージェントが、ええと、動き出して、
114 00:06:03.985 --> 00:06:07.565 あの、使います、つまりウェブを検索して、ええと、
115 00:06:08.625 --> 00:06:13.165 そして、あの、ある種、あの、取り組むことができます、ええ、ある種
116 00:06:13.165 --> 00:06:16.125 この質問にどう答えるかを見つけ出すようなことです。
117 00:06:16.905 --> 00:06:21.725 ええと、ある種、あの、一つのステップから別のステップへ反復していくように。
118 00:06:22.665 --> 00:06:25.485 そして、ええと、しばらくして、8分くらいかもしれないし、
119 00:06:25.485 --> 00:06:29.565 30分かもしれませんが、あの、本当に詳細で
120 00:06:30.145 --> 00:06:32.645 一貫性のある、情報に基づいたレポートをまとめます。
121 00:06:33.745 --> 00:06:36.525 それで、つまりこれは、ある種の
122 00:06:36.525 --> 00:06:40.725 昔ながらの、あの、chat GPTとはかなり違います。そちらは単に、
123 00:06:41.945 --> 00:06:44.765 ええと、要するに、回答をほぼ
124 00:06:44.765 --> 00:06:46.965 リアルタイムで返してくるようなもので、ある種、出かけていって
125 00:06:47.425 --> 00:06:50.325 そして、あの、多くの、あの、自律的なステップを踏むというよりは。
126 00:06:53.065 --> 00:06:57.045 それで、ええと、思うに、失礼、あの、
127 00:06:57.865 --> 00:07:01.045 なぜこのようなものが、ええと、
128 00:07:01.045 --> 00:07:02.885 メディアである種爆発的に話題になったのかというと、あの、
129 00:07:02.885 --> 00:07:05.565 人々がその結果に本当に感銘を受けたからです。
130 00:07:06.505 --> 00:07:11.365 それは実際に調査するという点で非常に優れた仕事をしているように見えました、
131 00:07:11.785 --> 00:07:15.205 あの、単に普通の答えを必要とするだけではないかもしれないトピックを、
132 00:07:15.265 --> 00:07:17.085 実際には出かけていって、
133 00:07:17.355 --> 00:07:18.805 複数の情報源を見ることを必要とするかもしれないものを、
134
135 00:07:21.885 --> 00:07:23.105 さらに質問をすることを。
136 00:07:24.045 --> 00:07:26.945 そしてどこかで読んだと思うのですが、ええと、ある種、あの、
137 00:07:26.975 --> 00:07:29.905 教授が、これはある種、要するに、
138 00:07:29.905 --> 00:07:32.265 ええと、
139 00:07:32.535 --> 00:07:35.865 研究をいくらか行うという点では、初期段階の博士課程学生のようなものを
140 00:07:35.895 --> 00:07:38.145 置き換えられるかもしれない、と言っていて、ええと、
141 00:07:38.145 --> 00:07:39.225 ほかの専門家たちもただ
142 00:07:39.225 --> 00:07:40.265 その結果に本当に感銘を受けていました。
143 00:07:40.725 --> 00:07:42.825 ええと、でもそれの何が正確に新しかったのでしょうか？
144 00:07:42.895 --> 00:07:45.865 まあ、それは商業的にリリースされた
145 00:07:46.385 --> 00:07:50.105 最初のリサーチエージェントではありませんでした。つまりGoogleの、あの、deep researchは
146 00:07:50.685 --> 00:07:53.985 およそ1か月前の、12月にリリースされていました。
147 00:07:56.045 --> 00:07:58.945 ええと、では、ええと、正確に何が新しかったのでしょうか？
148 00:07:58.945 --> 00:08:01.945 つまり何が、なぜ、なぜそれはある種、ええと、それについて何が
149 00:08:01.945 --> 00:08:05.745 これほどはるかに優れた、ええと、出力を、
150 00:08:06.005 --> 00:08:07.025 あの、質的にもたらしたのでしょうか？
151 00:08:08.485 --> 00:08:11.825 そして、ええと、それへの答えは、あの、
152 00:08:12.235 --> 00:08:14.745 私たちにはよくわからないと思います。なぜなら、それはクローズドソースだからです。
152 00:08:15.375 --> 00:08:17.625 設計は、ある種、厳重に守られた秘密のようなものです。
153 00:08:18.365 --> 00:08:21.945 でも、ええと、なんというか、その、ええ、そういう
154 00:08:21.945 --> 00:08:23.065 噂話からすると、
155 00:08:23.385 --> 00:08:25.905 内部の人に話を聞いた人たちがいる、という感じだと思います。
156 00:08:26.445 --> 00:08:29.065 ええ、それに加えて、ええと、その、その、そのブログ
157 00:08:29.065 --> 00:08:32.625 とOpenAIが公開した発表を見ると、大きな、
158 00:08:32.825 --> 00:08:36.305 その大きな、ええと、要素の一つは、ええと、
159 00:08:36.455 --> 00:08:40.425 それが、ええ、なんというか、ええ、
160 00:08:41.405 --> 00:08:43.625 ええ、エンドツーエンドの、ええ、訓練に焦点を当てていて、
161 00:08:43.625 --> 00:08:47.545 本当に高品質な、ええ、ええ、
162 00:08:47.575 --> 00:08:51.265 推論トレースデータに対する強化学習を使っている、ということのようです。これについてはこのあともう少し話します。
163 00:08:51.765 --> 00:08:53.025 ええと、ただ繰り返しますが、
164 00:08:53.305 --> 00:08:55.025 設計の中には他にも何かある可能性があります。
165 00:08:55.625 --> 00:08:57.285 ええ、クローズドソースなので、ただ分からないんです。
166 00:08:58.065 --> 00:09:00.765 でも、私たちが使っている、ええ、ベンチマークで
167 00:09:00.785 --> 00:09:03.285 同様の結果を達成できるシステムを、ええと、再現しようとすることで、
168 00:09:03.395 --> 00:09:07.725 それらが何なのかを、ある程度推測することはできます。
169 00:09:07.945 --> 00:09:09.405 ええと、ええ、私たちが使っているベンチマークです。
170 00:09:10.265 --> 00:09:14.685 それで、そうした、ええ、そうしたモデルの一つが、ええ、
171 00:09:14.995 --> 00:09:17.125 DeepSeekのものです。
172 00:09:17.505 --> 00:09:19.645 つまりDeepSeek r run、ええ、R1です。
173 00:09:19.645 --> 00:09:21.645 それについては少し後で話します。
174 00:09:25.405 --> 00:09:28.135 はい。では、ええ、リサーチエージェントとは正確には何で、
175 00:09:28.555 --> 00:09:33.375 リサーチエージェントは、単なる、なんというか、
176 00:09:33.595 --> 00:09:36.655 一般的な意味でのエージェントとどう違うのでしょうか？
177 00:09:37.595 --> 00:09:40.255 これは生成AIにおけるそういうものの一つだと思いますが、
178 00:09:40.835 --> 00:09:44.775 今のところ、人々は定義について意見が一致していません。
179 00:09:45.395 --> 00:09:47.015 ええと、私たちはまだ、ある種、
180 00:09:47.015 --> 00:09:49.055 正確な、ええ、定義へと収束しつつあるところです。
181 00:09:50.515 --> 00:09:54.735 でも、ええと、ええ、ええ、私の定義は、多くの人のものと
182 00:09:54.735 --> 00:09:59.135 重なると思いますが、それはエージェントで、つまり、その、ええと、その、
183 00:09:59.135 --> 00:10:02.375 目標は、ええと、
184 00:10:02.595 --> 00:10:06.015 リサーチをすることです。つまり、どこかへ行って、
185 00:10:06.555 --> 00:10:10.255 ええ、多くの、多くの関連ソースを発見しなければならない、という意味です。
186 00:10:10.635 --> 00:10:14.095 つまり、単に一回だけ、ええと、
187 00:10:14.295 --> 00:10:16.455 ベクトルデータベースを検索するだけではなく、あるいは、ほら、
188 00:10:16.455 --> 00:10:19.495 単にWikipediaの1ページにアクセスするだけでもなく、
189 00:10:20.205 --> 00:10:23.775 それは取り込んで、ええ、それは、ええと、ええ、
190 00:10:23.775 --> 00:10:28.695 検索すべきさまざまなソースについて、ええ、判断を下し、
191 00:10:30.275 --> 00:10:32.215 それから、ええと、ええ、
192 00:10:32.545 --> 00:10:35.015 質問を複数のステップに分解します。
193 00:10:35.995 --> 00:10:40.295 ええと、そして、ええ、ある種、ええ、
194 00:10:40.395 --> 00:10:42.415 あるいは、ええ、自律的に、ある種、質問への回答を
195 00:10:42.415 --> 00:10:45.775 推論して進め、それから、なんというか、
196 00:10:46.135 --> 00:10:49.015 最後に詳細なレポートを統合します。
197 00:10:49.955 --> 00:10:52.655 それで、ええと、ここに、なんというか、
198 00:10:53.115 --> 00:10:55.575 Deep Researchのリリースブログからの引用をいくつか用意しました。
199 00:10:56.275 --> 00:10:58.615 そして、私は3つのテーマのようなものを見ました。
200 00:10:59.355 --> 00:11:03.735 つまり、イテレーションがあり、ええと、検索があります。
201 00:11:04.115 --> 00:11:07.295 あるいは、ええと、あの、ツールの使用について話す、という感じでしょうか。
202 00:11:07.835 --> 00:11:10.655 そして3つ目は、ええと、推論です。
203 00:11:11.835 --> 00:11:16.055 では、反復というテーマのもとで言うと、その、ええと、
204 00:11:16.325 --> 00:11:20.335 deep researchのリリース、ええと、ブログ記事では、述べられていて、
205 00:11:20.355 --> 00:11:24.775 そこには、ええと、あの、計画を学ぶ、といったことが説明されていました。
206 00:11:25.005 --> 00:11:29.015 複数ステップの軌道を実行すること、またバックトラッキング
207 00:11:29.115 --> 00:11:31.815 そしてリアルタイムの情報に反応することです。
208 00:11:33.115 --> 00:11:36.655 つまりこれは明らかに、ええと、あの、
209 00:11:36.655 --> 00:11:40.095 次に何をすべきかを自律的にある程度知ることができる
210 00:11:40.095 --> 00:11:43.535 エージェントのようなものを説明していて、ええと、また、必要に応じて
211 00:11:43.555 --> 00:11:46.015 遭遇した情報に反応して方向転換することも含みます。
212 00:11:47.635 --> 00:11:48.935 ええと、2つ目の点ですが、
213 00:11:48.935 --> 00:11:51.175 これらはある意味、つまり、その、
214 00:11:51.245 --> 00:11:52.415 3つの間には重なりがあると思います。
215 00:11:52.875 --> 00:11:56.565 ええと、しかし検索というテーマのもとでは、その、
216 00:11:56.565 --> 00:12:00.285 ブログ記事には、さまざまなドメインにわたる難しいブラウジング
217 00:12:00.885 --> 00:12:02.805 および推論タスクに対するエンドツーエンドの
218 00:12:02.805 --> 00:12:05.485 強化学習の訓練、といったことが含まれていました。
219 00:12:06.025 --> 00:12:08.045 そして一般的には、これはいわば主要な、ええと、
220 00:12:08.045 --> 00:12:10.005 秘密のソース的な要素のようなものだと
221 00:12:10.005 --> 00:12:14.125 考えられていると思います。ええと、また
222 00:12:14.125 --> 00:12:16.285 ウェブブラウジングとデータ分析向けに最適化されています。
223 00:12:17.985 --> 00:12:22.565 そして、ええと、あの、3つ目のテーマについてですが、これは、ええと、
224 00:12:22.695 --> 00:12:25.605 反復検索と重なっているもので、ええと、推論です。
225 00:12:26.305 --> 00:12:28.685 つまり、今後登場する
226 00:12:29.275 --> 00:12:31.005 OpenAI o3推論モデルでファインチューニングされています。
227 00:12:31.505 --> 00:12:33.845 ええと、そして推論を活用して、大量の、ええと、テキストを
228 00:12:33.905 --> 00:12:37.645 検索し、解釈し、分析します。
229 00:12:39.025 --> 00:12:41.445 ですから、私たちはこの、ええと、あの、
230 00:12:41.445 --> 00:12:44.565 この、ええと、あの、ブログ記事のリリースから
231 00:12:44.915 --> 00:12:47.365 それがどのように機能するのかを、ある程度つなぎ合わせて、
232 00:12:47.945 --> 00:12:49.805 それを、たとえば、
233 00:12:49.805 --> 00:12:51.765 生成AIで起きている最新の発展と関連づけ、
234 00:12:52.305 --> 00:12:53.845 そして、ええと、試みとして、
235 00:12:53.845 --> 00:12:58.045 自分たちのシステムを構築することで
236 00:12:58.505 --> 00:12:59.605 結果を再現しようとできます。
237 00:13:05.195 --> 00:13:06.575 そして、ええと、それこそが私たちがやったことです。
238 00:13:06.575 --> 00:13:10.295 それで、ええと、私たちはそのリリースにとても興奮しました。ええと、その、
239 00:13:10.955 --> 00:13:15.335 ええと、つまり、出力の定性的な、ええと、
240 00:13:16.115 --> 00:13:17.975 ええと、品質を見たからです。
241 00:13:18.755 --> 00:13:23.135 それで私たちは本当に興味を持ちました。ええと、つまり、
242 00:13:23.175 --> 00:13:26.215 ベクトルデータベース企業として、ベクトルデータベースは
243 00:13:26.375 --> 00:13:29.375 エージェントを支える、ええと、コアコンポーネントの一つです。
244 00:13:30.035 --> 00:13:31.335 ええと、私たちは本当に興味がありました。つまり、
245 00:13:31.335 --> 00:13:35.975 同様に機能するような、ええと、
246 00:13:35.975 --> 00:13:37.015 自分たちのオープンソース版を構築できるだろうか、と。
247 00:13:37.675 --> 00:13:39.375 そして、ええと、それを私たちは約1か月前に行いました。
248 00:13:39.755 --> 00:13:42.575 ええと、何人かのエンジニアが、ええと、オープンソースの
249 00:13:43.335 --> 00:13:44.935 Deep Searcherというソフトウェアを構築しました。
250 00:13:47.965 --> 00:13:50.705 そして、つまり、deep researchのように、クエリを与えると、
251 00:13:51.325 --> 00:13:55.265 その後、ええと、複数のソースを検索して、ええと、
252 00:13:55.295 --> 00:13:58.745 ある種反復するように、ええと、つまり、ええと、
253 00:13:58.765 --> 00:14:01.705 質問を、ええと、反復可能なステップに分解し、
254 00:14:02.175 --> 00:14:06.185 最終的に、いつ、ええと、いつ止めるかを判断します、
255 00:14:06.525 --> 00:14:07.825 ええと、質問への回答を。
256 00:14:08.765 --> 00:14:11.305 そして、ええと、それからそのすべての情報から、詳細な
257 00:14:11.525 --> 00:14:12.865 レポートのようなものを統合します。
258 00:14:16.535 --> 00:14:19.595 そして、ええと、ですので、この、ええと、ああ、このリサーチエージェントは、
259 00:14:20.105 --> 00:14:24.435 Vectorデータベースの上に構築されています、ええと、vis、ああ、
260 00:14:24.485 --> 00:14:27.515 これは、ええと、つまり、zitsが、私たちが主要なコントリビューターです。
261 00:14:28.095 --> 00:14:31.195 ああ、これはLinux Foundation for AI
262 00:14:31.295 --> 00:14:34.675 and dataに寄贈されています、ええと、ああ、以来、ええと、ああ、
263 00:14:35.005 --> 00:14:36.395 たしか、ああ、2020年からです。
264 00:14:37.135 --> 00:14:39.635 ですので、ああ、Deep searcherのコードに入る前に
265 00:14:39.635 --> 00:14:43.595 VISについて少しだけお話しします。
266 00:14:44.735 --> 00:14:49.275 それで、ええと、VISは完全にオープンソースで、ええと、Apacheの
267 00:14:49.535 --> 00:14:52.125 ええと、ライブラリなので、商用利用にも適しており、
268 00:14:53.105 --> 00:14:54.925 そして、ええと、とても使いやすいです。
269 00:14:55.225 --> 00:14:58.605 ノートブック上で、lightバージョンを
270 00:14:58.625 --> 00:15:03.205 pip installできます、ええと、もっと、ええと、ああ、
271 00:15:03.445 --> 00:15:05.165 スケーラブルなバージョンは、
272 00:15:05.165 --> 00:15:06.405 docketイメージで本当に簡単に起動できます。
273 00:15:07.625 --> 00:15:12.325 そして、ええと、それから3つ目のバージョンのようなものがあり、
274 00:15:12.415 --> 00:15:15.325 それが、完全分散バージョンのmils clusterです
275 00:15:16.475 --> 00:15:19.605 それは、ええと、ああ、ご存じのように、Kubernetes経由で
276 00:15:19.605 --> 00:15:20.885 マシンのクラスター上に起動し、
277 00:15:21.385 --> 00:15:25.125 文字通り、ええと、ああ、数十から
278 00:15:25.125 --> 00:15:27.085 数百civiliansのベクトルまでスケールできます。
279 00:15:31.985 --> 00:15:36.925 ですので、ええと、セットアップが簡単で、ええと、本当に優れた統合が
280 00:15:37.715 --> 00:15:41.205 生成AIツールのエコシステムにあります。
281 00:15:42.905 --> 00:15:46.725 オープンソースなので、ああ、私たちは多くの、ああ、
282 00:15:47.045 --> 00:15:50.205 コントリビューションを受けています、つまり、ほとんどすべての、ええと、
283 00:15:50.205 --> 00:15:53.085 生成AIの大きなツールからです。
284 00:15:53.905 --> 00:15:57.685 たとえばhugging face open ai、l chain、Gina、
285 00:15:58.185 --> 00:16:02.765 ええと、air byte、ええと、あります、ええと、言うなら、ああ、つまり、
286 00:16:03.225 --> 00:16:05.325 こうした統合が何十も何十もあるので、
287 00:16:05.425 --> 00:16:09.485 おそらく既存の
288 00:16:09.705 --> 00:16:10.965 ああ、ツールセットの中で使えるでしょう。
289 00:16:14.025 --> 00:16:17.085 そして、私は思うのですが、ええと、強い、ある種の、ええと、たぶん
290 00:16:17.085 --> 00:16:21.205 ある種の、ああ、その性能
291 00:16:21.425 --> 00:16:24.605 と信頼性に対する推薦となるのは、
292 00:16:24.625 --> 00:16:25.765 本当に大きな企業の多くに使われているという事実です。
293 00:16:26.345 --> 00:16:30.645 nvidia、Microsoft、ええと、Salesforceから、
294 00:16:31.785 --> 00:16:33.125 ああ、Ikeaなどまでです。
295 00:16:37.145 --> 00:16:41.485 それで、ええと、ああ、ごく簡単に触れると、ええと、
296 00:16:41.605 --> 00:16:45.805 ベクトルデータベースの大きな用途の一つは、ああ、
297 00:16:45.985 --> 00:16:49.845 retrieval augmented generationであり、また、ああ、
298 00:16:49.845 --> 00:16:51.805 現在私たちがエージェントと呼んでいるものです。これは、
299 00:16:51.805 --> 00:16:53.365 このフレームワークへの拡張のようなものです。
300 00:16:54.065 --> 00:16:55.925 それで、ええと、つまり、明確にしておくと、
301 00:16:55.925 --> 00:16:57.045 ベクトルデータベースがどこに入るのかというと、
302 00:16:57.935 --> 00:17:01.025 ここにRAGパイプラインの概略図があります。
303 00:17:02.045 --> 00:17:04.825 まず、検索対象にしたいもののナレッジベースから
304 00:17:04.825 --> 00:17:05.865 始めます。
305 00:17:06.245 --> 00:17:09.545 あ、それで、ちなみに、ええと、私たちの、まあ、
306 00:17:09.785 --> 00:17:13.905 リサーチエージェントのパイプラインは、ええと、
307 00:17:14.065 --> 00:17:15.385 基本的なRAGパイプラインの拡張のようなものになります。
308 00:17:16.605 --> 00:17:18.985 ええと、検索したいナレッジベースがあります。
309 00:17:19.085 --> 00:17:21.425 これは、たとえば社内文書のようなものかもしれません。
310 00:17:22.205 --> 00:17:25.865 あるいは、ええと、顧客からの画像や、
311 00:17:25.965 --> 00:17:27.585 人々がアップロードした動画のようなものかもしれません。
312 00:17:29.005 --> 00:17:32.185 次にそれを埋め込みディープネットワークに通して、
313 00:17:32.765 --> 00:17:34.465 これらのベクトル埋め込みを生成し、
314 00:17:34.925 --> 00:17:37.825 それを、ええと、visに保存します。
315 00:17:38.945 --> 00:17:43.005 それで、Milsは、ええと、とても便利で、
316 00:17:43.145 --> 00:17:47.085 効率的なインターフェースを提供し、類似性検索、
317 00:17:47.625 --> 00:17:50.605 または、ええと、本質的にはセマンティック検索を実行できます。
318 00:17:51.265 --> 00:17:52.685 つまり、RAGチャットボットでは、
319 00:17:52.705 --> 00:17:54.605 ユーザーが質問を持ってやって来ます。
320 00:17:56.145 --> 00:17:58.685 ええと、その質問は
321 00:17:58.685 --> 00:18:00.405 通常、同じ埋め込みモデルに通され、
322 00:18:01.345 --> 00:18:04.885 そして私たちはクエリベクトルに似たベクトルを
323 00:18:05.625 --> 00:18:06.965 ベクトルデータベース内で検索し、
324 00:18:07.705 --> 00:18:11.685 ナレッジベース内の項目に対応する
325 00:18:11.685 --> 00:18:13.285 近いベクトルを取得します。
326 00:18:14.265 --> 00:18:16.205 そして、これらのモデルの仕組みによって、
327 00:18:16.775 --> 00:18:19.845 それらは私たちのクエリと意味的に類似したものになります。
328 00:18:20.545 --> 00:18:24.045 つまり言い換えると、それらには回答されるクエリに
329 00:18:24.665 --> 00:18:26.805 関連する情報が含まれているということです。
330 00:18:27.825 --> 00:18:29.605 ですから、RAGの考え方はとても単純です。
331 00:18:30.265 --> 00:18:34.525 それらを、私たちが
332 00:18:34.555 --> 00:18:37.405 大規模言語モデルに実行させるプロンプトのコンテキストに入れます。
333 00:18:37.425 --> 00:18:38.885 あるいは、大規模言語ビジョンモデル、
334 00:18:38.945 --> 00:18:40.725 または使用している任意の基盤モデルですね。
335 00:18:41.625 --> 00:18:45.565 つまり、ユーザーの質問を
336 00:18:46.095 --> 00:18:49.325 ベクトルデータベースから取得したこれらの文書で拡張し、
337 00:18:50.305 --> 00:18:51.725 大規模言語モデルに入れます。
338 00:18:52.425 --> 00:18:55.485 そして、大規模言語モデルにはそのコンテキストがあるので、
339 00:18:56.355 --> 00:18:59.885 はるかに、ええと、信頼性が高く、
340 00:19:00.345 --> 00:19:01.445 ええと、最新の回答を出せます。
341 00:19:02.105 --> 00:19:03.925 ですから、それは、たとえば、
342 00:19:04.275 --> 00:19:08.225 あなたのRAGやエージェントのための、
343 00:19:08.225 --> 00:19:09.745 外部メモリのようなものだと考えられます。
344 00:19:10.605 --> 00:19:13.545 つまり、新しい事実や新しいデータが入ってくるたびに
345 00:19:13.605 --> 00:19:15.905 更新できる外部メモリであり、
346 00:19:16.725 --> 00:19:19.585 あなたの、ええと、
347 00:19:20.015 --> 00:19:22.105 基盤モデルや大規模言語モデルを再学習する必要はありません。
348 00:19:24.935 --> 00:19:26.875 ここに2つ、ええと、リンクがあります。
349 00:19:27.415 --> 00:19:30.595 ええと、これらは、もしあなたが
350 00:19:30.595 --> 00:19:32.275 ええと、VISを始めること
351 00:19:32.335 --> 00:19:36.795 あるいは単に、ええと、生成AIアプリケーションを構築すること
352 00:19:36.795 --> 00:19:38.115 一般的なベクトルデータベースの。
353 00:19:39.055 --> 00:19:42.315 それで、右側には、melvicへのGitHubを載せています。
354 00:19:42.335 --> 00:19:44.995 なので、ダウンロード手順や、ドキュメントへのリンク、
355 00:19:44.995 --> 00:19:49.115 本当に役立つ、ええと、チュートリアルがたくさんあります。
356 00:19:50.055 --> 00:19:51.795 ええと、そして右側には、
357 00:19:51.865 --> 00:19:55.075 私たちの生成AI学習、ええと、ポータルがあります。
358 00:19:55.405 --> 00:19:59.275 そこには本当に役立つ、ええと、ノートブックがたくさんあり、
359 00:19:59.945 --> 00:20:02.395 その、ええと、ある種、ええと、皆さんを
360 00:20:02.395 --> 00:20:03.795 よりずっと
361 00:20:04.265 --> 00:20:06.035 本格的な、ええと、アプリケーションを構築する手順へと導いてくれます。
362 00:20:06.735 --> 00:20:10.595 なので、構築方法を学ぶための本当に良い、リソースです。ええと、
363 00:20:10.895 --> 00:20:14.195 その、RAGエージェント、推薦システム、
364 00:20:14.395 --> 00:20:16.275 セマンティック検索などです。
365 00:20:18.305 --> 00:20:21.205 ええと、ではここでdeep searcherのコードウォークスルーに移り、
366 00:20:21.305 --> 00:20:25.445 実際にどのように、ええと、
367 00:20:25.745 --> 00:20:29.885 この、ええと、このリサーチエージェントを構築したのか見ていきましょう。
368 00:20:30.785 --> 00:20:32.525 そして、実際にコードに入る前に
369 00:20:32.915 --> 00:20:36.845 それが何を、ええと、何を
370 00:20:36.845 --> 00:20:39.565 実際にしているのかについて、メンタルモデルを持っておくと役立つと思います。ええと、そうすればある種、
371 00:20:39.585 --> 00:20:42.285 ええと、その、何を、ええと、つまり、ある種
372 00:20:42.285 --> 00:20:43.685 コードを見ていく間もそれを念頭に置いておけるので、
373 00:20:43.685 --> 00:20:45.085 理解しやすくなります。
374 00:20:46.185 --> 00:20:49.885 ええと、ですので、ええと、RAGシステムと同様に、
375 00:20:50.475 --> 00:20:53.445 このリサーチエージェントには2つの別々の部分があります。
376 00:20:53.505 --> 00:20:57.445 1つ目は、ええと、データ取り込みで、これは、ええと、
377 00:20:58.465 --> 00:21:00.845 ええと、私たちの場合は、ええと、事前に行われます。
378 00:21:01.625 --> 00:21:05.165 つまり、検索対象にしたい内部ドキュメント、クロールしたWebページ、
379 00:21:05.485 --> 00:21:09.245 構造化データ、ええと、ストリーミングデータ、ええと、理論上はそれらを、
380 00:21:09.245 --> 00:21:10.525 検索したいものとして指定します。
381 00:21:11.145 --> 00:21:13.005 そしてそれが保存され、埋め込み化され、
382 00:21:13.145 --> 00:21:15.485 ベクトルデータベースであるvuに保存されます。
383 00:21:16.025 --> 00:21:18.565 ええと、なので、将来のバージョンでは、ええと、
384 00:21:18.665 --> 00:21:21.085 あるいは追加中の機能だと思いますが、これはある種
385 00:21:21.085 --> 00:21:25.125 必要に応じてWebを検索する、より動的な、ええと、検索です。
386 00:21:26.805 --> 00:21:29.185 ええと、そしてもう一方の部分、
387 00:21:29.285 --> 00:21:31.185 主要な部分がこのオンラインサービングです。
388 00:21:32.005 --> 00:21:34.865 ユーザーがクエリを持って入ってきます。
389 00:21:36.255 --> 00:21:40.105 次に、大規模言語モデルを使います。ええと、私たちの場合は、ええと、
390 00:21:40.225 --> 00:21:43.305 推論モデルを使って、質問を
391 00:21:43.935 --> 00:21:46.585 いくつかの、ええと、サブ質問
392 00:21:46.605 --> 00:21:51.055 またはサブクエリに分解します。ええと、それから、ええと、ええと、
393 00:21:51.615 --> 00:21:54.775 ルーターが、どの、ええと、どの種類の
394 00:21:54.775 --> 00:21:58.695 データストアから関連するエントリを取得するかを判断します。ええと、
395 00:21:58.695 --> 00:22:00.535 そしてそれをベクトルデータベースから行います。
396 00:22:01.955 --> 00:22:03.615 ええと、そしてこれはある種、ええと、
397 00:22:03.765 --> 00:22:05.695 これを、ええと、その、
398 00:22:05.695 --> 00:22:08.295 単なる普通のRAGではなくエージェントと呼べるものにしていると思います。
399 00:22:09.035 --> 00:22:11.095 このリフレクションステップがあるということです
400 00:22:11.605 --> 00:22:14.135 次に何をするかを決めます。
401 00:22:15.075 --> 00:22:17.055 それでLLMは、ええと、
402 00:22:17.075 --> 00:22:19.415 あるいは、その、そのプロンプトが質問に答えるよう求めます、
403 00:22:20.515 --> 00:22:24.655 その、ええと、その、その、その質問にギャップはあるか
404 00:22:25.005 --> 00:22:27.055 これまでに、ええと、尋ねられ
405 00:22:27.075 --> 00:22:31.135 そして回答されたもので、その、ええと、情報を使って
406 00:22:31.365 --> 00:22:33.255 その、ええと、データ取り込みからのものですか？
407 00:22:34.075 --> 00:22:38.695 そして、もしそれが、ええと、はい、まだギャップがあります、
408 00:22:39.035 --> 00:22:40.815 ええと、回答すべき知識ギャップがある、と言えば、
409 00:22:41.565 --> 00:22:44.175 それは新しいクエリを生成します。
410 00:22:45.365 --> 00:22:47.105 ええと、それから同じプロセスをたどるだけで
411 00:22:47.325 --> 00:22:51.305 ある意味、満足するまでこれをループし続けます、ええと、
412 00:22:51.335 --> 00:22:54.905 反復やトークンの、ええと、まあ、まあ予算を使い果たしたか
413 00:22:54.965 --> 00:22:58.665 あるいは、より可能性が高いのは
414 00:22:58.805 --> 00:23:02.545 その前に、答える必要があると考える、その、質問をすべて
415 00:23:02.895 --> 00:23:06.625 使い果たしたときです、ええと、その、クエリをある意味カバーし、
416 00:23:06.625 --> 00:23:09.265 知識ギャップがないようにするために答える必要があるものです。
417 00:23:10.765 --> 00:23:14.825 なので、ええと、これが、ええと、これをエージェントと呼べる理由です
418 00:23:15.365 --> 00:23:18.225 単なる、ええと、普通のragのようなものではなく
419 00:23:18.925 --> 00:23:23.865 LLMが、ええと、その、
420 00:23:24.125 --> 00:23:25.145 ええと、実行をルーティングするために使われているからです。
421 00:23:27.065 --> 00:23:30.605 ええと、そして、ええと、これをこう考えることもできます、ええと、
422 00:23:30.635 --> 00:23:34.005 動的に生成されたクエリに対して、こう
423 00:23:34.635 --> 00:23:36.085 ベクターデータベースを呼び出すことです。
424 00:23:36.085 --> 00:23:38.685 それは、ある意味、こう、ツール使用の一形態
425 00:23:38.685 --> 00:23:40.605 としても考えられます。
426 00:23:41.785 --> 00:23:45.725 つまり、私たちには、この、こうした、ええと、条件付き実行があります。
427 00:23:46.575 --> 00:23:49.365 ツール使用もあります、ええと、この2つは
428 00:23:49.365 --> 00:23:52.245 ある意味、ええと、エージェントであることの定義的特徴です。
429 00:23:53.985 --> 00:23:57.885 ええと、それでその後、それが、はい、
430 00:23:58.415 --> 00:24:02.115 知識ギャップはありません、と言うと、次に進みます
431 00:24:02.115 --> 00:24:04.195 最後のステップへです。それは
432 00:24:04.395 --> 00:24:06.875 大規模言語モデルを使って、
433 00:24:07.015 --> 00:24:10.275 サブ質問からのそれらの回答を結合し
434 00:24:10.905 --> 00:24:14.115 単一の一貫した、ええと、最終レポートにすることです。
435 00:24:15.775 --> 00:24:17.195 なので、ええと、
436 00:24:18.335 --> 00:24:23.285 そして、ええと、ええと、一つ言っておくべきことは、つまり私たちは、ええと、
437 00:24:23.285 --> 00:24:28.165 私たちは、ええと、ええと、通常は、こう、
438 00:24:28.485 --> 00:24:32.605 これらのステップのために、ええと、推論LLMを使っています、
439 00:24:33.305 --> 00:24:35.485 ええと、それについてはもう少し詳しく説明します、ええと、
440 00:24:36.065 --> 00:24:38.205 ええと、数枚後のスライドで。
441 00:24:38.665 --> 00:24:41.885 ええと、ただそれは、ある意味、本当に役に立つものです
442 00:24:41.885 --> 00:24:43.685 これのパフォーマンスを向上させるうえで、
443 00:24:44.065 --> 00:24:45.245 ええと、このリフレクションステップです。
444 00:24:47.375 --> 00:24:50.065 はい。では、そのGitHubに移って
445 00:24:50.165 --> 00:24:51.985 実際に少しコードを見てみましょう。
446 00:24:55.025 --> 00:24:57.165 ちなみに、ええと、遠慮しないでください。
447 00:24:57.165 --> 00:24:59.965 何か質問があれば、ええと、どうぞ
448 00:24:59.965 --> 00:25:01.925 チャットに書いてください。そうしたら、私は、私は止まって
449 00:25:01.925 --> 00:25:03.205 出てきた順に答えます。
450 00:25:04.545 --> 00:25:08.085 これは、deep searcher の GitHub リポジトリです。
451 00:25:09.465 --> 00:25:12.085 そして、ええと、そこにアーキテクチャ図が見えます。
452 00:25:14.205 --> 00:25:16.945 ええと、それで、ええと、これはまあ、
453 00:25:16.945 --> 00:25:19.465 出力からのスクリーンショットのようなものです。
454 00:25:19.685 --> 00:25:20.985 何かを出力しているように見えます。
455 00:25:21.805 --> 00:25:23.465 ええと、それで、はい、
456 00:25:23.465 --> 00:25:26.465 中間ステップを出力しているような感じで、ええと、
457 00:25:26.465 --> 00:25:29.025 サブクエリに分解する反復処理
458 00:25:29.025 --> 00:25:30.705 と、それらに答えること、ええと、
459 00:25:30.845 --> 00:25:32.465 「accelerated playback」と表示されているのが見えます。
460 00:25:32.465 --> 00:25:35.265 ですから、それは現在のリサーチエージェントにおける、ええと、
461 00:25:35.325 --> 00:25:39.585 課題の一つのようなものだと思います。ええと、
462 00:25:39.585 --> 00:25:43.145 基盤モデルの推論という点で、非常にコストが高いのです。ええと、
463 00:25:43.715 --> 00:25:45.105 基盤モデル推論です。
464 00:25:46.285 --> 00:25:49.465 それで、ええと、後でお見せする例では、
465 00:25:49.985 --> 00:25:53.905 推論型の大規模言語モデルに対して、
466 00:25:53.905 --> 00:25:56.105 たしか75回くらいクエリを投げたと思います。
467 00:25:56.885 --> 00:26:00.345 そして、ええと、つまり、それが10分、
468 00:26:00.375 --> 00:26:04.225 30分、あるいは実際にすべての推論ステップを
469 00:26:04.225 --> 00:26:05.305 実行し終えるのにそれ以上かかる理由です。
470 00:26:06.685 --> 00:26:08.545 ええと、実際、オンラインサービスで
471 00:26:08.545 --> 00:26:11.185 それをやっていたときに、ええと、レート制限に引っかかりました。
472 00:26:11.365 --> 00:26:15.985 なので、ええと、10回クエリを実行して、1分待って、
473 00:26:16.605 --> 00:26:17.665 また10回クエリを実行する、という感じでした。
474 00:26:18.285 --> 00:26:22.945 ええと、ですから、ええと、重要な点は、ええと、
475 00:26:23.015 --> 00:26:25.145 推論が本当に重要なボトルネックだということだと思います。
476 00:26:26.855 --> 00:26:31.345 では、Anna Ruda さんから質問が来ています。それは、
477 00:26:31.645 --> 00:26:36.345 LM は、知識ギャップがないと言えるほど十分な
478 00:26:36.345 --> 00:26:38.625 知識を得たことを、どのようにして知るのか、というものです。
479 00:26:39.615 --> 00:26:40.785 はい、とても良い質問です。
480 00:26:41.445 --> 00:26:43.790 ええと、これは、これはつまり、
481 00:26:43.790 --> 00:26:46.045 ええと、いわば LLM の
482 00:26:46.045 --> 00:26:48.165 魔法のような創発的特性に行き着くと思います。
483 00:26:48.545 --> 00:26:52.965 ええと、これらのモデルは、ええと、特に
484 00:26:52.985 --> 00:26:55.485 推論、つまり多段階推論タスクで訓練されています。
485 00:26:56.385 --> 00:27:01.325 そして、ええと、ええと、なので、はい、
486 00:27:01.605 --> 00:27:05.945 つまり、それは、ええと、まさにその、ええと、
487 00:27:06.325 --> 00:27:08.265 OM ができることの一つで、
488 00:27:08.855 --> 00:27:10.465 非常に大量のデータで訓練されており、
489 00:27:10.645 --> 00:27:14.105 ポストトレーニングにおいて、ある種関連するタスクも
490 00:27:14.615 --> 00:27:16.665 扱っているので、このタスクも実行できるように見えるのです。
491 00:27:19.245 --> 00:27:21.585 ええと、それでは推論モデルである必要があるのでしょうか？
492 00:27:21.805 --> 00:27:24.505 ええと、つまり、いいえ、推論モデルである必要はありません。
493 00:27:25.105 --> 00:27:28.545 実際には、他のステップの一部には、
494 00:27:28.545 --> 00:27:31.185 より安価なモデルを使う方が有利だと思います。
495 00:27:31.605 --> 00:27:34.065 ですから、あなたが言及したように、サブタスクに分解すること、ええと、
496 00:27:34.225 --> 00:27:37.105 クエリをサブクエリに分解することについては、ええと、
497 00:27:37.105 --> 00:27:41.505 それは、はるかに小さな、ええと、ええと、
498 00:27:41.535 --> 00:27:44.465 まあ、つまり、単に、より一般的なチャットボットLMのようなものでも、
499 00:27:44.465 --> 00:27:46.305 ええと、
500 00:27:46.325 --> 00:27:51.185 でも理想的には、その目的のために、ええと、
501 00:27:51.565 --> 00:27:53.745 ファインチューニングされた、ずっと小さな言語モデルです。
502 00:27:55.005 --> 00:27:58.225 なので、ええと、それはある意味、私が思うに、
503 00:27:58.895 --> 00:28:01.425 これらのモデルの推論を高速化するために到達できる、
504 00:28:01.425 --> 00:28:04.225 簡単な解決策の一つで、ええと、
505 00:28:04.225 --> 00:28:07.025 各ステップに小さな特化型モデルを使うことです。
506 00:28:08.965 --> 00:28:13.545 とても良い質問です。さて、では、ええと、
507 00:28:14.765 --> 00:28:16.625 では、ええと、コードを見ていきましょう。
508 00:28:16.645 --> 00:28:20.425 もしこれを自宅で試したい場合は、ええと、
509 00:28:20.525 --> 00:28:23.945 このリポジトリをgit cloneして、ええと、
510 00:28:23.945 --> 00:28:27.705 依存関係をインストールしてから、ええと、コピー＆ペーストできます。
511 00:28:27.805 --> 00:28:32.545 ええと、ここに、ええと、
512 00:28:32.685 --> 00:28:35.385 deep research agentへの呼び出しを実際に開始する方法の例があります。
513 00:28:35.545 --> 00:28:36.545 そのdeep research agentへの。
514 00:28:37.565 --> 00:28:41.145 ここでは、デフォルト設定を作成しているのがわかります。
515 00:28:42.415 --> 00:28:44.905 それからいくつか入れて、いくつかのオプションを上書きします。
516 00:28:45.605 --> 00:28:49.105 つまり、ええと、そのresearch agentに伝えます。
517 00:28:49.105 --> 00:28:51.385 大規模言語推論サービスとして、
518 00:28:51.925 --> 00:28:54.065 OpenAIを使いたいと、
519 00:28:54.445 --> 00:28:58.705 具体的にはGPT-4 oh、ええと、ええと、miniを使いたいと。
520 00:28:59.725 --> 00:29:02.065 ええと、そして、ええと、embedding modelについては、
521 00:29:02.315 --> 00:29:04.865 こちらもOpenAIのembedding serviceを使います。
522 00:29:05.925 --> 00:29:08.745 ただし、ええと、deep searcherは多数の
523 00:29:08.745 --> 00:29:12.665 異なる、ええと、推論およびembedding servicesをサポートしています。
524 00:29:13.485 --> 00:29:15.025 たとえば、
525 00:29:15.025 --> 00:29:17.305 embeddingにはHugging FaceのSentence Transformersを
526 00:29:17.305 --> 00:29:18.945 ローカルで使いたいかもしれません。
527 00:29:19.645 --> 00:29:22.025 ええと、あるいは私の場合は、
528 00:29:22.025 --> 00:29:24.265 大規模言語モデルとして、ええと、
529 00:29:24.295 --> 00:29:26.905 DeepSeek R1の蒸留版のようなものを使いたいかもしれません。
530 00:29:28.455 --> 00:29:33.385 はい。では次に、ええと、検索対象にしたい
531 00:29:33.385 --> 00:29:35.265 データを取り込みます。
532 00:29:36.085 --> 00:29:38.545 この場合、ええと、そのデータを
533 00:29:38.975 --> 00:29:40.905 事前に指定しています、ええと、
534 00:29:40.945 --> 00:29:43.685 でもこれを開発していくにつれて、それは
535 00:29:44.625 --> 00:29:47.405 自律的に出かけて、ええと、関連するソースを見つけられるようになります。
536 00:29:48.385 --> 00:29:50.245 そしてここで、この、ええと、
537 00:29:50.245 --> 00:29:51.445 このquery関数を呼び出すだけです。
538 00:29:52.625 --> 00:29:56.005 ええと、なので、私がコードの動作を理解するために
539 00:29:56.005 --> 00:30:00.805 やりたい方法の一つは、文字どおり順にたどることです、ええと、
540 00:30:00.835 --> 00:30:02.125 関数を順にたどることです。
541 00:30:02.265 --> 00:30:05.725 なので、ええと、ええと、つまり、その、私は、
542 00:30:06.085 --> 00:30:08.245 これをドキュメントに入れて、実行しました。
543 00:30:08.785 --> 00:30:11.525 ええと、残念ながらライブデモはできません。
544 00:30:11.525 --> 00:30:16.205 なぜなら、ええと、レポートを返すのに、
545 00:30:16.385 --> 00:30:18.445 たとえば10分以上かかるからです。
546 00:30:19.505 --> 00:30:22.205 ええと、でもそれをやったと想像してください。そうすれば動くことはわかります。
547 00:30:22.205 --> 00:30:24.925 それで、よし、実際に、ええと、続きをやってみましょう、と言えます。
548 00:30:24.925 --> 00:30:26.325 ステップ実行デバッグのように
549 00:30:26.825 --> 00:30:28.925 これらの各関数の中を見て
550 00:30:28.925 --> 00:30:31.325 実際にどうやってその処理をしているのかを解明します。
551 00:30:32.065 --> 00:30:36.805 ここには online query からの query がありますね、はい、
552 00:30:36.985 --> 00:30:39.845 それで、ええと、私は VS code を使っているので、
553 00:30:39.845 --> 00:30:41.365 定義へジャンプするようなことができます。
554 00:30:42.545 --> 00:30:46.005 すると、これが、ええと、
555 00:30:46.195 --> 00:30:49.125 この configuration dot default searcher を呼び出していて、
556 00:30:50.465 --> 00:30:53.165 その上で default searcher query を呼び出しているのがわかります。
557 00:30:54.915 --> 00:30:57.425 では default search とは何でしょうか？
558 00:30:57.615 --> 00:30:59.585 まあ、configuration に移動して
559 00:30:59.605 --> 00:31:02.265 そこでそれを何に設定しているのかを見てみる必要があります。
560 00:31:03.805 --> 00:31:05.105 あ、それで先に進む前に、
561 00:31:05.105 --> 00:31:08.655 もう一つ質問が来ています、ええと、
562 00:31:15.155 --> 00:31:16.515 いや、すみません、たぶんもう答えましたね。
563 00:31:16.515 --> 00:31:19.635 これは、ええと、Anna からの、どうやって
564 00:31:19.635 --> 00:31:20.795 knowledge gaps があるとわかるのか、という質問です。
565 00:31:22.575 --> 00:31:27.555 ええと、はい、それは、さっき言ったように、ええと、その、
566 00:31:27.555 --> 00:31:31.355 ええと、これらの foundation models は、ええと、特に
567 00:31:31.355 --> 00:31:33.035 chat や reasoning evaluation のような
568 00:31:33.055 --> 00:31:36.795 さまざまなタスク向けに後段階で訓練された後では、
569 00:31:37.385 --> 00:31:41.315 未知のタスクに対して非常に大規模な transfer learning のようなものを持っています。
570 00:31:42.055 --> 00:31:46.435 それで、ええと、この
571 00:31:47.035 --> 00:31:48.075 identifying、ええと、
572 00:31:48.145 --> 00:31:50.315 knowledge gaps のタスクが、訓練のどこかに含まれていたのかは正確にはわかりません。
573 00:31:50.775 --> 00:31:53.275 ええと、でもそれは、ほら、scale と
574 00:31:53.335 --> 00:31:56.555 transfer learning の力によって、こうしたタスクができるということです。
575 00:31:58.465 --> 00:32:00.915 では、わかるのは、ええと、
576 00:32:00.985 --> 00:32:05.675 configuration が初期化されるときに、default searcher は、
577 00:32:05.905 --> 00:32:10.795 それは、ええと、この rag router option を作成していて、
578 00:32:12.395 --> 00:32:16.975 それから、ええと、ここに二つの agents があります。
579 00:32:18.255 --> 00:32:22.215 これはたぶん、ええと、ほら、ええと、ええと、
580 00:32:23.235 --> 00:32:25.975 ええと、どちらに route するかを判断するのだと思いますが、見てみましょう。
581 00:32:25.995 --> 00:32:28.135 それで、chain of rag は別の technique のようなものです。
582 00:32:28.755 --> 00:32:32.145 ええと、興味があれば、この
583 00:32:32.255 --> 00:32:35.065 これをもう少し詳しく説明している research paper を確認できます。
584 00:32:35.845 --> 00:32:40.005 ええと、でも私たちはここで、この deep search の
585 00:32:40.945 --> 00:32:43.285 ええと、ええと、object の中を見ていきます。
586 00:32:44.145 --> 00:32:47.645 そして、この object にはロジックが含まれていそうです。
587 00:32:48.305 --> 00:32:52.965 私たちの、失礼、この、ええと、
588 00:32:52.965 --> 00:32:55.325 research agent の、この architecture を実行するためのものです。
589 00:32:57.545 --> 00:33:00.005 では、今から deep search の中を見てみましょう。
590 00:33:02.105 --> 00:33:04.805 deep search、つまり、ええと、deep search を含む file に移動しました。
591 00:33:04.805 --> 00:33:06.885 これが、ええと、deep search を含む file です。
592 00:33:07.265 --> 00:33:09.045 ところで、これは実際、
593 00:33:09.065 --> 00:33:10.245 皆さんにとって十分大きいですか？
594 00:33:10.275 --> 00:33:12.565 ちょっと、ええと、font を少し大きくできるか見てみます。
595 00:33:14.895 --> 00:33:19.625 はい。ええと、では、ええと、これが
596 00:33:19.725 --> 00:33:22.065 この deep search、ええと、object の定義です。
597 00:33:23.415 --> 00:33:26.915 ええと、オブジェクトに保存するために、
598 00:33:27.255 --> 00:33:30.995 いくつかのパラメータを取るようになっています。
599 00:33:30.995 --> 00:33:34.795 つまり、base LLM を取り、embedding model を取り、
600 00:33:35.775 --> 00:33:39.195 vector db を取り、ええと、
601 00:33:40.195 --> 00:33:41.475 最大反復回数を取ります。
602 00:33:41.735 --> 00:33:44.835 つまりこれは、実行できるこれらの
603 00:33:44.835 --> 00:33:47.315 reflection cycles の回数に対する制限のようなものになります。
604 00:33:51.305 --> 00:33:55.615 ええと、それに加えて、他にもいくつか
605 00:33:55.815 --> 00:33:57.935 設定のようなものがあって、ええと、もう少し
606 00:33:57.935 --> 00:33:58.975 雑多なものです。
607 00:33:58.995 --> 00:34:02.415 なので、それらは飛ばします。ええと、では、
608 00:34:03.715 --> 00:34:05.095 実際にクエリを実行している
609 00:34:05.095 --> 00:34:06.615 オブジェクトが何かは分かりました。
610 00:34:07.235 --> 00:34:08.255 なので、ここに戻ります。
611 00:34:08.275 --> 00:34:13.105 ここで分かるように、このメソッドは、ええと、
612 00:34:13.175 --> 00:34:14.345 deep search dot query を呼び出します。
613 00:34:14.525 --> 00:34:15.865 では、それは何をするのでしょうか？
614 00:34:15.895 --> 00:34:17.705 では、コードを見に行きましょう。
615 00:34:22.655 --> 00:34:24.505 はい、ここにあります。
616 00:34:24.885 --> 00:34:26.705 そして、ええと、繰り返すと、
617 00:34:26.725 --> 00:34:29.705 私は実際にはこれを vs code の
618 00:34:29.705 --> 00:34:34.225 ステップ実行デバッガでやります。つまり、
619 00:34:34.345 --> 00:34:37.385 ステップ実行、ステップイン、ステップインをしながら、ええと、
620 00:34:37.805 --> 00:34:40.185 実行の経路を追っていくような感じです。
621 00:34:40.965 --> 00:34:43.105 そして、ええと、これは何が関連するコードなのかを
622 00:34:43.105 --> 00:34:47.345 理解するための、本当に良い方法です。つまり、
623 00:34:47.345 --> 00:34:50.665 ええと、何のコードが何をしているのか、
624 00:34:51.275 --> 00:34:53.025 何が起きているのかを理解するうえで
625 00:34:53.025 --> 00:34:54.385 最も関連するコードはどこか、ということです。
626 00:34:55.285 --> 00:34:59.545 ええと、それから、ええと、ええと、
627 00:35:00.165 --> 00:35:01.865 全員がこれに詳しいわけではありませんが、
628 00:35:01.865 --> 00:35:03.465 デバッグやコード理解に本当に
629 00:35:03.465 --> 00:35:08.265 役立つツールは、ええと、vs code や任意の IDE にある
630 00:35:08.265 --> 00:35:12.185 debug console だと思います。
631 00:35:12.765 --> 00:35:15.145 ステップ実行デバッグで実行を停止したとき、
632 00:35:15.145 --> 00:35:17.945 実際にその debug terminal に
633 00:35:18.615 --> 00:35:19.945 式を入力できます。
634 00:35:20.845 --> 00:35:23.025 たとえば、こう入力できます。
635 00:35:23.025 --> 00:35:24.545 この tensor の shape は何か？
636 00:35:25.335 --> 00:35:30.265 この flag の値は何か、ええと、
637 00:35:30.505 --> 00:35:31.745 ある条件は成り立つのか？
638 00:35:31.885 --> 00:35:33.065 そしてこれは、プログラムが実行中に
639 00:35:33.065 --> 00:35:35.985 何が起きているのかを理解するために、プログラムを
640 00:35:36.325 --> 00:35:37.685 調べる本当に便利な方法です。
641 00:35:39.025 --> 00:35:41.405 では、この query function を見てみましょう。
642 00:35:42.265 --> 00:35:44.925 まず最初に行うことは、
643 00:35:46.595 --> 00:35:47.805 self retrieve を呼び出すことだと分かります。
644 00:35:48.675 --> 00:35:51.965 いいですか？つまり、実際の agent がどこで起きているのか、
645 00:35:51.985 --> 00:35:56.765 ええと、その実行フローを
646 00:35:56.765 --> 00:35:58.285 少しずつ解きほぐしているところだと思います。
647 00:35:59.145 --> 00:36:00.525 ええと、少し近づいてきていると思います。
648 00:36:00.745 --> 00:36:02.845 では次に、self retrieve function を見てみましょう。
649 00:36:06.205 --> 00:36:07.065 それで、どこにあるのでしょうか？
650 00:36:11.015 --> 00:36:15.875 ああ、ありました。つまり self retrieve のその呼び出し、それが呼び出すのは、
651 00:36:16.255 --> 00:36:19.275 ええと、self dot asynchronous retrieve です。
652 00:36:20.095 --> 00:36:22.435 ええと、つまりここでは単に、
653 00:36:22.435 --> 00:36:24.675 間接参照の層をかき分けて、
654 00:36:24.675 --> 00:36:25.755 その核心部分にたどり着こうとしています。
655 00:36:27.335 --> 00:36:30.715 そして、ええと、これを呼び出して、これを実行します、ええと、
656 00:36:31.575 --> 00:36:33.555 ああ、この関数を非同期に実行します。
657 00:36:34.335 --> 00:36:36.635 ええと、そして今、実際に、
658 00:36:36.695 --> 00:36:39.315 その、ええと、research の、
659 00:36:39.655 --> 00:36:41.915 ええと、agent がどのように動くかの核心ロジックにたどり着いたようです。
660 00:36:43.215 --> 00:36:47.945 いいですか？ まず最初に、ええと、ただ、
661 00:36:48.895 --> 00:36:50.185 変数を設定します。
662 00:36:50.255 --> 00:36:52.425 これは最大反復回数を含むものです。
663 00:36:54.565 --> 00:36:59.425 そして、ええと、このコメントは、ええと、
664 00:37:00.365 --> 00:37:03.185 ええと、最初に行うことは、
665 00:37:03.715 --> 00:37:05.865 クエリをサブクエリに分解することだと示しています。
666 00:37:06.565 --> 00:37:08.265 大規模言語モデルにプロンプトを与えることで行います。
667 00:37:10.125 --> 00:37:13.425 つまり、これは役に立たないクエリから、
668 00:37:13.485 --> 00:37:15.985 最初の、ああ、サブクエリのセットへのジャンプのようなものです。
669 00:37:19.115 --> 00:37:22.015 そしてここに、generate subqueries の、ああ、メソッドがあります。
670 00:37:22.235 --> 00:37:26.375 ええと、ここまで来て、つまり、ええと、
671 00:37:26.525 --> 00:37:28.975 核心ロジックのようなところに到達したので、ええと、ここでは
672 00:37:28.975 --> 00:37:30.615 このループ全体を見終えるまでは、
673 00:37:30.615 --> 00:37:32.215 さらに下へジャンプすることはしません。そうすれば、
674 00:37:32.375 --> 00:37:36.855 正確にどんなプロンプトが、ええと、ああ、ああ、
675 00:37:37.045 --> 00:37:39.375 LLM に与えられているプロンプトが何なのか見られます。
676 00:37:39.835 --> 00:37:43.295 サブクエリの生成や、
677 00:37:43.475 --> 00:37:45.815 ええと、知識のギャップがどこにあるかを判断することなど、さまざまなタスクを行うためのものです。
678 00:37:47.365 --> 00:37:50.975 はい、では、ええと、ここに log color print があります。
679 00:37:50.975 --> 00:37:52.455 これは、このステップを実行しているときに
680 00:37:52.525 --> 00:37:53.815 ターミナルに表示されるものです。
681 00:37:55.155 --> 00:37:58.655 ええと、そして current subqueries のリストを取り、
682 00:37:58.655 --> 00:38:00.975 それらをそこに追加するだけです。
683 00:38:03.695 --> 00:38:05.075 そして今、ループがあります。
684 00:38:05.215 --> 00:38:08.635 つまり今、このメインの、ああ、ロジックループに入りました。
685 00:38:09.545 --> 00:38:11.915 このメインの、ええと、ああ、
686 00:38:12.175 --> 00:38:13.515 私のマウスポインタが見えているかわかりませんが、
687 00:38:13.535 --> 00:38:17.355 私は今、この内側のループのような部分をぐるっと囲っています。
688 00:38:17.355 --> 00:38:19.835 online serving の、ええと、領域にある、
689 00:38:20.135 --> 00:38:21.955 その、architect diagram の部分です。
690 00:38:24.175 --> 00:38:28.955 ええと、最初の、最初のステップは、ええと、
691 00:38:29.215 --> 00:38:32.395 つまり、ええと、ああ、検索することです。
692 00:38:32.415 --> 00:38:34.875 vector database から関連する chunks を検索します。
693 00:38:35.535 --> 00:38:40.405 query と、ええと、その、その、その subqueries が与えられた状態でです。
694 00:38:41.585 --> 00:38:45.085 つまり、これは実際には、ええと、いくつかの、何というか、
695 00:38:45.085 --> 00:38:46.125 asynchronous tasks を返します。
696 00:38:47.065 --> 00:38:52.045 なので、ええと、ああ、つまり、それがこのようなステップです。
697 00:38:52.585 --> 00:38:55.325 ここで、ええと、その、その vector database を呼び出す、
698 00:38:55.475 --> 00:38:57.405 それらの queries と subqueries を使って呼び出すステップです。
699 00:38:59.365 --> 00:39:02.305 ええと、つまり、それらは tasks を返すだけです、ええと、
700 00:39:02.305 --> 00:39:06.145 この await を呼び出すまでは実行されません。
701 00:39:06.685 --> 00:39:08.065 ええと、async io gather です。
702 00:39:08.765 --> 00:39:12.265 そしてそれが実際に、タスクを並列に実行し、
703 00:39:12.405 --> 00:39:15.905 その後、最後のものが完了するのを待ってから
704 00:39:16.485 --> 00:39:17.905 検索結果を設定します。
705 00:39:19.575 --> 00:39:22.185 いいですか？ それで、ええと、あの、
706 00:39:22.445 --> 00:39:24.585 サブクエリからこれらの結果を取得して
707 00:39:25.125 --> 00:39:26.145 それらをマージします。
708 00:39:26.685 --> 00:39:30.945 また、どれだけの消費トークンがあるかも追跡しています。ええと、
709 00:39:31.205 --> 00:39:34.145 なぜなら、まあ、後でこれのコストを
710 00:39:34.845 --> 00:39:37.905 計算できるようにしたいからです。
711 00:39:38.685 --> 00:39:40.905 ええと、また、たとえば、
712 00:39:41.495 --> 00:39:45.985 トークン予算のようなものにハードリミットを設定したい場合もあります。ええと、
713 00:39:46.195 --> 00:39:48.185 トークン予算、と言うべきですね。
714 00:39:49.965 --> 00:39:52.625 ええと、それから、ええと、
715 00:39:55.285 --> 00:39:58.135 はい、それで、ある意味、ええと、そうですね、それから、ええと、
716 00:39:58.155 --> 00:40:01.695 検索結果を取得し、ええと、それらをこの、
717 00:40:01.835 --> 00:40:03.575 ええと、Vector db からの検索結果のリストに入れます。
718 00:40:05.595 --> 00:40:10.455 そして、ええと、私たちは、ええと、あの、多くの場合、
719 00:40:11.875 --> 00:40:13.615 おそらく、ええと、
720 00:40:13.645 --> 00:40:16.455 ベクトルデータベースから重複したチャンクが返されると思います。
721 00:40:17.635 --> 00:40:21.575 ですから、ええと、良いステップは、それらの重複を排除して、
722 00:40:21.575 --> 00:40:23.535 一意のチャンクのリストを持つことです。
723 00:40:24.085 --> 00:40:26.455 ベクトルデータベースから取得された、ええと、
724 00:40:26.805 --> 00:40:28.415 それらのサブクエリからのものです。
725 00:40:31.435 --> 00:40:33.775 ええと、ここで、もし私たちが、
726 00:40:33.955 --> 00:40:36.215 最大反復回数に達していれば、break します。
727 00:40:37.755 --> 00:40:42.015 ええと、しかし次のステップは reflection を実行し、
728 00:40:42.555 --> 00:40:45.615 追加の、ええと、クエリを取得することです。それによって
729 00:40:46.145 --> 00:40:47.815 知識ギャップのようなものをカバーできます。
730 00:40:49.055 --> 00:40:52.635 それで、ここに戻ると、どこかがわかります。つまり、私たちは、
731 00:40:52.635 --> 00:40:56.195 このループを一通り進んできて、今この、ええと、
732 00:40:56.665 --> 00:40:59.035 この、ええと、黄色オレンジのひし形にいて、
733 00:40:59.995 --> 00:41:02.895 この、ええと、この reflection ステップを実行しています。
734 00:41:03.835 --> 00:41:05.495 ここで LLM
735 00:41:05.835 --> 00:41:07.775 または reasoning model が
736 00:41:07.775 --> 00:41:10.295 実際に実行を制御することになります。
737 00:41:14.655 --> 00:41:18.275 そして、ええと、それで、ええと、それから、ええと、単に実行します。
738 00:41:18.375 --> 00:41:21.115 つまり、ええと、reasoning model に別のプロンプトを与えて、
739 00:41:21.145 --> 00:41:25.155 ギャップクエリを生成させます。
740 00:41:26.855 --> 00:41:29.155 そして、ええと、これは生成します。つまり、もし、もしそれが、
741 00:41:29.175 --> 00:41:33.355 モデルが、追加で回答が必要なクエリがあると判断した場合、
742 00:41:33.355 --> 00:41:35.315 それは、ある意味、
743 00:41:35.315 --> 00:41:38.275 知識ギャップを埋めるためのもので、それらを
744 00:41:38.375 --> 00:41:40.355 sub、ええと、sub gapp queries に返します。
745 00:41:41.415 --> 00:41:45.595 ええと、ですので、もし、それが空であれば、私たちは
746 00:41:45.595 --> 00:41:46.835 そのループを終了できるとわかります。
747 00:41:48.695 --> 00:41:51.325 そして最終レポートの生成に進みます。
748 00:41:53.705 --> 00:41:58.165 ええと、しかしそうでなければ、それらの新しいサブサブクエリを
749 00:41:58.665 --> 00:41:59.685 サブクエリに追加するだけです。
750 00:41:59.685 --> 00:42:01.885 つまり、これはある意味、スタックのようなものです。
751 00:42:02.065 --> 00:42:03.285 ええと、答えるべきクエリです。
752 00:42:03.945 --> 00:42:05.565 それからそれらをそのリストに追加します
753 00:42:06.185 --> 00:42:09.485 そして、この、ええと、反復を繰り返します。
754 00:42:11.185 --> 00:42:14.005 つまり、ここでもう一つループを回すような感じです。
755 00:42:15.945 --> 00:42:18.285 ええと、つまり、ほら、本質的にはそれだけです。
756 00:42:18.345 --> 00:42:21.165 それで、ええと、ええと、時間があれば、ちょっと
757 00:42:21.165 --> 00:42:23.765 簡単にこれらの、これらの関数を見てみます
758 00:42:23.765 --> 00:42:25.005 実際にプロンプトを定義しているものです
759 00:42:25.585 --> 00:42:28.725 そして、ええと、ええと、まあ少しお待ちください。
760 00:42:28.845 --> 00:42:30.525 私は、私は、あと数分だけあります
761 00:42:30.585 --> 00:42:32.485 それから、ええと、結論を述べます
762 00:42:33.305 --> 00:42:35.005 そして最後に、ええと、5分、
763 00:42:35.025 --> 00:42:36.485 10分ほど質問の時間を残します。
764 00:42:37.185 --> 00:42:40.245 ええと、なので実際には、ええと、私が言うのは、これは、ええと、
765 00:42:40.245 --> 00:42:43.045 皆さん自身の、ええと、いわば個人的な、
766 00:42:43.545 --> 00:42:46.285 ええと、楽しみ、ええと、学習のために残しておきます。
767 00:42:46.305 --> 00:42:47.885 ですから実際にこれらの中を見て、
768 00:42:47.885 --> 00:42:50.605 これらのメソッドをとても簡単に確認できます、ええと、
769 00:42:50.945 --> 00:42:54.605 そして、例えば、これらのタスクを実行するために、実際にどのように、ええと、
770 00:42:54.605 --> 00:42:58.565 プロンプトを整形しているのか、
771 00:42:58.585 --> 00:42:59.685 そしてそれをうまく行うのかを見つけられます。
772 00:43:00.465 --> 00:43:01.965 ですから、いつも良いことだと思います
773 00:43:01.965 --> 00:43:05.365 実際にプロンプトを読んで理解するのは、何が
774 00:43:06.185 --> 00:43:07.525 その、モデルが、つまり
775 00:43:07.525 --> 00:43:09.285 モデルは正確に何をするよう指示されているのか、ということです。
776 00:43:10.105 --> 00:43:11.285 なので、ぜひ中を見てみることをお勧めします
777 00:43:11.285 --> 00:43:14.045 これらの generate gap queries、ええと、
778 00:43:14.105 --> 00:43:16.645 search chunks from vector、ええと、
779 00:43:16.925 --> 00:43:18.165 generate subqueries などをです。
780 00:43:18.905 --> 00:43:22.685 ええと、では、ええと、とても手短に、つまり
781 00:43:22.685 --> 00:43:25.725 それが終わると終了し、その後
782 00:43:25.745 --> 00:43:26.805 この query 関数に戻ります、
783 00:43:27.545 --> 00:43:31.205 そして今、ここにある、ええと、2つのステップにいます
784 00:43:31.725 --> 00:43:36.125 これらすべての、ええと、サブクエリ
785 00:43:36.345 --> 00:43:37.965 と取得されたチャンクからレポートを合成するところです。
786 00:43:39.385 --> 00:43:41.005 ええと、そして、ほら、それは同じモデルへの
787 00:43:41.005 --> 00:43:42.205 さらなるプロンプト指定にすぎません。
788 00:43:43.375 --> 00:43:47.555 そして、ええと、それが終わると、ええと、つまり、ほら、
789 00:43:47.555 --> 00:43:48.795 10分くらいかかるかもしれませんし、
790 00:43:49.805 --> 00:43:53.025 使用する推論サービスによっては30分かかるかもしれません。
791 00:43:53.025 --> 00:43:56.225 そして質問について、これは複数回の反復を行っていることになります
792 00:43:56.405 --> 00:43:58.305 この、ええと、いわば、この推論の
793 00:43:59.065 --> 00:44:01.865 質問を、それに答えるためのいくつかの、いわば
794 00:44:01.995 --> 00:44:05.625 ステップに分解し、ええと、それが
795 00:44:05.765 --> 00:44:07.425 続けるべきか、それとも終了すべきかを判断します。
796 00:44:07.965 --> 00:44:09.865 そして、ちょっとした良いレポートを生成します。
797 00:44:10.525 --> 00:44:12.145 そして、ええと、ここに例があります。
798 00:44:12.765 --> 00:44:17.235 ええと、質問は、The Simpsons は
799 00:44:17.455 --> 00:44:18.595 時間とともにどのように進化してきたか、でした。
800 00:44:19.735 --> 00:44:22.155 そしてこれは、すべての要点を
801 00:44:22.155 --> 00:44:27.075 本当に網羅するような、素敵な小さなレポートをまとめています、ええと、素敵な感じで
802 00:44:27.075 --> 00:44:28.475 いわば、物事をまとめる結論のようなものです。
803 00:44:29.575 --> 00:44:33.285 それでは、ええと、スライドに戻って
804 00:44:33.585 --> 00:44:34.885 締めくくりましょう。
805 00:44:38.505 --> 00:44:42.115 では、プロンプトの大まかな概要を説明してもいいでしょうか？
806 00:44:42.855 --> 00:44:45.915 ええと、時間の関係で、ええと、あの、
807 00:44:51.605 --> 00:44:52.455 はい、見てみましょう。
808 00:45:01.515 --> 00:45:04.045 はい、つまり、つまり、時間の関係で、ええと、すみません、
809 00:45:04.385 --> 00:45:06.405 ええと、正確な、ええと、コードを見るのは
810 00:45:06.405 --> 00:45:08.205 飛ばさなければならないと思います。
811 00:45:08.665 --> 00:45:13.395 ええと、でも、ええと、皆さんに示したいのは、ええと、うわ、
812 00:45:13.415 --> 00:45:15.635 今ちょっと場所を見失いました。
813 00:45:22.065 --> 00:45:24.235 オーケー。はい、つまり、これも deep search の中にあり、
814 00:45:24.375 --> 00:45:28.955 Subquery prompt があります。そして見てわかるように、そう、つまり、
815 00:45:28.955 --> 00:45:31.555 これらのプロンプトは実際には deep search do pi ファイルの中にあります。
816 00:45:32.215 --> 00:45:35.035 たとえば、あなたは AI コンテンツ分析の専門家で、
817 00:45:35.035 --> 00:45:37.475 コンテンツの要約が得意です。要約してください、
818 00:45:37.655 --> 00:45:38.715 ほら、などなど、という感じです。
819 00:45:39.625 --> 00:45:40.795 それから refre、ええと、
820 00:45:40.835 --> 00:45:43.875 reflection prompt があり、元のクエリなどに基づいて
821 00:45:44.035 --> 00:45:46.355 追加の検索クエリが必要かどうかを判断します。
822 00:45:47.135 --> 00:45:48.635 ええと、re-ranking prompt があり、
823 00:45:49.815 --> 00:45:51.235 そして subquery prompt があります。
824 00:45:51.535 --> 00:45:52.995 ですから、見てわかるように、ええと、
825 00:45:53.095 --> 00:45:56.195 少なくとも4種類ほどの、ええと、プロンプティングがあり、
826 00:45:56.195 --> 00:45:58.115 それぞれ異なる、ええと、サブタスクに対応しています。
827 00:45:59.015 --> 00:46:00.595 ですので、ええと、でも、このファイルを見てみると、
828 00:46:00.615 --> 00:46:02.675 それらを、なんというか、ええと、
829 00:46:03.285 --> 00:46:04.595 もう少し詳しく確認できます。
830 00:46:05.135 --> 00:46:07.995 ええと、でもスライドに戻ると、見てみましょう。
831 00:46:15.785 --> 00:46:20.555 オーケー、では、ええと、ええと、こうした ations がどのように機能するかの背後にある
832 00:46:20.555 --> 00:46:23.835 いわば秘密のソースのようなものは何でしょうか、ええと、
833 00:46:23.835 --> 00:46:25.035 どのように機能するのでしょうか？
834 00:46:25.975 --> 00:46:28.075 ええと、ひとつには条件付き計算という考え方が
835 00:46:28.095 --> 00:46:29.555 あると思います。
836 00:46:30.095 --> 00:46:33.315 つまり、モデルは実際に、
837 00:46:33.695 --> 00:46:37.595 現在の、いわば、モデル出力の状態に基づいて、
838 00:46:37.595 --> 00:46:40.195 どれだけ計算を行うかを決められるということです。
839 00:46:40.195 --> 00:46:42.275 そしてこれは、さまざまな方法で行うことができます。
840 00:46:43.135 --> 00:46:46.435 ええと、ひとつの、いわば、ええと、より複雑な方法としては、
841 00:46:46.435 --> 00:46:49.595 実際に、ええと、ええと、
842 00:46:49.595 --> 00:46:53.555 reasoning tokens のようなものを導入して、モデルに
843 00:46:53.555 --> 00:46:56.515 ある種、ほら、中間出力を生成し続けさせ、
844 00:46:56.845 --> 00:46:58.155 追加の計算を行わせ、
845 00:46:58.155 --> 00:46:59.675 何らかの終了条件に達するまで続けさせることができます。
846 00:47:00.095 --> 00:47:02.515 ええと、どうやら deep seek はこの方法を使っていないようです。
847 00:47:03.175 --> 00:47:05.915 ええと、でも、これは条件付き計算を行うための
848 00:47:05.975 --> 00:47:07.275 良い戦略のようなものです。
849 00:47:08.695 --> 00:47:10.635 ええと、2つ目はこの
850 00:47:11.115 --> 00:47:12.195 強化学習トレーニングだと思います。
851 00:47:12.415 --> 00:47:15.195 つまり、ええと、本当に単純に、ええと、
852 00:47:15.195 --> 00:47:18.595 概念的には強力なベースモデルを取り、ええと、
853 00:47:18.815 --> 00:47:19.995 deep seek が行ったように、
854 00:47:20.615 --> 00:47:23.195 そして、ええと、ある形態
855 00:47:23.195 --> 00:47:24.835 の強化学習を適用します
856 00:47:24.835 --> 00:47:26.035 非常に高品質な推論データに対して。
857 00:47:26.455 --> 00:47:28.395 すると、ある種のアハ体験のような瞬間があって
858 00:47:29.025 --> 00:47:30.965 モデルがまさに推論の仕方を学び始めるんです。
859 00:47:34.025 --> 00:47:38.645 ええと、つまり、ええと、あの、すべてが、ええと、あの、
860 00:47:38.645 --> 00:47:39.685 バラ色というわけではありません。
861 00:47:40.195 --> 00:47:41.325 もちろん、いくつか、
862 00:47:41.485 --> 00:47:42.925 かなり大きな課題があると思います。
863 00:47:42.925 --> 00:47:45.125 そして最初のものは、単純にコストだと思います。
864 00:47:45.785 --> 00:47:49.605 もし Open AI の deep research agent を使うなら、ええと、
865 00:47:49.625 --> 00:47:51.205 彼らの pro subscription が必要になります。
866 00:47:51.245 --> 00:47:52.605 月額 $200 くらいだと思いますが、
867 00:47:53.325 --> 00:47:56.725 それでもまだ、推論のコストは
868 00:47:56.725 --> 00:47:58.845 その料金では賄えていないと思います。
869 00:47:59.625 --> 00:48:01.325 ええと、それで、私が発見したことの一つは、
870 00:48:01.325 --> 00:48:02.925 実際にこれらのクエリを実行してみると
871 00:48:03.785 --> 00:48:05.725 どれほど多くの推論を実際に必要とするか、
872 00:48:05.725 --> 00:48:09.005 ということでした。なぜなら第一に、これらの推論モデルは、ええと、
873 00:48:09.075 --> 00:48:12.605 通常ははるかに多くの、ええと、推論を使います。つまり、
874 00:48:12.605 --> 00:48:14.125 与えられたプロンプトに対して
875 00:48:14.585 --> 00:48:16.045 推論ステップの数を進めていくので、ええと、
876 00:48:16.065 --> 00:48:19.045 さらに、複数回これらを呼び出す必要があるという事実もあります
877 00:48:19.065 --> 00:48:20.325 これらを、ええと、
878 00:48:20.875 --> 00:48:23.565 単純な、ええと、RAG システムよりもはるかに多く呼び出します。
879 00:48:25.345 --> 00:48:29.445 ええと、また、ハルシネーションと同じで、全体的に、ええと、あの、
880 00:48:29.445 --> 00:48:32.085 基盤モデルには一般的な問題として、ええと、
881 00:48:32.115 --> 00:48:33.525 推論エラーが起こり得ます。
882 00:48:33.745 --> 00:48:37.805 つまり、その中間の、ええと、推論チェーンのトレースで、
883 00:48:37.985 --> 00:48:40.325 もし何らかの、ええと、誤ったステップがあると、
884 00:48:40.955 --> 00:48:43.045 その後のすべてのステップが失敗する可能性があります。
885 00:48:43.945 --> 00:48:47.875 ええと、そして最後に、ええと、実際にこれらの推論モデルを
886 00:48:47.875 --> 00:48:50.275 訓練するには、本当に高品質な、ええと、
887 00:48:50.275 --> 00:48:52.395 オープンソースの推論
888 00:48:52.865 --> 00:48:54.915 トレースデータセットが必要だと思います。
889 00:48:55.455 --> 00:48:57.715 そしてそれは、人々が取り組んでいることです
890 00:48:57.715 --> 00:49:01.475 そうすることで、Open AI や、ええと、
891 00:49:01.475 --> 00:49:04.115 その競合他社の結果の一部を再現できるようにするためです。
892 00:49:05.745 --> 00:49:08.595 はい。ACHI が、ええと、
893 00:49:08.595 --> 00:49:10.155 私を急がせているのが分かるので、本当に、本当に手短に話します。
894 00:49:10.255 --> 00:49:13.155 それで、ええと、コストに関しては、
895 00:49:13.155 --> 00:49:14.835 人々が取り組んでいる解決策の一部としては
896 00:49:14.835 --> 00:49:17.155 専用ハードウェア、ええと、
897 00:49:17.155 --> 00:49:18.955 そして他のタイプの推論もあります。
898 00:49:18.975 --> 00:49:23.115 つまり、continuous chain of thought と呼ばれる考え方があって、
899 00:49:23.615 --> 00:49:25.875 ええと、推論に離散トークンを使うのではなく、
900 00:49:25.935 --> 00:49:28.555 実際には、連続的な潜在変数のようなものを使います。
901 00:49:28.685 --> 00:49:32.035 これは、はるかに、ええと、あの、コスト効率が高いです。
902 00:49:32.735 --> 00:49:35.555 ええと、そして、これらの参入障壁は
903 00:49:35.555 --> 00:49:37.155 オープンソースソフトウェアについても同様に
904 00:49:37.855 --> 00:49:39.915 そして、その、データやモデルのようなものです。
905 00:49:40.695 --> 00:49:42.875 なので、ええと、Ziot のようなプレイヤー
906 00:49:42.895 --> 00:49:46.715 そして hugging Face、ええと、私たちは、ええと、
907 00:49:46.955 --> 00:49:48.955 これらの結果を完全にオープンソースで再現することに取り組んでいます。
908 00:49:49.455 --> 00:49:50.915 そうすれば新しい人たちが、その、
909 00:49:50.915 --> 00:49:53.395 うまく機能するシステムから、ええと、学びを得て
910 00:49:53.415 --> 00:49:55.875 そして、ええと、本当に簡単に
911 00:49:55.875 --> 00:49:57.195 成功する研究エージェントを構築できます。
912 00:49:58.535 --> 00:50:00.315 なので、ええと、私からは以上だと思います
913 00:50:00.535 --> 00:50:03.635 そして、ええと、ああ、少し時間を超過したようですが、
914 00:50:03.635 --> 00:50:05.795 質問のために5分残っていると思います。
915 00:50:06.585 --> 00:50:08.435 はい。いくつか質問がありますね、
916 00:50:08.495 --> 00:50:10.115 では、ええと、順番に見ていきましょう。
917 00:50:10.935 --> 00:50:13.635 画像に対するベクトル埋め込みは、ええと、どのように機能しますか
918 00:50:13.635 --> 00:50:17.155 ベクトルはピクセルのために作成されるのですか
919 00:50:17.155 --> 00:50:18.195 それとも画像の一部分のためですか？
920 00:50:21.835 --> 00:50:25.925 はい。わかりました。では、ええと、ええと、
921 00:50:26.805 --> 00:50:29.025 私は、はい。
922 00:50:29.025 --> 00:50:33.265 わかりました。では、ええと、つまり、ええと、私が提示したこの種のフレームワークは
923 00:50:33.265 --> 00:50:35.545 非常に、ええと、一般的なものです。
924 00:50:36.165 --> 00:50:39.185 必要なのは、何らかの埋め込みの概念
925 00:50:39.565 --> 00:50:41.585 そして何らかの基盤モデルだけです。
926 00:50:42.205 --> 00:50:46.585 ええと、通常、ええと、ええと、ええと、
927 00:50:47.555 --> 00:50:49.345 画像の埋め込みを実行できる
928 00:50:49.575 --> 00:50:51.705 本当に優れたオープンソースモデルがあり、
929 00:50:52.485 --> 00:50:54.625 それらは通常、画像全体に対して機能します。
930 00:50:55.205 --> 00:50:58.665 ええと、それらは、ええと、パッチのようなものを見ているかもしれません
931 00:50:58.665 --> 00:51:00.225 それをビジョントランスフォーマーのようなものに入れて
932 00:51:00.685 --> 00:51:02.865 それから画像全体の埋め込みのようなものを出力します。
933 00:51:03.805 --> 00:51:06.545 そして、私たちは、私たちは、画像を
934 00:51:06.545 --> 00:51:10.305 テキストと同じ空間に埋め込めるモデルを使うことができます。
935 00:51:11.005 --> 00:51:14.385 なので、ええと、ええと、同じような概念がすべてここにも適用されます。
936 00:51:14.805 --> 00:51:17.025 画像または画像とテキストに特化した
937 00:51:17.045 --> 00:51:18.545 別の埋め込みモデルを使うだけです。
938 00:51:21.405 --> 00:51:24.145 ええと、では反復検索推論サイクルでは
939 00:51:25.085 --> 00:51:27.305 反復推論は
940 00:51:27.305 --> 00:51:29.705 推論 LLM によって行われ、検索はベクトル db によって行われるのですか。
941 00:51:30.325 --> 00:51:33.505 ええと、つまり、ええと、LLM は、実際には決して、実際には、
942 00:51:33.525 --> 00:51:36.105 アクションを実行することはなく、ただ
943 00:51:36.105 --> 00:51:38.465 アクションを実行するための指示を出すだけです。
944 00:51:39.045 --> 00:51:43.105 なので、それは、わかりました、ベクトルデータベースで
945 00:51:43.165 --> 00:51:45.545 その、これを検索して、というように言い、それからコードが実際に
946 00:51:45.545 --> 00:51:46.785 その、その検索を実行します。
947 00:51:47.165 --> 00:51:50.185 でも、はい、その類似検索を実行しているのは
948 00:51:50.185 --> 00:51:51.305 ベクトルデータベースです。
949 00:51:51.845 --> 00:51:54.825 その、その LM はただ、ええと、ツール使用の
950 00:51:54.845 --> 00:51:55.945 インスタンスを要求するだけです。
951 00:51:57.205 --> 00:51:58.745 ええと、推論モデルである必要はありません。
952 00:51:58.765 --> 00:51:59.785 なので、はい、これはすでに扱ったと思います。
953 00:51:59.885 --> 00:52:04.585 ええと、なので、いいえ、ええと、実際には多くの
954 00:52:04.585 --> 00:52:06.425 他のステップが推論モデルでないなら、おそらく良いと思います
955 00:52:06.425 --> 00:52:10.185 なぜなら、ええと、推論のコストを削減できるからです
956 00:52:10.185 --> 00:52:14.945 システムをランク付けするためのもの、ええと、セマンティック検索です。
957 00:52:15.245 --> 00:52:19.685 ええと、なので、ええと、
958 00:52:20.595 --> 00:52:24.365 そうです、ええ、つまり、Melva は対応しています、
959 00:52:24.625 --> 00:52:26.645 ハイブリッド、ええと、検索に。
960 00:52:27.185 --> 00:52:31.805 つまり、語彙検索プラスセマンティック検索、ええ、Melva 2.5 では、
961 00:52:32.305 --> 00:52:33.325 それを実装できます
962 00:52:33.865 --> 00:52:35.405 そしてそれは、まあ、単に
963 00:52:35.405 --> 00:52:39.685 研究エージェント内の、ええと、あの、
964 00:52:39.685 --> 00:52:42.725 ベクトルデータベース検索ステップへのごく小さな変更のようなものになります。
965 00:52:44.345 --> 00:52:47.245 サブクエリの数を選べますか？ Peram？
966 00:52:47.505 --> 00:52:49.965 ええと、これはそういうものの一つだと思います
967 00:52:49.965 --> 00:52:51.485 実際にはそれが最善だと思うところです。
968 00:52:51.825 --> 00:52:54.845 つまり、私たちはシステムを、いわば、
969 00:52:54.865 --> 00:52:57.045 できるだけ自律的になるように設計しています。
970 00:52:57.985 --> 00:53:00.605 ええと、できます、まあ、いわばハードコードすることもできます、
971 00:53:00.675 --> 00:53:02.645 最大数のようなものを。
972 00:53:02.945 --> 00:53:04.565 できます、わかりませんが、再ランク付けして
973 00:53:04.565 --> 00:53:06.045 最大値を取ることもできます。
974 00:53:06.825 --> 00:53:09.845 ええと、ただ最も単純な実装では
975 00:53:09.845 --> 00:53:12.165 基盤モデルに、ええと、いくつにすべきかを決めさせるだけです、
976 00:53:12.345 --> 00:53:13.765 ええと、あの、あるべき数を。
977 00:53:14.185 --> 00:53:17.285 でも、ええと、そうですね、それは単なる設計上の選択です。
978 00:53:17.885 --> 00:53:19.205 私はただ、モデルに実際に
979 00:53:19.205 --> 00:53:23.125 それを決めさせることをお勧めします。ええと、はい。
980 00:53:23.585 --> 00:53:25.405 チャットにいくつか質問があります。
981 00:53:25.905 --> 00:53:29.925 ええと、これを open AI のソリューションとベンチマークしましたか？
982 00:53:30.025 --> 00:53:32.805 また、このフレームワークは、クエリに関連するデータを収集するために
983 00:53:32.945 --> 00:53:36.005 Web クローリングを行うツールも機能として提供していますか？
984 00:53:36.595 --> 00:53:39.325 はい、とても良い質問です。ええと、つまり、たぶん、その、その、
985 00:53:39.325 --> 00:53:42.325 目的は、ええと、あの、これらの異なるオープンソースの
986 00:53:43.195 --> 00:53:46.245 deep research エージェントは、ええと、それぞれ異なる、
987 00:53:46.245 --> 00:53:47.245 異なる目的を持っていました。
988 00:53:47.745 --> 00:53:50.325 それで、ええ、あの、私たちの目的はそれほど
989 00:53:50.385 --> 00:53:54.365 OpenAI が、ええと、
990 00:53:54.585 --> 00:53:58.605 彼らのものを実行した特定のベンチマークを再現することではなく、
991 00:53:58.985 --> 00:54:00.045 むしろ、いわば
992 00:54:00.045 --> 00:54:01.125 理解しやすいシステムを作ることでした。
993 00:54:01.865 --> 00:54:04.005 それを、例えば教育目的に使えます、
994 00:54:04.465 --> 00:54:06.645 ただお勧めするのは、ええと、その、
995 00:54:06.945 --> 00:54:09.565 hugging face の deep research エージェントを見てみてください、そこでは
996 00:54:09.565 --> 00:54:13.445 実際、それが彼らの主な動機の一つでした、
997 00:54:13.985 --> 00:54:15.805 ええと、同様の数値を達成すること
998 00:54:16.025 --> 00:54:18.325 あるいはベンチマークを上回ること、ええ、あの、彼らはそれを達成しました。
999 00:54:19.605 --> 00:54:21.165 また単に、いわば、
1000 00:54:21.165 --> 00:54:24.245 研究エージェントの異なるアーキテクチャを比較するのも興味深いと思います。
1001 00:54:26.175 --> 00:54:28.225 はい。このフレームワークは、
1002 00:54:28.285 --> 00:54:30.545 関連データを収集するための Web クローリングを行うツールも提供していますか？
1003 00:54:31.325 --> 00:54:34.745 ええと、あの、はい、つまり、私たちには、ええと、あの、
1004 00:54:34.745 --> 00:54:37.865 いくつかを呼び出すための、いわば、そのツールがあります
1005 00:54:37.865 --> 00:54:40.065 さまざまなWebクローリングの、ええと、サービスです。
1006 00:54:40.845 --> 00:54:43.025 ええと、私、私たちはまだそれをある種
1007 00:54:43.045 --> 00:54:45.065 動的な、ええと、ツール呼び出しとして追加しているところだと思います。
1008 00:54:45.645 --> 00:54:47.625 ええと、でもそれは近い将来のことだと思います。
1009 00:54:48.165 --> 00:54:51.625 でも、ええと、単に「はい、ここにドメイン名があります。
1010 00:54:51.785 --> 00:54:54.105 このドメインから自分のデータを全部、ええと、
1011 00:54:54.105 --> 00:54:57.865 取得したいです」と言えば、それがfire crawl
1012 00:54:57.925 --> 00:54:59.145 またはあなたが使っている何らかのサービスを呼び出し
1013 00:54:59.565 --> 00:55:03.265 それを取り込み、インデックス化し、それからクエリを実行します。
1014 00:55:05.805 --> 00:55:08.865 では、素晴らしい質問です。そしてそれで、
1015 00:55:08.925 --> 00:55:11.065 ええと、ちょうど時間になりそうですね。はい、
1016 00:55:11.295 --> 00:55:12.745 はい、ちょうど時間ぴったりです。
1017 00:55:12.925 --> 00:55:15.905 それでは皆さん、ありがとうございます。本日はご参加いただき本当にありがとうございました。
1018 00:55:16.365 --> 00:55:19.425 ええと、Stefanがここに彼の情報を画面に表示していますので、もし
1019 00:55:19.425 --> 00:55:20.545 彼への質問があればご覧ください。
1020 00:55:20.925 --> 00:55:22.585 ええと、オフィスアワーもあります。
1021 00:55:22.965 --> 00:55:25.345 ええと、もし、ええと、
1022 00:55:25.645 --> 00:55:28.625 もし専門的な1対1のセッションをご希望でしたら、ええと、
1023 00:55:28.885 --> 00:55:30.425 そのためのQRコードがここにあります。
1024 00:55:30.965 --> 00:55:33.785 ええと、また、Palo Altoで対面のワークショップを
1025 00:55:33.785 --> 00:55:34.865 近日開催予定です。
1026 00:55:35.125 --> 00:55:37.865 ええと、Bay Areaにお住まいの方は、そういう方も何人か
1027 00:55:37.865 --> 00:55:41.145 いらっしゃるのを見ましたので、ぜひそちらに登録してください。
1028 00:55:41.865 --> 00:55:43.425 ええと、本日はご参加いただきありがとうございました。
1029 00:55:43.685 --> 00:55:46.505 そして、ええと、次回のウェビナーでお会いできるのを楽しみにしています。
1030 00:55:47.055 --> 00:55:48.105 残りの一日をお過ごしください。
1031 00:55:48.365 --> 00:55:49.425 皆さん、ご参加ありがとうございました。
1032 00:55:49.485 --> 00:55:52.225 そして、ええと、3月に私たちの、
1033 00:55:52.225 --> 00:55:53.465 OpenAIとのワークショップでお会いできることを願っています。
1034 00:55:53.655 --> 00:55:54.305 はい。お元気で。
Meet the Speaker
Join the session for live Q&A with the speaker
Stefan Webb
Developer Advocate, Zilliz
Stefan Webb is a Developer Advocate at Zilliz, where he advocates for the open-source vector database, Milvus. Prior to this, he spent three years in industry as an Applied ML Researcher at Twitter and Meta, collaborating with product teams to tackle their most complex challenges. Stefan holds a PhD from the University of Oxford and has published papers at prestigious machine learning conferences such as NeurIPS, ICLR, and ICML. He is passionate about generative AI and is eager to leverage his deep technical expertise to contribute to the open-source community.