- Events
Milvusハイブリッド検索：キーワードの精度とセマンティックの力を組み合わせた次世代データ検索
ウェビナー
Milvusハイブリッド検索：キーワードの精度とセマンティックの力を組み合わせた次世代データ検索
Join the Webinar
Loading...
このウェビナーについて
このウェビナーでは、高度なウェブクローリングと、Milvus 内で全文検索と高密度ベクトル検索の両方を活用するハイブリッド検索アーキテクチャを組み合わせることで、ドキュメント検索への統合的なアプローチを実演します。参加者は、Crawl4AI を使用してドキュメントを抽出し、それを Milvus に取り込む方法を確認できます。このシステムは、組み込みの BM25 関連度スコアリングによって強化された Milvus の全文検索機能を利用してキーワードマッチングを処理し、高密度ベクトル検索をセマンティック類似性のために使用します。これらの方法を組み合わせることで、関連情報を正確に取得するという課題に対応します。
取り上げるトピック
- Crawl4AI によるデータ抽出: python および npm ライブラリのドキュメントをスクレイピングするための手法。
- Milvus 全文検索: テキストのトークン化、スパース埋め込み生成、BM25 スコアリングを含む内部メカニズム。
- Milvus 高密度ベクトル検索: ANN 検索と効率的なインデックス戦略を使用して、セマンティック類似性を迅速に計算。
- ハイブリッド検索の統合: キーワードベースおよびベクトルベースの検索を統合し、精度とカバレッジを向上させる方法。
1 00:00:03.545 --> 00:00:04.645 ご紹介できることをうれしく思います
2 00:00:04.645 --> 00:00:07.405 このセッションの研究「Combining Keyword Precision」
3 00:00:07.405 --> 00:00:10.085 「with semantic Power for NextGen Data Retrieval」
4 00:00:10.085 --> 00:00:12.645 本日のゲストスピーカー、kukaさんです。
5 00:00:12.865 --> 00:00:17.165 彼はData Datamax AIのデータおよびAIエンジニアで、
6 00:00:17.185 --> 00:00:19.325 MLおよびAIの開発と統合を専門としています。
7 00:00:20.105 --> 00:00:23.165 彼はデータトランスフォーマー、
8 00:00:23.165 --> 00:00:24.685 アーキテクチャ、アテンションメカニズム、
9 00:00:24.905 --> 00:00:26.725 そして機械学習のその他の重要分野について深い洞察を得ています。
10 00:00:27.515 --> 00:00:29.045 彼はSMASHラーニングに情熱を注いでおり、
11 00:00:29.505 --> 00:00:32.125 早くから自身のキャリアを前進させることに取り組み、
12 00:00:32.385 --> 00:00:33.685 最終的にはチームを率いて
13 00:00:33.745 --> 00:00:36.765 クラウド開発とAIにおける革新的なソリューションを創出することを目指しています。
14 00:00:37.295 --> 00:00:39.125 Early、ステージはあなたのものです。
15 00:00:40.325 --> 00:00:42.625 ええと、ありがとうございます、Stefan。皆さん、こんにちは。
16 00:00:43.205 --> 00:00:45.745 そうですね、ええと、
17 00:00:46.765 --> 00:00:49.565 この、今回のプレゼンテーションです。
18 00:00:49.825 --> 00:00:52.005 このプレゼンテーションでは、ええと、
19 00:00:52.795 --> 00:00:55.245 VISのPulテキスト検索
20 00:00:55.245 --> 00:00:58.045 と埋め込み検索を組み合わせて
21 00:00:58.045 --> 00:00:59.805 私の意見では面白いものを実現することについて話します。
22 00:01:00.465 --> 00:01:04.345 それで、この、ええと、プロジェクトへの探求は、
23 00:01:04.345 --> 00:01:08.865 私がある特定のツールを必要としていたことから始まりました。そのツールは
24 00:01:08.865 --> 00:01:12.875 ウェブをクロールし、ええと、見つけられるあらゆるウェブサイトを対象に、
25 00:01:13.675 --> 00:01:17.925 生成し、ええと、そのもののタイトルのようなデータや、
26 00:01:18.045 --> 00:01:20.525 基本的には要約を生成して、
27 00:01:20.525 --> 00:01:22.565 必要な部分やチャンクをより見つけやすくし、
28 00:01:22.625 --> 00:01:25.405 自分が、ええと、
29 00:01:25.475 --> 00:01:28.965 少し速くコードを書いたり、ライブラリなどをよりよく理解したりするのを助けるものでした。
30 00:01:30.105 --> 00:01:34.125 それでは、私が作成したプレゼンテーションを共有し、
31 00:01:34.225 --> 00:01:39.165 その後、ええと、デモにさらに深く入っていきます。そのデモでは、ええと、
32 00:01:39.585 --> 00:01:41.685 この全体のロジックがどのように
33 00:01:42.195 --> 00:01:45.005 まとまるのかを紹介し、ええと、
34 00:01:45.105 --> 00:01:46.445 将来それを使えるようにします。
35 00:01:54.885 --> 00:01:59.465 ですので、先ほど述べたように、ええと、
36 00:02:00.575 --> 00:02:03.435 このプレゼンテーションの重要なポイントはvis
37 00:02:03.575 --> 00:02:07.715 と、ええと、その、ええと、フルテキスト検索
38 00:02:07.815 --> 00:02:08.955 そして、ええと、ベクトル検索についてです。
39 00:02:09.735 --> 00:02:13.135 ええと、すみません。
40 00:02:13.835 --> 00:02:18.095 では、それらを組み合わせるとして、なぜこの2つの
41 00:02:18.475 --> 00:02:20.775 ええと、検索、ええと、手法を組み合わせる必要があるのでしょうか？
42 00:02:21.325 --> 00:02:22.695 まあ、ええと、単純に
43 00:02:22.725 --> 00:02:25.695 そのうちの一方が、たとえば、
44 00:02:25.795 --> 00:02:28.215 フルテキスト検索を使う場合、もしかすると
45 00:02:28.215 --> 00:02:31.255 いくつかの詳細を見落とす可能性があるからです。ええと、どんな
46 00:02:32.115 --> 00:02:34.775 大きな文書を読んでいる場合でも。
47 00:02:35.165 --> 00:02:36.935 Vectorについても同じです。それぞれに
48 00:02:37.185 --> 00:02:38.775 利点と欠点があります。
49 00:02:39.075 --> 00:02:40.615 ここで重要なのは、
50 00:02:40.615 --> 00:02:42.575 両方の長所を確実に得ることです。
51 00:02:42.955 --> 00:02:45.975 そして、ええと、VISを使うのは良いことです。
52 00:02:45.975 --> 00:02:48.215 なぜなら、後でお見せするように、
53 00:02:48.475 --> 00:02:51.015 それは私のDockerマシン上でローカルに実行されているからです。
54 00:02:51.515 --> 00:02:55.855 そして、ええと、それは間違いなく非常に高速で、とても信頼性があります。
55 00:02:56.155 --> 00:02:59.685 それは、ええと、数秒で起動します。数秒です。
56 00:02:59.685 --> 00:03:01.885 では、そもそもどうやってこれをやるのでしょうか？
57 00:03:02.145 --> 00:03:06.845 ええと、Python NPN の、ええと、ライブラリのクロールです。
58 00:03:07.485 --> 00:03:09.565 私は現在、GitHub ライブラリを使用しています
59 00:03:09.565 --> 00:03:10.845 Crawl for ai というものです。
60 00:03:11.025 --> 00:03:14.765 AI LLM の、ええと、
61 00:03:15.735 --> 00:03:18.365 界隈にいる人たちは、Crawl for ai にとても詳しいはずです。
62 00:03:19.115 --> 00:03:22.685 それが、ええと、基本的に何をするかというと、ええと、
63 00:03:24.345 --> 00:03:28.555 特定のウェブサイトをクロールして、それを整形する
64 00:03:28.655 --> 00:03:31.915 または最も重要なものを解析して取得します
65 00:03:32.725 --> 00:03:34.905 AI が後で受け取るコンテキストをよりよく理解できるように
66 00:03:34.905 --> 00:03:36.625 するためです。
67 00:03:37.405 --> 00:03:41.545 ええと、私はいくつかのスマートなロジックも開発していて、それについては
68 00:03:41.545 --> 00:03:45.025 少し後で触れますが、ええと、コードブロックを認識します
69 00:03:45.055 --> 00:03:48.825 ドキュメントで普通に見つかるような、ええと、ものです。
70 00:03:49.725 --> 00:03:50.945 ドキュメントサイトでです。
71 00:03:51.525 --> 00:03:55.245 それは、ええと、古いものをたどって、
72 00:03:55.465 --> 00:03:58.885 つまりサイトマップを使って、すべての
73 00:03:59.795 --> 00:04:04.605 ドキュメントサイト内にあるさまざまなウェブサイトをたどります。
74 00:04:05.025 --> 00:04:09.045 そして、ええと、AI が理解できるようにすべてを準備します。
75 00:04:09.225 --> 00:04:13.245 そしてウェブサイトをクロールした後、埋め込みを作成し
76 00:04:13.245 --> 00:04:16.165 その他もろもろを行い、それらを vu の、ええと、データベースに入れ
77 00:04:16.185 --> 00:04:17.925 そして後でそれらにアクセスできます。
78 00:04:18.905 --> 00:04:21.725 それで、Viss folks の全文検索メカニズムですが、
79 00:04:22.155 --> 00:04:25.445 基本的に何をするかというと、ええと、ちなみに、これは
80 00:04:25.465 --> 00:04:28.565 舞台裏のことなので、実際に見えるのはそれほど多くありません、
81 00:04:28.565 --> 00:04:29.565 ええと、VUS の部分は。
82 00:04:29.905 --> 00:04:34.125 それは、ええと、BM 25 スコアリング BMI 25 スコアリングを使います、つまり
83 00:04:35.585 --> 00:04:37.605 何らかの自然言語を与えると
84 00:04:37.985 --> 00:04:39.605 それがクエリを生成します。
85 00:04:39.825 --> 00:04:41.805 そしてそのクエリに基づいて、
86 00:04:41.805 --> 00:04:44.725 最も関連性の高い、ええと、ドキュメント
87 00:04:44.865 --> 00:04:48.085 または持っているかもしれない任意のチャンクを取得します。
88 00:04:48.145 --> 00:04:51.005 ここではチャンクが非常に重要です。少し後でお見せします。
89 00:04:52.025 --> 00:04:54.525 同じことが、ええと、ベクトルにも当てはまります。
90 00:04:55.145 --> 00:04:58.645 さて、前に言ったように、それら両方には利点
91 00:04:58.645 --> 00:05:00.205 と欠点があります。
92 00:05:00.785 --> 00:05:04.405 ええと、それぞれが自分の領域において
93 00:05:04.625 --> 00:05:05.925 非常に強力なソリューションです。
94 00:05:06.075 --> 00:05:08.765 しかし、それらには非常に大きな問題があります、
95 00:05:08.815 --> 00:05:10.285 特にRAGにおいてです。
96 00:05:10.605 --> 00:05:13.685 なぜなら結局のところ、ソリューションは rag、ええと、
97 00:05:14.005 --> 00:05:15.085 retrieval augmented だからです。
98 00:05:15.085 --> 00:05:19.575 そう、問題は、あまりに多くのデータを与えたり
99 00:05:19.755 --> 00:05:22.335 データベースをかなり飽和させたりすると、
100 00:05:22.675 --> 00:05:24.055 混乱してしまうということです。
101 00:05:24.185 --> 00:05:25.455 間違いなく混乱します。
102 00:05:26.035 --> 00:05:27.135 そこで回避策
103 00:05:27.475 --> 00:05:31.575 そして私たちがその両方を使っている理由、ええと、それは
104 00:05:31.765 --> 00:05:34.575 各
105 00:05:34.755 --> 00:05:36.775 チャンクに対して埋め込みを生成しているということです。
106 00:05:37.535 --> 00:05:39.635 各チャンクに対して要約を生成しています
107 00:05:39.735 --> 00:05:43.925 そしてタイトルも付けて、少しだけ充実させています。
108 00:05:45.495 --> 00:05:47.195 タイトルは実際には見せかけのためだけでしたが、
109 00:05:47.295 --> 00:05:49.315 それでも要約を使っていて、
110 00:05:49.855 --> 00:05:51.915 クエリを要約に渡しています。
111 00:05:51.975 --> 00:05:54.315 そして各チャンクの完全なコンテキストも渡しています。
112 00:05:55.275 --> 00:05:58.365 ええと、チャンクは、先ほど言ったように、少し、ええと、
113 00:05:58.865 --> 00:06:02.525 ドキュメントのサイトごとに異なります。
114 00:06:02.685 --> 00:06:04.085 なぜなら、コードブロックがある場合もあり、
115 00:06:04.185 --> 00:06:06.245 そこにはスマートなロジックがあって、
116 00:06:06.835 --> 00:06:08.965 コードブロック全体を読むか、少し手前で
117 00:06:08.965 --> 00:06:11.845 止めるかを判断します。いずれにしても精度を高め、
118 00:06:12.105 --> 00:06:14.605 より冗長にし、より良い
119 00:06:15.245 --> 00:06:18.495 カバレッジにし、もちろんスケーラブルにするためです。
120 00:06:18.895 --> 00:06:22.715 なぜなら、もしあるNPMライブラリの
121 00:06:22.715 --> 00:06:26.915 完全なドキュメントを渡すなら、その上に追加したいものが
122 00:06:26.915 --> 00:06:29.795 いくつかの、ええと、ライブラリなどかもしれないからです。
123 00:06:31.255 --> 00:06:35.235 では、なぜこれを行ったのでしょうか？
124 00:06:36.665 --> 00:06:40.645 言ったように、主な問題は実際には飽和です。
125 00:06:41.425 --> 00:06:45.435 少なくとも私にとって、ええと、AIで最初に始めた
126 00:06:45.435 --> 00:06:48.195 プロジェクトの一つは、ええと、RAGでした。
127 00:06:48.735 --> 00:06:50.995 そして、ええと、数百
128 00:06:51.715 --> 00:06:53.075 または数十のチャンクを
129 00:06:53.175 --> 00:06:57.555 渡した途端、実際にはモデルが非常に、
130 00:06:57.575 --> 00:07:01.555 埋め込みモデルが非常に、ええと、混乱することに気づきました。
131 00:07:01.975 --> 00:07:05.515 そして、ええと、解決策は単にリランカーを使うこと
132 00:07:05.735 --> 00:07:06.835 などでした。
133 00:07:07.415 --> 00:07:08.915 リランカーの問題は、
134 00:07:08.915 --> 00:07:10.675 それらもまた混乱する可能性があることです。
135 00:07:11.455 --> 00:07:15.705 なので、その解決策は
136 00:07:15.705 --> 00:07:17.505 エージェント型RAGです。
137 00:07:18.125 --> 00:07:22.785 各チャンクに対して生成する要約では、
138 00:07:23.085 --> 00:07:24.385 その要約の中で、
139 00:07:24.485 --> 00:07:27.345 それがどのチャンクなのかなども指定しています。
140 00:07:27.605 --> 00:07:31.225 そしてクエリを、ベクトル検索と、ええと、全文検索の両方で渡します。
141 00:07:31.225 --> 00:07:34.905 それらを要約の要約に渡し、
142 00:07:35.245 --> 00:07:38.585 それからクエリから最も関連性の高い結果を、
143 00:07:38.695 --> 00:07:40.545 両方ともチャット
144 00:07:40.805 --> 00:07:43.945 または任意のLLMに渡します。
145 00:07:45.065 --> 00:07:46.955 これは、私の経験
146 00:07:46.955 --> 00:07:48.395 および、これを内部ツールとして使っている
147 00:07:48.395 --> 00:07:51.355 同僚たちの経験からすると、
148 00:07:51.875 --> 00:07:56.655 非常に正確な、ええと、結果につながっています。
149 00:07:57.495 --> 00:07:59.895 私はまだ、ライブラリを
150 00:07:59.925 --> 00:08:01.975 よりうまく区別するようなロジック
151 00:08:01.975 --> 00:08:03.455 などを実装していません。
152 00:08:03.455 --> 00:08:07.335 しかし、私たちが使っている用途では、まったく問題ありません。
153 00:08:09.065 --> 00:08:12.285 そして今からライブデモをお見せします。
154 00:08:12.585 --> 00:08:16.645 ライブデモはこのように進みます。ええと、私が選んだ
155 00:08:17.235 --> 00:08:18.445 ウェブサイトをクロールします。
156 00:08:18.945 --> 00:08:21.125 ええと、この例ではpedanticを選びました。
157 00:08:21.125 --> 00:08:23.925 それを使ったプロジェクトがあったからです。
158 00:08:24.025 --> 00:08:25.285 だから、やってみようと思いました。
159 00:08:25.945 --> 00:08:29.845 ええと、サイトマップのロジックを紹介します
160 00:08:30.345 --> 00:08:32.365 そしてそれが実際にどう見えるかも。
161 00:08:33.645 --> 00:08:37.105 そして、それがすべての、ええと、
162 00:08:37.355 --> 00:08:39.345 すべての
163 00:08:41.895 --> 00:08:43.455 identity のドキュメントサイトをクロールした後、
164 00:08:43.545 --> 00:08:46.495 それはサイトマップから見つけるのですが、それから
165 00:08:46.555 --> 00:08:48.575 通常の RAG のようにクエリできます。
166 00:08:48.645 --> 00:08:52.175 ただし、どちらか一方だけを使うわけではありません。
167 00:08:52.355 --> 00:08:53.975 つまり Vector でも
168 00:08:54.195 --> 00:08:56.165 Tex でもなく、両方を使って
169 00:08:56.265 --> 00:08:57.725 さらに高い精度を得ます。
170 00:09:01.745 --> 00:09:04.555 はい。これがスクリプトです。
171 00:09:04.915 --> 00:09:06.835 あまり詳しくは説明しません。
172 00:09:07.175 --> 00:09:11.695 ええ、チャンクサイズ
173 00:09:11.795 --> 00:09:13.135 と、
174 00:09:13.315 --> 00:09:15.775 そしてコーディングブロックを見つけるロジックは、ええと、
175 00:09:16.165 --> 00:09:17.695 個人的には面白いと思います。
176 00:09:17.795 --> 00:09:21.075 見たい人は誰でも確認できると思います。
177 00:09:21.655 --> 00:09:24.195 なので、サイトマップを開いてみます。
178 00:09:24.195 --> 00:09:26.155 それが実際にどのように
179 00:09:26.155 --> 00:09:27.755 見えるのか理解してもらうためです。
180 00:09:29.005 --> 00:09:33.455 基本的にはこれです。この1つのサイトマップの中に
181 00:09:33.635 --> 00:09:35.895 複数のリンクがあります。
182 00:09:36.115 --> 00:09:38.575 ええと、通常、人々、つまり企業はこれを
183 00:09:38.575 --> 00:09:40.455 SEO、検索エンジン最適化のために使いますが、
184 00:09:41.115 --> 00:09:42.695 でも、それは私たちにとって都合がよくて、
185 00:09:42.695 --> 00:09:47.135 好きな用途に活用できるからです。
186 00:09:47.855 --> 00:09:50.935 また、どのウェブサイトでも必ず
187 00:09:51.115 --> 00:09:54.975 robots dot TXD を確認するべきだとも言っておきます。
188 00:09:55.555 --> 00:09:56.775 安全側に倒すためです。
189 00:09:57.375 --> 00:10:00.455 なぜなら、もしかすると違法かもしれないし、分かりません。
190 00:10:01.115 --> 00:10:05.135 それで、私はすでに
191 00:10:07.235 --> 00:10:11.285 ウェブサイト群をクロールしてあり、例えば1つのチャンクが表示されています。
192 00:10:11.385 --> 00:10:16.045 デモとして最初のチャンクには、タイトル、要約、
193 00:10:16.585 --> 00:10:21.005 ええと、コンテキスト全体、チャンク、ID、チャンク番号、すべて
194 00:10:21.025 --> 00:10:23.495 そして embeddings が少し、ええと、
195 00:10:23.495 --> 00:10:25.335 さらに下にタイムスタンプなど全部あります。
196 00:10:26.035 --> 00:10:30.095 そこで、crawl identical AI documentation を実行します。
197 00:10:30.195 --> 00:10:31.415 そういう名前にしました。
198 00:10:31.955 --> 00:10:35.695 そして、ええと、すべてをクロールした後、
199 00:10:36.075 --> 00:10:39.215 extremely run Streamli ui を実行するだけです。
200 00:10:40.465 --> 00:10:43.965 この Streamli UI はとてもシンプルです。
201 00:10:44.225 --> 00:10:48.455 ただ、ええと、入力用のような
202 00:10:48.965 --> 00:10:51.375 テキストボックスがあり、チャットをクリアしたり、画像をアップロードしたりできます。
203 00:10:51.595 --> 00:10:54.255 ええと、実はこれは Stefan が提案しました。
204 00:10:54.355 --> 00:10:58.815 例えば会議やプレゼンテーション、
205 00:10:58.815 --> 00:11:00.615 あるいは何かに参加している場合、
206 00:11:00.615 --> 00:11:01.615 画面に表示されているものを写真に撮るだけで
207 00:11:01.995 --> 00:11:05.455 そして、ええと、すでにそのドキュメントをクロールしていれば、
208 00:11:05.765 --> 00:11:09.935 自分の、ええと、lag を使って参照できます。
209 00:11:10.495 --> 00:11:12.375 ここで見ているものが何であれ。
210 00:11:12.635 --> 00:11:14.215 非常にシンプルなクエリを渡しています。
211 00:11:14.395 --> 00:11:15.895 皆さんご存じだと思いますが、ええと、 familiar
212 00:11:16.005 --> 00:11:18.935 p weather agent の例です。
213 00:11:19.555 --> 00:11:24.215 そして、ええと、取得したいのは
214 00:11:25.505 --> 00:11:27.165 P のウェブサイトにあるものです。
215 00:11:27.305 --> 00:11:31.245 これもコピーして、実行できるようにします。
216 00:11:37.015 --> 00:11:40.685 これが P が提供しているサンプルコードです。
217 00:11:41.315 --> 00:11:44.405 これは、私たちが見るはずのものに近いものです。
218 00:11:44.425 --> 00:11:46.885 そしてモデルが非常にうまく機能すれば、
219 00:11:46.885 --> 00:11:48.285 これらすべては必要なく、
220 00:11:48.505 --> 00:11:50.565 一部、これとそれだけでいいと理解します。
221 00:11:50.785 --> 00:11:52.045 これは本当は必要ありません。
222 00:11:53.965 --> 00:11:58.385 そして、より少ない、ええと、
223 00:11:59.855 --> 00:12:03.535 これらの入力などで、完全に機能するまったく同じものを提供してくれます。
224 00:12:03.995 --> 00:12:07.055 それをどう行うか、または何をインストールする必要があるかを示してくれます。
225 00:12:07.275 --> 00:12:10.115 そして、ええ、以上です。
226 00:12:10.495 --> 00:12:15.425 ええと、あなたが、その、全体の操作を
227 00:12:15.425 --> 00:12:19.825 オーケストレーションする方法は
228 00:12:20.365 --> 00:12:24.585 この別のファイルを使うことで、そこにただ
229 00:12:24.585 --> 00:12:25.745 シンプルなクエリを渡します。
230 00:12:26.225 --> 00:12:29.465 私は、あなたは my identity ai の専門家で、
231 00:12:29.545 --> 00:12:31.625 豊富なドキュメントにアクセスできる Python AI エージェントフレームワークです、
232 00:12:31.625 --> 00:12:32.905 としなければなりません。
233 00:12:33.045 --> 00:12:36.825 いくつかツールを与えると、ええと、それだけで動きます。
234 00:12:37.605 --> 00:12:40.425 ちなみに、面白いことに、私はこのプロジェクトにも iden を使いました。
235 00:12:41.325 --> 00:12:45.105 なので、そもそもそのアイデアはそこから生まれたんです。
236 00:12:45.625 --> 00:12:47.745 identity についてもう少し知りたいと思って、
237 00:12:48.365 --> 00:12:51.405 ええと、これが全体の仕組みです。
238 00:12:51.945 --> 00:12:52.945 という感じです。
239 00:12:59.125 --> 00:13:02.725 もしもし？ ええと、早かったですね。
240 00:13:05.335 --> 00:13:07.925 たぶん、ええと、いくつか質問がありますが、
241 00:13:07.985 --> 00:13:10.485 もしかすると説明してもらえますか、例えば
242 00:13:10.485 --> 00:13:13.285 そちらで日常的にどう使っているのか、
243 00:13:14.185 --> 00:13:15.185 もちろんです。あなたが何を
244 00:13:15.185 --> 00:13:15.765 達成したのか、ということですね。
245 00:13:17.065 --> 00:13:21.045 それで、ええと、先ほど言ったように、identity ai の、ええと、例では、
246 00:13:21.755 --> 00:13:25.765 私が最初にやろうとしていたことは、
247 00:13:25.825 --> 00:13:28.405 自分自身のためのツールを持つことでした。
248 00:13:28.505 --> 00:13:32.485 そして同僚たちのためにも、たぶん、ええと、さまざまな NPM
249 00:13:33.085 --> 00:13:36.245 や Python ライブラリのドキュメント、
250 00:13:36.245 --> 00:13:39.765 またはウェブ上で見つけたものをスクレイピングできるようにするためです。
251 00:13:39.865 --> 00:13:43.085 うんうん。そして、ええと、それをよりよく理解する助けになり、
252 00:13:43.085 --> 00:13:44.325 より早く理解できるようになります。
253 00:13:44.555 --> 00:13:47.245 すべてのドキュメントを読み通さなければならない代わりに、
254 00:13:47.985 --> 00:13:52.125 文字通り、ざっと目を通すような形で与えるだけで、
255 00:13:52.125 --> 00:13:54.125 どこを見るべきかが分かります。
256 00:13:54.465 --> 00:13:56.245 そして each at GPT
257 00:13:56.245 --> 00:13:59.445 または別の LLM にクエリして、実際の
258 00:14:00.475 --> 00:14:02.325 正しい回答のようなものを得ることができます。
259 00:14:02.325 --> 00:14:06.185 うんうん。それがこの全体の、ええと、ことの発端です。
260 00:14:07.915 --> 00:14:09.005 わかりました。わかりました。いいですね。
261 00:14:09.305 --> 00:14:11.605 ええと、チャットに質問があるかどうか分かりません。
262 00:14:12.105 --> 00:14:15.165 ええと、参加者の方は、q and a で直接質問できます。
263 00:14:16.025 --> 00:14:18.605 そうでなければ、私が進めます。
264 00:14:18.605 --> 00:14:20.325 その間に私からもいくつか質問します。
265 00:14:21.225 --> 00:14:24.005 ええと、先ほどBM 25について少し触れましたよね。
266 00:14:24.465 --> 00:14:26.725 あの、それで説明してもらえますか、その、
267 00:14:26.725 --> 00:14:28.965 BM 25のスコアリングにおける役割を、たとえば
268 00:14:29.475 --> 00:14:31.445 あなたが持っているvis full tech searchでの？
269 00:14:32.105 --> 00:14:32.755 はい、もちろんです。
270 00:14:37.335 --> 00:14:40.125 待って、固まりましたね。もしもし。
271 00:14:48.145 --> 00:14:51.595 チャットで誰かを呼んでいます。はい、戻りましたね。固まっていました。
272 00:14:51.855 --> 00:14:55.155 固まっていました。聞こえますか？はい、今は聞こえます。
273 00:14:55.295 --> 00:14:58.755 本当にすみません。私のインターネットが。よく分かりません。
274 00:14:59.255 --> 00:15:01.875 ええと、質問は、あの、DM 25についてでしたよね。はい、
275 00:15:02.335 --> 00:15:03.335 はい。
276 00:15:03.655 --> 00:15:07.915 わかりました。では、
277 00:15:08.195 --> 00:15:12.625 説明します、どういう感じか、はい、DM 25は、
278 00:15:12.625 --> 00:15:15.705 基本的に、それを使う理由は、
279 00:15:16.845 --> 00:15:18.865 BM 25を使う理由ですね。はい。
280 00:15:19.455 --> 00:15:22.305 ええ。ええ。なぜそれを、はい。
281 00:15:22.305 --> 00:15:23.865 自分で見たメリットは何ですか？
282 00:15:24.005 --> 00:15:26.065 それは、あの、それを使ったときに、
283 00:15:26.205 --> 00:15:28.225 何か、単に
284 00:15:28.225 --> 00:15:29.585 ベクトル検索を使うだけより良いものが見えましたか？
285 00:15:30.175 --> 00:15:31.425 わかりました、はい。はい。
286 00:15:31.765 --> 00:15:35.785 基本的に、あの、このプロジェクトのアイデアは
287 00:15:36.005 --> 00:15:40.185 vissを活用して、何か素晴らしいものを作ること、
288 00:15:40.515 --> 00:15:42.425 素晴らしいもの、非常に興味深いものを作ることだったので、
289 00:15:42.425 --> 00:15:45.745 Vissをよりよく理解するために見せられるようなもの、
290 00:15:45.765 --> 00:15:48.425 そして、あの、チームとしての私たちの能力を示せるように。
291 00:15:49.335 --> 00:15:51.385 BM 25というのは、
292 00:15:51.485 --> 00:15:53.185 確か単にbest matchingのことだったと思います。
293 00:15:53.485 --> 00:15:56.385 あの、これは検索結果を
294 00:15:57.095 --> 00:15:58.545 ランク付けして取得するものです。
295 00:15:59.085 --> 00:16:01.865 そして、あの、バックエンドでそれが行うこと、少なくとも
296 00:16:01.865 --> 00:16:05.745 Mildのサイトでは、私がそれを使うことも選んだ理由は、
297 00:16:05.745 --> 00:16:09.425 それによって、単に、ええと、
298 00:16:10.055 --> 00:16:14.425 自然言語を活用できるので、そこには
299 00:16:14.445 --> 00:16:17.465 その自然言語をどう理解するかという点でもメリットがあり得るからです、
300 00:16:17.525 --> 00:16:18.945 それ自体をクエリのように。
301 00:16:19.605 --> 00:16:20.945 あの、私はある程度
302 00:16:20.945 --> 00:16:24.785 VectorツールとM 25では異なる結果に気づきました。
303 00:16:25.245 --> 00:16:29.025 結局のところ、両方とも同じようなロジックを使っていますが、
304 00:16:29.765 --> 00:16:34.095 でも、ええと、少しMildの魔法のようなものです、その
305 00:16:34.095 --> 00:16:35.575 動作の仕方は。
306 00:16:35.575 --> 00:16:39.005 そうなんです。私の実験では、
307 00:16:39.175 --> 00:16:43.085 何度かやり取りをした後、あの、数分
308 00:16:43.305 --> 00:16:44.925 あるいはチャットで
309 00:16:45.045 --> 00:16:49.815 やり取りするメッセージを重ねると、ベクトル部分が、
310 00:16:49.815 --> 00:16:54.215 飽和し始めて、少し、あの、混乱するのかもしれません。
311 00:16:54.555 --> 00:16:59.135 うんうん。なぜかは本当にうまく言えません。
312 00:16:59.305 --> 00:17:02.335 もしかすると、もしかするとそれも
313 00:17:02.335 --> 00:17:05.215 私のロジックのせい、あの、スクリプトの
314 00:17:05.215 --> 00:17:06.575 書き方のせいかもしれません。
315 00:17:07.035 --> 00:17:10.575 でも、あの、その両方の組み合わせは、ただ
316 00:17:12.275 --> 00:17:16.625 それぞれのクエリから最良の、あの、結果をもたらすことが実証されています。
317 00:17:17.195 --> 00:17:18.925 はい。このアプリケーションでは。
318 00:17:19.465 --> 00:17:22.995 ええ、いや、えー、それについても付け加えられますが、それは、えー、それは
319 00:17:22.995 --> 00:17:24.795 私たちも顧客に見ていることです。
320 00:17:25.055 --> 00:17:28.195 そして特に、探しているものが
321 00:17:28.215 --> 00:17:30.635 特定の名前や特定のブランドである場合に非常に有用です。
322 00:17:30.705 --> 00:17:33.675 たとえば特定のライブラリ名を探している場合ですね、
323 00:17:33.675 --> 00:17:35.995 もしかすると似たような別のものがあるかもしれません、えー、
324 00:17:36.065 --> 00:17:38.755 キーワード検索なら、実際にこれを見つけられて
325 00:17:38.755 --> 00:17:40.555 似たような別のものではない、ということです。
326 00:17:40.615 --> 00:17:42.755 それは通常、良い方法です。
327 00:17:43.095 --> 00:17:45.155 えー、質問もいくつかありますので、
328 00:17:45.615 --> 00:17:48.355 聞いていきます。最初の質問は、えー、
329 00:17:48.375 --> 00:17:51.365 リクエストに応じてエンベディングから
330 00:17:51.465 --> 00:17:53.845 文字列へ、または文字列からエンベディングへ切り替えるのはどう管理していますか？
331 00:17:58.765 --> 00:18:02.665 つまり、えー、私が言い換えてみますので
332 00:18:02.665 --> 00:18:04.145 その人は合っているか教えてください。
333 00:18:04.805 --> 00:18:07.665 つまり、検索するクエリがある状態から
334 00:18:07.665 --> 00:18:09.465 その後エンベディングを持つ状態へどう移行するのか
335 00:18:10.695 --> 00:18:12.625 ということですか、それは、えー、少なくとも
336 00:18:12.625 --> 00:18:14.465 全文検索に関しては、VIS がそれを行います
337 00:18:14.655 --> 00:18:18.745 というのも、えー、少なくとも私の側ではインポートして、
338 00:18:18.805 --> 00:18:21.905 利用して、それで終わりで、バックエンドで行われます。
339 00:18:22.365 --> 00:18:23.945 それに関しては、あなたのほうがもう少し
340 00:18:23.945 --> 00:18:25.025 詳しく説明できると思います。
341 00:18:25.685 --> 00:18:29.625 はい。基本的には、ええ、私たちには独自の、えー、
342 00:18:29.815 --> 00:18:30.865 アナライザーがあり、えー、
343 00:18:31.005 --> 00:18:33.985 さまざまな関数があります。そこで、
344 00:18:33.985 --> 00:18:35.665 入力クエリを渡すと、えー、
345 00:18:35.665 --> 00:18:36.905 それが変換されます。
346 00:18:36.925 --> 00:18:38.465 つまり削除したり、たとえば、
347 00:18:38.465 --> 00:18:40.145 すべてを小文字にしたり
348 00:18:40.145 --> 00:18:41.385 そういったことをします。
349 00:18:41.385 --> 00:18:43.305 そして、えー、トークナイズと
350 00:18:43.325 --> 00:18:44.865 アナライザーが実行されます。
351 00:18:45.565 --> 00:18:48.785 ですから、その後はエンベディングについて考える必要はありません。
352 00:18:48.785 --> 00:18:50.865 それが、私たちが全文検索をリリースした理由でもあります
353 00:18:51.485 --> 00:18:54.865 そうすれば、入力としてテキストを書き、出力としてテキストを得られます
354 00:18:55.085 --> 00:18:57.745 そしてその間では、あなたが言ったように、えー、mini が
355 00:18:57.775 --> 00:18:59.105 ここで全部使うことになります。
356 00:19:00.365 --> 00:19:05.345 えー、別の質問があります、えー、
357 00:19:06.755 --> 00:19:10.585 それは、RAG のインデックス戦略のためのアプリ戦略ですか？
358 00:19:11.285 --> 00:19:14.695 ですので、もしかすると、これは私も
359 00:19:14.695 --> 00:19:16.335 よくわからないので言い換えてみます。
360 00:19:17.035 --> 00:19:19.495 えー、RAG のために異なる
361 00:19:19.785 --> 00:19:21.615 インデックス戦略を試しましたか、ということかもしれません。
362 00:19:22.835 --> 00:19:25.555 うーん。えー、過去には？
363 00:19:25.625 --> 00:19:28.875 はい、この数か月では。
364 00:19:29.015 --> 00:19:31.995 あまりありません。自分の定番を見つけたので。うん。
365 00:19:32.075 --> 00:19:35.195 それは OpenAI の、えー、エンベディングを使って
366 00:19:35.215 --> 00:19:38.075 それから、えー、リランカーを使うだけでした。それは
367 00:19:39.245 --> 00:19:40.895 Hugging Face からのものか、どこか別のところのものでした。
368 00:19:41.115 --> 00:19:42.335 でも、これは私の得意分野でした
369 00:19:42.335 --> 00:19:45.615 というのも、つい最近まで私には必要がなかったからです
370 00:19:46.445 --> 00:19:50.335 RAGに対するそこまで複雑なソリューションは
371 00:19:50.605 --> 00:19:54.135 なぜなら、ええと、私には必要がなかったからです
372 00:19:55.245 --> 00:19:57.685 何百もの、ええと、ウェブサイトを調べて同時にクエリする必要が。
373 00:19:57.685 --> 00:20:01.645 うんうん。なので、これが、ええと、十分な答えになっていればと思います。
374 00:20:02.795 --> 00:20:05.605 はい。それについては一応答えたと思いますが、
375 00:20:05.625 --> 00:20:07.005 もう一度聞きます。
376 00:20:07.025 --> 00:20:08.765 Vectorを組み合わせようとしましたか
377 00:20:08.765 --> 00:20:09.845 スパースや埋め込みモデルと？
378 00:20:09.985 --> 00:20:14.325 たとえばMilusにあるBG M threeのようなものですが、ええと、試しましたか
379 00:20:15.305 --> 00:20:16.305 SparseとVectorsを？
380 00:20:16.605 --> 00:20:18.865 ええと、つまり、理解するためにですね、
381 00:20:18.865 --> 00:20:21.585 埋め込みの代わりに全文検索を使う利点を。
382 00:20:22.595 --> 00:20:26.415 それで、ええと、私がやったとき、作業を始めたとき
383 00:20:27.155 --> 00:20:29.415 このツールに取り組み始めたとき、私は試しました、ええと、
384 00:20:30.165 --> 00:20:32.255 さまざまなものの非常に多くの組み合わせを。
385 00:20:32.795 --> 00:20:36.055 でも、ええと、最終的には、それが単に
386 00:20:37.425 --> 00:20:38.985 利便性とパフォーマンスだったのかはわかりませんが、
387 00:20:39.205 --> 00:20:41.225 このベクトルに戻り続けました
388 00:20:41.285 --> 00:20:43.545 そして全文、ええと、ソリューションに。
389 00:20:43.965 --> 00:20:47.845 それが常により良い答えを返してくれるように思えました。
390 00:20:48.285 --> 00:20:51.125 なぜなら、他の組み合わせのようなものだと、
391 00:20:52.045 --> 00:20:55.725 非常に良い応答が得られることもあれば
392 00:20:55.825 --> 00:20:59.525 その後で完全に的外れな、
393 00:20:59.715 --> 00:21:01.205 クエリ応答が返ってくることもありました。
394 00:21:01.995 --> 00:21:06.485 これは、私が取り組んでいるものにとって完璧なバランスでした。
395 00:21:06.485 --> 00:21:10.285 結局のところ、ええと、私がこれのユーザーとして想定しているのは
396 00:21:10.345 --> 00:21:12.765 自分が見ているものや調べているものを
397 00:21:12.765 --> 00:21:15.325 理解している人でもあるからです。
398 00:21:16.145 --> 00:21:20.105 だから、もう少し具体的である必要があるかもしれません。
399 00:21:20.365 --> 00:21:24.295 ええと、でも通常はより良く
400 00:21:24.355 --> 00:21:26.895 より信頼できる、ええと、結果を出してくれました。
401 00:21:27.135 --> 00:21:30.495 私はこれを数日間、うんうん。
402 00:21:30.975 --> 00:21:32.135 最低でも数日間使っています。
403 00:21:33.115 --> 00:21:36.645 いいですね。それから、あなたの回答に補足すると、つまり
404 00:21:36.645 --> 00:21:38.485 スパース埋め込みの代わりに全文検索を使う利点の一つは
405 00:21:38.485 --> 00:21:40.925 ええと、スパース埋め込みを使う場合、
406 00:21:40.925 --> 00:21:43.165 通常は自分でそれらを計算する必要があります。
407 00:21:43.785 --> 00:21:45.765 ええと、それは、なかなか難しいことがあります。
408 00:21:45.905 --> 00:21:48.245 つまり、統計を自分で更新しなければなりません。
409 00:21:48.465 --> 00:21:51.445 ええと、一方で全文検索では、基本的に私たちがそれを
410 00:21:51.445 --> 00:21:53.685 代わりに処理するので、別のパイプラインを持つ必要がありません。
411 00:21:53.685 --> 00:21:56.645 つまり、ええと、それも行うものがある、ということです。
412 00:21:57.625 --> 00:22:01.925 ええと、かなり長いものが一つあります。ええ、読んでいます
413 00:22:02.235 --> 00:22:03.235 これは、現在、
414 00:22:03.235 --> 00:22:05.925 現在Crawlを活用したものを構築中で
415 00:22:05.925 --> 00:22:08.285 four AIとZeisを使って、基本的には金融ニュースを監視し
416 00:22:08.285 --> 00:22:09.845 その上にRAG機能を追加しています。
417 00:22:10.045 --> 00:22:14.045 2つ問題がありました。直面しているのは、1つ目、たくさんあります
418 00:22:14.045 --> 00:22:15.365 記事の長さは非常に異なり、
419 00:22:15.365 --> 00:22:16.845 極端に長いものもあります。
420 00:22:17.505 --> 00:22:19.285 では、チャンキングにはどのようにアプローチすべきでしょうか？
421 00:22:20.185 --> 00:22:22.885 もう一つは、それらが異なる言語であるということです。
422 00:22:23.225 --> 00:22:24.965 多言語ドキュメントをどのように埋め込みますか？
423 00:22:24.985 --> 00:22:26.565 同じ空間に埋め込みますか、
424 00:22:26.865 --> 00:22:28.245 それとも言語ごとに分けますか？
425 00:22:28.545 --> 00:22:30.245 多言語の埋め込みモデルをどのように持たせますか？
426 00:22:31.985 --> 00:22:33.205 ええと、その2つについていきましょう。
427 00:22:33.505 --> 00:22:35.045 その後でフォローアップの質問に移ります。
428 00:22:35.945 --> 00:22:40.075 わかりました。まず、とても興味深いプロジェクトですね。
429 00:22:40.335 --> 00:22:43.755 正直に言うと、これは非常に良い、ええと、
430 00:22:43.755 --> 00:22:46.635 特に株などに興味があるなら、かなり良いものです。
431 00:22:47.175 --> 00:22:49.515 それで、ええと、チャンキングの件については、
432 00:22:49.535 --> 00:22:51.155 私なら個人的にこう進めます。
433 00:22:51.155 --> 00:22:52.675 そしてこれは私がある意味
434 00:22:52.675 --> 00:22:54.075 このプロジェクトでも行ったことです。
435 00:22:54.665 --> 00:22:59.355 代わりに、私はチャンクを2つの方法で追跡しています。
436 00:22:59.615 --> 00:23:02.955 チャンクのID、つまり各チャンクには独自のidがあります。
437 00:23:03.255 --> 00:23:05.395 それから実際のチャンク番号です。
438 00:23:05.535 --> 00:23:09.395 読んでいる、ええと、
439 00:23:09.395 --> 00:23:12.635 クロールしている特定の単一ウェブサイトのものです。私ならそうします。
440 00:23:12.695 --> 00:23:16.115 そしてその特定のウェブサイトの最後のチャンクは、
441 00:23:16.115 --> 00:23:17.835 少し短くなりますが、
442 00:23:18.575 --> 00:23:20.515 ええと、それがそれほど大きな問題だとは
443 00:23:20.515 --> 00:23:21.795 本当に思いません。
444 00:23:22.395 --> 00:23:25.915 というのも通常、特に金融記事
445 00:23:25.915 --> 00:23:28.515 などでは、要点は中間部分にあるからです。
446 00:23:29.215 --> 00:23:31.395 なので、それが私の意見です。
447 00:23:32.215 --> 00:23:35.515 それから言語の部分についてですが、私は
448 00:23:35.545 --> 00:23:38.515 異なる言語向けの、ええと、
449 00:23:39.465 --> 00:23:40.795 異なる埋め込みモデルを試したことがあります。
450 00:23:42.635 --> 00:23:44.515 今でも残念だと
451 00:23:45.105 --> 00:23:48.405 言うべきなのか何なのかですが、ええと、これに対処する最善の方法は
452 00:23:48.405 --> 00:23:50.085 それらを英語に翻訳することです。
453 00:23:50.515 --> 00:23:55.435 なぜなら、マルチモデル、ええと、多言語モデル、
454 00:23:55.475 --> 00:23:58.355 つまり埋め込みモデルを使っても、
455 00:23:58.355 --> 00:24:01.395 決して同じ性能にはならないからです。それには
456 00:24:01.395 --> 00:24:03.995 より多くの、ええと、
457 00:24:04.335 --> 00:24:06.355 異なる言語、多言語で訓練されているという欠点があります。
458 00:24:06.815 --> 00:24:09.955 なので私なら個人的には、どんな記事でも英語に翻訳して、
459 00:24:09.955 --> 00:24:12.635 それからチャンキングのロジック
460 00:24:12.815 --> 00:24:13.995 そしてICロジックを続けます。
461 00:24:14.375 --> 00:24:16.995 それから最後の部分については、本当に、
462 00:24:17.165 --> 00:24:19.395 特に金融に関しては、ええと、
463 00:24:23.915 --> 00:24:27.675 私は本当に個人的には、ええと、BM 25
464 00:24:27.695 --> 00:24:31.395 とNNを使います、そうですね。
465 00:24:31.945 --> 00:24:35.995 はい。でも私は、そういうふうにやります。
466 00:24:37.395 --> 00:24:40.085 なるほど、ありがとうございます。ええ、Ari、
467 00:24:40.165 --> 00:24:42.125 あなたはすでに少し触れていたと思いますが、
468 00:24:42.835 --> 00:24:45.085 ハイブリッド検索やセマンティック検索の性能のようなものですね。
469 00:24:45.265 --> 00:24:47.245 あなたは基本的に、
470 00:24:47.305 --> 00:24:48.525 全文検索を使うことで、と言っていましたね
471 00:24:48.525 --> 00:24:49.565 パフォーマンスが向上する、そうですよね？
472 00:24:49.565 --> 00:24:51.085 Q&Aに最初の質問があります。
473 00:24:51.755 --> 00:24:53.885 ええ、それで、
474 00:24:54.105 --> 00:24:58.415 私の経験では本当にそうで、まだ
475 00:24:58.415 --> 00:25:00.695 欠点を一つも見つけられていません、つまり
476 00:25:00.695 --> 00:25:02.935 この解決策全体に疑問を抱かせるようなものです。
477 00:25:04.105 --> 00:25:05.575 注意点はあったかもしれませんが、
478 00:25:05.575 --> 00:25:06.695 それすら覚えていません。
479 00:25:07.075 --> 00:25:09.735 なので、かなりうまくいっています。
480 00:25:10.245 --> 00:25:12.935 いいですね。ええと、あと
481 00:25:12.935 --> 00:25:16.735 1、2分だけ待って、
482 00:25:16.735 --> 00:25:20.125 参加者からさらに質問があるか確認します。なければ、ええ、
483 00:25:20.125 --> 00:25:21.965 たぶんLinkedInであなたを追加できますし、
484 00:25:22.025 --> 00:25:23.445 あるいはどこか、質問がある場合に
485 00:25:23.625 --> 00:25:25.085 どこでフォローアップできますか？
486 00:25:25.945 --> 00:25:28.075 わかりました。LinkedInで追加できますね。ええと、
487 00:25:28.705 --> 00:25:31.755 はい、LinkedInは確か、持っていれば、
488 00:25:32.055 --> 00:25:35.305 または私のLinkedInかGitHubのどちらかです。
489 00:25:35.565 --> 00:25:37.275 ええ、はい、
490 00:25:39.875 --> 00:25:44.555 少しだけ待って、それから確認しましょう。
491 00:25:44.705 --> 00:25:48.165 そうでなければ、1時30分まで待って、
492 00:25:49.065 --> 00:25:52.045 質問がなければ、これを終了できます。
493 00:25:53.185 --> 00:25:54.565 でも、はい、とても興味深かったです。
494 00:25:54.685 --> 00:25:57.645 つまり、ユースケースも興味深いですね、
495 00:25:58.975 --> 00:26:00.905 単なるおもちゃプロジェクト以上のものとしても。
496 00:26:00.905 --> 00:26:03.825 うんうん。なのでこれは、ええ、とてもクールです。
497 00:26:04.575 --> 00:26:07.025 日常的に使われています。ええ、
498 00:26:07.365 --> 00:26:09.985 もちろん、先ほど述べたように改善の余地はあります。
499 00:26:10.015 --> 00:26:13.225 できれば、いくつかのロジックを実装したいです。
500 00:26:13.225 --> 00:26:16.985 異なるサイトマップを区別するものですね、つまり
501 00:26:17.045 --> 00:26:19.945 異なるプロジェクトやライブラリのものです。
502 00:26:20.765 --> 00:26:24.665 でも、そこまで複雑なものにはまだ取り組んでいません。うんうん。
503 00:26:24.745 --> 00:26:27.145 なので、複数の
504 00:26:27.765 --> 00:26:28.865 ものを同時に参照する必要はありませんでした。
505 00:26:28.975 --> 00:26:30.065 これまで問題ありませんでした。
506 00:26:31.025 --> 00:26:33.115 わかりました。わかりました。はい、
507 00:26:33.115 --> 00:26:34.635 もう質問はないようですね。
508 00:26:35.065 --> 00:26:36.715 では、プレゼンテーションをどうもありがとうございました。
509 00:26:37.095 --> 00:26:39.955 ええと、皆さん、皆さん、失礼しました、ご参加いただきありがとうございます。
510 00:26:40.415 --> 00:26:42.595 ええと、録画を後ほどお送りしますので、
511 00:26:42.985 --> 00:26:44.605 数日以内にご覧いただけます。
512 00:26:45.465 --> 00:26:47.965 そして私の方では、また近いうちにお会いしましょう。
513 00:26:48.365 --> 00:26:50.245 実際には来週、次のウェビナーでお会いします。
514 00:26:50.335 --> 00:26:53.685 Feastと一緒に、リアルタイムRagをどのように行えるかについてです。
515 00:26:54.225 --> 00:26:56.685 それではどうもありがとうございました。世界のどこにいらっしゃっても、素敵な朝、午後、
516 00:26:56.685 --> 00:26:57.885 または夜をお過ごしください。
517 00:26:58.705 --> 00:26:59.845 それではさようなら。
Meet the Speaker
Join the session for live Q&A with the speaker
Erbli Kuka
Data / AI Engineer at datamax.ai
Erbli Kuka is a Data / AI Engineer at datamax.ai specializing in ML/AI development and integration. He has gained deep insights into the TRANSFORMERS architecture, attention mechanisms, and other critical areas of machine learning. Passionate about ML, Erbli is committed to advancing his career and ultimately leading teams to create innovative solutions in cloud development and AI.